Отличие ЭС от традиционных программ, точка архитектуры ЭС

 

ДЗ Выполнить этап идентификации и концептуализации для демонстрационной ЭС продукционного типа, определения уровня квалификации программиста

Это индивидуальная ЭС (ЭС для индивидуальноо пользования)

ЭС обычно создаются

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

1. ЭС основаны на инженерии знаний, пэтому центральное место в их архитектуре занимает расширяемая БЗ экспертов о некоторой обычно узкой проблемной области.(несмотря на то что МЛВ механизм логичесого вывода независимый компонент, но основная идея инженерия знаний заключается в том, что именно знания из БЗ + полученные в ходе консультации от пользователя факты, управляют УМЛВ). Для сравнения в процедурной парадигме активная часть достаётся функциям и процедурам, а данные пассивны. В оболчках ЭС обычно МЛВ является встроенным и именно благодаря тому, что активная роль отведена знаниям, один и тот же МЛВ с успехом решает не только разные задачи из разных проблемных областей одного типа» Диагностика (юридическая и т.д.)» но и даже задачи другого типа, например прогназирования. Это возможно благодаря тому что многие оболочки имеют в своём окружении настройки влияющие на стратегии вывода. Например в продукционной парадигме, где пракила представляются в виде еслито, существуют несколько стратегий вывода связанных с направлением вывода. Расширяемость БЗ означают в частности и то что она может пополнятся экспертами, инженерами по знаниям в не зависимости от других компонент системы. Это в частности может привести к тому что один и тот же пользователь консультируясь в разное время, и выдавая одни и те же факты на запрос системы. Может получить разный результат, что не возможно в традиционных программных средствах.

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

b. Обратный вывод, больше всего подходит для задач диагностики

c. Комбинированный подход для других типов задач(мониторинг ит.д.)

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

3. Недетерминированный характер логического вывода – недетерминированность в инженерии знаний, это своего рода вынужденная мера т.к. решаются неформальные слабо или трудно формализуемые задачи, требующие привлечения эвристик, Поэтому В ЭС ЗАШИТ НЕ АЛГОРИТМ РЕШЕНИЯ ЗАДАЧИ, а алгоритм поиска решения задачи, который в общем случае напоминает алгоритм перебора с возвратами, но при этом использует всевозможные приёмы сокращающие пространство поиска решения.

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

5. При отладке может помочь Наличие объяснительной компоненты – в GURU это раздел правил называется READEN компонента объяснения должна комментировать знания представленные в правилах, что используется для 2 основных целей (В GURU есть 2 команды Why How которые поясняют какие правила сработали, и какие переменные получили какие значения то есть какие факты как означились ЗАМЕЧАНИЕ: заключение правил так же как и запрашиваемые факты, называются фактами, но это выводимые факты, однако так же как и запрашиваемые факты после вывода своего значения, они помещаются в рабочую память системы и в этом смысле системе без разницы как получен факт. Так же есть Line of reasoning который выводит всю цепочку вывода. Таким образом, знания помещаемые в объяснительную компоненту являются важной частью общей базы знаний ЭС. В отличие от традиционных программных систем, которые тоже имеют объяснительную компоненту, которые выдают одну и то же ошибку, ЭС работает так что может менять в явном виде, пользователь с соответствующими полномочиями. (Чтобы изменить код ошибки компилятора надо иметь исходные коды))

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

b. Помогает разработчику в отладке ЭС(в виду недетерминированности метода)

6. Для ЭС характерны не итерации, а рекурсия. Не столько вычисления, сколько рассуждения в символьном виде, поэтому характерными операциями эффективно реализуемыми являются сопоставление с образцом, конкатенации и т.д. (В интегрированных системах имеются всё те же вычислительные возможности что и в паскале и т.д.) Например при оценке веса человека с точки зрения или в контексте средней продолжительности жизни используют понятия относительного веса человека (хрупкий норма крупный) на основе его (абсолютного веса, пола, роста и типа телосложения) при это важно не столько цифровое выражение этого значения(т.к. не нужны арифметические вычисления) сколько его символическое значение, например(>25, >25<50, 50<)

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

a. Не надёжные знания и факты(t>38, коэффициент доверия)

b. Неполнота, не монотонность

c. Многозначность(неоднозначность)

d. Недетерминированность

e. Нечёткие(fuzzy) множества

f. Лингвистические переменные

8. Способность системы к самообучению, рефлексии, в том числе на основе метазнаний и знаний типа «здравого смысла»

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

10. Учёт в ходе логического вывода различных типов связей(основные парадигматические связи) is a (Для сравнения: приложение БД количество связей в БД между таблицами учавствующими в запросе ничего не говорит о симантики, интерпритации этих связей и влияет на результат запроса лишь синтаксически)

МЛВ – механизм логического вывода

Рассмотрим демонстрационный пример ЭС(рекомендация чем человек будет заниматься через 5 лет)
Рассмотрим в среде оболочки ЭС GURU, которыая в отличие от ЭС не содержит БЗ ЭС за мисключением демонстрационных, но так же как ЭС содержит все остальные компоненты

· Компонента приобретения знаний

· Компонента логического вывода

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

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

· Интерфейсная компонента(обычно ориентированная на несколько категорий пользователей:)

o Эксперт

o Инженер по знаниям

o Конечный пользователь (конченый)

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

Причём не настройкой, а доработки расшерения возможности оболочки, если используется оболочка

 

Мы будем использовать оболочку GURU 81 года издания, в виду того что используется классическое представление знаиние продукции, а с другой стороны по сранению с доступными оболочками ЭС, она обладает намного более развитыми средствами неастройки и адамптации ЭС в частности в ней поддерживаются более 50 широковостребованных на практике, стратегии вывода, которые складываются из

1. Стратегия направления вывода
1. Прямая
2. Обратная
3. Комбинированная
2. Стратегия выборки правил
1. FIFO
2. LIFO
3. PRT(приоритет)
4. …
3. Стратегия тщательности вывода
1. Минимальная
2. Абсолютная
3. Комбинированная
4. и др.

 

смотри исходный текст демонстрационной БЗ Plays.rss:

1. используется прямой вывод

2. Абсолютная тщательность

3. Используются фази переменные

 

1. определиться кто будет источником знаний по теме(либо сам либо другие)
2. 2 основных типа зхадания
1. На диагностику(обратный вывод)
2. На прогнозирование (прямой вывод)

 

 

Знаменитые темы для диагностики:

• Медицинская диагностика
• Юридическая
• Авторское право
• Закон о безработице
• Отдельные главы уголовного и административного кодекса + комментарии к кодексам
• Подбор специальности для человека
• Подборы типа оружие под человека
• Отравления
• Определение грибов

Прогназирование:

• Экономическое
• Погода по приметам
• Феншуй

 

 

1. Узкая предметная область
2. Читаем, строим БЗ(определяем понятия)
3. Требования к интерфейсу. ТОЛЕРАНТЕН от третьего лица
4. Психологическая диагностика

 

 

ДЗ нормальный обратный вывод (invest), сейчас будем смотреть student

 

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

 

Последовательность шагов:

1. Объявляется конечная цель консультации.
2. МВЛ в соответствии со стратегией выборки правил, ищет правила в заключении которых находится текущая цель консультации.
3. Делается попытка доказать посылку соответствующего правила.
4. т.к. в посылке правила могут быть неозначенные переменные(факты), которые к тому жене являются запрашиваемыми, то первые из таких переменных автоматически объявляется текущей целью консультации и рекурсивно повторяется вывод.
5. В результате
1. Выводятся или запрашиваются все неизвестные переменные и срабатывает посылка соответствующего правила(то есть она истина) и как следствие срабатывает само правило. То есть факты из заключения считаются истинными и заносятся в рабочую память.
2. Либо после всех попыток доказать нужные подцели в рабочую память так и не попадает конечная цель консультации.(не успех). Замечание: В этой ситуации система должна выдать сообщение типа: «Обратитесь к другой ЭС»

 

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

«В GRUR(e.regr) который задаёт минимальную тщательность вывода, абсолютную и усреднённую».

 

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

Вариант тщательности вывода с (complex)

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

Минимальный уровень требований:

1. Правил не меньше 50, но при этом Акцент делать не на расширение знаний по горизонтали, а на углублённое знание по некоторым веткам по вертикали. То есть из всех возможных знаний из некоторой узкой ПО выбрать те из них, которые близки по подцелям
2. Глубина >3 не меньше 5 веток

 

Общие технологии разработки ЭС, кроме как концепция быстрого прототипа не существует.

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

• Демонстрационный прототип(не менее 50 отлаженных правил)
• БЗ 50-100 правил
• Система может быть не устойчива в работе
• И не эффективна
• Исследовательский прототип
• Наращивание БЗ поэтапное
• Повышение требований к надёжности и эффективности программного кода
• Действующий прототип
• Промышленный прототип
• Интерфейс
• Юзабилити
• Коммерческий

 

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

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

1. Этап идентификации:
1. Составление словоря используемых понятий включающие варианты допустимых значений, понятия обобщающего характера, понятия детализирующего характера
2. Этап концептуализации
1. Когда устанавливаются типы связи между понятий словоря и обычно представляются в графическом виде (дерево целей, И\или графа, сем.сетей)
3. Этап формализации
1. Представление знаний спроектированных на этапе концептуализации в выбранном формализме на соответствующем языке представления знаний:

i. Продукции

ii. Фреймы

iii. Сем.сети

iv. Логика

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

 

 

Архитектура ЭС

 

БЗ – смотри отличие от обычных.

 

КПЗ(компонента приобретения знаний) – как минимум предоставляет возможность в среде редактора, в соответствии с синтаксисом языка представления знаний(ЯПЗ), пополнять БЗ ЭС между консультациями. В развитых ЭС, КПЗ позволяет заполнять БЗ в автоматизированном режиме используя для этого либо продвинутую технику сопоставления с образцом, либо вопросно-ответный вариант, либо ЕЯ компоненту, но обычно на ограниченном ЕЯ. В современных ЭС роль КПЗ обычно берёт на себя КИЗ(компонента извлечения знаний), где активно используется DataMaining(технология извлечения знаний из структурированных данных типо БД, электронных таблиц), кроме тоогов совеременных ЭС используются TextManing и WebManing котороые позволяют извлекать знания из текста, сайта и т.д. Таким образом автоматизируется пополнение знаний в БЗ.

(Посмотреть WizWhy компонента DataManing строит прогноз урожая определённой культуры исходя из данных электронных таблиц, по таким показателям, как среднесуточная температуры и т.д.)

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

 

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

• Стратегия направления вывода(например в продукционных системах это прямой, обратный, комбинация)
• Стратегия выборки правил (FIFO,LIFO, стопка книг…)
• Стратегия означивания посылки(e.trip=”e”) после означивания каждого факта посылки делается проверка истинности посылки, в случае истины правило исполняется не смотря на то, что в посылке могли остаться неозначенные факты. Управляется БЗ,фактами, настройками, и фактами пользователя.
• P – сначала вычисляются все факты в посылке, и лишь потом она проверяется, но при этом допускается чтобы остались неозначенные факты
• S – по умолчанию. Аналогичен P, но не допускает пустые значения(UNKN – задаёт порог «известности» известным значение считается не просто = unkn, но и с порогом верности >20).
• Стратегия тщательности вывода
• На основе правил из БЗи фактов полученных от пользователя полученных в ходе консультации МЛВ пытается с учётом соответствующих у4становок, построить такую каузальную цепочку правил, которая в результате доказывает цель консультации

 

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

 

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

 

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

 

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

 

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

 

!таким образом в отличие от традиционных программ, разработчиком ЭС, напрямую пополняющие БЗ может быть не программист, но экспертам и инженерам по знаниям предъявляются особые требования:

 

 

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

 

1. На начальных этапах разработки ЭС, должен до половины времени уделять разработке, а далее не менее 1\3(тестирование, отладка)
2. Должен быть заинтересован(и морально и материально)
3. Должен верить в успех проекта
4. Самое главное должен быть способен и иметь желание верболизовать свои знания затратив на это достаточно времени (облеч в словестную форму)

 

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

 

Режимы работы ЭС

 

Основной режим смотреть на примере продукционной системы.

 

*Создаёт конфликтный набор правил

 

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

 

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

 

**Разрешает конфликт на основе стратегии выборки правил:

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

 

Пример прогназирование поведения животных:

1: If есть еда then еда;

2: If есть партнёр then спариваться;

 

***Цель – отражает рекурсивность процесса обратного вывода. Цикл остановится, когда в РП попадает цель консультации.

 

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

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

 

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

 

IF РП(название факта, значение фатка)

 

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

 

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

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

1. Языки искусственного интеллекта и ОО языки(Lisp,prolog)
1. В той или иной мере содержат и в своей парадигме, и в конструкциях языка смредства хорошо приспособленный для реализации ЭС, например средства связанные с символьным единообразным представлением программ и данных в lisp, логическим основанием как lisp так и prolog + встроенный механизм лог вывода в prolog(метод резолюций). В ООЯ и на уровне представления сложных структур данных, с учётом иерархии наследования развитая техника сопоставления с образцом, при поиске, и некоторые другие механизмы адекватны к задачам ЭС.
2. Языки инженерии знаний(KRL,FRL,KL-ONE..,OPS)
1. Специально разрабатывались для цели создания ЭС, а именно для представления знаний, и организации логического вывода на знания, поэтому в них зашиты изначально базовые примитивы, для предстваления фреймов, семантических сетей, продукций и организации логического вывода на них.
3. Оболочки ЭС и среды автоматизаци проектирования ЭС(GURU,VPExpert,Clirs,Kee)
1. Как следует из предыдущей лекции архитектура ЭС совпадает с оболочкой ЭС, за исключением отлаженной БЗ, поэтому по сравнению с другими категориями, сдесь автоматизированы все процессы создания ЭС и акцент делает лишь на заполнении БЗ, которая собственно является программой ЭС, поэтому напрямую разработчиком ЭС в случае использования оболочек, может выступать пользователь не программист.
2. Мы не стали отдельть оболочки от средст автоматизации, т.к. современные оболочки ЭС зачастую содержат встроенные высокоуровневые средства автоматизации их проектирования и наоборот, средства автоматизации проектирования зачастую в своей среде содержат в готовом виде все основные компоненты ЭС и позволяют комбинировать их с использованием всякого рода настроек.
3. Несмотря на то что оболочки самое высокоуровневое средство создания ЭС, им присущи 2 основных недостатка:

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

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

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

1. Выходом для нивилоравания первого недостатка, является использование настраевымых и универсальных оболочек ЭС
2. В случае настраевамых оболочек ЭС имеется конечный набор различных вариантов реализации различных компонентов ЭС, в том числе и в разных парадигмах, но после их интеграции заполнение и отладка БЗ ведётся в выбранной парадигме.
3. В сулчае универсальных оболочек ЭС(Loops,Kee), ктороые в разной степени интегрированности интегрироуют в себе различные парадигмы представления знаний (продукции, логика, сем сети, фреймы), и разные парадигмы функционирования(процедурная, ОО, ориентированную на данные, ориентированную на знания(продукционно ориентированная))

 

Процедурная: - активность функциям

О Данные – активность смещается в сторону данных

ООП – все равны

О знания – активность в знания

 

Пример интеграции:

If имя фрейма. Имя слота =” ”&…

 

Фрейм экзамен:

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

Почему?

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

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

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

 

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

 

 

Для фреймового представления знаний, наиболее адекватным является ООП, однако в них не встроен механизм логического вывода(наситель фреймов) и отсутствуют различные варианты наследования, за исключением традиционного.(same,Unique,range), когда потомки могут не только добавить св0ои свойства и метода и понаследовать родительские, но и переопределить родительские свойства и методы.

 

Книжка автор Марселус

 

Лекционно рассмотреть различные парадигмы представления знаний(обзорно) и отметить требования к прототипам ЭС и ответить на вопрос (Когда имеет смысл создавать ЭС?)

Обзор оболочек см в файле.

 

Зачем БД?

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

i. Запасти текстовые файлы определённой структуры

1. Vopros 1!....!

2. Otvet

a. 1!вар1

b. 1!вар…

ii. Создать запить в БД

iii. Data transfer для заполнения БД из исходныхтекстовых

iv. В initial выполнить команду USE для БД

v. В завершающей секции закрыть базу данных

vi. Load.. perform proc1

 

 

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