Аппарат простых систем альтернатив представляет собой не более, чем теоретическую основу для построения баз знаний. Практическую проверку этот аппарат прошел при разработке пустой экспертной системы ФИАКР (п. 1.3), которая поддерживает внутреннее представление баз знаний в виде систем альтернатив; соответственно, машина вывода системы ФИАКР реализует процедуру условного логического вывода 2.18. По ходу реализации возникла необходимость исследовать некоторые специальные вопросы ПА-систем. В частности, была усложнена структура множества основных фактов и расширены выразительные возможности модулей знаний.

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

3.1 Организация базы знаний

Система ФИАКР предназначена для построения экспертных систем, поддерживающих процесс принятия решений в задачах распознавания. Система позволяет строить базы знаний в пределах строго определенных (синтаксических) конструкций. Однако, прежде чем перейти к систематическому изложению способа представления знаний, необходимо бегло рассмотреть режим эксперта.

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

3.1.1 Модель проблемной области в системе ФИАКР

Система ФИАКР позволяет формировать признаковые модели проблемных областей (п. 1.2.6), в которых описание внешних признаков, промежуточных суждений и целевых состояний может быть представлено в виде совокупности однозначных атрибутов. Спектры возможных значений атрибутов фиксируются в базе знаний при формировании модели проблемной области.

Атрибуты и их значения традиционно используются для описания декларативных знаний. Возможность представления в системе ФИАКР процедуральных знаний связана с тем, что отдельные атрибуты отождествляются с именами программ. Когда в ходе консультации система вскрывает значение такого атрибута, диалог с пользователем временно прерывается и происходит автоматический вызов указанной программы, причем полученное значение передается в программу в качестве аргумента. Таким образом, значения процедуральных атрибутов можно рассматривать как режимы работы соответствующих программ.

В реальных задачах описание проблемной области содержит сотни различных атрибутов, что автоматически предполагает наличие средств структурирования. В связи с этим множество атрибутов разбивается на непересекающиеся классы, которые называются подсистемами. На содержательном уровне подсистема представляет собой набор атрибутов, характеризующий некоторый самостоятельный фрагмент модели проблемной области. Например, подсистема ЛИСТ может включать в себя атрибуты ОКРАСКА, РАЗМЕР, РАССЕЧЕННОСТЬ и т.д.

Применение подсистем облегчает, в частности, выбор имен атрибутов. Так, в базе знаний могут одновременно присутствовать три различных атрибута ОКРАСКА, принадлежащие подсистемам ЛИСТ, СТЕБЕЛЬ и ПЛОД.

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

Определение.
Тройка ( <ПОДСИСТЕМА>, <АТРИБУТ>, <ЗНАЧЕНИЕ> ) называется дескриптором свойства и записывается в виде

<ПОДСИСТЕМА>_<АТРИБУТ>: <ЗНАЧЕНИЕ>.

Например, ЛИСТ_ОКРАСКА: ЗЕЛЕНЫЙ. Строго говоря, для целей настоящего раздела форматы записей не представляют большого интереса. Однако мы приводим их с тем, чтобы не возвращаться к этому вопросу дважды.

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

Замечание.
В данном изложении речь идет только об основных фактах ПА-систем. Считается, что когнитолог может и не знать о существовании вспомогательных фактов.

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

В отличии от дескрипторов, некоторые флаги могут быть объявлены априорно установленными.

Замечание.
Во всех консультациях априорно установленные флаги автоматически заносятся во множество L⁺.

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

Замечание.
Переход некоторого факта в конфликтное состояние означает, что этот факт одновременно попадает во множества V и V ^-. Ситуация такого рода всегда предшествует первому применению правила 2.16(2').

Определение.
Обозначим D(Att) - множество дескрипторов свойств, относящихся к атрибуту Att.

Если, например, атрибут ЛИСТ_ОКРАСКА принимает значения {ЖЕЛТАЯ, СВЕТЛО-ЗЕЛЕНАЯ, ЗЕЛЕНАЯ, ТЕМНО-ЗЕЛЕНАЯ, СТАЛЬНАЯ}, то множество D(ЛИСТ_ОКРАСКА) образуют дескрипторы:

Из требования однозначности атрибутов следует, что факты множества D(Att) = { d₁, ..., d_m } в ходе логического должны функционировать как альтернатива < d₁, ..., d_m >. Таким образом, в системе ФИАКР семантика атрибутов жестко зафиксирована. При этом альтернатива < d₁, ..., d_m > одновременно служит для хранения значений атрибута, т.е выполняет роль структуры данных.

3.1.2 Модули знаний

Штатные возможности системы ФИАКР позволяют формировать модули знаний пяти типов: альтернатива, несовместимость, запрет, продукция и модуль импликации. Приведем прагматику этих модулей.

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

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

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

С теоретической точки зрения набор модулей является избыточным, однако устранять эту избыточность имеет смысл только на уровне машинной реализации базы знаний, всячески расширяя выразительные средства для представления экспертных знаний. Базовые конструкции альтернатив, реализующих указанные модули знаний, приведены в разделе 2.3. Для того, чтобы расширить возможности представления знаний, во всех модулях системы ФИАКР дополнительно разрешается использовать отрицания фактов. Кроме того, в модулях импликации и продукции разрешается иметь несколько следствий.

В ходе построения базы знаний и в ходе консультации может возникнуть необходимость сформулировать неоднозначное условие или дать неоднозначный ответ. Речь идет о высказываниях типа: "Значение атрибута ЛИСТ_ОКРАСКА принадлежит множеству {ЗЕЛЕНАЯ, ТЕМНО-ЗЕЛЕНАЯ, СТАЛЬНАЯ}". (В данном случае точное значение атрибута не называется, однако из рассмотрения исключаются значения ЖЕЛТАЯ и СВЕТЛО-ЗЕЛЕНАЯ.)

Для представления высказываний такого рода формальная модель системы ФИАКР дополнена понятием составного дескриптора.

Определение.
Подмножество фактов B из D(Att) называется составным дескриптором, если 1 < ||B||.

Пример.
Множество

Пусть B = { d₁, ...,d_n } - некоторый составной дескриптор для атрибута Att, и D(Att) = { d₁, ..., d_n, d_n+1, ..., d_m }. Составной дескриптор можно рассматривать как единый вспомогательный факт d_B, семантика которого задается альтернативой

Очевидно, что

С практической точки зрения переопределять составной дескриптор с помощью вспомогательного факта невыгодно. Дело в том, что при таком подходе усложняется процедура корректировки атрибутов, поскольку, помимо спектров их значений, приходится модифицировать и все альтернативы указанного вида. Вместе с тем, факты составного дескриптора B по определению являются взаимоисключающими, и замена в модулях знаний альтернатив типа < d_B, c > на < d₁, ..., d_n, c > является вполне законной. Как следует из семантики вспомогательного факта d_B, при такой замене единственное затруднение состоит в том, что процедура логического вывода при работе с альтернативами < d₁, ..., d_n, c > не позволяет опровергнуть факт c, если d_B ∈ V, т.е. {d_n+1, ..., d_m} ⊂ V ^-.

В связи с этим в модулях знаний на местах основных фактов s_i разрешается использовать последовательности дескрипторов свойств d₁, ..., d_n (n > 1), относящихся к одному и тому же множеству D(Att). Кроме того, в системе ФИАКР процедура условного логического вывода дополнена новым правилом.

Правило 2.18(5)

Правило 2.18(5) применяется к системе альтернатив только в том случае, когда V⁺ = ∅ и правила 2.18(1) - 2.18(3) не позволяют пополнить множества V ^- и V. По результатам выполнения правила 2.18(5) появляется возможность применить правило 2.18(1) и т.д. - начинает работать обычная процедура вывода, основанная на правилах 2.18(1) - 2.18(4). В целом же, процедура логического вывода заканчивает свою работу, если правило 2.18(5) не позволяет пополнить множество V ^- новыми фактами.

3.1.3 Флаги существования атрибутов

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

Традиционный выход из этой ситуации состоит в том, что в спектре значений атрибута резервируется специальное значение, которое интерпретируется как признак отсутствия атрибута вообще. В системе ФИАКР используется другой метод, в соответствии с которым каждому атрибуту в базе знаний автоматически приписывается флаг существования атрибута.

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

Формат флагов существования имеет вид:

Замечание.
В базе знаний системы ФИАКР изначально существуют пять архивов. В спецификациях фактов эти архивы выступают под именами БАЗА, БЛОК, ШЕФ, АНКЕТА и ЦЕЛЬ. Архив БАЗА является архивом архивов, он содержит [указатели на] архивы БЛОК, ШЕФ, АНКЕТА, ЦЕЛЬ. Имена архивов жестко зафиксированы в системе.

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

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

Например, факты уточнения структуры могут быть сгруппированы в подсистеме СТРУКТУРА, содержащей априорно обязательные атрибуты ОКРАСКА/ВОЛОС и ДЛИНА/ВОЛОС со значениями СУЩЕСТВУЕТ и ОТСУТСТВУЕТ. Далее, дескрипторы СТРУКТУРА_ОКРАСКА/ВОЛОС: СУЩЕСТВУЕТ и СТРУКТУРА_ДЛИНА/ВОЛОС: СУЩЕСТВУЕТ отождествляются соответственно с флагами существования БЛОК_ВОЛОСЫ= ОКРАСКА и БЛОК_ВОЛОСЫ= ДЛИНА.

В приведенном примере атрибуты ОКРАСКА/ВОЛОС и ДЛИНА/ВОЛОС предназначены только для управления состояниями флагов существования. Вообще говоря, такое решение является неэффективным, поскольку предполагает внесение в модель проблемной области дополнительных атрибутов. Другой подход к построению модулей управления обязательной структурой состоит в том, чтобы задействовать косвенную информацию об обязательной структуре, содержащуюся в ответах о значениях "обычных" атрибутов.

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

Предложенная классификация описывается парой атрибутов ЖИВОТНОЕ и МЛЕКОПИТАЮЩЕЕ со спектрами значений соответственно ПТИЦА, МЛЕКОПИТАЮЩЕЕ и ТРАВОЯДНОЕ, ХИЩНИК. Кроме того, в базе должен присутствовать модуль, устанавливающий эквивалентность дескриптора КЛАСС_ЖИВОТНОЕ: МЛЕКОПИТАЮЩЕЕ и флага БЛОК_КЛАСС= МЛЕКОПИТАЮЩЕЕ (здесь КЛАСС - подсистема, включающая атрибуты ЖИВОТНОЕ и МЛЕКОПИТАЮЩЕЕ).

3.1.4 Флаги существования подсистем

"Усеченный" вариант реализации некоторых проблемных ситуаций зачастую объясняется отсутствием у них целых подсистем. Типичный пример такой ситуации связан с подсистемой ВОЛОСЫ, включающей в себя необязательные атрибуты ОКРАСКА и ДЛИНА. Для того, чтобы использовать это обстоятельство в базе знаний, автоматически создаются флаги существования подсистем вида:

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

Формально, связь между флагами существования атрибутов s₁, ..., s_m и флагом существования подсистемы s₀ определяется модулем знания R_S:

K(R_S) = ( 2^S' \ {S'} ) ∪ { S }, где S' = { s₁, ..., s_m },    S = { s₀, s₁, ..., s_m }.

ПА-система R_S в ходе логического вывода может функционировать двумя способами.
1) Если S' ⊂ V, то s₀ ∈ V.
2) Если s₀ ∈ V, то S' ⊂ V.

В качестве фактов флаги существования подсистем могут участвовать в любых модулях знаний.

3.1.5 Флаги активизации

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

В связи с этим, множество модулей, представленных в базе знаний системы ФИАКР, формируется в виде непересекающихся групп, которые носят название экспертных. Экспертная группа (или просто - эксперт) характеризуется именем. При формировании базы знаний каждый модуль необходимо дополнительно связать с именем некоторой экспертной группы. Приведем примеры имен: ОЧЕВИДНО, УПРАВЛЕНИЕ/СТРУКТУРОЙ, ИВАНОВ и т.д. В первом случае экспертная группа объединяет модули знаний, характеризующие соображения здравого смысла. Модули уточнения обязательной структуры сосредоточены в группе с именем УПРАВЛЕНИЕ/СТРУКТУРОЙ. Знания эксперта Иванова размещаются в одноименной группе.

Каждой экспертной группе в базе знаний сопоставлен флаг активизации:

Например, БАЗА_ШЕФ= ОЧЕВИДНО,    БАЗА_ШЕФ= УПРАВЛЕНИЕ/СТРУКТУРОЙ.

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

В системе ФИАКР существуют три возможности задать состояние флага активизации.

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

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

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

3.1.6 Флаги целей

Несмотря на единообразное представление атрибутов в базе знаний, их роль в ходе консультации может быть различной. Часть атрибутов используется в качестве вопросов пользователю. Эти атрибуты представляют собой наблюдаемые или измеряемые характеристики проблемной ситуации. Значения остальных атрибутов вскрываются только посредством логического вывода. Некоторые атрибуты объявляется в системе как потенциально возможные цели консультации. Такие атрибуты называются целевыми. Как правило, целевые атрибуты выбираются из числа ненаблюдаемых (выводимых) атрибутов. Однако иногда, например, в целях отладки базы знаний, в качестве целевого может использоваться и наблюдаемый атрибут.

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

Например, в базе знаний диагностики растений в качестве целевых выделяются атрибуты БОЛЕЗНИ и ГОРМОНАЛЬНЫЙ/БАЛАНС. Для этих атрибутов система ФИАКР создает флаги целей

БАЗА_ЦЕЛЬ= БОЛЕЗНИ и БАЗА_ЦЕЛЬ= ГОРМОНАЛЬНЫЙ/БАЛАНС.

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

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

3.1.7 Флаги опроса

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

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

Например, выбор значения для атрибута ЛИСТ_ОКРАСКА (со спектром значений: ЖЕЛТАЯ, СВЕТЛО-ЗЕЛЕНАЯ, ЗЕЛЕНАЯ, ТЕМНО-ЗЕЛЕНАЯ, СТАЛЬНАЯ) связан с выбором значения атрибута ЛИСТ_ОТТЕНОК (БЛЕСТЯЩИЙ, ЗОЛОТИСТЫЙ, АНТОЦИАНОВЫЙ). Формально, атрибуты ЛИСТ_ОКРАСКА и ЛИСТ_ОТТЕНОК являются независимыми, т.е. в природе могут встречаться любые комбинации их значений. Однако для правильного ответа на вопрос ЛИСТ_ОКРАСКА необходимо знать, что в базе существует также атрибут ЛИСТ_ОТТЕНОК. Если же пользователь обратился к экспертной системе впервые, то ему просто неоткуда получить такую информацию. Таким образом, предъявление пользователю изолированных вопросов может привести к неадекватному описанию проблемной ситуации со всеми вытекающими последствиями.

В описанном примере наилучшее решение, по-видимому, состоит в том, чтобы предъявить пользователю в качестве вопроса сразу два атрибута. Впрочем количество взаимосвязанных атрибутов может быть произвольным. Главный вывод из приведенного примера состоит в том, что когнитолог при проектировании диалога экспертной системы с пользователем должен учитывать ЭФФЕКТ СВЯЗНОСТИ НАБЛЮДАЕМЫХ АТРИБУТОВ, а средства организации диалога должны предоставлять возможности корректной обработки такого рода эффектов.

В системе ФИАКР диалог с пользователем основан на механизме смены анкет. Анкета представляет собой группу наблюдаемых атрибутов, причем каждой из них ставится в соответствие флаг опроса вида:

Например, анкета с именем СТАРТ может содержать вопросы об общем виде, высоте и степени облиствленности растения. Этой анкете в базе знаний соответствует флаг опроса

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

Средства управления диалогом в системе ФИАКР разделяются на две части. К первой относятся флаги опроса, а вторую часть составляет процедура приоритетного выбора очередной анкеты.

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

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

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

3.2 Программное обеспечение режима эксперта

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

3.2.1 Входной язык системы ФИАКР

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

Описание базы на входном языке выглядит как некоторый текст, состоящий из терминов-слов, разделителей и ограничителей. В качестве разделителей используется пробел. Количество подряд стоящих разделителей не играет роли.

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

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

В свою очередь, каждая логическая строка представляет собой некоторую последовательность терминов. Допускается, что отдельные специально оговоренные термины могут заканчиваться ограничителями: в качестве ограничителей используются: подчеркивание (_) двоеточие (:) и знак равенства (=).

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

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

В качестве примера рассмотрим строгое описание некоторого модуля управления диалогом.

В первой строке - заголовке модуля - последовательно задаются тип (ПРОДУКЦИЯ), имя (П.1) и экспертная группа (ДИАЛОГ) данного модуля. Вторая и третья строки определяют посылки модуля, а в пятой строке содержится заключение. Черта, состоящая из знаков "-", разграничивает посылки и следствия.

Полное описание языка приводится в руководстве по системе ФИАКР [38]. Как правило, тексты на входном языке без труда понимаются проблемными специалистами, однако запись базы знаний с соблюдением всех формальных правил лучше возложить на когнитолога.

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

3.2.2 Редакторы базы знаний

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

Средства оперативной корректировки баз знаний включают в себя:
— редактор атрибутов;
— редактор модулей знаний;
— редактор анкет;
— редактор целей.

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

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

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

Редактор атрибутов обеспечивает модификацию подсистем, атрибутов и их значений. Кроме того, редактор позволяет изменять ролевые реквизиты атрибутов:
— отношение атрибута к обязательной структуре (обязательный или необязательный);
— отношение атрибута к процедуре опроса (наблюдаемый или выводимый);
— возможность использования атрибута в качестве цели (целевой или нецелевой);
— тип атрибута (процедуральный или декларативный).

Для того, чтобы упростить процедуру построения атрибутов, в подсистеме разрешается определять стандартные комбинации реквизитов, которые наследуются всеми ее атрибутами. В случае необходимости унаследованные значения реквизитов разрешается изменять. Аналогичные соглашения действуют и для входного языка системы ФИАКР.

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

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

Особого разговора заслуживает инструментарий построения модулей знаний, основанный на принципе "одна строка - один атрибут". Согласно этому принципу, каждый задействованный в модуле атрибут (со своими значениями) занимает ровно одну строку экрана. Если для размещения атрибута требуется более одной строки, то редактор модулей предпринимает попытку уменьшить длины имен посредством перехода к их сокращениям. В крайнем случае, часть значений заменяется многоточием, и в процессе редактирования система позволяет обновить представление спектра значений. Дополнительно на экран может быть выведена горизонтальная черта, позволяющая разделить модуль на посылки и следствия.

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

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

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

На следующем этапе - посредством перестановки строк - ситуация на экране приобретает вид:

Путем удаления значений и "навешивания" отрицания окончательно получаем:

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

Замечание.
Описанный принцип подачи исходного материала, а также метод вычеркивания "лишних" значений были выявлены после многочисленных и безуспешных попыток заставить экспертов формулировать свои знания непосредственно в виде модулей. (Речь идет о личном общении с экспертами.) На фоне прочих способов прямого извлечения знаний предъявление заготовок по принципу "одна строка - один атрибут" оказалось чрезвычайно эффективным: эксперты охотно занимались вычеркиванием значений, и в количественном отношении база знаний пополнялась очень быстро. В дальнейшем этот выявленный феномен и был положен в основу программной реализации редактора. Таким образом, в системе ФИАКР процедура редактирования модулей одновременно выполняет роль метода извлечения знаний.

3.2.3 Конструктор модулей знаний

Непосредственно формированием базы знаний занимается конструктор модулей. Именно этот программный блок формирует множество вспомогательных фактов и размещает альтернативы в файлах базы знаний. Конструктор реализован как общая компонента транслятора с входного языка и редактора модулей знаний.

Прежде всего, конструктор проверяет заданное ему описание модуля на структурную корректность, которая предполагает одновременное выполнение следующих четырех условий.
1.Разделительная черта (для альтернативы, несовместимости и запрета) отсутствует совсем или является строго внутренней (для продукции и импликации).
2.Все строки описания (за исключением разделительной черты) содержат непустое множество фактов.
3.Строки, начинающиеся с терминов БАЗА и БЛОК, содержат ровно один факт.
4.В описание модуля помимо разделительной черты входят не менее двух строк.

Если не выполняется хотя бы одно условие структурной корректности, то конструктор заканчивает свою работу с сообщением об ошибке. В противном случае база знаний пополняется новыми альтернативами. При этом конструктор использует указанный тип модуля и множество основных фактов S. (В данном случае в качестве факта может выступать составной дескриптор, так как элементы множества S взаимнооднозначно соответствуют строкам описания.) Дополнительно конструктор использует два независимых разбиения основных фактов:

Множество S_n образуют те факты, которые входят в модуль с отрицанием, S_y = S \ S_n. Множество S_c образуют факты, находящиеся под разделительной чертой, S_a = S \ S_c.

Для каждого основного факта из S действия конструктора по построению альтернатив определяются следующей таблицей:

Кроме того, для каждого модуля знаний конструктор размещает в базе следующие альтернативы:
— для продукции: < c_s | s ∈ S_a > ∪ < c'_s | s ∈ S_a > ∪ < c >;
— для импликации: < c_s | s ∈ S_a > ∪ < c >;
— для запрета и альтернативы: < c_s | s ∈ S >;
— для несовместимости: [ c_s | s ∈ S ].

Приведем множество альтернатив для примера из раздела 3.2.2, построенных в предположении, что полученное описание строк объявлено модулем импликации.

s₁ есть КУСТ_ВЫСОТА: КАРЛИК,
s₂ есть КУСТ_ВЫСОТА: НИЗКИЙ,
s₃ есть СТЕБЕЛЬ_ВЕТВИСТОСТЬ: СИЛЬНАЯ,
s₄ есть РАСТЕНИЕ_ЗАЦВЕТАНИЕ: РАННЕЕ,
s₅ есть РАСТЕНИЕ_ЗАЦВЕТАНИЕ: ПОЗДНЕЕ,
s₆ есть ЗАКЛЮЧЕНИЕ_ТИП: ДЕТЕРМИНАНТНЫЙ.

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

3.3 Программное обеспечение режима пользователя

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

3.3.1 Блок консультации

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

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

При выборе очередной анкеты процедура просматривает ранее не использовавшиеся анкеты и выбирает для продолжения диалога первую по порядку анкету с установленным флагом опроса. Имя найденной анкеты выводится на экран. В том случае, когда база знаний оказывается не в состоянии предложить анкету, процедура управления выдает сообщение "ПРЕДУПРЕЖДАЮ, ПОТЕРЯНО УПРАВЛЕНИЕ ДИАЛОГОМ" и предпринимает самостоятельную попытку найти продолжение. Фактически в этот момент процедура просматривает подряд все атрибуты базы данных. Если же и эта попытка заканчивается неудачно, то на экран выводится сообщение "ТУПИК В ДИАЛОГЕ".

Атрибут разрешается использовать в вопросе, если он удовлетворяет трем условиям:
1) установлен флаг существования атрибута;
2) атрибут является наблюдаемым и нецелевым;
3) в спектре значений атрибута имеются, по крайней мере, два дескриптора с неопределенными состояниями.

При ответе на вопрос задача пользователя состоит в том, чтобы давать наиболее точные характеристики проблемной ситуации. В затруднительных случаях допускаются неоднозначные ответы, в которых перечисляются целые группы значений атрибута. Основной вариант организации диалога основывается на одновременном предъявлении всех вопросов, перечисленных в анкете (см. 3.1.7). Свой ответ пользователь строит путем вычеркивания ненужных фактов, аналогично тому, как это реализовано в редакторе модулей.

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

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

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

Специфика логического вывода в системах альтернатив такова, что к моменту опроса по конкретному атрибуту часть его значений может быть опровергнута на основании ранее полученных данных. Однако в формулировку вопроса - с целью придания ему объективного характера - входят все без исключения возможные значения атрибута. Учитывая это обстоятельство, пользователь может обратиться к системе за подсказкой, в которой приводится текущее состояние спектра значений атрибута. Таким образом, функции помощи и подсказки в системе ФИАКР являются существенно различными.

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

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

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

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

Отметим, что редактор ответов не запускает машину вывода. Он просто восстанавливает первоначальную систему альтернатив и формирует новые множества L⁺ и L^- для всех атрибутов, участвовавших в опросе пользователя. Запуск машины вывода происходит лишь при обращении к блоку консультации.

3.3.2 Подсистема объяснений

В системе ФИАКР подсистема объяснений основана на взаимодействии двух схем. Первая схема - схема доступа к фактам базы знаний, посредством которой проблемный специалист может "перемещаться" по иерархической структуре базы знаний (подсистема - атрибут - значение, группа - модуль, и т.д.). Отметим, что такая схема является универсальной, т.е. не зависит от проведенной консультации.

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

В подсистеме предусмотрены два способа предъявления модулей знаний. Первый способ восстанавливает модуль в его исходном виде с дополнительной разметкой фактов по пяти категориям:
— неопределенные факты;
— установленные факты, выполнившие роль аргументов;
— опровергнутые факты, выполнившие роль аргументов;
— факты, установленные в данном модуле;
— факты, опровергнутые в данном модуле.

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

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

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

3.4 Особенности реализации системы ФИАКР

Система ФИАКР разрабатывалась на основе предварительного анализа задачи диагностики растений [40]. В дальнейшем именно эта проблемная область была использована в качестве модельной задачи для проверки реальных возможностей системы.

На содержательном уровне задача экспертной системы ФИтоАКтиваторов Растений на примере Томатов (ФИАКР-Т) состоит в том, чтобы по морфологическому описанию растения определить характерные для него типы соотношений между основными фитогормонами. Заключения такого рода используются на этапе планирования экспериментов по клеточной инженерии.

Диагноз гормонального баланса формируется из конечного набора высказываний типа "содержание индолилуксусной кислоты (ИУК) намного превосходит содержание кинетина". В экспертной системе ФИАКР-Т каждой паре фитогормонов соответствует один целевой атрибут, значения которого характеризуют возможные типы соотношений между гормонами. Например, атрибут с именем ИУК+КИНЕТИН может принимать значения: ИУК<<КИНЕТИН, ИУК<КИНЕТИН, ИУК=КИНЕТИН, ИУК>КИНЕТИН, ИУК>>КИНЕТИН. В этом примере значение ИУК>>КИНЕТИН соответствует процитированному ранее заключению. Дополнительно в формальной модели проблемной области выделены в качестве целевых еще несколько атрибутов, характеризующих особенности минерального питания растений.

Система реализована на языке ПАСКАЛЬ, причем все машино-зависимые операции вынесены в отдельные процедуры. Разработка и отладка основной версии системы ФИАКР велись на ЭВМ СМ-4, ОС RT-11. В дальнейшем система переносилась в среду ОС RSX11M и MS DOS для IBM/PC.

В режиме эксперта база знаний состоит из четырех файлов прямого доступа:
— файл.ALT содержит записи различной длины, которые соответствуют либо альтернативам, либо вспомогательным архивам, определяющим схему доступа; связи между записями задаются посредством указателей;
— файл.STS содержит множество основных и вспомогательных фактов, которые представляются в записях базы знаний своими указателями;
— файл.VCB содержит (печатные) наименования всех элементов базы знаний;
— файл.TAT содержит пояснительные записки, предназначенные для выбора значений атрибута.

Каждый указатель размещается в двух байтах и представляет собой смещение от начала файла. Соглашения о форматах записей позволяют интерпретировать составляющие их указатели однозначным образом. Ограниченность разрядной сетки, которая используется для хранения указателей, порождает ограничения на общие размеры файлов. Перевести эти ограничения в содержательные термины базы знаний практически невозможно, поэтому приведем характеристики экспертной системы ФИАКР-Т, которая использует возможный ресурс памяти на 70%.

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

3.5 Методы отладки баз знаний в системе ФИАКР

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

Отладка представляет собой итеративный процесс проверки и исправления базы знаний [39]. В некоторых случаях дефекты, обнаруженные в ходе проверки, могут привести к весьма значительным изменениям. Как правило, обнаруженный дефект можно трансформировать (формально или неформально) в вопросительное предложение, адресованное эксперту. Обычно полученный ответ предполагает исправление некоторых модулей знаний; эта операция выполняется с помощью редактора базы знаний.

В системе ФИАКР методы отладки подразделяются следующим образом:

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

С точки зрения АСИЗ методы отладки различаются способом организации базы сведений о проблемной области (п. 1.5). Методы тестирования используют так называемую базу тестов, в свою очередь методы исследования используют саму базу знаний и различаются лишь управляющими стратегиями сценариев извлечения знаний (п. 1.5).

3.5.1 Тестирование баз знаний

Тестирование базы знаний предполагает проверку ее свойств на заданном множестве примеров. В системе ФИАКР понятие примера естественным образом расширено с целью контроля промежуточных выводов.

Определение.
Тест представляет собой последовательность T₁, ..., T_n, где T_i есть четверка < F_i⁺ , F_i^- , G_i⁺ , G_i^- > все элементы которой представляют собой непересекающиеся подмножества основных фактов и || F_i⁺ ∪ F_i^- || = 1.

Определение.
Будем говорить, что база знаний удовлетворяет тесту T₁, ..., T_n, если для любого k = 1,...,n имеют место следующие условия:

По сути дела, тест представляет собой последовательность фактов (F_i⁺) или их отрицаний (F_i^-), которую можно рассматривать как описание некоторой проблемной ситуации. Кроме того, для каждой начальной подпоследовательности (задающей описание некоторого класса проблемных ситуаций) разрешается указывать присущие ей выводимые свойства G_i⁺ и G_i^-. В простейшем случае, когда G_i⁺ = G_i^- = ∅ (i=1, ..., n-1), тест вырождается в конкретный пример применения, в котором приводятся описание некоторой проблемной ситуации и связанное с ней решение G_n⁺ и/или G_n^-.

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

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

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

3.5.2 Статические методы исследования баз знаний

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

В системе ФИАКР реализованы автономные утилиты проверки тех или иных проблемно-независимых свойств баз знаний. Каждая утилита обрабатывает модули знаний строго определенного класса и позволяет выявить все проявления некоторого дефекта. В данном случае дефект рассматривается как формальное свойство, присущее отдельным элементам класса. Для полноты картины в описаниях проверок приводятся наиболее вероятные пути исправления обнаруженных дефектов.

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

Проверка 1. Проверяются все атрибуты базы знаний. Атрибут удовлетворяет условию выявления дефекта, если все дескрипторы свойств этого атрибута не встречаются в других модулях знаний. (Рекомендуется либо удалить выявленные атрибуты, либо дополнить базу новыми модулями знаний.)

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

Проверка 2. Проверяются ненаблюдаемые атрибуты базы знаний. Атрибут удовлетворяет условию выявления дефекта, если в базе отсутствуют модули знаний, способные вывести дескрипторы этого атрибута из неопределенного состояния. (Рекомендуется пополнить базу новыми модулями знаний.)

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

Проверка 4. Проверяются необязательные атрибуты базы знаний. Атрибут удовлетворяет условию выявления дефекта, если в базе знаний отсутствуют модули, способные установить его флаг существования. (Рекомендуется внести в базу соответствующие модули управления обязательной структурой.)

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

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

Проверка 6. Проверяются все анкеты базы знаний. Анкета удовлетворяет условию выявления дефекта, если она содержит ненаблюдаемый атрибут. (Рекомендуется исправить выявленную анкету.)

Проверка 7. Проверяются необязательные анкеты базы знаний. Анкета удовлетворяет условию выявления дефекта, если в базе отсутствуют модули, способные установить флаг опроса этой анкеты. (Рекомендуется либо доработать модули организации диалога, либо изменить реквизит выявленной анкеты.)

Перечисленные ниже проверки 8-12 обрабатывают модули знаний следующих типов: продукция, импликация, альтернатива, несовместимость и запрет.

Проверка 8. Модуль удовлетворяет условию выявления дефекта, если он содержит в качестве составного дескриптора весь спектр значения атрибута. (Рекомендуется исправить выявленные модули знаний.)

Проверка 9. Модуль удовлетворяет условию выявления дефекта, если он содержит флаг активизации собственной экспертной группы. (Рекомендуется перенести выявленные модули в другие экспертные группы.)

Проверка 10. Модуль удовлетворяет условию выявления дефекта, если он содержит два и более вхождений одного и того же факта. (Рекомендуется исправить выявленные модули знаний.)

Факты, представленные в базе знаний, имеют различную прагматику; дескрипторы свойств непосредственно связаны с природой проблемной области, а флаги в основном ориентированы на организацию работы самой экспертной системы. В связи с этим вряд ли можно считать обоснованным итоговое решение, при выводе которого зеленая окраска листа была опровергнута на том основании, что в базе знаний существует подсистема ЛИСТ и опровергнут флаг опроса анкеты ГИПОТЕЗА/А. Такая ситуация может возникнуть, когда в базе знаний имеется модуль импликации

Проверка 11. Модуль удовлетворяет условию выявления дефекта, если он позволяет выводить состояния дескрипторов свойств на основании состояния флагов. (Рекомендуется изменить состав фактов или тип выявленных модулей.)

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

Определение.
ПА-система R является обобщением ПА-системы R', если альтернативы из R' содержатся (с точностью до переименования вспомогательных фактов) в остаточной системе альтернатив, полученной из R для некоторых множеств L⁺ и L^-.

Проверка 12. Модуль удовлетворяет условию выявления дефекта, если в базе знаний имеется его обобщение. (Рекомендуется удалить выявленные модули.)

Проверка 13. Проверяются продукции и импликации. Модуль удовлетворяет условию выявления дефекта, если в базе знаний имеется однотипный модуль с теми же посылками. (Рекомендуется свести оба модуля в один путем объединения следствий.)

3.5.3 Динамические методы исследования баз знаний

В отличии от статических методов методы динамические в своей работе существенно используют машину логического вывода.

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

Прежде всего приведем трактовку конфликтного состояния в том виде, как это понимается в системе ФИАКР.

Определение.
Множество фактов F называется конфликтным описанием по отношению к заданной базе знаний (суть - ПА-системе), если логический вывод для множеств L⁺ = F и L^- = ∅ приводит к конфликтному окончанию.

Практически условие L^- = ∅ означает, что конфликтное состояние можно построить в ходе консультации, если на каждый вопрос системы либо давать однозначные ответы, либо отказываться отвечать. Рассмотрим подробнее природу конфликтных описаний.

Определение.
Конфликтное описание F называется минимальным, если любое его подмножество фактов F' (F' ⊂ F,   F' ≠ F) не является конфликтным описанием.

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

Алгоритм генерации минимальных конфликтных описаний [42] основывается на полном переборе описаний, начиная с проверки отдельных фактов; затем проверяются пары фактов и т.д. Для сокращения перебора существенно используется свойство однозначности атрибутов, в соответствии с которым имеет смысл рассматривать описания, содержащие по одному дескриптору от каждого атрибута. Кроме того, из рассмотрения исключаются описания, содержащие недопустимые комбинации фактов. Первоначально недопустимыми считаются описания, представленные в базе знаний как запреты. По ходу генерации к недопустимым причисляются и все обнаруженные конфликтные описания.

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

Интересно отметить, что первоначально реализация подсистемы отладки [41] велась по пути наращивания функциональных возможностей системы ФИАКР при неизменных соглашениях об организации файлов базы знаний. Однако в дальнейшем выяснилось, что для эффективного проведения отладки необходимо полностью пересмотреть и внутреннюю организацию базы, и принципы реализации основных блоков экспертной системы. Последнее обстоятельство связано с тем, что редакторы, машина вывода и подсистема объяснений должны вызываться не только из главного меню системы, но и из различных программных модулей подсистемы отладки. При этом возникает необходимость ввести дополнительные управляющие параметры, задающие специфику конкретного вызова. В связи с этим была реализована новая версия инструментальной системы - система ФИАКР+. Системы ФИАКР и ФИАКР+ используют один и тот же входной язык, а также реализуют один и тот же метод логического вывода. В этом смысле системы являются полностью совместимыми. Таким образом, на этапе проектирования инструментальных экспертных систем необходимо обратить самое серьезное внимание на потребности отладки баз знаний.