Этапы разработки экспертных систем. Этап IV. Реализация

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

В данной статье рассматривается четвертый этап: реализация.

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

Обычная ошибка разработчиков при создании прототипа состоит в том, что процесс приобретения знаний откладывают до полного понимания структуры базы знаний и всех тестовых примеров. Тем самым эта наиболее трудоемкая часть работы отодвигается на поздние этапы. Процесс накопления знаний позволяет уточнить используемые понятия и отношения, поэтому необходимо начинать приобретение знаний, как только составлены или выбраны инструментальные средства, позволяющие работать с простейшим представлением знаний и простейшими управляющими структурами. Такой подход позволяет как можно раньше начать выполнение отдельных подзадач и обнаружить, что в ряде случаев для их решения необходимы дополнительные знания. Иными словами, первый прототип экспертной системы (ЭС-1) должен появиться через 1-3 месяца после начала работы. Разработка прототипа является чрезвычайно важным шагом в создании экспертной системы. Некоторые фрагменты прототипа могут войти в окончательную версию экспертной системы, но не это является наиболее важной целью создания прототипа. Главное, чтобы прототип обеспечил проверку адекватности идей, выбранных при построении данной экспертной системы, решаемым задачам.

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

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

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

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

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

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