Совершенствование системы XCON

В течение 1986-1987 годов система XCON подверглась коренной модернизации на основе методологии RIME. Принцип нисходящего разложения проблемы на подзадачи (последние получили в новой терминологии наименование пространства системы— problem spaces) в процессе вычислений, который был реализован в системе R1, остался в неприкосновенности, но была изменена система классификаций правил. За основу новой системы классификации были взяты этапы выполнения алгоритма предложи-и-примени, на которых используется то или иное правило. Каждое пространство проблемы представляет относительно независимую подзадачу и специфицируется тремя параметрами:

управляющая структура, которая описывает метод решения проблем, применяемый в этом пространстве;

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

Операторы, которые позволяют манипулировать объектами в данном пространстве, если оно становится активным.

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

Возвращаясь к системе R1/XCON тремя годами позже, Мак-Дермот отметил, что из опыта ее эксплуатации и модернизации нужно извлечь три урока [McDermott, 1993].

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

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

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

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

Рекомендуемая литература

Процесс разработки и модернизации системы R1/XCON достаточно подробно отражен в технической литературе, однако назвать единственный источник, в котором можно было бы найти все детали этого проекта, затруднительно. Хорошей отправной точкой для знакомства с этим проектом может послужить работа [McDermott and Bachant, 1984]. Рекомендуется обратить внимание еще на одну совместную разработку университета Карнеги—Меллон и фирмы Digital Equipment— систему XSEL ([McDermott, 1982,bJ, [McDermott, 1984]}. Это программа, написанная на языке OPS5, которая помогает клиентам фирмы выбрать компоненты вычислительного комплекса VAX и разместить элементы комплекса в производственном помещении.

Весьма интересный анализ сильных и слабых сторон методов с ограничением роли выполнен в работе [Мшеп, 1992], которую рекомендуется прочесть вслед за статьей Мак-Дермота [McDermott, 1988]. В работе [Studer et al, 1998] обсуждаются как методы с ограничением роли, так и порождающие задачи, причем в качестве примера при обсуждении концепций используются системы CommonKADS и PROTEGE-II.

Упражнения

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

2. Что представляет собой метод Match? Какие "условия соответствия" должны быть соблюдены для того, чтобы этот метод сработал?

3. В чем состоит стратегия специфики, применяемая для разрешения конфликтов, и как она реализована в системе R1?

4. Детально опишите использование контекста в процессе работы системы R1. "Понимает" ли сама система используемую в ней стратегию решения проблемы нисходящим уточнением?

5. Что представляет собой "пространство проблемы" в методологии RIME и какую роль оно играет?

В чем преимущество использования более явного представления стратегии, реализованного при модернизации системы XCON?

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

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

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

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

стиль игры (ритмический, с медиатором и т.д.);

предпочтительная тональность ("жирный" или "тонкий" звук, "сладкий" или более резкий и т.п.);

"образцы для подражания", стилю игры которых следует пользователь (например, Клептон, Бек, ван Хален и т.д.);

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

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

Анализ задачи. Используйте тот же вид анализа задачи, который мы применяли в отношении системы R1, т.е. разложение задачи на подзадачи. Отправной точкой может послужить И/ИЛИ-дерево, приведенное на рис. 14.2. Постарайтесь либо построить систему на определенную глубину дерева, либо сделать ее более специализированной, "разрисовав" подробнее одно из поддеревьев, выбор усилителя или гитары.

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

Рис. 14.2. Дерево анализа задачи проектирования конфигурации музыкального комплекса

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