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

Ниже приведен программный код на языке 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, это не что иное, как стремление найти компромисс между более мощными правилами и правилами, более понятными.