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

16.1.4.

Организация вывода пояснений в системе 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 -------------

1) Идентификационный номер пациента: 7446

2) По поводу какого заболевания: АСТМА

[Прототип ASTHMA, МП 900]

3) ООЛ/ООЛ предсказываемый:

261

4) ОЕЛ (плетизмографическая) наблюдаемая/предсказываемая: 139

5) ФЖЕ/ФЖЕ предсказываемая:

[Прототип NORMAL, МП 500]

6) Отношение ОФВ1/ФЖЕ: 40

[Прототип ОАО, МП 900]

7) ПСОУ/ПСОУ предсказываемая: 117

[Прототип NORMAL, МП 7dO]

8) Изменение в ОФВ1 (после приема бронхолитиков): 31

9) УПМС/УПМС предсказываемая:

[Прототип ОАО, МП 900]

10) Наклон П5025: 9

[Прототип ОАО, МП 900]

Рассмотрим подробнее один из вопросов в этом протоколе.

6) Отношение ОФВ1/ФЖЕ: 40 [Прототип ОАО, КУ900]

Аббревиатуры в этих строках обозначают найденные прототипы заболеваний, МП означает "мера правдоподобия", ООЛ, ОЕЛ, ФВЖ и т.д. — результаты лабораторных анализов и измерения легочных функций:

ООЛ — остаточный объем легких, литры;
ОЕЛ — общая емкость легких, литры;
ФУКЕ — форсированная жизненная емкость легких, литры;
ОФВ1 — объем форсированного выдоха за 1 с, литры;
ПСОУ — проникающая способность для окиси углерода.

Введенное пользователем значение 40 отношения объема форсированного выдоха за 1 с (ОФВ1) к форсированной жизненной емкости легких (ФЖЕ) побуждает систему активизировать прототип ОАО (Obstructive Airways Dicease — обтурация воздухоносных путей) с мерой правдоподобности этой гипотезы 900.

Значение меры правдоподобия той или иной гипотезы выбирается в диапазоне от -1000 до 1000 исключительно из соображений упрощения вычислений. Этот параметр отражает степень уверенности системы в обоснованности выдвинутой (активизированной) гипотезы на основе имеющихся данных о конкретной истории болезни. Фактически при определении меры правдоподобия система сравнивает введенные пользователем данные с теми, которые хранятся в слотах прототипа-кандидата. Полученные значения служат основанием для выбора самой правдоподобной из имеющихся гипотез (прототипов). Назначение параметра "мера правдоподобия" в системе CENTAUR такое же, как и коэффициента уверенности в системах MYCIN и EMYCIN, причем для операций с мерами правдоподобия используются те же алгоритмы, что и для операций с коэффициентами уверенности. Обратите внимание — в процессе диалога с пользователем система не объясняет, почему выбрано именно такое, а не иное значение меры правдоподобия. Для пользователя алгоритм вычисления меры правдоподобия является "черным ящиком".

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

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

Гипотеза: ASTHMA, МП: 900. Причина: предыдущий диагноз — АСТМА

Гипотеза: NORMAL, МП: 500. Причина: ФЖЕ равно 81

Гипотеза: ОАО, МП: 900. Причина: отношение ОФВ1/ФЖЕ равно 40

Гипотеза: NORMAL, МП: 700. Причина: ПСОУ равно 117

Гипотеза: ОАО, МП: 900. Причина: УПМС равно 12

Гипотеза: ОАО, МП: 900. Причина: наклон П5025 равен 9

Наиболее правдоподобные гипотезы: NORMAL, ОАО [Новые анализируемые прототипы: NORMAL, ОАО]

Из этой распечатки следует, что далее система сосредоточится на двух наиболее правдоподобных гипотезах: NORMAL и OAD. Эти две гипотезы являются непосредственными "наследниками" прототипа PULMONARY-DISEASE. Рассмотрение гипотезы ASTHMA на время откладывается по той причине, что она является подтипом гипотезы OAD. Эта гипотеза будет рассмотрена в процессе уточнения гипотезы OAD, в полном соответствии со стратегией нисходящего уточнения. Иерархическая структура пространства гипотез позволяет дать пользователю полную и ясную информацию о том, как эта стратегия претворяется в жизнь в экспертной системе. В системах, полностью основанных на правилах, пользователь должен представлять себе ту стратегию разрешения конфликтов между конкурирующими правилами, которая используется в системе, и только тогда он сможет понять, почему в определенной ситуации было отдано предпочтение именно той гипотезе, которая зафиксирована в распечатке результата трассировки, а не какой-либо иной.

Обратите внимание — не все данные, введенные пользователем в ходе начального диалога, приводят к выбору гипотез-кандидатов, а в список гипотез-кандидатов попадает несколько прототипов. При заполнении данными отобранных в этом списке двух гипотез — NORMAL и OAD — такой параметр, как ОЕЛ (общая емкость легких), который в ходе диалога не повлиял на начальный список, будет учтен и, вполне возможно, повлияет на значение меры правдоподобия анализируемой гипотезы. Значение этого параметра (139) заставляет систему подвергнуть сомнению правдоподобность гипотезы NORMAL, как будет показано ниже в примере распечатки значений тех параметров, которые привели систему "в замешательство". Данные, которые "не вписываются" в диапазон, представленный в слотах определенных прототипов, заставляют систему снижать меру правдоподобия соответствующей гипотезы.

!.Неожиданное значение: ООЛ равно 261 в NORMAL, МП: 700

!Неожиданное значение: ОЕЛ равно 139 в NORMAL, МП: 400

!Неожиданное значение: ОФВ1/ФЖЕ равно 40 в NORMAL, МП: -176

!Неожиданное значение: УПМС равно 12 в NORMAL, МП: -499

!Неожиданное значение: П5025 равно 9 в NORMAL, МП: -699

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

Список гипотез: (ОАО 999) (NORMAL -699)

Проверяется гипотеза ОАО (ОБТУРАЦИЯ ВОЗДУХОНОСНЫХ ПУТЕЙ)

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

[Выполнение уточняющих правил ...]

20) Число "пачко-лет" курения: 17

21) Как давно пациент бросил курить: 0

22) Степень затруднения дыхания: НЕТ

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

[Выполняются действия, заданные в слоте ACTION прототипа ОАО ...]

Заключение: показания, свидетельствующие в пользу диагноза "Обтурация воздухоносных путей", следующие:

Увеличенные объемы легких указывают на гипернаполнение.

Увеличенное значение отношения ООЛ/ОЕЛ согласуется с наличием тяжелой обтура-ции воздухоносных путей. Форсированная жизненная емкость в норме, но отношение ОФВ1/ФЖЕ понижено, что указывает на обтурацию воздухоносных путей в тяжелой форме.

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

После приема бронхолитиков улучшается проходимость воздухоносных путей, что подтверждается изменением значения ОФВ1.

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

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

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

Пример окончательного заключения, которое выполняется правилами, хранящимися в слоте ACTION прототипа PULMONARY-DISEASE, представлен ниже.

[Выполняются действия, заданные в слоте ACTION прототипа PULMONARY-DISEASE ...]

-------Заключение--------

— Обтурация воздухоносных путей------

Диагноз "Обтурация воздухоносных путей" сделан на основании следующих фактов:

Отношение ОФВ1/ФЖЕ для ПАЦИЕНТА-7: 40

Отношение УПМС/УПМС-предсказываемая для ПАЦИЕНТА-7: 12

Значение наклона П5025 для ПАЦИЁНТА-7: 9

Кроме того, диагноз "Обтурация воздухоносных путей" согласуется со следующими

данными:

Отношение ОЕЛ/ОЕЛ-предсказываемая для ПАЦИЕНТА-7: 139

Отношение ООЛ/ООЛ-предсказываемая для ПАЦИЕНТА-7: 261

Значение П25 для ПАЦИЕНТА-7: 45

Степень затруднения дыхания для ПАЦИЕНТА-7: НЕТ

Интенсивность кашля для ПАЦИЕНТА-7: НЕТ

При установлении диагноза "Обтурация воздухоносных путей" должны приниматься во внимание следующие показания:

Ранее поставленный диагноз для ПАЦИЕНТА-7

Отношение ОФВ1/ФЖЕ для ПАЦИЕНТА-7

Значение П25 для ПАЦИЕНТА-7

Степень затруднения дыхания для ПАЦИЕНТА-7

Интенсивность кашля для ПАЦИЕНТА-7

Все указанные факты были приняты во внимание при подтверждении прототипа.

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

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

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

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

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

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

Система CENTAUR задает пользователю вопросы в том случае, когда ей не удается выделить необходимую информацию из правил или когда она нуждается в значениях параметров, помеченных в правилах маркером "ask-first" (сначала спроси). Вопросы, которые пользователь может задавать системе CENTAUR, по своему характеру напоминают вопросы "КАК" и "ПОЧЕМУ", которые возможны и при работе с системой EMYCIN, но они интерпретируются в зависимости от текущей стадии процесса консультации. Так, вопрос "ПОЧЕМУ", заданный в контексте конкретного прототипа в ходе выполнения этапа формирования диагноза, будет интерпретироваться как "Почему рассматривается именно данный прототип?" Такой же вопрос на этапе просмотра исходных данных будет интерпретироваться по-другому: "Почему данный прототип подтверждается?" Система CENTAUR всегда предоставляет пользователю информацию о текущем прототипе, а потому пользователь всегда может ориентироваться, в каком контексте программа задает тот или иной вопрос.

Система CENTAUR включает в протокол формирования заключения не только список подтвержденных прототипов, но и множество дополнительной информации:

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

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

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