Структуризация знаний на декларативные и процедурные

По форме описания знания подразделяются на:

· декларативные;

· процедурные.

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

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

Структуризация приложения на основе иерархии «часть/целое»

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

Этап IV. Реализация

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

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

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

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

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

При представлении правил в виде, понятном экспертной системе, особое внимание следует уделять трем ситуациям:

· некоторое правило слишком громоздко;

· имеется много похожих правил;

· используются частные, а не общие правила.

 

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

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

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

Этап V. Тестирование

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

Специалисты выделяют три аспекта тестирования экспертных систем:

· тестирование исходных данных;

· логическое тестирование базы знаний;

· концептуальное тестирование прикладной системы.

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

Логическое тестирование базы знаний заключается в обнаружении логических ошибок в системе продукций, не зависящих от предметной области, таких, как избыточные, циклические и конфликтные правила; пропущенные и пересекающиеся правила; несогласуемые и терминальные клаузы (несогласуемые условия). Формальный характер этих ошибок позволяет автоматизировать процесс логического тестирования. Существует большое количество инструментальных средств для верификации наборов правил и базы знаний в целом. Однако в ряде случаев, когда цепочки правил, используемых в процессе вывода, небольшие (от 3 до 10 правил), целесообразно проводить процесс верификации вручную.

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