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

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

 

 

Рис. 2.5. Этапы создания ЭС

Рассмотрим более подробно последовательности действий, которые необходимо выполнить на каждом из этапов.

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

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

q определить задачи, подлежащие решению и цели разработки;

q определить экспертов и тип пользователей.

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

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

· эксперт выступает в роли информатора, а инженер по знаниям в роли получателя информации;

· эксперт выполняет роль учителя, а инженер выполняет роль ученика.

Считается, что вторая форма (учитель-ученик) больше соответствует методологии проектирования ЭС.

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

ü общие характеристики задачи;

ü подзадачи, выделяемые внутри данной задачи;

ü ключевые понятия (объекты), характеристики и отношения;

ü входные и выходные данные;

ü предположительный вид решения;

ü знания, релевантные решаемой задаче;

ü примеры (тесты) решения задачи.

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

В ходе идентификации задачи необходимо ответить на следующие вопросы (примерный состав):

ü какой класс задач будет решать данная ЭС;

ü как эти задачи могут быть охарактеризованы или определены;

ü на какие подзадачи разбивается каждая задача;

ü какие данные они используют;

ü каковы основные понятия и взаимоотношения, используемые при формулировании и решении задачи;

ü какой вид имеет решение и какие знания используются в нем;

ü какие аспекты опыта эксперта существенны при решении задач;

ü какие возможны ситуации, препятствующие решению;

ü как эти препятствия влияют на ЭС.

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

При проектировании ЭС типичными ресурсами являются:

· источники знаний;

· время разработки;

· вычислительные средства (возможности ЭВМ и программного инструментального средства);

· объем финансирования.

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

При определении времени разработки необходимо иметь в виду, что при трудоемкости 5 чел.-лет сроки разработки и внедрения ЭС составляют (за редким исключением) не менее года.

 

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

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

· формализация неформальных знаний экспертов;

· улучшение качества решений, принимаемых экспертом;

· автоматизация рутинных аспектов работы эксперта (пользователя);

· тиражирование знаний эксперта.

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

На этапе концептуализации:

q проводится содержательный анализ предметной области;

q выделяются основные понятия и их взаимосвязи;

q определяются методы решения задач.

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

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

На этапе формализации:

q выбираются программные средства разработки ЭС;

q определяются способы представления всех видов знаний;

q формализуются основные понятия.

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

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

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

ü являются понятия примитивными или имеют внутреннюю структуру;

ü необходимо ли представлять причинные и пространственно-временные отношения между понятиями и должны ли они быть представлены явно;

ü необходима ли иерархия гипотез;

ü следует ли использовать различные уровни абстракции.

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

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

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

На этапе выполнения (наиболее важном и трудоёмком) осуществляется наполнение экспертом БЗ, при котором процесс приобретения знаний разделяют:

q на "извлечение" знаний из эксперта;

q на организацию знаний, обеспечивающую эффективную работу ЭС

q на представление знаний в виде, понятном для ЭС.

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

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

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

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

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

Развитие действующего прототипа осуществляется в направлении повышения эффективности решения задач, для чего производится:

· анализ функционирования системы при значительном расширении базы знаний;

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

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

 

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

Процесс приобретения знаний осуществляется инженером по знаниям на основе деятельности эксперта (см. табл. 2.1).

Таблица 2.1. Приемы извлечения знаний

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

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

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

Основными источниками неудач в работе системы обычно являются: тестовые примеры; ввод-вывод данных; правила вывода; управляющие стратегии.

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

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

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

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

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

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

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

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