3. Структуризация знаний на декларативные и процедурные
По форме описания знания подразделяются на:
декларативные;
процедурные.
Декларативные знания – это знания, которые записаны в памяти интеллектуальной системы так, что они непосредственно доступны для использования после обращения к соответствующему полю памяти. Обычно декларативные знания используются для представления информации о свойствах и фактах предметной области. По форме представления декларативные знания противопоставляются процедурным знаниям.
Процедурные знания – это знания, хранящиеся в памяти интеллектуальной системы в виде описания процедур, с помощью которых их можно получить. Обычно процедурные знания используются для представления информации о способах решения задач в проблемной области, а также различные инструкции, методики и т.п.
4. Структуризация приложения на основе иерархии «часть/целое»
Модульный принцип создания приложения предоставляет разработчику различные возможности разбиения приложения на подсистемы, легче поддающиеся сопровождению и модификации. Разбиение приложения на модули упрощает процесс тестирования за счет использования групповой работы над тестируемой системой. Модульность также обеспечивает базовые возможности для повторного использования фрагментов системы.
32. Характеристика этапа реализации проектирования экспертной системы
В ходе работ по созданию экспертных систем сложилась определенная технология их разработки, включающая шесть следующих этапов: идентификация, концептуализация, формализация, реализация, тестирование, опытная эксплуатация и внедрение.
В данной статье рассматривается четвертый этап: реализация.
Цель этапа выполнения состоит в создании одного или нескольких прототипов экспертной системы, решающих требуемые задачи. Затем по результатам этапов тестирования и опытной эксплуатации на данном этапе создается конечный продукт, пригодный для промышленного использования. Разработка прототипа состоит в программировании его компонентов (или выборе их из имеющихся инструментальных средств) и наполнении базы знаний.
Обычная ошибка разработчиков при создании прототипа состоит в том, что процесс приобретения знаний откладывают до полного понимания структуры базы знаний и всех тестовых примеров. Тем самым эта наиболее трудоемкая часть работы отодвигается на поздние этапы. Процесс накопления знаний позволяет уточнить используемые понятия и отношения, поэтому необходимо начинать приобретение знаний, как только составлены или выбраны инструментальные средства, позволяющие работать с простейшим представлением знаний и простейшими управляющими структурами. Такой подход позволяет как можно раньше начать выполнение отдельных подзадач и обнаружить, что в ряде случаев для их решения необходимы дополнительные знания. Иными словами, первый прототип экспертной системы (ЭС-1) должен появиться через 1-3 месяца после начала работы. Разработка прототипа является чрезвычайно важным шагом в создании экспертной системы. Некоторые фрагменты прототипа могут войти в окончательную версию экспертной системы, но не это является наиболее важной целью создания прототипа. Главное, чтобы прототип обеспечил проверку адекватности идей, выбранных при построении данной экспертной системы, решаемым задачам.
Создание первого прототипа должно подтвердить, что выбранные методы решений и способы представления пригодны для успешного решения по крайней мере ряда задач из области экспертизы. При разработке первого прототипа обычно оставляют в стороне вопросы, требующие значительных трудозатрат: построение сложных моделей; учет сложных временных, причинных и модальных отношений; понимание намерений пользователей; моделирование рассуждений, содержащих неточные понятия.
Итак, можно сделать вывод, что в первом прототипе реализуется простейшая процедура вывода. При его разработке основная цель состоит в том, чтобы получить решение задачи, не заботясь пока об эффективности. После разработки первого прототипа необходимо расширить круг задач, решаемых системой, для того, чтобы собрать пожелания и замечания, которые будут учтены во втором прототипе системы (ЭС-2).
В ходе приобретения знаний инженер по знаниям должен получить знания от эксперта, структурировать их и представить в виде, понятном экспертной системе. Процесс извлечения знаний сложен и длителен, так как эксперт часто или не осознает, какими знаниями он пользуется, или не может их вербализовать (содержательно выразить). Для достижения эффективного функционирования экспертной системы необходимо осуществить структурирование знаний. Наиболее важным средством для структурирования знаний является иерархия классов, описывающих понятия промежуточного уровня. Во многих случаях эти понятия могут явно не упоминаться (а возможно, и не осознаваться) экспертом. Задача инженера по знаниям – выделить такие понятия, обнаружив сходные действия эксперта при обработке различных ситуаций.
При представлении правил в виде, понятном экспертной системе, особое внимание следует уделять трем ситуациям: некоторое правило слишком громоздко; имеется много похожих правил; используются частные, а не общие правила. Громоздкость правила может объясняться тем, что в нем отражено несколько фактов из данной проблемной области. Если это так, то правило надо разбить на несколько более мелких. Вторая ситуация имеет место тогда, когда в проблемной области существует понятие, явно не указанное экспертом, а возможно, и не имеющее имени. В этом случае новое понятие необходимо ввести в явном виде, присвоить ему специальное имя и, используя это понятие, сформулировать одно правило взамен группы подобных. Третья ситуация имеет место тогда, когда эксперт не использует возможности, предоставляемые объектно-ориентированным программированием, позволяющим скрыть специфику объектов в иерархии классов и ссылаться в правилах на классы, а не на конкретные объекты.
Выполнение экспериментов с версией ЭС-2 и анализ результатов их прогонов позволяют выявить недостатки системы и разработать средства для их устранения. Этот итеративный процесс может продолжаться еще несколько месяцев и зависит от сложности проблемной области, от гибкости выбранного представления и степени соответствия управляющего механизма решаемым задачам (возможно, потребуется разработка ЭС-3 и т.д.).
В целом итеративная разработка заключается в подходе к реализации системы как серии удачных приближений прототипов к конечной цели, а не как к единой, монолитной, интегрированной системе. Итеративная разработка особенно эффективна при создании систем с недостаточно четко определенными спецификациями, к которым прежде всего относятся экспертные системы. Поскольку подобные проекты обычно недостаточно проработаны с точки зрения системного анализа, разработчики обычно обнаруживают новые требования к системе после начала проекта. Если принят итеративный подход к разработке, то на адаптацию системы и коррекцию дальнейшего плана работ требуются относительно небольшие затраты.
33. Характеристика этапа тестирования проектирования экспертной системы
В ходе работ по созданию экспертных систем сложилась определенная технология их разработки, включающая шесть следующих этапов : идентификация, концептуализация, формализация, реализация, тестирование , опытная эксплуатация и внедрение.
В данной статье рассматривается пятый этап : тестирование .
Этап тестирования экспертной системы включается в каждую стадию прототипирования прикладной системы . Хотя обычно тестирование рассматривают в качестве заключительной фазы процесса разработки, операционное прототипирование, характеризующееся возможностью изменения целей проектирования в процессе разработки, предъявляет особые требования к доказательству корректности (верификации – verification) и соответствия разрабатываемой системы предъявляемым требованиям (концептуальное тестирование – validation). Эти две задачи должны выполняться параллельно с процессом разработки экспертной системы . По аналогии с технологией тестирования традиционных программных систем можно интерпретировать процесс верификации (логического тестирования ) как альфа-тестирование программной системы , а концептуальное тестирование – как этап бета-тестирования, хотя тестирование экспертных систем принципиально отличается от тестирования традиционных систем. В то время как достаточно строгие предварительные спецификации традиционной системы позволяют программисту осуществлять эти работы (в особенности верификацию системы ) самостоятельно, для тестирования экспертной системы необходимо привлекать эксперта в данной предметной области.
Специалисты выделяют три аспекта тестирования экспертных систем :
тестирование исходных данных;
логическое тестирование базы знаний;
концептуальное тестирование прикладной системы.
Тестирование исходных данных включает проверку фактографической информации, служащей основой для проведения экспертизы. Очевидно, что наборы данных, используемых при тестировании , должны покрывать область возможных ситуаций, распознаваемых экспертной системой .
Логическое тестирование базы знаний заключается в обнаружении логических ошибок в системе продукций, не зависящих от предметной области, таких, как избыточные, циклические и конфликтные правила; пропущенные и пересекающиеся правила; несогласуемые и терминальные клаузы (несогласуемые условия). Формальный характер этих ошибок позволяет автоматизировать процесс логического тестирования . Существует большое количество инструментальных средств для верификации наборов правил и базы знаний в целом. Однако в ряде случаев, когда цепочки правил, используемых в процессе вывода, небольшие (от 3 до 10 правил), целесообразно проводить процесс верификации вручную.
Концептуальное тестирование проводится для проверки общей структуры системы и учета в ней всех аспектов решаемой задачи. На этом этапе проведение тестирования невозможно без привлечения конечных пользователей прикладной системы .
34. Характеристика этапа опытной эксплуатации проектирования экспертной системы
В ходе работ по созданию экспертных систем сложилась определенная технология их разработки, включающая шесть следующих этапов: идентификация, концептуализация, формализация, реализация, тестирование, опытная эксплуатация и внедрение.
В данной статье рассматривается шестой этап: опытная эксплуатация и внедрение.
На этапе опытной эксплуатации и внедрения проверяется пригодность экспертной системы для конечного пользователя. Здесь система занимается решением всех возможных задач при работе с различными пользователями. Целесообразно организовать работу системы не на стенде разработчика, а на месте работы пользователей. К этому этапу следует переходить лишь после того, как система, по мнению эксперта, будет успешно решать все требуемые задачи, чтобы ошибки в решениях не создавали у пользователя отрицательное представление о системе. Пригодность системы для пользователя определяется в основном удобством работы с ней и ее полезностью.
Под полезностью системы понимается способность системы в ходе диалога определить потребность пользователя, выявить и устранить причины неудач в работе и удовлетворить потребности пользователя (т.е. решить поставленные задачи). Говоря другими словами, пользователю важно «довести до сознания» системы свою информационную потребность, несмотря на возможные ошибки, допускаемые им в связи с недостаточным знанием системы. Конечно, для пользователя важны также полнота и правильность решений, но эти характеристики должны быть проверены экспертом на предыдущем этапе.
Под удобством работы с системой понимаются:
естественность взаимодействия с системой, т.е. общение в привычном, не утомляющем пользователя виде;
гибкость системы, т.е. способность системы настраиваться на различных пользователей, а также учитывать изменения в квалификации одного и того, же пользователя;
устойчивость системы к ошибкам, т.е. способность системы не выходить из строя при ошибочных действиях неопытного пользователя.
По результатам эксплуатации может потребоваться не только модификация правил и данных (совершенствование или изменение языка общения, диалоговых средств, средств обнаружения и исправления ошибок, настройка на пользователя и т.д.), но и изменение устройств ввода-вывода в связи с их неприемлемостью для пользователя. По результатам этого же этапа принимается решение о тиражировании системы. После успешного завершения этапа опытной эксплуатации и использования экспертной системы различными пользователями она может классифицироваться как промышленная экспертная система.
В целом в процессе опытной эксплуатации прототипа происходит уточнение требований к системе: разработчики и пользователи имеют возможность непосредственно изучить и устранить последствия принятых проектных решений. Принцип построения интерфейса WYSIWYG (What You See Is What You Get – что вы видите, то и получаете) позволяет пользователю непосредственно оценить результаты введенных в прототип изменений.
35. Статические и динамические экспертные системы
В середине 70-х годов прошлого столетия учеными стали разрабатываться первые экспертные системы , призванные помочь человеку в различных областях знаний принимать хладнокровные решения, основанные на знаниях многих людей-экспертов. Экспертные системы дают возможность не только принимать решения, но и «объясняют» мотивы его принятия, поскольку системы обладают способностью рассуждать о своих знаниях и способах принятия решений. Экспертные системы – это искуственный организм способный к умственному росту – системы допускают возможность пополнения своих знаний при взаимодействии с человеком – экспертом. Экспертные системы можно разделить на статические и динамические .
В статических экспертных системах не учитываются изменения окружающего мира в процессе решения задачи. Статическая экспертная система содержит базу знаний, правила, решатель, систему приобретения знаний, систему объяснения принятого решения и диалоговый компонент. База знаний статической экспертной системы состоит из двух частей, первая предназначена для хранения входных и промежуточных данных текущей задачи, вторая хранит долгосрочные знания, описывающие текущую область. Правила статической системы – целесообразные изменения данных области. Решатель – встроенный в систему модуль создающий последовательность правил, приводящих к решению задачи. Диалоговый компонент – программный модуль построения диалога между системой и пользователем. Динамическая экспертная система имеет ту же структуру что и статическая , за исключением того, что в динамическую систему добавлены два специальных модуля: модуль моделирования внешнего мира и модуль связи с внешним миром. Благодаря наличию этих модулей динамическая система может учитывать при решении задачи те изменения во внешнем окружении, которые происходят в этот момент. Динамические экспертные системы составляют 70% всех экспертных систем . Это связано с тем, что статические экспертные системы не позволяют представлять изменяющиеся во времени данные, поступающие от внешних источников, соответственно не обеспечивают их хранение и анализ. Динамические же системы помимо обработки временных данных проводят на их основе рассуждения о нескольких асинхронных процессах одновременно; обеспечивают гарантию того, что каждая задача будет решена в соответствии с временными ограничениями. Динамические системы позволяют моделировать окружающий мир и решать задачи, связанные с различными его состояниями. Динамические экспертные системы наполняют базу знаний в режиме реального времени с минимальными затратами времени и труда, поддерживают пользовательские интерфейсы для различных категорий пользователей, обеспечивают уровень защиты информации и предотвращают несанкционированный доступ. Первую оболочку Picon для создания динамических экспертных систем впервые выпустила для символьных ЭВМ Symbolics фирма Lisp Machine Inc в 1985 году. Picon имела большой успех, поэтому группа его разработчиков организовала фирму Gensym и , продолжив разработки, в 1988 году выпустила новую оболочку G2. Сейчас на рынке работает уже четвертая версия G2. Видя успех Gensym, другие компании начали создавать свои инструментальные средства для разработки динамических экспертных систем . Отметим среди них RT Works (фирма Talarian, США), COMDALE/C (Comdale Techn., Канада), COGSYS (SC, США), ILOG Rules (ILOG, Франция).
36. Нечеткий вывод знаний
37. Приобретение знаний
Введение.
Инженерия знаний – это область информационной технологий, цель которой
– накапливать и применять знания, не как объект обработки их человеком, но
как объект для обработки их на компьютере. Для этого необходимо
проанализировать знания и особенности их обработки человеком и
компьютером, а также разработать их машинное представление. К сожалению
точного и неоспоримого определения, что собой представляют знания, до сих
пор не дано. Но тем не менее цель инженерии знаний – обеспечить
использование знаний в компьютерных системах на более высоком уровне, чем
до сих пор – актуальна. Но следует заметить, что возможность использования
знаний осуществима только тогда, когда эти знания существуют, что вполне
объяснимо. Технология накопления и суммирования знаний идет бок о бок с
технологией использования знаний, они взаимно дополняют друг друга и ведут
к созданию одной технологии, технологии обработки знаний.
В данной работе я постарался описать методы решения одной из проблем
данного комплекса – это проблемы приобретения знаний, или говоря другими
словами – обучения.
Методы приобретения знаний.
Приобретение знаний реализуется с помощью двух функций: получения
информации извне и ее систематизации. При этом в зависимости от способности
системы обучения к логическим выводам возможны различные формы приобретения
знаний, а также различные формы получаемой информации. Форма представления
знаний для их использования определяется внутри системы, поэтому форма
информации, которую она может принимать, зависит от того, какие способности
имеет система для формализации информации до уровня знаний. Если
обучающаяся система совсем лишена такой способности, то человек должен
заранее подготовить все, вплоть до формализации информации, т. е. чем выше
способности машины к логическим выводам, тем меньше нагрузка на человека.
Функции, необходимые обучающейся системе для приобретения знаний,
различаются в зависимости от конфигурации системы. В дальнейшем при
рассмотрении систем инженерии знаний предполагается, что Существует система
с конфигурацией, показанной на рис, 1.1, которая включает базу знаний и
механизм логических выводов, использующий эти знания при решении задач.
Если база знаний пополняется знаниями о стандартной форме их представления,
то этими знаниями также можно воспользоваться. Следовательно, от функций
обучения требуется преобразование полученной извне информации в знания и
пополнение ими базы знаний.
Рис.1 Базовая структура систем обработки знаний
Можно предложить следующую классификацию систем приобретения знаний,
которая будет опираться на способность системы к восприятию знаний в разных
форматах, качественно различающихся между собой и способностью к
формализации (рис 2).
Рис 2.Классификация методов приобретения знаний.
Обучение без выводов.
Категорию А можно назвать обучением без выводов или механическим
запоминанием, это простой процесс получения информации, при котором
необязательны функции выводов, а полученная информация в виде программ или
данных используется для решения задач в неизменном виде. Другими словами,
это способ получения информации, характерный для существующих компьютеров.
Категория Б—это получение информации извне, представленной в форме знаний,
т. е. В форме, которую можно использовать для выводов. Обучающейся Системе
необходимо иметь функцию преобразования входной информации в формат,
удобный для дальнейшего использования и включения в базу знании.
Приобретение знаний на этом этапе происходит в наиболее простой форме: это
знания, предварительно подготовленные человеком во внутреннем формате,
какими являются большинство специальных знании, изначально заданных в
экспертных системах. В случае прикладных систем инженерии знаний необходимо
преобразовать специальные знания из какой-либо области в машинный формат,
но для этого нужен посредник, хорошо знающий как проблемную область, так и
инженерию знаний. Таких посредников называют инженерами по знаниям. В общем
случае для замены функции посредника можно использовать и специальные
подпрограммы. Т.е. необходимо иметь функции выводов достаточно высокого
уровня, но можно ограничиться и выводами на сравнительно низком уровне, а
остальное доверить человеку — в этом и состоит приобретение знаний в
диалоге. Примером служит хорошо известная система TEIRESIAS. Это система-
консультант в области медицины, разработанная на базе системы MYCIN.
Специалисты в проблемной области являются преподавателями обучающейся
системы, а ученик — система инженерии знаний — изучает ответы на
поставленные задачи и корректирует те правила в базе знаний, которые ранее
приводили к ошибкам. Для подготовки знаний в экспертной системе необходимы
вспомогательные средства типа редактора знаний, причем в процессе
приобретения знаний в диалоге не только редактируются отдельные правила и
факты, но и восполняются недостатки существующих правил, т. е. ведется
редактирование базы знаний.
Если знания заданы во внешнем формате, например на естественном языке, то
следует преобразовать их во внутренний формат. Для этого необходимо
понимать внешнее представление, т. е. естественный язык, графические данные
и т. п. Фактически приобретение знаний и их понимание тесно связаны.
Проблема понимания сводится не только к преобразованию структуры
предложений — необходимо получить формат, удобный для применения.
Аналогичная проблема — преобразование во внутренний формат советов,
подсказок по решению задач, что называется «операционализацией» знаний В
этом заключается центральная проблема искусственного интеллекта; она, в
частности, изучает преобразование советов, подсказок, представленных в
терминах проблемной области, в процедуры. Например, система UNDERSTAND
выполняет операционализацию представления задачи о ханойской башне на
английском языке путем построения соответствующих состояний и операций,
приводящих к этим состоя* киям.
38. Извлечение знаний из данных
Существует несколько стратегий получения знаний. Наиболее распространенные:
∙ приобретение;
∙ извлечение ;
∙ формирование.
Под приобретением знаний понимается способ автоматизированного построения базы знаний посредством диалога эксперта и специальной программы (при этом структура знаний заранее закладывается в программу). Эта стратегия требует существенной предварительной проработки предметной области. Системы приобретения знаний действительно приобретают готовые фрагменты знаний в соответствии со структурами, заложенными разработчиками систем. Большинство этих инструментальных средств специально ориентировано на конкретные экспертные системы с жестко обозначенной предметной областью и моделью представления знаний, т.е. не являются универсальными. Например, система TEIRESIAS [18], ставшая прародительницей всех инструментариев для приобретения знаний, предназначена для пополнения базы знаний системы MYCIN или ее дочерних ветвей, построенных на "оболочке" EMYCIN [10] в области медицинской диагностики с использованием продукционной модели представления знаний.
Термин извлечение знаний касается непосредственного живого контакта инженера по знаниям и источника знаний. Авторы склонны использовать этот термин как более емкий и более точно выражающий смысл процедуры переноса компетентности эксперта через инженера по знаниям в базу знаний экспертной системы.
Термин формирование знаний традиционно закрепился за чрезвычайно перспективной и активно развивающейся областью инженерии знаний, которая занимается разработкой моделей, методов и алгоритмов анализа данных для получения знаний и обучения. Эта область включает индуктивные модели формирования гипотез на основе обучающих выборок, обучение по аналогии и другие методы.
Таким образом, можно выделить три стратегии проведения стадии получения знаний при разработке экспертных систем (рис. 17.1).
На современном этапе разработки экспертных систем в нашей cтране стратегия извлечения знаний, по-видимому, является наиболее актуальной, поскольку промышленных систем приобретения и формирования знаний на отечественном рынке программных средств практически нет.
Извлечение знаний - то процедура взаимодействия эксперта с источником знаний, в результате которой становятся явными процесс рассуждений специалистов при принятии решения и структура их представлений о предметной области.
Рис. 17.1. Три стратегии получения знаний
В настоящее время большинство разработчиков экспертных систем отмечают, что процесс извлечения знаний остается самым "узким" местом при построении промышленных систем.
Процесс извлечения знаний - это длительная и трудоемкая процедура, в которой инженеру по знаниям, вооруженному специальными знаниями по когнитивной психологии [З], системному анализу, математической логике и пр., необходимо воссоздать модель предметной области, которой пользуются эксперты для принятия решения. Часто начинающие разработчики экспертных систем, желая избежать этой мучительной процедуры, задают вопрос: может ли эксперт сам извлечь из себя знания? По многим причинам это нежелательно.
Во-первых, большая часть знаний эксперта - это результат многочисленных наслоений, ступеней опыта. И часто зная, что из А следует В, эксперт не дает себе отчета, что цепочка его рассуждении была гораздо длиннее, например С ≈>D, D ≈> А, А ≈> В, или А ≈> Q,,═ Q->R,═R->B.
Во-вторых, как было известно еще древним (вспомним "Диалоги" Платона), мышление диалогично. И поэтому диалог инженера по знаниям и эксперта - наиболее естественная форма "раскручивания" лабиринтов памяти эксперта, в которых хранятся знания , частью носящие невербальный характер, т.е. выраженные не в форме слов, в форме наглядных образов, например. Именно в процессе объяснения инженеру по знаниям эксперт на эти размытые ассоциативные образы надевает четкие словесные ярлыки, т.е. вербализует знания .
В-третьих, эксперту гораздо труднее создать модель предметной области вследствие той глубины и необозримости информации, которой он обладает. Многочисленные причинно-следственные связи реальной предметной области образуют сложную систему, из которой выделить "скелет", или главную структуру, иногда доступнее аналитику, владеющему к тому же системной методологией. Любая модель - это упрощение, а упрощать легче с меньшим знанием деталей.
Чтобы разобраться в природе извлечения знаний , выделим три основных аспекта этой процедуры (рис. 17.2): психологический, лингвистический, гносеологический , которые подробно описаны в [4].
Рис. 17.2. Основные аспекты извлечения знаний |
39. Гносеологические аспекты извлечения знаний