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

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

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

Процесс разработки промышленной экспертной системы, опираясь на традиционные технологии [4,8,10], можно разделить на шесть более или менее независимых этапов (рис 16.7), практически не зависимых от предметной области.

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

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

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

ЭТАП 1: ВЫБОР ПОДХОДЯЩЕЙ ПРОБЛЕМЫ

Этот этап включает деятельность, предшествующую решению начать разрабатывать конкретную ЭС. Он включает:

определение проблемной области и задачи;

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

определение предварительного подхода к решению проблемы;

анализ расходов и прибыли от разработки;

подготовку подробного плана разработки.

Рис. 16.7. Этапы разработки ЭС

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

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

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

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

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

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

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

большое расхождение между решениями самых хороших и самых плохих исполнителей;

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

Подходящие задачи имеют следующие характеристики:

не зависят в значительной степени от общечеловеческих знаний или соображении здравого смысла;

o не являются для эксперта ни слишком легкими, ни слишком сложными (время, необходимое эксперту для решения проблемы, может составлять от трех часов до трех недель);

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

имеет результаты, которые можно оценить.

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

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

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

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

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

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

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

После того как инженер по знаниям убедился, что:

• данная задача может быть решена с помощью экспертной системы;

• экспертную систему можно создать предлагаемыми на рынке средствами;

• имеется подходящий эксперт;

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

• затраты и срок их возвращаемости приемлемы для заказчика.

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

ЭТАП 2: РАЗРАБОТКА ПРОТОТИПНОЙ СИСТЕМЫ

Понятие прототипной системы

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

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

Рис.16.8.Стадии разработки прототипа ЭС

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

Сроки приведены условно, так как зависят от квалификации специалистов и особенностей задачи.

Идентификация проблемы

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

необходимые ресурсы (время, люди, ЭВМ и т.д.);

источники знаний (книги, дополнительные эксперты, методики);

имеющиеся аналогичные экспертные системы;

цели (распространение опыта, автоматизация рутинных действий и др.);

классы решаемых задач и т.д.

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

Средняя продолжительность 1 — 2 недели.

Извлечение знаний

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

наблюдение и другие.

Извлечение знаний — получение инженером по знаниям наиболее полного представления о предметной области и способах принятия решения в ней.

Средняя продолжительность 1 -3 месяца.

Структурирование или концептуализация знаний

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

список основных понятий и их атрибутов;

отношения между понятиями;

структура входной и выходной информации;

стратегия принятия решений;

ограничения стратегий и т.д.

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

Такое описание называется полем знаний. Средняя продолжительность этапа 2 — 4 недели.

Формализация.

Строится формализованное представление концепций предметной области на основе выбранного языка представления знаний (ЯПЗ). Традиционно на этом этапе используются:

логические методы (исчисления предикатов I порядка и др.);

продукционные модели (с прямым и обратным выводом);

объектно-ориентированные языки, основанные на иерархии классов, объектов и др.

Формализация знаний — разработка базы знаний на языке, который, с одной стороны, соответствует структуре поля знаний, а с другой — позволяет реализовать прототип системы на следующей стадии программной реализации.

Все чаще на этой стадии используется симбиоз языков представления знаний, например, в системе ОМЕГА [7] — фреймы + семантические сети + полный набор возможностей языка исчисленияпредикатов. Средняя продолжительность 1 — 2 месяца.

Реализация

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

программирование на традиционных языках типа Паскаль, Си и др.;

программирование на специализированных языках, применяемых в задачах искусственного интеллекта: LISP [14], FRL [I], SmallTalk [7] и др.;

использование инструментальных средств разработки ЭС типа СПЭИС [З], ПИЭС [11];

использование «пустых» ЭС или «оболочек» типа ЭКСПЕРТ [2], ФИАКР [7] и др.

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

Средняя продолжительность 1 — 2 месяца.

Тестирование

Оценивается и проверяется работа программ прототипа с целью приведения в соответствие с реальными запросами пользователей. Прототип проверяется на:

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

• эффективность стратегии управления (порядок перебора,использование нечеткого вывода и др.);

• качество проверочных примеров;

• корректность базы знаний (полнота инепротиворечивость правил).

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

Средняя продолжительность 1 — 2 недели.

ЭТАП 3: РАЗВИТИЕ ПРОТОТИПА ДО ПРОМЫШЛЕННОЙ ЭС

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

Если первоначально выбранные объекты или свойства оказываются неподходящими, их необходимо изменить. Можно сделать оценку общего числа эвристических правил, необходимых для создания окончательного варианта экспертной системы. Иногда [14] при разработке промышленной системы выделяют дополнительные этапы для перехода: демонстрационный прототип — исследовательский прототип — действующий прототип — промышленная система.

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

Понятие же коммерческой системы в нашей стране входит в понятие промышленный программный продукт, или промышленной ЭС в этой работе (табл. 16.1).

Таблица 6.1. Переход от прототипа к промышленной экспертной системе

Демонстрационный прототип ЭС

Система решает часть задач, демонстрируя ж из неспособность полхода (несколько десятков правил или понятий)

Исследовательский прототип ЭС

Система решает большинство задач, но не устойчива в работе и не полностью проверена [несколько сотен правил или понятий)

Действующий прототип ЭС

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

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

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

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

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

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

ЭТАП 4: ОЦЕНКА СИСТЕМЫ

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

критерии пользователей (понятность и «прозрачность» работы системы, удобство интерфейсов и др.);

критерии приглашенных экспертов (оценка советов-решений, предлагаемых системой, сравнение ее с собственными решениями, оценка подсистемы объяснений и др.);

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

ЭТАП 5: СТЫКОВКА СИСТЕМЫ

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

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

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

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

Пример 16.15. Успешно состыкована со своим окружением система PUFF — экспертная система для диагностики заболеваний легких [10]. После того, как PUFF была закончена и все были удовлетворены ее работой, систему перекодировали с LISPa на Бейсик. Затем систему перенесли на ПК, которая уже работала и больнице. В свою очередь, эта ПК была связана с измерительными приборами. Данные с измерительных приборов сразу поступают в ПК. PUFF обрабатывает эти данные и печатает рекомендации для врача. Врач в принципе не взаимодействует с PUFF. Система полностью интегрирована со своим окружением — она представляет собой интеллектуальное расширение аппарата исследования легких, который врачи давно используют.

Пример 16.16. Другая система, которая хорошо функционирует в своем окружении, — САТ-1 [8] — экспертная система для диагностики неисправностей дизелей локомотивов.

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

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

ЭТАП 6: ПОДДЕРЖКА СИСТЕМЫ

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

Пример 16.17. Удачным примером ЭС, внедренной таким образом, является XCON (R1) — ЭС, которую фирма DEC использует для комплектации ЭВМ семейства VAX. Одна из ключевых проблем, с которой столкнулась фирма DEC, — необходимость постоянного внесения изменений для новых версий оборудования, новых спецификаций и т.д. Для этой цели XCON поддерживается в программной среде OPS5.

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

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

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

• созданы системы медицинской диагностики, которые по набору симптомов назначают анализы, по результатам которых ставится диагноз и определяется курс лечения [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

Искусственный интеллект на практике: создаём экспертную систему для приготовления шашлыка

В статье на примере советов по приготовлению шашлыка описаны основные принципы работы экспертных систем: от создания базы знаний и до релиза.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

База знаний

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

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

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

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

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

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

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

Переменные:

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

Правило:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

База знаний

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

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

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

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

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

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

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

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

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

Разрабатываем экспертную систему. Урок 1 . Немного теории.

В прежние времена экспертные системы были закрыты для широкого круга пользователь компьютеров. Они были ориентированы на мощные ЭВМ и использовали для своего создания сложный и геморройный язык программирования ЛИСП (язык обработки списков), что создавало дополнительные проблемы в их освоении. В рамках данного цикла уроков мы разработаем экспертную систему руководствуясь книгой Криса Нейлора «Как построить свою экспертную систему». В этой книге приведены простые примеры экспертных систем на языке программирования БЕЙСИК. Мы же переведем их на Delphi с использование объектно-ориентированного программирования.

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

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

Перечислим в качестве примера задачи, которые может решать экспертная система, взятых из книги «Как построить свою экспертную систему»:

• Диагностика общих болезней.
• Поиск неисправностей в простых цепях.
• Диагностика болезней растений.
• Анализ электрокардиограмм.
• Классификация животных, птиц или растений по видам.

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

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

Поехали дальше. Для начала развеем типичные мифы по поводу экспертных систем:

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

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

Теперь давайте попробуем разобраться, как будет храниться база знаний в памяти компьютера. Крис Нейлор в своей книге предлагает использовать матрицу (двумерный массив), которая доступна как в языке программирования БЕЙСИК, так и на в Delphi. Строки матрицы — это входящие параметры, наблюдения, столбцы — возможные варианты решений (предсказаний). В ячейках матрицы мы будем хранить вероятности (или весовые коэффициенты) решений (предсказаний) в зависимости от исходных данных.

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

Мы же можем создать экспертную систему с другой областью запросов. Например, пойдет завтра Газпром вверх или вниз? Соответственно, у нас будут и другие входные данные. Например, сегодня Газпром рос? Сегодня индекс РТС рос? Месяца назад Центробанк повышал учетную ставку?

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

© 2023 Программирование — это просто

Joomla! — свободное программное обеспечение, распространяемое по лицензии GNU/GPL.
Русская локализация © 2005-2008 Joom.Ru — Русский Дом Joomla!