Перспективы дальнейших исследований методов формирования пояснений

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

Проект EES служит хорошим примером одного из направлений в современной методологии инженерии знаний, которое предполагает разделение процесса на этапы спецификации знаний и компиляции системы. Но пока что совершенно неясно, как такая методология может справиться с задачей комбинирования разных стратегий решения проблем в рамках единой системы (как это выполняется, например, в системе CENTAUR). Основная сложность в использовании этой методологии — большой объем предыстории разработки и необходимость использования чрезвычайно мощного генератора программ (см. об этом в [Neches et al, 1985]). Альтернативой такому подходу является усложнение интерпретатора включением в него мощных управляющих примитивов. В результате предыстория разработки сокращается и снижаются требования к функциональным возможностям генератора программ, но информация о принятии решений, касающихся поведения программы, оказывается спрятанной в программном коде интерпретатора. Интересно звучит предложение дополнительно нагрузить генератор программ — заставить его формировать и интерпретатор, и информацию, необходимую для формирования пояснений относительно управляющих функций. Это должно привести к еще большему разделению управляющих знаний и знаний о предметной абласти, но, предположительно, одновременно поставит перед разработчиками множество проблем, связанных с интеграцией компонентов системы.

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

(1) дифференциация знаний;

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

(3) моделирование индивидуального уровня подготовки пользователя, работающего с экспертной системой.

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

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

Читателей, интересующихся историей разработки модели пользователя, мы отсылаем к сборникам [Sleeman and Brown, 1982] и [Poeson and Richardson, 1988]. Довольно обширная подборка статей, касающихся проблематики интерфейса с пользователем; представлена в сборнике [Maybury, 1993]. В работах [Moore and Paris, 1993] и [Moore et al, 1996] суммируется опыт планирования диалога, приобретенный авторами в процессе разработки оболочки EES и экспертной системы PEA.

Читателям, интересующимся дескриптивными языками описания семантических сетей, мы советуем обратить внимание на язык LOOM, представленный в работе [MacGregor, 1991]

Упражнения

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

Почему формирование пояснений в системах, основанных на порождающих правилах, упрощается, если разделить используемые правила на группы по назначению?

Какую помощь в формировании пояснений может оказать использование фреймов? С какой целью фреймы комбинируются с порождающими правилами?

4. Ниже представлена новая версия программы Assault-weapon (оружие нападения), которая была рассмотрена в главе 11. В этой версии программа задает пользователю вопросы об определенном виде оружия, а затем формирует пояснение, почему данный тип оружия относится (или не относится) к классу "оружие нападения" в соответствии с имеющимися в программе правилами. Программа состоит из двух частей: в первой уточняются характеристики модели оружия, а во второй формируется пояснение.

I) Разработайте правила, которые не представлены в приведенном ниже тексте программы. Указания, какие именно правила требуется разработать, выделены в комментариях в тексте программы.

;; Объявления (deftemplate gun

(field name (type SYMBOL))

(field model (type SYMBOL))

(field class (type SYMBOL) (default NIL))

(field action (type SYMBOL) (default NIL))

(field caliber (type FLOAT) (default 0.0))

(field capacity (type INTEGER) (default 0))

(field features (type SYMBOL) (default NIL))

)

(deftemplate assault-weapon

(field make (type SYMBOL))

(field model (type SYMBOL))

)

;; ПРАВИЛА

;; Общий случай

;; Любая полуавтоматическая

;; винтовка (semi-automatic rifle)

;; или охотничье ружье (shotgun) с емкостью

;; магазина более 5 патронов.

(defrule Parti

(gun (make?M) (model?N)

(class?CSrifle|shotgun) (action semi) (capacity?X&:(>?X 5))) =>

(assert (assault-weapon (make?M) (model?N)))

)

Разработайте правило make-and-model, которое будет запрашивать у пользователя необходимую информацию о модели оружия и формировать вектор gun в рабочей памяти. Используйте в качестве модели следующие правила, (defrule class-and-action

?G <- (gun (action NIL)) =>

(printout t crlf

"Please enter the class of gun" t crlf "

for example shotgun, rifle, pistol " t crlf "CLASS:" t crlf

;; "Введите класс оружия, "

;; "например, охотничье ружье, карабин,

;; "пистолет и т.д. "

;; "КЛАСС:"

(bind?class (read)) (printout t crlf

"Please enter the action type of the gun" t crlf

"for example bolt, slide, lever, semi,

revolver... " t crlf "ACTION:" t crlf

;; "Введите тип оружия, "

;; "например, с цилиндрическим затвором, со

;; скользящим затвором, с рычажным затвором,

;; полуавтоматический, револьвер...

;; "ТИП:"

(bind?action (read))

(modify?G (class?class) (action?action)))

;; Разработайте правило capacity, которое будет

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

;; В качестве прототипа используйте приведенное

;; ниже правило caliber, которое запрашивает у

;; пользователя значение калибра модели,

(defrule caliber

?G <- (gun (caliber 0.0)) =>

(printout t crlf

"Please enter the caliber of gun" t crlf "CALIBER:" t crlf

;; "Введите калибр оружия, "

;; "КАЛИБР:"

(modufy?G (caliber (read))))

;; Любая полуавтоматическая

;; винтовка (semi-automatic rifle)

;; или охотничье ружье (shotgun) с

;; перечисленными дополнительными признаками.

(defrule Part2

(gun (make?M) (model?N)

(class?CSrifle|shotgun) (action semi)

(features?F&flash-suppressor|barrel-shroud|night-scope)) =>

(assert (assault-weapon (make?M) (model?N))))

;;Разработайте правило pistol-grip-shotgun,

;;которое будет относить любое охотничье ружье

;;с пистолетной рукояткой к категории

;;"оружие нападения".

;;Разработайте правила, которые будут

;;запрашивать у пользователя сведения о

;;дополнительных конструктивных характеристиках

;;модели ранее определенного класса. Например,

;;пистолет, как правило, не имеет защитного

;;кожуха на стволе, поэтому в наборе правил не

;;имеет смысла запрашивать эту характеристику,

;;если ранее определен класс модели pistol.

;;Особые случаи касаются тех моделей, которые

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

;;Модель Cobray Mil относится к категории

"оружие нападения", defrule cobray

(declare (salience 20))

(gun (make cobray) (model Mil)

(class pistol)) =>

(assert (assault-weapon (make cobray)

(model Mil))))

;; Модель этого типа не относится

;; к категории "оружие нападения", (defrule rimfire

(declare (salience 10))

?except <- (gun (make?M) (model?N)

(class rifle) (caliber.22))

?mistake <- (assault-weapon) (model?N))

=>:

(printout t crlf "The "?M " "?N

" is definitely not an assault weapon. " t crlf

;; "Модель "?М " "?N

;; "по определению в законе не относится к

;; категории "оружие нападения"."

(retract?mistake)

(retract?except))

;;Разработайте аналогичное правило

;;slide-action, которое будет исключать

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

;;из категории "оружие нападения".

;;Правила вывода результатов.

;;Разработайте правило probably-is, которое

;;будет извещать пользователя о том, что

;;представленная им модель может быть отнесена

;;к категории "оружие нападения", согласно действующему

;;законодательному акту. В качестве прототипа

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

;;правилом, которое извещает пользователя об

;;обратном результате экспертизы.

(defrule probably-is-not (declare (salience -20))

(gun (make?M) (model?N)) (not

(assault-weapon (make?M) (model?N))) =>

(printout t crlf "The "?M " "?N

" is probably not an assault weapon. " t crlf

;; "Модель "?M " "?N

;; ", вероятно, не относится к

;; категории "оружие нападения"."

(halt))

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

(1) Общее описание полуавтоматического огнестрельного оружия с большой емкостью магазина.

(2) Перечень дополнительных характеристик.

(3) "Любое охотничье ружье с пистолетной рукояткой".

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

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

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

Для того чтобы реализовать в программе формирование такого пояснения, придется добавить два новых поля в вектор assault-weapon:

(deftemplate assault-weapon

(field make (type SYMBOL))

(field model (type SYMBOL))

(field just (type SYMBOL) (default NIL))

(field part (type INTEGER) (default 0)))

Правила, которые формируют этот вектор в новом варианте, должны заполнять эти атрибуты. Например:

(defrule Part)

(gun (make?M) (model?N)

(class?C&rifle|shotgun) (action semi)

(capacity?X&:(>?X 5))) =>

(assert (assault-weapon (make?M) (model?N)

(just capacity) (part 1))))

В этом правиле устанавливается, что причиной, по которой данная модель отнесена к категории "оружие нападения", является емкость ее магазина (capacity), причем сделано это на основании раздела 1 (part 1) законодательного акта.