Инструментальные средства разработки экспертных систем

Другие главы учебника "Экспертные системы"

17.4.1. Характерные сложности и способы их избежать

В своей книге Уотерман перечисляет следующие "ловушки", поджидающие разработчика экспертной системы на этапе внедрения, и дает рекомендации, как их избежать [Waterman, 1986, Chapter 19].

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

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

Как подобрать подходящий инструментарий для проектирования экспертной системы?
Насколько в действительности такие средства просты в обращении?
Что такое "хороший стиль программирования" в выбранной среде разработки?

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

Maya 3D графика в кино и телевидении Воздействие испытаний ядерного оружия на здоровье населения Объектно-ориентированный язык программирования Java Объектно-ориентированное программирование Delphi Библиотека визуальных компонентов VCL и ее базовые классы Кроссплатформенное программирование для Linux Элементы управления Win32 Элементы управления Windows XP Файлы и устройства ввода/вывода Что такое экспертная система? Объектно-ориентированное программирование Инструментальные средства разработки экспертных систем Программирование на языке CLIPS Критерии и количественные характеристики надежности Расчет характеристик надежности невостанавливаемых резервированных изделий Расчет надежности системы с постоянным резервированием Интегрирование тригонометрических функций ;