ПРЕДМЕТНЫЕ ОБЛАСТИ ДЛЯ ЭКСПЕРТНЫХ СИСТЕМ

ЭКСПЕРТНЫЕ СИСТЕМЫ: СТРУКТУРА И КЛАССИФИКАЦИЯ
ПРЕДМЕТНЫЕ ОБЛАСТИ ДЛЯ ЭКСПЕРТНЫХ СИСТЕМ
В нашей стране современное состояние разработок в области
экспертных систем можно охарактеризовать как стадию всевозрастающего
интереса среди широких слоев экономистов, финансистов, преподавателей,
инженеров, медиков, психологов, программистов, лингвистов. К сожалению,
этот интерес имеет пока достаточно слабое материальное подкрепление явная нехватка учебников и специальной литературы, отсутствие
символьных процессоров и рабочих станций искусственного интеллекта,
ограниченное финансирование исследований в этой области, слабый
отечественный рынок программных продуктов для разработки экспертных
систем.
Поэтому распространяются "подделки" под экспертные системы в виде
многочисленных диалоговых систем и интерактивных пакетов прикладных
программ, которые дискредитируют в глазах пользователей это чрезвычайно
перспективное направление. Процесс создания экспертной системы требует
участия высококвалифицированных специалистов в области искусственного
интеллекта, которых пока выпускает небольшое количество высших учебных
заведений страны.
Современные экспертные системы широко используются для
тиражирования опытам знаний ведущих специалистов практически во всех
сферах экономики. Традиционно знания существуют в двух видах коллективный опыт и личный опыт.
Если большая часть знаний в предметной области представлена в виде
коллективного опыта (например, высшая математика), эта предметная
область не нуждается в экспертных системах (рис.1).
Если в предметной области большая часть знаний является личным
опытом специалистов высокого уровня (экспертов), если эти знания по
каким-либо причинам слабо структурированы, такая предметная область
скорее всего нуждается в экспертной системе (рис. 2).
Рис. 1. Предметная область, не
пригодная для создания экспертной
системы
Рис. 2. Предметная область,
пригодная для создания экспертной
системы
ОБОБЩЕННАЯ СТРУКТУРА ЭКСПЕРТНОЙ СИСТЕМЫ.
ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ
Экспертные системы (ЭС) - это сложные программные комплексы,
аккумулирующие знания специалистов в конкретных предметных областях и
тиражирующие этот эмпирический опыт для консультаций менее
квалифицированных пользователей.
Обобщенная структура экспертной системы представлена на рис. 3.
Следует учесть, что реальные экспертные системы могут иметь более
сложную структуру, однако блоки, изображенные на рисунке, непременно
присутствуют в любой действительно экспертной системе, поскольку являют
собой негласный канон на структуру современной экспертной системы.
Рис. 3. Структура экспертной системы
Пользователь - специалист предметной области, для которого
предназначена система, Обычно его квалификация недостаточно высока, и
поэтому он нуждается в помощи и поддержке своей деятельности со стороны
ЭС.
Инженер по знаниям - специалист по искусственному интеллекту,
выступающий в роли промежуточного буфера между экспертом и базой
знаний. Синонимы: когнитолог, инженер-интерпретатор, аналитик.
Интерфейс пользователя - комплекс программ, реализующих диалог
пользователя с ЭС как на стадии ввода информации, так и получения
результатов.
База знаний (БЗ) - ядро ЭС, совокупность знаний предметной области,
записанная на машинный носитель в форме, понятной эксперту и
пользователю (обычно на некотором языке, приближенном к естественному).
Параллельно такому "человеческому" представлению существует БЗ во
внутреннем "машинном" представлении.
Решатель - программа, моделирующая ход рассуждений эксперта на
основании знаний, имеющихся в БЗ. Синонимы: дедуктивная машина, блок
логического вывода.
Подсистема объяснений - программа, позволяющая пользователю
получить ответы на вопросы; "Как была получена та или иная
рекомендация?" и "Почему система приняла такое решение?" Ответ на
вопрос "как" - это трассировка всего процесса получения решения с
указанием использованных фрагментов БЗ, т.е. всех шагов цепи
умозаключений. Ответ на вопрос "почему"- ссылка на умозаключение,
непосредственно предшествовавшее полученному решению, т.е. отход на
один шаг назад.
Интеллектуальный редактор БЗ - программа, представляющая
инженеру по знаниям возможность создавать БЗ в диалоговом режимеВключает в себя систему вложенных меню, шаблонов языка представления
знаний, подсказок ("help" - режим) и других сервисных средств,
облегчающих работу с базой.
В коллектив разработчиков ЭС входят как минимум четыре человека:
 эксперт;
 инженер по знаниям;
 программист;
 пользователь.
Возглавляет коллектив инженер по знаниям, это ключевая фигура при
разработке систем, основанных на знаниях.
КЛАССИФИКАЦИЯ ЭКСПЕРТНЫХ СИСТЕМ
Схема классификации
Класс "экспертные системы" сегодня объединяет несколько тысяч
различных программных комплексов, которые можно классифицировать по
различным
критериям.
Полезными
могут
оказаться
следующие
классификации
Рис. 4. Классификация экспертных систем.
Классификация по решаемой задаче
Интерпретация данных. Это одна из традиционных задач для
экспертных систем. Под интерпретацией понимается определение смысла
данных, результаты которого должны быть согласованными и корректными.
Обычно предусматривается многовариантный анализ данных.
Пример:
 обнаружение и идентификация различных типов океанских судов SIAP;
 определение
основных
свойств
личности
по
результатам
психодиагностического тестирования в системах АВТАНТЕСТ и
МИКРОЛЮШЕР и др.
Диагностика.
Под
диагностикой
понимается
обнаружение
неисправности в некоторой системе. Неисправность - это отклонение от
нормы. Такая трактовка позволяет с единых теоретических позиций
рассматривать и неисправность оборудования в технических системах, и
заболевания живых организмов, и всевозможные природные аномалии.
Важной спецификой является необходимость понимания функциональной
структуры ("анатомии") диагностирующей системы.
Пример:
 диагностика и терапия сужения коронарных сосудов - ANGY;
 диагностика ошибок в аппаратуре и математическом обеспечении ЭВМ
- система CRIB и др.
Мониторинг. Основная задача мониторинга - непрерывная
интерпретация данных в реальном масштабе времени и сигнализация о
выходе тех или иных параметров за допустимые пределы. Главные проблемы
- "пропуск" тревожной ситуации и инверсная задача "ложного"
срабатывания. Сложность этих проблем в размытости симптомов тревожных
ситуаций и необходимость учета временного контекста.
Пример:
 контроль за работой электростанций СПРИНТ, помощь диспетчерам
атомного реактора - REACTOR:
 контроль аварийных датчиков на химическом заводе - FALCON и др.
Проектирование. Проектирование состоит в подготовке спецификаций
на создание "объектов" с заранее определенными свойствами. Под
спецификацией понимается весь набор необходимых документов чертеж,
пояснительная записка и т.д. Основные проблемы здесь - получение четкого
структурного описания знаний об объекте и проблема "следа". Для
организации эффективного проектирования и, в еще большей степени,
перепроектирования необходимо формировать не только сами проектные
решения, но и мотивы их принятия. Таким образом, в задачах
проектирования тесно связываются два основных процесса, выполняемых в
рамках соответствующей ЭС: процесс вывода решения и процесс объяснения.
Пример:
 проектирование конфигураций ЭВМ VAX ― 1/780 в системе XCON
(или R1), проектирование БИС - CADHELP;
 синтез электрических цепей - SYN и др.
Прогнозирование. Прогнозирующие системы логически выводят
вероятные следствия из заданных ситуаций. В прогнозирующей системе
обычно используется параметрическая динамическая модель, в которой
значения параметров "подгоняются" под заданную ситуацию. Выводимые из
этой модели следствия составляют основу для прогнозов с вероятностными
оценками.
Пример:
 предсказание погоды - система WILLARD:
 оценки будущего урожая - PI.ANT;
 прогнозы в экономике - ЕСОN и др.
Планирование. Под планированием понимается нахождение планов
действий, относящихся к объектам, способным выполнять некоторые
функции. В таких ЭС используются модели поведения реальных объектов с
тем, чтобы логически вывести последствия планируемой деятельности.
Пример:
 планирование поведения робота - STRIPS,
 планирование промышленных заказов - 1SIS,
 планирование эксперимента - MOLGEN и др.
Обучение. Системы обучения диагностируют ошибки при изучении
какой-либо дисциплины с помощью ЭВМ и подсказывают правильные
решения. Они аккумулируют знания о гипотетическом "ученике" и его
характерных ошибках, затем в работе способны диагностировать слабости в
знаниях обучаемых и находить соответствующие средства для их
ликвидации. Кроме того, они планируют акт общения с учеником в
зависимости от успехов ученика с целью передачи знаний.
Пример:
 обучение языку программирования Лисп в системе "Учитель Лиспа";
 система PROUST - обучение языку Паскаль и др.
Классификация по связи с реальным временем
Статические ЭС разрабатываются в предметных областях, в которых
база знаний и интерпретируемые данные не меняются во времени. Они
стабильны.
Пример. Диагностика неисправностей в автомобиле.
Квазидинамические ЭС интерпретируют ситуацию, которая меняется с
некоторым фиксированным интервалом времени.
Пример. Микробиологические ЭС, в которых снимаются лабораторные
измерения с технологического процесса один раз в 4 - 5 (производство
лизина, например) и анализируется динамика полученных показателей по
отношению к предыдущему измерению.
Динамические ЭС работают в сопряжении с датчиками объектов в
режиме реального времени с непрерывной интерпретацией поступаемых
данных.
Пример. Управление гибкими производственными комплексами,
мониторинга реанимационных палатах и т.д. Пример инструментария для
разработки динамических систем - G2.
Классификация по типу ЭВМ
На сегодняшний день существуют:
 ЭС для уникальных стратегически важных задач на суперЭВМ
(Эльбрус, CONVEX и др.);
 ЭС на ЭВМ средней производительности (типа ЕС ЭВМ, mainframe);
 ЭС на символьных процессорах и рабочих станциях (SUN, APOLLO);
 ЭС на мини- и супермини-ЭВМ (VAX, micro-VAX и др.);
 ЭС на персональных компьютерах (IBM PC, MAC II и подобные).
Классификация по степени интеграции с другими программами
Автономные ЭС работают непосредственно в режиме консультаций с
пользователем для специфически "экспертных" задач, для решения которых
не требуется привлекать традиционные методы обработки данных (расчеты,
моделирование и т. д.).
Гибридные ЭС представляют программный комплекс, агрегирующий
стандартные пакеты прикладных программ (например, математическую
статистику, линейное программирование или системы управления базами
данных) и средства манипулирования знаниями.
Несмотря на внешнюю привлекательность гибридного подхода, следует
отметить, что разработка таких систем являет собой задачу, на порядок более
сложную, чем разработка автономной ЭС. Стыковка не просто разных
пакетов, а разных методологий (что происходит в гибридных системах)
порождает целый комплекс теоретических и практических трудностей.
ИНСТРУМЕНТАЛЬНЫЕ
СРЕДСТВА
ПОСТРОЕНИЯ
ЭКСПЕРТНЫХ СИСТЕМ
Традиционные языки программирования
Языки искусственного интеллекта
Это, прежде всего Лисп (LISP) и Пролог (Prolog) - наиболее
распространенные
языки,
предназначенные
для
решения
задач
искусственного интеллекта. Есть и менее распространенные языки
искусственного интеллекта, например РЕФАЛ, разработанный в России.
Универсальность этих языков меньшая, нежели традиционных языков, но ее
потерю языки искусственного интеллекта компенсируют богатыми
возможностями по работе с символьными и логическими данными, что
крайне важно для задач искусственного интеллекта. На основе языков
искусственного интеллекта создаются специализированные компьютеры
(например, Лисп-машины), предназначенные для решения задач
искусственного интеллекта. Недостаток этих языков - неприменимость для
создания гибридных экспертных систем.
Специальный программный инструментарий
В эту группу программных средств искусственного интеллекта входят
специальные инструментарии общего назначения. Как правило, это
библиотеки и надстройки над языком искусственного интеллекта Лисп: KEE
(Knowledge Engineering Environment), FRL (Frame Representation Language),
KRL (Knowledge Represantation Language), ARTS и др., позволяющие
пользователям работать с заготовками экспертных систем на более высоком
уровне, нежели это возможно в обычных языках искусственного интеллекта.
ТЕХНОЛОГИЯ РАЗРАБОТКИ ЭКСПЕРТНЫХ СИСТЕМ
ЭТАПЫ РАЗРАБОТКИ
Разработка программных комплексов экспертных систем, как за
рубежом, так и в нашей стране находится на уровне скорее искусства, чем
науки. Это связано с тем, что долгое время системы искусственного
интеллекта внедрялись в основном во время фазы проектирования, а чаще
всего разрабатывалось несколько прототипных версий программ, прежде чем
был получен конечный продукт. Такой подход действует хорошо в
исследовательских условиях, однако в коммерческих условиях он является
слишком дорогим, чтобы оправдать коммерчески жизненный продукт.
Процесс разработки промышленной экспертной системы, опираясь на
традиционные технологии, можно разделить на шесть более или менее
независимых этапов (рис 5), практически не зависимых от предметной
области.
Последовательность этапов дана для общего представления о создании
идеального проекта. Конечно, последовательность эта не вполне
фиксированная. В действительности каждый последующий этап разработки
ЭС приносит новые идеи, которые могут повлиять на предыдущие решения и
даже привести к их переработке. Именно поэтому многие специалисты по
информатике весьма критично относятся к методологии экспертных систем.
Они считают, что расходы на разработку таких систем очень большие, время
разработки слишком длительное, а полученные в результате программы
ложатся тяжелым бременем на вычислительные ресурсы.
В целом за разработку экспертных систем целесообразно браться
организации, где накоплен опыт по автоматизации рутинных процедур
обработки информации, например:
информационный поиск;
сложные расчеты;
графика;
обработка текстов.
Решение
таких
задач,
во-первых,
подготавливает
высококвалифицированных специалистов по информатике, необходимых для
создания интеллектуальных систем, во-вторых, позволяет отделить от
экспертных систем неэкспертные задачи.
ЭТАП 1: ВЫБОР ПОДХОДЯЩЕЙ ПРОБЛЕМЫ
Этот этап включает деятельность, предшествующую решению начать
разрабатывать конкретную ЭС. Он включает:
- определение проблемной области и задачи;
- нахождение эксперта, желающего сотрудничать при решении
проблемы, и назначение коллектива разработчиков;
- определение предварительного подхода к решению проблемы;
- анализ расходов и прибыли от разработки;
- подготовку подробного плана разработки.
Рис. 5. Этапы разработки ЭС
Правильный выбор проблемы представляет, наверное, самую
критическую часть разработки в целом. Если выбрать неподходящую
проблему, можно очень быстро увязнуть в "болоте" проектирования задач,
которые никто не знает, как решать. Неподходящая проблема может также
привести к созданию экспертной системы, которая стоит намного больше,
чем экономит. Дело будет обстоять еще хуже, если разработать систему,
которая работает, но не приемлема для пользователей. Даже если разработка
выполняется самой организацией для собственных целей, эта фаза является
подходящим моментом для получения рекомендаций извне, чтобы
гарантировать удачно выбранный и осуществимый с технической точки
зрения первоначальный проект.
При выборе области применения следует учитывать, что если знание,
необходимое для решения задач, постоянное, четко формулируемое и
связано с вычислительной обработкой, то обычные алгоритмические
программы, по всей вероятности, будут самым целесообразным способом
решения проблем в этой области,
Экспертная система ни в коем случае не устранит потребность в
реляционных базах данных, статистическом программном обеспечении,
электронных таблицах и системах текстовой обработки. Но если
результативность задачи зависит от знания, которое является субъективным,
изменяющимся, символьным или вытекающим частично из соображений
здравого смысла, тогда область может обоснованно выступать претендентом
на экспертную систему.
Приведем некоторые факты, свидетельствующие о необходимости
разработки и внедрения экспертных систем:
- нехватка специалистов, расходующих значительное время для оказания
помощи другим;
- потребность в многочисленном коллективе специалистов, поскольку ни
один из них не обладает достаточным знанием;
- сниженная производительность, поскольку задача требует полного
анализа сложное набора условий, а обычный специалист не в состоянии
просмотреть (за отведенное время) все эти условия;
- большое расхождение между решениями самых хороших и самых
плохих исполнителей;
- наличие конкурентов, имеющих преимущество в том, что они лучше
справляются с поставленной задачей.
Подходящие задачи имеют следующие характеристики:
- являются узкоспециализированными;
- не зависят в значительной степени от общечеловеческих знаний или
соображении здравого смысла;
- не являются для эксперта ни слишком легкими, ни слишком сложными
(время, необходимое эксперту для решения проблемы, может составлять
от трех часов до трех недель);
- условия исполнения задачи определяются самим пользователем системы;
- имеет результаты, которые можно оценить.
Обычно экспертные системы разрабатываются путем получения
специфических знаний от эксперта и ввода их в систему. Некоторые системы
могут содержать стратегии одного индивида. Следовательно, найти
подходящего эксперта - это ключевой шаг в создании экспертных систем.
В процессе разработки и последующего расширения системы инженер
по знаниям и эксперт обычно работают вместе. Инженер по знаниям
помогает эксперту структурировать знания, определять и формализовать
понятия и правила, необходимые для решения проблемы.
Во время первоначальных бесед они решают, будет ли их
сотрудничество успешным. Это немаловажно, поскольку обе стороны будут
работать вместе по меньшей мере в течение одного года. Кроме них в
коллектив разработчиков целесообразно включить потенциальных
пользователей и профессиональных программистов.
Предварительный подход к программной реализации задачи
определяется исходя из характеристик задачи и ресурсов, выделенных на ее
решение. Инженер по знаниям выдвигает обычно несколько вариантов,
связанных с использованием имеющихся на рынке программных средств.
Окончательный выбор возможен лишь на этапе разработки прототипа.
После того как задача определена, необходимо подсчитать расходы и
прибыли от разработки экспертной системы. В расходы включаются затраты
на оплату труда коллектива разработчиков. В дополнительные расходы
приобретаемого программного инструментария, с помощью которого
разрабатывается экспертная система.
Прибыль возможна за счет снижения цены продукции, повышения
производительности труда, расширения номенклатуры продукции или услуг
или даже разработки новых видов продукции или услуг в этой области.
Соответствующие расходы и прибыли от системы определяются
относительно времени, в течение которого возвращаются средства,
вложенные в разработку. На современном этапе большая часть фирм,
развивающих крупные экспертные системы, предпочли разрабатывать
дорогостоящие проекты, приносящие значительные прибыли.
Наметились тенденции разработки менее дорогостоящих систем, хотя и
с более длительным сроком возвращаемости вложенных в них средств, так
как программные средства разработки экспертных систем непрерывно
совершенствуются.
После того как инженер по знаниям убедился, что:
 данная задача может быть решена с помощью экспертной системы;
 экспертную систему можно создать предлагаемыми на рынке
средствами;
 имеется подходящий эксперт;
 предложенные критерии производительности являются разумными;
 затраты и срок их возвращаемости приемлемы для заказчика.
он составляет план разработки. План определяет шаги процесса
разработки и необходимые затраты, а также ожидаемые результаты.
ЭТАП 2: РАЗРАБОТКА ПРОТОТИПНОЙ СИСТЕМЫ
Понятие прототипной системы
Прототипная система является усеченной версией экспертной
системы, спроектированной для проверки правильности кодирования фактов,
связей и стратегий рассуждения эксперта. Она также дает возможность
инженеру по знаниям привлечь эксперта к активному участию в разработке
экспертной системы и, следовательно, к принятию им обязательства
приложить все усилия для создания системы в полном объеме.
Объем прототипа - несколько десятков правил, фреймов или примеров.
На рис. 6 изображены шесть стадий разработки прототипа и минимальный
коллектив разработчиков, занятых на каждой из стадий (пять стадий
заимствованы из). Приведем краткую характеристику каждой из стадий, хотя
эта схема представляет грубое приближение к сложному итеративному
процессу.
Рис. 6. Стадии разработки прототипа ЭС
Хотя любое теоретическое разделение бывает часто условным,
осознание коллективом разработчиков четких задач каждой стадии
представляется целесообразным. Роли разработчиков (эксперт, программист,
пользователь и аналитик) являются постоянными на протяжении всей
разработки. Совмещение ролей нежелательно.
Сроки приведены условно, так как зависят от квалификации
специалистов и особенностей задачи.
Идентификация проблемы
Уточняется задача, планируется ход разработки прототипа экспертной
системы, определяются:
необходимые ресурсы (время, люди, ЭВМ и т.д.);
источники знаний (книги, дополнительные эксперты, методики);
имеющиеся аналогичные экспертные системы;
цели (распространение опыта, автоматизация рутинных действий и др.);
классы решаемых задач и т.д.
Идентификация проблемы - знакомство и обучение коллектива
разработчиков, а также создание неформальной формулировки проблемы.
Средняя продолжительность 1 - 2 недели.
Извлечение знаний
Происходит перенос компетентности экспертов на инженеров по
знаниям с использованием различных методов:
- анализ текстов;
- диалоги;
- экспертные игры;
- лекции;
- дискуссии;
- интервью;
- наблюдение и другие.
Извлечение знаний - получение инженером по знаниям наиболее
полного представления о предметной области и способах принятия решения
в ней.
Средняя продолжительность 1 -3 месяца.
Структурирование или концептуализация знаний
Выявляется структура полученных знаний о предметной области, т.е.
определяются:
терминология;
список основных понятий и их атрибутов;
отношения между понятиями;
структура входной и выходной информации;
стратегия принятия решений;
ограничения стратегий и т.д.
Концептуализация знаний - разработка неформального описания
знаний о предметной области в виде графа, таблицы, диаграммы или текста,
которое отражает основные концепции и взаимосвязи между понятиями
предметной области.
Такое описание называется полем знаний. Средняя продолжительность
этапа 2 - 4 недели.
Формализация.
Строится формализованное представление концепций предметной
области на основе выбранного языка представления знаний (ЯПЗ).
Традиционно на этом этапе используются:
логические методы (исчисления предикатов I порядка и др.);
продукционные модели (с прямым и обратным выводом);
семантические сети;
фреймы;
объектно-ориентированные языки, основанные на иерархии классов,
объектов и др.
Формализация знаний - разработка базы знаний на языке, который, с
одной стороны, соответствует структуре поля знаний, а с другой - позволяет
реализовать прототип системы на следующей стадии программной
реализации.
Все чаще на этой стадии используется симбиоз языков представления
знаний, например, в системе ОМЕГА - фреймы + семантические сети +
полный набор возможностей языка исчисления предикатов. Средняя
продолжительность 1 - 2 месяца.
Реализация
Создается прототип экспертной системы, включающий базу знаний и
остальные блоки, при помощи одного из следующих способов:
- программирование на традиционных языках типа Паскаль, Си и др.;
- программирование на специализированных языках, применяемых в
задачах искусственного интеллекта: LISP, FRL, SmallTalk и др.;
- использование инструментальных средств разработки ЭС типа СПЭИС,
ПИЭС;
- использование "пустых" ЭС или "оболочек" типа ЭКСПЕРТ, ФИАКР и
др.
Реализация - разработка программного комплекса, демонстрирующего
жизнеспособность подхода в целом. Чаще всего первый прототип
отбрасывается на этапе реализации действующей ЭС.
Средняя продолжительность 1 - 2 месяца.
Тестирование
Оценивается и проверяется работа программ прототипа с целью
приведения в соответствие с реальными запросами пользователей. Прототип
проверяется на:
- удобство и адекватность интерфейсов ввода-вывода (характер вопросов в
диалоге, связность выводимого текста результата и др.)
- эффективность стратегии управления (порядок перебора, использование
нечеткого вывода и др.);
- качество проверочных примеров;
- корректность базы знаний (полнота и непротиворечивость правил).
Тестирование - выявление ошибок в подходе и реализации прототипа и
выработка рекомендаций по доводке системы до промышленного варианта.
Средняя продолжительность 1 - 2 недели.
ЭТАП 3: РАЗВИТИЕ ПРОТОТИПА ДО ПРОМЫШЛЕННОЙ ЭС
При неудовлетворительном функционировании прототипа эксперт и
инженер по знаниям имеют возможность оценить, что именно будет
включено в разработку окончательного варианта системы.
Если первоначально выбранные объекты или свойства оказываются
неподходящими, их необходимо изменить. Можно сделать оценку общего
числа эвристических правил, необходимых для создания окончательного
варианта экспертной системы. Иногда при разработке промышленной
системы выделяют дополнительные этапы для перехода: демонстрационный
прототип - исследовательский прототип - действующий прототип промышленная система.
Однако чаще реализуется плавный переход от демонстрационного
прототипа к промышленной системе, при этом, если программный
инструментарий выбран удачно, необязательна перепись другими
программными средствами.
Понятие же коммерческой системы в нашей стране входит в понятие
промышленный программный продукт, или промышленной ЭС в этой работе
(табл.1).
Таблица 1. Переход от прототипа к промышленной экспертной системе
Демонстрационный прототип ЭС
Система
решает
часть
задач,
демонстрируя
жизнеспособность
подхода (несколько десятков правил
или понятий)
Исследовательский прототип ЭС
Система решает большинство задач,
но не устойчива в работе и не
полностью проверена
Действующий прототип ЭС
Система надежно решает все задачи
на реальных примерах, но для
сложной задачи требует много
времени и памяти
Промышленная система
Система
обеспечивает
высокое
качество решений при минимизации
требуемого времени и памяти:
переписывается с использованием
более
эффективных
средств
представления знаний
Коммерческая система
Промышленная система, пригодная к
продаже,
т.е.
хорошо
документирована
и
снабжена
сервисом
Основное на третьем этапе заключается в добавлении большого числа
дополнительных эвристик. Эти эвристики обычно увеличивают глубину
системы, обеспечивая большее число правил для трудноуловимых аспектов
отдельных случаев. В то же время эксперт и инженер по знаниям могут
расширить охват системы, включая правила, управляющие дополнительными
подзадачами или дополнительными аспектами экспертной задачи
(метазнания).
После установления основной структуры ЭС инженер по знаниям
приступает к разработке и адаптации интерфейсов, с помощью которых
система будет общаться с пользователем и экспертом. Необходимо обратить
особое внимание на языковые возможности интерфейсов, их простоту и
удобство для управления работой ЭС. Система должна обеспечивать
пользователю возможность легким и естественным образом спрашивать
непонятное, приостанавливать работу и т.д. В частности, могут оказаться
полезными графические представления.
На этом этапе разработки большинство экспертов узнают достаточно о
вводе правил и могут сами вводить в систему новые правила. Таким образом,
начинается процесс, во время которого инженер по знаниям передает право
собственности и контроля за системой эксперту для уточнения, детальной
разработки и обслуживания.
ЭТАП 4: ОЦЕНКА СИСТЕМЫ
После завершения этапа разработки промышленной экспертной системы
необходимо провести ее тестирование в отношении критериев
эффективности. К тестированию широко привлекаются другие эксперты с
целью апробирования работоспособности системы на различных примерах.
Экспертные системы оцениваются главным образом для того, чтобы
проверить точность работы программы и ее полезность. Оценку можно
проводить, исходя из различных критериев, которые сгруппируем
следующим образом:
- критерии пользователей (понятность и "прозрачность" работы системы,
удобство интерфейсов и др.);
- критерии приглашенных экспертов (оценка советов-решений,
предлагаемых системой, сравнение ее с собственными решениями, оценка
подсистемы объяснений и др.);
- критерии коллектива разработчиков (эффективность реализации,
производительность, время отклика, дизайн, широта охвата предметной
области, непротиворечивость БЗ, количество тупиковых ситуаций, когда
система не может принять решение, анализ чувствительности программы к
незначительным изменениям в представлении знаний, весовых
коэффициентах, применяемых в механизмах логического вывода, данных и
т.п.).
ЭТАП 5: СТЫКОВКА СИСТЕМЫ
На этом этапе осуществляется стыковка экспертной системы с другими
программными средствами в среде, в которой она будет работать, и обучение
людей, которых она будет обслуживать. Иногда это означает внесение
существенных изменений. Такое изменение требует непременного
вмешательства инженера по знаниям или какого-либо другого специалиста,
который сможет модифицировать систему. Под стыковкой подразумевается
также разработка связей между экспертной системой и средой, в которой она
действует.
Когда экспертная система уже готова, инженер по знаниям должен
убедиться в том, что эксперты, пользователи и персонал знают, как
эксплуатировать и обслуживать ее. После передачи им своего опыта в
области информационной технологии инженер по знаниям может полностью
предоставить ее в распоряжение пользователей.
Для подтверждения полезности системы важно предоставить каждому
из пользователей возможность поставить перед ЭС реальные задачи, а затем
проследить, как она выполняет эти задачи. Чтобы система была одобрена,
необходимо представить ее как помощника, освобождающего пользователей
от обременительных задач, а не как средство их замещения.
Стыковка включает обеспечение связи ЭС с существующими базами
данных и другими системами на предприятии, а также улучшение системных
факторов, зависящих от времени, чтобы можно было обеспечить ее более
эффективную работу и улучшить характеристики ее технических средств,
если система работает в необычной среде (например, связь с
измерительными устройствами).
Пример. Успешно состыкована со своим окружением система PUFF экспертная система для диагностики заболеваний легких. После того, как
PUFF была закончена и все были удовлетворены ее работой, систему
перекодировали с LISPa на Бейсик. Затем систему перенесли на ПК, которая
уже работала и больнице. В свою очередь, эта ПК была связана с
измерительными приборами. Данные с измерительных приборов сразу
поступают в ПК. PUFF обрабатывает эти данные и печатает рекомендации
для врача. Врач в принципе не взаимодействует с PUFF. Система полностью
интегрирована со своим окружением - она представляет собой
интеллектуальное расширение аппарата исследования легких, который врачи
давно используют.
Пример. Другая система, которая хорошо функционирует в своем
окружении, - САТ-1 - экспертная система для диагностики неисправностей
дизелей локомотивов.
Эта система была разработана также на LISPe, а затем переведена на
FORTH, чтобы ее можно было более эффективно использовать в различных
локомотивных цехах. Мастер по ремонту запрашивает систему: определить
возможные причины неисправности дизеля. Система связана с видеодиском,
с помощью которого мастеру дают визуальные объяснения и подсказки
относительно более подробных проверок, которые ему нужно сделать.
Кроме того, если оператор не уверен в том, как устранить
неисправность, система предоставляет ему обучающие материалы, которые
фирма подготовила предварительно, и показывает ему на видеотерминале.
Таким образом, мастер по ремонту может с помощью экспертной системы
диагностировать проблему, найти тестовую процедуру, которую он должен
использовать, получить на дисплее объяснение, как провести тест, или
получит инструкции о том, как справиться с возникшей проблемой.
ЭТАП 6: ПОДДЕРЖКА СИСТЕМЫ
При перекодировании системы на язык, подобный Си, повышается ее
быстродействие и увеличивается переносимость, однако гибкость при этом
уменьшается. Это приемлемо лишь в том случае, если система сохраняет все
знания проблемной области, и это знание не будет изменяться в ближайшем
будущем. Однако если экспертная система создана именно из-за того, что
проблемная область изменяется, то необходимо поддерживать систему в
инструментальной среде разработки.
Пример. Удачным примером ЭС, внедренной таким образом, является
XCON (R1) - ЭС, которую фирма DEC использует для комплектации ЭВМ
семейства VAX. Одна из ключевых проблем, с которой столкнулась фирма
DEC, - необходимость постоянного внесения изменений для новых версий
оборудования, новых спецификаций и т.д. Для этой цели XCON
поддерживается в программной среде OPS5.