Аналитические приложения

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

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

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

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

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

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

Взаимодействие между экспертами может как стимулировать, так и подавлять их деятельность. Поэтому в разных случаях применяют различные методы экспертизы, отличающиеся характером взаимодействия экспертов друг с другом: анонимные и открытые опросы и анкетирования, совещания, дискуссии, деловые игры, мозговой штурм и т.д. Нередко при работе с экспертами используется метод Дельфи [73].

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

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

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

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

Рис. 12.12. Этапы проектирования экспертной системы

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

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

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

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

Описание приемов извлечения знаний инженерами знаний представлено в таблице 12.2.

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

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

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

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

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

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

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

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

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

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

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

После предварительного определения контуров разрабатываемой экспертной системы инженеры по знаниям совместно с экспертами определяют:

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

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

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

Хорошая концептуальная модель может только уточняться (детализироваться или упрощаться), но не перестраиваться.

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

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

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

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

Рассмотрим классификацию методов представления знаний:

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

Рассмотрим применение аппарата нечеткой логики на примере оценки надежности поставщика, в котором кроме фактора финансового состояния учитывается и фактор формы собственности (рис.12.13).

Рис. 12.13. Применение нечеткой логики

Пусть государственное предприятие не имеет задолженности с уверенностью 60% и предполагается, что его рентабельность удовлетворительна с уверенностью 80%. Фрагмент множества правил имеет следующий вид.

Правило 1: если Задолженность = "нет" и Рентабельность = "удовлетворительна", то Финансовое состояние = "удовлетвори-тельно" cf 100.

Правило 2: если Финансовое состояние = "удовлетворительно", то Надежность = "есть" cf 90.

Правило 3: если Предприятие = "государственное", то Надежность = "есть" cf 50.

Результат выполнения первого правила:

Результат выполнения второго правила:

Результат выполнения третьего правила:

Для динамических моделей важны:

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

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

В целях динамического реагирования на события некоторые продукционные модели используют специальные правила-демоны, которые формулируются следующим образом: "Всякий раз, как происходит некоторое событие, выполнить некоторое действие". Например: всякий раз, как становится известным значение переменной "Поставщик", выполнить набор правил "Финансовый анализ предприятия".

В программном средстве GURU подобное правило будет записано следующим образом:

IF: KNOWN ("Поставщик") = true THEN: CONSULT FIN_AN

Для динамических экспертных систем характерна также обработка времени как самостоятельного атрибута аргументации логического вывода: если в течение дня уровень запаса понизился больше, чем на 50%, то выполнить набор правил "Выбор поставщика для поставки".

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