Лекции - Искусственный интеллект

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

присоединенной процедуры САLС, при этом вызывается

процедура МЕАN, расположенная в фрейме ВВ.

Имя

слота

Тип Значени

Имя

слота

Тип Значени

ISA Frame A ISA Frame B

Объект

Integer 125 X Integer 10, 20,

Объект

Real 8.5 Y Real 8.0, 12.6

…… …… ……

MSG

Ответ

…… …… ……

Расчет LISP CALC Среднее LISP MEAN

Рис. 6.6. Обмен информацией между фреймами

Допустим, что процедура САLС(result) выполняет расчет,

в процессе которого происходит обращение к фрейму ВВ с

использованием команды MSG, реализующей передачу

сообщения в другой фрейм.

LISPproc САLС(result)

………..

MSG (cреднее, ВВ, X)

…………

end.

Команда MSG имеет три параметра: 1 — имя слота, к

которому происходит обращение (в данном случае значением

слота Среднее является присоединенная процедура МЕАN): 2

— имя фрейма, в котором содержится необходимая информация

(ВВ); 3 — имя слота-параметра, в котором находятся данные

для расчета (X). Таким образом, запуск процедуры САLС

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

143

во фрейм ВВ на запуск процедуры МЕАN, которая найдет

среднее арифметическое чисел, записанных в слоте X;

вычисленное значение будет записано в переменную result и

передано в САLС как ответ на сообщение MSG.

Итак, в интеллектуальных системах с фреймовым

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

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

присоединенные процедуры и демоны одновременно являются

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

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

фреймовой системе.

Возможность организации выводов любого типа является

существенным преимуществом фреймовых систем по

сравнению с продукционными и логическими. Не менее

важным достоинством является большее сходство этой модели

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

Вместе с тем практическая реализация фреймовых систем

сопряжена со значительной трудоемкостью как на этапе

проектирования, так и при реализации. Поэтому стоимость

промышленных экспертных систем фреймового типа на

порядок превосходит стоимость продукционных систем.

144

111

121

122

123

121

MSG MSG MSG

MSG

Value

Рис. 6.7. Средства управления выводом в интеллектуальной

системе фреймового типа

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

1. Докажите предложенную тавтологию семантическим

(синтаксическим) методом.

2. Расскажите о теоремах логики и их использовании в

ИИС. Приведите примеры.

3. Опишите возможности применения в логическом

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

тавтологий с эквивалентностями.

4. Опишите стратегию доказательства с введением

допущения. Приведите пример.

5. Рассмотрите пример доказательства путем приведения к

противоречию.

6. Расскажите о стратегии доказательства методом

резолюции. Приведите пример.

7. Опишите функционирование механизма вывода

продукционной ЭС и охарактеризуйте его составляющие:

компоненту вывода и управляющую компоненту.

8. Сформулируйте собственные примеры прямого и

обратного вывода в ЭС продукционного типа.

9. Приведите пример представления знаний в виде И-

ИЛИ-графа.

10. Опишите и представьте в графическом виде стратегии

поиска решений: в глубину, ширину, разбиением на подзадачи,

на основе --алгоритма.

145

11. Расскажите о способах организации логического

вывода в интеллектуальных системах с фреймовым

представлением знаний.

12. Разработайте программную реализацию

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

знаний и механизмом вывода на базе правила Modus Ponendo

Ponens.

7. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ЗНАНИЙ

Многие созданные к настоящему времени экспертные

системы ориентированы на решение конкретных задач, имеют

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

самых разнообразных инструментальных средств. Однако к

настоящему времени уже выделены основные принципы их

построения, создаются технологии их построения.

Каждая конкретная экспертная система является человеко-

машинной системой. В ее разработке необходимо участите

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

знаниям, конструкторов.

Эксперты − это специалисты по данной ПО, знания

которых требуется ввести в базу знаний экспертной системы,

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

выполнении своих непосредственных функций.

Эксперт-профессионал обладает знаниями двух типов. К

первому типу относятся та называемые вербализуемые знания.

Вербализуемые знания могут быть выражены словесно или

письменно, с использованием различных графиков, схем,

обобщены в виде статей, монографий, научных отчетов. Таким

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

специалистов, не входящих в непосредственный контакт с

носителем знаний. Этот тип знаний обычно без особых

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

системы. Второй тип знаний – невербализуемые знания. Они

отражают тот профессиональный опыт специалиста, который он

накопил в процессе своей профессиональной деятельности и

146

которые желают его эксперты. Зачастую эти знания

представляют наибольший интерес для проектируемой

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

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

подсознательно. Получение таких знаний и является в

настоящее время одной из центральных задач для специалистов

по искусственному интеллекту. Разрабатываются специальные

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

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

для практических приложений, относятся приемы

профессионала, которыми он пользуется при структуризации

своей ПО и решении профессиональных задач, его

предпочтения при принятии решений и т.п.

Конструкторы – это группа специалистов в области

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

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

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

экспертная система.

Инженер по знаниям выполняет сбор и формализацию

экспертных знаний, выбор конфигурации системы и загрузку в

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

звена между экспертами и конструкторами экспертной системы.

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

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

функции инженера по задания входит задача по формулировке

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

Можно указать следующие основные технологические

этапы разработки экспертной системы:

1. Этап взаимодействия инженеров по знания и

экспертов. На этом этапе формируется модель ПО. Модель

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

однако в ней должны быть специфицированы:

все основные понятия ПО;

атрибуты, их описывающие;

отношения, существующие между ними;

147

множество правил, описывающих специфические знания в

анализируемой ПО (например, в форме продукции).

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

знания с экспертами является выявление множества

неформальных правил, которыми эксперт пользуется в своей

профессиональной деятельности. В настоящее время

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

инженера по знаниям на этом этапе. Они позволяют

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

целью выявления вербализованных и невербализованных

знаний.

2. Этап взаимодействия инженера по знаниям и

конструкторов. На этом этапе выполняется настройка

инструментального пакета (так называемой оболочки

экспертной системы) на задачи ПО, выполняется загрузка

собранных знаний в систему. С этой целью. Выполняются

следующие действия:

на входном языке системы описываются понятия ПО (их

атрибуты, отношения, существующие между ними), а также

(если необходимо) операционная семантика отношений в виде

процедур;

реализация соответствующих действий;

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

продукций;

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

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

создается макет экспертной системы и выполняется его

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

3. Этап взаимодействия инженеров по знаниям,

экспертов и конструкторов. На этом этапе создается

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

4. Этап сопровождения и модификации экспертной

системы. Необходимость сопровождения и модификации

экспертной системы при ее функционировании вызвано тем, что

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

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

148

временем их достоверность, может изменяться со временем

операционная семантика отношений и т.п.

От стадии макетирования до получения промышленного

образца экспертная система проходит через следующие стадии:

1. Демонстрационный прототип (база знаний

содержит 50...100 правил). Система решает часть задач,

демонстрируя жизнеспособность подхода.

2. Исследовательский прототип (200...500 правил на

базе знаний). Система решает все задачи, но неустойчива в

работе.

3. Действующий прототип (база знаний содержит

500...1000 правил). Система надежно решает все задачи на

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

времени и памяти.

4. Промышленный образец (в базе знаний имеется

500...1500 и даже до 3000 правил). Система обеспечивает

высокое качество решений при минимизации требуемого

времени памяти.

8. МЕТОДЫ ПРОЕКТИРОВАНИЯ БАЗ ЗНАНИЙ

В настоящее время основным «узким местом» при

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

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

Знания о ПО можно взять из разных источников (научные

отчеты, монографии, статьи, базы данных, опытные данные и т.

п., а также личный опыт эксперта-профессионала). Работа по

сбору и обработке знаний выполняется специалистом —

инженером по знаниям. Обычно большую часть

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

результате взаимодействия с экспертом. К настоящему времени

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

ориентированных на получение информации от экспертов.

Рассмотрим их.

149

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

наблюдательный и интуитивный подходы.

При наблюдательном подходе следят за работой эксперта,

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

эксперта при решении задачи. За наблюдением следует этап

уточнения. На этапе уточнения инженер по знаниям совместно с

экспертом анализируют запись сеанса работы эксперта,

выполненную наблюдателем. Такой подход еще называют

«анализом протоколов».

При интуитивном подходе эксперт выступает как раз-

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

вариант — инженер по знаниям изучает литературу и другие ис-

точники информации, разрабатывает представление знаний о

ПО и затем проверяет их достоверность с экспертами.

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

сочетая их методом интервью — беседы с экспертами.

Обсуждение задач. Инженер по знаниям подготавливает

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

обсуждает их с экспертом, стараясь определить, как

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

понятиями и гипотезами по ПО он руководствуется в своей

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

противоречивыми данными по той или иной задаче.

Описание задачи. Эксперт подготавливает описание

типичных задач по ПО. Это метод очень хорошо работает на

задачах диагностического типа.

Анализ задач. Инженер по знаниям подготавливает

несколько задач, близких к реальным, и просит эксперта решить

их цель — выявить стратегию, которой пользуется эксперт при

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

работающие стремятся выделить как можно больше

промежуточных шагов решения, проанализировать их,

преследуя основную цель.

Оценивание системы. Эксперт анализирует и критически

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

системы. Анализирует стратегии выбора правил системой при

150

решении задач, рассматривает обоснованность их применения,

постоянно сравнивая их со своими методами решения задач.

Проверка системы. Инженер по знаниям представляет

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

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

- выявление элементов, вызывающих разногласия.

Кроме названных существует еще целый ряд практических

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

данном этапе.

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

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

первого варианта системы. Для этого выполняется следующая

спецификация выявленных знаний:

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

2. По каждой задаче специфицировать входные данные и

что требуется получить в результате решения, стратегии

решения, гипотезы, которые используются в процессе решения.

Специфицировать объекты (события) ПО, отношения и

атрибуты.

Специфицировать причинно-следственные, родовидовые

отношения, отношения типа «часть — целое».

По каждой задаче классифицировать знания на необходи-

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

полученного решения.

Отметим, что процесс концептуализации знаний —

итерационный процесс.

Далее выполняется процесс формализации

концептуальных знаний, в результате которого получают

формальное описание базы знаний. С этой целью инженер по

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

представления знаний, соответствующую рассматриваемой

проблеме, и оболочку экспертной системы, поддерживающую

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

концептуальных знаний.

Однако полученная на этом этапе база знаний не

гарантирует работоспособность системы (первый вариант

151

является макетом будущей системы), поскольку обязательно

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

либо правилами и стратегией управления процессом получения

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

несоответствия должны быть устранены.

На стадии отладки и тестирования полученного прототипа

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

на разнородных примерах. Оценить работу экспертной системы

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

случаев не существует формального способа доказательства

полученного системой решения. Кроме того, зачастую

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

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

системы необходимо учитывать интересы будущих

пользователей и включать их как экспертов в процессе

проектирования системы. Далее, с ростом объема базы знаний

(когда число правил достигает нескольких сотен) добавление

новых правил или исправление существующих зачастую

приводит к появлению новых ошибок, количество которых

сравнимо с устраняемыми ошибками. Отладка и тестирование

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

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

важного изменения в базе знаний ив стратегии управления

процессом решения задач. Помимо отладки на контрольном

наборе задач используется прием регистрации при

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

конкретным заключениям. Затем выполняется анализ

результатов регистрации. Неиспользуемые правила указывают

либо на неверные предпосылки в правилах, либо на ошибки в

используемых стратегиях управления процессом решения задач.

В процессе проектирования и создания экспертной

системы в нее постоянно вносятся различные изменения с

целью ее отладки и усовершенствования. Это итерационный

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

промышленная версия экспертной системы.

152