Простая экспертная система на языке Пролог
В рамках курсового проектирования на кафедре МиПОИС Белгородского государственного университета, была поставлена задача реализовать простую экспертную систему на тему "Определение неполадок компьютера".
Мы к этому делу подошли творчески 
и реализовали ее, совместив две технологии графический win32 интерфейс и собственно сама пролог машина, реализованная в компоненте LSEngine (Logical server engine) - движок логического сервера от компании amzi
Архитектура приложения следующая: логический сервер подгружает метапрограмму, которая использует нами созданную базу знаний для совершения логических выводов. В принципе все просто. База знаний построена по принципу логических выводов "если-то". Если совместить все логические выводы, то получим бинарное дерево, описывающее решение задачи определения поломки компьютера.
Узлы дерева это вопросы задаваемые пользователю экспертной системой, а листья (корни) это логические выводы по решаемой задаче. И никакой магии.
Привожу часть текста базы знаний:
'главная цель'(X) :- 'вопрос'-X.
'назначение экспертной системы'($Определение неполадок компьютера$).
'вопрос'('Работает ПК?').
'вопрос'('ПК включается?').
'вопрос'('Свет есть?').
'вопрос'('Изображение есть на мониторе?').
'вопрос'('Писк есть при загрузке?').
'вопрос'('Монитор подключен к сети?').
'вопрос'('Лампочка на мониторе горит?').
'вопрос'('Загружается ОС?').
'вопрос'('При входе в систему есть звук?').
'вопрос'('Есть сообщения об ошибке ОС?').
'вопрос'('У вас есть звуковая карта?').
'вопрос'('Система загрузилась без ошибок?').
'если' 'Работает ПК?' 'то' 'вопрос'-'Вы не нуждаетесь в услугах экспертной системы'.
'если' 'не' 'Работает ПК?' 'то' 'вопрос1'-'пк включается'.
'если' 'вопрос1'-'пк включается' 'и' 'ПК включается?' 'то' 'вопрос2'-'изображение'.
'если' 'вопрос1'-'пк включается' 'и' 'не' 'ПК включается?' 'то' 'вопрос1'-'свет есть'.
'если' 'вопрос1'-'свет есть' 'и' 'Свет есть?' 'то' 'вопрос'-'Поломался блок питания'.
'если' 'вопрос1'-'свет есть' 'и' 'не' 'Свет есть?' 'то' 'вопрос'-'Включите свет'.
'если' 'вопрос2'-'изображение' 'и' 'Изображение есть на мониторе?' 'то' 'вопрос3'-'писк'.
'если' 'вопрос2'-'изображение' 'и' 'не' 'Изображение есть на мониторе?' 'то' 'вопрос3'-'мониторсеть'.
...Надеюсь сдам все это на отлично в ближайший понедельник
Ресурсы
Компонент для Borland C++ Builder 6 AMZI Prolog LSEngine (1923)
Файлы A_MW3D.DLL и AMZI.PAS если потребует C++Builder нужно разместить в папку с проектом.
Проект C++ Builder 6 реализации экспертной системы (2692)
Скажу вам по секрету, знания об этой технологи передаются из старшего курса в младший курс уже около трех лет
Экспертные системы, достаточно мощная тема на западе а у нас их промышленной разработкой никто почти не занимается.
А вообще две фирмы всего нашел по запросу Экспертные системы, остальное ссылки на литературу
Можешь разъяснить парой слов, чем реализация на пролог лучше чем, если бы это все делалось с помощью каких либо алгоритмов просто на С++?
И еще как бы ты посоветовал делать ЭС, какие интересные идеи там можно реализовать, чтобы она смотрелась достойно (то есть на 5) для Прикладной Информатики?
Есть разные виды ЭС, которые основываются на разных алгоритмах, а также на разных моделях представления знаний. В общем можно сказать, что есть представление знаний, и есть набор алгоритмов (правил) по которым происходит работа со структурами данных (моделью представления знаний). Например, в приведенной ЭС, логика если, то самый простой вариант – булева логика. Также есть и другие логики, в том числе нечеткие, на основе математического аппарата которых, реализуются алгоритмы и модели представления данных. Кроме ЭС основанных на логике, есть например ЭС, реализованные на семантических сетях, или например на фреймовой модели представления знаний – вот здесь уже лучше использовать алгоритмические языки,такие как С++.
В данной ЭС на С++ реализован пользовательский интерфейс программы, так как пролог не имеет возможности построения оконного пользовательского интерфейса, а ядро ЭС реализовано на прологе, который для логики более предназначен.
Я думаю стоит взглянуть на те функции, которые должна выполнять ЭС, или по другому в каких режимах должна работать – режим работы с экспертом, когда человек, который компетентен в области знаний по которой составляется база знаний ЭС, составляет базу знаний – редактирует. Второй режим – собственно работа ЭС, когда пользователь работает с ЭС, и получает от нее знания, и заключения. Исходя из перечисленных режимов работы, нужно и реализовывать две функциональные возможности – это и будет твердая пять и готовый программный продукт, который можно будет даже продавать.
А вообще если это курсовой проект, то лучше обговорить с преподавателем его требования к программе для оценки пять.
да в том то и дело что это дипломный проект, а руководитель совсем не компетентен в этой области, вот и думаю, прошу совета как лучше, ну ладно спасибо и на том:) на самом деле многое почерпнул из твоего ответа, ОГРОМНОЕ спасибо!
Удачно сделать дипломный проект. Если что помогу советом.
Я снова за советом:)
Подумав, поразмыслив, я решил делать экспертную систему с использованием клиент-серверной технологии, чтобы база знаний (правила) находились на удаленном сервере, а пользователь при помощи разработанного клиентского приложения подключался к ней, вводил свои симптомы и после обработки их программой она выводила бы диагноз. Почему именно клиент – серверная технология, потому что можно обеспечить большое хранилище данных, на основе знаний докторов, своевременное наполнение новыми данными базы знаний, а так же постоянный доступ к обновленной информации, без установки каких либо дополнительных обновлений. А так же возможность реализации WEB-приложения, для диагностики пациентов в режиме реального времени. Еще один большой плюс в том что не придется делать огромное количество правил со всевозможным перебором всех вариантов симптомов и болезней, как это было во фреймовой модели БЗ для оболочки ESWIN, для того чтобы выдать пользователю ближайший диагноз по введенным им симптомам, если они не совпажают на сто процентов с реальными симптомами того или иного диагноза.
Как все это будет происходить: пусть есть диагноз Y, у него есть пять симптомов: x1, x2, x3, x4, x5. Y(x1, x2, x3, x4, x5). Допустим пользователь ввел всего 2 симптома, которые есть в диагнозе Y, это x1 и x2, программа свормирует sql запрос, который по этим симптомам выберет нам подходящий диагноз. Для выбраного диагноза так же можно будет подсчитать процент уверенности слежующим образом: если всего в выбранном диагнозе 5 симптомов, а мы введи 2 из этого числа симптомов, то обычной пропорцией высчитываем (2*100)/5=25%. В процессе выбора диагноза по симптомам из БЗ, система может выбрать несколько диагнозов, и для каждого из них будет расчитан процент уверенности. Преимущество в том, что правил получается как бы множество, а на самом деле в БЗ правила лиш о диагнозах и симптомах. По идее сокращается нагрузка на БЗ и увеличивается скорость поиска оптимального решения.
Ну и в итоге планируется сделать 3 модуля:
Модуль Expert, предназначен для авторизованных пользователей пользователей, которые будут иметь права, для добавления правил в базу знаний, их редактирования и удаления.
Модуль Klient, предназначен для диагностики пациентов.
Модуль Administrator, предназначен для добавления пользователей и наделение их правами редактировать базу знаний.
А так же web – сервис для on-line диагностики.
Вопщем, хочу услышать твое мнение об этой идее. И еще как бы лучше тему придумать? Вот что мне пришло на ум: Разработка и создание экспертной системы для диагностики пациентов с использованием клиент-серверной технологии
Идея хорошая с клиент-серверной технологией. Отмечу один минус, база знаний и база данных это ни одно и тоже, и хранить знания в реляционной БД не совсем хороший вариант, не смотря на то, что sql гибок и им можно выбирать данные по различным критериям. Конечно, есть и исключения, если структура реляционной БД подходит для хранения знаний, то почему бы не использовать.
Если близок пролог могу еще посоветовать на сайте amzi.com есть такой продукт Amzi! Prolog + Logic Server – именно Logic Server интересен, здесь уже правил а и факты не хранятся в файле, а удаленно на сервере, и к правилам и фактам также можно обращаться пролог командами, и выбирать необходимые результаты.
Лицензия правда на данный продукт стоит очень даже недешево, но я думаю есть бесплатные аналоги.
На счет использования реляционной БД: мне интуиция подсказывает, что будет на sql запросах накручена очень сложная логика.
Название подкорректирую: «Разработка экспертной системы диагностики пациентов с применением клиент-серверной технологии».
По модулям, я так понимаю будет еще Windows приложение?
Ну да Windows приложение это и есть модули Expert, Klient и Administrator. Пролог к сожалению я вообще не знаю, мы его не учили да и сам интереса не проявил. Можно попытаться конечно если ты мне посоветуеш какой нибудь ускоренный курс пролога. Насчет sql логики, я когда думал мне она вообще показалась очень простой, веть не сложный же запрос выбрать информацию из одной таблицы по информации из другой, связаны они между собой внешними ключами, усложняются запросы когда придется считать вероятность, это да, но есть идеи с оптимизацией и думаю будет нормально. Насчет базы данных и базы знаний, да, тут разграничить их трудно, единственное что приходит на ум это: «база знаний представляет собой таблицу базы данных системы». Хотел бы скинуть логическую модель которую я нарисовал, да тут не получается, как бы тебе можно ее передать?
zhuravskiy.vs[at]gmail.com
я отправил, но если не пришло то вот:
http://www.photoshare.ru/photo4668223.html
А зачем связаны пользователи и правила? В этом заключается какая-то бизнесс логика приложения?
Отношения между сущностями я думаю должны быть такими, чтобы было не сложно (удобно) выбирать нужные данные из БД.
А зачем связаны пользователи и правила? В этом заключается какая-то бизнесс логика приложения?
Отношения между сущностями я думаю должны быть такими, чтобы было не сложно (удобно) выбирать нужные данные из БД.
Правила связаны с пользователем для того, чтобы потом организовать авторизованный доступ к модулю эксперт, ну и просмотра какие правила добавлял тот или иной пользователь? А модель в принципе правильная да? Ничего лишнего, ничего не достающего?
О успешности модели сразу сказать ничего не смогу, тебе необходим взять несколько болезней, с симптомами, и попробовать заполнить таблицы, а потом все это выбрать SQL запросами, возможно придется как-то расширить таблицу правил, возможно ввести какой либо коэффициент – например после каждой работы с пользователем, в зависимости от его ответов, корректировать эти коэффициенты, их можно задействовать в вычислении вероятности, например в тех случаях когда у ЭС, в результате анализа БЗ – есть несколько результатов.
опять я, но уже с просьбой:) у тебя нет примера реализации алгоритма «обратного логического вывода» для поиска решения в базе знаний, желательно бы на C++, или может знаешь где расписано все очень хорошо?
Видишь чем плох SQL для применения в таких задачах. Про обратный логический вывод знаю в двух словах, что если условие записанное в конце условия истинно, то вычисление предыдущих выражений не происходит, если я не ошибаюсь.
Гугл подсказал два сайта:
http://rriai.org.ru/pryamoy-i-obratnyiy-logiche...
http://chernykh.net/content/view/361/563/
думаю есть и еще
Готовых алгоритмов нет к сожалению нет, в курсе по ЭС, мы проходили специализированные языки и программы для создания ЭС, реализация на Си было бы слишком низкоуровневым решением для реализации данных задач.
Без обратного вывода никак?
да нет, ну почему не происходит вычисление, алгоритм какой: мы находим правило, выводом которого является цель, потом берем предпосылки этого правила и ищем не являются ли они где так же выводом, ну и так далее, дойдя до вершины, последовательно задаем вопросы найденным предпосылкам, установив значение находим цель. А почему на Си слишком низкоуровнево? Да можно сделать на каком либо другом языке, но какой из них поддерживает клиент-серверную технологию? Просто хотелось сделать именно так, потому что если делать как делают все, по традиции, то ничего то нового я не внесу. Да и потом я продумывал если делать с реляционной БД, то существенно возрастает скорость поиска, просто если все делать на файлах и будет слишком много записей, представь как долго будет думать комп. Да и может правда есть в других специализированных языках, поддержка клиент-серверной технологии?
Не знаю на сколько мой совет поможет, возможно поступить двумя способами как я вижу:
1. Создать структуру данных типа N-арного дерева, где в узлах будут храниться данные выбранные из бд, ты будешь «бегать» по этому дереву, как по списку, и выбирать все, что тебе необходимо. На днях напишу пост, я реализовывал на подобие ЭС.
2. Сделать логику на SQL запросах и выбирать необходимые данные, т.е. не загружая все данные, также можно придумать удобную структуру данных в виде класса, для их хранения и работы с ней.
Возможны варианты, то как и с чем ты привык работать.