Режим работы эс (на примере продукционной системы)

В случае обратного вывода попадают все те правила, которые в заключении содержат текущую цель консультации.

В случае прямого вывода попадают все те правила, которые еще не отрабатывались.

Порядок правил важен!!!

** Если в конфликтном наборе находится правило с одинаковым приоритетом и при этом стратегия выборки правил не fifo, а по приоритету, то по умолчанию из всех правил конфликтного набора с одинаковым приоритетом, выбирается первый попавшийся. ВGURUза это отвечает переменнаяe.sord=”PCU”, которая представляет собой последовательность литер, задающих различные критерии стратегии выборки.P-приоритет,C– цена (сначала более дешевые правила, а именно такие, которые можно исполнить наиболее эффективно, т.е. правила, не требующие обращения к БД, удаленным серверам и другое),U– в первую очередь правила, у которых меньше неизвестных переменных. А после всегоfifo.

Пример из книги Марселуса «Программирование ЭС на турбо-прологе»:

If«есть еда»then«есть»

If«есть партнер»then«спариваться»

В таком порядке правил исполнится, при условии истинности обоих утверждений, сначала «есть», хотя в природе будет иначе.

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

Эта традиционная схема работы ЭС имеет ряд недостатков, основными из которых являются следующие:

• Отсутствие метазнаний в контуре управления

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

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

IfРП(деньги, меньше прожиточного минимума) &CLASS= «имя класса правила»thenCLASS= «другой класс»

Классификация инструментальных средств

1. Традиционные ЯП (Паскале - , Си - , Фортано - , Бэйсик – подобные)

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

2. Языки ИИ и ООЯ (Лисп, Пролог – ИИ, Smalltalk 80 – ООЯ)

Языки ИИ в той или иной мере содержат и в своей парадигме, и в конструкции языка средства, хорошо приспособленные для реализации ЭС. Например, связанные с символьным единообразным представлением, логическим основанием как лиспа, так и пролога + встроенный механизм логического вывода в прологе (метод резолюции). В ООЯ и на уровне представления сложных структур и сложно взаимосвязанных структур данных с учетом иерархии наследования развитой техники сопоставления с образцом при поиске и некоторые другие механизмы адекватны задачам ЭС. Замечание: для фреймового представления знаний наиболее адекватным является ООП, однако в них не встроен механизм логического вывода и отсутствует различные варианты наследования (same,unique,range), за исключением традиционного (override), когда потомки могут не только добавить свои свойства и методы и понаследовать родительские, но и переопределить родительские свойства и методы.

3. Языки инженерии знаний (KRL, FRL, KL-one и другое)

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

4. Оболочки ЭС, среды автоматизации проектирования ЭС (ART, GURU, VP-EXPERT).

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

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

2. Более низкая эффективность результирующего кода

3. Кроме того, ЭС поставляется вместе с её оболочкой

Выходом из 1 недостатка является использование универсальных и настраиваемых оболочек ЭС. В случае настраиваемых оболочках ЭС имеется конечный набор различных вариантов реализации различных компонентов ЭС, в том числе и в разных парадигмах, но после их интеграции заполнение и отладка БЗ ведется в выбранной парадигме с выбранными настройками. В случае универсальных оболочек ЭС (LOOPS,KEE,ART), которые в разной степени интеграции интегрируют в себе различные парадигмы представления знаний: продукции, логика, сем сети, фреймы, – и разные парадигмы функционирования: процедурную (активные функции, пассивны данные), объектно-ориентированную (активные данные и функции одинаково), ориентированную на данные (активные данные), ориентированную на знания, например, продукционно-ориентированную (активные знания, пассивен МЛВ).

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

Интеграция продукций с фреймами:

If<имя фрейма><имя слота> = « »

Фрейм «Экзамен»

| FrameПреподаватель |FrameСтудент | Предмет | Билет = счастливый | Аудитория = удобная | Оценка =? |

If(Преподаватель = «не требовательный») & (Студент = «середнячок»)thenОценка = «5»

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

Осталось:

1. требования к прототипам ЭС

2. парадигмы представления знаний

3. ответить на вопрос: «Когда имеет смысл создавать ЭС?»

4. Обзор современных оболочек (см. в файлах)

Работа с БД в гуру:

1. Работа с фактами (хранение)

2. Для отладки

3. Вспомогательные цели, например, хранить в БД на вопросы ответы с целью генерации экранных форм для запрашиваемых переменных. Для этого

   1. Надо запасти текстовые файлы определенной структуры:

txtvopros1| ….|

otvet1|Вар 1|

b. Создать БД

c. ВыполнитьDatatransfer

d. Использовать

e. var

information manager -> data manager -> table structuring -> build new structure тут создали

information manager -> data manager -> data transfer

САМАЯ СЕРЬЕЗНАЯ РЕКОМЕНДАЦИЯ связана с тем, что …, а начать с одного поддерева дерева цели, вершиной которого будет одна подцель, которая и будет в начале отладки целью консультации.

Мин. Уровень требований к БЗ:

Правил не менее 50, но при этом акцент делать не на расширении знаний по горизонтали, а на углубленное представление знаний по некоторым веткам по вертикали. Не менее 5 веток.

Этапы проектирования:

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

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

• Исследовательский прототип

• Действующий прототип

• Промышленный прототип

• Коммерческий прототип

отличающихся как объемом отлаженного ТЗ, так и требованиями надежности, эффективности, качества интерфейса, юзабилити.

Например, в случае демо-прототипа, БЗ должна иметь 50-100 правил, при этом система может быть неустойчива в работе, не эффективна и требования к интерфейсу пониженные.

Далее идет наращивание БХ поэтапное и повышается требование к надежности и эффективности программного кода.

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

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

Поэтому технологии создания ЭС подразумевает следующие этапы:

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

2. Концептуализации, когда устанавливаются типы связей между понятиями и словаря и представляется в графическом виде, например, дерево целей и/или графа, семантической сети.

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

4. Реализация, тестирование, отладка

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

АРХИТЕКТУРА ЭКСПЕРТНЫХ СИСТЕМ

База знаний

База знаний

КПЗ

МЛВ

(решатель)

Компонента объяснения

Компонента извлечения знаний

Рабочая память

Интерфейс конечного пользователя

Интерфейс эксперта, инженера по знаниям

КПЗ позволяет КАК МИНИМУМ среде текстового редактора в соответствии с синтаксисом языка представления знаний пополнять БЗ ЭС между консультациями. В развитых ЭС КПЗ позволяет заполнять БЗ в автоматизированном режиме, используя для этого либо продвинутую технику сопоставления с образцом, либо вопросно-ответный вариант, либо ЕЯ компоненту (на ест. языке). В современных ЭС роль КПЗ зачастую берет на себя компонента извлечения знаний, где активно используется технология DataMining. DM – технология извлечения данных из структурированных данных, типа БД, электронных таблиц. Еще есть TextMining и WebMining, которые позволяют извлекать данные из веб-страниц и анализировать структуру… таким образом, автоматизируется процесс пополнения БЗ. Компонента DM строит исходя из данных за много лет в электронных таблицах по таким показателям, как температура, состав почвы и т.д. В современных динамических ЭС с элементами самообучения непосредственно сами ЭС способны пополнять свою БЗ новыми фактами и правилами. Например, такую систему можно сделать на основе метазнаний, но при этом автоматически сохраняется авторство правил и система способна настраиваться на работу с учетом этих правил или без, пока человек-эксперт не переведет эти знания в «человеческие».

МЛВ является встроенным и, несмотря на то, что является отдельным компонентом ЭС, его функционирование управляется другим компонентом, а именно БЗ, фактами + настройки системы, управляющей выводом:

• Стратегия направления вывода (например, в продукционных системах это прямой, обратный, комбинированный)

• Стратегия выборки правил (фифо, лифо, приоритет и др.)

• Стратегия означивания посылки (e.tryp) – после означивания каждого факта посылки правила делается попытка проверки истинности посылки, и в случае истинности правила исполняются несмотря на то, что в посылке могли остаться неозначенные факты. Passion - сначала вычисляются все факты в посылке, лишь потом она проверяется, при этом допускается, что остались неозначенные факты. Strong (стоит по умолчанию) – аналогично passion, но все факты должны быть не UNKNOW. (UNKNOW: e.unkn – задает порог «известности», т.е. читается не просто значение <> UNKNOW, а с учетом доверия, не менее порогового). На основе правил из БЗ и фактов, полученных от пользователя в ходе консультации, МЛВ пытается с учетом соотв. установок построить такую каузальную цепочку правил, которая в результате доказывает цель консультации.

• Стратегия тщательности вывода (абс, мин, средняя)

Компонента объяснения (см. лекцию отличия ЭС от традиционных систем)

В соот. с ходом логического вывода выдает на ЕЯ аргументацию, обоснование применяемого правила. Эта аргументация извлекается из БЗ экспертов и является её важной частью.

Рабочая память (база фактов)

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

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

Архитектура ОБОЛОЧЕК ЭС практически полностью повторяет архитектуру ЭС, за исключением заполненной и отлаженной БЗ. Как следствие, обычно ЭС созданы под управлением оболочек, не являются независимыми и поставляются вместе с оболочками.

Коротко, об экспертах и инженерах по знаниям (ИПЗ). Если в качестве инструментального средства создания ЭС используется оболочка ЭС, то в команде разработчиков может отсутствовать программист, но эксперт и ипз должны присутствовать обязательно.

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

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

2. на начальных этапах разработки должен до половины времени уделять разработки, а последующих не менее 1/3 тестированию,

3. должен быть заинтересован (морально и материально)

4. должен верить в успех проекта

5. Самое главное, должен быть способен ВЕРБОЛИЗОВАТЬ свои знания, затратив на это достаточно времени.

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