Структура задач в системе NEOMYCIN
Опыт, полученный в ходе работы над системой GUIDON, был использован Кленси при разработке более сложной модели выполнения диагностирования, которая получила название NEOMYCIN. При создании базы медицинских знаний для этой консультационной системы была использована доработанная обучающая программа GUIDON2. Главные отличия системы NEOMYCIN от MYCIN состоят в следующем.
- Использованная в системе
процедура вывода суждений наиболее четко отделена от содержимого порождающих
правил, как об этом было сказано в предыдущем разделе при описании программы
GUIDON.
- Процедура вывода суждений
может использовать как прямую, так и обратную цепочку логического вывода.
Кленси утверждает, что поведение NEOMICYN ближе к модели поведения человека при диагностировании, чем поведение MYCIN.
Например, клиницисты обычно стараются определить диапазон возможных заболеваний, которыми может страдать пациент, на основе ограниченного набора анализов. По Кленси такое поведение можно рассматривать как стремление "ограничить пространство гипотез". Одна из стратегий, используемых для этого, называется "сгруппируй и раздели", т.е. задавшись какой-либо начальной гипотезой, правдоподобной при имеющихся данных, врач сначала пытается собрать все другие гипотезы, учитывающие те же признаки и симптомы, а затем разделить их на те, которые подходят к данному случаю, и те, которые должны быть отброшены.
Стратегия диагностирования в системе NEOMYCIN может быть представлена в виде дерева задач, в котором задачей верхнего уровня является КОНСУЛЬТАЦИЯ, в которую в виде подзадач входят ИДЕНТИФИКАЦИЯ ПРОБЛЕМЫ и СБОР ИНФОРМАЦИИ. Именно эта иерархия задач определяет направление потока управления, а не неявная иерархия концептуальных правил, прослеживаемая с помощью методики построения обратной цепочки рассуждений. В дополнение к задаче "сгруппируй и раздели" существуют еще две стратегии, которые помогают сформировать пространство гипотез: "попробуй и уточни" и "задай обобщенные вопросы". Первая предполагает достаточно детальное исследование определенной гипотезы, а вторая служит для сбора фоновой информации (например, можно запросить у пользователя, не беременна ли пациентка, не перенес ли пациент недавно хирургическую операцию).
Обеим задачам — и "сгруппируй и раздели", и "попробуй и уточни" — отводится свое место в контексте сложной иерархии патологий. Стратегия "сгруппируй и раздели" включает анализ той части иерархии, которая находится выше первоначальной гипотезы, и таким образом предпринимается попытка отыскать в этой части конкурирующие гипотезы. Стратегия "попробуй и уточни" включает анализ той части иерархии, которая находится ниже первоначальной гипотезы, и таким образом предпринимается попытка дальнейшего уточнения диагноза.
В следующей главе мы проанализируем весь процесс формирования гипотез и их тестирования в иерархии альтернатив. Здесь же важно обратить внимание на принцип представления в программе стратегии формирования логического вывода явно в структуре задач. Те результаты, которые получил Кленси при разработке конкретной интеллектуальной обучающей системы, могут быть с успехом распространены и на весь класс экспертных систем.
Независимо от того, всеми ли будет одобрена предложенная Кленси методика анализа, можно с уверенностью заявить, что она открыла новые направления в исследованиях в области экспертных систем. Точно так же, как задачи, выполняемые экспертными системами, нуждаются в той или иной форме онтологического анализа, который помогает систематизировать объекты и отношения между ними в конкретной предметной области, они нуждаются и в эпистемологическом анализе видов знаний о способах решения проблем в этой области, которыми обладает эксперт. Эти знания в совокупности со знаниями о том, на какой стадии процесса логического вывода их следует применять, как правило, слишком обширны. Поэтому для их представления недостаточно какого-то одно формализма (например, порождающих правил) и одного режима управления (например, построения обратной цепочки вывода).
Один из подходов к построению экспертных систем (как, впрочем, и любых других программ) — спросить себя, как распределить "сложность" между компонентами проекта. Существуют два крайних варианта — спроектировать конструкцию с достаточно богатыми возможностями, которую можно было бы относительно легко реализовать, или спроектировать простую конструкцию, но сосредоточить главные усилия на стадии кодирования. Это пример реализации принципа "бесплатных ленчей не бывает" в отношении программного обеспечения. Ресурсы, сэкономленные на одном уровне, непременно придется растратить на другом.