Формирование пояснений и автоматическое программирование

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

В этом разделе мы остановимся на двух экспертных системах, XPLAN и PEA, при разработке которых создатели попытались решить указанные проблемы, воспользовавшись специальной программой-оболочкой. Работы выполнялись в рамках исследовательского проекта EES — Explainable Expert Systems (экспертные системы, способные давать пояснения).

Автоматическое программирование в системе XPLAN

Хотя трассировка активизации правил и дает информацию о поведении системы, сама по себе она не может объяснить мотивов этого поведения [Swartout, 1983]. Это объясняется тем, что мотивация поведения является частью знаний, используемых при построении и внедрении программы, и она нигде не представлена явно в виде программного кода. Другими словами, те "знания как", которые заложены в конструкции системы, т.е. принципы логического вывода суждений, как правило, смешаны со "знанием что", т.е. моделью той предметной области, на работу в которой ориентирована конкретная экспертная система. В основу проектирования системы XPLAN, созданной Свотаутом (Swartout), была положена простая, но вместе с тем продуктивная идея увязать процесс разработки экспертной системы с процессом формирования пояснений. Один из методов проектирования экспертных консультирующих систем состоит в том, чтобы выработать спецификацию модели предметной области, включив в нее и принципы функционирования объектов этой области, а затем воспользоваться услугами "автоматического программиста" и сформировать по этой спецификации собственно программу экспертной системы. Предписывающие и описывающие компоненты спецификации объединяются таким образом в единую систему и используются затем для формирования пояснений в процессе функционирования этой системы.

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

Свотаут собрал информацию о тех вопросах, которые задают студенты-медики при работе с консультирующей системой Digitalis Therapy Advisor. В собранном массиве он выделил три базовые группы.

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

Вопросы, касающиеся причин принятия программой того или иного решения. Например, почему программа рекомендует именно такой, а не иной курс лечения.

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

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

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

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

16.2.2. Проект Explainable Expert Systems

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

Система XPLAN создавалась в рамках проекта Explainable Expert Systems (EES) [Heches et al, 1985], [Moore, 1995]. Идея этого проекта вполне созвучна существующей в настоящее время тенденции группировать и представлять в явном виде знания различного вида. Кроме того, в рамках этого проекта предпринята попытка использовать формальные методы, которые позволили бы зафиксировать в базе знаний системы основные решения, принимаемые в процессе ее разработки. Отсутствие таких формальных методов приводит к тому, что информация об основных решениях, положенных в основу проектирования, теряется на стадии реализации системы.

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

Рис. 16.3. Структура оболочки EES ([Neches et al., 1985])

Семантика базы знаний системы EES представлена в виде семантической сети, получившей наименование NIKL [Moser, 1983]. Сеть появилась в результате развития идей, положенных в основу создания сети KL-ONE [Brachman and Schmolze, 1985]. NIKL, так же, как и KL-ONE, формирует множество концептов, имеющих собственную внутреннюю структуру (набор слотов или ролей), между которыми можно задавать отношения (формировать связи). NIKL также имеет в своем составе классификатор, который, располагая информацией о структуре конкретной сети и новом концепте с определенной структурой, может поместить этот новый концепт на соответствующее ему место в общей таксономии концептов.

Пусть, например, в сети имеются узлы концептов ЖИВОТНОЕ, СОБАКА и БЕШЕНОЕ-ЖИВОТНОЕ, а в классификатор поступает новый концепт БЕШЕНАЯ-СОБАКА. В ответ классификатор формирует новый узел для этого концепта и отводит ему место в иерархии. Новый узел будет связан "узами наследования" с узлами СОБАКА и БЕШЕНОЕ-ЖИВОТНОЕ. Это выполняется после анализа свойств и характеристик нового концепта (рис. 16.4). Трудно переоценить способность системы наращивать таким образом базу знаний, которая, как правило, никогда не создается за "один присест".

Исчез (Neches) описал применение оболочки EES для построения экспертной системы Program Enhancement Advisor (PEA). Эта программа предназначена для оказания помощи программистам в повышении "читабельности" текстов программ. В той предметной области, в которой должна работать новая экспертная система, концептами семантической сети являются преобразования элементов программного кода, например замена оператора COND языка LISP на конструкцию IF-THEN-ELSE. Концепт является частным случаем другого концепта, KEYWORD CONSTRUCT, который, в свою очередь, является частным случаем концепта Easy-TO-READ CONSTRUCT. Используя организованную таким образом базу знаний, экспертная система может предложить программисту-пользователю заменить оператор

(COND ((АТОМ X) X) (Т (CAR X)))