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, рассматриваемых ниже.