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

 

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

Анализ существующих инструментальных систем показывает, что сначала в области ИИ более активно велись работы по созданию интеллектуальных систем автоматизированного синтеза исполнительных программ. И это естественно, если иметь в виду, что инструментарий ИИ является, по существу, эволюционным развитием систем автоматизации программирования. При этом основная доля мощности и интеллектуальности такого инструментария связывалась не с его архитектурой, а с функциональными возможностями отдельных компонентов той или иной технологической среды. Большое значение при разработке инструментария для ИИ уделялось и удобству сопряжения отдельных компонентов. Пожалуй, именно здесь были получены впечатляющие результаты и именно здесь наиболее широко использовались последние достижения теории и практики программирования, такие, например,чкак синтаксически-ориентированное редактирование и инкрементная компиляция. Вместе с тем подавляющее большинство современных инструментальных систем «не знают», что проектирует и реализует с их помощью пользователь. И с этой точки зрения можно сказать, что все такие системы являются не более чем «сундучками» с инструментами, успех использования которых определяется искусством работающего с ними мастера. Примерами подобных сред служит подавляющее большинство инструментальных пакетов и систем-оболочек для создания экспертных систем типа 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, рассматриваемых ниже.

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-инструментария, ориентированного на весь жизненный цикл создания систем, основанных на знаниях.

 

⇐ Предыдущая30313233343536373839Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: