Имя материала: Базы знаний интеллектуальных систем

Мы рассмотрели языки общего назначения для задач ИИ. Вместе с тем в рамках развития средств автоматизации программных систем, ориентированных на знания, были языки, сыгравшие важную роль в эволюции основных языков ИИ. В первую очередь среди них необходимо выделить языки, ориентированные на программирование поисковых задач. Это ПЛЭНЕР и различные его модификации [Пильщиков, 1983], КОННАЙВЕР [Sussman et al., 1976], а также языки, выросшие из потребностей известной планирующей системы QA4 [Sacerdoti et al., 1976]. Все эти языки функционируют в ЛИСП-среде и создавались как расширения базового языка. Для них, кроме свойств ЛИСПа, характерны следующие черты: представление данных в виде произвольных списковых структур; развитые методы сопоставления образцов; поиск с возвратами и вызов процедур по образцу. Заметим, что в конечном счете ни один из них не стал универсальным языком программирования ИИ. Однако выработанные здесь решения были использованы и в ЛИСПе, и в ПРОЛОГе, и в современных продукционных языках. Важно и то, что языки этой группы способствовали переосмыслению самого понятия программы. В области ИИ это послужило толчком к развитию объектно-ориентированного программирования и разработке языков представления знаний первого поколения.

В 70-х годах в программировании вообще и программировании задач ИИ, в частности, центр тяжести стал смещаться от процедурных к декларативным описаниям. К этому же времени в ИИ сформировались и концепции представления знаний на основе семантических сетей и фреймов. Естественно, что появились и специальные языки программирования, ориентированные на поддержку этих концепций. Но из десятков, а может и сотен языков представления знаний (ЯПЗ) первого поколения лишь несколько .. сыграли заметную роль в программной поддержке систем представления знаний. Среди таких ЯПЗ явно выделяются KRL, FRL, KL-ONE и некоторые другие [Хорошевский, 1990]. Характерными чертами этих ЯПЗ были: двухуровневое представление данных (абстрактная модель предметной области в виде иерархии множеств понятий и конкретная модель ситуации как совокупность взаимосвязанных экземпляров этих понятий); представление связей между понятиями и закономерностей предметной области в виде присоединенных процедур; семантический подход к сопоставлению образцов и поиску по образцу.

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

В силу ограниченного объема книги мы не сможем здесь рассмотреть даже наиболее распространенные языки и системы представления знаний. Поэтому ниже приведены лишь некоторые замечания относительно одного из самых распространенных ЯПЗ — OPS5 (Official Production System, version 5) [Brownston et al., 1985], который претендовал в начале 80-х годов на роль языка-стандарта в области представления знаний для ЭС.

OPS5 — один из многочисленных на сегодняшний день ЯПЗ для ЭС, поддерживающих продукционный подход к представлению знаний. OPSS-программа, в общем случае, содержит секцию деклараций, где описываются используемые объекты и определяются введенные пользователем функции, и секцию продукций, основу которой составляют правила. ОР85-объекты описываются с помощью фреймов-экземпляров, прототипы которых задаются в виде определенных структур данных, опирающихся на небольшое число встроенных типов. Во время исполнения программы обрабатываемые данные помещаются в рабочую намять, а правила — в память продукций. Модуль вывода решений в OPSS-системе состоит из трех основных блоков: отождествления, где осуществляется поиск подходящих правил; выбора исполняемого правила из конфликтного множества правил и собственно исполнителя выбранного правила. Непосредственно в OPS5 поддерживается единственная стратегия вывода решений — вывод, управляемый целями. Вместе с тем OPS5 — достаточно гибкий язык, в котором имеются явные средства не только для описания данных, но и средства определения управления над этими данными.

Анализ формализмов представления знаний и методов вывода решений позволяет сформулировать следующие требования к ЯПЗ:

• наличие простых и вместе с тем достаточно мощных средств представления сложно структурированных и взаимосвязанных объектов;

• возможность отображения описаний объектов на разные виды памяти ЭВМ;

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

• «прозрачность» системных механизмов для программиста, предполагающая возможность их доопределения и переопределения на уровне входного языка;

• возможность эффективной реализации.

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

 

6.4. Инструментальные пакеты для ИИ

 

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

Анализ существующих инструментальных систем показывает, что сначала в области ИИ более активно велись работы по созданию интеллектуальных систем автоматизированного синтеза исполнительных программ. И это естественно, если иметь в виду, что инструментарий ИИ является, по существу, эволюционным развитием систем автоматизации программирования. При этом основная доля мощности и интеллектуальности такого инструментария связывалась не с его архитектурой, а с функциональными возможностями отдельных компонентов той или иной технологической среды. Большое значение при разработке инструментария для ИИ уделялось и удобству сопряжения отдельных компонентов. Пожалуй, именно здесь были получены впечатляющие результаты и именно здесь наиболее широко использовались последние достижения теории и практики программирования, такие, например,чкак синтаксически-ориентированное редактирование и инкрементная компиляция. Вместе с тем подавляющее большинство современных инструментальных систем «не знают», что проектирует и реализует с их помощью пользователь. И с этой точки зрения можно сказать, что все такие системы являются не более чем «сундучками» с инструментами, успех использования которых определяется искусством работающего с ними мастера. Примерами подобных сред служит подавляющее большинство инструментальных пакетов и систем-оболочек для создания экспертных систем типа EXSYS [EXSYS, 1985], GURU [MDBS, 1986] и др. [Harmon, 1987]. Однако не они определяют на сегодняшний день уровень достижений в этой области. К первому эшелону большинство специалистов относит системы ART [ART, 1984], KEE [Florentin, 1987] и Knowledge Craft [CARNEGIE, 1987]. Заметим, что в последнее время в класс самых мощных и развитых систем вошла и среда G2 [CATALYST, 1993]. Все эти системы, во-первых, отличает то, что это, безусловно, интегрированные среды поддержки разработки интеллектуальных (в первую очередь, экспертных) систем. И вместе с тем для этих систем характерно не эклектичное объединение различных полезных блоков, но тщательно сбалансированный их отбор, что позволило сделать первые шаги от автоматизации программирования систем ИИ к технологическим системам поддержки проектирования сначала экспертных, а затем и других интеллектуальных систем. Остановимся чуть подробнее на двух системах из «большой тройки» — ART и КЕЕ, а в заключение кратко охарактеризуем систему G2. Сравнение основывается, главным образом, на работах [Wall et al., 1986; Richer, 1986; Gillmore et al., 1985] и на информации, полученной от дилеров этих систем. В середине 80-х годов система ART была одной из самых современных интегрированных сред (ИС), поддерживающих технологию проектирования систем, основанных на правилах. В ней существует ясное и богатое разнообразие типов правил. Различные типы правил элегантно вводятся с помощью мощного механизма «точек зрения» (Viewpoint). Этот механизм фактически является очень близким к системе, основанной на истинности предположений (truth maintanance system) [de Kleer, 1989], которая, по-видимому, является развитием идей KEEWorlds+ в системе КЕЕ. По существу, ART является пакетом разработчика. При этом возможные ограничения в использовании ART вызваны не свойствами самой системы, а философией базового метода представления знаний.

Страница: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 |