Лекция: Концептуализация проблемной области: Функциональная модель

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

А1_/\А2_/\А3_/\… /\Аn_ -> B,

означающей, что факт В имеет место только в том случае, если имеет

место конъюнкция фактов или их отрицаний А1, А2,…, Аn, например:

сбыт (Товар, «Слабый») и

прибыль (Товар, «Ничтожная») и

потребители (Товар, «Любители нового») и

число_конкурентов (Товар,«Небольшое») ->

жизненный_цикл (Товар, «Выведение на рынок»).

Функциональную зависимость фактов можно трактовать как отражение следующих отношений фактов:

• «Причина» — «Следствие»;
• «Средство» — «Цель»;
• «Аргумент» — «Функция»;
• «Ситуация» — «Действие».

В качестве термов конъюнкции фактов могут выступать более сложные логические условия.
Функциональная модель строится путем последовательной декомпозиции целей, а именно: для цели определяются подцели, для которых в свою очередь устанавливаются подцели и так дальше, пока в качестве подцелей не окажутся исходные факты (процесс декомпозиции «сверху» — «вниз»). Каждой цели (подцели) соответствует некоторая задача (подзадача), которая не может быть решена, пока не будут достигнуты ее нижестоящие подцели (решены подзадачи). Таким образом, функциональная модель отражает в обобщенной форме процесс решения характерных для нее задач.
Обычно функциональные зависимости фактов представляются графически в виде деревьев целей или графов «И» — «ИЛИ» (рис. 2.2), в которых каждый зависимый факт представляет собой целевую переменную — корневую вершину, а определяющие его факты-аргументы — cвязанные с корнем подчиненные вершины, условие конъюнкции (совместности анализа факторов) обозначается пересекающей дугой, а условие дизъюнкции (независимости влияния на цель факторов) никак не обозначается, причем если какой-либо факт-аргумент, в свою очередь, определяется другими фактами-аргументами, то он становится подцелью.

Рис. 2.2. Дерево целей — граф “И -ИЛИ”

26.Формализация проблемной области

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

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

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

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

· Логическая модель реализует и объекты, и правила с помощью предикатов первого порядка, является строго формализованной моделью с универсальным дедуктивным и монотонным методом логического вывода “от цели к данным”;

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

· Семантическая сеть отображает разнообразные отношения объектов;

· Фреймовая модель, как частный случай семантической сети, использует для реализации операционного знания присоединенные процедуры;

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

27. Реализация ЭС.

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

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

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

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

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

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

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

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

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

28. Тестирование ЭС.

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

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

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

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

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

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

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

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

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