Теоретический анализ процесса приобретения знаний

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

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

Стадии приобретения знаний

В работе [Buchanan et al, 1983] предлагается выполнить анализ процесса приобретения знаний в терминах модели процесса проектирования экспертной системы (рис. 10.1).

Рис. 10.1. Стадии приобретения знаний

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

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

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

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

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

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

Уровни анализа знаний

Приведенное выше разделение на этапы встречается также и в работе Уилинги, который разработал моделирующий подход к инженерии знаний в рамках созданной им среды KADS [Wielinga et al, 1992]. В основе этого подхода лежит идея о том, что экспертная система является не контейнером, наполненным представленными экспертом знаниями, а "операционной моделью", которая демонстрирует некоторое нужное нам поведение в столкновении с явлениями реального мира. Приобретение знаний, таким образом, включает в себя не только извлечение специфических знаний о предметной области, но и интерпретацию извлеченных данных применительно к некоторой концептуальной оболочке и формализацию их таким способом, чтобы программа могла действительно использовать их в процессе работы.

В основу оболочки KADS положено пять базовых принципов.

(1) Использование множества моделей, позволяющее преодолеть сложность процессов инженерии знаний.

(2) Четырехуровневая структура для моделирования требуемой экспертности — набора качеств, лежащих в основе высокого уровня работы специалистов.

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

(4) Процесс дифференциации простых моделей в сложные.

(5) Важность преобразования моделей экспертности с сохранением структуры в процессе разработки и внедрения.

Ниже мы рассмотрим подробно два первых принципа.

Главным мотивом создания оболочки KADS было преодоление сложности знаний. На сегодняшний день у инженеров по знаниям имеется возможность использовать при построении экспертных систем множество самых разнообразных методов и технологий. Однако при этом остаются три основных вопроса:

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

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

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

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

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

В своей ранней работе Уилинга немного по-другому проводил разграничение между уровнями анализа [Wielinga and Breuker, 1986]. Он рассматривал четыре уровня анализа.

Концептуализация знаний. На этом уровне предполагалось формальное описание знаний в терминах принципиальных концепций и отношений между концепциями.
Уровень эпистемологического анализа. Целью такого анализа было выявление структурных свойств концептуальных знаний, в частности таксономических отношений.
Уровень логического анализа. Основное внимание уделялось тому, как строить логический вывод в данной предметной области на основе имеющихся знаний.
Уровень анализа внедрения. Исследовались механизмы программной реализации системы.
В более поздней разработке три первых уровня включены в состав модели экспертно-сти, а уровень анализа внедрения — в модель проектирования. Четырехуровневая структура KADS согласуется с предложенной Кленси схемой разделения знаний различного вида в соответствии с их ролью в процессе решения проблем [Clancey, 1985]. Подробно схема Кленси будет рассмотрена в главе 11. В частности, знания, касающиеся конкретной предметной области, теперь разделены на знания более высокого уровня (знания, относящиеся к построению логического вывода в этой предметной области), знания выбора решаемых задач и знания стратегии решения задач.

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

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

Таблица 10.1. Четырехуровневая схема дифференциации знании в системе KADS


Категория знаний	Организация	Виды знаний
Стратегическая	Стратегии	Планы, метаправила
Задача	Задачи	Цели, управляющие термы, структуры задач
Логический вывод	Структура логического вывода	Источники знаний, метаклассы, схема предметной области
Предметная область	Теория предметной области	Концепции, свойства, отношения

10.1. Оболочки CommonKADS и KASTUS

Описанные принципы построения оболочки системы приобретения знаний получили дальнейшее развитие в системе CommonKADS [Breaker and van de Velde, 1994]. Эта система поддержки инженерии знаний содержит редакторы каждого из перечисленных типов моделей и множество инструментальных средств и компонентов, облегчающих проектирование экспертной системы. Существенную помощь менеджеру проекта при планировании работ должна оказать модель жизненного цикла экспертной системы. В дополнение к тем моделям, которые входили в состав ранних версий оболочки KADS, в новую версию включено несколько новых, в частности модель агента, которая представляет саму экспертную систему, ее пользователей и подключенные вычислительные системы.

В рамках проекта KASTUS онтология и методология оболочки KADS была использована и при построении больших повторно используемых баз знаний [Wielinga and Schreiber, 1994]. Наименование проекта KASTUS — сокращение от Knowledge about Complex Technical Systems for Multiple Use (знания многоразового применения о сложных технических системах). Цель проекта — создание системы знаний, которую можно было бы использовать в множестве разнообразных приложений.

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

Онтологический анализ

Александер и его коллеги предложили еще один уровень анализа знаний, который получил название онтологического анализа [Alexander et al., 1986]. В основе этого подхода лежит описание системы в терминах сущностей, отношений между ними и преобразования сущностей, которое выполняется в процессе решения некоторой задачи. Авторы указанной работы используют для структурирования знаний о предметной области три основные категории:

статическая онтология — в нее входят сущности предметной области, их свойства и отношения;
динамическая онтология — определяет состояния, возникающие в процессе решения проблемы, и способ преобразования одних состояний в другие;
эпистемическая онтология — описывает знания, управляющие процессом перехода из одного состояния в другое.
В этой схеме просматривается совершенно очевидное соответствие с уровнями концептуализации знаний и эпистемологического анализа в структуре, предложенной в уже упоминавшейся работе [Wielinga and Breaker, 1986]. Но на нижних уровнях — логического анализа и анализа внедрения — такое соответствие уже не просматривается. Онтологический анализ предполагает, что решаемая проблема может быть сведена к проблеме поиска, но при этом не рассматривается, каким именно способом нужно выполнять поиск. Примером практического применения такого подхода является система OPAL, описанная ниже в разделе 10.3.2.

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

10.2. Оболочки экспертных систем

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

Такие специальные языки, как правило, обладали двумя видами специфических средств:

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

Система EMYCIN

Примером такой оболочки может служить система EMYCIN, которая является предметно-независимой версией системы MYCIN, т.е. это система MYCIN, но без специфической медицинской базы знаний [van Melle, 1981]. (Само название EMYCIN толкуется авторами системы как "Empty MYCIN" , т.е. пустая MYCIN.) По мнению разработчиков, EMYCIN вполне может служить "скелетом" для создания консультационных программ во многих предметных областях, поскольку располагает множеством инструментальных программных средств, облегчающих задачу проектировщика конкретной экспертной консультационной системы. Она особенно удобна для решения дедуктивных задач, таких как диагностика заболеваний или неисправностей, для которых характерно большое количество ненадежных входных измерений (симптомов, результатов лабораторных тестов и т.п.), а пространство решений, содержащее возможные диагнозы, может быть достаточно четко очерчено.

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

Язык представления правил. В системе EMYCIN такой язык использует систему обозначений, аналогичную языку ALGOL. Этот язык, с одной стороны, более понятен, чем LISP, а с другой— более строг и структурирован, чем тот диалект обычного английского, который использовался в MYCIN.
Индексированная схема применения правил, которая позволяет сгруппировать правила, используя в качестве критерия группировки параметры, на которые ссылаются эти правила. Так, правила, применяемые в MYCIN, разбиваются на группы: CULRULES — правила, относящиеся к культурам бактерий, ORGRULES — правила, касающиеся организмов, и т.д.
Использование обратной цепочки рассуждений в качестве основной стратегии управления. Эта стратегия оперирует с И/ИЛИ-деревом, чьи листья представляют собой данные, которые могут быть найдены в таблицах или запрошены пользователем.
Интерфейс между консультационной программой, созданной на основе EMYCIN, и конечным пользователем. Этот компонент оболочки обрабатывает все сообщения, которыми обмениваются пользователь и программа (например, запросы программы на получение данных, варианты решения, которые формирует программа в ответ на запросы пользователя, и т.п.).
Интерфейс между разработчиком и программой, обеспечивающий ввод и редактирование правил, редактирование знаний, представленных в форме таблиц, тестирование правил и выполнение репрезентативных задач.
Значительная часть интерфейса реализуется отдельным компонентом EMYCIN — программой TEIRESIAS [Davis, 1980,b]. Эта программа представляет собой "редактор знаний", который упрощает редактирование и сопровождение больших баз знаний. Редактор проверяет синтаксическую корректность правил, анализирует взаимную непротиворечивость правил в базе знаний и следит за тем, чтобы новое правило не являлось частным случаем существующих. Противоречие возникает, когда два правила с одинаковыми антецедентами имеют противоречивые консеквенты. Одно правило является частью другого в том случае, когда совокупность условий антецедента одного правила представляет собой подмножество совокупности условий другого правила, а их консеквенты одинаковы. Но в состав TEIRESIAS не включены знания о какой-либо конкретной предметной области или о стратегии решения проблем, которая может быть использована в проектируемой экспертной системе.

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

Сопровождение и редактирование баз знаний с помощью программы TEIRESIAS

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

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

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

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

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

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

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

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

Таким образом, в программе TEIRESIAS можно выделить три уровня обобщения:

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

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

Режим объяснения (EXPLAIN). После выполнения каждого очередного задания — консультации — система дает объяснение, как она пришла к такому заключению. Распечатываются каждое правило, к которому система обращалась в процессе выполнения задания, и количественные параметры, связанные с применением этого правила, в том числе и коэффициенты уверенности.
Режим тестирования (TEST). В этом режиме эксперт может сравнить результаты, полученные при прогоне отлаживаемой программы, с правильными результатами решения этой же задачи, хранящимися в специальной базе данных, и проанализировать имеющиеся отличия. Оболочка EMYCIN позволяет эксперту задавать системе вопросы, почему она пришла к тому или иному заключению и почему при этом не были получены известные правильные результаты.
Режим просмотра (REVIEW). В этом режиме эксперт может просмотреть выводы, к которым приходила система при выполнении одних и тех же запросов из библиотеки типовых задач. Это помогает просмотреть эффект, который дают изменения, вносимые в набор правил в процессе наладки системы. В этом же режиме можно проанализировать, как отражаются изменения в наборе правил на производительности системы.
Нужно отметить, что не существует общепринятой методологии использования режима REVIEW, но в литературе имеются сообщения об исследовании процесса настройки отдельных правил (см., например, [Langlotz et al., 1986]) и оптимизации набора правил с помощью этого режима (например, [Wilkins and Buchanan, 1986]). Об этих работах мы поговорим в главе 20.

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

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

Методы приобретения знаний

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

Использование опроса экспертов для извлечения знаний в системе COMPASS

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

В процессе работы в системе переключения непрерывно выполняется самотестирование. При этом проверяется, нет ли разрыва в цепях, короткого замыкания, замедления срабатывания переключающих схем и т.д. При возникновении каких-либо нестандартных ситуаций система самотестирования формирует соответствующее сообщение. Причина появления неисправности в системе переключения может быть выявлена только на основании множества таких сообщений, причем на помощь приходит опыт специалистов-экспертов. Эти сообщения поступают в экспертную систему COMPASS, которая может предложить провести какой-либо специальный дополнительный тест или заменить определенный узел в системе (реле или плату). Система разработана компанией GTE и эксплуатируется во множестве ее филиалов [Рrеrаи, 1990].

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

ЕСЛИ

существует проблема "ВС Dual Expansion One PGA" и количество сообщений пять или более,

ТО

отказ в узле PGA, в котором горит индикатор расширения (.5), и отказ в резервном узле PGA (.3), и отказ в узле IGA (.1), и отказ в плате переключателей D2 (.1).

Обычно такие правила вводились в систему в виде одного или нескольких производящих правил на языке КЕЕ (подробнее речь о нем пойдет в главе 17), хотя в некоторых случаях более целесообразным кажется использование механизма представления фреймов или языка LISP. Сформулированные на английском языке правила накапливались в библиотеке "документированных знаний", которая являлась одним из компонентов комплекта документации экспертной системы. Эта библиотека помогала сохранить "первоисточник знаний", что очень помогло в процессе настройки и опытной эксплуатации системы.

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

(1) В процессе собеседования с экспертом извлечь определенные знания.

(2) Задокументировать извлеченные знания.

(3) Проверить новые знания:

попробовать применить их на разных наборах данных;
смоделировать вручную, к каким результатам приведет использование этих знаний;
сравнить результаты моделирования с теми, которые должны получиться по мнению эксперта;
если результаты отличаются, то определить, какие именно правила и процедуры внесли "наибольший вклад" в это отличие; вернуться к п. (1) и выяснить у эксперта, как следует скорректировать подозрительное правило или процедуру.
Графически циклическая процедура приобретения знаний представлена на рис. 10.2.

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

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

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

Рис. 10.2. Циклическая процедура приобретения знаний в системе COMPASS

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

Автоматизация процесса извлечения знаний в системе OPAL

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

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

Графический интерфейс модели предметной области

Программа OPAL упрощает процесс извлечения знаний, предназначенных для использования в экспертной системе ONCOCIN [Shortliffe et at, 1981]. Последняя формирует план лечения больных онкозаболеваниями и заинтересована в использовании модели предметной области для получения знаний непосредственно от эксперта с помощью средств графического интерфейса. Понятие модель предметной области можно трактовать в терминах знаний различного вида, которыми обладает эксперт.

Независимо от того, о какой конкретной предметной области идет речь, игре в шахматы или медицинской диагностике, всегда существуют некоторые предварительные условия или предварительный опыт, которыми должен обладать субъект или техническая система, чтобы воспринимать знания об этой предметной области. Если речь идет об игре в шахматы, то по крайней мере нужно знать правила этой игры: как ходят фигуры, в чем цель игры и т.п. Применительно к медицинской диагностике нужно иметь представление о пациентах, заболеваниях, клинических тестах и т.п. Этот вид фоновых, или фундаментальных, знаний иногда в литературе по экспертным системам называют глубокими знаниями {deep knowledge), противопоставляя их поверхностным знаниям (shallow knowledge), которые представляют собой хаотичный набор сведений о связях "стимул — реакция".

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

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

Рис. 10.3. Процесс приобретения знаний с использованием модели предметной области

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

В экспертной системе ONCOCIN используются три разных метода представления знаний:

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

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

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

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

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

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

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

Эффективность программы OPAL

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

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

Технология извлечения знаний о предметной области у эксперта посредством опроса через терминал в последнее время стала использоваться во множестве экспертных систем. В большинстве из них эксперту предлагается заполнить экранные формуляры, информация из которых затем считывается в структурированные объекты, аналогичные фреймам. Примерами таких систем могут служить ETS [Boose, 1986] и Student [Gale, 1986]. Но далеко не во всех системах такого рода имеется столь развитый графический интерфейс, как в программе OPAL, и существует возможность компилировать полученные знания непосредственно в правила принятия решений. Реализация этих возможностей в OPAL существенно облегчается особенностями структурирования планов лечения онкобольных, на что обращали внимание и авторы этой разработки.

Опыт, приобретенный в ходе разработки программы OPAL, был затем использован при создании PROTEGE — системы более общего назначения [Musen et al., 1995]. Последняя версия этой системы, PROTEGE-II, представляет собой комплект инструментальных средств, облегчающих создание онтологии предметной области и формирование программ приобретения знаний, подобных OPAL, для различных приложений. Вместо того чтобы разрабатывать инструментальные средства общего назначения с нуля, авторы этой разработки пошли по пути повышения уровня абстракции ранее разработанного и успешно используемого приложения, как это было сделано при разработке системы EMYCIN на основе MYCIN.

10.4. Приобретение новых знаний на основе существующих

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

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

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

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

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

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

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

и руководства по поиску неисправностей.

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

Например, руководство к пистолету "Кольт .45" включает шесть страниц советов, большинство из которых представлено в форме подобных таблиц.


Где?	Что?	Проверить	Примечание
Боек	Зажимается	Прямизну	При необходимости заменить
Эжектор	Неустойчивое выбрасывание	Зажимается ли возвратная пружина	Установить длинную направляющую
Экстрактор	Неправильно направляет гильзу	Угол установки дна	При необходимости выровнять

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

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

I) Выберите ту предметную область, которая вам более всего знакома, и разработайте для нее примерную онтологию в терминах:

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

;; #################################

;; # Поиск неисправностей в револьвере

;; # Smith & Wesson

;; #################################

;; Класс REVOLVER, определение компонентов (defclass revolver

(is-a INITIAL_OBJECT)

(slot barrel Jcreate-accessor read-write))

(slot barrel-pin

(create-accessor read-write))
(slot cyl-stop

(create-accessor read-write))
(slot cyl (create-accessor read-write))
(slot handspring

(create-accessor read-write))

)

;; Экземпляр класса REVOLVER.
;; Предназначен для тестирования программы,
(definstance guns (Ml9 of revolver

(barrel 4499)

(barrel-pin 4499)

(cyl-stop 4499)

(cyl 4499)

(handspring 5022)) )

;; МЕТОД . Получение номера детали револьвера
(def mas sage-handler revolver part-no (?part)
(dynamic-get ?part))

;; ПОЛЕЗНЫЕ ФУНКЦИИ

;; Приглашение пользователю ввести данные
(deffunction prompt ()

(printout t crlf "USER> "))

;; Распечатка списка деталей.
;; Замечание: приведенный список правил касается
;; только неисправностей со стволом (barrel),
(deffunction parts-list () (printout t crlf

"barrel cylinder ejector trigger hammer

firing-pin cylinder-stop

cylinder-hand yoke

frame sideplate rear-sight front-sight" crlf))

;; Выбор из списка.

(deffunction choose-list ()

(printout t crlf "Please choose from the following list: "

crlf))

;; Правила, которые относятся только к
;; револьверам модели 19.
(deffunction kind-list ()

(printout t crlf "M10 M12 M13 M14 M15 M16 M17 M18 M19 "

crlf) )

;; ШАБЛОНЫ РЕШЕНИЯ ПРОБЛЕМЫ

;; Формулировка проблемы включает узлы (part),
;; симптомы (symptom), возможно, детали (subpart),
;; входящие в состав узлов. С проблемой может
;; быть связано определенное испытание или
;; проверка (check), которые нужно провести,
(deftemplate problem

(field part (type SYMBOL) (default nil))
(field symptom (type SYMBOL) (default nil))
(field subpart (type SYMBOL) (default nil))
(field check(type SYMBOL) (default nil)) )

определение процедуры ремонта включает узел (part), операцию с этим узлом (action), возможно, детали (subpart), входящие в состав узлов, проверку (check), которую нужно провести, и поясняющее примечание, предназначенное для пользователя, (deftemplate problem

(field part (type SYMBOL)
(default nil)} (field action (type SYMBOL)
(default nil)) (field subpart (type SYMBOL)
(default nil)) (field check(type SYMBOL)
(default nil)) (field remarkftype STRING)
(default " "))

)

;;########################
;;

;; Порождающие правила

;; Правило START.

;; ЕСЛИ: начинается выполнение программы
;; ТО: определить поврежденный узел и
;; сформировать шаблон описания проблемы,

(defrule start

?start-token <- (initial-fact) =>

(retract ?start-token)

(printout t crlf

"What part of the gun are you problem with?"
;; С каким узлом у вас проблемы?

(choose-list)

(part-list)

(prompt)

(bind ?part (read))

(assert (problem (part ?part))) )

;; Правило FINISH:

;; ЕСЛИ: Неисправность устранена

;; TO: Прекратить работу программы.

(defrule finish

(repair (check done) (remark ?rem&~" "))

=>

(printout t crlf ?rem crlf)

(printout t crlf "Glad to be of service! " crlf)
;; Рад быть вам полезным!

(halt) )

Правило CHECK-REPAIR:

ЕСЛИ: Имеется решение менее радикальное, чем

замена

ТО: Информировать пользователя и отметить, что неисправность (проблема) может быть устранена путем ремонта,
(defrule check-repair ?rep <-
(repair (part ?part) (action ?actions~replace)

(subpart ?sub&~nil&~?part))
(problem (part ?part) (symptom ?sym))

=>

(printout t crlf

"If you " ?action "the " ?sub "that should "

"fix the " ?sym "problem with the," ?part crlf)

;; "Если вы " ?action ?sub "то это' должно "

;; "устранить " ?sym "проблемы с " ?part crlf)
(modify ?rep (check done))

)

Правило CHECK-REPLACE:

ЕСЛИ:
Решение требует замены узла
ТО:
Информировать пользователя и отметить, что неисправность (проблема) устранена. Для этого добавить в рабочую память пустой вектор и запросить у пользователя наименование модели
;; изделия,

(defrule check-replace

(repair (part ?part) (action replace))
(not (model ?mod&~nil))

?prob <- (problem (part ?part)
(symptom ?sym)) =>

(printout t crlf

"You have to replace the "
?part "to fix the " ?sym "problem" crlf)
;; "Вам потребуется заменить" ?part
;; "чтобы устранить " ?sym "проблемы " crlf)

(assert (model nil)) )

;; Правило REPLACE:

;; ЕСЛИ: Пользователю необходимо заменить узел
;; ТО: Запросить у пользователя наименование
;; модели изделия,

(defrule replace

?rep <- (repair (action replace))

?mod <- (model nil) =>

(printout t crlf

"What model of revolver do you have ?" crlf)
;; "Какой модели ваш револьвер?"

(kind-list)

(prompt)

(bind ?answer(read))

(retract ?mod)

(assert (model ?answer))

(modify ?rep (check part-no))

)

;; Правило PART-NO:

;; ЕСЛИ: Пользователю необходимо заменить узел
;; ТО: Выяснить номер узла, отослав сообщение
;; объекту, представляющему данную модель

;; изделия,

(defrule part-no

(model ?mod£Tnil)

?rep <- (repair (part ?part)
(action replace) (check part-no)) =>

(bind ?no (send (symbol-to-instance-name ?mod)
part-no ?part))

(printout t crlf

"The part number of the " ?mod " " ?part "
is " ?no crlf) ;; "Номер узла " ?mod " " ?part ?no

(modify ?rep (check done)) )

;; Правила BARREL (ствол)

;; Правило BARREL-SYMPTOM
;; ЕСЛИ: Неисправность не имеет признаков
;; ТО: Выяснить признак (симптом),
(defrule barrel-symptom

?prob <- (problem (part barrel)
(symptom nil) (subpart nil))

=>

(printout t crlf

"Is there a problem inside barrel? " crlf)
;; "Есть ли повреждения внутри ствола?"

(prompt)

(bind ?answer(read))

(if (eq ?answer yes)

then (modify ?prob (subpart bore))

) )

;; Правило BARREL-INSIDE

;; ЕСЛИ: Имеется повреждение канала ствола

;; ТО: Выяснить у пользователя,

;; какое (и предложить помощь).

(defrule barrel-inside

?prob <- (problem (part barrel) (symptom nil) (subpart bore))

^=>

(printout t crlf

"What is the problem inside the barrel? " crlf)
;; "Характер повреждения канала ствола?"
(choose-list) (printout t crlf "
leading rust jam" crlf)

;; " наличие ржавчины"

(prompt)

(bind ?answer (read))

(modify ?prob (symptom ?answer)) )

;; Правило BARREL-RUST
;; ЕСЛИ: Имеется ржавчина в канапе ствола
;; ТО: Проверить наличие раковин.
(defrule barrel-rust

?prob <- (problem (part barrel) (symptom rust) =>

(printout t crlf

"Are there pits inside the barrel? " crlf)
;; "Нет ли раковин в канале ствола?" (prompt)

(bind ?answer (read))
(if (eq ?answer yes) then (assert (repair

(action replace) (part barrel) (subpart bore))

(remark "Please consult your local dealer")))
;; Проконсультируйтесь с местным дилером

else (assert (repair

(action clean) (part barrel) (subpart bore))

(remark "Gun should be kept clean and dry"))
;; Оружие нужно содержать в чистоте и
;; предохранять от сырости

) )

;; Правило BARREL-LEADING
;; ЕСЛИ: Имеется налет свинца в канале ствола
;; ТО: Проверить качество патронов,
(defrule barrel-leading

?prob .<- (problem (part barrel) (symptom

leading) (check nil))

=>

(modify ?prob (check ammo))

(printout t crlf

"You may be using the wrong ammunition " crlf)
;; "Возможно, вы пользуетесь некачественными
;; патронами" )

;; Правило BARREL-LEADING-CHECK
;; ЕСЛИ: Имеется налет свинца в канале ствола
;; ТО: Проверить качество патронов,
(defrule barrel-leading-check

Pprob <- (problem (part barrel) (symptom

leading) (check ammo))

=>

(assert (repair (part barrel)
(action clean) (subpart bore)

(remark "Use Lewis Lead Remover"))
;; Воспользуйтесь средством для удаления свинца
;; фирмы Lewis )

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

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

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

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

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

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

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