CLAIM – научно-образовательный кластер

Учебный курс "Интеллектуальные системы"
Лабораторная работа № 2.
Разработка базы знаний с правилами вывода

Примечание. Отличие лабораторной работы № 2 от № 1 заключается в пунктах 3.6. и 3.7.

1. Цель работы.

Ознакомиться с подходом к разработке ЭС в части создания основных компонент: базы знаний, машины вывода и диалога (интерфейса) с пользователем.

2. Порядок выполнения работы.

2.1. Изучить теоретическое введение.

2.2. Последовательно выполнить все задания к лабораторной работе.

2.3. Проверить правильность выполнения заданий не менее чем на пяти примерах.

2.4. Оформить отчет по лабораторной работе.

3. Задания к лабораторной работе

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

3.2. Разбить процесс решения задачи на следующие этапы:

Количественные требования к основным показателям:

3.3. Разработать вопросы к пользователю и граф диалога

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

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

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

Порядок задавания вопросов должен изменяться в зависимости от ответов, т.е. могут быть заданы не все 20 вопросов, а только их часть. Более того, в зависимости от ответов должны задаваться разные группы вопросов.

Все вопросы должны задаваться в распространенной языковой и по возможности вежливой форме. Например, вместо Цвет?, Размер? должны задаваться указания или вопросы: Выберите цвет автомобиля, Какой размер одежды Вы носите?

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

Например, необходимо определить характеристики покупаемого компьютера. Пусть имеется, по крайней мере, четыре независимых группы вопросов, определяющих требования к системному блоку, монитору, клавиатуре и мыши соответственно. При использовании указанного подхода каждому ответу из множества {Answer1, …, AnswerN}, на котором заканчивается диалог о выборе системного блока, нужно сопоставить переход на первый вопрос Q2 из группы по выбору монитора (клавиатуры, мыши). Если нужно вопрос Q2 заменить на другой (Q3), то придется изменять N соответствующих переходов (ссылок) на него.

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

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

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

3.4. Разработать БД для хранения исходных, промежуточных и результирующих данных.

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

Необходимо разработать структуры для хранения данных о параметрах P, полученных в ходе ответов на вопросы, об атрибутах A объекта(ов) и, по желанию, о вариантах принятия решения (выбора).

3.5. Разработать вопросно-ответную компоненту БЗ.

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

* Можно расширить функциональные возможности программы за счет создания подсистем редактирования БЗ, и отображения графа диалога.

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

Ниже предлагается один из вариантов реализации структуры БЗ в архитектуре реляционных БД. БЗ содержит 3 таблицы: таблицу вопросов (Quest.db), таблицу правил очередности задавания вопросов (QuestRules.db) и таблицу ответов (Answ.db).

Таблица Quest.db

Таблица Answ.db

Таблица QuestRules.db

3.6. Разработать правила и реализовать машину вывода.

Необходимо формализовать второй этап принятия решения с помощью системы правил вывода, которые должны быть построены по принципу простой продукции ЕСЛИ …, ТО …

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

Если стиль_одежды = "модный" AND пол="женский" То цвет_одежды="розовый"

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

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

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

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

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

Таблица RulesSimple.db

Таблица RulesComplex.db

ЕСЛИ [(&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)]

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

3.7. Реализация принятия решения

Эта часть работы третьему этапу решения задачи. Она должна быть реализована произвольно с использованием стандартного подхода к разработке расчетно-логических систем в рамках тела программы или в виде дополнительного механизма с использование БЗ.

4. Содержание отчета

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

 © НОК CLAIM. Замечания, вопросы и сведения об ошибках просим сообщать в форуме или присылать администратору сайта.