Масленникова О.Е., Попова И.В. Основы искусственного интеллекта

Подождите немного. Документ загружается.

- 111 -

ввести в явном виде, присвоит ему специальное имя и, используя это

понятие, сформулировать одно правило взамен группы подобных.

Выполнение экспериментов с расширенной версией ЭС-1, анализ

пожеланий и замечаний служат отправной точкой для создания второго

прототипа (ЭС-2). Процесс разработки ЭС-2 итеративный, может

продолжаться от нескольких месяцев до нескольких лет в зависимости от

сложности предметной области, гибкости выбранного представления и

степени соответствия управляющего механизма решаемым задачам. При

разработке ЭС-2, кроме перечисленных задач, решаются следующие:

− анализ функционирования системы при значительном расширении

БЗ;

− исследование возможностей системы в решении более широкого

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

− анализ мнения пользователей о недостатках системы, о том, какую

дополнительную помощь он хочет получить от ЭС, и т.п.;

− разработка системы ввода- вывода, осуществляющей анализ или

синтез предложений ограниченного естественного языка, что

позволяет пользователю взаимодействовать с ЭС-2 в форме, близкой

к форме стандартных учебников для данной области.

Если ЭС-2 успешно прошла этап тестирования, то она может

классифицироваться как промышленная система.

Этап тестирования

В ходе этого этапа осуществляется оценка выбранного способа

представления знаний и ЭС в целом. Как только ЭС оказывается в состоянии

обработать от начала до конца два или три примера, необходимо начинать

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

БЗ и управляющего механизма (процедур вывода). Инженер по знаниям

должен подобрать примеры, обеспечивающие всестороннюю проверку ЭС.

Обычно выделяют следующие источники неудач в работе системы:

− тестовые примеры (недостаточно показательные, вне проблемной

области, на которую рассчитана ЭС, однородны);

− ввод-вывод (методы приобретения данных не дали нужных

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

не соответствуют знаниям пользователя; неудобный для пользователя

входной язык; выходные сообщения (заключения) системы

непонятны пользователю (эксперту)и др.);

− правила вывода (ошибочность, противоречивость и неполнота правил;

неучет зависимостей между правилами; порождение гипотез

(промежуточных заключений), которые правдоподобны по

отдельности, но комбинируются в бессмысленные

последовательности и др.);

− управляющие стратегии (чрезмерно сложные заключения и

объяснения ЭС).

- 112 -

Критерии, с помощью которых оценивается ЭС, зависят от того, с чьей

точки зрения дается оценка. Например, при тестировании ЭС-1 оценка

осуществляется с точки зрения эксперта, для которого важна в первую

очередь полнота и безошибочность правил вывода. При тестировании

промышленной системы оценка производится в основном с точки зрения

инженера по знаниям, которого интересует эффективность работы ЭС. При

тестировании ЭС после опытной эксплуатации оценка осуществляется с

точки зрения пользователя заинтересованного в первую очередь в удобстве

работы и получении практической пользы.

На этапе тестирования созданные экспертные системы оцениваются с

позиции двух основных групп критериев: точности и полезности.

С точностью работы связаны такие характеристики, как правильность

делаемых заключений, адекватность базы знаний проблемной области,

соответствие применяемых методов решения проблемы экспертным.

Полезность же экспертной системы характеризуется степенью

удовлетворения требований пользователя в части получения необходимых

рекомендаций, легкости и естественности взаимодействия с системой,

надежности, производительности и стоимости эксплуатации, способности

обоснования решений и обучения, настройки на изменение потребностей.

Оценивание экспертной системы осуществляется по набору тестовых

примеров как из предшествующей практики экспертов, так и специально

подобранных ситуаций.

Этап опытной эксплуатации

На данном этапе проверяется пригодность системы для конечного

пользователя. Здесь ЭС занимается решением всех возможных задач при

работе с различными пользователями. Целесообразно организовать работу

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

этапу следует переходить лишь после того, как система, по мнению эксперта,

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

решениях не создавали у пользователя отрицательного представления о ЭС.

Пригодность ЭС для пользователя определяется в основном удобством

работы с ней и ее полезностью. Под полезностью ЭС понимается

способность ее в ходе диалога определять потребности пользователя,

выявлять и устранять причины неудач в работе, а также удовлетворять

потребности пользователя (т.е. решать поставленные задачи). Другими

словами, пользователю важно довести «до сознания» ЭС свою

информационную потребность, несмотря на возможные ошибки,

допускаемые им из-за недостаточного знания ЭС. Конечно, для пользователя

важны также полнота и правильность решений, но эти характеристики

должны быть проверены экспертом на предыдущей стадии.

Под удобством работы понимается естественность взаимодействия с

экспертной системой, гибкость настройки и устойчивость к ошибкам

пользователя.

- 113 -

По результатам эксплуатации может потребоваться не только

модификация программ и данных, но и замена устройств ввода-вывода из-за

их неприемлемости для пользователя. По результатам этого же этапа

принимается решение о переносе системы на другие ЭВМ (например, для

расширения сферы использования ЭС и\или снижения ее стоимости).

После успешного завершения этапа опытной эксплуатации и

использования различными пользователями ЭС может классифицироваться

как коммерческая.

Опытная эксплуатация осуществляется в массовом порядке без

непосредственного контроля со стороны разработчиков и переход от

тестовых примеров к решению реальных задач. Важнейшим критерием

оценки становятся соотношение стоимости системы и еѐ эффективности. На

этом этапе осуществляется сбор критических замечаний и внесение

необходимых изменений. В результате опытной эксплуатации может

потребоваться разработка новых специализированных версий, учитывающих

особенности проблемных областей.

Модификация системы

В ходе создания ЭС почти постоянно осуществляется ее модификация.

Можно выделить следующие виды модификации системы:

− переформулирование понятий и требований (возврат на этапы

концептуализации и идентификации);

− переконструирование представления (возврат от этапа тестирования

на этап формализации приводит к пересмотру выбранного ранее

способа представления знаний);

− усовершенствование прототипа (осуществляется в процессе

циклического прохождения через этапы выполнения и тестирования

для отладки правил и процедур вывода; повторяется до тех пор, пока

система не будет себя вести ожидаемым образом; зависит от

выбранного способа представления и класса задач, решаемых ЭС; в

случае несостоятельности вносимых изменений может потребоваться

модификация архитектуры системы и БЗ).

3.5. Инструментальные средства экспертной системы

Классификация инструментальных средств экспертной системы

По своему назначению и функциональным возможностям

инструментальные программы, применяемые при проектировании ЭС,

можно разделить на представленные ниже категории.

Традиционные языки программирования. В эту группу

инструментальных средств входят традиционные языки программирования

(С, C++, Basic, SmallTalk, Fortran и т.д.), ориентированные в основном на

численные алгоритмы и слабо подходящие для работы с символьными и

логическими данными. Поэтому создание систем искусственного интеллекта

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

- 114 -

большим достоинством этих языков является высокая эффективность,

связанная с их близостью к традиционной машинной архитектуре. Кроме

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

включать интеллектуальные подсистемы (например, интегрированные

экспертные системы) в крупные программные комплексы общего

назначения. Среди традиционных языков наиболее удобными считаются

объектно-ориентированные (SmallTalk, C++). Это связано с тем, что

парадигма объектно-ориентированного программирования тесно связана с

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

программирования используются для создания других классов

инструментальных средств искусственного интеллекта.

Языки искусственного интеллекта. Это прежде всего Лисп (LISP) и

Пролог (Prolog) – наиболее распространенные языки, предназначенные для

решения задач искусственного интеллекта. Есть и менее распространенные

языки искусственного интеллекта, например РЕФАЛ, разработанный в

России. Универсальность этих языков меньшая, нежели традиционных

языков, но еѐ потерю языки искусственного интеллекта компенсируют

богатыми возможностями по работе с символьными и логическими данными,

что крайне важно для задач искусственного интеллекта. На основе языков

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

(например, Лисп-машины), предназначенные для решения задач

искусственного интеллекта. Недостаток этих языков – неприменимость для

создания гибридных экспертных систем.

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

программных средств искусственного интеллекта входят специальные

инструментарии общего назначения. Как правило, это библиотеки и

надстройки над языком искусственного интеллекта Лисп: КЕЕ (Knowledge

Engineering Environment), FRL (Frame Representation Language), KRL

(Knowledge Represantation Language), ARTS и др., позволяющие

пользователям работать с заготовками экспертных систем на более высоком

уровне, нежели это возможно в обычных языках искусственного интеллекта.

Оболочки экспертных систем (expert system shells). Системы этого

типа создаются, как правило, на основе какой-нибудь экспертной системы,

достаточно хорошо зарекомендовавшей себя на практике. При создании

оболочки из системы-прототипа удаляются компоненты, слишком

специфичные для области ее непосредственного применения, и оставляются

те, которые не имеют узкой специализации. Примером может служить

система EMYCIN, созданная на основе прошедшей длительную «обкатку»

системы MYCIN. В EMYCIN сохранен интерпретатор и все базовые

структуры данных – таблицы знаний и связанный с ними механизм

индексации. Оболочка дополнена специальным языком, улучшающим

читабельность программ, и средствами поддержки библиотеки типовых

случаев и заключений, выполненных по ним экспертной системой.

Дальнейшим развитием оболочки EMYCIN явились системы S.1 и М.4, в

- 115 -

которых механизм построения цепочки обратных рассуждений,

заимствованный в EMYCIN, объединен с фреймоподобной структурой

данных и дополнительными средствами управления ходом рассуждений.

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

непрограммистам воспользоваться результатами работы программистов,

решавших аналогичные проблемы. Так, например, на базе EMYCIN были

разработаны экспертные системы как для медицины (например, система

PUFF для диагностики легочных заболеваний), так и для других областей

знаний, например программа структурного анализа SACON.

Совершенно очевидно, что оболочки являются программами,

ориентированными на достаточно узкий класс задач, хотя и более широкий,

чем та программа, на основе которой была создана та или иная оболочка.

К сожалению, нельзя слишком доверять рекомендациям о возможности

использования оболочки для решения конкретных проблем. Дело в том, что

еще не сформировано настолько четкое представление о классификации

задач, решаемых экспертными системами, чтобы можно было точно

представить, к какому именно классу следует отнести конкретную систему.

В качестве отдельного задания в рамках самостоятельной работы

студентам рекомендуется провести сравнительный анализ нескольких

инструментальных оболочек. В рамках данного пособия будет подробно

рассмотрена работа с XpertRule.

Выбор инструментального средства экспертной системы

Среди специализированных инструментальных средств ЭС основной

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

позволяющие динамически управлять непрерывными процессами (70 %

рынка). Бесспорным лидером в разработке экспертных систем реального

времени является фирма Gensym с инструментальным средством G2

(дистрибьютор в России - фирма ArgusSoft), имеющая внедрения в таких

компаниях как IBM, NASA, General Electric, Nissan и др. На базе G2, в свою

очередь, созданы такие проблемно-ориентированные комплексы, как GDA

для решения задач диагностики, ReThink для моделирования бизнес-

процессов (бизнес-реинжиниринга), NeurOnline для поддержки нейронной

сети, IPS для решения задач динамического планирования, FaultExpert для

управления телекоммуникациями и др.

В процессе жизненного цикла разработки экспертной системы

инструментальные средства могут сменять друг друга по мере расширения

базы знаний. Так, на этапе проектирования прототипа требуется его быстрая

разработка в ущерб производительности, в то время как на этапе разработки

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

функционирования.

На выбор инструментальных средств экспертной системы, в основе

которых лежит определенный метод представления знаний, основное

влияние оказывает класс решаемых задач (проблемных областей) и

- 116 -

соответственно характер полученной концептуальной модели,

определяющий множество требований в части отображения объектов,

действий над объектами, методов обработки неопределенностей, механизмов

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

последовательности).

Таблица 11

Требования проблемной области к формализмам знаний

Описание метода

представления

знаний

Классы решаемых задач

Интер-

прета-

ция

Диаг-

ностика

Прогнози-

рование

Проекти-

рование

Планиро-

вание

Описание объектов

Предикаты

4 2

Правила

1 1

Семант. сеть

Фреймы

(Объекты)

Действия:

Предикаты

3 2

Правила

1 1

Сообщения

2 3

Процедуры

4 4

Неопределенность

Неполнота

2 4

Нечеткость

3 2

Многозначность

Недостоверность

Вывод

Прямая цепочка

Обратн. цепочка

Объект.ориент.

Гипотет. вывод

Обраб. времени

Доска объявлений

Инструментальные средства, в свою очередь, характеризуются

определенными возможностями по реализации этих требований. В табл. 12

представлено выполнение требований для наиболее популярных

- 117 -

инструментальных средств (цифрой показывается номер места в

упорядоченной последовательности).

Таблица 12

Возможности инструментальных средств ЭС

Описание метода

представления

знаний

Программные инструментальные средства

ЭКО

ArgusSoft

GURU

MDBS

Nexpert

Object

Neuron

Data

LEVEL-5

Level Co

ART

Enterprise

Inference

Gensym

Описание объектов

Предикаты

Правила

* *

Семант. сеть

Фреймы

(Объекты)

* *

Действия:

Предикаты

* *

Правила

Сообщения

Процедуры

* *

Неопределенность

Неполнота

* *

Нечеткость

Многозначность

Недостоверность

Выводы

Прямая цепочка

* *

Обратная цепочка

* *

Объектно-

ориентированный

* *

Гипотетическийв

вывод

Обработка

времени

Доска объявлений

Сущность алгоритма выбора инструментальных средств сводится к

наложению требований проблемной области к формализмам знаний на

возможности инструментальных средств и определению наилучших по

заданным ограничениям (табл. 13).

- 118 -

Таблица 13

Алгоритм выбора инструментальных средств ЭС

Классы

решаемых задач

Программные инструментальные средства

ЭКО

ArgusSoft

GURU

MDBS

Nexpert

Object

Neuron Data

LEVEL-5

Level Co

ART

Enterprise

Inference

Gensym

Интерпретация

Диагностика

Прогнозирование

Проектирование

Планирование

В своих аналитических заметках Робинсон обращает внимание на то,

что выбор инструментальной среды разработки экспертной системы

представляет собой достаточно сложную задачу по следующим причинам:

− большинство развитых сред разработки настолько дороги, что

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

подходящего не по средствам разработчикам;

− время, необходимое для освоения навыков работы с системой и

выявления ее сильных и слабых сторон, также слишком велико, а потому

редко кто может себе позволить проводить сравнение конкурирующих

моделей на практике;

− терминология, которую применяют в документации изготовители

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

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

интеллекта. Поэтому проводить сопоставление разных моделей по тем

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

достаточно трудно.

Последнее замечание справедливо в отношении большинства

программных продуктов, предлагающихся на рынке. Когда же речь идет о

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

то новизна и необычность терминологии еще более усугубляет проблему.

Уже давно в среде специалистов бытует мнение, что сравнение

конкурирующих систем одного класса можно выполнять только после

тщательного изучения их на практике.

В своей книге Уотерман перечисляет следующие «ловушки»,

поджидающие разработчика экспертной системы на этапе внедрения, и дает

рекомендации, как их избежать.

Знания, касающиеся предметной области, слишком тесно переплетены

с остальной частью программы. В частности, невозможно разделить эти

- 119 -

знания и знания общего применения, касающиеся способов поиска в

пространстве решений. Уотерман предполагает, что этого можно достичь,

положив в основу организации базы знаний набор правил, хотя из замечаний,

сделанных Кленси и Эйкинс, следует, что такая организация отнюдь не

гарантирует достижение ожидаемого результата.

Та база знаний, которая сформировалась после извлечения и

представления сотен правил в процессе опроса экспертов, может оказаться

все-таки настолько неполной, что не позволит решить и простую задачу,

поскольку в ней отсутствуют фундаментальные концепты предметной

области или эти концепты представлены с ошибками. Уотерман рекомендует

последовательно наращивать объем базы знаний, причем начинать с

фундаментальных понятий. Это позволит еще на ранних стадиях разработки

обнаружить указанную проблему. Он советует выполнять тестирование на

каждом этапе разработки, используя для этого подходящие

инструментальные средства инженерии знаний.

Среда разработки не располагает встроенными средствами

формирования функций пояснения экспертной системы, а добавление таких

функций в уже спроектированную систему – задача не из легких. Уотерман

советует позаботиться о прозрачности экспертной системы с первых же

шагов ее разработки. Это очень ценный совет, поскольку без хорошего

«окна», через которое можно заглянуть в «машинный зал» программы, даже

ее создатель не сможет понять, что же она на самом деле делает.

Система содержит чрезмерно большое количество слишком

специфических правил. Это, во-первых, приводит к замедлению работы

системы, а во-вторых, затрудняет управление ею. Уотерман рекомендует

объединять, где только возможно, мелкие правила в более общие. Тое есть

найти компромисс между более мощными правилами и правилами, более

понятными.

Оболочка XpertRule: назначение, основные понятия, компоненты

XpertRule является инструментальным средством для графической

разработки и запуска приложений, основанных на знаниях. Такие

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

задач (показанные в окне Map View).

Задача может состоять из дерева решений или множества правил

продукции, представляющих знания (принятие решений, совет, диагностика,

выбор, правила и положения и т.д.). Сложное знание может быть

структурировано в иерархически упорядоченные цепочки задач.

Приложение, выполненное средствами XpertRule, работает под

Windows. Запустить его можно, воспользовавшись модулем XpertRun,

входящим в пакет программы.

Компоненты XpertRule: основные окна, словарь

1. Диалоговое окно создания приложения (рис.46)

Команда меню File/New.

- 120 -

Поля:

− Name – имя приложения (латинскими буквами);

− Description - поле для комментариев;

− Task Type – тип вывода (возможные значения: логические,

числовые, булевы, дата, список);

− Inference Mode – выбор метода построения задачи.

2. Посредством пункта меню Views осуществляется доступ к окнам

работы с основными объектами XpertRule.

Диаграмма на рисунке 47 показывает, каким образом структурированы

окна Views.

Рис. 47. Структура окон XpertRule

Карта задач (Map of Tasks) и словарь (Dictionary) – глобальные

представления, атрибуты, примеры, дерево исключений, дерево решений,

правила продукции – представления более низкого уровня.

Рис. 46. Окно создания нового приложения