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

Ниже приведен программный код на языке 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 в конце главы).

 

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

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

 

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

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

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

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

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

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

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

• Как подобрать подходящий инструментарий для проектирования экспертной системы?

• Насколько в действительности такие средства просты в обращении?

• Что такое "хороший стиль программирования" в выбранной среде разработки?

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