Часть 4. Системы искусственного интеллекта

Часть 4. Системы искусственного интеллекта

4.1. Разновидности систем искусственного интеллекта

Классификация систем ИИ приведена на рис. 4.1.

Рис. 4.1. Классификация систем ИИ

В левой части рисунка 4.2 перечислены подсистемы, характерные для ЭС, а в правой части — подсистемы, характерные для интеллектуальных пакетов прикладных программ (ИППП) и расчетно-логических систем.

Штриховые стрелки указывают на соответствие подсистем в левой и правой частях рисунка 4.2, из которого можно получить различные варианты систем ИИ.

Состав систем ИИ различных разновидностей приведен в табл. 4.1.

Во все виды интеллектуальных систем входит система общения, в общем случае представляющая собой лингвистический процессор в программной или аппаратной реализации, который осуществляет автоматический перевод естественного языка (ЕЯ) на язык ЭВМ и обратно. "Перевод на язык ЭВМ" в данном контексте означает описание семантики ЕЯ-фраз в терминах использованной модели предметной области и получение в результате него перечня агрегатов данных, подлежащих обработке, и перечня модулей, используемых для обработки. Лингвистический процессор работает на основе модели языка (словарь и грамматика) и модели предметной области. В общем случае лингвистический процессор осуществляет морфологический, синтаксический и семантический анализ и синтез запросов и ответов. При звуковой речи соответственно добавляются фонетический анализ и синтез.

Рис. 4.2. Компоненты систем искусственного интеллекта

Таблица 4.1. Состав систем искусственного интеллекта по разновидностям

Разновидности систем	Компоненты	Необязательные компоненты
Интеллектуальные информационно-поисковые системы	1 - 5	3, 5
Интеллектуальные пакеты прикладных программ	1 - 5, 8 - 10
Расчетно-логические системы	1, 2, 4, 8 - 12	2, 4
"Традиционные" экспертные системы	1 - 7
Гибридные экспертные системы в области планирования и проектирования	1 - 6, 8 - 10
Распределенные экспертные системы	1 - 7, 11
Обобщенные прикладные интеллектуальные системы	1 - 12

4.2. Интеллектуальные информационно-поисковые системы

Как видно из табл. 4.1, основными составляющими интеллектуальных ИПС являются система общения, БЗ и БД. Эти системы явились самыми первыми системами ИИ, и работы над ними начались с развитием вычислительной техники. Интеллектуальные ИПС называют также естественноязыковыми системами общения или ЕЯ-системами. Основой систем общения является лингвистический процессор, осуществляющий анализ фраз естественного языка. Вопросно-ответные системы — это упрощенный вариант ЕЯ-систем, когда речь идет в основном об использовании модели языка (словарь и грамматика) и почти не используются знания о предметной области. Системы естественноязыкового общения кроме модели языка содержат базу знаний о предметной области.

Основные функции, выполняемые этими системами - поиск информации по ключевым словам, которые выделяются из фраз пользователя при их лингвистическом анализе.

4.3. Интеллектуальные пакеты прикладных программ

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

БЗ реализуется в виде функциональной семантической сети, представляющей собой в общем случае двудольный помеченный граф с двумя типами вершин. Один тип — это параметры рассчитываемых задач, в том числе исходные данные. Вершины-параметры дугами связаны с другим типом вершин, которым сопоставлены математические отношения. Функциональная семантическая сеть — это неориентированный граф, так как только при постановке расчетной задачи станет известно, что является входами, а что выходами данного математического отношения. Как только это становится известно, программа-планировщик вычленяет из неориентированного графа ориентированный граф решения задачи. У отношений выявляются входы и выходы, т. е. они преобразуются в функции. Если тем или иным способом реализовать программные модули, отвечающие каждой функции, то образуется ориентированный граф, который предопределит построение цепочки модулей рабочей программы.

В СССР были разработаны ИППП ПРИЗ со встроенным языком УТОПИСТ и СПОРА со встроенным языком ДЕКАРТ. С использованием указанных языков в этих системах строится функциональная семантическая сеть и описывается конкретная решаемая задача.

В системе МАВР сделан следующий шаг — автоматизировано построение самой математической модели, т. е. математическая модель автоматически строится по описанию проектируемой системы пользователем на своем языке. Описание пользователем модели предметной области ведется на фреймоподобном языке, а затем автоматически транслируется в функциональную семантическую сеть.

Система общения в таких случаях обычно строится по упрощенной схеме и представляет собой то, что обычно называют естественноязыковым модулем, состоящим из словаря и формирователя стандартизированных фраз-меню, на которых пользователь в режиме диалога осуществляет описание проектируемой системы и формулирует расчетную задачу.

4.4. Расчетно-логические системы

Дальнейшим развитием ИППП для коллективного распределенного решения задач планирования и проектирования, научных исследований и т. п. являются расчетно-логические системы.

ИППП — класс систем ИИ, который можно назвать моносистемами в том смысле, что здесь один (возможно, групповой) пользователь, и соответственно декларативные и процедурные знания сосредоточены в системе.

Между тем в коллективах, решающих какую-либо общую задачу, знания, умение, квалификация, ответственность распределены между специалистами, их группами, организационными подсистемами и т. п.

Для успешного решения общей задачи должно быть обеспечено организационное и информационное взаимодействие как между группами специалистов, так и между группами и руководящим центром. Таким образом, возникает сложная проблема, когда распределенное решение общей задачи будет происходить на основе включения ЭВМ в коммуникационные отношения внутри коллектива в процессе решения общей задачи.

В этом случае вместо совокупности не связанных между собой моносистем искусственного интеллекта будем иметь мультисистему или расчетно-логическую систему, которую можно назвать системой распределенного ИИ. Для распределенного решения общих задач характерным является решение локальных задач на отдельных рабочих местах, а решение общей задачи идет за счет координируемого взаимодействия по каналам связи. Взаимодействие между подсистемами или отдельными пользователями может быть организовано на сети ЭВМ, при этом компетенция, знания, ответственность рассредоточены по многим подсистемам, взаимосвязанным как по вертикали, так и по горизонтали.

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

Мультисистемы, в том числе системы распределенного ИИ, могут представлять собой расчетно-логические системы или быть образованы из экспертных моносистем.

4.5. Экспертные системы

4.5.1. Общие сведения

Экспертная система — это программы ЭВМ, использующие знания и технику рассуждений человека-эксперта. Отличительной особенностью экспертной системы является наличие в ее составе подсистемы объяснения (см. рис. 6.2).

Подсистема объяснения отвечает на вопросы «как» и «почему» система подводит конечного пользователя к тому или иному выводу. В случае отсутствия подсистемы объяснения возможны две равно неприемлемые альтернативы:

игнорирование ЭВМ в результате недоверия к полученным результатам;

перенос ответственности за последствия принятых решений на математиков и ЭВМ.

Практические достоинства ЭС:

ориентация на решение широкого круга задач в трудноформализуемых областях;

минимальные требования к подготовленности пользователя в области вычислительной техники;

повышение эффективности труда пользователей, равное эффекту от повышения их квалификации до уровня эксперта в данной области.

Функции ЭС:

интерпретация данных с целью определения их значения;

диагноз или определение состояния технических и биологических систем (на основе интерпретации зашумленных данных);

контрольное наблюдение (мониторинговые системы) или непрерывная интерпретация данных в реальном масштабе времени критических состояний наблюдаемых объектов (реанимация, ядерные реакторы и т. п.);

предсказание развития будущего на основе моделирования настоящего и прошлого;

планирование и разработка мероприятий для достижения поставленных целей;

проектирование или выработка предписаний по построению объектов, удовлетворяющих поставленным требованиям.

4.5.2. Классы ЭС

Диагностирующие системы (ANGY – диагностика сужения коронарных сосудов и терапевтические рекомендации, CRIB – диагностика ошибок в аппаратуре ЭВМ).

Системы мониторинга (слежения). Отличаются от предыдущих необходимостью функционирования в реальном масштабе времени. Примеры: специализированные диагностирующие системы в медицине (при реанимации), контроль процессов на опасных производствах (FALCON – химическое производство), в ядерных реакторах (REACTOR), на электростанциях (СПРИНТ) и т.д.

Прогнозирующие системы. Осуществляют оценку будущего на основе моделей прошлого и настоящего (WILLARD – предсказание погоды, PLANT – предсказание урожая, ECON – экономические прогнозы).

Планирующие системы. Обеспечивают принятие решений по оптимальному распределению ресурсов, в том числе временных (STRIPS – планирование поведения промышленного робота, ISIS – планирование промышленных заказов).

Системы для проектирования (SYN – синтез электрических цепей, CADHELP – проектирование БИС, XCON – проектирование конфигураций ЭВМ).

Системы для управления. Совмещают в себе планирующие и проектирующие системы с одной стороны, и диагностирующие и интерпретирующие системы с другой (GAS – помощь в управлении газовой котельной, Project Assistant – управление системой календарного планирования).

Системы для обучения. Близки к системам для управления, отличаются превалированием диагностических и интерпретационных функций (PROUST – обучение языку Pascal, Учитель ЛИСПа – обучение языку ЛИСП).

Интерпретирующие системы. Близки к диагностическим. Предназначены для установления свойств объекта по данным о нем. В общем случае объект имеет иерархическую структуру, при этом применяется т.наз. иерархическая интерпретация (SIAP – идентификация типов океанских судов по результатам аэрокосмического сканирования, АВТАНТЕСТ и МИКРОЛЮШЕР – определение основных свойств личности по результатам психодиагностического тестирования).

Диагностические ЭС (1, 2) осуществляют определение принадлежности объекта к какому-либо классу объектов путем анализа его параметров. Как правило, пользуются обратным логическим выводом. Примеры применения - ремонт (например, автомобилей), медицина. По совокупности признаков система определяет тип имеющихся повреждений. Пример программы такого рода- медицинская ЭС MYCIN.

Системы проектирования и планирования (3, 4, 5) весьма сходны с диагностическими, но, как правило, отличаются последовательностью действий. Для них характерны задачи типа: определение последовательности химических реакций, необходимых для получения заданного вещества (SYNCHEM), определение конфигурации компьютера по функциональным требованиям к нему (XCON). Как правило, используют прямую цепочку рассуждений.

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

Интерпретирующие системы близки к диагностическим, отличаются, очевидно, перенесением значительной части ресурсов, затрачиваемых на общение с пользователем, в область рассуждений и вычислений. В качестве примеров приводят: систему DENDRAL, определяющую по результатам спектрального анализа вещества его состав; систему PROSPECTOR, по характеристикам минеральной формации определяющую ее состав. Эти системы используют, как правило, прямую цепочку рассуждений.

Классификация по связи с реальным временем:

Статические ЭС. Знания и данные не меняются во времени. Пример: диагностика неисправностей автомобиля.

Квазидинамические ЭС. Оценка ситуации, меняющейся с некоторым фиксированным интервалом времени. Пример: микробиологические технологии, где лабораторные измерения параметров производятся раз в 4-5 часов.

Динамические ЭС. Работа с датчиками в реальном масштабе времени. Пример: мониторинг в реанимационных палатах.

4.5.3. Структура ЭС

Суть ЭС как человеко-машинной системы легче всего объяснить, показав ее структуру (рис. 4.3).

Рис. 4.3. Структура ЭС

ЭС включает базу знаний, решающий блок, подсистему общения, подсистему объяснений и подсистему накопления знаний. Через подсистему общения с ЭС связаны: конечный пользователь — непрограммирующий специалист; эксперт — квалифицированный специалист, опыт и знания которого намного превосходят знания и опыт рядового конечного пользователя; инженер по знаниям, владеющий языками описания знаний.

С экспертной системой на этапе наполнения знаний работают инженер по знаниям и эксперт, а на этапе эксплуатации и использования — конечный пользователь. Знания, которыми должна быть заполнена экспертная система, включают знания первого и второго рода.

Знания первого рода — это общезначимые факты, явления, закономерности-истины, признанные в данной предметной области и зафиксированные в книгах, статьях, справочниках и т. п.

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

Для создания эффективной экспертной системы необходимо, чтобы эксперт формализовал для инженера по знаниям знания как первого, так и второго рода.

Знания в экспертной системе фиксируются в базе знаний, в которой условно можно выделить интенсиональную и экстенсиональную (собственно базу данных) части (см. рис. 4.3).

Важное значение имеет подсистема объяснения— основное отличие экспертных систем от других диалоговых человеко-машинных систем. В сложных системах подсистема объяснения может быть преобразована в хорошо известную в исследовании операций систему анализа решений. Помимо подсистем объяснения, в экспертных системах начали развиваться специальные подсистемы доверия.

4.5.4. Технология проектирования и разработки экспертных систем

4.5.4.1. Коллектив разработчиков

Минимальный состав коллектива: пользователь, эксперт, инженер по знаниям (аналитик), программист. Реальный коллектив разработчиков – 8 – 10 человек. Причины увеличения коллектива разработчиков:

1) Необходимость учета мнения нескольких пользователей.

2) Необходимость участия нескольких экспертов.

3) Потребность в программистах различной специализации (проблемных, системных и пр.).

Дополнительные челны коллектива – менеджер и технический помощник.

При отсутствии профессионального менеджера руководителем коллектива является инженер по знаниям. К его квалификации предъявляются самые высокие требования.

Основные свойства пользователя:

1) Дружелюбие.

2) Умение объяснять.

3) Отсутствие психологического барьера к применению вычислительной техники.

4) Интерес к новому.

Основные свойства эксперта:

1) Доброжелательность.

2) Готовность поделиться своим опытом.

3) Умение объяснять.

4) Заинтересованность в успешности разработки.

Основные свойства программиста:

1) Общительность.

2) Способность отказаться от традиционных навыков и освоить новые методы.

3) Интерес к разработке.

4) Обязательное знакомство с основными структурами представления знаний и механизмами вывода, состоянием отечественного и мирового рынка программных средств для разработки ЭС и диалоговых интерфейсов.

Основные свойства инженера по знаниям:

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

Влияние фактора пола на эффективность аналитика неоднозначно. Мужчины более склонны к широкому охвату явлений, у них выше аналитичность. У женщин выше наблюдательность к деталям.

Для аналитика важен стиль общения. Рекомендуются внимательность, ненавязчивость, умение слушать и задавать вопросы, коммуникабельность и уверенность в себе.

Инженер по знаниям работает со всеми формами знаний:

Z1 – знания в памяти;

Z2 – знания в книгах;

Z3 – поле знаний;

Z4 – модель знаний;

Z5 – база знаний.

Z1 требует от инженера по знаниям знакомства с:

1) Элементами когнитивной психологии.

2) Способами репрезентации понятий и процессов в памяти человека.

3) Основными механизмами мышления – логическим и ассоциативным.

4) Способами активизации мышления (игры, мозговой штурм и т.п.).

5) Различными моделями рассуждений.

Z2 подразумевает:

· Широкую общенаучную подготовку.

· Знакомство с методами реферирования и аннотирования текстов.

· Владение навыками быстрого чтения.

· Владение текстологическими методами извлечения знаний.

Z3 требует знакомства с:

1. Методологией представления знаний.

2. Системным анализом.

3. Теорией познания.

4. Аппаратом многомерного шкалирования, кластерным и факторным анализом.

Z4 требует владения:

1) Аппаратом математической логики.

2) Современными языками представления знаний.

3) Методологией разработки ЭС, включая методы быстрого прототипирования.

Z5 требует владения:

1) Практическими навыками работы на ЭВМ.

2) Возможно, одним из языков программирования.

4.5.4.2. Проблемы разработки промышленных ЭС

Этапы процесса разработки ЭС:

· Выбор проблемы.

· Разработка прототипа ЭС.

· Доработка до промышленной ЭС.

· Оценка ЭС.

· Стыковка ЭС.

· Поддержка ЭС.

В целом за разработку экспертных систем целесообразно браться организации, где накоплен опыт автоматизации рутинных процедур обработки информации, таких как:

o организация сложных расчетов;

o работа с компьютерной графикой;

o обработка текстов;

o автоматизированный документооборот.

Практика решения задач такого рода:

· подготавливает высококвалифицированных разработчиков;

· позволяет отделить от экспертных систем неэкспертные задачи.

4.5.4.3. Этап выбора проблемы

Этот этап включает:

o определение проблемной области и задачи;

o нахождение эксперта и назначение коллектива разработчиков;

o определение предварительного подхода к решению проблемы;

o анализ расходов и прибылей от разработки;

o подготовку подробного плана разработки.

Последствия неправильного выбора проблемы:

1. Перегруженность проекта задачами, не имеющими традиционных решений.

2. Создание экспертной системы, неэффективной экономически.

3. Создание экспертной системы, неэффективной функционально.

Эта фаза наиболее приемлема для получения рекомендаций извне.

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

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

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

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

В данный момент большая часть разработок ЭС – это дорогостоящие прибыльные проекты, решающие крупные задачи. По мере развития средств разработки ЭС будут появляться менее прибыльные недорогие ЭС.

4.5.4.4. Этап прототипирования

Прототипная система является усеченной версией ЭС, спроектированной для проверки правильности кодирования фактов, связей и стратегий рассуждения эксперта.

Объем прототипа, как правило, – несколько десятков правил, фреймов или примеров.

Стадии разработки прототипа:

1. Идентификация проблемы (1 – 2 недели) – знакомство и обучение коллектива разработчиков, создание неформальной формулировки проблемы. Уточняется задача, планируется ход разработки прототипа, определяются:

a. необходимые ресурсы (кадровые, технические, временные и т.д.);

b. источники знаний (книги, дополнительные эксперты, методики);

c. имеющиеся аналоги разработки;

d. цели разработки;

e. классы решаемых задач.

2. Извлечение знаний (1 – 3 месяца) – получение инженером по знаниям наиболее полного из возможных представлений о предметной области и способах принятия решений в ней. Производится перенос компетентности от эксперта к инженеру по знаниям с использованием: анализа текстов, диалогов, экспертных игр, лекций, дискуссий, интервью и т.д.

3. Структурирование или концептуализация знаний (2 – 4 недели) – разработка неформального описания знаний о предметной области в виде графа, таблицы, диаграммы или текста, которое отражает основные концепции и взаимосвязи между понятиями предметной области. Определяются терминология, список основных понятий и атрибутов, отношения между ними, структура входной и выходной информации, стратегии принятия решений и т.д.

4. Формализация знаний (1 – 2 месяца) – разработка БЗ на ЯПЗ, который соответствует структуре поля знаний и позволит создать прототип системы. ЯПЗ основывается на одной из моделей представления знаний или их синтезе.

5. Реализация (1 – 2 месяца) – разработка программного комплекса, демонстрирующего жизнеспособность подхода. При реализации действующей ЭС первый прототип, как правило, отбрасывается. Способы разработки прототипа:

a. использование традиционных языков и средств разработки (C, Pascal и пр.);

b. использование специализированных языков, ориентированных на задачи ИИ (Lisp, SmallTalk, Prolog);

c. использование инструментальных средств разработки ЭС (G2, ПИЭС);

d. использование «пустых» ЭС или оболочек (ЭКСПЕРТ, ФИАКР).

6. Тестирование (1 – 2 недели) – выявление ошибок в подходе и реализации прототипа и выработка рекомендаций по доводке системы до промышленного варианта. Прототип проверяется на:

a. удобство и адекватность интерфейсов ввода/вывода;

b. эффективность стратегии управления;

c. качество проверочных примеров;

d. корректность БЗ.

4.5.4.5. Развитие прототипа до промышленной ЭС

Дополнительные этапы перехода:

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

Совершенствование БЗ на этапах от демонстрационного до действующего прототипа ведется в двух направлениях:

o увеличение «глубины» знаний (добавление новых знаний);

o добавление управляющих знаний о стратегиях и метазнаний.

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

4.5.4.6. Оценка системы

Оценка заключается в тестировании, к которому широко привлекаются эксперты со стороны. Критерии оценки:

o критерии пользователей (понятность работы системы, удобство интерфейсов);

o критерии экспертов (оценка решений, выдаваемых системой, оценка функционирования ее подсистем);

o критерии коллектива разработчиков (эффективность реализации, производительность, время отклика, дизайн, широта охвата предметной области, непротиворечивость БЗ, обработка ситуаций отсутствия решения).

4.5.4.7. Стыковка системы

Производится интеграция системы с БД, программными и техническими средствами в среде, в которой она будет работать, и обучение персонала (включая расширенную демонстрацию решения задач пользователей). Инженер по знаниям обязан лично проконтролировать результаты внедрения системы.

4.5.5. Разновидности ЭС

Распределенные экспертные системы.

Распределенные ЭС организуют в результате интеграции отдельных ЭС, в том числе ориентированных на различные предметные области. Применение - многоаспектный анализ сложных объектов, когда важно взаимодействие различных специалистов в процессе распознавания и формирования плана действий. Характерный пример - решение эколого-экономических проблем.

Гибридные экспертные системы.

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

Обобщенные прикладные интеллектуальные системы.

Обобщенные прикладные интеллектуальные системы можно рассматривать как расчетно-логические системы, дополненные экспертными подсистемами, или как распределенные экспертные системы с сильной вычислительной компонентой.

4.5.6. ЭС I и II поколений

Одним из серьезных недостатков продукционной концепции является невозможность реализовать (смоделировать) такие трудноформализуемые механизмы человеческой дедукции, как здравый смысл и интуиция. Иными словами, традиционные ЭС способны лишь повторять рассуждения эксперта, руководствуясь заложенными экспертом правилами. Они не способны заменить эксперта, повторить логику его рассуждений, применяемую им для вывода этих правил. ЭС такого рода называют ЭС первого поколения.

В 80-90-х г.г. начали разрабатываться ЭС второго поколения, называемые также партнерскими ЭС и усилителями интеллектуальных способностей человека. Они способны автоматически проводить анализ нечисловых данных, выявлять закономерности и формулировать на их основе гипотезы, оценивать достоверность фактов и непротиворечивость знаний.

Проведем сравнительный анализ ЭС первого и второго поколений по ряду их характеристик:

Представление знаний

ЭС I поколения:

Рассуждения ведутся только на основе знаний, полученных от эксперта.

Используется какая-либо одна модель представления знаний.

Методы представления знаний позволяют описывать лишь статические предметные области.

Отсутствуют знания о границах области компетентности системы, за пределами которой система оказывается неработоспособной.

ЭС II поколения:

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

Знания организованы в виде составных иерархических представлений, включающих сети фреймов, продукции и логические модели.

Система имеет не только модель предметной области, но и модель самой себя, что позволяет ей эффективно определять границы своей компетентности.

ЭС может решать задачи из динамических предметных областей, т.е. областей, знания о которых могут изменяться непосредственно в процессе вывода (в том числе и в результате действий самой ЭС).

Система включает средства для одновременной работы с несколькими моделями предметной области, отличающимися друг от друга уровнями детальности.

Механизм вывода

ЭС I поколения:

Получение новых заключений с помощью вывода на знаниях, т.е. на основе парадигмы ЗНАНИЯ+ВЫВОД.

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

Неумение проводить вывод с учетом связи объектов или фактов в пространстве и во времени.

Скачкообразная потеря способности экспертной системы находить решения даже при незначительном выходе задач за пределы области ее компетентности.

ЭС II поколения:

Получение новых заключений не на основе дедукции, а на основе аргументации, т.е. поиска аргументов для обоснования высказываемой гипотезы. Т.е. от парадигмы ЗНАНИЯ+ВЫВОД осуществлен переход к парадигме ЗНАНИЯ+АРГУМЕНТАЦИЯ.

Сочетание достоверного и правдоподобного (включающего характеристику степени достоверности) вывода.

Наличие помимо свойственного ЭС первого поколения дедуктивного вывода средств для реализации индуктивного (от частного к общему) и абдуктивного (от частного к частному) выводов, а также проведения немонотонных рассуждений, в процессе которых поступившие факты иногда изменяют истинность выведенных ранее заключений.

Способность проводить вывод с учетом связи объектов или фактов в пространстве и во времени.

Приобретение знаний и обучение

ЭС I поколения:

Пополнение знаний системы и контроль их непротиворечивости "вручную".

Обязательность приведениязнаний эксперта к виду, которого требует модель представления знаний в данной ЭС.

Несовпадение знаний о предметной области в ЭС с организацией их у эксперта, как следствие узости применяемой модели организации знаний, что влечет за собой неполноту знаний ЭС.

Отсутствие способности к обучению.

ЭС II поколения:

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

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

Способность ЭС к поиску противоречий между знаниями, проверки их полноты, пополнения их при необходимости путем запроса к пользователю.

Создание экспертных систем II поколения требует привлечения эффективных инструментальных средств программирования.

4.5.7. Применение технологий разработки программного обеспечения к разработке экспертных систем

4.5.7.1. Основные принципы реализации и проектирования ПО

Проектирование – составление формальных или формализованных спецификаций.

Реализация – преобразование (в частности, автоматическое или автоматизированное) этих спецификаций в программный код.

Сопровождение – тестирование разработанной системы, ее внедрение и последующая модификация (в том числе с возвратом в стадию проектирования).

Для того, чтобы преодолеть разрушающий эффект изменений требований в процессе разработки, должны обеспечиваться основные свойства программных систем:

1. Модифицируемость. Модификация ПО может выполняться по причине необходимости исправления ошибок или необходимости отражения в системе изменений требований.

2. Эффективность системы подразумевает оптимальное использование ею ресурсов (аппаратных и временных).

3. Надежность системы предполагает, что она должна предотвращать ошибки концепции, проектирования и реализации, ошибки, возникающие в процессе ее функционирования.

4. Понимаемость – «прозрачность» с точки зрения предметной области.

Достижение этих целей (свойств) обеспечивается выполнением следующих принципов:

o абстракции;

o модульности;

o сокрытия информации;

o локализации;

o единообразия;

o полноты;

o подтверждаемости.

Абстракция – выделение существенных свойств с игнорированием несущественных деталей. По мере декомпозиции решения на компоненты каждая из них становится частью абстракции на соответствующем уровне.

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

Абстракция и сокрытие информации способствуют модифицируемости и понимаемости систем ПО. На каждом уровне абстракции допускается применение лишь определенного набора операций и не допускается применение любых операций, нарушающих логическую концепцию данного уровня, за счет чего повышается надежность программной системы.

Модульность оценивается в критериях связности (взаимной зависимости модулей) и прочности (связности элементов внутри модуля). Модули могут быть функциональными (процедурно-ориентированными) и декларативными (объектно-ориентированными).

Принципы единообразия, полноты и подтверждаемости гарантируют получение согласованных и правильных систем.

Основные теоретические подходы к разработке ПО:

o нисходящее структурное проектирование (Йордан);

o проектирование, структурированное по данным (Джексон);

o объектно-ориентированное проектирование (Буч).

Нисходящее структурное проектирование заключается в декомпозиции функций системы и получении таким образом иерархии функциональных модулей.

Проектирование, структурированное по данным, заключается в декомпозиции данных и определении их структур, а затем, на их основе, разработке программных модулей.

Объектно-ориентированное проектирование является сбалансированным решением, избавленным от недостатков этих двух подходов.

Базисными понятиями при автоматизации проектирования программных комплексов являются модель программы и модель системы.

4.5.7.2. Методологии проектирования ПО

W/O-методология – методология Вернира-Орра (Warnier/Orr)

Объединяет методологию Вернира по использованию логических структур данных и логических конструкций программ и систем и методологию Орра DSSD (Data Structured System Development). Методология Орра базируется на аксиоме о логическом соответствии между эвристической структурой программ и обрабатываемых ими данных. На практике такая методология предполагает, что в распоряжении проектировщика имеется представительный набор процедурных шаблонов для достаточно широкого класса программируемых задач.

В настоящее время DSSD-методология переросла из методологии разработки программ в методологию разработки систем. В рамках ее выделены явно уровень программирования (programming level) и системный уровень (system level). Применяются два концептуальных представления – диаграммы входов (Entity Diagrams), обеспечивающие определение системного контекста, и модифицированные W/O-диаграммы (Assembly-line Diagrams), специфицирующие функциональное развитие системы.

Логическое моделирование Гэйна

Метод ориентирован на создание систем обработки данных. Логическая модель системы проектируется в семь этапов:

Описание предметной области с помощью диаграмм потоков данных (DFD – Data Flow Diagram).

Выделение первичной модели данных (списка элементов данных в каждом информационном узле).

Проверка структуры данных в DFD.

Сведение полученной на предыдущих этапах информации в двумерные таблицы.

Коррекция DFD с учетом результатов нормализации предыдущего этапа.

Разбиение полученной в результате выполнения предыдущих этапов модели на «процедурные единицы» (procedure units).

Определение деталей каждой процедурной единицы.

После выполнения этих этапов принимается решение о необходимости прототипирования системы на целевом языке.

Метод Йордана

Ориентирован на проектирование систем обработки данных. Включает два компонента: инструментальные средства и методики. Под инструментальными средствами здесь понимаются различные диаграммы, используемые при описании моделей требований и моделей архитектуры ИС. Недостатком DFD является отсутствие средств описания отношений между данными и их «поведения» во времени. Поэтому в состав инструментальных средств Йордана, кроме DFD, включены диаграммы «сущность-связь» (ERD – Entity Relationship Diagram) и диаграммы переходов (STD – State Transition Diagram).

Метод Йордана позволяет получить хорошо организованную системную модель на традиционном нисходящем (top-down) моделировании. Однако в настоящее время здесь используется метод событийного разбиения (event partitioning).При этом сначала создается контекстная диаграмма верхнего уровня (top level context diagram), где определяются системные ограничения и интерфейсы с внешним «миром». Затем с помощью техники интервью формируется список событий из внешней среды, на которые система должна реагировать. Такой подход обеспечивает простой базис для формирования «сырой» DFD. Несколько DFD-реакций могут быть объединены в реакцию более высокого уровня. Критерием такого объединения является наличие узлов, связанных общими данными. Событийное разбиение есть метод объектно-ориентированного проектирования.

Проблемы метода ERD связаны с трудностями интеграции компонентов. Этот метод был обобщен за счет введения интегрированной БД. При этом ERD-метод трансформируется в структурную методологию, основные этапы которой сводятся к разработке ERD, определению кардинальности – однозначности-многозначности типов связей, преобразованию ERD по определенным правилам в соответствующий файл и структуру БД. В процессе такого преобразования каждый тип сущности трансформируется в отношение, а тип связи – в особое отношение или объединяется с другими отношениями в зависимости от кардинальности типа связи. На основе сформированного файла и структуры БД производится разработка прикладного ПО.

Структурное проектирование Йордана

Мощный и активно используемый подход, использующий оценки результатов проектирования. Предлагается все проектные решения располагать в трехмерном пространстве «содержание-сложность-связность». Хорошие проектные решения при заданном содержании имеют минимальную сложность и максимальную связность. Пример структурного подхода – «водопадная» или «каскадная» (waterfall) модель разработки систем ПО.

Спиральная модель процесса разработки Боэма.

Суть – отдельные фазы процесса прокручиваются на постепенно повышающихся уровнях иерархии. Такая модель предполагает наличие более гибких механизмов взаимодействия между потребителями и разработчиками и соответствующих инструментальных средств.

Методология Шлайера-Мэллора

Относится к спиральным моделям. В рамках данного подхода проектирование рассматривается как процесс, протекающий в пространстве трех измерений «статика-динамика-алгоритмы». Указанные измерения обходятся последовательно в течение следующих стадий:

Вдоль оси «Статика»: идентификация и описание объектов, атрибутов и отношений.

От оси «Статика» к оси «Динамика»: описание поведения каждого объекта в качестве реакции на внешние факторы и формирование жизненных циклов объектов.

От оси «Динамика» к оси «Алгоритмы»: проектирование алгоритмов, специфицированных на предыдущей стадии.

От оси «Алгоритмы» к оси «Статика»: валидация спроектированной системы на полноту и функциональное соответствие исходной задаче.

4.5.7.3. Инструментальные средства поддержки разработки систем ПО

В общей структуре типовой технологической системы поддержки разработки обычно выделяют:

o БД проекта;

o подсистему автоматизации проектирования и программирования;

o подсистему отладки;

o подсистему документирования и сопровождения;

o подсистему управления ходом выполнения проекта.

Проект Gandalf

Аспекты поддержки проектирования ПО:

Управление проектом.

Контроль версий.

Инкрементное программирование.

Разрабатываемый проект трактуется как множество абстрактных типов данных, над которыми могут выполняться лишь определенные операции.

В результате проекта появилась система SDC (Software Development Control).

Проект FAFOS

Исследования в области контроля версий были начаты Л.Коопридером на безе проекта FAFOS (нач. 1970-х г.г.), где изначально анализировались возможности создания семейства операционных систем. Была разработана нотация для описания взаимодействий между подсистемами, для описания различных версий подсистем, для описания действующих на этапе разработки механизмов (компиляции, редактирования связей и т.п.).Был создан специальный язык Intercol как средство описания взаимосвязей и версий модулей в системе. В систему были встроены знания о том, как конструировать систему из частей. Была создана система SUCE, в которой отслеживались различия между реализациями (версиями, которые действительно дают код для ряда спецификаций) и композициями (версиями, определяющими новые подсистемы как группы существующих подсистем).

Система LOIPE (Language-Oriented Incremental Programming Environment)

Пользовательский интерфейс базируется на подсистеме синтаксически-ориентированного редактирования ALOE (A Language-Oriented Editor).

CASE-технология (Computer Aided Software Engineering)

Ранние CASE-системы поддерживали проектирование информационных потоков. Сейчас наблюдается отход от ориентации на системы обработки данных, и CASE-средства становятся все более универсальными.

Разновидности CASE-средств: CASE-ToolKit и CASE-WorkBench.

CASE-ToolKit – коллекция интегрированных программных средств обеспечивающих автоматическое ассистирование в решении задач одного типа в процессе создания программ.

Синонимы: пакеты разработчика, технологические пакеты, инструментальные сундучки.

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

CASE-WorkBench – средства реализации замкнутого производственного цикла разработки, реализации и сопровождения ПО.

Синонимы: технологические линии (станки) для производства программ.

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

Функциональные возможности CASE-средств:

4.5.8. Модели жизненного цикла интеллектуальных ИС

Отличия интеллектуальных ИС от обычных ИС

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

Основные этапы ЖЦ интеллектуальных систем:

1. Инженерия требований

2. Тестирование на прототипах

3. Сопровождение

4.1) Этап включает в себя проектирование, но начинается с формулирования полных, непротиворечивых и однозначных требований. При проектировании должны использоваться принципы технологии разработки ПО (сокрытие информации, локализация. модульность). Система должна проектироваться как композиция уровней. Любой уровень должен быть чувствителен лишь к нижележащим уровням. Такое проектирование упрощает не только реализацию, но и тестирование.

4.2) Тестирование ИИС отличается недетерминированным поведением системы, зависящим от параметров времени исполнения. Поэтому важно тестирование на прототипах.

4.3) Включает выполнение самых различных модификаций системы. БЗ – наиболее динамичный компонент системы и меняется в течение всего жизненного цикла. Для облегчения этого этапа могут использоваться системы управления версиями, системы управления конфигурациями, системы модифицирующих запросов.

Применительно к ЭС первые два этапа уточняются следующим образом:

1. Идентификация. Определение задач, выявление целей, ресурсов, определение наличия экспертов, категорий и требований будущих пользователей.

2. Концептуализация. Анализ предметной области, выявление понятий и методов решения задач.

3. Формализация. Определение способов представления всех типов знаний, спецификация выявленных понятий, фиксация способов интерпретации знаний, моделирование работы системы, оценка результатов.

4. Реализация. Создание программного окружения, в котором будет функционировать ЭС, наполнение экспертом БЗ.

5. Тестирование. Проверка компетентности и пригодности ЭС в интерактивном режиме экспертом и инженером по знаниям.

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

Промышленная технология создания ЭС включает в себя три фазы (технологии):

Проектирование.

Реализация.

Внедрение.

Жизненный цикл разработки при этом состоит из шести этапов:

исследование выполнимости проекта;

разработка общей концепции ЭС;

разработка и тестирование серии прототипов;

разработка и испытание головного образца;

разработка и проверка расширенных версий системы;

привязка системы к реальной рабочей среде.

Сводная таблица фаз и этапов ЖЦ ЭС

ЖЦ ИИС	ЖЦ ЭС	Фазы промышленной технологии разработки ЭС	Этапы промышленной технологии разработки ЭС
Инженерия требований	Идентификация	Проектирование	Исследование выполнимости проекта
Концептуализация	Разработка общей концепции ЭС
Формализация	Реализация	Разработка и тестирование серии прототипов
Тестирование на прототипах	Реализация	Разработка и испытание головного образца
Тестирование	Разработка и проверка расширенных версий системы
Сопровождение		Внедрение	Привязка системы к реальной рабочей среде

4.5.9. Языки программирования для ИИ и языки представления знаний (ЯПЗ)

Уже к началу 60-х г.г. XX в. стало очевидно, что сложность и трудоемкость разработки ИИС настолько велики, что универсальные языки программирования для их разработки применимы не всегда.

Нач. 60-х г.г. – Стэнфорд – Дж. Маккарти – ЛИСП. Первоначально этот язык не предназначался для реализации задач ИИ, а рассматривался как более универсальное средство программирования. ЛИСП должен был стать основой нового поколения языков, включающих средства работы с матрицами, указателями, структурами из указателей и т.п., однако для такой амбициозной задачи не хватило средств.

Первой окончательной версией языка стала LISP 1.5 (нач. 60-х г.г.). В дальнейшем концепция языка не менялась. В начале 70-х г.г. были созданы мощные версии языка MacLisp и InterLisp. Дальнейшее развитие языка шло по пути стандартизации: Standart Lisp, Franz Lisp, Common Lisp.

К концу 80-х г.г. версии ЛИСП были реализованы на всех классах ЭВМ. Тогда же начали выпускаться ЛИСП-машины, которые выпускаются некоторыми фирмами по сей день.

В середине 60-х г.г. появился язык СНОБОЛ (Грисуолд, лаб. Белла) – язык обработки строк, в котором впервые была в полной мере реализована концепция поиска по образцу, руководимого системой продукционных правил. Причинами низкой популярности СНОБОЛ считают массированную конкуренцию со стороны ЛИСП и опережение возможностями языка потребностей практики.

К концу 60-х г.г. был разработан язык РЕФАЛ (Турчин, ИПМ АН СССР). Вобрал в себя все лучшие черты языков того времени (в первую очередь, ЛИСП и СНОБОЛ): списочную организацию данных, механизмы поиска по образцу, реализацию продукционной концепции.

ПРОЛОГ – нач. 70-х г.г. – Марсельский университет. Если в ЛИСП была скрыта от разработчика работа с памятью, то в ПРОЛОГ – скрыт поток управления в программе. Программирование в ПРОЛОГ осуществляется путем декларирования отношений. В случае большого количества и сложности отношений программа становится сложной для разработки, понимания и сопровождения. Особую популярность ПРОЛОГ начал приобретать в начале 80-х г.г., когда был математически обоснован его логический базис.

Кроме названных, был разработан еще большой ряд языков ИИ, использующих и совершенствующих концепции, заложенные в ЛИСП и ПРОЛОГ. Важно то, что разработки языков программирования задач ИИ дали толчок к разработке языков представления знаний, т.к. задачи ИИ подразумевают работу со знаниями, и задача представления знаний так или иначе решалась во всех языках ИИ.

Характерные черты ЯПЗ:

o двухуровневое представление данных (абстрактная модель предметной области в виде иерархии множеств понятий и конкретная модель ситуации как совокупность взаимосвязанных экземпляров этих понятий);

o процедурное представление связей между понятиями;

o семантический подход к сопоставлению образцов и поиску по образцу.

Наиболее известные ЯПЗ: KRL, FRL, KL-ONE, OPS5 (Official Production System ver. 5).

OPS5 – один из многочисленных ЯПЗ, поддерживающих продукционное представление знаний. OPS5-программа содержит:

o секцию деклараций, где описываются используемые объекты, и определяются введенные пользователем функции;

o секцию правил-продукций.

Объекты описываются с помощью фреймов-экземпляров, прототипы которых задаются в виде определенных структур данных, опирающихся на небольшое число встроенных типов. Модуль вывода решений состоит из трех основных блоков:

o отождествления (поиска подходящих правил);

o выбора исполняемого правила из конфликтного множества правил;

o исполнителя выбранного правила.

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

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

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

Наличие гибких средств управления выводом.

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

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

4.5.10. Инструментальные пакеты разработки задач ИИ (ToolKit-системы)

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

Сначала в области ИИ более активно велись работы по созданию интеллектуальных систем автоматизированного синтеза исполнительных программ. Современные ToolKit-системы представляют собой программные комплексы поддержки технологии разработки ИИС.

Система ART (80-е г.г.)

Представление знаний: продукционные правила для процедурных знаний (основная модель) и фреймоподобные структуры для декларативных знаний. Декларативные знания представляют собой факты, схемы (таксономические структуры), образцы. В ART различаются факты, явно принимаемые за ложные и факты, истинность которых неизвестна. Механизм «точек зрения» (Viewpoint) допускает образование конкурирующих миров, где пробуются альтернативные решения. Обеспечивается 11 системно-определенных свойств, наследование которых поддерживается системой автоматически. Допускается множественное наследование.

Продукционные знания описываются с помощью правил пяти видов:

Правила вывода (добавляют факты в БЗ).

Продукционные правила (изменяют факты в БД).

Гипотетические правила (используются для формирования гипотез).

Правила ограничений (описывают невозможные ситуации).

Правила полаганий (используются для предположений о гипотезах).

При подтверждении гипотезой некоторого условия она принимается за правильную, объединяется со всеми породившими ее гипотезами и становится новым корнем в древовидной структуре. Несовместимые гипотезы отбрасываются.

Вызов процедур, определенных пользователем, возможен как в условных, так и в констатирующих частях правил. Образцы могут использоваться в условных частях правил. При этом они сопоставляются с фактами БД. Образцы могут включать переменные и логические связки (И, ИЛИ, НЕ, СУЩЕСТВУЕТ, ДЛЯ ВСЕХ).

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

Первые версии ART были реализованы на ЛИСП, последние – на C.

Пакет KEE

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

Основная модель представления знаний – фреймы. Фреймы могут, в частности, играть процедурную роль и дают возможность построения поведенческих моделей объекта. С этой целью к слотам могут привязываться активные значения и методы. Активные значения могут выборочно активизировать системы правил. Обеспечивается разделение знаний на проблемно-ориентированные фрагменты, активируемые по требованию.

Продукционные правила также присутствуют. Использование переменных и вызов функций ЛИСП допускается и в условных и в констатирующих частях.

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

Решетка наследования фреймов позволяет установить несколько видов зависимостей между объектами.

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

Инструментальная среда G2

Инструментальная среда G2 (Gensym Corp.) – развитие ЭС реального времени PICON.

Реализована на всех основных платформах, включая Sun, HP9000, RS/6000.

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

Функциональные возможности системы обеспечиваются, в частности, ссылками на исторические данные о поведении управляемого объекта, интеграцией с подсистемами динамического моделирования и процедурными знаниями о времени, стандартными механизмами прямого и обратного вывода, а также вывода, управляемого событиями (event-driven), механизмами фокусирования на определенном подмножестве знаний с использованием метазнаний.

Все это дает возможность прикладным системам, разработанным с использованием G2, поддерживать на мощных RISC-архитектурах обработку 1000 правил/с реального уровня сложности.

4.5.11. WorkBench-системы

Основные характеристики:

1. Использование определенной технологии проектирования на протяжении всего ЖЦ целевого продукта.

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

3. Горизонтальная интеграция моделей и методов, используемых на одной стадии проектирования.

4. Сбалансированность инструментария, «необходимость и достаточность» каждого инструмента.

VITAL (80-е г.г.).

Основные средства:

KAT (Knowledge Acquisition ToolKit) – подсистема анализа;

FTDT (Functional and Technical Design Tool) – подсистема проектирования;

ЯПЗ для кодирования знаний;

V&VT (Validation and Verification Tool) – подсистема проверки и верификации;

VT (Visualization Tool) – подсистема поддержки и отладки.

VITAL – система, пригодная для промышленного применения. Обеспечивается это средствами трансформации БЗ в процедурное представление и развитыми средствами визуализации для поддержки навигации по крупным БЗ.

Проект VITAL определил дальнейшую философию развития WorkBench-систем.

KEATS (кон. 80-х г.г.) – Knowledge Engineer Assistant.

В состав первой версии системы (KEATS-1) вошли:

Редактор текстов CREF (Cross Reference Editing Facility);

Графический редактор GIS (Graphical Interface System);

Фрейм-ориентированный язык описания знаний KDL (Knowledge Description Language);

Интерпретатор продукционных правил COPS (Context Oriented Production System).

CREF автоматизирует анализ текстовых документов и допускает установление связей между фрагментами типа «ссылается», «обобщает», «заменяет», «предшествует».

GIS позволяет инженеру знаний быстро построить представление концептуальной модели ПО. Элементами графического представления могут быть как фрагменты, выделенные посредством компонента CREF, так и произвольные объекты исследуемой ПО. Используются два вида графических элементов: классы и примеры. Разные типы отношений между элементами показываются разными стрелками. Такое графическое представление автоматически транслируется в текст на KDL. Поддерживается и обратная трансляция.

Недостатком KEATS-1 является отсутствие автоматического интерфейса между CREF и GIS, т.е. обмен данными между ними требует большого объема ручной работы. Этот недостаток был значительно сокращен подсистемой ACQUIST системы KEATS-2.

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

Реализован лексический анализ. Имеется возможность задать фильтр (перечисление) для отсеивания слов, не представляющих интереса. На понятиях может быть задана иерархическая структура. Пользователь может определить в одну группу близкие понятия и наименовать ее. Группы понятий также могут быть подвергнуты обобщению.

Для того, чтобы инженер по знаниям имел целостное представление о той структуре понятий, которую он создает, в ACQUIST имеется возможность построить карту текущей структуры. Для одного и того же множества понятий, групп и фрагментов может быть построено много карт, каждая из которых соответствует некоторому «взгляду» на отношения между элементами.

Сохраняемые версии результатов анализа называются здесь теориями. ACQUIST позволяет переключаться между теориями, а также объединять их. ACQUIST реализован с использованием методологии ООП: фрагменты, понятия и группы реализованы как объекты.

Основное назначение KEATS – поддержка разработки ЭС на критических стадиях – приобретение и кодирование знаний, отладка БЗ.

Основные компоненты современной версии KEATS:

ACQUIST – средство фрагментирования текстовых источников знаний (

Дата добавления: 2015-09-29