Системы, основанные на прецедентах

CBR – системы

В этих системах база знаний содержит не описания обобщенных ситуаций, а собственно сами ситуации (прецеденты).

Поиск решаемой проблемы сводится к поиску по аналогии – абдуктивный вывод от частного к частному.

1) Получение подробной информации от текущей проблеме;

2) Сопоставление полученной информации со значениями признаков прецедентов из базы знаний;

3) Выбор прецедента из базы знаний, который наиболее близок к рассматриваемой проблеме;

4) В случае необходимости выполняется адаптация выбранного прецедента к текущей проблеме;

5) Проверка корректности каждого полученного решения;

6) Занесение информации о полученном решении в базу знаний.

Также как и для индуктивных систем, прецеденты описываются

множеством признаков, по которым строятся индексы поиска. Но в отличии от индуктивных систем, допускается нечеткий поиск с получением множества альтернатив.

    Наиболее подходящее решение адаптируется к данной ситуации.

 

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

 

Рисунок 20 – Этапы разработки экспертных систем

 

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

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

1) Какие задачи нужно решать?

2) Как они определены?

3) На какие подзадачи надо разбить задачу?

4) Какие основные понятия и взаимоотношения используются при формулировании задачи?

5) Какие ситуации препятствуют решаемой задаче?

Идентификация цели

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

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

2. Улучшение качества решений, принятых экспертом.

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

4. Тиражирование знаний эксперта.

Обычно в основном цикле разработки системы участвует не менее трех-четырех человек: один – эксперт, один или два – инженеры по знаниям и один программист, привлекаемый для создания конкретных инструментальных систем. Могут привлекаться дополнительные эксперты, руководители.

Эксперт – информирующий, учитель.

Инженер – ученик.

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

 

Концептуализация

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

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

 

Содержательная модель

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

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

На этом этапе выявляются следующие особенности задач:

- типы доступных данных;

- исходные и выводимые данные;

- подзадачи, общие задачи;

- используемые стратегии и гипотезы;

- виды взаимосвязи между объектами;

- типы используемых отношений (часть- целое);

- процессы, используемые в ходе решения задачи, типы организации, накладываемые на процессы, используемые в ходе решения;

- состав знаний, используемый для решения задач;

- состав знаний, используемый для объяснения решения.

 

Этап формализации

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

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

Процесс зависит от трех факторов:

- структура, пространство, понятия;

- модель, лежащая в основе процесса решаемой задачи;

- свойства данных решаемой задачи.

При формализации необходимо ответить на следующие вопросы:

1) Являются ли понятия примитивными или имеют внутреннюю структуру;

2) Необходимо ли представление причинно-пространственного отношения между понятиями и должны ли они быть представлены явно;

3) Необходима ли иерархия гипотез;

4) Относится ли коэффициент уверенности или другие средства для выражения мнения только к окончательным гипотезам или он необходим для промежуточных гипотез;

5) Необходимо ли рассматривать понятия и процессы на различных уровнях абстракции.

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

1. Данные объяснены или нет в теории гипотез;

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

3. Данные могут быть редкими, обильными, недостаточными и избыточными.

4. Данные могут быть определены или нет и требуют ли уточнения фактора уверенности или нет.

5. Интегрированные данные зависят или не зависят от порядка их появления во времени;

6. Стоимость приобретаемых данных;

7. Как необходимые параметры объекта могут быть извлечены из входного сообщения: сигнала, изображения, текста.

8. Данные надежны, ненадежны;

9. Данные согласованы – несогласованны, полные – неполные.

 

 

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

    Цель этого этапа: создание одного или нескольких прототипов, которые решают данную задачу.

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

После разработки первого прототипа рассматриваемого круга задач собирают комиссию. Далее происходит развитие системы.

Она развивается путем добавления:

- дружественного интерфейса;

- средств для исследования баз знаний, цепочек вывода;

- средств для сбора замечаний пользователей;

- средств библиотек задач, решаемых системой.

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

 

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

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

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

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

Обычно выделяют следующие источники неудач в работе системы:

• тестовые примеры;

• ввод-вывод; правила вывода;

• управляющие стратегии.

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

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

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

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

Этап опытной эксплуатации.

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

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

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

Взаимодействия инженера по знаниям с экспертом.

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

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

1. Не будьте сами себе экспертом! (Другими словами, если Вы эксперт, то не пытайтесь описать свои знания без инженера по знаниям, который должен убедиться в достоверности выделенных знаний.)

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

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

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

Характеристики инструментальных средств.

Большинство ИтС предназначено для создания прототипов ЭС, решающих статиче­ские задачи (обычно задачи расширения) в статических проблем­ных областях.