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

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

Анализ существующих инструментальных систем показывает, что сначала в об­ласти ИИ более активно велись работы по созданию интеллектуальных систем автоматизированного синтеза исполнительных программ. И это естественно, если иметь в виду, что инструментарий ИИ является, по существу, эволюцион­ным развитием систем автоматизации программирования. При этом основная доля мощности и интеллектуальности такого инструментария связывалась не с его архитектурой, а с функциональными возможностями отдельных компонен­тов той или иной технологической среды. Большое значение при разработке ин­струментария для ИИ уделялось и удобству сопряжения отдельных компонен­тов. Пожалуй, именно здесь были получены впечатляющие результаты и именно здесь наиболее широко использовались последние достижения теории и прак­тики программирования, такие, например, как синтаксически-ориентирован­ное редактирование и инкрементная компиляция. Вместе с тем подавляющее большинство современных инструментальных систем «не знают», что проекти­рует и реализует с их помощью пользователь. И с этой точки зрения можно ска­зать, что все такие системы являются не более чем «сундучками» с инструмента­ми, успех использования которых определяется искусством работающего с ними мастера. Примерами подобных сред служит подавляющее большинство инструментальных пакетов и систем-оболочек для создания экспертных систем типа EXSYS [EXSYS, 1985], GURU [MDBS, 1986] и др. [Harmon, 1987]. Однако не они определяют на сегодняшний день уровень достижений в этой области.

К первому эшелону большинство специалистов относит системы ART [ART, 1984], KEE [Florentin, 1987] и Knowledge Craft [CARNEGIE, 1987]. Заметим, что в последнее время в класс самых мощных и развитых систем вошла и среда G2 [САTALYST, 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 различаются факты, которые явно принима­ются за ложные, и факты, истинность которых неизвестна. Возможно использо­вание логических зависимостей, которые позволяют изменить факты позже, если обнаружится, что они на самом деле оказались ложными. Механизм View­point допускает образование нескольких конкурирующих миров, где пробуются альтернативные решения.

Схема предусматривается в ART в качестве макроформы для выражения таксо­номических знаний в структурированном виде, но ни метод, ни активные значе­ния или выход в базовый язык в этом декларативном представлении не допус­каются. ART обеспечивает И системно-определенных свойств, наследование которых поддерживается системой автоматически. Допускается множествен­ное наследование. Однако средства задания активных значений, указания ограничений на слот и привязки процедурных знаний к слотам здесь отсутствуют. Та­ким образом, роль компонента, основанного на фреймах, является чисто опи­сательной. Ограничения и значения по умолчанию могут быть обеспечены в правилах, хотя их было бы легко установить непосредственно с помощью процедур­но-ориентированного фреймового формализма. Наследование, определяемое пользователем, не допускается, но тоже может быть смоделировано посред­ством правил [Wall et al, 1986]. Согласно концепции фирмы Inference Corpora­tion это является преимуществом, так как статическое наследование предус­матривает мощную прекомпиляцию эффективного кода.

Продукционные знания описываются с помощью правил пяти видов: правила выводов, продукционные правила, гипотетические правила, правила ограниче­ний и правила полаганий. Правила вывода добавляют факты в базу знаний, в то время как продукционные правила изменяют факты в рабочей памяти (напри­мер, значение атрибута объекта). Гипотетические правила позволяют в ART ис­пользовать возможности формирования гипотез и представляются в следующей форме: «ЕСЛИ это случилось, ТО рассматривать это как гипотезу». Правила ог­раничений описывают ситуацию, которая никогда не может появиться при пра­вильной точке зрения на действительность. Правила полаганий используются для предположений (которые принимаются за правильные) о точках зрения (ги­потезах). При подтверждении гипотезой некоторого условия она принимается за правильную, объединяется со всеми породившими ее гипотезами и становится новым корнем в древовидной структуре. Другие, несовместимые, гипотезы отбра­сываются.

Вызов процедур, определенных пользователем, может быть использован как в ле­вых, так и в правых частях правил ART. Образцы (patterns) используются в ус­ловной части правил. Они должны быть сопоставлены с фактами рабочей памя­ти. Образцы могут включать переменные и логические связки, обеспечивающие сочетание фрагментов модели (И, ИЛИ, НЕ, СУЩЕСТВУЕТ, ДЛЯ ВСЕХ). ART предлагает традиционные модели вывода: «от фактов к цели» и «от цели к фактам». Они могут объединяться в мощный механизм истинности, основанный на предположениях, который допускает аргументацию типа ЧТО ЕСЛИ. Кроме того, в составе ART используются и классические правила типа OPS.

Графическое окружение ART хорошо развито. Интерфейс ART Studio включает в себя базу знаний с демонстрацией гипотез, утилиты отладчика запускаемых про­грамм, систему подсказок, доступную в любое время, систему меню и графичес­кий пакет 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, 1985c; 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, рассматриваемых ниже.

Дата добавления: 2015-07-02