Формирование пояснений на основе фреймов

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

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

Организация вывода пояснений в системе CENTAUR

Первый вариант реализации системы PUFF, который был выполнен на основе оболочки EMYCIN (см., например, [Aikins et al., 1984]), оказался вполне работоспособным в том смысле, что хорошо справлялся с решением проблем в своей области, но схема представления знаний в нем не совсем удовлетворила разработчиков по следующим причинам.

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

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

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

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

Эйкинс (Aikins) также обратила внимание на то, что отчетливо выраженная модульность и единообразие порождающих правил имеет и обратную сторону. Большинство наборов правил обладает неявно выраженной группировкой, которая существует либо в виде определенного порядка индексации, скрытой в интерпретаторе (например, в наборе ORGRULES и PATRULES системы MYCIN, которые относятся к микроорганизмам и пациентам соответственно), либо в виде условий и операций, которые манипулируют лексемами целей в рабочей памяти. Такая организация зачастую имеет иерархический характер, предполагающий таксономический характер организации гипотез (в задачах классификации) и декомпозицию целей на подцели (в задачах конструирования). Многие из упомянутых выше проблем можно свести к минимуму, выделив отдельные виды знаний и манипулируя ими по-разному. Как вы помните из главы 13, в системе CENTAUR разработчики объединили методы программирования, основанные на правилах и концепции фреймов, таким образом, чтобы компенсировать слабости каждого из подходов и усилить их достоинства.

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

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

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

В ходе выполнения программы прототип находится в одном из трех возможных состояний:

неактивный, т.е. не рассматриваемый в качестве гипотезы;

потенциальный кандидат, т.е. такой, который имеет смысл рассмотреть исходя из имеющихся значений данных;

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

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

Основные события в сеансе выполнения консультации с помощью системы CENTAUR следующие:

ввод исходных данных;

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

оценка прототипов и выбор единственного, который назначается "текущим";

анализ известных фактов и заполнение на их основе полей данных текущего прототипа;

проверка соответствия фактов и ожидаемых значений;

выявление данных, не учтенных начальным вариантом диагноза;

уточнение диагноза на основе выявленных данных;

Суммирование и вывод результатов.

В самом начале сеанса в качестве текущего выбирается прототип CONSULTATION (консультация), а в список активных включаются две задачи текущего прототипа: FILL-IN (заполнение) и CONFIRM (подтверждение), которые извлекаются из управляющих слотов TO-FILL-IN и IF-CONFIRMED прототипа. Структура слотов прототипа CONSULTATION представлена ниже.

CONSULTATION

....................

TO-FILL-IN:

Запросить значение

TRACING-LEVEL для задачи

CONSULTATKDN Запросить значение

AGENTA-PRINTING для задачи

CONSULTATION Запросить значение

STRATEGY для задачи

CONSULTATION

IF-CONFIRMED:

Установить порог подтверждения равным 0

Установить относительное заполнение слотов, необходимое для подтверждения прототипа, равным 0.75

Установить процедуру по умолчанию для заполнения слотов: заполнение в убывающем порядке по степени важности Определить предмет консультации Выбрать лучший из текущих прототипов Заполнить прототип

Применить задачи из слота IF-CONFIRMED прототипа Отметить все факты, принимаемые во внимание прототипом Применить правила уточнения, связанные с подтвержденными прототипами; применить правила подведения итога, связанные с подтвержденными прототипами; выполнить операции, связанные с подтвержденными прототипами

Слот TO-FILL-IN прототипа фактически содержит три подзадачи, каждая из которых устанавливает определенную переменную сеанса консультаций: переменная TRACING-LEVEL задает уровень детализации трассировки, переменная AGENTA-PRINTING указывает, будут ли выводиться на печать наименования задач по мере включения их в список активных или по мере выполнения, а переменная STRATEGY может принимать значения CONFIRMATION (выбор наилучшего варианта и подтверждение его), или ELIMINATION (выбор наихудшего варианта и исключение его), или FIXED-ORDER (использование предопределенного порядка обработки гипотез).

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

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

------ПАЦИЕНТ-7 -------------