Инструментальные средства разработки экспертных систем

(4) Большое нефакторизуемое пространство решений. Пространство решений может оказаться и нефакторизуемым, в каком бы смысле мы не трактовали этот термин. Очень часто оказывается, что проблема проектирования допускает выработку частного решения какого-либо компонента только в контексте всего проекта. При сборке головоломки нельзя предсказать, найдено ли верное решение, пока последний элемент мозаики не станет на свое место. Общий подход к работе в большом пространстве поиска состоит в том, чтобы последовательно рассматривать его на разных уровнях абстракции, т.е. использовать варианты описания пространства с разным уровнем учета деталей. Решение проблемы таким методом часто называют нисходящим уточнением (top-down refinement) (см. об этом в главе 14). Применение метода нисходящего уточнения требует исключить, по возможности, обратное прослеживание между уровнями, реализация которого требует значительных вычислительных ресурсов. Но это срабатывает только в случае, если между уровнями нет тесного взаимодействия. Как было показано в главе 15, эффективной стратегией решения такого рода задач является стратегия наименьшего принуждения (least commitment), подкрепленная адекватным механизмом разрешения конфликтов.

В книге [Hayes-Roth et al, 1983] проблема выбора инструментальных средств представлена в терминах схемы рис. 17.2. Выяснив характеристики проблемы, решаемой проектируемой экспертной системой, можно определиться со свойствами пространства решений, которые перечислены выше. Затем они рассматриваются совместно с предполагаемыми характеристиками разрабатываемой системы -- характеристиками порождающих правил, прямой цепочки вывода или возможностями формирования пояснений, -- и вырабатываются желаемые характеристики инструментальной среды. Последние и позволяют подобрать нужную модель инструментальной среды. Нужно сказать, что все это прекрасно выглядит на картинке, но очень сложно реализуется на практике, хотя вряд ли кто-нибудь будет спорить с тем, что такой подход более логичен, чем какой-либо другой. Как показывает практика, большинство разработчиков явно или неявно следует именно такому подходу при создании экспертных систем.

Схема выбора инструментальной среды проектирования экспертной системы

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

· Эта среда предоставляет в распоряжение разработчика большее разнообразие парадигм программирования, чем какая-либо другая.

· Среда оснащена лучшими средствами интерфейса и более развитыми средствами редактирования.

· Поддержка этой среды со стороны фирмы-производителя организована лучше, чем у ее конкурентов.

Проанализировав возможные варианты, разработчики остановились на выборе в качестве основного инструментального средства компонента COTS среды КЕЕ.

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

Практическое освоение инструментальных средств

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

В работе [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] обращает внимание на то, что выбор инструментальной среды разработки экспертной системы представляет собой достаточно сложную задачу по следующим причинам:

· большинство развитых сред разработки настолько дороги, что покупать их для проведения сравнительного анализа перед выбором подходящего не по средствам разработчикам;

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

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

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

Правила и процедуры в инструментальной среде М.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. Например, ниже приведен текст простой процедуры.

procedure ( determine_and_display recs ( FAULT ) ) =

{

f ind_recomendations( FAULT) ;

LIST := listof( recommendations (FAULT) };

COUNT := 1;

while (LIST == [ITEM | REST])

{

display ([COUNT, ". ", ITEM, nl]);

COUNT := COUNT + 1; LIST := REST;

)

В этом фрагменте конструкция LIST == [ITEM (REST] заимствована из языка PROLOG. Она разделяет список LIST на головной элемент ITEM и хвост REST. Читатель может судить по этому фрагменту, насколько просто в среде М.4 программировать процедуры.

Стиль программирования

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

Но эти рекомендации слабо соотносятся со спецификой программирования задач искусственного интеллекта и, в частности, систем, основанных на знаниях. Тот массив программ на языке LISP, который накопился за многолетнюю практику применения этого языка в программировании задач искусственного интеллекта, повергнет в ужас любого студента, проштудировавшего классические труды по структурному программированию. В программах зачастую используются нестандартные способы управления последовательностью выполнения операторов, непредусмотренное никакими канонами динамическое связывание переменных и совершенно "безответственные" манипуляции со структурами данных, такими как списки свойств. Но в последние годы ситуация здесь значительно улучшилась (с точки зрения приверженцев строго структурированного стиля оформления текста программы). Чтобы убедиться в этом, сравните, например, обзоры [Winston and Horn, 1983] и [Winston and Horn, 1981]. Как бы там ни было, но написать хорошую программу на языке LISP -- это искусство, которым владеют единицы, хотя тексты большинства самых лучших программ искусственного интеллекта можно демонстрировать студентам в качестве наглядного пособия, как не надо писать программы.

Но, к сожалению, более чем 25-летний опыт совершенствования стиля программирования на LISP не востребуется разработчиками новых языков и инструментальных сред. Для меня, например, остается загадкой, что же представляет собой хороший стиль программирования по отношению к языку (и среде) КЕЕ. Мне приходилось наблюдать, как инженеры по знаниям, много лет проработавшие с языками структурного программирования, буквально падали в обморок от мешанины подключения процедур, комбинированных методов и активных значений в КЕЕ-программах. Это не следует рассматривать как серьезную критику в адрес функциональных возможностей языка, а скорее как констатацию того факта, что любые сложные инструментальные средства нуждаются в адекватной методологии пользования ими. Единственным исключением, на мой взгляд, является язык OPS5, о методике использования которого написана прекрасная книга [Brownston et al, 1985].

Некоторые максимы разработки экспертных систем

Чтобы не заканчивать эту главу на такой печальной ноте, я решил включить в последний раздел избранные максимы о построении экспертных систем, почерпнутые из классической работы Бучанана [Buchanan et al., 1983]. Следование им избавит проектировщика экспертных систем от опасности "наступить на грабли", многократно "опробованной" его коллегами. Другим прекрасным источником умных мыслей по тому же поводу может служить книга Преро [Ргегаи, 1990].

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

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

· Задача должна быть четко сформулирована.

· Уже на первой стадии работы над системой подумайте над тем, как она будет совершенствоваться.

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

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

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

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

В отношении формулировки правил авторы упомянутых работ советуют следующее.

· Если правило выглядит большим, то так оно и есть.

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

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

У Преро вы встретите и рекомендации, касающиеся этапа реализации экспертной системы. Ниже приведены некоторые из них.

· Группируйте правила в отдельные множества.

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

· Постарайтесь на самых ранних стадиях разработать систему соглашений об оформлении программы. Это придаст ей единообразный вид.

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

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

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

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

· Как только встанет вопрос о разработке второго прототипа, выбросите первый в мусорную корзину.

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

· Процесс проектирования экспертной системы неразрывно связан с экспериментированием.