Как написать экспертную систему

Рассказывает Юрий Дубровских

Экспертные системы — это вычислительные системы, способные в определённой предметной области принимать решения, схожие с решениями экспертов-людей.

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

Кроме того, можно применить несколько интересных особенностей. Например, система может сделать не один вывод, а перечислить варианты с разной степенью вероятности. Можно учитывать различные виды нечётких данных — если пользователь не знает ответы на некоторые вопросы или что-то предполагает. Вместо пользователя система может опрашивать датчики или брать информацию из разных источников. Продвинутые системы могут самообучаться, то есть выявлять закономерности во время сеансов работы и генерировать новые знания.

Таким образом, экспертные системы могут применяться для довольно широкого круга задач:

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

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

Тем не менее, в настоящее время существует и используется довольно много экспертных систем в сфере медицины, химии и военного дела. Вот некоторые примеры:

  • Система по глобальной онтологии;
  • Акинатор — система, которая отгадывает загаданного вами персонажа;
  • MYCIN — выбор антимикробной терапии в условиях стационара;
  • DENDRAL — химический анализ сложных молекул;
  • поговаривают также, что отечественная система «Периметр», предназначенная для ответного удара в случае уничтожения командных пунктов, оснащена экспертной системой (которая и принимает решение о нанесении удара).

Попробуем создать небольшую экспертную систему. Для первого раза возьмём тренировочную предметную область. Хороший способ убедиться, что искусственный интеллект своими руками — это просто.

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

Немного теории

Для начала разберёмся, что нам предстоит сделать.

Итак, экспертная система состоит из нескольких основных компонентов:

  • база знаний;
  • механизм логического вывода (МЛВ);
  • компонента объяснения.

База знаний

База знаний — это, можно сказать, сердце экспертной системы. Знание — это информация вместе со способом её интерпретации, то есть это более высокий уровень информации. Система, обладающая знаниями, может не только выдавать информацию, но и объяснять её смысл и происхождение. Описание способа интерпретации называется метаданными.

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

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

Получаемая при этом база знаний может быть представлена в различных видах. Это может быть, к примеру, семантическая сеть. Но более классический вариант — набор продукционных правил (продукций). Продукционное правило — это правило вида ЕСЛИ <условие> ТО <действие>. Формулируя на естественном языке: если мясо жарится долго, оно приготовилось. Где же тут действие, спросите вы. Обо всём по порядку. Посмотрим на структуру правила более пристально.

И условие, и действие содержат в себе некие факты. Факт сам по себе может быть истинным или ложным, а также мы можем не иметь данных о его истинности. Факт может иметь определённую степень уверенности, например мы не знаем, что значит «долго» в контексте приготовления шашлыка, но кажется, что жарится уже довольно давно. Состоит факт из переменной и значения. Значение берётся из множества возможных значений — домена переменной. То есть наше условие «мясо жарится долго» можно переписать в виде: Время жарки = долго, где «время жарки» — переменная, а «долго» — значение. Если все возможные вопросы относительно времени жарки будут иметь ответ только «долго» и «недолго» — это и будет домен этой переменной.

Действие представляет собой присвоение истинности некоторому факту. То есть вместо человеческого «оно приготовилось», в ходе работы правила факт Мясо готово = да помечается как истинный.

Ещё раз посмотрим на то, что получилось из простого предложения эксперта. Из начального Если мясо жарится долго, оно приготовилось получается:

Переменные:

  1. Время жарки (домен: долго, недолго).
  2. Мясо готово (домен: да, нет).

Правило:

Если факт «время жарки = долго» — истинный, то факт «мясо готово = да» пометить как истинный.

Конечно, если мясо долго жарится, ещё нельзя уверенно утверждать, что оно готово, может быть, угли холодные. Но в нашем примере мы закроем на это глаза и не будем использовать степень уверенности в фактах.

Так, изучая высказывания экспертов, инженеры по знаниям выделяют имеющиеся в предметной области сущности и формируют правила. Что же с этими правилами происходит дальше?

Механизм логического вывода

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

На первом шаге механизм находит в базе знаний все правила, в которых переменная-цель присутствует в качестве вывода, не важно, с каким значением. Теперь каждое правило, если они нашлись, по очереди (именно поэтому важен порядок следования правил) проверяются до первого сработавшего. То есть до того, все условия которого окажутся истинными. Для проверки правила берутся все его условия и, опять же, по очереди проверяются — объявляются целью консультации, и алгоритм запускается для них с первого шага.

Не для всех переменных существуют правила, которые их определяют. Некоторые запрашиваются из внешних источников, в простейшем случае — у пользователя. Переменные, которые определяются правилами, называются выводимыми, а определяемые пользователем во время консультации — запрашиваемыми. Тип переменной определяется ещё на этапе формирования базы знаний, и для запрашиваемых должны быть заданы способы определения, например сформулирован вопрос для пользователя. Если пользователь не может ответить или для выводимой переменной не нашлось правил, или ни одно из правил не сработало — переменная остаётся без значения, а пользователь — без установленной истины.

Существуют ещё выводимо-запрашиваемые переменные. Для них существуют и правила вывода, и вопрос пользователю. Сначала механизм логического вывода пытается определить такие переменные с помощью правил, а если не получается — задаёт вопрос.

Компонента объяснения

Ещё одна немаловажная часть экспертной системы. Именно объяснение хода рассуждений и обоснование выводов выгодно отличают экспертную систему от других отраслей искусственного интеллекта.

На этапе формирования базы знаний в качестве метаданных к правилам прилагаются их объяснения на естественном языке. После консультации система может показать все сработавшие правила вместе с этими пояснениями. Комментарии можно также добавлять к отдельным фактам или переменным.

В итоге мы узнаём не только что надо перевернуть шашлык, но и почему нужно это сделать.

Это очень серьёзное преимущество для систем поддержки принятия решений и для других применений экспертных систем. Некоторые промышленные системы в качестве результата дают несколько ответов с пояснениями и степенями вероятности.

Переход к практике

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

Оболочка экспертной системы

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

Ещё в студенческие годы мне довелось написать оболочку для экспертной системы. Конечно, она далеко не идеальна, ни с точки зрения кода, ни с точки зрения пользовательского интерфейса. Но во-первых, она работает. По крайней мере для небольших задач, как наша, она вполне годится для примера. Во-вторых, как ни странно, та же Википедия называет одним из основных недостатков экспертных систем отсутствие графического пользовательского интерфейса (взаимодействие обычно идёт через терминал). Так что наличие какого бы то ни было интерфейса (который у меня есть) — уже достаточный вклад в отрасль.

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

Модель данных можно использовать самую простую, как в теории:

  • Domain (Домен):
    • Имя.
    • Список значений.
  • Variable:
    • Имя.
    • Домен.
    • Тип (выводимая, запрашиваемая, выводимо-запрашиваемая).
    • Вопрос для пользователя.
    • Объяснение.
  • Fact:
    • Переменная.
    • Значение.
    • Истинность (неизвестно, истинный, ложный).
  • Rule:
    • Список фактов-условий.
    • Факт-вывод.
    • Результат (не сработало, сработало и вывод признан истинным, сработало и не привело к получению значения переменной).

В режиме проектирования базы знаний пользователь может завести все эти данные. Затем он переходит в режим консультации. Выбирается цель консультации, и запускается процедура GoConsult. Вот схема её работы:

Как видно, эта процедура вызывает проверку правил DoRule, её тоже рассмотрим подробно:

DoRule в свою очередь вызывает GoConsult, то есть алгоритм получается косвенно-рекурсивным. А в результате мы получаем факт — значение искомой переменной, которое введено пользователем или получено из базы знаний, или отсутствие значения, если истину определить не удалось.

Теперь, когда у нас есть модель данных и алгоритм, можем переходить к самому интересному — проектированию базы знаний.

База знаний

Что ж, начнём записывать в систему свои знания о шашлыке. При этом нужно помнить несколько вещей:

  1. Согласно алгоритму логического вывода, все условия в правиле объединены через И. Чтобы использовать ИЛИ, нужно создать несколько правил.
  2. Создать нужно не только подтверждающие что-то правила, но и противоположные. Например, если мы создаём правило ЕСЛИ Время жарки = Долго И Степень поджарки = Поджаристое, ТО Готово = Да, мы должны создать ещё такие правила: ЕСЛИ Время жарки = Только положили ТО Готово = Нет и ЕСЛИ Степень поджарки = Ещё сырое, ТО Готово = Нет.
  3. Важен порядок правил в базе знаний.

Нужно формализовать свои знания о шашлыке и представить в виде модели базы знаний, то есть выделить домены, переменные и правила. Чтобы было легче сформировать набор правил, да ещё и в нужном порядке, можно составить их графическое представление. У меня получилась довольно дикая, боюсь, понятная только мне схема:

Вершины определяют список переменных и возможных значений, а также какие переменные будут запрашиваемыми, а какие выводимыми. Дуги указывают на некоторые связи, из которых впоследствии получаются правила. Здесь я предположил, что мы будем жарить курицу или свинину, а система может подсказать три действия — ждать, перевернуть, снимать. Исходя из вашего опыта, вы можете сделать другие правила, расширить или переделать эту базу знаний. Вообще говоря, этим база знаний и хороша, что её ещё долго можно расширять, включая новые виды мяса, предполагаемые действия, обстоятельства и так далее. Пока же у меня получилось 27 правил:

В промышленных системах количество правил может исчисляться тысячами. Для нашей тренировочной области пока попробуем чуть меньше. Итак, запустим консультацию и посмотрим, что нам посоветует система.

Я сказал, что жарю свинину минут 10, и система посоветовала подождать ещё, и вот почему:

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

Вот и всё, искусственный интеллект — система поддержки принятия решений в узкой предметной области — создан. Конечно, он не учитывает многие факторы, нечёткости и так далее. В базе знаний нет сведений о том, как захватить мир, и в отличие от некоторых промышленных систем, наша не способна анализировать консультации и сама генерировать новые правила. Но с шашлычными экспертами, которые будут кучковаться летом вокруг мангала, она уже вполне может поспорить.

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

Экспертные системы создаются для самых различных предметных областей, например:

  • созданы системы медицинской диагностики, которые по набору симптомов назначают анализы, по результатам которых ставится диагноз и определяется курс лечения [1, 2];
  • экспертные системы могут следить за соблюдением правил дорожного движения [3] и даже оценивать военную безопасность государства [4].

Так или иначе, в процессе использования в систему попадают факты пользователя, чаще всего это происходит в форме диалога, при этом система формирует вопросы исходя их данных в базе и данных ранее ответов. Например, система Akinator [5], угыдывающая задуманного пользователем персонажа мультфильма, может спросить «является ли ваш персонаж человеком?».

Важно, что все экспертные системы, вне зависимости от предметной области, имеют схожую структуру — на самом деле, какая разница «угадывает» система диагноз по симптомам или персонажа мультфильма по его параметрам? По этой причине для разработки часто используются специальные инструменты создания типовых систем или заготовки систем, в которые эксперту нужно лишь внести данные и правила, однако, в этой статье мы посмотрим как сделать простейшую экспертную систему на языке Prolog.

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

Важно понимать, что база данных содержит факты, а база знаний — правила вывода решений на основе фактов и введенных пользователем данных. Правила представляют собой, по сути, исходный код программы, — именно поэтому для разработки экспертных систем удобно использовать языки типа SWI Prolog, ведь они позволяют добавлять новые правила в программу прямо во время ее исполнения. Чтобы понять как разработанная система работает и как запустить приведенный код стоит пройти по ссылкам [6, 7].

Ниже приведен пример разработки сильно упрощенной экспертной системы, помогающей студенту выбрать тему дипломной работы.

1 Обзор предметной области

Так как в основе любой экспертной системы находится база данных, то разработка начинается с анализа предметной области. Тут надо понять какие критерии стоит учитывать при подборе темы дипломной работы. Темы выпускных работ обычно формируют преподаватели исходя из своих интересов. Студент выбирает тему бакалаврской работы из набора имеющихся с учетом:

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

Например, если студент при обучении у преподавателя Пупкина с трудом получил тройку — маловероятно он пойдет к нему на дипломирование. Если студент ничего не знает в области блокчейна, но ему хотелось бы развиваться в этой сфере — возможно он выберет соответствующую тему. Тема работы «Разработка клиент-серверного приложения для игры в покер» может быть интересна студенту, но он не возьмет ее если руководитель требует писать сервер на Erlang, а студент не любит функциональное программирование.

Таким образом, предметная область задачи состоит из сущностей:

  • руководитель ВКР;
  • область интересов;
  • тема ВКР;
  • технология выполнения;
  • студент.

Модель предметной области с использованием нотации диаграммы классов UML [8] приведена на рисунке:

2 Наполнение базы данных

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

Для наполнения базы были найдены темы ВКР, по первому запросу поисковая система выдала информацию о темах Высшей школы экономики [9]. Однако, опубликованный список тем содержит лишь информацию о названии и руководителе, остальная информация была сформирована мной и не является точной — данные в базу данных экспертной системы должен вносить эксперт (руководитель ВКР).

В результате создана такая база данных:

theme('Повышение эффективности операций в цепях поставок', 
      'Бажина Д.Б.', 
      complex(70), 
      knowledge_areas(['экономика', 'управление', 'экономика', 'оптимизация']),
      skills(['1C'])
).

theme('Повышение эффективности управления цепями поставок скоропортящихся товаров', 
      'Бажина Д.Б.', 
      complex(75), 
      knowledge_areas(['экономика', 'управление', 'законы', 'экономика', 'оптимизация']),
      skills([])
).

theme('Разработка мероприятий по повышению лояльности потребителей транспортных услуг', 
      'Бородулина С.А.', 
      complex(85), 
      knowledge_areas(['транспорт', 'психология']),
      skills([])
).

theme('Повышение эффективности управления материальными ресурсами транспортной компании', 
      'Бородулина С.А.', 
      complex(60), 
      knowledge_areas(['транспорт', 'управление', 'экономика', 'оптимизация']),
      skills(['1C'])
).

theme('Разработка рекомендаций по применению геоинформационных технологий для повышения качества работы транспортной системы мегаполиса', 
      'Бочкарев А.А.', 
      complex(60), 
      knowledge_areas(['ГИС', 'транспорт', 'оптимизация']),
      skills(['1C'])
).

theme('Применение аппарата теории массового обслуживания для повышения эффективности синтеза обслуживающих систем', 
      'Булатов М.А.', 
      complex(95), 
      knowledge_areas(['математика', 'оптимизация']),
      skills(['теория массового обслуживания'])
).

На этом этапе можно лишь перебрать все записи базы и вывести их запросом:
?- theme(Theme, Name, Complex, knowledge_areas(Areas), skills(Skills)).

3 Алгоритмы работы экспертной системы (формирование базы знаний)

3.1 Выбор руководителей

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

Собрать всех преподавателей можно так:

findall(Name, theme(_Theme, Name, _Complex, _Areas, _Skills), Names),
list_to_set(Names, Set).

Встроенный предикат findall находит все решения предиката, переданного вторым аргументом и формирует из решений список. Однако, имена в таком списке могут повторяться — если у одного преподавателя было несколько тем то интерпретатор найдет его имя несколько раз. Поэтому следом вызывается предикат list_to_set, который убирает из списка повторы.

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

print_enumeration_list([], _Number):-!.
print_enumeration_list([Head|Tail], Number):-
    write('t'), write(Number), write(' - '), write(Head), nl,
    Next is Number+1,
    print_enumeration_list(Tail, Next).

get_names(Names):-
    findall(Name, theme(_Theme, Name, _Complex, _Areas, _Skills), Names),
    list_to_set(Names, Set).

Результат выполнения запроса:

Теперь можно запросить у пользователя список имен и выбрать соответствующих номерам преподавателей:

nths_1(All, Indexes, Selected):-
    Indexes = [], !, Selected = [];
    Indexes = [HeadIndex|TailIndexes],
    nth1(HeadIndex, All, HeadSelected),
    nths_1(All, TailIndexes, TailSelected),
    Selected = [HeadSelected|TailSelected].
    
select_names(SelectedNames):-
    get_names(Names),
    print_enumeration_list(Names, 1),
    write('Введи подходящих преподавателей [номера через запятую]: '),
    read(Numbers),
    nths_1(Names, Numbers, SelectedNames), !;
    % введены неверные данные:
    write('Неправильный ввод, повторим...'), nl,
    select_names(SelectedNames).

Тут предикат select_names после вывода списка преподавателей запрашивает список номеров и передает их в предикат nths_1, который выбирает элементы списка соответствующие списку номеров (нумерация начинается с единицы). если введены неверные данные — то выведется сообщение об ошибке и процесс повторится (рекурсивно):

3.2 Выбор области знаний

Теперь, когда выбраны предполагаемые — можно собрать список областей знаний в которых у них есть темы и выдать их в виде такого же списка.
Сначала можно получить список всех областей в которых есть темы у выбранных руководителей:

area_of_masters(Names, Area):-
    member(Name, Names), 
    theme(_Theme, Name, _Complex, knowledge_areas(Areas), _Skills),
    member(Area, Areas).

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

Теперь можно собрать все эти области в список и убрать из него повторы:

collect_areas(Names, Areas):-
    findall(Area, 
            area_of_masters(Names, Area),
            AreasList
    ),
    list_to_set(AreasList, Areas).

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

select_areas(Names, SelectedAreas):-
    collect_areas(Names, Areas),
    print_enumeration_list(Areas, 1),
    write('Введи подходящих области [номера через запятую]: '),
    read(Numbers),
    nths_1(Areas, Numbers, SelectedAreas), !;
    write('Неправильный ввод, повторим...'), nl,
    select_areas(Names, SelectedAreas).

В настоящий момент можно написать такую цель:

?- select_names(Names), select_areas(Names, Areas).

с ее помощью мы сначала просим выбрать имена, а затем области. Результат ее выполнения:

3.3 Указание компетенций студента

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

skills_of_such_themes_that(Names, Areas, Skill):-
    theme(_Theme, Name, _Complex, knowledge_areas(ThemeAreas), skills(Skills)),
    member(Name, Names),
    member(Area, Areas), member(Area, ThemeAreas),
	member(Skill, Skills).

collect_skills(Names, Areas, Skills):-
    findall(Skill, 
            skills_of_such_themes_that(Names, Areas, Skill),
            SkillsList
    ),
    list_to_set(SkillsList, Skills).

Дадим пользователю выбрать навыки из имеющегося списка:

select_skills(Names, Areas, SelectedSkills):-
    collect_skills(Names, Areas, Skills),
    print_enumeration_list(Skills, 1),
    write('Введи имеющиеся компетенции [номера через запятую]: '),
    read(Numbers),
    nths_1(Skills, Numbers, SelectedSkills), !;
    write('Неправильный ввод, повторим...'), nl,
    select_skills(Names, Areas, SelectedSkills).

Дальше надо убрать из выдачи темы, для выполнения которых у студента не хватает компетенций…

3.4 Выбор темы

Для выбора тем, соответствующих всем выбранным критериям написан такой предикат:

matched_theme(Names, Areas, Skills, Theme):-
    theme(Theme, Name, _Complex, knowledge_areas(ThemeAreas), skills(ThemeSkills)),
    member(Name, Names),
    member(Area, Areas), member(Area, ThemeAreas),
	+ (
    	member(Skill, ThemeSkills),
        + member(Skill, Skills)
    ).

Итак, он перебирает все темы в базе данных и для каждой из них проверяет следующее:

  • имя преподавателя есть в списке Names;
  • среди областей знаний темы есть тема из выбранного пользователем списка (проверяется с помощью двух вызовов member — выбери такой Area в списке Areas, что такой же Area есть в списке ThemeAreas);
  • проверяет что НЕТ такого навыка в теме, что им НЕ владеет студент.

Для реализации последней части используется два отрицания. Так:
+ member(Skill, Skills)
проверяет что навыка Skill нет в списке Skills. Список Skills — навыки студента.

А тут:

+ (
    	member(Skill, ThemeSkills),
        + member(Skill, Skills)
    ).

первый оператор + стоит перед группой (почти лямбда-функцией) и завершится успешно если вся группа «провалится». Группа провалится если среди навыков темы найдется такой Skill, что его нет у студента. Таким образом весь приведенный в последнем листинге фрагмент завершится если у студента есть все необходимые навыки для выполнения темы.

Все описанные выше предикаты собраны (вызываются) в предикате выбора темы так:

selected_theme(Theme):-
    select_names(Names),
    (   
    	Names = [], write('Ничем не могу помочь');
    
    	select_areas(Names, Areas),
        (   
        	Areas = [], write('Ничем не могу помочь');
        	select_skills(Names, Areas, Skills),
            matched_theme(Names, Areas, Skills, Theme)
        )
    ).

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

Результат подбора темы:

На приведенном рисунке видно, что одна и та же тема выведена дважды. Чтобы убрать это — все названия помещаются в список, который преобразуется во множество:

run(Theme):-
    findall(T, selected_theme(T), Themes),
    (   
    	Themes = [], write('Нет подходящих тем');
    	list_to_set(Themes, ThemesSet),
        member(Theme, ThemesSet)
    ).

4 Итоги

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

Исходный код разработанной системы доступен в репозитории [10], пример ее использования:

Предлагаю посмотреть несколько похожих по структуре экспертных систем, написанных на других диалектах языка Prolog:

  • Система подбора танцев (для Visual Prolog 5.2) [11];
  • Система диагностики болезней (для Turbo Prolog) [12].

Список использованной литературы

  1. РОДИНА Р. В., СУЗДАЛЬЦЕВ В. А. Экспертная система прогнозирования медицинских диагнозов //Молодежь и системная модернизация страны. – 2018. – С. 137-141.
  2. Ле Н. В. Интеллектуальная медицинская система дифференциальной диагностики на основе экспертных систем // Вестник СГТУ. 2014. №1. URL: https://cyberleninka.ru/article/n/intellektualnaya-meditsinskaya-sistema-differentsialnoy-diagnostiki-na-osnove-ekspertnyh-sistem (дата обращения: 30.09.2021).
  3. Варламов О.О., Аладин Д.В. О СОЗДАНИИ МИВАРНЫХ СИСТЕМ КОНТРОЛЯ ЗА СОБЛЮДЕНИЕМ ПРАВИЛ ДОРОЖНОГО ДВИЖЕНИЯ НА ОСНОВЕ «РАЗУМАТОРОВ» И ЭКСПЕРТНЫХ СИСТЕМ. Радиопромышленность. 2018;28(2):25-35. https://doi.org/10.21778/2413-9599-2018-2-25-35
  4. Буравлев А. И., Чумичкин А. А. Формирование базы знаний экспертной системы оценки военной безопасности: методологический подход //Вооружение и экономика. – 2011. – №. 1. – С. 156-166.
  5. Akinator. URL: https://ru.akinator.com/game
  6. Введение в логическое программирование (Prolog) // Блог программиста. URL: https://pro-prof.com/archives/2362
  7. Как работать в SWI Prolog // Блог программиста. URL: https://pro-prof.com/forums/topic/work_in_swi-prolog
  8. Нотации модели сущность-связь (ER диаграммы) // Блог программиста. URL: https://pro-prof.com/archives/8126
  9. Темы ВКР // ВШЭ. URL: https://spb.hse.ru/data/2020/10/01/1369098873/Предлагаемые темы ВКР 2020-2021 учебный год.pdf
  10. Исходный код экспертной системы // Bitbucket. URL: https://bitbucket.org/rrrfer-admin/pro-prof.com-sources/branch/prolog_es
  11. Экспертная система Подбор танцев на Prolog // Блог программиста. URL: https://pro-prof.com/forums/topic/%d1%8d%d0%ba%d1%81%d0%bf%d0%b5%d1%80%d1%82%d0%bd%d0%b0%d1%8f-%d1%81%d0%b8%d1%81%d1%82%d0%b5%d0%bc%d0%b0-%d0%bf%d0%be%d0%b4%d0%b1%d0%be%d1%80-%d1%82%d0%b0%d0%bd%d1%86%d0%b5%d0%b2-%d0%bd%d0%b0-prolog
  12. Prolog — Экспертная система диагностики болезней // Блог программиста. URL: https://pro-prof.com/forums/topic/prolog-%d1%8d%d0%ba%d1%81%d0%bf%d0%b5%d1%80%d1%82%d0%bd%d0%b0%d1%8f-%d1%81%d0%b8%d1%81%d1%82%d0%b5%d0%bc%d0%b0-%d0%b4%d0%b8%d0%b0%d0%b3%d0%bd%d0%be%d1%81%d1%82%d0%b8%d0%ba%d0%b8-%d0%b1%d0%be%d0%bb

Время на прочтение
12 мин

Количество просмотров 13K

Вступление

Как то мне посчастливилось выбирать тему дипломной работы по специальности программная инженерия, и я выбрал написание экспертной системы, причем именно на языке Пролог. Хоть в промышленном программировании он почти не используется, он интересен в теоретическом плане позволяет самым быстрым способом прикоснуться к интеллектуальным системам(ИС). Также сам язык интересен в спортивном плане, так как заставляет мыслить в непривычной манере, отличной от мышления процедурного программирования и ООП, что является хорошой тренировкой для мозгов.

Использовалась реализация Prolog — Visual Prolog, с встроенными библиотеками GUI. Но если
вы хотите написать GUI на Qt/C++, то в документации есть инструкция, как импортировать программу в DLL, и скомпилировать ее вместе с C/C++ проектом. Отсюда следует, что совместить можно и с другими языками.

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

Описание назначения системы: есть набор параметров, которым должен соответствовать кардиосигнал(ЭКГ), по которым можно определить заболевание. Человек отвечает на вопросы системы(в режиме диалога), и система, выступая в качестве эксперта по кардиозаболеваниям, делает выводы о потенциальном заболевании человека.

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

Исчисление предикатов первого порядка и язык Пролог

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

Языковые конструкции Пролога можно представить в виде импликаций вида:

A1, A2, …, An <= B1, B2, …,Bm (n>=0, m>=0) (1)

где Ai и Bi – атомарные формулы Fi(t1, t2, …, tk) или отрицание Fi(t1, t2, …, tk), где tk – термы(индивидная константа, переменная или результат применения функции)

В Прологе все отношения записываются как факты и правила, где n=1 в формуле (1), для повышения эффективности логического вывода. Правилам соответствует формула, называемая формулой Хорна:

A<=B1, B2, …, Bm ,где m>0 (2)

Фактам соответствует формула (2) при m=0:

A<= (3)

Формулой, которую нужно доказать в процессе механизма вывода, является формула (1) при n=0, m>0, называется целью или запросом:

<= B1, B2, …Bm (4)

Из этих языковых конструкций состоит вся программа на Прологе.
Например, следующее знание, в виде предложения на естественном языке – “Сын Ани любит Машу” можно записать в виде факта:

любит(сын(аня), маша)

а предложение “Аня любит всех, кого любит Оля” в виде:

(любит(аня,X)<=любит(оля,X))

Или рассуждение “Каждый человек смертен. Конфуций — человек”:

(человек(конфуций)& (смертен(X)<=человек(X)) <= смертен(конфуций)

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

Таким образом, видно, что Пролог предоставляет гибкий, простой и интуитивно понятный язык для описания знаний.

Но дальше встает вопрос о выборе реализации этого языка, и было решено целесообразным разрабатывать ЭС на расширении языка Пролог – Visual Prolog.

Visual Prolog

Visual Prolog – диалект языка Пролог с объектно-ориентированным расширением вместе с интегрированной средой разработки. Эта среда обеспечивает поддержку создания графических интерфейсов и многих других библиотек. Язык Пролог довольно популярный для создания ЭС, с простым синтаксисом, схожим по смыслу с отношениями предметной области и фактами. Вообще сам интерпретатор языка Пролог можно рассматривать как ЭС в терминах логики предикатов первого порядка, в которой пользователь задает вопрос в виде цели, истинность которой нужно доказать. Это декларативный язык, в нем описывается, что нужно получить, вместо последовательного алгоритма, прекрасно подходит для описания знаний небольшой ЭС. По сравнению с альтернативными средами AMZI Prolog и SWI-Prolog, предоставляет очень эффективный интерфейс взаимодействия с другими языками как с помощью компоновки объектных файлов или с помощью динамической загрузки DLL-библиотек, как других языков, так и как самостоятельный DLL-модуль. Также Visual Prolog хорошо документирована, имеет множество примеров. Также существует мнение, что выбор языка реализации, способа представления знаний и метода формирования рассуждений вторичны, по сравнению со знаниями эксперта, и влияют лишь на механизм их успешного использования. Тем не менее, наличие литературы с использованием пролога как средства создания ЭС говорит о пригодности его использования, по крайней мере в небольших системах.

Проектирование ЭС

В литературе принято разделять ЭС на несколько основных, мало зависящих друг от друга компонентов: базу знаний, механизм вывода и интерфейс с пользователем.

Существует 2 типа организации экспертных систем: на правилах и на фактах.

Знания ЭС на правилах записывается в виде продукционных правил. Левая часть каждого правила содержит какаю-то альтернативу решения вопроса, а правые части (посылки) специфицируются другими правилами. Единственное исключение – когда правило проверяет наличие в базе данных информации, например ответа на вопрос. Алгоритм работы механизма вывода сводится к сопоставлению, затем при множестве вариантов выбирается нужный в соответствии с заложенным принципом разрешения конфликта и в конце применяется выбранное правило и все начинается сначала. Плюсы у такой организации в том, что очень легко добавлять правила в систему без влияния на другие правила, а дополнять и модифицировать легко, так как программисту нужно просто вставить нужное правило в подходящий блок правил. Также такая организация имеет ограничения, а именно придется организовывать неестественный алгоритм сохранения трассировки или использовать для нее переменную в правилах, но это нарушит удобство модификации правил, так как для каждого предиката правила придется организовывать сохранения трассировки. Также это нарушит читабельность программы и возможность модификации вообще механизма вывода, так как вместе с информацией о правилах будет содержаться учет обхода посредством действия механизма вывода. Дополнительно Пролог не позволяет сохранять правила в файл базы данных и читать правила из базы данных, что не позволило бы обновлять базу знаний во время работы программы. Листинг 1 приводит пример такой организации базы знаний.

Листинг 1

diag("SIRS"):-
diag2("SIRS").
diag("Sepsis"):-
diag("SIRS"),
have("Sepsis character").
diag("Hard sepsis"):-
diag("Sepsis"),
have("Hard sepsis character").
	
diag("Shock sepsis"):-
diag("Hard sepsis"),
have("Shock sepsis character").

diag("MOF"):-
diag("Hard sepsis"),
have("MOF sepsis character").
diag("MOF"):-
diag("Shock sepsis"),
have("MOF sepsis character").

Как видно из листинга 1, механизм вывода полностью должен управляться встроенным в Пролог стандартным механизмом вывода.

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

Также как и в организации на правилах здесь действует цикл: сопоставление – разрешение конфликта — переход к очередному правилу, но поскольку механизм вывода управляется опосредовано удобно в процессе выводить информацию о поиске решения и изменять этот формат без изменения базы знаний. Главное преимущество организации на логике в том, что можно сделать так, чтобы переменные, которые сопоставляются в процессе вывода, автоматически доступны в механизме вывода, и их можно было выводить вместе цепочкой последних правил, которые выведены к текущей цели. Но для этого нужно дополнительно предусмотреть механизм привидения типов для разных типов правил. Также база знаний хранится в виде фактов, поэтому ее можно сохранять или читать с файла на носителе. Систему на фактах тяжелее модифицировать и отлаживать чем на правилах, так как механизм вывода управляется значениями переменных и термами, например в виде номера правила, что вносит дополнительные возможности для ошибок.

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

Большая ЭС для медицинской диагностики в случае поступления больных в критическом состоянии, особенно если используется одновременно множеством врачей, тоже должна укладываться в строгие временные рамки.

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

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

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

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

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

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

Реализация

На языке Пролог правила реализованы в виде предиката rule. Каждое правило имеет свой номер и название, которое является гипотезой (заключением), которую нужно доказать. Условию правила соответствует неявное утверждение, которое полностью определяет истинность гипотезы.

Условие правила:

Colclusion(K)=C1(K) and (C2(K) or C3(K)) and C4(K)

C1(K) = Истинны все заключения правил с номерами, записанных в первом списке для K-ого правила

С2(K) = Истинно хотя бы одно правило из второго списка для K-ого правила
С3(K) = Истинно ровно N(K) заключений правил из второго списка для K-ого правила

C4(K) = Предикат для K-ого правила(предикат doc(K)), который описывает пользователь.
Если любой список пуст, значит соответствующее утверждение истинно.

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

Механизм вывода обеспечивает применение правил в нужной последовательности и сохраняет трассировку.

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

Описание предикатов

В общем, принцип кодирования знаний реализован на Прологе с помощью двух предикатов в следующем виде:

rule(K,”Текст заключения — имя правила”, Id, List1, List2, N)
doc(K)
K — номер правила
Id — Идентификатор данных для данного правила
List1 – первый список номеров правил
List2 – второй список номеров правил
N – число истинных заключений

Причем rule всегда записывается как факт, без переменных, и его истинность, как было сказано, определяет помимо списков, соответствующий предикат doc.

Вот несколько примеров записи знаний:

rule(93,«TASH — TASH-score 43% »,tashSc10,[47],[],0)
rule(33,«TASH – Избыток оснований – есть сумма баллов»,none,[],[29,30,31,32],1).

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

Таким образов все знания записываются с помощью этих двух предикатов.

В предикатах doc в основном вызываются функции пользовательского интерфейса, так как некоторые правила по смыслу неразрывно связаны с ответом пользователя или в них проводятся проверки на допустимые значения.

Например, предикаты doc для правил, истинность которых зависит от интервала, в котором находится суммарный балл, делают соответствующие проверки.

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

Предикат kolNeg(Количество) ищет количество отрицательных ответов в базе данных для данной группы признаков. Для этого он сначала ищет всевозможные признаки данной группы признаков, чтобы не перепутать их с другими группами, а затем считает их из множества в базе данных с помощью предиката kol_neg_list_in_db, работающего со списком признаков данной группы.

Примеры кода

Проект большой, поэтому приведу наиболее важные отрывки.

Листинг 2 — Список правил

rule(11,"Sepsises - SIRS призн. 1: t>38C или t<36С",sirsPr1,[],[],0).
rule(12,"Sepsises - частота сердечных сокращений>90",sirsPr2,[],[],0).
rule(13,"Sepsises - частота дыхания>20 или PaCO2<32mmHg",sirsPr3,[],[],0).

Листинг 3 — Список фактов

fact1(sirsPr1,"SIRS","SIRS призн. 1: t>38C или t<36С").
fact1(sirsPr2,"SIRS","частота сердечных сокращений>90").
fact1(sirsPr3,"SIRS","частота дыхания>20 или PaCO2<32mmHg").
fact1(sirsPr4,"SIRS","кол-во лейкоцитов>12.000/mm>3, <4.000/mm>3 или >10% band").

— Список логических следствий

tash_score(1,tashSc1,0,8,"Вероятность прогноза <5%").
tash_score(2,tashSc2,9,9,"Вероятность прогноза 6%").
tash_score(3,tashSc3,10,10,"Вероятность прогноза 8%").

Листинг 4 — Машина вывода

sizeList([],0):-!.
sizeList([_|T],Size):-
sizeList(T,SizeTail),
 Size=SizeTail+1.

append_der_list([],List,List).
append_der_list([H|L1],List2,[H|L3]):-
    append_der_list(L1,List2,L3).

any2(NeedSize,NeedSize,_,[],[],_):-!.
any2(_,_,[],[],[],_):-!.
any2(NeedSize,Size,[H|T1],[H|T2],[FirstDer|OtherDer],Why):-
 Nomer=[H],
 go(Nomer,UnderFirstDer,Why),
 rule(H,Text,_,_,_,_),
 FirstDer=tree(Text,unmarked,UnderFirstDer,0),%der(H,UnderFirstDer),
 Size1=Size+1,!,
 any2(NeedSize,Size1,T1,T2,OtherDer,Why).
any2(NeedSize,Size,[_|T1],List,OrDer,Why):-
 !,any2(NeedSize,Size,T1,List,OrDer,Why).

go([],[],_):-!.
go([H|T],[FirstDer|OtherDer],Why):-
 rule(H,Name,_,ListAnd,ListOr,KolOr),
 NewWhy=[Name|Why],
 go(ListAnd,UnderFirstDer,NewWhy),
 goOr(ListOr,KolOr,_,OrDer,NewWhy),				
 append_der_list(UnderFirstDer,OrDer,TwoDers),
 FirstDer=tree(Name,unmarked,TwoDers,0),		
 asserta(why_trace(NewWhy)),
 doc(H,NewWhy),
 go(T,OtherDer,Why).					
goOr([],_,[],[],_):-!.
goOr(ListOr,KolOr,ListYes,OrDer,Why):-			
 KolOr<>0,
 any2(KolOr,0,ListOr,ListYes,OrDer,Why),
 sizeList(ListYes,KolOr).
goOr(ListOr,0,ListYes,OrDer,Why):-			
 any2(100000,0,ListOr,ListYes,OrDer,Why),
 sizeList(ListYes,KolListYes),
 KolListYes>0.

Листинг 5 — вывод конечных следствий

tashQuestion(Id):-
 fact2(Id,_,Prisnak,_),
 pos(Prisnak),!.
tashQuestion(Id):-
 fact2(Id,_,Prisnak,_),
 neg(Prisnak),fail,!.

tashQuestion(Id):-
 fact2(Id,_,Prisnak,Ball),
 not(neg(Prisnak)),
 not(pos(Prisnak)),
 dialog_ynw(Prisnak,Ans),
 tash_in_data_base(Ans,Prisnak,Ball),!.


tash_in_data_base("y",Prisnak,Ball):-
 asserta(pos(Prisnak)),sum_tash(Sum1),Sum2=Sum1+Ball,asserta(sum_tash(Sum2)),!.
tash_in_data_base("n",Prisnak,_):-
 asserta(neg(Prisnak)),!,fail.
tash_in_data_base(_,_,_):-
 write("nTASH-not correct answer"),!,fail.

oneQuestion(Id):-		
 fact1(Id,_,Prisnak),
 pos(Prisnak),!.
oneQuestion(Id):-
 fact1(Id,_,Prisnak),
 not(neg(Prisnak)),
 question_sepsis(Prisnak),!.

Выводы

Надеюсь, эта статья поможет начинающим построить свою экспертную систему.

Создание экспертной системы в Wi!Mi 1.1

Wi!Mi – это инструмент для создания моделей знаний с неограниченным количеством связей, параметров и отношений, обладающий логическим выводом. Скачать данный конструктор можно с официального сайта.
К сожалению, адекватного туториала по данной программе я не нашел, не считая видеоурока на youtube. Поэтому решил написать его самостоятельно.

Теория

Перед тем, как описывать процесс решения данной задачи, проведу краткий экскурс по теории, на которой базируется данная программа. В основе Wi!Mi лежит миварный подход к описанию и формализации любых типов знаний. Этот подход основан на создании эволюционного многомерного динамического пространства унифицированного представления данных и правил. Иначе говоря, получается, что миварный подход обобщает общепринятые подходы — к примеру, такие как когнитивные карты и онтологии.

Создание модели

Для простоты я разбил все данные на входные и выходные, чтобы проще было ориентироваться.

Входные данные модели:

  • Интенсивность поступления оборудования lambda;
  • Интенсивность обслуживания Mu;
  • Оплата сотрудника S;
  • Убытки фирмы в случае простоя Ub;
  • Число сотрудников K.
  • Загрузка одного сотрудника Ro;
  • Клиентов в очереди Q;
  • Суммарные затраты фирмы Cp.

Вернемся к созданию модели. Создадим два класса «Входные данные модели» и «Выходные данные модели». Для этого нажимаем кнопку «Добавить объект» и выбираем его тип «Класс».

Задаем имя класса и пишем его описание. Потом необходимо добавить параметры в наш класс. Для этого нажимаем на «Добавить параметр», и в открывшимся окне вводим необходимые данные – имя и тип. Стоит вводить и описание, но это не обязательный параметр — просто он позволяет легче ориентироваться в модели и понимать, для чего нужен тот или иной объект.

После того, как мы создадим два класса и наполним их объектами, получим следующий вид:

Далее нам необходимо создать отношения между объектами. Для этого переходим на вкладку «Отношения», нажимаем «Добавить отношение» и выбираем тип «Формула».

Введем формулу загрузки одного сотрудника Ro = lambda / (Mu * K) и нажмем на кнопку «Анализировать формулу». Программа автоматически определит входные и выходные параметры. Аналогичные действия делаем с формулой количества клиентов в очереди
Q =( K * Math.pow(Ro,K+1)) / (1 — Math.pow(Ro,K)) и с суммарными затратами фирмы Cp = K * S + Ub * Q.

Теперь необходимо создать правила. Для этого нажимаем на «Добавить правило» и выбираем тип «Простое правило».

Далее выбираем отношение, с которым мы будем работать. Выбрав его, привязываем к каждому объекту соответствующий параметр. Стоит отметить, что отношение может быть представлено в виде иных значений (x=y+z) — главное, чтобы оно повторяло структуру формулы. Это бывает удобно, когда к отношению привязывается несколько правил. Так как модель небольшая, я для простоты использовал значения, идентичные параметрам.

После того как мы создали все отношения и привязали к ним правила, получаем следующий вид:

Создание модели закончено. Теперь нужно ее проверить. Для этого необходимо перейти во вкладку «Умный калькулятор». Раскроем root и наши два класса. Введем данные из нашего условия и отметим галочкой параметры, которые необходимо получить.

Программа произвела расчет и выдала алгоритм решения.

Также можно нажать на галочку «Показать граф решения». Будет визуализирован весь алгоритм в виде графа.

В целом инструмент очень простой — даже в реализации интерфейсов. Однако для человека, который не хочет или не умеет программировать (а если умеет программировать, то в Wi!Mi есть специальные «Сложные» отношения, которые позволяют писать их на JavaScript), или не хочет долго вникать, как работать с этой «штукой» — отличный вариант. Хотел сказать еще, что все модели сохраняются в .XML формате.

По сути, остается написать свой интерфейс, распарсить эти данные — и мы получим свою полноценную программку. Лично мне было удобно использовать данный конструктор для быстрого построения логики.

Экспертные системы (Разработка)

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

Содержание

Требования по созданию

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

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

Оправданность использования

Бывают случаи, когда использование экспертной системы возможно, но не оправдано. А оправданным использование ЭС может считаться при наличии следующих факторов:

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

Соответствие приложения методам ЭС

Созданное приложение соответствует методам ЭС, если решаемая задача обладает совокупностью некоторых характеристик, а именно:

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

Концепция быстрого прототипа

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

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

Этапы разработки

В ходе многолетних работ по созданию ЭС сложилась определенная технология их разработки, включающая шесть последовательных этапов:

  • идентификация
  • концептуализация
  • формализация
  • выполнение
  • тестирование
  • опытная эксплуатация

На этапе идентификации определяют задачи, подлежащие решению, выявляются цели разработки, определяются эксперты и типы пользователей.

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

Формализация подразумевает выбор инструментов и способов представления всех видов знаний. На этом этапе формализуются основные понятия, определяются способы интерпретации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решений, средств представления знаний и управления ими.

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

Разработка экспертных систем на Prolog

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

Экспертные системы создаются для самых различных предметных областей, например:

  • созданы системы медицинской диагностики, которые по набору симптомов назначают анализы, по результатам которых ставится диагноз и определяется курс лечения [1, 2];
  • экспертные системы могут следить за соблюдением правил дорожного движения [3] и даже оценивать военную безопасность государства [4].

Так или иначе, в процессе использования в систему попадают факты пользователя, чаще всего это происходит в форме диалога, при этом система формирует вопросы исходя их данных в базе и данных ранее ответов. Например, система Akinator [5], угыдывающая задуманного пользователем персонажа мультфильма, может спросить «является ли ваш персонаж человеком?».

Важно, что все экспертные системы, вне зависимости от предметной области, имеют схожую структуру — на самом деле, какая разница «угадывает» система диагноз по симптомам или персонажа мультфильма по его параметрам? По этой причине для разработки часто используются специальные инструменты создания типовых систем или заготовки систем, в которые эксперту нужно лишь внести данные и правила, однако, в этой статье мы посмотрим как сделать простейшую экспертную систему на языке Prolog.

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

Важно понимать, что база данных содержит факты, а база знаний — правила вывода решений на основе фактов и введенных пользователем данных. Правила представляют собой, по сути, исходный код программы, — именно поэтому для разработки экспертных систем удобно использовать языки типа SWI Prolog, ведь они позволяют добавлять новые правила в программу прямо во время ее исполнения. Чтобы понять как разработанная система работает и как запустить приведенный код стоит пройти по ссылкам [6, 7].

Ниже приведен пример разработки сильно упрощенной экспертной системы, помогающей студенту выбрать тему дипломной работы.

1 Обзор предметной области

Так как в основе любой экспертной системы находится база данных, то разработка начинается с анализа предметной области. Тут надо понять какие критерии стоит учитывать при подборе темы дипломной работы. Темы выпускных работ обычно формируют преподаватели исходя из своих интересов. Студент выбирает тему бакалаврской работы из набора имеющихся с учетом:

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

Например, если студент при обучении у преподавателя Пупкина с трудом получил тройку — маловероятно он пойдет к нему на дипломирование. Если студент ничего не знает в области блокчейна, но ему хотелось бы развиваться в этой сфере — возможно он выберет соответствующую тему. Тема работы «Разработка клиент-серверного приложения для игры в покер» может быть интересна студенту, но он не возьмет ее если руководитель требует писать сервер на Erlang, а студент не любит функциональное программирование.

Таким образом, предметная область задачи состоит из сущностей:

  • руководитель ВКР;
  • область интересов;
  • тема ВКР;
  • технология выполнения;
  • студент.

Модель предметной области с использованием нотации диаграммы классов UML [8] приведена на рисунке:

2 Наполнение базы данных

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

Для наполнения базы были найдены темы ВКР, по первому запросу поисковая система выдала информацию о темах Высшей школы экономики [9]. Однако, опубликованный список тем содержит лишь информацию о названии и руководителе, остальная информация была сформирована мной и не является точной — данные в базу данных экспертной системы должен вносить эксперт (руководитель ВКР).

В результате создана такая база данных:

На этом этапе можно лишь перебрать все записи базы и вывести их запросом:
?- theme(Theme, Name, Complex, knowledge_areas(Areas), skills(Skills)).

3 Алгоритмы работы экспертной системы (формирование базы знаний)

3.1 Выбор руководителей

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

Собрать всех преподавателей можно так:

Встроенный предикат findall находит все решения предиката, переданного вторым аргументом и формирует из решений список. Однако, имена в таком списке могут повторяться — если у одного преподавателя было несколько тем то интерпретатор найдет его имя несколько раз. Поэтому следом вызывается предикат list_to_set , который убирает из списка повторы.

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

Результат выполнения запроса:

Теперь можно запросить у пользователя список имен и выбрать соответствующих номерам преподавателей:

Тут предикат select_names после вывода списка преподавателей запрашивает список номеров и передает их в предикат nths_1 , который выбирает элементы списка соответствующие списку номеров (нумерация начинается с единицы). если введены неверные данные — то выведется сообщение об ошибке и процесс повторится (рекурсивно):

3.2 Выбор области знаний

Теперь, когда выбраны предполагаемые — можно собрать список областей знаний в которых у них есть темы и выдать их в виде такого же списка.
Сначала можно получить список всех областей в которых есть темы у выбранных руководителей:

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

Теперь можно собрать все эти области в список и убрать из него повторы:

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

В настоящий момент можно написать такую цель:

?- select_names(Names), select_areas(Names, Areas).

с ее помощью мы сначала просим выбрать имена, а затем области. Результат ее выполнения:

3.3 Указание компетенций студента

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

Дадим пользователю выбрать навыки из имеющегося списка:

Дальше надо убрать из выдачи темы, для выполнения которых у студента не хватает компетенций…

3.4 Выбор темы

Для выбора тем, соответствующих всем выбранным критериям написан такой предикат:

Итак, он перебирает все темы в базе данных и для каждой из них проверяет следующее:

  • имя преподавателя есть в списке Names ;
  • среди областей знаний темы есть тема из выбранного пользователем списка (проверяется с помощью двух вызовов member — выбери такой Area в списке Areas , что такой же Area есть в списке ThemeAreas );
  • проверяет что НЕТ такого навыка в теме, что им НЕ владеет студент.

Для реализации последней части используется два отрицания. Так:
+ member(Skill, Skills)
проверяет что навыка Skill нет в списке Skills. Список Skills — навыки студента.

первый оператор + стоит перед группой (почти лямбда-функцией) и завершится успешно если вся группа «провалится». Группа провалится если среди навыков темы найдется такой Skill, что его нет у студента. Таким образом весь приведенный в последнем листинге фрагмент завершится если у студента есть все необходимые навыки для выполнения темы.

Все описанные выше предикаты собраны (вызываются) в предикате выбора темы так:

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

Результат подбора темы:

На приведенном рисунке видно, что одна и та же тема выведена дважды. Чтобы убрать это — все названия помещаются в список, который преобразуется во множество:

4 Итоги

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

Исходный код разработанной системы доступен в репозитории [10], пример ее использования:

Предлагаю посмотреть несколько похожих по структуре экспертных систем, написанных на других диалектах языка Prolog:

Введение

Настоящая
глава посвящена реализованным
средствами Тур-

бо-Пролога
экспертным системам — наиболее быстро
развивающейся

и
наиболее плодотворной области применения
Турбо-Пролога. Очень

важно
понимать , как работают экспертные
системы, так как они

могут
использоваться, фактически, в любой
области.

В
первом разделе этой главы описываются
принципы

построения
и организации экспертных систем в
терминах их

компонент:
базы знаний, механизма вывода и
системы

пользовательского
интерфейса. Здесь также рассматриваются

основные
характеристики и работа системы,
использующей

правила,
и системы, основанной на логике.

Во
втором разделе на примере системы для
выбора породы со-

баки
показано, как проектировать и реализовать
две экспертные

системы.
Одна базируется на правилах, а вторая
— на логике . В

третьем
разделе описывается экспертная система,
организованная

так,
что база знаний может хранится на диске
как файл базы дан-

ных.
Эта экспертная система предназначена
для постановки меди-

цинского
диагноза.

10.1
Принципы построения экспертных систем

Экспертная
система — это компьютерная программа,
которая в

некоторой
области проявляет степень познаний
равнозначную сте-

пени
познания человека-эксперта. Обычно эта
область строго ог-

раничена.
Однако, количество приложений огромно.
Сюда входят

понимание
речи, анализ изображений, прогноз
погоды, оценка бу-

дущего
урожая, медицинская диагностика,
разработка интегральных

схем,
финансирование, управление воздушным
движением, управле-

ние
боем и т.д.

Несколько
экспертных систем уже считаются
классическими.

Примером
могут служить разработанные в Стендфордском
универси-

тете
такие системы как DENDRAL, определяющая
молекулярную

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

масс-спектрометрии
и MYCIN, определяющая наличие инфекции у
па-

циента
, идентифицирующая микроорганизмы,
выбирающая подходящее

лекарство
и назначающая эффективный режим приема
лекарства. А

так
же разработанная в миланском университете
Карнеги эксперт-

ная
система XCON, определяющая конфигурацию
компьютерных систем

VAX
фирмы DEC, проверяющая спецификацию
частей и правильность

соединения
в требуемую компьютерную систему.

10.2
Структура экспертных систем

Чтобы
проводить эспертизу, компьютерная
программа должна

быть
способна решать задачи посредством
логического вывода и

получать
при этом достаточно надежные результаты.
Программа

должна
иметь доступ к системе фактов, называемой
базой знаний.

Программа
также должна во время консультации
выводить

заключения
из информации, имеющейся в базе знаний.
Некоторые

экспертные
системы могут также использовать новую
информацию,

добавляемую
во время консультации. Экспертную
систему, таким

образом,
можно представлять состоящей из трех
частей:

1.
База знаний (БЗ).

2.
Механизм вывода (МВ).

3.
Система пользовательского интерфейса
(СПИ).

Взаимное
расположение этих трех частей показано
на рис. 10.1.

Рис.10.1
Общая структура экспертной системы.

База
знаний — центральная часть экспертной
системы. Она

содержит
правила, описывающие отношения или
явления, методы и

знания
для решения задач из области применения
системы. Можно

представлять
базу знаний состоящей из фактических
знаний и зна-

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

«Джон
Ф. Кеннеди был 35-м президентом
Соединенных Штатов» —

пример
фактического знания. «Если у вас болит
голова,то примите

две
таблетки цитрамона» — пример знания
для вывода. Сама база

знаний
обычно располагается на диске или другом
носителе.

Механизм
вывода содержит принципы и правила
работы.

Механизм
вывода «знает», как использовать
базу знаний так,

чтобы
можно было получать разумно согласующиеся
заключения

(выводы)
из информации, находящейся в ней.

Когда
экспертной системе задается вопрос,
механизм вывода

выбирает
способ применения правил базы знаний
для решения зада-

чи,
поставленной в вопросе. Фактически,
механизм вывода запус-

кает
экспертную систему в работу, определяя
какие правила нужно

вызвать
и организуя к ним доступ в базу знаний.
Механизм вывода

выполняет
правила, определяет когда найдено
приемлемое решение

и
передает результаты программе интерфейса
с пользователем.

Когда
вопрос должен быть предварительно
обработан, то доступ к

базе
знаний осуществляется через интерфейс
с пользователем. Ин-

терфейс
— это часть экспертной системы, которая
взаимодействует

с
пользователем.

Как
правило, пользователи мало знают об
организации базы

знаний,
поэтому интерфейс может помочь им
работать с экспертной

системой
даже, если они не знают, как она
организована. Интер-

фейс
может также объяснить пользователю ,
каким образом экспер-

тная
система выводит результат.

Система
интерфейса с пользователем принимает
информацию от

пользователя
и передает ему информацию. Просто
говоря, система

интерфейса
должна убедиться, что, после того как
пользователь

описал
задачу, вся необходимая информация
получена. Интерфейс,

основываясь
на виде и природе информации, введенной
пользовате-

лем,
передает необходимую информацию
механизму вывода. Когда

механизм
вывода возвращает знания, выведенные
из базы знаний,

интерфейс
передает их обратно пользователю в
удобной форме. Ин-

терфейс
с пользователем и механизм вывода могут
рассматриваться

как
«приложение» к базе знаний. Они
вместе составляют оболочку

экспертной
системы как показано на рис. 10.1. Для
базы знаний,

которая
содержит обширную и разнообразную
информацию, могут

быть
разработаны и реализованы несколько
разных оболочек. Хоро-

шо
разработанные оболочки экспертных
систем обычно содержат ме-

ханизм
для добавления и обновления информации
в базе знаний.

Как
видем , экспертная система состоит из
трех основных

частей.
Взаимосвязь между частями может быть
сложной, зависящей

от
природы и организации знаний, а также
от методов и целей вы-

вода.
Следующие разделы описывают эти аспекты
экспертных сис-

тем.
Сначала описывается представление
знаний вместе с некото-

рыми
простыми примерами. Это описание
применимо как к системам,

основанным
на правилах,так и к системам, базирующимся
на логи-

ке.
Затем рассматриваются методы вывода.
Далее следует описание

систем
интерфейса с пользователем вместе с
примерами обработки

ввода
и вывода. Затем предполагается, что
читатель готов к рас-

смотрению
двух конкретных методик проектирования
экспертных

систем:
систем, базирующихся на правилах, и
систем, базирующих-

ся
на логике.

10.3
Представление знаний

Представление
знаний — это множество соглашений по
син-

таксису
и семантике, согласно которым описываются
объекты. Хо-

рошее
правило при проектировании представления
знаний — это

организация
знаний в такой форме, которая позволяет
легко

осуществлять
доступ с помощью естественных и простых
механиз-

мов.
«Чем проще, тем лучше» — правило,
которое нужно помнить,

при
работе с представлением знаний.

Экспертные
системы часто создаются «инженером
по знаниям»

(или
проектировщиками экспертных систем),
которые работают с

человеком-экспертом,
чтобы закодировать знания эксперта в
базе

знаний.
Проектировщик экспертной системы должен
иметь возмож-

ность
манипулировать представленными знаниями
и работать с че-

ловеком
экспертом. Эти работы составляют
развивающуюся область

инженерии
знаний.

В
экспертных системах на Турбо-Прологе,
описываемых в этой

главе,
знания будут всегда представлены
одним из двух спосо-

бов.Первый
способ — это классификация и помещение
фактов и чи-

сел
(фрагментов фактического знания) в
правила Турбо-Пролога.

Это
представление подходит для использования
в экспертных сис-

темах,
базирующихся на правилах. Другой способ
— это организа-

ция
фактов и числовой информации в
утверждениях, которые обра-

зуют
базу знаний на утверждениях. Представление
знаний в утвер-

ждениях
подходит для использования в экспертных
системах, бази-

рующихся
на логике.

Существуют
и другие системы представления знаний.
К ним

относятся
система на фреймах и разработанная
недавно система на

моделях.
Система на фреймах использует
представление знаний,

основанное
на логических группах атрибутов
объекта.Для хранения

и
обработки логические группы описываются
во фреймах. Для сис-

тем
, базирующихся на моделях, проект и
структура системы осно-

ваны
на знании структуры и поведения
устройства, которое явля-

ется
предметом исследования. Пример — это
экспертная система,

моделирующая
автомобиль. Детальное обсуждение таких
систем вы-

ходит
за рамками этой книги.

В
настоящее время системы, базирующиеся
на правилах, наи-

более
популярны. Они разработаны и используются
в широком диа-

пазоне
приложений от науки и инженерной работы
до бизнеса. Поэ-

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

ву.
Здесь же рассматриваются экспертные
системы , базирующиеся

на
логике, так как они естественным
образом укладываются в

структуру
языка Турбо-Пролог.

Конструирование
экспертной системы, можно начать с
табли-

цы,
состоящей из двух колонок. Одна колонка
содержит названия

стран,
а другая — названия соответствующих
столиц. Эта таблица

составляет
маленькую базу знаний:

Страна
Столица

США
Вашингтон (Округ Колумбия)

Англия
Лондон

Испания
Мадрид

Конечно,
подобная таблица используется только
для планиро-

вания
базы знаний; в экспертных системах
способы представления

знаний
более соответствуют языку программирования,
используемо-

му
для разработки системы. Утверждения
Турбо-Пролога , содержа-

щие
эти знания можно записать таким образом:

capital(«Washington
DC»,»USA»).

capital(«London»,»England»).

capital(«Madrid»,»Spain»).

Подобные
утверждения составляют базис экспертной
системы,

основанной
на логике.

Эти
же знания можно представить в форме
правил «если-то».

Правила
для предыдущих трех утверждений выглядят
так:

capital_is(«Washington
DC») :-

country(is,»USA»),!.

capital_is(«London»)
:-

country(is,»England»),!.

capital_is(«Madrid»)
:-

country(is,»Spain»),!.

Эти
правила могут служить основой экспертной
системы на

правилах.
Как видим представление знаний в
экспертной системе

то
же, что и представление фактов и правил,
которое ранее ис-

пользовалось
в этой книге.

Приведенные
примеры, конечно, просты , однако, они
очень

полезны
для демонстрации принципов построения
экспертных систем

на
Турбо-Прологе. В следующем разделе будет
показано, как можно

использовать
подобное представление знаний на
практике.

10.4
Методы вывода

Метод
вывода — это систематический способ
для доказатель-

ства
того, что из множества предположений
следует некоторое

заключение.
Этот систематический метод закодирован
в правилах

вывода,
которые специфицируют принятую логику
получения заклю-

чения.
Вывод осуществляется посредством
поиска и сопоставления

по
образцу. Другие языки требуют написания
собственных правил

поиска
и сопоставления по образцу. В Турбо-Прологе
эти задачи

выполняются
с помощью внутренних программ унификации,
поэтому в

данном
случае требуется только написать
необходимые специфика-

цию.
Как в системах, базирующихся на правилах,
так и в систе-

мах,
базирующихся на логике, пользователь
получает ответы на

свои
запросы в соответствии с логикой,
заложенной в системе. В

первом
случае запросы пользователя
трансформируются в форму,

сопоставимую
с формой правил базы знаний. Механизм
вывода ини-

циализирует
процесс сопоставления, начиная с
«верхнего» прави-

ла.
Обращение к правилу называется «вызовом».
Вызов соответст-

вующих
правил в процессе сопоставления
продолжается до тех пор,

пока
не произошло сопоставление или не
исчерпана вся база зна-

ний,
а сопоставление не найдено. Во втором
случае трансформиро-

ванные
запросы являются значениями, которые
сопоставляются со

значениями,
находящимися в базе знаний.

Если
механизм вывода обнаруживает, что можно
вызвать более

одного
правила, то необходимо осуществить
определенный выбор.

При
этом приоритет отдается обычно либо
правилам, которые более

специфицированы,
либо правилам, которые учитывают больше
теку-

щих
данных. Этот процесс называется
разрешением конфликта.

Чтобы
продемонстрировать процесс вывода,
предположим, что

нужно
выяснить является ли Мадрид столицей
Испании. Для вопро-

са
(В) «Мадрид столица Испании?»
механизм вывода в системе,

базирующейся
на логике, образует цель:

capital(«Madrid»,»Spain»).

Если
сопоставимый факт найден в системе,то
она выдает от-

вет
(О), т.е. «верно».

Система
на правилах использует форму в виде
правила для

поиска
ответа (О)на вопрос (В): «Если в базе
знаний есть прави-

ло
вида «Если <условие> тогда В «,
то ищи <условие>, чтобы по-

лучить
ответ О». Вопрос представляется в
виде:

capital_is(«Madrid»):-

country(is,»Spain»),
!.

Это
пример обратного вывода. Заключение из
правила специ-

фицировано
и механизм вывода ищет в базе знаний
все условия,

которые
приводят к этому заключению.

Экспертные
системы на Турбо-Прологе , рассматриваемые
в

этой
главе, объединяют методы вывода,
базирующиеся на логике,

и
методы, базирующиеся на правилах.

10.5
Система пользовательского интерфейса

Система
пользовательского интерфейса обеспечивает
взаимо-

действие
между экспертной системой и пользователем.
Это взаи-

модействие
обычно включает несколько функций:

1.
Обработка данных, полученных с клавиатуры,
и высвечива-

ние
вводимых и выводимых данных на экране.

2.
Поддержка диалога между пользователем
и системой.

3.
Распознавание ситуации непонимания
между пользователем

и
системой.

4.
Обеспечение «дружественности»
по отношению к

пользователю.

Система
интерфейса с пользователем должна
эффективно

обрабатывать
ввод и вывод. Для этого необходимо
обрабатывать

вводимые
и выводимые данные быстро, в ясной и
выразительной

форме.
Необходимо также включить возможность
работы с

дополнительными
средствами такими, как печатающие
устройства,

магнитные
диски и дополнительные файлы данных.

Кроме
того, система интерфейса должна
поддерживать

соответствующий
диалог между пользователем и системой.
Диалог


это общая форма консультации с
экспертной системой.

Консультация
должна завершаться ясным утверждением,
выдаваемым

системой,
и объяснением последовательности
вывода, приведшей к

этому
утверждению.

Система
пользовательского интерфейса должна
также распоз-

навать
непонимание,между пользователем и
системой, возникшее

либо
из-за ошибки, либо на принципиальной
основе . Система долж-

на
реагировать соответствующим образом
на эту ситуацию. Напри-

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

1,
когда ожидается «да» или «нет»,
или когда пользователь зада-

ет
бессмысленный вопрос.

Способность
экспертной системы моделировать человека
экс-

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

включения
новых знаний или новых способов решения
задачи. Сис-

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

работы
системы и ее развитии, если такое развитие
предусмотре-

но
в системе.

Наконец,
система пользовательского интерфейса
должна быть

«дружелюбной»
к пользователю. Например, последовательность
ме-

ню,
показывающая задачи, которые пользователь
может выбрать,

является
необходимой чертой экспертной системы.
Пользователь

также
должен иметь возможность взаимодействовать
с экспертной

системой
естественным образом. В идеале
пользователь должен

иметь
возможность использовать естественный
язык. Напечатать

«Что
рекомендуется при аллергической
головной боли?» легче,чем

ввести:

medication(Prescription,»allergy
headache»).

Хотя
обработка естественного языка очень
нужна в эксперт-

ных
системах, такую возможность трудно
спроектировать и реали-

зовать.
Экспертные системы на Турбо-Прологе,
представленные в

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

языка
рассматривается в гл. 11. Позже вы можете
ввести интер-

фейс
на естественном языке в вашу систему.

10.6
Экспертная система на правилах

Во
всех экспертных системах существует
зависимость между

входным
потоком данных и данными в базе знаний.
Во время кон-

сультации
входные данные сопоставляются с данными
в базе зна-

ний.
Результатом сопоставления является
отрицательный или ут-

вердительный
ответ. В системе, базирующейся на
правилах утвер-

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

правил.
Эти продукционные правила определяются
входными данны-

ми.

Таким
образом, экспертная система, базирующаяся
на прави-

лах
(на Турбо-Прологе) содержит множество
правил, которые вызы-

ваются
посредством входных данных в момент
сопоставления. Экс-

пертная
система также содержит интерпретатор
в механизме выво-

да,
который выбирает и активизирует
различные модули системы.

Работу
этого интерпретатора можно описать
последовательностью

трех
шагов:

1.
Интерпретатор сопоставляет образец
правила с

элементами
данных в базе знаний.

2.
Если можно вызвать более одного правила,то
интерпретатор

использует
механизм разрешения конфликта для
выбора правила.

3.
Интерпретатор применяет выбранное
правила , чтобы най-

ти
ответ на вопрос.

Этот
трехшаговый процесс интерпретации
является цикличес-

ким
и называется циклом «распознавание-действие».

В
системе, базирующейся на правилах,
количество продукци-

онных
правил определяет размер базы знаний.
Некоторые наиболее

сложные
системы имеют базы знаний с более чем
5000 продукцион-

ных
правил. Вы можете начать с небольшого
количества правил и

добавлять
их в базу знаний по мере расширения
экспертной систе-

мы.

Может
быть более важным, чем размеры базы
знаний, является

структура
самих продукционных правил. Проектировщик
базы знаний

отвечает
за построение совместимых правил. В
настоящее время не

существует
строгих принципов, которыми надо
руководствоваться

при
проектировании структуры правил. По
этому поводу лишь ве-

дутся
дискуссии. Однако за последние несколько
лет некоторые

рекомендации
стали очевидными и их нужно выполнять
как можно

точнее:

1.
Использовать минимально достаточное
множество условий

при
определении продукционного правила.

2.
Избегать противоречащих продукционных
правил.

3.
Конструировать правила, опираясь на
структуру присущую

предметной
области.

Первая
экспертная система на Турбо-Прологе в
этой главе


система для идентификации породы собак.
Она помогает потен-

циальному
хозяину выбрать породу собаки в
соответствии с опре-

деленными
критериями.

Предположим,
что пользователь сообщил множество

характеристик
собаки в ответ на вопросы экспертной
системы.

Интерпретатор
работает в цикле распознавание-действие
. Если

характеристики
сопоставимы с характеристиками породы
собаки,

составляющими
часть базы знаний, тогда вызывается

соответствующее
продукционное правило и в результате

идентифицируется
порода. Затем результат сообщается

пользователю.
Аналогично, если порода не идентифицирована,
это

тоже
сообщается пользователю.

Теперь
рассмотрим две характеристики породы
собак , кото-

рые
содержаться в базе знаний. Гончая
имеет короткую шерсть,

рост
меньше 22 дюймов, длинные уши и хороший
характер. Датский

дог
имеет короткую шерсть, свисающий хвост,
длинные уши, хоро-

ший
характер и вес более 100 фунтов.

Вы
видите из этого описания , что обе породы
имеют корот-

кую
шерсть, длинные уши и хороший характер.
Рост гончей меньше

22
дюймов в то время , как ничего не сказано
о росте дога. Дог

имеет
свисающий хвост и вес более 100 фунтов
— характеристики

отсутствующие
для гончей. Описание двух собак в
терминах ука-

занных
характеристик достаточно, чтобы
различить эти две поро-

ды,
и даже отличить их от любой другой породы
в базе знаний.

Следующие
продукционные правила могут быть
составлены по

указанным
характеристикам:

dog_is(«Beagle»):-

it_is(«short-haired
dog»),

positive(has,»height
under 22 inches»),

positive(has,»long
ears»),

positive(has,»good
natured personality»), !.

dog_is(«Great
Dane»):-

it_is(«short-haired
dog»),

positive(has,»low-set
tail»),

positive(has,»longer
ears»),

positive(has,»good
natured personality»),

positive(has,»weight
over 100 lb»), !.

В
предыдущем правиле длина шерсти может
быть представлена

с
помощью предиката positive в виде:

positive(has,»short-hair»).

Но
использование предиката it_is позволяет
ограничить

«пространство
поиска» (количество данных, проверяемых
при поис-

ке
решения) одним поддеревом древовидной
структуры , содержащей

информацию
о разных породах собак (см. рис. 10.2).
Экспертная

система,
базирующаяся на правилах, позволяет
проектировщику

(программисту)
строить правила, которые естественным
образом

объединяют
в группы связанные фрагменты знаний.
Каждое продук-

ционное
правило может быть независимым от
других. Эта независи-

мость
делает базу продукционных правил
семантически модульной,

т.е.
группы информации не влияют друг на
друга. Более того, мо-

дульность
базы правил позволяет развивать базу
знаний, увеличи-

вая
ее. Эта особенность крайне необходима
во многих приложени-

ях.
Турбо-Пролог позволяет легко ее
реализовать в экспертной

системе.

10.7
Экспертные системы, базирующиеся на
логике

В
экспертных системах, базирующихся на
логике, база знаний

состоит
из утверждений в виде предложений
логики предикатов.

Такие
предложения могут группироваться,
образуя базу данных

Турбо-Пролога.
Правила могут либо описывать данные
либо управ-

лять
процессом внутренней унификации
Турбо-Пролога.

Так
же как и в системе на правилах экспертная
система, ба-

зирующаяся
на логике, имеет множество правил,
которые могут вы-

зываться
с помощью данных из входного потока.
Система имеет

также
интерпретатор, который может выбирать
и активизировать

модули,
включаемые в работу системы.

Интерпретатор
выполняет различные функции внутри
системы

на
основе следующей схемы:

1.
Система имеет предложения в базе
знаний, которые уп-

равляют
поиском и сопоставлением. Интерпретатор
сопоставляет

эти
предложения с элементами данных в базе
данных.

2.
Если может быть вызвано более одного
правила , то сис-

тема
использует возможности Турбо-Пролога
для разрешения

конфликта.
Следовательно пользователю/программисту
не нужно

рассматривать
потенциально возможные конфликты.

3.
Система получает результаты
унификационного процесса

автоматически,
поэтому они могут направляться на
нужное уст-

ройство
вывода информации.

Так
же как и в системе, базирующейся на
правилах, данный

циклический
процесс является процессом
распознавание-действие.

Красота
и большие возможности системы,
основанной на логике,

заключаются
в том, что она отражает структуру самого
Турбо-Про-

лога.
Этим объясняется тот факт, что она очень
эффективна в ра-

боте.

Наиболее
важным аспектом для базы знаний в
системе, осно-

ванной
на логике, является проектирование
базы знаний, ее ут-

верждений
и их структуры. База знаний должна иметь
недвусмыс-

ленную
логическую организацию, и она должна
содержать минимум

избыточной
информации. Так же как и в системе,
базирующейся на

правилах,
минимально достаточное количество
данных образуют на-

иболее
эффективную систему. Утверждения базы
знаний для гончей

и
дога выглядят так:

rule(1,»dog»,»Beagle»,[1,2,3,4]).

rule(2,»dog»,»Great
Dane»,[1,5,3,4,6]).

cond(1,»short-haired»).

cond(2,»height
under 22 inches»).

cond(3,»longer
ears»).

cond(4,»good
natured personality»).

cond(5,»low-set
tail»).

cond(6,»weight
over 100 lb»).

Заметьте,
что в каждом предложении типа rule первый
аргу-

мент
— номер правила, второй аргумент — тип
объекта («собака»)

и
третий аргумент — порода собаки. В нашем
случае это гончая

или
дог. Список целых чисел задает номера
условий из предложе-

ний
типа cond ( условие ). Предложения типа
cond содержат все

характеристики
для любой породы, представленной в базе
знаний.

Списки
номеров условий служат для хранения
множества фак-

тов,
согласно которым выбираются предложения
типа rule. Интерп-

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

ет
эти номера условий, чтобы делать
соответствующий выбор.

Добавление
и обновление предложений базы знаний
являются

простыми
опреациями. Для повторения этой
методики вы можете

вернуться
к материалу гл. 9 о предикатах retract и
assert. Экс-

пертные
системы, базирующиеся на логике, легко
проектировать,

ширения
базы знаний программа не требует
модификации. Расшире-

ние
прежде всего заключается в постепенном
добавлении новых ут-

верждений.

10.8
Главное в разработке экспертных систем

Разработка
экспертной системы требует большой
организован-

ности
и внимания к мелочам. Это требование
меняется, естествен-

но,
с изменением размера и сложности
разрабатываемой экспертной

системы.
Если экспертная система, которую Вы
хотите сделать, в

конечном
счете может содержать сотни продукционных
правил, то

трудно
определить эффект от добавления
дополнительных правил. В

Турбо-Прологе
продукционные правила помещаются в
программу,и,

следовательно,
размеры програмы увеличиваются по мере
добавле-

ния
правил. Размеры памяти в конце концов
ограничивают число

правил.
В этом случае использование системы на
правилах стано-

вится
проблематичным. В то же время, в системе,
базирующейся на

логике,
где база знаний находится в файле на
диске, ограничения

на
размеры базы знаний не накладываются.
Поэтому система, осно-

ванная
на логике, предпочтительнее в этом
случае.

Если
же ваша экспертная система будет
содержать не более

нескольких
сотен правил, использование системы,
базирующейся на

правилах
более предподчительно. В силу того, что
продукционные

правила
почти не зависят друг от друга, создание
и тестирование

такой
экспертной системы проще. Просто
осуществляется и измене-

ние
правил с целью изучить эффект, вызванный
таким изменением.

В
системах, базирующихся на логике,
изменение параметров внутри

базы
знаний должно производится с большей
осторожностью, так

как
изменения менее заметны , а результат
может быть разруши-

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

Если
быстрота является главным требованием
к разрабатывае-

мой
экспертной системе,то можно выбрать
либо логическую систе-

му,
полностью находящуюся в оперативной
памяти, либо систему,

нако,
экспертная система должна содержать
большую базу знаний,

то
у разработчика имеется единственный
вариант — логическая

система,
находящаяся на диске.

После
того как выбор между системой, базирующейся
на пра-

вилах
и системой базирующейся на логике,
сделан и тщательно

изучены
данные, которые войдут в базу знаний,
можно начать про-

ектировать
базу знаний , содержащую специфицированные
функции и

имеющую
необходимые свойства.

Следующим
шагом является разработка диаграмм
потоков дан-

ных
и структурной схемы экспертной системы.
Это поможет сконст-

руировать
модули, составляющие систему. Затем
можно приступить

к
написанию программы, исходя из
диаграммы потоков данных и

структурной
схемы. После завершения программирования
необходимо

проверить
результаты с помощью человека-эксперта,
участвующего

в
проекте.

Программа
для выбора породы собаки, рассматриваемая
в сле-

дующем
разделе, используется для иллюстрации
методов построения

системы,
базирующейся на правилах, и системы,
базирующейся на

логике.
Таким образом есть возможность сравнить
два различных

подхода
при работе с одними и теми же данными.
В последнем раз-

деле
данной главы рассматривается базирующаяся
на логике расши-

ренная
экспертная система для медицинской
диагностики.

10.9
База знаний для выбора породы собаки.

В
различных экспертных системах для
выбора породы основные

данные
одинаковы. Вы знакомы с ними, так как
выбраны распрост-

раненные
породы собак. Классификация в базе
знаний может осно-

вываться
на древовидной структуре, как показано
на рис. 10.2.

Согласно
этой древовидной классификации породы
разделены на ко-

роткошерстные
и длинношерстные. Английский бульдог,
гончая, дог

и
американский фокстерьер являются
короткошерстными, а кок-

кер-спаниэль,
ирландский сеттер, колли и сенбернар —
длинношер-

стные.

Рис.
10.2 Древовидная структура базы знаний
экспертной системы

для
выбора породы собаки.

Для
идентификации породы внутри каждого
подмножества можно

использовать
список атрибутов. Количество характеристик
будет

определять
степень точности классификации.
Различающей не обя-

зательно
является какая-нибудь единственная
характеристика —

все
множество атрибутов используется
для достижения целей в

строящихся
правилах. Все восемь перечисленных
ниже атрибутов

являются
необходимыми, так как ни один из них не
характерен для

всех
пород одновременно. Вспомните главу
9 , где говорилось,

что
атрибут, который характеризует все
объекты одновременно,

возможно,
не является необходимым в множестве
данных. В нашей

экспертной
системе используются следующие
характеристики:

1)
короткая шерсть;

2)
длинная шерсть;

3)
рост меньше 22 дюймов;

4)
рост меньше 30 дюймов;

5)
низкопосаженный хвост;

6)
длинные уши;

7)
хороший характер;

8)
вес больше 100 фунтов.

Каждая
характеристика для конкретной породы
либо верна,

либо
не верна. Для каждой породы справедливы
следующие характе-

ристики:

Порода
Характеристики

Английский
бульдог 1,3,5,7

Гончая
1,3,6,7

Дог
1,4,6,7,8

Американская
гончая 1,5,6,7,

Коккер
спаниэль 2,3,5,6,7

Ирландский
сеттер 2,4,6

Колли
2,4,5,7

Сенбернар
2,5,7,8,

Способ
использования этой информации
зависит от

реализации
экспертной системы.

В
нашем случае при проектировании базы
знаний древовидная

структура,
множество идентифицирующих характеристик
и наборы

номеров
характеристик для каждой породы
составляют рабочую мо-

дель
базы знаний для выбора породы.

Заметьте,
что номера характеристик являются
искусственными

фактами,
необходимыми проектировщику, и введены
они для того,

чтобы
функциональным модулям экспертной
системы было легче

идентифицировать
характеристики и манипулировать ими.

10.10
Проектирование и реализация системы,
базирующейся на

правилах

Когда
спроектирована база знаний, можно
написать программу

на
Турбо-Прологе для манипулирования ею.
Для простоты и большей

ясности,в
программе, которая рассматривается в
этом разделе,ос-

новное
внимание уделяется процессам, возникающим
во время кон-

сультации
с экспертной системой. Эти процессы
включают управле-

ние
потоком данных, поступающих от
пользователя, получение ин-

формации
из базы данных и выдачу результатов
консультации. Ил-

люстрирующая
эти процессы, диаграмма потока данных
приведена на

рис.
10.3.

Рис.
10.3 Диаграмма потоков данных для экспертной
системы, ба-

зирующейся
на правилах, для выбора породы собаки

На
рис. 10.3 показаны линии потока данных,
выходящие из

клавиатуры.
Эти линии обозначают поток входных
данных от поль-

зователя.
Также линии потоков данных выходят
из базы знаний.

Эти
линии соответствуют данным полученным
из базы знаний. Линии

потока
данных, идущие к монитору, представляют
собой выводимые

на
экран данные .Теперь основываясь на
диаграмме потоков дан-

ных,
можно разработать структурную схему,
чтобы зафиксировать

организацию
программных модулей и правил. Рис. 10.4
показывает

результирующую
структурную схему.

На
рис. 10.4 можно видеть, что главным модулем
(или цель)

является
— do_expert_job (выполни экспертную работу).
Модули

ask(X,Y)
(спроси) и remember(X,Y,Reply) (запомни) управляют
по-

током
данных от пользователя. Другие модули
обновляют рабочие

данные
и выдают результаты консультации.

Используя
эту схему, Вы можете теперь разработать
эксперт-

ную
систему на Турбо-Прологе, базирующуюся
на правилах. Сначала

необходимо
сделать декларации базы данных. База
данных будет

хранить
ответы пользователя на вопросы системы
пользовательско-

го
интерфейса (СПИ). Эти данные являются
утвердительными или

отрицательными
ответами. Далее нужно объявить предикаты
для вы-

полнения
вывода (машина вывода) и для взаимодействия
с пользо-

вателем
(система пользовательского интерфейса).

Все
вместе это следующие декларации:

database

xpositive(symbol,symbol)

xnegative(symbol,symbol)

predicates

do_expert_job

do_consulting

ask(symbol,symbol)

dog_is(symbol)

it_is(symbol)

positive(symbol,symbol)

negative(symbol,symbol)

remember(symbol,symbol,symbol)

clear_facts

Предикаты
базы данных
xpositive и xnegative используются

для
хранения утвердительных и
отрицательных ответов

пользователя.
Первые четыре предиката нужны для
взаимодействия

с
пользователем, а остальные шесть — для
механизма вывода.

Рис
10.4 Структурная диаграмма для экспертной
системы, базирую-

щейся
на правилах, для выбора породы собаки

Должны
быть составлены восемь продукционных
правил : по

одному
для каждой породы. Каждое правило должно
идентифициро-

вать
породу по признаку принадлежности к
группе длинношерстных

или
короткошерстных. Это главные подкатегории,
как следует из

данных
и как показано на древовидной структуре
(см. рис. 10.2).

Правило
it_is производит эту идентификацию.
Затем правило

positive
идентифицирует характеристики собаки
в каждом случае.

И
it_is и positive используются механизмом
вывода. Ниже приве-

дено
полное продукционное правило для
коккер-спаниэля:

dog_is(«Cocker
Spaniel») :-

it_is(«long-haired
dog»),

positive(has,»height
under 22 inches»),

positive(has,»low
set tail»),

positive(has,»longer
ears»),

positive(has,»good
natural personality»),!.

Механизм
вывода должен иметь правила для управления
данны-

ми
вводимыми пользователем, для сопоставления
их с продукцион-

ными
правилами и сохранения «трассы»
(или запоминания) отрица-

тельных
и утвердительных ответов. Правила
positive и negative

используются
для сопоставления данных пользователя
с данными в

продукционных
правилах. Правило remember (запоминание)
произво-

дит
добавление предложений с ответами yes
(да) и no (нет), для

использования
при сопоставлении с образцом:

positive(X,Y)
:-

xpositive(X,Y),!.

positive(X,Y)
:-

not(negative(X,Y)),!,

ask(X,Y).

negative(X,Y)
:-

xnegative(X,Y),!.

remember(X,Y,yes)
:-

asserta(xpositive(X,Y)).

remember(X,Y,no)
:-

asserta(xnegative(X,Y)),

fail.

clear_facts
:-

retract(xpositive(_,_)),

fail.

clear_facts
:-

retract(xnegative(_,_)),

fail.

Назначение
системы пользовательского интерфейса
(СПИ) —

связь
вводимых пользователем данных с
системой логического

вывода.
Главный модуль do_expert_job (выполни
экспертную

работу)
и модуль do_consulting (выполни консультацию)

осуществляют
эту связь. Модуль ask(X,Y) (спроси) запрашивает

данные
у пользователя и сохраняет ответы в
базе знаний. Кроме

того,
окно обеспечивает дополнительное
удобство во время

консультации.
Система пользовательского интерфейса
полностью

приведена
ниже:

do_expert_job
:-

setup_window,

do_consulting,

write(«Press
space bar.»),nl,

readch(_),

removewindow,

exit.

setup_window
:-

makewindow(1,7,7,»AN
EXPERT SYSTEM»,1,16,22,58),

nl,write(«*
* * * * * * * * * * * * * * * * * * *»),

nl,write(»
A Dog Expert «),

nl,write(»
«),

nl,write(«This
is a dog identification system. «),

nl,write(«Please
answer the question about «),

nl,write(«the
dog you would like by typing in «),

nl,write(«‘yes’
or ‘no’. «),

nl,write(«*
* * * * * * * * * * * * * * * * * * *»),

nl,nl.

do_consulting
:-

dog_is(X),!,nl,

write(«the
dog you have indicated is a(n)»,X,».»),nl,

clear_facts.

do_consulting
:-

nl,write(«Sorry
I can’t help you ! «),

clear_facts.

ask(X,Y)
:-

write(»
Question :- «,X,» it «,Y,» ?»),

readln(Reply),

remember(X,Y,Reply).

Заметьте,
что главный модуль do_expert_job вызывает

модули
setup_window (установи окно) и do_consulting (выполни

консультацию).
Консультирующий модуль имеет две
альтернативные

формы.
Первая взаимодействует с механизмом
вывода; если

результат
цикла «распознавание — действие»
положительный, то

результат
сообщается пользователю. Вторая форма
сообщает о

негативном
результате.

Теперь
можно соединить отдельные компоненты
и сформировать

полную
экспертную систему на правилах для
выбора породы собаки.

Листинг
10.1 содержит эту программу.

Эта
программа просит пользователя выбрать
режим консульта-

ции
или выход из программы. Затем экспертная
система выбирает

породу
собаки на основании ответов пользователя
на вопросы, или

в
конце неудачного поиска выдает сообщение
Sorry I can’t help

you
(извините, я не могу помочь Вам) . На рис.
10.5 показан эк-

ран
во время консультации.

Программные
правила вывода , спроектированные в
соответст-

вии
с описанным процессом, гарантируют
нормальное выполнение

программы
при диалоге с пользователем и при поиске,
обеспечивая

удобный
и «дружелюбный» к пользователю
язык . Внутренние прог-

раммы
унификации Турбо-Пролога , его возможности
поиска и со-

поставления
по образцу обеспечивают эффективный и
исчерпывающий

процесс.

Рис
10.5 Диалог с экспертной системой,
базирующейся на прави-

лах,
для выбора породы собаки

Упражнения

10.1
Вызовите экспертную систему, базирующуюся
на правилах, для

выбора
породы собаки. Введите различные
последовательности от-

ветов
«yes»( да) и «no»(нет), наблюдая
как работает программа.

10.2
Пронаблюдайте, что происходит, когда
ваши ответы подобраны

так,
что их нельзя сопоставить с породами,
характеристики кото-

рых
хранятся в базе знаний. Вы увидите, что
внутренние програм-

мы
унификиции Турбо-Пролога производят
исчерпывающее сопостав-

ление.
Только когда никакое сопоставление не
возможно , система

выдает
сообщение Sorry.

10.3
Модифицируйте базирующуюся на правилах
экспертную систему

для
выбора породы собаки, добавив
гипотетическую породу. Напи-

шите
продукционное правило для этой породы
собаки и включите

правило
в программу. Проверьте программу и
убедитесь, что она

идентифицирует
породу, которую вы «спроектировали».
Заметьте,

что
ваши характеристики собаки должны быть
комбинацией характе-

ристик
уже существующих в программе, но
комбинация должна отли-

чаться
от комбинаций для других пород. Небольшая
таблица может

помочь
вам спроектировать характеристики
породы.

10.10
Проектирование и реализация системы,
базирующейся на ло-

гике

Структура
экспертной системы, основанной на
логике, анало-

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

Опять
для простоты и большей ясности в
рассматриваемой в этом

разделе
программе основное внимание уделено
консультации с экс-

пертной
системой. Программа должна управлять
потоком данных от

пользователя,
выводить заключения из базы знаний и
выдавать ре-

зультаты
консультации. Диаграмма, иллюстрирующая
потоки данных,

приведена
на рис. 10.6.

Рис.
10.6 Диаграмма потоков данных для экспертной
системы, ба-

зирующейся
на логике, для выбора породы собаки

На
рис. 10.6 выходящие из клавиатуры линии
потока данных предс-

тавляют
собой входной поток данных от пользователя.
Другие ли-

нии
потока данных выходят из базы знаний;
они обозначают извле-

каемые
данные. Линии потока данных также
направлены к видеоэк-

рану.
Исходя из диаграммы потока данных,
можно сконструировать

структурную
схему, как показано на рис. 10.7.

Рис.10.7
Структурная диаграмма для экспертной
системы, базирую-

щейся
на логике, для выбора породы собаки

Структурная
схема показывает, что главный
модуль

do_expert_job
вызывает модуль
show_menu. Этот модуль предлагает

пользователю
выбрать программную функцию. Ответ
пользователя

считывается
в целочисленную переменную Choice (выбор)
и вызов

process(Choice)
приводит к выполнению соответствующей
программ-

ной
функции. Модули process(0) и process(2) служат
для выхода

из
программы. Модуль process(1) вызывает модуль
do_consulting

(выполни
консультацию). Различные модули,
вызываемые

do_consulting,
выдают породы собак, выполняют вывод и
обновляют

рабочие
данные. Модуль eval_reply обеспечивает
удобное заверше-

ние
диалога консультации.

Теперь
можно начать разработку на Турбо-Прологе
экспертной

системы,
базирующейся на логике. Первый раздел,
который нужно

написать,
— это раздел
domains.

domains

CONDITIONS
= BNO *

HISTORY
= RNO *

RNO,
BNO, FNO = INTEGER

CATEGORY
= SYMBOL

и
декларации database для базы знаний:

database

rule(RNO,
CATEGORY, CONDITIONS)

cond(BNO,
STRING)

yes(BNO)

no(BNO)

topic(string)

Предикат
базы знаний rule (правило) содержит
данные о

собаке
и предикат cond (условие) хранит условия
(или атрибуты

)
, которые характеризуют различные
породы. Предикаты yes (да)

и
no (нет) хранят ответы пользователя.
Предикат topic (тема)

содержит
данные о типах собак (длинно- или
короткошерстная

порода).

Раздел
predicates имеет восемь предикатов для

интерфейса
с пользователем:

do_expert_job

show_menu

do_consulting

process(integer)

info(CATEGORY)

goes(CATEGORY)

listopt

erase

clear

eval_reply(char)

Предикат
do_expert_job (выполни экспертную
работу) являет-

ся
целью программы. Правило erase (исключение)
исключает данные

из
базы знаний после завершения цикла
распознавание — действие.

Правило
clear (очистить) уничтожает в базе данных
все ответы

yes
(да) и no (нет) . Остальные семь предикатов
используемся в

механизме
вывода.

go(HISTORY,
CATEGORY)

check(RNO,
HISTORY, CONDITIONS)

notes(BNO)

inpo(HISTORY,
RNO, BNO, STRING)

do_answer(HISTORY,
RNO, STRING, BNO, INTEGER)

Эти
предикаты и правила осуществляют поиск
в базе знаний и

сохраняют
трассу значений объектов базы знаний
и ввода пользо-

вателя
для целей логического вывода. Правило
check (проверка)

ищет
образцы данных, сопоставимые с входными
данными пользова-

теля.Альтернативы
правила notest сохраняют трассу ответов
yes

(да)
и no (нет) . Предикат do_answer (обработай
ответ) добавля-

ет
данные от пользователя в динамическую
базу данных.

Экспертная
система, базирующаяся на логике,
состоит из

базы
знаний , содержащей утверждения
логики предикатов.

Утверждения
имеют одну из двух форм: rule или cond.
База

знаний
приведена ниже:

topic(«dog»).

topic(«short-haired
dog»).

topic(«long-haired
dog»).

rule(1,
«dog», «short-haired dog», [1]
).

rule(2,
«dog», «longt-haired dog», [2]
).

rule(3,
«short-haired dog»,»English Bulldog «, [3,5,7]
).

rule(4,
«short-haired dog»,»Beagle», [3,6,7]
).

rule(5,
«short-haired dog»,»Great Dane», [5,6,7,8]
).

rule(6,
«short-haired dog»,»American Foxhound»,[4,6,7]
).

rule(7,
«long-haired dog», «Cocker Spaniel», [3,5,6,7]
).

rule(8,
«long-haired dog», «Irish Setter», [4,6]
).

rule(9,
«long-haired dog», «Collie», [4,5,7]
).

rule(9,
«long-haired dog», «St. Bernard», [5,7,8]
).

cond(1,
«short-haired» ).

cond(2,
«long-haired» ).

cond(3,
«height under 22 inches» ).

cond(4,
«height under 30 inches» ).

cond(5,
«low-set tail» ).

cond(6,
«longer ears» ).

cond(7,
«good natured personality» ).

cond(8,
«weight over 100 lb» ).

Вы
помните, что в разд. «Построение базы
знаний» было ска-

зано,
что последний объект в утверждении
rule — список целых

чисел.
Список содержит номера условий, которые
характеризуют

каждую
породу собаки в базе знаний. Предложения
cond содержат

все
возможные характеристики собак.

Теперь
необходимо «сконструировать»
предикаты и правила

для
механизма вывода. Практически механизм
вывода должен иметь

начальное
правило, такое как go , для принятия цели
пользовате-

ля
и инициализации цикла распознавание
— действие. Механизм

просматривает
утверждения базы знаний rule и cond для
выяснения

существования
или отсутствия подходящих значений
данных.

Начальное
правило вызывает правила, например
check (про-

верка),
для выполнения подзадач соответствующим
образом. Это

правило
содержит трассу номеров правил, номеров
условий и клас-

сифицированные
объекты в базе знаний. Оно пытается
сопоставить

классифицированные
объекты в терминах номеров условий.

Если
сопоставление происходит,то этот
модуль программы

должен
добавить в программу сопоставленные
значения и продол-

жить
процесс с новыми данными, полученными
от пользователя. Ес-

ли
сопоставление не происходит, механизм
останавливает текущий

процесс
и выбирает для сопоставления другую
трассу. Поиск и со-

поставление
продолжаются до тех пор, пока не исчерпаны
все воз-

можности.

По
завершении вывода начальное правило с
помощью интерфей-

са
передает результаты пользователю.

Ниже
приводится полная программа, реализующая
механизм

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

go(HISTORY,
Mygoal) :-

rule(RNO,Mygoal,NY,COND),

check(RNO,HISTORY,COND),

go([RNO|HISTORY],NY).

check(RNO,HISTORY,[BNO|REST])
:-

yes(BNO),!,

check(RNO,HISTORY,REST).

check(_,_,[BNO|_])
:- no(BNO),!,fail.

check(RNO,HISTORY,[BNO|REST])
:-

cond(BNO,NCOND),

fronttoken(NCOND,»not»,_,COND),

frontchar(_,COND,_,COND),

cond(BNO1,COND),

notest(BNO1),!,

check(RNO,HISTORY,REST).

check(_,_,[BNO|_])
:-

cond(BNO,NCOND),

fronttoken(NCOND,»not»,_,COND),

frontchar(_,COND,_,COND),

cond(BNO1,COND),

yes(BNO1),

!,fail.

check(RNO,HISTORY,[BNO|REST])
:-

cond(BNO,TEXT),

inpo(HISTORY,RNO,BNO,TEXT),

check(RNO,HISTORY,REST).

check(_,_,[]).

notest(BNO)
:- no(BNO),!.

notest(BNO)
:- not(yes(BNO)),!.

do_answer(_,_,_,_,0)
:- exit.

do_answer(_,_,_,BNO,1)
:-

assert(yes(BNO)),

shiftwindow(1),

write(yes),nl.

do_answer(_,_,_,BNO,2)
:-

assert(no(BNO)),

write(no),nl,

fail.

erase
:- retract(_),fail.

erase.

clear
:- retract(yes(_)),retract(no(_)),fail,!.

clear.

Для
описания работы механизма вывода
далее приводится

пример.
Предположим, что задачей механизма
вывода является

идентификация
собаки, чьи характеристики соответствуют
коккер

спаниэлю
и специфицируются в базе знаний номерами
3, 5, 6, и 7.

Во
время выполнения программы цель программы
обеспечивает

выдачу
полезной информации посредством
интерфейса с пользовате-

лем.
После этого вызывается модуль do_consulting
(выполни кон-

сультацию),
который в свою очередь вызывает
правило go. Это

правило
— начальное правило механизма вывода.

go(HISTORY,
Mygoal) :-

rule(RNO,Mygoal,NY,COND),

check(RNO,HISTORY,COND),

go([RNO|HISTORY],NY).

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

переменная
Mygoal (моя цель) получает значение «dog»
(собака).

Применяется
утверждение базы знаний
rule(1,»dog»,»short-haired

dog»,[1])
и списочная переменная COND получает
значение [1].

Далее
правило rule передает этот параметр
правилу check (про-

верка).
В свою очередь правило check осуществляет
доступ к пра-

вилу
cond базы знаний с параметром BNO равным
1. Правило check

передает
это значение предикату fronttoken, чтобы
создать зна-

чение
_COND. Это правило дает неуспех.

Правило
check возвращается к правилу cond и COND
содержит

значение
параметра. Затем правило check осуществляет
доступ к

значению
«short-haired» (короткошерстный) и
передает его в

переменной
TEXT правилу inpq. Правило inpq выдает на
экран

текстовую
строку:

Question:-
short-haired? (Вопрос:- короткошерстный?)

Пользователю
сообщается, что он должен нажать 1 для
утвер-

дительного
ответа и 2 для отрицательного. Правило
inpq принима-

ет
ответ пользователя в нашем примере
это 2, и интерпретирует

его
как отрицательный.

Процесс
продолжается со следующим утверждением
rule базы

знаний,
т.е. RNO равным 2. Теперь правило check
использует

значение
COND равное 2 для текущего правила rule ,
повторяет

цикл
построения списка значений COND и
запрашивает

пользователя
о дополнительном вводе.

Основываясь
на вводимых ответах пользователя (рис.
10.12),

доступ
к утверждениям rule и cond происходит в
следующим поряд-

ке:

rule(1),
cond(1),

rule(2),
cond(2),

rule(7),
cond(3),

rule(7),
cond(5),

rule(7),
cond(6),

rule(7),
cond(7).

В
конце этого процесса переменная COND типа
список имеет

значение
[3,5,6,7]. Этот список сопоставляется со
списком усло-

вий
в правиле 7. Сопоставление связывается
с классифицированным

объектом
«Cocker Spaniel» (коккер спаниэль) в
утверждении rule,

и
механизм вывода, таким образом, нашел
требуемый результат.

Система
пользовательского интерфейса имеет
три части.

Большая
часть состоит в основном из правил
для организации

меню
и уничтожения окна, когда оно больше
не нужно. Работа

второй
части СПИ зависит от выбора пользователем
программной

функции.
Подправило process(1) вызывает правило
do_consulting,

которое
в свою очередь вызывает goes(Mygoal). Это
подправило

выдает
список пород собак и вызывает правило
go(Mygoal),

которое
инициализирует процесс поиска и
сопоставления по

образцу.

Третья
часть СПИ запрашивает и получает ответы
yes и no

от
пользователя. Она реализована следующим
образом:

inpo(HISTORY,RNO,BNO,TEXT)
:-

write(«Question
:-«,TEXT,» ? «),

makewindow(2,7,7,»Response»,10,54,7,20),

write(«Type
1 for ‘yes’ ,»),nl,

write(«Type
2 for ‘no’ : «),nl,

readint(RESPONSE),

clearwindow,

shiftwindow(1),

do_answer(HISTORY,RNO,TEXT,BNO,RESPONSE).

Заметьте,
что это правило взаимодействует
и с

пользователем
и с механизмом вывода. Предикаты write и
readint

используются
для взаимодействия с пользователем,
а правило

do_answer
взаимодействует с МВ.

Теперь
можно соединить отдельные компоненты
вместе, чтобы

сформировать
полную экспертную систему для выбора
собаки, бази-

рующуюся
на логике. Листинг 10.2 — это реализация
данного про-

екта:

Эта
программа выдает начальное меню
, предлагая

пользователю
выбор между consultation (консультацией) и
exit

from
the system (выход из системы) . Если
пользователь

выбирает
консультацию, то между пользователем
и системой

происходит
диалог. Затем пользователю сообщается
результат.

Результатом
является либо выбранная порода, либо
сообщение

Sorry
I can’t help you (Извините, я не могу помочь
Вам).

На
рис. 10.8 показан диалог во время
консультации. Заметь-

те,
что этот диалог приводит к утвердительному
результату. То

есть
база знаний содержит информацию о породе
собаки, которая

удовлетворяет
спецификации пользователя.

Упражнения

10.4.
Вызовите программу экспертной системы
для выбора породы,

основанную
на логике. Проведите несколько консультаций
и по-

наблюдайте,
как работает система .

10.5.
Модифицируйте программу, включив
информацию о другой по-

роде
собаки. Напишите соответствующее
утверждение логики преди-

катов,
содержащее ее характеристики в виде
списка целых чисел.

Убедитесь,
что каждый список уникален.

10.6.
Вместо информации о собаке введите
абсолютно новую кате-

горию
знаний, например, «рыба» или «человек,
занимающийся поли-

тикой».
Начните с организации атрибутов по
выбранному объекту,

делая
это систематическим образом. Затем
определите, какие ат-

рибуты
будут отличать один объект от остальных.
Когда закончи-

те,
проверьте все категории чтобы убедиться,
что каждая катего-

рия
сконструирована правильно.

Рис.
10.8 Диалог с экспертной системой,
базирующейся на логике,

для
выбора породы собаки

10.11
Расширенная экспертная система,
базирующаяся на логике.

Две
экспертные системы, рассматриваемые
в предыдущих

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

чертой
обоих систем является,возможность их
расширения для под-

держки
больших баз знаний. Механизмы вывода в
этих экспертных

системах
структурированы таким образом, чтобы
их можно было

легко
расширять, включая более специфических
утверждений. Эти

утверждения
могут формировать большие и неоднородные
базы зна-

ний.

Медицинская
диагностическая экспертная система
может

проиллюстрировать
расширение системы указанным образом.
Назна-

чение
системы, базирующейся на логике, —
идентификация вероят-

ной
болезни. Пользователь дает информацию
о симптомах в ответ

на
вопросы экспертной системы.

Обсуждение
проекта

Проект
медицинской диагностической экспертной
системы ана-

логичен
базирующейся на логике экспертной
системе для выбора

породы
собаки. Дополнительно в нее включенны
модули для загруз-

ки
и сохранения базы знаний.

Диаграмма
потоков данных для этой системы
приведена на

рис.
10.9. Заметьте, что диаграмма схожа с
диаграммой потоков

данных,
приведенной на рис. 10.6, поэтому детали
потоков данных

на
рис.10.9 не специфицированы . Добавлены
модули process(1)

для
загрузки файла базы знаний в память и
process(3) для сохра-

нения
базы знаний на диске. ( Обратите внимание
на линии пото-

ков
данных между базой знаний в памяти и
файлом базы знаний на

диске).

Рис.
10.9 Диаграмма потоков данных для
медицинской диагности-

ческой
экспертной системы

Структурная
схема, полученная из диаграммы потоков
данных,

показана
на рис. 10.10. Эта структурная схема
аналогична схеме,

приведенной
на рис. 10.7 для базирующейся на логике
системы вы-

бора
собаки . Однако обратите внимание на
два дополнительных

модуля
process(1) и process(3), которые загружают и
сохраняют

базу
знаний.

Содержание
базы знаний для медицинской экспертной
системы

приведено
на рис. 10.11. База знаний имеет информацию
по 15 бо-

лезням;
эта информация хранится в 15 утверждениях
rule базы

данных.
Список целых чисел, связанный с каждым
утверждением

rule
характеризует болезнь. Утверждения
rule и cond связаны

посредством
списков в конце каждого правила для
медицинской эк-

спертной
проблемы. Например правило:

Рис.
10.10 Структурная диаграмма для медицинской
диагностичес-

кой
экспертной системы

rule(11,»illness»,»social
anxiety»,[12,15,16,17,18,13])

связано
со следующими симптомами (условиями):

cond(12,»feel
anxious most of time»)

cond(15,»anxious
since giving up tobacco,alcohol, drugs»)

cond(16,»recently
had a major upset in file»)

cond(17,»loss
weight or eyes bulding»)

cond(18,»have
sex life problem»)

cond(13,»feel
anxious in meeting, particles, interviews»)

Утверждение
topic(«illness») предоставляет пользователю
выбор

базы
знаний. В нашем случае выбор — «illness».
При желании ,

например,
создать базу знаний для инфекционных
болезней, следо-

вало
бы добавить утверждение topic(«infectious
diseases») (ин-

фекционные
болезни). Затем требуется спроектировать
и реализо-

вать
rule и cond утверждения для построения базы
знаний по бо-

лезням.

10.12
Построение медицинской диагностической
экспертной системы

Листинг
программы, реализующей систему для
выбора собаки,

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

точка
для программы экспертной системы
медицинской диагностики.

Структуры
двух программ аналогичны. При желании
можно получить

медицинскую
диагностическую экспертную систему.
Полная програм-

ма,
показанная на листинге 10.3, — реализация
такой модифика-

ции.

Заметьте,
что база знаний не приведена на
листинге. Она

содержится
в файле на диске. Этот файл создается с
помощью ре-

дактора
Турбо-Пролога. Предикаты работы с
файлами consult и

save
используются для загрузки файла базы
знаний и записи его

на
диск. Меню в программе для пользователя
обеспечивает удобную

загрузку
и сохранение модулей базы знаний.

Рис
10.11 База знаний для медицинской
диагностической эксперт-

ной
системы

При
выполнении программы пользователю
предоставляется меню

программных
функций. Затем производится консультация
на основе

вопросов
и ответов пользователя. Ответы дают
экспертной системе

информацию
для процесса сопоставления по образцу.
Модули поль-

зовательского
интерфейса обеспечивают соответствующую
графику и

удобный
для пользователя естественный язык
взаимодействия во

время
диалога. Когда заканчивается цикл
распознавание — дейст-

вие
экспертной системы, система выдает
конечное сообщение: либо

вероятную
болезнь, либо , совет обратиться к
врачу. Типичный

диалог
во время консультации показан на рис.
10.12. Консульта-

ция
приводит к идентификации болезни.

Ядро
медицинской диагностической экспертной
системы, бази-

рующейся
на логике, — механизм вывода. Работа
механизма вывода

аналогична
работе механизма вывода в базирующейся
на логике эк-

спертной
системе для выбора собаки.

Начальной
точкой работы механизма вывода является
получе-

ние
ввода пользователя illness. Первый задаваемый
пользователю

вопрос
исходит из первого утверждения cond.

На
экране появляется:

Question:
— continually on edge?

Оставшиеся
вопросы базируются на утверждениях
cond co 2-го

номера
по 8-й. Ответы на вопросы 5 и 8 отрицательные,
поэтому

переменная
COND типа список имеет значение [1,2,3,4,6,7].
Дан-

ный
список сопоставляется со списком условий
правила 6. Это со-

поставления
связывается с классифицированным
объектом

«hypothyroidism»
в утверждении rule, и механизм вывода
нашел,

таким
образом, решение — увеличение щетовидной
железы.

Рис.10.12
Диалог с медицинской диагностической
экспертной сис-

темой

Упражнения

10.7.
Вызовите медицинскую диагностическую
экспертную систему.

Вспомните,
что база знаний не существует пока Вы
не «создали»

ее,
то есть пока Вы не загрузили файл базы
знаний, как это об-

суждалось
ранее. Проведите несколько консультаций,
чтобы полу-

чить
и удачные и неудачные результаты.

10.8.
Добавьте в базу знаний информацию о
нескольких других бо-

лезнях
( о лихорадке и др. ). Используйте редактор
Турбо-Проло-

га
для добавления в файл базы знаний.
Вызовите программу и убе-

дитесь,
что система правильно диагностирует
болезни.

Обзор
главы

В
данной главе описаны принципы работы
двух широко расп-

ространенных
типов экспертных систем: системы на
правилах и

системы,
базирующейся на логике. Были представлены
компоненты

этих
систем: база знаний, механизм вывода
и система пользова-

тельского
интерфейса.

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

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

правила
для систем, базирующихся на правилах,
и базу знаний ут-

верждений
для систем , базирующихся на логике.

Наконец,
при обсуждении медицинской экспертной
системы,

показано
как создавать базу знаний на диске.
Использование

базы
знаний на диске требует дополнительных
модулей для

загрузки
и сохранения базы знаний.

На
протяжении этой главы демонстрировались,
что графика и

средства
редактирования, мощные внутренние
программы унифика-

ции,
средства поиска и сопоставления
Турбо-Пролога обеспечивают

эффективность
программ. Так как разработка экспертных
систем

становится
многообещающей областью практического
применения

программирования
для задач искусственного интеллекта,
рост ис-

пользования
возможностей Турбо-Пролога оказывается
неограничен-

ным.

Названия
рисунков

10.1.
Общая структура экспертной системы

10.2.Древовидная
структура базы знаний экспертной
системы для

выбора
породы собаки

10.3.
Диаграмма потоков данных для экспертной
системы,

базирующейся
на правилах, для выбора породы собаки

10.4.
Структурная диаграмма для экспертной
системы,

базирующейся
на правилах, для выбора породы собаки

10.5.
Диалог с экспертной системой, базирующейся
на правилах,

для
выбора породы собаки

10.6.
Диаграмма потоков данных для
экспертной системы,

базирующейся
на логике, для выбора породы собаки

10.7.
Структурная диаграмма для экспертной
системы,

базирующейся
на логике, для выбора породы собаки

10.8.
Диалог с экспертной системой, базирующейся
на логике, для

выбора
породы собаки

10.9.
Диаграмма потоков данных для медицинской
диагностической

экспертной
системы

10.10.
Структурная диаграмма для медицинской
диагностической

экспертной
системы

10.11.
База знаний для медицинской
диагностической экспертной

системы

10.12.
Диалог с медицинской диагностической
экспертной системой

Перевод
рисунков

10.1
1-оболочка, 2-пользователь, 3-система
пользователь-

ского
интерфейса (СПИ), 4-механизм вывода (МВ),
5-база знаний

(БЗ).

10.2
1-собака, 2-короткошерстная собака,
3-длинношнрстная

собака,
4-английский бульдог, 5-гончая, 6-дог,
7-американский

фокстерьер,
8-коккер-спаниэль, 9-ирландский сеттер,
10-колли,

11-
сенбернар

10.3
1-клавиатура, 2-дисплей, 3-база знаний

10.4

10.5

10.6
1-клавиатура, 2-дисплей, 3-база знаний

10.7

10.8

10.9
1-клавиатура, 2-дисплей, 3-база знаний,
4-основная

диаграмма
потоков данных (см. рис. 10.6), 5-файл базы
знаний

Листинг
10.1

/*
Программа: Эксперт по породам собак
Файл:prog1001.pro */

/*
Назначение. Демонстрация работы
экспертной системы. */

/*
Это продукционная система, базирующаяся
на правилах */

/*
Замечание: это система для идентификации
породы. Система */

/*
использует множество продукционных
правил для вывода */

/*
решения
*/

domains

database

xpositive(symbol,symbol)

xnegative(symbol,symbol)

predicates

do_expert_job

do_consulting

ask(symbol,symbol)

dog_is(symbol)

it_is(symbol)

positive(symbol,symbol)

negative(symbol,symbol)

remember(symbol,symbol,symbol)

clear_facts

goal

do_expert_job

clauses

/*
Система пользовательского интерфейса
(СПИ) */

do_expert_job
:-

makewindow(1,7,7,»AN
EXPERT SYSTEM»,1,16,22,58),

nl,write(«*
* * * * * * * * * * * * * * * * * * *»),

nl,write(»
WELCOME TO A DOG EXPERT SYSTEM «),

nl,write(»
«),

nl,write(«This
is a dog identification system. «),

nl,write(«Please
answer the question about «),

nl,write(«the
dog you would like by typing in «),

nl,write(«‘yes’
or ‘no’. «),

nl,write(«*
* * * * * * * * * * * * * * * * * * *»),

nl,nl.

do_consulting,

write(«Press
space bar.»),nl,

readch(_),

removewindow,

exit.

do_consulting
:-

dog_is(X),!,nl,

write(«the
dog you have indicated is a(n)»,X,».»),nl,

clear_facts.

do_consulting
:-

nl,write(«Sorry
I can’t help you ! «),

clear_facts.

ask(X,Y)
:-

write(»
Question :- «,X,» it «,Y,» ?»),

readln(Reply),

remember(X,Y,Reply).

/*
МЕХАНИЗМ ВЫВОДА */

positive(X,Y)
:-

xpositive(X,Y),!.

positive(X,Y)
:-

not(negative(X,Y)),!,

ask(X,Y).

negative(X,Y)
:-

xnegative(X,Y),!.

remember(X,Y,yes)
:-

asserta(xpositive(X,Y)).

remember(X,Y,no)
:-

asserta(xnegative(X,Y)),

fail.

clear_facts
:-

retract(xpositive(_,_)),

fail.

clear_facts
:-

retract(xnegative(_,_)),

fail.

/*
ПРОДУКЦИОННЫЕ ПРАВИЛА
*/

dog_is(«English
Bulldog») :-

it_is(«short-haired
dog»),

positive(has,»height
under 22 inches»),

positive(has,»low-set
tail»),

positive(has,»good
natured personality»),!.

dog_is(«Beagle»)
:-

it_is(«short-haired
dog»),

positive(has,»height
under 22 inches»),

positive(has,»longer
ears»),

positive(has,»good
natured personality»),!.

dog_is(«Great
Dane») :-

it_is(«short-haired
dog»),

positive(has,»low-set
tail»),

positive(has,»good
natured personality»),

positive(has,»weight
over 100 lb»),!.

dog_is(«American
Foxhound») :-

it_is(«short-haired
dog»),

positive(has,»height
under 30 inches»),

positive(has,»longer
ears»),

positive(has,»good
natured personality»),!.

dog_is(«Cocker
Spaniel») :-

it_is(«long-haired
dog»),

positive(has,»height
under 22 inches»),

positive(has,»low-set
tail»),

positive(has,»longer
ears»),

positive(has,»good
natured personality»),!.

dog_is(«Irish
Setter») :-

it_is(«long-haired
dog»),

positive(has,»height
under 30 inches»),

positive(has,»longer
ears»),!.

dog_is(«Collie»)
:-

it_is(«long-haired
dog»),

positive(has,»height
under 30 inches»),

positive(has,»low-set
tail»),

positive(has,»good
natured personality»),!.

dog_is(«St.
Bernard») :-

it_is(«long-haired
dog»),

positive(has,»low-set
tail»),

positive(has,»good
natured personality»),

positive(has,»weight
over 100 lb»),!.

it_is(«short-haired
dog») :-

positive(has,»short-haired»),!.

it_is(«long-haired
dog») :-

positive(has,»long-haired»),!.

/*
КОНЕЦ ПРОГРАММЫ
*/

Листинг
10.2

/*
Программа: Эксперт по породам собак
Файл:prog1002.pro */

/*
Назначение. Демонстрация работы
экспертной системы, */

/*
базирующейся на логике
*/

/*
Замечание: это система для идентификации
породы. Система */

/*
состоит из базы знаний (БЗ), механизма
вывода (МВ) */

/*
и системы пользовательского интерфейса
(СПИ). */

/*
База знаний располагается в оперативной
памяти */

domains

CONDITIONS
= BNO *

HISTORY
= RNO *

RNO,
BNO, FNO = INTEGER

CATEGORY
= SYMBOL

database

/*
Предикаты базы
данных */

rule(RNO,
CATEGORY, CONDITIONS)

cond(BNO,
STRING)

yes(BNO)

no(BNO)

topic(string)

predicates

/*
Предикаты системы пользовательского
интерфейса */

do_expert_job

show_menu

do_consulting

process(integer)

info(CATEGORY)

goes(CATEGORY)

listopt

erase

clear

eval_reply(char)

/*
Предикаты механизма
вывода */

go(HISTORY,
CATEGORY)

check(RNO,
HISTORY, CONDITIONS)

notes(BNO)

inpo(HISTORY,
RNO, BNO, STRING)

do_answer(HISTORY,
RNO, STRING, BNO, INTEGER)

goal

do_expert_job

clauses

/*
База знаний
(БЗ) */

topic(«dog»).

topic(«short-haired
dog»).

topic(«long-haired
dog»).

rule(1,
«dog», «short-haired dog», [1]
).

rule(2,
«dog», «longt-haired dog», [2]
).

rule(3,
«short-haired dog»,»English Bulldog «, [3,5,7]
).

rule(4,
«short-haired dog»,»Beagle», [3,6,7]
).

rule(5,
«short-haired dog»,»Great Dane», [5,6,7,8]
).

rule(6,
«short-haired dog»,»American Foxhound»,[4,6,7]
).

rule(7,
«long-haired dog», «Cocker Spaniel», [3,5,6,7]
).

rule(8,
«long-haired dog», «Irish Setter», [4,6]
).

rule(9,
«long-haired dog», «Collie», [4,5,7]
).

rule(9,
«long-haired dog», «St. Bernard», [5,7,8]
).

cond(1,
«short-haired» ).

cond(2,
«long-haired» ).

cond(3,
«height under 22 inches» ).

cond(4,
«height under 30 inches» ).

cond(5,
«low-set tail» ).

cond(6,
«longer ears» ).

cond(7,
«good natured personality» ).

cond(8,
«weight over 100 lb» ).

/*
Система пользовательского интерфейса
*/

do_expert_job
:-

makewindow(1,7,7,»
DOG EXPERT SYSTEM «,0,0,25,80),

show_menu,

nl,write(»
Press space bar. «),

readchar(_),

exit.

show_menu
:-

write(»
«),nl,

write(»
* * * * * * * * * * * * * * * * * * «),nl,

write(»
* DOG EXPERT * «),nl,

write(»
* * «),nl,

write(»
* 1. Consultation * «),nl,

write(»
* * «),nl,

write(»
* * «),nl,

write(»
* 2. Exit the system * «),nl,

write(»
* * «),nl,

write(»
* * * * * * * * * * * * * * * * * * «),nl,

write(»
«),nl,

write(«Please
enter your choice: 1 or 2 : «),nl,

readint(Choice),

process
(Choice).

process(1)
:-

do_consulting.

process(2)
:-

removewindow,

exit.

do_consulting
:-

goes(Mygoal),

go([],Mygoal),

!.

do_consulting
:-

nl,
write(» Sorry I can’t help yuo.»),

clear.

do_consulting.

goes(Mygoal)
:-

clear,

clearwindow,

nl,nl,

write(»
«),nl,

write(»
WELCOME TO THE DOG EXPERT SYSTEM «),nl,

write(»
«),nl,

write(«This
is a dog identification system. «),nl,

write(«To
begin the process of choosing a «),nl,

write(«dog,
please type in ‘dog’. If you «),nl,

write(«wish
to see the dog types, please «),nl,

write(«type
in a question mark (?). «),nl,

write(»
«),nl,

readin(Mygoal),

info(Mygoal),!.

info(«?»)
:-

clearwindow,

write(«Reply
from the KBS.»),nl,

listopt,

nl,write(«Please
any key. «),

readchar(_),

clearwindow,

exit.

info(X)
:-

X
>< «?».

listopt
:-

write(«The
dog types are : «),nl,nl,

topic(Dog),

write(»
«,Dog),nl,

fail.

listopt.

inpo(HISTORY,RNO,BNO,TEXT)
:-

write(«Question
:- «,TEXT,» ? «),

makewindow(2,7,7,»Response»,10,54,7,20),

write(«Type
1 for ‘yes’ ,»),nl,

write(«Type
2 for ‘no’ : «),nl,

readint(RESPONSE),

clearwindow,

shiftwindow(1),

do_answer(HISTORY,RNO,TEXT,BNO,RESPONSE).

eval_reply(‘y’)
:-

write(»
I hope you have found this helpful !»).

eval_reply(‘n’)
:-

write(»
I am sorry I can’t help you !»).

go(_,Mygoal)
:-

not(rule(_,Mygoal,_,_)),!,

nl,write(»
The dog you have indicated is a(n) «,

Mygoal,».»),nl,

write(«Is
a dog you would like to have (y/n) ?»),

nl,readchar(R),

eval_reply(R).

/*
Механизм вывода
*/

go(HISTORY,
Mygoal) :-

rule(RNO,Mygoal,NY,COND),

check(RNO,HISTORY,COND),

go([RNO|HISTORY],NY).

check(RNO,HISTORY,[BNO|REST])
:-

yes(BNO),!,

check(RNO,HISTORY,REST).

check(_,_,[BNO|_])
:- no(BNO),!,fail.

check(RNO,HISTORY,[BNO|REST])
:-

cond(BNO,NCOND),

fronttoken(NCOND,»not»,_,COND),

frontchar(_,COND,_,COND),

cond(BNO1,COND),

notest(BNO1),!,

check(RNO,HISTORY,REST).

check(_,_,[BNO|_])
:-

cond(BNO,NCOND),

fronttoken(NCOND,»not»,_,COND),

frontchar(_,COND,_,COND),

cond(BNO1,COND),

yes(BNO1),

!,fail.

check(RNO,HISTORY,[BNO|REST])
:-

cond(BNO,TEXT),

inpo(HISTORY,RNO,BNO,TEXT),

check(RNO,HISTORY,REST).

check(_,_,[]).

notest(BNO)
:- no(BNO),!.

notest(BNO)
:- not(yes(BNO)),!.

do_answer(_,_,_,0)
:- exit.

do_answer(_,_,BNO,1)
:-

assert(yes(BNO)),

shiftwindow(1),

write(yes),nl.

do_answer(_,_,_,BNO,2)
:-

assert(no(BNO)),

write(no),nl,

fail.

erase
:- retract(_),fail.

erase.

clear
:- retract(yes(_)),retract(no(_)),fail,!.

clear.

/*
Конец программы */

Листинг
10.3

/*
Программа: Медицинская экспертная
система Файл: prog1003.pro */

/*
*/

/*
Назначение. Демонстрация работы
экспертной системы,

/*
базирующейся на диске
*/

/*
Замечание: Это медицинская экспертная
система. Система */

/*
состоит из базы знаний (БЗ), механизма
вывода (МВ) */

/*
и системы пользовательского интерфейса
(СПИ). */

/*
База знаний загружается с диска
*/

domains

CONDITIONS
= BNO *

HISTORY
= RNO *

RNO,
BNO, FNO = INTEGER

CATEGORY
= SYMBOL

database

/*
Предикаты базы
данных */

rule(RNO,
CATEGORY, CONDITIONS)

cond(BNO,
STRING)

yes(BNO)

no(BNO)

topic(string)

predicates

/*
Предикаты системы пользовательского
интерфейса */

do_expert_job

show_menu

do_consulting

process(integer)

listopt

evalans(char)

info(CATEGORY)

goes(CATEGORY)

/*
Предикаты механизма
вывода */

go(HISTORY,
CATEGORY)

check(RNO,
HISTORY, CONDITIONS)

notes(BNO)

inpo(HISTORY,
RNO, BNO, STRING)

do_answer(HISTORY,
RNO, STRING, BNO, INTEGER)

erase

clear

goal

do_expert_job

clauses

/*
Cистема пользовательского интерфейса
(часть 1) */

do_expert_job
:-

makewindow(1,7,7,»MEDICAL
EXPERT SYSTEM «,0,0,25,80),

show_menu,

nl,write(»
Press space bar. «),

readchar(_),

exit.

show_menu
:-

write(»
«),nl,

write(»
* * * * * * * * * * * * * * * * * * «),nl,

write(»
* MEDICAL EXPERT * «),nl,

write(»
* * «),nl,

write(»
* 1. Load KBS * «),nl,

write(»
* 2. Consultation * «),nl,

write(»
* 3. Save KBS * «),nl,

write(»
* 4. Exit the system * «),nl,

write(»
* * «),nl,

write(»
* * * * * * * * * * * * * * * * * * «),nl,

write(»
«),nl,

write(«Please
enter your choice: 1,2,3 or 4 : «),nl,

readint(Choice),

process
(Choice).

process(0).

process(1)
:-

consult(«illness.dba»).

process(2)
:-

do_consulting.

process(3)
:-

save(«ILLNESS.DBA»).

process(4)
:-

exit.

do_consulting
:-

goes(Mygoal),nl,nl,

go([],Mygoal),

!.

do_consulting
:-

nl,
write(» Sorry I can’t determine that one»),

nl,write(»
Please see a physician. «),nl,

clear.

goes(Mygoal)
:-

clear,

clearwindow,

nl,nl,

write(»
«),nl,

write(»
WELCOME TO THE MEDICAL EXPERT SYSTEM «),nl,

write(»
«),nl,

write(«This
is an illnes identification system.»),nl,

write(«To
start the consultation process, «),nl,

write(«please
type in ‘illness’. «),nl,

readin(Mygoal),

info(Mygoal),!.

go(_,Mygoal)
:-

not(rule(_,Mygoal,_,__,!,nl,

write(»
I think it is «,MYgoal,».»),nl,nl,

write(»
Is my diagnosis right (y/n) ?»),nl,

readchar(Answer),

evalans(Answer).

/*
МЕХАНИЗМ ВЫВОДА
*/

go(HISTORY,Mygoal)
:-

rule(RNO,Mygoal,NY,COND),

check(RNO,HISTORY,COND),

go([RNO|HISTORY],NY).

check(RNO,HISTORY,[BNO|REST])
:-

yes(BNO),!,

check(RNO,HISTORY,REST).

check(_,_,[BNO|_])
:- no(BNO),!,fail.

check(RNO,HISTORY,[BNO|REST])
:-

cond(BNO,NCOND),

fronttoken(NCOND,»not»,_,COND),

frontchar(_,COND,_,COND),

cond(BNO1,COND),

notest(BNO1),!,

check(RNO,HISTORY,REST).

check(_,_,[BNO|_])
:-

cond(BNO,NCOND),

fronttoken(NCOND,»not»,_,COND),

frontchar(_,COND,_,COND),

cond(BNO1,COND),

yes(BNO1),

!,fail.

check(RNO,HISTORY,[BNO|REST])
:-

cond(BNO,TEXT),

inpo(HISTORY,RNO,BNO,TEXT),

check(RNO,HISTORY,REST).

check(_,_,[]).

notest(BNO)
:- no(BNO),!.

notest(BNO)
:- not(yes(BNO)),!.

do_answer(_,_,_,0)
:- exit.

do_answer(_,_,BNO,1)
:-

assert(yes(BNO)),

shiftwindow(1),

write(yes),nl.

do_answer(_,_,_,BNO,2)
:-

assert(no(BNO)),

write(no),nl,

fail.

erase
:- retract(_),fail.

erase.

clear
:- retract(yes(_)),retract(no(_)),fail,!.

clear.

/*
СИСТЕМА ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
(часть 2) */

inpo(HISTORY,RNO,BNO,TEXT)
:-

write(«Question
:-«,TEXT,» ? «),

makewindow(2,7,7,»Response»,10,54,7,20),

write(«Type
1 for ‘yes’ ,»),nl,

write(«Type
2 for ‘no’ : «),nl,

readint(RESPONSE),

clearwindow,

shiftwindow(1),

do_answer(HISTORY,RNO,TEXT,BNO,RESPONSE).

info(«?»)
:-

clearwindow,

write(«Reply
from the KBS.»),nl,

listopt,

nl,write(«Please
any key. «),

readchar(_),

clearwindow,

show_menu.

info(X)
:-

X
>< «?».

listopt
:-

write(«The
illnesses are : «),nl,nl,

topic(Ins),

write(»
«,Ins,» «),nl,

fail.

listopt.

evalans(‘y’)
:-

write(»
I am glad I can help you !»),nl,nl,

write(»
Press the space bar.»),

readchar(_),

clearwindow,

show_menu.

evalans(‘n’)
:-

write(»
I am sorry I can’t help you !»),nl,nl,

write(»
Please press space bar .»),

readchar(_),

clearwindow,

show_menu.

/*
Конец программы
*/

Как построить экспертную систему

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

Как построить экспертную систему

Вам понадобится

  • — среда программирования.

Инструкция

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

Определитесь с задачами, которые будет решать экспертная система. Основное отличие экспертной системы — это ее обучаемость, пусть и заданная программно. Подберите ту задачу, для решения которой мало исполняемого кода с условиями. Предусмотрите развитие логики программы.

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

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

Основное предназначение экспертной системы — решение задач, для которых необходимы данные и знания самого эксперта. Таким образом, стандартный пользователь получит «эксперта на дому», так как все знания эксперта будут реализованы в программном коде и логике работы программы, которую вы разработали.

Видео по теме

Войти на сайт

или

Забыли пароль?
Еще не зарегистрированы?

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Экспертные системы

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

В общем виде все системы, основанные на знаниях, можно разделить на

  • Системы, решающие задачи синтеза. Множество задач потенциально неограниченно и строится на решении компонентов или подпроблем.
    • Интерпретация данных
    • Диагностика
    • Поддержка принятия решений
  • Системы, решающие задачи анализа. Множество решений может быть перечислено и включено в систему.
    • Проектирование
    • Планирование
    • Управление

Состав команды разработки экспертной системы:

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

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

База знаний – ядро экспертной системы; совокупность знаний предметной области, представленная в форме, понятной эксперту и пользователю. Обычно на некотором языке, близком к естественному.

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

Подсистема объяснений – программа, позволяющая пользователю получить ответы на вопросы, как была получена та или иная рекомендация, почему машина приняла именно такое решение. Ответ на вопрос «как?» – трассировка всего процесса получения решения с указанием использованных фрагментов базы знаний. Ответ на вопрос «почему?» — ссылка на умозаключение, предшествовавшее полученному решению

Интеллектуальный редактор – программа, позволяющая аналитику создавать базу знаний в диалоговом режиме.

Классификация экспертных систем:

  • По задаче:
    • Интерпретация данных – определение смысла данных, результаты которого должны быть согласованными (осмысленными) и корректными. Обычно предусматривается многовариантный анализ данных.
    • Диагностика – процесс соотнесения объекта с некоторым классом объектов и/или обнаружение неисправностей в некоторой системе. Неисправность – отклонение от нормы. Такая трактовка позволяет с единых теоретических позиций рассматривать и неисправности оборудования в технических системах, и заболевания живых организмов, и природные аномалии, и пр.
    • Проектирование – подготовка спецификаций на создание объектов с заранее определёнными свойствами.
      • Спецификация – весь набор необходимых документов. Основная проблема – получение чёткого структурного описания знаний об объекте. Для организации эффективного проектирования и, особенно, перепроектирования, необходимо формировать не только проектные решения, но и мотивы их принятия. В задачах такого класса тесно связаны процессы вывода и объяснения решения.
    • Прогнозирование – позволяет предсказывать последствия событий или явлений на основании анализа имеющихся данных. Прогнозирующие системы обычно логически выводят вероятные следствия из заданных ситуаций. Является комбинированной задачей.
    • Мониторинг – непрерывная интерпретация данных в реальном масштабе времени и сигнализация о выходе параметров за допустимые пределы. Проблемы: пропуск тревожной ситуации и ложное срабатывание. Сложность этих проблем в размытости симптомов тревожной ситуации. Является комбинированной задачей.
    • Планирование – нахождение планов действий, относящихся к объектам, способным выполнять некоторые функции. В экспертных системах используются реальные модели поведения объектов, чтобы логически вывести последствия планируемой деятельности.
    • Обучение (дисциплине или предмету) – системы обучения диагностируют ошибки при изучении дисциплины и подсказывают правильные решения. Они аккумулируют знания о гипотетическом ученике, его характерных ошибках и затем в работе способны диагностировать слабости в познаниях и находить соответствующие средства для их ликвидации. Кроме того, они планируют акт общения с учеником в зависимости от его успехов. Является комбинированной задачей.
    • Управление – функция организованной системы, поддерживающая определённый режим деятельности. Такого рода экспертные системы осуществляют управление поведением сложных систем в соответствии с заданными спецификациями.
    • Поддержка принятия решений – совокупность процедур, обеспечивающих лицо, принимающее решение (ЛПР), необходимой информацией и рекомендациями, облегчающими процесс принятия решений. Такие экспертные системы помогают специалистам выбрать и/или сформировать нужную альтернативу среди множества выборов при принятии ответственных решений.
  • По связи с реальным временем:
    • Статические – разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени.
      • Пример: диагностика неисправностей в автомобиле.
    • Квазидинамические – интерпретируют ситуации, которые меняются с некоторым фиксированным интервалом времени.
      • Пример: микробиологические экспертные системы, в которых снимаются лабораторные измерения с технологического процесса. Полученные показатели и их динамика анализируются.
    • Динамические – работают в сопряжении с датчиками объектов в реальном времени с непрерывной интерпретацией поступающих в систему данных.
      Пример: мониторинг в реанимационных палатах.
  • По типу ЭВМ:
    • На супер-ЭВМ
    • На ЭВМ средней производительности (мейнфреймы)
    • На символьных процессорах
    • На рабочих станциях
    • На ПК
  • По степени интеграции:
    • Автономные – работают непосредственно в режиме консультации с пользователем для специфических экспертных задач. В них не требуется привлекать традиционные методы обработки данных.
    • Гибридные – программный комплекс, агрегирующий стандартные пакеты прикладных программ и средства манипулирования знаниями. Разработка таких систем гораздо сложнее автономных систем.
      • Пример: интеллектуальная надстройка над пакетом прикладных программ.

Требования к команде разработки экспертной системы:

Пользователь. Основное требование – базовый уровень квалификации, позволяющий ему правильно истолковывать рекомендации системы. Должна быть полная совместимость терминологии системы с терминологией пользователя. Остальные требования: дружелюбие, отсутствие психологического барьера к использованию ЭВМ, умение объяснить, что он хочет от системы.

Эксперт. Основное требование – готовность поделиться знаниями. Остальные требования: умение объяснять, заинтересованность, высокий профессионализм в своей области.

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

Аналитик. Основное требование – владение эффективными навыками грамотного извлечения, формализации и концептуализации знаний: Z1 — Z5. Должен владеть двумя механизмами вывода (ассоциативный и психологический) и извлечения знаний (мозговой штурм и т.п.). Аналитик должен владеть методологией разработки системы; одним из языков программирования.

  • Z1 – знания в памяти
  • Z2 – знания в книгах
  • Z3 – поле знаний (методология представления знаний)
  • Z4 – модель знаний
  • Z5 – база знаний

Технологии проектирования и разработки промышленных экспертных систем

Стадии разработки:

  • Выбор проблемы – деятельность, предшествующая разработке конкретной экспертной системы. Критическая часть разработки. При выборе проблемы следует учитывать, что если знания, необходимые для решения задач постоянны, чётко сформулированы и связаны с вычислительной обработкой, то не обязательно создавать экспертную систему – возможно, будет проще создать обычный программный комплекс.
    • Определение проблемной области задачи
    • Нахождение эксперта и назначение коллектива разработчиков
    • Определение предварительного подхода к решению проблемы
    • Анализ расходов и прибыли от разработки
    • Подготовка подробного плана разработки
  • Разработка прототипа
  • Доработка до промышленной системы
  • Оценка
  • Стыковка
  • Поддержка

Технологии быстрого прототипирования

Прототип системы – усечённая версия системы, ориентированная на проверку правильности кодирования фактов, знаний и стратегий рассуждения экспертов. Стандартный объём прототипа – несколько десятков правил.

Стадии прототипирования:

  1. Идентификация (переопределение) проблемы (эксперт, аналитики, пользователи).
    • Уточняется задача
    • Планируется ход разработки прототипа
    • Определяются необходимые ресурсы (время, люди, машины), источники знаний (книги, методики, дополнительные эксперты)
    • Определяются аналогичные экспертные системы
    • Определяются цели
    • Определяются классы решаемых задач
    • Знакомство и обучение всех членов коллектива разработчиков
    • Создание неформального описания проблемы
  2. Получение (извлечение) знаний (эксперт и аналитик) – получение аналитиком наиболее полного из возможных представления о предметной области и способах принятия решений в этой области. Средний срок стадии – 1-3 месяца.
  3. Структурирование (концептуализация) знаний (аналитик) – разработка неформального описания знаний о предметной области в виде таблиц, графов, обычного текста и т.п., которое отражает основные концепции и взаимосвязи между понятиями предметной области. Такое описание называется полем знаний. Выделяется терминология, список основных понятий и атрибутов, отношения между понятиями; структура входной и выходной информации, стратегия принятия решений, ограничения стратегии и т.д. Средний срок стадии – 3-4 недели.
  4. Формализация знаний (аналитик, программист) – разработка базы знаний на языке представления знаний (ЯПЗ). Средний срок – 1-2 месяца.
  5. Реализация прототипа (программист) – разработка программного комплекса, демонстрирующего жизнеспособность подхода в целом. Средний строк – 1-2 месяца.
  6. Тестирование (эксперт, аналитик, пользователи, программист) – выявление ошибок в подходе к реализации прототипа и выработка рекомендаций по доводке системы до промышленного варианта. Средний срок – 1-2 недели. Проверяется
    • работа прототипа с целью приведения в соответствие реальными запросами пользователя – удобство и адекватность интерфейса (ввод и вывод, характер вопросов, связность генерируемого текста и т.п.).
    • Эффективность стратегии управления
    • Качество проверочных примеров
    • Корректность (полнота и непротиворечивость) базы знаний

Развитие прототипа до промышленной экспертной системы

Стадии развития:

  • Демонстрационный прототип. Система решает часть задач и демонстрирует жизнеспособность подхода. В неё входит несколько десятков правил, понятий и т.п.
  • Исследовательский прототип. Система решает большинство задач, но неустойчива в работе и не полностью проверена. Содержит несколько сотен правил и понятий.
  • Действующий прототип. Система надёжно решает все задачи на реальных примерах, но нет оптимизации ресурсов.
  • Промышленная система. Система обеспечивает высокое качество решения при минимизации затрачиваемых ресурсов.
  • Коммерческая система. Система, ко всему прочему, хорошо документирована, снабжена сервисом.

Оценка системы

Проводится тестирование системы в отношениях критериев эффективности. Для этого привлекаются другие эксперты, дабы проверить работоспособность системы на других примерах.

Классификация критериев оценки:

  • Оценка пользователя (понятность и прозрачность системы, удобство пользования и т.д.)
  • Критерии приглашённых экспертов (оценка советов и решений, сравнение их с собственными решениями, оценка подсистемы объяснений, и.т.д.)
  • Критерии разработчика
    • эффективность реализации
    • производительность
    • время отклика
    • дизайн
    • широта охвата предметной области
    • непротиворечивость базы знаний
    • количество тупиковых ситуаций
    • анализ чувствительности программы к незначительным изменениям в представлении знаний, весовых коэффициентов в механизмах логического вывода

Стыковка системы

Стыковка экспертной системы с другими программами в среде, с которой она будет работать и обучение людей, которых она будет обслуживать. Иногда это означает внесение существенных изменений. В этом процессе участвуют аналитик и эксперт. После этого аналитик должен убедиться, что пользователи знают систему и могут её обслуживать. Для подтверждения полезности системы рекомендуется поставить пользователям свои задачи и получить решения. Необходимо представить систему как помощника, освобождающего пользователя от решения обременительных задач, а не как средство его (пользователя) замещения. Стыковка включает обеспечение связи экспертной системы с существующими базами данных и другими системами на предприятии, а также улучшение системных факторов, зависящих от времени, чтобы можно было обеспечить её более эффективную работу и улучшить характеристики технических средств, если система работает в необычной среде.

Поддержка системы

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

Понравилась статья? Поделить с друзьями:
  • Как написать экскурсию примеры написания
  • Как написать экскурсию для детей
  • Как написать экономическую часть диплома
  • Как написать экономическое эссе
  • Как написать экономическое обоснование пример для киви кошелька