Интеллектуальные информационные системы

КемИ РГТЭУ

В приведенной классификации некоторые из категорий задач перекрываются или включают

друг друга. Альтернативный метод классификации предложил Кленси В., взяв за основу набор родовых операций, которые выполняются по отношению к реальной обслуживаемой системе (механической, биологической, электрической и т.д.).
Кленси предложил разделять синтетические операции, результатом которых является изменение структуры (конструкции) системы, и аналитические операции, которые интерпретируют характеристики и свойства системы, не изменяя ее как таковую (рис. 5.1, 5.2).

207

Рисунок 5.1 Иерархия родовых аналитических операций

208

Рисунок 5.2 Иерархия родовых синтетических операций

209

можно разделить на шесть этапов:
Выбор проблемы.
Разработка прототипа ЭС.
Доработка до промышленной

ЭС.
Оценка ЭС.
Стыковка ЭС.
Поддержка ЭС.

Последовательность этапов не вполне фиксированная. Каждый последующий этап может принести новые идеи, которые повлияют на предыдущие этапы и приведут к их переработке. Рассмотрим подробнее содержимое каждого из этапов.

210

этап определяет деятельность, предшествующую началу разработки конкретной ЭС и включает:
определение

проблемной области и задачи (данная задача может быть решена с помощью ЭС; ЭС можно создать предлагаемыми на рынке средствами);
нахождение эксперта, желающего сотрудничать при решении проблемы и создание коллектива разработчиков;
определение предварительного подхода к решению проблемы;
анализ расходов и прибылей от разработки;
подготовку подробного плана разработки.
В расходы включаются затраты на оплату труда коллектива разработчиков и стоимость приобретаемого программного инструментария.
Прибыль может быть получена за счет снижения цены продукции, повышения производительности труда, расширения номенклатуры продукции или услуг, и даже разработки новых видов продукции или услуг в области, в которой будет использоваться ЭС.
Соответствующие расходы и прибыль от системы определяются относительно времени, в течение которого возвращаются средства, вложенные в разработку.

211

разработке ЭС, как правило, используется концепция «быстрого прототипа».
Прототипы должны

удовлетворять двум противоречивым требованиям:
они должны решать типичные задачи конкретного приложения,
время и трудоемкость их разработки должны быть весьма незначительны, чтобы можно было максимально запараллелить процесс накопления и отладки знаний (осуществляемый экспертом) с процессом выбора (разработки) программных средств (осуществляемым инженером по знаниям и программистом).
Прототип должен продемонстрировать пригодность методов инженерии знаний для данного приложения.
В случае успеха эксперт с помощью инженера по знаниям расширяет знания прототипа о проблемной области. При неудаче может потребоваться разработка нового прототипа или разработчики могут прийти к выводу о непригодности методов ЭС для данного приложения.
По мере увеличения знаний прототип может достигнуть такого состояния, когда он успешно решает все задачи данного приложения.
Преобразование прототипа ЭС в конечный продукт обычно приводит к перепрограммированию ЭС на языках низкого уровня, обеспечивающих как увеличение быстродействия ЭИС, так и уменьшение требуемой памяти.
Прототипная система является усеченной версией ЭС, спроектированной для проверки правильности кодирования фактов, связей и стратегий рассуждения эксперта. Она дает возможность инженеру знаний привлечь эксперта к активному участию в процессе разработки ЭС.
Объем прототипа – несколько десятков правил, фреймов или примеров. На рис. 6.1 изображены шесть стадий разработки прототипа и минимальный коллектив разработчиков, занятых на каждой стадии.

212

проблемы - знакомство и обучение членов коллектива разработчиков, а также

создание неформальной формулировки проблемы.
На этой стадии определяется: необходимые ресурсы (время, люди, ЭВМ); источники знаний (книги, дополнительные эксперты, методики); имеющиеся аналогичные ЭС; классы решаемых задач; цели разработки (распространение опыта, автоматизация рутинных действий).
Средняя продолжительность стадии - 1-2 недели.
2.Извлечение знаний - получение ИЗ наиболее полного из возможных представлений о ПО и способах принятия решений в ней.
На этой стадии происходит перенос компетентности от эксперта к инженерам знаний, с использованием разных методов: анализ текстов, диалоги, экспертные игры, лекции, дискуссии, интервью, наблюдение и др.
Средняя продолжительность стадии - 4-12 недель.

214

знаний - разработка неформального описания знаний о ПО в виде

графа, таблицы, диаграммы или текста, которое отражает основные концепции и взаимосвязи между понятиями ПО. Такое описание называется полем знаний.
Выявляется структура полученных знаний о ПО, то есть определяются:
терминология;
список основных понятий и их атрибутов;
отношения между понятиями;
структура входной и выходной информации;
стратегия принятия решений.
Средняя продолжительность стадии - 2-4 недели.
4.Формализация знаний - это разработка БЗ на языке представления знаний, которая с одной стороны соответствует структуре поля знаний, а с другой стороны позволяет реализовать прототип системы на следующей стадии программной реализации.
Средняя продолжительность стадии - 4 – 8 недель.

215

- это разработка программного комплекса, демонстрирующая жизнеспособность прототипа в целом.
На

этом этапе создается прототип ЭС при помощи одного из следующего способов:
программирование на традиционном языке (Pascal, Си);
программирование на языках искусственного интеллекта;
использование пустых ЭС или оболочек;
использование инструментальных средств разработки ЭС.
Средняя продолжительность стадии - 4-8 недель.
6.Тестирование - выявление ошибок в подходе и реализации прототипа и выработка рекомендаций по доводке системы до промышленного варианта.
Прототип проверяется на:
удобство и адекватность интерфейсов ввода-вывода;
эффективность стратегии управления;
качество проверочных примеров;
корректность БЗ.
Средняя продолжительность стадии - 1-2 недели.

216

ЭС Стадии перехода от прототипа к промышленной ЭС
217

этапа разработки промышленной ЭС необходимо провести ее тестирование в отношении

коэффициентов эффективности. К тестированию широко привлекаются другие эксперты с целью апробирования системы на различных примерах. Оценка проводится по нескольким критериям:
1) Критерии пользователя:
понятность;
прозрачность работы системы;
удобство интерфейса и др.
2) Критерии приглашенных экспертов:
оценка советов-решений, предлагаемых системой;
сравнение их с собственными решениями;
оценка подсистемы объяснений.
3) Критерии коллектива разработчиков:
эффективность реализации;
производительность;
время отклика;
дизайн;
широта охвата ПО;
непротиворечивость БЗ;
количество тупиковых ситуаций, когда система не может принять решение и т.д.

218

этапе осуществляется стыковка системы с другими программными средствами в среде,

в которой она будет работать и обучение людей, которых она будет обслуживать.
Стыковка включает обеспечение связей ЭС с существующими БД и другими системами на предприятии, а также улучшение системных факторов, зависящих от времени, чтобы обеспечить ее более эффективную работу и улучшить характеристики ее технических устройств, если система работает в необычной среде (например, связь с измерительными устройствами).
Пример 1: Cистема PUFF – ЭС для диагностики заболеваний легких успешно состыкована со своим окружением. Разработана на языке ЛИСП, потом для стыковки перекодирована на Бейсик, систему была перенесена на ПК и установлена в больнице. ЭВМ связали с измерительными приборами. Данные с измерительных приборов поступают в систему, она их обрабатывает и печатает рекомендации для врачей. ЭС представляет собой интеллектуальное расширение аппарата исследования легких.
Пример 2: Система САТ-1 для диагностики неисправности двигателей локомотивов. Разработана на ЛИСП, перекодирована на FORTH. Мастер по ремонту запрашивает систему о возможных причинах неисправности дизеля. Система связана с видеодиском, с помощью которого мастеру показывается визуальное объяснение и подсказки.

219

системы на язык программирования высокого уровня повышается ее быстродействие, переносимость,

эффективность, однако снижается гибкость. Поэтому перекодирование используется в тех случаях, если система сохраняет все знания ПО и они не будут изменяться в ближайшем будущем. Если ЭС создана именно из-за того, что проблемная область изменяется, то необходимо поддерживать систему в ее инструментальной среде разработки.
Пример:
Система XCON, которую фирма DEC использует для комплектации ЭВМ семейства VAX, внедрена именно таким образом. В систему постоянно вносятся изменения для новых версий оборудования, новых спецификаций. Для этой цели XCON поддерживается в программной среде OPS5.

220

Рисунок 7.1 Классификация методов извлечения знаний
221