Функции, выполняемые экспертной системой
Экспертная система — это программа, которая ведет себя подобно эксперту в некоторой, обычно узкой, прикладной области. Типичные применения экспертных систем включают в себя такие задачи, как медицинская диагностика, локализация неисправностей в оборудовании и интерпретация результатов измерений. Экспертные системы должны решать задачи, требующие для своего решения экспертных знаний в некоторой конкретной области. В той или иной форме экспертные системы должны обладать этими знаниями. Поэтому их также называют системами , основанными на знаниях . Однако не всякую систему, основанную на знаниях, можно рассматривать как экспертную. Экспертная система должна также уметь каким-то образом объяснять свое поведение и свои решения пользователю, так же, как это делает эксперт-человек. Это особенно необходимо в областях, для которых характерна неопределенность, неточность информации (например, в медицинской диагностике). В этих случаях способность к объяснению нужна для того, чтобы повысить степень доверия пользователя к советам системы, а также для того, чтобы дать возможность пользователю обнаружить возможный дефект в рассуждениях системы. В связи с этим в экспертных системах следует предусматривать дружественное взаимодействие с пользователем, которое делает для пользователя процесс рассуждения системы "прозрачным".
Часто к экспертным системам предъявляют дополнительное требование — способность иметь дело с неопределенностью и неполнотой. Информация о поставленной задаче может быть неполной или ненадежной; отношения между объектами предметной области могут быть приближенными. Например, может не быть полной уверенности в наличии у пациента некоторого симптома или в том, что данные, полученные лри измерении, верны; лекарство может стать причиной осложнения, хотя обычно этого не происходит. Во всех этих случаях необходимы рассуждения с использованием вероятностного подхода.
|
|
|
В самом общем случае для того, чтобы построить экспертную систему, мы должны разработать механизмы выполнения следующих функций системы:
• решение задач с использованием знаний о конкретной предметной области — возможно, при этом возникнет необходимость иметь дело с неопределенностью
• взаимодействие с пользователем , включая объяснение намерений и решений системы во время и после окончания процесса решения задачи.
Каждая из этих функций может оказаться очень сложной и зависит от прикладной области, а также от различных практических требований. В процессе разработки и реализации могут возникать разнообразные трудные проблемы. В данной главе мы ограничился наметками основных идей, подлежащих в дальнейшем детализации и усовершенствованию.
|
|
|
Грубая структура экспертной системы
При разработке экспертной системы принято делить ее на три основных модуля, как показано на рис. 14.1:
(1) база знаний,
(2) машина логического вывода,
(3) интерфейс с пользователем.
База знаний содержит знания, относящиеся к конкретной прикладной области, в том числе отдельные факты, правила, описывающие отношения или явления, а также, возможно, методы, эвристики и различные идеи, относящиеся к решению задач в этой прикладной области. Машина логического вывода умеет активно использовать информацию, содержащуюся в базе знаний. Интерфейс с пользователем отвечает за бесперебойный обмен информацией между пользователем и системой; он также дает пользователю возможность наблюдать за процессом решения задач, протекающим в машине логического вывода. Принято рассматривать машину вывода и интерфейс как один крупный модуль, обычно называемый оболочкой экспертной системы , или, для краткости, просто оболочкой .
Рис. 14.1. Структура экспертной системы.
В описанной выше структуре собственно знания отделены от алгоритмов, использующих эти знания. Такое разделение удобно по следующим соображениям. База знаний, очевидно, зависит от конкретного приложения. С другой стороны, оболочка, по крайней мере в принципе, независима от приложений. Таким образом, разумный способ разработки экспертной системы для нескольких приложений сводится к созданию универсальной оболочки, после чего для каждого приложения достаточно подключить к системе новую базу знаний. Разумеется, все эти базы знаний должны удовлетворять одному и тому же формализму, который оболочка "понимает". Практический опыт показывает, что для сложных экспертных систем наш сценарий с одной оболочкой и многими базами знаний работает не так гладко, как бы этого хотелось, за исключением тех случаев, когда прикладные области очень близки. Тем не менее даже если переход от одной прикладной области к другой требует модификации оболочки, то по крайней мере основные принципы ее построения обычно удается сохранить.
|
|
|
В этой главе мы намерены разработать относительно простую оболочку, при помощи которой, несмотря на. ее простоту, мы сможем проиллюстрировать основные идеи и методы в области экспертных систем. Мы будем придерживаться следующего плана:
|
|
|
(1) Выбрать формальный аппарат для представления знаний.
(2) Разработать механизм логического вывода, соответствующий этому формализму.
(3) Добавить средства взаимодействия с пользователем.
(4) Обеспечить возможность работы в условиях неопределенности.
14.3. Правила типа "если-то" для представления знаний
В качестве кандидата на использование в экспертной системе можно рассматривать, в принципе, любой непротиворечивый формализм, в рамках которого можно описывать знания о некоторой проблемной области. Однако самым популярным формальным языком представления знаний является язык правил типа "если-то" (или кратко: "если-то"-правил), называемых также продукциями . Каждое такое правило есть, вообще говоря, некоторое условное утверждение, но возможны и различные другие интерпретации. Вот примеры:
• если предварительное условие P то заключение (вывод) С
• если ситуация S то действие А
• если выполнены условия C1 и C2 то не выполнено условие С
"Если-то"-правила обычно оказываются весьма естественным выразительным средством представления знаний. Кроме того, они обладают следующими привлекательными свойствами:
• Модульность : каждое правило описывает небольшой, относительно независимый фрагмент знаний.
• Возможность инкрементного наращивания : добавление новых правил в базу знаний происходит относительно независимо от других правил.
• Удобство модификации (как следствие модульности): старые правила можно изменять и заменять на новые относительно независимо от других правил.
• Применение правил способствует прозрачности системы.
Последнее свойство — это важное, отличительное свойство экспертных систем. Под прозрачностью мы понимаем способность системы к объяснению принятых решений и полученных результатов. Применение "если-то"-правил облегчает получение ответов на следующие основные типы вопросов пользователя:
(1) Вопросы типа "как": Как вы пришли к этому выводу?
(2) Вопросы типа "почему": Почему вас интересует эта информация?
Механизмы, основанные на "если-то"-правилах, для формирования ответов на подобные вопросы мы обсудим позже.
если
1 тип инфекции — это первичная бактериемия и
2 материал для посева был отобран стерильно, и
3 предполагаемые ворота инфекции — желудочно-кишечный тракт
то
имеются веские аргументы (0.7) за то,
что инфекционный агент является бактерией
Рис. 14.2. "Если-то"-правило медицинской консультативной системы MYCIN (Shortliffe, 1976). Параметр 0.7 показывает степень доверия этому правилу.
"Если-то"-правила часто применяют для определения логических отношений между понятиями предметной области. Про чисто логические отношения можно сказать, что они принадлежат к "категорическим знаниям", "категорическим" — потому, что соответствующие утверждения всегда, абсолютно верны. Однако в некоторых предметных областях, таких, как медицинская диагностика, преобладают "мягкие" или вероятностные знания. Эти знания являются "мягкими"; в том смысле, что говорить об их применимости к любым практическим ситуациям можно только до некоторой степени ("часто, но не всегда"). В таких случаях используют модифицированные "если-то"-правила, дополняя их логическую интерпретацию вероятностной оценкой. Например:
если условие А то заключение В с уверенностью F
Рис. 14.2, 14.3 и 14.4 дают представление о разнообразии способов, которыми знания могут быть выражены при помощи "если-то"-правил. На этих рисунках приведены примеры правил из трех различных систем, основанных на знаниях: медицинской консультативной системы MYCIN, системы AL/X для диагностики неисправностей в оборудовании и системы AL3 для решения шахматных задач.
Вообще говоря, если вы хотите разработать серьезную экспертную систему для некоторой выбранной вами предметной области, вы должны провести консультации с экспертами в этой области и многое узнать о ней сами. Достигнуть определенного понимания предметной области после общения с экспертами и чтения литературы, а затем облечь это понимание в форму представления знаний в рамках выбранного формального языка — это искусство, называемое инженерией знаний . Как правило, это сложная задача, требующая больших усилий, чего мы не можем себе позволить в данной книге. Но какая-нибудь предметная область и какая-нибудь база данных нам необходимы в качестве материала для экспериментов. С практической точки зрения нам для этой цели вполне подойдет "игрушечная" база знаний. На рис. 14.5 показана часть такой базы знаний. Она состоит из простых правил, помогающих идентифицировать животных по их основным признаками в предположении, что задача идентификации ограничена только небольшим числом разных животных.
если
давление в v-01 достигло уровня открытия выпускного клапана
то
выпускной клапан в v-01 открылся
[N=0.005, S=400]
если
давление в v-01 не достигло уровня открытия выпускного клапана и выпускной клапан в v-01 открылся
то
преждевременное открытие выпускного клапана (сместилась установка порогового давления)
[N=0.001, S=2000]
Рис. 14.3. Два правила из демонстрационной базы знаний системы AL/X для диагностики неисправностей (Reiter 1980). N и S — величины "необходимости" и "достаточности", детально описанные в разд. 14.7. Величина S указывает степень, с которой условие влечет за собой заключение (вывод). Величина N указывает, до какой степени истинность условия необходима для того, чтобы заключение было истинным.
если
1 существует гипотеза H , что план P ведет к успеху, и
2 существуют две гипотезы
H1 , что план P1 опровергает план P , и
Н2 , что план Р2 опровергает план P , и
3 имеют место факты:
гипотеза H1 ложна и
гипотеза Н2 ложна
то
1 породить гипотезу Н3 , что составной план "P1 или Р2" опровергает план P , и
2 породить факт: из Н3 следует не( H)
Рис. 14.4. Правило уточнения плана из системы AL3 для решения шахматных задач (Bratko 1982).
Правила, содержащиеся в базе знаний, имеют вид
ИмяПравила : если Условие то Заключение
где Заключение — это простое утверждение, а Условие — это набор простых утверждений, соединенных между собой операторами и и или. Мы также разрешим в части условия использовать оператор не, хотя и с некоторыми оговорками. При надлежащем прологовском определении этих операторов (как это сделано на рис. 14.5) правила станут синтаксически верными предложениями Пролога. Заметим, что оператор и связывает операнды сильнее, чем или, что соответствует обычным соглашениям.
% Небольшая база знаний для идентификации животных
:- op( 100, xfx, [имеет, 'кормит детенышей',
'не может', ест, откладывает, это]).
:- op( 100, xf, [плавает, летает, хорошо]).
прав1: если
Животное имеет шерсть
или
Животное 'кормит детенышей' молоком
то
Животное это млекопитающее.
прав2: если
Животное имеет перья
или
Животное летает и
Животное откладывает яйца
то
Животное это птица.
прав3: если
Животное это млекопитающее и
( Животное ест мясо
или
Животное имеет 'острые зубы' и
Животное имеет когти и
Животное имеет
'глаза, направленные вперед' )
то
Животное это хищник.
прав4: если
Животное это хищник и
Животное имеет
'рыжевато-коричневый цвет' и
Животное имеет 'темные пятна'
то
Животное это гепард.
прав5: если
Животное это хищник и
Животное имеет
'рыжевато-коричневый цвет' и
Животное имеет 'черные полосы'
то
Животное это тигр.
прав6: если
Животное это птица и
Животное 'не может' летать и
Животное плавает
то
Животное это пингвин.
прав7: если
Животное это птица и
Животное летает хорошо
то
Животное это альбатрос.
факт: X это животное :-
принадлежит( X, [гепард, тигр, пингвин, альбатрос]).
можно_спросить( _ 'кормит детенышей' _,
'Животное' 'кормит детенышей' 'Чем').
можно_спросить( _ летает, 'Животное' летает).
можно_спросить( _ откладывает яйца,
'Животное' откладывает яйца).
можно_спросить( _ ест _, 'Животное' ест 'Что').
можно_спросить( _ имеет _,'Животное' имеет 'Нечто').
можно_спросить( _ 'не может' _,
'Животное' 'не может' 'Что делать').
можно_спросить( _ плавает, 'Животное' плавает).
можно_спросить( _ летает хорошо,
'Животное' летает хорошо).
Рис. 14.5. Простая база знаний для идентификации животных. Заимствовано из Winston (1984). Отношение "можно_спросить" определяет вопросы, которые можно задавать пользователю. Операторы если, то, и, или определены на рис. 14.10.
Рассмотрим еще одну небольшую базу знаний, которая может помочь локализовать неисправности в простой электрической схеме, состоящей из электрических приборов и предохранителей. Электрическая схема показана на рис. 14.6. Вот одно из возможных правил:
если
лампа1 включена и
лампа1 не работает и
предохранитель1 заведомо цел
то
лампа1 заведомо неисправна.
Вот другой пример правила:
если
радиатор работает
то
предохранитель1 заведомо цел.
Рис. 14.6. Соединения между предохранителями и приборами в простой электрической схеме.
Эти два правила опираются на некоторые факты (относящиеся к нашей конкретной схеме), а именно что лампа1 соединена с предохранитель1 и что лампа1 и радиатор имеют общий предохранитель. Для другой схемы нам понадобится еще один набор правил. Поэтому было бы лучше сформулировать правила в более общем виде (используя прологовские переменные) так, чтобы они были применимы к любой схеме, а затем уже дополнять их информацией о конкретной схеме. Например, вот одно из полезных правил: если прибор включен, но не работает, а соответствующий предохранитель цел, то прибор неисправен. На наш формальный язык это транслируется так:
правило_поломки:
если
Прибор включен и
не (Прибор работает) и
Прибор соединен с Предохранитель и
Предохранитель заведомо цел
то
Прибор заведомо неисправен.
База знаний такого рода показана на рис. 14. 7.
% Небольшая база знаний для локализации неисправностей в
% электрической схеме
% Если прибор включен, но не работает, и предохранитель цел,
% то прибор неисправен.
правило_поломки:
если
вкл( Прибор) и
прибор( Прибор) и
не работает( Прибор) и
соед( Прибор, Предохр) и
доказано( цел( Предохр) )
то
доказано( неиспр( Прибор) ).
% Если устройство работает, то его предохранитель цел
правило_цел_предохр:
если
соед( Прибор, Предохр)
и работает( Прибор)
то
доказано( цел( Предохр) ).
% Если два различных прибора подключены к одному и тому же
% предохранителю, оба включены и не работают, то предохранитель
% сгорел.
% ЗАМЕЧАНИЕ: предполагается, что из двух приборов неисправных -
% не более одного!
правило_предохр:
если
соед( Прибор1, Предохр) и
вкл( Прибор1) и
не работает( Прибор1) и
общ_предохр( Прибор2, Прибор1) и
вкл( Прибор2) и
не работает( Прибор2)
то
доказано( сгорел( Предохр) ).
правило_общ_предохр:
если
соед( Прибор1, Предохр) и
соед( Прибор2, Предохр) и
различны( Прибор1, Прибор2)
то
общ_предохр( Прибор1, Прибор2).
факт: различны( X, Y) :- not (X=Y).
факт: прибор( радиатор).
факт: прибор( лампа1).
факт: прибор( лампа2).
факт: прибор( лампа3).
факт: прибор( лампа4).
факт: соед( лампа1, предохр1).
факт: соед( лампа2, предохр1).
факт: соед( радиатор, предохр1).
факт: соед( лампа3, предохр2).
факт: соед( лампа4, предохр2).
можно_спросить( вкл( П), вкл( 'Прибор') ).
можно_спросить( работает( П), работает(' Прибор')).
Рис. 14.7. База знаний для локализации неисправностей в схеме, показанной на рис. 14.6.
Упражнения
14.1. Рассмотрите "если-то"-правила рис. 14.2-14.4 и транслируйте их в нашу систему обозначений для правил. Предложите расширение нотации, чтобы, при необходимости, можно было работать с оценками уверенности.
14.2. Придумайте какую-нибудь задачу принятия решений и сформулируйте соответствующие знания в форме "если-то"-правил. Можете рассмотреть, например, планирование отпуска, предсказание погоды, простой медицинский диагноз и лечение и т.п.
Разработка оболочки
Если мы посмотрим на правила наших двух маленьких баз знаний рис. 14.5 и 14.7, мы сразу увидим, что они по своему смыслу эквивалентны правилам Пролога. Однако, с точки зрения синтаксиса Пролога, эти правила в том виде, как они написаны, соответствуют всего лишь фактам. Для того, чтобы заставить их работать, самое простое, что может прийти в голову, это переписать их в виде настоящих прологовских правил. Например:
Животное это млекопитающее :-
Животное имеет шерсть;
Животное 'кормит детенышей' молоком.
Животное это хищник :-
Животное это млекопитающее,
Животное ест мясо.
...
Теперь эта программа сможет подтвердить, что тигр по имени Питер — это действительно тигр, если мы добавим в нее некоторые из свойств Питера (в виде прологовских фактов):
питер имеет шерсть.
питер ленив.
питер большой.
питер имеет 'рыжевато-коричневый цвет'.
питер имеет 'черные полосы'.
питер ест мясо.
Тогда мы можем спросить:
?- питер это тигр.
yes
?- питер это гепард.
no
Хотя пролог-система и отвечает на вопросы, используя для этого нашу базу знаний, нельзя сказать, что ее поведение вполне соответствует поведению эксперта. Это происходит по крайней мере по двум причинам:
(1) Мы не можем попросить систему объяснить свой ответ; например, как она установила, что Питер это тигр, и почему Питер это не гепард.
(2) Прежде, чем задать вопрос, нужно ввести в систему всю необходимую информацию (в виде прологовских фактов). Но тогда пользователь, возможно, введет какую-нибудь лишнюю информацию (как в нашем примере) или же упустит какую-нибудь информацию, имеющую решающее значение. В первом случае будет проделана ненужная работа, а во втором - система будет давать неверные ответы.
Для того, чтобы исправить эти два недостатка, мы нуждаемся в более совершенном способе взаимодействия между пользователем и системой во время и после завершения процесса рассуждений. Поставим себе целью добиться того, чтобы система взаимодействовала с пользователем так, как в следующем примере диалога (ответы пользователя даются полужирным шрифтом, реплики пролог-системы — курсивом):
Пожалуйста, спрашивайте:
Питер это тигр.
Это правда: питер имеет шерсть?
Да.
Это правда: питер ест мясо?
Нет.
Это правда: питер имеет острые зубы?
Да.
Это правда: питер имеет когти?
Почему.
Чтобы проверить по прав3, что питер это хищник,
Чтобы проверить по прав5, что питер это тигр
Это был ваш вопрос
Это правда: питер имеет когти?
Да.
Это правда: питер имеет глаза, направленные вперед?
Да.
Это правда: питер имеет рыжевато-коричневый цвет?
Да.
Это правда: питер имеет черные полосы?
Да.
(питер это тигр) это правда
Хотите узнать, как?
Да.
питер это тигр
было выведено по прав5 из
питер это хищник,
было выведено по прав3 из
питер это млекопитающее
было выведено по прав1 из
питер имеет шерсть
было сказано
и
питер имеет острые зубы
было сказано
и
питер имеет когти
было сказано
и
питер имеет глаза, направленные вперед
было сказано
и
питер имеет рыжевато-коричневый цвет
было сказано
и
питер имеет черные полосы
было сказано
Как видно из диалога, система задает пользователю вопросы, касающиеся "примитивной" информации, например:
Это правда: питер ест мясо?
Эту информацию нельзя отыскать в базе знаний или вывести из другой информации. На подобные вопросы пользователь может отвечать двумя способами:
(1) сообщив системе в качестве ответа на вопрос необходимую информацию или
(2) спросив систему, почему эта информация необходима.
Последняя из двух возможностей полезна, поскольку она позволяет пользователю заглянуть внутрь системы и увидеть ее текущие намерения. Пользователь спросит "почему" в том случае, когда вопрос системы покажется ему не относящимся к делу либо когда ответ на вопрос системы потребует от него дополнительных усилий. Из объяснений системы пользователь поймет, стоит ли информация, которую запрашивает система, тех дополнительных усилий, которые необходимо приложить для ее приобретения. Предположим, например, что система спрашивает: "Это животное ест мясо?" Пользователь, не знающий ответа на этот вопрос, поскольку он никогда не видел, как это животное ело что-либо, может решить, что не стоит ждать, пока он застанет животное за едой и убедится, что оно действительно ест мясо.
Для того, чтобы заглянуть внутрь системы и до какой-то степени представить себе протекающий в ней процесс рассуждений, можно воспользоваться прологовскими средствами трассировки. Но эти средства в большинстве случаев окажутся недостаточно гибкими для наших целей. Поэтому, вместо того, чтобы воспользоваться собственным механизмом интерпретации Пролога, который не сможет справиться с нужным нам способом взаимодействия с пользователем, мы создадим свое средство интерпретации в виде специальной надстройки над пролог-системой. Этот новый интерпретатор будет включать в себя средства для взаимодействия с пользователем.
Процесс рассуждений
Наш интерпретатор будет принимать вопрос и искать на него ответ. Язык правил допускает, чтобы в условной части правила была И/ИЛИ-комбинация условий. Вопрос на входе интерпретатора может быть такой же комбинацией подвопросов. Поэтому процесс поиска ответов на эти вопросы будет аналогичен процессу поиска в И/ИЛИ-графах, который мы обсуждали в гл. 13.
Ответ на заданный вопрос можно найти несколькими способами в соответствии со следующими принципами:
Для того, чтобы найти ответ Отв на вопрос В , используйте одну из следующих возможностей:
• если В найден в базе знаний в виде факта, то Отв — это "В это правда"
• если в базе знаний существует правило вида
"если Условие то В ",
то для получения ответа Отв рассмотрите Условие
• если вопрос В можно задавать пользователю, спросите пользователя об истинности В
• если в имеет вид В1 и В2 , то рассмотрите В1 , а затем,
если В1 ложно, то положите Отв равным "В это ложь", в противном случае рассмотрите В2 и получите Отв как соответствующую комбинацию ответов на вопросы В1 и В2
• если В имеет вид В1 или В2 , то рассмотрите В1 , а затем,
если В1 истинно, то положите Отв равным "В1 это правда", в противном случае рассмотрите В2 и получите Oтв как соответствующую комбинацию ответов на вопросы В1 и В2 .
Вопросы вида
не В
обрабатываются не так просто, и мы обсудим их позже.
14.4.2. Формирование ответа на вопрос "почему"
Вопрос "почему " возникает в ситуации, когда система просит пользователя сообщить ей некоторую информацию, а пользователь желает знать, почему эта информация необходима. Допустим, что система спрашивает:
а — это правда?
В ответ пользователь может спросить:
Почему?
Объяснение в этом случае выглядит примерно так:
Потому, что
Я могу использовать а ,
чтобы проверить по правилу Па , что b , и
Я могу использовать b ,
чтобы проверить по правилу Пb , что с , и
Я могу использовать с ,
чтобы проверить по правилу Пc , что d , и
…
Я могу использовать y ,
чтобы проверить по правилу Пy , что z , и
z — это ваш исходный вопрос.
Объяснение — это демонстрация того, как система намерена использовать информацию, которую она хочет получить от пользователя. Намерения системы демонстрируются в виде цепочки правил и целей, соединяющей эту информацию с исходным вопросом.
Рис. 14.8. Объяснение типа "почему". На вопрос "Почему вас интересует текущая цель?" дается объяснение в виде цепочки правил и целей, соединяющей текущую цель с исходным вопросом пользователя, находящимся в верхушке дерева. Эта цепочка называется трассой.
Будем называть такую цепочку трассой . Трассу можно себе представлять как цепочку правил, соединяющую в И/ИЛИ-дереве вопросов текущую цель с целью самого верхнего уровня так, как это показано на рис. 14.8. Таким образом, для формирования ответа на вопрос "почему" нужно двигаться в пространстве поиска от текущей цели вверх вплоть до самой верхней цели. Для того, чтобы суметь это сделать, нам придется в процессе рассуждений сохранять трассу в явном виде.
14.4.3. Формирование ответа на вопрос "как"
Получив ответ на свой вопрос, пользователь возможно захочет увидеть, как система пришла к такому заключению. Один из подходящих способов ответить на вопрос "как" — это представить доказательство, т.е. те правила и подцели, которые использовались для достижения полученного заключения. Это доказательство в случае нашего языка записи правил имеет вид решающего И/ИЛИ-дерева. Поэтому наша машина логического вывода будет не просто отвечать на вопрос, соответствующий цели самого верхнего уровня — этого нам недостаточно, а будет выдавать в качестве ответа решающее И/ИЛИ-дерево, составленное из имен правил и подцелей. Затем это дерево можно будет отобразить на выходе системы в качестве объяснения типа "как". Объяснению можно придать удобную для восприятия форму, если каждое поддерево печатать с надлежащим отступом, например:
питер это хищник
было выведено по прав3 из
питер это млекопитающее
было выведено по прав1 из
питер имеет шерсть
было сказано
и
питер ест мясо
было сказано
Реализация
Теперь мы приступим к реализации нашей оболочки, следуя тем идеям, которые обсуждались в предыдущем разделе. На рис. 14.9 показаны основные объекты, которыми манипулирует оболочка. Цель — это вопрос, подлежащий рассмотрению; Трасса — это цепочка, составленная из "целей-предков" и правил, находящихся между вершиной Цель и вопросом самого верхнего уровня; Ответ — решающее дерево типа И/ИЛИ для вершины Цель.
Рис. 14.9. Отношение рассмотреть( Цель, Трасса, Ответ).
Ответ — это И/ИЛИ решающее дерево для целевого утверждения Цель.
Основными процедурами оболочки будут:
рассмотреть( Цель, Трасса, Ответ)
Эта процедура находит ответ Ответ на вопрос Цель. Процедура
ответпольз( Цель, Трасса, Ответ)
порождает решения для тех вопросов Цель, которые можно задавать пользователю. Она спрашивает пользователя об истинности утверждения Цель, а также отвечает на вопросы "почему". Процедура
выдать( Ответ)
выводит результат и отвечает на вопросы "как". Все эти процедуры приводятся в действие процедурой-драйвером эксперт.
Процедура рассмотреть
Центральной процедурой оболочки является процедура
рассмотреть( Цель, Трасса, Ответ)
которая будет находить ответ Ответ на заданный вопрос Цель, используя принципы, намеченные в общих чертах в разд. 14.4.1: найти Цель среди фактов базы знаний, или применить правило из базы знаний, или спросить пользователя, или же обработать Цель как И/ИЛИ-комбинацию подцелей.
Аргументы имеют следующий смысл и следующую структуру:
Цель
вопрос, подлежащий рассмотрению, представленный как И/ИЛИ-комбинация простых утверждений, например
X имеет перья или X летает или
X откладывает яйца
Трасса
цепочка, составленная из целей-предков и правил, расположенных между Цель и исходной целью самого верхнего уровня. Представляется как список, состоящий из элементов вида
Цель по Прав
что означает: Цель рассматривалась с использованием правила Прав. Например, пусть исходной целью будет "питер это тигр", а текущей целью — "питер ест мясо". В соответствии с базой знаний рис. 14.5 имеем трассу
[( питер это хищник) по прав3,
( питер это тигр) по прав5 ]
Смысл ее можно выразить так:
Я могу использовать "питер ест мясо" для того, чтобы проверить по прав3, что "питер это хищник".
Далее, я могу использовать "питер это хищник" для того, чтобы проверить по прав5, что "питер это тигр".
Ответ
решающее И/ИЛИ-дерево для вопроса Цель. Общая форма представления для объекта Ответ:
Заключение было Найдено
где Найдено — это обоснование для результата Заключение. Следующие три примера иллюстрируют различные варианты ответов:
(1) ( соед( радиатор, предохр1) это правда) было
'найдено как факт'
(2) (питер ест мясо) это ложь было сказано
(3) (питер это хищник) это правда было
( 'выведено по' прав3 из
(питер это млекопитающее) это правда было
( 'выведено по' прав1 из
(питер имеет шерсть) это правда было сказано)
и
(питер ест мясо) это правда было сказано )
На рис. 14.10 показана прологовская программа для процедуры рассмотреть. В этой программе реализованы принципы разд. 14.4.1 с использованием только что описанных структур данных.
% Процедура
%
% рассмотреть( Цель, Трасса, Ответ)
%
% находит Ответ на вопрос Цель. Трасса - это цепочка
% целей-предков и правил. "рассмотреть" стремится найти
% положительный ответ на вопрос. Ответ "ложь" выдается
% только в том случае, когда рассмотрены все возможности,
% и все они дали результат "ложь".
:- op( 900, xfx, :).
:- op( 800, xfx, было).
:- op( 870, fx, если).
:- op( 880, xfx, то).
:- op( 550, xfy, или).
:- op( 540, xfy, и).
:- op( 300, fx, 'выведено по').
:- op( 600, xfx, из).
:- op( 600, xfx, по).
% В программе предполагается,что op( 700, хfх, это), op( 500, fx, не)
рассмотреть( Цель, Трасса, Цель это правда
было 'найдено как факт') :-
факт : Цель.
% Предполагается, что для каждого типа цели
% существует только одно правило
рассмотреть( Цель, Трасса,
Цель это ПравдаЛожь
было 'выведено по' Прав из Ответ) :-
Прав : если Условие то Цель,
% Правило, относящееся к цели
рассмотреть( Условие, [Цель по Прав | Трасса], Ответ),
истинность( Ответ, ПравдаЛожь).
рассмотреть( Цель1 и Цель2, Трасса, Ответ) :- !,
рассмотреть( Цель1, Трасса, Ответ1),
продолжить( Ответ1, Цель1 и Цель2, Трасса, Ответ).
рассмотреть( Цель1 или Цель2, Трасса, Ответ) :-
рассм_да( Цель1, Трасса, Ответ);
% Положительный ответ на Цель1
рассм_да( Цель2, Трасса, Ответ).
% Положительный ответ на Цель2
рассмотреть( Цель1 или Цель2, Трасса,
Ответ1 и Ответ2) :- !,
not рассм_да( Цель1, Трасса, _ ),
not рассм_да( Цель2, Трасса, _ ),
% Нет положительного ответа
рассмотреть( Цель1, Трасса, Ответ1),
% Ответ1 отрицательный
рассмотреть( Цель2, Трасса, Ответ2).
% Ответ2 отрицательный
рассмотреть( Цель, Трасса,
Цель это Ответ было сказано) :-
ответпольз( Цель, Трасса, Ответ). % Ответ дан пользователем
рассм_да( Цель, Трасса, Ответ) :-
рассмотреть( Цель, Трасса, Ответ),
положительный( Ответ).
продолжить( Ответ1, Цель1 и Цель2, Трасса, Ответ) :-
положительный( Ответ1),
рассмотреть( Цель2, Трасса, Ответ2),
( положительный( Ответ2), Ответ = Ответ1 и Ответ2;
отрицательный( Ответ2), Ответ = Ответ2).
продолжить( Ответ1, Цель1 и Цель2, _, Ответ1) :-
отрицательный( Ответ1).
истинность( Вопрос это ПравдаЛожь было Найдено,
ПравдаЛожь) :- !.
истинность( Ответ1 и Ответ2, ПравдаЛожь) :-
истинность( Ответ1, правда),
истинность( Ответ2, правда), !,
ПравдаЛожь = правда;
ПравдаЛожь = ложь.
положительный( Ответ) :-
истинность( Ответ, правда).
отрицательный( Ответ) :-
истинность( Ответ, ложь).
Рис. 14.10. Основная процедура оболочки экспертной системы.
Процедура ответпольз
Прежде чем перейти к написанию процедуры ответпольз, давайте рассмотрим одну полезную вспомогательную процедуру
принять( Ответ)
В процессе диалога часто возникает ситуация, когда от пользователя ожидается ответ "да", "нет" или "почему". Процедура принять предназначена для того, чтобы извлечь один из этих ответов, понимая его правильно и в тех случаях, когда пользователь применяет сокращения ('д' или 'н') или делает ошибки. Если ответ пользователя непонятен, то принять просит дать другой вариант ответа.
принять( Ответ) :-
read( Ответ1),
означает( Ответ1, Значение), !,
% Ответ1 означает что-нибудь?
Ответ = Значение; % Да
nl, write( 'Непонятно, попробуйте еще раз, % Нет
пожалуйста'), nl,
принять( Ответ). % Новая попытка
означает( да, да).
означает( д, да).
означает( нет, нет).
означает( н, нет).
означает( почему, почему).
означает( п, почему).
Следует заметить, что процедурой принять нужно пользоваться с осторожностью, так как она содержит взаимодействие с пользователем. Следующий фрагмент программы может служить примером неудачной попытки запрограммировать интерпретацию ответов пользователя:
принять( да), интерп_да( ...);
принять( нет), интерп_нет( ...);
...
Здесь, если пользователь ответит "нет", то программа попросит его повторить свой ответ. Поэтому более правильный способ такой:
принять( Ответ),
( Ответ = да, интерп_да( ...);
Ответ = нет, интерп_нет( ...);
... )
Процедура
ответпольз( Цель, Трасса, Ответ)
спрашивает пользователя об истинности утверждения Цель. Ответ — это результат запроса. Трасса используется для объяснения в случае, если пользователь спросит "почему".
Сначала процедура ответпольз должна проверить, является ли Цель информацией, которую можно запрашивать у пользователя. Это свойство объекта Цель задается отношением
можно_спросить( Цель)
которое в дальнейшем будет усовершенствовано. Если спросить можно, то утверждение Цель выдается пользователю, который, в свою очередь, указывает истинно оно или ложно. Если пользователь спросит "почему", то ему выдается Трасса. Если утверждение Цель истинно, то пользователь укажет также значения содержащихся в нем переменных (если таковые имеются).
Все вышеизложенное можно запрограммировать (в качестве первой попытки) следующим образом:
остветпольз( Цель, Трасса, Ответ) :-
можно_спросить( Цель), % Можно ли спрашивать
спросить( Цель, Трасса, Ответ).
% Задать вопрос относительно утверждения Цель
спросить( Цель, Трасса, Ответ) :-
показать( Цель),
% Показать пользователю вопрос
принять(Ответ1), % Прочесть ответ
обработать( Ответ1, Цель, Трасса, Ответ).
% Обработать ответ
обработать( почему, Цель, Трасса, Ответ) :-
% Задан вопрос "почему"
показать_трассу( Трасса),
% Выдача ответа на вопрос "почему"
спросить( Цель, Трасса, Ответ).
% Еще раз спросить
обработать( да, Цель, Трасса, Ответ) :-
% Пользователь ответил, что Цель истинна
Ответ = правда,
запрос_перем( Цель);
% Вопрос о значении переменных
спросить( Цель, Трасса, Ответ).
% Потребовать от пользователя новых решений
обработать( нет, Цель, Трасса, ложь).
% Пользователь ответил, что Цель ложна
показать( Цель) :-
nl, write( 'Это правда:'),
write( Цель), write( ?), nl.
Обращение к процедуре запрос_перем( Цель) нужно для того, чтобы попросить пользователя указать значение каждой из переменных, содержащихся в утверждении Цель:
запрос_перем( Терм) :-
var( Терм), !, % Переменная ?
nl, write( Терм), write( '='),
read( Терм). % Считать значение переменной
запрос_перем( Терм) :-
Терм =.. [Функтор | Аргументы],
% Получить аргументы структуры
запрос_арг( Аргументы).
% Запросить значения переменных в аргументах
запрос_арг( []).
запрос_арг( [Терм | Термы]) :-
запрос_перем( Терм),
запрос_арг( Термы).
Проведем несколько экспериментов с процедурой ответпольз. Пусть, например, известно, что пользователя можно спрашивать о наличии бинарного отношения ест:
можно_спросить( X ест Y).
(В приведенных ниже диалогах между пролог-системой и пользователем тексты пользователя даются полужирным шрифтом , а реплики пролог-системы курсивом ).
?- ответпольз( питер ест мясо, [], Ответ).
Это правда: питер ест мясо? % Вопрос пользователю
да. % Ответ пользователя
Ответ = правда
Более интересный пример диалога (с использованием переменных) мог бы выглядеть примерно так:
?- ответпольз( Кто ест Что, [], Ответ).
Это правда: _17 ест _18?
% Пролог дает переменным свои внутренние имена
Да.
_17 = питер .
_18 = мясо .
Ответ = правда.
Кто = питер
Что = мясо; % Возврат для получения других решений
Это правда: _17 ест _18?
Да.
_17 = сьюзен.
_18 = бананы.
Ответ = правда
Кто = сьюзен
Что = бананы;
Это правда : _17 ест _18?
Нет.
Ответ = ложь
Дата добавления: 2018-05-01; просмотров: 843; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!