Глава 2. Математическое описание экспертной системы

2.1. Структура экспертных систем

Экспертная система (статическая) – вычислительная система, использующая знания эксперта и процедуры логического вывода и позволяющая дать объяснения полученным результатам. Синонимом ЭС является термин «система, базирующаяся на знаниях». Знания – совокупность данных и связывающих их правил.

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

Изначально предполагалось, что схема ЭС будет иметь вид, показанный на рис. 1.1. Однако выяснилось, особенно после появления оболочки экспертной системы GURU, что построение «переводчика» с естественного языка на язык компьютера является сложной, вполне самостоятельной проблемой. Появление декларативных логических языков типа ПРОЛОГ (Prolog), а затем – языков, использующих ПРОЛОГ-идеи, позволило упростить задачу «перевода» при условии использования текстовых элементов из заранее составленного естественного языка. При этом структура интеллектуальной системы трансформировалась – исчезли блоки лингвистических и лексических процессоров.

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

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

Такие ЭС могут быть использованы как элементы управляющей части системы управления. Место таких систем в цикле управления показано на рис. 2.2.

Статистическая ЭС без блока «база правил» называется оболочкой ЭС (аналог СУБД). Наиболее известная оболочка GURU. В рамках языка ПРОЛОГ также имеется оболочка ЭС.

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

Статические ЭС не позволяют:

1) учесть, сохранить и провести анализ изменяющихся во времени данных, поступающих от внешних источников;

2) работать с асинхронными процессами;

3) обеспечить механизм рассуждений при ограниченных ресурсах;

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

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

Реализация ЭС в области управления называется интеллектуальной системой управления или ЭС реального времени (ЭСРВ).

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

Время в ЭСРВ присутствует напрямую (рис. 2.3) Их место в цикле управления показано на рис. 2.2.

Фирма Gensym в 1988 году выпустила очень удачный программный продукт под названием G2, получивший в настоящее время очень широкое распространение.

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

Создание даже статических ЭС достаточно дорого: 0,1 – 0,2 млн долларов при трудоемкости от 0,5 до 10 человеко-лет при количестве учитываемых параметров свыше тысячи.

В то же время использование ЭС и ЭСРВ в настоящее время приносит значительный экономический эффект [12].

Фирма American Express сократила на 27 млн долларов свои потери при применении экспертной системы, принимающей решения-советы по кредитованию.

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

Фирма Sira сократила затраты на строительство трубопровода в Австралии на 40 млн долларов, применив управление трубопроводом с помощью экспертной системы, реализованной с помощью оболочки G2. В последнее время наиболее значительная доля промышленных ЭС относится к ЭСРВ (например: G2).

Если в 1988 году доход от продажи ЭС составлял 3 млн долларов, то в 1993 году уже 55 млн долларов.

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

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

2.2. Составляющие теории экспертных систем

Создание ЭС предполагает рассмотрение процесса проектирования. Рассмотрим его для ЭСРВ, поскольку этот процесс для статических ЭС значительно проще. ЭСРВ, как отмечалось, суть разновидность автоматизированной системы управления - АСУ.

В то же время ЭСРВ специфична за счет более сложной структуры и потому для нее более подходит другая градация процесса проектирования [12].

I. Идентификация.

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

III. Формализация.

IY. Выполнение (реализация).

Y. Отладка и тестирование.

YI. Опытная эксплуатация.

Рассмотрим перечисленные этапы более подробно.

I. Идентификация. Цель этапа – определение цели проектирования – построение базы знаний (БЗ). На данном этапе можно выделить такие работы.

А. Формирование целей проектирования.

Б. Формирование коллектива разработчиков.

В. Определение ресурсов для разработки.

Г. Идентификация проблемы.

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

Цель работы спроектированной системы – выработка решений-советов, анализ и учет последствий принимаемых решений.

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

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

Б. На этом этапе участвует несколько экспертов (руководителей, конечных пользователей) в роли учителей и инженер по знаниям – в качестве ученика, осваивающего словесную модель.

В. Следует учитывать ограничения в процессе проектирования, к которым относятся:

а) размеры финансирования работ;

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

в) источники знаний;

г) вычислительные средства.

Г. Собственно идентификация предполагает получение ответов на следующие вопросы.

1. Какой класс задач решает система.

2. Как эти задачи могут быть определены.

3. Каковы основные понятия в предметной области.

4. Каковы трудности в решении выделенного класса задач.

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

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

1) долговременная работа с экспертами;

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

3) анализ начальных и полученных знаний.

В качестве методов извлечения можно использовать:

1) опрос эксперта по общему вопроснику с наводящими вопросами;

2) структуризованный опрос;

3) самонаблюдение с размышлением эксперта вслух;

4) самоотчет эксперта при выполнении работы;

5) критический обзор извлеченных знаний с целью уменьшения грубых ошибок и формирования метазнаний.

Детально процесс извлечения знаний описан в работе [8].

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

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

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

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

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

Определяют выходные, входные координаты (данные) и связывающие их алгоритмы.

Алгоритмами дискретной составляющей является система правил.

Чаще всего для описания знаний дискретной составляющей используется аппарат продукций (системы правил “если …, то …”).

Саму систему правил (дискретная составляющая описания управляющей части системы) выявляют в процессе беседы инженера по знаниям с экспертом - конечным пользователем по схеме “Ваше подразделение не выполнило план с начала месяца и за прошедший день – Ваши действия?”

Как правило, формулировка ответов будет иметь вид “если недостаточно такого-то ресурса, то действие таково”.

Целесообразно составить протокол рассуждений и действий эксперта.

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

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

III. Формализация. Цель этапа – переход от вербального (словесного) описания процессов в системе к их описанию на некотором формальном языке.

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

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

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

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

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

Одновременно оценивается достоверность исходных данных и правил. Для этих целей можно использовать аппарат факторов уверенности или нечетких переменных [17].

Здесь могут решаться следующие проблемы.

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

2. Построение модели настройки на конкретного КП и анализ его предпочтений.

3. Сопоставление предпочтениям ЛПР критериев оптимальности.

IY. Выполнение (реализация). Цель этапа – создание прототипа БЗ. На нем проверяются основные технические решения, при этом могут не учитываться сложные причинно-временные соотношения, неточность данных. Проводится корректировка правил дополнительные детали в которые “добавляются” разработчиком после отладки и тестирования системы, учета замечаний пользователя.

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

Y. Отладка и тестирование. На этом этапе система реализуется в полном объеме.

Тестирование в ЭСРВ понимается в широком смысле, предполагая тестирование:

1) выявленных алгоритмов до их реализации;

2) алгоритмов в форме реализованных на компьютере программ.

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

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

Для упрощения тестирования отдельных модулей полезна их автономная отладка в виде компонент или шаблонов.

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

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

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

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

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

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

В ЭСРВ выделяют тренажерное тестирование, пилотное сопровождение и опытную эксплуатацию.

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

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

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

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

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

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

Использование ЭС. Использование (рис. 2.4) предполагает; введение запроса; получение ответа системы; получение объяснения.

Формы запроса определяются интерфейсом пользователя (команды, системы команд, меню, естественный язык).

Форма ответа определяется алгоритмом, сформированным для работы ЭС и заложенным в процессе ее проектирования.

Объяснения могут иметь различную форму: КАК получено решение (на основе какаой системы правил), КАК звучит правило с определенным номером, в КАКИХ правилах используется тот или иной параметр, ПОЧЕМУ компьютер запрашивает данные для уточнения запроса.

Более подробно процесс объяснения описан при рассмотрении языка ПРОЛОГ и оболочки GURU.

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

Работа ЭС. В выводе результатов и объяснений основную роль играют блоки БД, база правил, МЛВ.

В общем случае Работа этих блоков в части вывода результатов Y может быть представлена в виде

Y = <X, P, B, R>, (2.1)

где X – множество базовых элементов (данных, называемы в теории экспертных систем и фактами); P – правила с условиями их применения; B – множество аксиом построения синтаксически правильных совокупностей; R – множество правил вывода. Результат Y в теории экспертных систем называют целью.

Совокупность <X, P> образует аппарат описания знаний в блоках БД и базе правил, совокупность <B, R> - закономерности вывода в блоке МЛВ. Сочетание элементов X и P имеют свою специфику, поскольку базы данных имеют свою структуру. Это сочетание более подробно рассмотрено позднее при обсуждении многоагентных систем (МАС). Пока предполагаем, что данные имеют простейший бесструктурный вид и сочетание A и P выполнимо.

Сложнее обстоит дело с сочетанием <X, P> и <B, R>, поскольку методы описания знаний и логического вывода первоначально развивались автономно. В связи с этим одной из задач экспертных систем является определение такого набора методов описания блоков, которые математически интегрировались бы в общую систему.

К такому интегральному описанию предъявляются следующие требования:

1) наглядность описания;

2) простота математического описания;

3) однозначность описания;

4) эффективность методов;

5) возможность интеграции методов;

6) возможность формирования объяснений;

7) описание соотношений множества и подмножеств.

Объяснение O в общем виде может быть описано

O = <P_i, i = 1, N>, (2.2)

где P_i - правила, участвовавшие при выводе данного результата. Они (рис. 2.5) запоминаются в процессе вывода (путь вывода помечен жирными линиями).

В рамках теории ЭС должны быть решены проблемы.