Хотя на этапе внедрения экспертной системы возникает очень много сложностей, до сих пор не предпринималось попытки их каким-либо образом систематизировать. В этом разделе мы ставили перед собой задачу познакомить пользователя с проблемами, наиболее часто возникающими при внедрении, и тем, как их избежать, как выбрать подходящие инструментальные средства для инженерии знаний, как организовать освоение и использование этих средств на практике. Возможно, приведенный ниже материал покажется вам в определенной мере противоречивым, но мы старались представить в нем как можно более широкий спектр существующих на сей счет мнений
17.4.1. Характерные сложности и способы их избежать
В своей книге Уотерман перечисляет следующие "ловушки", поджидающие разработчика экспертной системы на этапе внедрения, и дает рекомендации, как их избежать [Waterman, 1986, Chapter 19].
Знания, касающиеся предметной области, слишком тесно переплетены с остальной частью программы. В частности, невозможно разделить эти знания и знания общего применения, касающиеся способов поиска в пространстве решений. Уотерман предполагает, что этого можно достичь, положив в основу организации базы знаний набор правил, хотя из замечаний, сделанных Кленси и Эйкинс, следует, что такая организация отнюдь не гарантирует достижение ожидаемого результата.
Та база знаний, которая сформировалась после извлечения и представления сотен правил в процессе опроса экспертов, может оказаться все-таки настолько неполной, что не позволит решить и простую задачу, поскольку в ней отсутствуют фундаментальные концепты предметной области или эти концепты представлены с ошибками. Уотерман рекомендует последовательно наращивать объем базы знаний, причем начинать с фундаментальных понятий. Это позволит еще на ранних стадиях разработки обнаружить указанную проблему. Он советует выполнять тестирование на каждом этапе разработки, используя для этого подходящие инструментальные средства инженерии знаний.
Среда разработки не располагает встроенными средствами формирования функций пояснения экспертной системы, а добавление таких функций в уже спроектированную систему — задача не из легких. Уотерман советует позаботиться о прозрачности экспертной системы с первых же шагов ее разработки. Это очень ценный совет, поскольку без хорошего "окна", через которое можно заглянуть в "машинный зал" программы, даже ее создатель не сможет понять, что же она на самом деле делает.
Система содержит чрезмерно большое количество слишком специфических правил. Это, во-первых, приводит в замедлению работы системы, а во-вторых, затрудняет управление ею. Уотерман рекомендует объединять, где только возможно, мелкие правила в более общие. Как мы видели в разделе 17.2, это не что иное, как стремление найти компромисс между более мощными правилами и правилами, более понятными.
В следующих трех разделах мы остановимся на важных и сложных вопросах, которые следуют из представленного ниже перечня.
Как подобрать подходящий инструментарий для проектирования экспертной системы?
Насколько в действительности такие средства просты в обращении?
Что такое "хороший стиль программирования" в выбранной среде разработки?
Ответы на эти вопросы оттодь не очевидны, но любой разработчик экспертных систем не избежит необходимости отыскать их. Тот поход, которым я воспользовался при поиске этих ответов, базируется частично на авторитетном мнении ведущих специалистов в этой области, а частично на анализе имеющегося опыта проектирования. В конце главы будут приведены некоторые полезные рекомендации, почерпнутые из литературы.
17.4.2. Выбор подходящего инструментария для разработки экспертной системы
В работе [Hayes-Roth et al, 1983, Chapter 1] собраны рекомендации по выбору подходящих инструментальных средств построения экспертной системы. В основу рекомендаций положено сопоставление характеристик задач, решаемых проектируемой экспертной системой, и необходимых функциональных возможностей инструментального комплекса.
Общность. Выбрать инструмент со степенью общности, не превышающей той, которая необходима для решения данной задачи. Например, если для данной задачи сложный механизм управления не является жизненно необходимым, использовать его не только расточительно, но и нежелательно.
Выбор. Выбор инструментария должен определяться в первую очередь характеристиками задачи, решаемой экспертной системой, а не другими привходящими обстоятельствами, например тем, что какой-то инструмент уже есть под рукой или знаком вам лучше остальных. Авторы цитируемой работы затем развили свою мысль, опираясь на классификацию экспертных систем, о которой речь пойдет ниже.
Быстрота. Если успех проекта зависит от срока разработки, то следует выбирать инструментальную среду со встроенными средствами формирования пояснений и развитым пользовательским интерфейсом. Разработка интерфейса — одна из наиболее трудоемких стадий проектирования системы, и чем большую часть этой работы можно переложить на среду разработки, тем быстрее будет завершен проект.
Испытание. Постарайтесь как можно быстрее провести испытания новой для вас инструментальной среды. Без сомнения, это полезный совет, однако открытым остается вопрос о том, как определить степень совершенства инструмента по результатам испытаний.
Важнейшим для выбора инструментальной среды является вопрос о способе определения характеристик проблемы, решаемой проектируемой экспертной системой. Этот вопрос обсуждается в работе [Stefik et al, 1983], где предлагается схема анализа, основанная на свойствах пространства поиска решения. Я позволил себе несколько обобщить предлагаемые авторами работы категории проблем и свел 11 Категорий к четырем, хотя основные принципы классификации остались прежними.
(1) Малое пространство решений, надежные данные и знания. Предполагается, что количество альтернатив, которые следует принимать во внимание при поиске решения, невелико и что все данные достоверны, а истинность правил не вызывает сомнений. В таком случае возможно выполнять исчерпывающий поиск в пространстве решений и при необходимости организовать возврат с прослеживанием в обратном порядке. Для решения проблем этой группы можно воспользоваться готовыми решениями, т.е. ранее созданной оболочкой на базе экспертной системы, решавшей аналогичную проблему в другой предметной области. Распространено мнение, что такой подход позволяет получить удовлетворительное, а не оптимальное решение проблемы, т.е. достаточно хорошее, а не лучшее решение. Учтите, что попытка отыскать оптимальное решение неизбежно сопряжена с перебором нескольких вариантов, что таит в себе опасность "комбинаторного взрыва".
(2) Ненадежные данные или знания. Если данные и/или знания ненадежны, т.е. существует опасность, что вводимые в систему данные недостоверны, а правила в базе знаний неоднозначны, то в экспертной системе нужно комбинировать информацию от нескольких источников и использовать в какой-либо форме логику неточных рассуждений. Авторы цитируемой работы весьма мудро решили воздержаться от конкретных рекомендаций, какой именно формализм неточных рассуждений следует выбрать, но круг кандидатов в любом случае довольно ограничен — формализм коэффициентов уверенности (см. главу 3) или нечеткой логики (см. главу 9). Обсуждение альтернативных методов, таких как использование функций доверия (belief function) и обновляемых оценок по Байесу (Bayesian belief updating), мы отложим до главы 21.
(3) Большое, но факторизуемое пространство решений. В литературе можно найти два варианта толкования термина "факторизуемый". Пространство поиска можно назвать факторизуемым, если существует "правило исключения", которое помогает уменьшить размер пространства на ранней стадии решения проблемы [Stefik et al, 1983, p. 99]. Есть и другое определение — пространство поиска является факторизуемым, если возможно разделить его на несколько независимых подпространств, которые можно обрабатывать по отдельности, причем для разных подпространств могут быть использованы и разные множества правил или отдельные подмножества одного и того же множества правил [Nilsson, 1980, р. 37]. Обычно такое разбиение выполняется на уровне решаемой проблемы, т.е. большая общая проблема разбивается на несколько более мелких. Успех в достижении главной цели, таким образом, оценивается по совокупности успехов в достижении более или менее независимых подцелей. .Если система потерпит неудачу в достижении одной из подцелей, то это будет означать неудачу и решения проблемы в целом. В любом случае для решения проблем такого класса наиболее предпочтительным является метод порождения и проверки (generate-and-test). Этот метод позволяет "обрезать" ветви, уводящие нас от решения, и разделить большое пространство решений на подпространства.
(4) Большое нефакторизуемое пространство решений. Пространство решений может оказаться и нефакторизуемым, в каком бы смысле мы не трактовали этот термин. Очень часто оказывается, что проблема проектирования допускает выработку частного решения какого-либо компонента только в контексте всего проекта. При сборке головоломки нельзя предсказать, найдено ли верное решение, пока последний элемент мозаики не станет на свое место. Общий подход к работе в большом пространстве поиска состоит в том, чтобы последовательно рассматривать его на разных уровнях абстракции, т.е. использовать варианты описания пространства с разным уровнем учета деталей. Решение проблемы таким методом часто называют нисходящим уточнением (top-down refinement) (см. об этом в главе 14). Применение метода нисходящего уточнения требует исключить, по возможности, обратное прослеживание между уровнями, реализация которого требует значительных вычислительных ресурсов. Но это срабатывает только в случае, если между уровнями нет тесного взаимодействия. Как было показано в главе 15, эффективной стратегией решения такого рода задач является стратегия наименьшего принуждения (least commitment), подкрепленная адекватным механизмом разрешения конфликтов.
В книге [Hayes-Roth et al, 1983] проблема выбора инструментальных средств представлена в терминах схемы рис. 17.2. Выяснив характеристики проблемы, решаемой проектируемой экспертной системой, можно определиться со свойствами пространства решений, которые перечислены выше. Затем они рассматриваются совместно с предполагаемыми характеристиками разрабатываемой системы — характеристиками порождающих правил, прямой цепочки вывода или возможностями формирования пояснений, — и вырабатываются желаемые характеристики инструментальной среды. Последние и позволяют подобрать нужную модель инструментальной среды. Нужно сказать, что все это прекрасно выглядит на картинке, но очень сложно реализуется на практике, хотя вряд ли кто-нибудь будет спорить с тем, что такой подход более логичен, чем какой-либо другой. Как показывает практика, большинство разработчиков явно или неявно следует именно такому подходу при создании экспертных систем.
Рис. 17.2. Схема выбора инструментальной среды проектирования экспертной системы
Например, разработчики экспертной системы COMPASS, описанной в главе 10, следующим образом аргументировали свое решение выбрать для выполнения проекта инструментальную среду КЕЕ.
Эта среда предоставляет в распоряжение разработчика большее разнообразие парадигм программирования, чем какая-либо другая.
Среда оснащена лучшими средствами интерфейса и более развитыми средствами редактирования.
Поддержка этой среды со стороны фирмы-производителя организована лучше, чем у ее конкурентов.
Проанализировав возможные варианты, разработчики остановились на выборе в качестве основного инструментального средства компонента COTS среды КЕЕ.
При выборе инструментальной среды немаловажное значение имеет и то, насколько проста среда в обращении и как быстро проектировщики экспертной системы смогут овладеть методикой работы в этой среде, какую поддержку в этом готова оказать им фирма-изготовитель среды, и, конечно же, цена этого программного продукта
17.4.3. Практическое освоение инструментальных средств
В рекламном проспекте множества программных средств для проектирования экспертных систем можно встретить утверждение, что данным инструментом "может успешно пользоваться даже непрограммист" или программист, малознакомый с технологиями искусственного интеллекта. В этом разделе мы попытаемся критически рассмотреть, насколько справедливы подобные утверждения, основываясь на имеющихся обзорах и опубликованных сведениях об опыте работы с такого рода программами. Имеющиеся в нашем распоряжении данные свидетельствуют, что, как правило, овладение типовыми инструментальными средствами проектирования экспертных систем не легче, чем овладение новым языком программирования. Даже опытный программист на начальном этапе освоения такой программы допускает ошибки, свойственные только студентам-новичкам, приступившим к изучению обычного программирования.
В работе [Ward and Sleeman, 1987] представлены результаты мониторинга процесса изучения опытными программистами методики работы с оболочкой для проектирования экспертных систем S.1 [Teknowledge, 1985]. Прародителем S.1 является известная система EMYCIN, а дальнейшим развитием — система М.4. Базы знаний в S.1 содержат множество объектов разного назначения — управляющие выражения, классы, типы классов, порождающие правила, иерархии значений и функций. Таким образом, выбранная для S.1 архитектура, с одной стороны, позволила расширить возможности, которыми обладала система EMYCIN, а с другой — весьма усложнила саму систему. Это замечание еще более справедливо в отношении системы М.4 (см. врезку 17.3).
Среда S.1 поддерживает четыре режима работы:
подготовка и редактирование базы знаний;
использование базы знаний для выполнения консультации, т.е. прогон программы;
выявление и устранение ошибок на стадии компиляции;
выявление и устранение ошибок на стадии выполнения.
Как показал опрос, программисты с трудом осваивают методику совместного использования этих режимов в процессе проектирования экспертной системы, хотя все они имеют большой опыт работы и владеют такими распространенными навыками, как работа с файлами, компилирование файлов, выполнение программ, поиск и устранение ошибок. Те сообщения об ошибках, которые формируются инструментальной средой, несут информации не больше, чем стандартные сообщения об ошибках в большинстве компиляторов обычных языков программирования. По этим сообщениям трудно отличить место возникновения ошибки от места в программном коде, в котором эта ошибка проявилась. Учитывая, что разработка базы данных ведется в режиме постепенного наращивания ее объема (а такая стратегия рекомендуется всеми авторитетными специалистами), переключение с режима на режим в среде разработки должно выполняться как можно проще, поскольку инженеру по знаниям приходится выполнять итеративные процедуры пополнения базы знаний значительно чаще, чем обычному программисту выполнять расширение функций программы.
Анализ опыта освоения этой инструментальной среды также показал, что если программисты отдают предпочтение простейшей стратегии отладки (эта стратегия включает этапы ввода данных, обращения к системе с запросом о значении какого-либо параметра на основе анализа небольшого множества правил и вывода результата), то они сталкиваются с рядом проблем, касающихся методов представления информации и управления поиском. По мере увеличения сложности проектируемой системы — увеличение объема базы знаний, включение в рассмотрение неопределенностей разного рода, включение в алгоритм работы системы дополнительных режимов — стратегия проектирования требует все более тщательной предварительной подготовки. Авторы обзора [Ward and Sleeman, 1987] пришли к выводу, что хотя освоение системы S.1 и не сложнее освоения нового языка программирования уровня PASCAL, но утверждать, что эта система проще, тоже нельзя.
Утверждение, что эту систему могут освоить люди, не имеющие навыков программирования, "не нашло подтверждения на практике", а если уж говорить совсем откровенно, то это не более чем рекламный трюк. Мой собственный опыт наблюдения за аспирантами, которые пользовались такого рода инструментальными системами, полностью согласуется с этими выводами.
В своих аналитических заметках Робинсон [Robinson, 1987] обращает внимание на то, что выбор инструментальной среды разработки экспертной системы представляет собой достаточно сложную задачу по следующим причинам:
большинство развитых сред разработки настолько дороги, что покупать их для проведения сравнительного анализа перед выбором подходящего не по средствам разработчикам;
время, необходимое для освоения навыков работы с системой и выявления ее сильных и слабых сторон, также слишком велико, а потому редко кто может себе позволить проводить сравнение конкурирующих моделей на практике;
терминология, которую применяют в документации изготовители разных систем, существенно отличается, причем это относится даже к понятиям и технологиям, ставшим стандартными в области искусственного интеллекта. Поэтому проводить сопоставление разных моделей по тем сведениям, которые публикуются в технической документации, также достаточно трудно.
Последнее замечание справедливо в отношении большинства программных продуктов, предлагающихся на рынке. Когда же речь идет о программных средствах, связанных с областью искусственного интеллекта, то новизна и необычность терминологии еще более усугубляет проблему. Уже давно в среде специалистов бытует мнение, что сравнение конкурирующих систем одного класса можно выполнять только после тщательного изучения их на практике.
17.3. Правила и процедуры в инструментальной среде М.4
Основным средством представления знаний в оболочке М.4 являются порождающие правила, ориентированные на построение обратной цепочки логического вывода, причем применяется тот же синтаксис, что и в системе EMYCIN (см. главу 1.1), Приведенное ниже правило выбирает болт определенного размера, принимая во внимание ограничения на длину, диаметр и шаг резьбы. Прописными буквами в тексте правила выделены наименования переменных.
If recommended type = bolt and
recommended length = LENGTH and
recommended diameter = DIAMETER and
recommended thread_pitch = PITCH and
fastener(bolt, LENGTH, DIAMETER, PITCH) = BOLT
then recommended fastener = BOLT
Построение прямой цепочки логического вывода моделируется конструкциями whenfound и whencached, которые выполняют функции демонов (см. главу 6). Например, оператор whencached разрешает выполнение определенного действия при установке значения определенного элемента данных. Выполнение такого действия, как правило, включает вызов процедуры, причем на его характер накладывается меньше ограничений, чем на характер действия, специфицированного в правой части порождающего правила в CLIPS. Например, в приведенном ниже фрагменте утверждается, что обнаружен самолет в определенной точке LOC в момент времени TIME, как только при считывании показаний сенсора в момент времени TIME обнаруживается наличие реактивного двигателя или пропеллера, и эти показания согласуются с аналогичными показаниями соседнего сенсора в предыдущий момент времени.
whencached (sensor_reading
( SENSOR, TIME) = SIGNATURE) =
((signature-type (SIGNATURE) = jet or
signature-type (SIGNATURE) = prop)
and TIME -1 = PREVIOUS and cached
( sensor jreading) OTHER, PREVIOUS = SIGNATURE)
and
neighbor (SENSOR) = OTHER and location
(SENSOR) = LOC and do ( set plane_detected ( LOC , TIME ) ) ) .
Насколько этот фрагмент программы читабелен, судить вам.
Процедуры в М.4 имеют синтаксис, весьма напоминающий синтаксис языка программирования С или PASCAL. Например, ниже приведен текст простой процедуры.
В этом фрагменте конструкция LIST == [ITEM (REST] заимствована из языка PROLOG. Она разделяет список LIST на головной элемент ITEM и хвост REST. Читатель может судить по этому фрагменту, насколько просто в среде М.4 программировать процедуры
17.4.4. Стиль программирования
В литературе о программировании задач общего назначения часто обсуждается понятие "стиль программирования". Существует огромное множество книг о том, как писать программы, и кажется, что в них можно найти рекомендации на все случаи жизни.
Но эти рекомендации слабо соотносятся со спецификой программирования задач искусственного интеллекта и, в частности, систем, основанных на знаниях. Тот массив программ на языке LISP, который накопился за многолетнюю практику применения этого языка в программировании задач искусственного интеллекта, повергнет в ужас любого студента, проштудировавшего классические труды по структурному программированию. В программах зачастую используются нестандартные способы управления последовательностью выполнения операторов, непредусмотренное никакими канонами динамическое связывание переменных и совершенно "безответственные" манипуляции со структурами данных, такими как списки свойств. Но в последние годы ситуация здесь значительно улучшилась (с точки зрения приверженцев строго структурированного стиля оформления текста программы). Чтобы убедиться в этом, сравните, например, обзоры [Winston and Horn, 1983] и [Winston and Horn, 1981]. Как бы там ни было, но написать хорошую программу на языке LISP — это искусство, которым владеют единицы, хотя тексты большинства самых лучших программ искусственного интеллекта можно демонстрировать студентам в качестве наглядного пособия, как не надо писать программы.
Но, к сожалению, более чем 25-летний опыт совершенствования стиля программирования на LISP не востребуется разработчиками новых языков и инструментальных сред. Для меня, например, остается загадкой, что же представляет собой хороший стиль программирования по отношению к языку (и среде) КЕЕ. Мне приходилось наблюдать, как инженеры по знаниям, много лет проработавшие с языками структурного программирования, буквально падали в обморок от мешанины подключения процедур, комбинированных методов и активных значений в КЕЕ-программах. Это не следует рассматривать как серьезную критику в адрес функциональных возможностей языка, а скорее как констатацию того факта, что любые сложные инструментальные средства нуждаются в адекватной методологии пользования ими. Единственным исключением, на мой взгляд, является язык OPS5, о методике использования которого написана прекрасная книга [Brownston et al, 1985].
