Оболочка экспертной системы MINERVA

MINERVA— это оболочка экспертной системы, разработанная на базе EMYCIN и NEOMYCIN (см. главы 10-12). Система MINERVA обеспечивает ODYSSEUS базой знаний и методом решения проблем и разработана специально для поддержки метода обучения EBL. Одно из главных отличий системы MINERVA от EMYCIN состоит в том, что в ней представлены не только знания о предметной области, но и стратегические знания, отражающие способ мышления практикующего врача. Такие знания можно рассматривать как дальнейшее развитие метаправил систем MYCIN, EMYCIN и NEOMYCIN.

Главным компонентом этой системы является база медицинских знаний о диагностировании менингита и других неврологических заболеваний. MINERVA реализована на языке PROLOG, и знания о предметной области представлены в этой системе в виде фраз Хорна (см. главу 8), но правила по содержанию аналогичны тем, что использовались в MYCIN. Например, следующее выражение представляет тот факт, что фотофобия может быть связана с головной болью:

Conclude(migraine-headache, yes)

:- finding(photophobia, yes).

Знания о состоянии проблемы записываются в виде выражений для фактов в процессе работы системы. Например, выражение

Rule-applied(rulel63).

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

Differential(migraine-headache, tension-headache).

Зафиксирует тот факт, что мигрень и повышенное давление — текущие гипотезы, выдвинутые программой.

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

Несложное метаправило может быть представлено в следующем виде: goal(findout(Р)):- not(concluded(P)), ask-user(P).

Это правило утверждает, что если текущая цель системы — найти значение параметра Р и если система не может прийти к заключению о значении этого параметра на основании имеющихся у нее знаний, то она должна запросить его у пользователя. Поскольку Р является переменной, то головная часть выражения goal (findout (Р)) сопоставляется с выражением цели системы, представленным в явном виде, например goal (f indout (temperature)). Подцели вроде not(concluded(P)) могут быть сопоставлены (успешно или нет) с системными данными, описывающими текущее состояние процесса вычислений, например concluded (temperature).

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

Обучение в системе ODYSSEUS

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

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

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

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

Например, если задан вопрос askuser(temprature), то обратный просмотр приведет нас к ближайшей цели goal (f indout (temperature)).

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

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

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

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

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

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

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