Классификация экспертных систем

КЛАССИФИКАЦИЯ ЭКСПЕРТНЫХ СИСТЕМ

Схема классификации

Класс "экспертные системы" сегодня объединяет несколько тысяч различных программных комплексов, которые можно классифицировать по различным критериям. Полезными могут оказаться следующие классификации (рис. 16.6).

Рис. 16.6. Классификация экспертных систем

Классификация по решаемой задаче

Интерпретация данных. Это одна из традиционных задач для экспертных систем. Под ин­терпретацией понимается определение смысла данных, результаты которого должны быть согласованными и корректными. Обычно предусматривается многовариантный анализ данных.

Пример 16.5 (все примеры далее из [7, 8,10]):

• обнаружение и идентификация различных типов океанских судов — SIAP;

Рекомендуемые материалы

• определение основных свойств личности по результатам психодиагностического тестирования в системах АВТАНТЕСТ и МИКРОЛЮШЕР и др.

Диагностика. Под диагностикой понимается обнаружение неисправности в некото­рой системе. Неисправность — это отклонение от нормы. Такая трактовка позволяет с еди­ных теоретических позиций рассматривать и неисправность оборудования в технических системах, и заболевания живых организмов, и всевозможные природные аномалии. Важной спецификой является необходимость понимания функциональной структуры ("анатомии") диагностирующей системы.

Пример 16.6:

• диагностика и терапия сужения коронарных сосудов — ANGY;

• диагностика ошибок в аппаратуре и математическом обеспечении ЭВМ — система
CRIB и др.

Мониторинг. Основная задача мониторинга — непрерывная интерпретация данных в реальном масштабе времени и сигнализация о выходе тех или иных параметров за допусти­мые пределы. Главные проблемы — "пропуск" тревожной ситуации и инверсная задача "ложного" срабатывания. Сложность этих проблем в размытости симптомов тревожных си­туаций и необходимость учета временного контекста.

Пример 16.7:

• контроль за работой электростанций СПРИНТ, помощь диспетчерам атомного реактора — REACTOR;

• контроль аварийных датчиков на химическом заводе — FALCON и др.

Проектирование. Проектирование состоит в подготовке спецификаций на создание "объектов" с заранее определенными свойствами. Под спецификацией понимается весь набор необходимых документов — чертеж, пояснительная записка и т.д. Основные пробле­мы здесь — получение четкого структурного описания знаний об объекте и проблема "следа". Дня организации эффективного проектирования и, в еще большей степени, пере­проектирования необходимо формировать не только сами проектные решения, но и мотивы их принятия. Таким образом, в задачах проектирования тесно связываются два основных процесса, выполняемых в рамках соответствующей ЭС: процесс вывода решения и процесс объяснения.

Пример 16.8:

• проектирование конфигураций ЭВМ VAX — 11/780 в системе XCON (или R1), проектирование БИС — CADHELP;

• синтез электрических цепей — SYN и др.

Прогнозирование. Прогнозирующие системы логически выводят вероятные следст­вия из заданных ситуаций. В прогнозирующей системе обычно используется параметричес­кая динамическая модель, в которой значения параметров "подгоняются" под заданную ситуацию. Выводимые из этой модели следствия составляют основу для прогнозов с веро­ятностными оценками.

Пример 16.9:

•   предсказание погоды — система WILLARD;

•   оценки будущего урожая — PLANT;

•   прогнозы в экономике — ECON и др.

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

Пример 16.10:

• планирование поведения робота — STRIPS;

• планирование промышленных заказов — ISIS;

• планирование эксперимента — MOLGEN и др.

Обучение. Системы обучения диагностируют ошибки при изучении какой-либо дис­циплины с помощью ЭВМ и подсказывают правильные решения. Они аккумулируют зна­ния о гипотетическом "ученике" и его характерных ошибках, затем в работе способны диагностировать слабости в знаниях обучаемых и находить соответствующие средства для их ликвидации. Кроме того, они планируют акт общения с учеником в зависимости от успе­хов ученика с целью передачи знаний.

Пример 16.11:

• обучение языку программирования Лисп в системе "Учитель Лиспа";

• система PROUST — обучение языку Паскаль и др.

В общем случае все системы, основанные на знаниях, можно подразделить на систе­мы, решающие задачи анализа, и на системы, решающие задачи синтеза. Основное отли­чие задач анализа от задач синтеза заключается в следующем: если в задачах анализа мно­жество решений может быть перечислено и включено в систему, то в задачах синтеза мно­жество решений потенциально строится из решений компонентов или подпроблем. Задача анализа — это интерпретация данных, диагностика; к задачам синтеза относятся проектиро­вание, планирование. Комбинированные задачи: обучение, мониторинг, прогнозирование.

Классификация по связи с реальным временем

Статические ЭС разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени. Они стабильны.

Пример 16.12. Диагностика неисправностей в автомобиле.

Квазидинамические ЭС интерпретируют ситуацию, которая меняется с неко­торым фиксированным интервалом времени.

Пример 16.13. Микробиологические ЭС, в которых снимаются лабораторные измере­ния с технологического процесса один раз в 4 - 5 ч (производство лизина, например) и анализируется динамика полученных показателей по отношению к предыдущему измерению.

Динамические ЭС работают в сопряжении с датчиками объектов в режиме ре­ального времени с непрерывной интерпретацией поступаемых данных.

Пример 16.14. Управление гибкими производственными комплексами, мониторинг в реанимационных палатах и т.д. Пример инструментария для разработки динамичес­ких систем — G2[5],

Классификация по типу ЭВМ

На сегодняшний день существуют:

• ЭС для уникальных стратегически важных задач на суперЭВМ (Эльбрус, CRAY, CONVEX и др.);

• ЭС на ЭВМ средней производительности (типа ЕС ЭВМ, mainframe);

• ЭС на символьных процессорах и рабочих станциях (SUN, APOLLO);

• ЭС на мини- и супермини-ЭВМ (VAX, micro-VAX и др.);

• ЭС на персональных компьютерах (IBM PC, MAC II и подобные).

Классификация по степени интеграции с другими программами

Автономные ЭС работают непосредственно в режиме консультаций с пользователем для специфически "экспертных" задач, для решения которых не требуется привлекать тра­диционные методы обработки данных (расчеты, моделирование и т.д.).

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

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

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

Традиционные языки программирования

В эту группу инструментальных средств входят традиционные языки программирования (С, C++, Basic, SmallTalk, Fortran и т.д.), ориентированные в основном на численные алгоритмы и слабо подходящие для работы с символьными и логическими данными. Поэтому создание систем искусственного интеллекта на основе этих языков требует большой работы програм­мистов. Однако большим достоинством этих языков является высокая эффективность, свя­занная с их близостью к традиционной машинной архитектуре. Кроме того, использование традиционных языков программирования позволяет включать интеллектуальные подсисте­мы (например, интегрированные экспертные системы) в крупные программные комплексы общего назначения. Среди традиционных языков наиболее удобными считаются объектно-ориентированные (SmallTalk, C++). Это связано с тем, что парадигма объектно-ориентиро­ванного программирования тесно связана с фреймовой моделью представления знаний. Кроме того, традиционные языки программирования используются для создания других классов инструментальных средств искусственного интеллекта.

Языки искусственного интеллекта

Это прежде всего Лисп (LISP) и Пролог (Prolog) — наиболее распространенные языки, предназначенные для решения задач искусственного интеллекта. Есть и менее распростра­ненные языки искусственного интеллекта, например РЕФАЛ, разработанный в России. Универсальность этих языков меньшая, нежели традиционных языков, но ее потерю языки искусственного интеллекта компенсируют богатыми возможностями по работе с символь­ными и логическими данными, что крайне важно для задач искусственного интеллекта. На основе языков искусственного интеллекта создаются специализированные компьютеры (на­пример, Лисп-машины), предназначенные для решения задач искусственного интеллекта. Недостаток этих языков — неприменимость для создания гибридных экспертных систем.

Специальный программный инструментарий

В эту группу программных средств искусственного интеллекта входят специальные инстру­ментарии общего назначения. Как правило, это библиотеки и надстройки над языком искус­ственного интеллекта Лисп: КЕЕ (Knowledge Engineering Environment), FRL (Frame Representation Language), KRL (Knowledge Representation Language), ARTS и др., позволяющие пользователям работать с заготовками экспертных систем на более высоком уровне, нежели это возможно в обычных языках искусственного интеллекта.

"Оболочки"

Под "оболочками" (shells) понимают "пустые" версии существующих экспертных систем, т.е. готовые экспертные системы без базы знаний. Примером такой оболочки может слу­жить EMYCIN (Empty MYCIN — пустой MYCIN), которая представляет собой незапол­ненную экспертную систему MYCIN. Достоинство оболочек в том, что они вообще не требуют работы программистов для создания готовой экспертной системы. Требуется толь­ко специалист(ы) в предметной области для заполнения базы знаний. Однако если некото­рая предметная область плохо укладывается в модель, используемую в некоторой оболочке, заполнить базу знаний в этом случае весьма не просто.

16.3. ТЕХНОЛОГИЯ РАЗРАБОТКИ ЭКСПЕРТНЫХ СИСТЕМ

ЭТАПЫ РАЗРАБОТКИ

Разработка программных комплексов экспертных систем как за рубежом, так и в нашей стране находится на уровне скорее искусства, чем науки. Это связано с тем, что долгое время системы искусственного интеллекта внедрялись в основном во время фазы проекти­рования, а чаще всего разрабатывалось несколько прототипных версий программ, прежде чем был получен конечный продукт. Такой подход действует хорошо в исследовательских условиях, однако в коммерческих условиях он является слишком дорогим, чтобы оправдать коммерчески жизненный продукт.

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

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

В целом за разработку экспертных систем целесообразно браться организации, где на­коплен опыт по автоматизации рутинных процедур обработки информации, например:

• информационный поиск;

• сложные расчеты;

• графика;

• обработка текстов.

Решение таких задач, во-первых, подготавливает высококвалифицированных специа­листов по информатике, необходимых для создания интеллектуальных систем, во-вторых, позволяет отделить от экспертных систем неэкспертные задачи.

ЭТАП 1: ВЫБОР ПОДХОДЯЩЕЙ ПРОБЛЕМЫ

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

•         определение проблемной области и задачи;

Рис. 16.7.   Этапы разработки ЭС

• нахождение эксперта, желающего сотрудничать при решении проблемы, и назначение коллектива разработчиков;

• определение предварительного подхода к решению проблемы;

• анализ расходов и прибыли от разработки;

• подготовку подробного плана разработки.

Правильный выбор проблемы представляет, наверное, самую критическую часть раз­работки в целом. Если выбрать неподходящую проблему, можно очень быстро увязнуть в "болоте" проектирования задач, которые никто не знает, как решать. Неподходящая пробле­ма может также привести к созданию экспертной системы, которая стоит намного больше, чем экономит. Дело будет обстоять еще хуже, если разработать систему, которая работает, но не приемлема для пользователей. Даже если разработка выполняется самой организа­цией для собственных целей, эта фаза является подходящим моментом для получения реко­мендаций извне, чтобы гарантировать удачно выбранный и осуществимый с технической точки зрения первоначальный проект.

При выборе области применения следует учитывать, что если знание, необходимое для решения задач, постоянное, четко формулируемое и связано с вычислительной обработ­кой, то обычные алгоритмические программы, по всей вероятности, будут caмым целесооб­разным способом решения проблем в этой области.

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

Приведем некоторые факты, свидетельствующие о необходимости разработки и внед­рения экспертных систем:

•         нехватка специалистов, расходующих значительное время для оказания помощи другим;

• потребность в многочисленном коллективе специалистов, поскольку ни один из них не обладает достаточным знанием;

• сниженная производительность, поскольку задача требует полного анализа сложного набора условий, а обычный специалист не в состоянии просмотреть (за отведенное время) все эти условия;

• большое расхождение между решениями самых хороших и самых плохих исполните­лей;

•  наличие конкурентов, имеющих преимущество в том, что они лучше справляются с поставленной задачей. Подходящие задачи имеют следующие характеристики:

• являются узкоспециализированными;

• не зависят в значительной степени от общечеловеческих знаний или соображений здравого смысла;

• не являются для эксперта ни слишком легкими, ни слишком сложными (время, необ­ходимое эксперту для решения проблемы, может составлять от трех часов до трех не­дель);

• условия исполнения задачи определяются самим пользователем системы;

• имеет результаты, которые можно оценить.

Обычно экспертные системы разрабатываются путем получения специфических зна­ний от эксперта и ввода их в систему. Некоторые системы могут содержать стратегии одно­го индивида. Следовательно, найти подходящего эксперта — это ключевой шаг в создании экспертных систем.

В процессе разработки и последующего расширения системы инженер по знаниям и эксперт обычно работают вместе. Инженер по знаниям помогает эксперту структурировать знания, определять и формализовать понятия и правила, необходимые для решения пробле­мы.

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

Предварительный подход к программной реализации задачи определяется исходя из характеристик задачи и ресурсов, выделенных на ее решение. Инженер по знаниям выдви­гает обычно несколько вариантов, связанных с использованием имеющихся на рынке про­граммных средств. Окончательный выбор возможен лишь на этапе разработки прототипа.

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

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

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

После того как инженер по знаниям убедился, что:

• данная задача может быть решена с помощью экспертной системы;

• экспертную систему можно создать предлагаемыми на рынке средствами;

• имеется подходящий эксперт;

• предложенные критерии производительности являются разумными;

• затраты и срок их возвращаемое™ приемлемы для заказчика,

он составляет план разработки. План определяет шаги процесса разработки и необходимые затраты, а также ожидаемые результаты.

ЭТАП 2: РАЗРАБОТКА ПРОТОТИПНОЙ СИСТЕМЫ

Понятие прототипной системы

Прототипная система является усеченной версией экспертной системы, спроектирован­ной для проверки правильности кодирования фактов, связей и стратегий рассуждения экс­перта. Она также дает возможность инженеру по знаниям привлечь эксперта к активному участию в разработке экспертной системы и, следовательно, к принятию им обязательства приложить все усилия для создания системы в полном объеме.

Объем прототипа — несколько десятков правил, фреймов или примеров. На рис. 16.8 изображены шесть стадий разработки прототипа и минимальный коллектив разработчиков, занятых на каждой из стадий. Приведем краткую харак­теристику каждой из стадий, хотя эта схема представляет грубое приближение к сложному итеративному процессу.

Хотя любое теоретическое разделение бывает часто условным, осознание коллективом разработчиков четких задач каждой стадии представляется целесообразным. Роли разработ-

чиков (эксперт, программист, пользователь и аналитик) являются постоянными на протяже­нии всей разработки. Совмещение ролей нежелательно.

Сроки приведены условно, так как зависят от квалификации специалистов и особен­ностей задачи.

Идентификация проблемы

Уточняется задача, планируется ход разработки прототипа экспертной системы, определя­ются:

необходимые ресурсы (время, люди, ЭВМ и т.д.);

источники знаний (книги, дополнительные эксперты, методики);

имеющиеся аналогичные экспертные системы;

цели (распространение опыта, автоматизация рутинных действий и др.);

классы решаемых задач и т.д.

Идентификация проблемы — знакомство и обучение коллектива разра­ботчиков, а также создание неформальной формулировки проблемы.

Средняя продолжительность 1 - 2 недели.

Извлечение знаний

Происходит перенос компетентности экспертов на инженеров по знаниям с использованием различных методов:

анализ текстов;

диалоги;

экспертные игры;

лекции;

дискуссии;

интервью;

наблюдение и другие.

Извлечение знаний — получение инженером по знаниям наиболее полно­го представления о предметной области и способах принятия решения в ней.

Средняя продолжительность 1 - 3 месяца.

Структурирование или концептуализация знаний

Выявляется структура полученных знаний о предметной области, т.е. определяются: терминология;

список основных понятий и их атрибутов; отношения между понятиями; структура входной и выходной информации; стратегия принятия решений; ограничения стратегий и т.д.

Концептуализация знаний — разработка неформального описания знаний о предметной области в виде графа, таблицы, диаграммы или текста, кото­рое отражает основные концепции и взаимосвязи между понятиями пред­метной области.

Такое описание называется полем знаний. Средняя продолжительность этапа 2 - 4 не­дели.

Формализация

Строится формализованное представление концепций предметной области на основе вы­бранного языка представления знаний (ЯПЗ). Традиционно на этом этапе используются:

логические методы (исчисления предикатов I порядка и др.);

продукционные модели (с прямым и обратным выводом);

семантические сети;

фреймы;

объектно-ориентированные языки, основанные на иерархии классов, объектов и др.

Формализация знаний — разработка базы знаний на языке, который, с одной стороны, соответствует структуре поля знаний, а с другой — позво­ляет реализовать прототип системы на следующей стадии программной ре­ализации.

Все чаще на этой стадии используется симбиоз языков представления знаний, напри­мер, в системе ОМЕГА — фреймы + семантические сети + полный набор возможностей языка исчисления предикатов. Средняя продолжительность 1 - 2 месяца.

Реализация

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

• программирование на традиционных языках типа Паскаль, Си и др.;

• программирование на специализированных языках, применяемых в задачах искусст­венного интеллекта: LISP, FRL, SmallTalk и др.;

• использование инструментальных средств разработки ЭС типа СПЭИС, ПИЭС;

• использование "пустых" ЭС или "оболочек" типа ЭКСПЕРТ, ФИАКР  и др.

Реализация — разработка программного комплекса, демонстрирующего жизнеспособность подхода в целом. Чаще всего первый прототип отбрасы­вается на этапе реализации действующей ЭС.

Средняя продолжительность 1 - 2 месяца.

Тестирование

Оценивается и проверяется работа программ прототипа с целью приведения в соответствие с реальными запросами пользователей. Прототип проверяется на:

•          удобство и адекватность интерфейсов ввода-вывода (характер вопросов в диалоге, связность выводимого текста результата и др.);

• эффективность стратегии управления (порядок перебора, использование нечеткого вы­вода и др.);

• качество проверочных примеров;

• корректность базы знаний (полнота и непротиворечивость правил).

Тестирование — выявление ошибок в подходе и реализации прототипа и выработка рекомендаций по доводке системы до промышленного варианта.

Средняя продолжительность 1 - 2 недели.

ЭТАП 3: РАЗВИТИЕ ПРОТОТИПА ДО ПРОМЫШЛЕННОЙ ЭС

При неудовлетворительном функционировании прототипа эксперт и инженер по знаниям имеют возможность оценить, что именно будет включено в разработку окончательного ва­рианта системы.

Если первоначально выбранные объекты или свойства оказываются неподходящими, их необходимо изменить. Можно сделать оценку общего числа эвристических правил, необ­ходимых для создания окончательного варианта экспертной системы. Иногда при раз­работке промышленной системы выделяют дополнительные этапы для перехода: демонстрационный прототип — исследовательский прототип — действующий прото­тип — промышленная система.

Однако чаще реализуется плавный переход от демонстрационного прототипа к про­мышленной системе, при этом, если программный инструментарий выбран удачно, необя­зательна перепись другими программными средствами.

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

Таблица 16.1. Переход от прототипа к промышленной экспертной системе

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

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

На этом этапе разработки большинство экспертов узнают достаточно о вводе правил и могут сами вводить в систему новые правила. Таким образом начинается процесс, во время которого инженер по знаниям передает право собственности и контроля за системой экс­перту для уточнения, детальной разработки и обслуживания.

ЭТАП 4: ОЦЕНКА СИСТЕМЫ

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

• критерии пользователей (понятность и "прозрачность" работы системы, удобство интерфейсов и др.);

• критерии приглашенных экспертов (оценка советов-решений, предлагаемых системой, сравнение ее с собственными решениями, оценка подсистемы объяснений и др.);

• критерии коллектива разработчиков (эффективность реализации, производительность, время отклика, дизайн, широта охвата предметной области, непротиворечивость БЗ, количество тупиковых ситуаций, когда система не может принять решение, анализ чувствительности программы к незначительным изменениям в представлении знаний, весовых коэффициентах, применяемых в механизмах логического вывода, данных и т.п.).

ЭТАП 5: СТЫКОВКА СИСТЕМЫ

На этом этапе осуществляется стыковка экспертной системы с другими программными средствами в среде, в которой она будет работать, и обучение людей, которых она будет об­служивать. Иногда это означает внесение существенных изменений. Такое изменение тре­бует непременного вмешательства инженера по знаниям или какого-либо другого специалиста, который сможет модифицировать систему. Под стыковкой подразумевается также разработка связей между экспертной системой и средой, в которой она действует.

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

Дня подтверждения полезности системы важно предоставить каждому из пользовате­лей возможность поставить перед ЭС реальные задачи, а затем проследить, как она выпол­няет эти задачи. Чтобы система была одобрена, необходимо представить ее как помощника, освобождающего пользователей от обременительных задач, а не как средство их заме­щения.

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

Пример 16.15. Успешно состыкована со своим окружением система PUFF — эксперт­ная система для диагностики заболеваний легких. После того, как PUFF была за­кончена и все были удовлетворены ее работой, систему перекодировали с LISPa на Бейсик. Затем систему перенесли на ПК, которая уже работала в больнице. В свою очередь, эта ПК была связана с измерительными приборами. Данные с измерительных приборов сразу поступают в ПК. PUFF обрабатывает эти данные и печатает рекомен­дации для врача. Врач в принципе не взаимодействует с PUFF. Система полностью интегрирована со своим окружением — она представляет собой интеллектуальное расширение аппарата исследования легких, который врачи давно используют.

Пример 16.16. Другая система, которая хорошо функционирует в своем окруже­нии, — САТ-1 — экспертная система для диагностики неисправностей дизелей ло­комотивов.

Эта система была разработана также на LISPe, а затем переведена на FORTH, чтобы ее можно было более эффективно использовать в различных локомотивных цехах. Мастер по ремонту запрашивает систему: определить возможные причины неисправ­ности дизеля. Система связана с видеодиском, с помощью которого мастеру дают ви­зуальные объяснения и подсказки относительно более подробных проверок, которые ему нужно сделать.

Кроме того, если оператор не уверен в том, как устранить неисправность, система предоставляет ему обучающие материалы, которые фирма подготовила предваритель­но, и показывает ему на видеотерминале. Таким образом, мастер по ремонту может с помощью экспертной системы диагностировать проблему, найти тестовую процеду­ру, которую он должен использовать, получить на дисплее объяснение, как провести тест, или получит инструкции о том, как справиться с возникшей проблемой.

ЭТАП 6: ПОДДЕРЖКА СИСТЕМЫ

При перекодировании системы на язык, подобный Си, повышается ее быстродействие и увеличивается переносимость, однако гибкость при этом уменьшается. Это приемлемо лишь в том случае, если система сохраняет все знания проблемной области и это знание не будет изменяться в ближайшем будущем. Однако, если экспертная система создана именно из-за того, что проблемная область изменяется, то необходимо поддерживать систему в ин­струментальной среде разработки.

Пример 16.17. Удачным примером ЭС, внедренной таким образом, является XCON (R1) — ЭС, которую фирма DEC использует для комплектации ЭВМ семейства VAX. Одна из ключевых проблем, с которой столкнулась фирма DEC, — необходимость постоянного внесения изменений для новых версий оборудования, новых специфика­ций и т.д. Для этой цели XCON поддерживается в программной среде OPS5.

КЛЮЧЕВЫЕ ПОНЯТИЯ

Анализ:

морфологический

прагматический

семантический

синтаксический

База знаний

Данные

Знания:

глубинные

декларативные

поверхностные

процедурные

Инженер по знаниям

Интеллектуальный редактор БЗ

Интерфейс пользователя

Кибернетика "черного ящика"

Лабиринтный поиск

Нейрокибернетика

Нейрокомпьютер

Нейронные сети (нейросети)

Перцептрон

Подсистема объяснений

Поле знаний

Представление знаний

Продукционная модель

Пролог

Рефал                                                                                                 Экспертная система:

Решатель                                                                                                              диагностика

Семантическая сеть                                                                                             интерпретация данных

Ситуационное управление                                                                             мониторинг

Транспьютер                                                                                                         обучение

Фрейм:                                                                                                                 планирование

         образец                                                                                                           прогнозирование

         роль                                                                                                                 проектирование
         ситуация                                                                               ЭС по классификации:

         структура                                                                                                      автономные

         сценарий                                                                                                        гибридные

         экземпляр                                                                                                       динамические

Эвристика                                                                                                               квазидинамические

Эвристическое программирование                                                             статические

ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ

1. Перечислите основные направления искусственного интеллекта.

2. Что такое нейросеть?

3. Где применяются нейрокомпьютеры?

4. Что такое "эвристика"?

5. Что такое "ситуационное управление"?

6. Из каких этапов состоит анализ текста при переводе?

7. Перечислите три поколения роботов.

8. Перечислите уровни обработки данных.

9. Перечислите уровни обработки знаний.

10. Что является основой любой интеллектуальной системы?

11. Чем отличаются глубинные знания от поверхностных?

12. В чем выражаются процедурные знания?

13. Что такое продукционная модель?

14. Какова цель обратного вывода?

15. Из чего состоит семантическая сеть?

16. Какие бывают фреймы?

17. Что такое АКО-связь?

18. Что такое наследование свойств?

19. Что входит в состав экспертной системы?

20. Кто такой инженер по знаниям?

21. Перечислите классификацию экспертных систем по типу решаемых задач.

22. Что такое интегрированная экспертная система?

В лекции "Восприятие в зависимости от частоты" также много полезной информации.

23. Что такое "стыковка экспертной системы"?

24. Что происходит при извлечении знаний?

25. Кто участвует в структурировании знаний?

26. Какие языки используются при формализации?

27. Чем отличается исследовательский прототип от действующего?

28. Как связаны универсальность программного средства и количество работы по созда­нию готовой экспертной системы?