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


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

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



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

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

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

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

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

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

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

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

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

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

3) рабочие пространства могут селективно активироваться и деактивироваться. Это обеспечивает возможность подключения и игнорирования частей приложения во время работы;

4) рабочие пространства могут использоваться для конфигурирования методов доступа к находящейся в них информации.

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

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

Рабочие пространства, как и другие классы, могут быть организованы в иерархию. Рабочее пространство может быть рабочим пространством верхнего уровня или подчиненным рабочим пространством, ассоциированным с отдельным объектом. При этом подпространство объекта является составной частью пространства, вкотором находится данный объект. Подпространства могут и сами содержать объекты с подпространствами. Уровень вложенности подпространств практически может быть не ограничен. Рабочие пространства, таким образом, образуют иерархию, в которую подпространства включены на основе отношений "часть/целое" ("is-a-part-of"). Положение рабочего пространства в иерархии влияет на его активацию (деактивацию). Подпространства автоматически становятся неактивными при деактивации рабочего пространства, к которому они принадлежат (рис 7.1).

Рис.7.1. Пример членения базы знаний на рабочие пространства

 

База знаний на рис. 7.1 состоит из пяти рабочих пространств -трех верхнего уровня и двух подпространств. Каждое подпространство ассоциировано с объектом (изображенным в виде круга) в его "родительском" рабочем пространстве. Вследствие их взаимосвязанности деактивация рабочего пространства Б приводит к деактивации подпространств Г и Д.

Выполнение

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

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

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

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

• средств для исследования базы знаний и последовательностей выводов, генерируемых системой (что обеспечивает прозрачность и понимаемость системы разработчиком);

• средств для сбора замечаний пользователей;

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

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

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

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

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

Отладка и тестирование

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

Специалисты [4] выделяют три аспекта тестирования экспертных систем: тестирование исходных данных; логическое тестирование базы знаний; концептуальное тестирование прикладной системы.

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

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

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



Поделиться:


Последнее изменение этой страницы: 2016-04-26; просмотров: 316; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.235.186.149 (0.014 с.)