При идентификации
целей важно отличать цели, ради
которых создается ЭС, от задач,
которые она должна решать. Примерами
возможных целей являются: формализация
неформальных знаний экспертов;
улучшение качества решений, принимаемых
экспертом; автоматизация рутинных
аспектов работы эксперта (пользователя);
тиражирование знаний эксперта.
Этап концептуализации.
На данном этапе
проводится содержательный анализ
проблемной области, выявляются
используемые понятия и их
взаимосвязи, определяются методы
решения задач. Этот этап завершается
созданием модели предметной области
(ПО), включающей основные концепты и отношения.
На этапе концептуализации определяются
следующие особенности задачи: типы доступных
данных; исходные и выводимые данные, подзадачи
общей задачи; используемые стратегии
и гипотезы; виды взаимосвязей между объектами
ПО, типы используемых отношений (иерархия,
причина — следствие, часть — целое и
т.п.); процессы, используемые в ходе решения;
состав знаний, используемых при решении
задачи; типы ограничений, накладываемых
на процессы, используемые в ходе решения;
состав знаний, используемых для обоснования
решений.
Этап формализации.
Теперь все
ключевые понятия и отношения
выражаются на некотором формальном
языке, который либо выбирается
из числа уже существующих, либо
создается заново. Другими словами, на
данном этапе определяются состав средств
и способы представления декларативных
и процедурных знаний, осуществляется
это представление и в итоге формируется
описание решения задачи ЭС на предложенном
(инженером по знаниям) формальном языке.
Выходом этапа формализации является
описание того, как рассматриваемая задача
может быть представлена в выбранном или
разработанном формализме. Сюда относится
указание способов представления знаний
(фреймы, сценарии, семантические сети
и т.д.) и определение способов манипулирования
этими знаниями (логический вывод, аналитическая
модель, статистическая модель и др.) и
интерпретации знаний.
Этап выполнения.
Цель этого
этапа — создание одного или
нескольких прототипов ЭС, решающих
требуемые задачи. Затем на данном
этапе по результатам тестирования
и опытной эксплуатации создается
конечный продукт, пригодный для
промышленного использования. Разработка
прототипа состоит в программировании
его компонентов или выборе их из известных
инструментальных средств и наполнении
базы знаний.
Главное в создании
прототипа заключается в том,
чтобы этот прототип обеспечил
проверку адекватности идей, методов
и способов представления знаний
решаемым задачам. Создание первого
прототипа должно подтвердить,
что выбранные методы решений
и способы представления пригодны
для успешного решения, по крайней
мере, ряда задач из актуальной
предметной области, а также
продемонстрировать тенденцию к
получению высококачественных и
эффективных решений для всех
задач предметной области по
мере увеличения объема знаний.
После разработки
первого прототипа ЭС-1 круг предлагаемых
для решения задач расширяется,
и собираются пожелания и замечания,
которые должны быть учтены
в очередной версии системы
ЭС-2. Осуществляется развитие ЭС-1
путем добавления "дружественного"
интерфейса, средств для исследования
базы знаний и цепочек выводов, генерируемых
системой, а также средств для сбора замечаний
пользователей и средств хранения библиотеки
задач, решенных системой.
Выполнение экспериментов
с расширенной версией ЭС-1, анализ
пожеланий и замечаний служат
отправной точкой для создания
второго прототипа ЭС-2. Процесс
разработки ЭС-2 итеративный. Он
может продолжаться от нескольких
месяцев до нескольких лет
в зависимости от сложности
предметной области, гибкости
выбранного представления знаний
и степени соответствия управляющего
механизма решаемым задачам (возможно,
потребуется разработка ЭС-3 и
т.д.). При разработке ЭС-2, кроме
перечисленных задач, решаются
следующие:
анализ функционирования
системы при значительном расширении
базы знаний;
исследование возможностей
системы в решении более широкого
круга задач и принятие мер
для обеспечения таких возможностей;
анализ мнений пользователей
о функционировании ЭС;
разработка системы ввода-вывода,
осуществляющей анализ или синтез предложений
ограниченного естественного языка,
позволяющей взаимодействовать
с ЭС-2 в форме, близкой к форме
стандартных учебников для данной
области.
Если ЭС-2 успешно
прошла этап тестирования, то
она может классифицироваться
как промышленная экспертная
система. Этап тестирования.
В ходе данного
этапа производится оценка выбранного
способа представления знаний
в ЭС в целом. Для этого
инженер по знаниям подбирает
примеры, обеспечивающие проверку
всех возможностей разработанной
ЭС.
Различают следующие
источники неудач в работе
системы: тестовые примеры, ввод-вывод,
правила вывода, управляющие стратегии.
Показательные тестовые примеры
являются наиболее очевидной причиной
неудачной работы ЭС. В худшем случае тестовые
примеры могут оказаться вообще вне предметной
области, на которую рассчитана ЭС, однако
чаще множество тестовых примеров оказывается
слишком однородным и не охватывает всю
предметную область. Поэтому при подготовке
тестовых примеров следует классифицировать
их по подпроблемам предметной области,
выделяя стандартные случаи, определяя
границы трудных ситуаций и т.п.
Ввод-вывод характеризуется
данными, приобретенными в ходе
диалога с экспертом, и заключениями,
предъявленными ЭС в ходе объяснений.
Методы приобретения данных могут
не давать требуемых результатов,
так как, например, задавались
неправильные вопросы или собрана
не вся необходимая информация.
Кроме того, вопросы системы могут
быть трудными для понимания,
многозначными и не соответствующими
знаниям пользователя. Ошибки при
вводе могут возникать также
из-за неудобного для пользователя
входного языка. В ряде приложения
для пользователя удобен ввод
не только в печатной, но и
в графической или звуковой
форме.
Выходные сообщения
(заключения) системы могут оказаться
непонятны пользователю (эксперту)
по разным причинам. Например, их
может быть слишком много или,
наоборот, слишком мало. Также причиной
ошибок может являться неудачная
организация, упорядоченность заключений
или неподходящий пользователю
уровень абстракций с непонятной
ему лексикой.
Наиболее распространенный
источник ошибок в рассуждениях
касается правил вывода. Важная
причина здесь часто кроется
в отсутствии учета взаимозависимости
сформированных правил. Другая причина
заключается в ошибочности, противоречивости
и неполноте используемых правил.
Если неверна посылка правила,
то это может привести к
употреблению правила в неподходящем
контексте. Если ошибочно действие
правила, то трудно предсказать
конечный результат. Правило может
быть ошибочно, если при корректности
его условия и действия нарушено
соответствие между ними.
Нередко к ошибкам
в работе ЭС приводят применяемые
управляющие стратегии. Изменение
стратегии бывает необходимо, например,
если ЭС анализирует сущности
в порядке, отличном от "естественного"
для эксперта. Последовательность,
в которой данные рассматриваются
ЭС, не только влияет на эффективность
работы системы, но и может
приводить к изменению конечного
результата. Так, рассмотрение правила
А до правила В способно привести к тому,
что правило В всегда будет игнорироваться
системой. Изменение стратегии бывает
также необходимо и в случае неэффективной
работы ЭС. Кроме того, недостатки в управляющих
стратегиях могут привести к чрезмерно
сложным заключениям и объяснениям ЭС.
Критерии оценки
ЭС зависят от точки зрения.
Например, при тестировании ЭС-1 главным
в оценке работы системы является
полнота и безошибочность правил
вывода. При тестировании промышленной
системы превалирует точка зрения
инженера по знаниям, которого
в первую очередь интересует
вопрос оптимизации представления
и манипулирования знаниями. И,
наконец, при тестировании ЭС
после опытной эксплуатации оценка
производится с точки зрения пользователя,
заинтересованного в удобстве работы
и получения практической пользы
Этап опытной эксплуатации
На этом этапе
проверяется пригодность ЭС для
конечного пользователя. Пригодность
ЭС для пользователя определяется
в основном удобством работы
с ней и ее полезностью. Под
полезностью ЭС понимается ее
способность в ходе диалога
определять потребности пользователя,
выявлять и устранять причины
неудач в работе, а также удовлетворять
указанные потребности пользователя
(решать поставленные задачи). В свою
очередь, удобство работы с ЭС подразумевает
естественность взаимодействия с ней
(общение в привычном, не утомляющем пользователя
виде), гибкость ЭС (способность системы
настраиваться на различных пользователей,
а также учитывать изменения в квалификации
одного и того же пользователя) и устойчивость
системы к ошибкам (способность не выходить
из строя при ошибочых действиях неопытного
пользователях).
В ходе разработки
ЭС почти всегда осуществляется
ее модификация. Выделяют следующие
виды модификации системы: переформулирование
понятий и требований, переконструирование
представления знаний в системе и усовершенствование
прототипа. Экспертные системы, параллельные
и последовательные решения.
Как мы можем
заметить, в большинстве алгоритмов
распознавания образов подразумевается,
что к началу работы алгоритма
уже известна вся входная информация,
которая перерабатывается параллельно.
Однако ее получение зачастую
требует определенных усилий. Да
и наши наблюдения за реальными
экспертами подтверждают, что зачастую
они задают два-три вопроса,
после чего делают правильные
выводы. Представьте себе, если бы
врач (эксперт в области медицины)
перед постановкой диагноза "ангина"
заставлял бы пациента пройти
полное обследование вплоть до
кулоноскопии и пункции позвоночника.
Соответственно
большинство алгоритмов модифицируются,
чтобы обеспечить выполнение
следующих условий:
алгоритмы должны работать
в условиях неполной информации (последовательно);
последовательность запроса
информации должна быть оптимальна по
критериям быстроты получения результата
и (или) наименьшей трудоемкости (болезненности,
стоимости и т.д.) получения этой
информации.
Одной из возможных
стратегий для оптимизирования
запросов является стратегия
получения в первую очередь
той информации, которая подтверждает
либо опровергает наиболее вероятный
на текущий момент результат.
Другими словами мы пытаемся
подтвердить или опровергнуть
наши догадки (обратный вывод)
6.3 Разработка прототипа
экспертной системы[18]:
При разработке
практически всех инструментальных
средств за основу принимается
методология автоматизации проектирования
на базе использования прототипов.
По отношению к программному
обеспечению термин прототип
означает "работающую модель программы,
которая функционально эквивалентна
подмножеству конечного продукта".
Идея состоит в том, чтобы
на ранней стадии работы над
проектом разработать упрощенную
версию конечной программы, которая
могла бы послужить доказательством
продуктивности основных идей, положенных
в основание проекта. Прототип
должен быть способен решать
какую-либо из нетривиальных задач, характерных
для заданной области применения. На основе
анализа опыта работы с прототипом разработчики
могут уточнить требования к системе в
целом и ее Основным функциональным характеристикам.
Работоспособность прототипа может послужить
очевидным доказательством возможности
решения проблем с помощью создаваемой
системы еще до того, как на ее разработку
будут потрачены значительные средства.
После всестороннего
анализа прототип откладывается
в сторону и начинается разработка
рабочей версии программы, которая
должна решать весь комплекс
задач, определенных в спецификации
проекта. Процесс разработки экспертной
системы, как правило, состоит
из последовательности отдельных
этапов, на которых наращиваются
возможности системы, причем каждый
из этапов подразделяется на
фазы проектирования, реализации, компоновки
и тестирования. В результате
после каждого этапа наращивания
возможностей в распоряжении
пользователя имеется система,
которая способна справляться
со все более сложными вариантами проблемы.
Такая методика
проектирования несколько отличается
от методики разработки программ
других видов. При создании
большинства программных продуктов
чаще используется другая модель
процесса- сначала разрабатывается спецификация
продукта, затем выполняется планирование,
проектирование компонентов, их реализация,
компоновка комплекса и тестирование
конечного варианта. Тот факт, что при
разработке экспертных систем есть возможность
сначала построить и всесторонне испытать
прототип, позволяет избежать множества
переделок в процессе создания рабочей
версии системы. Но технология последовательного
наращивания функциональных возможностей
таит в себе и проблему интеграции новых
функций с реализованными в предыдущих
вариантах. Инструментальные средства
разработки экспертных систем и создавались,
в первую очередь, с целью преодоления
возникающих при этом сложностей на основе
модульного представления знаний.