Хелпикс

Главная

Контакты

Случайная статья





ПРОПУСК 2 часть первой пары из за опоздания)



 

Экспертные системы вторая часть курса лекций ко второй контрольной 30.09.16

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

Основные принципы создания экспертных систем(они получены в результате их успешного практического применения)

1. Мощность экспертной системы обусловлено в первую очередь мощностью базы знаний и возможностью ее пополнения и только во вторую очередь используемыми ею методами или процедурами.

2. Знания позволяющие экспертной системе получать качественные и эффективные решения задач является в основном эвристическими, экспериментальными, неопределенными, правдоподобными.

3. Учитывая не формализуемость решаемой задачи и эвристически личностный характер используемых знаний, пользователь должен иметь возможность непосредственного взаимодействия с экспертной системой в форме диалога.

Т.к. основной источник это знания то экспертная система должна обладать способность приобретать знания. Процесс приобретения знаний можно разделить на три этапа :

1. Получение знания от эксперта.

2. Организация знаний обеспечивающая эффективную работу системы.

3. Представление знаний в понятном системе виде.

Приобретение знаний осуществляется инженером по знаниям.

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

1. Задачи не могут быть заданы в числовой форме.

2. Цели не могут быть выражены в терминах в точно определенной целевой функции.

3. Не существует алгоритмического решения задач.

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

5. Ошибочность, неоднозначность , неполнота и противоречивость исходных данных.

6. Знаний о проблемной области и о решаемой задачи.

7. Динамически изменяющиеся данные и знания.

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

 

Архитектура Экспертной системы

Исходя из перечисленных трех принципов создания экспертной системы, типичная ЭС имеет следующий вид.

 

(Рисунок1)

 

ЭС состоит из :

1. База знаний хранящий множество в общем случае правил.

2. Рабочей памяти хранящей данные.

3. Интерпретатора решающего на основе имеющихся в системе знаний поставленную ему задачу.

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

5. Компоненты приобретения знаний.

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

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

Методология построения ЭС 7.10.16

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

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

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

2. Языки инженерии знаний. PROLOG, OPS-5

3. Средства автоматизации процесса конструирования использования и модификации ЭС. RLL, HEARSAY-III, TEIRESTAS….

4. Пустые ЭС( не содержащие знаний ). EMYCIN

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

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

Фотка с доски

1 Эксперт в проблемной области решаемой задачи.

2 Один, два инженера по знаниям, специалистов по разработки ЭС.

3 Программист осуществляющий модификацию согласования инструментальных средств.

Этапы идентификации.

На этом этапе решаются следующие задачи.

1. Определяются участники процесса проектирования и их роли.

2. Идентифицируется проблема.

3. Определяются ресурсы и цели.

4. 0Определяются источники знаний.

…..(прослушал пару слов) вербального описания решаемой проблемы. В этом описании указывается :

1.общие характеристики проблемы.

2. Подпроблемы выделяемые в данной проблеме.

3.Ключевые понятия и отношения. 

4.Входные данные. 

5.Предположительный вид решения.

6.Знания связанные с решаемой проблемой.

При проектировании, типичными ресурсами являются:

1. Источники знаний.

2. Время разработки.

3. Вычислительные средства.

4. Объем финансирования.

Практика показывает что сроки разработки ЭС составляет не менее двух лет при трудоемкости разработки от пяти до десяти человека лет.(такое выражение)

Что касается идентификации цели, важно отличать цель ради которой строится система от задач которой она должна решать.

Цели:

1. Формализация неформальных знаний эксперта.

 

Автоматизация рутинных аспектов работы пользователя.

(ПРОПУСК 2 часть первой пары из за опоздания)

2 пара.

Этап выполнения.

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

Цель первого прототипа получить решение задачи не заботясь о его эффективности.

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

1. Проводится анализ функционирования системы при значительном расширении базы знаний.

2. Исследуются возможности системы при решении или в решении более широкого круга задач и предпринимаются меры для обеспечения такой возможности

3. Анализируются мнения пользователей о недостатках системы.

4. Разрабатывается система ввода вывода (в основном направленная на поддержку ограниченного естественного языка).

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

В процессе реализации первого и второго прототипа постоянно идет процесс накопления знаний системы при этом инженер по знаниям получает знания от эксперта, структурирует их и представляет их в виде понятном для ЭС. Процесс …….(?)

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

Этап тестирования .

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

1. Качество тестовых примеров.

2. Ввод вывод(не та информация собрана или неправильно введена или не понятный вывод и тд)

3. Правило вывода

4. Управляющие стратегии

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

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

Модификации ЭС.

В процессе ЭС системы можно выделить следующие виды ее модификации

1. Переформулирование понятий и требований.

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

3. Усовершенствование прототипа.

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

Стадии ЭС.

 Разрешают следующие стадии существования ЭС.

1. Демонстрационный прототип

2. ……???

3. Действующий прототип( Надежно решает все задачи но сложные задачи могут потребовать слишком много ресурсов от двух до трех лет надо на доведение такого уровня и в базе знаний такая система содержит от 500 до 1000 правил.

4. Промышленная система. Высокое качество решений всех задач при минимуме всех ресурсов, переписывается на язык более низкого уровня . Содержит до тысячи правил, требуется…????

5. Коммерческая система(обобщается задачи решаемой системой) И расширяется их класс. Что используется различными потребителями. Для доведения до этой стадии требуется от 3х до 6ти лет.

 

Методы и средства представления знаний.

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

1. Правило продукционные.

2. Фреймы.

3. Логические подходы.

4. Семантические сети.

5. Антологии.

6. И другие.

Продукционный подход к представлению обработки знаний .

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

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

Рисунок(?)

 Процесс вывода останавливается если нет применимых продукций достигнуто целевое состояние либо в правиле содержится указание на остановку либо исчерпаны ресурсы. Рассмотрим схематичный пример одной итерации цикла

База данных С5,С1,С3.

Продукц. правила С18С2->A1

C3->A2 конфликт выполняем действие А2 и допустим оно меняет БД

C18C3->A3 конфликт

C4->A4

C5->A5 конфликт

Процесс распознавания включает два этапа сопоставление образцов

1. Этап сопоставления образцов

2. Этап выбора правила из конфликтного множества или проведение конфликтной резолюции

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

1. Синтаксическое сопоставление, оно предполагает что образец в левой части правила должен быть посимвольно идентичен элементу БД.

2. Семантическое сопоставление удовлетворение некоторым условиям или тестам элементов БД при условии что эти элементы соответствуют определенному образцу

3. Сопоставление образцу . В левой части правила используются переменные, во время установления соответствия переменные в условии связываются (замещаются константой из БД) и это связывание последовательно используется во всем правиле и в условной части и в части действия.

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

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

Управление на этапе сопоставления в основном сводится к выбору той или иной стратегии определяющие направление обработки правил и обычно называется управление сопоставлением

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

Конфликтная резолюция

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

Рассмотрим некоторые из широко используемых стратегий управления выбора продукции и инстанциацией.

1. Упорядочивание продукций. Над продукциями задан полный порядок и применяется та продукция из конфликтного множества у который максимальный приоритет.

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

3. Использование атрибутов новизны, доверия или другие из конфликтного множества, выбирается та продукция образцом для которой служат данные с максимальной новизной или доверием.

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

Процедура разрешения конфликта и информацию о последовательности применения продукции к БД называют управляющей стратегией продукционной системы. Обычно выделяют два класса управляющих стратегий 1) Безвозвратная стратегия 2)Пробная.

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

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

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

Действия правил.

Перечислим основные действия которые выполняют правые части правил.

1. Модификация, это внесение изменений в элементы в БД и базы правил.

2. Добавление элементов в БД или в базу правил.

3. Удаление элементов из БД и базы правил.

 

21.10.16

1 ПАРА ПРОПУСК.

2 Пара

Слот элемента : вагоны:

Класс значений ( цел пол ???)

Минимальное число значений (1)

Максимальное число значений (1)

Значении (неизвестно)

Слот собственный : максимум вагонов

Класс значений (???? Хз че там, Хуевый почерк???)

Минимальное число значений (1)

Максимальное число значений (1)

Значения (40)

Слот собственный : Минимум вагонов

Класс значений (?????)

Минимальное число значений (1)

Максимальное число значений (1)

Значения (10)

Фрейм поезд №183

Надклассы:

Скорые

Слот собственный : вагоны : 18

Слот собственный: статус :

 

При обработке знаний представленным фреймом, можно выделить три основные процедуры

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

2. Поиск фрейма адекватного текущей ситуации

3. Заполнение фрейма, конкретными значениями

Вывод: фреймы обеспечивают различные средства вывода на основе имеющихся.

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

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

Фреймы содержат атрибуты которые должны присутствовать у представляемыми их объектов. Информация связанная со слотами фрейма для данной ситуации может быть использована в качестве совета, как строить описание компонент.

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

(я так понял далее касается 2рого пункта “Поиск фрейма адекватного текущей ситуации“)

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

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

Опишем третий случай.

Таким образом со слотами могут быть ассоциирована информация в следующем виде. Помогающая вычислить значение данного слота и определяющая направление дальнейшего поиска ( в случае поиска фрейма адекватного текущей ситуации ) Либо дающая рекомендации для построения новых фреймов.

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



  

© helpiks.su При использовании или копировании материалов прямая ссылка на сайт обязательна.