Delphi | Сети | ПК | Маршрутизаторы | Моделирование | Протоколы | Экспертные системы | Художественные возможности материалов Удаленный доступ | Доменные имена развития компьютерной графики

Аплеты | SQL | Надежность | Задачи | Информационные процессы | Очередь JAVA | Отказы изделия | Расчет надежности показателей | Инфсис

Средства формирования пояснений Экспертные системы

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

• Обзор исследований в области искусственного интеллекта
• Символические вычисления
• Ассоциативные сети и системы фреймов Метод узловых и контурных уравнений Электротехника курсовая работа
• Логическое программирование
• Приобретение знаний
• Эвристическая классификация
• Проверка гипотез
• Решение проблем конструирования
• Инструментальные средства разработки экспертных систем
• Система отслеживания истинности предположений
• Сети доверия
• Гибридные системы
• Программирование на языке CLIPS

16.3. Перспективы дальнейших исследований методов формирования пояснений

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

Проект EES служит хорошим примером одного из направлений в современной методологии инженерии знаний, которое предполагает разделение процесса на этапы спецификации знаний и компиляции системы. Но пока что совершенно неясно, как такая методология может справиться с задачей комбинирования разных стратегий решения проблем в рамках единой системы (как это выполняется, например, в системе CENTAUR). Основная сложность в использовании этой методологии — большой объем предыстории разработки и необходимость использования чрезвычайно мощного генератора программ (см. об этом в [Neches et al, 1985]). Альтернативой такому подходу является усложнение интерпретатора включением в него мощных управляющих примитивов. В результате предыстория разработки сокращается и снижаются требования к функциональным возможностям генератора программ, но информация о принятии решений, касающихся поведения программы, оказывается спрятанной в программном коде интерпретатора. Интересно звучит предложение дополнительно нагрузить генератор программ — заставить его формировать и интерпретатор, и информацию, необходимую для формирования пояснений относительно управляющих функций. Это должно привести к еще большему разделению управляющих знаний и знаний о предметной абласти, но, предположительно, одновременно поставит перед разработчиками множество проблем, связанных с интеграцией компонентов системы.

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

(1) дифференциация знаний;

(2) явное представление стратегических и структурных знаний, которые в прежних системах оказывались скрытыми в программном коде;

(3) моделирование индивидуального уровня подготовки пользователя, работающего с экспертной системой.

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