<< Предыдущая

стр. 14
(из 26 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

систем

В настоящее время в области разработки и реализации интеллектуальных систем сложилось следующее положение: с одной стороны, квалификация коллективов разработчиков здесь, как правило, достаточно высока, чтобы считать классические положения технологии разработки ПО, обсуждавшиеся выше, естественным компонентом работы. С другой стороны, жизненно важными технологические аспекты создания интеллектуальных систем становятся, лишь когда такие системы выходят на уровень промышленных разработок. Создание и внедрение интеллектуальных систем общения с промышленными базами данных, систем машинного перевода нового поколения, интеллектуальных систем автоматического синтеза программ и особенно экспертных систем, по существу, и выдвинуло проблему технологической поддержки разработок в области ИИ на передний план [SIG-SOFT, 1986].
На фоне вышеописанной ситуации обращает на себя внимание тот факт, что имеются только единичные примеры инструментальных систем, которые бы поддерживали некоторую четко провозглашенную технологию разработки ПО и опирались бы на достаточно развитые системы представления знаний [Ramanioorthy et al, 1987]. Учитывая это, в данном параграфе рассматриваются технологические аспекты и методологии создания интеллектуальных систем в свете введенных выше понятий технологии программирования, а в следующих — инструментарий для разработки систем ИИ.
Стиль программирования систем искусственного интеллекта существенно отличается от стиля программирования с использованием обычных алгоритмических языков. При этом почти каждая подобласть области ИИ характеризуется своим собственным стилем программирования, не всегда адекватным для других приложений. В табл. 6.1 приведены некоторые характерные отличия между обычными программными системами и системами ИИ [Ramamoorthy et al, 1987].
Таблица 6.1.
Отличия систем ИИ от обычных программных систем

Характеристика
программирование
Программирование в СИИ
Традиционное
Тип обработки
Символьная
Числовая
Методы
Эвристический приск
Алгоритм
Задание шагов решения
Неявное
Точное
Искомое решение
Удовлетворительное
Оптимальное
Управление и данные
Перемешаны
Разделены
Знания
Неточные
Точные
Модификации
Частые
Редкие

Но ввиду все возрастающего использования систем ИИ в конкретных приложениях, к ним начинают предъявляться практически те лее требования, что и к традиционным программным комплексам и системам. В связи с этим становится весьма актуальной поддержка жизненного цикла программ в ИИ. К основным этапам в этом случае относятся инженерия требований, тестирование на прототипах и сопровождение.
Как и в случае обычных программных систем, разработка системы ИИ должна начинаться с формулирования полных, непротиворечивых и однозначных требований к ней [Basil! et al., 1984]. При проектировании должны использоваться принципы технологии разработки ПО — такие, например, как сокрытие информации, локализация и модульность. Предполагается, что система должна проектироваться как композиция уровней. Любой уровень должен быть чувствителен лишь к нижележащим уровням. Такое проектирование упрощает не только реализацию, но и тестирование.
Тестирование ПО ИИ отличается от тестирования обычных систем, так как для первых характерно недетерминированное поведение вследствие использования стратегии разрешения конфликтов, зависящей от параметров периода исполнения программы. Поэтому единственным эффективным способом тестирования систем ИИ является прототипизация.
Фаза сопровождения, включающая выполнение самых различных модификаций системы, является важнейшим этапом процесса разработки любой системы, но имеет свою специфику для систем ИИ. Здесь база знаний — наиболее динамичный компонент и меняется в течение всего жизненного цикла. Поэтому сопровождение интеллектуальных систем — серьезная проблема. Но именно вопросам сопровождения уделяется мало внимания, хотя в обычном программировании имеются средства, которые могли бы быть адаптированы и для случая ПО ИИ. Это, например, системы управления версиями, системы управления конфигурацией и системы модифицирующих запросов.
Таким образом, создание ПО систем, основанных на знаниях, имеет как общие моменты с разработкой традиционных систем ПО, так и свою специфику, которая явным образом должна отражаться в соответствующих моделях жизненного цикла.
В недавнем прошлом полигоном для создания и испытания таких моделей являлись экспертные системы (ЭС).
В ходе работ по созданию ЭС практически сложилась определенная технология, включающая следующие основные этапы: идентификацию, концептуализацию, формализацию, реализацию и тестирование [Попов, 1987; Уотерман, 1989]. На этапе идентификации определяются задачи, подлежащие решению, выявляются цели разработки, ресурсы, наличие экпертов, готовых и способных передать свои знания проектируемой ЭС, категории и требования будущих пользователей. Концептуализация необходима для проведения содержательного анализа предметной области, в процессе которого выделяются используемые понятия и их взаимосвязи, определяются методы решения задач, и подробно обсуждалась в предыдущих главах.
На этапе формализации определяются способы представления всех типов знаний, специфицируются выделенные ранее понятия, фиксируются способы интерпретации знаний, моделируется работа системы, и оцениваются полученные результаты.
Этап реализации предполагает создание программной обстановки, в которой будет функционировать будущая система, и наполнение экспертом базы знаний, а на этапе тестирования эксперт и инженер по знаниям в интерактивном режиме, используя, в частности, объяснения, проверяют компетентность ЭС. В заключение на этапе тестирования проверяется пригодность ЭС для конечных пользователей.
Понятно, что процесс создания ЭС не сводится к строгой последовательности выполнения вышеперечисленных этапов. В ходе разработки происходят многочисленные возвраты к предыдущим этапам и решения, принятые там, пересматриваются. Все это существенно снижает общую эффективность разработки конкретной системы и позволяет сделать вывод о том, что модель жизненного цикла, соответствующая такой технологии, имеет мало шансов на промышленное использование.
Это, конечно, не означает, что ЭС, разработанные в рамках такой методологии, практически бесполезны или их проектирование вообще невозможно. Обычно таким образом создаются небольшие автономно функционирующие ЭС первого поколения.
Промышленная технология создания ЭС включает три фазы (или, если быть точнее, технологии): проектирование, реализацию и внедрение. Жизненный цикл разработки, охватываемый этой технологией или совокупностью технологий, состоит из 6 этапов: исследование выполнимости проекта;разработка общей концепции ЭС;разработка и тестирование серии прототипов;разработка и испытание головного образца; разработка и проверка расширенных версий системы; привязка системы к реальной рабочей среде.
На фазе проектирования проект инициализируется, формируется группа разработчиков, определяются требования к будущей ЭС, проводятся исследования выполнимости проекта и вырабатывается общая концепция будущей системы. Остальные фазы данной технологии, по мнению [Микулич, 1990], ближе к технологии Уотермана (Waterman) и направлены на реализацию разработанной концепции в виде серии прототипов, последовательно приближающихся к требуемой ЭС. Последний из прототипов и приобретает статус головного образца, который устанавливается будущим пользователем в реальную операционную среду.
Нетрудно понять, что первые два этапа промышленной технологии соответствуют этапу идентификации; следующие три — этапам концептуализации, формализации, реализации и тестирования. Новым и вместе с тем естественным для промышленной технологии является здесь этап привязки системы к реальной рабочей обстановке.
Недостатком и той и другой технологии является то, что в действительности это лишь более или менее структурированный набор методических рекомендаций, к отдельным элементам которого, в лучшем случае, привязаны те или иные инструментальные средства. И можно сказать, что сегодняшнее состояние здесь ближе к описательному, чем к естественно-научному. А это влечет за собой наличие интерпретаций методологических рекомендаций, которые могут быть настолько различными, что теряется сама идея технологии. Таким образом, самым важным на данном этапе является создание операциональных моделей технологии разработки интеллектуальных систем. И здесь, по нашему мнению, хорошим примером могут послужить модели экспертизы, уже разработанные в рамках исследований по приобретению знаний.
Приобретение знаний, как уже неоднократно отмечалось выше, является ключевой задачей во всех технологиях построения систем, основанных на знаниях (СОЗ). Существует распространенный принцип, согласно которому производительность СОЗ находится в прямой зависимости от количества знаний, содержащихся в системе [Feigenbaum, 1977]. Более 15 лет, с момента появления известной программы TIERESIAS [Davis, 1984], исследователи в области ИИ рассматривают приобретение знаний как задачу переноса знаний эксперта в БЗ системы, что чрезвычайно важно для создания действующей системы. Но в настоящее время работы в области приобретения знаний становятся важными и с точки зрения использования полученных здесь результатов для создания интеллектуальных технологий разработки самих СОЗ.
Первое поколение методик для СОЗ базировалось на подходах двух типов: поэтапном и прототипном.
Поэтапный подход связан с представлениями о жизненном цикле [Buchanan et al., 1983; Guida et al., 1989] и соответствующей поддержке его основных стадий.
В прототипном подходе первого поколения [Grover, 1983; Wielinga et al., 1988] процесс приобретения знаний может не отрабатывать все стадии, так как основным предположением здесь была возможность раскрытия структуры области экспертизы на раннем этапе проектирования на основе сравнительно небольшого анализа. Во втором поколении СОЗ-методик признана сложность процесса приобретения знаний, преодоление которой видится в моделировании экспертизы. В данной области были предложены такие методики, как онтологический анализ [Alexander et al, 1987], концептуальные графы Sowa [Clancey, 1985], подходы, основанные на обобщенных (родовых) задачах [Chandrasekaran, 1985], и концептуальное моделирование, например КADS-методология [Breuker et al., 1986]. Методики приобретения знаний обсуждаются в огромном числе работ и, в частности, в предыдущих главах настоящей книги. Не имея места для их сколько-нибудь полного анализа, сошлемся здесь лишь на обзоры [Wielinga et al., 1988; Молокова, 1992; Осипов, 1993] и перейдем к инструментальным средствам поддержки разработки интеллектуальных систем.

6.3. Языки программирования для ИИ и
языки представления знаний

Обсуждение технологических аспектов разработки сложных программных систем, проведенное выше, показывает, что наиболее проработанным этапом здесь является реализация программных проектов. По идеям и методам этот этап близок к автоматизации программирования — одной из основных проблем использования средств вычислительной техники. Здесь уже в течение многих лет применяется обширный арсенал языков программирования высокого уровня, ориентированных на удобную и эффективную реализацию различных классов задач, а также широкий спектр трансляторов, обеспечивающих получение качественных исполнительных программ. Все шире используются на современном этапе и методы автоматического синтеза программ. Уже стало обычным применение языко-во-ориентированных редакторов и специализированных баз данных. И можно сказать, что в рамках технологии программирования уже практически сформировалась концепция окружения разработки сложных программных продуктов, которая и определяет инструментальные средства, доступные разработчикам.
Необходимость использования средств автоматизации программирования прикладных систем, ориентированных на знания, и в частности ЭС, была осознана разработчиками этого класса программного обеспечения ЭВМ уже давно. По существу, средства поддержки разработки интеллектуальных систем в своем развитии прошли основные стадии, характерные для систем автоматизации программирования.
Оценивая данный процесс с сегодняшних позиций, можно указать в этой области две тенденции. Первая из них как бы повторяет «классический» путь развития средств автоматизации программирования: автокоды — языки высокого уровня — языки сверхвысокого уровня — языки спецификаций. Условно эту тенденцию можно назвать восходящей стратегией в области создания средств автоматизации разработки интеллектуальных систем. Вторая тенденция, нисходящая, связывается со специальными средствами, уже изначально ориентированными на определенные классы задач и методов ИИ. В конце концов, обе эти тенденции, взаимно обогатив друг друга, должны привести к созданию мощного и гибкого инструментария интеллектуального программирования. Но для настоящего этапа в этой области, по нашему мнению, характерна концентрация усилий в следующих направлениях:
1. Разработка систем представления знаний (СПЗ) путем прямого использования широко распространенных языков обработки символьной информации и, все чаще, языков программирования общего назначения.
2. Расширение базисных языков ИИ до систем представления знаний за счет специализированных библиотек и пакетов.
3. Создание языков представления знаний (ЯПЗ), специально ориентированных на поддержку определенных формализмов, и реализация соответствующих трансляторов с этих языков.
На начальном этапе развития ИИ языков и систем, ориентированных специально на создание прикладных систем, основанных на знаниях, не существовало. С одной стороны, в то время еще не оформился сам подход, в котором центральное место отводилось бы изложению теории в форме программ, а с другой — сама область ИИ только зарождалась как научное направление. Немаловажным было и то, что появившиеся к тому времени универсальные языки программирования высокого уровня казались адекватным инструментом для создания любых, в том числе и интеллектуальных, систем. Однако сложность и трудоемкость разработки здесь настолько велики, что практически полезные интеллектуальные системы становятся недоступными для реализации. Учитывая вышесказанное, были разработаны языки и системы обработки символьной информации, которые на несколько десятилетий стали основным инструментом программирования интеллектуальных систем.
До недавнего времени наиболее популярным базовым языком реализации систем ИИ вообще и ЭС, в частности, был ЛИСП [McCarthy, 1978]. Ниже кратко рассматривается эволюция ЛИСПа, а затем обсуждаются альтернативы этому языку, существовавшие и существующие в области реализации систем, ориентированных на знания. Результаты этого краткого обзора суммированы в виде схемы развития средств автоматизации программирования интеллектуальных систем на рис. 6.5. Подробнее эти вопросы обсуждаются в работе [Хорошевский, 1990а, Хорошевский, 1990b].


Рис. 6.5. Эволюция средств представления знаний

Как известно, язык ЛИСП был разработай в Стэнфорде под руководством Дж. Маккарти в начале 60-х годов и не предназначался вначале для программирования задач ИИ. Это был язык, который должен был стать следующим за ФОРТРАНОМ шагом на пути автоматизации программирования.
По первоначальным замыслам новый язык должен был иметь средства работы с матрицами, указателями и структурами из указателей и т. п. Предполагалось, что первые реализации будут интерпретирующими, но в дальнейшем будут созданы компиляторы. Как отмечает сам автор языка в обзоре [McCarthy, 1978], к счастью, для столь амбициозного проекта не хватило средств. К тому же к моменту создания первых ЛИСП-интерпретаторов в практику работы на ЭВМ стал входить диалоговый режим, и режим интерпретации естественно вписался в общую структуру диалоговой работы.
Примерно тогда же окончательно сформировались и принципы, положенные в основу языка ЛИСП: использование единого спискового представления для программ и данных; применение выражений для определения функций; скобочный синтаксис языка. Процесс разработки языка завершился созданием версии ЛИСП 1.5 [McCarthy, 1978], которая на многие годы определила пути его развития.
На протяжении всего существования языка было много попыток его усовершенствования за счет введения дополнительных базисных примитивов и/или управляющих структур. Однако, как правило, все эти изменения не прививались в качестве самостоятельных языков, так как их создатели оставались в «лисповской» парадигме, не предлагая нового взгляда на программирование.
После разработки в начале 70-х годов таких мощных ЛИСП-систем, как MacLrsp и Interlisp [Moon, 1973; Teitelman, 1974], попытки создания языков ИИ, отличных от ЛИСПа, но на той же парадигме, по-видимому, сходят на нет. И дальнейшее развитие языка идет, с одной стороны, по пути его стандартизации (таковы, например, Standart Lisp, Franz Lisp и Common Lisp), а с другой — в направлении создания концептуально новых языков для представления и манипулирования знаниями, погруженных в ЛИСП-среду [Barr et al., 1982].
К концу 80-х годов ЛИСП был реализован на всех классах ЭВМ, начиная с персональных компьютеров и кончая высокопроизводительными вычислительными системами. Новый толчок развитию ЛИСПа дало создание ЛИСП-машин, которые и в настоящее время выпускаются рядом фирм США, Японии и Западной Европы.
Из предыдущего может сложиться впечатление, что язык ЛИСП (а вернее его современные диалекты) — единственный язык ИИ. В действительности, конечно, это не так. Уже в середине 60-х годов, то есть на этапе становления ЛИСПа, разрабатывались языки, предлагающие другие концептуальные основы. Наиболее важными из них в области обработки символьной информации являются, по нашему мнению, СНОБОЛ [Griswold, 1978], разработанный в лабораториях Белла, и язык РЕФАЛ [Турчин, 1968], созданный в ИПМ АН СССР.
Первый из них (СНОБОЛ) — язык обработки строк, в рамках которого впервые появилась и была реализована в достаточно полной мере концепция поиска по образцу. С позиций сегодняшнего дня можно сказать, что язык СНОБОЛ был одной из первых практических реализаций развитой продукционной системы. Наиболее известная и интересная версия этого языка — СНОБОЛ-IV [Грисуолд и др., 1980]. Здесь, на наш взгляд, техника задания образцов и работа с ними существенно опередили потребности практики. Может быть именно это, а также политика активного внедрения ЛИСПа помешали широкому использованию языка СНОБОЛ в области ИИ.
В основу языка РЕФАЛ положено понятие рекурсивной функции, определенной на множестве произвольных символьных выражений. Базовой структурой данных этого языка являются списки, но не односвязные, как в ЛИСПе, а двунаправленные. Обработка символов ближе, как мы бы сказали сегодня, к продукционному формализму. При этом активно используется концепция поиска по образцу, характерная для СНОБОЛа. Таким образом, РЕФАЛ вобрал в себя лучшие черты наиболее интересных языков обработки символьной информации 60-х годов. В настоящее время можно говорить о языке РЕФАЛ второго [Климов и др., 1987] и даже третьего поколения. Реализован РЕФАЛ на всех основных типах ЭВМ и активно используется для автоматизации построения трансляторов, для построения систем аналитических преобразований, а также, подобно ЛИСПу, в качестве инструментальной среды для реализации языков представления знаний [Хорошевский, 1983].
В начале 70-х годов появился еще один новый язык, способный составить конкуренцию ЛИСПу при реализации систем, ориентированных на знания, — язык ПРОЛОГ [Clocksin et al, 1982]. Он не дает новых сверхмощных средств программирования по сравнению с ЛИСПом, но поддерживает другую модель организации вычислений. Подобно тому, как ЛИСП скрыл от программиста устройство памяти ЭВМ, ПРОЛОГ позволил ему не заботиться (без необходимости) о потоке управления в программе. ПРОЛОГ предлагает такую парадигму мышления, в рамках которой описание решаемой задачи представляется в виде слабо структурированной совокупности отношений. Это удобно, если число отношений не слишком велико и каждое отношение описывается небольшим числом альтернатив. В противном случае ПРОЛОГ-программа становится весьма сложной для понимания и модификации. Возникают и проблемы эффективности реализации языка, так как в общем случае механизмы вывода, встроенные в ПРОЛОГ, обеспечивают поиск решения на основе перебора возможных альтернатив и декларативного возврата из тупиков. ПРОЛОГ разработан в Марсельском университете в 1971 г. [Colmerauer, 1983]. Однако популярность он стал приобретать лишь в начале 80-х годов, когда благодаря усилиям математиков был обоснован логический базис этого языка, а также в силу того, что в японском проекте вычислительных систем V поколения ПРОЛОГ был выбран в качестве базового для машины вывода. В настоящее время ПРОЛОГ завоевал признание и на американском континенте, хотя уступает в популярности ЛИСПу и даже специальным продукционным языкам, широко используемым при создании ЭС.
Мы рассмотрели языки общего назначения для задач ИИ. Вместе с тем в рамках развития средств автоматизации программных систем, ориентированных на знания, были языки, сыгравшие важную роль в эволюции основных языков ИИ. В первую очередь среди них необходимо выделить языки, ориентированные на программирование поисковых задач. Это ПЛЭНЕР и различные его модификации [Пильщиков, 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 вызваны не свойствами самой системы, а философией базового метода представления знаний.
ART объединяет два главных формализма представления знаний: правила для процедурных и фреймоподобные структуры для декларативных знаний. Главным является формализм продукционных правил. Декларативные знания описываются через факты и схемы [schemata] и в некоторых случаях через образцы [patterns]. Кроме факторов числовой неопределенности, которые связываются с индивидуальными фактами, в ART различаются факты, которые явно принимаются за ложные, и факты, истинность которых неизвестна. Возможно использование логических зависимостей, которые позволяют изменить факты позже, если обнаружится, что они на самом деле оказались ложными. Механизм Viewpoint допускает образование нескольких конкурирующих миров, где пробуются альтернативные решения.
Схема предусматривается в ART в качестве макроформы для выражения таксономических знаний в структурированном виде, но ни метод, ни активные значения или выход в базовый язык в этом декларативном представлении не допускаются. ART обеспечивает И системно-определенных свойств, наследование которых поддерживается системой автоматически. Допускается множественное наследование. Однако средства задания активных значений, указания ограничений на слот и привязки процедурных знаний к слотам здесь отсутствуют. Таким образом, роль компонента, основанного на фреймах, является чисто описательной. Ограничения и значения по умолчанию могут быть обеспечены в правилах, хотя их было бы легко установить непосредственно с помощью процедурно-ориентированного фреймового формализма. Наследование, определяемое пользователем, не допускается, но тоже может быть смоделировано посредством правил [Wall et al, 1986]. Согласно концепции фирмы Inference Corporation это является преимуществом, так как статическое наследование предусматривает мощную прекомпиляцию эффективного кода.
Продукционные знания описываются с помощью правил пяти видов: правила выводов, продукционные правила, гипотетические правила, правила ограничений и правила полаганий. Правила вывода добавляют факты в базу знаний, в то время как продукционные правила изменяют факты в рабочей памяти (например, значение атрибута объекта). Гипотетические правила позволяют в ART использовать возможности формирования гипотез и представляются в следующей форме: «ЕСЛИ это случилось, ТО рассматривать это как гипотезу». Правила ограничений описывают ситуацию, которая никогда не может появиться при правильной точке зрения на действительность. Правила полаганий используются для предположений (которые принимаются за правильные) о точках зрения (гипотезах). При подтверждении гипотезой некоторого условия она принимается за правильную, объединяется со всеми породившими ее гипотезами и становится новым корнем в древовидной структуре. Другие, несовместимые, гипотезы отбрасываются.
Вызов процедур, определенных пользователем, может быть использован как в левых, так и в правых частях правил ART. Образцы (patterns) используются в условной части правил. Они должны быть сопоставлены с фактами рабочей памяти. Образцы могут включать переменные и логические связки, обеспечивающие сочетание фрагментов модели (И, ИЛИ, НЕ, СУЩЕСТВУЕТ, ДЛЯ ВСЕХ). ART предлагает традиционные модели вывода: «от фактов к цели» и «от цели к фактам». Они могут объединяться в мощный механизм истинности, основанный на предположениях, который допускает аргументацию типа ЧТО ЕСЛИ. Кроме того, в составе ART используются и классические правила типа OPS. Графическое окружение ART хорошо развито. Интерфейс ARTStudio включает в себя базу знаний с демонстрацией гипотез, утилиты отладчика запускаемых программ, систему подсказок, доступную в любое время, систему меню и графический пакет ARTist (ART Image Syntesis Tool ) с оконным редактором. ART предлагает редактор базы знаний, но не дает редактора схем, подобного внутреннему графическому редактору KEE [Wall et al., 1986; Richer, 1986], обсуждаемому ниже. Как указывается в работе [Gillmore et al., 1985], это может стать причиной ошибок при «глубоком» редактировании разрабатываемых баз знаний. ARTist позволяет создавать доступные правилам меню и управлять окнами пользовательского интерфейса, а также создавать сами окна. Графические конструкции описываются с помощью схем и ссылаются на правила. Это обеспечивает функционирование по принципу управления обращениями к данным.
ART часто представляют в качестве лучшей ИС для создания экспертных систем, но следует понимать, что хорошо эта среда отвечает лишь всем требованиям подхода поверхностных знаний. Благодаря компилятору правил система вывода в ART является быстрой по своей природе. Главные стратегии структуры управления поиском решений обеспечиваются, и некоторая гибкость в управлении поиском остается инженеру по знаниям. Чисто декларативные таксономические фреймы языка интегрируются с системой правил, но в ART не существует действительно процедурных фреймов, которые могли бы позволить объединить предметные описания с продукционными. В этом отношении объектно-ориентированное программирование с образцами и возможностями моделирования могло бы быть более полезным. Нельзя сказать, что подход, основанный на моделях, не осуществим в ART. Однако кажется, что другие ИС более эффективны для этих целей.
Первые версии ART опирались на язык ЛИСП, последние реализованы непосредственно на С. Это увеличивает эффективность периода исполнения ART. Введены в новые версии и некоторые другие усовершенствования. Они касаются в основном выразительной силы формализма, основанного на фреймах, и увеличивают адекватность ART по отношению к методу аргументации, основанному на модели. Имеется информация, что в ART включен и объектно-ориентированный подход.
Теперь рассмотрим основные свойства системы КЕЕ и типы задач, которые «подходят» для этой среды. КЕЕ фактически является большим набором хорошо интегрированных ИИ-парадигм. Этот пакет включает продукционные правила, основанный на фреймах язык с наследованиями, логически-ориентированные утверждения, объектно-ориентированные парадигмы с сопутствующими сообщениями и обеспечивает доступ в базовую LISP-систему. Кроме того, КЕЕ предлагает средства для организации и объединения знаний в специфические компоненты и явного структурирования процесса аргументации. Преимущества КЕЕ заключаются также в мощности и дружественности пользовательского интерфейса.
Главное отличие между формализмом представления знаний КЕЕ и ART заключается в способе, которым эти ИС связывают фреймы и правила. КЕЕ является средой, в основе которой лежат фреймы, в то время как в ART — правила. Фреймы в КЕЕ называются элементами (units) и вводятся в более широком смысле, чем в ART. Здесь фреймы могут иметь процедурную роль и дают возможность построения поведенческих моделей объекта и моделей экспертизы. С этой целью к слотам могут привязываться активные значения и методы. Активные значения могут выборочно активизировать системы правил. Таким образом, язык фреймов КЕЕ позволяет представлять поведение независимых сложных компонент в рамках подхода, основанного на модели, что обеспечивает разделение знаний на проблемно-ориентированные фрагменты. При этом каждый компонент знаний может быть активирован по требованию.
Описание объектов и правил в КЕЕ представляется в виде иерархий фреймов. Доступны два основных отношения: классы/подклассы и классы/примеры. Каждый объект представляется слотами; в системе различаются индивидные (собственные) и коллективные слоты. Первые используются для описания атрибутов и свойств класса, рассматриваемого в качестве объекта, а вторые описывают родовые свойства членов класса. Слоты могут иметь различные аспекты, которые, в свою очередь, могут иметь множественные значения. На них могут накладываться ограничения, которые могут использоваться в качестве автоматических утилит для проверки целостности знаний. Этим КЕЕ отличается от ART, где ограничения могут выражаться только с помощью правил. Со слотами могут быть связаны активные значения. Формализм продукционных правил в КЕЕ тоже хорошо разработан. Использование переменных и вызов LISP-функций допускается как в исполняемых, так и в условных частях.
КЕЕ предлагает несколько методик для моделирования рассуждений. Конечно, при этом имеется базовый поисковый механизм, но КЕЕ позволяет также трансформировать неявные знания во фреймы и в решетки наследования, что дает средства для моделирования операций аргументации.
КЕЕ (версия 3.0) обеспечивается системой, основанной на предположении истинности выполнения, называемой KEEWorld. Согласно заявлениям фирмы IntelliCorp, она обеспечивает поддержку фундаментальных методов поиска в пространстве состояний. Мощность КЕЕ проявляется при решении задач, где процесс аргументации может трансформироваться, выполняться и управляться с помощью фреймовых компонент. Решетка наследования фреймов позволяет установить несколько видов зависимостей между объектами. Система снабжена возможностями автоматического восстановления неявной информации. Утверждается, что эта информация может быть представлена фреймами [Fikes et al., 1985]. КЕЕ обеспечена эффективными возможностями восстановления и автоматической проверки информации. Для этой цели существует логический язык TellandAsk, который используется для определения и восстановления фактов в базе знаний КЕЕ.
Пользовательский интерфейс КЕЕ очень гибкий и тщательно проработанный. Он включает мощный редактор, программу просмотра базы знаний, поясняющие сообщения и т. д. Известно, что он превосходит по мощности интерфейс ART [Wall et al., 1986; Richer, 1986]. КЕЕ обеспечивает пользователя графическими средствами KEEpictures и Activelmages для построения графических представлений. Последние могут быть привязаны к фреймовым слотам, и тогда изменение значения слота приводит к изменению «картинки».
Следует отметить и недавнюю эволюцию системы. КЕЕ 2.1 не имел гипотетической системы или системы, основанной на предположении об истинности выполнения. В КЕЕ 3.0 эти новые возможности доступны. А его открытая архитектура является важным фактором в процессе настройки и расширения, так как части КЕЕ написаны в самом КЕЕ. С одной стороны, это полезно для подтверждения гибкости КЕЕ и способности к развитию. С другой — это может привести к неэффективности исполняющей системы. Дополнительно,фирма IntelliCorp уже разработала пакет специализированных программ для КЕЕ. Одна из таких программ — SIMKIT. Она спроектирована для поддержки моделирования в КЕЕ.
Таким образом, КЕЕ является развитой системой, основанной на фреймах, где хорошо сбалансированы формализмы представления как декларативных, так и процедурных знаний. Доступны в системе и методы явного управления и структурирования процесса аргументации. Благодаря этому КЕЕ является подходящим для решения задач в рамках подхода, основанного на модели.
Важнейшими при разработке интеллектуальных прикладных систем являются вопросы формирования и отладки баз знаний. Но здесь КЕЕ, ART и многие другие инструментальные пакеты, к сожалению, идут по пути обычных систем автоматизации программирования. Пользователю предоставляется мощный графический редактор правил, используемый для начального ввода продукций и коррекции их в процессе отладки, и средства графической трассировки вывода решений, которые должны позволить инженеру знаний ориентироваться во взаимодействии сотен и тысяч правил.
Инструментальная среда G2 — разработка фирмы Gensym Corp. — является развитием известной экспертной системы реального времени PICON. По утверждению официального дилера этой фирмы в России Э. В. Попова, G2 является самой мощной из сред для систем реального времени среди всех инструментов данного класса. Система G2 реализована на всех основных вычислительных платформах, включая рабочие станции Sun, HP9000, RS/6000 и ПЭВМ, работающие под управлением Windows NT. Возможна работа с системой в режиме клиент—сервер в сети Ethernet.
Основные функциональные возможости G2 связаны с поддержкой процессов слежения за множеством (порядка тысяч) одновременно изменяющихся параметров и обработкой изменений в режиме реального времени; проверкой нештатных ситуаций на управляемых объектах и принятием решений как в режиме ассистирования оператору, так и в автоматическом режиме. Функциональные возможности системы обеспечиваются быстрым выполнением распараллеливающихся операций, доступными в режиме on-line данными, блоками темпорального вывода (включая ссылки на прошлое поведение и поведение управляемого объекта во времени, интеграцию с подсистемами динамического моделирования и процедурными знаниями о времени), специальной техникой вывода решений в режиме реального времени (включая стандартные forward и backward рассуждения, а также event-driven выводы, сканирование датчиков для определения ситуаций, требующих немедленного вмешательства в процесс управления, механизмы фокусирования на определенном подмножестве знаний с использованием метазнаний и мощной подсистемой real-time truth maintenance). Все это дает возможность прикладным системам, разработанным с использованием G2, поддерживать на RISC-архитектурах обработку 1000 правил/с реального уровня сложности.
Указанные параметры производят серьезное впечатление, и, хотя доступной технической информации по системе G2 явно недостаточно для окончательных выводов о ее применимости во всем спектре заявленных приложений, можно предположить, что система G2 действительно была одной из-первых инструментальных сред, поддерживающих разработку интегрированных интеллектуальных систем.
В заключение настоящего параграфа остановимся на первых попытках интеллектуализации инструментальных средств. Следует сразу сказать, что здесь достаточно четко просматриваются два направления: снизу (применение методов ИИ для разработки программного обеспечения) и сверху (переход к системам поддержки разработки баз знаний, основывающихся, в свою очередь, на метазнаниях).
Результаты, полученные с использованием методов ИИ в различных областях человеческой деятельности, привели разработчиков МО к идее использования интеллектуальных систем в программировании. Проект «Ассистент программиста» в Массачусетском технологическом институте и проект «Пси» в Стэнфорд-ском университете были первыми шагами в этом направлении [Waters, 1985; Green, 1977]. В этих проектах предпринимались попытки промоделировать знания программиста, используемые для понимания, проектирования, реализации и сопровождения ПО. Предполагалось, что эти знания могут быть использованы, например, экспертной системой для частичной автоматизации процесса разработки ПО, однако существенных результатов в этой части, по-видимому, получено не было.
Методы ИИ могут значительно увеличить мощность существующих инструментальных средств и в области разработки, оценки и проверки требований. Действительно, часто пользователь не знает тех возможностей и особенностей, которые он хотел бы иметь от программной системы, и процесс разработки требований напоминает процесс приобретения знаний. Понятно, что при этом соответствующие инструментальные средства могут использоваться при формировании пользователем своих требований. Вот почему ниже приводится краткий обзор средств приобретения знаний и сопровождения баз знаний, дополняющий аналогичный материал предыдущих глав, но с акцентом на инструментальных компонентах.
Исторически впервые автоматическое извлечение из экспертов конструктов и создание репертуарных решеток, необходимых для построения поля знаний [Гаврилова и др., 1988], было реализовано в системе PLANET [Shaw, 1982; Shaw et al., 1984]. Ряд алгоритмов и программ PLANET был впоследствии использован при создании системы ETS [Boose, 1985a; Boose, 1985b; Boose, 1985с; Boose, 1986], обеспечивающей не только автоматическое создание репертуарной решетки, но и преобразование ее в традиционные для ЭС формы представления БЗ. Потомками ETS являются система NeoETS [Boose et al., 1986] и интегрированная среда для извлечения экспертных знаний AQUINAS [Boose et al., 1987]. Дальнейшим развитием системы PLANET является интегрированная среда KITTEN [Gaines et al., 1986; Gaines et al., 1987], поддерживающая ряд методов извлечения знаний.
Перечисленные выше системы поддержки процессов приобретения знаний, как правило, ориентированы на отдельные фазы всего технологического цикла. Одной из методологий, ориентированных на «интегрированные» средства поддержки разработки, справедливо считается KADS, рассмотренная в параграфе 4.5. В этой системе сделана, пожалуй, первая попытка объединения достижений «классической» технологии программирования и методов ИИ. В дальнейшем эта тенденция стала проявляться все более определенно, и лидерство, в конечном счете, перешло к инструментальным системам нового поколения, основное отличие которых состоит в том, что они опираются на знания о технологии проектирования, реализации и сопровождения интеллектуальных систем. В настоящее время попытки создания таких инструментальных систем наблюдаются в Work-Bench, рассматриваемых ниже.

6.5. WorkBench-системы

К основным характеристикам WorkBench-систем относятся:
1. Использование определенной технологии проектирования на протяжении всего жизненного цикла целевого продукта.
2. Вертикальная интеграция инструментальных средств, обеспечивающая связи и совместимость по данным между различными инструментами, используемыми на разных стадиях создания целевой системы.
3. Горизонтальная интеграция моделей и методов, используемых на одной и той же стадии проектирования.
4. Сбалансированность инструментария, то есть отсутствие дублирующих компонентов, «необходимость и достаточность» каждого инструмента.
Одна из систем данного типа разрабатывалась в рамках проекта VITAL [VITAL, 1990]. Отдельные стадии методологии поддерживаются здесь следующими средствами: анализ — подсистемой КАТ (Knowledge Acquisition ToolKit); проектирование — подсистемой FTDT (Functional and Technical Design Tool); кодирование знаний — языком представления знаний; проверка и верификация — V&VT (Validation and Verification Tool); поддержка и отладка — VT (Visualization Tool).
WorkBench VITAL — тесно связанная с методологией система, пригодная для промышленного применения. Обеспечивается это средствами трансформации баз знаний в процедурное представление и развитыми средствами визуализации для поддержки навигации по большим базам знаний.
В целом проект VITAL был достаточно амбициозным по своим целям и задачам, но, учитывая финансирование его в рамках европейской научной программы ESPRIT и задел основных исполнителей, вполне реальным.
Проект VITAL, если так можно сказать, определил философию разработки WorkBench-систем. Ниже, в качестве примеров, рассматриваются две WorkBench-системы, KEATS [Motta et al., 1988] и Shelly [Bouchet et al, 1989], где эта философия нашла некоторое реальное воплощение.
Система KEATS (Knowledge Engineer's Assistant); [Motta et al., 1988; Motta et al, 1989] первоначально представляла собой набор инструментов, созданных для помощи инженерам знаний в проведении анализа предметных знаний и разработки концептуальной модели ПО (вот тут говорится про предметную область!!!). В первой версии системы, называемой KEATS-1 [Motta et al., 1988], были реализованы редактор текстов CREF (Cross Reference Editing Facility) и графический редактор GIS (Graphical Interface System), а также фрейм-ориентированный язык описания знаний KDL (Knowledge Description Language) и интерпретатор продукционных правил COPS (Context Oriented Production System).
Редактор текстов CREF помогает инженерам знаний провести анализ документов, имеющих текстовую форму, и допускает установление связей между фрагментами типа «ссылается», «обобщает», «заменяет», «предшествует».
Графический редактор GIS позволяет инженеру знаний быстро построить представление концептуальной модели ПО (то же самое). Элементами графического представления могут быть как фрагменты, выделенные посредством компонента CREF, так и произвольные объекты исследуемой ПО (то же самое). Различаются два вида графических элементов: классы (изображаются овалом) и примеры (изображаются прямоугольником). Разные типы отношений между элементами показываются разными стрелками. В KEATS-1 такое графическое представление автоматически транслируется в текст на языке KDL. Поддерживается и обратное отображение.
В работе [Motta et al., 1989] были проанализированы ограничения CREF и GIS как инструментальных средств приобретения знаний. Анализ текстовых документов в CREF и построение концептуальной модели ПО (то же самое), поддерживаемое GIS, являются хотя и разными, но тесно связанными видами деятельности. Но поскольку в KEATS-1 они обеспечиваются разными программными системами и автоматического интерфейса между ними нет, то построение концептуальной модели, элементами которой были бы сущности, выделенные в процессе анализа, требует от инженера по знаниям дополнительных усилий. Поэтому естественно иметь такую инструментальную поддержку, которая позволяла бы инженеру знаний строить концептуальную модель, исходя из информации, содержащейся в текстовых документах. Требуемая инструментальная поддержка была реализована в подсистеме ACQUIST системы KEATS-2 [Motta et al., 1989].
Рассмотрим функциональные возможности ACQUIST подробнее. Выделение фрагментов здесь реализуется посредством указания (с помощью мыши) на область текста и задания имени понятия, релевантного отмеченному тексту. Имена понятий высвечены в виде элементов меню на том же экране, что и анализируемый текст. Нескольким фрагментам может быть поставлено в соответствие одно и то же понятие. Понятия могут быть заранее перечислены инженером знаний или генерироваться непосредственно в процессе анализа текста. В последнем случае возможно «заводить» имена понятий вручную либо воспользоваться лексическим анализатором.
В ACQUIST лексический анализ может выполняться над множеством указанных пользователем текстов. Имеется возможность задать фильтр для отсеивания слов, не представляющих интереса, который реализуется как обычный текстовый файл, где перечислены такие «неинтересные» слова. На понятиях может быть задана иерархическая структура. Пользователь ACQUIST может объединить в одну группу близкие с его точки зрения понятия и дать название этой группе. Группы понятий, в свою очередь, могут быть подвергнуты дальнейшему обобщению.
ACQUIST позволяет связывать фрагменты, понятия, группы с помощью встроенных связей и связей, определенных самим пользователем. Для того чтобы инженер знаний имел целостное представление о той структуре, которую он, устанавливая связи, создает, в ACQUIST имеется возможность построить «карту» текущей структуры. Для одного и того же множества понятий, групп и фрагментов может быть построено много карт, каждая из которых соответствует некоторому «взгляду» на отношения между элементами. Пользователь имеет возможность не только просмотреть графическое представление, но и непосредственно манипулировать его элементами. В частности, можно определять связи, перемещать графические объекты и подструктуры и т. п.
Сохраняемые версии результатов анализа называются здесь теориями. ACQUIST позволяет одновременно загрузить несколько теорий и при необходимости переключаться от одной теории к другой. По желанию пользователя различные теории могут быть слиты. ACQUIST создан с использованием методологии объектно-ориентированного программирования: фрагменты, понятия и группы реализованы как объекты.
Новая версия системы KEATS, которая была развитием предыдущей, разработана в лаборатории когнитологии Открытого университета Великобритании и финансировалась British Telecom. Corp. По определению авторов, KEATS — программное окружение, поддерживающее построение систем, основанных на знаниях. Основное назначение — поддержка разработки ЭС на критических стадиях — приобретение и кодирование знаний, отладка БЗ [Motta et.al, 1989].
Данная система поддерживает не только отдельные методы моделирования, но и обеспечивает интегрированную программную поддержку взаимосвязанных моделей знаний. Основные компоненты KEATS: ACQUIST — средство фрагмен-тирования текстовых источников знаний, которое позволяет разбить текст или протокол беседы с экспертом на множество взаимосвязанных, аннотированных фрагментов (гипертекст) и создать концепты (понятия); FLIK — фреймово-ориентированный язык представления знаний; GIS — графический интерфейс, используемый как для создания гипертекстов и концептуальных моделей с помощью ACQUIST, так и для проектирования фреймовых систем на основе языка FLIK; ERI — базисный интерпретатор правил, обеспечивающий прямой и обратный вывод по продукциям; TRI — визуализирующий интерпретатор правил, демонстрирующий трассу выполнения продукций в виде мозаичной таблицы, а также графически отражающий активные правила, фреймы и конфликтное множество; Tables — интерфейс манипулирования таблицами, который может использоваться вместе со всеми моделями знаний, поддерживаемыми в KEATS; CS — язык описания и распостранения ограничений; TMS — немонотонная система сопровождения истинности, тесно связанная с ERI, FLIK и CS, а также TMV — графический интерфейс подсистемы TMS, обеспечивающий визуализацию на И/ИЛИ дереве значения истинности или ложности заключений в зависимости от посылок.
В системе KEATS концептуальные модели могут создаваться с помощью методов «сверху—вниз» и «снизу—вверх». Первый цодход используется при четко определенной задаче и наличии специфической модели в ПО (то же самое), например в задачах диагностики. Специфическая модель может быть сразу же отражена в виде таблиц и концептуальных моделей и имплантирована в будущую ЭС с помощью GIS и Tables. Когда приобретение знаний основывается не на четко определенной модели ПО, а, например, на протоколе опроса эксперта, используется второй подход. Текстовые данные анализируются и фрагментируются с помощью ACQUIST, и выделяются концепты. Созданная модель затем визуализируется с помощью GIS.
Интеллектуальная система Shelly [Bouchet et al., 1989] является представителем следующего поколения программной поддержки KADS-методологии. Она способна не только обеспечивать выполнение работ, предусматриваемых методологией, но и советовать инженеру знаний, когда и как выполнять ту или иную работу, а также объяснять, почему это необходимо. Система Shelly разрабатывалась как интегрированная программная среда, поддерживающая весь процесс создания ЭС, если он осуществляется в соответствии с KADS-методологией. И процесс разработки самой системы Shelly является примером практического ее применения.
Согласно KADS-методологии, рассмотренной в п. 4.5, необходимо провести анализ четырех типов знаний, относящихся соответственно к уровням стратегий, задач, выводов и предметной области. К уровню стратегий относятся знания, обеспечивающие гибкость разрабатываемой системы, ее способность решать разнообразные проблемы, выбирая или формируя подходящие стратегии. Для системы Shelly такими проблемами являются: управление деятельностью инженера знаний, разрабатывающего прикладную ЭС; слежение за процессом разработки ЭС; выдача советов, подсказок, объяснений по требованию пользователя.
Знания стратегического уровня, необходимые для решения этих проблем, представляют собой набор правил, задающих условия начала и завершения каждого вида работы, предусмотренной KADS-методологией. Иерархия видов работ, а также описания тех работ, выполнение которых поддерживается Shelly, составляют знания уровня задач. К уровню выводов относятся знания о конкретных действиях, с помощью которых может быть выполнена та или иная работа. Уровень предметной области составляют описания тех объектов, над которыми могут выполняться действия, относящиеся к уровню выводов. При этом различаются объекты, используемые в KADS-методологии («понятие», «метакласс» и т. п.), объекты, обусловленные программной реализацией методологии («фрагмент», «связь» и т. п.), и объекты, обусловленные природой интерфейса («окно», «текст» и т. п.).
Основное проектное решение при создании системы Shelly состоит в том, что каждому виду деятельности здесь соответствует свое инструментальное средство AST (Activity Support Tool).
Центральным модулем в Shelly является управляющий модуль «Advice & Guidance». Он предназначен для информирования пользователя о текущем состоянии разработки его прикладной ЭС; обеспечивает ответы на конкретные вопросы пользователя; рекомендует пользователю дальнейшие действия и активирует соответствующий модуль AST; предупреждает пользователя о нарушении им KADS-методологии.
Модуль «Advice & Guidance» может функционировать в двух режимах, различающихся степенью сложности, Первый, простой режим, «локального совета», активируется посредством явного запроса, поступившего от пользователя. Во втором режиме пользователь может получить рекомендации относительно того, как наиболее эффективно работать с Shelly. Система будет постоянно следить за деятельностью пользователя и при необходимости предупредит его и объяснит, почему рекомендуется выполнять ту или иную работу.
Рабочую память Shelly составляют база знаний, базы данных о разработках ЭС и база внешних форм. В базе знаний хранятся описания объектов KADS-методологии и соответствующих видов деятельности. Каждый вид деятельности представлен фреймом со следующим набором слотов
Пример 6.1
описание: <текст>
цель: <текст>
когда: <текст>
как: <текст>
вход: <объект КАВ8-методологии>
выход: <объект КАВ8-методологии>
связан с: <вид деятельности>
поддерживается: AST

Кроме того, в базе знаний имеется набор правил, позволяющих управлять процессом разработки прикладной ЭС.

Пример 6.2
ЕСЛИ <деятельиость1> по проекту X = «завершена» И
<деятелыюсть2> по проекту X = «завершена»
ТО возможно начать <деятельностьЗ> по проекту X.

В базах данных о разработках ЭС представлены примеры объектов KADS-методологии, построенные на конкретном предметном материале, а также информация о текущем статусе каждого вида деятельности («завершена», «начата», «не начата»).
Понятно, что фрагментарный обзор WorkBench-систем, приведенный выше, не дает полного представления обо всех их функциональных возможностях. Однако для нас важна, прежде всего, тенденция развития инструментальных средств поддержки разработки интеллектуальных систем, состоящая в том, что уже имеются положительные примеры WorkBench-инструментария, ориентированного на весь жизненный цикл создания систем, основанных на знаниях.







































Пример разработки системы,
основанной на знаниях

Ё Продукционно-фреймовый ЯПЗ PILOT/2
Ё Психодиагностика — пример предметной области для построения экспертных систем
Ё Разработка и реализация психодиагностической ЭС «Cattell»

7.1. Продукционно-фреймовый ЯПЗ PILOT/2

В любом языке программирования можно выделить три составляющие: декларативную (описания данных), процедурную (правила преобразования данных) и инференциальную (правила управления компонентами процедурной, а иногда и декларативной составляющих). Не исключение в этом смысле и языки представления знаний, но их специфика в том, что описания здесь в основном структурные, а данные могут быть активными за счет присоединенных процедур, обеспечивающих «вычисление» их значений; правила преобразования данных ориентированы скорее на то, чтобы явно специфицировать, что должно быть получено, не концентрируя без необходимости внимание программиста на том, как достигается результат. Но самое большое отличие ЯПЗ от других языков в инференциальной компоненте, которая реализует некоторую (чаще всего встроенную) стратегию поиска решения. Такой подход предполагает, что при выполнении ЯПЗ-программ всегда существует «арбитр», функцией которого является оценка «текущей ситуации» и выбор пути движения от нее к целевой.
В разных ЯПЗ имеются различные средства определения декларативной, процедурной и инференциальной составляющих. Отличия же здесь связаны, в первую очередь, с использованием того или иного подхода к представлению знаний.
В качестве примера развитых средств продукционно-фреймового программирования баз знаний ниже обсуждается ЯПЗ PILOT/2, разработанный в рамках проекта PiES WorkBench [Khoroshevsky, 1994b]. Его специфика в том, что здесь введены явно достаточно мощные средства программирования инференциальной составляющей и выразительные описания образцов, а также удобный и открытый для расширения набор операторов преобразования данных в основной и внешней памяти.

7.1.1. Структура ПИЛОТ-программ и
управление выводом

В общем случае PILOT-программа содержит две основные (декларативная и процедурная) и две вспомогательные (включение файлов и переопределение строк) компоненты. Декларативная часть состоит из элементов, специфицирующих переменные, прототипы функций и/или процедур, а также необходимые базы знаний. Продукционная часть состоит из секций, которые, в свою очередь, содержат продукции. Инференциальная составляющая присутствует в ЯПЗ PILOT/2 неявным образом в виде встроенного «арбитра», алгоритм работы которого описывается ниже, и, кроме того, определяется средствами настройки и перепрограммирования такого «арбитра».
Разбиение на секции и правила и специальные условия в виде секционных и пра-виловых разрешений необходимы для того, чтобы обеспечить многоуровневое управление выполнением PILOT-программ. Как известно [Форсайт, 1987], «арбитр» продукционной системы функционирует следующим образом: сначала для всех продукций проверяются условия применимости и из тех продукций, для которых эти условия истинны, формируется конфликтное множество. Из этого множества по определенному критерию выбирается исполняемая продукция; она реализуется (то есть отрабатывается ее правая часть), и цикл управления работой «арбитра» повторяется, пока конфликтное множество на некотором шаге не станет пустым (тогда работа продукционной системы завершается естественным образом) или функционирование не будет прервано явным образом, например с помощью специального действия из правой части исполняемой продукции (в этом случае работа продукционной системы завершается принудительно).
Понятно, что работа такого «арбитра» имеет смысл лишь в тех случаях, когда продукций немного (десятки), а в конфликтном множестве продукций мало (единицы). В противном случае функционирование системы неэффективно и требуются специальные алгоритмы, чтобы «арбитр» не тратил все время только на себя. К настоящему времени разработаны и опробованы на практике различные стратегии увеличения эффективности работы «арбитра» [de Kleer, 1989], которые используются и в данном случае. Но не менее важно иметь гибкие средства описания этих стратегий с уровня входного языка. Тогда пользователь, в зависимости от требований его задачи, сможет отказаться от стандартных стратегий и описать свою собственную, которая адекватна его конкретному случаю.
Для описания стратегий управления выводом решений в ЯЦЗ PILOT/2 служат секционное и правиловое разрешения. Каждое из них является последовательностью фильтров, с помощью которых формируется и/или изменяется конфликтное множество продукций. Для понимания того, как пользоваться этими фильтрами, необходимо знать стратегию встроенного «арбитра» PILOT/2. Поэтому ниже приводится алгоритм его работы, специфицирующий схему, представленную на рис. 7.1.



Приведенный алгоритм прозрачен и не нуждается в особых комментариях. Заметим лишь, что фильтр «активна/неактивна» реализован как встроенная проверка флагов активности продукций текущей секции. Первоначально (при запуске секции) «арбитр» считает, что все продукции секции активны, но в процессе выполнения их состояние может измениться за счет применения соответствующих действий. Фильтр секционного разрешения тоже программируется с уровня входного языка. В результате применения этих двух фильтров формируется множество продукций, которые принципиально могут войти в конфликтное множество. Этап фильтрации продукций по истинности левых частей — традиционный, в результате получается традиционное конфликтное множество (правда, уже усеченное за счет предыдущих двух фильтров). На этом множестве в ЯПЗ PILOT/2 может быть организовано дополнительное управление за счет программируемых правиловых разрешений. Если все усечения не привели к однозначному выбору исполняемой продукции, она выбирается случайным образом и цикл работы «арбитра» повторяется.
Точек «влияния» на работу «арбитра» PILOT/2 всего четыре: активность/неактивность продукций; секционное разрешение; истинность левых частей продукций; правиловое разрешение. Существует и пятая точка — алгоритм случайного выбора, но она инженеру по знаниям недоступна.
Секционные и правиловые разрешения суть последовательность операторов if-then-else и действий разрешения. При этом сами условия секционного и пра-вилового разрешений — логические формулы в базисе И-ИЛИ-НЕ с общепринятым старшинством операций. А специфика ЯЦЗ PILOT/2 состоит в том, как определяются элементарные разрешения. Семантика действий разрешений (при условии, что через КМ обозначено конфликтное множество) — следующая:
set (Rl, R2,.... Rk) KM - Rl, R2,..., Rk
insert (Rl, R2,..., Rk) КМн - KMC + Rl + R2 + ... + Rk
remove (Rl, R2,..., Rk) KMн - KMC - Rl - R2 - ... - Rk
removeall KM = пустое множество
break Прерывает выполнение оставшихся
элементов секционного или правилового разрешения
Семантика элементарных секционных (продукционных) разрешений — определяется правилами вида:
1. Элементарное секционное разрешение active(Rl,R2,...,Rk) истинно, если все продукции Rl, R2,..., Rk имеют включенные флаги активности.
2. Элементарное секционное (продукционное) разрешение used(Rl,R2,...,Rk) истинно, если все продукции Rl, R2,..., Rk применялись ранее.
3. Элементарное продукционное разрешение ready(Rl,R2,...,Rk) истинно, если все продукции Rl, R2,..., Rk готовы к выполнению, что, в свою очередь, справедливо, если их левые части (условия) истинны.
Понятно, что практически все элементарные разрешения работают с именами продукций, так что проверка соответствующих условий выполняется «арбитром» достаточно быстро. И этих средств (в подавляющем большинстве случаев) достаточно для существенного увеличения гибкости управления продукционной системой и сохранения в то же время приемлемой эффективности ее работы.
Вместе с тем в ЯПЗ PILOT/2 инженеру по знаниям предоставлена возможность управления работой продукционной системы и на основе анализа базы знаний. Нужно лишь понимать, что это управление «дорогое», так что пользоваться им следует лишь в тех случаях, когда соответствующие условия невозможно (или нецелесообразно) проверять в левых частях продукций.

7.1.2. Декларативное представление данных и знаний

Декларативная часть PILOT-программы состоит из элементов, специфицирующих типы данных, прототипы функций и/или процедур, переменные, а также необходимые базы знаний.
Спецификация типов — мощное средство конструирования новых типов данных, которые поддерживаются системой автоматически на основании базовых типов. В ЯПЗ PILOT/2 фиксированы следующие базовые типы: int, float, char, string, имя -фрейма, prototype, frame, func, рте. Без учета спецификации ограничения это дает почти те же возможности, что и спецификация typedef в языках С и C++. Однако в ЯПЗ PILOT/2 существуют и множественные типы, симметричные по отношению к базовым, а также усечение вновь вводимых типов с помощью ограничений. Последние задают в базисе И-ИЛИ-НЕ ограничения, которым должны удовлетворять значения соответствующего типа. Так, например, спецификация

Child is_a Age restr_by (>0 && <12);

вводит подтип типа Age, значения которого должны быть положительными целыми в интервале [0, 12].
Спецификации

Persons is_a {frame};
Friends is_a Persons restr_by (>={Петр, Иван} );

определяют, что элементами типа Friends являются элементы типа Persons, включающие в себя, по крайней мере, два указанных явно элемента.
Обработка сложно структурированных данных во внешней памяти является отличительным свойством всех ЯПЗ. Но помимо этого нужны и «обычные» переменные. Вот почему в ЯПЗ PILOT/2 введены регистры и стеки. Семантика регистров такая же, как у простых переменных традиционных языков программирования. Иначе обстоит дело со стеками. Для явной спецификации поведения стеков в ЯПЗ PILOT/2 введены префиксы и постфиксы, которые являются одноместными операторами, аналогичными по синтаксису унарным операторам (++) и (--) современных языков программирования. Семантика их зафиксирована в табл. 7.1. Одна и та же переменная, в зависимости от наличия или отсутствия префикса (постфикса), трактуется либо как регистр, либо как стек. Для выделения имен переменных в текстах PILOT-программ им предшествует символ «$».
Таблица 7.1.
Семантика переменных в языке PILOT/2

Стековые переменные




GET-переменные

<< Предыдущая

стр. 14
(из 26 стр.)

ОГЛАВЛЕНИЕ

Следующая >>