14.3. Использование знаний, развитие и расширение системы XCON
В этом разделе мы рассмотрим, какие особенности использования знаний существуют в системе XCON, как эта система совершенствовалась и расширялась. Система XCON выбрана в качестве примера по той простой причине, что процесс приобретения и расширения знаний в этой системе довольно подробно описан в доступной автору документации, чего нельзя сказать о множестве других экспертных систем. Совершенно очевидно, что три эти темы — извлечение знаний, совершенствование и расширение возможностей экспертной системы — тесно связаны. Проблема извлечения знаний применительно к системе XCON осложняется тем, что для решения задачи конфигурирования вычислительной системы требуются самые разнообразные знания. Но не нужно забывать о том, что углубленный анализ применяемых методов решения проблемы может в определенной мере упростить задачу извлечения необходимых знаний, как это было продемонстрировано в главах 11-13
14.3.1. Извлечение знаний в системе R1/XCON
В работе [McDermott, 1982, а] содержится множество интересных наблюдений о том, как выполняется начальная фаза извлечения знаний для системы R1.
У экспертов имеется достаточно четкое, систематическое представление о том, как разбить основную задачу на подзадачи, и о том, какие отношения существуют между этими подзадачами.
При решении сформулированных подзадач, однако, поведение экспертов определяется не столько общими принципами, сколько исключениями из них, например "при выполнении подзадачи S выполнять алгоритм X, пока не будет выполнено условие У". Можно считать, что в процессе решения подзадач поведение эксперта в основном направляется событиями.
Такая систематичность в выявлении отношений между подзадачами и несистематичность решения отдельных подзадач при реализации на языке OPS5 приводит к использованию контекстов и специальных случаев. Раздельное уточнение правил и контекстов обеспечивает модульный характер коррекции ошибок в поведении системы на начальном этапе ее разработки. Однако в работе [McDermott, 1988] Мак-Дермот обратил внимание на то, что различные виды знаний не всегда хорошо различимы в рамках решения одной подзадачи. В частности, в составе правил можно встретить два класса знаний:
знания о разных способах расширения частичной конфигурации;
знания о том, какой из возможных вариантов расширения следует выбрать.
Бачан ([Bachant, 1988]) присоединился к мнению Кленси ([Clancey, 1983]) и других, ратовших за более обобщенный подход к этой проблеме. В частности, предлагалось использовать явные средства управления режимом выполнения правил. Сторонники этого подхода обращали внимание на то, что разрешение конфликтов выполняется на очень низком уровне иерархии задач, хотя можно было бы его использовать для декомпозиции в пределах задач. В новом методе, названном RIME (аббревиатура от Rl's Imlicit Made Explicit — то, что в R1 было неявным, сделано явным), была предпринята попытка найти оптимальное соотношение между слишком жестким и слишком мягким режимами управления последовательностью выполнения операций. Основной метод решения проблем в системе R1 можно отнести к виду предложи-и-примени (propose-and-apply), который состоит из следующих шагов.
(1) Инициализация цепи. Формируется элемент управления для текущей задачи и удаляются все устаревшие элементы управления для тех задач, которые уже завершены.
(2) Предложение. Предлагаются возможные варианты дальнейших действий и отвергаются неприемлемые варианты. Варианты представляются в виде операторов.
(3) Удаление лишнего. Удаляются лишние операторы в соответствии с глобальным критерием, например заранее определенным приоритетом операторов.
(4) Разрешение конфликтов. Выполняется попарное сравнение конкурирующих операторов и принимается решение, какой из двоих оставить.
(5) Выбор единственного оператора. Анализируется результат выполнения шагов 2—4 и из всех оставшихся операторов выбирается единственный.
(6) Применение оператора. Выбранный оператор применяется к текущему состоянию проблемы и таким образом формируется расширение частичной конфигурации.
(7) Оценка цели. Проверяется, не достигнута ли сформулированная цель. Если цель достигнута, процесс завершается, в противном случае цикл повторяется.
Итак, как следует из анализа, выполненного Бачаном, слабый метод (Match) использует в процессе выполнения более строгий метод (предложи-и-примени). Этот подход в чем-то аналогичен использованию эвристической классификации (строгий метод) для формирования подцелей (слабый метод) в системе MYCIN.
Несколько позже Мак-Дермот (см. [McDermott, 1988]) назвал такие более строгие методы, которые используются в сочетании с более слабыми, "role-limiting methods" (методами с ограничением роли). Методы этой группы характеризуются видом тех управляющих знаний, которые используются для выявления, отбора и применения действий, выполняемых системой. При этом предполагается, что существует группа задач, для которых использование определенной части управляющих знаний может считаться независимым от специфики предметной области.
Таким образом, можно считать, что методы с ограничением роли— это такие "методы, которые строго направляют процесс накопления и представления знаний". Хотя это определение и нельзя признать достаточно строгим, в нем выражена главная идея — некоторый метод можно отнести к группе методов с ограничением роли в том случае, если те управляющие знания, которые, как правило, используются этим методом, не очень тесно связаны со спецификой решения задачи. Можно, конечно, возразить, что в таком случае метод эвристической классификации, который используется в MYCIN, также относится к этой группе, если не обращать внимание на тот факт, что в MYCIN используются нарождающие правила.
Справедливо, однако, утверждение, что некоторая часть экспертных систем может содержать управляющие знания менее абстрактного характера, т.е. знания, так или иначе связанные с объектами определенной предметной области и отношениями между ними. Мак-Дермот, в частности, процитировал одно из правил системы R1/XCON, которое приведено ниже.
ЕСЛИ
два действия-кандидата суть
включить в систему НМД RA60,
включить другой тип НМД,
который использует тот же тип корпуса,
ТО
отдать предпочтение на следующем шаге включению в систему НМД RA60.
ЕСЛИ
два действия-кандидата суть
включение в систему устройства, монтируемого на генпанели, тип которого
не RV20A или RV20B,
включение в систему другого устройства, монтируемого на генпанели, тип которого не RV20A или RV20B, и не выбран шкаф, и существует шкаф, в который можно вставить устройство, и желательно разместить первое устройство в шкафу перед тем, как размещать в нем второе устройство,
ТО
отдать предпочтение на следующем шаге включению в систему первого устройства.
Первое правило можно обобщить, если известно, почему предпочтительнее сначала иметь дело с НМД типа RA60. А вот второе правило кажется очень тесно связанным со спецификой размещения устройств отдельных типов в шкафах и их взаимной компоновкой. Более того, в этом правиле использованы отношения между объектами предметной области, которые можно отнести к разным уровням абстракции. Мак-Дермот обратил внимание на то, что тот вид суждений, который представлен в таких правилах, будет меняться от одной области применения системы к другой, а следовательно, его не удастся обобщить.
14.3.2. Совершенствование и расширение системы R1/XCON
Как уже отмечалось ранее (см. главу 3), совершенствование экспертной системы в процессе ее опытной эксплуатации — это отдельная, достаточно сложная тема для обсуждения. В процессе разработки системы оценка ее будущей производительности зачастую бывает весьма туманной. Понятно, что программа должна выполняться за разумное время и на первых порах справляться с типовыми для данной предметной области случаями, в частности с теми, которые использовались для извлечения знаний в процессе интервью с экспертами. Но стоит задуматься и над тем, чтобы разработать тест или набор тестов, которые позволят оценить реальную производительность системы и выявить те случаи, когда она достигает максимума.
В тех областях, где формализация затруднена или невозможна, вряд ли удастся когда-либо представить убедительное доказательство того, что данная система действительно является экспертом в некотором отвлеченном смысле. Свидетельство может быть только эмпирическим и включать диапазон возможных ситуаций, с которыми справляется программа. Для любого нетривиального применения этот диапазон должен быть достаточно широким. Несмотря на то что программа XCON на сегодняшний день обработала десятки тысяч заказов, считается, что просмотрена только малая часть пространства возможных вариантов.
По словам Мак-Дермота, на начальной стадии эксплуатации системы R1 предполагалось, что она сможет стать действительным помощником разработчика только после того, как будет справляться примерно с 90% всех поступающих заказов, т.е. сформированные программой по этим заказам компоновки вычислительной системы будут не хуже тех, которые проектируются опытным специалистом. Для того чтобы достичь такого уровня совершенства, с программой R1 пришлось повозиться почти три года, но опыт показал, что начальные требования к "изобретательности" системы были завышенными. Программа была признана пользователями вполне работоспособной и полезной еще до того, как достигла такого высокого уровня совершенства, поскольку качество ее работы не уступало качеству работы рядового специалиста. Проектирование конфигураций относится к тому классу задач, который редко решается каким-либо специалистом в одиночку. Как правило, одному специалисту для этого не хватает ни знаний, ни времени. Поэтому помощь, которую оказывала система R1 в решении этой задачи, была весьма кстати.
Можно ли считать решающим критерием сравнение результатов, полученных экспертной системой, с теми, которые получают эксперты в этой же предметной области? Вопрос этот не так прост, как кажется на первый взгляд. Помимо того, что в нем скрыта проблема выбора подходящих тестов, существует еще и проблема адекватного сравнения результатов. Система R1 дает более детальное решение этой задачи, чем человек-эксперт. Последний оставляет многие детали на усмотрение персонала, непосредственно занятого монтажом системы. Можно ли сравнивать проект, созданный экспертной системой, с результатами работы не только инженера-проектировщика, но и техников, монтирующих систему? Нужно принять во внимание еще и следующий нюанс. При монтаже системы техники имеют возможность экспериментировать с компоновкой в определенных пределах, а программа этой возможности лишена. Таким образом, сравнение будет не совсем корректным.
Добавление в экспертную систему новых знаний также не является тривиальной проблемой. Во-первых, новые знания добавляются в систему уже на стадии отладки тех знаний, которые были введены в первоначальный вариант системы. Во-вторых, существуют и другие причины, требующие включения новых знаний на протяжении всего жизненного цикла системы.
(1) Требуется ввод знаний о более широком классе объектов, с которыми должна иметь дело система. Например, может потребоваться проектировать конфигурации новых типов вычислительных систем.
(2) Могут потребоваться новые знания, улучшающие качество решения путем включения новых подзадач. Например, в случае задачи компоновки можно включить подзадачу размещения панелей управления на шкафах комплекса.
(3) Возникла необходимость расширения формулировки основной задачи системы. Например, первоначальный вариант системы R1 предполагал выполнение компоновки только однопроцессорных вычислительных комплексов, а затем возникла идея поручить этой системе и задачу компоновки многопроцессорных комплексов.
Как показывает опыт работы с системой R1, процесс расширения возможностей системы продолжается до тех пор, пока не завершится ее жизненный цикл. Предметная область вычислительных систем находится в постоянном движении — появляются новые компоненты (устройства) с новыми свойствами, которые по-разному сочетаются друг с другом и с ранее разработанными компонентами. Поэтому в экспертной системе и база данных, и рабочая память находятся в состоянии постоянного изменения. Более того, жизненный цикл системы можно уподобить погоне за движущейся целью, что делает и так непростые ее задачи еще более сложными.
Опыт работы с XCON показал, что непрерывное внесение изменений в систему приводит к определенной ее избыточности. Другими словами, если не предпринимать специальных мер противодействия, то уровень беспорядка в развивающейся системе будет постоянно нарастать. Построение новой системы с самого начала — это слишком дорогое удовольствие как в смысле материальных затрат, так и в смысле времени. Эти ресурсы гораздо целесообразнее направить на разработку средств, облегчающих расширение возможностей существующей системы. Вряд ли существует однозначный ответ на этот вопрос. Грамотный разработчик экспертных систем должен решать эту задачу, принимая каждый раз во внимание конкретные обстоятельства создания и область назначения именно данной системы. Читателям, интересующимся, как решили эту проблему разработчики системы XCON, мы советуем ознакомиться с врезкой 14.2.
В следующей главе будут рассмотрены две другие системы, предназначенные для конструктивного решения проблем, в которых использована более сложная стратегия управления. Дело в том, что в некоторых приложениях экспертных систем не соблюдается описанное в разделе 14.2.3 соответствие условий. Другими словами, не всегда удается на основании локальной информации определить, какая операция должна быть выполнена на следующем шаге, поскольку на текущее состояние задачи не наложены достаточные ограничения. В такой ситуации можно попытаться принять решение таким образом, чтобы оставались открытыми дополнительные возможности, или подготовиться к возможной отмене принятого решения, если позже обнаружится нарушение заданных ограничений. Будет показано, что такая стратегия серьезно усложняет процесс решения, но часто удается справиться с этими трудностями, привлекая на помощь знания из предметной области.
14.2. Совершенствование системы XCON
В течение 1986-1987 годов система XCON подверглась коренной модернизации на основе методологии RIME. Принцип нисходящего разложения проблемы на подзадачи (последние получили в новой терминологии наименование пространства системы— problem spaces) в процессе вычислений, который был реализован в системе R1, остался в неприкосновенности, но была изменена система классификаций правил. За основу новой системы классификации были взяты этапы выполнения алгоритма предложи-и-примени, на которых используется то или иное правило. Каждое пространство проблемы представляет относительно независимую подзадачу и специфицируется тремя параметрами:
управляющая структура, которая описывает метод решения проблем, применяемый в этом пространстве;
знания, которые используются для принятия решения о том, какое пространство проблемы должно быть активным в любой данный момент времени;
операторы, которые позволяют манипулировать объектами в данном пространстве, если оно становится активным.
Таким образом, за каждым пространством проблемы закрепляются правила типов предложение, удаление лишнего и т.д., чем достигается определенная систематизация представления знаний из системы R1. Однако главная особенность такой организации в том, что она обеспечивает применение более систематического подхода к извлечению необходимых знаний. В частности, она позволяет извлекать знания, специфичные для каждой подзадачи, на что обращал внимание Мак-Дермот.
Возвращаясь к системе R1/XCON тремя годами позже, Мак-Дермот отметил, что из опыта ее эксплуатации и модернизации нужно извлечь три урока [McDermott, 1993].
Работа с R1/XCON продемонстрировала важность управляющих знаний, специфичных для определенной предметной области. Обладая достаточными знаниями о том, что делать дальше, программа способна в процессе выполнения сложной задачи определить очередную операцию, пользуясь только локальной информацией.
Система, основанная на порождающих правилах, обеспечивает необходимый механизм уточнения и расширения знаний. В частности, это касается знаний об ограничениях, свойственных каждой подзадаче, и о том, какое подмножество всех возможных операций доступно для конкретной подзадачи. Когда такие отношения превалируют между подзадачами, менее вероятно, что добавление новых правил будет каким-либо образом влиять на уже имеющиеся, относящиеся к прежним задачам.
Для того чтобы экспертная система была признана полезной, она должна не только правильно выполнять возложенные на нее в первоначальном проекте задачи. Интеграция программ, подобных R1, в производственную систему является не менее важным фактором успеха всей разработки, что, как правило, со пряжено с преодолением множества трудностей организационного и даже психологического характера.
Таким образом, модернизация системы XCON вполне оправдала затраты. Конечно, этот вывод нельзя распространять на любую экспертную систему. Для небольших систем вполне может подойти и старое доброе правило "пока оно работает, не трогай его”
