Представление знаний в информационных системах

Глава 2. Инструментальные средства разработки 

2.1. Общая  характеристика инструментальных  средств для построения экспертных  систем

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

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

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

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

     1. Оболочки экспертных систем (expert system shells). Системы этого типа создаются,  как правило, на основе какой-нибудь  экспертной системы, достаточно  хорошо зарекомендовавшей себя  на практике. При создании оболочки  из системы-прототипа удаляются  компоненты, слишком специфичные  для области ее непосредственного  применения, и оставляются те, которые  не имеют узкой специализации.  Примером может служить система  EMYCIN, созданная на основе прошедшей  длительную "обкатку" системы  MYCIN. В EMYCIN сохранен интерпретатор  и все базовые структуры данных  — таблицы знаний и связанный  с ними механизм индексации. Оболочка  дополнена специальным языком, улучшающим  читабельность программ, и средствами  поддержки библиотеки типовых  случаев и заключений, выполненных  по ним экспертной системой. Дальнейшим  развитием оболочки EMYCIN явились  системы S.1 и М.4, в которых механизм  построения цепочки обратных  рассуждений, заимствованный в  EMYCIN, объединен с фреймоподобной структурой данных и дополнительными средствами управления ходом рассуждений.

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

     3. Среда программирования, поддерживающая  несколько парадигм (multiple-paradigm programming environment). Средства этой категории  включают несколько программных  модулей, что позволяет пользователю  комбинировать в процессе разработки  экспертной системы разные стили  программирования. Среди первых  проектов такого рода была  исследовательская программа LOOP, которая допускала использование  двух типов представления знаний: базирующегося на системе правил  и объектно-ориентированного. На  основе этой архитектуры во  второй половине 1980-х годов было  разработано несколько коммерческих  программных продуктов, из которых  наибольшую известность получили KEE, KnowledgeCraft и ART. Эти программы  предоставляют в распоряжение  квалифицированного пользователя  множество опций и для последующих  разработок, таких как КАРРА и  CLIPS, и стали своего рода стандартом. Однако освоить эти языки программистам  далеко не так просто, как языки,  отнесенные нами к предыдущей  категории.

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

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

     Класс программ, которые мы называем оболочкой  экспертной системы, создавался с целью  позволить непрограммистам воспользоваться  результатами работы программистов, решавших аналогичные проблемы. Так, программа  EMYCIN [van Melle, 1981] позволяет использовать архитектуру системы MYCIN в приложении к другим областям медицины (напомним, что программа MYCIN была ориентирована только на заболевания крови). На базе EMYCIN были разработаны экспертные системы как для медицины (например, система PUFF для диагностики легочных заболеваний), так и для других областей знаний, например программа структурного анализа SACON.

     Совершенно  очевидно, что оболочки являются программами, ориентированными на достаточно узкий  класс задач, хотя и более широкий, чем та программа, на основе которой  была создана та или иная оболочка. Автор системы EMYCIN Ван Мелле (van Melle) одним из первых подчеркнул, что  оболочки отнюдь не являются универсальной  архитектурой для решения проблем. Разработанная им система EMYCIN ориентирована  на те проблемы диагностирования с  большими объемами данных, которые  поддаются решению с помощью  дедуктивного подхода в предположении, что пространство диагностических  категорий стационарно. Кленси (Clancey) назвал класс подобных проблем "проблемами эвристической классификации". Однако этот подход значительно меньше подходит для решения проблем конструирования, т.е. объединения отдельных элементов  в единый комплекс с учетом заданных ограничений.

     К сожалению, нельзя слишком доверять рекомендациям о возможности  использования оболочки для решения  конкретных проблем. Дело в том, что  мы еще не имеем настолько четкого  представления о классификации  задач, решаемых экспертными системами, чтобы можно было точно представить, к какому именно классу следует отнести  конкретную систему. Классификации  задач, пригодных для решения  экспертными системами, посвящено  довольно много работ, из которых  следует отметить сборник [Hayes-Roth et al, 1983] и статью [Chandrasekaran, 1984]. Может создаться  впечатление, что отличить задачу классификации  от задачи конструирования можно  и "невооруженным глазом", но это  впечатление обманчиво. Множество  проблем допускает решение разными  способами. Например, в том подходе  к задаче диагностирования, который  использован в системе INTRN1ST, применяются  методы, свойственные решению задач  конструирования. Сложные проблемы зачастую требуют применения комбинированных  методов, в которых просматриваются  черты, свойственные обоим подходам.

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

     Простота  языков представления знаний, применяемых  в большинстве оболочек, является, с одной стороны, достоинством, а  с другой — недостатком такого рода систем. На это обратила внимание Эйкинс в критическом замечании  по поводу реализации экспертной системы PUFF на базе оболочки EMYCIN [Aikins, 1983].

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

     Основным  методом формирования суждений в EMYCIN является построение обратной цепочки  вывода. При этом используется множество  правил мета- и объектного уровня. В  результате очень сложно формировать  исчерпывающее и понятное для  пользователя пояснение. Как отмечал  Кленси ([Clancey, 1983])те решения, которые  принимаются на этапе программирования правил, в частности касающиеся порядка  и количества выражений в антецедентной  части, могут разительным образом  повлиять на путь поиска в пространстве решений в процессе функционирования системы.

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

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

     По  сравнению с первыми разработками современные оболочки более гибкие, по крайней мере, в том, что без  особого труда могут быть интегрированы  в большинство операционных сред, доступных на рынке программного обеспечения, и оснащены достаточно развитыми средствами пользовательского  интерфейса. Так, оболочка МЛ может  функционировать под управлением  любой из операционных систем, используемых в персональных компьютерах, подключаться к базам данных, иметь средства для включения фрагментов программного кода на языках С, Visual BASIC и Visual C++. Оболочка поддерживает индивидуальную настройку  пользовательского интерфейса и  возможность формирования пояснений  при ответах на вопрос "почему" в том же стиле, что и система-прародитель MYCIN. 

2.3. Языки  программирования высокого уровня 

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

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