Ii. разработка базы знаний с правилами вывода. (обязательная часть)

      Комментарии к записи Ii. разработка базы знаний с правилами вывода. (обязательная часть) отключены

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

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

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

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

2. Правила должны быть представлены в явном виде и храниться в отдельной структуре (таблице) БЗ. Описание правил в БЗ должно быть реализовано таким образом, что от пользователя не требуется указание номера вопроса, номера ответа и т.д.

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

4. Если условие применения одного правила зависит от результатов использования других правил, то необходимо задать соответствующий порядок (очередность). Альтернативой этому является повторная проверка выполнимости всех правил после срабатывания хотя бы одного из них.

5. В общем случае необходимость и очередность задавания вопросов может определяться на основе применения группы правил. Для реализации этого механизма имеет смысл объединить правила для вопросов и правила определения новых параметров.

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

Ниже приведены два варианта реализации таблицы правил. В таблице RulesSimple.db всегдаимеется только одна посылка и одно следствие. Для реализации множества следствий необходимо написать несколько правил с одинаковой левой частью. В таблице RulesComplex.db может иметься одна или две посылки, которые могут объединяться логической, арифметической или другой операцией. Для реализации более сложного правила, содержащего три или более посылки, его нужно разбивать на несколько простых. При вероятностном или нечетком выводе можно использовать операцию приращения/уменьшения значения параметра.

Таблица RulesSimple.db

Поле Типданных Описание
ID Integer Идентификатор правила
IF_Atr String Атрибут (свойство) объекта посылки.
IF_Value String Значение атрибута (свойства) объектапосылки.
Then_Atr String Атрибут (свойство) объекта следствия.
Then_Value String Значение атрибута (свойства) объектаследствия.
Used Boolean Использовано/не использовано правило

Таблица RulesComplex.db

Поле Типданных Описание
ID Integer Идентификатор правила
IF1_Atr String Атрибут (свойство) объекта посылки.
IF1_Value String Значение атрибута (свойства) объектапосылки.
Operation Integer Логическая операция ( 0 – нет операции, 1 –AND, 2 – OR, 3 – NOT …)
IF2_Atr String Атрибут (свойство) объекта посылки.
IF2_Value String Значение атрибута (свойства) объектапосылки.
Then_Atr String Атрибут (свойство) объекта следствия.
Then_Value String Значение атрибута (свойства) объектаследствия. Значение =’Null’, если осуществляетсяприрост/уменьшение вероятности гипотезы.
ChangeValue Integer(Number) Прирост/уменьшение вероятности(уверенности, достоверности) гипотезы (факта).
Used Boolean Использовано/не использовано правило

ЕСЛИ [(IF1_Atr = IF1_Value) Operation (IF2_Atr = IF2_Value)]

ТО [ЕСЛИ (Then_Value’Null’) ТО (Then_Atr = Then_Value)]

ЕСЛИ [(IF1_Atr = IF1_Value) Operation (IF2_Atr = IF2_Value)]

ТО[ЕСЛИ (Then_Value=’Null’) ТО (Then_Atr = Then_Atr + ChangeValue)]

Дополнительно в рамках работы можно реализовать:

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

Статьи к прочтению:

Как создать базу знаний (wiki) компании


Похожие статьи: