Способы разработки экспертных систем

Представления знаний в интеллектуальных системах, экспертные системы

Введение

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

Экскурс в историю экспертных систем

История экспертных систем берет свое начало в 1965 году. Брюс Бучанан и Эдвард Фейгенбаум начали работу над созданием информационной системы для определения структуры химических соединений.

Результатом работы была система под названием Dendral. В основе системы формировалась последовательность правил подобных к «IF – THEN». Информационная система не перестала развиваться и получила множество наследников, таких как ONCOIN – информационная система для диагностики раковых заболеваний, MYCIN – информационная система для диагностики легочных инфекционных заболеваний.

Следующим этапом стали 70-е годы. Период не выделялся особыми разработками. Было создано множество разных прототипов системы Dendral. Примером служит система PROSPECTOR, областью деятельности которой являлась геологические ископаемые и их разведка.
В 80-ых годах появляются профессия – инженер по знаниям. Экспертные системы набирают популярность и выходят на новый этап эволюции интеллектуальных систем. Появились новые медицинские системы INTERNIS, CASNE.

С 90-ых годов развитие интеллектуальных систем приобретает новые и новые методы и особенности. Нововведением становится парадигма проектирования эффективных и перспективных систем. Гибкость, четкость решения поставленных задач дало новое название – мультиагентных систем. Агент – фоновый процесс который действует в целях пользователя. Каждый агент имеет свою цель, «разум» и отвечает за свою область деятельности. Все агенты в совокупности образуют некий интеллект. Агенты вступают в конкуренцию, настраивают отношения, кооперируются, все как у людей.

В 21 век, интеллектуальной системой уже не удивишь никого. Множество фирм внедряет экспертные системы в области своей деятельности.

Быстродействующая система OMEGAMON разрабатывается c 2004 года с IBM, цель которой отслеживание состояния корпоративной информационной сети. Служит для моментального принятия решений в критических или неблагоприятных ситуациях.

G2 – экспертная система от фирмы Gensym, направленная на работу с динамическими объектами. Особенность этой системы состоит в том, что в нее внедрили распараллеливание процессов мышления, что делает ее быстрее и эффективней.

Структура экспертной системы

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

2. Данные
Данные — это совокупность фактов и идей представленных в формализованном виде.
Собственно на данных основываются закономерности для предсказания, прогнозирования. Продвинутые интеллектуальные системы способные учиться на основе этих данных, добавляя новые знания в базу знаний.

3. Модель представления данных
Самая интересная часть экспертной системы.
Модель представления знаний (далее по тексту — МПЗ) — это способ задания знаний для хранения, удобного доступа и взаимодействия с ними, который подходит под задачу интеллектуальной системы.

4. Механизм логического вывода данных(Подсистема вывода)
Механизм логического вывода(далее по тексту — МЛВ) данных выполняет анализ и проделывает работу по получению новых знаний исходя из сопоставления исходных данных из базы данных и правил из базы знаний. Механизм логического вывода в структуре интеллектуальной системы занимает наиболее важное место.
Механизм логического вывода данных концептуально можно представить в виде :
А — функция выбора из базы знаний и из базы данных закономерностей и фактов соответственно
B — функция проверки правил, результатом которой определяется множество фактов из базы данных к которым применимы правила
С — функция, которая определяет порядок применения правил, если в результате правила указаны одинаковые факты
D — функция, которая применяет действие.

Какие существуют модели представления знаний?

Распространены четыре основных МПЗ:

• Продукционная МПЗ
• Семантическая сеть МПЗ
• Фреймовая МПЗ
• Формально логическая МПЗ

Продукционная МПЗ

В основе продукционной модели представления знаний находится конструктивная часть, продукция(правило):
IF , THEN
Продукция состоит из двух частей: условие — антецендент, действие — консеквент. Условия можно сочетать с помощью логических функций AND, OR .
Антецеденты и консеквенты составленных правил формируются из атрибутов и значений. Пример: IF температура реактора подымается THEN добавить стержни в реактор
В базе данных продукционной системы хранятся правила, истинность которых установлена к за ранее при решении определенной задачи. Правило срабатывает, если при сопоставлении фактов, содержащихся в базе данных с антецедентом правила, которое подвергается проверке, имеет место совпадение. Результат работы правила заносится в базу данных.

Пример

Диагноз	Температура	Давление	Кашель
Грипп	39	100-120	Есть
Бронхит	40	110-130	Есть
Аллергия	38	120-130	Нет

Пример продукции:
IF Температура = 39 AND Кашель = Есть AND Давление = 110-130 THEN Бронхит

Продукционная модель представления знаний нашла широкое применение в АСУТП

Среды разработки продукционных систем(CLIPS)

CLIPS (C Language Integrated Production System) — среда разработки продукционной модели разработана NASA в 1984 году. Среда реализована на языке С, именно потому является быстрой и эффективной.
Пример:

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

Семантическая сеть МПЗ

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

• класс — подкласс
• свойство — значение
• пример элемента класса

По количеству типов отношений выделяют однородные и неоднородные семантические сети. Однородные имею один тип отношения между всеми понятиями, следовательно, не однородные имею множество типов отношений.

Все типы отношений:

• часть — целое
• класс — подкласс
• элемент — количество
• атрибутивный
• логический
• лингвистический

Пример

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

Фреймовая МПЗ

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

Слот может хранить другой фрейм, тогда фреймовая модель вырождается в сеть фреймов.

Пример

Пример вырождающейся в сеть фреймов

На своей практике, мне доводилось встречать системы на основе фреймовой МПЗ. В университете в Финляндии была установлена система для управления электроэнергией во всем здании.

Языки разработки фреймовых моделей (Frame Representation Language)

FRL (Frame Representation Language) — технология создана для проектирования интеллектуальных систем на основе фреймовой модели представления знаний. В основном применяется для проектирования вырождающихся в сеть фреймовой модели.

Запись фрейма на языке FRL будет иметь вид:

Существуют и другие среды: KRL (Knowledge Representation Language), фреймовая оболочка Kappa, PILOT/2.

Формально логическая МПЗ

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

Пример

A1 = A2 = A3 = ; IF A1 AND A2 THEN
Банальней примера и не придумаешь.
Важно: Стоит заметить, что формально логическая МПЗ схожа с продукционной. Частично это так, но они имеют огромную разницу. Разница состоит в том, что в продукционной МПЗ не определены никакие связи между хранимыми объектами предметной области.

Важно

Любая экспертная система должна иметь вывод данных и последовательность «мышления» системы. Это нужно для того чтобы увидеть дефекты в проектировании системы. Хорошая интеллектуальная система должна иметь право ввода данных, которое реализуется через интеллектуальный редактор, право редактора на перекрестное «мышление» представлений при проектировании системы и полноту баз знаний(реализуется при проектировки закономерностей предметной области между инженером по знаниям и экспертом).

Заключение

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

Источник

Экспертные системы (Разработка)

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

Содержание

Требования по созданию

Чтобы разработка ЭС была возможной для конкретного приложения, минимально необходимо одновременное выполнение следующих требований:

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

Оправданность использования

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

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

Соответствие приложения методам ЭС

Созданное приложение соответствует методам ЭС, если решаемая задача обладает совокупностью некоторых характеристик, а именно:

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

Концепция быстрого прототипа

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

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

Этапы разработки

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

• идентификация
• концептуализация
• формализация
• выполнение
• тестирование
• опытная эксплуатация

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

В ходе концептуализации проводится подробный анализ проблемной области, выявляются понятия и их взаимосвязи, определяются методы решения задач.

Формализация подразумевает выбор инструментов и способов представления всех видов знаний. На этом этапе формализуются основные понятия, определяются способы интерпретации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решений, средств представления знаний и управления ими.

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

Источник