Средства формирования пояснений

Проект Explainable Expert Systems

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

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

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

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

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

Структура оболочки 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. Используя организованную таким образом базу знаний, экспертная система может предложить программисту-пользователю заменить оператор другим оператором, смысл которого более понятен при анализе текста программы: (IF (АТОМ X) THEN X ELSE (CAR X)).

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

Включение нового концепта в семантическую сеть знаний

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

Генератор программ работает по принципу нисходящего (сверху вниз) уточнения, выполняя декомпозицию целей на подцели. Так, главная цель программы PEA -- усовершенствовать программу -- разделяется на подцели, например: улучшить читабельность. Разработчики системы назвали такой процесс декомпозиции целей "динамическим уточнением, направляемым пользователем", поскольку характер действий, выполняемых создаваемой системой, определяется инженером по знаниям, формирующим базу знаний. Если выбрана определенная цель, скажем, улучшить читабельность, то она автоматически становится субъектом процесса дальнейшей декомпозиции цель/подцель. Например, следующими подцелями будет просмотр текста программы и выявление в нем синтаксических конструкций, которые можно безболезненно заменить другими, более понятными, получение подтверждения от пользователя, одобряющего предлагаемую замену, выполнение замены и т.д. Фрагмент предыстории разработки системы PEA, в котором отображена описанная декомпозиция, представлен на рис.

Фрагмент предыстории разработки системы PEA, в котором отображена декомпозиция цели на подцели ([Moore, 1995])

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

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

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

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

Планирование текстов пояснений и модели пользователей в PEA

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

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

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

Вместо сценариев Мур использовал операторы планирования, в которых специфицируются определенные цели диалогового процесса, например передать пользователю информацию о мотивации некоторого действия системы. Каждое правило в операторе планирования имеет список условий, при выполнении которых применение оператора даст желаемый эффект. Ниже представлен перевод на "человеческий язык" оператора планирования, побуждающего пользователя (собеседника программы) выполнить определенное действие, например, заменить какую-либо программную конструкцию языка LISP, если речь идет об области применения системы PEA.

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

ЕСЛИ

Операция представляет собой шаг к достижению некоторой цели (целей), приемлемой для собеседника, и

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

Мотивировать это действие в терминах целей.

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

Уточнение целей при планировании диалога с пользователем

В составе программы нужно также иметь какое-то средство, которое помогло бы определить, достигнута ли цель, поставленная в плане диалога. Например, согласился ли пользователь с тем, что использование оператора IF делает текст программы более читабельным. Таким образом, необходимо динамически формировать модель поведения пользователя (его предпочтений и доверия к программе) и, сверяясь с этой моделью, проверять, удовлетворяются ли условия использования конкретного оператора планирования. В общих чертах это напоминает тот способ обращения к модели мира, который использовался в STRIPS при выяснении, можно ли протолкнуть ящик из одной комнаты в другую (см. главу 3). Но дополнительную сложность вносит необходимость представлять в модели такие понятия, как доверие и предпочтения пользователя. В системе PEA модель отдельного пользователя формируется на базе стереотипа пользователя, который обладает некоторой усредненной суммой знаний. Например, если речь идет о программировании на языке LISP, т.е. о той области, в которой применяется PEA, то следующий набор выражений представляет те знания, которыми обычно располагают пользователи:

(COMPETENT USER (DO USER REPLACE))

(KNOW-ABOUT USER (CONCEPT PROGRAM))

(KNOW-ABOUT USER (CONCEPT LISP-FUNCTION))

(KNOW-ABOUT USER (CONCEPT S-EXPR))

(KNOW-ABOUT USER (CONCEPT READABILITY))

(KNOW-ABOUT USER (CONCEPT MAINTAINABILITY))

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

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

Перспективы дальнейших исследований методов формирования пояснений

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

Проект EES служит хорошим примером одного из направлений в современной методологии инженерии знаний, которое предполагает разделение процесса на этапы спецификации знаний и компиляции системы. Но пока что совершенно неясно, как такая методология может справиться с задачей комбинирования разных стратегий решения проблем в рамках единой системы (как это выполняется, например, в системе CENTAUR). Основная сложность в использовании этой методологии -- большой объем предыстории разработки и необходимость использования чрезвычайно мощного генератора программ (см. об этом в [Neches et al, 1985]). Альтернативой такому подходу является усложнение интерпретатора включением в него мощных управляющих примитивов. В результате предыстория разработки сокращается, и снижаются требования к функциональным возможностям генератора программ, но информация о принятии решений, касающихся поведения программы, оказывается спрятанной в программном коде интерпретатора. Интересно звучит предложение дополнительно нагрузить генератор программ -- заставить его формировать и интерпретатор, и информацию, необходимую для формирования пояснений относительно управляющих функций. Это должно привести к еще большему разделению управляющих знаний и знаний о предметной абласти, но, предположительно, одновременно поставит перед разработчиками множество проблем, связанных с интеграцией компонентов системы.

Из приведенного краткого и довольно поверхностного описания проекта EES вы уже могли сделать вывод, что проблема автоматизации формирования пояснений является чрезвычайно сложной. Но этого описания достаточно, чтобы представить, на чем сосредоточено основное внимание исследователей в этой области. Можно выделить такие основные направления:

1) дифференциация знаний;

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

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