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

Содержание
Введение
Глава 1 Экспертные системы и их особенности
1.1 Характеристики и функциональность экспертных систем
1.2 Описание архитектурных особенностей экспертной системы
1.3 Классификация экспертных систем
Глава 2 Технология разработки экспертных систем
2.1 Описание этапности проводимых работ по разработке экспертной системы
2.2 Общая характеристика инструментальных средств для построения экспертных систем
2.3 Трудности при разработке экспертных систем
Заключение
Список использованной литературы
Приложение

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

управление системой календарного планирования оказывает система Project Assistant.
Поддержка принятия решений - это совокупность процедур, обеспечивающая принимающего решения индивидуума необходимой информацией и рекомендациями, облегчающими процесс принятия решения. Эти экспертные системы помогают специалистам выбрать и/или сформировать нужную альтернативу среди множества выборов при принятии ответственных решений.
Например, для выбора стратегии выхода фирмы из кризисной ситуации используется система CRYSIS.
В общем случае все системы, основанные на знаниях, можно подразделить на системы, решающие задачи анализа и на системы, решающие задачи син­теза.
Основное отличие задач анализа от задач синтеза заключается в том, что если в задачах анализа множество решений может быть перечисленои включено в систему, то в задачах синтеза множество решений потенциально не ограничено и строится из решений компонентов или подпроблем.
Зада­чами анализа являются: интерпретация данных, диагностика, поддержка принятия решения; к задачам синтеза относятся проектирование, планиро­вание, управление. Комбинированные: обучение, мониторинг, прогнозирование.
Классификация экспертных систем по связи с реальным временем
Статические экспертные системы разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени. Они стабильны.
Пример: диагностика неисправностей в автомобиле.
Квазидинамические экспертные системы интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени.
Пример: микробиологические ЭС, в которых снимаются лабораторные измерения с технологического процесса один раз в 4—5 часов (производство лизина, например) и анализируется динамика полученных показателей по отношению к предыдущему измерению.
Динамические экспертные системы работают в сопряжении с датчиками объектов в режиме реального времени с непрерывной интерпретацией поступающих в систему данных.
Пример: управление гибкими производственными комплексами, мониторинг в реанимационных палатах.
Классификация экспертных систем по типу ЭВМ
На сегодняшний день существуют:
экспертные системы для уникальных стратегически важных задач на суперЭВМ (Эльбрус, CRAY, CONVEX и др.);
экспертные системы на символьных процессорах и рабочих станциях (SUN, Silicon Graph ­ ics, APOLLO);
экспертные системы на персональных компьютерах (IBM -совместимые, Macintosh).
Классификация экспертных систем по степени интеграции с другими программами 
Автономные экспертные системы работают непосредственно в режиме консультаций с пользователем для специфически "экспертных" задач, для решения которых не требуется привлекать традиционные методы обработки данных (расчеты, моделирование и т. д.).
Гибридные экспертные системы представляют программный комплекс, агрегирующий стандартные пакеты прикладных программ (например, математическую статистику, линейное программирование или системы управления базами данных) и средства манипулирования знаниями. Это может быть интеллектуальная надстройка над пакетами прикладных программ или интегрированная среда для решения сложной задачи с элементами экспертных знаний. Несмотря на внешнюю привлекательность гибридного подхода, следует отметить, что разработка таких систем являет собой задачу на порядок более сложную, чем разработка автономной экспертной системы.
Глава 2 Технология разработки экспертных систем
2.1 Описание этапности проводимых работ по разработке экспертной системы
Процесс разработки экспертной системы, опираясь на традиционные, практически для любой предметной области можно разделить на шесть более или менее независимых этапов (рис. 3) [1, 2, 4].
Рис. 3 Этапы разработки экспертной системы
Последовательность этапов дана только с целью получения общего представления о процессе создания идеального проекта. Конечно, последовательность эта не вполне фиксированная. В действительности каждый последующий этап разработки может принести новые идеи, которые могут повлиять на предыдущие решения и даже привести к их переработке. Именно поэтому многие специалисты по информатике весьма критично относятся к методологии экспертных систем. Они считают, что расходы на разработку таких систем очень большие, время разработки слишком велико, а полученные в результате программы накладывают тяжелое бремя на вычислительные ресурсы.
1 этап - Выбор подходящей проблемы
Этот этап определяет деятельность, предшествующую решению начать разрабатывать конкретную экспертную систему и включает в себя:
определение проблемной области и задачи;
нахождение эксперта, желающего сотрудничать при решении проблемы, и назначение коллектива разработчиков;
определение предварительного подхода к решению проблемы;
анализ расходов и прибылей от разработки;
подготовку подробного плана разработки.
2 этап - Разработка прототипной системы
Прототипная система является усеченной версией экспертной системы, спроектированной для проверки правильности кодирования фактов, связей и стратегий рассуждения эксперта. Она также дает возможность инженеру по знаниям привлечь эксперта к активному участию в процессе разработки экспертной системы, и, следовательно, к принятию им обязательства приложить все усилия к созданию системы в полном объеме. Объем прототипа - несколько десятков правил, фреймов или примеров.
Существует шесть стадий разработки прототипа и минимальный коллектив разработчиков, занятых на каждой из стадий.
1) Идентификация проблемы - знакомство и обучение членов коллектива разработчиков, а также создание неформальной формулировки проблемы.
Уточняется задача, планируется ход разработки прототипа экспертной системы, определяются:
необходимые ресурсы (время, люди, ЭВМ и т. д.);
источники знаний (книги, дополнительные эксперты, методики);
имеющиеся аналогичные экспертные системы;
цели (распространение опыта, автоматизация рутинных действий);
классы решаемых задач и т. д.
Средняя продолжительность 1-2 недели.
2) Извлечение знаний - получение инженером по знаниям наиболее полного из возможных представлений о предметной области и способах принятия решения в ней.
На этой стадии происходит перенос компетентности от эксперта к инженеру по знаниям, с использованием различных методов (анализ текстов, диалоги, экспертные игры, лекции, дискуссии, интервью, наблюдение и др.).
Средняя продолжительность 1-3 месяца.
3) Структурирование (или концептуализация) знаний - разработка неформального описания знаний о предметной области в виде графа, таблицы, диаграммы или текста, которое отражает основные концепции и взаимосвязи между понятиями предметной области.
Выявляется структура полученных знаний о предметной области, то есть определяются:
терминология;
список основных понятий и их атрибутов;
отношения между понятиями;
структура входной и выходной информации;
стратегия принятия решений;
ограничения стратегий
и т. д.
Средняя продолжительность этапа 2-4 недели.
4) Формализация - разработка базы знаний на языке представления знаний, который, с одной стороны, соответствует структуре поля знаний, а с другой - позволяет реализовать прототип системы на следующей стадии программной реализации.
Строится формализованное представление концепций предметной области на основе выбранного языка представления знаний (ЯПЗ). Традиционно на этом этапе используются:
логические методы (исчисления предикатов 1-го порядка и др.);
продукционные модели (с прямым и обратным выводом);
семантические сети;
фреймы;
объектно-ориентированные языки, основанные на иерархии классов, объектов.
Средняя продолжительность 1-2 месяца.
5) Реализация - разработка программного комплекса, который демонстрирует жизнеспособность подхода в целом. Чаще всего первый прототип отбрасывается на этапе реализации действующей экспертной системы. Создается прототип экспертной системы, включающий базу знаний и остальные блоки.
Средняя продолжительность 1-2 месяца.
6) Тестирование - выявление ошибок в подходе и реализации прототипа и выработка рекомендаций по доводке системы до-промышленного варианта.
Оценивается и проверяется работа программ прототипа с целью приведения в соответствие с реальными запросами пользователей.
Прототип проверяется на:
удобство и адекватность интерфейсов ввода/вывода (характер вопросов в диалоге, связность выводимого текста результата и др.);
эффективность стратегии управления (порядок перебора, использование нечеткого вывода и др.);
качество проверочных примеров;
корректность базы знаний (полнота и непротиворечивость правил).
Средняя продолжительность 1-2 недели.
3 этап - Развитие до промышленной экспертной системы
Чаще всего реализуется плавный переход от демонстрационного прототипа к промышленной системе, при этом, если программный инструментарий был выбран удачно, не обязательно даже переписывать окончательный вариант другими программными средствами.
Основная работа на данном этапе заключается в существенном расширении базы знаний, то есть в добавлении большого числа дополнительных правил, фреймов, узлов семантической сети или других элементов знаний. Эти элементы знаний обычно увеличивают глубину системы, обеспечивая большее число правил для трудно уловимых аспектов отдельных случаев. В то же время эксперт и инженер по знаниям могут увеличить базу знаний системы, включая правила, управляющие дополнительными подзадачами или дополнительными аспектами экспертной задачи (метазнания).
На этом этапе разработки большинство экспертов узнают достаточно о вводе правил и могут сами вводить в систему новые правила. Таким образом, начинается процесс, во время которого инженер по знаниям передает право собственности и контроля за системой эксперту для уточнения, детальной разработки и обслуживания.
4 этап - Оценка экспертной системы
После завершения этапа разработки промышленной экспертной системы необходимо провести ее тестирование в отношении критериев эффективности.
Оценку можно проводить, исходя из различных критериев, которые сгруппируем следующим образом:
критерии пользователей (понятность и «прозрачность» работы системы, удобство интерфейсов и др.);
критерии приглашенных экспертов (оценка советов-решений, предлагаемых системой, сравнение ее с собственными решениями, оценка подсистемы объяснений и др.);
критерии коллектива разработчиков (эффективность реализации, производительность, время отклика, дизайн, широта охвата предметной области, непротиворечивость БЗ, количество тупиковых ситуаций, когда система не может принять решение, анализ чувствительности программы к незначительным изменениям в представлении знаний, весовых коэффициентах, применяемых в механизмах логического вывода, данных и т. п.).
5 этап - Стыковка экспертной системы
На этом этапе осуществляется стыковка экспертной системы с другими программными средствами в среде, в которой она будет работать, и обучение людей, которых она будет обслуживать. Иногда это означает внесение существенных изменений.
Под стыковкой подразумевается также разработка связей между экспертной системой и средой, в которой она действует.
Стыковка включает обеспечение связи экспертной системы с существующими базами данных и другими системами на предприятии, а также улучшение системных факторов, зависящих от времени, чтобы можно было обеспечить ее более эффективную работу и улучшить характеристики ее технических средств, если система работает в необычной среде (например, связь с измерительными устройствами).
6 этап - Поддержка экспертной системы
При перекодировании системы на язык, подобный Си, повышается ее быстродействие и увеличивается переносимость, однако гибкость при этом уменьшается. Это приемлемо лишь в том случае, если система сохраняет все знания проблемной области и это знание не будет изменяться в ближайшем будущем. Однако если экспертная система создана именно из-за того, что проблемная область изменяется, то необходимо поддерживать систему в ее инструментальной среде разработки.
2.2 Общая характеристика инструментальных средств для построения экспертных систем
При разработке практически всех инструментальных средств за основу принимается методология автоматизации проектирования на базе использования прототипов. По отношению к программному обеспечению термин прототип означает «работающую модель программы, которая функционально эквивалентна подмножеству конечного продукта». Идея состоит в том, чтобы на ранней стадии работы над проектом разработать упрощенную версию конечной программы, которая могла бы послужить доказательством продуктивности основных идей, положенных в основание проекта. Прототип должен быть способен решать какую-либо из нетривиальных задач, характерных для заданной области применения [1]. На основе анализа опыта работы с прототипом разработчики могут уточнить требования к системе в целом и ее Основным функциональным характеристикам. Работоспособность прототипа может послужить очевидным доказательством возможности решения проблем с помощью создаваемой системы еще до того, как на ее разработку будут потрачены значительные средства.
После всестороннего анализа прототип откладывается в сторону и начинается разработка рабочей версии программы, которая должна решать весь комплекс задач, определенных в спецификации проекта. Процесс разработки экспертной системы, как правило, состоит из последовательности отдельных этапов, на которых наращиваются возможности системы, причем каждый из этапов подразделяется на фазы проектирования, реализации, компоновки и тестирования [4]. В результате после каждого этапа наращивания возможностей в распоряжении пользователя имеется система, которая способна справляться с более сложными вариантами проблемы.
Такая методика проектирования несколько отличается от методики разработки программ других видов. При создании большинства программных продуктов чаще используется другая модель процесса - сначала разрабатывается спецификация продукта, затем выполняется планирование, проектирование компонентов, их реализация, компоновка комплекса и тестирование конечного варианта. Тот факт, что при разработке экспертных систем есть возможность сначала построить и всесторонне испытать прототип, позволяет избежать множества переделок в процессе создания рабочей версии системы. Но технология последовательного наращивания функциональных возможностей таит в себе и проблему интеграции новых функций с реализованными в предыдущих вариантах.
Инструментальные средства разработки экспертных систем создавались, в первую очередь, с целью преодоления возникающих при этом сложностей на основе модульного представления знаний [1].
По своему назначению и функциональным возможностям инструментальные программы, применяемые при проектировании экспертных систем, можно разделить на четыре достаточно больших категории.
Оболочки экспертных систем (expert system shells). Системы этого типа создаются, как правило, на основе какой-нибудь экспертной системы, достаточно хорошо зарекомендовавшей себя на практике. При создании оболочки из системы-прототипа удаляются компоненты, слишком специфичные для области ее непосредственного применения, и оставляются те, которые не имеют узкой специализации. Примером может служить система EMYCIN, созданная на основе прошедшей длительную "обкатку" системы MYCIN. В EMYCIN сохранен интерпретатор и все базовые структуры данных - таблицы знаний и связанный с ними механизм индексации [2, 4]. Оболочка дополнена специальным языком, улучшающим читабельность программ, и средствами поддержки библиотеки типовых случаев и заключений, выполненных по ним экспертной системой.