После считывания исходной информации машина вывода начинает просмотр базы знаний и последовательно сопоставляет описание задачи с записями БЗ, описывающими ход решения.
Если условие текущего правила БЗ подтверждается множеством исходных фактов, то система выполняет действие, записанное в данном правиле, добавляя в БЗ новые, производные факты.
На первый взгляд процесс вывода кажется достаточно простым – выполняются однотипные операции по перебору записей БЗ и сравнении их с имеющимися фактами, пока не будет найдено решение или некий целевой факт. Однако, управление процессом вывода, независящее от контекста проблемы не практике мало эффективно. При решении реальных задач человек крайне редко прибегает к перебору данных. Вместо этого, люди пользуются эвристическими правилами, которые значительно ограничивают пространство поиска решения и позволяет быстро и эффективно решать задачи. Эвристические знания имеют эмпирическую природу, то есть формируются на базе опыта и интуиции эксперта. Ярким примером превосходства эвристического подхода перед алгоритмическим (основанным на полном или частичном переборе) является игра в шахматы [5]. В начале игры «белые» имеют возможность сделать любой из 20 допустимых ходов, в ответ на который «черные» могут также совершить один из 20 ходов. Нетрудно посчитать, что следующий ход «белых» может быть выбран уже из 400 возможных различных состояний партии. Далее, по мере развития игры возникает неуправляемый комбинаторный взрыв. Особенно остро подобная проблема стоит в эндшпиле. Имея по нескольку фигур на доске, каждый из игроков располагает более чем 50 вариантами возможных ходов. Очевидно, шахматные мастера при всем желании не смогли бы осуществлять перебор ходов, для поиска лучшего варианта. Вместо этого они используют краткосрочные и долгосрочные стратегии. Каждая конкретная стратегия выбирается в соответствии с текущей ситуацией на игровой доске.
Другим более простым примером может служить способ строительства стен «сухим» методом. На первом этапе работы имеется большое количество камней различной формы, из которых нужно сложить ровную и устойчивую стену. Более того, камни могут подвозиться по мере необходимости, и осмотр всех камней в целях перебора может быть в принципе невозможен. Строитель вначале не знает, как и какие именно камни он будет выбирать. В процессе строительства время от времени он осматривает стену, определяет, какие камни остались, и выбирает краткосрочную стратегию, в частности, включающую возврат (удаление камней из стены). Имея один и тот же набор камней, он, возможно, никогда не построит дважды стену одинаково.
Существует два основных типа логического вывода: прямой и обратный.
Прямой вывод соответствует обычному ходу решения задачи – от исходных фактов к целевым. Примером прямого вывода является задача классификации. ЭС осуществляет постепенное обобщение исходных фактов, описывающих свойства исследуемого объекта, выявляя наиболее характерные признаки того или иного класса.
Обратный вывод соответствует, как следует из названия, обратной задаче – определить какие именно факты требуются для подтверждения данной цели.
Этот тип вывода соответствует противоположному ходу решения:
· сначала машина вывода рассматривает те правила БЗ, действием которых является вывод целевого факта.
· Затем выбираются новые подцели из условий этих правил, и
· процесс продолжается от целевых фактов к исходным.
Можно сказать, что при обратном выводе происходит конкретизация свойств исследуемого объекта. Этот вид логического вывода наделяет ЭС новым фундаментальным свойством – способностью объяснить, как было получено решение, или что требуется, для того, чтобы имел место тот или иной факт.
В реальных системах, как правило, используется комбинация из прямого и обратного вывода. А для управления всем процессом логического вывода предназначены метаправила – специальный вид правил БЗ, представляющие собой директивы машины вывода.
Используя метаправила можно упорядочить применение знаний в зависимости от конкретных значений фактов и текущего состояния БЗ.
Продемонстрировать отличие мета правил от обычных правил можно на примере «игрушечной» ЭС. Пусть задачей этой ЭС является размещение мебели (столов, стульев, парт и пр.) в аудиториях университета с учетом требований эргономики, безопасности и т.д. На основании знаний:
· об оборудовании помещения в зависимости от расположения и размеров аудитории,
· от вида занятий (лекции, практика или лабораторные работы) и других параметров,
В БЗ заложены правила предписывающие тот или иной способ размещения мебели. Это обычный вид правил.
Но в данной предметной области может понадобиться уточнить способ решения задачи с помощью метаправил вида:
«Если имеет место свойство X, то сначала применить группу правил N».
Таким метаправилом может быть, например, следующее: «Если аудитория предназначена для лабораторных занятий, то сначала применить правила, касающиеся компьютеров и лабораторного оборудования, а затем мебели».
Если обычные правила БЗ представляют шаги решения задачи, то метаправила описывают стратегию получения решений.
Тот факт, что фактически изменяемой компонентой в архитектуре ЭС является БЗ, наталкивает на закономерный вопрос: «Можно ли взять готовую экспертную систему из одной предметной области, заложить в нее знания из другой предметной области, и получить новую ЭС?»
Для редактирования или даже при полной замене содержимого БЗ не требуется изменение кода ЭС и привлечение программистов, поэтому такой перенос готовых программных решений в принципе возможен. Исследования в этом направлении привели к созданию так называемых оболочек экспертных систем.
Оболочки ЭС включают машину вывода и интерпретатор ЯПЗ, развитый интерфейс разработчика, а также средства проектирования интерфейса пользователя. Наполнение БЗ оболочки позволяет получить ЭС для различных задач. Повторное использование разработанных компонентов ЭС значительно сокращает время разработки новых ЭС.
Однако, как показала практика применения оболочек ЭС, перенос методов решений и средств представления знаний из одной области знаний в другую не всегда возможен. Инструментальные средства, успешно применяемые для одного вида задач, оказываются неэффективными при попытке использовать их для решения других видов задач. Структура и методы описания знаний, в задачах медицинской диагностики и поиска неисправностей в электронных схемах, существенно отличаются от тех, что используются при проектировании технологических цепочек или выборе конфигурации компьютера.
Таким образом, возникло новое направление исследований – классификация экспертных задач, таких как медицинская диагностика, планирование, интерпретация сигналов, и т.п. Были предприняты попытки эвристической классификации методов описания знаний и решения проблем в зависимости от решаемой задачи. Такая классификация стала рассматриваться в качестве этапа, предваряющего выбор методов и инструментов решения задач.
Как уже было отмечено выше, архитектура различных ЭС, с точки зрения входящих в нее программных модулей, идентична практически для любых задач. Детали реализации модулей, конечно, могут сильно отличаются в различных проектах, но их базовый состав и взаимодействие четко определено. Таким образом, при создании ЭС основные усилия должны быть сконцентрированы на проектировании БЗ, в рамках которого выбирается:
· язык представления знаний,
· способы логического вывода и пр.
То есть, несмотря на то, что по своей сути ЭС это программный продукт, разработка новой ЭС сильно отличается от написания новой программы. В случае же если в качестве инструментального средства используется оболочка ЭС, этап программирования вообще исключается из процедуры создания ЭС.
Учитывая вышесказанное, технологию разработки ЭС можно представить схемой, включающей следующие этапы (Рисунок 1–2. Этапы разработки ЭС.):
1.Предварительный этап – этот этап включает деятельность предшествующую решению о разработке новой ЭС. В рамках этого этапа осуществляются конкретизация задачи, подбор экспертов в данной предметной области для совместной работы, выбор подходящих инструментальных средств. Главной особенностью этого этапа является то, что может быть принято решение о нецелесообразности разработки ЭС для выбранной задачи.
2.Этап прототипирования – в ходе этого этапа создается прототип ЭС, предназначенный проверки правильности выбранных средств и методов разработки новой ЭС. К прототипу системы не предъявляются высокие требования. Основная его задача состоит в иллюстрации возможностей будущей системы для специалистов, непосредственно участвующих в разработке, а также для потенциальных пользователей. На этом этапе может быть осуществлена корректировка проекта, уточнены время, стоимость и необходимые ресурсы для завершения работы.
3.Этап доработки – это по сути основной, наиболее рутинный и продолжительный этап работы над ЭС. Все компоненты многократно тестируются и доводятся до соответствия требованиям проекта. Наибольшую сложность вызывает доработка и доказательство адекватности и эффективности БЗ, так как количество записей в ней может быть на порядок больше, чем в прототипе.
На практике граница между этапами может быть размыта, а сам процесс проектирования является достаточно неформальным, так как связан с исследованием и попыткой копирования деятельности человека. Большое количество применяемых эвристик, интуитивный подход к решению задач экспертами делают процесс создания ЭС творческим. Впрочем, формализация технологии ЭС, разработка в ее рамках математических методов и алгоритмов формирования и обработки знаний – это и есть суть современной теории ЭС. Еще одной особенностью разработки ЭС является поэтапное ее внедрение. Первые версии новой ЭС начинают эксплуатироваться в ограниченном объеме уже на этапе прототипирования.