Лекции - Интеллектуальные системы

Подождите немного. Документ загружается.

Фактор достоверности изменяется от –1 до +1. (-1 - полное

отрицание факта, +1 – полное подтверждение факта).

В MYCIN используется обратный вывод. Условная часть

правил в MYCIN принимает значение ИСТИНА с некоторым

коэффициентом CF. Тогда достоверность условной части меньше

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

В системе MYCIN не предусмотрены методы увеличения

эффективности поиска.

Контрольные вопросы:

1. Для чего нужен компонент вывода продукционной

системы?

2. Какие функции выполняет управляющий компонент?

3. Какие методы «слепого поиска» используются при

управлении в продукционных системах?

4. Какие методы эффективного поиска используются?

5. В чем суть стратегии выбора правил из альтернативного

ряда?

6. Недостатки продукционной модели.

7 Достоинства продукционной системы

РАЗРАБОТКА ЭС.

Лекция 10 ЭТАПЫ РАЗРАБОТКИ ЭС.

План лекции:

1. этапы разработки ЭС.

2. оценка качества ЭС.

3. 5 уровней развития ЭС.

Ключевые слова:

Идентификация, концептуализация, формализация, реализация,

тестирование, демонстрационный прототип, исследовательский

прототип, коммерческая система.

Разработку ЭС можно считать состоящей из пяти сильно

взаимодействующих и перекрывающихся этапов:

 Идентификация

 Концептуализация

 Формализация

 Реализация

 Тестирование.

На рис.25 представлена схема построения ЭС.

Рис.25. Этапы разработки ЭС

ЭС

Идентификация тестирование

реализация

Требования

Переформулировка

Концептуализация завершение

усовершенствование

переконструирование выполнение

понятия формализация

Рассмотрим эти этапы.

1. На этапе ИДЕНТИФИКАЦИИ разработчик и эксперт

определяют существенные особенности задачи. К ним

относятся тип задачи, широта постановки, а также требуемые

ресурсы (сроки и компьютерные мощности), цели и задачи

создания ЭС (повысить компетентности или тиражировать

редко встречающие способности и навыки). Из всех этих

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

широты постановки, т.е. ограничение области исследования.

2. На этапе КОНЦЕПТУАЛИЗАЦИИ инженер по знаниям и

эксперт решают, какие понятия, отношения и механизмы

управления используются для описание решения задачи в

избранной области. Исследуются также подзадачи, стратегии и

ограничения, связанные с деятельностью по решению задач. На

этой стадии обычно требуется рассмотреть вопрос о степени

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

наиболее абстрактный уровень детализации, (крупные гранулы)

который обеспечивает четкое выделение ключевых понятий.

После первой реализации ЭС придется детализировать

отдельные гранулы и уточнять понятия.

3. На этапе ФОРМАЛИЗАЦИИ ключевые понятия и отношения

между ними формируются в рамках выбранной схемы и языка

построения ЭС. Поэтому инженер по знаниям должен иметь

представление о том, какие языки подходят для

рассматриваемой задачи. Например, если задачу можно решить

с помощью подхода, ориентированного на правила, то он

может выбрать ROSIE в качестве языка описания системы и

собирать знания в форме правил ЕСЛИ-ТО. Если подходит

фреймовая модель представления знаний, то можно выбрать

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

большой сети.

4. На этапе РЕАЛИЗАЦИИ разработчик превращает

формализованное знание в работающую компьютерную

программу. Написание программы требует содержания, формы,

согласования. Содержание

берется из предметных знаний, сделанных явными в ходе

формализации, т.е. структур данных, правил вывода и

стратегий управления, необходимых для решения

задачи.Форма задается языком, выбранным для разработки

системы. Согласование включает в себя комбинирование и

реорганизацию порций знаний с целью устранения неувязки

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

5. ТЕСТИРОВАНИЕ включает оценивание качества работы и

полезности программы-прототипа, если это необходимо. При

таком оценивании могут обнаруживаться ошибки. Например,

”отсутствие нужных понятий”, и тогда необходимо вернуться

на этап идентификации и концептуализации.

При оценке качества работы ЭС необходимо ответить на

следующие вопросы:

1. Получаемые решения признаются экспертами правильными

или нет?

2. Являются ли правила вывода безошибочными,

непротиворечивыми и полными?

3. Позволяет ли стратегия управления рассматривать

обстоятельства в естественном порядке, как предпочитает

эксперт?

4. Адекватно ли объяснения системы описывают, как, почему

были получены те или иные заключения?

5. Охватывают ли тестовые задачи всю запланированную

область компетентности системы, покрывая классические

случаи и нащупывая границы трудных случаев?

При оценке полезности возникает другой набор вопросов:

1. Помогает ли решение задачи пользователю существенным

образом?

2. Являются ли заключения системы разумно

организованными?

3. Удовлетворяет ли пользователя скорость работы системы?

4. Является ли интерфейс дружественным?

ЭС должна быть опробована, усовершенствована и

протестирована в лабораторных условиях, прежде чем будет

передана в опытную эксплуатацию.

ЭС развиваются как и их средства построения от

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

разработки ЭС (таблица 3.).

1. Демонстрационный прототип решает некоторую основную

часть задачи. Создается для двух целей: 1. Убедить

финансирующую организацию, что данная ЭС может

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

Проверить концепции постановки задачи, и представление

данных из предметной области. Обычно содержит 50-100

правил, работает на 2-3 пробных случаях и требует до 3

месяцев на его разработку.

2. Большинство ЭС доведены до уровня исследовательского

прототипа. Это программы среднего размера, способные

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

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

границы ее разрешения. Могут возникать и ошибки из-за

недостаточного тестирования. Типичный исследовательский

прототип содержит 200-500 правил, хорошо работает на

большом числе пробных случаев, требует на разработку 1-2

года.

Таблица 3.

Уровень разработки Характеристика

1. Демонстрационный

прототип

Система решает часть

поставленной задачи

2. Исследовательский прототип Демонстрирует результаты по

всей проблеме в целом, но

может быть ненадежна из-за

неполного тестирования

3. Опытная эксплуатация Система проявляет высокое

качество работы при обширном

тестировании в реальных

условиях

4. Промышленный прототип Система имеет высокое

качество, надежность,

быстродействие в реальных

условиях эксплуатации

5. Коммерческая система Промышленный прототип,

используемый на коммерческой

основе

3. Уровень опытной эксплуатации. Это достаточно большие

программы, которые не один раз пересматривались. Они умеренно

надежны, имеют удобный и дружественный интерфейс и

ориентированны на нужды конкретного пользователя. Содержат

500-1000 правил, опробованы на всех тестах и требуют на

разработку 2-3 года.

4. Промышленный прототип – эти системы представляют большие

программы, подвергнутые интенсивной проверке в условиях

опытной эксплуатации, переписанные на более высоком

эффективном языке с целью увеличения скорости работы и

уменьшения необходимой машинной памяти. Типичный

промышленный тип – это программы, охватывающие 500-1500

правил, обеспечивающих точное, быстрое и эффективное решение.

Требует на разработку 2-4 года.

5. Коммерческая система – это немногие ЭС, эксплуатируемые на

регулярной коммерческой основе. Такие системы содержат свыше

3000 правил, частота правильных заключений 90-95% и требует на

разработку 4-6 лет.

Контрольные вопросы:

1. На каком этапе происходит выбор продукционной модели

представления знаний ЭС?

2. Главная цель этапа идентификации задачи.

3. Как оценивается качество работы ЭС?

4. Как оценивается полезность, разработанной ЭС?

5. Для чего предназначен демонстрационный прототип ЭС?

6. В чем особенности промышленного прототипа ЭС?

Лекция 11 ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ПОСТРОЕНИЯ ЭС.

План лекции:

1. Основные инструментальные средства.

2. Вспомогательные инструментальные средства.

3. Методы разработки ЭС.

Ключевые слова:

Метод прямой разработки, основные ИС, вспомогательные ИС,

языки инженерии знаний, скелетные языки, универсальные языки

разработки ЭС.

Разработка любой системы управления БЗ или ЭС –

большая и сложная работа, требующая привлечение

квалифицированных специалистов-экспертов и разработчиков-

программистов. Естественно, что для создания подобных систем

разрабатываются различные инструментальные средства. По

инструментальным возможностям эти средства можно разделить

на основные и вспомогательные. Основные средства образуют

языки, предназначенные для описания компонентов ЭС и системы

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

средства предназначены для упрощения отдельных этапов

разработки или тестирования тех иных компонентов ЭС.

Например, для наполнения и модификации БЗ, содержащей факты

и правила.

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

построения ЭС очень широк и существует несколько

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

от методов построения ЭС.

ОСНОВНЫЕ ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА.

Языки программирования, применяемые для работы в области

ЭС, – это, как правило, проблемно-ориентированные языки как

PASCAL, FORTRAN или языки обработки текстов – LISP и

PROLOG. Проблемно-ориентированные языки разработаны для

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

статистических исследованиях. Языки обработки текстов

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

Например, LISP имеет механизмы для манипулирования

символами в форме списковых структур. LISP и PROLOG

неуклонно завоевывают популярность. Популярность языков

основывается на нескольких их свойствах: легком

манипулировании символами, автоматическим управлением

памятью, развитом редактировании и средств отладки, едином

подходе в представлении программ.

Лисп существует в двух вариантах: Интерлисп, Мэклисп (имеют

различные средства поддержки).

Языки программирования подобные Лиспу предоставляют

гибкость разработчику ЭС, но никак не подсказывают ему, как

представлять знания или как построить механизм доступа к базе

знаний.

Языки инженерии знаний обладают меньшей гибкостью,

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

управления с помощью механизма выводов.

Средства Пакеты прерываний Меню

Доступ к

трассировке ОС

Средства отладки Средства

ввода- вывода

Автоматическое

тестирование Поддерживающие

Приобретение

Автоматическое средства знаний

документирование

Редакторы базы синтаксический

средства объяснения

знаний контроль

проверка извлечение знаний

непротиворечивости

Рис.26. Компоненты поддерживающей среды.

Языки инженерии можно разделить на скелетные и

универсальные.

Скелетный язык – это ‘раздетые’ ЭС без специальных

предметных знаний.

Скелетные системы обеспечивают структуризацию знаний и

готовые механизмы выводов. Но им не хватает общности и

гибкости. Они приложены только к узкому классу проблем и

сильно ограничивают возможности разработчика ЭС.

Универсальные языки могут быть применены к проблемам

различного типа в различных прикладных областях. Они

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

и доступом к ним, чем скелетные системы, но их труднее

использовать.

Вспомогательные средства построения ЭС: состоят из

программ, оказывающих помощь в приобретении знаний у

эксперта и представление их, а также программ, которые помогают

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

делятся на две группы:

 средства проектирования систем;

 средства приобретения знаний.

Системы AGE, TIMM, EXPERTEASE – это примеры средств

проектирования системы. TEIRESIAS ROGET – это пример

средства приобретения знаний.

Система TEIRESIAS оказывает помощь в приобретении знаний

от эксперта в БЗ.

Система приобретает новые правила из предметной области

через диалог с экспертом.

Система AGE состоит из набора компонент, которые могут быть

смонтированы, чтобы образовалась часть ЭС.

Вспомогательные средства включают также средства поддержки

– вспомогательные программы, которые прилагаются к средствам

построения ЭС, чтобы упростить его.

На рис. 26 приведены компоненты поддерживающей среды,

которая также относится к вспомогательным средствам.

Рассмотрим подробнее средства объяснения. Некоторые

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

ENYCIN. В других нет этого механизма рассуждения, а надо его

использовать. Существует несколько типов механизма объяснения:

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

 гипотетическое распределение;

 контрафактическое распределение.

При первом случае объясняется, как система достигла

конкретного состояния. Система может описать правило, которое

привело к заключению или часть цепочки правил. Во втором

случае - система объясняет, что получилось, если бы конкретный

факт или правило были другими. В третьем случае система

объясняет, почему ожидаемое заключение не получилось.

МЕТОДЫ РАЗРАБОТКИ.

В процессе разработки прикладной экспертной системы

могут использоваться 3 метода:

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

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

по этому методу являются DENDRAL, MYCIN и др. На

создание таких систем уходит много времени.

B. Основан на языке представления знаний или на языке

разработки ЭС. Этот метод отличается простотой,

позволяющей при наличии оболочки, затратить на разработку

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

очередь для ЭС на основе продукционной модели.

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

знаний фреймового типа. Фреймовая модель обладает большой

гибкостью и в ней возможно комбинировать декларативные и

процедурные знания в одном фрейме.

При использовании фреймовой системы прежде всего

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

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