То: экзамен по информатике будет провален

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

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

Рис. 17.1. Пример множества контекстов

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

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

Логический вывод в разных контекстах

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

;; ШАБЛОНЫ

;; Fact представляет собой субъект с определенными

;; свойствами.

;; Поле "world" несет информацию о контексте,

(deftemplate fact

(field subj (type SYMBOL))

(field attr (type SYMBOL))

(field world (type INTEGER))

)

;; Act представляет действие с объектом.

;; Поле "world" несет информацию о контексте.

(deftemplate act

(field action (type SYMBOL))

(field object (type SYMBOL))

(field world (type INTEGER))

)

;; Context имеет статус либо OK,

;; либо NG (no good - плохой).

(def template context

(field id (type INTEGER))

(field status (type SYMBOL))

)

;; Модель мира в исходном состоянии.

(def facts model

(context (id 1) (status OK))

(fact (subj weather) (attr sunny) (world 1))

)

;; ПРАВИЛА

;; Если дождя нет,

;; создать новый контекст, в котором можно

;; пропустить занятия.

(def rule skip

(fact (subj weather) (attr?W&~rainy) (world?C)) =>

(assert (act (action skip) (object class)

(world (+?C 1)))) (assert (context

((id (+?C 1)) (status OK)))

)

;; Если пропустить занятия,

;; то на экзамене вас ждет провал.

(defrule fail

(act (action skip) (object class) (world?W)) =>

(assert (act (action fail) (object exam) (world (?W)))

)

;; Если контекст содержит действие fail,

;; пометить его маркером NG. (defrule poison

(act (action fail) (world?W)).

?C <- (context (id?W) (status OK)) =>

(modify?C (status NG))

)

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

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

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

Характерные сложности и способы их избежать

В своей книге Уотерман перечисляет следующие "ловушки", поджидающие разработчика экспертной системы на этапе внедрения, и дает рекомендации, как их избежать [Waterman, 1986, Chapter 19].

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

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

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

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