Области применения методов

b>конструктивного решения проблем

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

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

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

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

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

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

14.2. Система R1/XCON

Система R1 была одной из первых успешных попыток применения экспертных систем в промышленности в начале 1980-х годов [McDermott, 1980], [McDermott, 1981], [McDermott, 1982,а]. Эта система предназначена для помощи разработчикам при определении конфигурации вычислительной системы на базе вычислительных устройств и блоков семейства VAX. Сначала программа проверяет полноту спецификации требований к проектируемой системе, которая представлена заказчиком. На втором этапе программа определяет конфигурацию системы, соответствующую этим требованиям. Коммерческая версия системы, разработанная совместно университетом Карнеги—Меллон и корпорацией Digital Equipment, получила наименование XCON. При описании истории разработки мы иногда будем обращать ваше внимание на отличия между начальным проектом и его коммерческой версией.

Первым практическим применением системы XCON была разработка конфигурации вычислительного комплекса VAX-11/780 на заводе фирмы DEC в Салеме, шт. Нью-Гемршир. Затем последовала разработка конфигураций других типов вычислительных комплексов, таких как VAX-11/750 и последующих модификаций продукции DEC. Наш интерес к этой экспертной системе объясняется тем, что она продемонстрировала, чего можно достичь при использовании даже относительно слабого метода решения проблем, если имеется достаточно знаний о предметной области. История развития этой системы также показывает, как расширяется сфера применения коммерческой экспертной системы при правильном менеджменте и как системы такого типа "врастают" в производственную среду.

Задачу системы R1 нельзя отнести к типу тривиальных. Типовой вычислительный комплекс включает 50-100 компонентов, главными из которых являются центральный процессор, устройство управления оперативной памятью, блоки управления интерфейсом по шинам UNIBUS и MASSBUS, причем все эти компоненты подключены к единой плате синхронизации. Шинные интерфейсы поддерживают обмен с широкой номенклатурой периферийных устройств — устройствами внешней памяти на магнитных лентах и дисках, принтерами и т.п. В результате имеется возможность строить системы самой различной конфигурации.

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

Компоненты и ограничения

Хотя и R1, и MYCIN являются программами, использующими в своей работе порождающие правила, между ними имеется ряд серьезных отличий. Одно из них состоит в том, что в MYCIN процесс решения проблемы направляется гипотезами (hypothesis-driven), т.е. процесс начинается с формулировки определенной цели, а затем она преобразуется в набор подцелей, совместное достижение которых позволяет достичь главной цели (см. об этом в главе 3). В системе R1 главным является подход, предполагающий, что процесс решения направляется данными (data-driven). Сначала программа определяет множество компонентов и далее пытается сконструировать такую конфигурацию этих компонентов, которая удовлетворяла бы ограничениям, вытекающим как из характеристик отдельных компонентов, так и из отношений и связей между ними. Для реализации программы был использован язык OPS5, один из первых языков представления правил, прямой предшественник языка CLIPS.

Для успешной работы программа R1 нуждается в знаниях двух видов:

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

RK611

CLASS: UNIBUS MODULE

TYPE: DISK DRIVE

SUPPORTED: YES

PRIORITY LEVEL: BUFFERED NPR

TRANFER RATE: 212

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

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

Система R1 хранит порядка 10 000 правил, значительная часть которых определяет, какое следующее действие должна выполнить программа. Пример одного из таких правил приведен ниже.

DISTRIBUTE-MB-DEVICES-3

ЕСЛИ: предыдущим активным контекстом является расширение количества

устройств, подключаемых к шине .MASSBUS

& имеется однопортовый НМД, не подключенный к MASSBUS

& отсутствуют двухпортовые НМД, еще не подключенные к MASSBUS

& количество устройств, которое можно подключить к расширителю MASSBUS,

известно

& существует расширитель MASSBUS, к которому подключен по крайней мере

один НМД и который может

поддерживать дополнительные НМД

& известен тип кабеля, которым должен быть связан НМД с ранее установленным устройством

ТО: подключить НМД к MASSBUS

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

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

Использование текущего контекста для управления структурой задачи

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

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

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

(1) Проверить заказ, уточнить все пропущенные в нем сведения и исправить замеченные ошибки.

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

(3) Включить в конфигурацию модули расширения шины UNIBUS, определить состав блоков в стойке расширения интерфейса.

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

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

(6) Разработать схему соединения стоек и выбрать типы кабелей.

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

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

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

Общепринято размещать условия распознавания контекста в самом начале антецедентной части порождающего правила. В результате, если это условие не соблюдается, не тратится время на анализ остальных. Кроме того, стратегия разрешения конфликтов в системе R1 (она получила название ME А) обращает особое внимание на первое условие в правиле после его конкретизации перед возможным применением. У правил, которые деактивизируют контекст, антецедентная часть состоит из единственного символа контекста. Такое правило будет применено только после всех остальных правил, чувствительных к тому же контексту. Это пример использования стратегии специфики. Следуя этой стратегии, система R1 сначала выполняет все действия, связанные с определенным контекстом, а уже после этого изменяет его.

Основная эвристика специфики состоит в следующем. Если существуют два конфликтующих правила Rule 1 и Rule 2 и условия, специфицированные в правиле Rule 2, являются подмножеством условий, специфицированных в правиле Rule 1, то правилу Rule 1 дается более высокий приоритет, чем правилу Rule 2. Можно и по-другому рассматривать эту эвристику. Правило Rule 2 является более "общим", чем правило Rule 1, и оно обрабатывает по умолчанию те случаи, которые не "охватываются" более специализированным правилом Rule 1. При этом фактически правило Rule 1 имеет дело с исключениями из общего правила Rule 2, поскольку в нем принимаются во внимание дополнительные условия (рис. 14.1).

Рис. 14.1. Пример применения стратегии специфики: правило Rule 1 доминирует над правилом Rule 2

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

Мак-Дермот (McDermott) конкретизировал использование контекстов состояния применительно к задаче формирования конфигурации вычислительной системы. Он считает, что этот способ довольно хорошо передает подход к решению аналогичных задач экспертом-человеком. Нужно, однако, отметить, что система R1 не располагает реальными знаниями о свойствах контекста, с которым имеет дело. Имена контекста— это только некоторые символические обозначения, в отличие от компонентов, с которыми связаны все виды атрибутов и значений. Следовательно, система R1 не может "рассуждать" о контекстах так же, как она "рассуждает" о компонентах или ограничениях. Система просто распознает состояние, когда ей необходим новый контекст или когда завершены все операции, связанные с данным контекстом.

14.1. Стратегии разрешения конфликтов LEX и МЕА

В главе 5 были упомянуты стратегии разрешения конфликтов LEX и МЕА, реализованные в языке CLIPS. Ниже будет в общих чертах рассмотрена реализация стратегии МЕА, которая использована в системе R1/XCON.

Как было показано в главе 3, анализ "средство — анализ результата" является абстрактным режимом формирования цепочки обратного логического вывода в случае, когда определена некоторая цель. Этот режим позволяет выбрать операторы или правила, которые способны сократить "расстояние" между текущим и заданным целевым состоянием проблемы. Несложно показать, как этот режим можно использовать в контексте порождающей системы с обратной стратегией логического вывода, например MYCIN, когда весь процесс начинается с цели самого верхнего уровня общности (см. главу 3). В системах, использующих прямой логический вывод, которые строятся на основе языковых средств OPS5 или CLIPS, применяется стратегия разрешения конфликтов МЕА. Основанный на ней режим управления позволяет программе "продвигаться" по неявно заданному дереву целей, которые представлены специальными лексемами в рабочей памяти экспертной системы.

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

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

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

равным приоритетом, они сохраняются в конфликтующем множестве, а прочие из него удаляются. Далее выполняется переход к шагу (3).

(3) Упорядочить конкретизированные правила по "новизне" остальных элементов условий в правилах. Если доминирует единственное правило, оно применяется и затем процесс прекращается. Если же доминируют два или несколько правил, то они остаются в конфликтующем множестве, а остальные удаляются из него. Затем выполняется переход к шагу (4),

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

(5) Применяется правило, выбранное произвольным образом из оставшихся в конфликтующем множестве, и процесс прекращается.

Таким образом, стратегия МЕА объединяет в едином алгоритме анализ таких показателей, как повторяемость, новизна и специфика. Алгоритм LEX практически идентичен алгоритму МЕА за одним исключением — в нем отсутствует шаг 2), а на шаге 3) сравниваются все элементы условий конкретизированных правил и связанных с ними элементов рабочей памяти. Первые элементы условий, которые использовались на шаге 2), являются, как правило, лексемами задач в рабочей памяти (в главе 5 приведен пример программы, которая манипулирует такими лексемами).

Формирование суждений с учетом ограничений: метод Match

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

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

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

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

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

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

Метод Match можно рассматривать как метод поиска экземпляра, который означивал бы (конкретизировал) определенную "форму", — символическое выражение, содержащее переменные. Примером такой формы может служить левая часть выражения порождающего правила. Таким образом, пространством поиска для метода Match является "пространство всех означиваний переменных в форме" [McDermott, 1982, а, р. 54]. Каждое состояние в этом пространстве соответствует частично означенной форме.

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

Соответствие условий. При сравнении конкретизированного экземпляра с образцом должна существовать возможность определить значение переменной на основе ограниченной информации локального характера. Применительно к системе R1 это означает возможность на любой стадии пользоваться только той информацией, которая доступна в рамках текущего контекста. Решение не должно зависеть от информации, доступной в каких-либо других контекстах ("дочерних" или "братских"), как бы близко к текущему они ни находились в иерархии контекстов. Это не означает, что контексты должны быть независимы; просто последующие сопоставления не должны использовать те, которые были выполнены раньше.
Однонаправленное распространение условий. Применение какого-либо оператора должно сказываться только на тех компонентах решения, которые до сих пор не были определены. Другими словами, применение какого-либо оператора не должно давать никаких побочных эффектов, которые могли бы повлиять на уже сформированные компоненты решения. Само название условия говорит о том, что последствия применения операторов должны распространяться только в одном направлении — от текущего контекста к "дочерним" и еще не проанализированным "соседним", но не в обратном направлении, — к "родительским" контекстам.
Мак-Дермот разделил все правила системы R1 на три категории в зависимости от их отношения к методу Match.

(1) Правила применения операторов, которые формируют и модифицируют частичную конфигурацию.

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

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

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

Использование знаний, развитие и расширение системы XCON

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

Извлечение знаний в системе 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. А вот второе правило кажется очень тесно связанным со спецификой размещения устройств отдельных типов в шкафах и их взаимной компоновкой. Более того, в этом правиле использованы отношения между объектами предметной области, которые можно отнести к разным уровням абстракции. Мак-Дермот обратил внимание на то, что тот вид суждений, который представлен в таких правилах, будет меняться от одной области применения системы к другой, а следовательно, его не удастся обобщить.

Совершенствование и расширение системы 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 вполне оправдала затраты. Конечно, этот вывод нельзя распространять на любую экспертную систему. Для небольших систем вполне может подойти и старое доброе правило "пока оно работает, не трогай его",

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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