Структура и этапы разработки экспертных систем

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

Функциональные возможности ЭС определяются двумя ее главными системными частями: средой развития и средой рекомендаций (рис. 2). Среда развития используется разработчиком ЭС для построения компонентов и размещения знаний в базе знаний (БЗ). Среда рекомендаций используется пользователями (неэкспертами) для получения экспертных знаний и советов.

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

• • подсистема извлечения знаний;
• • база знаний;
• • механизм вывода;
• • пользовательский интерфейс;
• • рабочая область;
• • подсистема объяснения;
• • подсистема верификации знаний.

Обычно большинство ЭС не содержат подсистему верификации знаний.

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

Среда рекомендации

Среда развития

Рисунок 2 - Структура экспертной системы и ее окружение

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

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

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

Механизм вывода имеет два главных элемента:

• • интерпретатор, призванный выполнять выбранные позиции агенды, используя соответствующие правила БЗ;
• • планировщик, поддерживающий управление агендой. Он оценивает результаты используемых правил вывода в свете их приоритетов или других критериев в агенде.

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

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

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

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

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

Этапы создания экспертных систем

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

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

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

В ходе работ по созданию ЭС сложилась определенная технология их разработки, включающая шесть следующих этапов (рис. 3):

• 1. Идентификация;
• 2. Концептуализация;
• 3. Формализация;
• 4. Выполнение;
• 5. Опытная эксплуатация;
• 6. Тестирование.

Рисунок 3 — Технология разработки экспертных систем

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

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

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

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

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

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

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

Обычно объектное знание представляется графически средствами ER-моделей (модель «Сущность - Связь»),

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

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

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

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

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

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

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

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

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