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

2.3.1. Языки  описания порождающих правил 

     Но, естественно, возможности языков высокого уровня также не беспредельны —  каждый из них имеет свои ограничения. Например, в языке OPS5 возможности  динамической памяти ограничены размещением  векторов в рабочей памяти, что  не позволяет строить в ней  рекурсивные структуры данных, такие  как графы или деревья. При  разработке системы MORE из-за этого возникли серьезные сложности [Kahn, 1988]. Некоторые  типы структур управления ходом выполнения, например рекурсивные и итерационные циклы, также с трудом реализуются  в этом языке. В общем, это та цена, которую приходится платить за относительную  простоту программного кода на языке OPS5 и эффективность его выполнения.

     В ранних моделях систем, основанных на порождающих правилах, до 90% времени  работы уходило на выполнение операций сопоставления условий. Но позднее  Форджи обратил внимание на возможные  источники низкой эффективности  такого упрощенного подхода [Forgy, 1982]. Алгоритм сопоставления RETE, предложенный Форджи и реализованный в языках описания порождающих правил семейства OPS, базируется на двух наблюдениях.

     В левых частях порождающих правил, которые размещаются в рабочей  памяти, часто встречаются повторяющиеся  условия. Если одно и то же условие  встречалось в N правилах, то при  прежнем упрощенном подходе выполнялось N операций сопоставления. Это пример внутрицикловой итерации (within-cycle iteration).

     Простейший  подход при сопоставлении условий  предполагает просмотр в каждом цикле  всех элементов рабочей памяти, хотя содержимое рабочей памяти от цикла  к циклу изменяется очень мало. Форджи назвал это межцикловой итерацией (between-cycle iteration).

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

     Совершенно  очевидно, что попытка использовать рекурсивные структуры данных потребует  серьезного усложнения описанного процесса обработки правил. Точно так же и изменение режима управления приведет к тому, что механизм разрешения конфликтов вынужден будет анализировать  дополнительную информацию. Разработчики языков, подобных OPS, всегда вынуждены  искать компромисс между мощностью  выразительных средств языка  и эффективностью выполнения программного кода. До сих пор в среде исследователей предметом оживленных дискуссий  является вопрос о том, удалось ли разработчикам OPS5 найти такой компромисс. Разработанные позже языки КЕЕ, КАРРА и CLIPS унаследовали от OPS5 синтаксис  и механизм активизации правил. Все  эти языки используют различные  версии алгоритма RETE при формировании множества конфликтующих правил.

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

2.3.2. Объектно-ориентированные  языки 

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

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

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

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

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

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

2.3.3. Языки  логического программирования экспертных  систем 

     Критически  оценивая первый опыт применения инструментальных средств типа оболочек при проектировании экспертных систем, в частности опыт использования EMYCIN, многие исследователи  полагали, что более перспективным  является альтернативный подход, основанный на логическом программировании . Например, предполагалось, что порождающие  экспертные системы, аналогичные MYCIN, могут  быть довольно просто реализованы на языке PROLOG [Clark and McCabe, 1982]. Правила можно  представить в виде фраз Хорна, в  которых головной (позитивный) литерал  соответствует заключению, а прочие (негативные) литералы будут соответствовать  условиям.

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

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

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

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

     стратегию управления (поиск в глубину — depth-first search), основанную на правилах нисходящего  поиска (фразы, которые размещены  в базе данных ближе к "голове", обрабатываются первыми) и вычислении слева направо (подцели обрабатываются в том порядке, в котором они  перечислены в списке).

     Действительно, дедуктивную порождающую систему  довольно ПРОСТО эмулировать на языке PROLOG. Можно без особого труда  разработать и простой интерпретатор, реализующий стратегию построения прямой цепочки вывода. Модификация  рабочей памяти выполняется операторами assert и retract, которые добавляют или  удаляют формулы из базы данных.

     Успешный  опыт применения идей логического программирования, в частности создание программы  МЕСНО, продемонстрировал ряд явных  отклонений от синтаксиса исчисления предикатов первого порядка и  его процедурной интерпретации  в стандартной версии PROLOG. Некоторые  семантические и синтаксические ограничения в программах МЕСНО  и PLANNER до сих пор не преодолены в  системах, базирующихся на языках логического  программирования. 

2.3.4. Многофункциональные  программные среды 

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

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

     Одной из первых многофункциональных сред искусственного интеллекта является LOOPS [Bobrow and Steflk, 1983], в которой в рамках единой архитектуры обмена сообщениями  были объединены четыре парадигмы программирования, перечисленные ниже.