It_is(mammal),!.

test1(n).

test2(m,c):-

It_is(carnivorous),!.

test2(m,n).

test2(n,w):-

confirm(does,swim),!.

test2(n,n).

test3(m,c,s):-

confirm(has,stripes),

asserta(have_found(tiger)),!.

test3(m,c,n):-

asserta(have_found(cheetah)).

test3(m,n,l):-

not(confirm(does,swim)),

not(confirm(does,fly)),!.

test3(m,n,n):-

asserta(have_found(blue_whale)).

test3(n,n,f):-

confirm(does,fly),

asserta(have_found(eagle)),!.

test3(n,n,n):-

asserta(have_found(ostrich)).

test3(n,w,t):-

confirm(has,tentacles),

asserta(nave_found(octopus)),!.

test3(n,w,n).

test4(m,n,l,s):-

confirm(has,stripes),

asserta(have_found(zebra)),!.

test4(m,n,l,n):-

asserta(have_found(giraffe)).

test4(n,w,n,f):-

confirm(has,feathers),

asserta(have_found(penguin)),!.

test4(n,w,n,n):-

asserta(have_found(sardine)).

Обратите внимание на то, что все проверки производятся посредством одних и тех же предикатов низкого уровня (it_is, confirm и т.п.), которые уже применялись ранее. Как возникает окончательный ответ? Когда при поиске по какому-либо маршруту достигается основание дерева решений, факт, идентифицирующий животное, помещается в базу данных. Например, посмотрите на последний предикат правила, определяющего test3(m,c,s). Мы провели достаточное количество проверок, чтобы узнать, что искомое животное - тигр. Позднее помещенный в базу данных этот факт будет использован в качестве ответа.

Взгляните на правило find_animal. Оно требует выполнения всех четырех проверок, хотя, как видно из блок-схемы, иногда достаточно только трех. Что здесь происходит? Тщательное исследование показывает, что в некоторых случаях основание дерева решений достигается на уровне test3, и в базу данных помещается ответ. Однако правило find_animal, продолжая свою "работу", попытается удовлетворить test4, что невозможно. Это не имеет большого значения, так как мы уже поместили ответ в такое место, откуда сможем его получить (в базу данных). Система возвращается назад и успешно выполняет второе предложение правила find_animal, так что процесс продолжается. Затем другие части правила guess_rule обеспечат распечатку ответа.

Сравнение двух главных стратегий вывода

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

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

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

Итак, какую же цепочку рассуждений предпочтительнее применять: прямую или обратную? Обычно, выбора у вас нет. Задача сама указывает нужный способ рассуждений, и только один подход оказывается реализуемым. Если предполагается небольшое число возможных альтернатив, то лучшие результаты даст использование обратной цепочки рассуждений. Задача, включающая неизменную последовательность шагов, на каждом из которых возникает много возможностей, всегда решается с помощью прямой цепочки рассуждении.

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

1. Программный код, написанный с использованием обратной цепочки рассуждений, более ясный. Все правила программы ПЗР версии 1 хорошо читаются. Они соответствуют интуитивному представлению человека о том, как нужно описывать предметы, являющиеся частью какой-либо иерархии. Описание выполняется по принципу "сверху вниз".

2. Этот программный код легче модифицировать и расширять. Для того чтобы добавить в структуру еще одно животное, его достаточно просто определить. При использовании же прямой цепочки рассуждений это не очевидно. При необходимости нескольких добавлений приходится переделывать все правила, чтобы поддержать прежний уровень эффективности проверок.

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

Задание

1. Сформировать собственную базу правил (не менее 20 правил) в произвольной предметной области на основе собственных знаний или знаний эксперта.

2. Написать программный модуль на Прологе, реализующий вышеприведенный алгоритм.

Содержание отчета

Описание работы программы. Листинг программы с комментариями. Пример работы системы.

Контрольные вопросы

1. Что такое символьная и числовая обработка ?

2. Каковы отличительные особенности ЭС ?

3. Что такое продукционная система, база правил, рабочая память ?

4. Как работает механизм вывода (интерпретатор правил) в Прологе?

5. Что такое прямой вывод ?

6. Как представляются знания в виде правил на языке Пролог?

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Таунсенд К.,Фохт Д. Проектирование и программная реализация экспертных систем на персональных ЭВМ - М.: Финансы и статистика, 1990.

2. Левин Р. и др. Практическое введение в технологию искусственного интелекта и экспертных систем с иллюстрациями на Бейсике. - М.: Финансы и статистика, 1991.

3. Нейлор К. Как построить свою экспертную систему. - М.: Энергоатомиздат, 1991.

4. Сойер Б., Фостер Д. Программирование экспертных систем на Паскале. - М.: Финансы и статистика, 1990.

5. Марселлус Д. Программирование экспертных систем на Турбо Прологе. - М.: Финансы и статистика, 1994.