• Введение
• ГЛАВА 1. Что такое экспертная система?
• ГЛАВА 2. Обзор исследований в области искусственного интеллекта
• ГЛАВА 3. Представление знаний
• ГЛАВА 4. Символические вычисления
• ГЛАВА 5. Системы, основанные на знаниях
• ГЛАВА 6. Ассоциативные сети и системы фреймов
• ГЛАВА 7. Объектно-ориентированное программирование
• ГЛАВА 8. Логическое программирование
• ГЛАВА 9. Представление неопределенности знаний и данных
• ГЛАВА 10. Приобретение знаний
• ГЛАВА 11. Эвристическая классификация (I)
• ГЛАВА 12. Эвристическая классификация (II)
• ГЛАВА 13. Иерархическое построение и проверка гипотез
• ГЛАВА 14. Решение проблем конструирования (I)
• ГЛАВА 15. Решение проблем конструирования (II)
• ГЛАВА 16. Средства формирования пояснений
• ГЛАВА 17. Инструментальные средства разработки экспертных систем
• ГЛАВА 18. Системы с доской объявлений
• ГЛАВА 19. Система отслеживания истинности предположений
• ГЛАВА 20. Формирование знаний на основе машинного обучения
• ГЛАВА 21. Сети доверия
• ГЛАВА 22. Рассуждения, основанные на прецедентах
• ГЛАВА 23. Гибридные системы
• ГЛАВА 24. Заключение
СОДЕРЖАНИЕ
СОДЕРЖАНИЕ 2
Введение 8
ГЛАВА 1. Что такое экспертная система? 11
1.1. Смысл экспертного анализа 11
1.2. Характеристики экспертных систем 13
1.3. Базовые функции экспертных систем 14
1.3.1. Приобретение знаний 14
1.3.2. Представление знаний 16
1.3.3. Управление процессом поиска решения 18
1.3.4. Разъяснение принятого решения 18
1.4. Резюме и структура книги 20
1.4.1. Текущее состояние проблемы 20
1.4.2. Распределение материала книги по главам 21
Рекомендуемая литература 22
ГЛАВА 2. Обзор исследований в области искусственного интеллекта 23
2.1. Классический период: игры и доказательство теорем 24
2.1.1. Поиск в пространстве состояний 24
2.1.2. Эвристический поиск 28
2.2. Романтический период: компьютер начинает понимать 30
2.2.1. Система SHRDLU 30
2.2.2. Схемы представления знаний 32
2.3. Период модернизма: технологии и приложения 34
2.3.1. В знании сила 34
2.3.2. Периоды "зимней спячки" и "пробуждения" в истории искусственного интеллекта 37
Рекомендуемая литература 37
Упражнения 38
ГЛАВА 3. Представление знаний 44
3.1. Представление знаний: принципы и методы 44
3.2. Планировщик STRIPS 46
3.2.1. Таблицы операторов и методика "средство -анализ завершения" 47
3.2.2. Анализ метода представления и управления в STRIPS 50
3.3. Формулировка подцелей в MYGIN 51
3.3.1. Лечение заболеваний крови 51
3.3.2. База знаний системы MYCIN 52
3.3.3. Структуры управления в MYCIN 54
3.4. Оценка и сравнение характеристик экспертных систем 57
3.4.1. Оценка системы MYCIN 57
3.4.2. Сравнение MYCIN и STRIPS 58
Рекомендуемая литература 60
Упражнения 60
ГЛАВА 4. Символические вычисления 63
4.1. Символическое представление 64
4.2. Физическая символическая система 64
4.3. Реализация символических структур на языке LISP 65
4.3.1. Структуры данных в языке LISP 65
4.3.2. Структура LISP-программы 66
4.3.3. Приложение функции и лямбда-исчисление 67
4.3.4. Обработка списков 68
4.3.5. Сопоставление с образцом 69
4.4. Почему. LISP не является языком представления знаний 71
4.4.1. Символический уровень и уровень знаний 71
4.4.2. LISP и разработка программ 71
4.5. Языки представления знаний 72
Рекомендуемая литература 73
Упражнения 73
ГЛАВА 5. Системы, основанные на знаниях 75
5.1. Канонические системы 75
5.2. Системы порождающих правил для решения проблем 76
5.2.1. Синтаксис представления правил 76
5.2.2. Рабочая память 78
5.3. Управление функционированием интерпретатора 81
5.3.1. Разрешение конфликтов 81
5.3.2. Прямая и обратная цепочки рассуждений 83
5.3.3. Правила и метаправила 87
Рекомендуемая литература 89
Упражнения 89
ГЛАВА 6. Ассоциативные сети и системы фреймов 92
6.1. Графы, деревья и сети 92
6.2. Ассоциативные сети 95
6.2.1. Разделение видов узлов и когнитивная экономия 95
6.2.2. Анализ адекватности ассоциативных сетей 96
6.3. Представление типовых объектов и ситуаций 97
6.3.1. Основные понятия концепции фреймов 97
6.3.2. Фреймы и графы 98
6.3.3. Значения по умолчанию и демоны 99
6.3.4. Множественное наследование 102
6.3.5. Сравнение сетей и фреймов 104
Рекомендуемая литература 105
Упражнения 105
ГЛАВА 7. Объектно-ориентированное программирование 109
7.1. Язык KRL 109
7.2. Языки LOOPS и FLAVORS 111
7.2.1. Передача сообщений 111
7.2.2. Проблема наложения методов 113
7.2.3. Метаклассы 114
7.3. Языки CLIPS и CLOS 116
7.3.1. Множественное наследование в CLOS и CLIPS 116
7.3.2. Наложение методов в CLOS и CLIPS 117
7.3.3. Метаклассы в CLOS и CLIPS 119
7.4. Множественное наследование в C++ 120
7.5. Объектно-ориентированный анализ и конструирование экспертных систем 123
Рекомендуемая литература 124
Упражнения 124
ГЛАВА 8. Логическое программирование 126
8.1. Формальные языки 126
8.1.1. Исчисление высказываний 126
8.1.2. Исчисление предикатов 127
8.2. Язык PROLOG 129
8.3. Опровержение резолюций 130
8.3.1. Принцип резолюций 130
8.3.2. Поиск доказательства в системе резолюций 131
8.4. Процедурная дедукция в системе PLANNER 134
8.5. PROLOG и MBASE 135
8.5.1. Правила поиска в языке PROLOG 135
8.5.2. Управление поиском в системе MBASE 136
Рекомендуемая литература 139
Упражнения 139
ГЛАВА 9. Представление неопределенности знаний и данных 141
9.1. Источники неопределенности 141
9.2. Экспертные системы и теория вероятностей 142
9.2.1. Условная вероятность 142
9.2.2. Коэффициенты уверенности 144
9.2.3. Коэффициенты уверенности и условные вероятности 145
9.3. Сомнительность и возможность 147
9.3.1. Нечеткие множества 147
9.3.2. Нечеткая логика 149
9.3.3. Теория возможности 150
9.4. Неопределенное состояние проблемы неопределенности 151
Рекомендуемая литература 151
Упражнения 151
ГЛАВА 10. Приобретение знаний 153
10.1. Теоретический анализ процесса приобретения знаний 153
10.1.1. Стадии приобретения знаний 154
10.1.2. Уровни анализа знаний 154
10.1.3. Онтологический анализ 157
10.2. Оболочки экспертных систем 157
10.2.1. Система EMYCIN 157
10.2.2. Сопровождение и редактирование баз знаний с помощью программы TEIRESIAS 158
10.3. Методы приобретения знаний 160
10.3.1. Использование опроса экспертов для извлечения знаний в системе COMPASS 160
10.3.2. Автоматизация процесса извлечения знаний в системе OPAL 162
10.3.3. Графический интерфейс модели предметной области 163
10.3.4. Эффективность программы OPAL 165
10.4. Приобретение новых знаний на основе существующих 166
Рекомендуемая литература 167
Упражнения 167
ГЛАВА 11. Эвристическая классификация (I) 173
11.1. Классификация задач экспертных систем 174
11.2. Классификация методов решения проблем 176
11.2.1. Эвристическое сопоставление 176
11.2.2. Общность эвристической классификации 177
11.3. Классификация или конструирование? 181
Рекомендуемая литература 182
Упражнения 182
ГЛАВА 12. Эвристическая классификация (II) 188
12.1. Инструментальные средства и задачи, решаемые экспертной системой 188
12.2. Эвристическая классификация в системах MUD и MORE 189
12.2.1. Модель предметной области выполнения буровых работ 189
12.2.2. Стратегии приобретения знаний 193
12.2.3. Использование коэффициентов уверенности в программе MORE 196
12.2.4. Опыт эксплуатации системы MORE 197
12.3. Совершенствование стратегий 198
12.3.1. Уроки проекта GUIDON 198
12.3.2. Структура задач в системе NEOMYCIN 200
Рекомендуемая литература 201
Упражнения 201
ГЛАВА 13. Иерархическое построение и проверка гипотез 205
13.1. Влияние сложности пространства гипотез на организацию работы системы 205
13.1. Обход дерева 207
13.2. Структурированные объекты в CENTAUR 207
13.2.1. Структура фреймов в CENTAUR 207
13.2.2. Правила, включенные в прототипы 208
13.3. Формирование суждений на базе модели в системе INTERNIST 209
13.3.1. Представление знаний в дереве заболеваний 210
13.3.2. Методика выделения правдоподобных гипотез в INTERNIST 212
13.3.3. Проблемы, обнаруженные в процессе эксплуатации системы INTERNIST 213
13.4. Рабочая среда инженерии знаний TDE 214
Рекомендуемая литература 216
Упражнения 216
ГЛАВА 14. Решение проблем конструирования (I) 219
14.1. Области применения методов конструктивного решения проблем 219
14.2. Система R1/XCON 220
14.2.1. Компоненты и ограничения 221
14.2.2. Использование текущего контекста для управления структурой задачи 222
14.2.3. Формирование суждений с учетом ограничений: метод Match 225
14.3. Использование знаний, развитие и расширение системы XCON 226
14.3.1. Извлечение знаний в системе R1/XCON 227
14.3.2. Совершенствование и расширение системы R1/XCON 228
Рекомендуемая литература 230
Упражнения 230
ГЛАВА 15. Решение проблем конструирования (II) 233
15.1. Стратегии конструирования 233
15.2. Архитектура систем планирования и метапланирования 235
15.3. Извлечение, представление и применение знаний о проектировании 241
15.3.1. Реализация обратного прослеживания в системе VT 241
15.3.2. Приобретение знаний с помощью системы SALT 243
15.4. Итоги анализа систем решения проблем конструирования 244
Рекомендуемая литература 246
Упражнения 246
ГЛАВА 16. Средства формирования пояснений 249
16.1. Формирование пояснений на основе знаний 249
16.1.1. Подсистема формирования пояснений в MYCIN 250
16.1.2. Формирование пояснений в системах, производных от MYCIN 251
16.1.3. Формирование пояснений на основе фреймов 253
16.1.4. Организация вывода пояснений в системе CENTAUR 253
16.1.5. Использование мультимедийного интерфейса для формирования пояснений 259
16.2. Формирование пояснений и автоматическое программирование 260
16.2.1. Автоматическое программирование в системе XPLAN 260
16.2.2. Проект Explainable Expert Systems 261
16.2.3. Планирование текстов пояснений и модели пользователей в PEA 264
16.3. Перспективы дальнейших исследований методов формирования пояснений 265
Рекомендуемая литература 266
Упражнения 266
ГЛАВА 17. Инструментальные средства разработки экспертных систем 270
17.1. Общая характеристика инструментальных средств для построения экспертных систем 270
17.2. Оболочки экспертных систем 272
17.3. Языки программирования высокого уровня 273
17.3.1. Языки описания порождающих правил 274
17.3.2. Объектно-ориентированные языки 274
17.3.3. Языки логического программирования экспертных систем 275
17.3.4. Многофункциональные программные среды 276
17.3.5. Дополнительные модули 278
17.4. Использование инструментальных средств 280
17.4.1. Характерные сложности и способы их избежать 280
17.4.2. Выбор подходящего инструментария для разработки экспертной системы 281
17.4.3. Практическое освоение инструментальных средств 283
17.4.4. Стиль программирования 285
17.5. Некоторые максимы разработки экспертных систем 286
Рекомендуемая литература 287
Упражнения 287
ГЛАВА 18. Системы с доской объявлений 289
18.1. Принципы организации систем с доской объявлений 289
18.2. Системы HEARSAY, AGE и ОРМ 290
18.2.1. Почему для HEARSAY-II выбрана такая архитектура 291
18.2.2. Использование источников знаний в HEARSAY-II 291
18.2.3. Система HEARSAY-III— оболочка для создания систем с доской объявлений 292
18.2.4. Инструментальные среды AGE и ОРМ 293
18.3. Среда с доской объявлений ВВ 295
18.3.1. Уровни абстракции в среде ВВ 295
18.3.2. Системы ВВ1 и ACCORD 295
18.3.3. Система PROTEAN 296
18.3.4. Интеграция стратегий логического вывода 296
18.3.5. Общая характеристика ВВ 297
18.4. Эффективность и гибкость модели с доской объявлений 297
18.4.1. Организация доски объявлений в системе GBB 297
18.4.2. Компоновка доски объявлений в среде ERASMUS 299
18.5. Организация параллельных вычислений в системах CAGE и POLIGON 300
Рекомендуемая литература 301
Упражнения 301
ГЛАВА 19. Система отслеживания истинности предположений 303
19.1. Отслеживание зависимостей 303
19.1.1. Релаксация в сети 303
19.1.2. Пересмотр допущений 305
19.2. Пересмотр теорий высказываний 306
19.3. Немонотонное обоснование 308
19.4. Работа со множеством контекстов 310
19.4.1. Отслеживание истинности предположений, основанное на анализе допущений 310
19.4.2. Использование систем отслеживания истинности предположений для диагностирования на основе моделей 313
19.5. Сравнение различных вариантов организации систем отслеживания истинности предположений 316
Рекомендуемая литература 316
Упражнения 316
ГЛАВА 20. Формирование знаний на основе машинного обучения 318
20.1. Индуктивное обучение 319
20.2. Система Meta-DENDRAL 321
20.2.1. Формирование и уточнение правил 321
20.2.2. Пространство версий 323
20.2.3. Алгоритм отсеивания кандидатов 324
20.2.4. Сопоставление экземпляров с образцами в Meta-DENDRAL 325
20.3. Построение дерева решений и порождающих правил 326
20.3.1. Структура дерева решений 326
20.3.2. Алгоритм формирования дерева решений по обучающей выборке 328
20.4. Уточнение наборов правил 332
Рекомендуемая литература 334
Упражнения 334
ГЛАВА 21. Сети доверия 336
21.1. Теория Демпстера—Шефера 336
21.1.1. Функции доверия 336
21.1.2. Применение теории Демпстера—Шефера к системе MYCIN 337
21.2. Методика Перла 339
21.3. Сравнение методов неточных рассуждений 341
21.4. Резюме 342
Рекомендуемая литература 342
Упражнения 342
ГЛАВА 22. Рассуждения, основанные на прецедентах 344
22.1. База прецедентов 345
22.1.1. Программа CHEF 345
22.1.2. Методы извлечения и адаптации прецедентов 346
22.2. Обучение с помощью компьютера: система САТО 348
22.2.1. Предметная область программы САТО 348
22.2.2. Расследования и рассуждения в юриспруденции 348
22.2.3. Обучение с помощью системы САТО 349
22.3. Формирование отчетов в системе FRANK 351
22.4. Сравнение систем, основанных на правилах и прецедентах 353
Рекомендуемая литература 354
ГЛАВА 23. Гибридные системы 355
23.1. Методы обучения в системе ODYSSEUS 355
23.2. Системы ODYSSEUS и MINERVA 357
23.2.1. Оболочка экспертной системы MINERVA 358
23.2.2. Обучение в системе ODYSSEUS 358
23.3. Использование прецедентов для обработки исключений 359
23.4. Гибридный символический подход и нейронные сети 361
23.4.1. Нейронные сети 361
23.4.2. SCALIR — гибридная система для извлечения правовой информации 364
23.4.3. Организация обучения в системе SCALIR 367
23.5. Будущее гибридных систем 367
Рекомендуемая литература 368
Упражнения 368
ГЛАВА 24. Заключение 370
24.1. Загадка искусственного интеллекта 370
24.2. Представление знаний 371
24.3. Языки программирования систем искусственного интеллекта 373
24.4. Решение практических проблем 373
24.5. Архитектура экспертных систем 375
Рекомендуемая литература 375
Литература 377
Введение
При подготовке третьего издания книги Введение в экспертные системы автор старался прежде всего учесть интересы и пожелания читателей четырех основных категорий:
• рядовых читателей, желающих познакомиться с новым классом информационных систем на достаточно высоком теоретическом и техническом уровне;
• преподавателей и студентов, которым необходимо учебное пособие, охватывающее все основные темы исследования и проектирования экспертных систем, причем глубина изложения материала должна соответствовать программам старших курсов вузов и первого года обучения в аспирантуре;
• инженеров-программистов, нуждающихся в практическом руководстве по экспертным системам, подкрепленном достаточно солидным теоретическим материалом;
• научных работников и студентов, активно занимающихся научной работой, которых особенно интересует обзорный материал, касающийся новейших тенденций в разработке систем такого рода.
Это введение послужит методическим руководством для каждой из перечисленных категорий при изучении материала данной книги.
Рядовым читателям
Я старался таким образом излагать материал в этой книге, чтобы начальные разделы каждой главы носили по возможности описательный характер, а уже в последующих разделах переходить к техническим деталям. Идея состояла в том, чтобы читатель, который желает получить общее представление о той или иной теме, мог без особого ущерба для себя быстро просмотреть или вообще опустить последние разделы. Некоторые разделы и целые главы, помеченные значком , можно также при желании пропустить, что не помешает получить достаточно полное представление об экспертных системах.
Читателям, желающим познакомиться с основной проблематикой экспертных систем, я рекомендую в первую очередь прочитать следующие главы.
1. Что такое экспертная система.
2. Обзор исследований в области искусственного интеллекта.
3. Представление знаний.
5. Системы, основанные названиях.
6. Ассоциативные сети и системы фреймов.
9. Представление неопределенности знаний и данных.
10. Приобретение знаний.
11. Эвристическая классификация (I).
14. Решение проблем конструирования (I).
16. Средства формирования пояснений.
17. Инструментальные средства разработки экспертных систем.
20. Формирование знаний на основе машинного обучения.
22. Рассуждения, основанные на прецедентах.
24. Заключение.
Материал остальных глав можно считать дополнительным, что, впрочем, зависит от индивидуальных интересов и наклонностей каждого отдельного читателя.
Студентам и преподавателям
Студентам старших курсов я бы рекомендовал выбрать для вводного курса по экспертным системам следующие главы.
1. Что такое экспертная система.
2. Обзор исследований в области искусственного интеллекта.
3. Представление знаний.
5. Системы, основанные на знаниях.
6. Ассоциативные сети и системы фреймов.
9. Представление неопределенности знаний и данных.
10. Приобретение знаний.
11. Эвристическая классификация (I).
14. Решение проблем конструирования (I).
16. Средства формирования пояснений.
17. Инструментальные средства разработки экспертных систем.
24. Заключение.
Приложение. Программирование на языке CLIPS.
Язык CLIPS послужит вам удобным инструментом для выполнения упражнений, поскольку он не требует разработки модулей кода значительного объема.
Для аспирантов, интересующихся проблемами искусственного интеллекта, особый интерес представляет материал следующих глав.
1. Что такое экспертная система.
5. Системы, основанные на знаниях.
6. Ассоциативные сети и системы фреймов.
9. Представление неопределенности знаний и данных.
10. Приобретение знаний.
11. Эвристическая классификация (I).
12. Эвристическая классификация (II).
14. Решение проблем конструирования (I).
15. Решение проблем конструирования (II).
16. Средства формирования пояснений.
17. Инструментальные средства разработки экспертных систем.
24. Заключение.
Приложение. Программирование на языке CLIPS.
Инженерам-программистам
Инженерам-программистам, которые интересуются прежде всего практическими вопросами проектирования экспертных систем, я бы рекомендовал в первую очередь обратить внимание на следующие главы.
4. Символические вычисления.
5. Системы, основанные на знаниях.
7. Объектно-ориентированное программирование.
8. Логическое программирование.
11. Эвристическая классификация (I).
12. Эвристическая классификация (II).
14. Решение проблем конструирования (I).
15. Решение проблем конструирования (II).
16. Средства формирования пояснений.
17. Инструментальные средства разработки экспертных систем.
18. Системы с доской объявлений,
19. Система отслеживания истинности предположений. Приложение. Программирование на языке CLIPS.
Остальные главы можно читать по мере необходимости.
Научным работникам
В последних главах книги описаны результаты новейших исследований в области структурной организации экспертных систем, поэтому их следует сопоставлять с материалом предыдущих глав. Я советую читателям этой категории обратить основное внимание на следующие главы.
3. Представление знаний.
5. Системы, основанные на знаниях.
6. Ассоциативные сети и системы фреймов.
8. Логическое программирование.
9. Представление- неопределенности знаний и данных.
10. Приобретение знаний.
13 Иерархическое построение и проверка гипотез.
16. Средства формирования пояснений.
18. Системы с доской объявлений.
19. Система отслеживания истинности предположений.
20. Формирование знаний на основе машинного обучения.
21. Сети доверия.
22. Рассуждения, основанные на прецедентах.
23. Гибридные системы.
Хочу обратить ваше внимание на то, что третье издание книги имеет менее прямолинейную структуру, чем первое и второе. При группировании материала во главу угла ставились не определенные модели экспертных систем, а используемые алгоритмы или методики. Я также включил в книгу множество примеров, в том числе и текстов программ, и различный дополнительный материал во врезках.
◦ ГЛАВА 1. Что такое экспертная система?
◦ 1.1. Смысл экспертного анализа
◦ 1.2. Характеристики экспертных систем
◦ 1.3. Базовые функции экспертных систем
▪ 1.3.1. Приобретение знаний
▪ 1.3.2. Представление знаний
▪ 1.3.3. Управление процессом поиска решения
▪ 1.3.4. Разъяснение принятого решения
◦ 1.4. Резюме и структура книги
▪ 1.4.1. Текущее состояние проблемы
▪ 1.4.2. Распределение материала книги по главам
◦ Рекомендуемая литература
◦ Упражнения
ГЛАВА 1. Что такое экспертная система?
• 1.1. Смысл экспертного анализа
• 1.2. Характеристики экспертных систем
• 1.3. Базовые функции экспертных систем
• 1.4. Резюме и структура книги
• Рекомендуемая литература
• Упражнения
День сегодня с утра не задался. Вы только что установили новую версию текстового редактора, к которому давно привыкли, но после щелчка на его ярлыке компьютер реагирует совсем не так, как хотелось бы, — выводится сообщение вроде этого:
Call to Undefined Link (Вызов неопределенной связи).
Как и большинство сообщений об ошибках, это помогает не больше, чем предсказания судьбы по состоянию Марса. Вы применяете крайнюю меру — удаляете целый каталог и переинсталлируете программу, но результат от этого не меняется. Вы начинаете менять настройки в разных файлах инициализации, но это тоже не помогает.
Наконец, устав от безнадежных попыток, вы набираете номер сервисной службы поддержки пользователей. И только после этого фортуна поворачивается к вам лицом — на помощь приходит человек, который знает, о чем говорит. Он советует вам выбросить с полдюжины устаревших DLL-модулей в системном каталоге и вновь переустановить программу. Последовав его совету, вы.уже через десяток минут можете нормально работать, и подскочившее недавно кровяное давление вновь возвращается к норме.
Какой бы уровень экспертного анализа не требовался в данной области, ясно, что специалист из сервисной службы способен его сделать, а вы — нет. Хотя в ящике стола у вас лежит диплом доктора философии по специальности "Информатика", и вы, возможно, прекрасно программируете задачи в своей области, но, не имея определенного опыта и подготовки, проблему устранения неисправности решить не смогли. Таким образом, способность выполнить экспертный анализ — это не только вопрос наличия определенных знаний и уровня квалификации. Для этого нужно обладать и очень специфическими навыками и умением разобраться в конкретной ситуации в данной предметной области. Таким образом, быть экспертом и иметь общее образование — это далеко не одно и то же.
1.1. Смысл экспертного анализа
Задумайтесь над таким вопросом: "При выполнении каких условий компьютерную программу можно назвать экспертом?"
• Вполне логично потребовать, чтобы такая программа обладала знаниями. Просто способность выполнять некоторый алгоритм, например производить анализ списка элементов на наличие какого-либо свойства, явно не отвечает этому требованию. Это все равно, что дать первому случайному прохожему список вопросов и ответов и ожидать от него успешного выполнения поиска и устранения неисправностей в системах определенного типа. Раньше или позже, но он обязательно столкнется с ситуацией, не предусмотренной в том списке, которым его снабдили.
• Знания, которыми обладает программа, должны быть сконцентрированы на определенную предметную область. Случайный набор имен, дат и мест событий, сентенций из классиков и т.п. — это отнюдь не те знания, которые могут послужить основой для программы, претендующей на способность выполнить экспертный анализ. Знания предполагают определенную организацию и интеграцию — то есть отдельные сведения должны соотноситься друг с другом и образовывать нечто вроде цепочки, в которой одно звено "тащит" за собой следующее.
• И, наконец, из этих знаний должно непосредственно вытекать решение проблем. Просто продемонстрировать свои знания, касающиеся, например, технического обслуживания компьютеров, — это далеко не то же самое, что привести компьютер в "чувство". Точно так же, получить доступ к оперативной документации — это совсем не то же самое, что заполучить в свое распоряжение специалиста (или программу), способного справиться с возникшими проблемами.
Теперь попробуем подытожить эти рассуждения в следующем формальном определении экспертной системы.
Экспертная система — это программа для компьютера, которая оперирует со знаниями в определенной предметной области с целью выработки рекомендаций или решения проблем.
Экспертная система может полностью взять на себя функции, выполнение которых обычно требует привлечения опыта человека-специалиста, или играть роль ассистента для человека, принимающего решение. Другими словами, система (техническая или социальная), требующая принятия решения, может получить его непосредственно от программы или через промежуточное звено — человека, который общается с программой. Тот, кто принимает решение, может быть экспертом со своими собственными правами, и в этом случае программа может "оправдать" свое существование, повышая эффективность его работы. Альтернативный вариант — человек, работающий в сотрудничестве с такой программой, может добиться с ее помощью результатов более высокого качества. Вообще говоря, правильное распределение функций между человеком и машиной является одним из ключевых условий высокой эффективности внедрения экспертных систем.
Технология экспертных систем является одним из направлений новой области исследования, которая получила наименование искусственного интеллекта (Artificial Intelligence — AI). Исследования в этой области сконцентрированы на разработке и внедрении компьютерных программ, способных эмулировать (имитировать, воспроизводить) те области деятельности человека, которые требуют мышления, определенного мастерства и накопленного опыта. К ним относятся задачи принятия решений, распознавания образов и понимания человеческого языка. Эта технология уже успешно применяется в некоторых областях техники и жизни общества — органической химии, поиске полезных ископаемых, медицинской диагностике. Перечень типовых задач, решаемых экспертными системами, включает:
извлечение информации из первичных данных (таких как сигналы, поступающие от гидролокатора);
диагностика неисправностей (как в технических системах, так и в человеческом организме);
структурный анализ сложных объектов (например, химических соединений);
выбор конфигурации сложных многокомпонентных систем (например, распределенных компьютерных систем);
планирование последовательности выполнения операций, приводящих к заданной цели (например, выполняемых промышленными роботами).
Хотя известны и "обычные" программы, специализирующиеся на определенных задачах из представленного перечня (или аналогичных им в смежных областях), в следующей главе мы покажем, в чем состоит существенная разница между "обычным" подходом и прелагаемым в сфере искусственного интеллекта и почему экспертные системы можно выделить в отдельный, достаточно хорошо различимый класс программ. Четкого формального определения экспертной системы, которое всех бы удовлетворило, не существует — приведенное выше тоже довольно расплывчато. Но тем не менее существует довольно много важных признаков, присущих в той или иной степени всем экспертным системам
1.2. Характеристики экспертных систем
Экспертная система отличается от прочих прикладных программ наличием следующих признаков.
• Моделирует не столько физическую (или иную) природу определенной проблемной области, сколько механизм мышления человека применительно к решению задач в этой проблемной области. Это существенно отличает экспертные системы от систем математического моделирования или компьютерной анимации. Нельзя, конечно, сказать, что программа полностью воспроизводит психологическую модель специалиста в этой предметной области (эксперта), но важно, что основное внимание все-таки уделяется воспроизведению компьютерными средствами методики решения проблем, которая применяется экспертом, -т.е. выполнению некоторой части задач так же (или даже лучше), как это делает эксперт.
• Система, помимо выполнения вычислительных операций, формирует определенные соображения и выводы, основываясь на тех знаниях, которыми она располагает. Знания в системе представлены, как правило, на некотором специальном языке и хранятся отдельно от собственно программного кода, который и формирует выводы и соображения. Этот компонент программы принято называть базой знаний.
• При решении задач основными являются эвристические и приближенные методы, которые, в отличие от алгоритмических, не всегда гарантируют успех. Эвристика, по существу, является правилом влияния (rule of thumb), которое в машинном виде представляет некоторое знание, приобретенное человеком по мере накопления практического опыта решения аналогичных проблем. Такие методы являются приблизительными в том смысле, что, во-первых, они не требуют исчерпывающей исходной информации, и, во-вторых, существует определенная степень уверенности (или неуверенности) в том, что предлагаемое решение является верным.
Экспертные системы отличаются и от других видов программ из области искусственного интеллекта.
• Экспертные системы имеют дело с предметами реального мира, операции с которыми обычно требуют наличия значительного опыта, накопленного человеком. Множество программ из области искусственного интеллекта являются сугубо исследовательскими и основное внимание в них уделяется абстрактным математическим проблемам или упрощенным вариантам реальных проблем (иногда их называют "игрушечными" проблемами), а целью выполнения такой программы является "повышение уровня интуиции" или отработка методики. Экспертные системы имеют ярко выраженную практическую направленность в научной или коммерческой области.
• Одной из основных характеристик экспертной системы является ее производительность, т.е. скорость получения результата и его достоверность (надежность). Исследовательские программы искусственного интеллекта могут и не быть очень быстрыми, можно примириться и с существованием в них отказов в отдельных ситуациях, поскольку, в конце концов, — это инструмент исследования, а не программный продукт. А вот экспертная система должна за приемлемое время найти решение, которое было бы не хуже, чем то, которое может предложить специалист в этой предметной области.
• Экспертная система должна обладать способностью объяснить, почему предложено именно такое решение, и доказать его обоснованность. Пользователь должен получить всю информацию, необходимую ему для того, чтобы быть уверенным, что решение принято "не с потолка". В отличие от этого, исследовательские программы "общаются" только со своим создателем, который и так (скорее всего) знает, на чем основывается ее результат. Экспертная система проектируется в расчете на взаимодействие с разными пользователями, для которых ее работа должна быть, по возможности, прозрачной.
Зачастую термин система, основанная на знаниях (knowledge-based system), используется в качестве синонима термина экспертная система, хотя, строго говоря, экспертная система — это более широкое понятие. Система, основанная на знаниях, — это любая система, процесс работы которой основан на применении правил отношений к символическому представлению знаний, а не на использовании алгоритмических или статистических методов. Таким образом, программа, способная рассуждать о погоде, будет системой, основанной на знаниях, даже в том случае, если она не способна выполнить метеорологическую экспертизу. А вот чтобы иметь право называться метеорологической экспертной системой, программа должна быть способна давать прогноз погоды (другой вопрос — насколько он будет достоверен).
Суммируя все сказанное, отметим — экспертная система содержит знания в определенной предметной области, накопленные в результате практической деятельности человека (или человечества), и использует их для решения проблем, специфичных для этой области. Этим экспертные системы отличаются от прочих, "традиционных" систем, в которых предпочтение отдается более общим и менее связанным с предметной областью теоретическим методам, чаще всего математическим. Процесс создания экспертной системы часто называют инженерией знаний (knowledge engineering) и он рассматривается в качестве "применения методов искусственного интеллекта" (см. [Feigenbaum, 1977]). Далее, в главах 2 и 3, мы более пристально рассмотрим отличие между общепринятым в программировании подходом к решению проблем и тем, который предлагается при проектировании экспертных систем.
В оставшейся части этой главы мы рассмотрим следующие вопросы. Сначала будут перечислены четыре базовые функции, которые реализуются в экспертных системах. Эти функции здесь будут рассмотрены очень поверхностно, с единственной целью дать читателю общее представление о них и познакомить с соответствующей терминологией. Последний раздел главы даст читателю представление об общей структуре материала в этой книге и о его распределении по главам
1.3. Базовые функции экспертных систем
Поскольку теория экспертных систем выросла из более общей концепции искусственного интеллекта, то нет ничего удивительного в том, что проблематика этих областей имеет много общего. На некоторых из таких связей акцентируется внимание в последующих разделах при обзоре литературы. Вы также встретите в них ссылки на последующие главы этой книги, в которых та или иная тема будет рассмотрена подробно.
1.3.1. Приобретение знаний
Бучанан следующим образом сформулировал функцию приобретения знаний [Buchanan et al, 1983]:
"[Приобретение знаний это] передача потенциального опыта решения проблемы от некоторого источника знаний и преобразование его в вид, который позволяет использовать эти знания в программе".
Передача знаний выполняется в процессе достаточно длительных и пространных собеседований между специалистом по проектированию экспертной системы (будем в дальнейшем называть его инженером по знаниям) и экспертом в определенной предметной области, способным достаточно четко сформулировать имеющийся у него опыт. По существующим оценкам, таким методом можно сформировать от двух до пяти "элементов знания" (например, правил влияния) в день. Конечно, это очень низкая скорость, а потому многие исследователи рассматривают функцию приобретения знаний в качестве одного из главных "узких мест" технологии экспертных систем [Feigenbaum, 1977].
Причин такой низкой производительности предостаточно. Ниже перечислены только некоторые из них.
• Специалисты в узкой области, как правило, пользуются собственным жаргоном, который трудно перевести на обычный "человеческий" язык (см. врезку 1.1). Но смысл жаргонного "словечка" отнюдь не очевиден, а потому требуется достаточно много дополнительных вопросов для уточнения его логического или математического значения. Например, специалисты по военной стратегии говорят об "агрессивной демонстрации" иностранной военной мощи, но при этом не могут объяснить, чем такая "агрессивная" демонстрация отличается от демонстрации, не несущей угрозы.
• Факты и принципы, лежащие в основе многих специфических областей знания эксперта, не могут быть четко сформулированы в терминах математической теории или детерминированной модели, свойства которой хорошо понятны. Так, эксперту в финансовой области может быть известно, что определенные события могут стать причиной роста или снижения котировок на фондовой бирже, но он ничего вам не скажет точно о механизмах, которые приводят к такому эффекту, или о количественной оценке влияния этих факторов. Статистические модели могут помочь сделать общий долговременный прогноз, но, как правило, такие методы не работают в отношении курсов конкретных акций на коротких временных интервалах.
• Для того чтобы решить проблему в определенной области, эксперту недостаточно просто обладать суммой знаний о фактах и принципах в этой области. Например, опытный специалист знает, какого рода информацией нужно располагать для формулировки того или иного суждения, насколько надежны различные источники информации и как можно расчленить сложную проблему на более простые, которые можно решать более или менее независимо. Выявить в процессе собеседования такого рода знания, основанные на личном опыте и плохо поддающиеся формализации, значительно сложнее, чем получить простой перечень каких-то фактов или общих принципов.
• Экспертный анализ даже в очень узкой области, выполняемый человеком, очень часто нужно поместить в довольно обширный контекст, который включает и многие вещи, кажущиеся эксперту само собой разумеющимися, но для постороннего отнюдь таковыми не являющиеся. Возьмем для примера эксперта-юриста, который принимает участие в судебном процессе. Очень трудно очертить количество и природу знаний общего рода, которые оказываются вовлечены в расследование того или иного дела.
1.1. Забытый пароль
Если у вас память ненамного лучше моей, то вы, вероятно, тоже часто забываете свои пароли на разных компьютерах. Как системному администратору, назовем его Сэмом, восстановить ваш пароль? Наш начинающий инженер по знаниям Кен пытается выяснить у администратора, как он это делает.
Сэм: Так вот, если это YP-пароль, я первым делом регистрируюсь как "root" на YP-главном.
Кен: А что такое YP-главный?
Сэм: Это дисковая машина, на которой установлена база данных с информацией обо всей сети.
Кен: А "дисковая машина" означает...
Сэм: Что на ней ОС установлена на локальном диске.
Кен: Ах вот что. (Почесывает в затылке) Итак, ты регистрируешься на...
Сэм: Как "root". Затем я редактирую файл данных паролей, удаляю зашифрованный элемент и создаю новую карту паролей.
Кен: ...карту паролей. (Насмешливо) А что произойдет, если ты забудешь собственный пароль?
Сэм: На дисковой машине я мог бы перегрузиться и запуститься в однопользовательском режиме или можно было бы загрузить MINI ROOT. Тогда можно редактировать /etc/password. Или можно переустановить всю систему, но этого я скорее всего делать не буду. Корневые пароли обычно не включаются в YP. На бездисковой машине клиента я мог бы воспользоваться командой passwd.
Кен: Уф-ф-ф. (Сожалеет, что взялся за onpoc)
Конечно, бедный Кен старался, как мог. Возможно, ему было бы полегче, если бы перед разговором со специалистом он заглянул в Руководство системного администратора и освоился хотя бы с основной терминологией.
Неудовлетворительные результаты подобных собеседований пробудили у некоторых исследователей интерес к автоматизации процесса передачи знаний специалистом машине. Одно из направлений исследований в этой области — автоматизированное извлечение знаний (automated knowledge elicitation) — появилось как побочный продукт в развитии систем человеко-машинного диалога (см. главу 10). Другие исследователи полагают, что "расшить" это узкое место можно, двигаясь по пути машинного обучения (machine learning). Идея состоит в том, чтобы машина училась решать проблемы примерно так, как учится человек (см. главу 20).
1.3.2. Представление знаний
Представление знаний — еще одна функция экспертной системы. Теория представления знаний — это отдельная область исследований, тесно связанная с философией формализма и когнитивной психологией. Предмет исследования в этой области — методы ассоциативного хранения информации, подобные тем, которые существуют в мозгу человека. При этом основное внимание, естественно, уделяется логической, а не биологической стороне процесса, опуская подробности физических преобразований.
1.2. Синтаксис и семантика представления семейных отношений
Основная часть представления знаний, на которую часто даже не обращают особого внимания, состоит в том, что представление должно каким-то образом "стандартизировать" семантическое разнообразие человеческого языка. Вот несколько предложений.
"Сэм — отец Билла". "Сэм — Биллов отец". "Биллов отец — Сэм".
"Отцом Билла является Сэм".
Все эти фразы выражают одну и ту же мысль (семантически идентичны). При машинном представлении этой мысли (знания) мы стараемся найти более простой метод сопоставления формы и содержания, чем в обычном человеческом языке, т.е. добиться того, чтобы выражения с одинаковым (или похожим) содержанием были одинаковыми и по форме. Например, все приведенные выше фразы могут быть сведены к выражению в такой форме:
отец (сэм, билл).
В семантике этого выражения должно быть специфицировано (наряду с прочими вещами) и то, что первое имя принадлежит родителю, а второе — потомку, а не наоборот.
Можно также заметить, что предложения
"Сэм — отец Джилла".
"Отцом Билла является Сэм".
имеют похожий смысл, но более очевидно ранжировать их в такой форме:
отец (сэм, билл). отец (сэм, джилл).
О синтаксисе и семантике мы поговорим более подробно в главах 3 и 8.
В 70-х годах исследования в области представления знаний развивались в направлениях раскрытия принципов работы памяти человека, создания теорий извлечения сведений из памяти, распознавания и восстановления. Некоторые из достигнутых в теории результатов привели к созданию компьютерных программ, которые моделировали различные способы связывания понятий (концептов). Появились компьютерные приложения, которые могли некоторым образом отыскивать нужные "элементы" знания на определенном этапе решения некоторой проблемы. Со временем психологическая достоверность этих теорий отошла на второй план, а основное место, по крайней мере с точки зрения проблематики искусственного интеллекта, заняла их способность служить инструментом для работы с новыми информационными и управляющими структурами.
В общем, вопрос представления знания был и скорее всего останется вопросом противоречивым. Философы и психологи зачастую бывают шокированы бесцеремонностью специалистов по искусственному интеллекту, которые бойко болтают о человеческом знании на жаргоне, представляющем дикую смесь терминологии, взятой из логики, логистики, философии, психологии и информатики. С другой стороны, компьютерный формализм оказался новаторским средством постановки, а иногда и поиска ответов на трудные вопросы, над которыми столетиями бились метафизики.
В области экспертных систем представление знаний интересует нас в основном как средство отыскания методов формального описания больших массивов полезной информации с целью их последующей обработки с помощью символических вычислений. Формальное описание означает
упорядочение в рамках какого-либо языка, обладающего достаточно четко формализованным синтаксисом построения выражений и такого же уровня семантикой, увязывающей смысл выражения с его формой. Мы отложим обсуждение вопросов синтаксиса и семантики до главы 3.
Символические вычисления означают выполнение нечисловых операций, в которых могут быть сконструированы символы и символьные структуры для представления различных концептов и отношений между ними. Обсуждение проблем символьных вычислений мы отложим до главы 4. Пример символического представления вы найдете во врезке 1.2.
В области искусственного интеллекта ведется интенсивная работа по созданию языков представления (representation languages). Под этим термином понимаются компьютерные языки, ориентированные на организацию описаний объектов и идей, в противовес статическим последовательностям инструкций или хранению простых элементов данных. Основными критериями доступа к представлению знаний являются логическая адекватность, эвристическая мощность и естественность, органичность нотации. Эти термины, скорее всего, нуждаются в пояснениях.
• Логическая адекватность означает, что представление должно обладать способностью распознавать все отличия, которые вы закладываете в исходную сущность. Например, невозможно представить идею, что каждое лекарство имеет какой-либо побочный нежелательный эффект, если только нельзя будет провести отличие между предназначением конкретного лекарственного препарата и его побочным эффектом (например, аспирин усугубляет язвенную болезнь). В более общем виде выражение, передающее этот эффект, звучит так: "каждое лекарство обладает нежелательным побочным эффектом, специфическим для этого препарата".
• Эвристическая мощность означает, что наряду с наличием выразительного языка представления должно существовать некоторое средство использования представлений, сконструированных и интерпретируемых таким образом, чтобы с их помощью можно было решить проблему. Часто оказывается, что язык, обладающий большей выразительной способностью в терминах количества семантических отличий, оказывается и больше сложным в управлении описанием взаимосвязей в процессе решения проблемы. Способность к выражению у многих из найденных формализмов может оказаться достаточно ограниченной по сравнению с английским языком или даже стандартной логикой. Часто уровень эвристической мощности рассматривается по результату, т.е. по тому, насколько легко оказывается извлечь нужное знание применительно к конкретной ситуации. Знать, какие знания более всего подходят для решения конкретной проблемы, — это одно из качеств, которое отличает действительно специалиста, эксперта в определенной области, от новичка или просто начитанного человека.
• Естественность нотации следует рассматривать как некую добродетель системы, поскольку большинство приложений, построенных на базе экспертных систем, нуждается в накоплении большого объема знаний, а решить такую задачу довольно трудно, если соглашения в языке представления слишком сложны. Любой специалист скажет вам, что при прочих равных характеристиках лучше та система, с которой проще работать. Выражения, которыми формально описываются знания, должны быть по возможности простыми для написания, а их смысл должен быть понятен даже тому, кто не знает, как же компьютер интерпретирует эти выражения. Примером может служить декларативный программный код, который сам по себе дает достаточно четкое представление о процессе его выполнения даже тому, кто не имеет представления о деталях реализации компьютером отдельных инструкций.
• За прошедшие годы было предложено немало соглашений, пригодных для кодирования знаний на языковом уровне. Среди них отметим порождающие правила (production rules) [Davis and King, 1977], структурированные объекты (structured objects) [Findler, 1979] и логические программы (logic programs) [Kowalski, 1979]. В большинстве экспертных систем используется один или несколько из перечисленных формализмов, а доводы в пользу и против любого из них до сих пор представляют собой тему для оживленных дискуссий среди теоретиков. Несколько формализмов такого рода критически рассмотрены в главах 5-8, а программные средства для их реализации — в главах 17-19.
Большинство фрагментов программного кода, приведенных в этой книге, написано на языке CLIPS, в котором используется комбинация порождающих правил и структурированных объектов. В Приложении вы найдете достаточно пространное описание основных концепций и программных конструкций языка CLIPS, которое сопровождается множеством примеров. Там же читатель сможет найти и нетривиальные программы, в которых продемонстрированы как многие интересные возможности языка, так и реализация его средствами методов искусственного интеллекта, обсуждаемых в главах 1-3.
1.3.3. Управление процессом поиска решения
При проектировании экспертной системы серьезное внимание должно быть уделено и тому, как осуществляется доступ к знаниям и как они используются при поиске решения [Davis, 1980, а]. Знание о том, какие знания нужны в той или иной конкретной ситуации, и умение ими распорядиться — важная часть процесса функционирования экспертной системы. Такие знания получили наименование метазнаний — т.е. знаний о знаниях. Решение нетривиальных проблем требует и определенного уровня планирования и управления при выборе, какой вопрос нужно задать, какой тест выполнить, и т.д.
Использование разных стратегий перебора имеющихся знаний, как правило, оказывает довольно существенное влияние на характеристики эффективности программы. Эти стратегии определяют, каким способом программа отыскивает решение проблемы в некотором пространстве альтернатив (см. главы 2 и 3). Как правило, не бывает так, чтобы данные, которыми располагает программа работы с базой знаний, позволяли точно "выйти" на ту область в этом пространстве, где имеет смысл искать ответ.
Большинство формализмов представления знаний может быть использовано в разных режимах управления (см. врезку 1.3), и разработчики экспертных систем продолжают экспериментировать в этой области. В последующих главах будут описаны системы, которые специально подобраны таким образом, чтобы проиллюстрировать отличия в существующих подходах к решению проблемы управления. В каждой из представленных систем есть что-нибудь полезное для студентов, специализирующихся в области разработки и исследования экспертных систем.
1.3. Обслуживание автомобиля
Представьте себе, что ваш автомобиль с трудом заводится, а в пути явно чувствуется снижение мощности. Сами по себе эти симптомы недостаточны для того, чтобы принять решение, где же искать источник неисправности — в топливной или электросистеме автомобиля. Познания в устройстве автомобиля подсказывают — нужно еще поэкспериментировать, прежде чем звать на помощь механика. Возможно, плоха топливная смесь, поэтому присмотритесь к выхлопу и нагару на свечах. Возможно, сбоит распределитель — посмотрите, не повреждена ли его крышка. Эти довольно специфические эвристики не гарантируют, что отыщется действительная причина, но вдруг вам улыбнется фортуна, и вы найдете неисправность без утомительной процедуры последовательной проверки всех систем.
Скорее всего, ваших знаний достаточно для того, чтобы выполнить общую проверку, прежде чем заниматься доскональным изучением отдельных узлов. Например, посмотреть, достаточно ли мощная искра в свече (если это так, то подозрения с электросистемы можно снять), прежде чем проверять аккумулятор. При отсутствии специальных эвристик, чем более методично вы будете действовать, тем больше шансов быстро найти причину неисправности. Общее эвристическое правило гласит:
"Сначала проверь весь узел, а уже потом приступай к проверке его компонентов".
Это правило можно считать частью режима управления — систематической стратегии применения имеющихся знаний. Другое эвристическое правило можно сформулировать, например, так:
"Сначала меняй более дешевые детали, а уже потом берись за более дорогие".
В некоторых случаях эти две эвристики могут противоречить друг другу, так что нужно заранее выбрать, какая из них имеет приоритет в случае, если обе включены в один и тот же режим управления.
1.3.4. Разъяснение принятого решения
Вопрос о том, как помочь пользователю понять структуру и функции некоторого сложного компонента программы, связан со сравнительно новой областью взаимодействия человека и машины, которая появилась на пересечении таких областей, как искусственный интеллект, промышленная технология, физиология и эргономика. На сегодня вклад в эту область исследователей, занимающихся экспертными системами, состоит в разработке методов представления информации о поведении программы в процессе формирования цепочки логических заключений при поиске решения.
Представление информации о поведении экспертной системы важно по многим причинам.
• Пользователи, работающие с системой, нуждаются в подтверждении того, что в каждом конкретном случае заключение, к которому пришла программа, в основном корректно.
• Инженеры, имеющие дело с формированием базы знаний, должны убедиться, что сформулированные ими знания применены правильно, в том числе и в случае, когда существует прототип.
• Экспертам в предметной области желательно проследить ход рассуждений и способ использования тех сведений, которые с их слов были введены в базу знаний. Это позволит судить, насколько корректно они применяются в данной ситуации.
• Программистам, которые сопровождают, отлаживают и модернизируют систему, нужно иметь в своем распоряжении инструмент, позволяющий заглянуть в "ее нутро" на уровне более высоком, чем вызов отдельных языковых процедур.
• Менеджер системы, использующей экспертную технологию, который в конце концов несет ответственность за последствия решения, принятого программой, также нуждается в подтверждении, что эти решения достаточно обоснованы.
Способность системы объяснить методику принятия решения иногда называют прозрачностью системы. Под этим понимается, насколько просто персоналу выяснить, что делает программа и почему. Эту характеристику системы следует рассматривать в совокупности с режимом управления, о котором шла речь в предыдущем разделе, поскольку последовательность этапов принятия решения тесно связана с заданной стратегией поведения. Более подробно связь этих характеристик будет рассмотрена в главе 16.
Отсутствие достаточной прозрачности поведения системы не позволит эксперту повлиять на ее производительность или дать совет, как можно ее повысить. Прослеживание и оценка поведения системы — задача довольно сложная и для ее решения необходимы совместные усилия эксперта и специалиста по информатике (подробно этот вопрос рассматривается в главах 3, 13 и 17).
1.4. Загадка одного портрета
В одной известной загадке человек смотрит на портрет и говорит:
"У меня нет братьев и сестер, но отец этого человека — это сын моего отца".
Спрашивается: 'Кто изображен на портрете?" Во-первых, потратьте пару минут и решите эту загадку. Во-вторых, представьте себе, как вы будете объяснять ход решения кому-нибудь постороннему, но при этом нельзя пользоваться никакими вспомогательными средствами вроде карандаша и бумаги. Для многих эта загадка представляется головоломной, причем немало и таких, которые не могут проследить за ходом уже описанного решения (Smullyan, 1978].
Ответ прост: отец смотрит на портрет сына (человек, который смотрит на портрет, — отец человека, изображенного на портрете). Как мы пришли к такому заключению, станет ясно после того, как мы воспользуемся логическим представлением. Пусть Пит — человек на портрете, а Люк — человек, который смотрит на портрет.
"...это сын моего отца".
сын(отец(люк)), отец(пит).
"У меня нет братьев и сестер..."
for all X,
if сын(отец(люк), X) then Х=люк.
Здесь сын — это отношение между двумя людьми, а отец — функция, поскольку каждый имеет только одного отца. Из этого утверждения после подстановки совершенно очевидно следует
отец(пит) = люк. Таким образом, Люк смотрит на портрет своего сына.
Правильное логическое представление зачастую значительно упрощает решение задачи и делает его более понятным. Но сформировать такое представление — это в значительной мере искусство. Объяснение не всегда имеет форму доказательства, как в данном случае, о чем будет подробно рассказано в главе 16
1.4. Резюме и структура книги
В этой главе я старался не только обратить внимание на сильные стороны экспертных систем, но прямо указать на присущие им ограничения. Таким образом, читатель, не знакомый с этой проблематикой, должен, по крайней мере, получить представление о том, чего можно ожидать от такого типа систем и насколько возможно приложение описанных в этой книге идей в той области, в которой читатель работает. Ниже я дам обзор остального материала книги и скажу о том, на какие главы следует обратить внимание читателям разных категорий в зависимости от круга их интересов. Этот материал в значительной мере повторяет предисловие к данной книге, но поскольку большинство читателей, как правило, предисловие перелистывают, не читая (я в этом смысле не исключение), то думаю, такое повторение имеет определенный смысл
1.4.1. Текущее состояние проблемы
Потенциальный пользователь экспертной системы чаще всего задается вопросом: "А сможет ли она решить мои проблемы?" Ответ уклончивый: "Смотря какие". Существуют три фактора, от которых зависит окончательный ответ, — природа проблемы, наличие определенного опыта в той предметной области, к которой относится проблема, и возможность сопоставления результатов анализа проблемы и имеющегося опыта методом, доступным компьютерной программе. Потенциальному пользователю следует сначала задуматься над следующим: есть ли у него на примете эксперт, который
• способен решить проблему;
• знает, как решается проблема;
• способен объяснить другому, как решается проблема;
• располагает временем, чтобы объяснить другому, как решается проблема;
• имеет достаточные побудительные мотивы к активному участию в этом предприятии.
Например, предсказание погоды — это не та задача, которую может решить кто-либо, даже умудренный большим опытом эксперт. Распознавание речи — это задача, которую решает практически каждый, но никто из нас (включая и профессиональных лингвистов) не может вразумительно объяснить, как это делается. А потому использовать для решения этой проблемы методы, основанные на анализе знаний, вряд ли удастся. Здесь большего следует ожидать от статистического моделирования. Даже имея на примете гениального эксперта, знающего, как решается задача, нельзя рассчитывать на успех, если этот эксперт не может или не желает подробно и вразумительно объяснить, как он это делает. Эксперт может быть не расположен к общению с посторонними или слишком занят, чтобы терять время на длительные собеседования с инженером, которому поручено проектирование базы знаний. Как правило, эксперт высокого класса не испытывает недостатка в предложениях работы в той области, с которой он хорошо знаком, а потому предпочитает выполнять ее, а не вести пространные беседы о том, как он это делает. Есть еще и психологический фактор — многие эксперты весьма ревниво относятся к своему уникальному опыту и не склонны его разглашать, поскольку считают (и нам нечего возразить им), что, передавая опыт автоматизированным системам, они рубят сук, на котором сидят.
Но даже если удастся выполнить оговоренные выше условия, в задаче могут существовать факторы, ограничивающие возможность "машинного" воспроизведения человеческого опыта. Например:
• в процессе решения задачи используются способности органов чувств человека, недоступные на сегодняшний день в мире машин;
• в решение задачи вовлечены соображения здравого смысла человечества или большой объем знаний, само собой разумеющихся для любого человека (более подробно об этом — в главе 3).
Очень важно отделить те знания, владение которыми характерно именно для эксперта в определенной области, от тех знаний, которые известны любому, выполняющему в этой области рутинную работу. Управление автомобилем при езде по забитым транспортом улицам требует не столько знаний эксперта, сколько умения мгновенно оценивать ситуацию и быстро на нее реагировать. Хотя современные роботы такой скоростью и таким умением не владеют, вряд ли кто-нибудь назовет такого водителя "экспертом" (по крайней мере, в моем родном Рочестере, шт. Нью-Йорк).
Нельзя упускать из виду и огромный объем знаний об окружающем мире, которым мы все располагаем: знаниями о предметах и их свойствах, людях и мотивации их действий, взаимосвязях в физическом мире и наиболее вероятном течении событий в тех или иных условиях — список можно продолжать до бесконечности. Эту совокупность знаний мы не включаем в знания, отличающие эксперта, но до сих пор еще совсем не ясно, насколько они важны компьютеру для решения узкоспециальной проблемы. Таким образом, любая задача, которую не удается "инкапсулировать" в ограниченный перечень фактов и правил, на сегодняшний день не под силу экспертным системам.
С другой стороны, проблемы, которые могут быть решены перечислением ассоциативных связей между обозримыми совокупностями данных и классами событий, прекрасно подходят для экспертных систем. Например, проблемы, связанные с функционированием промышленных систем (тепловые, вентиляционные или кондиционирования)— диагностика, мониторинг состояния и т.д.,— могут решаться системами, основанными на анализе формальных правил, связывающих энергопотребление здания с параметрами окружающей среды. Уже на нынешнем этапе с помощью экспертных систем решаются задачи эскизного конструирования многокомпонентных объектов из заданного набора примитивов. С примерами такого рода систем вы познакомитесь в, главах 14 и 15
1.4.2. Распределение материала книги по главам
В табл. 1.1 суммированы темы, обсуждавшиеся в разделе 1.3, и указаны главы, в которых'эти темы рассматриваются подробно. Рядовому читателю, скорее всего, будут интересны темы, касающиеся представления знания и управления процессом анализа, поскольку это ключевые проблемы в технологии экспертных систем. Темы восприятия знаний и объяснения принятого решения имеют не меньшее значение при построении экспертных систем, но они носят более прикладной характер.
В главах 2 и 3 рассматриваются базовые концепции технологии экспертных систем. В главе 2 дан краткий обзор нынешнего состояния исследований в области искусственного интеллекта, которые создали предпосылки для развития исследований по созданию экспертных систем. Глава 3 также имеет вводный характер и в ней описаны ранние разработки систем такого рода, рассматриваются цели их создания и принципы функционирования.
Таблица 1.1. Содержание глав
Тема
Определение
Главы
Овладение знаниями
Передача опыта решения проблемы от человека программе
10-15,20
Представление знаний
Кодирование информации об опыте решения проблем внутри машины
2-9,21-23
Управление процессом поиска решения
Принятие решения о последовательности использования имеющихся знаний
3, 11, 12, 17-19
Объяснение принятых решений
Передача информации о ходе решения проблемы пользователю
3,5, 16,23
В главах 3-9 освещаются основные схемы представления проблемно-ориентированных знаний в программах и методы применения этих знаний к решению сложных проблем с помощью компьютера. Мы начнем с краткого обзора работ в области символических вычислений, а затем перейдем к анализу некоторых специализированных языков представления знаний, таких как CLIPS. Будут также рассмотрены и возможности использования для построения экспертных систем объектно-ориентированных языков общего назначения, подобных C++. И в завершение этой части книги будет рассмотрена проблема приблизительных рассуждений и различные качественные и количественные методы оценки неопределенности.
В главах 10-16 речь пойдет о технических вопросах конструирования экспертных систем. Мы начнем с проблемы восприятия знаний, т.е. рассмотрим, каким образом можно передать технической системе знания, накопленные человеком-экспертом, как их преобразовать в форму, удобную для хранения и дальнейшего использования этой системой на основе методов, описанных в предыдущих главах. В последующих главах рассматриваются парадигмы решения проблем, которые целесообразно использовать для таких задач, как диагностика и конструирование. Этот материал будет проиллюстрирован примерами, описанными в разных источниках. При отборе примеров в расчет принимались скорее доводы педагогики, чем -технические характеристики систем, а потому те, которые описаны, не следует рассматривать, как самые лучшие в своем классе. Тем не менее в этих системах есть много поучительного, на что имеет смысл обратить внимание.
В главах 17-19 анализируются инструментарий и структура программного обеспечения экспертных систем. Мы начнем с критического обзора разного рода сред разработки, используемых при проектировании программного обеспечения экспертных систем. Затем будут описаны два типа структурной организации: системы с доской объявлений (blackboard systems) и системы обработки правдоподобия {truth maintenance systems).
В заключительных главах книги мы затронем более сложные темы: машинное обучение, сети доверия (правдоподобия), логический вывод, базирующийся на прецедентах, и гибридные экспертные системы.
Рекомендуемая литература
Обзоры ранних исследований в области экспертных систем опубликованы в работах [Barr and Feigenbaum, 1982], [Hayes-Roth et al., 1983], [Buchanan and Shortliffe, 1984] и [Waterman, 1986].
Применение технологии экспертных систем в разных предметных областях описано в работах [Weiss and Kulikowski, 1983], [Klahr and Waterman, 1986], [Gale, 1986] и [Quinlan, 1987].
Читателям, интересующимся применением экспертных систем в промышленности, следует заглянуть в работу [Feigenbaum et al., 1988]. Кроме того, множество обзоров такого рода регулярно публикуется в отраслевых изданиях, в частности в Expert Systems Review for Business and Accounting.
Из работ последних лет следует обратить внимание на книги [Harmon and Sawyer, 1990], [Giarratano andRiley, 1994] и [Stefik, 1995].
◦ ГЛАВА 2. Обзор исследований в области искусственного интеллекта
◦ 2.1. Классический период: игры и доказательство теорем
▪ 2.1.1. Поиск в пространстве состояний
▪ 2.1.2. Эвристический поиск
◦ 2.2. Романтический период: компьютер начинает понимать
▪ 2.2.1. Система SHRDLU
▪ 2.2.2. Схемы представления знаний
◦ 2.3. Период модернизма: технологии и приложения
▪ 2.3.1. В знании сила
▪ 2.3.2. Периоды "зимней спячки" и "пробуждения" в истории искусственного интеллекта
◦ Рекомендуемая литература
◦ Упражнения
ГЛАВА 2. Обзор исследований в области искусственного интеллекта
2.1. Классический период: игры и доказательство теорем
2.2. Романтический период: компьютер начинает понимать
2.3. Период модернизма: технологии и приложения
Рекомендуемая литература
Упражнения
Что такое искусственный интеллект? Барр и Файгенбаум предложили следующее определение, которое никем не оспаривается почти два десятка лет [Barr and Feigenbaum, 1981].
"Искусственный интеллект (ИИ) — это область информатики, которая занимается разработкой интеллектуальных компьютерных систем, т.е. систем, обладающих возможностями, которые мы традиционно связываем с человеческим разумом, — понимание языка, обучение, способность рассуждать, решать проблемы и т.д."
Другими словами, исследования в области искусственного интеллекта направлены на разработку программ, решающих такие задачи, с которыми сейчас лучше справляется человек, поскольку они требуют вовлечения таких функций человеческого мозга, как способность к обучению на основе восприятия, особой организации памяти и способности делать выводы на основе суждений [Minsky, 1968].
Таким образом, разработка программы, которая будет выполнять сложную статистическую обработку данных, нельзя рассматривать как исследование в области искусственного интеллекта, какие бы сложные алгоритмы в ней не использовались. А вот создание программы порождения и проверки гипотез относится именно к этой области. Большинство людей не обладают возможностью выполнять в уме арифметические действия уже с трехразрядными числами, а компьютеры превосходно справляются с гораздо более сложными вычислениями. Но, с другой стороны, разделить процесс проверки гипотез на
отдельные эксперименты — это искусство, которое исследователь постигает как в результате специального обучения, так и на собственном опыте. Составить компьютерную программу, которая выполняла бы то же самое, — задача далеко не тривиальная.
Конечно, как в каждой новой области, и здесь существуют разные точки зрения на главное предназначение исследований по искусственному интеллекту. Некоторые ученые склоняются к тому, что искусственный интеллект является ответвлением технических наук, поскольку основное направление исследований в этой сфере — создание интеллектуальных искусственных существ, скажем роботов [Nilsson, 1971]. Другие делают упор на связях с теми областями, которые занимаются механизмом познания, — процессами обработки информации в мозгу человека.
Но как бы там ни было, никто не отрицает, что основные усилия в этой области предпринимаются в направлении эмуляции мышления человека — разработке методов, которые позволили бы запрограммировать машину таким образом, чтобы она могла моделировать (воспроизводить) или даже превосходить способности человеческого разума. Исследования в этой области тесно связаны со смежными — информатикой (наукой об обработке информации с помощью компьютеров), психологией и лингвистикой. Тот факт, что исследования в области искусственного интеллекта часто "вторгаются" в смежные области, иногда приводит к определенным трениям в научной среде, но гораздо чаще результатом является появление новых и неожиданных идей.
В этой главе я постараюсь сделать краткий обзор исследований в области искусственного интеллекта, выполненных за последние пять десятилетий, уделяя особое внимание тем из них, которые имеют отношение к проблематике экспертных систем. Также будет рассмотрен вопрос, в чем состоит отличие программирования, основанного на знаниях, от обычной технологии программирования, с одной стороны, и обобщенных методов решения проблем, которые развивали пионеры в области искусственного интеллекта, — с другой.
Историю исследований в этой области, начиная примерно с 1950 года и по сегодняшний день, можно разделить на три периода. За основу периодизации мы взяли те направления исследований, которые наиболее активно развивались в течение каждого из них, — как в смысле наибольшей активности ученых, так и в смысле получения наиболее существенных практических результатов. Более подробную информацию о становлении искусственного интеллекта как научного направления читатель найдет в книгах, перечисленных в библиографической справке в конце главы.
2.1. Классический период: игры и доказательство теорем
Исследования в области искусственного интеллекта начались практически сразу же после появления компьютеров и первых опытов по их применению для других, более "приземленных" целей. Все началось с того, что вскоре после окончания Второй мировой войны были предприняты попытки решать с помощью компьютера игровые задачи и головоломки. Конечнтикой экспертных систем и недостаточно серьезны, чтобы дать что-нибудь полезное для реальных приложений. Однако сейчас, оглядываясь назад, можно проследить, как некоторые идеи и подходы к решению проблем с помощью компьютера выросли именно из этих первых экспериментов.
2.1.1. Поиск в пространстве состояний
Фундаментальная идея, которая появилась в результате этих первых опытов, получила наименование поиск в пространстве состояний. По существу, идея очень проста. Множество проблем можно сформулировать в терминах трех важнейших ингредиентов:
исходное состояние проблемы, например исходное состояние головоломки;
тест завершения — проверка, достигнуто ли требуемое конечное состояние или найдено решение проблемы (примером может послужить правило определения, собрана ли головоломка);
множество операций, которые можно использовать для изменения текущего состояния проблемы, например шаги или перемещения фигур при сборке головоломки.
Один из способов представления такого концептуального пространства состояний — граф, в котором состояниям соответствуют узлы, а операциям — дуги. Рассмотрим в качестве примера задачу построения слова из некоторого множества букв, как в игре Scrabble. Задавшись набором операций установки букв, можно сформировать пространство состояний.
Предположим, что множество доступных букв включает Т, С и А. На каждом уровне графа мы будем добавлять по одной определенной букве. Каждая ветвь, исходящая из узла, соответствует установке буквы в определенную позицию в последовательности, а эта последовательность должна образовать осмысленное слово (рис. 2.1). Если это произошло, то головоломка считается собранной (например, если образовалась комбинация "act" или "cat"). (Сейчас мы не будем стремиться собрать какое-нибудь сложное слово вроде "scrabble", которое может принести играющему больше очков.)
Рис. 2.1. Дерево пространства состояний головоломки Scrabble с буквами Т, С и А
Это пространство состояний обладает двумя интересными свойствами, которые присущи далеко не всем пространствам состояний:
оно конечно, поскольку существует только п! способов расставить я букв;
оно не содержит повторяющихся узлов, что может привести к образованию петель на графе.
Метод формирования анаграмм последовательным перечислением является примером применения алгоритма, получившего наименование generate-and-test (порождение и проверка).
(1) Генерировать новое состояние, модифицируя существующее; например, изменить последовательность букв, добавив новую в существующую последовательность.
(2) Проверить, не является ли образовавшееся состояние конечным (решением); например, проверить, не является ли образовавшаяся последовательность осмысленным словом. Если это так, то завершить, иначе перейти к шагу (1).
Множество решений, которые удовлетворяют условию на шаге (2), иногда называют пространством решений. В некоторых головоломках, например в уже упомянутой "8 ферзей", решений много, а в других существует всего несколько или только одно. Действительно, существует довольно много способов разместить восемь ферзей на шахматной доске так, чтобы ни один из них не оказался под боем, а вот для головоломки "8-Puzzle" существует единственное решение (см. упр. 7).
Алгоритм имеет два основных варианта: поиск в глубину (depth-first search) и поиск в ширину (breadth-first search). Отличаются варианты порядком формирования состояний на шаге (1). Действительные алгоритмы приведены в упр. 5, а здесь мы дадим только их неформальное описание.
Для любого данного узла N алгоритм поиска в глубину строит потомок этого узла, т.е. формирует состояние, которое образуется в результате применения операторов к узлу N, а потом переходит к формированию узла, ближайшего к N, на том же уровне графа ("соседу" N), т.е. формирует состояние, которое образуется в результате применения оператора к узлу-родителю N. Алгоритм поиска в ширину действует наоборот — сначала формируются все "соседи" узла N, а потом уже строятся его потомки. Таким образом, в алгоритме поиска в ширину просматриваются последовательно состояния, представленные узлами одного и того же уровня на графе (рис. 2.2), а в алгоритме поиска в глубину просматриваются состояния на одном пути, а затем происходит возврат назад на один уровень и формируется следующий путь (рис. 2.3).
Рис. 2.2. Граф пространства состояний при использовании алгоритма поиска в ширину
Рис. 2.3. Граф пространства состояний при использовании алгоритма поиска в глубину
На обоих рисунках числа на дугах графа указывают номер шага, на котором формируется тот узел (состояние), для которого эта дуга является входящей. Конечно, этот номер еще зависит и от того, в каком порядке используются операторы из имеющегося множества. В представленном примере сначала применяется оператор, добавляющий очередную букву в конец последовательности, затем оператор, добавляющий букву на предпоследнюю позицию, и т.д., а последним применяется оператор, добавляющий букву на первое место. Но ведь можно использовать и обратный порядок применения операторов.
Оба алгоритма завершат работу (найдут конечное состояние) после формирования узла "act", а не "cat". Но алгоритму поиска в ширину придется для этого "посетить" пять узлов (сформировать и проанализировать пять состояний), а алгоритму поиска в глубину — четыре.
Отметим, что свойства этих алгоритмов существенно отличаются.
Алгоритм поиска в ширину отыскивает решение, путь к которому на графе — кратчайший, если таковое существует. Другими словами, он находит кратчайший путь между исходным состоянием и решением. Алгоритмы, обладающие таким свойством, называются разрешимыми (admissible).
Алгоритм поиска в глубину может быстрее найти решение, особенно, если при его выполнении используются эвристики для выбора очередной ветви. Но этот алгоритм может никогда не закончиться, если пространство состояний бесконечно.
Нетрудно заметить, что число узлов растет экспоненциально по мере увеличения числа уровней на графе. Это явление часто называют комбинаторным взрывом и оно представляет очень серьезную проблему при программировании таких задач, например при "грубом" переборе всех возможных вариантов позиций в игре в шахматы (см. врезку 2.1). Поскольку человеческий мозг слабее компьютера при решении задач, связанных с перебором вариантов, естественно предположить, что серьезный шахматист решает эту задачу каким-то другим способом. Скорее всего он использует свой опыт, воображение и аналитические способности, во-первых, для формирования общей стратегии игры, а во-вторых, для выбора наилучшего очередного хода. Вот такой-то способ решения мы и называем "интеллектуальным", в отличие от "грубого перебора".
В игровых программах также используется поиск в пространстве состояний, но стратегия поиска более избирательна, чем в случае прямого применения алгоритма generate-and-test. Кроме того, нужно принимать во внимание и то, что в игре, как правило, принимают участие две противоборствующие стороны. Были разработаны довольно неплохие программы для игры в шашки, нарды и шахматы. Созданные программы игры в шахматы нельзя отнести к классу систем, основанных на знаниях, а скорее к классу программ, обладающих способностью избирательно анализировать пространство состояний, что значительно повышает скорость и эффективность анализа. Методы и алгоритмы этого класса в данной книге рассматриваться не будут.
Другая задача, которая занимала умы исследователей в области искусственного интеллекта в середине 50-х годов, — доказательство теорем. Смысл задачи доказательства состоит в том, чтобы показать, как некоторое утверждение, которое требуется доказать (теорема), логически следует из декларированного множества других утверждений или аксиом (которые полагаются истинными или являются такими априори).
2.1. Комбинаторный взрыв
Исследованием вычислительной обозримости (или необозримости) проблем занимается теория сложности. Для начала нам потребуется только знать, что существуют классы проблем, решение которых требует ресурсов, экспоненциально возрастающих при линейном увеличении размерности задачи. Например, время, необходимое для отыскания пути в лабиринте, экспоненциально увеличивается при увеличении количества разветвлений в лабиринте. Аналогично, время, необходимое для поиска доказательства теоремы исчислением утверждений, растет экспоненциально по отношению к количеству переменных. Такие проблемы являются в общем случае необозримыми и называются NP-hard. Читателей, которые ими заинтересуются, мы отсылаем к специальной литературе, в частности книге Хопкрофта и Ульмана [Hopcroft and Ullman, 1979].
Проблемы, время решения которых связано с размерностью задачи полиномиальной функции, считаются обозримыми. Например, проверка заданного маршрута в лабиринте или проверка правильности доказательства некоторой теоремы — обозримые проблемы. Но можно показать, что, к сожалению, большинство проблем, которые интересуют нас в области искусственного интеллекта, относятся к классу NP-hard. Поэтому такое важное значение придается использованию эвристических методов при их решении.
Прекрасное изложение теории вычислительной сложности, рассчитанное на читателя, несклонного к излишнему теоретизированию, можно найти в работе Паунд-стоуна [Poundstone, 1988, Chapter 9].
Рассмотрим такой пример. Пусть имеются две аксиомы, представленные на некотором формальном языке:
"Если компьютер может ошибаться, он ошибется" и
"Мой компьютер может ошибаться".
Тогда, используя механизм исчислений только правил влияния, мы можем показать, что справедлива теорема.
"Мой компьютер ошибется".
Это утверждение логически следует из заданных аксиом в том смысле, что оно не может быть ложным, если истинны исходные утверждения (аксиомы). Корректности такого следствия легко доказываются компьютером — все, что от него требуется, так это обработать выражения в форме логической зависимости:
(любой Х)(F(X)) G(X))
F(a) / [G(a){X/a}]
которое читается следующим образом:
"Все элементы F являются элементами G, а входит в F, следовательно, F есть G".
Как и в случае с головоломками, некоторые концепции и методы, разработанные в области машинного доказательства теорем (иногда эту область исследований называют automated reasoning — машинным поиском логического вывода), весьма помогут студентам при решении практических проблем. Итак, знания, касающиеся решения некоторой проблемы, можно представить как набор аксиом, т.е. теорию, а процесс поиска решения проблемы можно рассматривать как попытку доказать теорему, каковой является искомое решение (подробнее об этом — в главе 8). Другими словами, поиск решения среди сформулированных теорем аналогичен поиску пути на графе в пространстве состояний и для его анализа можно использовать тот же аппарат.
К сожалению, процесс порождения всех возможных теорем, вытекающих из заданного множества аксиом, имеет все черты комбинаторного взрыва, поскольку на основе первичных теорем, непосредственно вытекающих из аксиом, можно сформулировать новое множество теорем и т.д. Поиск решения посредством доказательства теорем может повлечь за собой такое количество вычислений, с которым не справится никакой мыслимый компьютер, и можно доказать, что некоторые из таких вычислений даже теоретически никогда не смогут завершиться. В области машинного поиска логического вывода существенные успехи достигнуты в направлении, которое связано с генерацией формальных математических доказательств, но эти методы с трудом приложимы к менее формализованным областям. Поскольку большинство человеческих особей не обладают выдающимися способностями в области построения логических выводов, да еще принимая во внимание комбинаторные сложности, вряд ли стоит рассчитывать на существенное влияние участия человека в формальных рассуждениях такого рода. Скорее помощь может проявиться в том, что человек сможет делать более правдоподобные предположения или порождать более вероятные гипотезы, носящие неформальный характер. Это именно тот вид заключений, который используется при моделировании путей поиска решения реальных проблем в экспертных системах
2.1.2. Эвристический поиск
Поскольку слепой поиск возможен только в небольшом пространстве вариантов, напрашивается совершенно естественный вывод, что необходим некоторый способ направленного поиска. Если такой способ использует при поиске пути на графе в пространстве состояний некоторых знаний, специфических для конкретной предметной области, его принято называть эвристическим поиском. Лучше всего рассматривать эвристику в качестве некоторого правила влияния, которое, хотя и не гарантирует успеха (как детерминированный алгоритм или процедура принятия решения), в большинстве случаев оказывается весьма полезным.
Простая форма эвристического поиска — это восхождение на гору. В процессе поиска в программе использует некоторая оценочная функция, с помощью которой можно грубо оценить, насколько "хорошим" (или "плохим") является текущее состояние. Затем можно применить ту же функцию для выбора очередного шага, переводящего систему в следующее состояние.
Например, простая оценочная функция для программы игры в шахматы может включать очевидную оценку материала (количества и качества имеющихся на доске фигур) — своего и соперника. Затем программа перебирает возможные операторы перехода в новое состояние (возможные ходы фигур) и, сравнивая результаты вариантов, отыскивает такой, который характеризуется максимальным значением оценочной функции. Другими словами, ищется такой ход, который дает наибольший материальный выигрыш.
Основной алгоритм, реализующий идею восхождения на гору, можно сформулировать следующим образом.
(1) Находясь в данной точке пространства состояний, применить правила порождения нового множества возможных решений, например множества ходов фигур, допустимых в данной позиции.
(2) Если одно из новых состояний является решением проблемы, прекратить процесс. В противном случае перейти в то состояние, которое характеризуется наивысшим значением оценочной функции. Вернуться к шагу (1).
Но применение этого подхода наталкивается на хорошо известные трудности. Главная из них — как сформулировать оценочную функцию, которая адекватно бы отражала "качество" текущего состояния. Продолжая наш пример с игрой в шахматы, заметим, что иметь много фигур, больше чем у соперника, отнюдь не значит иметь лучшую позицию, т.е. быть ближе к успеху. Такая простая оценочная функция не учитывает многих особенностей этой игры (а в более широком контексте — особенностей данной предметной области).
Более того, даже если оценочная функция и позволяет адекватно оценить текущую ситуацию, сущестЬуют разнообразные ситуации игры, которые сами по себе могут быть источником затруднений. Например, в данном состоянии нет очевидного очередного хода, т.е. оказывается, что все возможные ходы одинаково хороши (или плохи). Это не что иное, как выход на "плато" в нашем восхождении, когда ни один из возможных путей не влечет за собой подъем. Другой
возможный источник затруднений — наличие локальных максимумов, из которых возможен только спуск, т.е. "ухудшение" состояния. Например, я могу взять вашего ферзя и после этого проиграть партию.
Лучшими свойствами обладает другая форма эвристического поиска, которая получила наименование сначала наилучший (best-first search). Так же, как и в варианте восхождения на гору, в нашем распоряжении имеется оценочная функция, с помощью которой можно сравнивать состояния в пространстве состояний. Основное же отличие нового метода от ранее рассмотренного состоит в том, что сравниваются не только те состояния, в которые возможен переход из текущего, но и все, до которых "можно достать".
Такой алгоритм, естественно, требует значительно больших вычислительных ресурсов, но идея состоит в том, чтобы принимать во внимание не только ближайшие состояния, т.е. локальную обстановку, а "окинуть взглядом" как можно больший участок пространства состояний и быть готовым, в случае необходимости, вернуться туда, где мы уже были, и пойти другим путем, если ближайшие претенденты не сулят существенного прогресса в достижении цели (см. описание алгоритма А во врезке 2.2). Вот эта возможность отказаться от части пройденного пути во имя глобальной цели и позволяет найти более эффективный путь. Необходимость хранить ранее сделанные оценки состояний и постоянно их обновлять, конечно, требует значительных вычислительных ресурсов.
2.2. Алгоритм А
Существует хорошо известный алгоритм поиска, который относится к группе первый лучший, получивший наименование А (произносится "А со звездочкой"). Основная идея алгоритма состоит в использовании для каждого узла п на графе пространства состояний оценочной функции вида
f(n) = g(п) + h(n).
Здесь g(п) соответствует расстоянию на графе от узла п до начального состояния, a h(n) —оценка расстояния от п до узла, представляющего конечное (целевое) состояние. Чем меньше значение оценочной функции f(n), тем "лучше", т.е. узел п лежит на более коротком пути от исходного состояния к целевому. Идея алгоритма состоит в том, чтобы с помощью f(n) отыскать кратчайший путь на графе от исходного состояния к целевому.
Отсюда следует, что если h(n) — нижняя оценка действительного расстояния до целевого состояния, т.е. если h(n) никогда не дает завышенной оценки расстояния, то алгоритм А всегда отыщет оптимальный путь до цели при помощи оценочной функции f(n). Алгоритм, обладающий таким свойством, называется разрешимым (более подробное обсуждение этого вопроса читатель найдет в специальной литературе, в частности в работах Нмпьсона [Nilsson, 1980, Chapter 2] и Перла [Pearl, 1984, Chapter 2]).
Обозначения:
s — узел начального состояния;
g— узел целевого состояния;
OPEN — список, который содержит,выбранные, но необработанные узлы;
CLOSED — список, который содержит обработанные узлы.
Алгоритм
(1) OPEN:={s}.
(2) Если ОРЕМ:={}, то прекратить выполнение. Пути к целевому состоянию на графе не существует.
(3) Удалить из списка OPEN узел п, для которого f(n)
(4) Сформировать список очередных узлов, в который возможен переход из узла n и удалить из него все узлы, образующие петли; с каждым из оставшихся связать указатель на узел п.
(5) Если в сформированном списке очередных узлов присутствует д, то завершить выполнение. Сформировать результат — путь, порожденный прослеживанием указателей от узла д до узла s.
(6) В противном случае для каждого очередного узла n', включенного в список, выполнить следующую последовательность операций.
Вычислить f(n').
Если n не присутствует ни в списке OPEN, ни в списке CLOSED, добавить его в список, присоединить к нему оценку f(n') и установить обратный указатель на узел п.
Если n' уже присутствует в списке OPEN или в списке CLOSED, сравнить новое значение f(n)=new с прежним f(n')=old.
Если old
Если new
был в списке CLOSED, перенести его в список OPEN.
Конец алгоритма
Применение этого алгоритма рассмотрено в упр. 8.
Вычислительная мощность современных компьютеров все-таки недостаточна для того, чтобы использовать алгоритмы поиска решений даже с помощью направленного поиска с применением оценочной функции, не говоря уже о методике слепого перебора возможных состояний. Пространство состояний, в котором нужно вести поиск, при решении таких задач, как распознавание речи, выбор конфигурации компьютерной системы или планирование последовательности операций, настолько велико, что его невозможно проанализировать такими обобщенными методами за обозримый отрезок времени, если только не призвать на помощь знания, касающиеся конкретной предметной области. Можно показать, что многие из этих проблем изоморфны абстрактным задачам, которые заведомо относятся к классу "необозримых" в том смысле, что их сложность, а соответственно и потребность в вычислительных ресурсах, экспоненциально возрастает при линейном увеличении размерности задачи.
Как будет показано далее, развитие экспертных систем пошло по пути привлечения опыта экспертов, как касающегося деталей поведения конкретных объектов в конкретной ситуации, так и стратегии логического вывода в определенной предметной области, что и позволяет преодолеть трудности, связанные со сложностью формализованного поиска в пространстве состояний.
Достаточно подробно результаты первых исследований в области программирования игр и машинного доказательства теорем описаны в сборнике статей под редакцией Фей-генбаума и Фельдмана [Feigenbaum and Feldman, 1963]. Я склонен к тому, чтобы считать "классическим" в истории искусственного интеллекта период, который начался с публикации в 1950 году статьи Шеннона об игре в шахматы [Shannon, 1950] и закончился выходом сборника Фейгенбаума и Фельдмана. Наиболее существенные результаты, полученные в этот период, можно сформулировать следующим образом:
проблему любой сложности, в принципе, можно свести к проблеме поиска в пространстве состояний, если только удается ее формализовать в терминах начального состояния, конечного состояния и операций перехода в пространстве состояний;
поиск в пространстве состояний должен направляться определенным образом представленными знаниями о конкретной предметной области.
Очень редко удается свести использование знаний к формулировке адекватной оценочной функции и таким образом помочь программе оценить свое поведение в текущей ситуации и найти правильный путь к решению. Но в большинстве случаев требуется нечто большее, что-то вроде глобальной стратегии решения проблем или явного использования знаний об объектах, их свойствах и связанных с ними действиях в конкретной предметной области, или комбинации того и другого.
2.2. Романтический период: компьютер начинает понимать
Период от середины 60-х до середины 70-х я называю "романтическим" в истории исследований искусственного интеллекта. В это время внимание исследователей сосредоточилось в основном на проблеме машинного "понимания", т.е. способности воспринимать естественный язык человека, в частности вести осмысленный диалог. Эти попытки были встречены философами с определенным скепсисом. Они сомневались в том, что по отношению к компьютерной программе вообще можно употреблять слово "понимание".
2.2.1. Система SHRDLU
Кульминационным моментом этой эпохи явилась разработка Виноградом [Winograd, 1972] системы SHRDLU, которая понимала довольно представительное подмножество слов английского языка и делала определенные выводы в ограниченной области (в мире, построенном из деталей детского конструктора). Программа демонстрировала свои возможности восприятия речевых команд, реконструируя созданный ею "мир деталей" и отвечая на вопросы, касающиеся как конфигурации деталей, так и своих действий с ними. Она могла отвечать на вопросы вроде следующих:
"Какого цвета блок, на котором стоит красная пирамида?" и строить план выполнения команды, например: "Поставь синюю пирамиду на зеленый кубик".
Можно было считать, что система SHRDLU понимает фразы на человеческом языке, поскольку она адекватно на них реагировала. "Разумность" такого рода восприятия была названа "процедуральной семантикой". Вывод о разумности программы основывался на идее, что если программа способна в ответ на вопрос выполнить соответствующие действия, то можно считать, что она "поняла" заданный вопрос. Такая точка зрения на проблему машинного "понимания" основывается на воспроизведении в первую очередь поведенческой реакции, а не способностей человеческого мышления.
Другое направление исследований было связано с попытками воспроизвести механизм понимания в менее искусственном и более близком к реальному контексте, например в ситуаиии визита к врачу или посещения ресторана. Шанк и Колби [Schank and Colby, 1973] воспользовались структурой, названной ими сценарием, для объединения разнообразных элементов, представляющих в совокупности реальную ситуацию. Сценарий можно рассматривать как объединение разнообразных целей, решений и обычаев, связанных с определенными событиями. Так, "сценарий посещения ресторана" приводится в действие при возникновении цели "чего бы съесть", удовлетворяется событием "прием пищи" и объединяет промежуточные знания о том, как заказать столик, выбрать блюда в меню, расплатиться, дать на чай и т.п. Такое объединение целей и средств, характерных для определенной ситуации, объясняет, почему определенные действия считаются нормой в одной ситуации и рассматриваются как неадекватные в другой. Например, раздевание в присутствии постороннего является нормой при визите к врачу и рассматривается как неадекватное при посещении ресторана. Такой же подход позволяет включить и некоторые знания, которые мы считаем само собой разумеющимися, — любой под визитом к врачу понимает посещение клиники, а не квартиры врача. В сценарии "визит к врачу" это учитывается включением в качестве места посещения по умолчанию именно клиники.
2.3. Сценарий посещения ресторана
Для описания сценария можно использовать разные системы обозначений, но все они должны содержать определенные базовые компоненты: цель, которой должны удовлетворять все действия в этом сценарии, предварительные условия, которые должны быть удовлетворены перед тем, как сценарий можно будет применить, и заключительные условия, характеризующие ситуацию после завершения применения сценария. В системе обозначений также должны быть предусмотрены разделители между отдельными фазами сценария, которые служат для организации некоторых действий. Ниже приведен простой сценарий визита в ресторан.
Цель: поесть без самостоятельного приготовления пищи. Предварительные условия: голоден, есть деньги, ресторан работает. Состояние после завершения: сыт, денег стало меньше.
Действие первое: войти в ресторан. Найти место самостоятельно, если нет никаких других признаков, что на вас обратили внимание, или отсутствует метрдотель. В противном случае позволить метрдотелю найти место.
Действие второе: просмотреть меню, сделать заказ,и поесть. Не забыть, что в ресторане могут быть фирменные блюда.
Действие третье: получить чек. Заплатить официанту/официантке или кассиру. Покинуть заведение.
Обратите внимание на то, что в разных ресторанах существуют отличительные способы выполнения похожих действий, — по-разному отыскивается место за столиком, предлагаются свои фирменные блюда, выполняется расчет за услуги. Такие нюансы также можно зафиксировать в сценарии, что позволит сформировать поведение, адекватное конкретной ситуации. В идеале, в сценарии могут быть зафиксированы разные варианты поведения, в зависимости от выполнения тех или иных условий, специфицированных в компоненте "Предварительные условия".
Применение механизма сценариев можно рассматривать в свете проблемы представления знаний на более высоком уровне, чем в случае процедуральной семантики. Описание понятия на уровне отдельной фразы нельзя "поднять" на более высокий уровень, когда нужно принимать во внимание эпизод в целом вместе с множеством мотиваций, подразумеваемых, но никогда (или редко) не формулируемых человеком вслух. Некоторые исследователи пришли к выводу, что зависимость от контекста является главным препятствием в решении проблемы компьютерного понимания естественного языка. В результате были начаты исследования в направлении, где предпочтение отдается не формальным моделям языка и сопряженных с его восприятием мыслительных процессов, независимых от конкретной предметной области, а относительно неформальным, контекстным способам рассуждений.
Другие исследователи (например, [Newell and Simon, 1972] и [Anderson, 1976]) попробовали на несложных задачах (простенькие головоломки, игры в слова и тесты, оценивающие способность к запоминанию) смоделировать присущий человеку подход к решению проблем. Они стремились сделать так, чтобы знания и стратегия поведения программы как можно больше походили на знания и стратегию поведения человека в аналогичной ситуации. Оценка успешности моделирования производилась путем сравнения поведения человека и программы при решении одной и той же задачи.
Но такое компаративное изучение сталкивается с фундаментальной проблемой — не существует прямого метода показать, что человек и программа искусственного интеллекта делают одни и те же вещи одинаковым способом. В результате используется косвенная аргументация. Например, демонстрируется, что человек и программа делают аналогичные ошибки, если встречаются с проблемой повышенной сложности и ошибочными данными, или что распределение времени на выполнение одинаковых этапов решения задачи у человека и программы имеет одинаковый характер при решении аналогичных задач различных классов. Общепринятой стала точка зрения, что простое совпадение ответов на одинаковые вопросы — недостаточное доказательство совпадения способов рассуждений, поскольку существует множество отличающихся стратегий и способов использования имеющихся знаний, которые можно применить для решения одной и той же проблемы
2.2.2. Схемы представления знаний
Независимо от того, насколько это вторжение в науку о познании было продуктивным для психологии, оно способствовало весьма существенному прогрессу в информатике. Ньюэлл (Newell) и Саймон (Simon) предложили схему, известную как набор порождающих правил (production rules). (Подобно мы поговорим о ней в главе 5.) Со временем порождающие правила стали основным инструментом при проектировании экспертных системы. Ньюэллу и Саймону также принадлежит приоритет в разработке методики, получившей наименование анализ протокола (protocol analysis). Эта методика заключается в том, что человеку предлагается "думать вслух" в процессе решения проблемы, а затем зафиксированный протокол анализируют и пытаются отыскать в нем концепции и процедуры, которые были использованы человеком. Этот подход можно считать предшественником используемой сегодня методики извлечения знаний. Уже первые исследования на стыке психологии и информатики показали, насколько сложной является проблема представления знаний, но они также и продемонстрировали, что ее решения следует искать скорее на пути эмпирических исследований, чем философских дебатов.
В романтический период было предпринято множество исследований, целью которых было выяснить, каким образом и многообразие сведений об отдельных фактах, и общие принципы построения окружающего нас мира можно использовать в компьютерной программе, которая ориентирована на построение логического рассуждения, направленного на достижение определенной цели. Эти исследования включали использование конструкций следующих видов (чаще в чистом виде, но иногда и в комбинации):
правил в форме, "если имеет место это условие, то примени этот оператор";
разного рода сетей, в которых узлы соответствуют концепциям, а дуги — отношениям между ними;
логических формул, представляющих отдельные факты и принципы, включая управляющую информацию о том, когда применить то или иное соответствие.
Следует отметить, что большинство созданных в этот период программ носили только исследовательский характер. Лишь немногие работы получили продолжение и воплотились в нечто, приложимое к реальным задачам.
Весьма репрезентативная подборка статей, написанных в первой половине этого периода, опубликована Минским [Minsky, I968J. Любая из них представляет интерес, но далеко не все убедительны с точки зрения достижений сегодняшнего дня. Тем не менее множество схем представления знаний, которым мы отдаем предпочтение в современных разработках, основаны именно на результатах, полученных в тот романтический период. Например, в работе Квилиана (Quillian) предложены ассоциативные и семантические сети в качестве графического формализма для описания фактов и определений (подробнее об этом— в главе 6). Без результатов, полученных в это время, вряд ли разработчики современных экспертных систем располагали бы таким разнообразием функций и структур.
Наиболее интересные работы, опубликованные во второй половине этого периода, собраны Уинстоном [Winston, 1976,b]. Среди них я настоятельно рекомендую ознакомиться с фундаментальной работой Минского о формализме представления знаний, получившем наименование фреймов. Работы, выполненные в этом направлении в 70-е годы в Массачусетсском технологическом институте, собраны в двухтомнике Уинстона и Брауна [Winston and Brown, 1979]. Здесь вы найдете множество статей и о тех областях искусственного интеллекта, которые выходят за рамки этой книги, в частности о машинном восприятии естественного человеческого языка, искусственном зрении, робототехнике.
2.4. Летучие мыши и проблема с пингвинами
Семантические цепи представляют собой средство представления знаний, базирующееся на формализме теории графов. В таксономическом графе на рис. 2.4 представлены наши познания о птицах, перепончатокрылых млекопитающих и даже специфических видах рыб— летающих. Однако птицы являются куда более типичными представителями летающих животных, чем, скажем, летучие мыши (перепончатокрылые млекопитающие), которые, в свою очередь, более распространены, чем летающие рыбы. Этот факт никак не отражается на простом графе.
Аналогично, простой граф "умалчивает" и о другом факте. Несмотря на то что подавляющее большинство птиц способно летать, этого нельзя сказать о пингвинах. Как же отразить на графе исключение из общего правила. Некоторые из возможных ответов вы найдете в главе 6.
Рис. 2.4. Простой таксономический граф, не учитывающий исключений
Конечно, вряд ли исследования в области машинного "понимания" будут завершены. Сейчас мы даже не знаем, при каких условиях можно сделать заключение, что машина все понимает. Но если мы не можем со всей уверенностью четко сформулировать, что представляет собой фундамент машинного понимания, можно, по крайней мере, перечислить его необходимые составляющие.
Первая — это способность представлять знания об окружающем мире и формулировать суждения, основываясь на таких представлениях. В экспертных системах эта способность демонстрируется на практике с учетом того, что в таких системах представляются знания о конкретной предметной области, соответственно и порождаемые ими суждения относятся только к этой области. Как и программа Винограда, экспертная система выглядит весьма ограниченной в смысле объема знаний, а вероятность получить достоверное с нашей точки зрения суждение обратна объему знаний, вовлеченных в вывод суждения.
Другим признаком "понимающей" машины является способность находить эквивалентность или аналогию между разными представлениями в одинаковых ситуациях. Здесь, конечно, счет далеко не в пользу экспертных систем, поскольку в таких системах ввод информации выполняется в совершенно определенной, жесткой форме, полностью соответствующей запасенным в системе знаниям. Любое отклонение от ожидаемой схемы может привести к практически непредсказуемым последствиям.
И последнее— понимание предполагает способность обучаться каким-либо нетривиальным способом. В частности, новая информация должна интегрироваться в уже имеющееся знание и, возможно, модифицировать его. Такие способности редко демонстрируются в современных экспертных системах, хотя в последние годы и наметился определенный прогресс в области машинного обучения (подробнее об этом читайте в главе 20).
Нужно отметить, что современные экспертные системы еще слабо соответствуют многим из этих критериев, но вывод о том, что они не обладают "пониманием" хотя бы в отдельной предметной области, также спорен. В своей области каждая из современных экспертных систем "понимает", т.е. способна решать проблемы, ненамного хуже, чем человек [Davis, 1989]. Ряд хорошо описанных систем решает свои задачи на таком же уровне, что и человек-эксперт, хотя и не демонстрирует "понимания" того вида, которым так были озабочены исследователи в описываемый романтический период. Дэвис настаивает на том, что не существует связи на уровне необходимости между частным процессом решения проблемы и самим решением. Другими словами, все, что нам требуется от экспертной системы, — это получить ответ, более или менее близкий к тому, который дает эксперт-человек, или помочь человеку дать правильный ответ. Нам отнюдь не требуется, чтобы система в процессе получения ответа повторяла ту же последовательность рассуждений, что и человек, или точно таким же способом организовала свои знания о предметной области.
Однако в главе 11 и далее мы увидим, что попытки использовать экспертную систему для преподавания наталкивают на мысль о необходимости пересмотреть эту точку зрения. Результаты последних исследований в области совершенствования экспертных систем подталкивают нас все ближе к расплывчатым целям машинного "понимания". Эти же результаты породили и новый взгляд на процесс решения проблем человеком и предоставили в наше распоряжение значительно более широкий набор концепций, пригодных для анализа активности как человека, так и машины при решении проблем
2.3. Период модернизма: технологии и приложения
Период, который я называю периодом модернизма, продолжался с середины 70-х до конца 80-х годов. Он характеризуется значительным прогрессом в области экспертных систем, так называемой "зимней спячкой" в области "чистого" искусственного интеллекта, интерес к которому возобновился с появлением Всемирной паутины. То время, когда готовилось к печати настоящее издание, я отношу уже к следующему периоду— периоду постмодернизма, от характеристики которого я здесь воздержусь, поскольку сам являюсь участником происходящего в нем. Но, не боясь ошибиться, можно утверждать, что происходящее в нем во многом определяется развитием Internet-приложений, в частности интеллектуальных агентов и советчиков, облегчающих и упрощающих извлечение информации при работе со средствами электронной коммерции. Успехи и неудачи в области искусственного интеллекта в этот период в значительной мере зависят от возможности и желания исследователей преодолеть влияние традиционных концепций, характерных для прежних периодов, и сосредоточить усилия на реальных проблемах новой информационной среды.
2.3.1. В знании сила
В период модернизма возросла уверенность, что эвристические возможности "решателя" проблем определяются представлением в явной форме соответствующих зданий, доступных программе, а не применением какого-то изощренного механизма определения взаимовлияния или сложных оценочных функций. Значительные усилия были направлены на разработку методов разбиения знаний, присущих человеку, на модули, которые можно было бы активизировать по заданной схеме (см. врезку 2.5). Уже при первых попытках сымитировать процесс разрешения проблем, характерный для человеческого разума (например, в работе [Newell and Simon, 1972]), исследователи столкнулись с ограниченными возможностями представления знаний и необходимостью упростить механизм их взаимовлияний, хотя более поздние исследования и помогли в определенной степени преодолеть эти трудности (об этом мы поговорим в главах 11-18).
Стало ясно, что стратегия явного представления человеческого знания в форме направляемых заданной схемой модулей обладает определенными преимуществами перед включением знаний в алгоритм, которые могут быть реализованы с помощью программных технологий, более близких к традиционным.
Процесс воспроизведения явных знаний, напоминающий кулинарный рецепт, потенциально обещает более чувствительный механизм настройки соответственно тому, как эксперт хранит и применяет имеющиеся у него знания. Редко кто из экспертов может представить четко сформулированную последовательность операций, гарантирующую успешное завершение процедуры в любой ситуации, в ответ на вопрос о том, как он действует в процессе решения проблемы. Скорее знания, которыми обладает эксперт, извлекаются по мере выяснения, как поступать в типичных ситуациях, а затем к ним прибавляются исключения из таких ситуаций.
Такой метод программирования знаний создает предпосылки для довольно быстрого создания прототипа системы и последующего ее постепенного развития. Если конструктор системы и программист справились со своей работой должным образом, созданную в результате программу несложно модифицировать и функционально расширить. Ошибки и провалы, обнаруженные в процессе эксплуатации в заложенных в систему знаниях, могут быть скорректированы и заполнены, причем это не влечет за собой кардинальную переделку основного программного кода. Если же в структуре системы не предусмотрена такая "модульность" знаний, их изменения могут повлечь за собой полную реконструкцию системы.
Большинство из тех, кто работали с практическими программами решения проблем, пришли к выводу, что полезной может быть и программа, которая не решает проблему целиком или не бывает права абсолютно всегда. Экспертная система может функционировать и как "разумный ассистент", который предлагает несколько альтернативных вариантов решения проблемы и отвергает менее приемлемые.
В этот период разработчики на практике убедились в том, как сложно создавать и отлаживать системы, базирующиеся на правилах. По мере расширения базы знаний оказалось, что правила имеют тенденцию взаимодействовать в пределах системы самым неожиданным образом, соревнуясь за приоритет при решении проблемы, что разные режимы управления правилами эффективны для проблем одного типа и не дают эффекта при решении проблем другого типа. Со временем в этом перестали видеть что-то необычное, но поначалу свидетельства такого эффекта воспринимались как анекдоты.
Практический опыт научил нас, что наилучшие результаты при решении проблем разного рода можно получить, только используя отличающиеся методики. Эти методики, получившие звучные и исполненные тайного смысла наименования "эвристическая классификация", "иерархическая проверка гипотез" и "предложение, проверка и исправление", как правило, сводятся к разным стратегиям управления последовательностью применения правил. Эти методики будут подробно рассмотрены в главах 11-15.
2.5. Процедуральное или декларативное знание
В процедурных языках программирования, таких как С, мы, как правило, физически не разграничиваем ту часть программы, которая описывают ее "логику", от той, которая имеет дело с манипулированием данными. Например, процедура, в которой проверяется, обладает ли данная птица способностью летать, будет выглядеть так:
char fly(char s)
{
char answer = 'д'; if (strcmpfs, "пингвин")==0)
{ answer = 'н';} return answer;
}
Независимо от того, владеете вы языком С или нет, понятно, что этот программный код явно вызывается другой частью программы, например, так:
char с;
с = fly("пингвин");
Предположим, что вместо этого у нас есть два правила, которые хранятся в базе знаний:
(defrule
(птица (тип ?Х)) =>
(assert (да))
)
(defrule
(птица (тип пингвин)) =>
(assert (нет)) )
В этом примере форма правил более близка к объявлению или определению (использован- синтаксис языка CLIPS). Для случайно выбранной птицы утверждается, что она способна летать. Но если известно, что птица — это пингвин, то утверждается, что она не способна летать. Но поскольку пингвин это тоже птица, то какой-то другой компонент экспертной системы должен решить, какое из этих двух правил применять в данной ситуации. Этот компонент называется машиной логического вывода (inference engine).
В этом примере совершенно отчетливо видна модульная природа правил. Код, который в явном виде вызывает то или иное правило, отсутствует. Подробно реализация таких правил будет рассмотрена в главе 5.
В этот период появился ряд систем, которые довольно эффективно справлялись с нетривиальными задачами. Примером может служить система R1/XCON, предназначенная для структурного синтеза вычислительных систем (подробно о ней — в главе 14). В этой системе реализован ряд концепций, существенно отличающих ее как от обычных программных приложений, так и от исследовательских программ искусственного интеллекта (см. [Davis, 1982]). Те, которые я считаю наиболее важными, перечислены ниже.
Как уже было подчеркнуто в главе 1, часть программы, которая содержит представление знаний, касающихся определенной предметной области, — база знаний, как правило, отделена от той части программы, которая занимается формулировкой соображений, — машины логического вывода. Такое разделение позволяет вносить изменения (конечно, в разумных пределах) в одну часть программы, не меняя другой. В частности, можно добавлять в базу знаний новую информацию, расширяя имеющиеся в системе знания, или настраивать механизм логического вывода, повышая его эффективность, и при этом не модифицировать программный код системы.
С точки зрения пользователя систем такого рода желательно, чтобы в них использовалась единая форма представления знаний, насколько это вообще возможно в системах разного назначения. Это упрощает процесс ввода знаний в систему, облегчает обслуживающему персоналу сопровождение системы и препятствует излишнему усложнению машины логического вывода. Однако, как будет показано в главе 11 и последующих, единообразие может привести к возникновению определенных трудностей при попытке "втиснуть" самые разные по своей естественной природе знания в один и тот же формализм. Таким образом, в вопросе о представлении знаний существует определенная "золотая середина" между крайностями — полным единообразием и узкоспециализированным формализмом.
Помимо найденного решения проблемы, экспертная система должна предоставить пользователю еще и информацию о том, как это решение было получено. Этим она существенно отличается от большинства привычных программных приложений. При использовании простой машины логического вывода и определенного формализма представления знаний такое объяснение включает перечень модулей базы знаний, задействованных в процессе принятия решения, и информацию о том, в каком порядке они активизировались. В главе 16 будет показано, как это выглядит на практике, и вы сможете убедиться, что эта информация не всегда соответствует нашим ожиданиям по части полноты и что желательно в этой области изобрести какую-нибудь более информативную технологию.
2.6. Машина логического вывода и база знаний
Как правило, в структуре экспертной системы можно четко разделить базу знаний и компонент, который этой базой пользуется, — машину логического вывода. Взаимодействие между ними обеспечивается программой, которую принято называть оболочкой (shell) экспертной системы. Конечный пользователь приложения взаимодействует с системой через оболочку, передавая ей запросы. Последняя активизирует машину логического вывода, которая обращается к базе знаний, извлекает знания, необходимые для ответа на конкретный вопрос, и передает сформированный ответ пользователю либо как решение проблемы, либо в форме рекомендации или совета (рис. 2.5).
В базе данных содержатся правила и всевозможные декларации. В частности, применительно к примеру "Пингвин", представленному во врезке 2.5, в базе знаний, организованной с помощью языка CLIPS, должны присутствовать следующие декларации:
(deftemplate птица (field (тип SYMBOL)))
в дополнение к имеющимся правилам:
(defrule (птица (тип ?Х))
=>
(assert (да))
)
(defrule
(птица (тип пингвин))
=>
(assert (нет)) )
Из этой декларации следует, что объект данных птица может содержать поле (field) тип. В главе 5 вы познакомитесь с декларациями другого типа, которые служат для настройки поведения машины логического вывода.
Рис. 2.5. Структура экспертной системы
2.3.2. Периоды "зимней спячки" и "пробуждения" в истории искусственного интеллекта
В первой части периода модернизма среди исследователей, занимавшихся "чистыми" проблемами искусственного интеллекта, очень распространенным было настроение критической самооценки. Одним из его симптомов была оживленная дискуссия между сторонниками формальных и неформальных методов (подробнее об этом — в главе 23). Кажется само собой разумеющимся, что имеют право на существование как исследования чисто теоретические, фундаментальные, так и прикладные, призванные использовать фундаментальные результаты в конкретных задачах.
А тем временем продолжалось активное развитие технологии экспертных систем для самых разных прикладных областей. Фирмы, специализирующиеся в области искусственного интеллекта, предлагали достаточно дорогие программные продукты, требовавшие специальной аппаратной среды и к тому же плохо поддающиеся интеграции с другими коммерческими системами. Вместо того чтобы осваивать свою нишу на рынке решением тех проблем, которые восприимчивы к подходу, основанному на знаниях, делались широковещательные заявления о создании эффективных систем, способных справиться с любой проблемой.
Возрождение интереса к исследованиям в области искусственного интеллекта связано с новым информационным взрывом. В расширяющейся информационной вселенной, без сомнения, не останутся невостребованными методы искусственного интеллекта при решении, по крайней мере, таких задач, как обработка текстов и изображений, которые нужно извлекать из различного рода источников, анализировать, классифицировать, индексировать, обобщать, интерпретировать и т.д. и т.п. Настало время и для внедрения результатов, достигнутых в технологии символических вычислений и обобщенной теории представления знаний. Но эти подходы должны сочетаться со статистическим и вероятностным подходами, поскольку нам приходится иметь дело с огромными и все увеличивающимися объемами информации, доступной по Internet и различным коммерческим информационным сетям.
В следующей главе приводится описание структуры и основных принципов функционирования двух ранних программ искусственного интеллекта. Хотя со времени создания этих систем прошло уже более двадцати лет, они могут служить прекрасной иллюстрацией базовых концепций, используемых при построении программ такого рода, и мне незачем извиняться за включение этого материала в книгу. Каждую из этих программ можно рассматривать как своеобразный мост, переброшенный между концепцией поиска в пространстве состояний и развитием подхода, опирающегося на базы знаний. Студенты, только приступающие к освоению материала об экспертных системах, найдут в описании этих программ много такого, что необходимо уразуметь прежде, чем заняться более современными системами. С последними читатель сможет поближе познакомиться в главах 11-15 и особенно в 22 и 23, где анализируются результаты некоторых экспериментов, демонстрирующих пределы возможностей экспертных систем
Рекомендуемая литература
Хорошим введением в проблематику искусственного интеллекта могут послужить книги Рича и Найта [Rich and Knight, 1991] и Уинстона [Winston, 1992]. Для студентов хорошим источником ссылок на работы в этой области, хотя и несколько устаревшие с точки зрения сегодняшнего дня, являются различные выпуски серии Handbook of Artificial Intelligence ([Barr and Feigenbaum, 1981, 1982]; [Cohen and Feigenbaum, 1982]). Читателям, интересующимся проблемой машинного распознавания естественного языка, рекомендую прочесть книгу Аллена (Allen, 1995), в которой описаны фундаментальные исследования в этой области, а о том, каким видится будущее искусственного интеллекта из окон лабораторий МИТ, читатель сможет узнать в книге Уинстнона и Шелларда [Winston andShellard, 1990].
Начальные главы книги Нильсона [Nilsson, 1980] по-прежнему остаются лучшим описанием методики эвристического поиска, но более строгое математическое изложение этого материала можно найти в работе Перла [Pearl, 1984]. Некоторые примеры приложения методики эвристического поиска, взятые из современной практики, собраны в сборнике [Rayward-Smith et al, 1996], а Рейард-Смит в своей книге излагает современный взгляд на эти методы [Rayward-Smith, 1994].
Алгоритмы, аналогичные рассмотренному А , по-прежнему привлекают немалое внимание. Например, в одной из последних статей Корфа и Рейда [Korf and Reid, 1998] показано, что эвристики значительно улучшают процесс поиска не тем, что сужают поиск, как считалось до сих пор, а уменьшая его глубину. Таким образом, оказывается, что эвристики способствуют отысканию более коротких путей решения, не снижая при этом фактор ветвления.
Упражнения
1. Почему пакет программ статистического анализа нельзя считать программой искусственного интеллекта?
2. Могут ли психологи подсказать нам, как сконструировать думающую машину?
3. Как вы понимаете термин "пространство поиска"? Что представляет собой пространство поиска в игре в шахматы?
4. Как вы понимаете термин "пространство решений"? Что представляет собой пространство решений в игре в шахматы?
5. Ниже приведен алгоритм поиска в глубину. Он записан с помощью функциональной нотации, которая подчеркивает его рекурсивную структуру. Таким образом, dfs представляет собой функцию трех аргументов: goal, current и pending:
goal — это объект поиска,
current — текущий узел на графе состояний (в самом начале — узел исходного состояния),
pending — список узлов, претендующих на обработку (в самом начале — пустой).
В дальнейшем используются следующие обозначения:
символ := означает присваивание;
функция expand формирует узлы, следующие за аргументом этой функции; знак + означает слияние двух списков, т.е.
(а b с) + (d e f ) = (а b с d e f);
() означает пустой список;
first и rest — функции, которые возвращают начало и конец списка:
first(a b с) = a
rest(a b c) = (b c).
I) Выразите следующий алгоритм на каком-либо из известных вам языков программирования.
dfsfgoal, current, pending)
{
if current = goal, then success;
else
{
pending := expand (current}+ pending;
if pending = () then fail;
else dfs(goal, first(pending), .rest( pending));
} }
II) Разработайте аналогичный алгоритм для поиска в ширину и реализуйте его на том же языке. Необходимо будет изменить только одно выражение в функции dfs.
6. Рассмотрите головоломку "миссионеры и каннибалы", схематически представленную на рис. 2.6.
Рис. 2.6. Головоломка "миссионеры и каннибалы "
Условия головоломки следующие.
На левом берегу реки находятся три миссионера и три каннибала. К этому же берегу причалена единственная лодка. На этой лодке нужно переправить всех миссионеров и всех каннибалов на правый берег при условии, что лодка одновременно может перевозить не более двоих, в обратный путь на лодке должен отправиться хотя бы один человек. Таким образом, дозволены следующие варианты шагов (переправ):
К-> одного каннибала с левого берега на правый
КК-> двух каннибалов с левого берега на правый
МК-> одного миссионера и одного каннибала с левого берега на правый
ММ-> двух миссионеров с левого берега на правый
М-> одного миссионера с левого берега на правый
К этому нужно добавить такие же варианты переправы с правого берега на левый. Но есть еще одно обстоятельство, существенно влияющее на весь процесс: если окажется, что каннибалов на любом из берегов больше, чем миссионеров, то несчастных просто съедят. Решение головоломки — это последовательность шагов с учетом описанных ограничений, переводящая систему в заданное конечное состояние.
Конечно, эту головоломку можно решить и простым перебором и испытанием всех возможных состояний, поскольку пространство поиска не так уж велико. На рис. 2.7 показано, как образуется пространство поиска рекурсивным применением дозволенных операторов, причем на графе состояний особо выделены узлы, приводящие к образованию петель, и узлы, соответствующие недозволенным состояниям (когда кто-либо из миссионеров обречен).
Рис. 2.7. Построение пространства поиска в головоломке "миссионеры и каннибалы"
На рис. 2.8 показано законченное пространство поиска, сформированное алгоритмом поиска в глубину, причем перебор возможных шагов ведется в том порядке, в котором они перечислены в представленном в условии, списке.
Рис. 2.8. Законченное пространство поиска в головоломке "миссионеры и каннибалы ", сформированное алгоритмом поиска в глубину
В процессе поиска было развернуто 22 узла, а путь, приводящий к успеху, содержит 11 узлов. Таким образом, оценка проницательности поиска равна 11/22=0.5. Грубо говоря, проницательность поиска говорит нам о том, насколько данный алгоритм позволил избежать выполнения ненужной работы в процессе Поиска решения. Чем выше значение проницательности поиска для того или иного алгоритма, тем лучше.
I) Выберите представление состояний на берегах реки и разработайте программу, которая решает эту задачу, используя оба варианта алгоритмов поиска— в глубину и в ширину. С разными способами формализации этой
задачи можно познакомиться в работе Амарела [Amarel, 1968]. Обратите внимание на то, что существуют способы представления состояний, которые позволяют более экономно использовать вычислительные ресурсы при решении задачи.
II) Попытайтесь улучшить оценку проницательности поиска, полученную для алгоритма поиска в глубину (рис. 2.8), изменив порядок, в котором анализируются в каждом очередном состоянии дозволенные операторы.
III) Обобщите программу как в части количества пассажиров в лодке, так и в части количества миссионеров/каннибалов. Сделайте их параметрами программы, задаваемыми извне. Если вы начнете проводить эксперименты с такой программой, то убедитесь, что, во-первых, эти параметры нельзя варьировать независимо, поскольку при некоторых комбинациях задача не имеет решения, а во-вторых, увеличение значений любого из параметров существенно расширяет пространство поиска.
7. Другая классическая головоломка, знакомая в несколько ином виде многим еще со школьной скамьи, — "Восьмерка". В головоломке принимает участие восемь пронумерованных фишек, которые могут перемещаться по игровому полю 3x3. Цель состоит в том, чтобы из некоторого случайногорасположения фишек перейти к упорядоченному (рис. 2.9).
Мы несколько модифицируем ограничения, сформулировав их в терминах перемещения единственного "пустого поля".
Рис. 2.9. Головоломка "Восьмерка"
В отличие от задачи о миссионерах и каннибалах, эту головоломку можно решить за приемлемое время методом "слепого" поиска. Дело в том, что головоломка имеет только 9! состояний и, следовательно, можно использовать для поиска очередного хода оценочную функцию по методике "восхождения на гору".
I) Придумайте оценочную функцию для этой задачи и разработайте программу, которая реализует поиск по методике "восхождения на гору". Возможные варианты оценочной функции некоторого состояния должны включать, во-первых, количество фишек, которые стоят не на своих местах, а во-вторых, сумму расстояний от текущего положения каждой фишки до предназначенного ей целевого (имеются в виду расстояния по Евклиду).
II) Какая из предложенных выше оценочных функций является более чувствительной? Можете ли вы предложить лучший способ управления поиском?
III) Как будет работать ваша программа, если увеличить количество фишек до 15, а размер игрового поля до 4x4? В этом случае придется исследовать 16! состояний.
Эту головоломку с точки зрения методов искусственного интеллекта рассматривал Нильсон (см. [Nilsson, 1980, Chapter 1].
8. Просмотрите описание алгоритма А во врезке 2.2 и выполните следующее.
I) Реализуйте алгоритм А на любом известном вам языке программирования.
II) С помощью созданной программы попробуйте решить головоломки "о миссионерах и каннибалах" и "Восьмерку". (Придется придумать оценочную функцию для головоломки "о миссионерах и каннибалах". Воспользуйтесь оценочной функцией из упр. 7.)
III) Попробуйте с помощью этого алгоритма решить криптоарифметическую головоломку, описанную ниже:
BEST
SEND
DONALD
CROSS
+MADE
+MORE
+GERALD
+ROADS
MASTER
MONEY
ROBERT
DANGER
Термин "криптоарифметическая" означает использование цифр, зашифрованных буквами, и соответственно чисел, зашифрованных словами. Задача состоит в том, чтобы найти, какие цифры нужно подставить вместо букв, чтобы представленные арифметические операции над расшифрованными числами давали верный результат. Такая задача рассматривается во многих классических работах по искусственному интеллекту (см., например, [Raphael, 1976, Chapter 3].
Вам придется подумать над тем, как представить слагаемые и сумму, какие возможны в решении этой задачи "ходы" (т.е. какой набор операций можно предложить для перехода из одного состояния в другое) и какую эвристику можно применить для управления поиском
ГЛАВА 3. Представление знаний
3.1. Представление знаний: принципы и методы
3.2. Планировщик STRIPS
3.2.1. Таблицы операторов и методика "средство — анализ завершения"
3.2.2. Анализ метода представления и управления в STRIPS
3.3. Формулировка подцелей в MYCIN
3.3.1. Лечение заболеваний крови
3.3.2. База знаний системы MYCIN
3.3.3. Структуры управления в MYCIN
3.4. Оценка и сравнение характеристик экспертных систем
3.4.1. Оценка системы MYCIN
3.4.2. Сравнение MYCIN и STRIPS
Рекомендуемая литература
Упражнения
ГЛАВА 3. Представление знаний
3.1. Представление знаний: принципы и методы
3.2. Планировщик STRIPS
3.3. Формулировка подцелей в MYCIN
3.4. Оценка и сравнение характеристик экспертных систем
Рекомендуемая литература
Упражнения
В главе 2 отмечалось, что большинство исследователей весьма скептически относятся к возможности использования в прикладных системах таких методик поиска решений проблем, как "порождение и проверка" и "восхождение на гору". Серьезные технические сложности программной реализации оценочных функций навели на мысль, что такая методика недооценивает возможности узкоспециальных знаний в конкретной предметной области и переоценивает возможности обобщенного подхода к воспроизведению механизмов человеческого мышления. Весьма мало вероятно, что сегодня существовала бы такая область исследований, как экспертные системы, если бы удалось найти общие принципы решения проблем, которые можно было применять, отвлекаясь от специфики конкретной предметной области.
В этой главе описана одна из первых экспертных систем, MYCIN, при разработке которой была предпринята попытка отойти от традиции использования "обобщенного решателя проблем". Система построена на основе относительно несложного алгоритма поиска, значительно более простого, чем описанный в предыдущей главе алгоритм А. Возможности программы определяются не столько реализованным в ней алгоритмом поиска, сколько методикой представления знаний, специфических для той области, в которой предполагалось использовать систему, а именно — в лечении заболеваний крови.
Но начнем мы с разъяснения таинственного термина "представление знаний", используя в качестве примера разработанную приблизительно в это же время другую программу искусственного интеллекта — программу планирования STRIPS, — которую еще нельзя было отнести к классу экспертных систем. Затем будет описана система MYCIN, использованные в ней средства представления знаний и алгоритмы. Будет показано, как в процессе эксплуатации совершенствовалась система и с помощью каких средств разработчики пытались повысить ее производительность. В заключение мы сравним обе системы и отметим, что есть в них общего и в чем существенная разница. Анализ отличий между системами поможет проиллюстрировать тот существенный вклад, который внесли разработчики ранних экспертных систем в теорию и практику искусственного интеллекта в начале 70-х годов.
3.1. Представление знаний: принципы и методы
В области экспертных систем представление знаний означает не что иное, как систематизированную методику описания на машинном уровне того, что знает человек-эксперт, специализирующийся в конкретной предметной области. Но ошибочно считать, будто представление знаний сводится к кодированию в смысле, аналогичном шифрованию. Если закодировать сообщение, подставив некоторым регулярным образом вместо одних символов другие, то полученный результат не имеет ничего общего с представлением содержания сообщения в том смысле, как это понимается в теории искусственного интеллекта, даже если полученный код легко воспринимается на машинном уровне и его можно хранить в памяти компьютера.
Обратим внимание хотя бы на то, что в таком коде сохраняется та лексическая или структурная неоднозначность, которая присуща естественному человеческому языку. Так, сообщение
"Посещение тетушки может быть надоедливым"
будет настолько же неоднозначным в кодированном виде, что и на "человеческом" языке. Перевод этого текста в машинный код не избавит нас от того, что это сообщение можно трактовать и как утверждение, что "надоедает наносить визиты тетушке", и как утверждение, что "надоедает, когда тетушка наносит визит".
3.1. Молотки, графины и теоремы
Один из парадоксов искусственного интеллекта состоит в том, что многие задачи поиска смыслового содержания, которые легко решаются человеком, очень трудно реализовать на машине и наоборот. Рассмотрим следующую фразу:
"Молоток ударил графин, и он разбился".
К чему относится "он" в этой фразе? Для нас ответ очевиден, и мы даже не замечаем неоднозначности в этой фразе. Но как в общем смысле машина будет интерпретировать эту фразу? Предположение, что "он" относится к последнему по порядку следования в предложении существительному, не всегда срабатывает. Например:
Графин ударился о камень, и он разбился."
Для нас совершенно очевидно, что пострадавшим в обоих случаях должен быть графин. Мы обладаем тем, что называется "предварительным знанием", но непотнятно, как оно должно быть представлено в машине. Также далеко не очевидно, как собрать такого рода знания и как организовать их извлечение в конкретной ситуации. Единственное, что в этом смысле можно предложить — сформировать огромную таблицу, состоящую из всевозможных пар объектов во вселенной, и указать в ней, какой из двух предметов более хрупкий?
Теперь рассмотрим задачу из совершенно другой области. Нужно решить, является ли некоторая логическая формула теоремой исчисления высказываний (см. главу 8). Например, является ли теоремой формула
(р & (q=>r)) э ((s v p) & (~r=>-q)).
Оказывается, что не является, поскольку существует вариант, когда истинное значение присваивается последовательно переменным р, q, r, s, и все выражение становится ложным. Написать программу, которая поможет компьютеру прийти к такому заключению, — задача довольно тривиальная, а сделать то же самое обычному человеку довольно сложно.
Грубо говоря, разница между этими двумя задачами состоит в том, что знание, необходимое для решения задач из области исчисления высказываний, можно выразить в компактной форме в виде правил, а знания, которые требуются для правильной интерпретации любой фразы в форме
"X ударил Y, и он разбился",
кажутся на первый взгляд бесконечными по объему и предполагают множество исключений вроде того, что существует и пластиковый молоток, и выточенная из камня ваза, бумажная стена и т.д. и т.п. Кажется, что для решения подобных проблем программа должна обладать чем-то вроде "здравого смысла", в то время как для решения формальных логических задач никакого здравого смысла не нужно.
Любое общение человека с миром техники предполагает наличие некоторого предварительного знания. Если, например, некто берется за поиск неисправности в цифровой схеме, то это предполагает, что он обладает определенными базовыми знаниями из области электротехники. Нет необходимости подчеркивать, что компьютер (в чистом виде) никакими предварительными знаниями не обладает, а потому техническая эксперт-ность — набор качеств, лежащих в основе высокого уровня работы людей-специалистов при решении проблем в определенной узкой области, — должна включать и эти предварительные знания.
И наконец, представление предполагает определенную организованность знаний. Представление знаний должно позволить извлекать их в нужной ситуации с помощью относительно несложного и более-менее естественного механизма. Простого перевода информации (знаний) в форму, пригодную для хранения на машинных носителях, здесь явно недостаточно. Для того чтобы можно было достаточно быстро извлекать те элементы знаний, которые наиболее пригодны в конкретной ситуации, база знаний должна обладать достаточно развитыми средствами индексирования и контекстной адресации. Тогда программа, использующая знания, сможет управлять последовательностью применения определенных "элементов" знания, даже не обладая точной информацией о том, как они хранятся.
Конечно, программный код, выполняемый компьютером, должен соответствовать применяемой системе обозначений, но это нельзя считать слишком уж серьезным ограничением. Многие схемы представления, на первый взгляд чрезвычайно сильно отличающиеся, оказываются на самом деле формально эквивалентными, т.е. все, что может быть выражено в одной системе представления, может быть выражено и в другой.
Прежде чем перейти к рассмотрению конкретных примеров, давайте уточним терминологию, взяв за основу цитаты из "классических" работ по искусственному интеллекту.
Представление (representation) в работе Уинстона [Winston, 1984] определяется как "множество синтаксических и семантических соглашений, которое делает возможным описание предмета". В искусственном интеллекте под "предметом" понимается состояние в некоторой проблемной области, например объекты в этой области, их свойства, отношения, которые существуют между объектами. Описание (description) "позволяет использовать соглашения из представления для описания определенных предметов" [Winston, 1992].
Синтаксис представления специфицирует набор правил, регламентирующих объединение символов для формирования выражений на языке представления. Можно говорить о том, что выражение хорошо или плохо сформировано, т.е. о том, насколько оно соответствует этим правилам. Смысл должны иметь только хорошо сформированные выражения.
Общепринятым в области искусственного интеллекта является синтаксис в виде конструкции предикат-аргумент, которая имеет форму
<фраза> ::= <предикат> (<аргумент>,..., <аргумент>)
В этой конструкции за к-местным предикатом должны следовать k аргументов. Так, at может быть двухместным отношением, в котором в качестве первого аргумента выступает имя некоторого объекта, а в качестве второго— его местонахождение (например, комната):
at(робот, комнатаА)
Семантика представления специфицирует, как должно интерпретироваться выражение, построенное в соответствии с синтаксическими правилами, т.е. как из его фор"мы можно извлечь какой-то смысл. Спецификация обычно выполняется присвоением смысла отдельным символам, а затем индуцированием присвоения в более сложных выражениях. Так, присваивая смысл символам at, робот, комнатаА, мы можем сказать, что выражение
at(робот, комнатаА)
означает: робот находится в комнате А (но не наоборот — комната А находится в роботе).
Процесс решение проблемы, как правило, включает в себя наряду с представлением предметов окружающего мира и суждение о некоторых действиях. Как уже было показано в главе 2, некоторые проблемы формулируются в терминах исходного и целевого состояний и множества операций, которые можно использовать при попытках преобразовать начальное состояние в целевое. Но здесь остается невыясненным вопрос о том, как можно представлять операции
3.2. Планировщик STRIPS
Программа STRIPS [Fikes and Nilsson, 1971] демонстрирует один из подходов к представлению проблем. Наименование программы — аббревиатура от Stanford Research Institute Problem Solver (решатель проблем Станфордского исследовательского института). Программа предназначалась для решения проблемы формирования плана поведения робота, перемещающего предметы через множество (анфиладу) помещений. Программа STRIPS оказала очень большое влияние на последующие разработки в области искусственного интеллекта, и те базовые методики представления знаний, которые были в ней использованы для формирования действий, не утратили своей актуальности до настоящего времени.
Текущее состояние окружающей среды — помещений и предметов в них — представляется набором выражений предикат-аргумент, которые в совокупности образуют модель мира. Так, набор формул
W = { at(po6oт, комнатаА), at(ящик1, комнатаБ), at(ящик2, комнатаВ)}
означает, что робот находится в комнате А и имеются два ящика, один из которых находится в комнате Б, а второй — в комнате В.
Действия, которые может выполнить робот, принимают форму операторов, приложимых к текущей модели мира. Эти операторы позволяют добавить в модель некоторые факты (сведения) или изъять их из модели. Например, выполнение операции
"Переместить робот из комнаты А в комнату Б"
в модели мира приведет к формированию новой модели W. При этом факт at (робот, комнатаА) будет изъят из модели, а добавлен факт at (робот, комнатаБ). В результате новая модель мира будет иметь вид
W' = { at (робот, комнатаБ), at (ящик1, комнатаБ), аt (ящик2, комнатаВ)}
Обращаю ваше внимание на то, что сейчас мы обсуждаем только символические преобразования в модели мира и не затрагиваем вопрос о возможности реального перемещения робота из комнаты А в комнату Б. Обладающий интеллектом робот должен быть не только способен изменять свое реальное положение в окружающей среде, но и одновременно менять свое внутренне представление этой среды, знать, где он сейчас находится.
3.2.1. Таблицы операторов и методика "средство -анализ завершения"
Допустимые операции, такие как перемещение робота из одной комнаты в другую или проталкивание объектов, кодируются в таблице операторов. Ниже показан элемент этой таблицы, соответствующий операции push (толкать):
push(X, Y, Z)
Предварительные условия at(po6oT, Y), at(X, Y)
Список удалений at (робот, Y), at(X, Y)
Список добавлений at (робот, Z), at(X, Z)
Здесь выражение push(X, Y, Z)
означает, что объект X выталкивается (роботом) из положения Y в положение Z, причем X, Y и Z — переменные в области значений, охватывающей доступное множество объектов, в то время как робот, комнатаА, ящик1, комнатаБ, ящик2, комнатаВ — это имена конкретных объектов из этого множества.
С точки зрения программиста переменные X, К и Z в определении оператора, заданном элементом таблицы, — это аналоги формальных параметров в определении процедуры, которая соответствует такому действию:
"Вытолкнуть какой-либо объект из какого-либо положения в любое другое положение, если имеют место заданные предварительные условия; затем удалить формулы, указанные в списке удаления, и добавить формулы, указанные в списке добавления".
С точки зрения логики элемент push таблицы операторов может быть прочитан в виде формулы, которая утверждает:
"При любых X, Y и Z объект X выталкивается из Y в Z, если робот и объект X находятся в 7, а затем состояние изменятся заменой Y на Z".
Целевое состояние также представляется формулой, например: а1(ящик1, комнатаА), а^ящик2, комнатаБ).
Программа STRIPS включает множество процедур, которые выполняют различные функции, в частности:
обработка списка целей;
выбор очередной цели;
поиск операторов, которые могут быть использованы для достижения текущей цели;
анализ соответствия между целью и формулам в списке добавлений в модель;
установка сформулированных предварительных условий в качестве подцелей.
Чтобы представить себе, как на практике использовать подобную "структуру представлений, рассмотрим простую задачу: как готовиться к ленчу с потенциальным клиентом. Для этого, во-первых, нужно иметь в своем распоряжении определенную сумму наличных денег, чтобы расплатиться, во-вторых, нужно проголодаться, поскольку речь идет о приеме пищи. Сформулированные условия можно рассматривать в качестве предварительных для достижения цели "ленч". Эта цель может быть представлена оператором, как на рис. 3.1. После завершения ленча деньги будут потрачены, а у вас исчезнет чувство голода. Эти простые факты нашли отражение в списках удалений и добавлений для оператора have lanch. Однако обладание известной суммой наличных денег нельзя рассматривать как естественное состояние клиента. Сначала нужно получить их в банкомате, что, в свою очередь, требует передвижения. Следовательно, нужно добавить в таблицу операторов еще два элемента — at cash mashine (передвижение к банкомату) и have money (получение наличности).
Этот простой пример обладает довольно интересными свойствами. Отметим, что формулы для модели мира в исходном состоянии
at(work), have(transport)
остаются в неприкосновенности до тех пор, пока мы явно не удалим их. Таким образом, у вас остается возможность передвигаться по городу на протяжении всего времени реализации плана, поскольку формально отсутствуют какие-либо признаки, что эта возможность может быть утеряна (например, автомобиль будет угнан, или вы попадете в дорожную аварию, или по дороге к банкомату кончится бензин). Точно так же может что-нибудь произойти и с банкоматом — он может "зажевать" карточку, или вы можете забыть вытащить ее, или может вдруг появиться механическая рука и ножницами разрезать ее. Но предполагается, что последовательность действий, представленная в сгенерированном машиной плане, не должна предвидеть такие исключительные ситуации, хотя в реальной обстановке это соблюдается далеко не всегда.
Такая стратегия "обратных" рассуждений, т.е. от целей к подцелям, чрезвычайно распространена в программах искусственного интеллекта и экспертных системах, как вы вскоре убедитесь на примере системы MYCIN. Но даже на таком ограниченном множестве операторов, как в нашем примере, может существовать несколько вариантов выполнения действий. В этом случае необходимо будет организовать какой-то механизм поиска наилучшей последовательности операторов, приводящих к достижению сформулированной цели.
Рис. 3.1. Таблица операторов для задачи "Ленч"
По существу, в системе STRIPS при выборе операторов выполняется поиск в пространстве состояний, как это было описано в главе 2. В результате формируется план, т.е. последовательность операторов, приводящая к достижению цели, причем за основу берется стратегия "обратного" прослеживания. Основное отличие STRIPS от других аналогичных программ состоит в том, что вместо методики "генерация —проверка" для передвижения в пространстве состояний используется другой метод, известный как "средство — анализ завершения" (means-ends analisys).
В контексте нашей задачи применение методики "генерация —проверка" означает следующее: для каждого текущего состояния предпринимаются попытки использовать все возможные операторы, причем после каждой попытки анализируется, не привела ли она к желанной цели. Но такая методика явно бессмысленна, поскольку количество разнообразных операций, которые робот способен выполнить в некоторой произвольной ситуации, очень велико, причем многие из этих операций не имеют никакого отношения к достижению заданной цели. Уже после нескольких первых испытаний размерность пространства состояний увеличится и будет экспоненциально нарастать с каждым новым испытанием. Совершенно очевидно, что в данном случае нужна совершенно иная стратегия.
Основная идея, которая лежит в основе метода "средство — анализ завершения", состоит в том, чтобы с каждой новой операцией отличие между текущим состоянием и целевым уменьшалось, т.е. каждая очередная операция должна приближать нас к цели. Но это предполагает включение в рассмотрение некоторой меры для оценки "расстояния" в пространстве состояний. Такая мера очень походит на оценочную функцию. Если очередная цель сформулирована в виде
at(ящик1, комнатаА),
а ящик находится в комнате Б, то перемещение робота из комнаты А в комнату В никак не "приблизит" текущее состояние к целевому. А вот перемещение робота из комнаты А в комнату Б уменьшит расстояние между текущим и целевым состоянием, поскольку робот теперь сможет на очередном шаге вытолкнуть ящик из комнаты Б в комнату А. В этом смысле поведение робота "мотивируется" от целевого состояния к подцелям, которые могут привести к достижению сформулированной цели.
В действительности программа STRIPS считывает список целей наподобие такого:
at(ящик1, комнатаА), аt(ящик2, комнатаБ),
а затем сопоставляет эти цели и список добавления в описании каждого оператора. Так, цель at (ящик!, комнатаА) будет соответствовать элементу at(X, Z) в списке добавлений оператора push (X, Y, Z).
Схема сопоставления будет подробно рассмотрена в главах 4, 5 и 8, но сейчас, не вдаваясь в детали, просто отметим, что существует подстановка значений переменных
Х/ящик1, Z/комнатаА,
которая приводит к равенству выражений at (ящик!, комнатаА) nat(X, Z).
Программа следующим образом формирует подцели, выбирая в качестве таковых предварительные условия оператора.
(1) Подстановкой {Х/ящик1, Z/комнатаА} означить предварительное условие, которое является производным от соответствия at (ящик!, комнатаА) nat(X, Z), и получить таким образом
at(po6oт , Y), at(ящик1, Y).
(2) Найти в модели мира формулу, которая представляла бы текущее положение ящика а1(ящик1, комнатаБ), сравнить ее с at(ящик1, Y) и в результате этого сравнения сформулировать подстановку {Y/комнатаБ}, которую затем применить к уже частично означенному предварительному условию. В результате будет сформулирована очередная подцель:
at(робот, комнатаБ), at(ящик1, комнатаБ).
Теперь первое предварительное условие даст желаемое (целевое) положение робота, а второе предварительное условие уже выполнено.
Так как таблица операторов, модель мира и цели представлены с помощью одного и того же синтаксиса в виде конструкций предикат-аргумент, то, применяя описанную выше схему сопоставления, программа довольно просто находит, какие именно операции нужно выполнить для достижения поставленной цели. Все, что нужно для этого сделать, — просмотреть списки добавлений в описании операторов и найти в них элемент, соответствующий заданной цели, как это показано на рис. 3.1.
Подцели формулируются на основе анализа предварительных условий, заданных для операторов, означивая их подстановкой переменных из формулы модели мира. Как только выбран нужный оператор, его предварительные условия преобразуются и добавляются в список подцелей. Если в текущем состоянии можно применить не один оператор, то для выбора между "кандидатами" нужно применить какую-либо эвристику. Например, можно выбрать тот из операторов, который сулит наибольшее сокращение "расстояния" между текущим состоянием и целевым. Другой возможный вариант — операторы в таблице заранее упорядочены и нужно применять тот из них, который стоит в списке раньше.
Весь процесс решения проблемы по такой методике имеет ярко выраженный рекурсивный характер. Подцели могут, в свою очередь, приводить к формулировке подподце-лей и т.д. На самом нижнем уровне окажутся подцели, которые реализуются операторами, либо не имеющими предварительных условий, либо имеющими такие предварительные условия, которые удовлетворяются тривиально. Мы рассмотрим подробно методику "средство — анализ завершения" в главах 5 и 14.
3.2.2. Анализ метода представления и управления в STRIPS
Для того чтобы яснее представить себе достоинства метода представления, использованного в системе STRIPS, рассмотрим альтернативный метод. Предположим, что текущее состояние окружающего мира представлено в виде двумерного массива с элементами разного размера (в таком массиве элементы верхнего уровня — ячейки — представляют различные помещения, а элементы второго уровня — объекты в этих помещениях). Такой вариант представления компактнее описательного, но он не позволяет выполнять операции сопоставления, описанные в предыдущем разделе. Можно, конечно, придумать какой-нибудь способ описания целей и операций на языке, ориентированном на работу с массивами, но тогда будут утеряны некоторые из главных достоинств рассмотренной методики.
В качестве операторов придется использовать процедуры манипуляции с элементами массивов, которые с большим трудом воспринимаются человеком, а значит, отлаживать и конструировать операторы в такой форме значительно труднее, чем в форме таблиц операторов.
Программу будет значительно сложнее модифицировать и совершенствовать. Предположим, что усложнится размещение помещений и связи между ними. В таком случае придется полностью пересмотреть и вручную скорректировать все процедуры работы с массивами помещений и объектов, поскольку изменится размерность массива и связи между его элементами. А в системе STRIPS единственное, что нужно будет сделать в этом случае, — изменить модель мира, что делается значительно проще, поскольку при этом меняется не программный код, а только описания.
Предположим теперь, что в множество целей нужно включить, например, и такую: "перенести любые три ящика в комнату А", т.е. цель задает не единственное состояние мира, а множество состояний, удовлетворяющих сформулированному условию. При такой постановке проблемы набор процедур, ориентированных на табличное представление, придется пересмотреть коренным образом. Представление на базе конструкций предикат-аргумент позволяет выразить целевое состояние, введя в выражение переменные
at(X, комнатаА), at(Y, комнатаА), at(Z, комнатаА).
После этого можно использовать прежнюю методику поиска решения.
Поиск решения проблемы предполагает использование эвристик, поскольку, как правило, существует множество вариантов, среди которых приходится выбирать.
При единообразном представлении проще находить те операторы, которые можно применить в конкретной ситуации, и просмотреть, какой эффект даст их применение. Единообразное представление также значительно упрощает программную реализацию процесса поиска.
Часто удается достичь заданной цели, применяя методику понижения уровня сложности проблемы (problem reduction). При этом производится обратная трассировка проблемы — "отталкиваясь" от цели, выясняем, какие предварительные условия требуется удовлетворить для ее достижения, и формулируем на основе таких рассуждений более простые подцели. Этот процесс рекурсивно продолжается до тех пор, пока не будут сформулированы тривиальные подцели, достижимые с помощью простейших операций.
Язык представления, подобный тому, что используется в STRIPS, с точки зрения программной реализации является интерпретируемым языком, т.е. трансляция с этого языка выполняется интерпретатором, программой, которая способна распознавать в операторах языка формулы, подобные рush(ящик1, комнатаБ, комнатаА), и выразить заложенный в формулах смысл в терминах выполняемых процедур. Так, смысл приведенной выше формулы интерпретируется как необходимость достичь предварительных условий
at(робот, комнатаБ), at(ящик1, комнатаБ),
а затем реализовать действия, предписанные списками добавлений и исключений, т.е. добавить в модель мира состояние
at(po6oт, комнатаА), at(ящик1, комнатаА)
и исключить из модели мира состояние
at(робот, комнатаБ), at(ящик1, комнатаБ).
Такой подход к интерпретации получил наименование проиедуральной семантики (procedural semantics), поскольку все, что известно программе о смысле формулы, — какие действия ей нужно выполнить для того, чтобы формула получила значение Истина. Как отмечалось в главе 2, это не очень широкое толкование смысла, и такой подход вряд ля продвинет нас далеко в развитии машинного "понимания". Но, тем не менее, процедуральная семантика позволяет нам по крайней мере построить связь между мыслью и действием.
3.3. Формулировка подцелей в MYGIN
По сравнению с STRIPTS, программа MYCIN менее однородна и включает в свой состав множество различных модулей. Однако в структуре управления программой MYCIN можно найти элементы, в определенной мере схожие с элементами STRIPS. Это, в частности, относится к той части программы, которая реализует квазидиагностическую функцию. Правда, цель, которая должна быть достигнута в этом случае, является не физическим состоянием, а некоторым суждением, предполагающим формулировку диагностических гипотез.
В этом разделе основное внимание будет уделено диагностическому модулю MYCIN. Мы дадим несколько упрощенное описание его назначения, структуры и функционирования в процессе эксплуатации системы. Затем мы проведем сравнительный анализ работы модуля диагностирования MYCIN и работы STRIPTS, особо останавливаясь на тех качественных отличиях, которые существуют между классом экспертных систем, к которым принадлежит MYCIN, и классом исследовательских программ искусственного интеллекта, к которым относится STRIPTS. В конце этой главы мы кратко остановимся на эволюции экспертных систем, а затем вновь вернемся к этому вопросу в главе 14.
3.3.1. Лечение заболеваний крови
Сначала нам предстоит небольшой экскурс в ту предметную область, в которой используется MYCIN, — в область диагностики и лечения заболеваний крови. Это описание достаточно поверхностное, поскольку рассчитано на читателей, не имеющих специальных познаний в медицине. Но, как мы уже не раз подчеркивали, нельзя рассматривать структуру и работу экспертной системы в отрыве от той предметной области, с которой данная система имеет дело.
"Антимикробный агент"— это любой лекарственный препарат, созданный для уничтожения бактерий и воспрепятствования их роста. Некоторые агенты слишком токсичны для терапевтических целей, и не существует агента, который является эффективным средством борьбы с любыми бактериями. Выбор терапии при бактериальном заражении состоит из четырех этапов:
выяснить, имеет ли место определенный вид заражения у данного пациента;
определить, какой микроорганизм (микроорганизмы) мог вызвать данный вид заражения;
выбрать множество лекарственных препаратов, подходящих для применения в данной ситуации;
выбрать наиболее эффективный препарат или их комбинацию.
Первичные анализы, взятые у пациента, направляют в микробиологическую лабораторию, где из них выращивается культура бактерий, т.е. создаются наилучшие условия для их роста. Иногда уже на ранних стадиях можно сделать заключение о морфологических характеристиках микроорганизмов. Но даже если микроорганизм, вызвавший заражение, и идентифицирован, еще неизвестно (или нет полной уверенности), к каким препаратам он чувствителен.
Часто программу MYCIN считают диагностической, но это не так. Назначение этой программы — быть ассистентом врача, который не является узким специалистом в области применения антибиотиков при лечении заболеваний крови. В процессе работы программа формирует гипотезы диагноза и придает им определенные веса, но самостоятельно, как правило, не делает окончательного выбора. Работа над программой началась в 1972 году в Станфордеком университете и велась специалистами в области искусственного интеллекта в тесном сотрудничестве с медиками. Наиболее полное описание этой системы читатель найдет в работе Шортлиффа [Shortliffe, 1976].
После 1976 года система неоднократно модифицировалась и обновлялась, но базовая версия состояла из пяти компонентов (рис. 3.2). Стрелки на рисунке показывают основные потоки информации между модулями.
(1) База знаний содержит фактические знания, касающиеся предметной области, и сведения об имеющихся неопределенностях.
(2) Динамическая база данных пациентов содержит информацию о конкретных пациентах и их заболеваниях.
(3) Консультирующая программа задает вопросы, выводит заключения системы и дает советы для конкретного случая, используя информацию о пациенте и статические знания.
(4) Объясняющая программа отвечает на вопросы и дает пользователю информацию о том, на чем основываются рекомендации или заключения, сформулированные системой. При этом программа приводит трассировку процесса выработки рекомендаций.
(5) Программа восприятия знаний служит для обновления знаний, хранящихся в системе, в процессе ее эксплуатации.
Рис. 3.2. Структура системы MYC1N ([Buchanan and Shortliffe, 1984])
Подсистема, в которую входят компоненты 1, 2 и 3, отвечает за решение проблемы. Эта подсистема строит гипотезы относительно причин заболевания и формирует рекомендации, основываясь на этих гипотезах. Ниже мы подробнее рассмотрим принципы работы этих компонентов. Методы восприятия знаний, в частности и те, которые использованы в компоненте системы MYCIN, мы рассмотрим в главах 10-15, а работа объясняющей программы будет описана в главе 16
3.3.2. База знаний системы MYCIN
База знаний системы MYCIN организована в виде множества правил в форме если условие1 и... и условиет удовлетворяются то прийти к заключению1 и... и к заключению n
Эти правила преобразованы в операторы языка LISP (подробнее о программировании базы знаний рассказано в главе 4).
Вот как выглядит перевод на обычный язык типичного правила MYCIN:
ЕСЛИ 1) организм обладает грамотрицательной окраской, и
2) организм имеет форму палочки, и
3) организм аэробный,
ТО есть основания предполагать (0,8), что этот микроорганизм относится к классу enterobacteriaceae.
Такого рода правила названы оргправилами (ORGRULES) и в них сконцентрированы знания о таких организмах, как strepococcus , pseudonomas и enterobacteriaceae.
Это правило говорит о том, что если организм имеет форму палочки, пятнистую окраску и активно развивается в среде, насыщенной кислородом, то с большой вероятностью его можно отнести в классу enterobacteriaceae. Число 0.8 называется уровнем соответствия (tally) правила, т.е. мерой правдоподобия заключения, сделанного на основании сформулированных условий. Методика использования уровня соответствия правила будет рассмотрена ниже. Каждое правило такого вида можно рассматривать как представление в машинной форме некоторого элемента знаний эксперта. Возможность применить правило определяется тем, удовлетворяются ли в конкретной ситуации условия, сформулированные в первой его части. Сформулированные условия также носят нечеткий характер и могут удовлетворяться с разной степенью истинности. Поэтому в результате импортирования правил из базы знаний применительно к конкретной ситуации формируется более общее правило, включающее и оценки уровня истинности соблюдения условий:
если условие1 удовлетворяется с истинностью х1 и ... и условиеm удовлетворяется с истинностью хм,
то прийти к заключению1 со степенью уверенности у1 и ... и к заключениюn со степенью уверенности уn.
Здесь степень уверенности, связанная с каждым заключением, является функцией от оценок истинности соблюдения условий и уровня соответствия, отражающего степень уверенности эксперта при формулировке первичных оргправил.
Фактически правило является парой "предпосылка—действие"; такое правило иногда традиционно называют "продукцией" (подробнее об этом см. в главе 5). Предпосылка — это совокупность условий, а уверенность в достоверности предпосылки зависит от того, насколько достоверной является оценка условий. Условия — это предположения о наличии некоторых свойств, которые принимают значения истина либо
ложь с определенной степенью достоверности. Примером может служить условие в приведенном выше правиле:
"Организм имеет форму палочки".
Действие — это либо заключение, либо рекомендация о том, какое действие предпринять. Примером заключения может служить вывод о том, что данный организм относится к определенному классу. Пример рекомендации — сформулированный перечень лечебных процедур.
Мы детально проанализируем процесс применения правил в последующих разделах. А сейчас кратко остановимся на том, как в MYCIN для представления знаний используются структуры другого вида.
Помимо правил, в базе знаний MYCIN также хранятся факты и определения. Для их хранения используются разные структурные формы:
простые списки, например списки всех микроорганизмов, известных системе;
таблицы знаний с записями об определенных клинических показаниях и значениях, которые эти показания имеют при разных условиях; примером может служить информация о форме микроорганизмов, известных системе;
система классификации клинических параметров соответственно контексту, в котором эти параметры рассматриваются, например являются ли они свойством (атрибутом) пациентов или микроорганизмов.
Значительная часть знаний хранится не в виде правил, а в виде свойств, ассоциированных с 65 клиническими параметрами, известными системе MYCIN. Например, форма— это атрибут микроорганизма, который может принимать самые разнообразные значения, например "палочка" или "кокон". Система также присваивает значения параметрам и для собственных нужд — либо для упрощения мониторинга взаимодействия с пользователем, либо для индексации при определении порядка применения правил.
Информация о пациенте хранится в структуре, названной контекстным деревом (context tree). На рис. 3.3 показано контекстное дерево пациента ПАЦИЕНТ 1. В это дерево включены три культуры организмов (например, полученные из анализа крови пациента) и текущие назначения, которые нужно учитывать при анализе, поскольку они сопряжены с приемом определенных лекарственных средств. С культурами связаны микроорганизмы, присутствие которых предполагается на основании данных, полученных в лаборатории, а с микроорганизмами — лекарственные средства, оказывающие воздействие на них.
Предположим, что в записи, связанной с узлом ОРГАНИЗМ-1 в этой структуре, хранятся данные
ГРАН = (ГРАМ-ОТР 1.0)
МОРФ = (ПАЛОЧКА .8) (КОКОН .2)
ВОЗДУХ = (АЭРОБ .6),
которые имеют следующий смысл:
совершенно определенно организм имеет грамотрицательную окраску;
со степенью уверенности 0.8 организм имеет форму палочки, а со степенью уверенности 0.2 — форму колбочки;
со степенью уверенности 0.6 ОРГАНИЗМ-1 является аэробным (т.е. воздушная среда способствует его росту).
Рис. 3.3. Типичное контекстное дерево в системе MYCIN ([Buchanan and Shortliffe, 1984])
Теперь предположим, что применяется сформулированное выше правило. Нам требуется определить степень уверенности в выполнении всех трех перечисленных в нем условий применительно к данным, представленным в ОРГАНИЗМ-1. Степень уверенности в выполнении первого условия равна 1.0, второго — 0.8, а третьего — 0.6. Степень уверенности в выполнении совокупности условий принимается равной минимальному из значений, характеризирующих отдельные компоненты, т.е. 0.6.
В качестве оценки достоверности совокупности принимается минимальное значение по той причине, что рассчитывать на выполнение всех условий вместе можно не более, чем на выполнение самого "ненадежного" из них. Здесь очень уместна аналогия с цепочкой, прочность которой не может быть выше прочности самого слабого ее звена. Можно рассмотреть и обратный случай: какова степень уверенности в невыполнении совокупности условий? Она равна максимальному из значений, характеризующих невыполнение отдельных компонентов. Сформулированные выше соглашения легли в основу методики формирования неточных суждений, так называемой нечеткой логики, о которой мы поговорим в главе 9.
В данном случае мы приходим к заключению, что микроорганизм, описанный в узле ОРГАНИЗМ-1, относится к классу энтеробактерий со степенью уверенности, равной 0.6 х 0.8 = 0.48. Сомножитель 0.6 — это степень уверенности в выполнении совокупности условий, перечисленных в правиле, а 0.8 — степень уверенности в том, что правило дает правильное заключение, когда все означенные в нем условия гарантированно удовлетворяются. За сомножителями и результатом этого выражения закрепился термин коэффициента уверенности (CF— certainty factor). Таким образом, в общем случае имеем:
СF(действие) = СF(предпосылка) х СРF(правило)
Более подробно о коэффициентах уверенности мы поговорим в главах 9 и 21, где основное внимание уделяется теме представления неопределенности. Коэффициенты уверенности имеют много общего с оценками вероятности, но между этими двумя понятиями есть и определенные различия. Свойства этих коэффициентов не всегда подчиняются правилам теории вероятности и, таким образом, с математической точки зрения вероятностями не являются. Но методы вычисления коэффициентов уверенности некоторой совокупности правил или действий по коэффициентам уверенности, характеризующим отдельные компоненты в этой совокупности, в значительной мере напоминают методы вычисления вероятности сложных событий по вероятностям совершения событий-компонентов.
3.3.3. Структуры управления в MYCIN
Целевое правило самого верхнего уровня в системе MYCIN можно сформулировать примерно так:
ЕСЛИ 1) существует микроорганизм, который требует проведения курса терапии, и 2) заданы соображения относительно любых других микроорганизмов, которые требуют проведения курса терапии,
ТО сформировать список возможных курсов терапии и выделить наилучший из них. В ходе консультации выполняется простая двухэтапная процедура:
формируется контекст пациента в формесамого верхнего узла контекстного дерева;
предпринимается попытка применить целевое правило к этому контексту пациента.
Применение правила включает в себя оценку сформулированных в нем предпосылок, а этот процесс, в свою очередь, включает проверку, существует ли микроорганизм, который требует проведения курса терапии. Для этого сначала нужно выяснить, существует ли вообще факт заражения микроорганизмами, связанными с определенными болезнями. Эту информацию можно получить либо непосредственно от пользователя, либо воспользовавшись цепочкой рассуждений, основанных на наблюдаемых симптомах и имеющихся данные лабораторных исследований.
Консультация представляет собой, по сути, поиск на древовидном графе целей. В корне дерева располагается цель самого верхнего уровня — та часть целевого правила, в которой отображено действие, — рекомендуемый курс лекарственной терапии. На более низких уровнях размещаются подцели, которые представляют собой, например, выяснение, какие микроорганизмы обнаружены в зараженных тканях и насколько заражение каждым из них существенно. Многие из этих подцелей распадаются на более мелкие подцели. Листьями дерева являются факты, которые не нуждаются в логическом выводе, поскольку получены эмпирическим путем, например факты, установленные в лаборатории.
Для работы программы очень удобно представить процесс порождения подцелей с помощью особого вида структуры, названной И/ИЛИ-графом. Основная идея состоит в том, что корневой узел дерева представляет главную цель, а терминальные узлы — примитивные операции, которые может выполнить программа. Нетерминальные (промежуточные) узлы представляют подцели, по отношению к которым допустимо выполнить дальнейший анализ. Существует довольно простое соответствие между анализом таких структур и анализом множества правил.
Рассмотрим следующий набор правил "условие-действие":
Если
X имеет СЛУЖЕБНОЕ УДОСТОВЕРЕНИЕ И
X имеет ОГНЕСТРЕЛЬНОЕ_ОРУЖИЕ, ТО X - ПОЛИСМЕН.
ЕСЛИ
X имеет РЕВОЛЬВЕР, или
X имеет ПИСТОЛЕТ, или
X имеет ВИНТОВКУ, ТО X имеет ОГНЕСТРЕЛЬНОЕ ОРУЖИЕ.
Если
X имеет ЛИЧНЫЙ_ЖЕТОН, то
X имеет СЛУЖЕБНОЕ_УДОСТОВЕРЕНИЕ.
Эти правила можно представить в виде набора узлов в дереве целей (рис. 3.4), в котором отражены цели, которые выступают в совокупности, и те, которые воспринимаются независимо, по одиночке. Между связями, идущими от узла ПОЛИСМЕН (корневой узел — главная цель) к узлам СЛУЖЕБНОЕ_УДОСТОВЕРЕНИЕ и ОГНЕСТРЕЛЬНОЕ_ОРУЖИЕ, проведена дуга, которая подчеркивает, что для удовлетворения главной цели необходимо удовлетворить обе подцели. Но между связями, проведенными от узла ОГНЕСТРЕЛЬНОЕ_ОРУЖИЕ к узлам РЕВОЛЬВЕР, ПИСТОЛЕТ и ВИНТОВКА, такой дуги нет, поскольку для удовлетворения цели ОГНЕСТРЕЛЬНОЕ_ОРУЖИЕ достаточно удовлетворить любую из присоединенных подцелей. Узел может иметь и единственного наследника, как узел СЛУЖЕБНОЕ_ УДОСТОВЕРЕНИЕ на этом графе.
И/ИЛИ-граф на рис. 3.4 можно рассматривать как способ представления пространства поиска для цели ПОЛИСМЕН, перечислив все способы, которыми можно применить различные операторы, чтобы достичь главной цели.
Рис. 3.4. Представление набора правил в виде И/ИЛИ-графа
Такой вид структуры управления правилами получил наименование цепочки обратного вывода (backward chaining), поскольку путь рассуждений идет от того, что нужно доказать, к фактам, на которых основывается доказательство. При прямой цепочке рассуждение ведется, отталкиваясь от имеющихся фактов. В этом отношении система MYCIN напоминает STRIPS, где цель также достигалась разбиением ее на подцели, к которым можно было бы применить определенные операторы. Поиск решения в процессе построения цепочки обратного вывода более целенаправлен, поскольку рассматриваются только факты, потенциально способные повлиять на решение.
Структура управления правилами в MYCIN использует И/ИЛИ-граф и по сравнению с программами искусственного интеллекта довольно проста — в ней, по сути, использована методика исчерпывающего поиска, описанная в главе 2, в которую внесены только незначительные изменения.
(1) Формулировка каждой подцели всегда представляет собой обобщенную форму исходной цели. Так, если подцель состоит в том, чтобы доказать справедливость суждения "организм— это E.Coli", то формулировка такой подцели— определение типа организма. Этим инициируется исчерпывающий поиск, в который вовлекаются все возможные сведения об организмах.
(2) В множестве правил, подходящих для сформулированной цели, выискивается такое, которое определенно удовлетворяется. Если для заключения об определенном параметре, например о природе организма, подходит несколько правил, то их результаты объединяются (см. врезку 3.2). Если коэффициент уверенности какой-либо из выдвинутых гипотез оказывается в диапазоне от -0.2 до +0.2, то гипотеза отбрасывается.
(3) Если текущая подцель представляет собой лист на графе (терминальный узел), то данные запрашиваются у пользователя. В противном случае устанавливается очередная подцель и выполняется переход на шаг (1).
По завершении процесса диагностики выбирается рекомендуемый курс лечения. Выбор включает две стадии: отбор рекомендуемых медикаментов и предпочтительного варианта или комбинации медикаментов из полученного списка.
3.2. Комбинация гипотез
В системе MYC1N может оказаться, что для суждения об определенном параметре подойдет не одно правило, а несколько. Применение каждого из них — отдельная гипотеза — характеризуется некоторым значением коэффициента уверенности. Например, из одного правила следует, что данный микроорганизм— это E.Coli, причем коэффициент уверенности этой гипотезы равен 0.8. Другое правило, принимая во внимание другие свойства анализируемого объекта, приводит к заключению/что этот микроорганизм — E.Coli, но эта гипотеза характеризуется коэффициентом уверенности 0.5 (или, например, -0.8). Отрицательное значение коэффициента уверенности указывает, что данное правило опровергает сформулированное заключение.
Пусть х и у— коэффициенты уверенности одинаковых заключений, полученные при применении разных правил. В таком случае в системе MYCIN используется следующая формула определения результирующего коэффициента уверенности:
{
X+Y-XY
при X,Y>0
CF(X,Y)=
{
X+Y+XY
при X,Y<0
{
(X+Y)/(1-min(|X|,|Y|))
при (X>0 и Y<0) или (X<0 и Y>0)
Здесь |Х| означает абсолютное значение X.
Что при этом происходит, нетрудно понять интуитивно. Если обе гипотезы подтверждают вывод (или, наоборот, обе гипотезы его опровергают), то коэффициент уверенности их комбинации возрастает по абсолютной величине. Если же одна гипотеза подтверждает вывод, а другая его опровергает, то наличие знаменателя в соответствующем выражении сглаживает этот эффект.
Если оказалось, что гипотез несколько, то их можно по очереди "пропускать" через эту формулу, причем, поскольку она обладает свойством коммутативности, порядок, в котором обрабатываются гипотезы, значения не имеет.
Отдельное правило применяется по отношению к главной цели, представленной корневым узлом на И/ИЛИ-графе. Если удовлетворяются все, связанные с ним предпосылки, то это правило, вместо того чтобы формировать суждение, возбуждает определенное действие. Здесь в системе MYCIN на сцену выходят правила формулировки рекомендаций о курсе лечения. Эти правила включают информацию о чувствительности различных организмов, известных системе, к тем или иным медикаментам. Ниже приведено простое правило выдачи рекомендаций о лечении.
ЕСЛИ микроорганизм идентифицирован как pseudomonas,
ТО рекомендуется выбрать следующие медикаменты:
1 - COLISTIN (0.98)
2 - POLYMIXIN (0.96)
3 - GENTAMICIN (0.96)
4 - CARBENICILLIN (0.65)
5 - SULFISOXAZOLE (0.64)
Числа, следующие за названием каждого из перечисленных медикаментов, представляют оценки вероятности Того, что бактерия pseudomonas окажется чувствительной к этому препарату, и вводятся в систему исходя из существующей медицинской статистики. Предпочтительный препарат из этого перечня выбирается с учетом противопоказаний, специфичных для каждого пациента. Пользователь может пойти дальше и задавать вопросы об альтернативном курсе лечения до тех пор, пока система не исчерпает список вероятных диагнозов.
3.4. Оценка и сравнение характеристик экспертных систем
Существует множество способов оценки или сравнения характеристик экспертных систем, но наиболее распространенный — сравнение полученных с их помощью результатов с теми, которые получает человек-эксперт. При разработке системы инженер по знаниям и эксперт работают вместе, добиваясь того, чтобы с помощью системы решить весь набор типовых тестовых примеров. Затем системе предлагается решить "неизвестную" ей проблему и анализируется, насколько полученный результат согласуется с полученным экспертом.
3.4.1. Оценка системы MYCIN
Еще в 1974 году, на самой ранней стадии разработки системы MYCIN, были получены весьма обнадеживающие результаты. Команда из пяти высококвалифицированных экспертов в области диагностики инфекционных заболеваний подтвердила правильность 72% рекомендаций, сделанных системой, которые относились к 15 реальным заболеваниям. Главной проблемой оказалась не точность диагноза, а отсутствие правил, которые позволяли бы судить о серьезности заболевания.
В 1979 году были организованы более формальные испытания усовершенствованной версии MYCIN по диагностике таких заболеваний, как бактеремия и менингит. Окончательное заключение, вынесенное программой в 10 реальных случаях, сравнивалось с заключениями ведущих медиков Станфордского университета и рядовых врачей, причем рассматривались и такие случаи, в которых лечение уже проводилось. Затем были привлечены восемь других экспертов, которых попросили оценить рейтинг 10 рекомендаций о курсе лечения в каждом из рассмотренных случаев. Для каждого из предлагавшихся наборов рекомендаций была определена максимальная оценка 80 баллов, причем экспертам было неизвестно, что некоторые из них предложены не врачом, а компьютером. Результаты представлены ниже.
Рейтинг по заключению 8 экспертов на основании 10 клинических случаев
Максимально возможная оценка — 80 баллов
MYCIN
52
Курс лечения, назначенный в действительности
46
Faculty-1
50
Faculty-4
44
Faculty-2
48
Resident
36
Inf dis fellow
48
Faculty-5
34
Faculty-3
46
Student
24
Неприемлемый курс лечения
0
Одинаковые курсы лечения
1
Отличие между оценкой, полученной MYCIN, и оценками качества рекомендаций ведущих специалистов Станфорда, невелико, а по сравнению с рядовыми врачами система оказалась даже на более высоком уровне.
Однако по ряду причин (в том числе и перечисленных ниже) экспертная система MYCIN так никогда и не использовалась в реальной врачебной практике.
База знаний системы, включающая около 400 правил, все-таки недостаточна для реального внедрения в практику лечения больных инфекционными болезнями.
Внедрение системы требует приобретения достаточно дорогой вычислительной машины, что не могло себе позволить в те времена большинство лечебных учреждений.
Врачи-практики не испытывают никакого желания работать за терминалом компьютера, что совершенно необходимо для применения на практике экспертной системы. К тому же существующий в 1976 году интерфейс с пользователем в той версии системы MYCIN не был тщательно продуман.
Система MYCIN при всей ее практической направленности была и осталась все-таки экспериментальной исследовательской системой, не рассчитанной на коммерческое применение. Тем не менее на ее основе были созданы другие экспертные диагностические системы, которые реально использовались в лечебной практике (об одной из них — системе PUFF — читайте в главе 13).
В этой книге мы часто будем сталкиваться с оценкой качества отдельных моделей экспертных систем, и вы увидите, что выработать какой-то общий подход к такой оценке, не принимая во внимание специфику области применения, не удается. Однако можно выделить ряд предварительных условий, которые необходимо соблюдать для адекватной оценки качества экспертной системы любого назначения (этот вопрос обсуждается в сборнике под редакцией Хейеса-Рота [Hayes-Roth et al, 1983, Chapter 8]).
Должны существовать определенные объективные критерии правильности ответа, формируемого экспертной системой. В некоторых областях, например финансовых инвестиций, может не существовать иных критериев, кроме как оценивание сторонними специалистами вывода, сделанного системой, или выполнение рекомендаций на практике и анализ последующих результатов. Сложность первого способа состоит в том, что эксперт может не согласиться с самой постановкой проблемы в конкретном случае (особенно, если мы имеем дело со сложным случаем). Что же касается второго способа, то за оценку придется заплатить слишком дорого, если практическое воплощение рекомендации приведет к неожиданным последствиям.
Должна соблюдаться определенная процедура проведения эксперимента. Вместо того чтобы просить эксперта оценить качество ответа, предложенного компьютером, лучше предложить ему несколько вариантов решений, одни из которых предложены специалистами в этой предметной области, а другие — экспертной системой, причем эксперт не должен знать, есть ли среди предложенных вариантов "машинные". Именно так проводилась описанная выше процедура оценки качества системы MYCIN. При этом эксперт избавлен от возможно и неосознаваемой психологической "тенденциозности" в оценке того, что предлагается компьютером.
Оценка должна протекать безболезненно для эксперта либо ее вообще нет смысла проводить. Если оценка сопряжена с какими-либо неприятными для эксперта последствиями, то рассчитывать на его объективность, конечно же, нельзя. Нельзя проводить оценку, если существуют очень жесткие требования к времени ее выполнения и используемым при этом ресурсам. Вполне может оказаться так, что процесс оценки качества системы займет больше времени, чем ее разработка.
Читателю также должно быть ясно, что роль разных экспертных систем в той или иной предметной области может быть совершенно различной, соответственно различными должны быть и требования к ее производительности. Многие экспертные системы выполняют роль советчика и предоставляют пользователю набор возможных вариантов решения проблемы. В таком случае от системы требуется в основном сформировать как можно более "емкий" перечень вариантов решения проблемы при заданных ограничениях, причем система должна уложиться в разумное время. Другие системы предназначены для формирования законченного решения проблемы, которое пользователь может принять или отвергнуть. Учитывая, что последнее слово все-таки остается не за компьютером, а за человеком, система может быть признана вполне работоспособной и в том случае, если не все 100% предлагаемых ею решений правильны, но она должна быть способна достаточно живо реагировать на запросы
3.4.2. Сравнение MYCIN и STRIPS
Возвращаясь вновь к системе STRIPS, отметим, что, как показывает опыт работы с этой программой, она способна решать только самые простенькие проблемы. Сложности появляются при самых разных обстоятельствах. Вот только два примера.
Иногда оказывается, что прогресс в движении к заданной цели требует, чтобы окружающая среда была не более упорядоченной, а более неорганизованной (в смысле применения оценочной функции).
Если у системы появляется несколько целей, они начинают накладываться друг на друга и прогресс в движении к одной цели приводит к отдалению от другой.
Отчетливо видно, что модель мира в системе STRIPS оказалась "бедной на знания", т.е. она содержит очень мало специфических знаний о помещениях и объектах, которые должны перетаскивать роботы, например о весе и габаритах объектов и размерах дверных проемов в стенах. Для перемещения объектов используются только те эвристики, которые содержатся в таблице операторов. Например, отсутствуют эвристики, позволяющие избежать маршрутов движения через слишком узкие проемы, комбинировать перемещаемые объекты с учетом грузоподъемности робота. Отсутствует также подготовительная фаза, на которой можно было бы сгруппировать объекты, перемещаемые по близким маршрутам.
Более широкие возможности системы MYCIN в решении проблем проистекают от двух факторов: большой набор правил, которые используются для формирования гипотез и способов подтверждения их истинности, и большая база данных, в которой хранится информация о микроорганизмах, медикаментах и лабораторных тестах. В то же время механизм управления применением правил в MYCIN несколько проще, чем в STRIPTS. Основное различие между двумя программами состоит не в отличиях между областями применения, а в способности использовать декларативные знания в своей области.
В главе 2 мы обращали ваше внимание на то, что пионеры в области экспертных систем очень быстро пришли к выводу, что лучше передать программе фактические сведения о специфике предметной области и правила разного уровня абстракции, а затем применять довольно простые правила влияния, чем передать системе информацию о более общих законах, действующих в этой предметной области, и обобщенные алгоритмы целенаправленного логического вывода. Человек-эксперт предпочитает действовать исходя из общих законов только в особо трудных, необычных ситуациях, а в большинстве других использует уже апробированные, знакомые ему решения.
Мы также отметили, что одна из особенностей экспертных систем, отличающих их от обычных программ, состоит в широком использовании эвристик, которые помогают минимизировать количество шагов поиска при решении проблемы. Такой ускоренный путь решения проблем воспроизводит и механизм мышления человека-эксперта, который применяет базовые принципы только в редких случаях, а в большинстве ситуаций вполне удовлетворяется решениями из накопленного опыта. В результате цепочка рассуждений оказывается довольно короткой и крайне специфичной для каждой конкретной ситуации.
Использование эвристик также означает, что процесс рассуждений в экспертной системе не всегда может быть "озвучен", т.е. не всегда образует цепочку логической дедукции. Инженер по знаниям должен не только решить, как структурировать знания в базе знаний экспертной системы, но и как использовать эти знания в процессе построения заключения. Структура машины логического вывода обычно определяется как используемым представлением знаний, так и механизмом применения этих знаний. Например, на любой стадии решения проблемы может сложиться ситуация, когда возможно применение более чем одного правила (элемента знаний). Более того, эти правила могут взаимно не согласовываться или даже быть противоречивыми. Так, в систему планирования маршрута разносчика посылок могут быть заложены эвристические правила, одно из которых гласит:
"Первыми разнести посылки тем адресатам, которые расположены наиболее близко",
а второе:
"Избегать выезда в предместья во время напряженного трафика".
Если окажется, что довольно много адресатов компактно расположены в предместье, а расписание разноски составлено так, что посылки нужно доставить как раз тогда, когда на дорогах массовое движение, то эти два правила противоречат друг другу. Машина логического вывода должна быть спроектирована так, чтобы справляться с подобными противоречиями.
Довольно распространено мнение, что способ, основанный на эвристиках, может привести к ошибочному заключению, да и сами эвристики зачастую противоречивы. Тем не менее эвристики широко используются в экспертных системах, поскольку во многих областях их применения просто не существует надежных алгоритмов общего вида для поиска решения, либо такие алгоритмы требуют огромных вычислительных ресурсов в виду комбинаторного взрыва, т.е. экспоненциального роста сложности поиска при линейном росте размерности задачи (об этом мы говорили в главе 2). Отсюда ясно, почему при построении экспертных систем такое большое внимание уделяется средствам представления узкоспециальных знаний в конкретной предметной области, большинство из которых являются эвристиками. Подробный анализ различных схем представления таких знаний будет проведен в главах 4-8
Рекомендуемая литература
Идеи планирования операций, положенные в основу функционирования системы STRIPS, рассматриваются во множестве книг, посвященных проблематике искусственного интеллекта (например, [Givan and Dean, 1997]). Однако за время, прошедшее после появления STRIPS, многие пришли к выводу, что использованные в ней методы требуют слишком больших вычислительных ресурсов. В общем случае задача сводится к полному Р-пространству [Bylander, 1994]. Нильсон предложил программную реализацию формализма STRIPS [Nilsson, 1980], с версиями которой можно познакомиться на различных университетских Web-страницах, например по адресу http: / /www. cs. brown. edu/research/ai.
Наиболее полное описание системы MYCIN читатель найдет в работе [Shortliffe, 1976]. Анализ функциональных возможностей MYCIN и описание отдельных подсистем содержится в работах [Buchanan and Shortliffe, 1984] и [Clancey and Shortliffe, 1984]. В последней читатель найдет также описание некоторых других ранних экспертных систем, ориентированных на медицинскую диагностику. В работе [Cendrowska and Bramer, 1984] описана модификацию системы MYCIN и приведено много интересных деталей реализации программы
Упражнения
1. Что такое таблица операторов? Можно ли в таблице операторов представить любую операцию, выполнение которой хотелось бы потребовать от робота?
2. Что такое порождающее правило? Какое, на ваш взгляд, существует соответствие между набором порождающих правил и деревом решений?
3. Какая связь существует между таблицами операторов и набором порождающих правил? Эквивалентны ли они? Можно ли выразить одни в терминах других?
4. Представьте себе, что манипуляционный робот смонтирован над столиком с детскими игрушками. В таблице операторов имеется оператор move (В, L, М), который заставляет робот перенести блок В из положения L в положение М.
move (В, L, M)
Предварительные условия on (В, L), clear (В), clear (M)
Список удалений on (В, L), clear (M)
Список добавлений on (В, L), clear (L), clear (столик)
Здесь выражение on (В, L) означает, что блок В устанавливается на объект L, причем в качестве L может выступать или поверхность столика, или другой блок; непосредственно на один блок можно поставить только еще один блок, но на поверхность столика можно ставить сколько угодно блоков; выражение clear (L) означает, что на объекте L ничего не стоит.
I) Выразите сцену, представленную на рис. 3.5, в виде формул модели мира.
II) Пусть перед роботом поставлена цель перестроить башню, показанную на рис. 3.5, установив блоки в следующем порядке: синий— на красном, красный — на зеленом, а зеленый — на поверхности столика. Таким образом, перед роботом стоит цель преобразовать модель мира и привести ее к виду
on(зеленый, стол), on(красный, зеленый), on(синий, красный). Представьте план достижения этой цели.
III) Покажите, как будет изменяться база данных при выполнении плана в соответствии с таблицей операторов.
IV) Почему после каждой операции move нужно добавлять формулу clear (столик)?
V) Можно ли, используя представленный элемент move в таблице операторов, выразить "отрицательную" цель, например "зеленый блок не должен стоять
Рис. 3.5. Задача о перемещении блоков
5. Как можно удостовериться в правильности простого плана (как созданный в предыдущем примере), в том смысле, что он гарантирует успешное достижение поставленной цели, предполагая, что робот выполняет все операции правильно.
6. Можете ли вы представить вид плана, который не может быть сформирован с помощью простого формализма таблицы операторов, наподобие представленного в предыдущем упражнении.
7. Рассмотрим правило системы MYCIN, представленное ниже:
ЕСЛИ
1) организм обладает грамположительной окраской, и
2) организм имеет форму колбочки, и
3) организм в процессе роста образует цепочки,
ТО есть основания предполагать (0,7), что этот микроорганизм относится к классу streptococcus.
Предположим, что сформулированные в правиле условия характеризуются следующими коэффициентами уверенности:
Условие 1: 0.8 Условие 2: 0.2 Условие 3: 0.5
Какой коэффициент уверенности характеризует заключение о том, что данный организм относится к классу streptococcus, которое вынесет MYCIN в соответствии со сформулированным правилом?
8. Рассмотрим такую пару правил системы MYCIN:
ЕСЛИ
1) культура взята из анализа крови и
2) пациент страдает повреждением кожи ecthyma gangrenosum,
ТО есть основания предполагать (0,6), что этот микроорганизм относится к классу pseudomonas.
ЕСЛИ
1) тип инфекции бактериальный и
2) пациент имеет серьезные ожоги,
ТО есть слабые основания предполагать (0,4), что этот микроорганизм относится к классу pseudomonas.
Предположим, что сформулированные в первом правиле условия характеризуются коэффициентами уверенности 0.8 и 0.9, а сформулированные во втором правиле — коэффициентами уверенности 0.2 и 0.3. Какой коэффициент уверенности будет характеризовать вывод, что исследуемый микроорганизм относится к классу pseudomonas?
9. Начертите И/ИЛИ-граф по типу приведенного в разделе 3.3.3 для следующего набора правил.
Если
ТОПЛИВО, и
ВЫДЕЛЕНИЕ_ТЕПЛА,
и КИСЛОРОД,
то ПОЖАР
Если
ЖИДКОСТЬ и
ВОСПЛАМЕНЯЕМАЯ, то ТОПЛИВО
Если
ТВЕРДОЕ и
ГОРЮЧЕЕ, то ТОПЛИВО
Если
ГАЗ и
ГОРЮЧЕЕ, то ТОПЛИВО
Если
ПЛАМЯ и
ОТКРЫТОЕ, то ВЫДЕЛЕНИЕ_ТЕПЛА
Если
ЭЛЕКТРИЧЕСТВО,
ТО ВЫДЕЛЕНИЕ_ТЕПЛА
Если
ТРЕНИЕ,
ТО. ВЫДЕЛЕНИЕJTEIU1A. 10.
Выразите правила предыдущего упражнения средствами языка CLIPS (см. Приложение).
ГЛАВА 4. Символические вычисления
4.1. Символическое представление
4.2. Физическая символическая система
4.3. Реализация символических структур на языке LISP
4.3.1. Структуры данных в языке LISP
4.3.2. Структура LISP-программы
4.3.3. Приложение функции и лямбда-исчисление
4.3.4. Обработка списков
4.3.5. Сопоставление с образцом
4.4. Почему LISP не является языком представления знаний
4.4.1. Символический уровень и уровень знаний
4.4.2. LISP и разработка программ
4.5. Языки представления знаний
Рекомендуемая литература
Упражнения
ГЛАВА 4. Символические вычисления
4.1. Символическое представление
4.2. Физическая символическая система
4.3. Реализация символических структур на языке LISP
4.4. Почему LISP не является языком представления знаний
4.5. Языки представления знаний
Рекомендуемая литература
Упражнения
Прежде чем приступить в обсуждению специализированных языков представления знаний, остановимся на более общей теме языков программирования задач искусственного интеллекта. В этой главе мы не задавались целью научить читателя пользоваться определенным языком, а стремились познакомить с некоторыми темами, касающимися представления и управления, которые имеют отношение к программной реализации экспертных систем. Интересно отметить, что широко распространившийся в современной практике создания программного обеспечения объектно-ориентированный подход к анализу и разработке должен привести к определенному сближению методик решения проблем, предполагающих использование идей искусственного интеллекта и не предполагающих такового. Кроме того, представление приложения как совокупности взаимодействующих относительно автономных модулей очень близко к подходу, реализуемому методами искусственного интеллекта. По мере того как все больше специалистов отдают предпочтение такому образу мышления, средства, используемые для решения обычных задач и задач искусственного интеллекта, будут становиться все более близкими.
В этой главе читатель найдет:
объяснение, почему исследования в области искусственного интеллекта и создание соответствующих приложений требуют применения языков программирования определенного вида;
обсуждение специфических свойств таких языков, отличающих их от широко используемых в практике программирования задач обработки данных и научных расчетов;
вводные сведения об основных концепциях языка LISP, который на определенном этапе стал основным языком программирования задач искусственного интеллекта;
объяснение, почему LISP редко выбирается в качестве базового языка при построении экспертных систем;
объяснение, почему чаще используются более специализированные языки вроде CLIPS (подробное описание этого языка приведено в Приложении).
Специализированные языки, объектно-ориентированный подход и программные инструментальные средства, предназначенные для построения экспертных систем, мы подробно рассмотрим в главах 5, 7 и 17. В этой же главе мы в первую очередь сосредоточим внимание на концепциях программирования и структурах, существенно влияющих на конструирование экспертных систем. Детали реализации и специфические приемы будут рассмотрены в соответствующих разделах других глав в контексте конкретных систем (главы 11-16).
Одна из причин, по которой мы уделяем такое внимание языку LISP в этой главе, состоит в том, что многие языки, появившиеся на свет после него, имеют синтаксис, очень близкий синтаксису LISP (в частности, это относится к языку CLIPS), и включают очень много языковых конструкций, заимствованных из LISP. Однако при построении экспертных систем иногда используются языки, существенно отличающиеся от LISP, например PROLOG, которому будет уделено особое внимание в главе 8 при рассмотрении концепции логического программирования. Синтаксис, основанный на логическом формализме, который уже упоминался в главе 3 при обсуждении системы SRTIPS, имеет много общего с синтаксисом языка PROLOG.
4.1. Символическое представление
Понятие символ настолько распространено в современной теории и практике искусственного интеллекта, что важность его трудно переоценить. Именно на этом понятии базируются главные связи между проблематикой искусственного интеллекта и формальными системами математики и логики. Если воспользоваться самой понятной терминологией, то символ — это нечто, замещающее другое нечто. В этом определении "другое нечто" обычно называется значением (designation) символа. Это то, на что ссылается и что представляет символ. Значением может быть физический объект или понятие (концепт), но сам символ является физическим объектом. Так, цифра "7" является символом, представляющим число 7, которое является понятием.
Идея, которая скрывается за термином "символические вычисления", состоит в том, что мы можем понимать под символом, с которым выполняются какие-то действия, все, что угодно. Языки программирования, основанные на этой парадигме, поддерживают множество простейших структур данных, связывающих одни символы с другими, а также примитивные операции манипулирования символами и структурами символов. Таким образом, программист должен специфицировать
такие синтаксические правила формирования символических структур из символов, которые придают сформированным структурам смысл, зависящий от смысла компонентов;
правила трансформации, регламентирующие преобразование одних символических структур в другие.
Как правило, программы манипуляций с символами принимают в качестве исходной информации одну или более символических структур, представляющих исходное состояние решаемой проблемы, и возвращают символическую структуру, представляющую конечное состояние проблемы или ее решение, причем и вход, и выход должны иметь форму, удовлетворяющую оговоренные синтаксические правила, а преобразование входных символических структур в выходную должно выполняться только с использованием дозволенных правил трансформации. Программа на таком языке сама по себе также является символической структурой. Поэтому нет никаких формальных препятствий к тому, чтобы некоторая программа не могла рассматриваться в качестве исходных данных для другой, а отсюда следует вывод, что такое единообразие в представлении программ и данных очень полезно в контексте проблематики искусственного интеллекта. Но еще более важной является идея, что можно сделать нечто большее, чем просто сформулировать правила манипулирования символами, — мы можем воплотить эти символы вместе с правилами манипулирования ими в виде какого-то физического устройства. Отсюда следует очень, казалось бы, простая и в то же время очень продуктивная идея — идея физической символической системы.
4.2. Физическая символическая система
Ньюэлл [Newell, 1981] описывает физическую символическую систему как помещенную в некоторую среду машину, состоящую из следующих компонентов:
памяти, включающей символические структуры, число и содержание которых может изменяться во времени;
набора операторов для манипулирования символическими структурами, например чтения, записи, копирования;
средств управления, предназначенного для непрерывной интерпретации текущей активной символической структуры или структуры, к которой выполняется обращение;
средств ввода из окружающей среды посредством рецепторов и вывода в окружающую среду посредством эффекторов.
Программа в физической символической системе — это также символическая структура, которая интерпретируется или обрабатывается каким-то способом, зависящим от символов, составляющих ее (программу), и от символов, полученных от средств ввода. Простейшие программы соответствуют операторам манипулирования символами, а более сложные описывают процедуры, скомпонованные из этих операторов. Средства управления способны отличать данные от программы, хотя и те и другие являются символическими структурами. Физическая символическая система весьма схожа с компьютером общего назначения, оснащенным программами обработки символов. Известно, что компьютер с хранимой программой является универсальной машиной (грубо говоря, он может моделировать операции любой другой машины), а следовательно, обладает способностью воспроизводить все обобщенные рекурсивные функции (т.е. все функции, которые могут быть реализованы любой машиной). Именно наличие такого средства, которое потенциально подходит для реализации абстрактной физической символической системы, и вдохновило исследователей на смелое предположение, что машина может обладать интеллектом.
В следующем разделе мы рассмотрим реализацию и использование физической символической системы в искусственном интеллекте.
4.1. Главная гипотеза
Ньюэлл и Саймон следующим образом сформулировали гипотезу физической символической системы (Physical Symbol System Hypothesis) [Newell and Simon, 1976]:
"Физическая символическая система имеет необходимые и достаточные средства для того, чтобы производить осмысленные действия".
Другими словами, без символических вычислений невозможно выполнять осмысленные действия, а способность выполнять символические вычисления вполне достаточна для того, чтобы быть способным выполнять осмысленные действия. Таким образом, если мы полагаем, что животное, или человек, или машина действуют осмысленно, то значит, они каким-то образом выполняют символические вычисления. (Ваш кот в действительности умнее, чем вы думаете.)
Независимо от того, справедлива ли эта гипотеза, символические вычисления стали реальностью, и полезность этой парадигмы для программирования трудно отрицать.
4.3. Реализация символических структур на языке LISP
Как только мы беремся за задачу реализации символических структур и выполнения операций над такими структурами, немедленно встает вопрос, о каких именно структурах идет речь. Символы в логике и математике обычно организованы в виде множеств или последовательностей. Посмотрим, как эти формальные структуры, достаточно понятные на абстрактном уровне, можно использовать в качестве базиса для структуры, объединяющей физические символы.
Множество — это неупорядоченный набор элементов, в то время как физические символы в структуре должны занимать определенное положение (это положение может быть скрытым от программиста, и он может рассматривать структуру как неупорядоченное множество, но это уже относится в особенностям реализации). Последовательность, как структура, позволяет говорить о месте символа в этой последовательности, но абстрактная последовательность может быть бесконечной.
Хорошим кандидатом на место базисной структуры в физической символической системе является список— элементы в списке занимают совершенно определенное место и его можно однозначно связать с каждым отдельным элементом. С помощью списка можно представить и множество, и последовательность, хотя размерность последней и ограничена физическими характеристиками среды реализации.
4.3.1. Структуры данных в языке LISP
Одним из первых языков обработки списков был LISP2 [McCarthy, 1960]. За четыре десятилетия, которые прошли после появления его первой версии, язык неоднократно, модифицировался и расширялся, но в основе своей изменился мало. Разработчики языка утверждали, что LISP отличается от прочих языков программирования следующими свойствами [McCarthy et al, I960]:
основной структурой данных в нем является список;
программы на этом языке также имеют списочную структуру;
его базовыми операциями являются операции над списками.
В 1960 году выбор списков в качестве базовой структуры языка программирования рассматривался как революционный шаг. Сейчас большинство языков программирования общего назначения тем или иным образом поддерживает операции над списочными структурами, хотя от программистов обычно требуется запрашивать выделение памяти для формирования списка, а затем после его использования — возвращать память системе. В LISP еще на ранних стадиях развития в исполняющую систему был встроен механизм "уборки мусора", и программисту не требовалось следить за распределением памяти.
Базовым блоком в структуре данных языка LISP является символическое выражение. Простое символическое выражение использует атомарные символы, или атомы — строки буквенно-цифровых символов, которые начинаются с буквы, например WOMBAT. (Допустимая длина строки варьируется в зависимости от версии исполняющей системы.) Во внутренней структуре данных атом представлен ячейкой памяти. Отдельным атомом является символ Т, которым представляется константа "True" — истина. Другой специальный атом, NIL, представляет, с одной стороны, константу "False"—ложь, а с другой — пустой список.
Составные выражения объединяются в древовидной структуре, при этом используется очевидное соответствие между символическими выражениями и представлением конечных деревьев. Читатели, склонные к математическим формулировкам, найдут более строгое изложение этого соответствия во врезке 4.2.
Списки представляют собой довольно гибкие структуры данных, поскольку могут объединять элементы разных типов и иметь произвольную длину и размерность (вложенность). Например, в LISP возможен такой список:
("а" (9) () N (? (WOMBAT)) (A . В) NIL 0.9)
Этот список содержит элементы разных типов — строки, числа с фиксированной и плавающей точкой, атомы, булевы значения, точечные пары и другие списки.
Но списки имеют и определенные недостатки, из-за которых в LISP были включены и другие структуры данных. Списки в LISP представляют собой стеки, т.е. доступ к ним возможен только с одного конца списка. Манипулируя только таким списком, невозможно обратиться к элементу списка по его позиции, как это делается с элементом массива. Поэтому для представления больших совокупностей относительно постоянных или редко меняющихся данных в LISP были включены другие типы структур. В современных версиях LISP поддерживаются массивы, хэш-таблицы и структуры, подобный записям, которые позволяют эффективнее использовать пространство памяти и повысить скорость доступа.
4.2. Списки и точечные пары
Пусть задан оператор "." для комбинирования ячеек в древовидной структуре. Тогда определение символического выражения в LISP можно сформулировать следующим образом.
Любой атом является символическим выражением.
Если А1 и А2 суть символические выражения, то (А1 A2)— это также символические выражения.
Если S = (А,. (А2 . (.... (Ап-1. AJ ....))) — суть символическое выражение для некоторого п>0, то S — список тогда и только тогда, когда Аn =NIL.
В соответствии с этим определением, если п=0, то S представляет собой пустой список, NIL. Такое определение допускает существование списка списков, а также списка атомов. Если S1 S2, ..., Sn— символические выражения, то мы будем представлять список
S1.(S2.(.... (Sn. NIL)....)))
в виде
(S1 S2.... Sn)
Таким образом, (А . (В . NIL)) является списком. Он представляет список (А В), но (А . (В. С)) списком не является, поскольку (С=NIL)).
Символическое выражение, которое не является ни атомом, ни списком, называется точечной парой. Если (А . В) — точечная пара, то А — это голова пары, а B — ее хвост. Точечные пары могут иметь произвольную сложность. Так, ((А . В). С) — тоже точечная пара, так же, как и ((А . В) . (С. D)). Благодаря наличию соответствия между точечными парами и списками, понятия головы и хвоста определены и для списков. Поскольку список (А В) — это (А . (В . NIL)), то очевидно, что А — голова в списке (А В), а хвост — это (В), но не В. Хвостом списка (В) является NIL
4.3.2. Структура LISP-программы
Как использовать список в качестве базовой структуры данных, понятно. Сложнее представить себе, как можно организовать программу или выражение программы в виде списка. Например, список
(+ X Y) представляет математическое выражение в форме
(<функция> <1-й аргумент> <2-й аргумент>),
которое обозначает сложение двух чисел. Такой метод обозначений (нотация) отличается от привычного нам обозначения функции п переменных в виде f(x1, ... xn). Но возникает вопрос, как компилятор или интерпретатор отличает данные от программы, если и то и другое представлено списками.
Необходимо иметь возможность определить значение такого выражения— например, значение выражения ( + X Y). Для этого нужно отыскать определение функции (в данном случае — функции +). В этом определении должна содержаться та последовательность элементарных операций, которую нужно применить к аргументам, чтобы определить значение функции.
Нужно иметь средства сформировать определение функции и применить это определение к аргументам, т.е. к действительным, а не формальным параметрам. Механизм определения функции и приложения функции базируется на логической системе, названной лямбда-исчислением (см. [Church, 1941]). Лямбда-исчисление является скорее функциональным, чем исчислением отношений, и в этом состоит различие между ним и исчислением предикатов первого порядка. В функциональном исчислении первичным понятием является отношение "многие-к-одному", а не "многие-ко-многим". Так, отец — это функциональное отношение, а брат — более общее отношение, поскольку каждый человек может иметь только одного отца, а братьев можетбыть несколько. Ниже в этой главе мы более подробно остановимся на связях между языком LISP и лямбда-исчислением.
Нужно располагать средствами доступа к текущим значениям переменных (или формальных параметров), таких как X и Y. Вычисление каждого символического выражения выполняется в контексте формирования переменных. Нужно располагать средствами сохранения и восстановления этого контекста при вычислении значений сложных символических выражений, т.е. вычисления и комбинирования значений содержащихся в них подвыражений.
При вычислении сложных символических выражений, когда необходимо вычислять значения его компонентов, которые являются сложными выражениями, нужно располагать средствами сохранять текущее выражение и промежуточные результаты. Необходимо также обладать средствами копирования символических выражений.
Нужно уметь подавлять вычислительную обработку списков, которые не являются операторами программы, а структурами данных. Например, не нужно пытаться вычислять выражение, подобное следующему:
((1 2 3)(4 5 6)(7 8 9))
и пытаться отыскать определение функции (1 2 3).
Для этого существует специальная форма выражения (QUOTE X) для любых X, которая возвращает X. Точно такое же действие выполняется и выражением (quote X).
Современные версии LISP не чувствительны к регистру символов, хотя и возможно так сконфигурировать исполнительную систему, что она станет по-разному воспринимать символы верхнего и нижнего регистров.
4.3. Функции, их вычисление и проблема цитирования в CLIPS
Существуют два основных метода разрешения проблемы цитирования, т.е. предотвращения интерпретации данных как функций или выражений. Один метод заключается в том, чтобы в число системных функций ввести специальную функцию, которая рассматривается интерпретатором как указание не обрабатывать последующий список. Такой системной функцией в LISP является QUOTE. Другой метод состоит в том, чтобы по умолчанию подавлять механизм оценивания значения (вычисления) до тех пор, пока специальная синтаксическая конструкция его не запустит. В языке CLIPS использован именно такой метод.
Например, в CLIPS можно следующим образом определить функцию:
(deffunction between(?lb ?value ?ub)
(or (> lib ?value) (> ?value ?ub))))
Эта функция определяет, попало ли заданное целочисленное значение в диапазон между указанными нижним и верхним пределами. Знак вопроса, предшествующий именам, говорит интерпретатору CLIPS, что выражения ?lb, ?value и ?ub являются переменными и их не нужно оценивать.
Общепринятым методом реализации функциональных языков типа LISP является использование четырехстековой машины, за которой закрепилось наименование SECD-машины. В четырех стеках машины отслеживаются промежуточные результаты, значения переменных, текущее выражение и копии текущего состояния процесса вычислений сложного выражения, которые нужны, чтобы восстановить состояние после завершения вычисления вложенного выражения (подвыражения). Не вдаваясь в подробности, отметим, что процесс оценивания символического выражения в такой машине — это не что иное, как реализация базовой операции приложения функции, как это определено в лямбда-исчислении (см., например, [Henderson, 1980], [Glaser et al., 1984]).
4.3.3. Приложение функции и лямбда-исчисление
Для того чтобы разобраться в связи между лямбда-исчислением и языком LISP, нужно постоянно держать в уме сформулированное Черчем отличие между денотацией (означиванием) и абстракцией. Так, выражение (X X) означивает конкретное число, которое зависит от значения X. Но то же число можно получить и при помощи функции square(X), которая является абстракцией, поскольку ее можно приложить к разным значениям X. Для того чтобы отличить означивание от абстракции, первое представляется в лямбда-исчислении в таком виде:
(лх)(X х)
Говорят, что лямбда-оператор, X, связан с переменной X, как квантор связывает отдельные переменные в исчислении предикатов. Тогда (ЛХ)(X X) может служить определением функции возведения в квадрат:
square(X) = (лX)(X X)
Теперь для применения функции возведения в квадрат к конкретному числу, скажем 3, мы должны каким-то образом подставить 3 вместо переменной X и оценить (X ,Х), в результате чего получим 9. Когда определение функции применяется к аргументу 3, используется правило влияния, получившее наименование лямбда-преобразования. Доложим, что (лХ)М определяет любую лямбда-абстракцию, и пусть S(a, X, М) — результат подстановки X в М.
Лямбда-преобразование. Заменим любую часть (lХ)М в формуле на s(a, x, М), причем ограниченные переменные в м отличны как от х, так и от свободных переменных а.
Если мы полагаем, что ((ЛХ)М) а обозначает применение определения функции (ЛХ)М к аргументу а, то
((ЛХ)(Х Х))(3) = (3 3) = 9 .
Какое же все это имеет отношение к языку LISP? А вот какое. Определение функции возведения в квадрат в LISP выглядит примерно так:
(defun SQUARE (X) (LAMBDA (X) ( X X))) .
В различных диалектах языка допустимы вариации, но смысл остается тем же. В частности, в диалекте COMMON LISP используется сокращенная форма
(defun SQUARE (X) ( X X)) .
В любом случае имя функции, в данном случае SQUARE, ассоциируется в определении с лямбда-выражением. Выражение (LAMBDA (X) ( X X)) — это просто синтаксический вариант ((ЛХ) (X X)). Фактически, если определено SQUARE, в любом диалекте LISP имеем
(SQUARE 3) = ((LAMBDA (X)
( X X)) 3) = ((АХ)(Х Х))(3) = 9 .
Обратите внимание на то, что LAMBDA не является функцией. Это специальный оператор в лямбда-исчислении.
Синтаксическая форма вызова функции в языке LISP имеет вид
(<функция> <аргумент> ... <аргумент>).
Это не самая сложная синтаксическая форма, а вместе с QUOTE, LAMBDA и условными выражениями этим фактически исчерпывается все, что необходимо знать о синтаксисе языка LISP. Тем, кто по каким-то иррациональным причинам испытывает тягу к запятым, двоеточиям, точкам с запятой, палиндромам вроде (if... ft, case ... esac) и тому подобному, будет поначалу трудно свыкнуться с мыслью, что в LISP единственным ограничителем являются круглые скобки. Программа на языке LISP — это просто структура данных, и другая LISP-программа ее может читать, записывать и обрабатывать точно так же, как любой другой набор данных.
4.3.4. Обработка списков
Языку LISP можно дать очень лаконичное формальное определение. Большинство LISP-программ можно специфицировать, используя только пять простейших операторов над символическими выражениями (см. врезку 4.4) и одну специальную форму (условное выражение). Эта элегантность и красота языка LISP часто не заметна неопытному взгляду, поскольку большинство LISP-приложений включает множество дополнительных операторов, собственно к LISP не относящихся. Современные диалекты LISP в буквальном смысле задыхаются от программных конструкций, заимствованных из языка FORTRAN, некоторые из которых оказались полезными, а другие просто вызывают отвращение (справедливости ради, нужно отметить, что некоторые обладают и тем и другим).
Как оказалось, структурой, наиболее подходящей для нечисловых вычислений, являются списки. Именно такие вычисления необходимо выполнять в процессе поиска решения в пространстве альтернатив, как это было показано в главе 2. В списке можно держать в поле зрения те альтернативные варианты, которые уже были рассмотрены ранее, не которые еще предстоит рассмотреть, и т.д. Поскольку между списками и древовидными ориентированными графами существует изоморфизм, естественно представлять развернутое пространство состояний в виде одного или более списков.
4.4. Примитивы в LISP
В языке LISP имеется пять операций, которые, хотя и не имеют специальных наименований, лежат в основе всех остальных. LISP использует их в качестве виртуального машинного кода" при построении более сложных примитивов. Например, в LISP имеются полиморфные предикаты равенства.
Пусть s — множество символических выражений. Можно, например, записать:
Е(Х , Y): S x S -> {Т, NIL}
Это означает, что Е является функцией двух аргументов, причем оба аргумента — символические выражения из множества S, которые могут принимать значение либо Т, либо NIL.
(1)Е(Х , Y): S x S -> {Т, NIL} проверяет, равны ли два атома.
(2)А(Х): S -> {Т, NIL} проверяет, является ли символическое выражение атомом.
(З)Н(Х): S -> S извлекает голову символического выражения, которое не является атомом; если х — атом, то результат функции не определен.
(4) Т(Х): S —> S извлекает хвост символического выражения, которое не является атомом; если х — атом, то результат функции не определен.
(5)С(Х , Y): S х S —> S формирует символическое выражение; если А и в являются символическими выражениями , то можно сформировать новое символическое выражение (А . В).
Совокупности операции композиции функций и условного оператора описанных оераций вполне достаточно для того, чтобы вычислить любую обобщенную рекурсивную функцию. Композиция функций — это способность сделать значение одной срункции аргументом другой, т.е. организовать гнездование функций, например С(Н(Х), У).
Фактически система, состоящая из трех компонентов
(1) единственного атома NIL;
(2) условного выражения, проверяющего равенство, в форме
if E(X, NIL) then ... else ... 3) функций Н(Х), Т(Х), С(ХД)
к которым добавлена операция композиции функций, вполне позволяет реализовать машину Тьюринга (см. [Minsky, 1972, Chapter 10]).
Можно использовать списки и для представления ассоциативной связи одних символов с другими. Например, список
((Alabama Montgomery) (Alaska Juneau) (Arizona Phoenix) ... )
позволяет представить столицы пятидесяти штатов. Представленная ниже LISP-программа сможет затем извлечь название столицы заданного штата из этого ассоциативного списка.
(defun assoc (key alist)
(cond ((null alist) NIL)
((eq (first (first a list)) key) (first alist))
(T (assoc key (rest alist)))) )
Если обратиться к этой функции с помощью, например, выражения (assoc 'Alaska '((Alabama Montgomery) (Alaska Juneau) (Arizona Phoenix) ... ), то функция возвратит список
(Alaska Juneau) .
NULL — это предикат, который проверяет, не пуст ли список, EQ — предикат, который проверяет равенство двух атомов, FIRST — функция, которая возвращает головной элемент списка, a REST — функция, которая возвращает хвост списка (см. врезку 4.4).
Основным условным выражением в LISP является COND. В приведенном выше фрагменте программного LISP-кода это условное выражение может быть расшифровано следующим образом:
если alist это null, то вернуть NIL, иначе
{
если головной элемент головного элемента alist равен key, то вернуть головной элемент alist,
иначе вернуть результат применения функции assoc к хвосту alist. }
Условное выражение COND можно представить в терминах примитива if-then-else, описанного во врезке 4.4. Выражение COND может включать сколько угодно вложенных конструкций if-then-else.
Конечно, ассоциативные списки — это не самое лучшее средство хранения данных, но наш пример с таким списком помог вам представить, как в LISP организуется рекурсивная обработка списков
4.3.5. Сопоставление с образцом
Одним из ключевых компонентов в большинстве программ искусственного интеллекта является анализатор соответствия (pattern matcher) — компонент, который некоторым образом сравнивает поступающие на его вход списки (или другие структуры данных) с имеющимися символическими образцами и таким образом выполняет распознавание входных данных.
В главе 3 мы обращали ваше внимание на то, что факты, относящиеся к состоянию окружающего мира, представляются в форме "предикат— аргумент". Тот факт, что робот находится в комнате, был представлен в модели мира формулой
at(robot, room). На языке LISP этот факт будет представлен символическим выражением
(at robot room). Положим, что ? — символ универсальной подстановки и что выражение
(at robot ?) представляет собой образец, которому соответствует и выражение
(at robot room), и другое выражение в форме
(at robot blah),
где blah — любой символ. На языке LISP несложно разработать простой анализатор соответствия, который будет сравнивать два ординарных списка (т.е. списка, на имеющего подсписков в качестве элементов) и возвращать значение TRUE, если один из них, sample (пример), можно представить как реализацию другого — pattern (образец). Текст такой программы приведен ниже. Предполагается, что образец может иметь любую конечную длину и содержать любое количество символов универсальной подстановки.
(defun match (sample pattern)
(cond ((and (null sample)
(null pattern)) T) ((or
(null sample) (null pattern)) NIL)
((eq (first pattern '?))
(match (rest sample) (rest pattern)))
((eq (first sample) (first pattern))
(match (rest sample) (rest pattern)))
(T NIL)) )
Обращение к этой функции в выражении
(match '(at robot room) '(at robot ?))
даст результат Т, а обращение
(match '(at box room) '(at robot ?))
даст результат NIL.
Можно усовершенствовать приведенный анализатор соответствия. Например, сделать так, чтобы он различал другой символ универсальной подстановки в качестве переменной, которой может быть присвоено значение символа, соответствие с которым анализируется. Например, образцу
(at ?X ?Y)
должен соответствовать пример
(at robot room),
который образуется при подстановке {?X/robot, ?Y/room}, как об этом говорилось в главе 3. Можно также потребовать, чтобы присвоение значений переменным было совместимым, т.е. чтобы пример
(at robot room)
не соответствовал образцу
(at ?Х ? X).
Но, как мы видели в главе 3, главное назначение анализатора соответствия — показать, что имеющаяся в программе модель мира удовлетворяет условиям некоторого правила, которое в таком случае программа сможет затем применить. Пусть в программе имеется простое правило, утверждающее, что все объекты, находящиеся в комнате, нужно покрасить:
if (at ?X room) then (paint ?X)
Нужно проверить, соответствует ли условию if (at ?X room) этого правила модель мира, представленная списком
(at box room).
Полученную подстановку {?X/box} применим затем к констатирующей части правила и получим в результате
(paint box).
Анализ соответствия — это довольно "расточительная" операция в смысле расхода вычислительных ресурсов, если только не пользоваться ею с умом. В главе 13 мы увидим, что существуют довольно эффективные алгоритмы, которые позволяют решить, в каких именно из имеющихся в наборе правилах (или отдельном правиле) сформулированы условия, соответствующие анализируемым данным. В настоящее время язык LISP не используется для реализации систем, базирующихся на правилах, в основном из-за недостаточной его эффективности, но по-прежнему используется тот принцип обработки списков при анализе соответствия, который был впервые реализован на LISP.
4.4. Почему. LISP не является языком представления знаний
Невольно напрашивается вопрос, почему с помощью LISP нельзя удовлетворить все наши потребности в области представления знаний. Ведь, как было показано, этот язык позволяет хранить и обрабатывать символические структуры и управлять процессом их оценивания. С его помощью можно реализовать анализ соответствия, эвристический поиск и устанавливать наличие ассоциативной связи между символами. Разве всего этого недостаточно для того, чтобы на базе LISP реализовать физическую символическую систему для разумных действий?
4.4.1. Символический уровень и уровень знаний
Совершенно ясно, что среда символических вычислений весьма подходит для реализации структур, необходимых для представления знаний, но символический уровень анализа ничего не говорит нам о том, чем должны быть такие структуры. Нужен еще один уровень анализа, расположенный выше символического, который будет ограничивать набор возможных представлений при решении некоторой проблемы. Ньюэлл в работе [Newell, 1982] назвал его уровнем знаний и предположил, что знания должны быть охарактеризованы функционально, т.е. в терминах действия, а не в терминах структурной организации.
Из предложения Ньюэлла следует, что нельзя адекватно представлять знания, не располагая сведениями о том, как они могут быть использованы. Возможно, это одна из причин, которая побуждает нас разделить факты и знания. То, что норманны в 1066 году захватили Англию, — это только факт. Но мое знание этого факта может быть использовано совершенно по-разному. В частности, это в равной степени позволит мне успешно сдать экзамен по истории или спровоцировать драку между англичанами и французами. Если цель состоит именно в том, чтобы получить более высокую оценку на экзамене, то представление знаний лучше связать с другими фактами, например сведениями о короле Гарольде или короле Вильяме. Если же цель — разжечь ненависть между англичанами и французами, то лучше воспользоваться такими фактами, как вандализм английский футбольных фанатов или эксцентричная манера вести себя на дорогах, присущая французским мотоциклистам. Таким образом, не существует "правильного" способа представить какой-то факт, но существует более или менее полезное представление знания некоторыми фактами.
В синтаксисе и семантике языка LISP нет ничего такого, что подсказало бы вам, как организовать знания. Список — это удобная, но иногда неэффективная в работе структура данных, но он не имеет никаких преимуществ с точки зрения представления знаний по сравнению с массивом в языке FORTRAN и менее удобен, чем класс в языке C++. Утверждение о широких возможностях LISP имеет скорее отношение к тому, что для опытного программиста довольно легко создать на его основе производный язык по своему выбору. Но такой специализированный интерпретатор, функционирующий в среде LISP, оказывается очень непроизводительным, и в этом его основной недостаток.
4.4.2. LISP и разработка программ
Многие программисты склонны к тому, чтобы создавать программный код, напоминающий спагетти, и их буквально приводит в состояние шока знакомство с широкими возможностями, которые сулит в создании такого кода язык LISP. Но при всем этом сообщество приверженцев LISP на удивление мало привнесло в методологию программирования (см. [Abelson et al, 1996]).
4.5. Гипотеза Смита
Смит выдвинул гипотезу представления знаний (Knowledge Representation Hypothesis), которая гласит [Smith, 1982]:
"Каждая интеллектуальная физическая символическая система включает символические структуры, которые мы, как внешние наблюдатели, можем расценивать как предложение, .основанное на знаниях, которыми располагает система".
Очевидно, что эта гипотеза ничего не говорит о том, как эти знания могут быть в действительности представлены. Единственное, что нам, как внешним наблюдателям, доступно— это выводы, которые система делает на основании своих знаний. Но эти выводы сами по себе не дают возможности однозначно выяснить, на основании какой схемы представления знаний они cделаны.
Многие идеи, касающиеся представления знаний, зародились в процессе развития методики объектно-ориентированного анализа и проектирования. Объектно-ориентированные языки программирования, такие как C++, SmallTalk и Eiffel, стали в последнее время привлекать все большее внимание конструкторов экспертных систем. Появилось довольно много библиотек классов, которые можно использовать при построении такого рода приложений. В этом же направлении стал развиваться и LISP. В частности, на его основе разработан язык CLOS — Common Lisp Object System, в котором механизм множественного наследования работает значительно эффективнее, чем в C++ (подробнее об этом — в главе 7). Но даже самые верные приверженцы LISP находят маловероятным, что его новейшие диалекты скоро найдут широкое применение в создании коммерческих программных продуктов
4.5. Языки представления знаний
И представление знаний, и объектно-ориентированный подход к программированию основываются на одной и той же идее, что конкретная предметная область приложения имеет такое же значение для модели, как и для проблем, которые нужно разрешить. Если вы работаете в определенной предметной области — технической, издательском деле или сфере управления, — то вид проблемы, которую потребуется решить, будет изменяться не только от проекта к проекту, но и на разных стадиях работы над проектом, по мере того как будут уточняться концепции проекта и его цели. Относительно постоянными остаются только "обитатели" предметной области — машины, процессы, неживые объекты или люди. Представление этих сущностей, которое может быть воспринято машиной и обработано программой, формируется таким образом, чтобы его можно было использовать в самых разнообразных проектах.
В самом общем виде разница между представлением знаний и объектно-ориентированным подходом состоит в том, что в первом случае стремятся представить не только сущности в определенной предметной области, но и знания об этих сущностях, которыми обладают эксперты в данной области. Например, экспертам известны различные способы классификации, упорядочивания, обозрения и манипулирования такими сущностями, которые позволяют эффективно решать разнообразные задачи.
Если рассматривать в этом свете проблематику представления знаний, то ее можно сформулировать следующим образом: "Существует ли способ, пользуясь которым можно закодировать знания о предметной области таким образом, чтобы поддерживать приложение этих знаний к решению различных проблем в разных проектах?" Ответом на этот вопрос является проектирование независящих от приложения "банков знаний", о котором речь пойдет в главе 10. Вы в дальнейшем встретитесь и с такими примерами, когда доступные программе знания по-разному используются в пределах одного и того же приложения (главы 13 и 16).
В последующих трех главах вы познакомитесь как с подходом, базирующимся на правилах, так и с объектно-ориентированным подходом к программированию, причем на примере языка CLIPS будет показано, как можно комбинировать оба этих подхода. Причина, по которой в индустрии производства программных продуктов продолжают оставаться популярными такие инструментальные средства, состоит в том, что как бы ни тяжело было кодировать человеческие знания, такие эпистемологические трудности ничто в сравнении с тем, что может наделать с указателями C++ неопытный программист. Построение системы, базирующейся на правилах на таком языке, — это нетривиальная задача, которую лучше всего поручить специалистам.
Другая причина состоит в том, что при создании с нуля системы, базирующейся на знаниях, аналитики и программисты попадают в такое обширное пространство альтернативных решений, что запутаться в нем гораздо легче, чем отыскать правильный путь. Языки представления знаний предлагают разработчику как программные средства высокого уровня, так и множество конструкций низкого уровня, которые можно использовать для организации и применения знаний, синтаксические и семантические примитивы, уже не раз доказавшие свою полезность на практике.
В главе 5 в качестве основного инструмента для иллюстрации идей построения систем, основанных на знаниях, используется язык CLIPS. Сделано это по следующим причинам:
этот язык относительно дешев;
без зазрения совести разработчики включили в него множество опробованных на практике конструкций из других инструментальных средств;
язык имеет довольно четко сформулированный синтаксис, позаимствованный у LISP;
язык (точнее, его исполнительная система) обладает вполне приемлемой производительностью, так что предлагаемые в качестве примеров программы выполняются достаточно быстро;
язык допускает вызов внешних функций, написанных на других языках программирования;
язык включает средства (правда, ограниченные), позволяющие комбинировать правила и объекты.
В главе 6 будет проанализировано использование структурированных объектов, таких как семантические сети и фреймы, а в главе 7 мы перейдем к более тщательному анализу объектно-ориентированного подхода. Описание методики логического программирования, в частности с использованием языка PROLOG, завершит в главе 8 тему изучения языков представления знаний. В главе 17 вы найдете обзор множества доступных на сегодняшний день программных пакетов, предназначенных для построения экспертных систем, а в главах 18 и 19 анализируются более специализированные инструментальные средства.
Рекомендуемая литература
В качестве наиболее доступного руководства по языку LISP я бы рекомендовал книгу Уинстона и Хорна [Winston and Horn, 1988], а в книгах Чарняка [Charniak et al., 1987] и Грехема [Graham, 1994] можно уточнить многие детали применения LISP для решения задач искусственного интеллекта.
В прекрасной книге Норвига [Norvig, 1992] подробно описан базовый диалект Common LISP, а в книге Рассела и Норвига [Russel and Norvig, 1995] основное внимание уделено программированию задач искусственного интеллекта.
В книге Кратко [Braico, 1990] читатель найдет обширный материал по использованию языка PROLOG для решения задач искусственного интеллекта. Кроме того, желающим изучить язык PROLOG я также рекомендую прочесть книгу Стерлинга и Шапиро [Sterling and Shapiro, 1994].
Упражнения
1. Что означает понятие "символ" применительно к проблематике искусственного интеллекта? Являются ли символами изображение и слово?
2. Что представляет собой гипотеза физической символической системы! Является ли она, по вашему мнению, правдоподобной?
3. Пусть L — список
(а (b) с ((d) е (f) g).
Какое значение вернет следующее выражение, состоящее из вложенных функций: first(first(rest(rest(rest(L))))).
Запишите приведенное выше выражение в синтаксисе примитивов LISP.
4. Пусть функция f определяется следующим образом:
f(X Y) = (ЛX)(if Y = 0 then 1, else X f(X, Y - 1)).
Какое значение будет иметь такое применение этой функции:
f(2 3) ?
Запишите приведенное выше выражение в синтаксисе примитивов LISP.
5. Усовершенствуйте приведенную в тексте программу анализа соответствия таким образом, чтобы она могла обрабатывать списки с произвольной вложенностью. Эта программа должна быть способна, например, показать, что список
(lisp (a functional language)
(invented by (John mccarthy)))
соответствует образцу
(lisp (a ? language) (invented by (? mccarthy))),
но не соответствует образцу
(lisp (a ? language) (invented by (тагу ?))).
6. Усовершенствуйте приведенную в тексте программу анализа соответствия таким образом, чтобы она возвращала подстановку значений для переменных, которая будет превращать образец в пример. Образец для переменной имеет в таком случае вид
(? Variable-name),
и тогда образцу
(at (? X) (? Y))
будет соответствовать пример
(at robot room),
а программа должна вернуть подстановку
( (X robot) (Y room))
в виде списка. Можно положить, что пример представляет собой простой список.
7. Скомбинируйте программы, разработанные в упр. 5 и 6, таким образом, чтобы результирующая программа могла обрабатывать вложенные списки и формировать подстановку. Эта программа должна быть способна, например, показать, что список (lisp (a functional language) (invented by (John mccarthy))) соответствует образцу
(lisp (a (? type) language)
(invented by ((? name) mccarthy))) ,
и вернуть подстановку
((type functional) (name John)) .
ГЛАВА 5. Системы, основанные на знаниях
5.1. Канонические системы
5.2. Системы порождающих правил для решения проблем
5.2.1. Синтаксис представления правил
5.2.2. Рабочая память
5.3. Управление функционированием интерпретатора
5.3.1. Разрешение конфликтов
5.3.2. Прямая и обратная цепочки рассуждений
5.3.3. Правила и метаправила
Рекомендуемая литература
Упражнения
ГЛАВА 5. Системы, основанные на знаниях
5.1. Канонические системы
5.2. Системы порождающих правил для решения проблем
5.3. Управление функционированием интерпретатора
Рекомендуемая литература
Упражнения
В области искусственного интеллекта и в современной психологии утверждение, что разумное поведение направляется правилами, превратилось уже в аксиому. Даже в "большом" мире люди склонны связывать уровень интеллектуальности со следованием правилам, и мы все чаще при объяснении разумности обращаем внимание на то, насколько при этом соблюдаются правила. Возьмем для примера манеру разговаривать на естественном языке. Мы все ведем себя так, как если бы обладали знанием всех правил того языка, на котором говорим, например английского, хотя, конечно, мы знаем далеко не все. (Любой, кто запишет эти правила, может рассчитывать на ослепительную карьеру в лингвистике.)
Суть же заключается в том, что разумное поведение, такое как правильная речь, представляется нам как некоторый процесс, регламентируемый определенными правилами, даже в том случае, если мы не можем их точно сформулировать. В искусственном интеллекте правила играют даже более явно выраженную роль в формировании того, что мы называем разумным поведением. Мы говорим, что нечто (агент) ведет себя именно таким образом, поскольку оно располагает представлением правил, уместных для формирования поведенческого акта, который в таком случае претендует на разумность.
Набор порождающих правил — это формализм, который уже использовался в теории автоматов, формальной грамматике, разработке языков программирования, прежде чем стать на службу моделированию психофизиологической деятельности [Newell and Simon, 1972] и экспертных систем [Buchanan and Feigenbaum, 1978]. В литературе по экспертным системам их иногда называют правилами "условие — действие" или "ситуация — действие". Это связано с тем, что такие правила обычно используются для представления эмпирических ассоциативных связей между данными, предъявленными системе, и действиями, которые система должна предпринять в ответ.
В экспертных системах такие правила обычно задают, что нужно сделать с символической структурой, представляющей текущее состояние проблемы, чтобы перейти к представлению, более близкому к решению.
5.1. Канонические системы
Порождения — это в действительности грамматические правила манипулирования строками символов и потому их иногда называют правилами переписывания (rewrite rules). Пост изучал свойства систем правил, базирующихся на порождениях, которые он назвал каноническими системами [Post, 1943]. Каноническая система — это разновидность формальной системы, основанной на следующих компонентах:
алфавит А, из символов которого формируются строки;
некоторое множество строк, которые рассматриваются как аксиомы,
множества порождений в форме
а1$1 ... am$m->b1$'1...bn$'1...bn$'n.
где
(I) каждое ai и bi; есть фиксированная строка;
(II) а1 и am, часто есть нуль;
(III) некоторые или все из ai или bi могут представлять собой нуль;
(IV) каждое $i является переменной строкой, которая также может быть нулем;
(V) каждое $i заменяется определенным $'i .
Определение канонической системы, возможно, станет более понятным, если привести пример. Пусть А — алфавит {а, b, с}, а аксиомы суть:
а, b, с, аа, bb, cc.
Тогда следующие порождения сгенерируют все палиндромы, базирующиеся на этом алфавите, приняв за отправную точку имеющиеся аксиомы:
(Р1)$->а$a (Р2) $ -> ab$ab (РЗ) $ -> с$с.
Более того, в данном случае можно проследить применение правил, которые должны привести к росту определенного палиндрома. Например, чтобы сгенерировать bacab, нужно применить Р1 к аксиоме с, а затем Р2 — к результату. Другими словами, приняв с в качестве аксиомы, можно вывести из нее теорему аса и добавить ее к имеющимся аксиомам. Затем из аса можно вывести новую теорему bacab. Обратите внимание, что эта последовательность порождений не обладает свойством коммутативности, т.е. если применять те же правила, но в ином порядке, получится совсем другой результат. Например, если к аксиоме с применить сначала правило Р2, а затем Р1, то получим abcba.
На первый взгляд канонические системы довольно тривиальны. Все, что можно сделать в рамках такой системы, — преобразовать одну строку символов в другую. Но если задуматься, то любое логическое или математическое исчисление в конце концов сводится к набору правил манипулирования символами. Мы упускаем это из виду, поскольку для нас часто важен определенный смысл логических и математических символов, чего не скажешь о строках типа abcba.
Отсюда следует, что любая формальная система может рассматриваться как каноническая (см., например, [Minsky, 1972, Chapter 12J). В действительности к этому нужно добавить тривиальную оговорку, что такая система может нуждаться еще в дополнительном алфавите, буквы которого будут использоваться в качестве знаков пунктуации в сложных доказательствах. Таким образом, для проверки доказательства в любой формальной системе или для того, чтобы выполнить любую эффективную процедуру, вполне достаточно способности прочесть строку символов, разделить ее на компоненты и переупорядочить (при этом, возможно, придется добавить еще какие-то символы или удалить существующие в исходной строке).
5.1. Смысл порождений
Пусть задано порождающее правило в форме
а1$1...am$m-> b1$'1...bn$'n
В нем a1$1 ... аm$m часто называют антецедентом (antecedent) правила, а b,$'1 ... bn$'n консеквентом (consequent) правила, по аналогии с условным выражением логики высказываний (см. главу 8). Условный оператор обычно записывается в виде
p U q1 что означает, "если р, то q", например "если вы упали в реку, то будете мокрым".
Однако часто значок 'U' заменяют значком '->', что вряд ли стоит делать, поскольку последний несет более императивный или разрешающий смысл. Как правило, он говорит не столько о логическом следствии, сколько о том, что нужно сделать, или о том, что можно было бы сделать.
Правило в форме Х->У говорит о том, что можно записать, сгенерировать или породить консеквент У при заданном анцеденте X. Оно не говорит о том, что набор X, У является неразрывно связанной последовательностью, как в примере с купанием в реке. Правила переписывания в теоретической лингвистике называются "порождениями", поскольку правило вида
S->NP+ VP
имеет следующую интерпретацию: "один из способов сформировать предложение S состоит в том, чтобы взять существительное (NР) и добавить к нему глагол (VP)".
5.2. Системы порождающих правил для решения проблем
Хотя в приложении к экспертным системам порождающие правила и отличаются от тех правил переписывания, о которых шла речь выше, фундаментальные принципы и формальные свойства их остаются теми же. Но при этом нас интересует не столько сама по се-
бе грамматика символических структур, как в примере с палиндромами, сколько способы представления некоторой проблемы и преобразования этого представления, которое должно привести ее к виду, о котором можно сказать: "Это решение данной проблемы".
5.2.1. Синтаксис представления правил
В настоящее время порождающие правила обычно реализуются в форме правил, манипулирующих с символическими структурами типа списка векторов, а не строк символов. В этом сказывается влияние языков программирования вроде LISP и тех структур данных, которые они поддерживают. (В ранних реализациях использовались языки манипулирования символами, например SNOBOL.)
В результате алфавит канонической символьной системы заменяется словарем символов или атомов и довольно простой грамматикой формирования символических структур. Словарь, как правило, состоит из трех подмножеств:
подмножества N имен объектов предметной области;
подмножества Р имен свойств, которые рассматриваются в качестве атрибутов объектов;
подмножества V допустимых значений атрибутов.
На практике подмножества N и V перекрываются.
Используемая грамматика, как правило, имеет вид триад объект-атрибут-значение. Триада (v, л, w) существует, если v принадлежит N и л принадлежит Р, w принадлежит V. Например, триада
(ОРГАНИЗМ-1, морфология, палочка)
представляет определенный микроорганизм, имеющий форму палочки.
Представленная синтаксическая форма обобщается в том случае, когда нужно для некоторого объекта v представить « вариантов пар атрибут-значение (л1,w1) ..., (лn,wn). В таком случае они объединяются в вектор в форме
(v, л1, w1,..., лn, wn).
На языке CLIPS тот факт, что определенный микроорганизм имеет форму палочки и активно развивается в воздушной среде, будет представлен вектором
(organism-1 (morphology rod) (aerobicity aerobic)).
В дальнейшем мы будем повсеместно использовать именно такой синтаксис, поскольку CLIPS будет нашим основным программным инструментом.
Имея в своем распоряжении словарь символов и грамматику, регламентирующую порождение символических структур, можно представить в машинном виде исходное состояние интересующих нас проблем. Эти представления соответствуют аксиомам канонической системы — они представляют собой некоторую символическую структуру, которую нужно преобразовывать, применяя имеющиеся правила в определенном порядке.
Теперь перейдем к самим правилам. В этих правилах антецеденты должны соответствовать допустимым символическим структурам, а консеквенты — содержать специальные операторы манипулирования такими структурами. Детали этого процесса станут вам понятны после изучения следующего раздела, где будет описан вычислительный механизм применения таких правил.
Продукционная система (production system) состоит из множества правил (иногда этот набор правил называют продукционной памятью — production memory), интерпретатора правил, который решает, когда надлежит применить каждое из них, и рабочей памяти, содержащей данные, описание цели и промежуточные результаты, в совокупности определяющие текущее состояние проблемы. Именно структуры данных в рабочей памяти анализируются и преобразуются порождающими правилами. Обращение к правилам синхронизируется текущими данными, а интерпретатор правил управляет выбором и активизацией определенных правил в каждом цикле.
Схематически правила в продукционной системе имеют такую обобщенную форму:
P1,..., Pm,->Q1,..., Qn
которая читается следующим образом:
если предпосылки Р1 и ... и Рт верны, то выполнить действия Q1 и ... и Qn.
Предпосылки часто называются условиями, а действия — заключениями, поскольку один из видов действий — сделать заключение, если встретилось такое сочетание условий, которое делает истинным или вероятным определенное порождающее правило, как это было показано в главе 3. Иногда используется и другая терминология, согласно которой предпосылки называются левой частью правила, а действия — правой.
Предпосылки обычно бывают представлены в форме вектора объект-атрибут— значение, как, например:
(organism-1 (morphology rod) (aerobicity aerobic)).
В данном случае предпосылка состоит в том, что определенный микроорганизм имеет форму палочки и размножается в воздушной среде.
Правило, которое включает такую предпосылку, на языке CLIPS имеет вид, показанный в листинге 5.1.
Листинг 5.1. Оргправило системы MYCIN, записанное на языке CLIPS
(defrule diagnosis
(patient (name Jones)
(organism organism-1))
(organism (name organism-1)
(morphology rod)
(aerobicity aerobic)) => (assert
(organism
(name organism-1)
(identify enterobacteriaceae)
(confidence 0.8)))
На языке CLIPS представление правила имеет следующий формат:
(defrule <наименование правила> <предпосылка1>
<предпосылка m > =>
<действие 1>
<действие n>
Перечень предпосылок в таком правиле представляет собой образец вектора, которому должно соответствовать состояние рабочей памяти. Действия, такие как (assert ...) в приведенном выше примере, задают изменения, которые должны быть внесены в состояние рабочей памяти. Например, специфицированное в приведенном выше правиле действие добавит в рабочую память новый вектор
(organism (name organism-1)
(identify enterobacteriaceae)
(confidence 0.8)).
Таким образом, правило diagnosis означает следующее: если у определенного пациента обнаружена связь с определенным микроорганизмом, который имеет перечисленные в правиле свойства, то мы можем с определенным шансом на успех предполагать, что этот микроорганизм принадлежит такому-то классу. Это правило не является общим, поскольку применимо только к конкретному пациенту (Jones) и конкретному микроорганизму (organism-1). Гораздо чаще нам придется применять правила, которые пригодны для любого пациента и любого микроорганизма. В такие правила поле имени пациента вовсе не включается.
Желание сформировать общие правила требует включения в него переменных, которые играют роль местодержателя. В правиле, представленном в листинге 5.2, такие переменные отличаются от прочих членов наличием префикса ? перед именем. Обратите внимание на то, что переменная ?pat не появляется в заключительной части правила, а значит, использование поля имени пациента в предпосылках правила действительно является избыточным.
Листинг 5.2. Правило, в котором используются переменные
(defrule diagnosis
(patient (name ?pat)
(organism ?org))
(organism (name ?org)
(morphology rod)
(aerobicity aerobic)) => (assert
(organism
(name ?org)
(identify enterobacteriaceae) (confidence 0.8)))
При использовании правила интерпретатором вместо всех одноименных переменных подставляется одно и то же значение.
5.2.2. Рабочая память
Основная функция рабочей памяти — хранить данные в формате векторов объект-атрибут-значение. Эти данные используются интерпретатором, который в случае присутствия (или отсутствия) определенного элемента данных в рабочей памяти активизирует те правила, предпосылки в которых удовлетворяются наличными данными. Как это делается, рассмотрим на примере.
Пусть в рабочей памяти содержатся векторы
(patient (name Jones) (age 40)
(organism organism-1))
(organism (name organism-1)
(morphology rod) (aerobicity .aerobic)).
В очередном цикле интерпретатор просмотрит имеющийся список правил и отыщет в нем то, которое содержит условия, удовлетворяющиеся этими векторами.
Если предпосылка в правиле не содержит переменных, она удовлетворяется при точном совпадении выражений в правиле и в рабочей памяти. Если же предпосылка в правиле содержит переменные, т.е. является образцом, то она удовлетворяется, если в рабочей памяти содержится вектор, включающий такую пару атрибут-значение, которая остается постоянной при удовлетворении всех остальных условий в том же правиле.
В самом простом случае соответствие проверяется присвоением постоянных значений переменным, которые делают предпосылку совпадающей с вектором в рабочей памяти. Так, вектор состояния в рабочей памяти
(patient (name Jones) (age 40)
(organism organism-1))
удовлетворяет предпосылку в правиле
(patient (name ?pat) (organism ?org))
подстановкой Jones вместо ?pat и Organism-1 вместо ?org.
Обратите внимание на то, что мы опускаем при анализе соответствия пары, которые отсутствуют в предпосылке правила. Поскольку другая предпосылка в этом же правиле также удовлетворяется при указанной подстановке, то новый вектор
(organism (name organism-1)
(identify enterobacteriaceae) (confidence 0.8))
добавляется интерпретатором в рабочую память.
Поскольку для заключения правила значение ?pat безразлично, поле имени пациента можно в условии вообще игнорировать.
Теперь рассмотрим набор правил, представленный в листинге 5.3, вместе с множеством векторов в рабочей памяти. Этот пример основан на планировщике STRIPS, о котором шла речь в главе 3. Программа состоит из выражений трех типов:
деклараций (или шаблонов), которые определяют формат векторов в рабочей памяти;
определений фактов, которыми задается начальное состояние проблемы;
порождающих правил, которые определяют возможные трансформации состояния проблемы.
Строки, которые начинаются символами ";;", являются комментариями.
Листинг 5.3. Набор правил для проблемы в системе STRIPS
;; Шаблоны
;; Цель (goal) представляет собой вектор, состоящий из
;; четырех компонентов:
;; действие, которое нужно выполнить,
;; объект, над которым должно быть выполнено действие;
;; исходное положение;
;; положение, в которое нужно перейти.
(deftemplate goal
(field action (type SYMBOL))
(field object (type SYMBOL))
(field from (type SYMBOL))
(field to (type SYMBOL))
)
;; Вектор 'in' указывает, где находится объект, (deftemplate in
(field object (type SYMBOL))
(field location (type SYMBOL)))
ФАКТЫ
;;Функция 'deffacts' вводит в рабочую память
;;описание исходного состояния.
;;Функция вызывается при перезапуске системы.
;;Исходное состояние объектов следующее.
;;Робот находится в комнате А,
;;ящик находится в комнате В,
;;цель - вытолкнуть ящик в комнату А.
(deffacts world
(in (object robot)
(location RoomA))
(in (object box)
(location RoomB))
(goal (action push)
(object box)
(from RoomB) (to RoomA))
)
;; ПРАВИЛА
;; Это правило утверждает:
;; Прекратить процесс, когда цель будет достигнута.
(defrule stop
(goal (object ?X) (to ?Y))
(in (object ?X) (location ?Y)) =>
(halt) )
;; Если робот отсутствует в том месте, где находится
;; объект, который нужно передвинуть,
;; переместить туда робот.
(defrule move
(goal (object ?X) (from ?Y))
(in (object ?X) (location ?Y))
?robot-position <- (in (object robot)
(location ?Z&~?Y)) =>
(modify ?robot-position (location ?Y))
;; Если робот и объект не в том помещении,
;; которое указано в цепи,
;; переместить туда робот и объект.
(defrule push
(goal (object ?X) (from ?Y) (to ?Z))
(in (object ?X) (location ?Y))
?object-position <- (in (object ?X) (location ?Y))
?robot-position <- (in (object robot) (location ?Y))
=>
(modify ?robot-position (location ?Z))
(modify ?object-position (location ?Z))
Это законченная программа на языке CLIPS, которую можно запустить на выполнение в среде разработки CLIPS 6.O. В этой программе не нужно было специально предусматривать какие-либо варианты разрешения конфликтных ситуаций, поскольку стратегия, предложенная по умолчанию, всегда обеспечит решение задачи (см. раздел 5.3). Введите в систему текст этой программы и запустите на выполнение:
введите (reset),
затем введите (run).
С помощью команды watch посмотрите, в каком порядке будут использоваться специфицированные в программе правила. Во врезке 5.2 представлены трассировка выполнения этой программы и краткие пояснения.
5.2. Трассировка программы управления роботом
Представленная ниже карта трассировки будет сформирована при запуске про-граммы в режиме трассировки.
Команда reset обеспечит перезагрузку описания исходного состояния в рабочую память, а команда run запустит программу на выполнение.
В карте трассировки каждая строка, которая начинается с символов ==>, представляет добавление вектора в рабочую память, а строка, которая начинается с символов, <==, — удаление вектора из рабочей памяти. Строки, которые начинаются с 'FIRE', представляют активизацию какого-либо правила. Остальные строки пока ,что игнорируйте.
(reset)
==> f-0 (initial-fact)
=> f-1 (in (object robot) (location RoomA))
==> f-2 (in (object box) (location RoomB))
==> f-3 (goal (action push) {object box)
(from RoomB) (to RoomA)) CLIPS>
(run) FIRE 1 move: f-3, f-2, f-1
<== f-1 (in (object robot) (location RoomA))
==> f-4 (in (object robot) (location RoomB))
FIRE 2 push: f-3, f-2, f-4 <== f_4
(in (object robot) (location RoomB))
==> f-5 (in (object robot) (location RoomA))
<== f-2 (in (object box) (location RoomB))
==> f-6 (in (object box) (location RoomA))
FIRE 3 stop: f-3, f-6
[PRCCODE4] Execution halted during the actions of defrule stop.
CLIPS> (reset)
<== f-0 (initial-fact)
<== f-3 (goal {action push)
(object box) (from RoomB) (to RoomA))
<== f-5 (in (object robot) (location RoomA))
<== f-6 (in (object box) (location RoomA))
CLIPS>
Обратите внимание на то, что выполнение программы останавливается правилом 'stop'.
5.3. Управление функционированием интерпретатора
Процесс применения специфицированных правил можно описать в терминах цикла распознавание-действие, который состоит из следующих шагов.
(1) Сопоставить образцы в предпосылках правил и элементы данных в рабочей памяти.
(2) Если окажется, что можно активизировать более одного правила, выбрать одно из них; этот шаг называется разрешением конфликта.
(3) Применить выбранное правило. Результатом, скорее всего, будет добавление нового элемента данных в рабочую память и/или удаление какого-либо существующего элемента из рабочей памяти. Затем перейти к шагу 1.
Обычно перед началом этого циклического процесса в рабочую память вводится элемент, соответствующий исходному состоянию проблемы. На языке CLIPS такой элемент является вектором (initial-fact). Процесс останавливается, если будет обнаружен цикл, в котором ни одно из правил не может быть активизировано, или если активизированное правило явно содержит команду прекращения работы5. На шаге 2 система располагает набором пар, состоящих из правил и подстановок переменных, которые сформированы при сопоставлении образцов. Такие пары называются означиваниями (instantiations). Механизм разрешения конфликтов специфичен для каждой системы, т.е. для каждого интерпретатора правил. Можно, конечно, сформулировать и такой набор правил, что в любой ситуации только одно из них будет удовлетворяться (он называется детерминированным). Но в экспертных системах обычно используются недетерминированные наборы правил, поскольку в реальной жизни очень часто встречаются ситуации, которые позволяют использовать более одного правила.
Управление процессом функционирования системы, основанной на применении порождающих правил, выдвигает ряд нетривиальных проблем. Существуют две разновидности обобщенного подхода к управлению функционированием — локальный и глобальный. Глобальный подход имеет тенденцию к поиску решений, не связанных с особенностями определенной предметной области, а локальный, наоборот, на первый план выдвигает приемы, специфические для данной предметной области. Все стратегии, которые будут перечислены в следующем разделе, являются примерами использования глобального подхода и, как правило, "жестко" встраиваются в структуру интерпретатора правил, как это сделано в интерпретаторе CLIPS. Программист, использующий при построении конкретной системы такой интерпретатор, лишен возможности каким-либо образом изменить жестко заложенную в нем стратегию либо может варьировать ее в очень узких пределах.
Локальный подход предполагает использование специальных правил управления правилами — метаправил. Такие правила обычно программируются в явном виде разработчиком конкретной системы с учетом специфики ее применения.
5.3.1. Разрешение конфликтов
Как мы видели, в алгоритме функционирования продукционной системы введен специальный шаг принятия решения между шагами анализа ситуации и применения правила. В результате анализа соответствия текущих данных и предпосылок различных правил в имеющемся наборе можно сформировать список правил, которые могут быть применимы в данной ситуации. Такой набор иногда называют конфликтующий множеством (conflict set). В терминологии языка CLIPS этот список называется agenda — список заявок.
Цель процедуры разрешения конфликтов — выбрать из сформированного списка заявок единственное правило, которое должно быть применено в текущей ситуации. Поскольку стратегия разрешения конфликтов оказывает существенное влияние на производительность системы в целом, в большинстве программных систем предусматриваются определенные опции для подстройки этого механизма.
При выработке стратегии разрешения конфликтов обычно используется комбинация разных базовых механизмов, каждый из которых обладает свойственными только ему характеристиками. Производительность экспертной системы зависит от таких ключевых характеристик режима управления, как чувствительность и стабильность. Чувствительность характеризует, как быстро система будет реагировать на изменение среды, которое отражается в рабочей памяти, а стабильность характеризует степень консерватизма в поведении системы ([McDermott andForgy, 1978], [Brownston et al., 1985, Chapter 7]).
Свойства механизмов разрешения конфликтов, которые реально применяются в системах, при всем их разнообразии можно разделить на три довольно компактные группы.
Разнообразие. Не следует применять к одним и тем же данным правило, которое уже было к ним применено ранее. Самый простой вариант реализации этого механизма — удалять из списка заявок примененное ранее правило. Иногда используется другой вариант — из списка удаляется правило, активизированное в предыдущем цикле, — это предотвращает зацикливание, но если желательно именно повторять процедуру, то в распоряжение программиста предоставляется функция refresh, которая позволяет временно подавить механизм, действующий по умолчанию.
Новизна. Элементы в рабочей памяти в таких инструментальных системах, как CLIPS, снабжены специальным атрибутом времени порождения. Это позволяет системе ранжировать элементы в списке заявок соответственно тому, как давно введены в рабочую память данные, которые использовались при сопоставлении, а затем приоритет отдается правилам, "реагирующим" на более свежие данные. Идея состоит в том, чтобы следовать за "текущей волной" и меньше внимания уделять тем данным, которые были давно сформированы. К ним можно будет вернуться в дальнейшем, если текущая цепочка рассуждения натолкнется на какое-либо препятствие.
Специфика. Более специфичные правила, которые включают большее количество компонентов в предпосылках и соответственно труднее удовлетворяются, имеют приоритет перед более общими. Идея состоит в том, что использование таких правил должно принести больше "пользы", поскольку они принимают во внимание больше информации. Эту стратегию можно эффективно использовать при работе с исключениями из общих правил.
Не располагая механизмом разрешения конфликтов, продукционная система будет не в состоянии эффективно справляться с отсутствием детерминизма в наборе правил, обработкой исключений и переключением внимания на определенный стиль рассуждений. Другими словами, представление будет страдать отсутствием эвристических способностей, а управлять функционированием такой системы будет довольно трудно, даже если знания представлены вполне корректно.
В системе интерпретации CLIPS использованы все три описанные выше механизма, что дает хороший эффект. Кроме того, интерпретатор позволяет пользователю связать с любым правилом свойство salience (выпуклость), которое используется для того, чтобы отсортировать список заявок по классам выпуклости. В первом приближении можно считать, что список заявок сортируется сначала по классам выпуклости, а затем правила, имеющие одинаковую "выпуклость", отсортировываются по другим характеристикам механизма разрешения конфликтов.
5.3. Разрешение конфликтов в CUPS
В этой врезке будут описаны те стратегии разрешения конфликтов, которые используются в исполнительной системе языка CLIPS. Для краткости мы будем говорить о сортировке правил, хотя в действительности сортируются означивания правил, которые образуются в результате подстановки значений переменных и таким образом отражают соответствие между образцом, специфицированным в предпосылке правила, и действительными данными.
Стратегия глубины. Это воплощение стратегии новизны данных по отношению к правилам, имеющим одинаковый класс выпуклости. Правила, выбранные в список заявок на основании данных, которые были включены в рабочую память сравнительно недавно, располагаются в этом списке раньше правил, при выборе которых использованы более старые данные. Таким образом, предпочтение отдается принципу поиска в глубину в пространстве состояний проблемы, т.е. правила, которые являются следствием более поздних изменений состояния системы, имеют определенный приоритет. В системе CLIPS 6.0 эта стратегия реализуется по умолчанию.
Стратегия ширины. Эта стратегия обратна рассмотренной выше стратегии глубины и предназначается для реализации поиска в ширину в пространстве состояний проблемы. Правила, выбранные в список заявок на основании данных, которые были включены в рабочую память сравнительно давно, располагаются в этом, списке раньше правил, при выборе которых использованы более свежие данные.
Стратегия простоты. Сложность правила определяется количеством операций проверки, которые нужно выполнить при анализе условий данного правила. Более верхнее положение в списке заявок при реализации этой стратегии отдается тем правилам, сложность которых ниже.
Стратегия сложности. Использует тот же критерий, что и стратегия простоты, но располагает правила в обратном порядке — более сложные занимают более приоритетное место в списке.
LEX-стратегия. Предполагает сначала удаление из списка заявок всех правил, которые уже были ранее использованы. Оставшиеся правила с равным значением выпуклости затем отсортировываются по "новизне" используемых данных. Если окажется, что два правила используют данные одинаковой "свежести", то предпочтение отдается тому, которое вовлекает в анализ предпосылок больше данных.
МЕА-стратегия. Во многом аналогична предшествующей, но при анализе новизны принимаются во внимание только первые условия в предпосылках правил. Если окажется, что в списке заявок оказались два претендента с равными показателями, то для выбора между ними применяется механизм LEX-стратегии.
МЕА — это аббревиатура от наименования одной из первых методик решения задач искусственного интеллекта путем построения обратной цепочки рассуждений Mean-Ends Analysis (средство — анализ результата). Идея состоит в том, что стратегия должна быть использована вместе со специальными лексемами цели в рабочей памяти, которые направляют процесс рассуждений и которым соответствуют первые условия в предпосылках правил. Пример использования такой методики представлен в главе 14.
В системе OPS5, многие черты которой унаследовали более поздние программные средства построения экспертных систем, использовались только две последние из перечисленных стратегий — LEX и МЕА. Стратегия LEX показала себя как хорошая стратегия общего применения, в то время как МЕА является эффективной стратегией при решении более специфических задач, таких как планирование. Тривиальный пример использования этой стратегии в программе на языке CLIPS представлен в листинге 5.4
5.3.2. Прямая и обратная цепочки рассуждений
На глобальном уровне управления последовательностью применения правил можно выделить две стратегии поведения — применять правила в прямом и обратном порядке. Прямой порядок означает, что цепь рассуждений строится, отталкиваясь от данных (условий, о которых известно, что они удовлетворяются), к гипотезам (состоянию проблемы, вытекающему из этих условий). Обратная цепочка означает, что рассуждения строятся, отталкиваясь от заданной цели (гипотезы, представляющие целевое состояние системы) к условиям, при которых возможно достижение этой цели. Здесь явно чувствуется аналогия с прямой и обратной стратегиями доказательства теорем (см. об этом в главе 8).
CLIPS представляет собой систему, в которой строится прямая цепочка рассуждений, а порождающие правила в системе MYCIN используются в большинстве случаев для построения обратной цепочки рассуждений, как было показано в главе 3. В CLIPS всегда сопоставляются состояние рабочей памяти и левые части правил, а затем выполняются действия, предусмотренные правой частью выбранного правила. А в MYCIN ведущей в рассуждениях является правая часть правила. Если мы задались целью установить природу некоторого микроорганизма, то отбираются все правила, в правой части которых дается соответствующее заключение, и затем анализируется, предпосылки какого из них удовлетворяются текущими данными.
Проще всего представить отличие между прямой и обратной цепочками рассуждений в терминах грамматических правил, аналогичных представленным в разделе 5.1. Как было показано, набор правил
(Р1) $ -> а$а
(Р2) $ -> b$b
(РЗ) $ -> с$с
можно использовать двумя способами.
Во-первых, их можно использовать для формирования палиндромов. Если задаться некоторым начальным символом из имеющегося алфавита, то любая последовательность применения правил приведет к формированию палиндрома. Так, применение правил Р1, Р1, РЗ, Р2, Р3 к исходному символу с приведет к формированию строк
аса, aacaa, caacaac, bcaacaacb, cbcaacaacbc.
Это пример прямой цепочки, поскольку с и каждая последующая сформированная строка сопоставляются с левой частью правила, а затем означивается правая часть правила.
Во-вторых, можно использовать этот же набор правил не для формирования, а для распознавания палиндромов. Мы уже видели ранее, что, задавшись некоторой строкой, например ЬасаЬ, можно проследить, в какой последовательности применялись правила при построении этой строки. Строка bасаb соответствует правой части правила Р2; можно сказать, что правая часть правила Р2 "допускает" строку bacab. Означенная левая часть правила Р2 — это строка аса, которая соответствует правой части правила PI, a означенная левая часть этого правила — аксиома с. Таким образом, процесс распознавания успешно завершился — мы доказали, что bacab представляет собой палиндром. Описанный процесс распознавания — это пример применения обратной цепочки рассуждений. Начальная строка bacab и каждая очередная подстрока анализируются на соответствие с правыми частями имеющихся правил, а результатом является означивание левой части выбранного правила. Если в качестве исходной мы зададимся строкой acbcb, то для нее не удастся найти в имеющемся наборе правил такое, правая часть которого "допускала" бы эту строку, а значит, исходная строка не может быть палиндромом.
В литературе по теории доказательства теорем прямая цепочка рассуждений, как правило, ассоциируется с "восходящим" процессом, т.е. рассуждениями от фактов к целям, а обратная цепочка — с "нисходящим" процессом, рассуждением от целей к фактам. Но, строго говоря, в отношении продукционных систем эти термины не являются синонимами. Например, вполне возможно реализовать нисходящий процесс в продукционной системе с прямой цепочкой рассуждений, если должным образом настроить локальный режим управления, например задать явное указание целей.
В листинге 5.4 показана простая программа построения башни из блоков. Эта программа переключается между двумя задачами: выбором очередного блока и установкой блока в башню.
В разделе шаблонов блоки представлены объектами, обладающими такими свойствами, как цвет, размер и положение. Если положение блока не определено, предполагается, что он находится в куче блоков (heap), еще не уложенных в башню. Шаблон on предоставляет в наше распоряжение средство, позволяющее описать размещение блоков одного (upper) на другом (lower). Информацию о текущей фазе решения проблемы (поиск или установка) несет шаблон goal.
Листинг 5.4. Набор правил для построения башни из блоков
;; СТРАТЕГИЯ РАЗРЕШЕНИЯ КОНФЛИКТОВ
(declare (strategy mea))
;; Шаблоны
;; Объект block характеризуется цветом, размером и положением,
(deftemplate block
(field color (type SYMBOL))
(field size (type INTEGER))
(field place (type SYMBOL)) )
;; Вектор 'on' указывает, что блок
;; находится на блоке . (deftemplate on
(field upper (type SYMBOL»
(field lower (type SYMBOL))
(field place (type SYMBOL) (default heap)] )
;; Текущая цель (goal) может быть либо 'найти' (find),
;; либо 'уложить' (build), (deftemplate goal
(field task (type SYMBOL)) )
;; ИНИЦИАЛИЗАЦИЯ
;; Имеются три блока разных цветов и размеров.
;; Предполагается, что они находятся в куче.
(deffacts the-facts
(block (color red) (size 10))
(block(color yellow) (size 20))
(block (color blue) (size 30))
)
;; ПРАВИЛА
;; Задать первую цель: найти первый блок,
(defrule begin
(initial-fact) =>
(assert (goal (task find))) )
;; Взять самый большой блок в куче (heap),
(defrule pick-up
?my-goal <- (goal (task find))
?my-block <- (block (size ?S1) (place heap))
(not (block (color ?C2) (size ?S2&:(>-?S2 ?S1))
(place heap))) =>
(modify ?my-block (place hand))
(modify ?my-goal (task build)) )
;; Установить первый блок в основание башни (tower).
;; Этот блок не имеет под собой никакого другого,
(defrule place-first
?my-goal <- (goal (task build))
?my-block <- (block (place hand))
(not (block (place tower)))
=>
(modify ?my-block (place tower))
(modify ?my-goal (task find)) )
;; Установить последующие блоки на тот,
;; что лежит в основании башни,
(defrule put-down
?my-goal <- (goal (task build))
?my-block <- (block (color ?C0)
(place hand))
(block (color ?C1) (place tower)))
(not (on (upper ?C2) (lower ?C1)
(place tower)))
=>
(modify ?my-block (place tower))
(assert (on (upper ?CO) (lower ?C1)
(place tower)))
(modify ?my-goal (task find)) )
;; Если в куче больше нет блоков, прекратить процесс,
(defrule stop
?my-goal <- (goal (task find))
(not (block (place heap)))
=>
(retract ?my-goal) )
Обратите внимание на то, что порядок перечисления правил в программе не имеет значения. В программе управления роботом, представленной в листинге 5.3, правило прекращения выполнения стояло в списке первым, а в этой программе оно стоит в самом конце списка. Трассировку выполнения приведенной программы и некоторые комментарии вы найдете во врезке 5.4.
5.4. Трассировка программы строительства башни
При запуске программы в режиме трассировки будет сформирована следующая карта трассировки.
CLIPS> (reset)
==> f-0 (initial-fact)
==> f-1 (block (color red) (size 10) (place heap))
==>f-2 (block (color yellow) (size 20) (place heap))
==> f-3 (block (color blue) (size 30) (place heap))
CLIPS> (run)
TIRE 1 begin: f-0
==> f-4 (goal (task find))
FIRE 2 pick-up: f-4, f-3,
<== f-3 (block (color blue) (size 30) (place heap))
==> f-5 (block (color blue) (size 30) (place hand))
<== f-4 (goal (task find))
==> f-6 (goal (task build))
FIRE 3 place-first: f-6, f-5,
<== f-5 (block (color blue) (size 30) (place hand))
==> f-7 (block (color blue) (size 30) (place tower))
<== f-6 (goal (task build))
==> f-8 (goal (task find))
FIRE 4 pick-up: f-8, f-2,
<== f-2 (block (color yellow) (size 20) (place heap))
==> f-5 (block (color yellow) (size 20) (place hand))
<== f-8 (goal (task find))
==> f-10 (goal (task build))
FIRE 5 put-down: f-10, f-9, f-7,
<== f-9 (block (color yellow) (size 20) (place hand))
==>. f-11 (block (color yellow) (size 20) (place tower))
==> f-12 (on (upper yellow) (lower blue) (place tower))
<== f-10 (goal (task build))
==> f-13 (goal (task find))
FIRE 6 pick-up: f-13, f-1,
<== f-1 (block (color red) (size 10) (place heap))
==> f-5 (block (color red) (size 10) (place hand))
<== f-13 (goal (task find))
==> f-15 (goal (task build))
FIRE 7 put-down: f-15, f-14, f-11,
<== f-14 (block (color red) (size 10) (place hand))
==> f-16 (block (color red) (size 10) (place tower))
==> f-17 (on (upper red) (lower yellow) (place tower))
<== f-15 (goal (task build))
==> f-18 (goal (task find))
FIRE 8 stop: f-18,
<== f-18 (goal (task find))
CLIPS> (reset)
<== f-0 (initial-fact)
<== f-7 (block (color blue) (size 30) (place tower))
<== f-11 (block (color yellow) (size 20) (place tower))
<== f-12 (on (upper yellow) (lower blue) (place tower))
<== f-16 (block (color red) (size 10) (place tower))
<== f-17 (on (upper red) (lower yellow) (place tower))
Обратите внимание на манипулирование лексемой цели в ходе выполнения программы. Конечное состояние представлено при очистке рабочей памяти. Блоки в башне расположились в таком порядке: красный (red) — самый верхний, он стоит на желтом (yellow), который стоит на синем (blue).
Особенность этого примера в том, что в программе реализована нисходящая стратегия рассуждений, хотя правила предполагают использование прямой цепочки анализа данных, т.е. "работают" в направлении снизу вверх. Этот эффект достигается манипулированием лексемами цели. В данном случае выражение (initial-fact) формулирует цель верхнего уровня — построить башню. Эта цель имеет две подцели — поиск блока и установка блока в башню, которые представлены лексемами
(goal (task find)
и
(goal (task build)).
Когда оказывается, что в куче больше нет блоков, главная цель достигнута. Мы делаем это в определенной степени неформально, используя (initial-fact) для упрощения программного кода, но принцип, тем не менее, соблюдается.
Иногда необходимо провести четкую границу между направленностью цепочки и направленностью действительных рассуждений. Эти две операции представляют разные уровни анализа. Очевидно, что цепочка является реализацией рассуждений, а не наоборот, но стратегия рассуждений управляет процессом построения цепочки, что в данном случае выполняется манипулированием лексемами цели. В главе 14 будет продемонстрирован гораздо более сложный пример использования этого метода в системе R1/XCON.
Это разделение высвечивает проблему, с которой очень часто приходится сталкиваться при обсуждении функционирования программ искусственного интеллекта. Большинство сложных систем, независимо от того, являются ли они программными системами, или физическими устройствами, или комбинацией тех и других, могут быть описаны на разных уровнях [Newell, 1982]. В соответствии с терминологией Ньюэлла, построение цепочки — это свойство символического уровня, где нас интересуют только левые и правые части правил, а рассуждение— это нечто, возникающее на уровне знаний, где можно провести разделение между фактами и задачами.
Ранее уже утверждалось, что большинство порождающих правил, представляющих реальный интерес с точки зрения приложений искусственного интеллекта, являются недетерминированными. При построении прямой цепочки рассуждений может оказаться, что текущие данные удовлетворяют предпосылки не одного правила, а нескольких. При построении обратной цепочки также зачастую оказывается, что одна и та же цель достигается при выполнении не единственного правила, а нескольких. Поэтому понятно, какая важная роль отводится механизму управления правилами в функционировании продукционной системы.
В главе 3 мы рассказывали о представлении пространства поиска, связанного с набором порождающих правил, с помощью И/ИЛИ-дерева. Узлы такого дерева соответствуют состояниям рабочей памяти, а дуги — правилам, которые при этом возможно применить. Древовидная схема очень хорошо согласуется с методикой обратной цепочки рассуждений, если считать, что корень дерева соответствует целевому состоянию, промежуточные узлы — подцелям, а терминальные узлы (листья) — данным.
В И/ИЛИ-дереве корень представляет исходное состояние проблемы, а листья — возможные варианты ее решения. Нетерминальные узлы могут быть двух видов: И-узлы и ИЛИ-узлы. И-узлы соответствуют применению нескольких правил, которые в совокупности формируют цель как объединение нескольких подцелей, а ИЛИ-узлы соответствуют наличию альтернативы при выборе возможных правил. Таким образом, используя терминологию главы 2, можно говорить о том, что возможные варианты применения правил формируют пространство поиска и определяют его структуру.
Программирование, основанное на правилах (логическое программирование), не снимает с повестки дня проблему комбинаторного взрыва, поскольку для любой проблемы И/ИЛИ-дерево может ветвиться по экспоненциальному закону. Но на практике стратегия разрешения конфликтов, реализованная в интерпретаторах правил, позволяет надеяться на отыскание разумного решения
5.3.3. Правила и метаправила
Код каждого порождающего правила является самодостаточным, т.е. весь необходимый контекст активизации правила содержится только в его предпосылках. Не существует способа, который позволял бы одному правилу вызывать другое, как если бы правила были процедурами. Правило R, которое активизируется в цикле Сi, может облегчить последующую активизацию правила R' в цикле Ci+1, но единственный способ сделать это — изменить состояние рабочей памяти.
Иногда, для того чтобы решить, какое правило следует активизировать, желательно использовать конкретные знания, а не следовать общей стратегии разрешения конфликтов. С этой целью в некоторые интерпретаторы правил включены средства, позволяющие программисту сформулировать и ввести в программу метаправила. Эти метаправила определяют правила применения правил, т.е. правила, по которым выполняется отбор тех правил из претендующих на выполнение, которые следует рассматривать в первую очередь или, более того, выполнять обязательно, (Такая возможность отсутствует в интерпретаторе CLIPS.)
Метаправила, таким образом, существенно отличаются от обычных правил, поскольку они направляют ход рассуждений, а не принимают непосредственное участие в процессе формирования суждений. Часто это отличие формулируется в терминах разграничения уровней функционирования правил —метауровня и объектного уровня.
Например, в системе MYCIN набор порождающих правил индексирован по клиническим параметрам, которые упоминаются в его правой части (заключение правила). В результате появляется предпосылка для значительного ускорения процедуры извлечения правил, которые можно использовать для определения величины определенного параметра (лекарственного препарата). Эта информация используется метаправилами, которые применяются по отношению к правилам, с помощью которых достигается определенная подцель. Пусть, например, сформулирована очередная подцель G, скажем, классифицировать микроорганизм. Для достижения этой подцели в системе при данном состоянии рабочей памяти можно применить множество, например порядка 30 правил. Метаправила позволяют значительно сузить круг кандидатов на основании какого-либо критерия, заложенного программистом в формулировку этого правила.
Ниже представлено простое метаправило сокращения количества кандидатов в системе MYCIN, заимствованное из книги Бучанана и Шортлиффа [Buchanan and Shortliffe, 1984, Chapter 28].
МЕТАПРАВИЛO001
ЕСЛИ
культура получена не из стерильного источника, и существуют правила, в предпосылках которых упоминается предыдущий классифицированный организм, который может быть тем же самым, что и текущий,
ТО
с совершенной определенностью (1.0) можно предположить, что каждое из этих правил в данном случае не применимо.
Это метаправило позволяет исключить из рассмотрения те правила, которые использовались для классификации других организмов из этого же источника.
Другие метаправила могут быть использованы для изменения порядка приоритетов правил. В них фактически заложены знания, рекомендующие: "сначала попробуйте этот способ, а уж потом — тот". Примером может служить приведенное ниже метаправило, также относящееся к системе MYCIN.
МЕТАПРАВИЛO002
ЕСЛИ
(1)инфекция относится к классу pelvic-abscess, и
(2)существуют правила, в предпосылках которых упоминается enterobacteriaceae, и
(3)существуют правила, в предпосылках которых упоминается грамполохительная окраска,
ТО
есть основания предполагать (0.4), что приоритет следует отдать первым из перечисленных правил.
Обратите внимание на то, что в приведенном метаправиле также присутствует коэффициент уверенности меньше единицы.
Последний пример демонстрирует метаправило, которое относится к общей стратегии решения проблем, а не к конкретным проблемам предметной области.
МЕТАПРАВИЛO00З
(1)существуют правила, в предпосылках которых не упоминается текущая цель, и
(2)существуют правила, в предпосылках которых упоминается текущая цель,
ТО
с совершенной определенностью (1.0) можно утверждать, что сначала следует активизировать первые из перечисленных правил.
Довольно часто метаправила отражают знания относительно конкретной предметной области. Например, если мы обратимся к системам медицинской диагностики, то в виде метаправила можно представить тот факт, что пациенты определенной группы, например склонные к употреблению алкоголя или пострадавшие от ожогов, особенно подвержены влиянию определенных видов инфекций. Тогда в метаправиле нужно указать, что для таких пациентов при анализе правил-кандидатов предпочтение следует отдавать тем, которые специфичны именно для этой инфекции.
Но очень важно, чтобы применение метаправил не увело нас в сторону, а для этого при их формулировке на основе существующих знаний нужно использовать определенный уровень абстрагирования. Например, метаправило
ЕСЛИ
(1)х алкоголик,
ТО
сначала следует рассмотреть правила, имеющие отношение к болезни А, а затем правила, имеющие отношение к болезни Б может быть сформулировано более абстрактно:
(1) существует определенная причина X, которая склоняет нас к мысли, что Y относится к категории Z, и
(2)существуют специальные правила, связанные именно с категорией Z,
ТО
применить эти правила прежде, чем попробовать другие, допустимые в данных условиях.
Вторая формулировка менее связана с предметной областью, а потому такое метаправило можно применять в системах различного назначения. Первую формулировку можно рассматривать и как реализацию в конкретной предметной области более общей второй формулировки метаправила. По мере проникновения экспертных систем во все новые предметные области растет интерес к таким обобщенным формулировкам метаправил на высоком уровне абстракции (см. главы 11, 12 и 17).
Мы еще вернемся к теме метаправил в главах 12, 15, 18 и 23, а сейчас только отметим, что это довольно продуктивная идея, которой, тем не менее, следует пользоваться осмотрительно. Если программа потратит значительную часть времени на определение того, какими правилами пользоваться, то это может сказаться отрицательно на ее производительности.
5.5. Свойство выпуклости в CLIPS: пингвины обретают способность летать (или не обретают)
В языке CLIPS отсутствуют средства определения метаправил. Но в интерпретаторе этого языка имеется возможность анализировать свойство правил, названное разработчиками salience (выпуклость), и отдавать при разрешении конфликтов предпочтение тому правилу, которое характеризуется большим значением этого свойства.
Вспомним пример с классификацией пингвинов, рассмотренный в главе 2. Нужно так организовать систему правил, чтобы то правило, которое имеет отношение именно к пингвинам, имело более высокий приоритет перед более общим правилом, имеющим отношение ко всем птицам. Для этого правилу, касающемуся пингвинов, придается большая "выпуклость", чем правилу, относящемуся ко всем птицам. Это правило как бы выталкивается на авансцену. На языке CLIPS определение правил тогда будет иметь вид
(defrule (bird (type ?X))
(assert (yes))
) (defrule
(declare (salience 100))
(bird (type penguin))
=>
(assert (no)) )
По умолчанию любое правило имеет нулевое значение свойства salience, если оно явно не задано. Этому свойству можно придавать как положительное значение, "выталкивая" соответствующее правило вперед, а можно присвоить и отрицательное значение, насильно отправляя его в конец очереди.
С точки зрения теории не рекомендуется приписывать жесткие приоритеты правилам, поскольку в общем случае это влечет за собой много побочных следствий, но в отдельных конкретных случаях такой подход дает весьма неплохие результаты.
Рекомендуемая литература
Прекрасное изложение базовых принципов применения правил в задачах искусственного интеллекта читатель найдет в книге Нильсона [Nilsson, 1980]. Дэвис и Кинг обобщили большой материал, касающийся продукционных систем, и проанализировали слабые и сильные стороны этой парадигмы программирования [Davis and King, 1977]. Эта работа до сих пор остается наиболее подробной. Современные исследования, касающиеся возможности использовать параллелизм в продукционных системах, описаны в работе Шмольца [Schmolze, 1991].
Описание языка CLIPS, который можно рассматривать как одно из современных средств создания систем, базирующихся на правилах, читатель найдет в Приложении в конце данной книги. Естественно, что приведенное там описание не претендует на роль исчерпывающего справочника, но оно поможет представить, как на практике реализовать изложенные в этой книге концепции.
Читателей, интересующихся подробным описанием методики реализации стратегии управления производящими правилами, мы отсылаем к книге Браунстона [Brownston et ai, 1985].
Упражнения
1. Как вы понимаете термин "разрешение конфликтов"?
2. Пусть А — это алфавит {а, b} и пусть в этом алфавите существуют аксиомы ab, bа.
Какие строки будут сформированы следующими порождающими правилами:
(Р1) $a ->$ab
(Р2) $b -> $bа
3. Пусть А — это алфавит {а, b} и пусть в этом алфавите существуют аксиомы аа, bb.
Какой набор порождающих правил может сформировать строки вида аа, bb, aabb, bbaa, aabbaa, bbaabb, aabbaabb, bbaabbaa и т.д.
4. На языке CLIPS напишите программу, которая будет выполнять рассуждения на основании силлогизмов. Силлогизм — это множество правил, определяющих, какие умозаключения можно получить из множества суждений. Ниже приведен простой силлогизм
Все Аi являются Вi Все Вi являются Сi Все Аi являются Сi
Все Аi являются Еi Некоторые Аi являются С, Все Сi являются Вi
Все Аi являются Вi
Ни один из Сi не является Вi
Ни один из Сi не является Аi
Эти суждения несложно представить в виде диаграмм Венна. Смоделируйте их с помощью языка CLIPS в виде трех правил.
Вам понадобится единственный шаблон, в котором будет определено, что утверждение (statement) состоит из квантификатора (quantifier), который может принимать одно из трех значений: all (все), some (некоторые) или по (ни один) и двух множеств.
(deftemplate statement
(field quantifier (type SYMBOL))
(field setl (type SYMBOL))
(field set2 (type SYMBOL)) )
Так, выражение "Все А1 являются В" примет вид
(statement (quantifier all) (setl As) (set2 Bs))
Проверить, как работает программа, можно на таких фактах:
(deffacts the-facts
(statement (quantifier all) (setl puppies)
(set2 dogs)) (statement (quantifier all) (setl dogs)
(set2 mammals)) (statement (quantifier all) (setl mammals)
(set2 animals)) (statement (quantifier no) (setl sea-cretures)
(set2 dogs)) (statement (quantifier some) (setl sea-cretures)
(set2 mammals)) )
5. Проанализируйте программу диагностики болей в брюшной полости, представленную в листинге 5.5. (Предупреждаю ипохондриков: эти правила скопированы из первого попавшегося под руку справочника, поэтому не стоит пользоваться ими-для самодиагноза.)
В этой программе есть одно обычное для таких программ ограничение. В исходном состоянии рабочей памяти необходимо представить все симптомы, но многие пациенты говорят только о самом явном (боли) и могут даже и не упомянуть о других, например ссадине на лодыжке.
Модифицируйте программу таким образом, чтобы она запрашивала о забытых симптомах. Самый простой способ сделать это — добавить правила, которые в предпосылках имеют только одно условие — жалобы на боль. Такое условие, например, может иметь вид
(sign (symptom pain) (organ abdomen) (site lower))
Действие правила состоит в том, чтобы добавить в рабочую память вопрос, который нужно задать. Затем понадобится правило, которое собственно и задаст вопрос и поместит в рабочую память вектор sign, сформированный в соответствии с полученным ответом. Шаблон для вектора question (вопрос) имеет такой вид:
(deftemplate question
(field symptom (type SYMBOL))
(field organ (type SYMBOL) (default NIL))
(field answer (type SYMBOL) (default NIL)) )
Таким образом, и образец в левой части порождающего правила, и сопоставляемые с ним элементы в рабочей памяти должны соответствовать этим шаблонам.
В чем, по-вашему, состоит ограничение возможностей подхода, использующего свойство salience, описанное во врезке 5.5?
Листинг 5.5. Набор диагностических правил заболеваний брюшной полости на языке CLIPS
;; Шаблоны
;; Объект 'sign' - это симптом, связанный с органом
;; или придатком,
(deftemplate sign
(field symptom (type SYMBOL))
(field organ (type SYMBOL))
(field site (type SYMBOL)) )
;; Вектор 'diagnosis' классифицирует патологию
;; некоторого органа.
(deftemplate diagnosis
(field disorder (type SYMBOL))
(field organ (type SYMBOL) (default NIL))
)
;; Факты
;; Некоторые простые симптомы.
(deffacts the-facts
(sign (symptom pain) (organ abdomen) (site lower))
(sign (symptom poor-appetite))
(sign (symptom weight-loss))
)
;; ПРАВИЛА
;; Признаки: боль в нижней части брюшной полости И
;; плохой аппетит, И потеря веса.
(defrule stomach-tumor
(sign (symptom pain) (organ abdomen) (site lower))
(sign (symptom poor-appetite))
(sign (symptom weight-loss)) =>
(assert (diagnosis (disorder tumor) (organ stomach)) )
;; Признаки: боль (pain)- в нижней части (lower)
;; брюшной полости ( abdomen ) ,
;; И понос (diarrhea), И рвота (nausea),
;; но высокой температуры нет.
(defrule inflammationl
(sign (symptom pain) (organ abdomen) (site lower))
(sign (symptom diarrhea) )
(sign (symptom nausea)) =>
(assert (diagnosis (disorder inflammation)
(organ large-intestine)))
)
;; Признаки: боль (pain) в нижней части (lower)
;; брюшной полости (abdomen),
;; И понос (diarrhea),
;; И высокая температура (fever).
(defrule inflamation2
(sign (symptom pain) (organ abdomen) (site lower))
(sign (symptom diarrhea))
(sign (symptom fever)) =>
(assert (diagnosis (disorder inflammation)
(organ large-intestine)))
)
;; Признаки: боль в верхней правой части брюшной полости
;; И отсутствие высокой температуры.
(defrule gallstones
(sign (symptom pain) (organ abdomen)
(site upper-right)) =>
(assert (diagnosis (disorder gallstones)
(organ gallbladder)))
)
;; Признаки: боль в верхней правой части брюшной полости,
;; И рвота, И высокая температура.
(defrule gallbladder
(sign (symptom pain) (organ abdomen)
(site upper-right)) (sign (symptom vomiting))
(sign (symptom fever)) =>
(assert (diagnosis (disorder inflammation)
(organ gallbladder))) )
ГЛАВА 6. Ассоциативные сети и системы фреймов
6.1. Графы, деревья и сети
6.2. Ассоциативные сети
6.2.1. Разделение видов узлов и когнитивная экономия
6.2.2. Анализ адекватности ассоциативных сетей
6.3. Представление типовых объектов и ситуаций
6.3.1. Основные понятия концепции фреймов
6.3.2. Фреймы и графы
6.3.3. Значения по умолчанию и демоны
6.3.4. Множественное наследование
6.3.5. Сравнение сетей и фреймов
Рекомендуемая литература
Упражнения
ГЛАВА 6. Ассоциативные сети и системы фреймов
6.1. Графы, деревья и сети
6.2. Ассоциативные сети
6.3. Представление типовых объектов и ситуаций
Рекомендуемая литература
Упражнения
Следуя Нильсону [Nilsson, 1982], я буду использовать термин структурированный объект по отношению к любой схеме представления, базовые блоки которой аналогичны узлам и дугам в теории графов или слотам и заполнителям структур записей. Я буду систематически сравнивать этот вид представления со схемами, производными от правил формальных грамматик или формализмов разнообразных логик. Представление с помощью структурированных объектов является весьма удобным средством для группирования информации более или менее естественным путем.
В предыдущей главе уже отмечалось, что порождающие правила очень подходят для представления связей состояния некоторой проблемы с действиями, которые необходимо предпринять для продвижения к искомому решению. Однако иногда для решения проблемы больший интерес представляет не ответ на вопрос "Что делать, если...?", а свойства и взаимоотношения между сложными объектами в предметной области. Представлять знания о таких объектах и событиях и их взаимосвязях (таких как тип — подтип, часть — целое, до — после и т.д.) с помощью формальных правил далеко не всегда удобно.
В этой и следующей главах мы рассмотрим способы, удобные для представления структурированных знаний, и остановимся на тех трудностях, с которыми столкнулись исследователи на практике. Формальный аппарат, который будет использован в данной главе, базируется на различных видах графов, узлы которых хранят информацию о сущностях в форме записей, а дуги определяют взаимоотношения между этими сущностями. В следующей главе мы рассмотрим объектно-ориентированный подход к представлению знаний, который влечет за собой определенную методологию разработки и соответствующий стиль программирования
6.1. Графы, деревья и сети
Для описания многих видов абстрактных данных в информатике вообще и в теории искусственного интеллекта, в частности, очень широко используется терминология, заимствованная из теории графов. Следующие определения приведены здесь для того, чтобы показать, как эти заимствованные термины трактуются при описании структурированных объектов, что несколько отличается от их трактовки в "родной" математической сфере.
Рис. 6.1. Некоторые виды графов: а) обыкновенный граф; б) связный граф с петлей; в) обыкновенный ориентированный граф — дерево
Все определения сформулированы в предположении, что существуют два вида примитивов — узлы и связи. Узлы представляют собой исходящие и целевые пункты для связей и обычно каким-либо образом промаркированы. Связи также могут быть промаркированы, но это не обязательно. Все зависит от того, имеем ли мы дело со связями одного вида или разных. В общепринятой терминологии теории графов узлы называются "вершинами", а связи — "ребрами графа", или "дугами".
Определение 6.1. Если N— множество узлов, то любое подмножество NxN является обобщенным графом G. Если в парах подмножества NxN имеет значение порядок, то граф G является ориентированным.
На рис. 6.1 показаны разные типы графов. Обратите внимание на то, что граф не обязательно должен быть связным. Если задаться условием, что петли не допускаются, т.е. в каждой паре должны присутствовать разные узлы, то такой граф называется обыкновенным. Если на графе не допускаются не только петли, но и циклы (т.е. последовательность связей, в которой начальный и конечный узлы совпадают), то такой граф называетсялесом.
Определение 6.2. Если G— обыкновенный граф, в котором имеется п узлов и п-1 связей и отсутствуют циклы, то такой граф является деревом.
Иными словами, дерево — это связный лес. Обычно один из узлов дерева является его корнем, например узел е на графе, представленном на рис. 6.1,в. Остальные узлы образуют ветвящуюся структуру "наследников" корневого узла, в которой отсутствуют циклы. Узлы, не имеющие наследников, являются терминальными, или "листьями" дерева, а остальные узлы называются промежуточными (нетерминальными).
В теории графов сетью называется взвешенный ориентированный граф, т.е. граф, в котором каждой связи сопоставлено определенное число. Обычно этими числами оценивается "стоимость" пути вдоль этой связи или длина связи, как на карте дорог. В каждом конкретном случае применения графа как формального средства описания проблемы эти числа могут трактоваться по-своему.
Следующее определение сети более близко к специфике задач искусственного интеллекта, которыми мы сейчас занимаемся.
Определение 6.3. Если L — это множество взвешенных связей, a N, как и ранее, множество узлов, то сеть — это любое подмножество NxLxN, в котором имеет значение порядок в триадах.
Связи в сети практически всегда являются ориентированными, поскольку отношения, представленные взвешенными связями, не должны быть симметричными.
Обыкновенные графы используются для представления взаимоотношений между объектами в пространстве или во времени. Можно использовать их и для представления более абстрактных причинно-следственных связей, как, например, связей между различными видами патологий в медицине (рис. 6.2). Доступ к такой информации связан в той или иной мере с использованием специальных средств прослеживания путей на графе, для которых разработаны самые различные алгоритмы (см., например, работу [Pearl, 1984]).
Рис. 6.2. Участок сети причинно-следственных связей ([Pople, 1982P
Для представления иерархических классификаций и сетей применяются деревья. Например, на рис. 6.3 показано дерево классификации болезней по расположению пораженного органа. Корневой узел дерева представляет множество всех болезней, а его наследники — группы болезней, соответствующие основному пораженному органу. Каждый из этих узлов будет иметь своих наследников, представляющих более узкие группы болезней, и т.д. Терминальные узлы дерева будут представлять конкретные заболевания.
Семантические сети вначале использовались для представления смысла выражений естественного языка человека, откуда и появилось название этого класса сетей. Теперь же они используются в качестве структуры, пригодной для представления информации общего вида, — узлы представляют некоторые концепты (понятия), а связи — отношения между концептами. На рис. 6.4 представлены два фрагмента семантической сети. Первый фрагмент представляет глагол давать и показывает, что этот глагол может иметь три вида взаимодействия с остальными членами предложения: с донором, реципиентом и с объектом, который должен быть передан. Надписи в узлах, к которым подходят связи, соответствуют классу сущностей, которые могут выступать в качестве субъектов связи. Так, донор и реципиент, как правило, —люди, а то, что нужно передать, — вещь.
Рис. 6.3. Обыкновенное дерево классификации болезней
a
б
Рис. 6.4. Фрагменты семантической сети: а) представление глагола "давать "; б) представление конкретного действия
Второй фрагмент соответствует конкретной фразе или конкретной реализации действия, означенного этим глаголом. Эту реализацию мы назвали давать-265. Смысл фразы состоит в том, что Джон передает Мери книгу "Война и мир". Фразу можно считать допустимой, поскольку все ее члены удовлетворяют ограничениям, специфицированным соответствующими узлами сети. Джон и Мери принадлежат к классу люди, а "Война и мир" — к классу книга, который, в свою очередь, является одним из видов класса вещи.
Обычно узел давать-265 связывается с узлом давать связью, которая указывает, что давать-265 — это одна из конкретных реализаций концепта (в данном случае действия) давать. Такого рода специальные связи часто называют ISA-связями (связями типа "это есть...").
Термин ассоциативные сети лучше отражает характер использования такого рода формальных структур для тех задач, которые мы рассматриваем. Поскольку аппарат ассоциативных сетей все шире используется для моделирования объектов и их взаимосвязей в конкретных предметных областях, что необходимо для построения экспертных систем, ниже мы рассмотрим их более детально
6.2. Ассоциативные сети
Систематические исследования методики использования сетей для представления знаний начались с исследования методов представления семантики естественного языка [Quillian, 1968]. Квиллиан предположил, что наша способность понимать язык может быть охарактеризована, хотя бы в принципе, некоторым множеством правил. Он предположил, что процесс восприятия текста включает в себя "создание некоторого рода мысленного символического представления". Исходя из этого, он занялся изучением вопроса, как смысл отдельных слов может быть сохранен в компьютере, чтобы компьютер смог использовать их по тому же принципу, что и человек. Квиллиан был не первым, кто обратил внимание на важность обобщенного, абстрактного знания для понимания естественного языка. Еще ранее к такому же заключению пришли исследователи, занимавшиеся проблемами машинного перевода. Но Квиллиан первым предложил использовать для моделирования человеческой памяти сетевые структуры, в которых узлы и связи между ними представляли бы концепты и отношения между концептами. Он же предложил работающую модель извлечения информации из памяти.
Если мы стремимся создать программу, устойчивую к модификации данных, т.е. сохраняющую работоспособность при множестве таких модификаций, то нам непременно понадобится какое-либо средство проверки целостности знаний. Это, в свою очередь, накладывает определенные ограничения на методы представления знаний: знания должны быть организованы таким образом, чтобы упростить проверку их целостности. Именно такая цель преследовалась при создании тех видов структуры представления знаний, которые мы будем рассматривать в этой главе.
6.2.1. Разделение видов узлов и когнитивная экономия
Два аспекта модели памяти, предложенной Квиллианом, оказали особенно существенное влияние на последующее развитие исследований в области применения систем семантических сетей.
Во-первых, он ввел разделение между видами узлов, представляющих концепты. Один вид узлов он назвал узлами-типами. Такой узел представляет концепт, связанный с конфигурацией других узлов, узлов-лексем. Конфигурация узлов-лексем образует определение концепта узла-типа. Это в определенной степени напоминает толковый словарь, в котором каждое понятие (элемент словаря) определяется другими понятиями, также присутствующими в этом словаре, причем их смысл толкуется с помощью еще каких-либо понятий в этом словаре. Таким образом, смысл узла-лексемы определяется ссылкой на соответствующие узлы-типы.
Например, можно определить смысл слова "машина" как конструкцию из связанных компонентов, которые передают усилие для выполнения некоторой работы. Это потребует присоединения узла-типа для слова "машина" к узлам-лексемам, представляющим слова "конструкция", "компонент" и т.д. Однако в дополнение к связям, сформированным для определения смысла, могут существовать и связи к другим узлам-лексемам, например "телетайп" или "офис". Эти связи представляют знание о том, что телетайпы являются одним из видов машин, которые используется в офисе.
Другое интересное свойство модели памяти получило наименование когнитивной экономии. Суть его поясним на примере. Если известно, что машина — это конструкция, состоящая из взаимодействующих деталей, а телетайп — это тоже машина, то можно сделать вывод, что телетайп — это тоже конструкция. Таким образом, нет смысла в явном виде хранить эту информацию, присоединяя ее к узлу "телетайп". Указывая, что этот узел сохраняет определенные свойства, заданные связями узла "машина", мы можем сэкономить память и сохранить при этом возможность извлечь всю необходимую информацию, если только будем способны построить правильную схему влияния одних узлов на другие.
Эта схема, которую в настоящее время принято называть схемой наследования свойств, получила широкое распространение в представлении знаний. Наследование свойств является типичным примером сохранения объема памяти за счет снижения производительности, которое должен учитывать разработчик схемы представления знаний. Мы увидим в дальнейшем, что такой подход влечет за собой появление множества нетривиальных проблем, в частности, если допустить возможность исключений в наследовании, т.е. существование таких узлов-лексем, которые не наследуют все свойства своего узла-типа. Кроме того, хотя смысл понятий полностью определен в пределах сети, но для каждого отдельного понятия он "размазывается", т.е. отдельные части определения связываются с разными узлами. В нашем примере определение понятия "телетайп" только частично хранится в соответствующем узле, а остальная часть определения находится в узле "машина".
Таким образом, помимо антагонизма "объем памяти/производительность", появляется еще и антагонизм между модульностью определения и разумностью этого определения с точки зрения пользователя. Тем не менее, если эта идея будет корректно реализована, программа всегда будет знать, как отыскать отдельные части определения некоторой сущности и собрать их воедино. Главное же преимущество состоит в том, что в узле можно хранить произвольное количество семантической информации, например данные о диапазонах значений свойств, которыми могут обладать узлы-лексемы определенного типа. В чистом виде такая организация памяти не практикуется при использовании формализмов вроде продукционных систем, поскольку придется выполнять трудоемкий анализ целостности информации в рабочей памяти либо с привлечением специальных правил, описывающих такую целостность, либо с помощью самих правил поиска решений. В любом случае это потребует значительных вычислительных ресурсов.
6.2.2. Анализ адекватности ассоциативных сетей
Основную операцию извлечения информации в той модели обработки, которая следует из предложенной Квиллианом модели памяти, можно охарактеризовать как распространяющуюся активность. Идея состоит в том, что если желательно знать, является ли телетайп машиной, то необходимо искать, т.е. распространить "активность" некоторого вида во всех направлениях — как от узла-типа " телетайп", так и от узла-типа "машина". Если где-то эти две волны встретятся, то таким образом будет установлено существование связи между этими двумя концептами, т.е. определен путь на графе от одного узла к другому. Такая распространяющаяся в разных направлениях активность реализуется передачей маркеров вдоль именованных связей. Мы еще раз вернемся к этой, на первый взгляд, простой, но довольно продуктивной идее при обсуждении нейронных сетей в главе 23.
Интересно отметить, что идеи Квиллиана не получили широкого распространения в качестве модели психологической организации и функционирования памяти человека. При проверке адекватности этой модели Коллинс и Квиллиан измеряли время, которое требовалось испытуемым для ответа на вопрос о принадлежности определенного понятия к некоторой категории и о его свойствах [Collins and Quillian, 1969]. Оказалось, что время, затрачиваемое на поиск ответа, действительно увеличивается по мере увеличения количества узлов в сети, описывающей связи между понятиями. Однако такая зависимость имела место только в отношении положительных ответов. Существовали определенные подозрения, что применение предложенной модели для случая отрицательных ответов натолкнется на определенные трудности. И последующие эксперименты, проведенные другими исследователями, эти подозрения подтвердили.
Тем не менее Квиллиан продолжал исследование возможности использования формализма сетей для представления знаний. Хотя современное представление об ассоциативных сетях во многом существенно отличается от первоначальной концепции и область их использования включает множество проблем, отличных от понимания смысла предложений естественного языка, многие базовые принципы унаследованы от пионерских работ Квиллиана, упомянутых выше.
Существует довольно обширный перечень проблем, при решении которых представление, базирующееся на формализме ассоциативных сетей, оказывается весьма полезным. В 1970-х годах было опубликовано множество работ, в которых анализировались различные виды такого формализма. Наиболее удачной из них, на наш взгляд, является работа Вудса [Woods, 1975]. Использование узлов и связей в сети для представления понятий и отношений между ними может показаться само собой разумеющимся, но опыт показал, что на этом пути неосторожного путника поджидает множество ловушек.
В различных вариантах спецификаций структуры сети далеко не всегда четко определяется смысл маркировки узлов. Так, если рассмотреть узел-тип, имеющий маркировку "телетайп", то часто бывает непонятно, представляет ли этот узел понятие "телетайп", или класс всех агрегатов типа "телетайп", или какой-либо конкретный телетайп. Аналогично, и узел-лексема также открыт для множества толкований — определенный телетайп, какой-то телетайп, произвольные телетайпы и т.д. Разные толкования влекут за собой и разный характер влияния этого узла на другие в сети, а это играет весьма важную роль в дальнейшем анализе.
Поиск пересечения неизбежно "тянет за собой" проблему преодоления комбинаторного взрыва, о которой шла речь в главе 2. Поэтому создается впечатление, что организация памяти в терминах множества узлов, для которых в качестве главного вида процесса извлечения используется распространяющаяся по всем направлениям активность, приведет к образованию системы с труднопредсказуемым поведением. Например, весьма вероятно, что при отрицательных ответах на запросы придется выполнить огромное количество элементарных действий, поскольку нужно убедиться, что не существует пересекающихся путей на графе сети между двумя заданными узлами.
Из сказанного выше ясно, что первоначальные виды формализмов ассоциативных сетей страдают минимум двумя недостатками.
Сети являются логически неадекватными, поскольку в них нельзя представить множество различий, представимых в логическом исчислении, например различие между определенным телетайпом, любым единственным телетайпом, всеми телетайпами, ни одним телетайпом и т.д. Смысл или значение, которые ассоциируются с узлами и связями в сети, часто сложным образом связаны с такими характеристиками системы, как способность к извлечению информации и анализу взаимовлияний. Такое смешение семантики с деталями реализации является результатом того, что сети одновременно являются и средством представления знаний, и средством извлечения из них нужной информации, и средством конструирования заключений, основанных на знаниях, причем везде используется один и тот же набор ассоциативных механизмов. Естественно, что при этом различия между тремя означенными сторонами модели представления смазываются, теряют четкость.
Сети являются эвристически неадекватными, поскольку поиск информации в ней сам по себе знаниями не управляется. Другими словами, этот механизм не предполагает наличия какого-либо знания о том, как искать нужную нам информацию в представленных знаниях. Эти два недостатка иногда "усиливают" друг друга самым неприятным образом. Например, если невозможно представить логическое отрицание или исключение (логическая неадекватность), это приведет к определенным "провалам" в знаниях, которые к тому же нельзя ликвидировать эвристически, прекратив поиск в этом направлении (эвристическая неадекватность).
Для разрешения описанных проблем предлагались самые разные формализмы и механизмы, но лишь немногие из них нашли широкое распространение. Например, многие системы, базирующиеся на сетевом представлении, были расширены и в результате получили множество свойств, характерных для чисто логических систем (см., например, [Schubert, 1976]). В других системах эвристики использовались таким образом, что с каждым узлом связывались процедуры, которые выполнялись, как только узел активизировался (см., например, [Levesque and Mylopoulos, 1979]). Как бы там ни было, но основной принцип организации памяти в терминах узлов и связей остается прежним, несмотря на использование всякого рода дополнительных структур, например "суперузлов" [Hendrix, 1979]. Образующиеся в результате системы часто плохо контролируются пользователем и, утрачивая при этом первоначальную простоту, мало что приобретают в смысле функциональных характеристик
6.3. Представление типовых объектов и ситуаций
В этом разделе мы рассмотрим более простой механизм представления знаний, названный системой фреймов. Этот механизм появился в результате стремления объединить декларативные знания об объектах, о событиях и их свойствах и процедурные знания о методах извлечения информации и достижения целей. Предполагалось, что механизм фреймов поможет избежать ряда проблем, связанных с представлением на основе семантических сетей.
6.3.1. Основные понятия концепции фреймов
Становление теории систем фреймов во многом обязано ряду интуитивных предположений, касающихся механизмов психологической деятельности человека. В частности, предполагается, что представление понятий в мозге не требует строгого формулирования набора свойств, которыми должна обладать та или иная сущность, чтобы можно было рассматривать ее в качестве представителя определенной категории сущностей. Многие из тех категорий, которыми мы пользуемся, не имеют четкого определения, а базируются на довольно расплывчатых понятиях. Создается впечатление, что человек более всего обращает внимание на те бросающиеся в глаза свойства, которые ассоциируются с объектами, наиболее ярко представляющими свой класс.
Такие объекты были названы "прототипическими объектами", или прототипами. В частности, "прототипическая" птица, например воробей, может летать, а потому у нас есть основание полагать, что это — свойство всех птиц, хотя и существуют редкие виды птиц, которые этим свойством не обладают, например пингвины. Именно в этом смысле воробей является лучшим экземпляром категории "птицы", чем пингвин, поскольку он представляет более типические свойства объектов своего класса. Несмотря на существование видов птиц, являющихся исключением в своем классе, мы можем сформулировать обобщенное свойство объектов этого класса следующим образом: "птицы летают".
Теперь обратимся к объектам другого рода— математическим, например многоугольникам. По отношению к этой категории объектов у нас также имеется интуитивное представление о типичности. Например, рассматривая четырехугольники, представленные на рис. 6.5, вряд ли кто будет оспаривать утверждение, что "типичность" объектов увеличивается по мере перехода от фигур, расположенных слева, к фигурам, расположенным справа. Четырехугольник, не обладающий выпуклостью, кажется нам менее типическим, чем выпуклый, а прямоугольник кажется более типическим, чем выпуклый четырехугольник с различными внутренними углами, возможно потому, что площадь фигуры коррелируется в нашем сознании с длиной периметра, а эта связь лучше проявляется при равных значениях внутренних углов.
Рис. 6.5. Изменение "типичности" прямоугольников разного вида
В системе фреймов предпринимается попытка судить о классе объектов, используя представление знаний о прототипах, которые хорошо представляют большинство разновидностей объектов данного класса, но должны быть каким-то образом скорректированы, для того чтобы представить всю сложность, присущую реальному миру. Так, если мне ничего не известно о площади более или менее прямоугольного участка земли, но известны длины сторон, то я могу оценить площадь, полагая, что внутренние углы контура этого участка почти равны. В худшем случае, если мои предположения о равенстве углов окажутся уж слишком далеки от действительности, то оценка площади будет завышенной, но такая ситуация типична для подавляющего большинства эвристических механизмов.
При решении практических проблем мы встречаемся с изобилием исключений из правил, а границы между разными классами оказываются очень размытыми. Системы фреймов оказываются полезными по той причине, что они дают нам в руки средства структурирования эвристических знаний, связанных с приложением правил и классификацией объектов. При использовании фреймов эвристические знания не "размазываются" по программному коду приложения, но и не собираются воедино в виде метазнаний, а распределяются между теми видами объектов, к которым они приложимы, и существуют на уровне управления в иерархии представления таких объектов
6.3.2. Фреймы и графы
Минский в свой работе [Minsky, 1975] определил фрейм как "структуру данных для представления стереотипных ситуаций". Эту структуру он наполнил самой разнообразной информацией: об объектах и событиях, которые следует ожидать в этой" ситуации, и о том, как использовать информацию, имеющуюся во фрейме. Идея состояла в том, чтобы сконцентрировать все знания о данном классе объектов или событий в единой структуре данных, а не распределять их между множеством более мелких структур вроде логических формул или порождающих правил. Такие знания либо сосредоточены в самой структуре данных, либо доступны из этой структуры (например, хранятся в другой структуре, связанной с фреймом).
Таким образом, по существу, фрейм оказался тем средством, которое помогло связать декларативные и процедурные знания о некоторой сущности в структуру записей, которая состоит из слотов и наполнителей (filler). Слоты играют ту же роль, что и поля в записи, а наполнители — это значения, хранящиеся в полях. Однако, как будет сказано ниже, фреймы отличаются от привычных программных структур вроде записей в языке PASCAL.
Каждый фрейм имеет специальный слот, заполненный наименованием сущности, которую он представляет. Другие слоты заполнены значениями разнообразных атрибутов, ассоциирующихся с объектом. Это могут быть и процедуры, которые необходимо активизировать всякий раз, когда осуществляется доступ к фрейму или его обновление. Идея состоит в том, чтобы выполнение большей части вычислений, связанных с решением проблемы, явилось побочным эффектом передачи данных во фрейм или извлечения данных из него.
Фрейм также можно рассматривать как сложный узел в особого вида ассоциативной сети. Как правило, фреймы организованы в виде "ослабленной иерархии" (или "гетерархии"), в которой фреймы, расположенные ниже в сети, могут наследовать значения слотов разных фреймов, расположенных выше. (Гетерархия — это "запутанная иерархия", т.е. ациклический граф, в котором узлы могут иметь более одного предшественника.)
Фундаментальная идея состоит в том, что свойства и процедуры, ассоциированные с фреймами в виде свойств узлов, расположенных выше в системе фреймов, являются более или менее фиксированными, поскольку они представляют те вещи или понятия, которые в большинстве случаев являются истинными для интересующей нас сущности, в то время как фреймы более нижних уровней имеют слоты, которые должны быть заполнены наиболее динамической информацией, подверженной частым изменениям. Если такого рода динамическая информация отсутствует из-за неполноты наших знаний о наиболее вероятном состоянии дел, то слоты фреймов более нижних уровней заполняются данными, унаследованными от фреймов более верхних уровней, которые носят глобальный характер. Данные, которые передаются в процессе функционирования системы от посторонних источников знаний во фреймы нижних уровней, имеют более высокий приоритет, чем данные, унаследованные от фреймов более верхних уровней.
Среди связей в системе фреймов особо нужно выделить связи между экземплярами и классами и связи между классами и суперклассами. Узел Компьютер имеет связь с узлом Машина, которая представляет отношение "класс-суперкласс", а узел sol2, представляющий конкретный компьютер (тот, на котором я работаю), имеет связь с узлом Компьютер, которая представляет отношение "экземпляр-класс". Свойства и отношения, которые в типичной семантической сети кодируются маркировкой связей между узлами, теперь кодируются с помощью представления слот-заполнитель. Кроме того, со слотами может быть ассоциирована любая дополнительная информация, например процедуры вычисления значения этого слота в случае отсутствия явного его заполнения, процедуры обновления значения слота при изменении значения другого слота, ограничения на величины, хранящиеся в слотах, и т.д.
6.3.3. Значения по умолчанию и демоны
Представьте себя на некоторое время в роли агента по оценке недвижимости. Вы должны оценить примерную стоимость на рынке земельных участков, полной информацией о которых не располагаете. Большинство участков имеет, как правило, форму выпуклых прямоугольников, поэтому можно оценить стоимость участков, предполагая, что те, о которых идет речь, также имеют подобную форму, если только у вас нет конкретной информации об обратном.
Предположим, что граф на рис. 6.6 представляет знания о плоских геометрических фигурах, которые можно использовать для логических рассуждений о форме участков. Каждый узел на этом графе имеет связанную с ним структуру записей (фрейм), формат которой приведен ниже.
NAME (ИМЯ):
Number of sides (Количество сторон):
Length of sides (Длины сторон):
Size of Angles (Углы):
Area (Площадь):
Price (Цена):
Практически все слоты фрейма Многоугольник придется оставить незаполненными, поскольку ничего нельзя сказать о сторонах и углах типичного многоугольника. Однако для слота Количество сторон в качестве значения по умолчанию можно установить 4, поскольку подавляющее большинство земельных участков имеет форму четырехугольника. Таким образом, все земельные участки, информация о форме контура которых отсутствует, будут полагаться четырехугольными. Слот Площадь также нельзя заполнить, но известно, как вычислить площадь многоугольника, располагая другой информацией о нем. Любой n-сторонний многоугольник можно разбить на п-2 треугольника, вычислить их площади и затем просуммировать результаты. Программу, реализующую эту процедуру, можно подключить к слоту Площадь. Процедуры, подключенные к структуре данных и запускаемые на выполнение при появлении запроса или обновлении информации в структуре, иногда называют демонами. Те демоны, которые по запросу вычисляют некоторые значения, называются демонами по требованию (IF-NEEDED).
Полезно также иметь демон, который при заполнении слота Площадь сразу вычислял бы цену участка. Эта процедура относится к другому типу демонов — демонам добавления (IP-ADDED) — и подключается также к слоту Площадь. Теперь при обновлении или установке значения слота Площадь автоматически будет вычислена цена участка, а результат будет помещен в слот Цена.
Перейдем к следующему уровню в иерархии фреймов. Для фрейма Четырехугольник совершенно очевидно нужно установить значение 4 в слот Количество сторон. Это значение будет наследоваться фреймами на каждом из последующих уровней иерархии. Вычислять площадь и цену всех фигур, представленных фреймами последующих уровней, можно тем же способом, что и для многоугольника. Поэтому описанные выше демоны также могут быть унаследованы всеми последующими фреймами.
Но для четырехугольника можно примерно оценить площадь, даже не располагая информацией о значениях внутренних углов контура, а зная только длины сторон. Вполне приемлемые результаты можно получить с помощью следующего эвристического способа: среднюю длину стороны для одной пары противолежащих сторон умножить на среднюю длину стороны для другой пары. Этот метод даст существенную ошибку только для четырехугольников, не являющихся выпуклыми, а такое встречается очень редко.
Эта эвристика может быть реализована в виде демона по требованию, подсоединенного к слоту Площадь фрейма Четырехугольник. Такой демон должен выполнять следующее:
Рис. 6.6. Иерархия плоских геометрических фигур
если имеется информация о величинах углов четырехугольника и длинах сторон, то вызывать демон фрейма Многоугольник и выполнять точное вычисление площади;
если имеется только информация о длинах сторон четырехугольника, то выполнять вычисление по приближенному эвристическому методу;
если отсутствует любая информация о параметрах четырехугольника, не выполнять никаких вычислений.
Фреймы, представляющие все последующие разновидности четырехугольников, наследуют значение из слота Количество сторон фрейма Четырехугольник. Но в каждом из этих фреймов можно реализовать свою процедуру вычисления площади, лучше учитывающую особенности именно данного вида фигур. Например, площадь трапеции можно вычислить как произведение высоты на среднюю длину оснований, а фреймы прямоугольника и квадрата могут унаследовать эту процедуру у параллелограмма, площадь которого равна произведению основания на высоту.
Этот простой пример демонстрирует, как, используя значения по умолчанию и демоны, можно заполнить слоты иерархической системы фреймов, причем этот механизм оказывается более удобным, чем тот, который используется в структурах записей языка PASCAL. Данные, процедуры и определения оформляются в виде единого пакета и образуют отдельный модуль для каждого фрейма, причем разные модули могут совместно использовать данные и процедуры, пользуясь механизмом наследования.
6.1. Реализация фреймов и наследования в языке CLIPS
Хотя язык CLIPS и не поддерживает в явном виде формализм семантических сетей и фреймов, их можно неявно определить, используя имеющуюся в CLIPS конструкцию def class. Мы более подробно поговорим об этой конструкции в следующей главе, поскольку ее основное назначение — реализация объектно-ориентированного подхода. Для представления иерархии геометрических объектов, показанной на рис. 6.6, нам понадобятся следующие определения:
(defclass polygon (is-a USER))
(defclass quadrilateral (is-a polygon))
(defclass trapezium (is-a quadrilateral))
(defclass parallelogram (is-a trapezium))
(defclass rectangle (is-a parallelogram))
(defclass square (is-a rectangle))
Обратите внимание на то, что класс polygon (многоугольник) объявлен как подкласс класса USER, который является базовым для всех классов, объявленных пользователем. Отношение is-a (является), которое фигурирует во всех языках представления фреймов, обычно обладает свойством транзитивности: квадрат является прямоугольником, но квадрат также является и трапецией и т.д. Это отношение является антисимметричным, т.е. если квадрат является прямоугольником, то прямоугольник в общем случае не является квадратом.
Для того чтобы представить на языке CLIPS тот факт, что большинство многоугольников предположительно должно иметь четыре стороны, потребуются кое-какие дополнительные языковые конструкции. Нужно будет несколько изменить определение классов polygon и quadrilateral:
(defclass polygon (is-a USER)
(role abstract)
(slot no-of-sides (default 4)))
(defclass quadrilateral (is-a polygon)
(role concrete))
Теперь polygon объявлен как абстрактный класс, т.е. класс, не способный самостоятельно порождать определенные объекты. Его подкласс quadrilateral и все последующие подклассы класса quadrilateral являются конкретными классами, т.е. эти классы могут порождать конкретные экземпляры (объекты классов). При определении класса polygon его слоту no-of-sides (количество сторон) назначено по умолчанию значение 4. Это отражает наше интуитивное предположение, что большинство многоугольников будет четырехугольниками. В терминологии систем фреймов такое значение по умолчанию называется фацетом слота no-of-sides.
После этого можно приступить к описанию демонов. Для этого нужно воспользоваться конструкцией defmessage-handler, которая имеется в CLIPS. (Подробно конструкция defmessage-handler также будет описана в следующей главе.)
(defmessage-handler polygon sides () ?self:no-of-sides)
Демон sides связан с классом polygon и попросту получает доступ к слоту no-of-sides того объекта, который его вызвал. Предположим, например, что определен конкретный участок, имеющий форму квадрата, причем ему присвоено наименование square-one.
(definstances geometry (square-one of square))
Система инициализируется командой (reset). Теперь можно активизировать демон, послав ему сообщение
(send [square-one] sides)
В ответ интерпретатор CLIPS выведет результат
Обратите внимание на то, что выражение ?self :no-of-sides вычисляется в контексте объекта square-one, которому было направлено сообщение и который в ответ на него активизировал демона. В этом выражении ?self является переменной и определяет объект, к слоту которого производится обращение, а двоеточие — это инфиксный оператор доступа к конкретному слоту.
6.3.4. Множественное наследование
В то определение понятия наследования, которое было дано в работах Квиллиана, концепция фреймов внесла определенные коррективы. В настоящее время является общепризнанным, что некоторый фрейм может наследовать информацию от множества предшественников в системе фреймов. В результате граф, представляющий связи между фреймами, стал больше походить на решетку, чем на дерево, поскольку каждый узел не обязательно имеет единственного предшественника. Очень часто система строится таким образом, что некоторые фреймы имеют несколько предшественников, хотя в подавляющем большинстве структур сохраняется единственность корня. Пример такой структуры представлен на рис. 6.7.
Новый узел Правильный многоугольник "не вписывается" в прежнюю классификацию, в которой за основу бралось количество сторон. Этот фрейм вводит в систему новый атрибут— "правильность" контура фигуры. Таким образом, появляется возможность передать таким фреймам, как Квадрат и Равносторонний треугольник, некоторые свойства, характерные именно для равносторонних фигур, использовав для этого механизм множественного наследования. Например, все равносторонние многоугольники имеют равные значения внутренних углов, и лучше всего хранить информацию об этом свойстве именно во фрейме Правильный многоугольник, как это следует из принципа когнитивной экономии.
Такая организация связей между фреймами не влечет за собой никаких проблем только до тех пор, пока информация, поступающая от различных источников наследования, не становится противоречивой. Но рассмотрим пример, представленный на рис. 6.8. (Он часто используется в специальной литературе и даже получил имя собственное — "Алмаз Никсона", по причинам, которые станут ясны далее.)
Положим, мы договорились считать по умолчанию, что квакеры — это пацифисты, т.е. в слоте пацифизм фрейма квакер "прописано" значение истина, и что республиканцы пацифистами не являются, т.е. в слоте пацифизм фрейма республиканец "прописано" значение ложь. Все это означает, что при отсутствии более полной информации о каком-либо конкретном республиканце или квакере предполагается, что он именно так относится к идеям пацифизма.
Рис. 6.7. Гетерархическое представление множества геометрических фигур
Рис. 6.8. Конфликт при множественном наследовании свойств
Но что в таком случае можно сказать о квакере, который является сторонником Республиканской партии? А ведь именно в такой роли выступал бывший Президент США Ричард Никсон. Является ли он пацифистом или нет? Иными словами, откуда должен унаследовать квакер-республиканец значение слота пацифизм, если считать, что мы не располагаем никакой дополнительной уточняющей информацией?
Поскольку значения, предлагаемые по умолчанию, конфликтуют друг с другом, мы, используя только ранее введенную информацию, не можем ничего сказать о пацифизме Ричарда Никсона. В такой ситуации некоторые системы, использующие механизм наследования, отказываются давать однозначное заключение. Системы с таким поведением получили наименование скептических (см., например, [Horty et al, 1987]). Другие, обнаружив подобный конфликт, выносят заключение наудачу. За ними закрепилось определение доверчивые (см., например, [Touretzky, 1986]).
Трудно отдать предпочтение какой-либо из этих стратегий. Но в любом случае лучше заранее подумать о том, как избежать подобных конфликтов при внедрении систем фреймов. Например, можно оспорить мнение, что миролюбивый республиканец — явление более редкое, чем квакер, поддерживающий акции с применением силы, и либо установить определенный порядок анализа наследования от различных предшественников, либо не использовать в данном случае механизм наследственности и принудительно установить значение истина для слота пацифизм во фрейме квакер-республиканец. Есть и альтернативный вариант— подключить к слоту пацифизм во фрейме квакер-республиканец специальный демон по требованию, использующий "для устранения неоднозначности какие-либо "посторонние" знания, которыми мы не располагаем на стадии конструирования системы фреймов. Так, квакер-республиканец может не следовать идеям пацифизма в год выборов в соответствии с общей политикой своей партии, но в обычное время будет рассматриваться как пацифист, полагая, что квакерское воспитание пересиливает партийную дисциплину.
Следует отметить, что анализ сетей с наследованием оказывается проще, чем анализ систем фреймов, поскольку узлы в сети не нуждаются в слотах или подключенных процедурах. Неоднозначность в сети устанавливается путем анализа ее топологии. Для того чтобы в сети потенциально могла появиться неоднозначность, о которой идет речь, необходимо, чтобы набор узлов {А, В, С, ...} образовал ациклический граф со связями двух типов: положительные связи, которые означают, что А является элементом В, и отрицательные связи, которые означают, что А не является элементом В. Тогда мы сможем представить проблему выяснения глубины пацифистских взглядов Р. Никсона в виде сети рис. 6.9. Здесь пацифист — это узел со своими собственными правами, и отрицательный характер связи между ним и узлом республиканец показан засечкой на линии связи.
Рис. 6.9. Представление "проблемы Никсона" в виде сети с наследованием
Из изложенного ясно, что в гетерархической системе потенциальные возможности для образования самых разнообразных взаимосвязей гораздо шире, чем в системе с жесткой иерархической структурой. Узлы более высоких уровней могут иметь общих наследников на более низких уровнях, что является признаком существования непрямых отношений между такими узлами. Например, имеются определенные отношения между узлами, представляющими равносторонний треугольник и квадрат в рассмотренном выше примере. В системе фреймов значение некоторого слота также может быть указателем на определенный фрейм (или фреймы), что порождает еще одно измерение в структуре системы (см. об этом в описании системы CENTAUR в главе 13).
6.3.5. Сравнение сетей и фреймов
Подводя итог всему сказанному выше об ассоциативных сетях и фреймах, отметим, что в большинстве предлагаемых структур сетей не удалось дать четкий ответ на два важных вопроса.
Что же действительно стоит за узлами и связями в сети?
Как можно эффективно обрабатывать информацию, хранящуюся в такой структуре?
В большинстве последних исследований, касающихся представления знаний, предпочтение отдается фреймам. Такой подход дает вполне удовлетворительные ответы на сформулированные выше вопросы. Семантика узлов и связей четко прослеживается благодаря разделению узлов на узлы-типа и узлы-лексемы и ограничению количества связей. Эффективность обработки обеспечивается подключением к узлам специфических процедур, на которые возлагается вычисление значений переменных в ответ на запросы или при обновлении значений других свойств узла.
Использование фреймов в качестве основной структуры данных, хранящей информацию о типичных объектах и событиях, в настоящее время широко распространено в практике создания приложений искусственного интеллекта (см. об этом в главах 13 и 16). Большинство программных инструментальных средств, предназначенных для построения экспертных систем, обеспечивает тем или иным способом организацию базы знаний на основе фреймов (см. об этом подробнее в главах 17 и 18). Во многих случаях желательно оценить, какими возможностями обладает механизм представления гипотез с помощью фреймов в части использования таких данных, как совокупность симптомов или результатов наблюдений за поведением объектов. Сопоставление этих данных с информацией, хранящейся в слотах фреймов, предоставляет свидетельство в пользу гипотез, представленных фреймом, а также позволяет формулировать определенные предположения относительно других данных, например предположить существование дополнительных симптомов, присутствие или отсутствие которых сможет подтвердить (или опровергнуть) анализируемую гипотезу (см. об этом подробнее в главе 13).
Естественно, для того чтобы реализовать систему фреймов в виде, пригодном для работы с конечным пользователем, требуется разработать программную оболочку и средства пользовательского интерфейса. Хотя к слотам отдельных фреймов и могут быть подключены специальные процедуры, эти локальные модули не способны взять на себя все заботы об организации вычислительного процесса в системе. Необходимо иметь в той или иной форме специальный интерпретатор, который будет формировать и обрабатывать запросы и принимать решение, при каких условиях можно считать достигнутой цель, сформулированную в запросе. Поэтому чаще всего фреймы используются в сочетании с другими средствами представления знаний, в частности в сочетании с порождающими правилами. В следующей главе мы рассмотрим стиль программирования, который в определенной степени избавляет структурированные объекты от необходимости пользоваться внешними средствами контроля, поскольку позволяет объектам пересылать сообщения друг другу и инициировать таким образом более сложные вычисления.
Рекомендуемая литература
В двух сборниках [Bobrow and Collins, 1975] и [Findler, 1979] содержится подборка статей, которые дают достаточно полное представление об исследованиях, выполненных в то время, когда проблематика ассоциативных сетей вызывала наибольший интерес. Начинать изучение концепции фреймов следует с пионерской статьи Минского, опубликованной в сборнике [Winston, 1975], в которой даны исходные формулировки базовых понятий, таких как "типичность" и "значения по умолчанию". Другие понятия, связанные с этой концепцией, рассматриваются в работе Шенка и Абельсона [Schank and Abelson, 1977].
Турецкий рассмотрел некоторые теоретические вопросы построения сетей с наследованием и предложил весьмаинтересную процедуру формирования суждений при наличии исключений [Touretzky, 1986]. Среди более поздних работ, посвященных этим проблемам, следует отметить [Touretzky et al, 1987], [Horty et al., 1987] и [Selman and Levesque, 1989]. В последней статье показано, что предложенная Турецким процедура относится к классу NP-hard, т.е. для обширных сетей с большим количеством связей становится "вычислительно необозримой".
Позднее Томасон опубликовал обзор современных работ по сетям с наследованием [Thomason, 1992], а в двух работах Йена описана методика интеграции концепции сетей с наследованием в экспертные системы, основанные на порождающих правилах [Yen et al., 1991,a], [Yen et al, 1991, b].
Упражнения
1. Прочитайте статью Хейеса в сборнике [Brachman and Levesque, 1985]. Как вы думаете, можно ли считать фреймы не более чем средством реализации подмножества логики предикатов, или они позволяют смоделировать экстралогические свойства, присущие человеку, формулирующему суждения?
2. Неоднозначность, которую мы обнаружили в "проблеме Никсона", можно распространить каскадно и получить еще более замысловатые примеры. Один из них взят из работы [Touretzky et al., 1987] (рис. 6.10). Познакомьтесь с этой работой, а затем ответьте на следующие вопросы.
I) К какому заключению придет доверчивый резонер, рассуждая об отношении квакера-ре спубликанца к армии?
II) К какому заключению придет резонер-скептик?
3. Примеры сетей с наследованием, представленные на рис. 6.11 и 6.12, также взяты из работы [Touretzky et a/., 1987]. На этих рисунках представлены две топологически
идентичные сети, которые отличаются только маркировкой узлов. На рис. 6.11 показано, что королевские слоны являются исключениями, поскольку не имеют серой окраски, а на рис. 6.12 показано, что капелланы являются исключениями, поскольку это мужчины, не склонные к употреблению пива.
Рис. 6.10. Сеть с наследованием, в которой имеется каскад неоднозачностей
I) Резонер Турецкого должен был бы заключить, что в обоих случаях возможно несколько интерпретаций. Согласны ли вы с таким заключением или нет и по какой причине?
II) Сандуол полагает, что корректная интерпретация сети на рис. 6.11 состоит в том, что прямой путь от узла королевский слон к узлу серые животные должен иметь более высокий приоритет, чем непрямой путь через узел слон [Sandewall, 1986]. А что вам подсказывает ваша интуиция?
III) Днализируя сеть, представленную на рис. 6.12, Турецкий пришел к заключению, что изменение маркировки узлов сети с одной и той же топологией меняет и наше интуитивное предположение о распространении наследуемых свойств. Заключение о том, что корабельный капеллан не является любителем пива (как на том настаивает Сандуол), является менее обоснованным, чем в случае со слонами. В пользу такого заключения Турецкий приводит следующие аргументы.
Ни капелланы, ни моряки не могут рассматриваться как типичные мужчины, причем обе категории очень сильно отличаются друг от друга. Поэтому сделать какое-либо заключение о свойствах корабельного капеллана очень сложно.
Хотя нам и известно, что капелланы — трезвенники, мы ничего не знаем о том, насколько распространено употребление пива среди моряков на кораблях. Вполне возможно, что оно стало популярным и среди корабельных капелланов.
С какой из участвующих в споре сторон согласны вы? Или, возможно, у вас есть аргументы в пользу обеих точек зрения?
Рис. 6.11. Проблема "королевского слона"
Рис. 6.12. Проблема "корабельного капеллана "
4. Просмотрите пример из врезки 6.1. Придумайте обработчик сообщения для класса square, который будет вычислять площадь объекта этого класса, например объекта square-one, а затем присваивать вычисленное значение слоту этого объекта.
Для этого вам понадобится сначала внести изменения в определение класса square.
(defclass square (is-a rectangle)
(slot length-of-sides (create-accessor write))
(slot area (create-accessor write)))
Согласно этому определению, класс square имеет два слота: length-of-sides — для хранения длин сторон объекта, area — для хранения его площади. Фацет create-accessor в определении слота говорит о том, что функции доступа к слоту должны автоматически формироваться средствами языка CLIPS. Последние самостоятельно сформируют объявления функций put-length-of-sides и put-area. Эти наименования функций можно затем использовать в обработчиках сообщений.
Второй шаг — модифицировать спецификацию объекта, в которую следует включить задание длин сторон:
(definstances geometry (square-one of square
(length-of-sides 10)))
Теперь остается только разработать обработчик события, который будет использовать функцию для установки нужного значения в слот area объекта square-one.
5. Метод, который был реализован в предыдущем упражнении, хорош для работы с квадратами, но с его помощью нельзя решить аналогичную проблему при работе с другими четырехугольниками, представленными в нашей иерархии,— прямоугольниками, параллелограммами и трапециями. Теперь, когда вы знаете, как сформировать слоты и обработчики событий, пользуясь средствами языка CLIPS, попытайтесь решить и эту проблему. Для этого вам потребуется передавать объекту любого класса, расположенного в иерархии ниже узла четырехугольник, сообщение, в ответ на которое соответствующий обработчик должен извлечь данные из слотов, представляющих отдельные исходные параметры формы фигуры (длины сторон, высота и т.д.), и обрабатывать их по формуле, специфичной для фигур каждого вида. Постарайтесь найти такое решение, которое позволяло "бы обрабатывать различные фигуры по возможности единообразно. Учтите, что подклассы могут наследовать и слоты, и обработчики сообщений от своих суперклассов (предшественников).
ГЛАВА 7. Объектно-ориентированное программирование
7.1. Язык KRL
7.2. Языки LOOPS и FLAVORS
7.2.1. Передача сообщений
7.2.2. Проблема наложения методов
7.2.3. Метаклассы
7.3. Языки CLIPS и CLOS
7.3.1. Множественное наследование в CLOS и CLIPS
7.3.2. Наложение методов в CLOS и CLIPS
7.3.3. Метаклассы в CLOS и CLIPS
7.4. Множественное наследование в C++
7.5. Объектно-ориентированный анализ и конструирование экспертных систем
Рекомендуемая литература
Упражнения
ГЛАВА 7. Объектно-ориентированное программирование
7.1. Язык KRL
7.2. Языки LOOPS и FLAVORS
7.3. Языки CLIPS и CLOS
7.4. Множественное наследование в C++
7.5. Объектно-ориентированный анализ и конструирование экспертных систем
Рекомендуемая литература
Упражнения
За последние 20 лет было разработано довольно много языков для представления знаний, причем большинство из них можно отнести к классу объектно-ориентированных. Как и в случае с использованием концепции фреймов, основная идея состоит в том, чтобы заключить данные и связанные с ними процедуры в некие структуры, объединенные механизмом наследования. Отличие от формализмов, описанных в предыдущей главе, состоит в том, что процедуры могут наследоваться (и комбинироваться) точно так же, как и данные, а объекты могут взаимодействовать друг с другом напрямую или посредством специальных протоколов обмена сообщениями.
Сначала читатель вкратце познакомится с одним из предшественников современных программных средств — системой KRL (сокращение от Knowledge Representation Language — язык представления знаний). Потом будет показано, как в процессе эволюции в последующих разработках были преодолены некоторые сложности, присущие этому стилю программирования. Читатель познакомится с системами FLAVORS, LOOPS и более современной системой CLOS (Common LISP Object System — объектная система на базе обычного LISP). В конце главы описывается, как объектно-ориентированный подход реализован в языке CLIPS, и рассмотрены достоинства и недостатки использования для представления знаний объектно-ориентированных языков общего назначения, таких как C++.
В данной главе мы вновь затронем некоторые вопросы, рассмотренные в предыдущих главах, в частности вопрос о наследовании, но уделим ему гораздо больше внимания. Независимо от того, какой конкретный язык будет обсуждаться в том или ином разделе, во всех представленных примерах используется либо язык COOL (CLIPS Object Oriented language — объектно-ориентированная версия языка CLIPS), либо C++. Разделы, в которых детально изложены технические подробности функционирования конкретных программных средств (они помечены крестиком), можно при желании опустить. Большинство примеров приведено во врезках. При первом чтении их также можно бегло просмотреть или опустить, что не помешает разобраться в основных темах главы.
7.1. Язык KRL
В языке KRL впервые была сделана попытка собрать воедино результаты выполненных ранее исследований о структурировании элементов знаний и реализовать их в виде единой системы [Bobrow and Winograd, 1977]. Создание системы преследовало не только теоретические цели, но и имело достаточно четкую практическую направленность. В качестве "строительных блоков" системы использованы так называемые "концептуальные объекты", которые были сходны с фреймами, предложенными Минским, в том, что представляют прототипы и связанные с ними свойства. Основную идею авторы так изложили в опубликованной в 1977 году статье:
"...анализ последствий объектно-центрической факторизации знаний в противовес более общей факторизации, предполагающей структурирование знаний в виде набора фактов, каждый из которых ссылается на один или несколько объектов".
Такая ориентация повлекла за собой создание декларативного языка, основанного на описаниях, в которых концептуальные объекты рассматриваются не изолированно, а в совокупности с другими объектами-прототипами. Фундаментальное предположение состояло в том, что то, какие свойства некоторого объекта знаний оказываются существенными, представляющими интерес и т.д., зависит от точки зрения на объект и цели решаемой задачи. Например, если вам нужно сыграть музыкальную пьесу на пианино, то вас интересуют такие свойства этого объекта, как качество звучания, настройки и т.п. А вот грузчику более интересны такие свойства этого музыкального инструмента, как вес и габариты.
В этом свете описание новой сущности можно рассматривать как процесс сравнения ее с ранее описанными: нужно указать, на какие из известных объектов похож новый и чем именно, а в чем от них отличается. Так, мини-фургон очень похож на легковой автомобиль, но отличается от последнего отсутствием сидений для пассажиров и окон в задней части. Другими словами, полный набор понятий можно определить в терминах друг друга, а не в терминах более компактного множества примитивных идей. Сложность с использованием примитивов в представлении семантики состоит в том, что вряд ли когда-нибудь удастся прийти к единому мнению о том, что же представляют собой такие примитивные понятия и как их следует комбинировать при формировании более сложной идеи (с некоторыми соображениями на сей счет читатель может ознакомиться в работах [Schank, 1975] и [Schank andAbelson, 1977]).
В основе процедурных свойств языка KRL также лежат наиболее распространенные программные методы, предполагающие подключение процедур общего вида к классам объектов данных. Бобров и Виноград объединили этот вид подключения процедур со структурой фрейма и позволили подклассам наследовать как процедуры, так и данные своего суперкласса.
Разработчики языка предположили, что наследование процедур позволит программировать в терминах родовых операций, детали реализации которых конкретизируются по-разному для объектов разных классов. Так же, как абстрактные типы данных позволяют программисту забыть о деталях хранения конкретных данных в машине, так и родовые операции позволяют на определенной стадии не принимать во внимание детали реализации однотипных операций в каждом конкретном случае. Пример поможет вам четче представить смысл этой идеи.
Предположим, вас назначили Верховным главнокомандующим при проведении военной операции, в которой принимают участие различные рода войск. Отданные в ваше распоряжение танки, корабли и самолеты ждут приказа атаковать. Получив такой приказ, каждый из родов войск будет действовать по-своему: самолеты начнут бомбить, корабли — выпускать ракеты и т.д. Но поведение каждого из родов войск — это частная реализация общей концепции наступательных военных действий. Как главнокомандующего, вас мало интересуют детали выполнения приказа: на какие рычаги нажимать, какие переключатели включать, — все это должно быть определено на более низких уровнях.
Возвращаясь вновь к KRL, отметим, что идея, которая стоит за объектно-центрической организацией процедур, состоит в том, чтобы попытаться программно воспроизвести тот естественный стиль выработки суждений, который реализуется в мозге человека. В частности, предполагается, что управление логическим выводом реализуется на локальном уровне, в отличие от глобальных задач, ассоциирующихся, например, с автоматическим доказательством теорем. Другими словами, зная, как реализовать родовые операции, классы объектов будут обладать знаниями и о том, когда активизировать те многочисленные процедуры, к которым они имеют доступ.
Мы не затрагивали многих других аспектов языка KRL, например средств управления процессом или составления расписаний работ. Читателям, интересующимся этим языком, рекомендуем познакомиться с критическим анализом этого языка, который выполнили Ленерт и Уилкс [Lehnert and Wilks, 1979], и ответом разработчиков на эти критические замечания [Bobrow and Winograd, 1979]. Нельзя не отметить, что язык KRL явился тем локомотивом, который существенно подтолкнул исследования в области теории представления знаний и, в частности, способствовал появлению практических систем, о которых речь пойдет в следующем разделе.
7.1. Процедуры и объекты
На рис. 7,1 мы попытались схематически представить, в чем основная разница между процедурно- и объектно-ориентированным подходами в программировании.
Серые! эллипсы на схеме в левой части рисунка представляют процедуры, некоторые из которых напрямую обращаются к данным, хранящимся в файле или в базе данных. Зачерненный эллипс представляет процедуру самого верхнего уровня (в языке С — это процедура main). Эта функция вызывает другие функции, которые в конце концов вызывают функции самого нижнего уровня, выполняющие операции ввода/вывода.
На правой схеме объекты объединяют данные и процедуры работы с ними. Объекты организованы в виде одной или нескольких иерархических структур — деревьев или решеток. Утолщенный прямоугольник на схеме представляет базовый абстрактный класс. Экземпляры этих объектов взаимодействуют друг с другом, обмениваясь сообщениями, и таким образом образуются связи, ортогональные иерархии наследования.
Рис. 7.1. Процедурно- и объектно-ориентированные парадигмы программирования. Незаполненные фигуры представляют данные, а фигуры с заливкой—процедуры
7.2. Языки LOOPS и FLAVORS
Объектно-ориентированный стиль программирования идеально подходит для решения проблем, требующих детального представления объектов реального мира и динамических отношений между ними. Классическим примером применения данного подхода являются задачи моделирования. В таких программах компоненты сложной системы представляются структурами, инкапсулирующими и данные, и функции, моделирующие поведение соответствующих компонентов. Первым языком, в котором была реализована такая идея, стал SmallTalk [Goldberg andRobson, 1983].
Для задач искусственного интеллекта были разработаны языки LOOPS и FLAVORS, причем оба представляли собой объектно-ориентированные расширения языка LISP. Хотя в настоящее время эти языки практически не используются, реализованные в них базовые идеи унаследованы множеством языков представления знаний, появившихся позже. В частности, это можно сказать о языках CLOS (Common LISP Object System) и CLIPS. Ниже мы кратко опишем основные функциональные возможности языков LOOPS и FLAVORS и обратим ваше внимание на некоторые сложности, связанные с реализацией объектно-ориентированного стиля программирования.
7.2.1. Передача сообщений
Идея объектно-ориентированного программирования состоит в том, что программа строится вокруг множества объектов, каждый из которых обладает собственным набором функций (операций). Вместо того чтобы представлять объект пассивным набором данных, объектно-ориентированная система позволяет объекту играть более активную роль, в частности взаимодействовать с другими объектами, обмениваясь с ними сообщениями. В результате основной упор переносится с разработки общей управляющей структуры программы, которая ответственна за порядок обращения к функциям, на конструирование самих объектов, выяснение их ролей и создание протоколов взаимодействия объектов. Эти протоколы, по существу, определяют интерфейс между объектами. Если один объект должен взаимодействовать с другим, он должен вызывать функции в строгом соответствии с этим интерфейсом.
Объекты располагают собственными данными, которые играют ту же роль, что и слоты фреймов, собственным механизмом обновления этих данных и использования хранящейся в них информации. Помимо функций интерфейса, объекты располагают собственными, "приватными" функциями, которые, как правило, представляют собой реализацию определенной родовой операции применительно к данному объекту. Помимо данных, передаваемых в качестве аргументов родовой операции, такие функции используют и локальные данные объекта — аналоги слотов фрейма.
Предположим, мы определили объект, представляющий класс ship (корабль), и наделили его свойствами x-velocity (скорость по х) и y-velocity (скорость по у). Теперь можно создать экземпляр класса ship, назвать его Titanic и одновременно присвоить свойствам x-velocity и y-velocity нового экземпляра исходные значения. Практически нет никаких отличий между этой процедурой и процедурой создания нового экземпляра фрейма, рассмотренной в предыдущей главе.
Предположим теперь, что нам понадобилось определить процедуру speed, которая будет вычислять скорость судна на основании значений свойств x-velocity и у-velocity (скорость вычисляется как корень квадратный из суммы квадратов компонентов). Такая процедура будет принадлежать абстрактному типу данных, представляющему любые суда (в терминологии языка SmallTalk speed — это метод класса ships, а в терминологии C++ — функция-член класса ships.)
Идея состоит в том, чтобы закодировать в объекте (классе) не только декларативные знания о судах, но и процедурные, т.е. методы использования декларативных знаний. Для того чтобы активизировать процедуру вычисления скорости определенного судна, в частности "Титаника", нужно передать объекту Titanic сообщение, которое побудит его обратиться к ассоциированной процедуре в контексте данных о компонентах скорости именно этого объекта. Titanic — это экземпляр класса ships, от которого он унаследовал процедуру speed. Все это представляется довольно очевидным, но описанный механизм срабатывает только в случае, если соблюдаются следующие соглашения.
Во-первых, программа, разработанная в расчете на этот механизм, должна "учредить" и следовать в дальнейшем определенному протоколу или "контракту", определяющему способ взаимодействия между объектами. Другими словами, интерфейс обмена сообщениями между объектами должен быть досконально продуман, а правила этого интерфейса жестко соблюдаться. Лучше всего продемонстрировать эту мысль на примере.
Для того чтобы определить компоненту X текущего положения "Титаника", программа должна послать запрос объекту Titanic, который имел бы следующий смысл: "передай текущее значение координаты X". Как в объекте формируется это значение или как оно хранится — дело только самого объекта и никого более не касается. Ни объекты других классов, ни какие-либо другие компоненты программы этого не знают. Более того, внутренний механизм доступа к этой информации должен быть скрыт, чтобы никто не мог добраться к ней, минуя сам объект. Это соглашение принято называть инкапсуляцией.
Во-вторых, совершенно очевидна избыточность определения своего метода вычисления скорости для каждого класса объектов, которые обладают возможностью перемещаться в двумерной системе координат. Метод, который мы только что определили для класса судов, с таким же успехом может быть использован и для других движущихся объектов, поскольку вычисление скорости представляет собой родовую операцию. Поэтому имеет смысл связать этот метод с каким-нибудь суперклассом транспортных средств, производными от которого будут классы судов, автомобилей, троллейбусов и т.п. Все эти подклассы унаследуют родовую операцию у своего базового класса.
Такое наследование — это уже нечто большее, чем когнитивная экономия или наследование свойств. Выполнение родовых операций встраивается в механизм обмена сообщениями. Отсылка сообщения— это отнюдь не вызов определенной процедуры, поскольку вызывающий объект не знает, каким именно методом отреагирует на это сообщение объект-получатель, от кого он унаследует этот метод, и будет ли вообще задействован механизм наследования в данном конкретном случае. Вызывающему объекту известны лишь наименование операции и ее внешние по отношению к преемнику аргументы. Все остальное — заботы объекта-реципиента сообщения.
7.2. Формирование объекта класса на языке CLIPS
Ниже показано, как на языке CLIPS определяется класс ship и формируется экземпляр этого класса titanic. Сначала определим класс ship, в котором имеются два слота: x-velocity и y-velocity:
(defclass ship
(is-a INITIAL_OBJECT)
(slot x-velocity (create-accessor read-write))
(slot y-velocity (create-accessor read-write)) )
Теперь сформируем экземпляр этого класса,, которому будет дано наименование "Titanic". Проще всего это сделать с помощью функции definstaces, которая в качестве аргументов принимает список параметров формируемых экземпляров. Определенные таким способом экземпляры класса будут инициализироваться при каждом перезапуске интерпретатора CLIPS.
(definstances ships (titanic of ship
(x-velocity 12) (y-velocity (10)
Завершается определение созданием обработчика событий для класса ship. Все экземпляры класса будут использовать этот обработчик для вычисления собственной скорости. Обратите внимание на то, что член в этом определении ссылается на значение слота того экземпляра класса, скорость которого требуется вычислить.
(defmessage-handler ship speed () (sqrt
( +
{ ?self:x-velocity ?self:x-velocity)
( ?self:y-velocity ?self:y-velocity)))
)
Если файл со всеми представленными выше выражениями загрузить в среду CLIPS, а затем ввести с клавиатуры (send [titanic] speed), то в ответ интерпретатор CLIPS выведет скорость объекта titanic
7.2.2. Проблема наложения методов
Та простая картина, которая вырисовывается из представленного выше механизма прямого наследования, несколько усложняется, если мы попытаемся заменить прямое наследование множественным. В главе 6 уже отмечалось, что это может привести к неоднозначности в наследовании свойств. Но в контексте объектно-ориентированного подхода при множественном наследовании появляется и неоднозначность поведения.
С этой проблемой впервые столкнулись при разработке объектно-ориентированного языка FLAVORS, который поддерживает множественное наследование и наложение методов [Cannon, 1982]. Язык FLAVORS позволяет объектам иметь несколько родителей и таким образом наследовать процедуры и данные из нескольких источников. Для FLAVORS характерна не иерархия объектов, а гетерархия. Если графически изобразить отношения между разными объектами в FLAVORS, то схема будет больше походить на решетку, чем на дерево. Каков во всем этом смысл? Рассмотрим следующий пример, взятый из статьи Кэннона.
Отображение окон на дисплее рабочей станции реализуется, как правило, с использованием объектно-ориентированного стиля программирования. Будем считать, что окна на экране дисплея представлены в виде LISP-объектов, в каждом из которых записаны свойства окна (размеры и положение на поле экрана) и процедуры работы с окном (открытие, закрытие, перерисовка и т.п.). Существует несколько разновидностей окон и соответственно объектов окон — с рамкой, без рамки, со строкой заголовка, без заголовка и т.д.
Класс окно с рамкой .является подклассом (или производным классом) класса окно. Точно так же подклассом класса окно является и класс окно с заголовком. В иерархической системе классы окно с рамкой и окно с заголовком представляют собой отдельные узлы одного и того же уровня иерархии. Они наследуют определенные методы, например refresh (освежить), от базового класса окно, но имеют и собственные методы выполнения таких операций, как перерисовка рамки или строки заголовка.
А теперь предположим, что нам потребовался еще один вид окна — окно с рамкой и строкой заголовка. Окно такого типа должно быть представлено новым классом окно с рамкой и заголовком. В иерархической системе новый класс будет наследником класса окно и независимым "близким родственником" уже существующих классов окно с рамкой и окно с заголовком на том же уровне иерархии (рис. 7.2). Но даже интуитивно чувствуется, что такая организация избыточна. Ведь фактически мы стремимся "смешать" два набора уже существующих качеств и получить в результате новый комбинированный набор. Кажется, что целесообразнее сделать новый класс "дитятей" двух родителей, — классов окно с рамкой и окно с заголовком (рис. 7.3).
Рис. 7.2. Иерархическая система классов окон
Но здесь возникают вопросы: а как новый класс будет наследовать процедуры, определенные в двух базовых классах? Устроит ли нас "смешанное" поведение нового класса? Эту проблему можно разложить на две составляющие:
найти подходящие методы в базовых классах;
скомбинировать их таким образом, чтобы получить желаемый эффект.
Рис. 7.3. Гетерархическая система классов окон
Для решения этой задачи очень подходит механизм включения в основной метод вставок, которые должны выполняться до или после него. В приведенном выше примере с объектами окон можно скомпоновать метод отрисовки окна с рамкой и строкой заголовка таким образом, чтобы новый класс использовал унаследованный от класса окно метод refresh и, кроме того, специализированные методы, унаследованные от каждого из ближайших родителей и выполняемые после основного refresh. При этом должен четко соблюдаться порядок выполнения унаследованных операций и вставок, поскольку его изменение может привести к нежелательному эффекту. В нашем примере после выполнения метода "прародителя" окно нужно выполнить сначала вставку, унаследованную от класса окно с рамкой, а потом вставку, унаследованную от класса окно с заголовком. В противном случае при вычерчивании рамки будет затерта строка заголовка.
7.2.3. Метаклассы
Отличительной чертой языка LOOPS является поддержка концепции метаклассов, т.е. классов, членами которых являются другие классы. Впервые метаклассы появились в языке SmallTalk. В первой системе реализации этого языка имелся единственный метакласс Class, членами которого были все прочие классы в системе, в том числе и Class. В более поздних реализациях SmallTalk метакласс формировался автоматически всякий раз, когда создавался новый класс, и этот класс становился экземпляром класса Metaclass. Метаклассы в SmallTalk-80 сами по себе не являлись экземплярами метаклассов, а принадлежали единственному метаклассу Metaclass. Во избежание путаницы мы в дальнейшем будем называть "классами объектов" те классы, которые не являются метаклассами.
Смысл существования метаклассов — поддержка создания и инициализации экземпляров классов. Обычно сообщение посылается экземпляру класса, а не самому классу. Экземпляр класса наследует поведение от своего класса объектов. Но иногда желательно передать сообщение именно классу, например сообщение "сформировать экземпляр с такими-то свойствами". Классы наследуют поведение от своих метаклассов и таким образом вся система обладает приятным с точки зрения пользователя единообразием. (Обычно сообщения метаклассам не посылаются, но если такое произойдет, то они будут наследовать поведение от класса Metaclass, к которому они все принадлежат, включая и сам Metaclass.)
В языке LOOPS метакласс не создается для каждого класса. Этот язык имеет более простую структуру классов, представленную схематически на рис. 7.4. Узлы в форме эллипсов представляют классы объектов и метаклассы, а узлы в форме прямоугольников представляют экземпляры классов объектов. Тонкие стрелки означают отношения вида "А является подклассом В", а толстые — отношения вида "А является экземпляром В".
Рис. 7.4. Структура классов в языке LOOPS
LOOPS поддерживает три стандартных метакласса: Object, Class и Metaclass. Тонкие стрелки на рис. 7.4 означают, что Object является суперклассом класса Class, a Class является суперклассом класса Metaclass. Кроме того, Object является членом Class, Class — членом Metaclass, a Metaclass — членом самого себя. Таким образом, оказывается, что Object является корнем иерархии классов (не имеет суперкласса), а Metaclass является корнем иерархии экземпляров (не имеет ни одного класса, кроме самого себя).
Узлы, вычерченные утолщенными линиями — ship (корабль) и liner (лайнер), — типичные классы, определенные пользователем. Обратите внимание на то, что все классы такого рода являются членами класса Class, от которого они наследуют свое поведение. Таким образом, для того чтобы сформировать экземпляр Titanic, нужно переслать сообщение new классу liner, который наследует метод new от класса Class. Поведение экземпляра Titanic, естественно, будет унаследовано от его класса— в данном случае liner.
Использование метаклассов позволяет запрограммировать поведение по умолчанию и определенные виды структур в объектно-ориентированной системе на самом высоком уровне. Экземпляры классов объектов, таких как liner, обычно формируются стандартным способом, но если для одного или семейства классов желательно использовать какой-то более специфический вариант, нужно включить между liner и Class определенный пользователем метакласс (например, metaliner), в котором и "прописать" желаемые модификации (рис. 7.5). Таким образом, структура классов в языке LOOPS позволяет в одной системе объединить мощность и гибкость представления объектов реального мира.
Рис. 7.5. Вставка метакласса, определенного пользователем
7.3. Языки CLIPS и CLOS
Появление языка Common LISP было связано с попыткой стандартизировать многочисленные диалекты LISP и создать устраивающую большинство пользователей версию этого языка. Развитие объектно-ориентированного подхода в программировании привело к разработке объектно-ориентированной версии LISP — Common LISP Object System (CLOS), о которой и пойдет речь в этом разделе. Разработчики CLOS включили в свою систему поддержку всех новшеств, ранее хорошо себя зарекомендовавших в языках FLAVORS и LOOPS, таких как множественное наследование, объединение методов и структура метаклассов.
Объектно-ориентированная версия CLIPS, язык COOL, очень близок к CLOS, что мы и продемонстрируем на примерах в этом разделе.
7.3.1. Множественное наследование в CLOS и CLIPS
Механизм множественного наследования в языках CLOS и CLIPS работает практически так же, как и в языке LOOPS. Порядок, в котором базовые классы перечислены в определении подкласса, задает и порядок приоритетов наследования данных и процедур. Кроме того, существует правило, в соответствии с которым определение процедуры или свойства, сделанное в классе, всегда имеет приоритет перед унаследованными от суперклассов. Эти соглашения позволяют разрешить проблему неоднозначности при множественном наследовании путем формирования списка предшествования классов.
Рассмотрим фрагмент программы на языке CLIPS, представленный в листинге 7.1. Этот фрагмент описывает "Алмаз Никсона", о котором шла речь в главе 6. Класс person определен как объявленный пользователем, классы quaker и republican — производные от person, a republican-quaker — производный как от quaker, так и от republican. Класс USER является системным абстрактным классом, т.е. может быть использован только для создания подклассов. Если планируется создавать экземпляры любого класса, производного от USER, то этот класс нужно объявлять с квалификатором concrete, как это и сделано при объявлении класса republican-quaker.
Листинг 7.1. Объявление классов на языке CLIPS
(defclass person (is-a USER)
(defclass quaker (is-a person)
(defclass republican (is-a person)
(defclass republican-quaker
(is-a republican quaker) (role concrete)
Список предшествования классов для класса republican-quaker будет иметь вид (republican-quaker republican,quaker person).
Список формируется в результате прослеживания графа связей системы классов, который неявно представлен слотами is-a в определениях классов.
Роль списка предшествования классов становится ясной при разработке обработчика событий для производного класса. Определим поведение классов quaker и republican как "голубей" и "ястребов" соответственно:
(defmessage-handler quaker speak () (printout t crlf "Peace")
)
(defmessage-handler republican speak ()
(printout t crlf "War") )
Сформируем экземпляр класса republican-quaker:
(definstances people
(richard of republican-quaker))
Теперь загрузим все это в исполняющую систему CLIPS и введем запрос к экземпляру Richard:
(send [richard] speak)
В ответ интерпретатор выведет "War" (война). Оказывается, что "ястребиный" характер республиканцев возобладал у экземпляра richard, поскольку в списке предшествования классов republican стоит раньше, чем quaker. Изменим порядок перечисления этих классов в определении republican-quaker:
(defclass republican-quaker
(is-a quaker republican)
(role concrete) )
Теперь в характере экземпляра Richard миролюбие квакеров будет доминировать. Ничего не изменится в поведении экземпляра и в том случае, если добавить обработчик сообщения в класс person:
(defmessage-handler person speak ()
(printout t crlf "Beer") )
Эта реализация метода speak перекрывается другими, поскольку класс находится в списке предшествования на последнем месте.
Слоты данных в языке COOL также поддерживают фацеты, т.е. свойства, ответственные за доступ к слотам в процессе работы программы. Например, существует фацет visibility (видимость), который определяет, какие другие классы могут обратиться к слоту. Значение private означает, что только обработчик сообщения данного класса может получить доступ к данным, а значение public позволяет это сделать также обработчикам сообщений производных классов и суперклассов.
Другие фацеты позволяют реализовать следующие возможности:
автоматическое определение функций доступа и присвоения значений слотам;
хранение данных, к которым возможен доступ со стороны всех экземпляров класса, аналогично статическим членам классов в языке C++.
7.3.2. Наложение методов в CLOS и CLIPS
В языках FLAVORS и LOOPS реализованы разные механизмы комбинирования поведения, унаследованного от разных "родителей". В языке FLAVORS используется описанный выше механизм вставок, а в языке LOOPS производится дополнительное обращение к альтернативному коду.
В языке CLOS поддерживаются оба варианта. Обычно существует главный метод, который берет на себя основную часть работы по выполнению родовой операции (примером является метод refresh, о котором шла речь при обсуждении набора классов окон). Как и в языке FLAVORS, before-методы (предварительные методы) используются для подготовки данных для тех вычислений, которые должны быть выполнены primary-методом (основным методом), а after-методы (заключительные-методы) используются для выполнения заключительных операций.
Кроме того, в CLOS имеется возможность использовать так называемые around-методы (методы оболочки), которые образуют своего рода оболочку вокруг ядра (последовательности "before-метод— primary-метод— after-метод"). Такая методика предназначена для ситуаций, в которых ядро не позволяет достичь требуемого результата. Например, желательно, чтобы before-метод установил локальные переменные, которые должны быть использованы primary-методом, или когда нужно заключить primary-метод в какую-либо управляющую структуру. В ядре before- и after-методы используются только для того, чтобы сформировать побочные эффекты; возвращается же значение, сформированное primary-методом, причем это значение не ограничивается никакими внешними управляющими структурами.
Наиболее специфический around-метод связывается с сообщением, которое передается перед тем, как будут вызваны подходящие before-, primary- или after-методы. Обращение к ядру производится в процессе выполнения системной функции call-next-method, которая размещается в теле around-метода.
Стандартная методика наложения методов суммирована в схеме, представленной на рис. 7.6.
В CLOS предлагается множество дополнительных типов наложения методов. Более того, пользователь может самостоятельно создавать и собственные типы. Например, тип or-combination передает вызывающему объекту значение первого компонента, вернувшего значение, отличное от NIL. При создании собственных функций наложения пользователь может использовать операторы разных видов: логические, арифметические или манипулирования списками.
Следует отметить, что стандартная схема наложения методов удовлетворяет потребности программирования практически на 90%.
Методы в CLOS являются эффективными родовыми функциями, возможность применения которых зависит от специальных параметров, представляющих класс первого аргумента сообщения. Методы вызываются точно так же, как и функции LISP (т.е. не используются никакие функции отсылки, как это делается в LOOPS). Получатель сообщения представляется первым аргументом, а остальные'аргументы — обычные параметры функции.
Рис. 7.6. Стандартная схема наложения методов в языках CLOS и CLIPS ([Keene,1989])
Кроме того, в CLOS существуют и так называемые мультиметоды, которые позволяют настраивать поведение в зависимости от классов нескольких аргументов, а не одного. Например, люди, принадлежащие к разным культурам, не только отдают в своем рационе приоритет разным продуктам, но и готовят их по-разному. Так, японцы, в отличие от американцев, отдают предпочтение рыбе, но, кроме того, они часто едят рыбу сырой. Таким образом, метод prepare-meal (приготовить пищу) должен быть чувствителен как к национальности получателя сообщения, так и к виду предлагаемого блюда. Метод имеет два аргумента
(prepare-meal X Y)
и его реализация зависит как от класса аргумента X (повара), так и от класса аргумента У (блюда). Аналогичные возможности в CLIPS обеспечиваются посредством родовых функций (подробнее об этом — в главе 17).
7.3. Как сделать людей вежливыми
Положим, что используются те же обработчики сообщений для классов guaker и republican, что и в предыдущем примере. Можно, определив специальный заключительный метод для класса person, придать формируемым ответам вежливый вид. Этот метод будет выполняться после того, как будет выполнен основной метод, выбранный для ответа на сообщение speak:
(defmessage-handler guaker speak ()
(printout t crlf "Peace")
)
(defmessage-handler republican speak ()
(printout t crlf "War")
)
(defmessage-handler person speak after()
(printout t ", please" t crlf)
)
Теперь в ответ на запрос (send frichard] speak) последует ответ "War, please" Обработчики сообщений базовых классов имеют статус primary по умолчанию, а потому можно и не указывать это явно в объявлении обработчика, как это сделано, например, ниже:
(defmessage-handler republican speak primary () (printout t crlf "War")
7.3.3. Метаклассы в CLOS и CLIPS
В языке CLOS классы и метаклассы интегрированы в среду LISP. Фактически каждый объект LISP является экземпляром класса. Например, существует класс массивов array, соответствующий типу данных array в Common LISP.
В CLOS поддерживаются три базовых метакласса.
standard-class. Это метакласс по умолчанию для любого класса объектов, определенных пользователем с помощью функции defclass. Ниже приведено определение обычного класса father (отец), который имеет суперклассы man (мужчина) и parent (родитель), слоты для хранения имени (name) и рода занятий (occupation) экземпляров класса, а также краткого описания (documentation).
(defclass father (man parent) (:name)
(:occupation) (:documentation "Класс родителя мужского пола"))
Большинство классов, определенных пользователем, имеет именно этот метакласс.
build-in-class. Это метакласс тех классов объектов, которые реализованы необычным способом. Например, некоторые из таких классов могут соответствовать типам данных Common LISP. Большинство системных классов имеет именно этот метакласс.
structure-class. Это метакласс тех классов объектов, которые определены с помощью функции defstruct, а не defclass. Функция defstruct используется в Common LISP для формирования фреймов, состоящих из слотов и наполнителей, но не поддерживающих множественное наследование.
Хотя функциональные возможности базовых метаклассов вполне приемлемы для большинства приложений, программист может воспользоваться и опциями формирования специализированного standard-class, который будет обладать каким-нибудь экзотическим поведением. В частности, можно использовать meta-object protocols (протоколы мета-объектов) и переопределить родовой алгоритм диспетчирования. В результате у разработчика появляется возможность создать собственный механизм наследования, более приемлемый для конкретного приложения, чем стандартный. Нужно отметить, что подобного рода возможности отсутствуют в языках, подобных C++, правда, как показал опыт, большинство пользователей обращаются к ним очень редко.
Язык COOL, включенный в состав CLIPS, имеет 17 системных классов, причем некоторые из них выполняют функции метаклассов. Верхние уровни структуры классов схематически представлены на рис. 7.7.
Рис. 7.7. Верхние уровни иерархической системы классов языка COOL
Все классы, определенные пользователем, являются производными от USER, который отчасти выполняет функции метакласса. В нем реализованы практически все базовые обработчики сообщений инициализации и удаления объектов. Однако USER все-таки не является метаклассом, поскольку классы, определенные пользователем, — это производные от USER, а не его экземпляры. Initial-Object является экземпляром по умолчанию, который создается при выполнении функции def instaces. Класс Primitive и его подклассы реализуют основные структуры данных — числа, символы строки, адреса и многокомпонентные объекты. Все классы, представленные на рис. 7.7, кроме Initial-Object, являются абстрактными и служат только для определения родовых операций и структур данных
7.4. Множественное наследование в C++
Так же, как язык CLOS представляет собой объектно-ориентированное расширение языка LISP, так и язык C++ создан на основе широко известного языка С и сохранил все его возможности, добавив к ним средства объектно-ориентированного программирования. Если отвлечься от того факта, что CLOS и C++ основаны на разных языках-прототипах, то основное отличие между ними заключается в реализации механизма наследования, в частности множественного наследования. В языке C++ множественное наследование трактуется совсем не так, как мы это делали в предшествующих разделах настоящей главы, а потому этот вопрос заслуживает подробного обсуждения.
В языке C++ родовые операции реализуются в виде виртуальных функций. Виртуальная функция, объявленная в классе X, это функция, которая может быть перегружена (переопределена) в классе, производном от X. При объявлении в классе X виртуальная функция вообще может не иметь тела, т.е. программного кода реализации. В таком случае функция называется чисто виртуальной, а класс, имеющий одну или более чисто виртуальных функций, является абстрактным базовым классом, экземпляры которого создать невозможно. В любом случае ключевое слово virtual говорит компилятору, что программный код функции будет уточнен впроизводных классах.
Те методы, которые вызываются на выполнение, являются невиртуальными членами-функциями, т.е. функциями, имеющими определенный программный код, который не перегружается в производных классах. В этом смысле C++ существенно отличается от языка CLOS, в котором практически все функции суперкласса в большей или меньшей степени модифицируются механизмом наложения методов. Поэтому в C++ существует множество синтаксических тонкостей, в которых не нуждается CLOS. Например, во всех классах иерархии виртуальная функция должна иметь квалификатор virtual до тех пор, пока в некотором производном классе не будет представлена ее конкретная реализация.
В чисто иерархической структуре классов, когда каждый производный класс имеет единственного "родителя", передача методов по наследству выполняется совершенно очевидным способом. Единственная тонкость в реализации этого механизма в C++ состоит в использовании квалификаторов наследования public и private. Если не вдаваться в подробности, то наследование вида public представляет собой отношение "is а" (является), которое мы использовали при обсуждении фреймов. Наследование вида private ближе к отношению "реализовано в терминах", которое позволяет скрыть определенные детали реализации интерфейсов объектов. Такое полезное разделение "выпало" в языке CLOS, в котором каждое отношение "класс-подкласс" несет семантический смысл.
Но если обратиться к множественному наследованию, то механизмы его реализации в C++ и CLOS существенно отличаются. Поскольку в языке C++ не существует такого понятия, как порядок предшествования классов, то даже такой простой случай, как в рассмотренном выше примере "Алмаз Никсона", приводит к неоднозначности. Будем считать, что отношения между классами Person, Quaker, Republican и Republican_Quaker, как и прежде, имеют вид, представленный на рис. 7.8.
Объявление классов Person, Quaker, Republican и Republican Quaker на языке C++ показано в листинге 7.2 (программный код объявления включен в файл nixon.h).
Рис. 7.8. Отношения между классами в примере "Алмаз Никсона"
Листинг 7.2. Файл nixon.h. Объявление классов, версия 1
// Объявление классов для задачи "Алмаз Никсона" finclude
class Person
{ public:
Personf) {};
virtual "Person() {};
virtual void speak() = 0; };
class Republican : public Person
{ public:
Republican)) {};
virtual ~Republican)) {};
virtual void speak() { cout « "War";} };
class Quaker : public Person
{ public:
Quakerf) {};
virtual ~Quaker)) {};
virtual void speak)) { cout « "Peace";} };
class Republican_Quaker : public Republican,
public Quaker
{ public:
Republican_Quaker() {};
virtual ~Republican_Quaker() {};
};
Создадим экземпляр richard класса Republican_Quaker.
#include "nixon.h" void main))
Republican_Quaker richard; richard.speak));
При обработке этого программного кода компилятор C++ обнаружит, что вызов richard.speak)) содержит неоднозначную ссылку. Оно и понятно, поскольку нельзя однозначно заключить, скажет ли Ричард "War" (война) или "Peace" (мир).
Если мы решим, что метод speak)) класса Republican_Quaker должен "брать пример" с класса Quaker, то проблему можно решить, определив этот метод одним из двух способов:
void S::speak(){ cout << "Peace"; }
или
void S::speak)({Quaker::speak)); }
Первый вариант просто перегружает оба наследованных определения метода, а второй в явном виде вызывает один из них, а именно тот вариант, который реализован в классе Quaker.
Однако совершенно незначительное на первый взгляд изменение в файле определения классов может разительно изменить поведение объекта. Предположим, решено удалить объявления методов speak)) из всех классов, кроме Person, как это показано в листинге 7.3.
Листинг 7.3. Файл nixon.h. Объявление классов, версия 2
class Person
public:
Person)) {};
virtual "Person)) {};
virtual void speak)){ cout « "Beer";}
};
class Republican : public Person
public:
Republican)) {}; virtual ~Republican)) {};
class Quaker : public Person
public:
Quaker)) {};
virtual ~Quaker)) {};
class Republican Quaker : public Republican, public Quaker
{
public:
Republican_Quaker( ) {} ;
virtual ~Republican_Quaker( ) {};
}
При обработке такого файла определения компилятор опять выдаст сообщение о неоднозначности ссылки на метод speak ( ). Это произойдет по той причине, что компилятор сформирует две копии объявления класса Person — по одной для каждого пути наследования, а это приведет к конфликту имен. Чтобы устранить эту неоднозначность, нужно объявить Person как виртуальный базовый класс и для Republican, и для Quaker. Тогда оба производных класса будут ссылаться на единственный объект суперкласса (листинг 7.4).
Листинг 7.4. Файл nixon.h. Объявление классов, версия 3
class Person
{ public:
Per son () {};
virtual "Person)) {};
virtual void speak(){ cout << "Beer";} И
class Republican : virtual public Person
{ public:
Republican)) {};
virtual ~Republican)) {};
};
class Quaker : virtual public Person
{
public:
Quaker)) {};
virtual ~Quaker)) .{};
}
class Republican_Quaker : public Republican, public Quaker
{
public:
Republican_Quaker { ) { } ;
virtual "Republican_Quaker( ) {};
}
Объявление Person в качестве виртуального базового класса для Republican и Quaker имеет и еще одно преимущество. Предположим, что нам нужно сделать так, чтобы класс Republican_Quaker отдавал предпочтение стилю поведения квакеров, а все другие были индифферентны к вопросам войны и мира и следовали линии поведения, определенной классом Person. Тогда, поскольку Person является виртуальным базовым классом, можно заставить доминировать Quaker::speak)) над Person::speak)) для класса Republican_Quaker (листинг 7.5).
Листинг 7.5. Файл nixon.h. Объявление классов, версия 4
class Person
public:
Person)) {};
virtual ~Person)) {};
virtual void speak)){ cout « "Beer";}
class Republican : virtual public Person
public:
Republican)) {}; virtual ~Republican)) {};
class Quaker : virtual public Person
public:
Quaker)) {};
virtual ~Quaker() {};
virtual void speak)) { cout « "Peace";}
class Republican_Quaker : public Republican, public Quaker
public:
Republican_Quaker() {};
virtual "Republican_Quaker() {};
}
При создании языка C++ преследовалась цель не усложнять механизм множественного наследования по сравнению с единственным и разрешать все неоднозначности на стадии компиляции [Stromtrup, 1977]. В этом существенное различие между C++ и SmallTalk. В последнем такого рода конфликты разрешаются на стадии выполнения программы. Это также отличается и от метода, основанного на списке предшествования классов, который используется в CLOS. Кроме того, в языке CLOS конфликта имен, подобного тому, который мы наблюдали с классом Person, быть просто не может, поскольку все базовые классы с одинаковыми именами считаются идентичными.
Таким образом, за высокую эффективность языка C++ приходится платить, тщательно продумывая передачу свойств и поведения от классов родителей к производным классам с учетом всех нюансов функционирования механизма наследственности в C++.
В этом отношении C++ напоминает свой прототип — язык С, который требует гораздо более близкого знакомства с работой компьютера, чем язык LISP, поскольку позволяет напрямую обращаться к памяти компьютера, манипулировать адресами, формировать собственный механизм выделения памяти и т.д. Какую стратегию предпочесть — зависит от индивидуальных предпочтений разработчика, но если главным требованием к продукту является высокая производительность, то чем большими возможностями управления ресурсами обладает разработчик, тем лучше, тем более эффективную программу можно создать.
Суммируя все сказанное о языке C++, отметим, что он вполне может послужить базовым программным инструментом для создания экспертных систем. Если потребуется интерпретатор порождающих правил, то можно либо разработать его самостоятельно (хотя это и далеко не тривиальная задача), либо воспользоваться одним из имеющихся на рынке, которые допускают внедрение в среду C++. Если вам удастся избежать описанных выше сложностей в реализации множественного наследования, вы сможете в полной мере воспользоваться многочисленными преимуществами этого языка — проверкой статических типов, разделением между закрытым и общедоступным наследованием, множеством средств защиты данных от случайных изменений.
7.5. Объектно-ориентированный анализ и конструирование экспертных систем
Философия и технология объектно-ориентированного программирования могут весьма пригодиться проектировщику экспертных систем.
Философия представления знаний о реальном мире в терминах взаимодействия объектов и субъектов предоставляет достаточно удобную среду для решения большого класса проблем, предполагающих значительный объем моделирования (задачи планирования и составления расписаний).
Методика представления абстрактных данных и процедур позволяет программистам, занятым задачами искусственного интеллекта, на ранних этапах разработки сосредоточиться на выборе подходящих видов объектов и их поведении, не вдаваясь в подробности реализации функций и структур данных.
Существует довольно много литературы по объектно-ориентированному программированию, которая поможет конструктору экспертных систем.
Но существуют и определенные сложности внедрения объектно-ориентированного подхода в область задач искусственного интеллекта.
Объекты в основном являются средствами реализации вычислений.
Идея наследования поведения вленет за собой появление множества проблем при ее реализации, как мы видели это на примере с классами окон. Некоторые из появившихся в последнее время объектно-ориентированных схем допускают наследование только интерфейсов.
Определенные сложности возникают с реализацией наследования при использовании новых технологий многокомпонентных объектов, таких как СОМ (см. [Chappell, 1996]).
В идеальном случае желательно так организовать разработку системы, особенно экспертной, чтобы добавление новых возможностей сводилось к включению в систему новых модулей программного кода. Приведенные в этой главе примеры показывают, что это вряд ли возможно даже при использовании объектно-ориентированной среды. Добавление новых модулей знаний всегда связано с побочными эффектами, которые вовлекают в свою орбиту правила разрешения конфликтов и неопределенностей. В дальнейшем мы покажем, что эта проблема характерна и для технологии логического программирования (об этом речь пойдет в главе 8).
Таким образом, совершенно очевидно, что реализация идей объектно-ориентированного программирования не позволяет решить все проблемы и разработчику экспертной системы будет еще над чем поломать голову. Но объектно-центрическая парадигма упрощает принятие определенных видов решений в процессе проектирования системы и облегчает реализацию уже принятых.
Рекомендуемая литература
Для ознакомления с общими концепциями объектно-ориентированных вычислений и их практической реализацией я бы рекомендовал статьи из сборника [Peterson, 1987]. Обзор работ по объектно-ориентированной технологии применительно к задачам искусственного интеллекта читатель найдет в [Stefik and Bobrow, 1986]. В работе [Кеепе, 1989] довольно подробно описан язык CLOS.
Подробное описание C++ и методики программирования на этом языке содержится в книгах [Booch, 1994] и [Meyers, 1995], [Meyers, 1997], хотя я и не в восторге от двух последних.
Упражнения
1. Чем отличаются объектно-ориентированные языки программирования от обычных процедурных языков?
2. В чем состоит отличие между конкретными и абстрактными классами?
3. Почему при множественном наследовании иерархическая структура превращается в гетерархическую?
4. В чем состоит проблема наложения методов при множественном наследовании?
5. Что такое метакласс и в чем польза применения такой конструкции?
6. Что понимается под термином "список предшествования классов"? 7. Рассмотрите схему отношений между классами на рис. 7.9.
Используя конструкцию def class языка CLIPS, опишите эту структуру классов таким образом, чтобы соблюдался следующий порядок наследования в классах, имеющих несколько суперклассов:
wkg-man: (man worker) father: (parent man)
wkg-woman: (worker woman) mother: (parent woman)
wkg-father: (wkg-man father)
wkg-raother: (mother wrk-woman)
Начните с класса person:
(defclass person (is-a USER) (role concrete))
Какой вид будет иметь список предшествования классов wkg-father и wkg-mother?
Рис. 7.9. Схема структуры классов для упражнения 7
8. Предположим, что классы на рис. 7.9 имеют следующие предпочтения при выборе блюд на завтрак:
man: donut woman:
croissant parent:
fruit worker: bacon
Закодируйте данные предпочтения в обработчиках сообщений этих классов таким образом, чтобы класс-получатель сообщения вернул наименование того блюда, которое он предпочитает.
Сформируйте следующие экземпляры классов:
Joan — экземпляр класса wrk-mother,
Jim — экземпляр класса wrk-man.
Передайте им сообщение, например, в такой форме:
(send [Joan] breakfast)
Чем ответят экземпляры Joan и Jim на такое сообщение и почему?
ГЛАВА 8. Логическое программирование
8.1. Формальные языки
8.1.1. Исчисление высказываний
8.1.2. Исчисление предикатов
8.2. Язык PROLOG
8.3. Опровержение резолюций
8.3.1. Принцип резолюций
8.3.2. Поиск доказательства в системе резолюций
8.4. Процедурная дедукция в системе PLANNER
8.5. PROLOG и MBASE
8.5.1. Правила поиска в языке PROLOG
8.5.2. Управление поиском в системе MBASE
Рекомендуемая литература
Упражнения
ГЛАВА 8. Логическое программирование
8.1. Формальные языки
8.2. Язык PROLOG
8.3. Опровержение резолюций
8.4. Процедурная дедукция в системе PLANNER
8.5. PROLOG и MBASE
Рекомендуемая литература
Упражнения
Еще в конце 1970-х годов стала отчетливо просматриваться тенденция к использованию в исследованиях в области искусственного интеллекта "формальных" методов, т.е. основанных на аппарате математической логики. Эти методы противопоставлялись более интуитивным и менее формализованным эвристическим методам, скажем, таким, которые были использованы в системе MYCIN. Для того чтобы стало ясно, что все это значит, нужно познакомить вас с логическими языками, а затем показать, как соотносятся их свойства с теми методами рассуждений, которые должны поддерживать типовые экспертные системы.
8.1. Формальные языки
Математическая логика является формальным языком в том смысле, что в отношении любой последовательности символов она позволяет сказать, удовлетворяет ли эта последовательность правилам конструирования выражений в этом языке (формулам). Обычно формальным языкам противопоставляются естественные, такие как французский и английский, в которых грамматические правила не являются жесткими. Утверждение, что логика является исчислением с определенными синтаксическими правилами логического вывода, означает, что влияние одних членов выражения на другие зависит только от формы выражения в данном языке и ни коим образом не зависит от каких-либо посторонних идей или интуитивных предположений.
Под автоматическим формированием суждений (automated reasoning) понимается поведение некоторой компьютерной программы, которая строит логический вывод на основании определенных законов. Так, нельзя отнести к классу программ автоматического формирования суждений программу, которая моделирует подбрасывание монетки, чтобы определить, следует ли одна формула из набора других. (В литературе также часто встречается термин автоматическая дедукция (automated deduction), равнозначный по смыслу термину автоматическое формирование суждений.)
При реализации автоматического формирования суждений, как правило, стремятся к максимально возможному единообразию и стандартизации в представлении формул, но в то же время в литературе часто приходится сталкиваться с самыми разнообразными системами обозначений, относящихся к логике. Основными синтаксическими схемами представления выражений являются конъюнктивная нормальная форма (conjunctive normal form— CNF), полная фразовая форма (full clausal form) и фраза Хорна (Horn clause), последняя является подмножеством полной фразовой формы. Далее мы увидим, что эти формы представления значительно упрощают процедуру логического вывода, но сначала рассмотрим некоторые вопросы исчисления высказываний и предикатов.
8.1.1. Исчисление высказываний
Исчисление высказываний представляет собой логику неанализируемых предположений, в которой пропозициональные константы могут рассматриваться как представляющие определенные простые выражения вроде "Сократ — мужчина" и "Сократ смертен". Строчные литеры р, q, r, ... в дальнейшем будут использоваться для обозначения пропозициональных констант, которые иногда называют атомарными формулами, или атомами.
Ниже приведены все синтаксические правила, которые используются для конструирования правильно построенных формул (ППФ) в исчислении высказываний.
(S. U) ЕслиU является атомом, то у является ППФ.
(S¬) Если U является ППФ, то —U также является ППФ.
(S. v) Если U и ф являются ППФ, то (U u ф) также является ППФ.
В этих правилах строчные буквы греческого алфавита (например, U и ф) представляют пропозициональные переменные, т.е. не атомарные формулы, а любое простое или составное высказывание. Пропозициональные константы являются частью языка высказываний, который используется для приложения исчисления пропозициональных переменных к конкретной проблеме.
Выражение -U читается как "не U", а (U v ф) читается как дизъюнкция "U или ф (или оба)". Можно ввести другие логические константы — "л" (конъюнкция), "D" (импликация, или обусловленность), "=" (эквивалентность, или равнозначность), которые, по существу, являются сокращениями комбинации трех приведенных выше констант. .
(U ^ ф) Эквивалентно¬(¬U v ф). Читается "U и ф".
(U ф) Эквивалентно (¬U v ф). Читается "U имплицирует ф".
(U==ф) Эквивалентно (Uф)^(фU). Читается "U эквивалентно ф".
В конъюнктивной нормальной форме исчисления высказываний константы "импликация" и "эквивалентность" заменяются константами "отрицание" и "дизъюнкция", а затем отрицание сложного выражения раскрывается с помощью формул Де Моргана:
¬(U^ф) преобразуется в (¬Uv¬ф), ¬(U v ф) преобразуется в (-U^ф) , ¬¬U преобразуется в U .
Последний этап преобразований — внесение дизъюнкций внутрь скобок: (£ v (U ^ф))) заменяется ((£vU\(U)^(£vф)).
Принято сокращать вложенность скобочных форм, отбрасывая в нормальной конъюнктивной форме знаки операций v и л. Ниже представлен пример преобразования выражения, содержащего импликацию двух скобочных форм, в нормальную конъюнктивную форму.
¬(pvq)(-p^A-q) Исходное выражение.
¬¬(pvg)v(-p^- q) Исключение~.
(pvq)v(-p^- q) Ввод - внутрь скобок.
(¬pv(pvq))v(¬pv(pvq)) Занесение v внутрь скобок.
{{-p, р, q}, {¬q, р, q} } Отбрасывание А и v в конъюнктивной нормальной форме.
Выражения во внутренних скобках — это либо атомарные формулы, либо негативные атомарные формулы. Выражения такого типа называются литералами, причем с точки зрения формальной логики порядок литералов не имеет значения. Следовательно, для представления множества литералов — фразы — можно позаимствовать из теории множеств фигурные скобки. Литералы в одной и той же фразе неявно объединяются дизъюнкцией, а фразы, заключенные в фигурные скобки, неявно объединяются конъюнкцией.
Фразовая форма очень похожа на конъюнктивную нормальную форму, за исключением того, что позитивные и негативные литералы в каждой дизъюнкции группируются вместе по разные стороны от символа стрелки, а затем символ отрицания отбрасывается. Например, приведенное выше выражение
преобразуется в две фразы:
p,q<¬q.
в которых позитивные литералы сгруппированы слева от знака стрелки, а негативные справа.
Более строго, фраза представляет собой выражение вида
в котором p1..., рт q1,..., qn являются атомарными формулами, причем т=>0 и п=>0. Атомы в множестве р1,..., рт представляют заключения, объединенные операторами дизъюнкции, а атомы в множестве q1 ..., qn — условия, объединенные операторами конъюнкции.
8.1.2. Исчисление предикатов
Исчисление высказываний имеет определенные ограничения. Оно не позволяет оперировать с обобщенными утверждениями вроде "Все люди смертны". Конечно, можно обозначить такое утверждение некоторой пропозициональной константой р, а другой константой q обозначить утверждение "Сократ — человек". Но из (р л q) нельзя вывести утверждение "Сократ смертен".
Для этого нужно анализировать пропозициональные символы в форме предикатов и аргументов, кванторов и квантифщированных переменных. Логика предикатов предоставляет нам набор синтаксических правил, позволяющих выполнить такой анализ, набор семантических правил, с помощью которых интерпретируются эти выражения, и теорию доказательств, которая позволяет вывести правильные формулы, используя синтаксические правила дедукции. Предикатами обозначаются свойства, такие как "быть человеком", и отношения, такие как быть "выше, чем".
Аргументы могут быть отдельными константами, или составным выражением "функция-аргумент", которое обозначает сущности некоторого мира интересующих нас объектов, или отдельными квантифицируемыми переменными, которые определены в этом пространстве объектов. Специальные операторы — кванторы — используются для связывания переменных и ограничения области их интерпретации. Стандартными являются кванторы общности (V) и существования (3). Первый интерпретируется как "все", а второй — "кое-кто" (или "кое-что").
Ниже приведены синтаксические правила исчисления предикатов первого порядка.
Любой символ (константа или переменная) является термом. Если rk является символом k-местной функции и а1 ...,
(S 40
Если Tk является символом k-местного предиката
и а1 ..., ak являются термами,
то U(а1 ..., ak) является правильно построенной формулой (ППФ).
(S. -) и (S. v)
Правила заимствуются из исчисления высказывании.
(S. V) Если U является ППФ и % является переменной,
то (любой Х) U является ППФ.
Для обозначения используются следующие символы:
U — произвольный предикат;
Г — произвольная функция;
a — произвольный терм;
X — произвольная переменная.
Действительные имена, символы функций и предикатов являются элементами языка первого порядка.
Использование квантора существования позволяет преобразовать термы с квантором общности в соответствии с определением
(EX)U определено как -(любой X)-U.
Выражение (EХ)(ФИЛОСОФ(Х)) читается как "Кое-кто является философом", а выражение (любой Х)(ФИЛОСОФ(Х)) читается как "Любой является философом". Выражение ФИЛОСОФ(Х) представляет собой правильно построенную формулу, но это не предложение, поскольку область интерпретации для переменной X не определена каким-либо квантором. Формулы, в которых все упомянутые переменные имеют определенные области интерпретации, называются замкнутыми формулами.
Как и в исчислении высказываний, в исчислении предикатов существует нормальная форма представления выражений, но для построения такой нормальной формы используется расширенный набор правил синтаксических преобразований. Ниже приведена последовательность применения таких правил. Для приведения любого выражения к нормальной форме следует выполнить следующие операции.
(1) Исключить операторы эквивалентности, а затем импликации.
(2) Используя правила Де Моргана и правила замещения (E X)U на -(любой X)-U (а следовательно, и (любой X) U на -(E X)-U), выполнить приведение отрицания.
(3) Выполнить приведение переменных. При этом следует учитывать особенности определения области интерпретации переменных кванторами. Например, в выражении (E Х)(ФИЛОСОФ(Х))&(E Х)(АТЛЕТ(Х)) переменные могут иметь разные интерпретации в одной и той же области. Поэтому вынесение квантора за скобки — (E Х)(ФИЛОСОФ(Х))&.(АТЛЕТ(Х))— даст выражение, которое не следует из исходной формулы.
(4) Исключить кванторы существования. Кванторы существования, которые появляются вне области интерпретации любого квантора общности, можно заменить произвольным именем (его называют константой Сколема), в то время как экзистенциальные переменные, которые могут существовать внутри области интерпретации одного или более кванторов общности, могут быть заменены функциями Сколема. Функция Сколема— это функция с произвольным именем, которая имеет следующий смысл: "значение данной переменной есть некоторая функция от значений, присвоенных универсальным переменным, в области интерпретации которых она лежит".
(5) Преобразование в префиксную форму. На этом шаге все оставшиеся кванторы (останутся только кванторы общности) переносятся "в голову" выражения и таким образом оказываются слева в списке квантифицированных переменных. За ними следует матрица, в которой отсутствуют кванторы.
(6) Разнести операторы дизъюнкции и конъюнкции.
(7) Отбросить кванторы общности. Теперь все свободные переменные являются неявно универсально квантифицированными переменными. Экзистенциальные переменные станут либо константами, либо функциями универсальных переменных.
(8) Как и ранее, отбросить операторы конъюнкций, оставив множество фраз.
(9) Снова переименовать переменные, чтобы одни и те же имена не встречались в разных фразах.
8.1. Снова о роботах и комнатах
В главе 3 мы уже упоминали об исчислении предикатов в упрощенном виде. Там выражение вида
at(робот, комнатаА)
означало, что робот находится в комнате А. Термы робот и комнатаА в этом выражении представляли собой константы, которые описывали определенные реальные объекты. Но что будет означать выражение вида
at(X, комнатаА) ,
в котором х является переменной? Означает ли оно, что нечто находится в комнате А? Если это так, то говорят, что переменная имеет экзистенциальную подстановку (импорт). А может быть, выражение означает, что все объекты находятся в комнате А? В таком случае переменная имеет универсальную подстановку. Таким образом, отсутствие набора четких правил не позволяет однозначно интерпретировать приведенную формулу.
Перечисленные в этом разделе правила исчисления предикатов обеспечивают однозначную интерпретацию выражений, содержащих переменные.
В частности, фраза
at(X, комнатаА )<—at (X, ящик1) интерпретируется как
"для всех X X находится в комнате А, если X находится в ящике 1". В этой фразе переменная имеет универсальную подстановку. Аналогично, фраза
at(X, комнатаА) <-интерпретируется как "для всех X X находится в комнате А". А вот фраза
<— at(X, комнатаА) интерпретируется как "для всех XX не находится в комнате А".
Иными словами, это не тот случай, когда некоторый объект X находится в комнате А и, следовательно, переменная имеет экзистенциальную подстановку.
Теперь можно преобразовать фразовую форму, в которой позитивные литералы сгруппированы слева от знака стрелки, а негативные — справа. Если фраза в форме
P1, ..., Рт <— q1,...qn содержит переменные х1,..., хk, то правильная интерпретация имеет следующий вид:
для всех x1, ..., хk
p1 или ... или pm является истинным, если q1 и ... и qn являются истинными.
Если п = 0, т.е. отсутствует хотя бы одно условие, то выражение будет интерпретироваться следующим образом:
для всех x1, ..., xk
p1 или ... или рт является истинным.
Если т = 0, т.е. отсутствуют термы заключения, то выражение будет интерпретироваться следующим образом:
для всех x1, ..., xk
не имеет значения, что q1 и ... и qn являются истинными.
Если же т = п = 0, то мы имеем дело с пустой фразой, которая всегда интерпретируется как ложная.
8.2. Язык PROLOG
Фразы Хорна (Horn clause) представляют собой подмножество фраз, содержащих только один позитивный литерал. В общем виде фраза Хорна представляется выражением
В языке PROLOG эта же фраза записывается в таком виде (обратите внимание на символ точки в конце):
р :- q1,...,qn. Такая фраза интерпретируется следующим образом:
"Для всех значений переменных в фразе p истинно, если истинны q1 и ... и qn",
т.е. пара символов ":-" читается как "если", а запятые читаются как "и".
PROLOG — это не совсем обычный язык программирования, в котором программа состоит в основном из логических формул, а процесс выполнения программы представляет собой доказательство теоремы определенного вида.
Фраза в форме
р :- q1, ...,qn.
может рассматриваться в качестве процедуры. Такая процедура предполагает следующий порядок выполнения операций.
(1) Литерал цели сопоставляется с литералом р (унифицируется с р), который называется головой фразы.
(2)Хвост фразы ql, ...,qn конкретизируется подстановкой значений переменных (или унификаторов), сформированных в результате этого сопоставления.
(3) Конкретизированные термы хвостовой части образуют затем множество подцелей, которые могут быть использованы другими процедурами.
Таким образом, сопоставление (или унификация) играет ту же роль, что и передача параметров функции в других, более привычных языках программирования.
Например, рассмотрим набор фраз языка PROLOG, представленных в листинге 8.1. Предположим, что a, b и с — какие-то блоки в мире блоков. Две первые фразы утверждают, что а находится на (on) b, a b находится на (on) с. Третья фраза утверждает, что X находится выше (above) Y, если X находится на (on) Y. Четвертая фраза утверждает, что X находится выше (above) Y, если существует какой-то другой блок Z, размещенный на (on) Y, и X находится выше (above) Y.
Листинг 8.1. Простая программа на языке PROLOG, определяющая отношение on (на)
on(а, b).
on(b, с).
above(X, Y) :- on(X, Y).
above(X, Y) :- on(Z, Y),
above(X, Z).
Очевидно, что от программы требуется вывести цель above (а, с) из этого множества фраз. Как это делается, мы увидим в разделе 8.3.2, но уже сейчас можно сказать, что процесс формулировки выражения цели включает обработку двух процедур above и использование двух фраз on.
8.3. Опровержение резолюций
В языке PROLOG используется "интерпретация фраз Хорна для решения проблем" (см. [Kowalski, 1979, р. 88-89]). Фундаментальный метод доказательства теорем, на котором базируется PROLOG, называется опровержением резолюций (resolution refutation). Полное описание этого метода читатель найдет в книге Робинсона [Robinson, 1979], а в этом разделе мы попытаемся кратко изложить только основные идеи.
8.3.1. Принцип резолюций
Ранее я уже вскользь упоминал о том, что мы стараемся упростить синтаксис исчисления таким образом, чтобы уменьшить количество правил влияния, необходимое для доказательства теорем. Вместо дюжины.или более правил, которые используются при доказательстве теорем вручную, системы автоматического доказательства для фразовых форм используют единственное правило вывода — принцип резолюций, — впервые описанное Робинсоном ([Robinson, 1965]).
Рассмотрим следующий пример из исчисления высказываний. В дальнейшем прописными буквами Р, Q, R,... будут обозначаться отдельные фразы, а строчными греческими U, ф и £ — пропозициональные переменные, как и раньше.
Если U и ф представляют две произвольные фразы, которые можно представить в конъюнктивной нормальной форме, и
U={ U1, ..., Ui, ...., Um},
и
ф= {ф1..., фi.....,фn}, и
Ui, = ¬фi при 1[i[mm,1 [j [ n,
то новую фразу £ можно вывести из объединения U' и ф', где
U' = U¬{ Ui} и ф' = ф¬{ф,}.
Фраза £ = U' и ф' называется резольвентой шага резолюции, а U и ф являются родительскими фразами. Иногда говорят, что U и ф "сталкиваются" на паре дополняющих литералов Ui , и фj.
Мощность резолюции обеспечивается тем, что в ней суммируется множество других правил. Это станет очевидно после того, как обычные правила будут представлены в конъюнктивной нормальной форме.
В левой колонке табл. 8.1 перечислены наименования правил вывода, в средней показано, как они выглядят в обычных обозначениях, а в правой колонке — во фразовой форме. В каждой записи выражения в верхней части представляют схему предпосылок, а выражения в нижней части — схему заключений. Из этой таблицы видно, что каждое из цитированных выше пяти правил является одним из экземпляров резолюции!
Таблица 8.1. Обобщение резолюции
Правило вывода
Обычная форма
Конъюнктивная нормальная форма
Modus ponens
(Uф,U)/Ф
{¬U,Ф},{U}/{ф}
Modus fallens
(Uф.¬ф)/-U
{¬U,ф},{-,ф}/{-U}
Сцепление
(Uф,ф£)(U£)
{¬U,ф},{¬ф,£}/{¬U,£}
Слияние
(Uф,¬U ф)/ф
{U,ф},{¬U,ф}/{ф}
Reductio
(U,¬U)/ |
{¬U},{U}/{}
Обратите внимание на то, что противоречие в правиле, которое обычно обозначается значком 1, дает в результате пустую фразу— {}. Это означает, что предпосылки несовместимы. Если считать, что предпосылки описывают некоторое состояние предметной области, то такой набор предпосылок не может быть реально обеспечен в ней, т.е. такое состояние невозможно.
Главное, что нужно вынести из всего сказанного выше, что компонент автоматического доказательства теорем, который является основным компонентом большинства систем искусственного интеллекта и, в частности, языков программирования искусственного интеллекта, таких как PROLOG, является системой, опровержения резолюций. Для того чтобы доказать, что р следует из некоторого описания состояния (или теории) Т, нужно положить —р и попытаться доказать, что из этого предположения следует утверждение, противоречащее Т. Если это удастся сделать, то тем самым подтверждается утверждение р, а в противном случае оно опровергается.
В исчислении предикатов использование резолюций требует дополнительных усилий, поскольку в этом исчислении присутствуют переменные. Основная операция сопоставления в доказательстве теорем с помощью резолюций называется унификацией (подробное описание используемого при этом алгоритма читатель найдет, например, в работе Нильсона [Nilsson, 1980]). При сопоставлении дополняющих литералов отыскивается такая подстановка переменных, которая превращает оба выражения в идентичные.
Например, выражения БЕЖИТ_БЫСТРЕЕ_ЧЕМ(Х, улитка) и БЕЖИТ_БЫСТРЕЕ _ЧЕМ (черепаха, Y) превращаются в идентичные при подстановке {Х/черепаха, Y/улитка}. Такая подстановка называется унификатором. Наша цель — отыскать наиболее общую подстановку такого рода.
8.3.2. Поиск доказательства в системе резолюций
Резолюция представляет собой правило вывода, с помощью которого можно вывести новую ППФ (правильно построенную формулу) из старой. Однако в приведенном выше описании логической системы ничего не говорилось о том, как выполнить доказательство. В этом разделе мы обратим основное внимание на стратегические аспекты доказательства теорем.
Пусть р представляет утверждение "Сократ — это человек", a q — утверждение "Сократ смертен". Пусть наша теория имеет вид
Т={{¬р,q}, {р}}.
Таким образом, утверждается, что если Сократ человек, то Сократ смертен, и что Сократ — человек. {17} выводится из теории Т за один шаг резолюции, эквивалентной правилу modus ponens. .
Выражения {¬р, q} и {р} "сталкиваются" на паре дополняющих литералов р и ¬р, а {q} является резольвентой. Таким образом, теория Алогически подразумевает д, что записывается в форме Т|-q. Теперь можно добавить новую фразу {q} — резольвенту — в теорию Т и получить таким образом теорию
Т'= {{ ¬ip, q}, {p}, {q}}.
Конечно, в большинстве случаев для доказательства требуется множество шагов. Положим, например, что теория Т имеет вид
В этой теории р и q сохраняют прежний смысл, а г представляет утверждение "Сократ — бог". Для того чтобы показать, что Т|- ¬r , потребуются два шага резолюции:
{¬q,p},{Р}/{q}
{¬q,-r},{q} / {-r}
Обратите внимание, что на первом шаге используются две фразы из исходного множества Т, а на втором— резольвента {q}, добавленная к Т. Кроме того, следует отметить, что доказательство может быть выполнено и по-другому, например:
{¬p,q},{¬q,¬r}/{¬p,¬r},
{¬p,¬r},{p}/{¬r}
При таком способе доказательства к Т добавляется другая резольвента. В связи со сказанным возникает ряд проблем.
Когда множество Т велико, естественно предположить, что должно существовать несколько способов вывести интересующую нас конкретную формулу (эта формула является целевой). Естественно, что предпочтение следует отдать тому методу, который позволяет быстрее сформулировать доказательство.
Множество Т может поддерживать и те правила, которые не имеют ничего общего с доказательством целевой формулы. Как же заранее узнать, какие правила приведут нас к цели?
Потенциально весь процесс подвержен опасности комбинаторного взрыва. На каждом шаге множество Г растет, и в нашем распоряжении оказывается все больше и больше возможных путей продолжения процесса, причем некоторые из них могут привести в зацикливанию.
Та схема логического вывода, которой мы следовали до сих пор, обычно называется прямой, или восходящей стратегией. Мы начинаем с того, что нам известно, и строим логические суждения в направлении к тому, что пытаемся доказать. Один из возможных способов преодоления сформулированных выше проблем — попытаться действовать в обратном направлении: от сформулированной целевой формулы к фактам, которые нужны нам для доказательства истинности этой формулы.
Предположим, перед нами стоит задача вывести {q} из некоторого множества фраз
Т= {...,{ ¬p, q},...}.
Создается впечатление, что это множество нужно преобразовать, отыскивая фразы, включающие q в качестве литерала, а затем попытаться устранить другие литералы, если таковые найдутся. Но фраза {q} не "сталкивается" с такой фразой, как, например, { —р, q}, поскольку пара, состоящая из одинаковых литералов q, не является взаимно дополняющей.
Если q является целью, то метод опровержения резолюции реализуется добавлением негативной формулы цели к множеству Т, а затем нужно показать, что формула
Т' = Т U {¬q}
является несовместной. Полагая, что множество Т непротиворечиво, приходим к выводу, что Т' может быть противоречивым вследствие Т |- q.
Рассмотрим этот вопрос более подробно. Сначала к существующему множеству фраз добавляется отрицание проверяемой фразы {-q}. Затем предпринимается попытка резольвиро-вать {-q} с другой фразой в Т. При этом существуют только три возможные ситуации.
В Т не существует фразы, содержащей q. В этом случае доказать искомое невозможно.
Множество Т содержит {q}. В этом случае доказательство выполняется немедленно, поскольку из {¬q} и {q} можно вывести пустую фразу, что означает несовместность (наличие противоречия).
Множество Т содержит фразу {..., q, ...}. Резольвирование этой фразы с {¬q} формирует новую фразу, которая содержит остальные литералы, причем для доказательства противоречия все они должны быть удалены в процессе резольвирования.
Эти оставшиеся литералы можно рассматривать в качестве подцелей, которые должны быть разрешены, если требуется достичь главной цели. Описанная стратегия получила название нисходящей (или обратной) и очень напоминает формулирование подцелей в системе MYCIN.
В качестве примера положим, что множество Т, как и ранее, имеет вид {{¬p,q},{¬q,¬r},{p}}. Мы пытаемся показать, что Т|- ¬r. Для этого докажем, что фраза {r} является следствием существующего множества Т, для чего добавим к этому множеству отрицание фразы ¬r. Поиск противоречия происходит следующим образом:
[{¬q,¬r},{r}]/{¬q}
[{¬p,q},{¬q}]/{¬q}
[{¬p},{p}]/{}
Этот метод доказ_ательства теорем получил название "опровержение резолюции", поскольку, во-первых, он использует правило вывода резолюций, а во-вторых, следует стратегии "от противного" (стратегии опровержения).
Теперь вернемся к примеру PROLOG-программы, представленному в листинге 8.1. На рис. 8.1 показано дерево доказательства утверждения above(a, с). Дерево строится сверху вниз, и каждая ветвь связывает две "родительские фразы", в которых содержатся дополняющие литералы, с фразой, которая образуется в результате применения правила резолюции. Ко всем целям, записанным справа от значка ":-", неявно применяется отрицание. В левой части дерева представлены формулы целей, а в правой — фразы, взятые из базы данных.
Корнем дерева является пустая фраза {}. Это означает, что поиск доказательства был успешным. Добавление негативной фразы :- above (а, с) к исходному множеству (теории) привело к противоречию. Таким образом, можно утверждать, что фраза above (а, с) является логическим следствием из этой теории.
Обратите внимание на роль операции унификации в этом доказательстве. Цель above (а, с) унифицируется с головной фразой above(X, Y) с помощью подстановки {Х/а, Y/c}, где выражение Х/а можно интерпретировать как "X получает значение а". Затем эта подстановка применяется к хвостовой части фразы
on(Z, Y), above(X, Z),
из чего следует формулировка подцелей
on(Z, с), above(a, Z).
Следующая подцель on(Z, с) унифицируется с on(b, с) подстановкой {Z/b}. Эта подстановка затем применяется и к оставшейся подцели, которая таким образом превращается в above (а, b), и так до тех пор, пока не образуется пустая фраза.
Рис. 8.1. Дерево доказательства методом опровержения резолюций
Восходящий процесс доказательства, использующий в качестве отправной точки утверждение, которое мы стараемся доказать, позволяет сфокусировать внимание на процессе поиска решения, поскольку анализируемые логические связи по крайней мере потенциально ведут нас к цели. Правда, основанный на этой стратегии метод опровержения резолюций не позволяет решить все перечисленные выше проблемы. В частности, этот метод не гарантирует, что найденный путь доказательства будет короче других (или длиннее).
В следующих двух разделах мы рассмотрим эволюцию процедурных дедуктивных систем, т.е. систем, в которых процедуры используются для добавления дополнительных управляющих свойств в процесс целенаправленного поиска и для представления знаний, которые не имеют четко выраженного декларативного характера.
Процесс становления этого класса систем весьма поучителен, поскольку демонстрирует, как, отталкиваясь от стандартной логики и добавляя методики, обычно используемые при доказательстве теорем, можно построить успешно функционирующую автоматическую систему доказательства.
8.4. Процедурная дедукция в системе PLANNER
Система PLANNER явилась одной из первых попыток разработки языка программирования задач искусственного интеллекта, базирующегося на идеях автоматического доказательства теорем. Хотя разработчикам и не удалось в полной мере реализовать задуманное, созданное подмножество языка, получившего название Micro-PLANNER, нашло применение в системах планирования, в частности в программе SHRDLU, представленной в главе 2. Ниже мы обсудим те аспекты системы PLANNER, которые имеют отношение к представлению знаний.
Система PLANNER моделировала состояние некоторой области рассуждений в терминах ассоциативной базы данных, которая содержала как утверждения, так и теоремы, функционирующие как процедуры. Утверждения представляли собой списки типа "предикат-аргумент", подобные тем, что используются в LISP. Например:
(BLOCK B1) (ON Bl TABLE)
Теоремы же в действительности представляли собой выражения, в которых можно было проследить влияние одних термов на другие. Например, теорема
(ANTE (BLOCK X) (ASSERT (ON X TABLE)))
в действительности является процедурой, которая говорит: "Если утверждается, что X это блок, то также утверждается, что X находится на столе". Таким образом, если существует утверждение (BLOCK B1), то можно также считать утверждением и выражение (ON Bl TABLE). Функция ASSERT добавляет собственный конкретизированный аргумент (т.е. аргумент, которому присвоено определенное значение) в базу данных.
Выше был приведен пример антецедентной теоремы. Это название акцентирует внимание на том, что нас интересует только логическая связь между антецедентом и консек-вентом (по аналогии с правилом modus ponens), а не связь между отрицанием консеквен-та и отрицанием антецедента (по аналогии с правилом modus fallens). Мы говорим, что в действительности эта теорема является процедурой, поскольку в ней содержится управляющая информация. Ее функционирование во многом напоминает демонов в системе фреймов, описанных в главе 6.
Система PLANNER поддерживает и другой вид процедур, которые получили наименование консеквентной теоремы. Пример процедуры такого типа приведен ниже:
(CONSE (MORTAL X) (GOAL (MAN X))).
Эта процедура может быть прочитана так: "Для того чтобы показать, что Xсмертен, покажите, что X — человек". Если выражение, которое нужно доказать (цель), сформулировано в виде (MORTAL SOCRATES) (Сократ смертен), то в качестве подцели будет выступать выражение (MAN SOCRATES) (Сократ человек). Функция GOAL организует поиск в базе данных собственного конкретизированного аргумента. Однако не удастся использовать эту теорему для перехода от утверждения (MAN SOCRATES) (Сократ человек) к утверждению (MORTAL SOCRATES) (Сократ смертен).
Консеквентные теоремы могут также манипулировать базой данных. Например, для того чтобы положить блок В1, на котором ничего не стоит, на блок В2, на котором также ничего не стоит, нужно отыскать, на чем же стоит блок В1, удалить соответствующее утверждение и сформировать новое, которое говорит, что блок В1 стоит на блоке В2.
(CONSE (ON X Y)
(GOAL (CLEAR X)) (GOAL (CLEAR Y))
(ERASE (ON X Z)) (ASSERT (ON X Y)))
Задавшись целью (ON Bl B2), если на Bl и на В2 ничего не стоит, PLANNER выполнит необходимые операции с базой данных. Таким образом, консеквентная теорема поддерживает в системах автоматизации планирования работу механизма реализации операторов, подобных тем, которые мы видели в программе STRIPS (см. главу 3).
Из этого краткого описания читатель может сделать заключение, что в системе PLANNER управляющая информация явно представлена в базе данных процедур, а не скрывается в компоненте, ведающем стратегией выполнения доказательства теорем, как это делается в системах, работающих на основе метода опровержения резолюций. Достоинство такого подхода состоит в том, что можно решить в каждом конкретном случае, какие правила влияния следует применять. Кроме того, в нашем распоряжении оказывается довольно эффективный инструмент моделирования изменения состояния задачи.
С концепцией процедурной дедукции связана проблема полноты. Система доказательства является полной, если все тавтологии, т.е. тривиально истинные выражения вроде (р v —pi), могут быть выведены в ней как теоремы. В системе PLANNER это свойство отсутствует. Мы уже обращали внимание на то, что нельзя сформировать выражение (MORTAL SOCRATES) из базы данных, в которой содержатся
(MAN SOCRATES)
(CONSE (MORTAL X)
(GOAL (MAN X))).
Это те издержки, с которыми нужно смириться, если мы хотим объединить управляющую информацию с пропозициональным представлением. К сожалению, система PLANNER оказалась не более эффективной, чем системы, основанные на теоремах резолюций. Это произошло потому, что использованная в ней управляющая информация страдает "близорукостью", отсутствует общая стратегия, а имеющийся набор теорем позволяет формулировать локальные решения, которые могут давать, а могут и не давать желаемый эффект. Отсутствует в PLANNER и возможность каким-то образом формировать суждения о механизме управления, что-то вроде метаправил, о которых шла речь в главе 5.
В следующем разделе мы кратко остановимся на системах, в которых была предпринята попытка устранить эти недостатки
8.5. PROLOG и MBASE
Ранее мы уже видели, что фразу, содержащую предположение, можно представить с помощью исчисления предикатов первого порядка. Фраза
"Если философ выиграет у кого-нибудь в забеге, то этот человек будет им восхищен" в формализме предикатов приобретет вид формулы
(любой A) (любой Y)(PHILOSOPHER(X)^BEATS(X, Y)ADMJRE(Y, X)).
Эту формулу можно представить в конъюнктивной нормальной форме следующим образом:
{ADMIRE(Y, X), -ВЕАТS(Х, Y), ->PHILOSOPHER(X)}.
Также было показано, что если записать это выражение таким образом, чтобы слева от оператора ":-" стоял единственный позитивный литерал, а справа — негативные литералы, то получится выражение, представляющее фразу Хорна в синтаксисе языка логического программирования PROLOG:
admire (Y, X) :- philosopher ( X) , beats (X,Y).
Ниже мы рассмотрим, как организовать управление применением таких правил.
8.5.1. Правила поиска в языке PROLOG
Существует аналогия между выражениями вида
admire(Y, X) :- philosopher (X) , beats (X,Y)
в языке PROLOG и консеквентной теоремой в системе PLANNER. При запросе "who admires whom?" ("кто кем восхищается?"), который может быть представлен в виде фразы
:- admire(V, W). ,
приведенное выше выражение интерпретируется следующим образом: "Для того чтобы показать, что Y восхищается X, покажите, что X является философом, а затем покажите, что X обогнал Y".
Цель, которая унифицируется с выражением admire(Y, X), может быть истолкована как вызов процедуры, а процесс унификации может рассматриваться как механизм передачи действительных параметров другим литералам, образующим тело процедуры. В данном случае не имеет значения, являются ли эти "параметры" переменными, как в представленном примере. Подцели в теле процедуры упорядочены. В языке PROLOG такое упорядочение называется правилом поиска слева направо.
В PLANNER и ранних системах, основанных на методе резолюций, цель легко достигается, если в базе данных содержатся утверждения
philosopher (zeno) . beats (zeno, achilles).
Тогда получим ответ
admire (achilles, zeno).
Если в базе данных содержится другая информация, касающаяся искомой цели, то программе может потребоваться выполнить обратный просмотр (backtrack), прежде чем добраться до цели. Обратный просмотр используется в том случае, когда нужно отменить присвоение значений переменным, выполненное при обработке некоторой подцели, поскольку это присвоение приводит к неудаче в обработке поздней подцели. Положим, что база данных содержит дополнительную фразу
philosopher ( socrates ) .
В этом случае, если эта формула отыщется прежде, чем формула
philosopher(zeno).,
обработка следующей подцели приведет к неудаче, а следовательно, нужно будет поискать другого философа. Объем работы, который придется выполнить системе в процессе достижения цели admire(V, W), зависит от количества альтернативных вариантов утверждений, касающихся философов, которые имеются в базе данных.
Предположим, что в базе данных содержатся факты еще о ста философах, т.е. в ней имеются сто других выражений в формате philosopher(X), в которых X отличается от zeno. Тогда в худшем случае программе потребуется 100 раз выполнить обратный просмотр, прежде чем будет найдено именно то утверждение, которое согласуется с целью.
База данных может содержать и другие правила, которые взаимодействуют с интересующим нас выражением admire (V, W). Например, можно положить, что утверждение "X обогнал Y" представляет транзитивное отношение. В этом случае в нашем распоряжении будет правило
beats(X, Y) :- beats(X, Z), beatsf Z, Y).
Можно также дать такое определение понятию "философ", что таковым будет считаться только тот, кого хотя бы однажды обогнала черепаха:
philosopher(X) :- beats(Y, X), tortoise(Y).
Наличие этих правил очень усложнит пространство поиска и значительно увеличит количество случаев, когда придется выполнять обратный просмотр.
В следующем разделе описано одно из расширений языка PROLOG— система MBASE, на базе которой реализована программа МЕСНО для решения задач вузовского курса теоретической механики
8.5.2. Управление поиском в системе MBASE
Один из распространенных способов управления поиском в применении к доказательству какого-либо утверждения — тщательное упорядочение базы данных. При поиске нужных фактов или правил исполнительная система языка PROLOG просматривает базу данных от начала до конца. Используя это обстоятельство, можно несколько сократить время доказательства.
Определенные факты (основные атомы — ground atoms) нужно разместить в базе данных раньше, чем правила, которые в качестве цели имеют соответствующие предикаты. Таким образом будут минимизированы издержки обращения к правилам. Например, утверждение
beats(achilles, zeno).
должно стоять раньше правила
beats(X, Y) :- beats(X, Z), beats( Z, Y).
Исключения из общих правил также должны располагаться в базе данных раньше, чем сами общие правила. Например, правило, утверждающее, что пингвины не летают,
flies(X) :- penguin(X), !, fail .
должно стоять раньше общего правила, гласящего, что птицы летают,
flies(X) :- bird(X).
Литерал fail представляет собой один из способов выражения отрицания в языке PROLOG. Кроме того, в языке PROLOG имеется литерал !, который называется "отсечением". Этот литерал говорит исполнительной системе PROLOG, что не нужно осуществлять возврат из этой точки. Комбинация литералов представляет эффективный механизм управления обратным просмотром, предотвращая выполнение ненужных операций.
Предположения по умолчанию реализуются включением неосновных атомов в самый конец базы знаний. Например, если желательно, чтобы по умолчанию квакеры считались пацифистами, то фраза
pacifist(X) :- quaker(X).
должна появиться после всех фраз вида
pacifist(nixon) :- !, fail.
В случае, если при просмотре базы знаний не будет найдено утверждение об обратном, касающееся конкретного квакера, то на него распространится утверждение, справедливое для всех остальных.
Общее правило гласит, что сначала в базе данных следует располагать данные об особых случаях, т.е. определенные факты и исключения, затем данные об общих случаях, например правила влияния, и последними должны располагаться сведения о свойствах по умолчанию.
Все эти требования соблюдены в системе MBASE, но, кроме того, еще существует и возможность управления глубиной поиска. В этой системе существуют литералы, задающие один из трех имеющихся режимов поиска.
Обращение к базе данных (DBC — database call). Этот режим ограничивает зону поиска только основными литералами в базе данных и таким образом исключает применение правил. Для настройки этого режима нужно включить основной литерал в предикат ВВС. Например, факт, что b1 является блоком, будет представлен фразой
DBC(block(b1)).
Тогда для некоторой фразы Р при обработке подцелей в форме DBC (Р) будет просматриваться только указанная часть базы данных.
Описанная выше комбинация литералов отсечения и неудачи также может использоваться в сочетании с предикатом DBC. Таким образом, формируется своего рода "ловушка", прекращающая поиск цели, которая не может быть найдена. Например, можно таким способом прекратить попытки доказать, что блок одновременно находится в двух местах:
at(Block, Placel) :-
DEC(at(Block, Place2)), different(Placel, Place2), !, fail.
Обратите внимание на то, что если бы в теле процедуры отсутствовал предикат ВВС, то программа очень быстро зациклилась.
Вызов правил влияния (DBINF — inference call) — это обычный режим работы исполнительной системы PROLOG с использованием всех имеющихся правил. При этом соблюдаются соглашения о порядке поиска в базе сверху вниз, а в правиле слева направо.
Порождающий вызов (СС — creative call). В этом режиме формируются место-держатели для неизвестных и выполняются вычисления в тех случаях, когда обычный режим может привести к неудаче. Режим используется для математических вычислений, когда отсутствуют значения всех переменных в уравнении.
С помощью литералов 1 и fail обычно определяется отрицание определенной процедуры, например, так:
not(P) :- call(P) !, fail. not(P) .
В языке PROLOG специальный предикат call обрабатывает цель, переданную ему в качестве параметра. Идея состоит в том, что если такая обработка приведет к успеху, то отрицание цели приведет к неудаче, а литерал отсечения предотвратит обратный просмотр. В противном случае мы перейдем ко второй фразе, и отрицание цели очевидно приведет к успеху.
Некоторые из проблем полноты, отмеченные в системе PLANNER, существуют и в языке PROLOG. В частности, использование литералов отсечения и неудачи может серьезно сказаться на полноте и согласованности фактов и правил. Существует множество способов внедрения отрицаний в логику фразы Хорна, но условия, при которых это можно сделать, весьма ограничены (см., например, [Shepherdson, 1984], [Shepherdson, 1985]).
Тем не менее исследователи пришли к выводу, что описанный выше механизм управления далеко не всегда может привести процесс вычислений к искомому заключению, поскольку не обладает достаточной "глобальностью". Проблема состоит в том, что все описанные методы базируются все-таки на довольно ограниченных, локальных знаниях о текущем состоянии процесса вычислений. В MBASE была предпринята попытка дополнить локальное управление двумя механизмами— схематизацией (schemata) и мета-предикатами. О них-то и пойдет речь ниже.
Под схематизацией подразумеваются ассоциативные механизмы, которые используются в основном для представления в компьютере знаний общего характера. Например, ниже приведено представление знаний о системе подъема грузов на основе ворота (pulley system):
sysinfo(pullsys,
[Pull, Str, P1, P2],
[pulley, string, solid, solid]
[ supports(Pull, Str),
attached(Str, Pi),
attached(Str, P2) ]).
Предикат sysinfo принимает четыре аргумента, каждый из которых аналогичен слоту в системе фреймов (см. об этом в главе 6):
первый аргумент, pullsys, свидетельствует о том, что эта схема представляет типовую систему подъема грузов с воротом и, таким образом, аналогичен слоту наименования;
второй аргумент, [Pull, Str, P1, P2], является перечнем деталей в этом механизме — ворот, трос и два груза;
третий аргумент, [pulley, string, solid, solid], содержит информацию о типе этих компонентов;
четвертый аргумент содержит список отношений (связей) между компонентами.
Обратите внимание на то, что в этом представлении нет никакой пропозиционально-сти, например сведений о том, каким способом можно неявно сопоставить два списка. По существу, это представление очень похоже на описание фрейма (но вряд ли с ним можно работать так же эффективно).
Описанная схематизация представляет только один из использованных в МЕСНО способов организации фоновой информации, которая нужна программе. Имеются и другие типы структур, которые помогают выбрать подходящие формулы для определения характеристических параметров той или иной моделируемой системы. Например, выражение
kind(al, accel, relaccel(...)).
означает, что al является параметром типа accel (ускорение), который определен в утверждении relaccel, т.е. в контексте относительных ускорений. Другое выражение
relates(accel, [resolve, constaccel, relaccel)).
означает, что формулы resolve, constaccel и relaccel содержат переменные типа accel и, следовательно, могут быть использованы для вычисления ускорения. Приведенные выражения можно рассматривать как один из видов дополнительного индексирования в ассоциативной сети. В данном случае индексирование представлено в форме логики, причем используются структуры, обычно редко встречающиеся в исчислении предикатов первого порядка.
Роль метапредикатов состоит в отборе правил, наиболее подходящих для вывода конкретной цели. Рассмотрим следующий пример:
solve(U, Exprl, Ans) :-
occur)U, Exprl, 2), collect(U, Exprl, Expr2), isolate(U, Expr2, Ans).
Эта процедура означает, что Ans является уравнением, которое решается относительно неизвестного U в выражении Exprl, если
в выражение Exprl неизвестная U входит дважды:
выражение Ехрг2 представляет собой Exprl, в котором выполнено приведение неизвестной U;
Ans является выражением Ехрг2, в котором неизвестная U вынесена в левую часть.
В данном случае метапредикат solve указывает способ преобразования уравнения к виду, который позволит разрешить его относительно неизвестного. Метапредикаты используются для того, чтобы формировать суждения о том, как формировать суждения, и в этом подобны метаправилам в продукционных системах.
Некоторые примеры использования системы МЕСНО демонстрируют, что методика логического программирования во многом сходна с программированием на обычных языках. Однако при создании приложений, которые требуют обработки обширного набора структурированных фактов, подчиняющихся определенным физическим законам (анализ электрических цепей или сложных механических систем), единственным подходящим языком часто оказывается PROLOG. Этот же язык может быть использован и для описания теорий, затрагивающих такие общие категории, как пространство, время, допустимость и обязательность, в которых существуют общие принципы, допускающие декларативное представление, и в которых не требуется глубокий поиск.
В главе 23 мы увидим, что, несмотря на существование определенных проблем при использовании концепций логического программирования и основанного на них языка PROLOG, эта концепция имеет приложение в двух других областях исследований, которые представляют интерес с точки зрения экспертных систем, а именно: обобщение на базе объяснения (explanation-based generalization) и логический вывод на метауровне (meta-level inference). Обобщение на базе объяснения используется для машинного обучения, а логический вывод на метауровне позволяет программе строить суждения о собственном поведении.
Рекомендуемая литература
Четкое изложение основных концепций теории доказательств в математической логике читатель найдет в работе Эндрюса [Andrews, 1986]. Я также рекомендую познакомиться с книгой [Quine, 1979] — переизданием классического труда, опубликованного впервые еще в 1940 году. Достаточно обширное введение в проблематику автоматического формирования суждений содержится в книге Робинсона [Robinson, 1979].
Более популярное изложение этого материала с упором на проблематику искусственного интеллекта можно найти в работе [Genesereth andNilsson, 1987, Chapters 1-5]. Обсуждение проблем математической логики в контексте искусственного интеллекта содержится в статье Хейеса и Мичи [Hayes and Michie, 1984]. Новой работой в этой области является книга Гинзберга [Ginsberg, 1993]
Упражнения
1. Выразите с помощью логики предикатов следующие утверждения.
I) Каждый студент использует какой-нибудь компьютер, и по крайней мере один компьютер используется каждым студентом. (Используйте только предикаты СТУДЕНТ, КОМПЬЮТЕР и ИСПОЛЬЗУЕТ.)
II) Каждый год некоторые студенты-мужчины проваливают каждый экзамен, но каждый студент-женщина сдает какой-нибудь экзамен. (Используйте только предикаты СТУДЕНТ, МУЖЧИНА, ЖЕНЩИНА, СДАЕТ, ЭКЗАМЕН, ГОД.)
Ill) Каждый мужчина любит какую-нибудь женщину, которая любит другого мужчину. (Используйте только предикаты МУЖЧИНА, ЖЕНЩИНА, ЛЮБИТ и = .)
IV) Не существует двух философов, которые любили бы одну и ту же книгу. (Используйте только предикаты ФИЛОСОФ, КНИГА, ЛЮБИТ и = .)
2. Выразите предложения упр. 1 в форме фразы.
3. Имеет ли смысл выразить следующие цитаты с помощью логики предикатов? Покажите, в чем состоит сложность такого преобразования в каждом конкретном случае.
I) Ни один человек не является островом. (Джон Донн (John Donne))
II) Человек, который живет где-нибудь, живет везде. (Тацит)
III) Прошлое — это иная страна. В нем все происходит по-другому. (Л. П. Хартли (L. P. Hartley))
4. Следующая формула утверждает, что кто-то бреет себя сам или парикмахер бреет кого-то:
бреет) X, X), бреет (парикмахер, X) <—
I) Используя обратную стратегию, покажите, что из этой формулы следует
бреет (парикмахер, парикмахер) <-
II) То же самое покажите с помощью прямой стратегии.
III) Как вы понимаете в том же контексте следующую фразу:
<- бреет(У, Y), бреет (парикмахер, У)
IV) Покажите, что следующие фразы противоречивы. Для этого достаточно показать, что из них следует пустая фраза:
бреет(Х, X), бреет (парикмахер, X)
<-<- бреет(У, Y), бреет (парикмахер, Y)
5. Ниже представлены правило поиска неисправности и описание конкретной ситуации.
Если компьютер не включается и напряжение в сети питания в норме, то оборван шнур питания или неисправен блок питания. Мой компьютер не включается. Напряжение в сети питания в норме. Шнур питания не оборван.
I) Выразите эти предложения в форме логики предикатов.
II) Постройте конъюнктивную нормальную форму.
III) Используя прямую стратегию доказательства, покажите, что утверждение "Неисправен блок питания" логически вытекает из приведенного набора фактов. То же самое покажите с использованием обратной стратегии доказательства.
6. Предположим, что в синтаксисе языка PROLOG цель сформулирована следующим образом :- bachelor (f red).
I) К какому заключению придет приведенная ниже PROLOG-программа относительно семейного положения человека по имени Fred?
man(fred).
man(george).
wife(george, georgina).
bachelor(X) :- not(wife(X, Y)).
not(P) :- call(P), !, fail.
not(P).
II) К какому заключению придет приведенная ниже PROLOG-программа?
man(fred).
man(george).
wife(george, georgina).
bachelor(X) :- not(wife(X, Y)).
(wife(X, Y) :- !, fail.
(wifeffred, freda).
7. Предположим, что в синтаксисе языка PROLOG цель сформулирована следующим образом :- enemy(fred).
I) К какому заключению придет приведенная ниже MBASE-программа относительно человека по имени Fred?
DBC(friend (george)).
republican(fred).
enemy(X) :- not(DBC(friend(X))).
friend(X)) :- republican(X).
not(P) :- call(P), !, fail.
not(P).
II) К какому заключению придет приведенная ниже MBASE-программа?
DBC(friend (george)).
enemy(X) :- not(DBC(friend(X))). friend(X))
:- not(communist(X)). not(P)
:- call(P), !, fail. not(P).
8. Ниже приведена программа на языке PROLOG, в которой идентифицируется подмножество лиц, имеющих право работать в службе обеспечения общественного порядка штата Нью-Йорк. Вы можете ввести эту программу в исполнительную систему PROLOG и поэкспериментировать с ней.
Затем попробуйте добавить в программу новое правило, касающееся еще одной категории служащих.
Деревенские констебли, назначенные с условием, что это не противоречит законам штата.
Данные для тестирования этого правила включены в раздел фактов программы.
/ Правила для сотрудников службы общественного порядка /
/ Шериф и заместитель шерифа округа Нью-Йорк /
/ The sheriff and deputy sheriff of NYC /
po(X) :-
(sheriff(X) ; deputy(X)), jurisdiction(X, nyc).
/ Сотрудники службы охраны порядка
округа Уэстчестер, принятые на
работу после 1982 года, которые
выполняют функции, ранее возлагавшиеся
на шерифа округа Уэстчестер /
/ Officers of Westchester country
public safety services appointed
after 1982 who perform functions
previously performed by a Westchester
country sheriff on or prior to such date /
po(X) :-
safetyOfficer(X), jurisdiction(X, Westchester),
appointed(X, Date), Date > 1982.
/ ФАКТЫ /
/ Wayne, Doug, Ken и Pete - некоторые лица. /.
sheriff(wayne).
jurisdiction(wayne, nyc).
deputy(doug), jurisdictionfdoug, nyc).
constable(ken), jurisdiction(ken, naples).
village(naples). RuledOut(constable, naples).
safetyOfficer(pete) jurisdiction(pete, Westchester).
appointed(pete, 1990).
9. Запишите программу из упр. 8 на языке CLIPS. Сравните оба варианта программы.
ГЛАВА 9. Представление неопределенности знаний и данных
9.1. Источники неопределенности
9.2. Экспертные системы и теория вероятностей
9.2.1. Условная вероятность
9.2.2. Коэффициенты уверенности
9.2.3. Коэффициенты уверенности и условные вероятности
9.3. Сомнительность и возможность
9.3.1. Нечеткие множества
9.3.2. Нечеткая логика
9.3.3. Теория возможности
9.4. Неопределенное состояние проблемы неопределенности
Рекомендуемая литература
Упражнения
ГЛАВА 9. Представление неопределенности знаний и данных
9.1. Источники неопределенности
9.2. Экспертные системы и теория вероятностей
9.3. Сомнительность и возможность
9.4. Неопределенное состояние проблемы неопределенности Рекомендуемая литература
Упражнения
Во многих реальных приложениях приходится сталкиваться с ситуацией, когда автоматический решатель задач имеет дело с неточной информацией. В этой главе мы рассмотрим основные идеи, касающиеся количественной оценки неопределенности и методов формирования нечетких суждений. В главах 11-15 будет продемонстрировано, как такие методы используются на практике. В настоящей главе речь пойдет в основном о теоретических аспектах представления неопределенности и о том, почему в исследованиях по искусственному интеллекту такое большое внимание уделяется этим проблемам. В главе 21 мы вновь вернемся к проблеме неопределенности и рассмотрим ее более глубоко, но для большинства читателей вполне достаточно будет и тех сведений, которые представлены в данной главе.
9.1. Источники неопределенности
При решении проблем мы часто встречаемся со множеством источников неопределенности используемой информации, но в большинстве случаев их можно разделить на две категории: недостаточно полное знание предметной области и недостаточная информация о конкретной ситуации.
Теория предметной области (т.е. наши знания об этой области) может быть неясной или неполной: в ней могут использоваться недостаточно четко сформулированные концепции или недостаточно изученные явления. Например, в диагностике психических заболеваний существует несколько отличающихся теорий о происхождении и симптоматике шизофрении.
Неопределенность знаний приводит к тому, что правила влияния даже в простых случаях не всегда дают корректные результаты. Располагая неполным знанием, мы не можем уверенно предсказать, какой эффект даст то или иное действие. Например, терапия, использующая новые препараты, довольно часто дает совершенно неожиданные результаты. И, наконец, даже когда мы располагаем достаточно полной теорией предметной области, эксперт может посчитать, что эффективнее использовать не точные, а эвристические методы. Так, методика устранения неисправности в электронном блоке путем замены подозрительных узлов оказывается значительно более эффективной, чем скрупулезный анализ цепей в поиске детали, вышедшей из строя.
Но помимо неточных знаний, неопределенность может быть внесена и неточными или ненадежными данными о конкретной ситуации. Любой сенсор имеет ограниченную разрешающую способность и отнюдь не стопроцентную надежность. При составлении отчетов могут быть допущены ошибки или в них могут попасть недостоверные сведения. На практике далеко не всегда можно получить полные ответы на поставленные вопросы и хотя можно воспользоваться различного рода дополнительной информацией о пациенте, например с помощью дорогостоящих процедур или хирургическим путем, такие методики используются крайне редко из-за высокой стоимости и рискованности. Помимо всего прочего, существует еще и фактор времени. Не всегда есть возможность быстро получить необходимые данные, когда ситуация требует принятия срочного решения. Если работа ядерного реактора вызывает подозрение, вряд ли кто-нибудь будет ждать окончания всего комплекса проверок, прежде чем принимать решение о его остановке.
Суммируя все сказанное, отметим, что эксперты пользуются неточными методами по двум главным причинам:
точных методов не существует;
точные методы существуют, но не могут быть применены на практике из-за отсутствия необходимого объема данных или невозможности их накопления по соображениям стоимости, риска или из-за отсутствия времени на сбор необходимой информации.
Большинство исследователей, занимающихся проблемами искусственного интеллек: та, давно пришли к единому мнению, что неточные методы играют важную роль в разработке экспертных систем, но много споров вызывает вопрос, какие именно методы должны использоваться. До последнего времени многие соглашались с утверждениями Мак-Карти и Хейеса, чт.о теория вероятности не является адекватным инструментом для решения задач представления неопределенности знаний и данных [McCarthy and Hayes, 1969]. Выдвигались следующие аргументы в пользу такого мнения:
теория вероятности не дает ответа на вопрос, как комбинировать вероятности с количественными данными (см. об этом в главе 8);
назначение вероятности определенным событиям требует информации, которой мы просто не располагаем.
Другие исследователи прибавляли к этим аргументам свои:
непонятно, как количественно оценивать такие часто встречающиеся на практике понятия, как "в большинстве случаев", "в редких случаях", или такие приблизительные оценки, как "старый" или "высокий";
применение теории вероятности требует "слишком много чисел", что вынуждает инженеров давать точные оценки тем параметрам, которые они не могут оценить;
обновление вероятностных оценок обходится очень дорого, поскольку требует большого объема вычислений.
Все эти соображения породили новый формальный аппарат для работы с неопределенностями, который получил название нечеткая логика (fuzzy logic) или теория функций доверия (belieffunctions). Этот аппарат широко используется при решении задач искусственного интеллекта и особенно при построении экспертных систем. Нечеткая логика будет рассмотрена ниже в этой главе, а о теории функций доверия (ее также называют теорией признаков Демпстера— Шафера) мы поговорим в главе 21. Однако в последние годы адвокаты теории вероятностей предприняли довольно эффективную контратаку, а потому мы также представим читателям основные концепции этой теории и ее главных конкурентов, а обзор дальнейшего развития работ в этом направлении отложим до следующей главы
9.2. Экспертные системы и теория вероятностей
В этом разделе будут рассмотрены те аспекты теории вероятностей, которые имеют отношение к представлению неопределенностей. Мы начнем с понятия условной вероятности и остановимся на тех причинах, по которым вероятностный подход критикуется большинством исследователей, занимающихся экспертными системами. Затем мы вернемся к коэффициентам уверенности, которые обсуждались в главе 3 в связи с системой MYCIN, рассмотрим их подробнее и сравним результаты, которые получаются при использовании этого аппарата и аппарата теории вероятностей.
9.2.1. Условная вероятность
Условная вероятность события d при данном s — это вероятность того, что событие d наступит при условии, что наступило событие s. Например, вероятность того, что пациент действительно страдает заболеванием d, если у него (или у нее) обнаружен только симптом s.
В традиционной теории вероятностей для вычисления условной вероятности события d при данном s используется следующая формула:
P(d|s)=(d^ s)/P(S) (9.1)
Как видно, условная вероятность определяется в терминах совместимости событий. Она представляет собой отношение вероятности совпадения событий d и s к вероятности появления события s. Из формулы (9.1) следует, что
P(d^s)=P(d|s)P(d).
Если разделить обе части на P(s) и подставить в правую часть (9.1), то получим правило Байеса в простейшем виде:
P(d|s)=(s|d)P(d)/P(S) (9.2)
Это правило, которое иногда называют инверсной формулой для условной вероятности, позволяет определить вероятность P(d | s) появления события d при условии, что произошло событие s через известную условную вероятность P(s | d). В полученном выражении P(d) — априорная вероятность наступления события d, a P(d | s) — апостериорная вероятность, т.е. вероятность того, что событие d произойдет, если известно, что событие s свершилось.
Для систем, основанных на знаниях, формула (9.2) гораздо удобнее формулы (9.1), в чем вы сможете убедиться в дальнейшем.
Предположим, что у пациента имеется некоторый симптом заболевания, например боль в груди, и желательно знать, какова вероятность того, что этот симптом является следствием определенного заболевания, например инфаркта миокарда или перикардита (воспаление каверн в легких), или чего-нибудь менее серьезного, вроде несварения желудка. Для того чтобы вычислить вероятность Р(инфаркт миокарда боль в груди) по формуле (9.1), нужно знать (или оценить каким-либо способом), сколько человек в мире страдают таким заболеванием и сколько человек и больны инфарктом миокарда, и жалуются на боль в груди (т.е. имеют такой же симптом). Как правило, такая информация отсутствует, особенно последняя, которая нужна для вычисления вероятности Р (инфаркт миокарда л боль в груди). Таким образом, определение, данное формулой (9.1), в клинической практике не может быть использовано.
Отмеченная сложность получения нужной информации явилась причиной негативного отношения многих специалистов по искусственному интеллекту к вероятностному подходу вообще (см., например, [Charniak and McDermott, 1985, Chapter 8]). Это негативное отношение подкреплялось тем, что в большинстве классических работ по теории вероятностей понятие вероятности определялось как объективная частотность (частота появления при достаточно продолжительных независимых испытаниях).
Однако существует мнение, что эти базовые предположения небесспорны с точки зрения практических приложений (см., например, [Pearl, 1982] и [Cheeseman, 1985]). Сторонники такого подхода придерживаются субъективистской точки зрения на определение вероятности, который позволяет иметь дело с оценками совместного появления событий, а не с действительной частотой. Такой взгляд на вещи связывает вероятность смеси событий с субъективной верой в то, что событие действительно наступит.
Например, врач может не знать или не иметь возможности вычислить, какая часть пациентов, жалующихся на боль в груди, страдает инфарктом миокарда, но на основании собственного опыта он может оценить, у какой части его пациентов, страдающих этим заболеванием, встречался такой симптом. Следовательно, он может оценить значение вероятности Р(боль в груди | инфаркт миокарда). Субъективный взгляд на природу вероятности тесно связан с правилом Байеса по следующей причине. Предположим, мы располагаем достаточно достоверной оценкой вероятности P(s | а), где 5 означает симптом, a d— заболевание. Тогда по формуле (9.2) можно вычислить вероятность P(d\ s). Оценку вероятности P(d) можно взять из публикуемой медицинской статистики, а оценить значение P(s) врач может на основании собственных наблюдений.
Вычисление P(d | s) не вызывает затруднений, когда речь идет о единственном симптоме, т.е. имеется множество заболеваний D и множество симптомов S, причем для каждого члена из D нужно вычислить условную вероятность того, что у пациентов, страдающих этим заболеванием, наблюдался один определенный симптом из множества S. Тем не менее, если в множестве D имеется т членов, а в множестве S— п членов, потребуется вычислить тп + т + п оценок вероятностей. Это отнюдь не простая работа, еcли в системе медицинской диагностики используется до 2000 видов заболеваний и огромное число самых разнообразных симптомов.
Но ситуация значительно усложняется, если мы попробуем включить в процесс составления диагноза не один симптом, а несколько.
В более общей форме правило Байеса имеет вид
P(d|s1^...^sk )= P(s1^...^sk|d)P(d)/P(s1^...^sk) (9.3)
и требует вычисления (mn)k + m + nk оценок вероятностей, что даже при небольшом значении А; очень много. Эти оценки вероятностей требуются нам по той причине, что в общем случае для вычисления P(s1 ^ ....^ sk) нужно предварительно вычислить произведения вида
P(s1 | s2 ^.. .^sk )P(s2 | s3 ^.. .^sK )... P(sk ) .
Однако, если предположить, что некоторые симптомы независимы друг от друга, объем вычислений существенно снижается. Независимость любой пары симптомов Si, и Sj означает, что
P(Si)=P(Sl|Sj),
из чего следует соотношение
P(Si^Sj)=P(Si)P(Sj).
Если все симптомы независимы, то объем вычислений будет таким же, как и в случае учета при диагнозе единственного симптома.
Но, даже если это и не так, в большинстве случаев можно предположить наличие условной независимости. Это означает, что пара симптомов s\ и Sj является независимой, поскольку в нашем распоряжении имеются какие-либо дополнительные свидетельства на этот счет или фундаментальные знания Е. Таким образом,
P(Si|Sj,E)=P(Si|E).
Например, если в моем автомобиле нет горючего и не работает освещение, я могу смело сказать, что эти симптомы независимы, поскольку моих познаний в устройстве автомобиля вполне достаточно, чтобы предположить, что между ними нет никакой причинной связи. Но если автомобиль не заводится и не работает освещение, то заявлять, что эти симптомы независимы, нельзя, поскольку они могут быть следствием одной и той же неисправности аккумуляторной батареи. Степень доверия к симптому "не работает освещение" только увеличится, если обнаружится, что к тому же и двигатель не заводится. Необходимость отслеживать такого рода связи в программе и соответственно корректировать степень доверия к симптомам значительно увеличивает объем вычислений в общем случае (см. об этом в работе [Cooper, 1990]).
Таким образом, использование теории вероятности ставит перед нами следующие проблемы, которые лучше всего сформулировать в терминах задачи выбора:
либо априори предполагается, что все данные независимы, и использовать менее трудоемкие методы вычислений, за что придется платить снижением достоверности результатов;
либо нужно организовать отслеживание зависимости между используемыми данными, количественно оценить эту зависимость, реализовать оперативное обновление соответствующей нормативной информации, т.е. усложнить вычисления, но получить более достоверные результаты.
В главе 19 представлен обзор символических методов отслеживания зависимости между используемыми данными, а в главе 21 описаны некоторые численные методы моделирования зависимости между вероятностями.
В следующем разделе мы рассмотрим альтернативный подход, с помощью которого удается обойти указанные сложности при построении экспертных систем. Здесь же, а также в главе 21 будут проанализированы критические замечания, касающиеся этого подхода.
9.2.2. Коэффициенты уверенности
Теперь мы вернемся к коэффициентам уверенности, о которых уже шла речь в главе 3, когда мы рассматривали принципы работы системы MYCIN.
В идеальном мире можно вычислить вероятность P(di| E), где di — i-я диагностическая категория, а £ представляет все необходимые дополнительные свидетельства или фундаментальные знания, используя только вероятности P(di | Sj), где Sj является j-м клиническим наблюдением (симптомом). Мы уже имели возможность убедиться в том, что правило Байеса позволяет выполнить такие вычисления только в том случае, если, во-первых, доступны все значения P(sj | di), и, во-вторых, правдоподобно предположение о взаимной независимости симптомов.
В системе MYCIN применен альтернативный подход на основе правил влияния, которые следующим образом связывают имеющиеся данные (свидетельства) с гипотезой решения:
ЕСЛИ
пациент имеет показания и симптомы s1 ^ ...^ sk и имеют место определенные фоновые условия t1 ^ ... ^ fm ,
ТО
можно с уверенностью т заключить, что пациент страдает заболеванием di.
Коэффициент-уверенности t принимает значения в диапазоне [-1,+ 1]. Если т = +1, то это означает, что при соблюдении всех оговоренных условий составитель правила абсолютно уверен в правильности заключения di, а если т = -1, то значит, что при соблюдении всех оговоренных условий существует абсолютная уверенность в ошибочности этого заключения. Отличные от +1 положительные значения коэффициента указывают на степень уверенности в правильности заключения di, а отрицательные значения — на степень уверенности в его ошибочности.
Основная идея состоит в том, чтобы с помощью порождающих правил такого вида попытаться заменить вычисление P(di | s1 ^ ... ^ sk) приближенной оценкой и таким образом сымитировать процесс принятия решения экспертом-человеком. Как было показано в главе 3, результаты применения правил такого вида связываются с коэффициентом уверенности окончательного заключения с помощью CF(a) — коэффициент уверенности в достоверности значения параметра а, а дополнительные условия t1 ^ ... ^ tm представляют фоновые знания, которые ограничивают применение конкретного правила. Чаще всего оказывается, что эти условия могут быть интерпретированы значениями "истина" или "ложь", т.е. соответствующие коэффициенты принимают значение +1 или -1. Таким образом, отличные от единицы значения коэффициентов характеризуют только симптомы s1, ... , sk. Роль фоновых знаний состоит в том, чтобы разрешить или запретить применение правила в данном конкретном случае. Пусть, например, имеется диагностическое правило, связывающее появление болей в брюшной полости с возможной беременностью. Применение этого правила блокируется фоновым знанием, что оно справедливо только по отношению к пациентам-женщинам.
Бучанан и Шортлифф утверждают, что, строго говоря, применение правила Байеса в любом случае не позволяет получить точные значения, поскольку используемые условные вероятности субъективны [Buchanan and Shortliffe, 1984, Chapter 11]. Как мы уже видели, это основной аргумент против применения вероятностного подхода. Однако такая аргументация предполагает объективистскую интерпретацию понятия вероятности, т.е. предполагается, что "правильные" значения все же существуют, но мы не можем их получить, а раз так, то и правило Байеса нельзя использовать. Этот аргумент имеет явно схоластический оттенок, поскольку любая экспертиза, проводимая инженером по знаниям, совершенно очевидно сводится к представлению тех знаний о предметной области, которыми обладает человек-эксперт (эти знания, конечно же, являются субъективными), а не к воссозданию абсолютно адекватной модели мира. С точки зрения теории представляется, что целесообразнее использовать математически корректный формализм к неточным данным, чем формализм, который математически некорректен, к тем же неточным данным.
Перл обратил внимание на важное практическое достоинство подхода, основанного на правилах [Pearl, 1988, р.5]. Вычисление коэффициентов уверенности заключения имеет явно выраженный модульный характер, поскольку не нужно принимать во внимание никакой иной информации, кроме той, что имеется в данном правиле. При этом не имеет никакого значения, как именно получены коэффициенты уверенности, характеризующие исходные данные.
При построении экспертных систем часто используется эта особенность. Полагается, что для всех правил, имеющих дело с определенным параметром, предпосылки каждого правила логически независимы. Анализируя систему MYCIN, Шортлифф посоветовал сгруппировать все зависимые признаки в единое правило, а не распределять их по множеству правил (см., например, [Buchanan and Shortliffe, 1984, p. 229]).
Пусть, например, существует зависимость между признаками Е1 и E2- Шортлифф рекомендует сгруппировать их в единое правило если E1 и Е2, то приходим к заключению Н с уверенностью т, а не распределять по двум правилам если E1, то приходим к заключению Н с уверенностью t, если Е2, то приходим к заключению Н с уверенностью t.
В основе этой рекомендации лежит одно из следствий теории вероятностей, гласящее, что Р(Н | E1, Е2) не может быть простой функцией от Р(Н | Е1) и Р(Н | Е2).
Выражения для условной вероятности не могут в этом смысле рассматриваться как модульные. Выражение
P(B | A) = t
не позволяет заключить, что Р(В) = t при наличии А, если только А не является единственным известным признаком. Если кроме А мы располагаем еще и знанием Е, то нужно сначала вычислить Р(В | А, Е), а уже потом можно будет что-нибудь сказать и о значении Р(В). Такая чувствительность к контексту может стать основой очень мощного механизма логического вывода, но, как уже не раз подчеркивалось, за это придется платить существенным повышением сложности вычислений.
9.2.3. Коэффициенты уверенности и условные вероятности
Адаме показал, что если используется простая вероятностная модель на основе правила Байеса, то в системе MYCIN коэффициенты уверенности гипотез не соответствуют вероятностям гипотез при заданных признаках [Adams, 1976]. На первый взгляд, если коэффициенты уверенности используются только для упорядочения альтернативных гипотез, это не очень страшно. Но Адаме также показал, что возможна ситуация, когда при использовании коэффициентов уверенности две гипотезы будут ранжированы в обратном порядке по отношению к соответствующим вероятностям. Рассмотрим этот вопрос подробнее.
Обозначим через Р(h) субъективное, т.е. составленное на основе заключения эксперта, значение вероятности того, что гипотеза h справедлива, т.е. значение Р(Н) отражает степень уверенности эксперта в справедливости гипотезы h. Усложним положение дел и добавим новый признак е в пользу этой гипотезы, такой что P(h | е) > Р(h).Степень доверия эксперта к справедливости гипотезы увеличится, и это увеличение выразится отношением
MB(h,e)= [P(h|e)-P(h)]/[1-P(h)]
где MB означает относительную меру доверия.
Если же признак е свидетельствует против гипотезы h, т.е. P(h | е) < P(h), то увеличится мера недоверия эксперта к справедливости этой гипотезы. Меру недоверия MD можно выразить следующим отношением:
MD(h, e) =[P(h)-P(h|e) ] / P(h)]
Адаме обратил внимание на то, что уровни доверия к одной и той же гипотезе с учетом разных дополнительных признаков не могут быть определены независимо. Если некоторый признак является абсолютным диагностическим индикатором конкретного заболевания, т.е. если все пациенты с симптомом s1 страдают заболеванием dj, то никакие другие признаки уже не могут изменить диагноз, т.е. уровень доверия к выдвинутой гипотезе. Другими словами, если существует пара признаков s1 и s2 и
P(di|s1)=P(di|S1^S2)=1,
то
P(di|s2)= P(dl).
Адаме также критически отнесся к объединению (конъюнкции) гипотез. Модель, положенная в основу MYCIN, предполагает, что уровень доверия к сочетанию гипотез d1 ^ d2 должен соответствовать наименьшему из уровней доверия отдельных гипотез, а уровень недоверия — наибольшему из уровней недоверия отдельных гипотез. Предположим, что гипотезы d1 и d2 не только не независимы, но и взаимно исключают друг друга. Тогда P(d1 ^ d2 | е) = 0 при наличии любого признака е и независимо от степени доверия или недоверия к d1 или d2
Бучанан и Шортлифф определили коэффициент уверенности как некий артефакт, который позволяет численно оценить комбинацию уровней доверия или недоверия к гипотезам [Buchanan and Shortliffe, 1984, p. 249]. Он представляет собой разницу между мерой доверия и недоверия:
CF(h, еа ^ ef ) = MB(h, ef) - MD(h, ea),
где ef— признак, свидетельствующий в пользу гипотезы h, a ea — признак, свидетельствующий против гипотезы h. Однако полученное таким образом значение отнюдь не эквивалентно условной вероятности существования гипотезы h при условии еа ^ ef, которое следует из правила Байеса:
P(h|ea^ef)=[P(ea^ef | h)P(h)]/[P(ea^ef )]
Таким образом, хотя степень доверия, связанная с определенным правилом, и может быть соотнесена с субъективной оценкой вероятности, коэффициент уверенности является комбинированной оценкой. Его основное назначение состоит в следующем:
управлять ходом выполнения программы при формировании суждений;
управлять процессом поиска цели в пространстве состояний: если коэффициент уверенности гипотезы оказывается в диапазоне [+0.2, -0.2], то поиск блокируется;
ранжировать набор гипотез после обработки всех признаков.
Адаме, однако, показал, что ранжирование гипотез на основе коэффициентов уверенности может дать результат, противоположный тому, который будет получен при использовании вероятностных методов. Он продемонстрировал это на следующем примере.
Положим, что d1u d2 — это две гипотезы, а е — признак, свидетельствующий как в пользу одной гипотезы, так и в пользу другой. Пусть между априорными вероятностями существует отношение P(d1) > P(d2) и P(d\ \ е) > P(d2 | е). Другими словами, субъективная вероятность справедливости гипотезы d\ больше, чем гипотезы d2, причем это соотношение сохраняется и после того, как во внимание принимается дополнительный признак. Адаме показал, что при этих условиях возможно обратное соотношение CF(d1, е) < CF(d2, е) между коэффициентами уверенности гипотез.
Предположим, что вероятности имеют следующие значения:
P(d1) = 0.8,
P(d2) = 0.2,
P(d1|e) = 0.9,
P(d2| e) = 0.8.
Тогда повышение доверия к d1 будет равно (0.9 - 0.8) / 0.2 = 0.5, а повышение доверия к
d2 — (0.8 - 0.2) / 0.8 = 0.75.
Отсюда следует, что CF(d1| e) < CF(d2, е), несмотря на то, что и P(d1 | e) > P(d2| е).
Адаме назвал это явление "нежелательным свойством" коэффициентов доверия. Избежать такой ситуации можно, если все априорные вероятности будут равны. Несложно показать, что эффект в приведенном выше примере явился следствием того, что признак е больше свидетельствовал в пользу гипотезы d2, чем в пользу d1, именно из-за более высокой априорной вероятности последней. Однако приравнивание априорных вероятностей явно не согласуется со стилем мышления тех, кто ставит диагноз, поскольку существует достаточно большое отличие в частоте сочетаний разных болезней с одинаковыми симптомами, следовательно, эксперты будут присваивать им совершенно разные значения субъективных вероятностей.
Последовательное применение правил в системе MYCIN также связано с существованием определенных теоретических проблем. Используемая при этом функция комбинирования основана на предположении, что если признак е влияет на некоторую промежуточную гипотезу h с вероятностью P(h | е), а гипотеза h входит в окончательный диагноз d с вероятностью P(d | h), то
P(d|e) = P(d|h)P(h|e).
Таким образом, создается впечатление, что транзитивное отношение в последовательности правил вывода суждений справедливо на первом шаге, но не справедливо в общем случае. Для того чтобы существовала связь между правилами, популяции, связанные с этими категориями, должны быть вложены примерно так, как на рис. 9.1.
Рис. 9.1. Популяции, позволяющие использовать P(d | е; = P(d| h)P(h| z)
Адаме пришел к выводу, что успех практического применения системы MYCIN и других подобных систем объясняется тем, что в них используются довольно короткие последовательности комбинирования правил, а рассматриваемые гипотезы довольно просты.
Другое критическое замечание относительно MYCIN было высказано Горвицем и Гекерманом и касается использования коэффициентов уверенности в качестве меры изменения доверия, в то время как в действительности они устанавливаются экспертами в качестве степени абсолютного доверия [Horvitz and Heckerman, 1986]. Связывая коэффициенты доверия с правилами, эксперт отвечает на вопрос: "Насколько вы уверены в правдоподобности того или иного заключения?" При применении в MYCIN функций комбинирования дополнительных признаков эти коэффициенты становятся мерой обновления степени доверия, что приводит к несовместимости этих значений с теоремой Байеса.
9.3. Сомнительность и возможность
Помимо использования коэффициентов уверенности, в литературе описаны и иные подходы, альтернативные вероятностному. В частности, много внимания уделяется нечеткой логике (fuzzy logic) и теории функций доверия (belieffunctions). О функциях доверия мы поговорим в главе 21, а в данном разделе читатель познакомится с основными аспектами нечеткой логики. Будет показано, почему подход, основанный на идеях нечеткой логики, в последнее время все шире используется при создании экспертных систем
9.3.1. Нечеткие множества
То знание, которое использует эксперт при оценке признаков или симптомов, обычно базируется скорее на отношениях между классами данных и классами гипотез, чем на отношениях между отдельными данными и конкретными гипотезами. Большинство методик .решения проблем в той или иной форме включает классификацию данных (сигналов, симптомов и т.п.), которые рассматриваются как конкретные представители некоторых более общих категорий. Редко когда эти более общие категории могут быть четко очерчены. Конкретный объект может обладать частью характерных признаков определенной категории, а частью не обладать, принадлежность конкретного объекта к определенному классу может быть размыта. Предложенная Заде [Zadeh, 1965] теория нечетких множеств (fuzzy set theory) представляет собой формализм, предназначенный для формирования суждений о таких категориях и принадлежащих к ним объектах. Эта теория лежит в основе нечеткой логики (fuzzy logic) [Zadeh, 1975] и теории возможностей (possibility theory) [Zadeh, 1978].
Классическая теория множеств базируется на двузначной логике. Выражения в форме а & А, где а представляет индивидуальный объект, а А — множество подобных объектов, могут принимать только значение "истина" либо "ложь". После появления понятия "нечеткое множество" прежние классические множества иногда стали называть жесткими. Жесткость классической теории множеств стала источником ряда проблем при попытке применить ее к нечетко определенным категориям.
Рассмотрим категорию, определенную словом "быстрый" (fast). Если применить это определение к автомобилям, то какой автомобиль можно считать быстрым? В классической теории мы можем определить множество А "быстрых автомобилей" либо перечислением (составив список всех членов множества), либо введя в рассмотрение некоторую характеристическую функцию f такую, что для любого объекта X
f(X) = истина тогда и только тогда, когда Х принадлежит А.
Например, эта функция может отбирать только те автомобили, которые имеют скорость более 150 миль в час:
GT150(X)={ истина,если CAR(X) и TOP_SPEED(X) > 150 ложь в противном случае
Множество, определенное такой характеристической функцией, представляется формулой
{Х ~ CAR TOP-SPEED(X)> 150}.
Эта формула утверждает, что элементами нового множества являются те элементы множества CAR, которые имеют максимальную скорость свыше 150 миль в час.
А что можно сказать о множестве (категории) "быстрых" автомобилей? Интуитивно кажется, что ситуация сходна с представленной на рис. 9.2, где границы множества размыты и принадлежность элементов множеству может быть каким-то образом ранжирована. В таком случае можно говорить о том, что отдельный объект (автомобиль) более или менее типичен для этого множества (категории). Можно с помощью некоторой функции/охарактеризовать степень принадлежности объектов X такому множеству. Функция /(X) определена на интервале [0,1]. Если для объекта X функция f(X) = 1, то объект определенно является членом множества, если ДА) = 0, то объект определенно не является членом множества. Все промежуточные значения означают степень членства объекта X в этом множестве. В примере с автомобилями нам понадобится функция, оперирующая с максимальной скоростью каждого претендента на членство. Можно определить ее таким образом, что fFAST(80) = 0, fFAST(180) = 1, а промежуточные значения представляются некоторой монотонной гистограммой, имеющей значения в интервале между нулем и единицей. Тогда множество "быстрых автомобилей" может быть охарактеризовано функцией
fFAST CAR(X) =fFAST(TOP-SPEED(X)),
которая определена на множестве всех автомобилей. Таким образом, членами множества становятся пары (объект, степень), например:
FAST-CAR = {(Porche-944, 0.9),
(BMW-316, 0.5), (Chevy-Nova, 0.1)}.
Рис. 9.2. Нечеткое множество "быстрых" автомобилей
9.3.2. Нечеткая логика
Ту роль, которую в классической теории множеств играет двузначная булева логика, в теории нечетких множеств играет многозначная нечеткая логика, в которой предположения о принадлежности объекта множеству, например FAST-CAR(Porche-944), могут принимать действительные значения в интервале от 0 до 1. Возникает вопрос, а как, используя концепцию неопределенности, вычислить значение истинности сложного выражения, такого как
¬FAST¬CAR(Chevy-Nova).
По аналогии с теорией вероятности, если F представляет собой нечеткий предикат, операция отрицания реализуется по формуле
¬F(X)=1-F(X).
Но аналоги операций конъюнкции и дизъюнкции в нечеткой логике не имеют никакой связи с теорией вероятностей. Рассмотрим следующее выражение:
"Porche 944 является быстрым (fast), представительским (pretentious) автомобилем". В классической логике предположение
FAST-CAR(Porche-944) ^PRETENTIOUS-CAR(Porche-944)
является истинным в том и только в том случае, если истинны оба члена конъюнкции. В нечеткой логики существует соглашение: если F и G являются нечеткими предикатами, то
Таким образом, если
FAST-CAR(Porche-944) = 0.9
PRETENTIOUS-CAR(Porche-944) = 0.7,
то
FAST-CAR(Porche-944) ^ PRETENTIOUS-CAR(Porche-944) = 0.7.
А теперь рассмотрим выражение
FAST-CAR(Porche-944) ^ ¬FAST-CAR(Porche-944).
Вероятность истинности этого утверждения равна 0, поскольку
P(FAST-CAR(Porche-944) | ¬FAST-CAR(Porche-944)) = 0,
но в нечеткой логике значение этого выражения будет равно 0.1 . Какой смысл имеет это значение. Его можно считать показателем принадлежности автомобиля к нечеткому множеству среднескоростных автомобилей, которые в чем-то близки к быстрым, а в чем-то — к медленным.
Смысл выражения FAST-CAR(Porche-944) = 0.9 заключается в том, что мы только на 90% уверены в принадлежности этого автомобиля к быстрым именно из-за неопределенности самого понятия "быстрый автомобиль". Вполне резонно предположить, что существует некоторая уверенность в том, что Porche-944 не принадлежит к быстрым, например он медленнее автомобиля, принимающего участие в гонках "Формула-1".
Аналог операции дизъюнкции в нечеткой логике определяется следующим образом:
f(F v G)(X) = max(fF(X),fG(X)).
Здесь также очевидна полная противоположность с теорией вероятностей, в которой
Р(А v В) = Р(А) + Р(B) - Р(А ^ В) .
Рассмотрим следующие предположения и значения истинности их принадлежности к нечеткому множеству FAST-CAR:
FAST-CAR(Porche-944) v ¬FAST-CAR(Porche-944) = 0.9,
FAST-CAR(BMW-316) v FAST-CAR(BMW-316) = 0.5,
FAST-CAR(Chevy-Nova) v FAST-CAR(Chevy-Novd) = 0.9.
Значение вероятности истинности каждого из этих предположений, как это определено в теории вероятностей, равно 1. В нечеткой логике более высокие значения для автомобилей Porche-944 и Chevy-Nova объясняются тем фактом, что степень принадлежности каждого из этих объектов к нечеткому множеству FAST-CAR выше. Нечеткость концепции "быстрый или не быстрый" более благоприятна для них, чем для более медленного BMW-316, который "ни рыба ни мясо".
Операторы обладают свойствами коммутативности, ассоциативности и взаимной дистрибутивности. Как к операторам в стандартной логике, к ним применим принцип композитивности, т.е. значения составных выражений вычисляются только по значениям выражений-компонентов. В этом операторы нечеткой логики составляют полную противоположность законам теории вероятностей, согласно которым при вычислении вероятностей конъюнкции и дизъюнкции величин нужно принимать во внимание условные вероятности
9.3.3. Теория возможности
Нечеткая логика имеет дело с ситуациями, когда и сформулированный-вопрос, и знания, которыми мы располагаем, содержат нечетко очерченные понятия. Однако нечеткость формулировки понятий является не единственным источником неопределенности. Иногда мы просто не уверены в самих фактах. Если утверждается: "Возможно, что Джон сейчас в Париже", то говорить о нечеткости понятий Джон и Париж не приходится. Неопределенность заложена в самом факте, действительно ли Джон находится в Париже.
Теория возможностей является одним из направлений в нечеткой логике, в котором рассматриваются точно сформулированные вопросы, базирующиеся на неточных знаниях. В этом разделе вы познакомитесь только с основными идеями этой теории. Лучше всего это сделать на примере.
Предположим, что в ящике находится 1 0 шаров, но известно, что только несколько из них красных. Какова вероятность того, что на удачу из ящика будет вынут красный шар?
Просто вычислить искомое значение, основываясь на знаниях, что только несколько шаров красные (red), нельзя. Тем не менее для каждого значения X из P(RED) в диапазоне [0,1] можно следующим образом вычислить возможность, что P(RED) = Х.
Во-первых, определим "несколько" (several) как нечеткое множество, например, так:
fSEVERAL = {(3, 0.2), (4, 0.6), (5, 1.0), (6, 1.0), (7, 0.6), (8, 0.3)} .
В этом определении выражение (3, 0.2) е fSEVERAL означает, что 3 из 10 вряд ли можно признать как "несколько", а выражения (5, 1 .0) е fSEVERAL и (6, 1 .0) е fSEVERAL означают, что значения 5 и 6 из 10 идеально согласуются с понятием "несколько". Обратите внимание на то, что в определение нечеткого множества не входят значения 1 и 10, поскольку интуитивно ясно, что "несколько" означает "больше одного" и "не все". Нечеткое множество, определенное на множестве чисел, называется нечеткими числами (fuzzy numbers). По тому же принципу, что и множество fSEVERAL, можно определить нечеткие множествами/для понятия "мало" fMOST для понятия "почти".
Теперь распределение возможностей для P(RED) представляется формулой
fP(RED) = SEVERAL / 10,
которая после подстановки дает
{(0.3, 0.2), (0.4, 0.6), (0.5, 1.0), (0.6, 1.0), (0.7, 0.6), (0.8, 0.3)}.
Выражение (0.3, 0.2) ~ fP(RED) означает, что шанс на то, что P(RED) = 0.3, равен 20%. Можно рассматривать fP(RED) как нечеткую вероятность (fuzzy probability).
Полагая, что почти любое понятие может быть областью определения такой функции, естественно ввести в обиход и понятие "нечеткое значение правдоподобия". Мы часто оцениваем некоторое утверждение как "очень правдоподобное" или "частично правдоподобное". Таким образом, можно представить себе нечеткое множество
ftrue-: [0 , 1]-> [0, 1],
где и область определения, и область значений функции ftrue являются возможными значениями правдоподобия в нечеткой логике. Следовательно, можно получить
TRUE(FASR-CAR(Porsche-944)) = 1
даже при FASR-CAR(Porsche-944) = 0.9, поскольку (0.9, 1.0)~ftrue Это означает, что любое предположение относительно значения 0.9 рассматривается как "достаточно правдоподобное". Таким образом, можно с уверенностью сказать, что Porsche-944 является быстрым автомобилем, несмотря на то, что на рынке есть и более скоростные
9.4. Неопределенное состояние проблемы неопределенности
Одно из главных достоинств формализма нечеткой логики в применении к экспертным системам состоит в возможности комбинирования его логических операторов. Ранее мы уже отмечали, что для правила MYCIN
ЕСЛИ
пациент имеет показания и симптомы s1 ^ ... ^ sk и
имеют место определенные фоновые условия t1 ^ ... ^ tm ,
ТО можно с уверенностью т заключить, что пациент страдает заболеванием di
оценка набора симптомов s1 ^ ... ^ sk, в соответствии с аксиомами теории вероятностей, включает вычисление произведений вида
P(s1 | s2 ^.. ,^ sk )P(s2 | s3 ^.. .^ sk )... P(sk)
Такая операция в худшем случае требует вычисления k-1 оценки вероятностей свыше тех, что необходимы для si.
Было также показано, что в MYCIN конъюнкция интерпретируется как оператор нечеткой логики, — при этом вычисляется min (s1^ ...^ sk). Это может иногда привести к результатам, полностью противоположным тем, которые следуют из теории вероятностей. Прк сравнении результатов, полученных с помощью различных методов обработки неопределенности в практических системах, были найдены и другие примеры ошибочных выводов, Это сравнение показало, что методы, основанные на нечеткой логике, менее надежны, чем те, которые используют Байесовский подход (см., например, [Wise and Henrion, 1986]).
С другой стороны, нелишне отметить, что человеку также не свойственно строить суждения на основе Байесовского подхода. Исследования Канемана и Тверского показали, что люди склонны не принимать во внимание прежний опыт и отдавать предпочтение более свежей информации [Kahneman and Tversky, 1972]. Некоторые исследователи полагают, что людям свойственно переоценивать свою компетентность (см., например, статьи в сборнике [Kahneman et al, 1982]), причем большинство имеют слабое представление о теории оценок [Tversky and Kahneman, 1974].
Частично привлекательность нечеткой логики для проектировщиков экспертных систем состоит в ее близости к естественному языку. Таким терминам, как "быстрый", "немного", "правдоподобно", чаще всего дается интерпретация на основе повседневного опыта и интуиции. Это упрощает процесс инженерии знаний, поскольку подобные суждения человека-эксперта можно непосредственно преобразовать в выражения нечеткой логики.
Мы еще вернемся к нечеткой логике в главе 21. Здесь же были изложены только основные идеи, чтобы читатель мог получить первое представление о концепции неопределенности знаний и данных и связанных с этим проблемах. Но даже из этого краткого изложения ясно, что предстоит еще очень много сделать для того, чтобы иметь полное понятие об адекватном представлении неопределенности в технических системах.
Рекомендуемая литература
Подробное изложение методики применения коэффициентов уверенности в системе MYCIN читатель найдет в части 4 книги Бучанана и Шортлиффа [Buchanan and Shartliffe, 1984]. В этой же книге воспроизведена критическая статься Адамса. В сборнике [Mamdani and Games, 1981] собраны статьи зачинателей теории нечеткой логики. Книга Санфорда [Sanford, 1987] содержит популярное изложение исследований в области психологических аспектов теории возможностей.
Наиболее свежие работы в области нечеткой логики опубликованы в сборниках [Baldwin, 1996], [Dubois et al, 1996], [Jamshidi et al., 1997]. В книге [Walker and Nguyen, 1996] представлен вводный курс нечеткой логики, а в книге [Yager and Filev, 1994] описано применение идей нечеткой логики в моделировании и управлении. Книга [McNeill and Freiberger, 1993] предназначена для читателей-неспециалистов и содержит описание истории нечетких суждений, сопровождаемое множеством анекдотов и исторических фактов
Упражнения
1. Какова вероятность того, что из полной колоды будет вытянута одна из старших карт (король, дама или валет)?
2. Какова вероятность того, что в каждом из двух последовательных бросаний игральной кости выпадет число больше трех?
3. Предположим, что вероятность отказа одного из двигателей трехмоторного самолета равна 0.01. Какова вероятность того, что откажут все три двигателя, если считать, что работоспособность одного двигателя не зависит от состояния двух других?
4. Какова вероятность того, что в примере упр. 3 откажут все три двигателя, если отказаться от предположения о независимости состояния двигателей, а использовать приведенные ниже значения условных вероятностей?
Р(отказ_двиг_1 | отказ_двиг_2 v отказ _двиг_3) =0.4
Р(отказ_двиг_2 | отказ_двиг_1 v отказ_двиг_3) = 0.3
Р(отказ_двиг_3 | отказ_двиг_1 v отказ_двиг_2) = 0.2
Р(отказ_двиг_1 отказ_двиг_2 v отказ_двиг_3) = 0.9
Р(отказ_двиг_2 | отказ_двиг_1 v отказ_двиг_3) = 0.8
Р(отказ_двиг_3 | отказ_двиг_1 v отказ_двиг_2) = 0.7
5. Положим, что Р(ртказ_трех_двиг | диверсия) = 0.9, а вероятность отказа любого отдельного двигателя, как и ранее, равна 0.01. Используя условные вероятности, представленные в упр. 4, определите, какова вероятность того, что была совершена диверсия, если известно, что отказали все три двигателя.
6. Поясните, в чем состоит отличие между частотной и субъективистской интерпретацией вероятности.
7. Почему во многих экспертных системах для вычисления степени уверенности в сделанном заключении не используется правило Байеса?
8. Какие проблемы могут появиться при использовании следующей пары правил системы MYCIN? Какие особенности структуры управления в MYCIN усугубляют ситуацию?
если Е1, то Н c уверенностью +0.5, если Е1 и £2, то Н с уверенностью -0.5.
Как следует скорректировать данные правила, чтобы избежать появления этих проблем?
9. Предположим, что понятие "немного" определено как нечеткое множество:
fНЕМНОГО = {(3, 0.8), (4, 0.7), (5, 0.6), (6, 0.5), (7, 0.4), (8, 0.3)}.
В ящике находится 15 шаров и известно, что немногие из них синего цвета. Какова вероятность того, что наудачу из ящика будет вынут именно синий шар?
10. Предположим, что понятие "необычная оценка из десяти" определено как нечеткое множество:
fНЕОБЫЧНО = {(0, 1.0), (1, 0.9), (2, 0.7), (3, 0.5), (4, 0.3), (5, 0.1),
(6, 0.1), (7, 0.3), (8, 0.5), (9, 0.9), (10, 0.9)},
а понятие "высокая оценка из десяти" определено как нечеткое множество
f ВЫСОКАЯ= {(0, 0), (1, 0), (2, 0), (3, 0.1), (4, 0.2), (5, 0.3),
(6, 0.4), (7, 0.6), (8, 0.7), (9, 0.8), (10, 1.0)}.
Постройте составную функцию "необыкновенно высокая оценка из десяти".
ГЛАВА 10. Приобретение знаний
10.1. Теоретический анализ процесса приобретения знаний
10.1.1. Стадии приобретения знаний
10.1.2. Уровни анализа знаний
10.1.3. Онтологический анализ
10.2. Оболочки экспертных систем
10.2.1. Система EMYCIN
10.2.2. Сопровождение и редактирование баз знаний с помощью программы TEIRESIAS
10.3. Методы приобретения знаний
10.3.1. Использование опроса экспертов для извлечения знаний в системе COMPASS
10.3.2. Автоматизация процесса извлечения знаний в системе OPAL
10.3.3. Графический интерфейс модели предметной области
10.3.4. Эффективность программы OPAL
10.4. Приобретение новых знаний на основе существующих
Рекомендуемая литература
Упражнения
ГЛАВА 10. Приобретение знаний
10.1. Теоретический анализ процесса приобретения знаний
10.2. Оболочки экспертных систем
10.3. Методы приобретения знаний
10.4. Приобретение новых знаний на основе существующих
Рекомендуемая литература
Упражнения
В главе 1 мы уже цитировали определение термина приобретение знаний (knowledge acquisition), данное Бучананом.
"Передача и преобразование опыта решения проблем, полученного от некоторого источника знаний, в программу".
Термин приобретение знаний носит обобщенный характер и совершенно нейтрален к способу передачи знаний. Например, передача может осуществляться с помощью специальной программы, которая в процессе обработки большого массива историй болезни устанавливает связь между симптомами и заболеваниями. А вот термин извлечение знаний (knowledge elicitation) относится именно к одному из способов передачи знаний — опросу экспертов в определенной проблемной области, который выполняется аналитиком или инженером по знаниям. Последний затем создает компьютерную программу, представляющую такие знания (или поручает это кому-нибудь другому, обеспечивая его всей необходимой информацией).
Этот же термин применяется и для обозначения процесса взаимодействия эксперта со специальной программой, целью которого является:
извлечь каким-либо систематическим способом знания, которыми обладает эксперт, например, предлагая эксперту репрезентативные задачи и фиксируя предлагаемые способы их решения;
сохранить полученные таким образом знания в некотором промежуточном виде;
преобразовать знания из промежуточного представления в вид, пригодный для практического использования в программе, например в набор порождающих правил.
Преимущество использования такой программы — снижение трудоемкости процесса, поскольку перенос знаний от эксперта к системе осуществляется в один прием.
В этой главе мы детально рассмотрим процесс извлечения знаний и в теоретическом, и в практическом аспектах. Сначала будет представлен такой способ организации приобретения знаний, когда весь процесс разбивается на несколько этапов или уровней анализа. Затем будут описаны результаты некоторых ранних работ в области автоматизации извлечения знаний, причем основное внимание будет сосредоточено на синтаксисе и правилах. В последнем разделе эти результаты сравниваются с поздними работами, в которых на первый план выходит семантика предметной области.
10.1. Теоретический анализ процесса приобретения знаний
В главе 1 отмечалось, что при извлечении знаний в ходе опроса экспертов за рабочий день удается сформулировать от двух до пяти "эквивалентов порождающих правил". Причин такой низкой производительности несколько:
прежде чем приступить к опросу экспертов, инженер по знаниям, который не является специалистом в данной предметной области, должен потратить довольно много времени на ознакомление с ее спецификой и терминологией; только после этого процесс опроса может стать продуктивным;
эксперты склонны думать о знакомой им области не столько в терминах общих принципов, сколько в терминах отдельных типических объектов, событий и их свойств;
для представления специфических знаний о предметной области нужно подобрать подходящую систему обозначений и структурную оболочку, что само по себе является непростой задачей.
Как известно, любую сложную задачу лучше всего разбить на подзадачи, и именно так мы поступим с задачей приобретения знаний.
10.1.1. Стадии приобретения знаний
В работе [Buchanan et al, 1983] предлагается выполнить анализ процесса приобретения знаний в терминах модели процесса проектирования экспертной системы (рис. 10.1).
Рис. 10.1. Стадии приобретения знаний
(1) Идентификация. Анализируется класс проблем, которые предполагается решать с помощью проектируемой системы, включая данные, которыми нужно оперировать, и критерии оценки качества решений. Определяются ресурсы, доступные при разработке проекта, — источники экспертных знаний, трудоемкость, ограничения по времени, стоимости и вычислительным ресурсам.
(2) Концептуализация. Формулируются базовые концепции и отношения между ними. Сюда же входят и характеристика различных видов используемых данных, анализ информационных потоков и лежащих в их основе структур в предметной области в терминах причинно-следственных связей, отношений частное/целое, постоянное/временное и т.п.
(3) Формализация. Предпринимается попытка представить структуру пространства состояний и характер методов поиска в нем. Выполняется оценка полноты и степени достоверности (неопределенности) информации и других ограничений, накладываемых на логическую интерпретацию данных, таких как зависимость от времени, надежность и полнота различных источников информации.
(4) Реализация. Преобразование формализованных знаний в работающую программу, причем на первый план выходит спецификация методов организации управления процессом и уточнение деталей организации информационных потоков. Правила преобразуются в форму, пригодную для выполнения программой в выбранном режиме управления. Принимаются решения об используемых структурах данных и разбиении программы на ряд более или менее независимых модулей.
(5) Тестирование. Проверка работы созданного варианта системы на большом числе репрезентативных задач. В процессе тестирования анализируются возможные источники ошибок в поведении системы. Чаще всего таким источником является имеющийся в системе набор правил. Оказывается, что в нем не хватает каких-то правил, другие не совсем корректны, а между некоторыми обнаруживается противоречие.
Как видно из рис. 10.1, проектирование экспертной системы начинается с анализа класса проблем, которые предполагается решать с помощью этой системы. Было бы ошибкой приступать к проектированию системы, заранее задавшись определенной концепцией или определенной структурной организацией знаний. Весьма сомнительно, чтобы тот вариант концепции или тот способ организации идей, которым мы задались априори, взяв за основу предыдущие разработки, был приложим и к новой предметной области
10.1.2. Уровни анализа знаний
Приведенное выше разделение на этапы встречается также и в работе Уилинги, который разработал моделирующий подход к инженерии знаний в рамках созданной им среды KADS [Wielinga et al, 1992]. В основе этого подхода лежит идея о том, что экспертная система является не контейнером, наполненным представленными экспертом знаниями, а "операционной моделью", которая демонстрирует некоторое нужное нам поведение в столкновении с явлениями реального мира. Приобретение знаний, таким образом, включает в себя не только извлечение специфических знаний о предметной области, но и интерпретацию извлеченных данных применительно к некоторой концептуальной оболочке и формализацию их таким способом, чтобы программа могла действительно использовать их в процессе работы.
В основу оболочки KADS положено пять базовых принципов.
(1) Использование множества моделей, позволяющее преодолеть сложность процессов инженерии знаний.
(2) Четырехуровневая структура для моделирования требуемой экспертности — набора качеств, лежащих в основе высокого уровня работы специалистов.
(3) Повторное использование родовых компонентов модели в качестве шаблонов, поддерживающих нисходящую стратегию приобретения знаний.
(4) Процесс дифференциации простых моделей в сложные.
(5) Важность преобразования моделей экспертности с сохранением структуры в процессе разработки и внедрения.
Ниже мы рассмотрим подробно два первых принципа.
Главным мотивом создания оболочки KADS было преодоление сложности знаний. На сегодняшний день у инженеров по знаниям имеется возможность использовать при построении экспертных систем множество самых разнообразных методов и технологий. Однако при этом остаются три основных вопроса:
определение проблемы, которую необходимо решить с помощью экспертной системы;
определений функций, которые возлагаются на экспертную систему применительно к этой проблеме;
определение задач, которые необходимо решить для выполнения возложенной функции.
Первый из принципов, положенных в основу KADS, состоит в том, что оболочка должна содержать множество частных моделей, помогающих найти ответ на эти вопросы. Примерами таких моделей могут служить:
организационная модель "социально-экономической среды", в которой должна функционировать система, например финансовые услуги, здравоохранение и т.п.;
прикладная модель решаемой проблемы и выполняемой функции, например диагностика, планирование расписания работ и т.д.;
модель задач, демонстрирующая, как должна выполняться специфицированная функция, для чего производится ее разбиение на отдельные задачи, например сбор данных о доходах, формирование гипотез о заболеваниях.
Между этой терминологией и той, которой пользовался Бучанан, нет прямого соответствия, но можно сказать, что организационная и прикладная модели аналогичны стадии идентификации в предложенной Бучананом структуре.
В подходе, который реализован при создании KADS, стадия "концептуализации" разбивается на две части: модель кооперации, или коммуникации, и модель экспертности. Первая отвечает за декомпозицию процесса решения проблемы, формирование набора простейших задач и распределение их между исполнителями, в качестве которых могут выступать и люди, и машины. Вторая модель представляет процесс, который обычно называется извлечением знаний, т.е. анализ разных видов знаний, которые эксперт использует в ходе решения проблемы.
Кроме указанных, в состав оболочки KADS входит еще и модель проектирования, включающая технологии вычислений и механизмы представления знаний, которые могут быть использованы для реализации спецификаций, сформулированных предыдущими моделями.
На первый взгляд кажется, что представленный выше анализ в какой-то степени смазывает отличие между стадиями концептуализации и формализации. Можно, конечно, возразить, что стадия формализации представляет собой просто более детальную проработку концепций и отношений, выявленных на ранних стадиях. Модель проектирования частично включает то, что в прежней схеме было отнесено к стадии реализации, но она не предполагает создание выполняемой программы.
В своей ранней работе Уилинга немного по-другому проводил разграничение между уровнями анализа [Wielinga and Breuker, 1986]. Он рассматривал четыре уровня анализа.
Концептуализация знаний. На этом уровне предполагалось формальное описание знаний в терминах принципиальных концепций и отношений между концепциями.
Уровень эпистемологического анализа. Целью такого анализа было выявление структурных свойств концептуальных знаний, в частности таксономических отношений.
Уровень логического анализа. Основное внимание уделялось тому, как строить логический вывод в данной предметной области на основе имеющихся знаний.
Уровень анализа внедрения. Исследовались механизмы программной реализации системы.
В более поздней разработке три первых уровня включены в состав модели экспертно-сти, а уровень анализа внедрения — в модель проектирования. Четырехуровневая структура KADS согласуется с предложенной Кленси схемой разделения знаний различного вида в соответствии с их ролью в процессе решения проблем [Clancey, 1985]. Подробно схема Кленси будет рассмотрена в главе 11. В частности, знания, касающиеся конкретной предметной области, теперь разделены на знания более высокого уровня (знания, относящиеся к построению логического вывода в этой предметной области), знания выбора решаемых задач и знания стратегии решения задач.
Эти уровни знаний представлены в табл. 10.1. Стратегический уровень управляет процессом выполнения задач, использующих при решении проблем методы логического вывода, подходящие для конкретной предметной области, и знания из этой области. Анализ такой схемы дифференциации знаний будет проведен в следующей главе.
Сейчас же только отметим, что описанная схема дифференциации знаний приводит нас к довольно простой архитектуре экспертной системы. В частности, оказывается, что даже в рамках традиционной архитектуры, предполагающей наличие базы знаний и машины логического вывода, можно неявным образом включить задачи и стратегии и в структуру знаний о предметной области, и в механизм построения логических заключений. Мы еще увидим в дальнейшем, что явное выделение этих задач и стратегий является главным моментом как в процессе приобретения знаний, так и в процессе проектирования структуры экспертной системы.
Таблица 10.1. Четырехуровневая схема дифференциации знании в системе KADS
Категория знаний
Организация
Виды знаний
Стратегическая
Стратегии
Планы, метаправила
Задача
Задачи
Цели, управляющие термы, структуры задач
Логический вывод
Структура логического вывода
Источники знаний, метаклассы, схема предметной области
Предметная область
Теория предметной области
Концепции, свойства, отношения
10.1. Оболочки CommonKADS и KASTUS
Описанные принципы построения оболочки системы приобретения знаний получили дальнейшее развитие в системе CommonKADS [Breaker and van de Velde, 1994]. Эта система поддержки инженерии знаний содержит редакторы каждого из перечисленных типов моделей и множество инструментальных средств и компонентов, облегчающих проектирование экспертной системы. Существенную помощь менеджеру проекта при планировании работ должна оказать модель жизненного цикла экспертной системы. В дополнение к тем моделям, которые входили в состав ранних версий оболочки KADS, в новую версию включено несколько новых, в частности модель агента, которая представляет саму экспертную систему, ее пользователей и подключенные вычислительные системы.
В рамках проекта KASTUS онтология и методология оболочки KADS была использована и при построении больших повторно используемых баз знаний [Wielinga and Schreiber, 1994]. Наименование проекта KASTUS — сокращение от Knowledge about Complex Technical Systems for Multiple Use (знания многоразового применения о сложных технических системах). Цель проекта — создание системы знаний, которую можно было бы использовать в множестве разнообразных приложений.
Уилинга и его коллеги сформулировали ряд принципов, которые составили основу 'методологии построения баз данных совместного использования. Один из них предполагает четкое разделение знаний, относящихся к предметной области и методам управления процессом применения знаний, другой — дальнейшее углубление онтологии предметной области, т.е. модели сущностей этой области и отношений между сущностями. Углублению и развитию этих двух концепций посвящено целое направление в современной литературе по экспертным системам, в которой такой подход противопоставляется методологии, основанной на приоритете технологий программирования, таких как формализм порождающих правил
10.1.3. Онтологический анализ
Александер и его коллеги предложили еще один уровень анализа знаний, который получил название онтологического анализа [Alexander et al., 1986]. В основе этого подхода лежит описание системы в терминах сущностей, отношений между ними и преобразования сущностей, которое выполняется в процессе решения некоторой задачи. Авторы указанной работы используют для структурирования знаний о предметной области три основные категории:
статическая онтология — в нее входят сущности предметной области, их свойства и отношения;
динамическая онтология — определяет состояния, возникающие в процессе решения проблемы, и способ преобразования одних состояний в другие;
эпистемическая онтология — описывает знания, управляющие процессом перехода из одного состояния в другое.
В этой схеме просматривается совершенно очевидное соответствие с уровнями концептуализации знаний и эпистемологического анализа в структуре, предложенной в уже упоминавшейся работе [Wielinga and Breaker, 1986]. Но на нижних уровнях — логического анализа и анализа внедрения — такое соответствие уже не просматривается. Онтологический анализ предполагает, что решаемая проблема может быть сведена к проблеме поиска, но при этом не рассматривается, каким именно способом нужно выполнять поиск. Примером практического применения такого подхода является система OPAL, описанная ниже в разделе 10.3.2.
Рассматриваемая схема онтологического анализа выглядит довольно абстрактной, но ее ценность в том, что она упрощает анализ плохо структурированных задач. Каждый, кто сталкивался с выявлением знаний в процессе опроса человека-эксперта, знает, как трудно найти подходящую схему организации таких знаний. Чаще всего в таких случаях говорят: "Давайте воспользуемся фреймами или системой правил", откладывая таким образом выбор подходящего метода реализации на будущее, когда природа знаний эксперта станет более понятна.
10.2. Оболочки экспертных систем
На раннем этапе становления экспертных систем проектирование каждой очередной системы начиналось практически с нуля, в том смысле, что проектировщики для представления знаний и управления их применением использовали самые примитивные структуры данных и средства управления, которые содержались в обычных языках программирования. В редких случаях в существующие языки программирования включались специальные языки представлений правил или фреймов.
Такие специальные языки, как правило, обладали двумя видами специфических средств:
модулями представления знаний (в виде правил или фреймов);
интерпретатором, который управлял активизацией этих модулей.
Совокупность модулей образует базу знаний экспертной системы, а интерпретатор является базовым элементом машины логического вывода. Невольно напрашивается мысль, что эти компоненты могут быть повторно используемыми, т.е. служить основой для создания экспертных систем в разных предметных областях. Использование этих программ в качестве базовых компонентов множества конкретных экспертных систем позволило называть их оболочкой системы
10.2.1. Система EMYCIN
Примером такой оболочки может служить система EMYCIN, которая является предметно-независимой версией системы MYCIN, т.е. это система MYCIN, но без специфической медицинской базы знаний [van Melle, 1981]. (Само название EMYCIN толкуется авторами системы как "Empty MYCIN" , т.е. пустая MYCIN.) По мнению разработчиков, EMYCIN вполне может служить "скелетом" для создания консультационных программ во многих предметных областях, поскольку располагает множеством инструментальных программных средств, облегчающих задачу проектировщика конкретной экспертной консультационной системы. Она особенно удобна для решения дедуктивных задач, таких как диагностика заболеваний или неисправностей, для которых характерно большое количество ненадежных входных измерений (симптомов, результатов лабораторных тестов и т.п.), а пространство решений, содержащее возможные диагнозы, может быть достаточно четко очерчено.
Некоторые программные средства, впервые разработанные для EMYCIN, в дальнейшем стали типовыми для большинства оболочек экспертных систем. Среди таких средств следует отметить следующие.
Язык представления правил. В системе EMYCIN такой язык использует систему обозначений, аналогичную языку ALGOL. Этот язык, с одной стороны, более понятен, чем LISP, а с другой— более строг и структурирован, чем тот диалект обычного английского, который использовалсяв MYCIN.
Индексированная схема применения правил, которая позволяет сгруппировать правила, используя в качестве критерия группировки параметры, на которые ссылаются эти правила. Так, правила, применяемые в MYCIN, разбиваются на группы: CULRULES — правила, относящиеся к культурам бактерий, ORGRULES — правила, касающиеся организмов, и т.д.
Использование обратной цепочки рассуждений в качестве основной стратегии управления. Эта стратегия оперирует с И/ИЛИ-деревом, чьи листья представляют собой данные, которые могут быть найдены в таблицах или запрошены пользователем.
Интерфейс между консультационной программой, созданной на основе EMYCIN, и конечным пользователем. Этот компонент оболочки обрабатывает все сообщения, которыми обмениваются пользователь и программа (например, запросы программы на получение данных, варианты решения, которые формирует программа в ответ на запросы пользователя, и т.п.).
Интерфейс между разработчиком и программой, обеспечивающий ввод и редактирование правил, редактирование знаний, представленных в форме таблиц, тестирование правил и выполнение репрезентативных задач.
Значительная часть интерфейса реализуется отдельным компонентом EMYCIN — программой TEIRESIAS [Davis, 1980,b]. Эта программа представляет собой "редактор знаний", который упрощает редактирование и сопровождение больших баз знаний. Редактор проверяет синтаксическую корректность правил, анализирует взаимную непротиворечивость правил в базе знаний и следит за тем, чтобы новое правило не являлось частным случаем существующих. Противоречие возникает, когда два правила с одинаковыми антецедентами имеют противоречивые консеквенты. Одно правило является частью другого в том случае, когда совокупность условий антецедента одного правила представляет собой подмножество совокупности условий другого правила, а их консеквенты одинаковы. Но в состав TEIRESIAS не включены знания о какой-либо конкретной предметной области или о стратегии решения проблем, которая может быть использована в проектируемой экспертной системе.
Такая организация программы TEIRESIAS является, с одной стороны, ее достоинством, а с другой — недостатком. Общность интерфейса, его независимость от назначения проектируемой экспертной системы — достоинства TEIRESIAS. Используемые в ней методы синтаксического анализа могут быть применены к правилам, относящимся к любой предметной области. А тот факт, что эта программа привносит существенные сложности в процесс общения инженера по знаниям с экспертом, является ее недостатком. Зачастую знания, которыми располагает эксперт, не укладываются в жесткие рамки синтаксических правил, на соблюдении которых "настаивает" TEIRESIAS. Тем не менее эта программа включает множество новшеств, которые имеет смысл рассмотреть подробнее, что мы и сделаем в следующем разделе. Другие аналогичные программные средства, предназначенные для облегчения процесса извлечения знаний, детально описаны в разделе 10.3 с учетом семантики предметной области
10.2.2. Сопровождение и редактирование баз знаний с помощью программы TEIRESIAS
Как правило, человек-эксперт знает о той предметной области, в которой он является специалистом, гораздо больше, чем может выразить на словах. Вряд ли можно добиться от него многого, задавая вопросы в общем виде, например: "Что вам известно об инфекционных заболеваниях крови?" Гораздо продуктивнее подход, реализованный в программе TEIRESIAS, который предполагает вовлечение эксперта в решение несложных репрезентативных задач из определенной предметной области и извлечение необходимых знаний в процессе такого решения.
Задавшись определенным набором базовых правил, представляющих прототип экспертной системы, TEIRESIAS решает в соответствии с этими правилами какую-нибудь из сформулированных репрезентативных проблем и предлагает эксперту критиковать результаты. В ответ эксперт должен сформулировать новые правила и откорректировать введенные ранее, а программа отслеживает внесенные изменения, анализирует их на предмет сохранения целостности и непротиворечивости всего набора правил, используя при этом модели правил. В процессе анализа используется обобщение правил различного вида.
Например, правила системы MYCIN, предназначенные для идентификации организмов, содержат в предпосылках сведения о параметрах анализируемой культуры организмов и типе инфекции. Таким образом, если эксперт собирается добавить новое правило такого типа, то вполне резонно предположить, что в нем должны упоминаться аналогичные параметры. Если же это не так, то, как минимум, нужно обратить на это внимание пользователя и предоставить в его распоряжение средства, помогающие что-либо сделать с этими параметрами.
Другая модель правил может учитывать тот факт, что правила, касающиеся образцов культур и типов инфекции, среди прочих, должны в антецедентной части включать и способы проникновения инфекции в организм пациента. Опять же, система может запросить эту информацию у пользователя, если при формулировке нового правила этого типа она была опущена. Более того, можно догадаться, какой именно способ проникновения обычно бывает связан с теми клиническими показаниями, которые содержатся в данном правиле, и обратить внимание пользователя на возможное несоответствие.
Модели правил являются, по существу, метаправилами, уже рассмотренными в главе 5, поскольку они предназначены для выработки суждений о правилах, а не об объектах предметной области приложения. В частности, в программе TEIRESIAS имеются метаправила, относящиеся к атрибутам правил объектного уровня. Такие правила обращают внимание пользователя на то, что в данных обстоятельствах целесообразно сначала исследовать определенные параметры, а уж затем в процессе отладки набора правил пытаться отслеживать влияние других параметров.
Существуют также средства, помогающие эксперту добавить новые варианты типов данных. Ошибки, которые обычно возникают при решении подобных задач, состоят в том, что новые типы данных имеют структуру, не согласующуюся с типами, уже существующими в системе. Например, если предпринимается попытка включить в систему MYCIN новый клинический параметр, то он должен унаследовать структуру атрибутов, связанную с другими аналогичными параметрами, а значения атрибутов должны иметь согласованные диапазоны представления.
Абстрактные данные, которые используются для формирования новых экземпляров структур данных, называются схемами. Эти схемы представляют собой обобщенные описания типов данных, точно так же, как структуры данных являются обобщениями конкретных данных. Следовательно, схемы также могут быть организованы в виде иерархической структуры, в которой каждая схема, во-первых, наследует атрибуты, ассоциированные с ее предшественницей в иерархии, а во-вторых, имеет еще и собственные дополнительные атрибуты.
В таком случае процесс создания нового типа данных включает прослеживание пути от корня иерархии схем к той схеме, которая представляет интересующий нас тип данных. На каждом уровне имеются атрибуты, которые нужно конкретизировать, причем процесс продолжается до тех пор, пока не будет конкретизирована вся структура. Отношения между схемами в иерархии определяют последовательность выполнения задач обновления структур данных в системе.
Таким образом, в программе TEIRESIAS можно выделить три уровня обобщения:
знания об объектах данных, специфические для предметной области;
знания о типах данных, специфические для метода представления знаний;
знания, независимые от метода представления.
Из сказанного выше следует, что эксперт может использовать программу TEIRESIAS для взаимодействия с экспертной системой, подобной MYCIN, и следить с ее помощью за тем, что делает экспертная система и почему. Поскольку на этапе разработки экспертной системы мы всегда имеем дело с неполным набором правил, в котором к тому же содержится множество ошибок, можно задать вопрос эксперту: "Что вы знаете такого, что еще не знает программа?" Решая конкретную проблему, эксперт может сосредоточить внимание на корректности правил, вовлеченных в этот процесс, из числа тех, что ранее введены в систему, их редактировании при необходимости или включении в систему новых правил.
В составе TEIRESIAS имеются и средства, которые помогают оболочке EMYCIN следить за поведением экспертной системы в процессе применения набора имеющихся правил.
Режим объяснения (EXPLAIN). После выполнения каждого очередного задания — консультации — система дает объяснение, как она пришла к такому заключению. Распечатываются каждое правило, к которому система обращалась в процессе выполнения задания, и количественные параметры, связанные с применением этого правила, в том числе и коэффициенты уверенности.
Режим тестирования (TEST). В этом режиме эксперт может сравнить результаты, полученные при прогоне отлаживаемой программы, с правильными результатами решения этой же задачи, хранящимися в специальной базе данных, и проанализировать имеющиеся отличия. Оболочка EMYCIN позволяет эксперту задавать системе вопросы, почему она пришла к тому или иному заключению и почему при этом не были получены известные правильные результаты.
Режим просмотра (REVIEW). В этом режиме эксперт может просмотреть выводы, к которым приходила система при выполнении одних и тех же запросов из библиотеки типовых задач. Это помогает просмотреть эффект, который дают изменения, вносимые в набор правил в процессе наладки системы. В этом же режиме можно проанализировать, как отражаются изменения в наборе правил на производительности системы.
Нужно отметить, что не существует общепринятой методологии использования режима REVIEW, но в литературе имеются сообщения об исследовании процесса настройки отдельных правил (см., например, [Langlotz et al., 1986]) и оптимизации набора правил с помощью этого режима (например, [Wilkins and Buchanan, 1986]). Об этих работах мы поговорим в главе 20.
Система EMYCIN была одной из первых попыток создать программный инструмент, позволяющий перенести архитектуру экспертной системы, уже эксплуатируемой в одной предметной области, на другие предметные области. Опыт, полученный в процессе работы с EMYCIN, показал, что те инструментальные средства, которые были включены в состав EMYCIN, пригодны для решения одних проблем и мало что дают при решении других. В результате многих исследователей заинтересовали вопросы: "Какие именно характеристики проблемы делают ее более или менее пригодной для решения с помощью системы, подобной EMYCIN? Связано ли это с какими-то характеристиками предметной области, с.о стилем логического вывода или с размерностью решаемых задач?"
Мы вернемся к обсуждению этого вопроса в главах 11 и 12, но уже сейчас можно отметить, что разработка системы EMYCIN и других, ей подобных, заставила задуматься над этими вопросами. В частности, исследователи заинтересовались классификацией проблем, таких как медицинская диагностика, планирование маршрутов движения, интерпретация сигналов в системах ультразвуковой локации и т.п. Такая классификация стала рассматриваться в качестве этапа, предваряющего поиск методов решения задач указанных классов. Другими словами, исследователи начали изобретать различные методы описания проблем, отталкиваясь от предписываемых для их решения методов. Это, в свою очередь, привело к попытке установить связь между типами проблем и методами приобретения знаний, подходящих для их решения. Организация и методы восприятия знаний, необходимых для решения задач медицинской диагностики и поиска неисправностей в электронных схемах, весьма отличаются от тех, которые нужны для построения планов производства или выбора конфигурации вычислительной системы.
10.3. Методы приобретения знаний
Познакомив читателей с теоретическими вопросами, на которых базируется методика приобретения знаний, и некоторыми ранними разработками в этой области, мы рассмотрим в этом разделе две сравнительно новые системы, которые демонстрируют разные подходы к решению аналогичных задач. Первая из рассматриваемых ниже систем предназначена для поиска неисправностей в переключающей системе телефонной сети, а другая используется при планировании курсов лечения онкобольных. В обоих проектах большое внимание уделено методике приобретения и представления знаний, причем для решения этих задач используются совершенно отличные подходы
10.3.1. Использование опроса экспертов для извлечения знаний в системе COMPASS
Для переключения номеров в телефонной сети используется довольно сложная система, которая может занимать большую часть здания телефонной станции. Основная задача при обслуживании системы переключений — минимизировать число вызовов, которые необходимо перебросить на запасные маршруты из-за неисправности основных линий подключений, и быстро восстановить работу всей системы. Неисправность линий подключения может быть вызвана отказом каких-либо электронных схем, обеспечивающих связь между парой абонентов.
В процессе работы в системе переключения непрерывно выполняется самотестирование. При этом проверяется, нет ли разрыва в цепях, короткого замыкания, замедления срабатывания переключающих схем и т.д. При возникновении каких-либо нестандартных ситуаций система самотестирования формирует соответствующее сообщение. Причина появления неисправности в системе переключения может быть выявлена только на основании множества таких сообщений, причем на помощь приходит опыт специалистов-экспертов. Эти сообщения поступают в экспертную систему COMPASS, которая может предложить провести какой-либо специальный дополнительный тест или заменить определенный узел в системе (реле или плату). Система разработана компанией GTE и эксплуатируется во множестве ее филиалов [Рrеrаи, 1990].
Ранее для поддержания работоспособности телефонной сети компании требовался многочисленный штат опытных наладчиков, которые должны были за ограниченное время проанализировать большое количество зарегистрированных сообщений об отклонениях, обнаруженных в процессе самотестирования, отыскать и устранить неисправность. Радикально решить проблему обслуживания такой сложной структуры могло только создание системы, способной аккумулировать в виде программы опыт специалистов высокого касса и помочь обеспечить таким образом нужный уровень обслуживания. Накопление в системе знаний экспертов осуществлялось в процессе опроса. Эксперты описывали применяемые ими эвристические способы поиска неисправности, а инженеры по знаниям формулировали их в виде правил "если ... то". Затем эксперты повторно анализировали результаты формализации и проверяли, насколько эти правила согласуются с их опытом и интуицией. При обнаружении разночтений инженеры по знаниям изменяли формулировку правил и совместными усилиями с экспертами добивались, чтобы правила были приемлемыми. Пример одного правила, построенного таким способом, представлен ниже.
ЕСЛИ
существует проблема "ВС Dual Expansion One PGA" и количество сообщений пять или более,
ТО
отказ в узле PGA, в котором горит индикатор расширения (.5), и отказ в резервном узле PGA (.3), и отказ в узле IGA (.1), и отказ в плате переключателей D2 (.1).
Обычно такие правила вводились в систему в виде одного или нескольких производящих правил на языке КЕЕ (подробнее речь о нем пойдет в главе 17), хотя в некоторых случаях более целесообразным кажется использование механизма представления фреймов или языка LISP. Сформулированные на английском языке правила накапливались в библиотеке "документированных знаний", которая являлась одним из компонентов комплекта документации экспертной системы. Эта библиотека помогала сохранить "первоисточник знаний", что очень помогло в процессе настройки и опытной эксплуатации системы.
В процессе приобретения знаний большое внимание, по крайней мере на первых порах, уделялось моделированию применения правил при поиске неисправностей "вручную", т.е. с помощью карандаша и бумаги. Цикл приобретения знаний при разработке системы COMPASS включал следующие этапы.
(1) В процессе собеседования с экспертом извлечь определенные знания.
(2) Задокументировать извлеченные знания.
(3) Проверить новые знания:
попробовать применить их на разных наборах данных;
смоделировать вручную, к каким результатам приведет использование этих знаний;
сравнить результаты моделирования с теми, которые должны получиться по мнению эксперта;
если результаты отличаются, то определить, какие именно правила и процедуры внесли "наибольший вклад" в это отличие; вернуться к п. (1) и выяснить у эксперта, как следует скорректировать подозрительное правило или процедуру.
Графически циклическая процедура приобретения знаний представлена на рис. 10.2.
После того как объем накопленных знаний превысит некоторый минимум, можно проверять работу системы на практике. При этом между этапами документирования и проверки знаний появляется еще один — внедрение знаний в систему. После этого можно проверять адекватность новых знаний не только моделированием вручную, но и выполнением программы на разных наборах входных данных. Конечно, анализ и сравнение результатов при этом усложняются, поскольку на ошибки в процессе формализации могут накладываться и ошибки реализации правил в работающей программе.
Преро (Prerau), ведущий разработчик системы, отметил, что по мере накопления опыта в процессе извлечения знаний инженеру по знаниям легче было общаться с экспертами. Последние постепенно освоились с методикой формализации знаний в виде правил, а инженер по знаниям достаточно глубоко ознакомился со спецификой предметной области. Такое сближение "стилей мышления" можно было рассматривать как признак успешного хода работы над проектом. Определенную помощь в этом, по наблюдению
Преро, сыграло совместное участие инженера по знаниям и эксперта в ручном моделировании процесса принятия решений на основе полученных знаний и последующей проверке результатов.
Рис. 10.2. Циклическая процедура приобретения знаний в системе COMPASS
В 1990 году система COMPASS была внедрена на ряде дочерних предприятий фирмы GTE и поначалу эксплуатировалась как вспомогательное средство обслуживания систем, обеспечивавших телефонной связью до полумиллиона абонентов. Успех внедрения системы был во многом обеспечен тем, что при ее разработке использовалась описанная выше методика накопления и формализации знаний. Кроме того, структура системы была задумана таким образом, что не препятствовала дальнейшему накоплению и обновлению знаний даже в процессе эксплуатации.
10.3.2. Автоматизация процесса извлечения знаний в системе OPAL
Проект COMPASS можно считать одним из наиболее ярких примеров использования традиционной методики приобретения знаний, базирующейся на соответствующим образом организованном опросе экспертов. Такая методология "выросла" из предложенной Ньюэллом и Саймоном методики анализа протокола (protocol analysis), которую мы рассматривали в главе 2. В этом разделе мы остановимся на проекте OPAL, в котором использована другая методика, отличающаяся от традиционной в двух важных аспектах.
Эта методика ориентирована на частичную автоматизацию процесса извлечения знаний в ходе активного диалога интервьюируемого эксперта с программой.
Методика приобретения знаний предполагает использование стратегии, направляемой знаниями о предметной области.
Мы уже рассматривали программу TEIRESIAS, в которой использовалось множество средств поиска ошибок в существующем наборе правил, редактирования и тестирования откорректированного набора правил. Но для построения начального набора правил или отслеживания изменений в них программа TEIRESIAS не использовала какие-либо знания о предметной области. Программа OPAL, напротив, пытается "вытянуть" из пользователя как можно больше деталей, касающихся представления знаний и их использования. OPAL не является программой общего назначения. Она разработана специально для диагностики онкологических заболеваний и предназначена для формирования правил принятия решений на основе полученных от эксперта знаний о планах лечения в том или ином случае
10.3.3. Графический интерфейс модели предметной области
Программа OPAL упрощает процесс извлечения знаний, предназначенных для использования в экспертной системе ONCOCIN [Shortliffe et at, 1981]. Последняя формирует план лечения больных онкозаболеваниями и заинтересована в использовании модели предметной области для получения знаний непосредственно от эксперта с помощью средств графического интерфейса. Понятие модель предметной области можно трактовать в терминах знаний различного вида, которыми обладает эксперт.
Независимо от того, о какой конкретной предметной области идет речь, игре в шахматы или медицинской диагностике, всегда существуют некоторые предварительные условия или предварительный опыт, которыми должен обладать субъект или техническая система, чтобы воспринимать знания об этой предметной области. Если речь идет об игре в шахматы, то по крайней мере нужно знать правила этой игры: как ходят фигуры, в чем цель игры и т.п. Применительно к медицинской диагностике нужно иметь представление о пациентах, заболеваниях, клинических тестах и т.п. Этот вид фоновых, или фундаментальных, знаний иногда в литературе по экспертным системам называют глубокими знаниями {deep knowledge), противопоставляя их поверхностным знаниям (shallow knowledge), которые представляют собой хаотичный набор сведений о связях "стимул — реакция".
Так, программа игры в шахматы, которая просто выбирает дозволенные ходы, не обладает глубокими знаниями об этой игре, в отличие от программы, которая учитывает "ценность" фигур и "качество" позиции на доске. Аналогично и программа диагностики, которая не делает ничего иного, кроме того, что пытается спроектировать имеющийся набор симптомов на список заболеваний, является поверхностной по сравнению с программой, которая пытается найти согласованное объяснение всем представленным симптомам в терминах небольшого числа совместно проявляющихся патологий. Человек, который разбирается в основных принципах игры в шахматы или клинического диагноза, может затем на основе этих знаний повышать свое мастерство, а без таких фундаментальных знаний дальнейшее совершенствование практически невозможно.
OPAL представляет собой программу извлечения знаний, которая обладает некоторыми фундаментальными знаниями в области терапии онкологических заболеваний. Программа использует эти базовые знания в процессе диалога с экспертом для извлечения дополнительных, более детальных знаний. Знания о предметной области нужны программе и для того, чтобы преобразовать информацию, полученную с терминала в процессе диалога, в исполняемый код — порождающие правила или таблицу состояний. Такая комбинация процесса наращивания знаний и их компиляции является одной из наиболее привлекательных возможностей той методологии построения экспертных систем, которая положена в основу системы OPAL. Графически основная идея представлена на рис. 10.3, где на человека-эксперта возлагается задача расширения и уточнения модели предметной области. Эта модель затем компилируется в программу, состоящую из процедур и порождающих правил. Поведение программы снова анализируется экспертом, который при необходимости вносит коррективы в модель и замыкает таким образом цикл итеративного процесса.
Рис. 10.3. Процесс приобретения знаний с использованием модели предметной области
Чтобы лучше понять, как работает программа OPAL, нужно сказать несколько слов о той предметной области, в которой она используется. Курсы лечения онкологических заболеваний называются протоколами, и в них специфицируются медикаменты, которые назначаются пациенту на определенный период времени, необходимые лабораторные анализы и иногда курсы радиационной терапии. Система ONCOCIN формирует рекомендации относительно курса лечения, используя базу знаний протоколов, которые представляют собой шаблоны планов лечения. Программа сначала выбирает подходящий протокол, а затем конкретизирует его — назначает конкретные медикаменты, сроки и т.п. Такой метод решения подобных задач иногда называют уточнением плана.
В экспертной системе ONCOCIN используются три разных метода представления знаний:
иерархия объектов, представляющая протоколы и их компоненты, в частности медикаменты;
порождающие правила, которые связаны с фреймами и формируют заключения о значениях медицинских параметров в процессе уточнения плана;
таблицы конечных состояний представляют собой последовательности терапевтических курсов (назначение и использование этих таблиц будет описано ниже).
Включение в систему ONCOCIN нового протокола влечет за собой формирование иерархии, которая представляет его компоненты, связывание подходящих порождающих правил с новыми объектами и заполнение таблицы конечных состояний, которая определяет порядок назначения определенных компонентов курса лечения. Программа OPAL формирует элементы нового протокола в процессе "собеседования" с экспертом с помощью средств графического интерфейса. При этом полученные знания преобразуются сначала в промежуточную форму представления, а затем транслируются в формат, используемый в системе ONCOCIN. На последней стадии формируются соответствующие порождающие правила. Для упрощения реализации промежуточных стадий, трансляции и формирования порождающих правил в программе OPAL используется модель предметной области лечения онкологических заболеваний, о которой и пойдет речь ниже.
В модели предметной области можно выделить четыре основных аспекта, которые явились следствием применения онтологического анализа, как отмечалось в разделе 10.1.3.
Сущности и отношения. Сущностями в этой предметной области являются элементы (компоненты) курса лечения — назначаемые медикаменты. Эти сущности образуют часть статической онтологии предметной области. Большая часть знаний о предметной области касается атрибутов альтернативных медикаментов, например доз и их приема. Отношения между элементами курса лечения довольно запутаны в том смысле, что они связывают различные уровни спецификации в плане лечения. Так, медикаменты могут быть частью химиотерапии, а химиотерапия может быть частью протокола.
Действия в предметной области. При заданных отношениях между элементами для уточнения плана приема медикаментов потребуется обращение к перечню планов. Другими словами, уточнение плана является неявным в иерархической организации сущностей предметной области. Таким образом, модель предметной области в OPAL позволяет сконцентрировать основное внимание на задачах, а не на используемых методах поиска. Однако может потребоваться изменить планы для отдельных пациентов, например изменить дозировку или заменить один препарат другим. Такие концепции, как изменение дозировки или замена препаратов в курсе лечения, образуют часть динамической онтологии предметной области.
Предикаты предметной области. Этот аспект модели касается условий, при которых обращаются к модификации назначенного плана лечения. Сюда могут входить результаты лабораторных анализов и проявления у пациента определенных симптомов (например, токсикоз на определенные препараты). Такие знания образуют часть эпи-стемической онтологии предметной области, т.е. эти знания направляют и ограничивают возможные действия. На уровне реализации правила, изменяющие курс лечения, основываются на этих условиях. Такие предикаты появляются в левой части порождающих правил ONCOCIN. Подобное правило подключается к объекту в иерархии планирования таким образом, что оно применяется только в контексте определенного препарата или определенного курса химиотерапии в конкретном протоколе.
Процедурные знания. Поскольку планы курса лечения предполагают определенное расписание приема назначенных пациенту препаратов, знания о способе реализации протокола составляют существенную часть модели предметной области. Эти знания позволяют программе OPAL извлекать информацию, которая потом направляется в таблицы конечных состояний, описывающие возможные последовательности этапов курса терапии, и таким образом образуют другую часть эпистемической онтологии предметной области. На уровне реализации программа OPAL использует для описания таких процедур специальный язык программирования, который позволяет эксперту представлять достаточно сложные алгоритмы, манипулируя пиктограммами на экране дисплея.
Используя эту модель, программа OPAL может извлекать и отображать в разной форме знания о планах лечения — в виде пиктограмм, представляющих отдельные элементы плана, формуляра, заполненного информацией об отдельных препаратах, в виде предложений специального языка, представляющих процедуры, связанные с реализацией плана лечения.
Сущности и отношения между ними вводятся с помощью экранных формуляров, в которых пользователь выбирает элементы из меню. Затем заполненный формуляр преобразуется в фрейм, причем отдельные поля формуляра образуют слоты фрейма, а введенные в них значения — значения слотов (заполнители слотов). Эти новые объекты затем автоматически связываются с другими объектами в иерархии. Например, медикаменты связываются с объектами курсов химиотерапии, компонентами которых они являются.
Операции предметной области также вводятся с помощью заполнения экранных формуляров. В этом случае формуляр представляет собой пустой шаблон плана, в котором представлены поля для назначения расписания приема препаратов, а меню возможных действий включает такие операции, как изменение дозировки, временное прекращение приема и т.д. Поскольку список возможных действий довольно короткий, эта методика позволяет эксперту достаточно легко ввести нужную последовательность операций. В отличие от программы TEIRESIAS, OPAL позволяет пользователю не вдаваться в подробности реализации. Например, не нужно думать о том, на какие медицинские параметры ссылается та или иная операция в процессе реализации ее системой ONCOCIN. Вся информация, касающаяся медицинских параметров, такая как число белых кровяных телец, уже связана с формулярами. Количество предикатов предметной области, так же, как и количество возможных действий, ограничено. Поэтому при вводе экспертом информации о том, как изменять протокол в процессе выполнения курса лечения, программа OPAL тоже использует метод выбора из заранее сформированных списков видов лабораторных анализов. Процесс перевода введенной информации в выражения, которые могут обрабатываться системой ONCOCIN, скрыт от пользователя.
Процесс приобретения знаний в значительной мере облегчается при использовании языков визуального программирования. Графический интерфейс позволяет пользователю создавать пиктограммы, представляющие элементы плана, и формировать из них графические структуры. Расставляя такие элементы на экране и вычерчивая связи между ними, пользователь формирует мнемоническую схему управления потоками, которая обычно представляется в виде программы на каком-нибудь языке программирования.
На последующих этапах такие программы преобразуются в таблицы конечных состояний, хорошо известные специалистам в области теории вычислительных машин. Для любого текущего состояния системы такая таблица позволяет определить, в какое новое состояние перейдет система, получив определенный набор входных сигналов, и какой набор выходных сигналов при этом будет сформирован. В контексте той системы, которую мы рассматриваем, состояния — это планы лечения, а входные и выходные сигналы — это медицинские данные
10.3.4. Эффективность программы OPAL
При разработке прототипа системы ONCOCIN одной из наиболее сложных оказалась именно проблема приобретения знаний. Ввод информации, необходимой для создания протоколов лечения рака лимфатических узлов, занял около двух лет и отнял у экспертов около 800 часов рабочего времени. Формирование последующих наборов протоколов в процессе развития системы занимало, как правило, несколько месяцев. При этом было отмечено, что эффективность процесса приобретения знаний системой в решающей степени зависит от того, насколько успешно инженер по знаниям справляется с ролью переводчика в процессе передачи знаний от экспертов программе. Желание избавиться от этой зависимости и вдохновило разработчиков на создание программы OPAL, которая помогла бы автоматизировать процесс приобретения знаний.
Используя эту программу, эксперт может сформировать новый протокол в течение нескольких дней. За первый год эксплуатации программы OPAL в систему ONCOCIN было добавлено свыше трех дюжин новых протоколов. Эффективность использованного в этой программе метода заполнения формуляров при вводе новых знаний во многом объясняется тем, что в программу включены базовые знания о той предметной области, в которой она используется. Конечно, включение этих знаний потребовало значительных усилий от инженеров по знаниям, которые ранее занимались общением с экспертами, но эти затраты затем с лихвой окупились. Успешное применение программы OPAL показало преимущество представления знаний о предметной области на нескольких уровнях абстракции по сравнению с подходом, предполагающим переключение основного внимания на детали реализации.
Технология извлечения знаний о предметной области у эксперта посредством опроса через терминал в последнее время стала использоваться во множестве экспертных систем. В большинстве из них эксперту предлагается заполнить экранные формуляры, информация из которых затем считывается в структурированные объекты, аналогичные фреймам. Примерами таких систем могут служить ETS [Boose, 1986] и Student [Gale, 1986]. Но далеко не во всех системах такого рода имеется столь развитый графический интерфейс, как в программе OPAL, и существует возможность компилировать полученные знания непосредственно в правила принятия решений. Реализация этих возможностей в OPAL существенно облегчается особенностями структурирования планов лечения онкобольных, на что обращали внимание и авторы этой разработки.
Опыт, приобретенный в ходе разработки программы OPAL, был затем использован при создании PROTEGE — системы более общего назначения [Musen et al., 1995]. Последняя версия этой системы, PROTEGE-II, представляет собой комплект инструментальных средств, облегчающих создание онтологии предметной области и формирование программ приобретения знаний, подобных OPAL, для различных приложений. Вместо того чтобы разрабатывать инструментальные средства общего назначения с нуля, авторы этой разработки пошли по пути повышения уровня абстракции ранее разработанного и успешно используемого приложения, как это было сделано при разработке системы EMYCIN на основе MYCIN.
10.4. Приобретение новых знаний на основе существующих
Мы еще не раз будем возвращаться к теме приобретения знаний, поскольку это одна из главных проблем проектирования экспертных систем. Мы еще увидим, что уроки, полученные при попытках расширить область применения технологии экспертных систем в различных направлениях, имеют прямое отношение к проблеме приобретения знаний. В частности, в ходе экспериментов по созданию интеллектуальных обучающих систем на основе технологии экспертных систем исследователи пришли к более глубокому пониманию того, какими видами знаний пользуется эксперт в процессе решения проблем. При создании инструментальных средств общего назначения, аналогичных EMYCIN и предназначенных для построения широкого класса экспертных систем, разработчики столкнулись с интересной проблемой: как преобразовать знания, имеющие отношение к любой проблемной области, во фреймы или порождающие правила.
Такие попытки заставили исследователей глубже проанализировать роль знаний о предметной области и специфических для нее правил логического вывода, в частности рассмотреть их с точки зрения разных стилей рассуждения, характерных для разных областей.
Забегая немного вперед, отметим: совершенно очевидно, что процесс приобретения знаний в значительной мере облегчается, если он также основывается на знаниях. Другими словами, программа извлечения знаний нуждается в некоторых базовых знаниях о той предметной области, в которой специализируется интервьюируемый эксперт. И точно такими же знаниями должен обладать инженер по знаниям. Только в этом случае он сможет достичь взаимопонимания в диалоге с экспертом.
Вряд ли стоит надеяться на то, что со временем появится такая методика извлечения знаний у эксперта, которая будет одинаково эффективна в любой предметной области. Знания, которыми нужно обладать для того, чтобы воспринимать новые знания, можно рассматривать как метазнания. В основном к ним относятся знания о структуре и стратегии, включая информацию о методах классификации явлений и сущностей в определенной предметной области (например, заболеваний) и способах выбора альтернативных действий (например, курсов терапии). Существуют также и отдельные знания, необходимые для того, чтобы объяснить, почему получено именно такое, а не иное решение проблемы (об этом будет подробно рассказано в главе 16).
Извлечение знаний посредством опроса экспертов на основе модели предметной области — отнюдь не последнее слово в автоматизации этого процесса. В дальнейших главах мы рассмотрим два других подхода:
стратегии приобретения знаний, ориентированные на определенный метод решения проблем;
машинное обучение, базирующееся на построении правил индукции, на наборе показательных примеров.
Тема приобретения знаний будет доминирующей в следующих пяти главах. Вы познакомитесь со множеством методов, которым авторы дали весьма экзотические названия, — "эвристическая классификация", "сопоставление", "предложение и применение", "предложение и проверка" и т.п. Каждый из этих методов оказывается эффективным в определенных условиях и рассчитан на разную стратегию приобретения знаний.
Обсуждение проблем машинного обучения мы отложим до главы 20, поскольку это слишком сложный материал для той части книги, которую мы рассматриваем как вводную.
Рекомендуемая литература
В работе Ван Мелле [van Melle, 1981] подробно описана методика разработки систем на основе оболочки EMYCIN. Книга [Boose and Games, 1988] содержит подборку статей о методах приобретения знаний, включая и описание программы OPAL. Описание систем ETS и AQUINAS читатель найдет в работе [Boose and Bradshaw, 1987]. Обзор стратегий приобретения знаний, разработанных в 1980-х годах, включающий большой список источников, приводится в работах [Boose, 1989] и [Neale, 1988]. В статьях [Eriksson el al, 1995] и [Ти et al., 1995] читатель найдет подробное описание системы PROTEGE-II.
В Европе стандартом de facto в 1990-х годах стало использование при построении экспертных систем оболочки CommonKADS, хотя эксперименты с применением системы KADS проводились и в Соединенных Штатах (см., например, [Eriksson et al, 1995]}. Линстер и Мюсен также использовали CommonKADS для моделирования задач терапии раковых заболеваний, решаемых в экспертной системе ONCOCIN. Примеры модели проектирования на базе CommonKADS можно найти в ряде статей, опубликованных в последние годы, например [Kingston, 1995], [Kingston et al, 1995], [Kingston, 1997].
Упражнения
1. В состав документации, которая прилагается к большинству приборов и технических изделий, как правило, входят и руководства по поиску неисправностей. При отсутствии эксперта такие руководства можно с успехом использовать в качестве учебного материала для выполнения упражнений по извлечению знаний.
Например, руководство к пистолету "Кольт .45" включает шесть страниц советов, большинство из которых представлено в форме подобных таблиц.
Где?
Что?
Проверить
Примечание
Боек
Зажимается
Прямизну
При необходимости заменить
Эжектор
Неустойчивое выбрасывание
Зажимается ли возвратная пружина
Установить длинную направляющую
Экстрактор
Неправильно направляет гильзу
Угол установки дна
При необходимости выровнять
Для того чтобы разобраться в такой таблице, требуется обладать некоторыми знаниями о принципах работы описываемого устройства. В частности, нужно иметь представление о том, что
искривленный боек часто застревает в направляющей канавке, что приводит к осечке; такой боек нужно заменить;
возвратная пружина, которая зажимается внутри канавки, вероятнее всего, погнута; предотвратить такую поломку поможет замена стандартного короткого направляющего стержня полноразмерным;
неправильный угол установки экстрактора приводит к тому, что он выбрасывает гильзы обратно на стреляющего, а не вправо; эту неисправность можно устранить подгонкой и шлифовкой дна экстрактора.
Применение онтологического анализа позволяет систематизировать такое ознакомление. Самый верный путь к неудаче — приступить к записи диагностических правил до того, как будет понятен принцип работы устройства.
I) Выберите ту предметную область, которая вам более всего знакома, и разработайте для нее примерную онтологию в терминах:
ключевые сущности и отношения, такие как компоненты и отношения часть-целое;
предикаты предметной области, такие как неустойчивые, прямые, связывающие;
операции в предметной области, такие как замена, очистка, установка и т.п. II) Продолжите анализ предметной области и рассмотрите следующие вопросы:
насколько детальным должен быть анализ отношений часть-целое;
какие предикаты предметной области должны быть использованы для разбиения на части пространства признаков неисправностей;
какие логические отношения существуют между операциями в предметной области, например подобие между заменой и установкой (одна операция включает другую в качестве составляющей).
2. Реализуйте на языке CLIPS простую систему, основанную на правилах, которая будет выполнять функции консультанта по поиску неисправностей в устройствах из предметной области, выбранной вами при выполнении предыдущего упражнения. Используйте в качестве прототипа приведенную ниже программу.
;; #################################
;; # Поиск неисправностей в револьвере
;; # Smith & Wesson
;; #################################
;; Класс REVOLVER, определение компонентов (defclass revolver
(is-a INITIAL_OBJECT)
(slot barrel Jcreate-accessor read-write))
(slot barrel-pin
(create-accessor read-write))
(slot cyl-stop
(create-accessor read-write))
(slot cyl (create-accessor read-write))
(slot handspring
(create-accessor read-write))
)
;; Экземпляр класса REVOLVER.
;; Предназначен для тестирования программы,
(definstance guns (Ml9 of revolver
(barrel 4499)
(barrel-pin 4499)
(cyl-stop 4499)
(cyl 4499)
(handspring 5022)) )
;; МЕТОД . Получение номера детали револьвера
(def mas sage-handler revolver part-no (?part)
(dynamic-get ?part))
;; ПОЛЕЗНЫЕ ФУНКЦИИ
;; Приглашение пользователю ввести данные
(deffunctionprompt ()
(printout t crlf "USER> "))
;; Распечатка списка деталей.
;; Замечание: приведенный список правил касается
;; только неисправностей со стволом (barrel),
(deffunction parts-list () (printout t crlf
"barrel cylinder ejector trigger hammer
firing-pin cylinder-stop
cylinder-hand yoke
frame sideplate rear-sight front-sight" crlf))
;; Выбор из списка.
(deffunction choose-list ()
(printout t crlf "Please choose from the following list: "
crlf))
;; Правила, которые относятся только к
;; револьверам модели 19.
(deffunction kind-list ()
(printout t crlf "M10 M12 M13 M14 M15 M16 M17 M18 M19 "
crlf) )
;; ШАБЛОНЫ РЕШЕНИЯ ПРОБЛЕМЫ
;; Формулировка проблемы включает узлы (part),
;; симптомы (symptom), возможно, детали (subpart),
;; входящие в состав узлов. С проблемой может
;; быть связано определенное испытание или
;; проверка (check), которые нужно провести,
(deftemplate problem
(field part (type SYMBOL) (default nil))
(field symptom (type SYMBOL) (default nil))
(field subpart (type SYMBOL) (default nil))
(field check(type SYMBOL) (default nil)) )
определение процедуры ремонта включает узел (part), операцию с этим узлом (action), возможно, детали (subpart), входящие в состав узлов, проверку (check), которую нужно провести, и поясняющее примечание, предназначенное для пользователя, (deftemplate problem
(field part (type SYMBOL)
(default nil)} (field action (type SYMBOL)
(default nil)) (field subpart (type SYMBOL)
(default nil)) (field check(type SYMBOL)
(default nil)) (field remarkftype STRING)
(default " "))
)
;;########################
;;
;; Порождающие правила
;; Правило START.
;; ЕСЛИ: начинается выполнение программы
;; ТО: определить поврежденный узел и
;; сформировать шаблон описания проблемы,
(defrule start
?start-token <- (initial-fact) =>
(retract ?start-token)
(printout t crlf
"What part of the gun are you problem with?"
;; С каким узлом у вас проблемы?
(choose-list)
(part-list)
(prompt)
(bind ?part (read))
(assert (problem (part ?part))) )
;; Правило FINISH:
;; ЕСЛИ: Неисправность устранена
;; TO: Прекратить работу программы.
(defrule finish
(repair (check done) (remark ?rem&~" "))
=>
(printout t crlf ?rem crlf)
(printout t crlf "Glad to be of service! " crlf)
;; Рад быть вам полезным!
(halt) )
Правило CHECK-REPAIR:
ЕСЛИ: Имеется решение менее радикальное, чем
замена
ТО: Информировать пользователя и отметить, что неисправность (проблема) может быть устранена путем ремонта,
(defrule check-repair ?rep <-
(repair (part ?part) (action ?actions~replace)
(subpart ?sub&~nil&~?part))
(problem (part ?part) (symptom ?sym))
=>
(printout t crlf
"If you " ?action "the " ?sub "that should "
"fix the " ?sym "problem with the," ?part crlf)
;; "Если вы " ?action ?sub "то это' должно "
;; "устранить " ?sym "проблемы с " ?part crlf)
(modify ?rep (check done))
)
Правило CHECK-REPLACE:
ЕСЛИ:
Решение требует замены узла
ТО:
Информировать пользователя и отметить, что неисправность (проблема) устранена. Для этого добавить в рабочую память пустой вектор и запросить у пользователя наименование модели
;; изделия,
(defrule check-replace
(repair (part ?part) (action replace))
(not (model ?mod&~nil))
?prob <- (problem (part ?part)
(symptom ?sym)) =>
(printout t crlf
"You have to replace the "
?part "to fix the " ?sym "problem" crlf)
;; "Вам потребуется заменить" ?part
;; "чтобы устранить " ?sym "проблемы " crlf)
(assert (model nil)) )
;; Правило REPLACE:
;; ЕСЛИ: Пользователю необходимо заменить узел
;; ТО: Запросить у пользователя наименование
;; модели изделия,
(defrule replace
?rep <- (repair (action replace))
?mod <- (model nil) =>
(printout t crlf
"What model of revolver do you have ?" crlf)
;; "Какой модели ваш револьвер?"
(kind-list)
(prompt)
(bind ?answer(read))
(retract ?mod)
(assert (model ?answer))
(modify ?rep (check part-no))
)
;; Правило PART-NO:
;; ЕСЛИ: Пользователю необходимо заменить узел
;; ТО: Выяснить номер узла, отослав сообщение
;; объекту, представляющему данную модель
;; изделия,
(defrule part-no
(model ?mod£Tnil)
?rep <- (repair (part ?part)
(action replace) (check part-no)) =>
(bind ?no (send (symbol-to-instance-name ?mod)
part-no ?part))
(printout t crlf
"The part number of the " ?mod " " ?part "
is " ?no crlf) ;; "Номер узла " ?mod " " ?part ?no
(modify ?rep (check done)) )
;; Правила BARREL (ствол)
;; Правило BARREL-SYMPTOM
;; ЕСЛИ: Неисправность не имеет признаков
;; ТО: Выяснить признак (симптом),
(defrule barrel-symptom
?prob <- (problem (part barrel)
(symptom nil) (subpart nil))
=>
(printout t crlf
"Is there a problem inside barrel? " crlf)
;; "Есть ли повреждения внутри ствола?"
(prompt)
(bind ?answer(read))
(if (eq ?answer yes)
then (modify ?prob (subpart bore))
) )
;; Правило BARREL-INSIDE
;; ЕСЛИ: Имеется повреждение канала ствола
;; ТО: Выяснить у пользователя,
;; какое (и предложить помощь).
(defrule barrel-inside
?prob <- (problem (part barrel) (symptom nil) (subpart bore))
=>
(printout t crlf
"What is the problem inside the barrel? " crlf)
;; "Характер повреждения канала ствола?"
(choose-list) (printout t crlf "
leading rust jam" crlf)
;; " наличие ржавчины"
(prompt)
(bind ?answer (read))
(modify ?prob (symptom ?answer)) )
;; Правило BARREL-RUST
;; ЕСЛИ: Имеется ржавчина в канапе ствола
;; ТО: Проверить наличие раковин.
(defrule barrel-rust
?prob <- (problem (part barrel) (symptom rust) =>
(printout t crlf
"Are there pits inside the barrel? " crlf)
;; "Нет ли раковин в канале ствола?" (prompt)
(bind ?answer (read))
(if (eq ?answer yes) then (assert (repair
(action replace) (part barrel) (subpart bore))
(remark "Please consult your local dealer")))
;; Проконсультируйтесь с местным дилером
else (assert (repair
(action clean) (part barrel) (subpart bore))
(remark "Gun should be kept clean and dry"))
;; Оружие нужно содержать в чистоте и
;; предохранять от сырости
) )
;; Правило BARREL-LEADING
;; ЕСЛИ: Имеется налет свинца в канале ствола
;; ТО: Проверить качество патронов,
(defrule barrel-leading
?prob .<- (problem (part barrel) (symptom
leading) (check nil))
=>
(modify ?prob (check ammo))
(printout t crlf
"You may be using the wrong ammunition " crlf)
;; "Возможно, вы пользуетесь некачественными
;; патронами" )
;; Правило BARREL-LEADING-CHECK
;; ЕСЛИ: Имеется налет свинца в канале ствола
;; ТО: Проверить качество патронов,
(defrule barrel-leading-check
Pprob <- (problem (part barrel) (symptom
leading) (check ammo))
=>
(assert (repair (part barrel)
(action clean) (subpart bore)
(remark "Use Lewis Lead Remover"))
;; Воспользуйтесь средством для удаления свинца
;; фирмы Lewis )
Если посчитаете нужным, скопируйте из этой программы вспомогательные функции и структуры определения правил, но используйте знания из другой предметной области, которые были приобретены при выполнении предыдущего упражнения.
3. Рассмотрите ситуацию, которая возникает при планировании покупки какой-нибудь дорогостоящей вещи. Пусть, например, у вас появилась идея приобрести новый автомобиль. Эту проблему можно будет считать хорошо определенной только после того, как вы решите, какую сумму можно потратить на эту покупку, для каких поездок будет в основном использоваться новый автомобиль, какой изготовитель и какая модель для вас предпочтительны, и т.п. Для подобных упражнений можно использовать не только пример с автомобилем, но и с другими видами дорогостоящих покупок, — загородный дом, высококачественная электронная аппаратура и т.д. Далее уточните спецификацию покупки следующим образом.
I) Составьте список ключевых концепций и отношений между ними, которые нужно учитывать при решении проблемы. В случае с автомобилем такой список, очевидно, будет включать атрибуты фирмы-изготовителя и модели автомобиля, разнообразные эксплуатационные характеристики (мощность двигателя, расход топлива), связи между этими атрибутами и параметрами, определяющими ваш "стиль жизни", — частота и продолжительность поездок, предполагаете ли вы брать в поездку каких-либо экзотических попутчиков (лошадь или собаку) или необычный груз (например, лодку, домик на колесах) и т.п.
II) Попробуйте найти способ формального представления перечисленных концепций и отношений между ними. Например, изготовитель автомобиля и его модель могли бы быть выбраны из существующего набора классов — седан, спортивное авто, микроавтобус и т.д. Проанализируйте, не нужно ли при этом использовать многомерную классификацию концепций, при которой придется использовать множественное наследование.
III) Обратите внимание на важность учета приоритета разных свойств рассматриваемого объекта и необходимость использования средств разрешения конфликтов между ними. Если, например, хочется купить автомобиль, который, с одной стороны, имеет мощный двигатель, а с другой стороны, потребляет мало бензина, то нужно подумать над тем, как найти компромисс между этими противоречивыми требованиями.
4. Составьте на языке CLIPS несложную консультационную программу, которая помогла бы пользователю в решении проблемы целесообразности покупки, сформулированной при выполнении предыдущего упражнения. При разработке программы главное внимание нужно уделить тому, как представить сформулированные ранее концепции и отношения между ними в виде структур данных. Нужно также продумать и режимы управления, которые учитывали бы как структуру пространства состояний (например, способ классификации автомобилей), так и механизм обработки приоритетов свойств и разрешения конфликтов между ними.
5. До какого уровня детализации, по вашему мнению, можно спроектировать экспертную систему, не зная, как она будет внедряться? Какие опасности, по-вашему, подстерегают разработчика, который слишком рано принимает решение о способе внедрения экспертной системы?
ГЛАВА 11. Эвристическая классификация (I)
11.1. Классификация задач экспертных систем
11.2. Классификация методов решения проблем
11.2.1. Эвристическое сопоставление
11.2.2. Общность эвристической классификации
11.3. Классификация или конструирование?
Рекомендуемая литература
Упражнения
ГЛАВА 11. Эвристическая классификация (I)
11.1. Классификация задач экспертных систем
11.2. Классификация методов решения проблем
11.3. Классификация или конструирование?
Рекомендуемая литература
Упражнения
В предыдущей главе мы уже упоминали о том, что базовые компоненты экспертных систем, хорошо зарекомендовавшие себя на практике (машина логического вывода и подсистема представления знаний), могут быть использованы для построения аналогичных систем для других областей приложения. Так, архитектура оболочки EMYCIN явилась результатом дальнейшего развития принципов, положенных в основу ранней и узкоспециализированной системы MYCIN.
В этой главе мы рассмотрим вопросы применения тех методов решения проблем, которые используются на практике при построении экспертных систем разного назначения, и постараемся увязать характерные черты этих методов со спецификой областей применения. В идеальном случае хотелось бы получить ответы на следующие вопросы.
Можно ли классифицировать области применения экспертных систем на основе характеристик задач, решаемых в этой области?
Можно ли сформулировать хорошо дифференцированный набор методов решения проблем, которые приложимы для определенных классов областей применения?
Можно ли определить, какие стили представления знаний и правил логического вывода наиболее подходят для данного метода решения проблем?
Мы попытаемся дать ответы на эти вопросы, основываясь на том опыте построения экспертных систем, который накопило научное сообщество на сегодняшний день. Не следует ожидать, что эти ответы будут обладать исчерпывающей полнотой и четкой аргументацией, но, тем не менее, они представляют большой интерес как в теоретическом, так и в практическом плане. Если уж технология экспертных систем должна иметь солидный теоретический базис, то необходимо представлять себе, почему эта технология оказывается работоспособной при решении одних задач и неработоспособной при решении других. С практической точки зрения ответы на поставленные вопросы помогут разработчикам экспертных систем принять правильное решение и таким образом избавят их от крушения надежд и разочарования, которыми часто сопровождается ошибочный выбор. В этой главе читатель найдет следующий материал.
Сначала будет представлен критический обзор подходов к классификации задач экспертных систем, описанных в технической литературе.
Затем мы рассмотрим те методы решения проблем, которые в литературе объединены под общим названием эвристической классификации. Этим термином принято характеризовать поведение множества экспертных систем, ориентированных на выполнение таких задач, как диагноз и интерпретация данных.
В последних разделах будет проведено сравнение эвристической классификации с другими методами, пригодными для решения задач, оказавшихся не под силу эвристической классификации.
Противопоставление различных подходов, рассмотренное в заключительном разделе, в дальнейшем будет описано при более глубоком анализе различных методов в главах 12-15. В качестве примеров применения таких методов мы выбирали экспертные системы различного назначения, достаточно подробно описанные в литературе. Пользуясь такой методикой изложения, мы постараемся отыскать те более или менее общие схемы представления знаний и механизмы логического вывода, которые целесообразно применять для конкретных типов задач. В главах 18, 22 и 23 мы остановимся на более "экзотических" схемах и механизмах решения задач.
11.1. Классификация задач экспертных систем
В сборнике статей, опубликованном под общей редакцией Хейеса-Рота [Heyes-Roth et al, 1983], была предложена классификация экспертных систем, которая отражает специфику задач, решаемых с помощью этой технологии. С тех пор эта классификация неоднократно критиковалась различными авторами, в основном из-за того, что в ней были смешаны разные характеристики, а это привело к тому, что сформулированные категории нельзя рассматривать как взаимно исключающие. Тем не менее мы кратко представим эту классификацию и будем рассматривать ее как отправную точку для дальнейшего совершенствования.
Интерпретирующие системы предназначены для формирования описания ситуаций по результатам наблюдений или данным, получаемым от различного рода сенсоров. Типичные задачи, решаемые с помощью интерпретирующих систем, — распознавание образов и определение химической структуры вещества.
Прогнозирующие системы предназначены для логического анализа возможных последствий заданных ситуаций или событий. Типичные задачи для экспертных систем этого типа — предсказание погоды и прогноз ситуаций на финансовых рынках.
Диагностические системы предназначены для обнаружения источников неисправностей по результатам наблюдений за поведением контролируемой системы (технической или биологической). В эту категорию входит широкий спектр задач в самых различных предметных областях — медицине, механике, электронике и т.д.
Системы проектирования предназначены для структурного синтеза конфигурации объектов (компонентов проектируемой системы) при заданных ограничениях. Типичными задачами для таких систем является синтез электронных схем, компоновка архитектурных планов, оптимальное размещение объектов в ограниченном пространстве.
Системы планирования предназначены для подготовки планов проведения последовательности операций, приводящей к заданной цели. К этой категории относятся задачи планирования поведения роботов и составление маршрутов передвижения транспорта.
Системы мониторинга анализируют поведение контролируемой системы и, сравнивая полученные данные с критическими точками заранее составленного плана, прогнозируют вероятность достижения поставленной цели. Типовые области приложения таких систем — контроль движения воздушного транспорта и наблюдение за состоянием энергетических объектов.
Наладочные системы предназначены для выработки рекомендаций по устранению неисправностей в контролируемой системе. К этому классу относятся системы, помогающие программистам в отладке программного обеспечения, и консультирующие системы.
Системы оказания помощи при ремонте оборудования выполняют планирование процесса устранения неисправностей в сложных объектах, например в сетях инженерных коммуникаций.
Обучающие системы проводят анализ знаний студентов по определенному предмету, отыскивают пробелы в знаниях и предлагают средства для их ликвидации.
Системы контроля обеспечивают адаптивное управление поведением сложных человеко-машинных систем, прогнозируя появление возможных сбоев и планируя действия, необходимые для их предупреждения. Областью применения таких систем является управление воздушным транспортом, военными действиями и деловой активностью в сфере бизнеса.
Как уже упоминалось, множество исследователей отмечали наличие ряда существенных недостатков в приведенной классификации. Рейхгелт и Ван Гармелен обратили внимание на то, что некоторые из категорий в ней перекрываются или включают друг друга [Reichgelt and van Harmelen, 1986]. Например, категорию системы планирования в этой классификации вполне можно рассматривать как составную часть категории системы проектирования, поскольку планирование можно трактовать как проектирование последовательности операций (на это, кстати, обратили внимание и авторы классификации [Heyes-Roth et al, 1983]). Кленси также задался вопросом: "Является ли автоматизация программирования проблемой планирования или проектирования!" [Clancey, 1985]. Совершенно очевидно, что подобное замечание можно высказать и по отношению к таким категориям, как диагностические системы, системы мониторинга, системы оказания помощи при ремонте и обучающие системы.
Кленси предложил альтернативный метод классификации, взяв за основу набор родовых (generic) операций, выполняемых в рассматриваемых системах. Вместо того чтобы пытаться разделить анализируемые программы решения проблем по признакам особенностей тех проблем, на решение которых они ориентированы, он предложил поставить во главу угла те виды операций, которые выполняются по отношению к реальной обслуживаемой системе (механической, биологической или электрической).
Кленси предложил разделять синтетические операции, результатом которых является изменение структуры (конструкции) системы, и аналитические операции, которые интерпретируют характеристики и свойства системы, не изменяя ее как таковую. Эта обобщенная концепция может быть конкретизирована, в результате чего построена иерархическая схема видов операций, выполнение которых может быть затребовано от программы. На рис. 11.1 и 11.2 представлены такие иерархические схемы для аналитических и синтетических операций.
Рис. 11.1. Иерархия родовых аналитических операции ([Clancey, 1985])
Рис. 11.2. Иерархия родовых синтетических операции ([Clancey, 1985])
На рис. 11.1 показано, как различные виды операции Интерпретация соотносятся с понятием система. Операция Идентификация позволит выяснить, с системой какого типа мы имеем дело, используя в качестве объекта анализа пары сигналов "стимул/реакция". Если обслуживаемая система является системой управления, то операция Предсказание предоставит нам информацию о том, каких выходных сигналов (проявлений поведения системы) следует ожидать для определенного класса входных сигналов. Операция Управление, опираясь на известные характеристики системы, определяет, какие стимулы (входные сигналы) следует подать на ее вход, чтобы получить желаемую реакцию. Таким образом, три указанные разновидности операции Интерпретация перекрывают все возможные варианты неопределенности любого из членов множества {вход, выход, сиcтема} при известных двух других. Для систем, в которых существует неисправность, можно провести дальнейшую конкретизацию операции Идентификация. Операция Мониторинг определяет наличие отклонений в поведении, а операция Диагностирование выявляет причины этих отклонений.
Как показано на рис. 11.2, есть три варианта конкретизации операции Построение. Операция Спецификация задает ограничения, которым должна удовлетворять синтезируемая система. Операция Проектирование формирует структурную организацию компонентов, которая удовлетворяет заданным ограничениям, а операция Сборка реализует спроектированную систему, собирая воедино отдельные ее компоненты. Операция Проектирование, в свою очередь, разделяется на операции Конфигурирование (формирование структуры системы) и Планирование (формирование последовательности действий по созданию системы с заданной структурой).
Теперь посмотрим, как соотносится описанная ранее классификация экспертных систем с предложенной Кленси иерархической схемой операций.
Кленси относит интерпретацию к родовым операциям, таким образом, задача интерпретации "накрывает" любые другие задачи, в том или ином виде выполняющие описание обслуживаемой системы. В частности, выделенные в первой классификации задачи (категории экспертных систем) предсказание и управление теперь превращаются в разновидность задачи интерпретация.
Мониторинг и диагноз становятся вариантами задачи идентификации, которая, в свою очередь, является разновидностью задачи интерпретации. Задачу наладка можно включить в задачу диагноз, хотя частично она включает и задачу модификация (чтобы привести обслуживаемую систему в режим нормальной работы).
Проектирование остается базовой категорией, а обучение "поглощается" задачей модификация, так же, как и ремонт. Задача планирование превращается в один из вариантов задачи проектирование.
Как уже отмечалось, то внимание, которое мы уделяем вопросам классификации, объясняется не только любовью к отвлеченным теоретическим рассуждениям. В идеале мы стремимся к тому, чтобы иметь возможность отобразить множество методов решения проблем на множество задач. Тогда можно было бы сказать, какой из методов наиболее приемлем для любой заданной задачи. Вклад Кленси в этот вопрос — выявление определенного метода решения проблем, эвристической классификации, к рассмотрению которой мы сейчас и перейдем. Мы уделяем этому методу так много внимания по той простой причине, что он достаточно понятен и может быть использован для характеристики поведения множества систем, которые мы рассматривали в предыдущих главах
11.2. Классификация методов решения проблем
Классификация — это одна из наиболее распространенных проблем в любой предметной области. Например, эксперты в области ботаники или зоологии первым делом пытаются определить место в существующей таксономии для вновь открытого растения или животного. Как правило, система классов имеет явно выраженную иерархическую организацию, в которой подклассы обладают определенными свойствами, характерными для своих суперклассов, причем классы-соседи на одном уровне иерархии являются взаимно исключающими в отношении наличия или отсутствия определенных наборов свойств
11.2.1. Эвристическое сопоставление
Кленси отметил, что одна из важнейших особенностей классификации состоит в том, что эксперт выбирает категорию из ряда возможных решений, которые можно заранее перечислить. Когда мы имеем дело с простыми вещами или явлениями, то для их классификации вполне достаточно бросающихся в глаза свойств объектов. Это позволяет почти мгновенно сопоставлять данные и категории. В более сложных случаях таких лежащих на поверхности свойств может оказаться недостаточно для того, чтобы правильно определить место объекта в иерархической схеме классификации. В этом случае нам остается уповать на тот метод, который Кленси назвал эвристической классификацией. Суть его состоит в установлении неиерархических ассоциативных связей между данными и категориями классификации, которое требует выполнения промежуточных логических заключений, включающих, возможно, и концепции из другой таксономии.
На рис. 11.3 показаны три основных этапа выполнения эвристической классификации: абстрагирование от данных, сопоставление абстрактных категорий данных с абстрактными категориями решений (утолщенная стрелка) и конкретизация решения. Рассмотрим их по очереди.
Рис. 11.3. Структура логических связей при эвристической классификации ([Clancey, 1985])
Абстрагирование от данных. Часто бывает полезно абстрагироваться от данных, характеризующих конкретный случай. Так, при диагностировании заболевания зачастую важ_но не столько то, что у пациента высокая температура (скажем, 39.8°), а то, что она выше нормальной. То есть врач обычно рассуждает в терминах диапазона температур, а не в терминах конкретного ее значения.
Эвристическое сопоставление. Выполнить сопоставление первичных данных в конкретном случае и окончательного диагноза довольно трудно. Гораздо легче сопоставить более абстрактные данные и достаточно широкий класс заболеваний. Например, повышенная температура может служить индикатором лихорадки, наводящей на мысль о инфекционном заражении. Данные "включают" гипотезы, но на относительно высоком уровне абстракции. Такой процесс сопоставления имеет ярко выраженный эвристический характер, поскольку соответствие между данными и гипотезами на любом уровне не бывает однозначным и из общего правила может быть множество исключений. Анализ данных, которые "вписываются" в определенную абстрактную категорию, просто позволяет отбирать решения, лучше согласующиеся с абстрактами решений.
Конкретизация решений. После того как определена абстрактная категория, которая сужает пространство решений, нужно определить в этом пространстве конкретные решения-кандидаты и каким-то образом их ранжировать. Это может потребовать дальнейших размышлений, в которые включаются уже количественные параметры данных, или даже сбора дополнительной информации. В любом случае целью этой процедуры является отбор "соревнующихся" гипотез в пространстве решений и последующее их ранжирование — сортировка по степени правдоподобия.
Кленси различает три варианта построения абстрактных категорий данных.
Определительный. В этом варианте в первую очередь рассматриваются характерные признаки класса объектов, и он во многом напоминает таксономический подход в ботанике и зоологии.
Количественный. В этом варианте абстрагирование выполняется исходя из количественных характеристик, как это было сделано в упоминавшемся выше примере с температурой пациента.
Обобщение. Этот вариант основывается на иерархии характерных свойств. Например, пациенты, обладающие подавленной иммунной активностью, в более общем смысле могут рассматриваться как потенциальные носители инфекции.
На рис. 11.4 представлена эвристическая классификация в контексте программы медицинской диагностики MYCIN, которую мы обсуждали в главе 3.
Исходными являются данные анализа крови пациента (количество лейкоцитов). Сначала выполняется количественное абстрагирование от конкретного значения этого показателя, который оценивается как низкий, что, в свою очередь, является характерным признаком лейкопении (здесь мы имеем дело с определительным вариантом абстрагирования). Обобщение лейкопении — подавленная иммунная активность, а обобщение последней— повышенная склонность к переносу инфекции (т.е. такие пациенты более подвержены воздействию различных микроорганизмов). Повышенная склонность к переносу инфекции является уже родовой категорией и наводит на мысль о наличии инфекции, вызванной грамотрицательными микроорганизмами (т.е. инфекции, связанной с определенным классом бактерий). Затем это родовое решение конкретизируется и предполагается, что источником инфекции являются бактерии E.Coli.
В системе MYCIN сопоставление данных и абстрактных категорий решений выполняется с помощью порождающих правил, а эвристическая природа такого сопоставления выражается коэффициентами уверенности. Эти коэффициенты можно рассматривать как заложенную в порождающее правило меру "строгости" соответствия между предпосылкой и выводом. Другие правила затем будут уточнять выполненное сопоставление и таким образом "подстраивать" коэффициент уверенности
11.2.2. Общность эвристической классификации
Интересной особенностью методики анализа, предложенной Кленси, является то, что она подходит для большого спектра экспертных систем. Оказывается, что, несмотря на различие областей применения, многие экспертные системы функционируют, в принципе, одинаково. В своей статье Кленси продемонстрировал применение предложенной методики на множестве систем, помимо MYC1N.
Программа SAGON [Bennett et al., 1978] предназначена для выработки рекомендаций относительно использования программного пакета MARC, с помощью которого выполняется анализ характеристик механических систем методом конечных элементов. MARC — это достаточно сложный программный продукт, который предоставляет в распоряжение пользователей огромное количество опций. Разумное использование широких возможностей MARC представляет серьезную проблему для неопытных пользователей. Роль программы SAGON состоит именно в том, чтобы помочь таким пользователям. Программа формирует стратегию анализа, которая основывается на введенном пользователем описании компонентов.
Рис. 11.4. Структура логических связей в системе MYCIN ([Clancey, 1985])
Программа SAGON располагает знаниями о более чем 30 классах анализа. При определении типа анализа, наиболее подходящего для заданной пользователем проблемы, программа использует два этапа эвристического сопоставления, которые аналогичны описанным Кленси. Первый этап — выбор математической модели для оценки напряжений и деформаций при различных условиях, которая учитывает введенную пользователем информацию о геометрии моделируемой конструкции и нагрузках. Второй этап — выбор стратегии анализа этой модели, руководствуясь принципом наихудшего случая распределения напряжений и деформаций.
Оба этапа включают выбор из набора альтернативных вариантов и эвристическое сопоставление различных абстрактных категорий. Этап конкретизация решения отсутствует, поскольку на втором этапе определяются только подходящие классы программ из комплекта MARC, хотя формируемая стратегия анализа включает и рекомендации о выборе специфических функций из числа тех, которые имеются в MARC. В отличие от MYCIN, при сопоставлении не используются коэффициенты уверенности. Это объясняется тем, что за основу принят принцип наихудшего случая, который позволяет давать категоричные рекомендации даже в случае не совсем точного сопоставления.
Кленси обратил также внимание на то, что в большинстве экспертных систем используется не одна, а несколько родовых операций из тех, что представлены на рис. 11.1 и 11.2. В частности, процесс выработки рекомендаций о курсе лечения в системе MYCIN включает мониторинг состояния пациента, диагностирование категории заболевания, идентификацию микроорганизмов и модификацию состояния пациента (или состояния организма). Программа SACON идентифицирует типы структур, предсказывает в терминах математической модели, как такие структуры будут себя вести, и затем идентифицирует подходящий метод анализа.
В своей статье Кленси также проанализировал и систему SOPHIE ([Brown et ai, 1982]), предназначенную для поиска неисправностей в электронных схемах. Программа создавалась как инструмент для проведения исследований в области обучения с использованием компьютера, но включенный в ее состав модуль решения проблем способен классифицировать электронные схемы в терминах компонентов, которые вызывают неправильное функционирование схемы. Заранее пронумерованное пространство решений этого модуля содержит описания дозволенных и ошибочных пар вход/выход.
На рис. 11.5 схематически показано, каким образом структуру логического вывода в системе SOPHIE можно трактовать в качестве примера эвристической классификации. Результаты измерений в различных точках электронной схемы позволяют SOPHIE формировать количественные утверждения о поведении схемы, например о напряжении между двумя точками электрической цепи. Программа затем может преобразовать их в утверждения относительно качества функционирования схемы (например, слишком высокое напряжение), а последние эвристически сопоставляются с отказами на уровне модуля. Таким образом, в терминах задач анализа, представленных на рис. 11.1, можно говорить о том, что в системе SOPHIE выполняется мониторинг состояния схемы и диагностирование отказавших модулей и компонентов.
В системе COMPASS, описанной в предыдущей главе, также используется некоторая форма эвристической классификации как часть процесса декомпозиции проблем. При анализе отказов системы переключений телефонной сети программа сначала разбивает сообщения об ошибках на группы. Это можно рассматривать как этап формирования абстрактной категории данных в соответствии с методикой Кленси. Во-первых, такое разбиение необходимо, поскольку для идентификации отказа недостаточно единственного сообщения, а во-вторых, разбиение возможно, поскольку существует эвристика, позволяющая сопоставлять отказы с набором сообщений определенных групп. Но в этой системе можно найти и аналог этапа конкретизации, на котором устраняются неопределенности, остающиеся после группирования. Без неявной абстракции данных на этапе группирования не удалось бы сопоставить сообщения и отказы, а без последующего этапа конкретизации рекомендации, которые формирует система, были бы слишком расплывчаты и неконкретны.
Ценность предложенной Кленси методики анализа заключается в том, что она непосредственна связана с поиском ответов на сформулированные в начале этой главы вопросы. В частности, эта методика позволяет определить базовый метод решения проблем, который может быть с успехом применен в различных предметных областях. В следующей главе мы попытаемся четче обозначить различие между эвристической классификацией и другими методами и выделим тот класс проблем, по отношению к которым применение эвристической классификации наиболее целесообразно.
Рис. 11.5. Структура логических связей в системе SOPHIE ([Clancey, 1985])
Нужно отметить, что предложенная Кленси методика анализа фундаментальных аспектов решения проблем с помощью технологии экспертных систем не является единственной. Например, в работе [Chandrasekaran, 1986] получило дальнейшее развитие понятие родовой задачи (generic task). Родовая задача представляет собой, по сути, спецификацию задачи, включающую описание различных форм знаний о предметной области и их организации для выполнения задачи вручную и набор режимов выполнения задачи.
Примерами таких задач являются иерархическая классификация, сопоставление или оценка гипотез и передача информации, направляемая знаниями.
Задача иерархической классификации включает отбор гипотез из иерархически организованного пространства альтернатив, а затем уточнение этих гипотез с учетом' имеющихся данных. Гипотезами могут быть, например, заболевания или неисправности оборудования. Каждая такая гипотеза может быть порождена имеющимися данными, но прежде чем развивать ее дальше, необходимо выполнить определенные проверки или уточнить гипотезу таким образом, чтобы она соответствовала более широкому набору имеющихся фактов. Экспертные системы, в которых выполняются такие родовые задачи, мы рассмотрим в главах 13 и 16.
Под сопоставлением гипотез понимается выполнение количественной оценки свидетельств в пользу достоверности гипотез или того, насколько полным является соответствие между имеющимися данными и гипотезами. В такую оценку иногда включается априорная вероятность гипотез, поиск возможных конкурирующих гипотез и т.п. Все операции, связанные с обработкой коэффициентов уверенности в системе MYCIN, можно рассматривать как реализацию механизма родовых задач этого вида. Некоторые из этих тем мы рассмотрим в главе 12.
Передача информации, направляемой знаниями, проявляется в виде неочевидных логических связей, которые трудно классифицировать, но которые характерны для способа мышления эксперта. Например, врач не оставит без внимания тот факт, что пациент недавно перенес хирургическую операцию, поскольку, скорее всего, он подвергся анестезии, а это может косвенно сказаться на формировании диагноза. В логических рассуждениях такого типа используются "фоновые" знания о предметной области, а не те порождающие правила, с которыми мы связываем свое представление об экспертной системе медицинской диагностики. Ниже, в главе 12, мы обсудим дифференциацию разных видов знаний.
Итак, одно из отличий между подходами Кленси и Чандрасекарана состоит в том, что для первого характерно стремление разбить решение проблемы на мелкие абстрактные категории. Подход Кленси приводит к поглощению этапа сопоставления гипотез эвристической классификацией, в то время как Чандрасёкаран делает акцент на том, что обработка гипотез может рассматриваться как самостоятельная родовая задача со своими собственными правами вне контекста классификации. Таким образом, появляется проблема, до какого уровня "зернистости" целесообразно доводить абстрагирование и какие критерии следует выбрать для оценки этой "грануляции". Рассмотрение этих вопросов выходит за рамки вводного курса, однако те, кто собирается профессионально заниматься конструированием экспертных систем, должны не упускать из виду существование множества способов разрешения этих проблем.
11.1. Определение понятия "оружие нападения"
Под термином "оружие нападения" чаще всего понимаются различные виды полуавтоматического индивидуального стрелкового оружия, подобного тому, которое используется в профессиональной армии. Довольно трудно дать точное определение оружия нападения, из которого было бы ясно, чем отличается такое оружие от спортивного, например. Но в таком определении весьма заинтересованы законодатели на самых различных уровнях— федеральном, штата и местном. В сборниках законодательных актов можно встретить самые разные толкования этого термина. В контексте этой книги попытка сформулировать такое определение может быть хорошим примером эвристической классификации.
Определение, данное законодателями города Рочестер, шт. Нью-Йорк, включает пять частей. В первых трех специфицируются свойства стрелкового оружия, которые позволяют отнести его к категории оружия нападения. В части 4 просто перечисляются модели оружия, которые следует отнести к этой категории. В части 5 перечисляются типы огнестрельного оружия, которые не считаются относящимися к категории оружия нападения.
Можно считать, что в первых трех частях выполняется абстрагирование от данных, как, например, в этом предложении:
"Любая винтовка с центральным боем или охотничье ружье, в котором используется сила пороховых газов для перезаряжания после каждого выстрела и которое заряжается или может быть заряжено обоймой на 6 и более боеприпасов".
Этим определением "накрывается" большинство полуавтоматических винтовок и охотничьих ружей, оснащенных магазином, в который помещается более пяти патронов.
В части 4 перечисляются 17 моделей индивидуального стрелкового оружия, причем некоторые из них уже подходят под определение, которое дано в первых трех частях. Но некоторые модели отнесены к этой категории, несмотря на то, что они не обладают признаками, обозначенными ранее. В, частности, к таким моделям относится полуавтоматический пистолет с 30-зарядным магазином Gobray М11. Можно считать, что в этой части рассматриваются специальные случаи, не учтенные при составлении предыдущих трех.
Часть 5 можно рассматривать как аналог этапа конкретизация решения. В этой части некоторые из типов оружия, "подпадающие" под действие частей 1-3, исключаются из категории при наличии дополнительных признаков.
В разделе упражнений вы встретите набор правил на языке CLIPS, которые соответствуют определению, сформулированному в рассматриваемом документе.
11.3. Классификация или конструирование?
Отличительным признаком эвристической классификации является возможность заранее перенумеровать пространство решений. Так, при выполнении диагностической процедуры в системе MYCIN программа выбирает из фиксированного множества предлагаемых микроорганизмов. Но имеется множество задач, в которых не производится выбор в пространстве решений, а решение конструируется программой. Примером может служить программа формирования курса лечения, которая входит в состав MYCIN. Курс лечения представляет собой комбинацию назначенных больному препаратов и их дозировок. Можно, конечно, представить себе и таблицу, в которую включены все возможные комбинации препаратов и дозировок, но вряд ли такой подход будет целесообразным.
Конструирование решения для некоторой проблемы обычно требует наличия какой-либо модели структуры решения и поведения сложного объекта, который мы собираемся построить. В эту модель должно быть заложено знание об ограничениях, которым должен удовлетворять создаваемый объект, а именно: ограничения на конфигурацию компонентов решения, ограничения на значения входов и выходов любых процессов и ограничения на взаимодействие двух первых ограничений.
Например, при планировании действий робота, который должен достичь заданной цели, будут существовать ограничения, запрещающие выполнение определенных операций или последрвательностей операций. Это могут быть физические ограничения, предписывающие, как можно захватывать и размещать объекты (в главе 3 они называются пред- и постусловиями). Такие ограничения частично определяют временные ограничения на то, как связывать воедино операции захвата и размещения, т.е. они определяют конфигурацию компонентов решения. Нужно также уделить внимание и ограничениям на взаимные отношения между такими компонентами. Так, если ставится задача покрасить дом в течение одного дня, то скорее всего нужно начинать с покраски комнат, которые находятся на верхнем этаже.
Как Правило, такие проблемы сами по себе не приводят к решениям в терминах эвристической классификации. Пространство возможных последовательностей действий для открытой системы планирования является практически бесконечным, а потому вряд ли существует способ заранее определить все возможные варианты таких последовательностей и затем выбрать из них подходящее решение. В отличие от классификации, задача конструирования осложняется наличием комбинаторных перестановок возможных элементов решения. Таким образом, приходится сразу отказаться от ориентации на выбор решения из какого-либо подходящего класса и конкретизации его с помощью эвристического сопоставления.
Тем не менее очень важно учитывать предложенное Кленси разделение между задачами и методами решения проблем. Все диагностические задачи не являются проблемами классификации, поскольку при их решении может потребоваться создать новые классы отказов или модифицировать существующие, по мере того как будет накапливаться опыт работы с новыми устройствами. Аналогично, для задачи планирования в какой-то проблемной области может оказаться возможным организовать выбор из библиотеки планов или набора заготовок планов, как это делается в системе ONCOCIN (мы рассматривали ее в главе 10). Все зависит от того, какие ограничения накладываются в данной ситуации на процесс решения проблемы. Даже обычную задачу проектирования, например нового дома, можно решить несколькими способами. На одном конце диапазона стоит привлечение архитектора, который спроектирует дом с нуля (метод конструирования), а на другом — выбор проекта из каталога (метод классификации).
Кленси утверждает, что его работа может следующим образом, повлиять на исследования в области экспертных систем.
Она предоставляет в распоряжение исследователей инструмент для выполнения декомпозиции проблемы в набор операций, которые значительно легче классифицировать.
Разработка ианализ методик, аналогичных эвристической классификации, может послужить прелюдией к созданию специальных инструментальных средств инженерии знаний для этих целей.
Эта работа предоставляет проектировщикам экспертных систем базис для выбора областей приложения. Например, если оказывается, что проблема подходит для эвристической классификации, то имеются серьезные основания верить, что эту проблему можно решить с помощью технологии экспертных систем.
В следующей главе мы рассмотрим, как, используя концепции конструирования и эвристической классификации, можно взаимно увязать задачи, методы и инструментальные средства. В частности, мы остановимся на возможности использования такой методики анализа для целей автоматизации извлечения знаний
Рекомендуемая литература
Помимо тех работ, ссылки на которые приведены в тексте, существует и ранняя классификация подходов к решению проблем, выполненная Чандрасекараном [Chandrasekaran, 1983]. Теоретические аспекты классификации родовых задач были увязаны с проектом MDX [Chandrasekaran, 1984], в котором исследовались методы решения проблем применительно к области диагностики легочных заболеваний. Наиболее полное изложение подхода, предполагающего использование родовых задач, сопровождаемое комментариями и материалами дискуссии, читатель найдет в работе [Chandrasekaran, 1988].
Достаточно полное изложение результатов, полученных Кленси, можно найти в работе [Clancey, 1987, а, в]. Описание системы HERACLES, задуманной как прототип оболочки для исследования методики эвристической классификации, представлено в работе [Clancey, 1987,с].
Методика эвристической классификации была использована в системе KADS в качестве абстрактной модели экспертноети [Scheiber et al, 1993]. В настоящее время существуют KADS-модели и для других родовых задач, таких как мониторинг, конфигурирование, моделирование и т.д.
Упражнения
1. Проанализируйте классификацию задач, решаемых экспертными системами, которую предложил Хейес-Рот.
I) Как вы считаете, существуют ли задачи, которые не представлены в этой классификации?
II) В какую категорию систем этой классификации входит, по вашему мнению, система, которая консультирует пользователей относительно их юридических прав и выдает рекомендации о действиях в ходе судебного процесса.
2. Проанализируйте схему задач экспертных систем, предложенную Кленси (рис. 11.1 и 11.2).
I) Где в этой схеме, по-вашему, место для компьютерной системы обработки данных?
II) Можете ли вы предложить способ расширения или уточнения такого анализа? Например, можете ли вы предложить способ дальнейшей дифференциации задачи "Управление"?
3. Являются ли перечисленные ниже задачи по своему характеру задачами классификации, задачами конструирования или задачами, обладающими признаками обоих этих типов?
I) Принятие решения о том, какой курс дисциплин следует прослушать в колледже.
II) Принятие решения о том, как провести отпуск.
III) Изменение ранее составленного плана проведения отпуска вследствие непредвиденных обстоятельств.
IV) Подготовка налоговой декларации.
4. Ниже представлен список правил на языке CLIPS, который соответствует приведенному во врезке 11.1 определению термина "оружие нападения" (assault-weapon). Некоторые правила в этом наборе вам следует попытаться сформулировать самостоятельно.
;; Объявления (deftemplate gun
(field name (type SYMBOL))
(field class (type SYMBOL))
(field action (type SYMBOL))
(field caliber (type FLOAT))
(field capacity (type INTEGER))
(field feature (type SYMBOL))
)
(deftemplate assault-weapon
(field name (type SYMBOL)) )
;; Факты
;; Данный набор исходных правил квалифицируют
;; только модели Heckler & Kock 91 и Benelli
;; как "оружие нападения".
(deffacts guns
(gun (name Browning22)
(class rifle) (action semi)
(caliber .22) (capacity 11))
(gun (name CobrayMll)
(class pistol)
(action semi)
(caliber 9.0) (capacity 30))
(gun (name HK91) (class rifle)
(action semi) (caliber .308) (capacity 20))
(gun (name GlocklT) (class pistol)
(action semi) (caliber 9.0) (capacity 17))
(gun (name Mossberg) (class shotgun)
(action slide) (caliber .410)
(capacity 5) (feature pistol-grip))
(gun (name BenelliSuper90)
(class shotgun) (action semi)
(caliber 12.0) (capacity 5)
(feature barrel-shroud)) )
;; ПРАВИЛА
;; Общий случай
;; Любая полуавтоматическая
;; винтовка (semi-automatic rifle)
;; или охотничье ружье (shotgun) с емкостью
;; магазина более 5 патронов.
(defrule Parti
(gun (name ?N) (class ?Csrifle|shotgun)
(action semi) (capacity ?X&:(> ?X 5))) =>
(assert (assault-weapon (name ?N)))
)
;; Любая полуавтоматическая
;; винтовка (semi-automatic rifle)
;; или охотничье ружье (shotgun) с
;; перечисленными дополнительными признаками.
(defrule Part2
(gun (name ?N) (class ?C&rifle|shotgun)
(action semi)
(feature ?Fsflash-suppressor|barrel-shroud|night-scope)) =>
(assert (assault-weapon (name ?N)))
)
;; Любое охотничье ружье (shotgun) с пистолетной
;; рукояткой.
;; Сюда вставьте разработанное вами
;; самостоятельно правило pistol-grip.
;; Особые случаи
;; Модель Cobray Mil относится к категории
;; "оружие нападения".
;; Сюда вставьте разработанное вами
;; самостоятельно правило cobray.
;; Исключения
;; Модели, указанные пользователем, не относятся
;; к категории "оружие нападения", (defrule rimfire
?except <- (gun (name ?N) (class rifle)
(caliber .22)
?mistake <- (assault-weapon) (name ?N)) =>
(retract ?mistake) (retract ?except) )
;; К категории "оружие нападения" не относятся
;; охотничьи ружья со скользящим затвором
;;(slide-action shotgun).
;; Сюда вставьте разработанное вами
;; самостоятельно правило slide.
Правило cobray учитывает особый случай с моделью Cobray Mil. Включение в набор правила pistol-grip приведет к тому, что к категории "оружие нападения" будет отнесена и модель Mossberg, но затем уточняющее правило slide исключит эту модель.
5. Ниже приведен фрагмент программы Wine Advisor (Советчик для любителей вин) на языке CLIPS (программа разработана Рандом Вальцманом для системы Teknowledge OPS5). В программу вводится название блюда, а она предлагает список вин, рекомендуемых к этому блюду. Программа работает по принципу эвристической классификации, поскольку построена на предположении о наличии прямого соответствия между основными характеристиками блюда (например, из мяса или рыбы, типа приправ и т.п.) и классом рекомендуемых вин (в характеристики класса входит цвет, крепость, сахаристость и т.п.).
I) Ваша задача состоит в том, чтобы проанализировать представленный набор правил и принять решение о том, как организовать базу знаний о блюдах и винах, как поступать с неопределенностью, как переходить от одной стадии процесса логического вывода к другой. Комментарии в тексте программы помогут вам понять ее суть и укажут способ расширения ее возможностей. В случае необходимости пользуйтесь описанием языка CLIPS, приведенном в Приложении.
;; Шаблоны
(def template wine
(field property (type SYMBOL))
(field is (type SYMBOL))
(field cert (type FLOAT))
)
(def template meal
(field property (type SYMBOL))
(field is (type SYMBOL))
)
(deftemplate decision
(field re (type SYMBOL)) (field is (type SYMBOL))
)
;; Факты
(deffacts the-facts
(task dish) )
;; Порождающие правила в формате
;; (defrule <наименование_правила> <прав часть>
;; =>
;; <лев_часть> ).
;; ПРАВИЛА, КАСАЮЩИЕСЯ БЛЮД.
Эти правила соответствуют этапу абстрагирования данных.
Правило dish-type вызывается первым, поскольку оно устанавливает модель среды в соответствии с имеющимися фактами при перезапуске исполнительной системы CLIPS,
(defrule dish-type (initial-fact) (task dish) =>
(printout t crlf
"Is the main dish of the meal MEAT, FISH or POULTRY?"
;; Блюдо приготовлено из МЯСА, РЫБЫ или ПТИЦЫ?
t crlf) (assert (meal (property dish-type)
(is read)))) )
;; Правило meat собирает дополнительные сведения
;; о блюде, если известно, что оно приготовлено
;; из мяса, (defrule meat (task dish)
(meal (property dish-type) (is meat)) =>
(printout t crlf
"What kind of meat? For example STEAK, VEAL, LAMB."
;; Из какого мяса? Например, ГОВЯДИНА, ТЕЛЯТИНА, БАРАНИНА.
t crlf) (assert (meal (property meat-type)
(is read)))) )
Аналогичное правило fish для блюда из рыбы напишите самостоятельно. Это правило должно уточнять тип морского продукта, из которого приготовлено блюдо: свежая рыба, моллюски и т.п.
Разработайте и правило poultry для блюд из птицы.
;; ПРАВИЛА, КОТОРЫЕ ИМЕЮТ ДЕЛО С
;; ХАРАКТЕРИСТИКАМИ ВИН.
Эти правила соответствуют этапу эвристического сопоставления.
Правило steak является примером сопоставления вида мясного блюда с классом вин.
(defrule steak
?task <- (task dish) (meal
(property meat-type) (is steak)) =>
(assert (wine (property color) (is red)
(cert 1.0))) (assert (wine (property body) (is full)
(cert 1.0))) (assert (wine (property flavor) (is dry)
(cert 0.7))) (assert (wine (property flavor) (is sweet)
(cert 0.2))) (retract ?task)
(assert (task attributes)) )
;;Такие же правила можно написать и для других
;;видов мясных блюд: из телятины (veal),
;;баранины (lamb) и т.д.
;;Задача dish удалена, поскольку известно,
;;какого типа блюдо.
;;Затем устанавливается задача принятия решения
;;о характеристиках вина.
;;Для блюд из мяса, рыбы и птицы нужно
;;определить правила по умолчанию
;;(default rules), которые будут относиться к
;;любому типу соответствующего исходного
;;продукта (например, подходят и для блюда из
;;аллигатора, если последний отнесен
;;к мясным продуктам).
;;ПРАВИЛА РАБОТЫ С КОЭФФИЦИЕНТАМИ УВЕРЕННОСТИ
;;Если в модели среды существуют две структуры с
;;одними и теми же значениями для одних и тех же
;;атрибутов, но отличаются коэффициентами
;;уверенности, то правило
;;attribute-update создает из них третью
;;структуру с новым значением и удаляет две
;;исходные.
;;Новое значение коэффициента уверенности CF
;;вычисляется по формуле:
;;cf = cfl + с£2(1 - cfl)
(defrule attribute-update (task attributes)
?winel <- (property ?attribute) (is ?value)
(cert ?certl)) ?wine2 <- (property ?attribute) (is ?value)
(cert ?cert2)) (<> ?crtl ?cert2) =>
(bind ?newcert (+ ?certl ( ?cert2
(- 1 ?certl)))) (assert (wine (property ?attribute)
(is ?value) (cert ?newcert))) (retract ?winel) (retract ?wine2) )
;;Разработайте правило preference, к которому
;;следует обращаться только в том случае, если в
;;рабочей памяти существует больше одного
;;возможного значения для некоторого атрибута.
;;Это правило должно запросить у пользователя,
;;какое значение атрибута из существующих для
;;него предпочтительнее, соответственно
;;изменить коэффициент уверенности в выбранном
;;сочетании атрибут-значение, а другое значение
;;удалить из памяти.
;Разработайте правило choose-value, которое
;;будет активизироваться в том случае, если в
;;рабочей памяти существуют две структуры,
;;характеризуемые разными значениями одного и
;;того же атрибута. Правило должно
;;выбирать структуру, у которой коэффициент
;;уверенности больше, а другую удалять.
;Разработайте правило unique, которое будет
;;активизироваться в том случае, если существует
;;только одна структура с определенным значением
;;атрибута. Это правило объявляет, что атрибут
;;окончательно определен.
;Разработайте правило unity, которое будет
;;активизироваться в том случае, если существует
;;структура, обладающая коэффициентом
;;уверенности, равным 1.
;;Это правило объявляет, что атрибут
;;окончательно определен.
;;Если все атрибуты вина определены, вывести отчет,
(defrule all-attributes-done ?task .
<- (task attributes) ?col
<- (color done) ?bod
<- (body done) ?fla
<- (flavor done) (wine (property color)
(is ?color)) (wine (property body)
(is ?body)) (wine (property flavor)
(is ?flavor)) =>
(printout t crlf
"Try a " ?flavor " " ?color " wine with a " ?body " body"
;; "Попробуйте " ?f lavor " " ?color " вино с
;; " ?body " консистенцией."
t crlf)
(retract ?col) (retract ?bod) (retract ?fla)
(retract ?task) (assert (task brand)) )
;;ПРАВИЛА, ИМЕЮЩИЕ ОТНОШЕНИЕ К ВИНУ.
;;Выбор вина по заданному описанию значений ;атрибутов.
;;Правила этой группы соответствуют этапу
;;"конкретизация решения".
;;Прежде чем предложить пользователю выбрать
;;желаемый продукт, нужно сформировать список
;;кандидатов.
;;Разработайте правило go-choose, которое
;;выбирает вино с наивысшим рейтингом, если не
;;активизируются никакие другие правила,
;;дополняющие список вин.
;;Правило soave является примером правила
;;дополнения списка новым названием вина
;;(в данном случае "soave").
;;Разработайте другие аналогичные правила.
(defrule soave (task brand)
(wine (property color) (is white))
(wine (property flavor) (is dry)
(cert ?certl)) (wine (property body) (is fine)
(cert ?cert2)) =>
(assert (wine (property brand) (is soave)
(cert (min ?certl ?cert2))))
)
;; ПРАВИЛА, ОРГАНИЗУЮЩИЕ ВЫБОР ПОЛЬЗОВАТЕЛЕМ ИЗ
;; СПИСКА.
Пользователь отвечает на выводимый запрос вводом "yes" или "по".
Разработайте правило selection, которое выбирает вино с наивысшим рейтингом и предлагает его пользователю.
Разработайте правило rejection, которое активизируется после ввода пользователем отрицательного ответа на текущее предложение.
Правило acceptance завершает текущий сеанс работы с программой, (defrule acceptance
(task choice)
(decision (re ?candidate) (is yes))
=>
(printout
t crlf
"Sir/Madam has impeccable taste "
;; "Сэр/Мадам! У вас исключительно тонкий вкус! "
t crlf) (halt) )
II) Как можно изменить стратегию поиска, например не формировать сначала весь список, а предлагать пользователю вина сразу же после формирования очередного кандидата, причем создавать их в порядке "качества" вина?
ГЛАВА 12. Эвристическая классификация (II)
12.1. Инструментальные средства и задачи, решаемые экспертной системой
12.2. Эвристическая классификация в системах MUD и MORE
12.2.1. Модель предметной области выполнения буровых работ
12.2.2. Стратегии приобретения знаний
12.2.3. Использование коэффициентов уверенности в программе MORE
12.2.4. Опыт эксплуатации системы MORE
12.3. Совершенствование стратегий
12.3.1. Уроки проекта GUIDON
12.3.2. Структура задач в системе NEOMYCIN
Рекомендуемая литература
Упражнения
ГЛАВА 12. Эвристическая классификация (II)
12.1. Инструментальные средства и задачи, решаемые экспертной системой
12.2. Эвристическая классификация в системах MUD и MORE
12.3. Совершенствование стратегий Рекомендуемая литература Упражнения
Сейчас мы продолжим начатый в предыдущей главе анализ различий между задачами классификации и конструирования. Но теперь основное внимание будет сосредоточено на методах решения проблем, включая и различные способы представления знаний и реализации машины логического вывода. В частности, мы подробно рассмотрим типы инструментальных программных средств, наиболее подходящих для разработки систем эвристической классификации, примеры использования эвристической классификации в экспертных системах, более современных, чем MYCIN и EMYCIN, и увидим, каким образом сказывается обладание знаниями об используемых методах решения проблем на работе автоматизированных систем извлечения знаний.
Мы начали обсуждение методов решения проблем с эвристической классификации по той причине, что этот метод наиболее понятный. В следующих главах будут рассмотрены другие, более сложные методы, и вы сможете сравнить их.
Но в этой главе мы будем считать, что метод решения проблем выбран, а наша задача — проанализировать процесс выбора инструментальных средств для проектируемой экспертной системы и средств приобретения знаний.
12.1. Инструментальные средства и задачи, решаемые экспертной системой
В своей статье [Clancey, 1985] Кленси отметил, что хотя языки, базирующиеся на правилах, такие как EMYCIN, и не учитывают многих свойств предложенной им модели эвристической классификации, все же они являются достаточно подходящими инструментами для задач классификации, в частности задач диагностики. Хотя вразрез с рекомендациями Кленси ни система MYCIN, ни системы, базирующиеся на EMYCIN, не содержат специфических средств таксономии симптомов или признаков неисправностей, тот факт, что решения могут быть заранее пронумерованы, означает, что можно применить обратную стратегию построения суждений, т.е. строить логическую цепочку от абстрактных категорий решений к подходящим данным через промежуточный этап абстрагирования данных. Этот этап неявно включен в используемые правила. Тот факт, что выводы из набора правил индексируются в терминах медицинских параметров, на которые они ссылаются, позволяет без особого труда реализовать стратегию рассуждения от цели к средствам.
Ранее мы уже упоминали о таких особенностях MYCIN, как отказ от обратного прослеживания в пользу деструктивной модификации рабочей памяти и использование стратегии исчерпывающего поиска.
Эти две особенности MYCIN тесно увязаны. Нет необходимости использовать обратное прослеживание, поскольку мы неотступно следуем за множеством независимых свидетельств и на заключительной стадии ранжируем гипотезы. Если бы не использовалась стратегия достаточно исчерпывающего поиска, то потребовалось бы выполнять в той или иной форме обратное прослеживание, как это было показано в главе 2. Процесс обратного прослеживания требует больших затрат вычислительных ресурсов системы, так как приходится сохранять информацию о предыдущих этапах вычислений, к которым, возможно, придется еще возвращаться. Большой объем пространства состояний, в котором ведется поиск, требует значительных ресурсов памяти. На практике при этом используется механизм постраничного обмена между оперативной и дисковой памятью, что отрицательно сказывается на производительности системы в целом. Однако значительные вычислительные ресурсы отвлекаются на активизацию каждого потенциально подходящего правила, от чего приходится отказываться в некоторых системах. Во многих системах используется методика восхождение на гору, в которой принятие решения об использовании некоторого правила не может быть пересмотрено или отменено (см. главу 2). Иногда при этом может потребоваться использование локального обратного отслеживания (подробнее об этом — в главе 14 и в Приложении).
Такой простой режим управления редко используется при решении проблем конструирования. Проблемы проектирования и формирования конфигураций, как правило, требуют использования средств, характеризующихся наличием множества альтернативных способов решения, причем эти способы отнюдь не равноценны по качеству результата. Довольно часто приходится сталкиваться с ситуацией, когда отсутствует хорошая оценочная функция, которую можно было бы применить при поиске в пространстве состояний. Это объясняется тем, что качество проектирования определяется не только изолированными свойствами проектируемой конструкции и ее компонентов, но и глобальными параметрами, которые можно оценить только после завершения проектирования конечного продукта. Например, при решении задачи рациональной расстановки мебели в помещениях нужно принимать во внимание необходимость удовлетворения определенных ограничений и пожеланий: желательно письменный стол ставить вблизи окна, книжный шкаф размещать недалеко от письменного стола, диван ставить против телевизора и т.д. Но сформированные решения могут удовлетворять одним пожеланиям (ограничениям) и не удовлетворять другим, поскольку нужно удовлетворить какие-либо важные глобальные ограничения — оставить свободным проход через комнаты или обеспечить единообразную расстановку мебели.
В главах 14 и 15 мы еще познакомимся с дополнительными стратегиями управления поиском, которые приходится использовать в задачах конструирования. Сюда входят:
стратегия наименьшего принуждения (least commitment) — стремление отложить на будущее, насколько это возможно, принятие решений, ограничивающих свободу последующего выбора;
стратегия предложения и исправления (propose and revise) — стремление устранить нарушение сформулированных ограничений, как только такое нарушение обнаруживается;
различные виды обратного прослеживания, когда при обнаружении нарушения определенных условий пересматриваются только что принятые решения и выполняется откат в предшествующее состояние.
Отображение таких методов на множество типов решаемых задач — предмет дальнейших исследований.
Как бы там ни было, но для выбора подходящих инструментальных средств построения экспертных систем существенную роль играет идентификация уровня задач анализа, которая базируется на используемых методах решения проблем. Этот уровень, как правило, располагается между более высокими концептуальным и эпистемологическим уровнями и более низкими логическим и уровнем реализации, о которых шла речь в главе 10. Если не выполнить такую идентификацию, появляется опасность утраты обобщенных связей между типами задач и структурами логического вывода и языками представления знаний.
12.2. Эвристическая классификация в системах MUD и MORE
В этом разделе мы проанализируем последствия применения методики анализа, предложенной Кленси, к процессу приобретения знаний. Сначала будет рассмотрена экспертная система MUD, которая ориентирована на решение задач геологоразведки, в частности бурения скважин. Эта система является хорошим примером весьма эффективного использования метода эвристической классификации. Затем для этой системы будет описан прототип системы извлечения знаний, названный MORE, в котором стратегия приобретения знаний связывается с используемыми методами решения проблем.
Как и в системе MYCIN, в MOD процесс приобретения знаний в основном ориентирован на установление отображения множества данных на множество решений. Однако в системе MYCIN другие виды знаний, например иерархические отношения между данными и абстрактными категориями решений, эвристики раскрытия пространства состояний и т.п., представлены в наборе правил только неявным образом. Подход, использованный при создании MUD и MORE, делает эти знания более явными, и в этом смысле существует определенное сходство между этими системами и системой OPAL (см. главу 10). И там, и здесь используется промежуточное представление, которое играет роль модели предметной области
12.2.1. Модель предметной области выполнения буровых работ
Система MUD [Kahn and McDermott, 1984] предназначена для консультирования инженеров при проведении буровых работ на газонаполненных и текучих пластах. Основываясь на описании свойств пластов, система анализирует проблемы, возникающие при таком бурении, и предлагает способы их преодоления. Изменение свойств пластов, такое как внезапное увеличение вязкости в процессе бурения, может возникать вследствие самых различных факторов, например повышения температуры или давления или неправильной рецептуры смеси химических добавок.
Система MUD реализована с помощью языка описания порождающих правил OPS5 (предшественника CLIPS). Правила связывают изменения свойств пластов (абстрактные категории данных) с возможными причинами этих изменений (абстрактные категории решений). Ниже приведено одно из таких правил в переводе на "человеческий" язык.
ЕСЛИ:
(1) обнаружено уменьшение плотности пласта и
(2) обнаружено повышение вязкости,
ТО:
есть умеренные (7) основания предполагать, что имеется приток воды.
В формулировке таких правил числа в скобках — коэффициенты уверенности, которые при "сцеплении" правил комбинируются таким же способом, как и в системе MYCIN (подробнее об этом см. в главе 3). Таким образом, для того, чтобы определить достоверность предположения о проникновении воды, нужно принять во внимание все правила, которые "порождают" свидетельства за и против этой гипотезы. Мера доверия (или недоверия), связанная с каждым свидетельством, определяется способом, описанным в главе 9, а коэффициент уверенности в достоверности гипотезы является разностью между мерами доверия и недоверия.
Опыт, приобретенный Каном в процессе работы над этой системой, показал, что эксперты часто затрудняются сформулировать правила, приемлемые для подхода на основе эвристической классификации. Формат правила далеко не всегда соответствует способу мышления, привычному для экспертов, и способу обмена знаниями, принятыми в их среде. Определенные сложности вызывает и назначение коэффициентов уверенности в констатирующей части новых правил. При этом обычно приходится пересматривать сформулированные ранее правила и сравнивать имеющиеся в них значения коэффициентов. Очень часто эксперты используют коэффициенты уверенности для частичного упорядочения в отношении определенного "заключения. Бучанан и Шортлифф [Buchanan and Shortliffe, 1984, Chapter 7] также отмечали, что экспертам иногда для правильной формулировки правил нужно располагать довольно подробной информацией о режиме применения правил и распространении значений коэффициентов уверенности в процессе их "сцепления".
При проектировании программ эвристической классификации, таких как MUD или MYCIN, процесс уточнения правил является, по существу, шестиэтапным.
(1) Эксперт сообщает инженеру по знаниям, какие правила нужно добавить или изменить.
(2) Инженер по знаниям вносит изменения в базу знаний системы.
(3) Инженер по знаниям запускает на выполнение программу, вводит данные, которые ранее уже обрабатывались прежним набором правил, и проверяет таким образом полноту нового набора.
(4) Если при обработке новым набором правил ранее проверенных исходных данных возникают какие-либо проблемы, инженер по знаниям обсуждает способы их преодоления с экспертом и далее повторяется этап 1.
(5) Эксперт запускает систему и вводит новый вариант данных.
(6) Если при обработке нового варианта не возникает никаких проблем, можно считать очередной сеанс внесения изменений в правила завершенным. В противном случае повторяется вся процедура начиная с 1-го этапа.
Как было показано в главе 10, именно такой базовый алгоритм внесения изменений в базу знаний используется в системе MYCIN, а для повышения эффективности выполнения отдельных этапов применяются разнообразные инструментальные средства, в частности язык сокращенного описания правил из состава оболочки EMYCIN, библиотека тестовых наборов данных, средства выполнения тестовых примеров в пакетном режиме и т.п.
Кан и его коллеги пошли по другому пути [Kahn et al, 1985], [Kahn, 1988]. Они применили программу извлечения знаний MORE, которая использует для обновления базы знаний MUD как знания о предметной области, так и знания о стратегии решения проблем. Как и OPAL, программа MORE располагает моделью предметной области, в которой представлены основные отношения между базовыми концепциями. Эти знания используются для организации опроса экспертов, обнаружения ошибок при назначении коэффициентов доверия и для генерации правил, на основании которых выполняется эвристическая классификация.
В программе MORE модель предметной области состоит из следующих компонентов:
симптомы, т.е. явления, которые можно наблюдать в процессе проведения диагноза; появление этих явлений и должна объяснить система;
атрибуты, которые являются средством детализации симптомов, например резкое возрастание или снижение значения какого-либо параметра;
события, которые являются возможным следствием симптомов и таким образом могут рассматриваться в качестве гипотез;
фоновые условия, позволяющие судить о большей или меньшей вероятности наличия связи между обнаруженными симптомами и теми или иными гипотетическими причинами их появления;
тестовые процедуры, которые можно использовать для обнаружения наличия или отсутствия упомянутых выше фоновых условий;
условия выполнения тестовых процедур, способные повлиять на точность результатов тестирования.
Эти знания организованы в виде сети, в которой явно обозначены связи между симптомами и возможными причинами их появления, а также связи между условиями и теми состояниями или событиями, на которые эти условия могут повлиять. На рис. 12.1 представлен фрагмент сети представления модели предметной области, в которой используется система MUD.
Загрязнение сланцами и приток воды — это гипотезы, объясняющие появление четырех симптомов: понижение давления внутри пласта, повышение доли твердых включений, повышение уровня содержания неэмульсионной воды и повышение вязкости. Все они являются свойствами вязких и жидких пластов, на которых может сказаться загрязнение теми или иными компонентами при выполнении буровых работ. Обратите внимание, что на этой схеме некоторые линии причинно-следственных связей параметризиро-ваны степенью влияния на симптом. ТСМ— это тест синевы метилена, который проверяет повышение количества твердых включений в вязких пластах, а используется масляная эмульсия — фоновое условие, которое может сказаться на связи между притоком воды и повышением уровня содержания неэмульсионной воды.
Рис. 12.1. Фрагмент модели предметной области, которая используется в программе MORE
12.1. Диагностические правила в М U D
Ниже приведены некоторые диагностические правила для той предметной области, на которую ориентирована система MUD. Правила, реализованные в виде программы на языке CLIPS, описывают те же причинно-следственные связи, что и на рис. 12.1. Если вы запустите эту программу на выполнение и ответите на оба вопроса утвердительно, то программа придет к заключению, что возможны два варианта объяснения наличия указанных симптомов— и загрязнение сланцами, и приток воды. Если на один из вопросов ответить отрицательно, то программа отдаст предпочтение одной из гипотез.
;; ШАБЛОНЫ (deftamplate symptom
(field datum (type SYMBOL))
(field change (type SYMBOL))
(field degree (type SYMBOL) (default NIL))
)
(deftamplate hypothesis
(field object (type SYMBOL))
(field event (type SYMBOL))
(field status (type SYMBOL) (default NIL))
(deftemplate testing
(field name (type SYMBOL))
(field for (type SYMBOL))
(field status (type SYMBOL) (default NIL)) )
;; ФАКТЫ
(deffacts mud
a(symptom (datum viscosity)
(change increase))
(symptom (datum density)
(change decrease) (degree gradual))
(testing (name МВТ)
(for low-SG-solids))
(testing (name oil-mud)
(for unemulsified-water))
)
;; ПРАВИЛА
;; Правило обратного вывода, принимающее во внимание
;; вязкость (viscosity).
(defrule viscosity (symptom
(datum viscosity) (change increase))
=>
(assert (hypothesis (object low-SG-water)
(event increase))) (assert (hypothesis
(object unemulsified-water) (event increase)))
)
;; Правила обратного вывода, принимающие во внимание
;; плотность (density). (defrule density :
(symptom (datum density)
(change decrease) (degree gradual))
=>
(assert (hypothesis (object shale)
(event contamination)))
)
(defrule density
(symptom (datum density) (change decrease)
(degree rapid)) =>
(assert (hypothesis (object water) (event influx»)
)
;; Свидетельства в пользу загрязнения сланцами
(shale contamination) (defrule shale ?effect
<- (hypothesis (object low-SG-water)
(event increase)
(status yes)) => (assert (hypothesis
(object shale) (event contamination)
(status yes)))
(modify ?effect (status done)) )
;; Свидетельства в пользу притока воды (water influx)
(defrule water ?effect <- (hypothesis
(object unemulsified-water)
(event increase) (status yes)) =>
(assert (hypothesis (object water)
(event influx)
(status yes))) (modify ?effect
(status done))
)
;; Поиск теста гипотезы (defrule peek-test
(hypothesis (object ?obj) (event ? change))
?operator <- (testing (name ?name)
(for ?obj) (status NIL)) =>
(printout
t crlf
"Is there " ?obj " " ?change " according to the "
?name " test? "
;; "Существует " ?obj " " ?change " в соответствии с " ,
;; " тестом " ?name " ? "
) ;; (modify ?operator (status (read)))
)
;; Применить результат теста к гипотезе.
{defrule poke-test
?cause <- (hypothesis (object ?obj)
(event ?change))
?operator <- (testing (name ?name)
(for ?obj) (status yes))
=>
(modify ?cause (status yes)
(modify ?operator (status done))
)
; ; Вывести активную гипотезу.
(defrule show-and-tell
(hypothesis (object ?obj)
(event ?ev) (status yes))
=>
(printout
t crlf
?obj " " ?ev "is a possibility. " t crlf
;; ?obj " " ?ev " является вероятной. "
)
12.2.2. Стратегии приобретения знаний
Кан и его коллеги атаковали проблему извлечения знаний с двух направлений. С одной стороны, в процессе проектирования системы MUD они совершенствовали методику опроса экспертов инженерами по знаниям. С другой стороны — проанализировали используемую методику в терминах метода решения проблем с помощью эвристической классификации, который используется в MUD. В результате были выделены восемь вариантов стратегий извлечения знаний, которые перечислены ниже. Каждый из вариантов стратегии используется программой MORE для подтверждения или опровержения гипотез в процессе диагностирования.
Дифференциация. Поиск симптомов, позволяющих разделить гипотезы, например симптомов, которые могут иметь единственную причину. Такое взаимно однозначное соответствие между симптомом и явлением, его вызвавшим, в медицинской литературе называется патогенетической (pathognomic) ассоциацией.
Частотное упорядочение условий. Определение тех фоновых условий, которые влияют на степень правдоподобности конкретных гипотез. Если подходить к задачам диагноза с точки зрения теории принятия решения, то степень поддержки конкретной гипотезы об источнике неисправности, которую вносит определенное свидетельство (симптом), зависит от априорной вероятности этой неисправности.
Отчетливость симптомов. Идентификация тех свойств симптомов, которые могут являться индикаторами лежащих в глубине причин появления этих симптомов. Так, в схеме на рис. 12.1 видно, что резкое повышение плотности пласта является довольно отчетливым индикатором наличия притока воды.
Установление связи между симптомами и условиями. Отыскание таких условий, при которых можно рассчитывать на то, что разные симптомы проявятся сами по себе при данной неисправности. Такие ожидания могут служить для опровержения гипотез, если они не получили подтверждения.
Разделение пути. Попытка найти такие промежуточные события между гипотезами о причинах неисправности и вероятными симптомами, которые имеют более высокую условную вероятность, чем сами симптомы. Если такие промежуточные события не фиксируются в процессе диагностирования, то это может служить более серьезным доводом против данной гипотезы, чем отсутствие симптома.
Дифференциация путей. Как и в случае разделения пути, анализируется "траектория" причинно-следственных связей между симптомами и неисправностями. В процессе этого анализа стараются выявить такие промежуточные события, которые позволят провести разделение неисправностей, имеющих одинаковые симптомы.
Дифференциация тестирования. Определение степени доверия к результатам тестирования. Свидетельство, как правило, является результатом тестирования, а последнее может быть охарактеризовано различными значениями степени достоверности.
Установление связи между тестированием и условиями его проведения. Определение фоновых условий, которые могут сказаться на степени достоверности результатов тестирования. Такая информация влияет на оценку результатов текущих наблюдений для анализируемого случая.
Извлечение знаний с помощью программы MORE начинается с получения от эксперта знаний о базовых неисправностях (патологиях) и связанных с ними симптомах. Затем программа избирательно активизирует указанные выше стратегии приобретения знаний, базируясь на тех знаниях, которые приобретены на предыдущих стадиях. Чтобы понять механизм выбора стратегий, рассмотрим процесс приобретения знаний с помощью MORE более подробно.
В той предметной области, на которую ориентирована программа MORE, существуют три типа порождающих правил.
Диагностические правила описывают соответствие между симптомами и гипотезами. Правила такого типа имеются во многих экспертных системах — MYCIN, ONCOCIN, MUD и т.п.
Правила оценки степени достоверности симптомов. С помощью этих правил выполняется неявная качественная оценка абстрактных категорий данных в пространстве симптомов, которая опирается на уровень достоверности результатов тестирования при различных фоновых условиях.
Правила оценки степени правдоподобности гипотез позволяют провести неявную качественную оценку абстрактных категорий решений в пространстве гипотез. При этом оценивается априорная вероятность гипотез при различных фоновых условиях.
Отличительной чертой диагностических правил, которые используются в системе MUD, является наличие двух коэффициентов доверия — положительного и отрицательного. Положительный коэффициент отображает степень поддержки заключения данным правилом при соблюдении сформулированных в нем условий, а отрицательный— степень "опровержения" заключения данным правилом, если сформулированные в правиле условия не соблюдаются. В правилах, относящихся к двум другим группам, используется только один коэффициент. В правилах оценки степени достоверности симптомов значение коэффициента несет информацию об изменении степени достоверности определенного симптома, которое вносится данным правилом. В правилах оценки степени правдоподобности гипотез значение коэффициента определяет изменение степени правдоподобия гипотезы, которое вносится при выполнении условий, специфицированных в данном правиле.
Программа MORE работает с двумя видами моделей — моделью событий и моделью правил. Модель событий охватывает симптомы, гипотезы и условия и связи между ними, как показано на рис. 12.1. В MORE это представление используется для формирования порождающих правил, в отличие от программы OPAL, в которой правила формируются на основании модели предметной области.
Если быть точным, то программа MORE генерирует целое семейство диагностических правил по одному на каждую гипотезу. Например, прямо из модели событий MUD программа MORE может сформировать следующее диагностическое правило:
[Правило 1]
ЕСЛИ обнаружено повышение уровня хлоридов,
ТО существует солевое загрязнение.
Но это правило является слишком общим. Ему нужно дать качественную оценку, например с помощью стратегии отчетливости симптомов. Эта оценка позволит учесть эффект влияния фоновых условий на степень важности симптома. Таким образом, в семейство правил солевое загрязнение может быть добавлено следующее правило:
[Правило 2]
ЕСЛИ обнаружено повышение уровня хлоридов и пласт недостаточно насыщен,
ТО существует солевое загрязнение.
Программа MORE работает с семействами правил следующим образом. Когда программа "изучает" новые условия, имеющие отношение к некоторой гипотезе, она создает новое правило с единственным условием в левой части и добавляет его в семейство правил этой гипотезы. Если же новое условие имеет отношение и к другим правилам, ранее включенным в это же семейство, то в них также добавляется это условие. (Если новое условие не совместимо с другими, указанными в одном из правил семейства, то такое правило не изменяется.) Правила, в которые добавляется новое условие, называются составными правилами (constituent rules). О них мы поговорим в следующем разделе, когда будем рассматривать коэффициенты уверенности.
Приведенный пример применения стратегии отчетливости симптомов показывает, как с помощью той или иной стратегии извлечения знаний выполняется уточнение сформулированных правил. Стратегия отчетливости симптомов используется тогда, когда в семействе не оказывается правил с отчетливо выраженным положительным коэффициентом доверия. Приведенное выше исходное правило было слишком общим, а потому ему нельзя было назначить высокий коэффициент доверия. Поскольку на начальном этапе это правило является единственным в семействе, для его уточнения и активизируется стратегия отчетливости симптомов. Чаще всего, после того как формулируются другие правила семейства, в которых специфицируются различные фоновые условия, такие общие правила удаляются из семейства. Такое удаление можно рассматривать как стремление отдавать предпочтение специализированным правилам, а не более общим, на чем основаны некоторые стратегии разрешения конфликтов.
Стратегия установление связи между симптомами и условиями используется в том случае, если в семействе отсутствуют правила с отчетливо выраженным отрицательным коэффициентом доверия. В таких случаях программа MORE предпринимает попытку выявить те фоновые условия, которые позволяют более отчетливо проявиться симптому какой-либо определенной гипотезы. Знание условий, при которых повышается вероятность проявления симптома, позволяет компоненту решения задач отбрасывать часть гипотез, для которых наиболее показательные симптомы отсутствуют.
Другие стратегии — дифференциация, дифференциация путей и разделение пути — используются для создания новых семейств правил. Стратегия дифференциации задейст-вуется в тех случаях, когда программа обнаруживает пару гипотез, не имеющих отличающихся симптомов. В этом случае на схеме модели событий, аналогичной приведенной на рис. 12.1, возникает ситуация, когда для пары гипотез Н1 и H2 не оказывается ни одного симптома, который имел бы связь с Н1 но не имел связи с H2, или наоборот. Используя стратегию дифференциации, программа MORE пытается выяснить у эксперта, какой еще симптом можно добавить в набор и с его помощью устранить неоднозначность. Этот новый симптом добавляется затем в модель событий и связывается с определенными гипотезами. Таким образом модель уточняется до тех пор, пока не появится возможность сформировать отдельные семейства правил для гипотез Н1 и H2
Стратегия дифференциации путей выбирается в том случае, если в модели событий некоторый симптом оказывается связан с двумя разными гипотезами. В этой ситуации программа MORE пытается выяснить у эксперта, существует ли какое-либо промежуточное событие, которое, с одной стороны, может послужить причиной появления такого симптома, а с другой, может возникнуть только в том случае, когда правдоподобна одна из "конкурирующих" гипотез и неправдоподобна другая. Включение такого события в модель поможет разделить существующие объяснения появления такого симптома, а соответственно и уточнить связанные с ними правила.
К стратегии разделения пути программа обращается в том случае, если в семействе правил некоторой гипотезы обнаруживается отсутствие правила, которое связало бы высокое значение отрицательного коэффициента доверия с отсутствием какого-либо симптома. В этой ситуации программа MORE пытается выяснить у эксперта, существует ли какое-либо промежуточное событие, причиной которого могла бы быть данная гипотеза. Если такое событие существует, то тот факт, что оно не наблюдается, может с большей очевидностью свидетельствовать против данной гипотезы, чем тот факт, что симптом не наблюдается. В результате можно создать новое семейство правил для гипотезы.
Остальные стратегии — частотное упорядочение условий, дифференциация тестирования и установление связи между тестированием и условиями его проведения — активизируются в случаях, когда в семействе обнаруживается отсутствие правил с достаточно высоким или достаточно низким значением положительного или отрицательного коэффициента доверия. В таком случае правила нельзя считать достаточно информативными для решения проблемы классификации. Получение от эксперта информации о новых тестовых процедурах и условиях их выполнения, а также оценок априорной вероятности гипотез при различных фоновых условиях позволит либо увеличить, либо уменьшить коэффициенты в правилах, связывающих симптомы и гипотезы. Информация первого типа используется для корректировки правил оценки степени достоверности симптомов, а информация второго типа — для корректировки правил оценки степени правдоподобности гипотез.
12.2.3. Использование коэффициентов уверенности в программе MORE
Выше уже не раз обращалось внимание на тот факт, что эксперты зачастую испытывают серьезные затруднения при назначении коэффициентов уверенности конкретным правилам. Прежде чем назначить коэффициент новому правилу, эксперты любят просмотреть уже сформулированные и сравнить установленные в них значения с тем, которое планируется присвоить новому правилу. Они стараются добиться взаимной увязки всех сформулированных правил как в отношении степени важности отдельных свидетельств, так и в отношении "крепости" ассоциативных связей между свидетельствами и гипотезами. Как помочь эксперту решить эту задачу?
Определенную помощь в этом эксперту может оказать программа MORE, которая формирует предположительные значения коэффициентов, основываясь на ранее введенных правилах, и предлагает их эксперту. Если введенное экспертом значениеигнорирует предложенные программой, то выводится предупреждающее сообщение для инженера по знаниям, в котором программа приводит свои соображения относительно обнаруженного противоречия. После этого пользователь имеет возможность воспользоваться набором опций и устранить противоречие между параметрами нового правила и ранее созданных.
Программа MORE формирует предположительные значения коэффициентов следующим образом.
Предположим, что неисправность D проявляется в виде симптома S1 а появление симптома S1 влечет за собой и появление симптома S2. В таком случае программа MORE предполагает, что отрицательный коэффициент уверенности, назначенный правилу, которое связывает симптом S1 с гипотезой D, будет больше или равен отрицательному коэффициенту, назначенному правилу, которое связывает симптом S2 с гипотезой D. В схеме модели событий на рис. 12.2 ожидается, что С1=> С2. Здесь коэффициентом С, оценивается связь между симптомом S1 и гипотезой D, а коэффициентом С2 — связь между симптомом S2 и гипотезой D.
Почему предполагается такое соотношение между значениями коэффициентов, интуитивно понятно. Если отсутствие симптома S1 является более веским аргументом против гипотезы D, то отсутствие симптома S2 не меняет положения дел. Если вновь вернуться к модели событий на рис. 12.1, то отрицательная связь между притоком воды и повышением уровня содержания неэмульсионной воды должна быть более "сильной", чем связь между притоком воды и повышением вязкости.
Диагностическая значимость симптома является величиной, обратной количеству гипотез, в которых учитывается наличие этого симптома. В модели событий, схема которой представлена на рис. 12.3, программа MORE предполагает, что С1 > С2, поскольку появление симптома S1 может быть вызвано только неисправностью (гипотезой) D1, a появление симптома S2 может быть вызвано и другими неисправностями.
Рис. 12.2. Отрицательные коэффициенты достоверности в цепочке причинно-следственной связи
Рис. 12.3. Положительные коэффициенты достоверности в случае множественной связи симптома с гипотезами
Программа MORE также оценивает и отношения между значениями коэффициентов в правилах одного семейства (т.е. в правилах, делающих одинаковое заключение или, что то же самое, относящихся к одной и той же гипотезе). Например, если в семейство правил добавляется новое условие проявления симптома, которое увеличивает условную достоверность симптома, это скажется на тех правилах, которые имеют большие отрицательные значения коэффициентов, чем составные правила. (Напомним, что составными называются правила, расширенные при добавлении нового условия.) Рациональность этих предположений заключается в том, что чем больше мы рассчитываем на появление определенного симптома при данной гипотезе (при данной неисправности), тем сильнее будет наше недоверие к этой гипотезе при отсутствии такого симптома.
Каждое из таких предположений основано на стремлении сохранить взаимную согласованность коэффициентов в правилах одного семейства.
12.2.4. Опыт эксплуатации системы MORE
В одной из своих ранних работ, посвященных созданию системы MYCIN, Шортлифф обратил внимание на необходимость разработки такого механизма извлечения знаний, который помогал бы эксперту назначать порождающим правилам коэффициенты уверенности [Shortliffe, 1976]. В сборнике [Buchanan and Shortliffe, 1984, Chapter 10, Section 5] собрано множество статей, в которых обсуждается ряд вопросов, связанных с этой проблемой. В этих статьях, в частности, обсуждается, как добавлять новые правила в существующий набор и как модифицировать ранее сформулированные правила.
Тот подход, который использован в программе MORE, достаточно прозрачен и понятен. Но в этой программе совершенно не затрагивается вопрос о независимости значений коэффициентов, который был в свое время поднят Шортлиффом. В главе 6 мы видели, что применение теоремы Байеса требует, чтобы свидетельства в пользу гипотез были независимыми, если мы собираемся комбинировать их параметры с помощью простой мультипликативной схемы.
Шортлифф предложил сгруппировать зависимые свидетельства в одном правиле, а не распределять их по множеству и рассматривать такую группу свидетельств в качестве "суперсимптома". Оценку весомости этого суперсимптома можно сделать на основе аппроксимации конъюнкции весов индивидуальных свидетельств. В программе MORE это предложение не реализовано, но в ней имеется вся необходимая для этого информация, представленная в модели событий. Анализ функционирования системы подтвердил предположение, что при нарушении независимости свидетельств коэффициенты уверенности отклоняются в значительно большем диапазоне, чем вероятности (см. об этом в [Buchanan and Shortliffe, 1984, Chapter 11, Section 5]).
Кан обратил внимание на другие проблемы, обнаруженные при эксплуатации прототипа системы MORE.
Пользователи предпочли бы, чтобы программа MORE использовала каким-то образом модель событий для формирования предположительных значений коэффициентов и задавала меньше вопросов общего характера.
Такие концептуальные понятия, как гипотезы и симптомы, с трудом воспринимаются экспертами в большинстве предметных областей, связанных с промышленным производством, чьи знания очень важны для систем, ориентированных на диагностику неисправностей.
Стандартный алфавитно-цифровой интерфейс общения эксперта с системой показал свою полную непригодность даже для выполнения экспериментов с прототипом системы.
Последнее замечание еще раз подтверждает важность хорошо продуманного и удобного интерфейса для успешного внедрения экспертной системы. До тех пор, пока пользователь будет лишен возможности легко интерпретировать то, что он видит на экране, быстро отыскивать необходимую ему информацию, он не сможет понять, что именно делает система.
Привычный для всех современных пользователей графический интерфейс значительно повышает производительность работы с системой на всех стадиях ее развития.
Другой ряд проблем связан с тем, что программа MORE реализована на языке OPS5, а модель событий описывается в терминах сложных векторов, размещаемых в рабочей памяти. Такое представление плохо подходит для представления знаний о причинно-следственных отношениях, а потому при описании, модификации и сопровождении модели событий разработчикам пришлось столкнуться с большими сложностями. Здесь скорее подошло бы представление в виде структурированных объектов, которое было описано в главе 6.
За время, прошедшее после создания программы MORE, на свет появилось еще множество других программ извлечения знаний для последующего использования в экспертных системах, выполняющих эвристическую классификацию. Одна из таких программ — TDE — будет представлена в следующей главе
12.3. Совершенствование стратегий
Работа инженера по знаниям отнюдь не заканчивается после того, как эвристические знания будут представлены в виде исходного набора порождающих правил. И исследователи, и практики давно пришли к выводу, что процесс дальнейшего совершенствования базы знаний не уступает по сложности процессу создания ее первой версии. Существует довольно большой круг проблем, связанных как с обслуживанием большого набора правил, так и с дальнейшим уточнением их на базе опыта, полученного в процессе эксплуатации системы.
Только часть из этих проблем может быть решена с помощью таких инструментальных средств извлечения знаний, как система MORE. Создается впечатление, что некоторые аспекты этих проблем являются следствием применения подхода, базирующегося на правилах, а потому требуется определенное переосмысление способов организации набора правил. В этом разделе мы попытаемся провести краткий обзор существующих на сегодняшний день мнений на этот счет.
12.3.1. Уроки проекта GUIDON
В своей работе [Clancey, 1983] Кленси раскритиковал использование неструктурированного набора порождающих правил в экспертных системах, основываясь в основном на опыте адаптации системы MYCIN для учебных целей в ходе выполнения проекта GUIDON. Описание этого проекта можно найти в работе [Clancey, 1987, а]. Главный аргумент Кленси состоит в том, что единообразный синтаксис правил в виде выражений "если... то" скрывает тот факт, что такие правила часто выполняют совершенно различные функции и соответственно должны конструироваться по-разному. При нынешней постановке вопроса определенные структурные и стратегические решения, касающиеся представления знаний о предметной области, присутствуют в наборе правил неявно, а потому недоступны для коррекции или анализа в явном виде.
Мы уже видели, что порождающие правила в обобщенной форме могут быть интерпретированы следующим образом: если предпосылки Р1 и ... и Рт верны, то выполнить действия Q1 и ... и Qn
Порядок перечисления предпосылок Рi не имеет значения, поскольку Р1 ^ P2 эквивалентно P2^P1 в любой стандартной логике. Однако порядок перечисления предпосылок влияет на процедурную интерпретацию таких правил, поскольку он материализуется в логическом программировании. Различные варианты упорядочения в совокупности могут породить совершенно различные виды пространства поиска, которые будут анализироваться по-разному, как мы это уже видели в главе 8. Аналогично, порядок применения правил для достижения определенной цели будет влиять на порядок формирования подцелей. Можно с уверенностью утверждать, что такой механизм разрешения конфликтов, при котором первыми будут выполняться наиболее предпочтительные правила, в большинстве случаев позволит намного сократить процесс поиска.
Проблема состоит в том, что критерии, по которым можно было бы упорядочить правила и логические фразы, представлены в наборе правил в неявном виде. Знания о том, какое правило следует применить первым и в каком порядке анализировать члены совокупности предпосылок в правиле, являются, по существу, метазнаниями, т.е. знаниями о том, как применять знания. Вряд ли кто-нибудь будет спорить с тем, что такие знания имеют важнейшее значение для правильного функционирования экспертной системы, а получить их от эксперта и представить в удобном виде в программе чрезвычайно трудно.
Кленси утверждал, что система, основанная на правилах, нуждается в эпистемологической оболочке, которая каким-то образом придает смысл специфическим знаниям о предметной области. Другими словами, правила логического вывода, имеющие отношение к определенной предметной области, часто оказываются неявно включены в более абстрактные знания. Лучший способ объяснить эту мысль -- воспользоваться примером, описанным Кленси. Рассмотрим следующее правило:
ЕСЛИ: 1) заражение — менингит,
2) доступны только косвенные свидетельства,
3) тип инфекции — бактериальный,
4) пациент принимает кортикостероиды,
ТО: имеются основания предполагать наличие таких микроорганизмов e.coli (.4)
klebsiella-pneumoniae (.2) или pseudomonas-aeruginosa (.1).
Порядок перечисления предпосылок (конъюнктов) в этом правиле исключительно важен. Обычно стараются сначала сформулировать гипотезу относительно природы инфекции (предпосылка 1), а затем решать, являются ли свидетельства, относящиеся к этой гипотезе, косвенными или нет (предпосылка 2). Бактериальный менингит— это подкласс, отличный от вирусного менингита, и, следовательно, предпосылку 3 можно рассматривать как уточнение предпосылки 1. И наконец, решение отложить проверку предпосылки 4 можно, вероятно, отнести к категории стратегических. Если сделать эту последнюю предпосылку первой в правиле, то пространство поиска будет иметь совершенно другой вид, причем возможным следствием такого изменения будет отбрасывание всех последующих проверок, если эта даст отрицательный результат.
Процесс представления знаний приводит к тому, что знания становятся явными, но порождающие системы оставляют множество общих принципов управления поиском представленными в неявном виде. Возможно, этим и объясняется тот факт, что добавление или удаление правил из существующего набора иногда дает совершенно неожиданный эффект. Декларативная интерпретация правил на "человеческом" языке подводит нас к одному выводу, а процедурная интерпретация этих же правил в системе может дать совершенно иной результат.
Кленси предложил довольно привлекательную методику анализа разных видов знаний, выполнение которого может быть возложено на эпистемологическую оболочку системы, основанной на правилах. Предлагается выделить такие компоненты знаний: структурные, стратегические и поддерживающие.
Структурные знания состоят из абстрактных категорий разных уровней, посредством которых представляются знания о предметной области. Таксономия — это, возможно, один из самых очевидных примеров источника таких знаний, которые обычно явно представляются в виде порождающих правил. Знание, что менингит — это заражение, которое может быть острым либо хроническим, бактериальным или вирусным и т.д., неявно представляется в предпосылках многих правил.
Стратегические знания — это знания о том, как выбрать порядок применения методов или выбора подцелей, который минимизировал бы объем работы, необходимый для поиска' в пространстве решений. Например, правило, которое гласит, что пациент, склонный к определенной патологии (например, алкоголик), может с большей вероятностью иметь необычную этиологию, должно побудить эксперта первым делом обратить внимание на менее обычные причины заражения. Такие знания обычно используются в сочетании со структурными знаниями. Например, такая эвристика может быть связана скорее с бактериальным менингитом, чем с вирусным.
Поддерживающие знания — - это знания, которые содержатся в причинно-следственной модели предметной области и которые объясняют, почему в этой предметной области имеют место определенные необычные явления. Так, в системе MYCIN имеется правило, которое связывает употребление стероидов с наличием грамотрицательных микроорганизмов в форме палочек, которые могут вызвать бактериальный менингит. В основе этого правила лежит тот факт, что стероиды ослабляют иммунную систему. К тому же такие знания увязываются со структурными знаниями, касающимися классификации заболеваний и классификации микроорганизмов.
Очевидно, что большая часть таких фундаментальных знаний не представлена в явном виде в порождающих правилах. Структурные знания лучше всего представляются в форме составных объектов данных, таких как фреймы, но некоторая часть управляющей информации может быть представлена в процедурном виде. Поддерживающие знания, как правило, включаются в сопроводительную документацию к программе, но они должны быть доступны и для программы, формирующей объяснения сделанных заключений. Попытка "втиснуть" разнородные знания в единый формат представления отрицательно сказывается на ясности и прозрачности системы для пользователя, но, тем не менее, позволяет весьма изобретательно использовать эффект от рационального выбора способа упорядочения правил и предпосылок.
12.3.2. Структура задач в системе NEOMYCIN
Опыт, полученный в ходе работы над системой GUIDON, был использован Кленси при разработке более сложной модели выполнения диагностирования, которая получила название NEOMYCIN. При создании базы медицинских знаний для этой консультационной системы была использована доработанная обучающая программа GUIDON2. Главные отличия системы NEOMYCIN от MYCIN состоят в следующем.
Использованная в системе процедура вывода суждений наиболее четко отделена от содержимого порождающих правил, как об этом было сказано в предыдущем разделе при описании программы GUIDON.
Процедура вывода суждений может использовать как прямую, так и обратную цепочку логического вывода.
Таким образом, поток данных и управляющей информации в программе NEOMYCIN в большей степени независим от порождающих правил и механизма их интерпретации, чем в системе MYCIN, которая тратила большую часть рабочего времени на выполнение исчерпывающего нисходящего поиска. MYCIN задавала пользователю вопросы и собирала необходимую информацию в том случае, когда не находила такого правила, которое можно было бы применить для формирования заключения, связанного с некоторым фактом. В этом смысле MYCIN очень напоминала те системы логического программирования, в которых использовалась технология "спроси у пользователя". Работая с пользователем в интерактивном режиме, программа накапливала факты, недостающие для выполнения доказательства. Процесс функционирования NEOMYCIN, напротив, лучше всего может быть представлен как обработка множества разнообразных гипотез и тестов, среди которых отыскивается наиболее предпочтительная гипотеза и сравнивается с конкурентами. Следовательно, вопросы, которые система задает пользователю, диктуются желанием выбрать между альтернативными предложениями, а не просто собрать факты для проведения единственной линии суждений, которая может завершиться успехом или неудачей.
Кленси утверждает, что поведение NEOMICYN ближе к модели поведения человека при диагностировании, чем поведение MYCIN.
Например, клиницисты обычно стараются определить диапазон возможных заболеваний, которыми может страдать пациент, на основе ограниченного набора анализов. По Кленси такое поведение можно рассматривать как стремление "ограничить пространство гипотез". Одна из стратегий, используемых для этого, называется "сгруппируй и раздели", т.е. задавшись какой-либо начальной гипотезой, правдоподобной при имеющихся данных, врач сначала пытается собрать все другие гипотезы, учитывающие те же признаки и симптомы, а затем разделить их на те, которые подходят к данному случаю, и те, которые должны быть отброшены.
Стратегия диагностирования в системе NEOMYCIN может быть представлена в виде дерева задач, в котором задачей верхнего уровня является КОНСУЛЬТАЦИЯ, в которую в виде подзадач входят ИДЕНТИФИКАЦИЯ ПРОБЛЕМЫ и СБОР ИНФОРМАЦИИ. Именно эта иерархия задач определяет направление потока управления, а не неявная иерархия концептуальных правил, прослеживаемая с помощью методики построения обратной цепочки рассуждений. В дополнение к задаче "сгруппируй и раздели" существуют еще две стратегии, которые помогают сформировать пространство гипотез: "попробуй и уточни" и "задай обобщенные вопросы". Первая предполагает достаточно детальное исследование определенной гипотезы, а вторая служит для сбора фоновой информации (например, можно запросить у пользователя, не беременна ли пациентка, не перенес ли пациент недавно хирургическую операцию).
Обеим задачам — и "сгруппируй и раздели", и "попробуй и уточни" — отводится свое место в контексте сложной иерархии патологий. Стратегия "сгруппируй и раздели" включает анализ той части иерархии, которая находится выше первоначальной гипотезы, и таким образом предпринимается попытка отыскать в этой части конкурирующие гипотезы. Стратегия "попробуй и уточни" включает анализ той части иерархии, которая находится ниже первоначальной гипотезы, и таким образом предпринимается попытка дальнейшего уточнения диагноза.
В следующей главе мы проанализируем весь процесс формирования гипотез и их тестирования в иерархии альтернатив. Здесь же важно обратить внимание на принцип представления в программе стратегии формирования логического вывода явно в структуре задач. Те результаты, которые получил Кленси при разработке конкретной интеллектуальной обучающей системы, могут быть с успехом распространены и на весь класс экспертных систем.
Независимо от того, всеми ли будет одобрена предложенная Кленси методика анализа, можно с уверенностью заявить, что она открыла новые направления в исследованиях в области экспертных систем. Точно так же, как задачи, выполняемые экспертными системами, нуждаются в той или иной форме онтологического анализа, который помогает систематизировать объекты и отношения между ними в конкретной предметной области, они нуждаются и в эпистемологическом анализе видов знаний о способах решения проблем в этой области, которыми обладает эксперт. Эти знания в совокупности со знаниями о том, на какой стадии процесса логического вывода их следует применять, как правило, слишком обширны. Поэтому для их представления недостаточно какого-то одно формализма (например, порождающих правил) и одного режима управления (например, построения обратной цепочки вывода).
Один из подходов к построению экспертных систем (как, впрочем, и любых других программ) — спросить себя, как распределить "сложность" между компонентами проекта. Существуют два крайних варианта — спроектировать конструкцию с достаточно богатыми возможностями, которую можно было бы относительно легко реализовать, или спроектировать простую конструкцию, но сосредоточить главные усилия на стадии кодирования. Это пример реализации принципа "бесплатных ленчей не бывает" в отношении программного обеспечения. Ресурсы, сэкономленные на одном уровне, непременно придется растратить на другом.
Рекомендуемая литература
В дополнение к системам, описанным в этой главе, читателям рекомендуется познакомиться с системой MOLE [Eshelman and McDermott, 1986], [Eshelman et al., 1987], [Eshelman, 1988]. Это интересная оболочка для построения экспертных систем, решающих проблему классификации. Она более интеллектуальная, а следовательно, и более сложная для понимания, чем MORE, а потому мы не рассматривали ее в данной книге. Особенностью этой системы является разделение между категориями накрывающих знаний {covering knowledge) — знаний, относящихся к сопоставлению данных и гипотез, и дифференцирующих знаний (differentiating knowledge) — знаний, которые позволяют сделать выбор между конкурирующими гипотезами. Это разделение используется для структурирования процесса извлечения знаний и уточнения сформированной базы знаний.
Подробное обсуждение вопросов эвристической классификации и эпистемологического анализа в системах, основанных на правилах, можно найти в работах [Clancey, 1993,а] к [Clancey, 1993,b
Упражнения
1. Почему в системах, основанных на правилах, сложно выполнять обратное прослеживание на большую глубину?
2. Перечислите шесть основных этапов проектирования систем, основанных на знаниях.
3. В чем разница между стратегиями частотного упорядочения условий и установления связи между симптомами и условиями в системе MORE?
4. Говорят, что правила ожидаемости гипотез в системе MORE "неявно квалифицируют абстрактные категории решений в пространстве гипотез". Что под этим понимается?
5. В чем заключается значение фоновых условий в модели, используемой в MORE?
6. В чем состоит отличие между моделями событий и правил в системе MORE?
7. Какая ошибка допущена при назначении коэффициентов уверенности на схеме модели событий, представленной на рис. 12.4? На этой схеме D — это неисправность, а
S1,S2 и S3 -СИМПТОМЫ.
Рис. 12.4. Модель событий
8. Какая ошибка допущена при назначении коэффициентов уверенности на схеме модели событий, представленной на рис. 12.5? На этой схеме Di — это неисправности, а Si — симптомы.
Рис. 12.5. Модель событий
9. Рассмотрите CLIPS-программу, представленную во врезке 12.1.
I) Добавьте в программу новые правила, соответствующие представленным ниже
IF: there is an increase in chlorides, and
the drilling fluid is undersaturated, THEN: there is salt contamination.
IF: there is salt contamination
THEN: there is an increase in viscosity.
ЕСЛИ: обнаружено повышение уровня хлоридов и
пласт недостаточно насыщен, ТО: существует солевое загрязнение.
ЕСЛИ: существует солевое загрязнение,
ТО: повышается вязкость.
II) Назначьте значения коэффициентов уверенности дугам, соединяющим узлы на схеме рис. 12.1. Включите также коэффициенты, связывающие процедуры анализа и результаты проведения анализа. При установке значений коэффициентов соблюдайте ограничения, описанные в разделе 12.2.3. Значения всех коэффициентов могут быть положительными.
III) После этого измените определения шаблонов в тексте программы таким образом, чтобы и гипотезы, и тесты имели соответствующие атрибуты.
IV) Измените в программе правила таким образом, чтобы в них был реализован механизм распространения коэффициентов уверенности по мере формирования гипотез и выполнения тестирующих процедур. Комбинирование коэффициентов должно выполняться в соответствии с формулой
Z = X+Y-XY,
где Z— новое значение коэффициента уверенности, полученного на основании значений X и Y, связанных с симптомами. Таким образом, если программа приходит к заключению increase in low-specific-gravity solids (повышение доли твердых включений) исходя из симптома increase in viscosity (повышение вязкости), который характеризуется коэффициентом уверенности X, и результатов теста МВТ (тест синевы метилена), которые характеризуются коэффициентом Y, то с помощью приведенной выше формулы можно получить значение коэффициента Z, характеризующее степень достоверности заключения.
V) Запустите программу на выполнение и проверьте, как она будет реагировать на разные варианты ответов на вопросы.
10. Приведенная ниже модель диагностики взята из руководства владельца автомобиля BMW 320.
I) Представьте приведенные ниже инструкции по поиску неисправностей в виде модели предметной области, которая используется в системе MORE (см. рис. 12.1).
Симптом
Причины
Двигатель не заводится
На стартер не подается ток
Разряжена аккумуляторная батарея
Поврежден провод, подключенный к одной из клемм батареи
Поврежден соленоид стартера
Плохой контакт с "массой"
На стартер подается ток
Заклинило шестерню стартера
Поврежден двигатель стартера
Двигатель проворачивается,
но не запускается
Нет искры между электродами свечи
Загрязнены контакты прерывателя Наличие влаги в распределителе
Неправильно подключены контакты прерывателя
Поврежден конденсатор (модель прежних лет выпуска)
Поврежден ключ прерывателя
Повреждена катушка (модель прежних лет выпуска)
Нет топлива в жиклере карбюратора
Нет топлива в баке Паровая пробка в системе подачи топлива
(в жаркое время года)
Засорен жиклер
Неисправен бензонасос
Двигатель заглох и вновь не
заводится
Заливает карбюратор
Заедание игольчатого клапана
Поврежден поплавок
Неправильно установлен уровень поплавка
Нет топлива в жиклере карбюратора
Нет топлива в баке Вода попала в систему подачи топлива
Замечания в круглых скобках в столбце "Причины" следует рассматривать как фоновые условия в системе MORE.
II) Постройте на основе этой инструкции набор порождающих правил и разработайте соответствующую CLIPS-программу. Фоновые условия должны вводиться пользователем в ответ на запросы программы.
ГЛАВА 13. Иерархическое построение и проверка гипотез
13.1. Влияние сложности пространства гипотез на организацию работы системы
13.2. Структурированные объекты в CENTAUR
13.2.1. Структура фреймов в CENTAUR
13.2.2. Правила, включенные в прототипы
13.3. Формирование суждений на базе модели в системе INTERNIST
13.3.1. Представление знаний в дереве заболеваний
13.3.2. Методика выделения правдоподобных гипотез в INTERNIST
13.3.3. Проблемы, обнаруженные в процессе эксплуатации системы INTERNIST
13.4. Рабочая среда инженерии знаний TDE
Рекомендуемая литература
Упражнения
ГЛАВА 13. Иерархическое построение и проверка гипотез
13.1. Влияние сложности пространства гипотез на организацию работы системы
13.2. Структурированные объекты в CENTAUR
13.3. Формирование суждений на базе модели в системе INTERNIST
13.4. Рабочая среда инженерии знаний TDE Рекомендуемая литература Упражнения
В данной главе будут рассмотрены три системы, реализующие комбинированный метод решения проблем, который получил в литературе наименование иерархического построения и проверки гипотез (hierarchical hypothesize and test). С методом эвристической классификации этот метод сходен в том, что в нем используется отображение множества абстрактных категорий данных на множество абстрактных категорий решений, но этот подход усложнен тем, что элементы решений могут комбинироваться и объединяться в составные гипотезы. Цель такого усложнения — построение гипотезы, которая могла бы объяснить все симптомы и признаки анализируемой ситуации. Классическим примером ситуации, в которой проявляются достоинства нового метода, является дифференциальное диагностирование, когда предполагается, что пациент страдает не одним, а несколькими заболеваниями, и нужно по множеству симптомов и показаний определить, какими именно.
Включение в процесс анализа комбинированных гипотез значительно усложняет положение вещей. Пространство гипотез "разрастается", и его приходится каким-то образом структурировать, чтобы сделать обозримым. Метод иерархического построения и проверки гипотез пытается решить эту проблему с помощью явно выраженного таксо-нометрического представления пространства гипотез. Таксонометрическое представление обычно имеет вид дерева, листьями которого являются элементы решения. Нет ничего удивительного в том, что при представлении знаний, основанном на иерархически структурированной организации объектов, процесс активизации гипотез направляется этой организацией и заданным режимом управления.
Первой будет рассмотрена система CENTAUR [Aikins, 1983], поскольку она лучше документирована и в особенностях ее работы легче разобраться. Затем мы рассмотрим более сложную систему INTERNIST [Pople, 1977], на примере которой можно увидеть, какие проблемы возникают при использовании метода иерархического построения и проверки гипотез. Последней будет рассмотрена современная система TEST [Kahn et al., 1987], на примере которой можно увидеть, какое влияние оказывает иерархическая стратегия на методику извлечения знаний.
13.1. Влияние сложности пространства гипотез на организацию работы системы
Такие системы, как MYCIN, имеют дело с отдельной, очень специфической частью проблемной области (в данном случае — медицины). В частности, система MYCIN диагностирует только заболевания крови. Поскольку пространство состояний в системах, подобных MYCIN, достаточно ограничено, в них можно использовать метод исчерпывающего поиска в глубину.
А что делать, если мы собираемся построить экспертную систему, имеющую дело со всеми возможными заболеваниями, а не только с отдельным специфическим классом? Количество различных заболеваний, известных врачам на сегодняшний день (диагностических категорий), лежит, по разным оценкам, в диапазоне от двух до десяти тысяч. Нужно также учитывать, что существуют пациенты, у которых обнаруживается до десятка заболеваний одновременно. Как отметил Попл (Pople), в худшем случае программе, использующей обратную цепочку рассуждений, придется при диагностировании таких пациентов проанализировать около 1040 диагностических категорий!
Именно в тех системах, в которых пространство решений потенциально может быть очень большим, и проявляются преимущества метода иерархического построения и проверки гипотез. Пространство поиска в таком случае может рассматриваться как дерево, представляющее таксономию типов решений. Узлы более верхних уровней дерева соответствуют более широким (а потому менее четко очерченным) категориям решений, чем узлы более нижних уровней. Терминальные узлы дерева соответствуют совершенно конкретным решениям. При такой организации пространства решений процесс уточнения гипотез значительно упрощается, поскольку структура пространства решений может быть использована для формирования эвристик управления последовательностью анализа.
На рис. 13.1 показана часть иерархической систематики заболеваний, которая используется в системе CENTAUR. Корневым узлом этого фрагмента являются ЗАБОЛЕВАНИЯ_ ОРГАНОВ_ДЫХАНИЯ, а все последующие узлы — различные виды таких заболеваний. Следующий уровень узлов представляет наиболее общие категории заболеваний органов дыхания, а терминальные узлы (листья) — конкретные заболевания, которые можно диагностировать и в дальнейшем лечить.
Естественно, если таким образом представить медицинские знания обо всех возможных болезнях, то дерево очень сильно "разрастется". В системе INTERNIST организация дерева привязана к основным органам — легким, печени, сердцу и т.п. Хотя иерархическая организация и помогает выполнять поиск, она не устраняет проблему отыскания наилучшего объяснения имеющегося набора данных (симптомов). Для этого необходимо объединять гипотезы об отдельных болезнях и добиваться, чтобы в такой комбинированной гипотезе были учтены все признаки и симптомы, обнаруженные у пациента.
Рис. 13.1. Иерархическое представление заболеваний органов дыхания
Методика вариативного построения гипотез и их проверки оказывается особенно полезной в тех случаях, когда
ассоциативные связи между свидетельствами и "терминальными" гипотезами слабые, а ассоциативные связи между исходными данными и "нетерминальными" гипотезами достаточно сильные, и существуют методы уточнения построенных гипотез и их разделения;
в полном наборе правил имеется большая избыточность, т.е. значительная часть условий одновременно включена во множество правил и таким образом связывается с множеством различных заключений;
система спроектирована с расчетом на явное представление пространства гипотез, которым можно манипулировать, причем на любом этапе работы может существовать множество конкурирующих гипотез, которые нельзя анализировать независимо;
не все условия можно одинаково легко сформулировать либо из-за сложности сопутствующих вычислений, либо вследствие факторов стоимости и риска; таким образом, оказывается, что процесс накопления свидетельств сам по себе представлен в пространстве состояний и к нему нужно применять некоторые методы логического вывода;
возможны множественные и частичные решения, например пациент может страдать несколькими заболеваниями, либо для проведения лечения вполне достаточно знания класса заболеваний или основных альтернативных заболеваний.
Один из этапов подхода, использованного в CENTAUR, состоит в том, что просматривается, насколько полно представление гипотетического заболевания совпадает с имеющимися данными (симптомами, показаниями и т.п.). Узлы в дереве представления гипотез активизируются имеющимися данными, конкретизируются, оцениваются и упорядочиваются по степени "накрытия" имеющихся фактов. Узлы, "получившие" наиболее высокие оценки, включаются в список заявок и в дальнейшем анализируются более подробно. В первом приближении этот анализ сводится к выяснению, насколько имеющиеся симптомы соответствуют каждому из дочерних узлов. Последовательно применяя такую процедуру анализа, программа в конце концов формирует список терминальных узлов с достаточно высокими оценками степени соответствия имеющимся данным.
13.1. Обход дерева
В самых общих чертах алгоритм выполнения иерархического построения и проверки гипотез (НАТ-алгоритм) может быть представлен следующим образом. Предположим, имеется дерево гипотез, которые могут быть активизированы на основе части имеющихся данных. Активизированные гипотезы предполагают наличие и других данных, помимо тех, что были использованы для их отбора, которыми мы можем располагать или которые можно дополнительно затребовать.
НАТ-алгоритм
(1) Считать исходные данные.
(2) Для каждой исследуемой гипотезы сформировать оценку, которая показывает, какая часть исходных данных учитывается этой гипотезой.
(3) Определить ту гипотезу (узел) л, которая имеет наивысшую оценку.
(4) Если п— терминальный узел, то завершить выполнение алгоритма. В противном случае выделить в пространстве гипотез два подпространства К и L Подпространство К должно содержать дочерние узлы п, а подпространство L — узлы-конкуренты п на том же уровне дерева.
(5) Собрать дополнительные данные, которые можно использовать для анализа гипотез в подпространстве К, и провести оценку гипотез на основе этих дополнительных данных. Пусть k— наивысшая оценка гипотез из К, а l— наивысшая оценка гипотез из L
(6) Если k выше, чем /, то положить п = k. В противном случае положить n = /.
(7) Перейти к п. 4.
13.2. Структурированные объекты в CENTAUR
Для того чтобы понять алгоритм работы программы CENTAUR, нужно хотя бы в общих чертах представлять себе ту предметную область, на которую ориентирована эта программа. CENTAUR выполняет практически те же задачи, что и разработанная ранее система PUFF (см. [Кит et al, 'I978J, [Aikins et al., 1984]}. Система PUFF предназначалась для диагностики нарушения работы дыхательных органов. В качестве исходных данных, как правило, использовались результаты анализа объема выдыхаемого воздуха и скорость движения воздуха при выдохе (этот анализ выполняется с помощью спирографа).
13.2.1. Структура фреймов в CENTAUR
Основная идея, положенная в основу системы CENTAUR, состоит в том, что фреймо-подобные структуры обеспечивают явное представление предметной области, которое может быть использовано для формирования суждений с помощью порождающих правил. Такое описание предметной области позволяет разделить стратегические знания о том, как управлять процессом формирования суждений, и ситуационные знания о том, какой вывод можно сделать из имеющегося набора фактов. Теоретически это позволит отделить ситуационные знания, специфичные для конкретной предметной области, а значит, создать систему, которую можно будет приспособить для работы в разных областях.
При таком подходе порождающие правила могут быть просто включены в структуру фрейма в качестве значения одного из слотов. Связывание правил со слотами фрейма создает возможность организации единого механизма функционирования правил на основе естественного группирования. Другие слоты в данном фрейме образуют в явном виде контекст применения правила.
В CENTAUR используются три типа фреймоподобных структур: прототипы, компоненты и факты. Из 24 прототипов двадцать один представляет определенные заболевания органов дыхания, один — знания, общие для всех заболеваний этого вида, а еще два — знания, в определенной мере независимые от предметной области. Это знания о том, как запустить консультирующую программу и просмотреть имеющиеся свидетельства. Таким образом, знания организуются вокруг самих диагностических категорий. Альтернативный вариант, используемый в большинстве других систем, — заложить эти знания в неявной форме в набор неструктурированных правил.
Прототипы в программе CENTAUR содержат знания и объектного, и метауровня. Из них организована сеть, фрагмент которой представлен на рис. 13.1. Верхний уровень иерархии занимает прототип CONSULTATION (консультация), который управляет всеми стадиями процесса проведения консультаций (ввод исходных данных, активизация гипотез и т.п.). Затем следует слой прототипов, представляющих определенные патологические состояния, такие как RESTRCTIVE LUNG DESEASE (легочные заболевания), OBSRTUCTIVE AIRWAYS DESEASE (заболевания верхних дыхательных путей) и т.п. И на самом нижнем уровне категории заболеваний разделяются, во-первых, на конкретные заболевания, а во-вторых, по степени остроты. Так, категория заболеваний верхних дыхательных путей (OBSRTUCTIVE AIRWAYS DESEASE) может быть разделена на подкатегории MILD (мягкие), MODERATE (умеренные), MODERATELY SEVERE (умеренной остроты) и SEVERE (острые). А конкретные виды заболеваний, представленные на этом уровне, — ASTHMA (астма), BRONCHITIS (бронхит) и EMPHYSEMA (эмфизема).
Каждый прототип имеет слоты для некоторого набора компонентов, которые содержат указатели на субфреймы знаний на объектном уровне. В каждом прототипе заболеваний органов дыхания существуют слоты, представляющие результаты анализов легких, причем каждый из этих слотов также является фреймом с собственными правами и собственной внутренней структурой. Например, фрейм OBSRTUCTIVE AIRWAYS DESEASE (заболевания верхних дыхательных путей) включает 13 компонентов, каждый из которых имеет собственное наименование, характеризуется диапазоном допустимых значений и степенью (мерой) важности. В дополнение к этому фрейм компонента часто содержит специальный слот, называемый "inference rules" (правила вывода), в котором хранятся порождающие правила формирования логического вывода на основе значения этого компонента. Если компонент не содержит такого рода правил или правило по каким-либо причинам не может обработать значение компонента, программа обращается с вопросом к пользователю. Такую меру предосторожности в отношении набора правил можно рассматривать как процедурную связь определенного вида. Процедурная связь обычного вида потребовала бы включение в программу довольно значительного по объему фрагмента LISP-кода.
Факты, с которыми работает программа, представляются фреймами, каждый из которых имеет шесть слотов. В них содержится информация о наименовании параметра, его значении, степени достоверности, источнике, классификации и обоснованности.
Помимо знаний, специфичных для предметной области, в прототипах имеется и управляющий слот. В нем представлены знания метауровня о том, как использовать этот структурный элемент знаний. Этот слот содержит LISP-выражения, предназначенные для
конкретизации прототипа— установки множества компонентов, значения которых должны быть определены;
реагирования на подтверждение или отклонение прототипа; реакция программы заключается в том, что задается множество прототипов, которые следует активизировать на следующем шаге;
вывода сообщения, в котором приводится окончательное заключение.
Каждый управляющий слот можно рассматривать как консеквентную часть правила, условная часть которого сопоставима с ситуацией, описанной компонентами прототипа
13.2.2. Правила, включенные в прототипы
Нелишне напомнить, что именно компоненты прототипа представляют большую часть знаний объектного уровня, специфичных для определенной предметной области, поскольку в структуре этого типа содержится информация о лабораторных исследованиях, результаты которых должны быть использованы при диагностировании того или иного конкретного заболевания. Эти компоненты являются значениями слотов прототипов, представляющих заболевания, и в то же время имеют собственную внутреннюю структуру и являются прототипами со своими собственными правами. Таким образом, оказывается, что в составе прототипа имеются не только порождающие правила, но и другие прототипы. Можно с полным правом утверждать, что система прототипов имеет по крайней мере двухмерную организацию в дополнение к иерархической организации, представленной в явном виде в терминах типов и подтипов заболеваний. Структуры данных, которые могут быть включены сами в себя, принято называть рекурсивными.
В CENTAUR используется пять типов правил.
Правила логического вывода. Связаны с компонентами,представляющими клинические параметры, и задают возможные способы определения их значений.
Правила активизации. Это антецедентные правила, связанные с клиническими параметрами, которые служат для выдвижения прототипов в качестве гипотез с некоторой степенью правдоподобности.
Правша обработки остаточных фактов. После того как система придет к какому-нибудь заключению в форме набора подтвержденных прототипов, эти правила стараются оценить, как это заключение согласуется с фактами, неучтенными при формировании заключения (остаточными фактами).
Уточняющие правила. Эти правила предполагают проведение дополнительных лабораторных анализов. После выполнения этих правил будет сформировано окончательное множество прототипов с указанием, какой из них учитывает тот или иной из имеющихся фактов, причем каждый факт должен быть учтен по крайней мере одним прототипом.
Правша вывода. Эти правила переводят информацию, представленную в прототипах, на "человеческий" язык и представляют ее пользователю.
Другие слоты содержат обычную информацию, необходимую для учета, — имя автора, сведения об источнике информации и о текущей ситуации, которые затем используются при формировании объяснения, почему данный прототип был активизирован.
Как видно, в системе CENTAUR в основу классификации правил положены функции, выполняемые с их помощью. В системе PUFF, реализованной на базе оболочки EMYCIN, все правила считаются правилами логического вывода, хотя многие из них и не имеют непосредственного отношения к логическому выводу. Например, большая группа правил предназначена для сбора информации, используемой в качестве свидетельств, или для установки значений по умолчанию. Кроме того, контекст применения правил в CENTAUR представлен в явном виде, поскольку правила являются значениями слотов. Например, в системе PUFF правила для оценки значений клинических параметров индексированы по наименованию параметра, которое появляется в консеквентной части правила, т.е. использован тот же принцип, что и в системе MYCIN. В системе CENTAUR правила оценки определенных параметров хранятся в виде значения одного из слотов в прототипе компонента, представляющего этот параметр, и применяются только в контексте этого прототипа, т.е. в том случае, если прототип активизирован.
Ниже, в главе 18, будет показано, что дальнейшее углубление такого "распределенного" подхода к организации порождающих правил приводит к созданию нового класса систем, получивших название систем с доской объявлений (blackboard systems). Но уже на опыте эксплуатации системы CENTAUR исследователи убедились в преимуществах явного связывания правил с контекстом их применения. Это не только упрощает процесс программирования экспертной системы, но и помогает при формировании объяснений, почему в конкретной ситуации были использованы определенные правила (более подробно об этом — в главе 16).
13.3. Формирование суждений на базе модели в системе INTERNIST
В программе INTERNIST предпринята попытка смоделировать поведение врача на различных этапах диагностического процесса. Как правило, общая картина, которая вырисовывается на основании имеющихся симптомов, порождает одну или несколько гипотез о том, какие патологии имеются у пациента. Эти гипотезы, в свою очередь, подталкивают врача к поиску других симптомов. Дальнейшее наблюдение пациента может привести к тому, что какие-то из ранее выдвинутых гипотез получат дальнейшее подтверждение, а другие, наоборот, окажутся противоречащими новым данным. Не исключен и вариант появления после более тщательного исследования пациента новых гипотез. Гипотезы, которые появились на начальном этапе, можно считать порожденными первичными данными в том смысле, что определенное проявление патологии порождает множество догадок. Последующее накопление новых данных, призванных подтвердить или опровергнуть первоначальные догадки, можно рассматривать как ведомое моделью в том смысле, что оно базируется на определенных стереотипах или концептуальных идеях о том, как проявляется то или иное заболевание.
В большинстве задач, связанных с логическим выводом (к ним относятся и задачи диагностирования), редко когда рассуждение ведется только в одном направлении, т.е. в направлении одной цели (версии о причинах случившегося). В основном это происходит из-за неполноты исходной информации, которой бывает недостаточно для четкой формулировки проблемы. Например, врач может не располагать на начальном этапе обследования достаточно полной информацией для того, чтобы очертить круг возможных заболеваний пациента, или та информация, которой он располагает, может вести его в разных направлениях (не исключено, что пациент страдает не одним, а несколькими заболеваниями).
При разработке программы INTERNIST ставилась задача провести разграничение между множеством взаимно исключающих гипотез о заболеваниях, которые могут возникнуть, в процессе диагностирования. Если пациент страдает несколькими заболеваниями, то программа должна отобрать такое множество гипотез, которое "накрывало" бы как можно большую часть (а лучше все) обнаруженных симптомов. Для этого сначала исследуется наиболее правдоподобная гипотеза, определяется, какую часть из имеющихся симптомов она учитывает, затем анализируется следующая по степени правдоподобия гипотеза, и так до тех пор, пока набором гипотез не будут учтены все имеющиеся симптомы.
13.3.1. Представление знаний в дереве заболеваний
Попл (Pople) рассматривает четыре этапа процесса логического вывода при диагностировании.
(1) Клинические наблюдения должны дать основания для формирования списка возможных заболеваний (кандидатов для дальнейшего уточнения), которые могут быть причиной наблюдаемых явлений или симптомов.
(2) Эти гипотетические кандидаты затем порождают предположения относительно того, какими другими проявлениями они могли бы "дать знать" о себе.
(3) Далее потребуется изыскать какой-либо метод, позволяющий сделать выбор в пользу определенных гипотез на основании имеющихся свидетельств.
(4) Нужно иметь возможность разделить множество имеющихся гипотез на ряд взаимно исключающих подмножеств. Правдоподобие одного подмножества автоматически означает при этом неправдоподобие другого.
Ключевым моментом в рассматриваемой Поплом схеме является двунаправленная связь между заболеваниями, с одной стороны, и признаками или симптомами, с другой. Программа INTERNIST рассматривает такую связь как пару отдельных отношений: EVOKE и MANIFEST.
Отношение EVOKE (истребование) указывает на способ, которым некоторый признак дает основание предполагать наличие определенного заболевания.
Отношение MANIFEST (провозглашение) указывает на то, как (в виде каких показаний или симптомов) может проявляться определенное заболевание.
Знания в области медицины представлены в программе INTERNIST в виде дерева заболеваний — иерархической классификации типов заболеваний. Корневой узел в этом дереве соответствует всем известным заболеваниям, нетерминальные узлы — областям заболеваний, а терминальные — сущностям заболеваний, т.е. конкретным заболеваниям, которые можно диагностировать и для которых можно назначать курс лечения. Это дерево представляет собой статическую структуру данных, отдельную от основного программного кода системы INTERNIST, что делает его сходным с таблицами знаний в системе MYCIN. Но в отличие от таблиц знаний в MYCIN, знания в системе INTERNIST играют куда более активную роль в управлении процессом логического вывода.
База знаний программы INTERNIST формируется следующим образом.
(1) Определяется базовая структура иерархии— к корневому узлу подсоединяются узлы основных областей внутренних болезней (органов дыхания, болезней печени, сердца и т.п.).
(2) Выделяются подкатегории, в которых объединяются области заболеваний с похожими схемами протекания (патогенезом) и проявлениями (признаками и симптомами).
(3) Эти подкатегории разделяются до тех пор, пока не будет достигнут уровень сущностей, т.е. конкретных заболеваний.
(4) Собираются данные, касающиеся связей между сущностями заболеваний и их проявлениями. В число этих данных входят: список всех проявлений конкретного заболевания; оценка вероятности того, что данное заболевание является причиной проявления именно такого признака или симптома; оценка того, насколько часто у пациентов, страдающих определенным заболеванием, наблюдается каждое из отмеченных проявлений.
(5) К представлению каждого заболевания D присоединяется список связанных с ним проявлений (M1, ..., Мn), список показателей причинности L(D, Mi) и список показателей частотности L(Mi, D). Показатели обоих типов определены в диапазоне 0-5.
(6) С каждым заболеванием D, помимо признаков и симптомов, могут быть связаны и другие заболевания, которые также могут рассматриваться как проявления заболевания D. Такие ''вторичные" заболевания связываются в структуре представления знаний с узлом заболевания отношениями EVOKE и MANIFEST.
(7) После сбора и представления всей информации, касающейся "обслуживаемых" системой заболеваний D (т.е. терминальных узлов дерева), запускается программа, которая преобразует описанное дерево в обобщенное представление иерархической структуры. В этом представлении нетерминальные узлы содержат только те свойства, которые являются общими для всех его дочерних узлов.
(8) Вводятся данные об отдельных проявлениях. Наиболее существенными свойствами проявлений являются TYPE (например, признак, симптом, лабораторный тест и т.п.) и INDEX (число в диапазоне 1-5, которое является показателем важности данного проявления).
В ходе выполнения первых трех этапов формируется "суперструктура" базы знаний, т.е. в общих чертах определяется ее схема — диапазон категорий и уровень анализа каждой категории. На последующих трех этапах сформированная структура базы знаний наполняется содержимым. Введенные значения показателей причинности и частотности позволяют программе манипулировать в дальнейшем с "вескостью" свидетельств в пользу или против определенной гипотезы.
На шаге 7 программа определяет проявления для нетерминальных узлов, представляющих области заболеваний, анализируя степень их общности для дочерних узлов более низких уровней иерархии. Например, разлитие желчи является проявлением целой группы заболеваний печени, которая объединяется областью гепатитные заболевания.
Целесообразность такого обобщения проявлений объясняется следующим образом. Как уже не раз подчеркивалось ранее, пространство диагностируемых категорий для пациентов, страдающих несколькими заболеваниями, оказывается чрезвычайно большим. Вследствие этого на практике не удается применить в этом пространстве обычные методы поиска, такие как поиск в глубину. Нужно каким-то способом "свернуть" пространство поиска или сфокусировать усилия программы на определенной области пространства и таким образом добиться приемлемой скорости поиска.
Проблема скорости поиска не стояла бы с такой остротой даже при наличии у пациента нескольких заболеваний, если бы существовали более прямые ассоциативные связи между заболеваниями и их проявлениями, т.е. если бы определенное проявление сразу позволило врачу прийти к заключению о наличии определенного заболевания. Такие отношения в медицинской литературе называются патогенетическими, и они действительно существуют, но, к несчастью, значительно реже, чем нам хотелось бы. Хуже всего то, что патогенетические отношения характерны для тех проявлений, которые могут быть выявлены только в процессе сложных лабораторных исследований или хирургическим путем.
Установить же достаточно жесткие связи между определенными проявлениями и целой группой заболеваний (областью заболеваний в терминологии программы INTERNIST) удается гораздо чаще. Такое проявление, как разлитие желчи, жестко связано с областью заболеваний печени, а кровохаркание — с областью легочных заболеваний. Программа INTERNIST использует связи на верхних уровнях дерева для "сужения" пространства поиска. При этом начальная точка поиска как бы переносится на более низкие уровни иерархии в пространстве заболеваний и уже оттуда начинается выполнение процедуры поиска в глубину.
В используемой Поплом терминологии сужение (constrictor) для конкретного случая диагноза — это нахождение во множестве известных проявлений "намека", в какой области пространства заболеваний находятся правдоподобные гипотезы. Однако не следует забывать, что такое сужение является эвристическим, а потому не гарантирует на все сто процентов, что искомое заболевание находится именно в определенной таким способом области. Хотя на верхних уровнях иерархии и могут существовать проявления, прямо связанные с определенной областью, другие проявления остаются только более предпочтительными для одной области и менее предпочтительными, но отнюдь не невозможными, для другой. При этом ситуация еще более ухудшается по мере перехода на более низкие уровни иерархии.
Из всего сказанного следует, что то упорядочение проявлений, которое выполняется на этапе 7, позволяет консультационной программе начинать диагностическую процедуру на том уровне иерархии, на котором начинают проявляться патогенетические отношения, и отсеивать таким образом целые классы заболеваний.
На этапе 8 обрабатываются свойства самих проявлений, что в процессе работы программы скажется на эффективности выполнения функций на стратегическом уровне. Например, свойство TYPE позволяет судить о том, насколько велики будут затраты на получение того или иного показателя или насколько процесс его получения будет опасен для здоровья пациента, а эту информацию следует учитывать при назначении уточняющих анализов. Свойство IMPORT позволяет принять решение, нельзя ли проигнорировать данное проявление в контексте определенного заболевания. Обратите внимание на то, что на этапах 5 и 8 используется довольно неформализованное представление неопределенности в суждениях. Но в дальнейшем мы увидим, что основной причиной появления проблем в процессе работы с системой INTERNIST является неудовлетворительная формулировка структуры пространства поиска, а не недостаточная точность исходных данных.
Ниже, в разделе 13.4, мы рассмотрим, как отражается использование в программе INTERNIST иерархической структуры дерева гипотез на методике извлечения знаний при опросе экспертов
13.3.2. Методика выделения правдоподобных гипотез в INTERNIST
В процессе выполнения консультаций программа INTERNIST работает следующим образом. Сначала пользователь вводит список существующих проявлений заболеваний пациента. Каждое проявление активизирует один или несколько узлов в дереве заболеваний.
Из выделенных на этом этапе узлов программа формирует модели заболевания, каждая из которых включает четыре списка:
(1) наблюдаемые проявления, не связанные с данным заболеванием;
(2) наблюдаемые проявления, согласующиеся с данным заболеванием;
(3) проявления, отсутствующие во введенных данных, но всегда сопутствующие данному заболеванию;
(4) проявления, которые отсутствуют во введенных данных, но не согласуются с данным заболеванием (опровергают выдвинутую гипотезу).
В модели заболевания проявления, подтверждающие гипотезу, получают положительные оценки, а те, которые им противоречат, — отрицательные. Оба типа оценок "взвешиваются" значениями свойств IMPORT соответствующих проявлений, и модель получает премиальные очки, если имеет причинную связь с другим подтвержденным заболеванием. Затем модели заболеваний разделяются на две группы. В одну группу попадают модель с самой высокой оценкой и все остальные, которые представляют взаимно исключающие с ней гипотезы. Их можно считать "соседними" узлами на дереве заболеваний. Другая группа включает заболевания, совместимые с наиболее правдоподобной гипотезой, т.е. узлы, принадлежащие другим областям заболеваний (рис. 13.2).
Рис. 13.2. Разделение узлов в дереве гипотез. Узлы активизированных гипотез вычерчены утолщенными прямоугольниками, а узел наиболее правдоподобной гипотезы и его дочерние узлы залиты серым цветом
В таком разделении используется концепция доминирования, которой придается следующий смысл. Модель заболевания D1 доминирует над D2 в том случае, если наблюдаемые проявления, которые не могут быть объяснены гипотезой D1, входят как подмножество в число проявлений, которые не объясняются и гипотезой D2. Если мы выделили наиболее правдоподобную гипотезу D0 среди всех активизированных на первом этапе, то каждая из остальных гипотез Di сравнивается с гипотезой Do Если D0 доминирует над Di или Di доминирует над Do, то Di включается в ту же группу "привилегированных" гипотез, что и Do Эта группа должна рассматриваться программой в первую очередь. В противном случае Д включается в другую группу гипотез, анализ которых откладывается на будущее.
Рациональное зерно в таком разделении в том, что модели, включенные в привилегированную группу на любом этапе уточнения, можно считать взаимно исключающими альтернативами. Такое заключение основано на том, что для любых гипотез (моделей) Di и Dj в этой группе диагноз, включающий Di иDj, добавит очень немного или не добавит ничего к "полноте накрытия" каждой из гипотез Di и Dj по отдельности. На следующем этапе уточнения модели обрабатываются по той же методике, если проблема выбора среди моделей, связанных с Do, будет решена. Разделение начинается с нового узла Do, который получит наивысшую оценку среди уточняемых моделей.
Уже после ввода первой порции исходных данных будет активизирована только часть всех узлов дерева. Теперь задача программы состоит в том, чтобы преобразовать дерево из исходного состояния в состояние решения. В состоянии решения дерево должно включать только те терминальные узлы, которые в совокупности "накрывают" все имеющиеся симптомы.
Разделив модели заболеваний, программа может использовать ряд альтернативных стратегий, которые выбираются в зависимости от количества обрабатываемых гипотез.
Если обрабатывается более четырех гипотез, используется стратегия опровержения (режим RULEOUT). Смысл ее заключается в том, чтобы как можно сильнее свернуть дерево пространства гипотез, задавая пользователю вопросы о симптомах, которые являются наиболее сильными индикаторами гипотез-кандидатов.
Если количество анализируемых гипотез не превышает четырех, но больше одной, используется стратегия дифференциации (режим DISCRIMINATE). При этом пользователю задают вопросы, которые помогут выбрать между гипотезами-кандидатами.
Если анализируется всего одна гипотеза, используется стратегия верификации (режим PURSUING). Пользователю задают вопросы, способные подтвердить справедливость анализируемой гипотезы.
Весь процесс носит итеративный характер. Данные, которые пользователь вводит в ответ на вопросы программы в любом из перечисленных режимов, обрабатываются по той же методике, что и введенные сразу после начала сеанса работы с программой. При этом, в частности, активизируются новые узлы дерева, обновляется активизация ранее проанализированных узлов, формируются и сортируются модели заболеваний и выбираются узлы (возможно, новые) для формирования уточняющих вопросов
13.3.3. Проблемы, обнаруженные в процессе эксплуатации системы INTERNIST
В общих чертах программа INTERNIST работает следующим образом. На начальном этапе данные о пациенте вводятся в любом порядке, при этом объем данных значения не имеет. Далее программа приступает к первому шагу решения задачи дифференциального диагностирования — формируется первичный набор гипотез, который может включать как области заболеваний (т.е. нетерминальные узлы дерева заболеваний), так и конкретные заболевания (терминальные узлы). Если какая-либо из отобранных гипотез объясняет наличие важных проявлений из числа тех, которые наблюдаются у пациента, то этой гипотезе "начисляются" поощрительные очки. Если из гипотезы следует, что у пациента должно быть определенное проявление заболевания, а в действительности оно не наблюдается, то гипотеза "наказывается" штрафными очками. В списке гипотез, отсортированном по сумме набранных оценок, два элемента считаются конкурирующими в том случае, если их объединение не объясняет никаких новых проявлений, которые не могли бы быть объяснены любой из этих гипотез по отдельности. Определив набор альтернатив, программа таким образом формулирует задачу дифференциации. Далее программа "сосредоточит внимание" на множестве гипотез, в которое входят наиболее правдоподобная гипотеза и ее конкуренты.
Однако следует подчеркнуть, что INTERNIST в действительности не использует тот простой алгоритм иерархического построения и проверки гипотез, который в общих чертах был описан в разделе 13.1. Это объясняется тем, что симптомы, которые активизируют определенный нетерминальный узел в дереве заболеваний, могут быть также существенны и для других узлов. Таким образом, программа не может предполагать, что заболевание, которым страдает пациент, должно быть найдено только среди дочерних узлов активизированного нетерминального узла. Так, хотя симптомом холеры (cholestasis) и является разлитие желчи (jaundice), существуют и другие заболевания, никакого отношения к холере не имеющие, которые могут иметь такой же симптом, например группа алкогольных гепатитов (alcoholic hepatitis). Таким образом, хотя основная идея построения дерева заболеваний состоит в том, что соседние узлы в иерархии должны соответствовать заболеваниям или группам заболеваний с общими симптомами, программе приходится часто рассматривать гипотезы из достаточно разнородных областей заболеваний.
В этом и состоит основная проблема при решении задачи диагностирования с помощью INTERNIST. В одной из своих работ Попл указал на то, что на практике использованные в программе эвристические методы управления процессом логического вывода иногда оставляют без внимания важные данные о состоянии пациента, а отдают предпочтение менее существенным с точки зрения специалистов-практиков [Pople, 1982]. Поскольку сходимость процесса поиска не совсем соответствует той идеальной картине, которая была описана выше, это приводит к серьезному затягиванию интерактивного процесса диагностирования в сложных случаях, так как на начальной стадии программа отдала предпочтение неконструктивной гипотезе. Так, результаты клинических анализов исследования различных органов пациента, если рассматривать их по отдельности, заставляют программу "распылять" внимание в нескольких направлениях. Опытный клиницист постарается интегрировать имеющиеся данные на ранних стадиях диагностирования и сосредоточиться на какой-либо одной ключевой гипотезе. Таким образом, оказывается, что схема управления процессом логического вывода, реализованная в программе INTERNIST, на практике оказывается слишком упрощенной по сравнению с моделью рассуждений, используемой опытным врачом.
Как показал опыт эксплуатации систем PUFF и CENTAUR, при работе в ограниченной предметной области, т.е. в случае, когда диагностируется довольно жестко очерченный круг заболеваний, описанная стратегия оказывается вполне приемлемой. Проблемы возникают при расширении предметной области. Нельзя сказать, что при этом метод оказывается вообще неработоспособным, поскольку программа INTERNIST все-таки справляется с довольно сложными случаями, но врачи отмечают, что при этом она иногда демонстрирует довольно странный путь поиска решения.
Попл пришел к выводу, что базовая стратегия иерархического построения и проверки гипотез нуждается в дополнении новыми структурами знаний, которые представляли бы сведения о подходящем структурировании множества альтернатив, известных опытным клиницистам. Он отметил, что в нынешней базе знаний программы INTERNIST знания о возможных конкурирующих заболеваниях представлены недостаточно полно, нужно провести дальнейшие исследования целесообразности использования различных стратегий управления логическим выводом после того, как задача дифференциального диагностирования сформулирована, в частности разработать наиболее удачные критерии отсеивания гипотез.
Если воспользоваться терминологией Кленси (см. главу 12), то в решении проблем, связанных с медицинской диагностикой, имеются структурный и стратегический аспекты, которые не представлены явно ни в организации пространства гипотез, ни в организации процедур конструирования и решения задач дифференциального диагностирования.
13.4. Рабочая среда инженерии знаний TDE
TDE [Kahn et at, 1987] представляет собой среду разработки для комплекса инструментальных средств создания экспертных систем TEST [Pepper and Kahn, 1987]. Последний ориентирован прежде всего на решение проблем классификации, к которым, в частности, относится и задача диагноза. Название системы TEST— аббревиатура от Troubleshooting Expert System Tool (комплекс инструментальных средств для построения экспертных систем поиска неисправностей), а название системы TDE — аббревиатура от TEST Development Environment (среда разработки TEST). При создании этих программ был использован подход, существенно отличающийся как от подхода при разработке программ MYCIN/EMYCIN (см. главу 10), так и от подхода, использованного при разработке программ MUD/MORE (см. главу 12).
Основным элементом представления знаний является структурированный объект, а не порождающее правило. (Для разработки TDE был использован язык описания фреймов Knowledge Craft.)
Объекты представляют понятия, тесно связанные со способом мышления специалистов по поиску и устранению неисправностей. Такие абстрактные понятия, как гипотезы и симптомы, заменены конкретными— вид отказа (failure mode) и тестовая процедура (test procedure), смысл которых будет объяснен ниже.
Свои знания пользователи вводят в систему, манипулируя пиктограммами (в этом смысле процедура ввода знаний напоминает использованную в системе OPAL (см. главу 10)).
Представление знаний имеет ярко выраженный процедуральный аспект. Например, в представлении знаний тестовые процедуры связаны с видами отказов в дополнение к вычислению степени уверенности в правдоподобности гипотезы, которая рассматривается как функция от наблюдаемых симптомов.
Вид отказа, пожалуй, самое важное понятие в TEST и TDE: оно означает любое отклонение в поведении объекта при тестировании — от полной неработоспособности до отклонений в функционировании какого-нибудь малозначительного компонента. Так, если речь идет об обслуживании автомобиля, то "двигатель не заводится" — это типичный вид отказа, но "разряжена аккумуляторная батарея" — это тоже один из видов отказа. В традиционных экспертных системах нужно было различать, чем является разряд аккумуляторной батареи, — гипотезой об источнике неисправности, которая следует из первичных данных, или симптомом, представленным в составе первичных данных. Для системы TEST это разделение не имеет такого существенного значения, как для системы MUD или MYCIN. При организации знаний в TEST использованы и другие концепции:
процедуры тестирования и ремонта неисправностей (отказов);
представление в явном виде причинно-следственных связей между отказами.
Виды отказов в системе организованы в древовидную структуру, в которой корневой узел, как правило, представляет неисправность всего устройства (составного объекта), а терминальные узлы (листья дерева)— неисправности конкретных компонентов устройства (простейших объектов). Нетерминальные узлы представляют отклонения или неисправности при выполнении отдельных функций, например "нет освещения". Между корнем дерева и терминальными узлами может находиться довольно много уровней нетерминальных узлов.
Как и в системах CENTAUR и INTERNIST, это дерево неисправностей в TEST является скелетом базы знаний. Следующий уровень структуризации составляют процедуры выполнения тестирования и устранения неисправностей и различные виды правил, представляющих процедуральные знания, связанные с видами отказов. К ним относятся знания о том, какие измерения нужно выполнить для подтверждения неисправности, как устранить ее, как отыскать компонент, неисправность которого может быть причиной данного отказа, и т.п. И, наконец, существует еще и третий уровень структуризации декларативных знаний, который представлен множеством атрибутов, связанных с узлами отказов. Эти атрибуты описывают разнообразные свойства компонентов, имеющих отношение к определенной неисправности, а также связи между компонентами.
Хотя в структуре базы знаний системы TEST и не используются такие традиционные понятия, как гипотезы и симптомы, все же можно говорить о том, что работа системы построена на базе метода эвристической классификации. Узлы отказов, расположенные ближе к корню дерева, представляют абстрактные категории данных, а те, что ближе к листьям, — абстрактные категории решений (рис. 13.3). Задача программы— построить цепочку причинно-следственных связей от узлов отказов верхних уровней, например "двигатель не заводится", до терминальных узлов вроде "разряжена аккумуляторная батарея". Отображение абстрактных категорий данных на абстрактные категории решений состоит из двух типов отношений между узлами отказов в дереве — из-за (due-to) и всегда_приводит_к (always-leads-to). Эвристики представляются на программном уровне в виде подключенных к узлам дерева правил, которые направляют процесс поиска узлов более нижних уровней.
TDE является сравнительно новой системой, которую можно считать существенным шагом вперед по сравнению с системой MORE. К сожалению, когда эта книга готовилась к печати, у нас не было возможности опробовать эту систему на практике, но кое-какие тенденции в ее конструкции просматриваются довольно четко. Например, совершенно очевидно, что графический интерфейс предоставляет пользователю гораздо большую свободу при построении базы знаний, чем символьный интерфейс системы MORE. Для новичков в системе предусмотрена опция переключения на режим вопросов и ответов. В этом режиме система задает пользователю вопросы и последовательно "ведет" его через три стадии описания знаний, которые были описаны чуть выше. Опытный пользователь может отказаться от такого режима и вводить информацию, необходимую для представления знаний, в той последовательности, которую считает наиболее целесообразной.
Рис. 13.3. Иерархическая организация узлов отказов в системе TEST
Сравнивая системы MORE и TDE, можно прийти к заключению, что даже в том случае, когда в экспертной системе используется один определенный метод решения проблем, например метод эвристической классификации, может существовать несколько методик извлечения и структурирования знаний. Многое в этом процессе еще не ясно, предстоит еще много работы по сравнению разных методик, но тот опыт, который уже получен при разработке и эксплуатации систем типа MORE и TDE, дает значительный экспериментальный материал для дальнейшего теоретического осмысления и обобщения
Рекомендуемая литература
Подробное описание программы INTERNIST и исследований, выполненных в процессе работы над этой программой, читатель найдет в работе [Pople, 1982]. Но не все идеи, описанные в этой статье, были реализованы в готовой системе и не все декларированные принципы были соблюдены при ее разработке. Архитектура системы GENTAUR была успешно использована для построения экспертных систем, не имеющих отношения к медицине. В частности, эта архитектура использована в системе REX, консультирующей статистиков при выполнении регрессионного анализа [Gale, 1986]. В работе этого же автора [Gale, 1987] описана программа извлечения знаний Student, созданная для работы в той же предметной области, что и Rex. В этой системе использованы некоторые принципы, опробованные в системе OPAL, в частности во главу угла поставлены знания, а не определенная стратегия решения проблем, принятая в данной проблемной области.
В работе [Мшеп et al, 1995] описан опыт переделки программы INTERNIST с помощью набора инструментальных средств PROTEGE (о последнем см. в [Musen, 1989] и [Rothenfluket al., 1994]). Комплекс PROTEGE во многом сходен с CommonKADS. В нем объединена1 онтологическая оболочка, подобная реализованной в системе OPAL, с обобщенным методом решения проблем [Puerto et al., 1994].
Упражнения
1. Что понимается под прототипом в системе CENTAUR? Какие функции возлагаются на прототипы?
2. В чем преимущества смешанного способа представления знаний в системе CENTAUR?
3. Что представляет собой модель заболевания в системе INTERNIST? Объясните смысл концепции доминантности применительно к модели заболеваний в системе INTERNIST.
4. Какие проблемы обнаружились при работе над системой INTERNIST и как они соотносятся с проведенным Кленси анализом различных видов знаний?
5. Выполнение этого упражнения потребует некоторых познаний в медицине — знаний о физическом смысле некоторых параметров, измеряемых при лабораторных анализах органов дыхания. (Лично я узнал о них от д-ра Джереми Уатта (Jeremy Wyatt) и д-ра Патриции Твидейл (Patricia Tweedale). Любые фактические ошибки в приведенном ниже описании прошу отнести на мой счет, но думаю, они не повлияют на смысл самого упражнения.)
При диагностике легочных заболеваний используются следующие параметры, измеряемые при лабораторном обследовании пациентов.
Index0.htm FEV1 (Forced Expiratory Volume). Объем форсированного выдоха за 1 секунду, измеренный в литрах. Измеряется количество воздуха, выдыхаемого пациентом в течение 1 секунды. Этот параметр является показателем эластичности легочных тканей (а следовательно, и их здоровья).
Index0.htm IFV1. Показатель изменения FEV1 после курса лечения с применением бронхолитиков.
Index0.htm FVC (Forced Vital Capacity). Жизненная емкость легких - объем вдыхаемого воздуха при максимальном наполнении легких.
Index0.htm IFVC. Показатель изменения FVC после курса лечения с применением бронхолитиков.
Index0.htm TLC (Total Lung Capacity). Общая емкость легких.
Index0.htm RV (Residual Volume). Остаточный объем легких - объем воздуха, который остается в легких после максимального выдоха.
Index0.htm RATI01 = FEV1/FVC.
Index0.htm RATI02 = FEV1/FVC после курса лечения с применением бронхолитиков.
Ниже в постановке задачи переменная PRED означает ожидаемое значение любого из перечисленных выше параметров. (Ожидаемое значение медицинского параметра зависит главным образом от пола пациента.) Выражения вида
80% < RATI01 < 100% (PRED-2SD)
означают, что параметр RATI01 имеет значение между 80 и 100 процентами от ожидаемого значения, уменьшенного на удвоенное стандартное отклонение в соответствующей популяции.
Аббревиатура RTB означает Response To Bronchodilation (реакция на прием бронхолитиков).
I) Разработайте структуру фреймов для каждого из следующих заболеваний дыхательных органов и связанных с ними медицинских параметров. Организуйте иерархию фреймов и включите ее в иерархию других аналогичных заболеваний, представленную на рис. 13.1.
AIRWAIS OBSTRUCTION
существует, если:
RATI01 < PRED-2SD отсутствует RTB, если:
RATI02 < PRED-2SD хороший показатель RTB, если:
RATI02 > PRED-2SD
SLIGHT AIRWAIS OBSTRUCTION
существует, если:
801 < RATI01 < 100% (PRED-2SD) отсутствует RTB, если:
IFV1 < FEV1/10
IFVC < FVC/10 хороший показатель RTB, если:
FEV1 > (PRED-2SD)/4
FEV1/3 < IFEV1
MODERATE AIRWAIS OBSTRUCTION
существует, если:
55% < RATI01 < 80% (PRED-2SD)
SEVERE AIRWAIS OBSTRUCTION
существует, если:
RATI01 <= 55% (PRED-2SD)
RESTRICTIVE DEFECT
существует, если: RV < PRED+2SD TLC <= 80% (PRED-2SD)
RATI01 > 80% (PRED-2SD)
EARLY RESTRICTIVE DEFECT существует,
если: TLC < (PRED-2SD) RATI01 > (PRED-2SD)
MILD RESTRICTIVE DEFECT
существует, если:
RATI01 > (.PRED-2SD) 80% < TLC < 100% (PRED-2SD)
MODERATE RESTRICTIVE DEFECT
существует, если:
RATI01 > (PRED-2SD)
60% < TLC < 80 (PRED-2SD)
SEVERE RESTRICTIVE DEFECT существует, если:
RATI01 > (PRED-2SD) TLC < 60 (PRED-2SD)
Вам понадобятся процедуры для накопления диагностических знаний, связанных с этими заболеваниями.
В каждом фрейме нужно предусмотреть слоты для хранения ожидаемых среднестатистических значений и стандартных отклонений. Так, слот PRED-RATI01 будет хранить ожидаемое значение параметра RATI01, а слот SD-RATI01 — стандартное отклонение этого параметра. Конечно, для этого упражнения можно подставить любые значения в эти слоты, поскольку главное, что от вас требуется, — правильно организовать связи между слотами.
Например, фрейм-объект SEVERE-RESTRICTIVE-DEFECT может включать метод (процедуру LISP) PRESENT, который определен следующим образом:
SEVERE-RESTRICTIVE-DEFECT.PRESENT
(and( > RATI01 (- PRED-RATI01 ( SD-RATI01 2)))
(< TLC (/ ( 6 (- PRED-TLC (*SD-TLC 2))) 10)))
Эта процедура возвращает значение Т, если соблюдаются специфицированные в ней условия.
II) Представьте диагностические знания, связанные с этими фреймами, в виде порождающих правил, а не в виде процедур. Как и в предыдущем случае, правила должны ссылаться на значения слотов.
6. Разработайте и реализуйте простую программу извлечения знаний, которая позволила бы пользователю передать сведения о неисправностях в некотором устройстве и перечислить их возможные причины. Например, если вас привлекает предметная область обслуживания автомобиля, то программа должна принимать сведения о таких видах отказов (в терминологии TDE), как "двигатель не заводится", уточнять причину отказа, например "подается ли ток на электродвигатель стартера?", и связывать возможные причины с каждым таким уточнением.
Естественно ожидать, что отказ "двигатель не заводится" будет связан с такими причинами, как "неисправна аккумуляторная батарея" и "неисправен соленоид стартера", а узлы отказов вроде "неисправна аккумуляторная батарея" должны требовать дальнейшего уточнения — "разряжена аккумуляторная батарея" и "недостаточный уровень электролита в аккумуляторной батарее". Программа должна сохранять всю полученную информацию в древовидной структуре, которая была описана в разделе 13.4.
7. Протестируйте разработанную в упр. 6 программу либо самостоятельно, либо пригласите коллегу, которого считаете специалистом в соответствующей предметной области. Если не удастся найти никого, кто помог бы вам в этом деле, воспользуйтесь доступной технической литературой. Например, для ввода знаний о возможных неисправностях автомобиля вполне достаточно руководства, которое выдают к каждому автомобилю при покупке.
ГЛАВА 14. Решение проблем конструирования (I)
14.1. Области применения методов конструктивного решения проблем
14.2. Система R1/XCON
14.2.1. Компоненты и ограничения
14.2.2. Использование текущего контекста для управления структурой задачи
14.2.3. Формирование суждений с учетом ограничений: метод Match
14.3. Использование знаний, развитие и расширение системы XCON
14.3.1. Извлечение знаний в системе R1/XCON
14.3.2. Совершенствование и расширение системы R1/XCON
Рекомендуемая литература
Упражнения
ГЛАВА 14. Решение проблем конструирования (I)
14.1. Области применения методов конструктивного решения проблем
14.2. Система R1/XCON
14.3. Использование знаний, развитие и расширение системы XCON Рекомендуемая литература
Упражнения
В конце главы 11 отмечалось, что отличительной чертой методов решения проблем конструирования является формирование решения из более примитивных компонентов. Этим методы решения задач конструирования отличаются от методов, применяемых для задач классификации, когда решение выбирается из некоторого фиксированного множества. В следующих двух главах будут описаны методы искусственного интеллекта, которые можно использовать для решения проблем конструирования, и на примерах, взятых из различных источников, продемонстрировано, как эти методы реализуются на практике.
Когда речь идет о решении некоторой проблемы конструирования, предполагается, что имеется пространство элементов решения, из которого можно выбирать, и имеются правила, которые помогают комбинировать выбранные элементы. Самым простым примером является задача, которую приходится решать чуть ли не ежедневно, — как одеться, чтобы не выглядеть в родной конторе пугалом. Существуют писаные и неписаные правила, в чем прилично являться на работу, а что рассматривается как пренебрежение мнением окружающих (и руководства). Итак, задача состоит в том, чтобы, во-первых, не выглядеть пугалом, а во-вторых, не вносить диссонанс в рабочую обстановку слишком вызывающим внешним видом. Даже в том случае, если отсутствуют четко сформулированные правила, вряд ли кто-нибудь посчитает совместимым костюм-тройку и кроссовки.
Можно рассматривать задачу решения проблемы конструирования и в терминах ограничений — сформировать такое решение, которое удовлетворило бы некоторым общим требованиям к качеству и при этом не противоречило бы ни одному из специальных правил, отвергающих определенные элементы решения или их комбинации
14.1. Области применения методов конструктивного решения проблем
Методы конструктивного решения проблем применяются в экспертных системах, которые используются для планирования, проектирования и некоторых видов диагностирования.
В системах планирования элементами решения являются некоторые операции, а решения — это последовательности операций, которые приводят к намеченной цели. Ограничения чаще всего связаны с естественными отношениями объектов в пространстве и времени, например два объекта не могут занимать одно и то же пространство в одно и то же время, один и тот же человек не может выполнять одновременно два вида работ и т.п.
В задачах конструирования элементами решения являются компоненты, а решения— суть комбинации этих компонентов, которые образуют сложный объект, удовлетворяющий определенным физическим ограничениям, вытекающим из свойств материалов компонентов, или определенным эстетическим соображениям.
При диагностировании множественных неисправностей элементами решения являются отдельные неисправности, а решением — множество неисправностей, которое "экономно накрывает" все наблюдаемые симптомы неправильного функционирования объекта. Таким образом, одним из ограничений может служить стремление так сформировать множество возможных неисправностей, чтобы в нем исключался многократный учет одних и тех же симптомов.
В каждом из этих случаев невозможно заранее сформировать множество решений. Существует слишком много вариантов комбинаций отдельных операций, или компонентов сложной конструкции, или совместимых неисправностей. Более того, операции могут взаимодействовать друг с другом, компоненты конкурировать за пространство или возможность подключения друг к другу, а отдельные неполадки переплетаться самым причудливым образом, учитывая возможные причинные связи между ними.
Относительно простые случаи каждой из перечисленных задач вполне могут решаться методами классификации. Например, в главе 10 мы рассматривали систему ONCOCIN, которая формировала план лечения онкобольных, выбирая из библиотеки заготовки возможных вариантов. Выбранный вариант нуждался в дальнейшем только в конкретизации дозировок и расписания приема препаратов. Более сложные проблемы таким способом решить не удается, поскольку объем библиотеки заготовок пришлось бы сделать слишком большим. Длятаких случаев единственно возможным становится конструктивный подход, который позволяет более гибко строить и модифицировать набор примитивных операций в формируемом плане действий.
В главе 2 уже отмечалось, что стремление решить задачу планирования "в лоб" выбором из пространства возможных решений неизбежно наталкивается на проблему экспоненциального взрыва при усложнении задачи и соответствующем расширении пространства решений. Это не является серьезным препятствием в том случае, когда существует довольно много удовлетворительных решений задачи и мы не слишком озабочены их качеством. Тогда и ненаправленный поиск позволяет за разумное время найти приемлемое решение. Но если желательно отыскать оптимальное или близкое к оптимальному решение, ненаправленный поиск даже при использовании чрезвычайно мощного компьютера чаще всего оказывается обреченным на неудачу. Для эффективного решения таких задач требуются знания о том, как ограничить "обследуемое" пространство решений и сфокусировать поиск именно на тех его элементах, которые образуют искомый результат.
В следующем разделе мы рассмотрим один из вариантов конструктивного метода, который получил название Match. Этот вариант дает хорошие результаты в тех случаях, когда имеющихся знаний о предметной области достаточно для того, чтобы на любой стадии вычислений определить верное направление дальнейших действий. Тогда появляется возможность использовать для решения проблем методику "предложи и попробуй", в которой основной упор сделан на выборе правильного оператора расширения частичного решения. В главе 15 будет показано, что этот метод не является универсальным, пригодным для решения любых конструктивных проблем, но в тех случаях, когда его можно применять, результаты оказываются намного лучше, чем при использовании выбора из библиотеки частичных решений.
14.2. Система R1/XCON
Система R1 была одной из первых успешных попыток применения экспертных систем в промышленности в начале 1980-х годов [McDermott, 1980], [McDermott, 1981], [McDermott, 1982,а]. Эта система предназначена для помощи разработчикам при определении конфигурации вычислительной системы на базе вычислительных устройств и блоков семейства VAX. Сначала программа проверяет полноту спецификации требований к проектируемой системе, которая представлена заказчиком. На втором этапе программа определяет конфигурацию системы, соответствующую этим требованиям. Коммерческая версия системы, разработанная совместно университетом Карнеги—Меллон и корпорацией Digital Equipment, получила наименование XCON. При описании истории разработки мы иногда будем обращать ваше внимание на отличия между начальным проектом и его коммерческой версией.
Первым практическим применением системы XCON была разработка конфигурации вычислительного комплекса VAX-11/780 на заводе фирмы DEC в Салеме, шт. Нью-Гемршир. Затем последовала разработка конфигураций других типов вычислительных комплексов, таких как VAX-11/750 и последующих модификаций продукции DEC. Наш интерес к этой экспертной системе объясняется тем, что она продемонстрировала, чего можно достичь при использовании даже относительно слабого метода решения проблем, если имеется достаточно знаний о предметной области. История развития этой системы также показывает, как расширяется сфера применения коммерческой экспертной системы при правильном менеджменте и как системы такого типа "врастают" в производственную среду.
Задачу системы R1 нельзя отнести к типу тривиальных. Типовой вычислительный комплекс включает 50-100 компонентов, главными из которых являются центральный процессор, устройство управления оперативной памятью, блоки управления интерфейсом по шинам UNIBUS и MASSBUS, причем все эти компоненты подключены к единой плате синхронизации. Шинные интерфейсы поддерживают обмен с широкой номенклатурой периферийных устройств — устройствами внешней памяти на магнитных лентах и дисках, принтерами и т.п. В результате имеется возможность строить системы самой различной конфигурации.
Получив заказ со спецификацией характеристик вычислительного комплекса, система R1 должна принять решение о том, какие устройства нужно включить в состав комплекса и как их объединить в единую систему. Принять решение о том, соответствует ли определенная конфигурация тем характеристикам, которые представлены в заказе, не так просто, поскольку для этого нужно обладать знаниями о возможностях и характеристиках всех компонентов и отношениях между разными компонентами. Не менее сложна и задача оптимальной компоновки комплекса из выбранного набора компонентов, поскольку при ее решении нужно принимать во внимание множество ограничений на взаимное расположение компонентов в структуре комплекса. Например, подключение модулей расширения UNIBUS к устройству синхронизации требует учитывать ограничения по токовой нагрузке, существующие для устройства синхронизации, и распределение приоритетов прерываний для подключаемых модулей расширения. Таким образом, задачу выбора конфигурации можно с полным правом считать классической конструктивной проблемой, которая требует для своего решения значительного объема экспертных знаний.
14.2.1. Компоненты и ограничения
Хотя и R1, и MYCIN являются программами, использующими в своей работе порождающие правила, между ними имеется ряд серьезных отличий. Одно из них состоит в том, что в MYCIN процесс решения проблемы направляется гипотезами (hypothesis-driven), т.е. процесс начинается с формулировки определенной цели, а затем она преобразуется в набор подцелей, совместное достижение которых позволяет достичь главной цели (см. об этом в главе 3). В системе R1 главным является подход, предполагающий, что процесс решения направляется данными (data-driven). Сначала программа определяет множество компонентов и далее пытается сконструировать такую конфигурацию этих компонентов, которая удовлетворяла бы ограничениям, вытекающим как из характеристик отдельных компонентов, так и из отношений и связей между ними. Для реализации программы был использован язык OPS5, один из первых языков представления правил, прямой предшественник языка CLIPS.
Для успешной работы программа R1 нуждается в знаниях двух видов:
о характеристиках компонентов — электрических (напряжение питания, потребляемая мощность, параметры выходных сигналов и т.п.), механических (габариты, тип и количество разъемов), структурных (количество портов) и т.п.;
об ограничениях, накладываемых на "совместимость" компонентов, — правилах формирования частичных конфигураций и их расширения.
Знания о компонентах хранятся в базе данных отдельно как от памяти системы порождающих правил, так и от рабочей памяти транзитных элементов данных. Таким образом, база данных имеет статическую структуру, в то время как рабочая память является динамической, В отличие от памяти порождающей системы, которая организована в виде набора модулей, управляемых по определенной схеме, база данных состоит из записей обычной структуры, которые для каждого компонента хранят информацию о его классе, типе и множестве характеристик. Например, ниже представлен фрагмент записи о контроллере накопителя на магнитных дисках типа
RK611
CLASS: UNIBUS MODULE
TYPE: DISK DRIVE
SUPPORTED: YES
PRIORITY LEVEL: BUFFERED NPR
TRANFER RATE: 212
Знания об ограничениях сохраняются в виде правил в памяти продукционной системы программы R1. Левая часть правил описывает условия (ситуацию), при соблюдении которых возможно расширение частичной конфигурации, а правая часть описывает, как выполняется расширение. В начале сеанса работы с системой рабочая память пуста, а в конце сеанса в ней содержится описание сформированной конфигурации. Компоненты в этом описании представлены в виде лексем, имеющих вид векторов, состоящих из элементов "атрибут-значение". С информацией, хранящейся в базе данных компонентов, система R1 может выполнять пять видов операций: генерировать новую лексему, отыскивать лексему, отыскивать подстановку для заданной лексемы, извлекать атрибуты, связанные с заданной лексемой, и извлекать шаблон, который в дальнейшем должен быть заполнен.
Помимо лексем компонентов, рабочая память содержит элементы, которые представляют частичные конфигурации оборудования, результаты вычислений и символьное описание текущей задачи.
Система R1 хранит порядка 10 000 правил, значительная часть которых определяет, какое следующее действие должна выполнить программа. Пример одного из таких правил приведен ниже.
DISTRIBUTE-MB-DEVICES-3
ЕСЛИ: предыдущим активным контекстом является расширение количества
устройств, подключаемых к шине .MASSBUS
& имеется однопортовый НМД, не подключенный к MASSBUS
& отсутствуют двухпортовые НМД, еще не подключенные к MASSBUS
& количество устройств, которое можно подключить к расширителю MASSBUS,
известно
& существует расширитель MASSBUS, к которому подключен по крайней мере
один НМД и который может
поддерживать дополнительные НМД
& известен тип кабеля, которым должен быть связан НМД с ранее установленным устройством
ТО: подключить НМД к MASSBUS
Такие управляющие знания о предметной области (domain-specific control knowledge) позволяют программе R1 принимать решение о том, с чего начинать и как расширять структуру комплекса, не используя при этом сложной процедуры поиска. Как мы увидим далее, программа R1, как правило, не нуждается в обратном прослеживании неудовлетворительных решений, которое можно было бы использовать для отмены сформированной частичной конфигурации и замены ее новой.
Использованные в R1 управляющие знания малочувствительны к очередности применения отдельных правил. Этим она отличается от систем, в которых общая задача конфигурирования решается разделением на подзадачи и выбором групп правил, соответствующих определенной подзадаче. В результате процесс решения проблемы в R1 направляется последовательностью правил, активизированных последними. Как будет показано в следующем разделе, для упрощения реализации такой стратегии используются некоторые из средств разрешения конфликтов, которые имеются в языке OPS5.
14.2.2. Использование текущего контекста для управления структурой задачи
Помимо информации о компонентах и ограничениях, в рабочей памяти системы R1 содержатся также символические структуры, определяющие текущий контекст вычислительного процесса. Это помогает разделить задачу конфигурирования на подзадачи. В первом приближении можно считать, что каждой такой подзадаче соответствует активизация определенной группы правил. Более того, эти подзадачи можно организовать, в иерархическую структуру с временными отношениями между ними и таким образом наложить на задачу конфигурирования структуру, в чем-то схожую с планом.
Другими словами, главная задача, скажем "разработать конфигурацию модулей VAX-11/780 соответственно данному заказу", может быть разбита на ряд подзадач, например "проверить корректность заказа", "подобрать компоненты в соответствии с заказом (возможно, ранее скорректированным)". Выполнение этих двух задач приведет к выполнению главной задачи. Естественно, что порядок выполнения подзадач не может быть произвольным, — вряд ли кому-то придет в голову сначала подобрать компоненты в соответствии с заказом, а потом проверять, не допущена ли в заказе ошибка.
Программа R1 разбивает задачу конфигурирования на шесть подзадач, каждая из которых, в свою очередь, может быть разбита на более мелкие подзадачи.
(1) Проверить заказ, уточнить все пропущенные в нем сведения и исправить замеченные ошибки.
(2) Включить в конфигурацию модуль центрального процессора, все компоненты, непосредственно связанные с центральным процессором, и определить состав блоков основной стойки комплекса.
(3) Включить в конфигурацию модули расширения шины UNIBUS, определить состав блоков в стойке расширения интерфейса.
(4) Включить в конфигурацию генпанели, распределить их между стойками и связать с блоками расширения интерфейса и обслуживаемыми устройствами.
(5) Составить план расположения стоек, распределить блоки периферийных устройств между стойками с учетом длин связей.
(6) Разработать схему соединения стоек и выбрать типы кабелей.
По отношению к порядку выполнения подзадач эта иерархическая схема может быть либо детерминированной, либо недетерминированной. Если в пределах подзадачи на любую заданную глубину порядок выполнения операций фиксирован, то говорят, что используется детерминированный анализ задач. В противном случае — допустимы отклонения в последовательности выполнения подзадач на любом уровне — считается, что используется недетерминированный анализ задач.
В системе R1 детерминированный анализ используется только в отношении части задач, которые всегда выполняются в одном и том же порядке. Достигается такое упрощение следующим образом. Множество правил в R1 служит просто для управления символами контекста — теми элементами рабочей памяти системы, которые несут информацию о текущем положении системы в иерархии задач. Одни правила этой группы определяют условия, при которых нужно инициировать новую подзадачу, — при этом в рабочую память добавляются новые символы контекста, а другие правила распознают, закончилось ли выполнение подзадачи, и удаляют символы контекста из рабочей памяти. Все остальные правила содержат элементы условий, анализирующие символы контекста, а потому они выполняются только в том случае, если "активен" соответствующий контекст. Чтобы разобраться в том, как работает этот механизм на практике, нужно остановиться хотя бы вкратце на стратегии разрешения конфликтов, используемой в R1.
Каждый символ контекста содержит имя контекста, например "подсоединение_источника_питания", символ, который несет информацию о том, активен данный контекст или нет, тэг времени, который несет информацию о том, как давно контекст был активизирован. Правила, которые распознают, когда должна быть запущена на выполнение новая подзадача, используют с этой целью текущее состояние частичной конфигурации. Те правила, в условной части которых имеется соответствующий символ контекста, получают более высокий приоритет в цикле "распознавание состояния — действие".
Общепринято размещать условия распознавания контекста в самом начале антецедентной части порождающего правила. В результате, если это условие не соблюдается, не тратится время на анализ остальных. Кроме того, стратегия разрешения конфликтов в системе R1 (она получила название ME А) обращает особое внимание на первое условие в правиле после его конкретизации перед возможным применением. У правил, которые деактивизируют контекст, антецедентная часть состоит из единственного символа контекста. Такое правило будет применено только после всех остальных правил, чувствительных к тому же контексту. Это пример использования стратегии специфики. Следуя этой стратегии, система R1 сначала выполняет все действия, связанные с определенным контекстом, а уже после этого изменяет его.
Основная эвристика специфики состоит в следующем. Если существуют два конфликтующих правила Rule 1 и Rule 2 и условия, специфицированные в правиле Rule 2, являются подмножеством условий, специфицированных в правиле Rule 1, то правилу Rule 1 дается более высокий приоритет, чем правилу Rule 2. Можно и по-другому рассматривать эту эвристику. Правило Rule 2 является более "общим", чем правило Rule 1, и оно обрабатывает по умолчанию те случаи, которые не "охватываются" более специализированным правилом Rule 1. При этом фактически правило Rule 1 имеет дело с исключениями из общего правила Rule 2, поскольку в нем принимаются во внимание дополнительные условия (рис. 14.1).
Рис. 14.1. Пример применения стратегии специфики: правило Rule 1 доминирует над правилом Rule 2
В языке OPS5 (а также в CLIPS) эвристика специфим Машина логического вывода частично упорядочивает кон в качестве критерия упорядочения количество проверок правилах. В частности, выполняется анализ соответствия констант или переменных заданным значениям. Доминировать будут те правила, для которых потребуется наибольшее количество проверок. В любом случае применение стратегии МЕА помогает упорядочить применение правил, сделать его более или менее регулярным.
Мак-Дермот (McDermott) конкретизировал использование контекстов состояния применительно к задаче формирования конфигурации вычислительной системы. Он считает, что этот способ довольно хорошо передает подход к решению аналогичных задач экспертом-человеком. Нужно, однако, отметить, что система R1 не располагает реальными знаниями о свойствах контекста, с которым имеет дело. Имена контекста— это только некоторые символические обозначения, в отличие от компонентов, с которыми связаны все виды атрибутов и значений. Следовательно, система R1 не может "рассуждать" о контекстах так же, как она "рассуждает" о компонентах или ограничениях. Система просто распознает состояние, когда ей необходим новый контекст или когда завершены все операции, связанные с данным контекстом.
14.1. Стратегии разрешения конфликтов LEX и МЕА
В главе 5 были упомянуты стратегии разрешения конфликтов LEX и МЕА, реализованные в языке CLIPS. Ниже будет в общих чертах рассмотрена реализация стратегии МЕА, которая использована в системе R1/XCON.
Как было показано в главе 3, анализ "средство — анализ результата" является абстрактным режимом формирования цепочки обратного логического вывода в случае, когда определена некоторая цель. Этот режим позволяет выбрать операторы или правила, которые способны сократить "расстояние" между текущим и заданным целевым состоянием проблемы. Несложно показать, как этот режим можно использовать в контексте порождающей системы с обратной стратегией логического вывода, например MYCIN, когда весь процесс начинается с цели самого верхнего уровня общности (см. главу 3). В системах, использующих прямой логический вывод, которые строятся на основе языковых средств OPS5 или CLIPS, применяется стратегия разрешения конфликтов МЕА. Основанный на ней режим управления позволяет программе "продвигаться" по неявно заданному дереву целей, которые представлены специальными лексемами в рабочей памяти экспертной системы.
Алгоритм МЕА включает пять шагов. Напомним, что конфликтующее множество правил включает те конкретизированные правила, которые должны быть активизированы в течение одного и того же цикла вычислений. Конкретизация правила представляет собой совокупность обобщенной формулировки правила и значений используемых в нем переменных .
(1) Исключить из конфликтующего множества те правила, которые уже были применены в предыдущем цикле. Если после этого множество стало пустым, прекратить процесс.
(2) Сравнить "новизну" элементов в рабочей памяти, которые соответствуют первым элементам условий в конкретизированных правилах, оставшихся в конфликтующем множестве. Приоритет отдается тем правилам, которые обращаются к самым "свежим" элементам рабочей памяти,— эти правила "доминируют" над остальными. Если существует единственное такое правило, то оно выбирается для применения, после чего процесс должен быть прекращен. В противном случае, если имеется несколько доминирующих правил с
равным приоритетом, они сохраняются в конфликтующем множестве, а прочие из него удаляются. Далее выполняется переход к шагу (3).
(3) Упорядочить конкретизированные правила по "новизне" остальных элементов условий в правилах. Если доминирует единственное правило, оно применяется и затем процесс прекращается. Если же доминируют два или несколько правил, то они остаются в конфликтующем множестве, а остальные удаляются из него. Затем выполняется переход к шагу (4),
(4) Если по критерию "новизны" элементов условий отобрано несколько правил с равными показателями, то сравнивается другой показатель правил — показатель специфики. Предпочтение отдается тому правилу, применение которого требует проверки наибольшего количества условий в рабочей памяти. Если "претендентов" окажется несколько, остальные удаляются из конфликтующего множества и выполняется переход к шагу (5).
(5) Применяется правило, выбранное произвольным образом из оставшихся в конфликтующем множестве, и процесс прекращается.
Таким образом, стратегия МЕА объединяет в едином алгоритме анализ таких показателей, как повторяемость, новизна и специфика. Алгоритм LEX практически идентичен алгоритму МЕА за одним исключением — в нем отсутствует шаг 2), а на шаге 3) сравниваются все элементы условий конкретизированных правил и связанных с ними элементов рабочей памяти. Первые элементы условий, которые использовались на шаге 2), являются, как правило, лексемами задач в рабочей памяти (в главе 5 приведен пример программы, которая манипулирует такими лексемами).
14.2.3. Формирование суждений с учетом ограничений: метод Match
Для иллюстрации использования ограничений в системе R1 рассмотрим, как выполняется подзадача 3), конфигурирование модулей расширения шины UNIBUS в шкафах и блоках.
Основная сложность решения проблемы "распределения по закромам" состоит в том, что, как правило, не удается найти подходящий способ поиска в пространстве состояний, поскольку отсутствует подходящая оценочная функция для сравнения частичных конфигураций. Другими словами, отсутствует формула, которую можно было бы применить для того, чтобы сказать, что такая-то конфигурация лучше некоторой другой. Система функциональных и пространственных связей сама по себе является единым сложным объектом, и невозможно по отдельному ее фрагменту заранее сказать, приведет ли данный путь к удовлетворительному решению или нет. Это можно сделать, только получив определенные характеристики системы в целом, например показатели ее симметричности, которые влияют на избыточность.
В контексте подзадачи 3) существует ряд ограничений, которые можно использовать для унификации поиска решения.
Каждый модуль UNIBUS требует размещения на генплате ответного разъема подходящего типа.
Каждая генплата в шкафу должна быть размещена таким образом, чтобы все подключенные к ней модули пользовались одними и теми же блоками питания.
Выходная мощность каждого блока питания ограничена и не зависит от количества слотов на генплате.
Если модулю необходимо выделить пространство на панели управления, это можно сделать только на панели того шкафа, в котором размещен модуль.
Некоторые модули требуют для своей работы подключения других модулей, которые должны размещаться либо в одном блоке с обслуживаемым модулем, либо подключаться к той же генплате.
Существует оптимальная последовательность подключения модулей к шине UNIBUS, которая влияет на назначение модулям приоритетов прерываний и на скорость передачи информации по шине. Желательно размещать модули таким образом, чтобы их конфигурация как можно меньше отличалась от оптимальной.
Как правило, существует и ограничение на объем внутреннего пространства в шкафах системы. В результате, сказать о том, приемлема определенная конфигурация или нет, можно только после того, как на шине будут размещены все модули системы. Поэтому иногда система R1 вынуждена формировать несколько вариантов компоновки модулей, прежде чем будет найдена приемлемая.
Хотя система R1 и формирует иногда несколько вариантов решения одной и той же задачи, в ней никогда не выполняется обратное прослеживание. Иными словами, в ней никогда не формируется промежуточный вариант решения, к которому затем можно вернуться и отменить. На любой стадии процесса решения задачи система располагает достаточными знаниями для того, чтобы сделать следующий шаг. Использование обратного прослеживания потребовало бы значительных вычислительных ресурсов, особенно ресурсов оперативной памяти. К тому же при использовании обратного прослеживания пользователю очень сложно понять ход рассуждений, который привел к предлагаемому варианту решения.
Для основной проблемы в том способе решения проблемы, который использован в системе R1, разработчики выбрали наименование "Match" (сопоставление), которое вносит некоторую путаницу в смысл проблемы. Любые системы, основанные на применении правил, в той или иной мере используют сопоставление, но разработчики системы R1 придали термину Match (начинающемуся с прописной буквы "М") несколько иной смысл. Вместо того чтобы формировать набор решений-кандидатов и затем выбирать из них подходящий, как это делается в системе DENDRAL (см. главу 20), программа, использующая метод Match, на каждой стадии процесса "распознает", что ей делать дальше.
Метод Match можно рассматривать как метод поиска экземпляра, который означивал бы (конкретизировал) определенную "форму", — символическое выражение, содержащее переменные. Примером такой формы может служить левая часть выражения порождающего правила. Таким образом, пространством поиска для метода Match является "пространство всех означиваний переменных в форме" [McDermott, 1982, а, р. 54]. Каждое состояние в этом пространстве соответствует частично означенной форме.
Существуют формы, которые заключают в себе знания, специфические для данной предметной области, касающиеся удовлетворения ограничений. Именно с ними при решении данной частной проблемы и имеет дело метод Match. Мак-Дермот указал на два условия, которые нужно удовлетворить для того, чтобы можно было использовать для отыскания решения этот довольно "слабый" метод поиска.
Соответствие условий. При сравнении конкретизированного экземпляра с образцом должна существовать возможность определить значение переменной на основе ограниченной информации локального характера. Применительно к системе R1 это означает возможность на любой стадии пользоваться только той информацией, которая доступна в рамках текущего контекста. Решение не должно зависеть от информации, доступной в каких-либо других контекстах ("дочерних" или "братских"), как бы близко к текущему они ни находились в иерархии контекстов. Это не означает, что контексты должны быть независимы; просто последующие сопоставления не должны использовать те, которые были выполнены раньше.
Однонаправленное распространение условий. Применение какого-либо оператора должно сказываться только на тех компонентах решения, которые до сих пор не были определены. Другими словами, применение какого-либо оператора не должно давать никаких побочных эффектов, которые могли бы повлиять на уже сформированные компоненты решения. Само название условия говорит о том, что последствия применения операторов должны распространяться только в одном направлении — от текущего контекста к "дочерним" и еще не проанализированным "соседним", но не в обратном направлении, — к "родительским" контекстам.
Мак-Дермот разделил все правила системы R1 на три категории в зависимости от их отношения к методу Match.
(1) Правила применения операторов, которые формируют и модифицируют частичную конфигурацию.
(2) Правила установки последовательности, которые указывают порядок принятия решений, используя для этого в основном текущий контекст.
(3) Правила накопления информации, которые организуют обращение к базе данных компонентов и отвечают за выполнение разнообразных вычислений "по заказу" других правил.
Выше уже отмечалось, что использование понятия контекста при решении задачи синтеза конфигурации в определенной мере соответствует тому способу мышления, который близок эксперту-человеку. Однако попытка рассмотреть понятие контекста с точки зрения формальных вычислений не предпринималась. Если же обратиться к методу Match, то ситуация становится в определенной мере обратной. Человек-эксперт при решении аналогичной задачи не использует ничего, подобного этому методу. Скорее он склонен к эвристическому поиску в той или иной форме, что само по себе часто приводит к использованию обратного прослеживания. Преимущество использования метода Match с точки зрения затрачиваемых вычислительных ресурсов несомненно, и в этом ему следует отдать предпочтение перед методом эвристического поиска при разработке программ решения тех задач, где метод Match можно применить
14.3. Использование знаний, развитие и расширение системы XCON
В этом разделе мы рассмотрим, какие особенности использования знаний существуют в системе XCON, как эта система совершенствовалась и расширялась. Система XCON выбрана в качестве примера по той простой причине, что процесс приобретения и расширения знаний в этой системе довольно подробно описан в доступной автору документации, чего нельзя сказать о множестве других экспертных систем. Совершенно очевидно, что три эти темы — извлечение знаний, совершенствование и расширение возможностей экспертной системы — тесно связаны. Проблема извлечения знаний применительно к системе XCON осложняется тем, что для решения задачи конфигурирования вычислительной системы требуются самые разнообразные знания. Но не нужно забывать о том, что углубленный анализ применяемых методов решения проблемы может в определенной мере упростить задачу извлечения необходимых знаний, как это было продемонстрировано в главах 11-13
14.3.1. Извлечение знаний в системе R1/XCON
В работе [McDermott, 1982, а] содержится множество интересных наблюдений о том, как выполняется начальная фаза извлечения знаний для системы R1.
У экспертов имеется достаточно четкое, систематическое представление о том, как разбить основную задачу на подзадачи, и о том, какие отношения существуют между этими подзадачами.
При решении сформулированных подзадач, однако, поведение экспертов определяется не столько общими принципами, сколько исключениями из них, например "при выполнении подзадачи S выполнять алгоритм X, пока не будет выполнено условие У". Можно считать, что в процессе решения подзадач поведение эксперта в основном направляется событиями.
Такая систематичность в выявлении отношений между подзадачами и несистематичность решения отдельных подзадач при реализации на языке OPS5 приводит к использованию контекстов и специальных случаев. Раздельное уточнение правил и контекстов обеспечивает модульный характер коррекции ошибок в поведении системы на начальном этапе ее разработки. Однако в работе [McDermott, 1988] Мак-Дермот обратил внимание на то, что различные виды знаний не всегда хорошо различимы в рамках решения одной подзадачи. В частности, в составе правил можно встретить два класса знаний:
знания о разных способах расширения частичной конфигурации;
знания о том, какой из возможных вариантов расширения следует выбрать.
Бачан ([Bachant, 1988]) присоединился к мнению Кленси ([Clancey, 1983]) и других, ратовших за более обобщенный подход к этой проблеме. В частности, предлагалось использовать явные средства управления режимом выполнения правил. Сторонники этого подхода обращали внимание на то, что разрешение конфликтов выполняется на очень низком уровне иерархии задач, хотя можно было бы его использовать для декомпозиции в пределах задач. В новом методе, названном RIME (аббревиатура от Rl's Imlicit Made Explicit — то, что в R1 было неявным, сделано явным), была предпринята попытка найти оптимальное соотношение между слишком жестким и слишком мягким режимами управления последовательностью выполнения операций. Основной метод решения проблем в системе R1 можно отнести к виду предложи-и-примени (propose-and-apply), который состоит из следующих шагов.
(1) Инициализация цепи. Формируется элемент управления для текущей задачи и удаляются все устаревшие элементы управления для тех задач, которые уже завершены.
(2) Предложение. Предлагаются возможные варианты дальнейших действий и отвергаются неприемлемые варианты. Варианты представляются в виде операторов.
(3) Удаление лишнего. Удаляются лишние операторы в соответствии с глобальным критерием, например заранее определенным приоритетом операторов.
(4) Разрешение конфликтов. Выполняется попарное сравнение конкурирующих операторов и принимается решение, какой из двоих оставить.
(5) Выбор единственного оператора. Анализируется результат выполнения шагов 2—4 и из всех оставшихся операторов выбирается единственный.
(6) Применение оператора. Выбранный оператор применяется к текущему состоянию проблемы и таким образом формируется расширение частичной конфигурации.
(7) Оценка цели. Проверяется, не достигнута ли сформулированная цель. Если цель достигнута, процесс завершается, в противном случае цикл повторяется.
Итак, как следует из анализа, выполненного Бачаном, слабый метод (Match) использует в процессе выполнения более строгий метод (предложи-и-примени). Этот подход в чем-то аналогичен использованию эвристической классификации (строгий метод) для формирования подцелей (слабый метод) в системе MYCIN.
Несколько позже Мак-Дермот (см. [McDermott, 1988]) назвал такие более строгие методы, которые используются в сочетании с более слабыми, "role-limiting methods" (методами с ограничением роли). Методы этой группы характеризуются видом тех управляющих знаний, которые используются для выявления, отбора и применения действий, выполняемых системой. При этом предполагается, что существует группа задач, для которых использование определенной части управляющих знаний может считаться независимым от специфики предметной области.
Таким образом, можно считать, что методы с ограничением роли— это такие "методы, которые строго направляют процесс накопления и представления знаний". Хотя это определение и нельзя признать достаточно строгим, в нем выражена главная идея — некоторый метод можно отнести к группе методов с ограничением роли в том случае, если те управляющие знания, которые, как правило, используются этим методом, не очень тесно связаны со спецификой решения задачи. Можно, конечно, возразить, что в таком случае метод эвристической классификации, который используется в MYCIN, также относится к этой группе, если не обращать внимание на тот факт, что в MYCIN используются нарождающие правила.
Справедливо, однако, утверждение, что некоторая часть экспертных систем может содержать управляющие знания менее абстрактного характера, т.е. знания, так или иначе связанные с объектами определенной предметной области и отношениями между ними. Мак-Дермот, в частности, процитировал одно из правил системы R1/XCON, которое приведено ниже.
ЕСЛИ
два действия-кандидата суть
включить в систему НМД RA60,
включить другой тип НМД,
который использует тот же тип корпуса,
ТО
отдать предпочтение на следующем шаге включению в систему НМД RA60.
ЕСЛИ
два действия-кандидата суть
включение в систему устройства, монтируемого на генпанели, тип которого
не RV20A или RV20B,
включение в систему другого устройства, монтируемого на генпанели, тип которого не RV20A или RV20B, и не выбран шкаф, и существует шкаф, в который можно вставить устройство, и желательно разместить первое устройство в шкафу перед тем, как размещать в нем второе устройство,
ТО
отдать предпочтение на следующем шаге включению в систему первого устройства.
Первое правило можно обобщить, если известно, почему предпочтительнее сначала иметь дело с НМД типа RA60. А вот второе правило кажется очень тесно связанным со спецификой размещения устройств отдельных типов в шкафах и их взаимной компоновкой. Более того, в этом правиле использованы отношения между объектами предметной области, которые можно отнести к разным уровням абстракции. Мак-Дермот обратил внимание на то, что тот вид суждений, который представлен в таких правилах, будет меняться от одной области применения системы к другой, а следовательно, его не удастся обобщить.
14.3.2. Совершенствование и расширение системы R1/XCON
Как уже отмечалось ранее (см. главу 3), совершенствование экспертной системы в процессе ее опытной эксплуатации — это отдельная, достаточно сложная тема для обсуждения. В процессе разработки системы оценка ее будущей производительности зачастую бывает весьма туманной. Понятно, что программа должна выполняться за разумное время и на первых порах справляться с типовыми для данной предметной области случаями, в частности с теми, которые использовались для извлечения знаний в процессе интервью с экспертами. Но стоит задуматься и над тем, чтобы разработать тест или набор тестов, которые позволят оценить реальную производительность системы и выявить те случаи, когда она достигает максимума.
В тех областях, где формализация затруднена или невозможна, вряд ли удастся когда-либо представить убедительное доказательство того, что данная система действительно является экспертом в некотором отвлеченном смысле. Свидетельство может быть только эмпирическим и включать диапазон возможных ситуаций, с которыми справляется программа. Для любого нетривиального применения этот диапазон должен быть достаточно широким. Несмотря на то что программа XCON на сегодняшний день обработала десятки тысяч заказов, считается, что просмотрена только малая часть пространства возможных вариантов.
По словам Мак-Дермота, на начальной стадии эксплуатации системы R1 предполагалось, что она сможет стать действительным помощником разработчика только после того, как будет справляться примерно с 90% всех поступающих заказов, т.е. сформированные программой по этим заказам компоновки вычислительной системы будут не хуже тех, которые проектируются опытным специалистом. Для того чтобы достичь такого уровня совершенства, с программой R1 пришлось повозиться почти три года, но опыт показал, что начальные требования к "изобретательности" системы были завышенными. Программа была признана пользователями вполне работоспособной и полезной еще до того, как достигла такого высокого уровня совершенства, поскольку качество ее работы не уступало качеству работы рядового специалиста. Проектирование конфигураций относится к тому классу задач, который редко решается каким-либо специалистом в одиночку. Как правило, одному специалисту для этого не хватает ни знаний, ни времени. Поэтому помощь, которую оказывала система R1 в решении этой задачи, была весьма кстати.
Можно ли считать решающим критерием сравнение результатов, полученных экспертной системой, с теми, которые получают эксперты в этой же предметной области? Вопрос этот не так прост, как кажется на первый взгляд. Помимо того, что в нем скрыта проблема выбора подходящих тестов, существует еще и проблема адекватного сравнения результатов. Система R1 дает более детальное решение этой задачи, чем человек-эксперт. Последний оставляет многие детали на усмотрение персонала, непосредственно занятого монтажом системы. Можно ли сравнивать проект, созданный экспертной системой, с результатами работы не только инженера-проектировщика, но и техников, монтирующих систему? Нужно принять во внимание еще и следующий нюанс. При монтаже системы техники имеют возможность экспериментировать с компоновкой в определенных пределах, а программа этой возможности лишена. Таким образом, сравнение будет не совсем корректным.
Добавление в экспертную систему новых знаний также не является тривиальной проблемой. Во-первых, новые знания добавляются в систему уже на стадии отладки тех знаний, которые были введены в первоначальный вариант системы. Во-вторых, существуют и другие причины, требующие включения новых знаний на протяжении всего жизненного цикла системы.
(1) Требуется ввод знаний о более широком классе объектов, с которыми должна иметь дело система. Например, может потребоваться проектировать конфигурации новых типов вычислительных систем.
(2) Могут потребоваться новые знания, улучшающие качество решения путем включения новых подзадач. Например, в случае задачи компоновки можно включить подзадачу размещения панелей управления на шкафах комплекса.
(3) Возникла необходимость расширения формулировки основной задачи системы. Например, первоначальный вариант системы R1 предполагал выполнение компоновки только однопроцессорных вычислительных комплексов, а затем возникла идея поручить этой системе и задачу компоновки многопроцессорных комплексов.
Как показывает опыт работы с системой R1, процесс расширения возможностей системы продолжается до тех пор, пока не завершится ее жизненный цикл. Предметная область вычислительных систем находится в постоянном движении — появляются новые компоненты (устройства) с новыми свойствами, которые по-разному сочетаются друг с другом и с ранее разработанными компонентами. Поэтому в экспертной системе и база данных, и рабочая память находятся в состоянии постоянного изменения. Более того, жизненный цикл системы можно уподобить погоне за движущейся целью, что делает и так непростые ее задачи еще более сложными.
Опыт работы с XCON показал, что непрерывное внесение изменений в систему приводит к определенной ее избыточности. Другими словами, если не предпринимать специальных мер противодействия, то уровень беспорядка в развивающейся системе будет постоянно нарастать. Построение новой системы с самого начала — это слишком дорогое удовольствие как в смысле материальных затрат, так и в смысле времени. Эти ресурсы гораздо целесообразнее направить на разработку средств, облегчающих расширение возможностей существующей системы. Вряд ли существует однозначный ответ на этот вопрос. Грамотный разработчик экспертных систем должен решать эту задачу, принимая каждый раз во внимание конкретные обстоятельства создания и область назначения именно данной системы. Читателям, интересующимся, как решили эту проблему разработчики системы XCON, мы советуем ознакомиться с врезкой 14.2.
В следующей главе будут рассмотрены две другие системы, предназначенные для конструктивного решения проблем, в которых использована более сложная стратегия управления. Дело в том, что в некоторых приложениях экспертных систем не соблюдается описанное в разделе 14.2.3 соответствие условий. Другими словами, не всегда удается на основании локальной информации определить, какая операция должна быть выполнена на следующем шаге, поскольку на текущее состояние задачи не наложены достаточные ограничения. В такой ситуации можно попытаться принять решение таким образом, чтобы оставались открытыми дополнительные возможности, или подготовиться к возможной отмене принятого решения, если позже обнаружится нарушение заданных ограничений. Будет показано, что такая стратегия серьезно усложняет процесс решения, но часто удается справиться с этими трудностями, привлекая на помощь знания из предметной области.
14.2. Совершенствование системы XCON
В течение 1986-1987 годов система XCON подверглась коренной модернизации на основе методологии RIME. Принцип нисходящего разложения проблемы на подзадачи (последние получили в новой терминологии наименование пространства системы— problem spaces) в процессе вычислений, который был реализован в системе R1, остался в неприкосновенности, нобыла изменена система классификаций правил. За основу новой системы классификации были взяты этапы выполнения алгоритма предложи-и-примени, на которых используется то или иное правило. Каждое пространство проблемы представляет относительно независимую подзадачу и специфицируется тремя параметрами:
управляющая структура, которая описывает метод решения проблем, применяемый в этом пространстве;
знания, которые используются для принятия решения о том, какое пространство проблемы должно быть активным в любой данный момент времени;
операторы, которые позволяют манипулировать объектами в данном пространстве, если оно становится активным.
Таким образом, за каждым пространством проблемы закрепляются правила типов предложение, удаление лишнего и т.д., чем достигается определенная систематизация представления знаний из системы R1. Однако главная особенность такой организации в том, что она обеспечивает применение более систематического подхода к извлечению необходимых знаний. В частности, она позволяет извлекать знания, специфичные для каждой подзадачи, на что обращал внимание Мак-Дермот.
Возвращаясь к системе R1/XCON тремя годами позже, Мак-Дермот отметил, что из опыта ее эксплуатации и модернизации нужно извлечь три урока [McDermott, 1993].
Работа с R1/XCON продемонстрировала важность управляющих знаний, специфичных для определенной предметной области. Обладая достаточными знаниями о том, что делать дальше, программа способна в процессе выполнения сложной задачи определить очередную операцию, пользуясь только локальной информацией.
Система, основанная на порождающих правилах, обеспечивает необходимый механизм уточнения и расширения знаний. В частности, это касается знаний об ограничениях, свойственных каждой подзадаче, и о том, какое подмножество всех возможных операций доступно для конкретной подзадачи. Когда такие отношения превалируют между подзадачами, менее вероятно, что добавление новых правил будет каким-либо образом влиять на уже имеющиеся, относящиеся к прежним задачам.
Для того чтобы экспертная система была признана полезной, она должна не только правильно выполнять возложенные на нее в первоначальном проекте задачи. Интеграция программ, подобных R1, в производственную систему является не менее важным фактором успеха всей разработки, что, как правило, со пряжено с преодолением множества трудностей организационного и даже психологического характера.
Таким образом, модернизация системы XCON вполне оправдала затраты. Конечно, этот вывод нельзя распространять на любую экспертную систему. Для небольших систем вполне может подойти и старое доброе правило "пока оно работает, не трогай его”
Рекомендуемая литература
Процесс разработки и модернизации системы R1/XCON достаточно подробно отражен в технической литературе, однако назвать единственный источник, в котором можно было бы найти все детали этого проекта, затруднительно. Хорошей отправной точкой для знакомства с этим проектом может послужить работа [McDermott and Bachant, 1984]. Рекомендуется обратить внимание еще на одну совместную разработку университета Карнеги—Меллон и фирмы Digital Equipment— систему XSEL ([McDermott, 1982,bJ, [McDermott, 1984]}. Это программа, написанная на языке OPS5, которая помогает клиентам фирмы выбрать компоненты вычислительного комплекса VAX и разместить элементы комплекса в производственном помещении.
Весьма интересный анализ сильных и слабых сторон методов с ограничением роли выполнен в работе [Мшеп, 1992], которую рекомендуется прочесть вслед за статьей Мак-Дермота [McDermott, 1988]. В работе [Studer et al, 1998] обсуждаются как методы с ограничением роли, так и порождающие задачи, причем в качестве примера при обсуждении концепций используются системы CommonKADS и PROTEGE-II.
Упражнения
1. Почему проблемы планирования и проектирования не всегда могут быть решены с помощью методов классификации? При соблюдении каких условий методы классификации могут быть использованы для решения проблем этих классов?
2. Что представляет собой метод Match? Какие "условия соответствия" должны быть соблюдены для того, чтобы этот метод сработал?
3. В чем состоит стратегия специфики, применяемая для разрешения конфликтов, и как она реализована в системе R1?
4. Детально опишите использование контекста в процессе работы системы R1. "Понимает" ли сама система используемую в ней стратегию решения проблемы нисходящим уточнением?
5. Что представляет собой "пространство проблемы" в методологии RIME и какую роль оно играет?
6. В чем преимущество использования более явного представления стратегии, реализованного при модернизации системы XCON?
7. Подумайте, как можно автоматизировать решение следующей задачи проектирования конфигурации. Эта задача достаточно сложна, чтобы не считаться тривиальной, но, конечно же, значительно уступает по сложности задаче проектирования конфигурации вычислительного комплекса.
Описание задачи. Пользователь системы желает скомпоновать музыкальный комплекс, в состав которого должны входить электрогитара, усилитель и педали звуковых эффектов. Задача экспертной системы — помочь пользователю выбрать вариант комбинации компонентов, которые обеспечат желаемое качество звучания.
Данные и знания. Данные, передаваемые в систему, должны включать следующие параметры:
музыкальный жанр, на который ориентируется пользователь (джаз, блюз, рок и т.д.);
стиль игры (ритмический, с медиатором и т.д.);
предпочтительная тональность ("жирный" или "тонкий" звук, "сладкий" или более резкий и т.п.);
"образцы для подражания", стилю игры которых следует пользователь (например, Клептон, Бек, ван Хален и т.д.);
сумма, которой располагает пользователь для покупки каждого из основных компонентов.
Постарайтесь отыскать среди своих знакомых заядлого гитариста и "вытянуть" из него необходимые знания. Рассматривайте это упражнение, в первую очередь, как упражнение на проектирование.
Анализ задачи. Используйте тот же вид анализа задачи, который мы применяли в отношении системы R1, т.е. разложение задачи на подзадачи. Отправной точкой может послужить И/ИЛИ-дерево, приведенное на рис. 14.2. Постарайтесь либо построить систему на определенную глубину дерева, либо сделать ее более специализированной, "разрисовав" подробнее одно из поддеревьев, выбор усилителя или гитары.
Организуйте детерминированный просмотр дерева программой в процессе решения задачи и выполняйте его сверху вниз и слева направо. Наиболее важное решение, которое должна принять программа, — выбор гитары. Поэтому сначала завершите эту задачу, а затем переходите к выбору усилителя. Естественно, сначала нужно выбрать изготовителя и модель, а уже потом тип струн и прочих аксессуаров.
Рис. 14.2. Дерево анализа задачи проектирования конфигурации музыкального комплекса
Мы выделили две категории усилителей — транзисторные и ламповые. Хотя усилители обеих категорий могут работать с гитарами любого типа, все же ламповые усилители предпочтительнее для одних стилей исполнения и музыкальных жанров, а транзисторные — для других. Еще одно соображение нужно принимать во внимание. Некоторые модели усилителей имеют встроенные средства создания звуковых эффектов, например реверберации или хорового исполнения. При выборе таких моделей соответственно должны быть скорректированы требования к педалям дополнительных эффектов. Выбор набора педалей зависит, естественно, от предпочтительных музыкальных жанров и стилей исполнения
ГЛАВА 15. Решение проблем конструирования (II)
15.1. Стратегии конструирования
15.2. Архитектура систем планирования и метапланирования
15.3. Извлечение, представление и применение знаний о проектировании
15.3.1. Реализация обратного прослеживания в системе VT
15.3.2. Приобретение знаний с помощью системы SALT
15.4. Итоги анализа систем решения проблем конструирования
Рекомендуемая литература
Упражнения
ГЛАВА 15. Решение проблем конструирования (II)
15.1. Стратегии конструирования
15.2. Архитектура систем планирования и метапланирования
15.3. Извлечение, представление и применение знаний о проектировании
15.4. Итоги анализа систем решения проблем конструирования Рекомендуемая литература
Упражнения
В предыдущей главе мы рассматривали экспертные системы для решения проблем конструирования, в которых по ходу процесса никогда не возникала необходимость отмены уже принятых решений. Однако такая стратегия подходит далеко не для всех задач конструирования, поскольку мы не всегда располагаем всеми необходимыми для этого знаниями о предметной области. В этой главе мы проанализируем применение двух стратегий — наименьшего принуждения (least commitment) и предложение и пересмотр (propose and revise). Завершит главу обзор некоторых инструментальных средств приобретения знаний, которые используются в системах решения проблем конструирования.
15.1. Стратегии конструирования
Предположим, у вас возникла необходимость расставить мебель в комнате. Цель решения этой задачи можно сформулировать следующим образом: найти такой вариант расстановки, который, во-первых, удовлетворял бы заданным геометрическим ограничениям (комната имеет конечные размеры, в ней, возможно, имеются какие-то специфические особенности, например альков, предметы обстановки также имеют свои размеры и т.п.), а во-вторых, учитывал бы определенные предпочтения, касающиеся взаимного расположения предметов обстановки (рабочий стол возле окна, диван против телевизора и т.д.). Скорее всего вы начнете с того, что выберете место для одного-двух главных предметов, которые зададут "точки привязки" для остальных. Далее выполняется расстановка остальных предметов и проверяется, насколько полученный вариант удовлетворяет сформулированным требованиям.
Если вам очень повезет, то первый же вариант может оказаться удачным, но рассчитывать на это вряд ли стоит. Скорее всего окажется, что на каком-то этапе расстановки нарушаются сформулированные ограничения. Когда такое случится, совсем не обязательно отменять все ранее сделанное и возвращаться в самое начало процесса. Как правило, вы найдете способ, как, сдвинув пару-другую предметов, "втиснуться" в ограничения. Лучшим из способов такой "подстройки" является тот, который сохранит самую большую часть ранее проделанной работы.
Как уже не раз подчеркивалось, основная сложность решения задач конструирования состоит именно в том, что чаще всего нельзя заранее сказать, подойдет ли данная частично выполненная конструкция для окончательного варианта, т.е. можно ли будет, развивая дальше это частичное решение, получить окончательный вариант, удовлетворяющий всем ограничениям. В применении к задачам конструирования восходящая стратегия (стратегия снизу вверх), которую мы использовали для решения задач малой размерности, выглядит примерно так.
(1) Если это возможно, начать с частичного варианта расстановки, который удовлетворяет заданным ограничениям. В противном случае начать с размещения первого компонента.
(2) Если расставлены все компоненты, прекратить процесс. В противном случае выполнить "наиболее многообещающее" расширение текущего варианта — поместить в планировку новый компонент.
(3) Если новый вариант размещения "не вписывается" в ограничения, предложить такой способ корректировки этого варианта, который требует как можно меньших переделок выполненных этапов.
(4) Перейти на шаг 2.
Конечно, эта стратегия выглядит слишком уж обобщенной, но даже на этом уровне в ней можно отметить несколько интересных моментов. Во-первых, она рекомендует при малейшей на то возможности начинать с какого-нибудь удовлетворительного варианта, а не с чистого листа. Так, если речь идет о планировании операций, начинайте с какого-нибудь частичного варианта, развитие которого в предыдущих аналогичных задачах привело к успеху. Не так уж фантастично выглядит идея, что в голове у человека-проектировщика имеется что-то вроде библиотеки заготовок для тех классов задач, с которыми ему приходилось иметь дело. Во-вторых, "наиболее многообещающее" расширение текущего варианта— это то, которое оставляет вам как можно большую свободу действий в будущем. Например, при выполнении планирования очередное действие должно по возможности сохранять временной зазор для последующих этапов, еще не включенных в план. Такую стратегию принято называть стратегией наименьшего принуждения (least commitment). В-третьих, корректировка текущего варианта совсем не обязательно должна сводиться к отмене последней по времени операции. Например, установка рабочего стола может привести к тому, что он "закроет" телевизор. Но совсем не обязательно отменять последнее действие и удалять с плана стол, может быть, целесообразнее сдвинуть телевизор или диван.
При решении задачи расстановки множества предметов может оказаться, что пространство поиска будет очень большим и таким образом проблема может перейти в разряд нерешаемых. Но, как правило, такие задачи можно упростить, рассматривая их на разном уровне представления деталей. Рассмотрим, например, задачу планировки дома на заданном участке земли. Пусть сейчас нас интересует компоновка помещений. Эту задачу можно сформулировать на разных уровнях абстракции (см. [Rosenman et al, 1987]):
в терминах взаимного положения, например "комната А рядом с комнатой Б";
в терминах ориентации, например "комната А на север от комнаты Б";
в терминах координат, которые точно указывают положение комнаты А по отношению к комнате Б.
На самом верхнем уровне абстракции принимается решение, какое помещение с каким должны соседствовать (например, кухня и столовая, ванная и спальня). Это решение уже сокращает возможность экспоненциального расширения пространства поиска. На следующем уровне принимается решение, например, что жилая комната должна выходить на юг, а кухня — на север, чтобы в ней было прохладнее. Это решение накладывает одновременно ограничения и на расположение столовой. После того как будет покончено с взаимным положением помещений и их ориентацией, нам потребуются какие-то эвристики, помогающие выделить место на планировке для всех помещений и разрешать возникающие при этом конфликты. Например, одна из эвристик предлагает сначала выбрать место для самых главных помещений, а оставшееся распределить между подсобными.
Такой иерархический подход хорошо знаком тем, кто часто имеет дело с проектированием планировок. Что касается экспертных систем, предназначенных для такого рода задач, то в таких системах, как NOAH [Sacerdoti, 1974] и NONLIN [Tate, 1977], которые явились развитием программы STRIPS, упрощение пространства поиска было достигнуто за счет следующего:
действия на более высоких уровнях абстракции рассматриваются как группы, объединяющие целую последовательность действий более низких уровней;
проблема планирования решается в терминах частичного упорядочения таких групп;
уточнение деталей выполняется на все более низких уровнях абстракции до тех пор, пока план не будет полностью завершен.
Описанный подход к решению проблемы можно отнести к типу нисходящих. В чем-то он напоминает организацию задача-подзадача, принятую в системе R1. Но существенное отличие от системы R1 состоит в том, что в данном случае иногда приходится пересматривать уже принятые решения в пределах одного и того же уровня абстракции, чего в программе R1 никогда не делается. Это и есть реализация той части стратегии, которая обозначена словом пересмотр в общем названии предложение и пересмотр (propose and revise). При решении очень сложных задач планирования иногда приходится выполнять пересмотр решений, принятых и на более верхних уровнях абстракции, а затем возвращаться на текущий уровень. Конечно, желательно по возможности избегать такого переноса, а потому серьезное внимание должно быть уделено выработке наиболее перспективных предложений и реализации стратегии наименьшего принуждения.
В следующем разделе мы рассмотрим систему MOLGEN [Stefik, 1981, a], [Stefik, 1981, b], которая предназначена для планирования экспериментов в исследованиях по молекулярной генетике. По ходу описания системы мы еще раз обратим ваше внимание на те моменты, о которых шла речь в этом разделе. Эта система является хорошим примером применения многоуровневого подхода на основе стратегии наименьшего принуждения для решения проблем конструирования. В разделе 15.3 будет рассмотрен метод восходящего решения проблем в системе VT [Marcus et al, 1988]. Эта система предказначена для проектирования лифтовых систем и использует стратегию предложение и пересмотр. В этом же разделе вы познакомитесь с методикой приобретения знаний, основанной на использовании инструментальной системы SALT [Marcus, 1988, b].
15.2. Архитектура систем планирования и метапланирования
Экспертная система MOLGEN, предназначенная для планирования экспериментов в исследованиях по молекулярной генетике, имеет многоуровневую организацию, в которой каждый более верхний уровень управляет расположенными ниже. Такой вид организации экспертной системы получил в литературе название метауровневой архитектуры (meta-level architecture). Идея состоит в том, что в дополнение к представлению "первого уровня" проблемы в предметной области добавить еще более высокие уровни, представляющие такие понятия, как возможные действия с объектами предметной области, критерии выбора и комбинирования таких действий.
В терминологии системы MOLGEN уровни управления называются пространствами планирования (planning space). Программа использует три таких пространства, каждое из которых имеет собственные объекты и операторы, которые взаимодействуют друг с другом с помощью протоколов передачи сообщений (см. главу 7). Схематически организация уровней управления в системе MOLGEN представлена на рис. 15.1. На этой схеме в левой части прямоугольников, представляющих каждое пространство планирования, приведен список некоторых операторов этого пространства. Интерпретатор организует внешний цикл управления системой. Фактически он формирует и следит за соблюдением определенной стратегии поведения системы. Как будет показано ниже, в этих стратегиях реализуется логический вывод суждений на метауровне, которые управляют способом решения проблемы планирования эксперимента.
Мы начнем анализ архитектуры системы MOLGEN с самого нижнего уровня — пространства лабораторных экспериментов (laboratory space). В этом пространстве содержатся знания об объектах и операциях, выполняемых в лаборатории в процессе проведения экспериментов. Объектами этого пространства являются те сущности, которыми манипулируют лаборанты, а операторы — это те действия, которые с этими сущностями могут выполняться, например сортировка, слияние и т.д. Мы не будем подробно останавливаться на этом уровне. Читатели, которых интересуют подробности его организации, могут обратиться к статьям Стефика [Stefik, 1981, а] и [Stefik, I981, b].
Пространство разработки (design space) содержит знания о планах проведения экспериментов в форме классов операторов для выполнения следующих действий:
проверки прогнозируемых характеристик и выявления необычных характеристик объектов — операторы сравнения (comparison-operators),
формирования предложений относительно целей, операций и прогнозируемых результатов — операторы временного расширения (temporal-extension operators);
уточнения этапов плана в соответствии с имеющимися ограничениями — операторы специализации (specialization operators).
Например, оператор Propose-Goal (предложение цели) относится к группе операторов временного расширения и устанавливает для лабораторного пространства цели проведения экспериментов. Оператор Check-Prediction (проверка прогнозируемых результатов) относится к группе операторов сравнения и выполняет сравнение прогнозируемых результатов экспериментов с текущей целью. Оператор Refine-Operator (уточнение) входит в группу операторов специализации. Он заменяет в форме уточняемого плана абстрактные этапы в операциях пространства лабораторных экспериментов на более конкретные.
Рис. 15.1. Организация пространств планирования в системе MOLGEN ([Stefik, 1981,b])
Каждому оператору назначается определенный уровень приоритета. Как правило, операторы сравнения имеют более высокий приоритет, чем операторы временного расширения, а последние имеют приоритет перед операторами специализации. Такое ранжирование операторов является, по существу, одним из отражений стратегии наименьшего принуждения, поскольку операции с более высоким приоритетом, как правило, оставляют большую свободу действий на будущее, чем операторы с более низким приоритетом. В той предметной области, для которой предназначена система MOLGEN, с помощью этих операторов моделируется экспертность специалистов, разрабатывающих эксперименты, но общие принципы организации этой системы вполне применимы и в других областях проектирования и планирования.
Большую роль в системе MOLGEN (как, впрочем, и в других приложениях, предназначенных для решения проблем конструирования) играют следующие три операции с ограничениями.
Формулирование ограничений. Эта операция формирует ограничения для пространства решений. Если воспользоваться примером из области планирования компоновки помещений, то такой операцией будет принятие решения, что кухня и столовая должны быть расположены рядом.
Распространение ограничений. Эта операция организует передачу информации между подзадачами, которые являются в определенной мере независимыми. Например, компоновка помещений на верхнем и нижнем этажах коттеджа является почти независимыми задачами, но они связаны друг с другом наличием одних и тех же ограничений в виде расположения лестниц и элементов водопроводной системы.
Удовлетворение ограничений. Эта операция собирает информацию об ограничениях, извлекая ее из деталей реализации отдельных подзадач проектирования. Например, при планировке помещений можно попробовать подгонять планировку верхнего и нижнего этажей таким образом, чтобы облегчить выполнение подзадачи планирования системы водоснабжения.
Полезно попытаться охарактеризовать отдельные операции в терминах тех ограничений, которые на них накладываются. Например, если проблема состоит в том, чтобы выяснить, что делать сегодня вечером, а текущая операция — это "пойти в кино", то можно сказать, что эта операция недоопределена (underconstrained), если в городке есть более одного кинотеатра. В более общем смысле операция является недоопределенной, если отсутствует вся необходимая информация для того, чтобы эта операция могла быть однозначно реализована в терминах более детальных этапов. Но операция "пойти посмотреть фильм-ужастик" является переопределенной (overconstrained), если в городке нет ни одного кинотеатра, в котором бы шел такой фильм. В более общем смысле операция является переопределенной в том случае, если любая попытка выполнить ее приводит к нарушению наложенных ограничений.
Назначение пространства стратегий (strategy space) — выработка суждений об этапах плана в пространстве разработки. Основным инструментом для этого являются эвристики стратегии наименьшего принуждения. Если операторы пространства разработки отвечают за формирование последовательности этапов выполнения в предметной области, то операторы пространства стратегий отвечают за формирование последовательности выполнения операторов пространства разработки. Таким образом, можно утверждать, что операторы этого пространства выполняют метапланирование.
Пространство стратегий системы MOLGEN состоит из следующих операторов, которые мы будем описывать в терминах сообщений, передаваемых сущностям управляемого пространства разработки.
Оператор Focus посылает сообщение "find task" каждому оператору пространства разработки, побуждающее его найти такую задачу, которую этот оператор мог бы выполнить в развитии текущего плана. Затем предлагаемые операции включаются в список и сортируются в порядке приоритетов соответствующих операторов. Не все из этих операций могут быть действительно выполнены. Некоторые из них недоопределены, а другие— переопределены. Оператор Focus просматривает сформированный список и выполняет те задачи, которые могут быть выполнены, отсылая после каждого успешного выполнения сообщение "find task". Если обнаруживается недоопределенная задача, ее выполнение приостанавливается. Когда же будет обнаружена переопределенная задача, управление передается оператору Undo.
Оператор Resume во многом похож на оператор Focus. Отличие состоит в том, что он не формирует новые задачи, а старается выявить ранее приостановленные и повторно запустить их на выполнение.
Оператор Guess активизируется в том случае, когда оказывается, что все предлагаемые для дальнейших действий задачи являются недоопределенными. Возникает ситуация, когда обычный "регулярный" подход на основе стратегии наименьшего принуждения не позволяет определить следующее действие и нужно привлекать на помощь эвристики. Оператор Guess посылает каждой приостановленной задаче сообщение, предлагая оценить степень "полезности" опций, которыми располагает эта задача, а затем выбирает ту из них, у которой самый высокий рейтинг.
Оператор Undo активизируется, когда обнаруживается, что в план включена переопределенная задача. В этом случае складывается ситуация, в которой нельзя применить стратегию наименьшего принуждения. В том виде, в каком он реализован в системе MOLGEN, оператор Undo выглядит довольно примитивным. Он отыскивает тот этап, который привел к включению в план переопределенной задачи, и предлагает изъять его из плана.
В системе MOLGEN список актуальных операторов используется более гибко, чем в системах INTERNIST и CENTAUR, описанных в главе 13. Хотя во всех трех системах разделяется предложение задач к выполнению и их реальное выполнение, только архитектура MOLGEN позволяет задачам взаимодействовать нетривиальным способом. Как отметил Стефик (Stefik), если такое взаимодействие не организуется явным образом на более, высоких уровнях, оно может привести к весьма неожиданным результатам на более низких. Естественно, многоуровневая архитектура должна существенно упростить решение проблемы, если в ней правильно выполнено распределение нагрузки по уровням. По мере перехода на более высокие уровни решаемые задачи должны упрощаться. На самом высоком уровне, уровне интерпретатора, решается единственная тривиальная задача запуска на выполнение той подзадачи, которая стоит первой в списке актуальных.
Как уже отмечалось, основной "слабостью" системы MOLGEN является то, что в ней отсутствует достаточно совершенный механизм обратного прослеживания. Другими словами, если вспомнить о наименовании стратегии предложение и пересмотр, то эта система сильна в выработке предложений, но слаба в их пересмотре, а потому ей не всегда удается "выкарабкаться" из ситуации, которая складывается после неудачного предложения.
В следующем разделе будет описана экспертная система, в которой используется та же парадигма предложение и пересмотр, но процесс пересмотра реализован более удачно.
15.1. Программа планирования мероприятий
Ниже приведена программа планирования мероприятий, написанная на языке CLIPS. При сформировании расписания программа сначала старается как можно раньше назначить для каждого отдельного мероприятия начальный момент выполнения, а затем назначает конечный момент, если в расписании найдено место для мероприятия. Программа расставляет задачи в соответствии с их приоритетами и старается сохранять себе свободу действий как можно дольше. Однако эта программа не способна справиться с ситуацией, которая складывается после неудачно принятого решения, ни с помощью обратного прослеживания, ни с помощью коррекции частичного расписания, из которого развился тупиковый вариант.
;; ШАБЛОНЫ
;; Объект мероприятий.
(deftemplate errand
(field name (type SYMBOL)) ; имя
;; интервал времени, в течение которого нужно
;; приступить к выполнению мероприятия
;; не раньше (field earliest (type INTEGER) (default 0))
;; не позже
(field latest (type INTEGER) (default 0))
;; продолжительность
(field duration (type INTEGER) (default 0))
;; приоритет
(field priority (type INTEGER) (default 0))
;; включено в расписание (field done (type SYMBOL)
(default no));
)
; ; Объект расписания (def template schedule
(field task (type SYMBOL))
;; задача
;; интервал времени, в течение которого нужно
;; выполнить задачу
;; начало
(field start (type INTEGER) (default 0))
;; конец
(field finish (type INTEGER) (default 0))
;; приоритет
(field priority (type INTEGER) (default 0))
;; полностью заполнено
(field status (type SYMBOL) (default no))
)
;; Объект цели. Используется для управления поведением
;; программы, принуждая ее к определенному порядку
;; достижения целей. (def template goal
(field subgoal (type SYMBOL)))
;; ФАКТЫ
(deffacts the-facts (goal (subgoal start))
(errand (name hospital) (earliest 1030)
(latest 1030)
(duration 200) (priority 1)) (errand
(namе doctor) (earliest 1430) (latest 1530)
(duration 200) (priority 1))
(errand (name lunch) (earliest 1130) (latest 1430)
(duration 100) (priority 2))
(errand (name guitar-shop)
(earliest 1000)
(latest 1700) (duration 100)
(priority 3)) (errand (name haircut)
(earliest 900) (latest 1700)
(duration 30) (priority 4))
(errand (name groceries)
(earliest 900) (latest 1800)
(duration 130) (priority 5))
(errand (name dentist)
(earliest 900) (latest 1600)
(duration 100) (priority 2))
;; Попадает ли время начала S в интервал [Т, T+D]?
;; Две задачи не могут начинаться в одно и то же время.
(deffunction overlapl (Is ?t ?d)
(and (<= ?t ?s) (< ?s (+ ?t ?d))))
;; Попадает ли время завершения S в интервал [Т, T+D]?
;; Для задачи А можно назначить время начала выполнения
;; равным времени завершения задачи В.
(deffunction overlap2 (?s ?t ?d)
(and (< ?t ?s) (< ?s (+ ?t ?d))))
;; Операция добавления к значению времени интервала,
;; выраженного в формате INTEGER,
(deffunction +t (?X ?Y) (bind ?T (+ ?X n))
(if(or (= (- ?T 60) ( (div (- ?T 60) 100) 100))
(= (- ?T 70) ( (div (- ?T 70) 100) 100))
(= (- ?T 80) ( (div (- ?T 80) 100) 100))
(= (- ?T 90) ( (div (- ?T 90) 100) 100)))
then (+ ?T 40)
telse ?T))
;; ПРАВИЛА
;; На выполнение некоторых задач отводится
;; фиксированное время, (defrule fixed
(declare (salience 80))
(goal (subgoal start))
?E <- (errand (name ?N)
(earliest ?T) (latest ?T) (duration ?D)
(priority ?P) (done no))
(not (schedule (start ?U1&:(overlapl ?U1 ?T ?D))))
(not (schedule (finish ?U2&:(overlap2 ?U2 ?T ?D))))
(printout t crlf "Fixing start and end of " ?N t crlf)
;; ( "Определение начала и завершения " ?N
(modify ?E (done finish)) (assert (schedule (task ?N)
(start ?T) (finish (+t ?T ?D)) (priority ?P)))
;; Следующей в расписание включается задача с наиболее
;; высоким приоритетом, причем ей задается самое раннее
;; время начала выполнения, (defrule priorityl
(declare (salience 50))
(goal (subgoal start))
: ?Е <- (errand (name ?N) (earliest ?T)
(duration ?D) (priority ?P)) (not (errand
(priority ?Q&:(< ?Q ?P)) (done no)))
(not (schedule (start ?01&:(overlapl ?Ul ?T ?D))))
(not (schedule (finish ?U2S:(overlap2 ?U2 ?T ?D))) =>
(printout t crlf "Fixing start of " ?N t crlf)
;;"Коррекция начала: " ?N
(modify ?E (done start)) (assert (schedule
(task ?N) (start ?T) (priority ?P)
)
;; Скорректировать значение параметра earliest задач
;; более низкого приоритета, если это время уне занято
;; теми задачами, которые включены в расписание,
(defrule priority2
(declare (salience 60))
(goal {subgoal start)) ?E <- (errand (name ?N)
(earliest ?T)(duration ?D) (priority ?P) (done no))
(not (errand (priority ?QS:(< ?Q ?P)') (done no)))
(schedule (task ?M) (start ?U&:(overlapl 7U ?T ?D)))
(errand (name ?M&~?N) (duration ?C)) =>
(printout t crlf ?N " overlaps with start of " ?M t crlf)
;; ?N " пересекается с началом " ?M
(modify ?E (earliest (+t ?U ?C))) )
;; Скорректировать значение параметра earliest задач
;; более низкого приоритета, если запуск задачи в
;; указанное этим параметром время приведет к тому,
;; что она не успеет завершиться до запуска другой
;; задачи более высокого приоритета,
;; ухе включенной в расписание,
(defrule priority3
(declare (salience 60))
(goal (subgoal start))
?E <- (errand (name ?N) (earliest ?T)
(priority ?P) (done no))
(errand (name ?M&"?N) (duration ?C))
(schedule (task ?M)
(start ?0&:(overlap1 ?T ?U ?C)))
(printout t crlf ?N " overlaps with end of " ?M t crlf)
;; ?N " пересекается с концом " ?M
(modify ?E (earliest (+t ?U ?C)))
)
;;Скорректировать значение параметра earliest
;; задач более низкого приоритета,
;;если запуск задачи в указанное этим
;;параметром время приведет к тому,
;; что ее начало перекроет одну
;;задачу, уже включенную
;; ранее в расписание, и она не успеет завершиться
;; до запуска другой задачи более высокого приоритета ,
;; уже включенной в расписание.
(defrule priority4
(declare (salience 60))
(goal (subgoal start))
?E <- (errand (name.?N) (earliest ?T)
(duration ?D) (priority ?P) (done no))
(errand (name ?M&~?N) (duration ?C))
(schedule (task ?M)
(start ?U&:(<= ?U ?T)) (finish ?F&:
(<= (+ ?T ?D) ?F)))
)
=>
(printout t crlf ?N " would
occur during " ?M t crlf)
?N " может появиться во время "
?М (modify ?E (earliest (+t ?U ?C)))
)
;; Изменение цели. Новая цель - установка конечного
;; времени выполнения задачи. (defrule change-goal
?G <- (goal (subgoal start)) =>
(modify ?G (subgoal finish))
)
;; Время завершения задачи - это время начала ее
;; выполнения плюс продолжительность . (defrule endpoint
(goal (subgoal finish))
(errand (name ?N) (latest ?L) (duration ?D))
?S <- (schedule (task ?N) (start
?!&:(<= ?T ?L)) (finish 0)) ... =>
(printout t crlf "Fixing end of" ?N t crlf)
;; "Определение завершения " ?N
(modify ?S (finish (+t ?T ?D)))
;; Новая цель - вывести отчет о плане.
(defrule unfinish
?G <- (goal (subgoal finish)) =>
(modify ?G (subgoal report))
)
;; Вывести задачи в хронологическом порядке.
(defrule scheduled
(declare (salience 10)) (goal (subgoal report))
?S <- (schedule (task ?N) (start ?T1) (finish ?T2S"0)
( status 0 ) ) . '(not (schedule (start ?T
3&:(<= ?T3 ?T1)) (status 0)))
)
=>
(printout t crlf ?N " from " ?T1 " till " ?T2t crlf)
;; ?N " от " ?T1 " до " ?T2
(modify ?S (status 1))
)
;; Для некоторых задач в расписании может не найтись
;; места.
(defrule unscheduled
(goal (subgoal report))
?S <- (schedule (task ?N) (finish 0) (status 0))
(printout t crlf ?N " not scheduled. " t crlf)
;; ?N " не включена в расписание. "
(modify ?S (status 1)) )
Эта программа успешно справляется с составлением расписания мероприятий, перечисленных после оператора deffact. В упр. 4 в конце главы будет показано, что существуют наборы мероприятий, с которыми программа не может справиться, хотя составить расписание для них с учетом оговоренных ограничений можно
15.3. Извлечение, представление и применение знаний о проектировании
В этой главе мы рассмотрим экспертную систему проектирования лифтовых систем VT [Marcus et al., 1988] и использованную в процессе ее разработки систему автоматизированного приобретения знаний SALT [Marcus et al, 1988]. В первом разделе основное внимание будет уделено самой программе VT, а в следующем будет описана методика приобретения знаний о проектировании, использованная в системе SALT.
15.3.1. Реализация обратного прослеживания в системе VT
Программа VT (название программы — аббревиатура от Vertical Transportation, транспортировка по вертикали) была использована фирмой Westinghouse Elevator для разработки лифтовых систем индивидуального исполнения. Исходные данные для программы VT представляют собой набор основных параметров проектируемой системы — скорость, грузоподъемность, размеры лифтовых шахт. На основе этих данных программа формирует список подходящего оборудования и компоновку всех шахт с учетом требований безопасности и производительности системы.
В процессе проектирования программа сначала формирует примерную компоновку, а затем уточняет ее на основе анализа оговоренных ограничений. На первом этапе используется прямая цепочка правил логического вывода. Программа выбирает в качестве исходных данных либо введенные параметры, либо значения, вычисленные другими процедурами. Типичное правило (в системе VT они почему-то названы PROCEDURE — процедура) представлено ниже.
ЕСЛИ: доступны значения параметров
DOOR-OPENING, PLATFORM-WIDTH и OPENING-WIDTH
и DOOR-OPENING=CENTER,
ТО: CAR-JAMBETURN=(PLATFORM-WIDTH - OPENING-WIDTH)/2.
На этом этапе весь процесс направляется данными. Допустима любая операция проектирования, если только для этого имеется достаточно исходной информации. Но поскольку на этом этапе некоторые из задач оказываются недоопределенными, то вполне возможна и такая ситуация, когда при отсутствии полностью определенных задач в списке актуальных очередное предложение будет сформировано такой недоопределенной задачей. В результате в дальнейшем будет развиваться частичная конфигурация проекта, созданная на базе неполной информации. Иными словами, в системе VT не всегда соблюдаются условия соответствия, сформулированные в предыдущей главе, но, тем не менее, процесс проектирования продолжается, поскольку предполагается, что в дальнейшем удастся скорректировать возможное нарушение ограничений.
По мере развития проекта система VT отслеживает на каждом шаге, от каких исходных или промежуточных данных зависят сформированные на этом шаге данные. В процессе отслеживания формируется сеть зависимостей (dependency network). Структура сети зависимостей будет детально рассмотрена в главе 19, а пока считайте, что такая сеть представляет собой один из видов ориентированного графа без петель. Узлы графа представляют вычисленные значения важных параметров проектируемой системы, например CAR_JUMB_RETURN (пространство для маневрирования автомобилей при загрузке в лифт), а ребра — применяемые для их определения правила. Узлы и ребра графа формируются по мере активизации тех или иных правил в процессе развития проекта. В результате программа после завершения проектирования получит возможность выяснить, каким образом в процессе рассуждений было определено значение того или иного параметра, и найти, какое из принятых в процессе проектирования решений привело к нарушению ограничений. Найденное решение и послужит отправной точкой для пересмотра проекта.
Нарушение ограничений выявляется с помощью демонов (см. главу 6). Если имеется достаточно информации для того, чтобы определить, как связано значение некоторой величины со значениями ограничений, выполняется сравнение. Возможные способы устранения несоответствия ранжированы и активизируются в заданном порядке. Пример правила устранения несоответствия приведен ниже.
ЕСЛИ: нарушено ограничение MAXIMUM-MACHINE-GROOVE-PRESSURE,
ТО: попробовать понизить значение MACHINE-GROOVE-MODEL (1),
увеличить значение HOST-CABLE_QUANTITY (4).
После применения правила устранения несоответствия программа, пользуясь сформированной ранее сетью зависимостей, корректирует и остальные параметры проекта, зависящие от тех, которые были изменены в результате применения правила.
Приведенное выше правило устранения предлагает два варианта, причем указанный в скобках уровень приоритета означает, что предпочтение следует отдать первому варианту. Если же его реализовать по каким-либо причинам не удастся, следует попробовать второй вариант.
Говорят, что два ограничения являются антагонистическими, если удовлетворение одного из них приводит к нарушению другого. Если вернуться к рассмотренному выше примеру с посещением кинотеатра, то можно интерпретировать антагонистические ограничения следующим образом. Два человека хотят вместе пойти в кино, но один не желает видеть ничего, кроме фильмов ужасов, а другой не выносит вида крови. Если удовлетворить вкусы одного, то желание другого будет проигнорировано.
Проблема пересмотра ранее принятых решений усложняется тем фактом, что коррекция параметров, необходимая для устранения одних ограничений, влияет на другие параметры, которые, в свою очередь, связаны с другими ограничениями. В правиле, приведенном выше, одна из рекомендаций предполагает изменение количества тросов подъемника, что приведет к изменению множества других параметров всей конструкции. Вполне возможно, что после этого придется заменить и модель лифта. База знаний программы VT включает 37 цепочек устранения несоответствия ограничениям, причем три из них имеют дело с антагонистическими ограничениями. Антагонистическими, например, являются ограничения MAXIMUM-MACHINE-GROOVE-PRESSURE (максимальная нагрузка на трос подъемника) и MAXIMUM-TRACTION_RATIO (максимальное отношение сцепления). Понижение нагрузки приведет к увеличению отношения сцепления и наоборот.
Если одновременно нарушаются оба антагонистических ограничения, то складывается ситуация, когда, скорректировав параметры, необходимые для устранения одного несоответствия, мы еще более усугубим другое. В системе VT проблема устранения антагонистических ограничений выделена в отдельный случай и решается следующим образом. Когда демон фрейма обнаруживает такую ситуацию, каждому параметру, имеющему отношение к выявленному нарушению ограничений, присваивается то значение, которое он имел до нарушения любого ограничения. Таким образом отменяются все предпринятые ранее меры по ликвидации нарушения всех ограничений. После этого программа предпринимает попытку выполнить какую-либо из корректирующих операций, весь набор которых разделен на три группы очередности:
(1) операции, которые помогают устранить нарушение обоих антагонистических ограничений;
(2) операции, которые помогают устранить нарушение одного из антагонистических ограничений и не усугубляют нарушение другого;
(3) операции, которые помогают устранить нарушение одного из антагонистических ограничений, но усугубляют нарушение другого.
Если дело доходит до выполнения операций третьей группы, то сначала программа пытается устранить нарушение наиболее существенного ограничения. Таким образом, одно из важнейших отличий программы VT от MOLGEN состоит в том, что хотя в обеих системах используется стратегия предложение и пересмотр, в программе VT гораздо большее внимание уделено фазе пересмотра ранее принятых решений, а программа MOLGEN концентрируется на реализации принципа наименьшего принуждения.
Программа VT реализована с помощью языка OPS5. База знаний этой программы насчитывает около 3000 правил. В литературе приводятся сведения о производительности системы. Для выполнения задания средней сложности программа активизирует от 2 500 до 11 500 правил, на что затрачивается от 7 до 20 минут машинного времени компьютера VAX 11/780, оснащенного оперативной памятью объемом 20 Мбайт. Интересно отметить, что около 2000 правил системы VT сформировано с помощью системы автоматизированного приобретения знаний SALT, а другие (их около 1000) отвечают за организацию ввода/вывода, управление порядком применения правил и формирование объяснений, помогающих пользователю уяснить, почему программа в процессе проектирования приняла определенные решения.
15.3.2. Приобретение знаний с помощью системы SALT
Система автоматизированного приобретения знаний SALT разрабатывалась с ориентацией на использование в тех экспертных системах, в которых доминирующей при решении проблем является стратегия предложение и пересмотр. Это предположение было положено в основу организации процесса приобретения знаний. Один из используемых методов состоит в том, .что выявляются знания, позволяющие наполнить содержанием определенные роли в выбранной стратегии решения проблемы. При таком подходе решающее значение для успешной реализации задач системы имеет правильный выбор ролей и отношений между ними.
Полагается, что знания о предметной области должны распределяться между тремя ролями. Они перечислены ниже, причем в скобках приведено наименование каждой роли, присвоенное ей в документации системы SALT.
(1) Знания, которые касаются развития текущей промежуточной стадии проекта (PROPOSE-A-DESIGN-EXTENTION).
(2) Знания, относящиеся к определению ограничений, накладываемых на текущую промежуточную стадию проекта (IDENTIFY-A-CONSTRAINT).
(3) Знания, касающиеся устранения обнаруженных нарушений ограничений (PROPOSE-A-FIX).
Система SALT автоматически организует извлечение знаний каждой из указанных категорий в процессе интерактивного сеанса опроса эксперта, азатем преобразует полученные сведения в порождающие правила и формирует базу знаний о предметной области. После этого созданная база знаний объединяется с интерпретатором оболочки экспертной системы (см. главу 10). Система SALT сохраняет первичные сведения, полученные от эксперта, в декларативной форме и таким образом при необходимости позволяет их скорректировать и обновить ранее созданную базу знаний.
В качестве промежуточной формы представления знаний в SALT используется сеть зависимостей. Каждый узел этой сети представляет наименование какого-либо контрольного параметра (например, TYPE-OF-LOADING), параметра, характеризующего конструкцию (например, PLATFORM-WIDTH), или ограничения (например, MAXIMUM-MACHINE-GROOVE-PRESSURE). Связи в сети разделены на три группы:
содействующая — связывает узлы А и В в том случае, если значение параметра узла А используется для вычисления значения параметра узла В',
ограничивающая — связывает узлы А и В в том случае, если значение параметра узла А является ограничением, которое должно учитываться при выборе значения конструктивного параметра, ассоциированного с узлом В;
корректирующая — связывает узлы А и В в том случае, если с узлом А ассоциировано значение ограничения и нарушение этого ограничения может быть скорректировано изменением текущего значения параметра, ассоциированного с узлом В.
Работая с системой SALT, пользователь может вводить знания в любом порядке, но каждое элементарное знание должно иметь один из трех квалификаторов в соответствии с перечисленными выше ролями:
PROCEDURE — знания о развитии текущей промежуточной стадии проекта;
CONSTRAINT — знания об определении ограничений, накладываемых на текущую промежуточную стадию проекта;
FIX — знания об устранении обнаруженных нарушений ограничений.
Получив значение квалификатора, система SALT организует диалог с пользователем и предлагает ему ввести знания, соответствующие заданной роли.
Для каждого конструктивного параметра, который фигурирует в завершенном проекте, в базе знаний должен присутствовать свой элемент знаний типа PROCEDURE (правило). В таком элементе должны быть отображены все соображения, относящиеся к выбору значения этого параметра. Если правило недоопределено, т.е. не позволяет однозначно определить значение параметра, то в таком правиле должны присутствовать соображения о предпочтительных значениях параметра в пределах допустимого диапазона. Полный формуляр правила вычисления параметра CAR-JAMB-RETURN (этот параметр присутствовал в правиле, цитированном в предыдущем разделе) выглядит так, как показано ниже.
1. Name: CAR-JAMB-RETURN
2. Precondition: DOOR-OPENING=CENTER
3. Procedure: CALCULATION
4. Formula: (PLATFORM-WIDTH - OPENING-WIDTH)/2
5. Justification: CENTER-OPENING DOOR LOOK BEST WHEN
CENTERED ON THE PLATFORM
1.Имя: CAR-JAMB-RETURN
2. Предусловия: DOOR-OPENING=CENTER
3. Процедура: Вычисление
4. Формула: (PLATFORM-WIDTH - OPENING-WIDTH)/2
5. Уточнение: Двери, открывающиеся от середины, выглядят лучше,
если на платформе их разместить по центру
В правилах типа CONSTRAINT собирается информация о взаимных связях между значениями параметров, которая не вошла в правила типа PROCEDURE, но необходима для проверки качества созданного проекта. Правила типа FIX предлагают варианты корректирующих действий, которые можно предпринять при нарушении заданных ограничений. Ниже приведен заполненный формуляр для правила этого типа, которое относится к ликвидации нарушения ограничения MAXIMUM-MACHINE-GROOVE-PRESSURE.
Constraint name: MAXIMUM-MACHINE-GROOVE-PRESSURE
Value to Change HOIST_CABLE-QUANTITY
Change Type: INCREASE
Step Type: BY-STEP
Step Size: 1
Preference Rating: 4
Preference Reason: CHANGES MINOR EQUIPMENT SIZING
Имя ограничения: MAXIMUM-MACHINE-GROOVE-PRESSURE Изменить: HOIST_CABLE-QUANTITY
Тип изменения: INCREASE
Режим изменения: BY-STEP
Величина шага: 1
Приоритет: 4
Критерий выбора: Минимальные изменения размеров другого оборудования
Информация из таких стилизованных формуляров довольно просто преобразуется в порождающие правила. Но система SALT не только переводит полученную информацию в формат правил, но и анализирует соответствие между новым правилом и ранее введенными. Поэтому желательно сначала ввести информацию для всех правил типов PROCEDURE и CONSTRAINT, а уже затем вводить информацию для правил типа FIX. В этом случае правила последнего типа будут анализироваться с учетом всех знаний, касающихся проектирования и ограничений.
Информацию о связях в сети зависимостей программа SALT извлекает из тех элементов знаний, которые вводятся пользователем. Так, после ввода приведенного выше правила типа PROCEDURE программа сформирует содействующую связь между узлом, ассоциированным с параметром PLATFORM-WIDTH, и узлом, ассоциированным с параметром CAR-JAMB-RETURN. Точно так же после ввода правил типов CONSTRAINT и FIX будут сформированы ограничивающие и корректирующие связи.
Формируемая экспертная система должна присвоить значения каждому узлу сети и найти на графе сети такой путь, который обеспечивал бы проверку и удовлетворял всем заданным ограничениям. На компилятор возлагается задача сформировать процедуры в соответствии с найденным путем на графе и проверить, является ли он единственным и полным для набора входных данных
15.4. Итоги анализа систем решения проблем конструирования
Мы показали, что в ряде случаев методы решения проблем конструирования можно существенно упростить, используя специфические знания из предметной области. Например, система разработки компоновок вычислительных комплексов R1 организована таким образом, что она всегда располагает информацией, необходимой для выбора следующего шага, и не нуждается в механизме пересмотра принятых решений. В результате система не нуждается в дополнительных ресурсах для хранения предыстории принятых решений и взаимных связей между этими решениями.
Но в большинстве случаев не удается организовать такой однозначный выбор порядка выполнения проектирования, причиной чему является либо отсутствие достаточных знаний о данной предметной области, либо существование множества близких к оптимальному решений. Неполнота имеющихся знаний означает, что экспертная система должна следовать стратегии наименьшего принуждения и обладать способностью формировать предложения по наилучшему развитию текущего частичного варианта проекта. Поскольку такое предложение не всегда может быть правильным, программа должна иметь возможность обнаружить нарушение имеющихся ограничений в текущем незавершенном варианте проекта и либо вернуться и попробовать другой вариант продолжения, либо предложить способ устранения обнаруженного несоответствия. При реализации такой стратегии важную роль играет механизм записи и сохранения ранее принятых решений и отношений между ними. Мы еще вернемся к таким механизмам в главе 19.
Если задачи конструирования в определенной области могут иметь несколько вариантов решения, самая простая стратегия для экспертной системы — выбрать первое подходящее, ограничиваясь проверкой только жестких ограничений. Перебор нескольких вариантов и их последующее сравнение требует слишком больших вычислительных затрат. Это связано, в первую очередь, с тем, что проблемы конструирования или выбора компоновки многокомпонентной системы определены на довольно большом, а иногда и на бесконечно большом пространстве поиска вариантов, и этим они разительно отличаются от проблем классификации, рассмотренных в главах 11 и 12.
Совершенно очевидно, что размер пространства решений влияет на проблемы конструирования значительно сильнее, чем на проблемы классификации. Даже если обратиться к простейшим игровым задачам, вроде задачи о ферзях, которая рассматривалась в одном из упражнений главы 1, то и на их примере нетрудно убедиться, что метод, который позволит решить задачу о четырех или восьми ферзях, нельзя применить, когда речь пойдет о сотне или тысяче ферзей. Проблемы классификации относятся к числу тех, с которыми следует поступать по принципу "разделяй и властвуй", особенно если пространство категорий может быть организовано иерархически.
К слову сказать, существует множество реальных задач, типа планирования поведения роботов или составления расписания мероприятий, которые включают комбинаторику, не позволяющую использовать принцип "разделяй и властвуй". Частично это объясняется отсутствием подходящей метрики, которая позволила бы оценить, насколько близко конкретный фрагмент решения подходит к общему решению задачи. План можно оценить только целиком; нельзя сказать, насколько он будет хорош по характеристикам его отдельных этапов. Подход, основанный на "библиотеке заготовок" (он использовался в системе ONCOCIN; см. главу 10), также не годится для решения большинства проблем конструирования.
Методы, основанные на знаниях, являются реальной альтернативой алгоритмическому подходу в тех случаях, когда имеется достаточный объем знаний в конкретной предметной области, которые позволяют реализовать стратегию предложения и пересмотра или предложения и исправления. Но для реализации таких методов требуется довольно специфический механизм управления и обратного прослеживания решений, принимаемых программой. Мы еще вернемся к этой теме в последующих главах.
В главе 18 будет рассмотрена система, предназначенная для идентификации трехмерных структур протеинов в растворах. Комбинаторика, связанная с просмотром всех возможных вариантов компоновки молекул, совершенно очевидно не позволяет использовать исчерпывающий поиск или обратное прослеживание на сколько-нибудь значительную глубину. Поэтому программа организована таким образом, что в ней имеется несколько баз знаний, поддерживающих разные эвристики управления поиском в пространстве решений. Такая архитектура, получившая, название системы с доской объявлений (blackboard system), обеспечивает мощный механизм реализации таких стратегий, как последовательное уточнение частичных решений и восстановление после принятия неудачных решений.
В главе 19 мы рассмотрим системы обработки правдоподобия (truth maintenance) — усовершенствованный механизм фиксации решений, который существенно облегчает выполнение обратного прослеживания. В тех случаях, когда обратного прослеживания избежать невозможно, желательно, по крайней мере, быстро определить, в какую именно точку вычислений нужно вернуться, а не отменять по очереди все предыдущие операции, анализируя каждый раз последствия такой отмены.
Рекомендуемая литература
Применение экспертных систем для выполнения планирования рассматривается во множестве статей, включенных в популярные сборники, среди которых рекомендуем обратить внимание на следующие: [Nilsson, 1980], [Genesereth and Nilsson, 1987] и [Charniak and McDermott, 1985]. Читателей, интересующихся ранними исследованиями в области использования стратегии наименьшего принуждения для планирования, мы отсылаем к работе [Sacerdoti, 1974], Описание других исследований, касающихся решения проблем конструирования, можно найти в работах [Brown and Chandrasekaran, 1989] и [Coyne, 1988].
Результаты более поздних исследований представлены в книге [Dean and Wellman, 1991] и публикуемых IEEE трудах ежегодных конференций AI Simulation and Planning in High Autonomy Systems (выпуски за 1991 и 1992 гг.).
С системой EXPECT, которая является одной из автоматизированных систем приобретения знаний, аналогичной по возможностям рассмотренной _в этой главе системе VT, можно ознакомиться в работе [Gil and Paris, 1984].
Упражнения
1. Поясните смысл стратегии наименьшего принуждения. В чем отличие этой стратегии и стратегии предложение и пересмотр!
2. Постарайтесь перечислить как можно больше задач, к которым, по вашему мнению, можно применить стратегию наименьшего принуждения; нельзя применить стратегию наименьшего принуждения, не подкрепив ее какой-нибудь другой.
Подумайте о тех задачах, с которыми вы достаточно часто сталкиваетесь в повседневной жизни, например планирование похода по магазинам. Чем отличаются эти два класса задач?
3. Объясните смысл терминов метауровневая архитектура и метапланирование.
4. Проанализируйте программу, представленную во врезке 15.1. Подумайте над тем, каким образом нужно модифицировать данные, приведенные в операторе deffacts, -чтобы программа прервала работу, поскольку не смогла сформировать расписание, хотя, в принципе, его можно составить. (Указание: попробуйте манипулировать только приоритетами задач.)
5. Программа планирования мероприятий, представленная во врезке 15,1, не сможет составить расписание для следующего набора исходных данных, несмотря на то, что такое расписание существует.
(deffacts the-facts
(goal (subgoal start))
(errand (name hospital)
(earliest 1030)
(latest 1030) (duration 200) (priority 1))
(errand (name doctor)
(earliest 1430) (latest 1530)
(duration 200) (priority 1))
(errand (name lunch)
(earliest 1130) (latest 1430)
(duration 100) (priority 2))
(errand (name guitar-shop)
(earliest 1000) (latest 1700)
(duration 100) (priority 2))
(errand (name haircut)
(earliest 900) (latest 1700)
(duration 30) (priority 2))
(errand (name groceries)
(earliest 900) (latest 1800)
(duration 130) (priority 2))
(errand (name bank)
(earliest 930) (latest 1530)
(duration 30) (priority 2))
(errand (name dentist)
(earliest 900) (latest 1600)
(duration 100) (priority 1)) )
Почему?
6. Ниже представлено дополнительное правило для программы составления расписания, которое позволит разрешить проблему, на которой программа споткнулась в предыдущем упражнении. Это правило разрешает конфликт между задачами, одна из которых должна начаться в точно зафиксированное время, а другая уже вставлена в расписание. Для этого вторая задача сдвигается в расписании. Если же в конфликте участвует задача, для которой не оговорено точное время начала, сдвигается та задача, которая имеет более низкий приоритет.
(defrule clash
(declare (salience 100))
(goal (subgoal fix))
?S <- (schedule (task ?M) (start ?M1))
(errand (name ?N)
(earliest ?E1) (latest ?L1)
(duration ?C)) (schedule
(task ?N&"?M)
(start ?Nl&:(and (<= ?M1 ?Nl)
(< ?N1 (+ ?M1 ?C)))))
(errand (name ?N) (duration ?D)
(earliest ?E2) (latest ?L2i:
(< (- ?L2 ?E2) (- ?L1 ?E1)))) =>
(printout t crlf ?M " clashes with " ?N t crlf)
;; ( ?M " конфликтует с " ?N
(modify 7S (start (+t ?N1 ?D))) )
Это правило гласит: "В случае конфликта передвинуть в расписании ту задачу, которая имеет меньшее ограничение". Оно активизируется только в том случае, если текущей является подцель fix. Правила start и finish, которые контролируются подцелями start и finish, остаются без изменений.
Ваша задача — разработать три новых управляющих правила, которые организуют работу правил clash, start и finish.
I) Правило fixstart будет активизироваться в случае, если предложения, сформированные всеми прочими правилами для подцели start, будут нарушать ограничения. Это новое правило выделяет вектор schedule для задачи и присваивает его полю start значение, которое хранится в слоте latest элемента errand.
II) Измените существующее правило unstart таким образом, чтобы оно заменяло подцель в выражении goal с start на fix вместо прежней замены start на finish.
III) Разработайте правило unfix, которое будет заменять подцель в выражении goal с fix на finish.
Затем выполните следующее.
IV) Протестируйте программу и убедитесь, что она справляется с проблемой на наборе исходных данных, установленном в упр. 5.
V) Эвристика, использованная в правиле clash, не может справиться со всеми возможными случаями. Постарайтесь найти такой вариант исходных данных, который поставит программу "в тупик", несмотря на то, что построить расписание возможно.
7. В программе составления расписания используется единственный вид ограничений — ограничения по времени, запрещающие наложение мероприятий. Давайте добавим в нее пару ограничений, специфических для мероприятий определенного вида, — это будут своего рода специфические знания о предметной области. Например, логично ввести ограничение, отражающее тот факт, что для выполнения покупки или посещения какого-либо заведения сети обслуживания нужно располагать некоторой суммой денег. Следовательно, перед тем как отправляться за покупками, нужно зайти в банк.
I) В шаблон мероприятия errand добавьте поле kind (вид). Допустимые значения этого поля — одна из трех символических констант: goods (вещи), service (обслуживание), visit (визит). Такие мероприятия, как посещение банка или врача, относятся к группе visit, посещение парикмахерской (haircut) или ресторана (lunch) — к группе service, а поход в овощную лавку (groceries) или музыкальный салон (guitar-shopping) — к группе goods.
II) Включите в число возможных предложений в процессе решения проблемы новую фазу (подцель) tune, которая должна следовать за подцелью start перед fix. Таким образом, можно будет проанализировать введенные специфические ограничения перед тем, как браться за корректировку расписания (подцель fix). При изменении программы вам придется модифицировать правила, манипулирующие лексемами подцели.
III) Добавьте правило money, которое будет активизироваться только в том случае, когда -текущей подцелью в рабочей памяти является tune. Правило должно распознавать ситуацию, в которой мероприятие, требующее присутствия определенной наличности в бумажнике, оказывается в расписании раньше, чем посещение банка. Правило должно корректировать расписание, сдвигая в нем такое мероприятие на позднее время, т.е. на время после посещения банка. Если такая коррекция приведет к возникновению конфликтной ситуации в расписании, она будет устранена правилом fix.
IV) Протестируйте скорректированную программу на следующем наборе входных данных (фактов):
(deffacts the-facts
(goal (subgoal start))
(errand (name hospital)
(kind visit) (earliest 930)
(latest 930) (duration 200)
(priority 1)) (errand (name lunch)
(kind service) (earliest 1130)
(latest 1430) (duration 100)
(priority 2)) (errand
(name guitar-shop) (kind goods)
(earliest 1000) (latest 1700) (duration 100)
(priority 3)) (errand (name haircut)
(kind service) (earliest 900)
(latest 1700) (duration 30)
(priority 4)) (errand (name groceries)
(kind goods) (earliest 900)
(latest 1800) (duration 130) (priority 5))
(errand (name bank) (kind visit)
(earliest 930) (latest 1530)
(duration 30) (priority 2))
)
8. Как вы оцениваете методику последовательного уточнения программы, которая была использована при выполнении упр. 4-7? Какие, по-вашему, существуют доводы за и против использования такой методики разработки?
ГЛАВА 16. Средства формирования пояснений
16.1. Формирование пояснений на основе знаний
16.1.1. Подсистема формирования пояснений в MYCIN
16.1.2. Формирование пояснений в системах, производных от MYCIN
16.1.3. Формирование пояснений на основе фреймов
16.1.4. Организация вывода пояснений в системе CENTAUR
16.1.5. Использование мультимедийного интерфейса для формирования пояснений
16.2. Формирование пояснений и автоматическое программирование
16.2.1. Автоматическое программирование в системе XPLAN
16.2.2. Проект Explainable Expert Systems
16.2.3. Планирование текстов пояснений и модели пользователей в PEA
16.3. Перспективы дальнейших исследований методов формирования пояснений
Рекомендуемая литература
Упражнения
ГЛАВА 16. Средства формирования пояснений
16.1. Формирование пояснений на основе знаний
16.2. Формирование пояснений и автоматическое программирование
16.3. Перспективы дальнейших исследований методов формирования пояснений
Рекомендуемая литература
Упражнения
Существуют две причины, которые побуждают разработчиков экспертных систем делать их по возможности "прозрачными" для пользователя. Под прозрачностью при этом понимается способность системы объяснить пользователю, почему принято именно такое решение, вследствие каких рассуждений система пришла к тому или иному выводу.
Клиент, который обращается к экспертной системе за советом, должен знать, на основе каких логических доводов этот совет был сформирован. Только получив исчерпывающую информацию о ходе рассуждений, клиент может с доверием отнестись к полученному совету, поскольку за последствия неверно принятого решения расплачиваться придется не столько "советчику", сколько чересчур доверчивому клиенту.
Инженер, обслуживающий экспертную систему, должен быть уверен в правильности работы всех подсистем, а проверить это он может, только получив от экспертной системы всю возможную информацию о ходе рассуждений в процессе решения задач.
Эту главу мы начнем с краткого обзора ранних работ, касающихся включения в экспертные системы специальных средств, формирующих для пользователя информацию о ходе рассуждений (в дальнейшем для краткости мы будем называть ее поясняющей информацией). Затем более детально будут рассмотрены средства формирования пояснений экспертной системы CENTAUR, о которой уже упоминалось в главе 13. И в заключение мы обсудим одно из последних исследований в этой области, выполненное в рамках проекта Explainable Expert Systems, в котором основное внимание было уделено обеспечению прозрачности экспертной системы с точки зрения инженеров по знаниям, т.е. была предпринята попытка рассмотреть в комплексе вопросы формирования поясняющей информации и извлечения знаний
16.1. Формирование пояснений на основе знаний
На начальном этапе исследований в области экспертных систем, которые выполнялись в Станфордском университете в 60-70-х годах/поясняющая информация предоставлялась в виде трассировки процесса выполнения программы и использовалась в основном для отладки разрабатываемых систем. Этого было достаточно для разработчиков экспериментальных систем, подобных MYCIN, но не соответствовало тому уровню сервиса пользователя, который необходим для коммерческого программного продукта. Впоследствии вопросу формирования информации, которая давала бы возможность пользователю четко представить себе ход рассуждений программы, стало уделяться значительно больше внимания.
Исследователи пришли к заключению, что автоматическое формирование пояснений требует доступа к модели предметной области точно так же, как и извлечение знаний (см. об этом в главе 10). Другими словами, представление о знаниях в конкретной области необходимо для предоставления пользователю информации о поведении системы в процессе формирования результата точно так же, как и для приобретения новых знаний.
Такое знание позволит перекинуть мост между деталями реализации процесса вывода (например, в какой последовательности активизировались правила) и стратегией поведения системы (например, какие соображения побудили систему выбрать ту или иную гипотезу из множества конкурирующих).
В последние десятилетия специалисты серьезно потрудились над развитием этой идеи, и обзор некоторых из полученных результатов читатель найдет в разделе 16.2. Совершенно очевидно, что проблемы извлечения знаний и формирования пояснений тесно связаны. По сути, они представляют две стороны одной медали. Существенным толчком для совершенствования средств, используемых для предоставления пользователю пояснений, как, впрочем, и для извлечения знаний, стало развитие методов графического интерфейса в современных операционных системах, которые обеспечивают возможность вывода не только статической, но и динамической видеоинформации со звуковым сопровождением.
16.1.1. Подсистема формирования пояснений в MYCIN
Модуль формирования пояснений в экспертной системе MYCIN (о ней шла речь в главе 3) автоматически вызывается по завершении каждого сеанса консультаций. Для того чтобы предоставить пользователю информацию о том, почему система рекомендует именно такие значения медицинских параметров, модуль извлекает список правил, активизированных в процессе сеанса, и распечатывает его вместе с заключениями, которые были сделаны этими правилами. Модуль также позволяет пользователю задавать вопросы системе по поводу выполненной консультации, причем вопросы могут носить и обобщенный характер.
Способность системы отвечать на вопросы пользователя, касающиеся выполненной работы, основывается на следующих функциях:
вывод на экран правил, активизированных на любой стадии консультации;
запись и сохранение в процессе работы активизированных правил и связанных с ними событий, например задаваемых вопросов и сформированных заключений;
использование индексации правил, которая дает возможность извлечь определенное правило в ответ на вопрос, содержащийся в пользовательском запросе.
Как отмечалось в главе 3, процесс выполнения консультаций в экспертной системе, использующей обратную цепочку логического вывода, включает поиск в дереве целей (рис. 16.1). Следовательно, справки о ходе выполнения консультации можно разделить на два типа:
почему система сочла необходимым задать пользователю определенный вопрос;
как система пришла к определенному заключению.
Чтобы ответить на вопрос почему, нужно просмотреть дерево целей "вверх" и определить, какую цель более высокого уровня пытается достичь система. Чтобы ответить на вопрос как, нужно просмотреть дерево "вниз" и выяснить, достижение каких подцелей привело к данной цели (в текущее состояние). Таким образом, процессе формирования пояснений можно рассматривать как некоторый вид прослеживания дерева целей, т.е. свести к задаче поиска в дереве.
Тот факт, что MYCIN отслеживает прохождение структур цель-подцель в процессе выполнения вычислений, позволяет этой системе отвечать на вопросы вроде приведенного ниже.
"Почему вас интересует, является ли окраска микроорганизма грамотрицательной?"
Рис. 16.1. Формирование ответов на основе дерева целей в системе MYCIN
В ответ система может процитировать правило, которое утверждает, что если микроорганизм имеет грамотрицательную окраску и соблюдаются другие условия, то этот организм относится к классу enterobacteriaceae. Помимо цитирования правила, в ответе также указывается, что текущая цель — выяснение класса микроорганизма.
В MYCIN сохраняется список всех решений, принятых в течение сеанса работы, а затем этот список используется для пояснения и уточнения принятых решений в ответ на вопрос пользователя почему, например, такой:
"Почему вы предполагаете, что Организм-1 это протеин?"
В ответ MYCIN процитирует правило, относящееся к этому заключению, и выведет значение степени уверенности в достоверности этого правила. Системе MYCIN можно также задавать вопросы общего характера. Такие вопросы касаются правил безотносительно к текущему состоянию базы данных, т.е. безотносительно к конкретному пациенту. Например:
"Что прописывать при заражении инфекцией pseudonomas?"
В ответ система выведет тот набор препаратов, который рекомендуется в правилах, касающихся инфекции pseudonomas.
Однако пользователь не может получить доступ к информации, хранящейся в виде статических знаний или в таблицах знаний, поскольку эти источники данных не имеют формата порождающих правил. Кроме того, механизм формирования рекомендаций о курсе лечения и выборе предпочтительных медикаментов представлен в программе в виде LISP-функций, которые пользователь не может просмотреть (а если и сможет, то вряд ли что-нибудь в них поймет). Пользователь также не может задать системе вопросы о том, в каком порядке просматриваются правила в процессе формирования решения и в каком порядке анализируются условия, специфицированные в этих правилах.
Подытоживая сказанное о средствах формирования пояснений в системе MYCIN, отметим, что хотя вопросы как и почему и дают пользователю определенную информацию о порядке логического вывода, но признать ее достаточной можно с большими оговорками. Пользователю трудно проследить за логикой процесса по длинной распечатке активизированных правил. Правда, такая распечатка содержит довольно ценную информацию для инженеров по знаниям и разработчиков системы, особенно на стадии ее настройки.
В тех экспертных системах, в которых используется прямая цепочка рассуждений, список активизированных правил несет еще меньше полезной для пользователя информации, поскольку на промежуточной стадии вычислений трудно по нему судить, куда же ведет цепочка рассуждений.
16.1.2. Формирование пояснений в системах, производных от MYCIN
Вряд ли для кого-нибудь является секретом, что по мере увеличения размеров базы знаний в экспертной системе проблемы понимания ее поведения, оперативного наблюдения и корректировки поведения нарастают как, снежный ком (см., например, [Davis, 1980, b]). Например, бывает трудно обеспечить полную совместимость новых правил с включенными ранее в базу знаний или разобрать в потоке управления в тех ситуациях, когда большое число конкурирующих друг с другом правил пытается "обратить на себя внимание" интерпретатора. Исследователям пришлось немало потрудиться над проблемой обнаружения противоречивости и преодоления избыточности множества правил (см. в [Suwa et al, 1980, b]).
Система EMYCIN (Empty MYCIN — пустая MYCIN) представляет собой оболочку, созданную на базе системы MYCIN [van Melle, 1981]. Идея состояла в том, чтобы удалить из системы MYCIN базу знаний и создать таким образом систему, сохраняющую все функциональные возможности MYCIN, которую в дальнейшем можно наполнять знаниями из той или иной предметной области (подробнее об этом см. в главе 10). В процессе разработки в EMYCIN были внесены некоторые усовершенствования по сравнению с прототипом. Для облегчения работы инженеров по знаниям в ходе отладки новой базы знаний в систему включены команды EXPLAIN (объяснение), TEST (проверка) и REVIEW (просмотр). Как и в MYCIN, команда EXPLAIN выводит на печать список тех правил, которые были активизированы в процессе сеанса работы. При этом выводится еще и дополнительная информация:
(1) значение коэффициента уверенности, полученное в результате выполнения правила;
(2) значения условий, специфицированных в активизированном правиле;
(3) последний вопрос, который задавала система пользователю перед тем, как сформировать заключение.
Использование в MYCIN и EMYCIN метаправил, которые позволяют в явной форме управлять выбором активизируемых правил, создает предпосылки для анализа пользователем стратегии поведения экспертной системы в процессе формирования рекомендаций. Теперь можно было задуматься и над тем, как отразить применение метаправил в формируемых пояснениях, — предоставить пользователю информацию о том, почему в данной ситуации из множества возможных правил система выбрала именно это, а остальные отвергла.
В конце 1970-х годов в Станфорде на основе ранее созданных систем была разработана усовершенствованная программа NEOMYCIN, в которой была предпринята попытка использовать более абстрактный подход к решению медицинских проблем, чем в прототипе, все в той же MYCIN [Clancey and Letsinger, 1984], [Clancey, 1987, с]. В центре внимания разработчиков оказались те знания, которыми пользуются врачи-практики при рутинной процедуре диагностики, и связанный с ними ход рассуждений. Таким образом, было уделено значительное внимание моделированию того метода решения проблемы, который присущ человеку (так называемое когнитивное моделирование). Тот метод логического вывода, который был использован в системе-прототипе MYCIN, вряд ли придет в голову кому-либо из практикующих врачей — совпадают у них только результаты.
Этот новый подход отразился и на средствах формирования пояснений. В NEOMYCIN упор был сделан на пояснении стратегии поведения системы — предоставлении пользователю информации об общем плане решения проблемы и методах, использованных для достижения поставленной цели, а не просто перечислении правил, активизированных в процессе работы [Hasting et al., 1984]. В процессе накопления и интерпретации данных в центре внимания постоянно находилось текущее множество гипотез (дифференциал — термин, производный от дифференциального диагностирования). Для того чтобы разобраться в поведении программы, т.е. в вопросах, которые ставит программа, и в потоке управления, пользователю нужен доступ к стратегии диагностирования, которую использует программа.
Основные принципы организации системы NEOMYCIN следующие.
Стратегические знания отделены от собственно медицинских и представлены в виде метаправил.
Информация о заболеваниях имеет таксономическую организацию, как в системе INTERNIST, и таким образом обеспечено в некотором роде явное представление пространства гипотез.
Знания перечисленных выше типов отделены от правил, которые связывают гипотезы с данными.
Таким образом, основным является все-таки подход на базе эвристической классификации (см. об этом в главах 11 и 12), но смешанная схема представления структур данных и управления использованием правил упрощает реализацию процесса. Кроме того, правила, относящиеся к предметной области, в свою очередь, разделены на четыре класса.
Причинные правила связывают симптомы и гипотезы через сеть симптомов и категорий заболеваний.
Запускающие правила связывают данные с гипотезами и таким образом обеспечивают построение прямой цепочки рассуждений. Когда активизируется правило этого типа, соответствующая гипотеза помещается в дифференциал.
Правила данные/гипотезы также связывают данные с гипотезами, но распространяются они только на те гипотезы, которые уже включены в дифференциал.
Правила отображения представляют такие операции, как ограничение данных, например "если пациент мужчина, то отбросить возможность беременности".
Процитированное ниже метаправило представляет общую стратегию поведения системы, которая заключается в том, что выискиваются данные, отличающие две текущие гипотезы, например данные, которые подтверждают правдоподобность одной гипотезы, но никак не связаны с другой.
METARULE397
ЕСЛИ: В дифференциале имеются два элемента, которые отличаются какими-либо характеристиками заболевания, ТО: Задать вопрос, который позволит выяснить отличие этих заболеваний.
Таким образом, использованный в MYCIN глобальный режим управления, организующий обратную цепочку логического вывода, заменен в NEOMYCIN выполнением метаправил, которые полностью определяют поток управления в программе. Это значительно более радикальный способ использования метаправил, чем тот, который имел место в MYCIN.
Упорядоченный набор метаправил выполнения определенных задач можно рассматривать как своего рода метауровневую архитектуру, в которой задачи и подзадачи соответствуют целям и подцелям на метауровне. Метаправила представляют собой методы достижения абстрактных целей, например "сформировать вопросы", а уже правила предметного уровня задают конкретные вопросы. Вместо того чтобы формировать суждения об отдельных фрагментах информации, метаправила представляют общую стратегию манипулирования информацией.
В дополнение к правилам, которые запрашивают конкретные данные у пользователя, в NEOMYCIN существуют и правила, управляющие процессом опроса пользователя. Эти правила цитируются при формировании пояснения, почему пользователю был задан конкретный вопрос.
Другой вариант модернизации системы MYCIN был осуществлен в 1970-х годах и вылился в создание системы CENTAUR [Aikins, 1983]. В этой программе (см. главу 13) используется смешанное представление знаний, заимствованных из ранее созданной экспертной системы PUFF, предназначенной для диагностики легочных заболеваний. В архитектуре системы CENTAUR фреймы (см. главу 6) и порождающие правила (см. главу 6) объединены таким образом, что это значительно упрощает формирование пояснений.
16.1.3. Формирование пояснений на основе фреймов
Вы уже имели возможность убедиться в том, что сформировать достаточно информативные пояснения, пользуясь только результатами трассировки активизированных правил, довольно сложно. Информация, содержащаяся в правилах, не несет достаточных сведений о контексте, в котором эти правила были активизированы. Фактически мы узнаем только о выполнении тех условий, которые явно специфицированы в активизированном правиле. Отсутствуют сведения о том, для какой задачи более высокого уровня потребовалось активизировать то или иное правило. Например, желательно знать, потребовалось ли это для подтверждения какой-либо гипотезы, или для принятия решения о выборе между конкурирующими гипотезами, или для запроса данных у пользователя и т.п.
В результате исследователи и разработчики экспертных систем в 1980-х годах задумались над тем, как объединить порождающие правила с фреймами, которые могли бы предоставить необходимую информацию о контексте. Во фреймах могут быть представлены важные отношения между данными и гипотезами, которые не нашли отражения в порождающих правилах. Кроме того, фреймы могут служить удобными контейнерами для поясняющих текстов. Когда в начале 1990-х годов в распоряжении программистов появились мультимедийные средства, фреймы стали использоваться для хранения не только поясняющих текстов, но и ссылок на сопутствующие изображения, например схемы, или даже на целые руководства в электронном виде.
16.1.4. Организация вывода пояснений в системе CENTAUR
Первый вариант реализации системы PUFF, который был выполнен на основе оболочки EMYCIN (см., например, [Aikins et al., 1984]), оказался вполне работоспособным в том смысле, что хорошо справлялся с решением проблем в своей области, но схема представления знаний в нем не совсем удовлетворила разработчиков по следующим причинам.
С ее помощью трудно представлять типовые образцы данных или типичные классы пациентов.
Добавление или модификация правил при расширении базы знаний или уточнении ранее введенных знаний требовали слишком больших затрат.
Изменение порядка, в котором информация запрашивается у пользователя, также было связано с определенными сложностями, поскольку запросы формируются интерпретатором автоматически, как только активизируются правила.
Особую проблему представляет формирование ясных пояснений, поскольку практически для выполнения этой задачи доступна информация, лишь незначительно более обширная, чем просто результаты трассировки последовательности активизации правил.
Эйкинс (Aikins) также обратила внимание на то, что отчетливо выраженная модульность и единообразие порождающих правил имеет и обратную сторону. Большинство наборов правил обладает неявно выраженной группировкой, которая существует либо в виде определенного порядка индексации, скрытой в интерпретаторе (например, в наборе ORGRULES и PATRULES системы MYCIN, которые относятся к микроорганизмам и пациентам соответственно), либо в виде условий и операций, которые манипулируют лексемами целей в рабочей памяти. Такая организация зачастую имеет иерархический характер, предполагающий таксономический характер организации гипотез (в задачах классификации) и декомпозицию целей на подцели (в задачах конструирования). Многие из упомянутых выше проблем можно свести к минимуму, выделив отдельные виды знаний и манипулируя ими по-разному. Как вы помните из главы 13, в системе CENTAUR разработчики объединили методы программирования, основанные на правилах и концепции фреймов, таким образом, чтобы компенсировать слабости каждого из подходов и усилить их достоинства.
Что касается формирования пояснений, то в системе CENTAUR сделан акцент на контексте, в котором формировалось суждение, и на зависимости между применяемой экспертом методикой и этапом процесса решения проблемы. Для того чтобы понять, почему задан определенный вопрос, нужно принимать во внимание не только то правило, которое при этом активизировано, но и ту гипотезу, которая анализируется на данном этапе. Таким образом, Эйкинс вполне разделяет опасения, высказанные Кленси, хотя ее подход и менее амбициозен, поскольку в нем дело не дошло до когнитивного моделирования.
Работа консультирующей программы CENTAUR состоит в основном из выполнения интерпретатором текущего списка актуальных задач, кроме того, в ней значительно меньше места отводится построению цепочки правил. Основное назначение списка актуальных задач— способствовать формированию пояснений, почему система поступает именно так в ходе данного сеанса консультаций. Поэтому каждый элемент в списке задач содержит информацию как об источнике задачи, так и о причине, которая побудила систему включить данную задачу в список актуальных.
Источником задачи может быть активный прототип (т.е. тот, который наиболее близок к специфическим данным рассматриваемого случая) или другая задача. Новые задачи добавляются в список актуальных либо слотами управления прототипов, либо в процессе выполнения тех задач, которые ранее были включены в список актуальных. Информация о причине добавления генерируется на основе наименования прототипа и имени управляющего слота, ответственного за включение задачи.
В ходе выполнения программы прототип находится в одном из трех возможных состояний:
неактивный, т.е. не рассматриваемый в качестве гипотезы;
потенциальный кандидат, т.е. такой, который имеет смысл рассмотреть исходя из имеющихся значений данных;
активный, т.е. выбранный из множества потенциальных кандидатов и помещенный в список гипотез.
Прототипы заболеваний представляют гипотезы! Список гипотез — это, по сути, список пар "прототип-коэффициент уверенности", упорядоченных в убывающем порядке значений коэффициентов уверенности. Имеются еще два списка, которые служат для отслеживания подтвержденных и отвергнутых прототипов.
Основные события в сеансе выполнения консультации с помощью системы CENTAUR следующие:
ввод исходных данных;
отбор прототипов с использованием антецедентных правил;
оценка прототипов и выбор единственного, который назначается "текущим";
анализ известных фактов и заполнение на их основе полей данных текущего прототипа;
проверка соответствия фактов и ожидаемых значений;
выявление данных, не учтенных начальным вариантом диагноза;
уточнение диагноза на основе выявленных данных;
суммирование и вывод результатов.
В самом начале сеанса в качестве текущего выбирается прототип CONSULTATION (консультация), а в список активных включаются две задачи текущего прототипа: FILL-IN (заполнение) и CONFIRM (подтверждение), которые извлекаются из управляющих слотов TO-FILL-IN и IF-CONFIRMED прототипа. Структура слотов прототипа CONSULTATION представлена ниже.
CONSULTATION
....................
TO-FILL-IN:
Запросить значение
TRACING-LEVEL для задачи
CONSULTATKDN Запросить значение
AGENTA-PRINTING для задачи
CONSULTATION Запросить значение
STRATEGY для задачи
CONSULTATION
IF-CONFIRMED:
Установить порог подтверждения равным 0
Установить относительное заполнение слотов, необходимое для подтверждения прототипа, равным 0.75
Установить процедуру по умолчанию для заполнения слотов: заполнение в убывающем порядке по степени важности Определить предмет консультации Выбрать лучший из текущих прототипов Заполнить прототип
Применить задачи из слота IF-CONFIRMED прототипа Отметить все факты, принимаемые во внимание прототипом Применить правила уточнения, связанные с подтвержденными прототипами; применить правила подведения итога, связанные с подтвержденными прототипами; выполнить операции, связанные с подтвержденными прототипами
Слот TO-FILL-IN прототипа фактически содержит три подзадачи, каждая из которых устанавливает определенную переменную сеанса консультаций: переменная TRACING-LEVEL задает уровень детализации трассировки, переменная AGENTA-PRINTING указывает, будут ли выводиться на печать наименования задач по мере включения их в список активных или по мере выполнения, а переменная STRATEGY может принимать значения CONFIRMATION (выбор наилучшего варианта и подтверждение его), или ELIMINATION (выбор наихудшего варианта и исключение его), или FIXED-ORDER (использование предопределенного порядкаобработки гипотез).
Первые три задачи слота IF-CONFIRMED устанавливают значения переменных, управляющих процессом консультации. В частности, одна из переменных определяет, какая часть полей прототипа должна быть заполнена прежде, чем его можно будет считать подтвержденным. Наличие таких переменных позволяет инженеру по знаниям экспериментировать с разными режимами управления процессом и, возможно, настраивать работу системы в разных предметных областях. Остальные задачи слота IF-CONFIRMED управляют отдельными этапами проведения консультации.
После того как будет определен предмет консультации (в настоящем контексте это область легочных заболеваний), следующим текущим прототипом становится PULMONARY-DISEASE. Первой задачей, специфицированной в этом прототипе, является запрос данных у пользователя. Протокол такого диалога представлен ниже (в переводе на русский язык). Нумерованная строка в протоколе — запрос системы, а текст после двух звездочек, выделенный полужирным шрифтом, — ответ пользователя. В квадратных скобках приведены комментарии — сообщения, которыми система дает знать пользователю, что она отыскала соответствующий прототип в базе знаний и в дальнейшем будет рассматривать его в качестве кандидата для более подробного анализа.
------ПАЦИЕНТ-7 -------------
1) Идентификационный номер пациента: 7446
2) По поводу какого заболевания: АСТМА
[Прототип ASTHMA, МП 900]
3) ООЛ/ООЛ предсказываемый:
261
4) ОЕЛ (плетизмографическая) наблюдаемая/предсказываемая: 139
5) ФЖЕ/ФЖЕ предсказываемая:
81
[Прототип NORMAL, МП 500]
6) Отношение ОФВ1/ФЖЕ: 40
[Прототип ОАО, МП 900]
7) ПСОУ/ПСОУ предсказываемая: 117
[Прототип NORMAL, МП 7dO]
8) Изменение в ОФВ1 (после приема бронхолитиков): 31
9) УПМС/УПМС предсказываемая:
12
[Прототип ОАО, МП 900]
10) Наклон П5025: 9
[Прототип ОАО, МП 900]
Рассмотрим подробнее один из вопросов в этом протоколе.
6) Отношение ОФВ1/ФЖЕ: 40 [Прототип ОАО, КУ900]
Аббревиатуры в этих строках обозначают найденные прототипы заболеваний, МП означает "мера правдоподобия", ООЛ, ОЕЛ, ФВЖ и т.д. — результаты лабораторных анализов и измерения легочных функций:
ООЛ — остаточный объем легких, литры;
ОЕЛ — общая емкость легких, литры;
ФУКЕ — форсированная жизненная емкость легких, литры;
ОФВ1 — объем форсированного выдоха за 1 с, литры;
ПСОУ — проникающая способность для окиси углерода.
Введенное пользователем значение 40 отношения объема форсированного выдоха за 1 с (ОФВ1) к форсированной жизненной емкости легких (ФЖЕ) побуждает систему активизировать прототип ОАО (Obstructive Airways Dicease — обтурация воздухоносных путей) с мерой правдоподобности этой гипотезы 900.
Значение меры правдоподобия той или иной гипотезы выбирается в диапазоне от -1000 до 1000 исключительно из соображений упрощения вычислений. Этот параметр отражает степень уверенности системы в обоснованности выдвинутой (активизированной) гипотезы на основе имеющихся данных о конкретной истории болезни. Фактически при определении меры правдоподобия система сравнивает введенные пользователем данные с теми, которые хранятся в слотах прототипа-кандидата. Полученные значения служат основанием для выбора самой правдоподобной из имеющихся гипотез (прототипов). Назначение параметра "мера правдоподобия" в системе CENTAUR такое же, как и коэффициента уверенности в системах MYCIN и EMYCIN, причем для операций с мерами правдоподобия используются те же алгоритмы, что и для операций с коэффициентами уверенности. Обратите внимание — в процессе диалога с пользователем система не объясняет, почему выбрано именно такое, а не иное значение меры правдоподобия. Для пользователя алгоритм вычисления меры правдоподобия является "черным ящиком".
В экспертных системах, полностью основанных на правилах, в протоколе трассировки обычно выводятся только те исходные данные, которые активизируют правило, получившее наивысшую оценку при разрешении конфликта. Пользователю в такой ситуации остается только гадать, как система отреагировала на данные, которые были введены, но не упоминаются в протоколе. Как видно в приведенном выше протоколе диалога с пользователем, программа CENTAUR сразу же дает знать пользователю, какие предварительные соображения вызвали у нее введенные значения отдельных параметров.
После завершения диалога система предъявляет пользователю свои "соображения" по поводу введенных данных.
Гипотеза: ASTHMA, МП: 900. Причина: предыдущий диагноз — АСТМА
Гипотеза: NORMAL, МП: 500. Причина: ФЖЕ равно 81
Гипотеза: ОАО, МП: 900. Причина: отношение ОФВ1/ФЖЕ равно 40
Гипотеза: NORMAL, МП: 700. Причина: ПСОУ равно 117
Гипотеза: ОАО, МП: 900. Причина: УПМС равно 12
Гипотеза: ОАО, МП: 900. Причина: наклон П5025 равен 9
Наиболее правдоподобные гипотезы: NORMAL, ОАО [Новые анализируемые прототипы: NORMAL, ОАО]
Из этой распечатки следует, что далее система сосредоточится на двух наиболее правдоподобных гипотезах: NORMAL и OAD. Эти две гипотезы являются непосредственными "наследниками" прототипа PULMONARY-DISEASE. Рассмотрение гипотезы ASTHMA на время откладывается по той причине, что она является подтипом гипотезы OAD. Эта гипотеза будет рассмотрена в процессе уточнения гипотезы OAD, в полном соответствии со стратегией нисходящего уточнения. Иерархическая структура пространства гипотез позволяет дать пользователю полную и ясную информацию о том, как эта стратегия претворяется в жизнь в экспертной системе. В системах, полностью основанных на правилах, пользователь должен представлять себе ту стратегию разрешения конфликтов между конкурирующими правилами, которая используется в системе, и только тогда он сможет понять, почему в определенной ситуации было отдано предпочтение именно той гипотезе, которая зафиксирована в распечатке результата трассировки, а не какой-либо иной.
Обратите внимание — не все данные, введенные пользователем в ходе начального диалога, приводят к выбору гипотез-кандидатов, а в список гипотез-кандидатов попадает несколько прототипов. При заполнении данными отобранных в этом списке двух гипотез — NORMAL и OAD — такой параметр, как ОЕЛ (общая емкость легких), который в ходе диалога не повлиял на начальный список, будет учтен и, вполне возможно, повлияет на значение меры правдоподобия анализируемой гипотезы. Значение этого параметра (139) заставляет систему подвергнуть сомнению правдоподобность гипотезы NORMAL, как будет показано ниже в примере распечатки значений тех параметров, которые привели систему "в замешательство". Данные, которые "не вписываются" в диапазон, представленный в слотах определенных прототипов, заставляют систему снижать меру правдоподобия соответствующей гипотезы.
!.Неожиданное значение: ООЛ равно 261 в NORMAL, МП: 700
!Неожиданное значение: ОЕЛ равно 139 в NORMAL, МП: 400
!Неожиданное значение: ОФВ1/ФЖЕ равно 40 в NORMAL, МП: -176
!Неожиданное значение: УПМС равно 12 в NORMAL, МП: -499
!Неожиданное значение: П5025 равно 9 в NORMAL, МП: -699
Из представленной распечатки видно, что, хотя по итогам предварительного экспресс-анализа введенных данных гипотеза NORMAL представлялась весьма правдоподобной, более подробное исследование всей совокупности данных, в частности пяти параметров, включенных в распечатку, заставило систему весьма засомневаться в ее обоснованности. Всю эту информацию пользователь может почерпнуть из распечаток, которые система CENTAUR выводит в процессе работы. Затем формируется список гипотез, который упорядочивается в порядке убывания, причем на первом месте оказывается прототип ОАО:
Список гипотез: (ОАО 999) (NORMAL -699)
Проверяется гипотеза ОАО (ОБТУРАЦИЯ ВОЗДУХОНОСНЫХ ПУТЕЙ)
Далее система подтвердит гипотезу о том, что пациент страдает обтурацией воздухоносных путей, причем степень заболевания — серьезная, а подтип заболевания — астматический. После этого система переходит к этапу уточнения диагноза. На этом этапе пользователю задаются дополнительные вопросы, ответы на которые несут необходимую для этого информацию. Этот этап выполняется под управлением специальных правил уточнения, которые хранятся в слотах соответствующего прототипа. Протокол фрагмента уточняющего диалога с пользователем приведен ниже.
[Выполнение уточняющих правил ...]
20) Число "пачко-лет" курения: 17
21) Как давно пациент бросил курить: 0
22) Степень затруднения дыхания: НЕТ
После завершения уточняющего диалога в дело вступают правила, формирующие заключение для данного сеанса консультаций. Эти правила специфичны для каждого из возможных прототипов, и в конце сеанса выполняется тот набор правил, который связан с прототипом выбранной гипотезы. Набор правил этого типа, связанных с прототипом OAD, приведен ниже.
[Выполняются действия, заданные в слоте ACTION прототипа ОАО ...]
Заключение: показания, свидетельствующие в пользу диагноза "Обтурация воздухоносных путей", следующие:
Увеличенные объемы легких указывают на гипернаполнение.
Увеличенное значение отношения ООЛ/ОЕЛ согласуется с наличием тяжелой обтура-ции воздухоносных путей. Форсированная жизненная емкость в норме, но отношение ОФВ1/ФЖЕ понижено, что указывает на обтурацию воздухоносных путей в тяжелой форме.
Низкий средневыдыхаемый поток согласуется с наличием тяжелой обтурации воздухоносных путей. На обтурацию воздухоносных путей указывает кривизна зависимости потока воздуха от объема.
После приема бронхолитиков улучшается проходимость воздухоносных путей, что подтверждается изменением значения ОФВ1.
После приема бронхолитиков улучшается проходимость воздухоносных путей, что подтверждается изменением значения УПМС.
Обратимость обтурации воздухоносных путей подтверждается улучшением проходимости после приема бронхолитиков.
Эти правила суммируют информацию, собранную в процессе диалогового "обследования" пациента, и не требуют никакой ответной реакции со стороны пользователя.
Пример окончательного заключения, которое выполняется правилами, хранящимися в слоте ACTION прототипа PULMONARY-DISEASE, представлен ниже.
[Выполняются действия, заданные в слоте ACTION прототипа PULMONARY-DISEASE ...]
-------Заключение--------
— Обтурация воздухоносных путей------
Диагноз "Обтурация воздухоносных путей" сделан на основании следующих фактов:
Отношение ОФВ1/ФЖЕ для ПАЦИЕНТА-7: 40
Отношение УПМС/УПМС-предсказываемая для ПАЦИЕНТА-7: 12
Значение наклона П5025 для ПАЦИЁНТА-7: 9
Кроме того, диагноз "Обтурация воздухоносных путей" согласуется со следующими
данными:
Отношение ОЕЛ/ОЕЛ-предсказываемая для ПАЦИЕНТА-7: 139
Отношение ООЛ/ООЛ-предсказываемая для ПАЦИЕНТА-7: 261
Значение П25 для ПАЦИЕНТА-7: 45
Степень затруднения дыхания для ПАЦИЕНТА-7: НЕТ
Интенсивность кашля для ПАЦИЕНТА-7: НЕТ
При установлении диагноза "Обтурация воздухоносных путей" должны приниматься во внимание следующие показания:
Ранее поставленный диагноз для ПАЦИЕНТА-7
Отношение ОФВ1/ФЖЕ для ПАЦИЕНТА-7
Значение П25 для ПАЦИЕНТА-7
Степень затруднения дыхания для ПАЦИЕНТА-7
Интенсивность кашля для ПАЦИЕНТА-7
Все указанные факты были приняты во внимание при подтверждении прототипа.
Заключение: возможно, курение усугубляет серьезность обтурации воздухоносных путей у пациента. Прекращение курения поможет избавиться от некоторых симптомов. Хорошая реакция на бронхолитики согласуется с астматическим характером заболевания. Высокая проникающая способность согласуется с астмой.
Диагноз: обтурация воздухоносных путей астматического типа в серьезной форме. Консультация завершена.
Поскольку поведение программы по отношению к пользователю на каждом этапе зависит от смысла этого этапа, пользователю довольно легко разобраться в логике рассуждений "консультанта". На каждой стадии процесса понятно, чего пытается добиться система и какой прототип активизирован. Поэтому разобраться в работе системы и инженеру, занимающемуся отладкой, и пользователю, обратившемуся за консультацией, значительно легче, чем в случае, когда приходится иметь дело с программой, не оснащенной дополнительными структурными элементами, присущими системе иерархических фреймов.
Подводя итог обсуждению возможностей программы CENTAUR, Эйкинс обратила внимание на то, что пользователю, для того чтобы правильно интерпретировать заключение, представленное программой, необходимо иметь четкое представление о смысле вопросов, которые задает программа, причинах, побудивших программу задавать именно такие вопросы, и механизме уточнения промежуточных заключений.
Эйкинс отметила наличие четырех принципиальных недостатков в том виде пояснений, которые формируются в программе EMYCIN.
Пользователь вынужден следовать за цепочкой обратных рассуждений в процессе применения правил, а эта стратегия не свойственна тому способу логического вывода, который привычен для человека.
Знания в правилах, используемых системой, могут быть неполными или недостаточно специфичными для того уровня детализации, который позволит пользователю проследить за очередностью применения правил.
Знания, касающиеся контекста и режима управления, не выделяются на фоне прочих знаний о конкретной предметной области, т.е. отсутствует четкая граница между мета- и объектным уровнем знаний.
Применение каждого очередного правила объясняет только последний заданный перед этим вопрос, поэтому теряется общий контекст рассуждений.
Система CENTAUR задает пользователю вопросы в том случае, когда ей не удается выделить необходимую информацию из правил или когда она нуждается в значениях параметров, помеченных в правилах маркером "ask-first" (сначала спроси). Вопросы, которые пользователь может задавать системе CENTAUR, по своему характеру напоминают вопросы "КАК" и "ПОЧЕМУ", которые возможны и при работе с системой EMYCIN, но они интерпретируются в зависимости от текущей стадии процесса консультации. Так, вопрос "ПОЧЕМУ", заданный в контексте конкретного прототипа в ходе выполнения этапа формирования диагноза, будет интерпретироваться как "Почему рассматривается именно данный прототип?" Такой же вопрос на этапе просмотра исходных данных будет интерпретироваться по-другому: "Почему данный прототип подтверждается?" Система CENTAUR всегда предоставляет пользователю информацию о текущем прототипе, а потому пользователь всегда может ориентироваться, в каком контексте программа задает тот или иной вопрос.
Система CENTAUR включает в протокол формирования заключения не только список подтвержденных прототипов, но и множество дополнительной информации:
данные, которые побудили ее рассматривать каждый прототип;
данные, согласующиеся с каждым прототипом;
данные, противоречащие каждому прототипу;
данные, не принятые во внимание ни одним из прототипов.
Все данные, которые не были приняты во внимание ни одним из подтвержденных прототипов, перечисляются в итоговом протоколе. Туда же включаются и сведения о тех отвергнутых прототипах, которые учитывают эти данные. Это позволяет пользователю не упустить из виду как возможные ошибки системы (пробелы в знаниях), так и возможные ошибки в выполнении лабораторных анализов. Пользователь имеет возможность ознакомиться в итоговом протоколе не только с теми прототипами, которые программа сочла правдоподобными, но и с теми, которые она отвергла, посчитав, что они не подтверждаются имеющимися в ее распоряжении данными.
Из того краткого обзора, с которым читатель мог ознакомиться в этой главе, думаю, можно сделать вывод, к которому пришел и Кленси, — задачу формирования пояснений невозможно выделить в отдельный, достаточно автономный модуль экспертной системы. Предмет пояснений настолько связан со всеми остальными аспектами работы экспертной системы, что выделить его в отдельный компонент вряд ли кому-нибудь удастся. Мораль всей этой истории такова — о тех средствах, которые будут использованы для формирования пояснений, нужно начинать думать сразу же после начала проектирования экспертной системы, поскольку встроить их каким-либо образом в уже работающую или хотя бы наполовину спроектированную систему невозможно.
16.1.5. Использование мультимедийного интерфейса для формирования пояснений
Те примеры, которые мы рассматривали выше, базируются на самых непритязательных диалоговых средствах, предоставляющих пользователю информацию в текстовом виде и в таком же виде принимающих от него информацию. В этом разделе мы вкратце затронем тему использования современных средств поддержки графического интерфейса и более широко — мультимедийного интерфейса между компьютерной системой и пользователем для формирования пояснений в экспертных системах. Естественно, многие детали останутся за рамками этой книги, и тем читателям, которые хотят подробнее познакомиться с этой темой, следует обратиться к специальной литературе, перечисленной в конце главы. Основное внимание в этом разделе будет уделено рассмотрению общих проблем проектирования с использованием мультимедийных средств и координации различных видов таких средств при формировании пояснений в экспертных системах.
Один из способов дополнить и расширить возможности формирования пояснений в системах, базирующихся на представлении знаний в виде фреймов, — добавить в них возможность формирования изображений. В системе JETA [Abu-Hakima et al., 1993] привычный текстовый интерфейс, подобный тому, который использовался при формировании пояснений в системе CENTAUR, был дополнен изображениями диаграмм в виде схем и графов. В основу архитектуры системы JETA положена трехуровневая структура фреймов (рис. 16.2). Два уровня фреймов — диагностики и параметров — аналогичны фреймам системы CENTAUR. Третий уровень — уровень фреймов глоссария (glossary frames) — поддерживает функционирование двух первых и содержит маркеры гипертекста. Фреймы этой группы предназначены специально для формирования пояснений и поддержки системы оперативной справки, касающейся функционирования фреймов других уровней. Назначение экспертной системы JETA — определение причин отклонений в работе реактивных двигателей.
Рис. 16.2. Трехуровневая структура фреймов экспертной системы JETA
В исследовательской системе COMET [Feiner and McKeown, 1991] была предпринята попытка реализовать обширную интеграцию средств формирования пояснений со средствами представления знаний и формирования суждений. В этой системе изображения и текст не просто "законсервированы", а генерируются с помощью трех баз знаний:
системы фреймов, представляющей предметную область и действия в ней; базы диагностических правил;
базы знаний о геометрии, необходимой для формирования изображений геометрических фигур.
Предметная область, на которую была ориентирована разработка системы COMET, — техническое обслуживание и ремонт систем радиосвязи военного назначения. Программа может формировать набор инструкций по выполнению тех или иных операций обслуживания аппаратуры и осуществлять диагностику и поиск неисправностей, снабжая при этом персонал обширными пояснениями, касающимися последовательности ремонтных работ. Идея, положенная в основу этой системы, — обеспечить координацию предоставления пользователям графической и текстовой информации, которая должна иллюстрировать ключевые моменты выполнения ремонтных работ и операций по текущему обслуживанию аппаратуры.
Например, для проверки удаленного модуля ввода/вывода приемопередающей станции нужно выполнить следующие операции, оговоренные в инструкции.
(1) Нажать кнопку ВАТТ/CALL на передней панели.
(2) Настроить приемопередатчик, используя для этого переносной пульт.
(3) Проверить, появилась ли на табло надпись CALL.
В системе такая инструкция для пользователя озвучивается и снабжается иллюстрацией в виде анимации. Для этого координированно выполняются две последовательности операций — одна формирует звук (V), а другая — динамическое изображение (А):
V: Нажмите и удерживайте кнопку ВАТТ/CALL.
А: На экране увеличивается изображение клавиатуры и табло и крупным планом выделяется кнопка BAIT/CALL
V: Удерживая кнопку, настройте приемопередатчик.
А: На экране крупным планом выводится переносной пульт.
V: Одновременно следите за надписью на табло.
А: На экране подсвечивается изображение табло.
В следующем разделе мы несколько детальнее остановимся на планировании отдельных этапов представления пояснений пользователю, рассматривая их как часть общего процесса формирования пояснений. Теперь же просто отметим, что использование мультимедийных средств требует тщательной предварительной подготовки. Нужно продумать, что, когда и как показывать, как координировать работу различных звуковых и изобразительных средств, какие сервисные средства предоставить в распоряжение пользователя, и т.д.
16.2. Формирование пояснений и автоматическое программирование
В этом разделе будет рассмотрен достаточно радикальный подход к формированию пояснений в экспертных системах, который предполагает представление соответствующих знаний в явной форме и хранение их отдельно от знаний, необходимых для решения проблем в предметной области. Причиной возникновения сложностей с формированием пояснений в значительной мере является использование в процессе логического вывода различного рода эвристик и методов, "спрятанных" в самой структуре системы и таким образом недоступных тем компонентам программы, которые формируют пояснения.
В этом разделе мы остановимся на двух экспертных системах, XPLAN и PEA, при разработке которых создатели попытались решить указанные проблемы, воспользовавшись специальной программой-оболочкой. Работы выполнялись в рамках исследовательского проекта EES — Explainable Expert Systems (экспертные системы, способные давать пояснения).
16.2.1. Автоматическое программирование в системе XPLAN
Хотя трассировка активизации правил и дает информацию о поведении системы, сама по себе она не может объяснить мотивов этого поведения [Swartout, 1983]. Это объясняется тем, что мотивация поведения является частью знаний, используемых при построении и внедрении программы, и она нигде не представлена явно в виде программного кода. Другими словами, те "знания как", которые заложены в конструкции системы, т.е. принципы логического вывода суждений, как правило, смешаны со "знанием что", т.е. моделью той предметной области, на работу в которой ориентирована конкретная экспертная система. В основу проектирования системы XPLAN, созданной Свотаутом (Swartout), была положена простая, но вместе с тем продуктивная идея увязать процесс разработки экспертной системы с процессом формирования пояснений. Один из методов проектирования экспертных консультирующих систем состоит в том, чтобы выработать спецификацию модели предметной области, включив в нее и принципы функционирования объектов этой области, а затем воспользоваться услугами "автоматического программиста" и сформировать по этой спецификации собственно программу экспертной системы. Предписывающие и описывающие компоненты спецификации объединяются таким образом в единую систему и используются затем для формирования пояснений в процессе функционирования этой системы.
Модель предметной области содержит сведения, касающиеся специфики области приложения экспертной системы, в частности сведения о причинно-следственных связях и систематике объектов в этой области. Эта концепция достаточно близка тому, что Кленси (Clancy) назвал "структурным знанием" (см. об этом в главе 12). Подобные знания лежат в основе системы правил, регламентирующих действия в определенных ситуациях. Но модель предметной области включает и такие методы и эвристики, которые обычно жестко "встраиваются" в интерпретатор экспертной системы или передаются интерпретатору в качестве метаправил. Этот вид знаний в терминологии Кленси получил наименование стратегических. Свотаут отметил, что такое разделение видов знаний положительно сказывается на производительности экспертной системы при выполнении большинства функций, исключая функцию формирования пояснений.
Свотаут собрал информацию о тех вопросах, которые задают студенты-медики при работе с консультирующей системой Digitalis Therapy Advisor. В собранном массиве он выделил три базовые группы.
Вопросы, касающиеся методов, которые используются программой. Например, как программа вычисляет значение того или иного параметра.
Вопросы, касающиеся причин принятия программой того или иного решения. Например, почему программа рекомендует именно такой, а не иной курс лечения.
Вопросы, предлагающие системе уточнить смысл вопроса, заданного пользователю. Такие вопросы возникают в тех ситуациях, когда у студентов возникали сомнения, правильно ли понят пользователем заданный системой вопрос или каких именно сведений ожидает система от пользователя.
На вопросы первого типа большинство экспертных систем может ответить без особых затруднений. Все, что требуется при этом от программы, — перевести на обычный "человеческий" язык тот программный код, который она выполняет. Ответы на вопросы второго типа требуют несколько большего — программа должна обладать способностью представить пользователю те знания, на которых базируется программный код. Еще с большими сложностями сталкивается экспертная система при ответах на вопросы третьего типа. Она должна обладать способностью представлять себе, как пользователь понимает терминологию, используемую в исходном вопросе (т.е. в вопросе, который система задала пользователю и который послужил причиной ответного вопроса), и разрешать любые конфликты между действительным смыслом вопроса и тем, как он воcпринят пользователем. При разработке системы XPLAN основное внимание было уделено способности системы отвечать на вопросы второго типа.
Подход на основе автоматического программирования, который использован в системе XPLAN, можно рассматривать как метод объединения фаз спецификации и реализации в процессе создания экспертной системы. Идея состоит в том, что описание модели предметной области должно быть полностью декларативным. В этом случае программа может использовать одни и те же структурные элементы знаний для выполнения разных функциональных задач. Принципы организации объектов в предметной области можно использовать для рекурсивного уточнения структуры целей, связанной с решаемой задачей. Рекурсивное уточнение выполняется до тех пор, пока в модели существуют методы, связанные с каждым из шагов самого нижнего уровня, которые должна выполнить программа.
Представленный в модели вид управления должен быть более строгим, чем использование метаправил, аналогичных тем, что имеются в системе MYCIN. На управление возлагаются более широкие функции, чем просто установление порядка применения отдельных правил, специфических для предметной области. Интеграция сформированных таким образом фрагментов программы является довольно сложным процессом, которым мы сейчас заниматься не будем, поскольку главное, что нас интересует, как из декларативного описания модели предметной области можно извлечь информацию для формирования пояснений.
16.2.2. Проект Explainable Expert Systems
Свотаут обратил внимание на проблему "компьютерных артефактов" в тех средствах формирования пояснений, которые использовались в ранее разработанных экспертных системах. Под такими артефактами он подразумевал те аспекты выполнения вычислений, которые связаны не с лежащей в основе системы моделью предметной области, а с программной реализацией алгоритмов самого нижнего уровня. Эти аспекты поведения программы совершенно не интересуют специалистов, пользующихся услугами экспертной системы.
Система XPLAN создавалась в рамках проекта Explainable Expert Systems (EES) [Heches et al, 1985], [Moore, 1995]. Идея этого проекта вполне созвучна существующей в настоящее время тенденции группировать и представлять в явном виде знания различного вида. Кроме того, в рамках этого проекта предпринята попытка использовать формальные методы, которые позволили бы зафиксировать в базе знаний системы основные решения, принимаемые в процессе ее разработки. Отсутствие таких формальных методов приводит к тому, что информация об основных решениях, положенных в основу проектирования, теряется на стадии реализации системы.
На рис. 16.3 представлена структурная схема оболочки, созданной в рамках проекта EES. Обратите внимание на прямоугольник в левой части схемы, который представляет базу знаний системы. В эту базу знаний входят не только модель и правила предметной области, но и много дополнительной информации, например описание терминологии предметной области, информация, связанная с правилами предметной области, о доводах в пользу и против выбора определенной стратегии достижения цели, информация о том, каким целям отдается предпочтение в процессе решения проблемы, и т.д. Знания, выделенные в группу "Интеграция", используются для разрешения конфликтов между правилами предметной области в процессе работы "автоматического программиста", а знания, выделенные в группу "Оптимизация", имеют отношение к производительности экспертной системы, генерируемой этим автоматическим программистом. Эти служебные группы знаний представляют те виды метазнаний, которые не связаны непосредственно с выбором правил объектного уровня в процессе логического вывода на этапе функционирования экспертной системы, а имеют отношение скорее к этапу ее проектирования.
Рис. 16.3. Структура оболочки EES ([Neches et al., 1985])
Семантика базы знаний системы EES представлена в виде семантической сети, получившей наименование NIKL [Moser, 1983]. Сеть появилась в результате развития идей, положенных в основу создания сети KL-ONE [Brachman and Schmolze, 1985]. NIKL, так же, как и KL-ONE, формирует множество концептов, имеющих собственную внутреннюю структуру (набор слотов или ролей), между которыми можно задавать отношения (формировать связи). NIKL также имеет в своем составе классификатор, который, располагая информацией о структуре конкретной сети и новом концепте с определенной структурой, может поместить этот новый концепт на соответствующее ему место в общей таксономии концептов.
Пусть, например, в сети имеются узлы концептов ЖИВОТНОЕ, СОБАКА и БЕШЕНОЕ-ЖИВОТНОЕ, а в классификатор поступает новый концепт БЕШЕНАЯ-СОБАКА. В ответ классификатор формирует новый узел для этого концепта и отводит ему место в иерархии. Новый узел будет связан "узами наследования" с узлами СОБАКА и БЕШЕНОЕ-ЖИВОТНОЕ. Это выполняется после анализа свойств и характеристик нового концепта (рис. 16.4). Трудно переоценить способность системы наращивать таким образом базу знаний, которая, как правило, никогда не создается за "один присест".
Исчез (Neches) описал применение оболочки EES для построения экспертной системы Program Enhancement Advisor (PEA). Эта программа предназначена для оказания помощи программистам в повышении "читабельности" текстов программ. В той предметной области, в которой должна работать новая экспертная система, концептами семантической сети являются преобразования элементов программного кода, например замена оператора COND языка LISP на конструкцию IF-THEN-ELSE. Концепт является частным случаем другого концепта, KEYWORD CONSTRUCT, который, в свою очередь, является частным случаем концепта Easy-TO-READ CONSTRUCT. Используя организованную таким образом базу знаний, экспертная система может предложить программисту-пользователю заменить оператор
(COND ((АТОМ X) X) (Т (CAR X)))
другим оператором, смысл которого более понятен при анализе текста программы: (IF (АТОМ X) THEN X ELSE (CAR X)).
Рис. 16.4. Включение нового концепта в семантическую сеть знаний
Знания, которые необходимы непосредственно для решения проблем, также представляются в семантической сети NIKL. Они выражаются в терминах концептов планов и целей, которые организованы в иерархическую структуру. Планы и цели связаны. Каждый план имеет "описание возможностей", в котором представлена информация о том, какие действия можно реализовать с помощью этого плана. Терминологическая информация, хранящаяся в семантической сети, используется генератором программ, например, для того, чтобы собирать воедино отдельные экземпляры концептов.
Генератор программ работает по принципу нисходящего (сверху вниз) уточнения, выполняя декомпозицию целей на подцели. Так, главная цель программы PEA — усовершенствовать программу — разделяется на подцели, например улучшить читабельность. Разработчики системы назвали такой процесс декомпозиции целей "динамическим уточнением, направляемым пользователем", поскольку характер действий, выполняемых создаваемой системой, определяется инженером по знаниям, формирующим базу знаний. Если выбрана определенная цель, скажем улучшить читабельность, то она автоматически становится субъектом процесса дальнейшей декомпозиции цель/подцель. Например, следующими подцелями будет просмотр текста программы и выявление в нем синтаксических конструкций, которые можно безболезненно заменить другими, более понятными, получение подтверждения от пользователя, одобряющего предлагаемую замену, выполнение замены и т.д. Фрагмент предыстории разработки системы PEA, в котором отображена описанная декомпозиция, представлен на рис. 16.5.
Рис. 16.5. Фрагмент предыстории разработки системы PEA, в котором отображена декомпозиция цели на подцели ([Moore, 1995])
Авторы оболочки EES утверждают, что использованный ими подход имеет следующие достоинства.
Позволяет относительно просто выразить сложные стратегии высокого уровня, которые в обычных экспертных системах представлены неявно и "упрятаны" в алгоритм интерпретатора.
Разделение всех знаний на отдельные группы упрощает разбиение системы на набор относительно независимых модулей, а значит, облегчает последующую модификацию системы в процессе ее эксплуатации.
Автоматическая классификация новых знаний с помощью языков представления семантических сетей, подобных NIKL, упрощает разработку и сопровождение системы, поскольку освобождает инженеров по знаниям от забот о структурировании новых знаний
16.2.3. Планирование текстов пояснений и модели пользователей в PEA
Помимо совершенствования базы знаний и явного представления структуры целей, для формирования пояснений необходимо также иметь определенный план выполнения этой процедуры. Мур отказался от идеи использования сценариев или шаблонов поясняющих текстов по следующим причинам [Moore, 1995].
Сценарии могут помочь в представлении шаблонов сообщений, но не учитывают возможности представления более субъективных вещей вроде информации о тех соображениях, которые побудили систему выполнить определенную манипуляцию с переменными или задать вопрос пользователю.
Сценарии образуют слишком "жесткую" конструкцию, в которую сложно втиснуть подходящие по смыслу ответы на запросы пользователя.
Вместо сценариев Мур использовал операторы планирования, в которых специфицируются определенные цели диалогового процесса, например передать пользователю информацию о мотивации некоторого действия системы. Каждое правило в операторе планирования имеет список условий, при выполнении которых применение оператора даст желаемый эффект. Ниже представлен перевод на "человеческий язык" оператора планирования, побуждающего пользователя (собеседника программы) выполнить определенное действие, например заменить какую-либо программную конструкцию языка LISP, если речь идет об области применения системы PEA.
Для перехода в состояние, в котором собеседник будет склонен выполнить операцию
ЕСЛИ
Операция представляет собой шаг к достижению некоторой цели (целей), приемлемой для собеседника, и
Цели являются наиболее приемлемыми среди всех возможных путей уточнения
ТО
Мотивировать это действие в терминах целей.
Процитированный оператор является достаточно общим и может быть применен к любой предметной области, а не только к той, в которой используется конкретная экспертная система. Однако действие, к выполнению которого этот оператор побуждает пользователя, конечно же, связано с конкретной предметной областью. Точно так же и цели имеют смысл, связанный с конкретной предметной областью. Если речь идет о системе PEA, то такой целью может быть либо улучшение читабельности программы, либо упрощение ее сопровождения, либо какая-то другая цель, которую может преследовать пользователь, работая с системой. Как и при работе с программой STRIPS и другими экспертными системами планирования, связывание таких правил в цепочку приводит к последовательному разложению целей на подцели (рис. 16.6).
Рис. 16.6. Уточнение целей при планировании диалога с пользователем
В составе программы нужно также иметь какое-то средство, которое помогло бы определить, достигнута ли цель, поставленная в плане диалога. Например, согласился ли пользователь с тем, что использование оператора IF делает текст программы более читабельным. Таким образом, необходимо динамически формировать модель поведения пользователя (его предпочтений и доверия к программе) и, сверяясь с этой моделью, проверять, удовлетворяются ли условия использования конкретного оператора планирования. В общих чертах это напоминает тот способ обращения к модели мира, который использовался в STRIPS при выяснении, можно ли протолкнуть ящик из одной комнаты в другую (см. главу 3). Но дополнительную сложность вносит необходимость представлять в модели такие понятия, как доверие и предпочтения пользователя. В системе PEA модель отдельного пользователя формируется на базе стереотипа пользователя, который обладает некоторой усредненной суммой знаний. Например, если речь идет о программировании на языке LISP, т.е. о той области, в которой применяется PEA, то следующий набор выражений представляет те знания, которыми обычно располагают пользователи:
(COMPETENT USER (DO USER REPLACE))
(KNOW-ABOUT USER (CONCEPT PROGRAM))
(KNOW-ABOUT USER (CONCEPT LISP-FUNCTION))
(KNOW-ABOUT USER (CONCEPT S-EXPR))
(KNOW-ABOUT USER (CONCEPT READABILITY))
(KNOW-ABOUT USER (CONCEPT MAINTAINABILITY))
Эти выражения на языке LISP отражают тот факт, что пользователь знает, как с по-Мощью редактора заменить одно выражение другим, имеет представление о программе и функциях языка LISP и т.д. Но система PEA может также учитывать и уровень подготовки не усредненного, а конкретного пользователя, анализируя его поведение и представленный для модификации программный код. Например, программа в процессе просмотра кода выясняет, каким функциям LISP программист отдает предпочтение, и соответственно корректирует модель пользователя. Она также фиксирует, когда пользователь соглашается с предлагаемыми программой мерами модификации анализируемого текста. В результате система способна определить, достигнута ли поставленная цель диалога с пользователем.
Подведем итоги всему сказанному о возможностях системы PEA. Планировщик этой программы располагает сформулированной целью общения с пользователем, с которой он время от времени сверяет свои действия. Как правило, это происходит, когда возникает необходимость убедить в чем-то пользователя. Обладая способностью анализировать уровень подготовки пользователя, система может адекватно формировать пояснения на том уровне детализации, который необходим именно данному пользователю
16.3. Перспективы дальнейших исследований методов формирования пояснений
В главе 13 мы обсуждали, как используется технология иерархического построения и проверки гипотез для факторизации большого пространства решений и построения обширных баз знаний в системе INTERNIST. Иерархический подход к методике решения проблем имеет и другие достоинства, в частности прозрачность поведения программы с точки зрения пользователя и гибкость управления этим поведением. Указанные возможности продемонстрированы в этой главе на примере программы CENTAUR, в которой используются иерархия фреймов для отслеживания контекста применения порождающих правил и список актуальных задач для управления порядком анализа гипотез.
Проект EES служит хорошим примером одного из направлений в современной методологии инженерии знаний, которое предполагает разделение процесса на этапы спецификации знаний и компиляции системы. Но пока что совершенно неясно, как такая методология может справиться с задачей комбинирования разных стратегий решения проблем в рамках единой системы (как это выполняется, например, в системе CENTAUR). Основная сложность в использовании этой методологии — большой объем предыстории разработки и необходимость использования чрезвычайно мощного генератора программ (см. об этом в [Neches et al, 1985]). Альтернативой такому подходу является усложнение интерпретатора включением в него мощных управляющих примитивов. В результате предыстория разработки сокращается и снижаются требования к функциональным возможностям генератора программ, но информация о принятии решений, касающихся поведения программы, оказывается спрятанной в программном коде интерпретатора. Интересно звучит предложение дополнительно нагрузить генератор программ — заставить его формировать и интерпретатор, и информацию, необходимую для формирования пояснений относительно управляющих функций. Это должно привести к еще большему разделению управляющих знаний и знаний о предметной абласти, но, предположительно, одновременно поставит перед разработчиками множество проблем, связанных с интеграцией компонентов системы.
Из приведенного краткого и довольно поверхностного описания проекта EES вы уже могли сделать вывод, что проблема автоматизации формирования пояснений является чрезвычайно сложной. Но этого описания достаточно, чтобы представить, на чем сосредоточено основное внимание исследователей в этой области. Можно выделить такие основные направления:
(1) дифференциация знаний;
(2) явное представление стратегических и структурных знаний, которые в прежних системах оказывались скрытыми в программном коде;
(3) моделирование индивидуального уровня подготовки пользователя, работающего с экспертной системой.
В этой главе основное внимание было уделено двум первым направлениям, а что касается третьего, то мы постарались хотя бы очертить круг проблем, над которыми работают исследователи
Рекомендуемая литература
Читателей, интересующихся историей разработки модели пользователя, мы отсылаем к сборникам [Sleeman and Brown, 1982] и [Poeson and Richardson, 1988]. Довольно обширная подборка статей, касающихся проблематики интерфейса с пользователем; представлена в сборнике [Maybury, 1993]. В работах [Moore and Paris, 1993] и [Moore et al, 1996] суммируется опыт планирования диалога, приобретенный авторами в процессе разработки оболочки EES и экспертной системы PEA.
Читателям, интересующимся дескриптивными языками описания семантических сетей, мы советуем обратить внимание на язык LOOM, представленный в работе [MacGregor, 1991]
Упражнения
1. Почему в качестве пояснения процесса логического вывода пользователю недостаточно представить только результаты трассировки активизируемых правил?
2.Почему формирование пояснений в системах, основанных на порождающих правилах, упрощается, если разделить используемые правила на группы по назначению?
3. Какую помощь в формировании пояснений может оказать использование фреймов? С какой целью фреймы комбинируются с порождающими правилами?
4. Ниже представлена новая версия программы Assault-weapon (оружие нападения), которая была рассмотрена в главе 11. В этой версии программа задает пользователю вопросы об определенном виде оружия, а затем формирует пояснение, почему данный тип оружия относится (или не относится) к классу "оружие нападения" в соответствии с имеющимися в программе правилами. Программа состоит из двух частей: в первой уточняются характеристики модели оружия, а во второй формируется пояснение.
I) Разработайте правила, которые не представлены в приведенном ниже тексте программы. Указания, какие именно правила требуется разработать, выделены в комментариях в тексте программы.
;; Объявления (deftemplate gun
(field name (type SYMBOL))
(field model (type SYMBOL))
(field class (type SYMBOL) (default NIL))
(field action (type SYMBOL) (default NIL))
(field caliber (type FLOAT) (default 0.0))
(field capacity (type INTEGER) (default 0))
(field features (type SYMBOL) (default NIL))
)
(deftemplate assault-weapon
(field make (type SYMBOL))
(field model (type SYMBOL))
)
;; ПРАВИЛА
;; Общий случай
;; Любая полуавтоматическая
;; винтовка (semi-automatic rifle)
;; или охотничье ружье (shotgun) с емкостью
;; магазина более 5 патронов.
(defrule Parti
(gun (make ?M) (model ?N)
(class ?CSrifle|shotgun) (action semi) (capacity ?X&:(> ?X 5))) =>
(assert (assault-weapon (make ?M) (model ?N)))
)
Разработайте правило make-and-model, которое будет запрашивать у пользователя необходимую информацию о модели оружия и формировать вектор gun в рабочей памяти. Используйте в качестве модели следующие правила, (defrule class-and-action
?G <- (gun (action NIL)) =>
(printout t crlf
"Please enter the class of gun" t crlf "
for example shotgun, rifle, pistol " t crlf "CLASS:" t crlf
;; "Введите класс оружия, "
;; "например, охотничье ружье, карабин,
;; "пистолет и т.д. "
;; "КЛАСС:"
(bind ?class (read)) (printout t crlf
"Please enter the action type of the gun" t crlf
"for example bolt, slide, lever, semi,
revolver ... " t crlf "ACTION:" t crlf
;; "Введите тип оружия, "
;; "например, с цилиндрическим затвором, со
;; скользящим затвором, с рычажным затвором,
;; полуавтоматический, револьвер ...
;; "ТИП:"
(bind ?action (read))
(modify ?G (class ?class) (action ?action)) )
;; Разработайте правило capacity, которое будет
;; запрашивать емкость магазина модели оружия.
;; В качестве прототипа используйте приведенное
;; ниже правило caliber, которое запрашивает у
;; пользователя значение калибра модели,
(defrule caliber
?G <- (gun (caliber 0.0)) =>
(printout t crlf
"Please enter the caliber of gun" t crlf "CALIBER:" t crlf
;; "Введите калибр оружия, "
;; "КАЛИБР:"
(modufy ?G (caliber (read))) )
;; Любая полуавтоматическая
;; винтовка (semi-automatic rifle)
;; или охотничье ружье (shotgun) с
;; перечисленными дополнительными признаками.
(defrule Part2
(gun (make ?M) (model ?N)
(class ?CSrifle|shotgun) (action semi)
(features ?F&flash-suppressor|barrel-shroud|night-scope)) =>
(assert (assault-weapon (make ?M) (model ?N))) )
;;Разработайте правило pistol-grip-shotgun,
;;которое будет относить любое охотничье ружье
;;с пистолетной рукояткой к категории
;;"оружие нападения".
;;Разработайте правила, которые будут
;;запрашивать у пользователя сведения о
;;дополнительных конструктивных характеристиках
;;модели ранее определенного класса. Например,
;;пистолет, как правило, не имеет защитного
;;кожуха на стволе, поэтому в наборе правил не
;;имеет смысла запрашивать эту характеристику,
;;если ранее определен класс модели pistol.
;;Особые случаи касаются тех моделей, которые
;;явно перечислены в законодательном акте
;;Модель Cobray Mil относится к категории
"оружие нападения", defrule cobray
(declare (salience 20))
(gun (make cobray) (model Mil)
(class pistol)) =>
(assert (assault-weapon (make cobray)
(model Mil))) )
;; Модель этого типа не относится
;; к категории "оружие нападения", (defrule rimfire
(declare (salience 10))
?except <- (gun (make ?M) (model ?N)
(class rifle) (caliber .22))
?mistake <- (assault-weapon) (model ?N))
=> :
(printout t crlf "The " ?M " " ?N
" is definitely not an assault weapon. " t crlf
;; "Модель " ?М " " ?N
;; "по определению в законе не относится к
;; категории "оружие нападения"."
(retract ?mistake)
(retract ?except) )
;;Разработайте аналогичное правило
;;slide-action, которое будет исключать
;;любое охотничье ружье со скользящим затвором
;;из категории "оружие нападения".
;;Правила вывода результатов.
;;Разработайте правило probably-is, которое
;;будет извещать пользователя о том, что
;;представленная им модель может быть отнесена
;;к категории "оружие нападения", согласно действующему
;;законодательному акту. В качестве прототипа
;;можете воспользоваться приведенным ниже
;;правилом, которое извещает пользователя об
;;обратном результате экспертизы.
(defrule probably-is-not (declare (salience -20))
(gun (make ?M) (model ?N)) (not
(assault-weapon (make ?M) (model ?N))) =>
(printout t crlf "The " ?M " " ?N
" is probably not an assault weapon. " t crlf
;; "Модель " ?M " " ?N
;; ", вероятно, не относится к
;; категории "оружие нападения"."
(halt) )
II) Теперь обратимся к той части программы, которая должна давать пользователю пояснения, на чем основывается сделанное заключение. Сначала нам понадобится зафиксировать в программе пояснения ко всем решениям, неявно представленным в правилах, а затем процитировать соответствующие статьи из законодательного акта. Представленный в нем перечень характеристик, на основании которых модель оружия относится к категории "оружие нападения", состоит из пяти разделов.
(1) Общее описание полуавтоматического огнестрельного оружия с большой емкостью магазина.
(2) Перечень дополнительных характеристик.
(3) "Любое охотничье ружье с пистолетной рукояткой".
(4) Перечень фирм-изготовителей и выпускаемых ими моделей, которые безоговорочно относятся к этой категории.
(5) Перечень характеристик, которые позволяют исключить рассматриваемую модель из категории "оружие нападения" даже в том случае, если она удовлетворяет требованиям, перечисленным в предыдущих разделах.
В случае положительного решения (рассматриваемая модель отнесена к категории "оружие нападения") в пояснении должно быть указано, какой из первых четырех разделов послужил основанием для такого заключения. Если же сделано отрицательное заключение, то оно также должно быть мотивировано в пояснении, опираясь на процитированные пять разделов.
Для того чтобы реализовать в программе формирование такого пояснения, придется добавить два новых поля в вектор assault-weapon:
(deftemplate assault-weapon
(field make (type SYMBOL))
(field model (type SYMBOL))
(field just (type SYMBOL) (default NIL))
(field part (type INTEGER) (default 0)) )
Правила, которые формируют этот вектор в новом варианте, должны заполнять эти атрибуты. Например:
(defrule Part)
(gun (make ?M) (model ?N)
(class ?C&rifle|shotgun) (action semi)
(capacity ?X&:(> ?X 5))) =>
(assert (assault-weapon (make ?M) (model ?N)
(just capacity) (part 1))) )
В этом правиле устанавливается, что причиной, по которой данная модель отнесена к категории "оружие нападения", является емкость ее магазина (capacity), причем сделано это на основании раздела 1 (part 1) законодательного акта.
Для завершения разработки программы нужно выполнить следующее.
Модифицировать правило Part2, воспользовавшись в качестве прототипа приведенным выше текстом правила Part1.
Модифицировать правило cobray таким образом, чтобы отразить в нем причину, по которой эта модель отнесена к категории "оружие нападения" (причиной является значение атрибута model).
Аналогично модифицировать и тот вариант правила pistol-grip-shotgun, который вы разработаете, выполняя первую часть этого упражнения.
Отредактировать правила rimf ire, slide-action и probably-is, включив в них манипуляции с атрибутами just и part.
При выводе поясняющих сообщений оператором printout воспользуйтесь шаблоном, в который требуется подставить значения переменных из атрибутов make, model, part и features. Шаблон должен выглядеть примерно так:
"The MAKE MODEL is (not) an assault weapon
under Part NUMBER of the definition because of the FEATURE"
"Изделие ИЗГОТОВИТЕЛЬ, МОДЕЛЬ (не) является оружием нападения на основании раздела НОМЕР определения вследствие ХАРАКТЕРИСТИК."
Прописными буквами в шаблоне выделены элементы, которые должны быть заменены значениями соответствующих атрибутов
ГЛАВА 17. Инструментальные средства разработки экспертных систем
17.1. Общая характеристика инструментальных средств для построения экспертных систем
17.2. Оболочки экспертных систем
17.3. Языки программирования высокого уровня
17.3.1. Языки описания порождающих правил
17.3.2. Объектно-ориентированные языки
17.3.3. Языки логического программирования экспертных систем
17.3.4. Многофункциональные программные среды
17.3.5. Дополнительные модули
17.4. Использование инструментальных средств
17.4.1. Характерные сложности и способы их избежать
17.4.2. Выбор подходящего инструментария для разработки экспертной системы
17.4.3. Практическое освоение инструментальных средств
17.4.4. Стиль программирования
17.5. Некоторые максимы разработки экспертных систем
Рекомендуемая литература
Упражнения
ГЛАВА 17. Инструментальные средства разработки экспертных систем
17.1. Общая характеристика инструментальных средств для построения экспертных систем
17.2. Оболочки экспертных систем
17.3. Языки программирования высокого уровня
17.4. Использование инструментальных средств
17.5. Некоторые максимы разработки экспертных систем
Рекомендуемая литература
Упражнения
Эту главу не следует рассматривать в качестве исчерпывающего справочника по доступным на сегодняшний день инструментальным средствам разработки экспертных систем. Представленный в ней материал скорее претендует на то, чтобы дать читателю общее представление о состоянии разработок в этой области и возможностях типовых средств подобного назначения. Хотя некоторые из рассматриваемых в этой главе программ и упоминались ранее, здесь мы старались систематизировать имеющиеся о них сведения, обращая основное внимание на использованную методику и способы практического применения.
Как и в предыдущих главах, при необходимости проиллюстрировать те или иные методы программирования мы пользуемся языком CLIPS, хотя вы встретите и несколько фрагментов программ на других языках. Более сложные и специализированные инструментальные средства, в частности системы с доской объявлений и системы обработки правдоподобия, будут детально рассмотрены в главах 18 и 19. В этой же главе мы представим общие тенденции в разработке и использовании инструментальных средств для построения экспертных систем.
17.1. Общая характеристика инструментальных средств для построения экспертных систем
При разработке практически всех инструментальных средств за основу принимается методология автоматизации проектирования на базе использования прототипов. По отношению к программному обеспечению термин прототип означает "работающую модель программы, которая функционально эквивалентна подмножеству конечного продукта" [Schach, 1993]. Идея состоит в том, чтобы на ранней стадии работы над проектом разработать упрощенную версию конечной программы, которая могла бы послужить доказательством продуктивности основных идей, положенных в основание проекта. Прототип должен быть способен решать какую-либо из нетривиальных задач, характерных для заданной области применения. На основе анализа опыта работы с прототипом разработчики могут уточнить требования к системе в целом и ее Основным функциональным характеристикам. Работоспособность прототипа может послужить очевидным доказательством возможности решения проблем с помощью создаваемой системы еще до того, как на ее разработку будут потрачены значительные средства.
После всестороннего анализа прототип откладывается в сторону и начинается разработка рабочей версии программы, которая должна решать весь комплекс задач, определенных в спецификации проекта. Процесс разработки экспертной системы, как правило, состоит из последовательности отдельных этапов, на которых наращиваются возможности системы, причем каждый из этапов подразделяется на фазы проектирования, реализации, компоновки и тестирования. В результате после каждого этапа наращивания возможностей в распоряжении пользователя имеется система, которая способна справляться со все более сложными вариантами проблемы.
Такая методика проектирования несколько отличается от методики разработки программ других видов. При создании большинства программных продуктов чаще используется другая модель процесса— сначала разрабатывается спецификация продукта, затем выполняется планирование, проектирование компонентов, их реализация, компоновка комплекса и тестирование конечного варианта. Тот факт, что при разработке экспертных систем есть возможность сначала построить и всесторонне испытать прототип, позволяет избежать множества переделок в процессе создания рабочей версии системы. Но технология последовательного наращивания функциональных возможностей таит в себе и проблему интеграции новых функций с реализованными в предыдущих вариантах. Инструментальные средства разработки экспертных систем и создавались, в первую очередь, с целью преодоления возникающих при этом сложностей на основе модульного представления знаний, которое мы уже обсуждали в главах 5-8.
По своему назначению и функциональным возможностям инструментальные программы, применяемые при проектировании экспертных систем, можно разделить на четыре достаточно больших категории.
(1) Оболочки экспертных систем (expert system shells). Системы этого типа создаются, как правило, на основе какой-нибудь экспертной системы, достаточно хорошо зарекомендовавшей себя на практике. При создании оболочки из системы-прототипа удаляются компоненты, слишком специфичные для области ее непосредственного применения, и оставляются те, которые не имеют узкой специализации. Примером может служить система EMYCIN, созданная на основе прошедшей длительную "обкатку" системы MYCIN. В EMYCIN сохранен интерпретатор и все базовые структуры данных — таблицы знаний и связанный с ними механизм индексации. Оболочка дополнена специальным языком, улучшающим читабельность программ, и средствами поддержки библиотеки типовых случаев и заключений, выполненных по ним экспертной системой. Дальнейшим развитием оболочки EMYCIN явились системы S.1 и М.4, в которых механизм построения цепочки обратных рассуждений, заимствованный в EMYCIN, объединен с фреймоподобной структурой данных и дополнительными средствами управления ходом рассуждений.
(2) Языки программирования высокого уровня. Инструментальные средства этой категории избавляют разработчика от необходимости углубляться в детали реализации системы — способы эффективного распределения памяти, низкоуровневые процедуры доступа и манипулирования данными. Одним из наиболее известных представителей таких языков является OPS5, о котором уже шла речь в главах 5, 14. Этот язык прост в изучении и предоставляет программисту гораздо более широкие возможности, чем типичные специализированные оболочки. Следует отметить, что большинство подобных языков так и не было доведено до уровня коммерческого продукта и представляет собой скорее инструмент для исследователей.
(3) Среда программирования, поддерживающая несколько парадигм (multiple-paradigm programming environment). Средства этой категории включают несколько программных модулей, что позволяет пользователю комбинировать в процессе разработки экспертной системы разные стили программирования. Среди первых проектов такого рода была исследовательская программа LOOP, которая допускала использование двух типов представления знаний: базирующегося на системе правил и объектно-ориентированного (см. об этой программе в главе 5). На основе этой архитектуры во второй половине 1980-х годов было разработано несколько коммерческих программных продуктов, из которых наибольшую известность получили KEE, KnowledgeCraft и ART. Эти программы предоставляют в распоряжение квалифицированного пользователя множество опций и для последующих разработок, таких как КАРРА и CLIPS, и стали своего рода стандартом. Однако освоить эти языки программистам далеко не так просто, как языки, отнесенные нами к предыдущей категории.
(4) Дополнительные модули. Средства этой категории представляют собой автономные программные модули, предназначенные для выполнения специфических задач в рамках выбранной архитектуры системы решения проблем. Хорошим примером здесь может служить упоминавшийся в главе 15 модуль работы с семантической сетью, использованный в системе VT. Этот модуль позволяет отслеживать связи между значениями ранее установленных и новых параметров проектирования в процессе работы над проектом. Подобные модули управления семантической сетью можно использовать для распространения внесенных изменений на все компоненты системы.
В последующих разделах этой главы мы более подробно рассмотрим перечисленные выше категории.
17.2. Оболочки экспертных систем
Класс программ, которые мы называем оболочкой экспертной системы, создавался с целью позволить непрограммистам воспользоваться результатами работы программистов, решавших аналогичные проблемы. Так, программа EMYCIN [van Melle, 1981] позволяет использовать архитектуру системы MYCIN в приложении к другим областям медицины (напомним, что программа MYCIN была ориентирована только на заболевания крови). На базе EMYCIN были разработаны экспертные системы как для медицины (например, система PUFF для диагностики легочных заболеваний), так и для других областей знаний, например программа структурного анализа SACON.
Совершенно очевидно, что оболочки являются программами, ориентированными на достаточно узкий класс задач, хотя и более широкий, чем та программа, на основе которой была создана та или иная оболочка. Автор системы EMYCIN Ван Мелле (van Melle) одним из первых подчеркнул, что оболочки отнюдь не являются универсальной архитектурой для решения проблем. Разработанная им система EMYCIN ориентирована на те проблемы диагностирования с большими объемами данных, которые поддаются решению с помощью дедуктивного подхода в предположении, что пространство диагностических категорий стационарно. Кленси (Clancey) назвал класс подобных проблем "проблемами эвристической классификации" (см. главы 11 и 12). Однако этот подход значительно меньше подходит для решения проблем конструирования, т.е. объединения отдельных элементов в единый комплекс с учетом заданных ограничений (см. о методах решения таких проблем в главах 14 и 15).
К сожалению, нельзя слишком доверять рекомендациям о возможности использования оболочки для решения конкретных проблем. Дело в том, что мы еще не имеем настолько четкого представления о классификации задач, решаемых экспертными системами, чтобы можно было точно представить, к какому именно классу следует отнести конкретную систему. Классификации задач, пригодных для решения экспертными системами, посвящено довольно много работ, из которых следует отметить сборник [Hayes-Roth et al, 1983] и статью [Chandrasekaran, 1984]. Может создаться впечатление, что отличить задачу классификации от задачи конструирования можно и "невооруженным глазом", но это впечатление обманчиво. Множество проблем допускает решение разными способами. Например, в том подходе к задаче диагностирования, который использован в системе INTRN1ST, применяются методы, свойственные решению задач конструирования (см. об этом в главе 13). Сложные проблемы зачастую требуют применения комбинированных методов, в которых просматриваются черты, свойственные обоим подходам.
Мы еще остановимся на общем подходе к выбору инструментальных средств для построения конкретных экспертных систем ниже, в разделе 17.4. Но если речь идет конкретно об оболочках, то уже сейчас нужно отметить, что большинство коммерческих продуктов этого типа подходит только для тех проблем, в которых пространство поиска невелико. Как правило, в них применяется метод исчерпывающего поиска с построением обратной цепочки вывода и ограниченными возможностями управления процессом. Но некоторые современные оболочки, например М.4, как утверждают их создатели, могут применяться для решения широкого круга задач, поскольку они поддерживают множество функций представления знаний и управления, включая и моделирование прямой цепочки логического вывода, процедуры, передачу сообщений и т.п.
Простота языков представления знаний, применяемых в большинстве оболочек, является, с одной стороны, достоинством, а с другой — недостатком такого рода систем. На это обратила внимание Эйкинс в критическом замечании по поводу реализации экспертной системы PUFF на базе оболочки EMYCIN [Aikins, 1983].
Использованный в EMYCIN формализм порождающих правил затрудняет разделение разных видов знаний— эвристических, управляющих, знаний об ожидаемых значениях параметров. Мы уже отмечали в главе 12. что способноть системы дифференцировать виды знаний рассматривается многими исследователями как одно из главных условий обеспечения ее "прозрачности" для пользователя
Недостаточная структурированность набора порождающих правил в EMYCIN также затрудняет и восприятие новых знаний, поскольку добавление в базу знаний нового правила требует внесения изменений в различные компоненты системы. Например, нужно вносить изменения в таблицы знаний, содержащие информацию о медицинских параметрах. Это одна из проблем, решением которой гордятся создатели системы TEIRESIAS (см. главу 10).
Основным методом формирования суждений в EMYCIN является построение обратной цепочки вывода. При этом используется множество правил мета- и объектного уровня. В результате очень сложно формировать исчерпывающее и понятное для пользователя пояснение. Как отмечал Кленси ([Clancey, 1983])те решения, которые принимаются на этапе программирования правил, в частности касающиеся порядка и количества выражений в антецедентной части, могут разительным образом повлиять на путь поиска в пространстве решений в процессе функционирования системы (см. об этом в главе 12).
Другое критическое замечание Эйкинс касается не столько конкретной системы PUFF или EMYCIN, сколько функциональных возможностей систем, базирующихся на правилах, в общем, а следовательно, и всех оболочек, в которых порождающие правила используются в качестве основного языка представления знаний. Значительная часть экс-пертности — это знания о типовых случаях, т.е. довольно часто встречающихся в предметной области. Эксперты легко распознают известные типовые случаи и способны без особого труда классифицировать их в терминах идеальных прототипов даже при наличии определенных "помех" или неполных данных. Они интуитивно различают подходящие случаю или необычные значения исходных данных и принимают адекватное решение о том, как поступить в дальнейшем при решении проблемы. Такие знания практически невозможно представить в экспертной системе, если пользоваться только правилами в форме "условие-действие". Для этого потребуется значительно более сложный формализм, который сведет на нет одно из главных достоинств использования порождающих правил в качестве основного средства принятия решений.
Последнее замечание по поводу использования оболочек касается механизма обработки неопределенности. Такие оболочки, как М.1, уже включают в себя определенный формальный механизм работы с неопределенностью, например основанный на использовании коэффициентов уверенности. Однако большинство, если не все использованные в оболочках механизмы такого рода, не согласуются с выводами теории вероятностей и обладают свойствами, которые с трудом поддаются анализу. Конечно, конкретному методу обработки неопределенности при решении конкретной задачи в данной предметной области можно дать прагматическое обоснование, как поступил, например, Шортлифф (Shortliffe) по отношению к схеме обработки коэффициентов уверенности в системе MYCIN. Но вряд ли оправданно распространять этот аппарат на другие области применения, встроив его в оболочку.
По сравнению с первыми разработками современные оболочки более гибкие, по крайней мере, в том, что без особого труда могут быть интегрированы в большинство операционных сред, доступных на рынке программного обеспечения, и оснащены достаточно развитыми средствами пользовательского интерфейса. Так, оболочка МЛ может функционировать под управлением любой из операционных систем, используемых в персональных компьютерах, подключаться к базам данных, иметь средства для включения фрагментов программного кода на языках С, Visual BASIC и Visual C++. Оболочка поддерживает индивидуальную настройку пользовательского интерфейса и возможность формирования пояснений при ответах на вопрос "почему" в том же стиле, что и система-прародитель MYCIN
17.3. Языки программирования высокого уровня
Языки высокого уровня являются в руках опытного программиста прекрасным средством быстрого создания прототипа экспертной системы, позволяют обеспечить гибкость процесса разработки при одновременном снижении материальных затрат и сокращении сроков выполнения проекта. Как правило, среда разработки таких языков обеспечивает совмещение интерфейса разработки и времени выполнения, что позволяет совместить вставку, редактирование и тестирование фрагментов программного кода. Но пользовательский интерфейс такой среды уступает интерфейсу оболочек по части "дружественности", что, правда, не мешает опытному программисту быстро ее освоить.
Языки описания порождающих правил, объектно-ориентированные языки и процедурные дедуктивные системы предоставляют проектировщику экспертных систем значительно большую свободу действий, чем оболочки. Особенно это касается программирования процедур управления и обработки неопределенности. Как отмечалось выше, обычно оболочка имеет встроенный режим управления и методы обработки неопределенности, которые не могут быть затем изменены в процессе построения на ее основе конкретной экспертной системы. Та гибкость, которую предоставляют программисту языки высокого уровня, особенно важна при создании экспериментальных систем, в которых заранее выбрать оптимальный режим управления вряд ли возможно
17.3.1. Языки описания порождающих правил
Но, естественно, возможности языков высокого уровня также не беспредельны — каждый из них имеет свои ограничения. Например, в языке OPS5 возможности динамической памяти ограничены размещением векторов в рабочей памяти, что не позволяет строить в ней рекурсивные структуры данных, такие как графы или деревья. При разработке системы MORE (о ней речь шла в главе 12) из-за этого возникли серьезные сложности [Kahn, 1988]. Некоторые типы структур управления ходом выполнения, например рекурсивные и итерационные циклы, также с трудом реализуются в этом языке. В общем, это та цена, которую приходится платить за относительную простоту программного кода на языке OPS5 и эффективность его выполнения.
В ранних моделях систем, основанных на порождающих правилах, до 90% времени работы уходило на выполнение операций сопоставления условий. Но позднее Форджи обратил внимание на возможные источники низкой эффективности такого упрощенного подхода [Forgy, 1982]. Алгоритм сопоставления RETE, предложенный Форджи и реализованный в языках описания порождающих правил семейства OPS, базируется на двух наблюдениях.
В левых частях порождающих правил, которые размещаются в рабочей памяти, часто встречаются повторяющиеся условия. Если одно и то же условие встречалось в N правилах, то при прежнем упрощенном подходе выполнялось N операций сопоставления. Это пример внутрицикловой итерации (within-cycle iteration).
Простейший подход при сопоставлении условий предполагает просмотр в каждом цикле всех элементов рабочей памяти, хотя содержимое рабочей памяти от цикла к циклу изменяется очень мало. Форджи назвал это межцикловой итерацией (between-cycle iteration).
Предложенный Форджи алгоритм значительно снижает количество внутрицикловых итераций за счет использования сети сортировки, имеющей древовидную структуру. Выражения в левой части порождающих правил компилируются и включаются в эту сеть, а алгоритм сопоставления довольно просто определяет конфликтующее множество, просматривая состояние сети в текущем цикле. Количество межцикловых итераций сокращается за счет обработки множества лексем, которые являются индикаторами удовлетворения условий, размещенных в рабочей памяти. Это множество лексем отображает изменения, происходящие в рабочей памяти от цикла к циклу, и таким образом позволяет выявить те условия, которые подлежат проверке. Поскольку никаких других процессов управления, кроме цикла распознавание-действие, в системе не существует, то обработать полученное в результате конфликтующее множество не представляет особого труда. Механизм разрешения конфликтов выполняет это, не обращая внимания на другие аспекты текущего контекста вычислений.
Совершенно очевидно, что попытка использовать рекурсивные структуры данных потребует серьезного усложнения описанного процесса обработки правил. Точно так же и изменение режима управления приведет к тому, что механизм разрешения конфликтов вынужден будет анализировать дополнительную информацию. Разработчики языков, подобных OPS, всегда вынуждены искать компромисс между мощностью выразительных средств языка и эффективностью выполнения программного кода. До сих пор в среде исследователей предметом оживленных дискуссий является вопрос о том, удалось ли разработчикам OPS5 найти такой компромисс. Разработанные позже языки КЕЕ, КАРРА и CLIPS унаследовали от OPS5 синтаксис и механизм активизации правил. Все эти языки используют различные версии алгоритма RETE при формировании множества конфликтующих правил.
Преодоление недостатков программирования порождающих правил лежит не на пути усложнения существующих языков программирования, а скорее на пути объединения их с другими парадигмами программирования, позволяющими использовать рекурсивные структуры данных и управления. Примером такого объединения может служить комбинирование порождающих правил и фреймов, что позволяет сопоставлять условия, специфицированные в правилах, с содержимым слотов фреймов (см. главу 13). Для решения проблем управления в последнее время все чаще используется включение наборов правил в более мощную.вычислительную среду, которая позволяет работать со списками заявок и с множеством источников знаний (подробнее об этом — в главе 18).
17.3.2. Объектно-ориентированные языки
В главе 12 мы уже обращали ваше внимание на то, что формат правил хорошо согласуется с представлением знаний в форме "при выполнении условий Сь ..., С„ выполнить действие А", но менее подходит для описания сложных объектов и отношений между ними. Языки объектно-ориентированного программирования предоставляют в распоряжение программиста альтернативную программную среду для организации знаний в терминах декларативного представления объектов предметной области. Все, связанное с процедурной стороной решения проблем, распределяется между этими объектами, которые в таком случае располагают собственными процедурами и могут общаться друг с другом посредством протоколов передачи сообщений.
Другим приятным аспектом объектно-ориентированного программирования является возможность использования таких стилей представления знаний, которые не встречаются в исчислении предикатов и в порождающих правилах. Вместо "размывания" знаний об объекте предметной области между множеством правил или аксиом, на которые они ссылаются, эти знания концентрируются в едином месте — в программном описании объекта. Эта концентрация является виртуальной в том смысле, что нет необходимости, чтобы вся информация об объекте предметной области хранилась в соответствующем ему программном объекте, но любая команда или запрос к этому объекту может быть реализована только через посылку сообщения этому объекту.
В реальном мире вещей существует множество систем, в которых обмен энергией или информацией может быть представлен через обмен сообщениями между их компьютерными представлениями, и такая связь с технологией моделирования является очень важным достоинством данного подхода (см., например, [McArthur et al, 1986]). Не вызывает сомнений, что моделирование является одним из мощнейших средств решения проблем и что, рассматривая процесс логических рассуждений в контексте сложной системы, его иногда понять значительно легче, чем в контексте применения правил. Объектно-ориентированное программирование интегрирует символические вычисления в операционную среду, базирующуюся на средствах графического интерфейса, — меню, пиктограммы и т.п. Хотя само по себе оснащение экспертной системы этими средствами и не решает проблему ее прозрачности для пользователя, в руках умелого программиста они позволяют лучше представить пользователю процессы, происходящие в системе (см., например, [Richer andClancey, 1985]).
Основная сложность в использовании средств объектно-ориентированного программирования — уяснить для себя, что именно должен представлять программный объект по отношению к предметной области. В ранних версиях объектно-ориентированных языков, которые были предназначены в основном для разработки программ моделирования, такая проблема не возникала — программные объекты представляли объекты моделируемой системы. Например, при моделировании производственной линии отдельные программные объекты представляли те или иные механизмы этой линии, а сообщения между программными объектами — информационные, энергетические и материальные потоки. Задача программиста серьезно облегчалась тем, что существовало достаточно очевидное соответствие между программными и реальными объектами.
Но для того чтобы внедрить объектно-ориентированный стиль в проектирование экспертных систем, нужно задуматься над тем, как соотнести программные объекты с абстрактными понятиями и категориями предметной области. Объекты должны представлять факты и цели, наборы правил или отдельные гипотезы. Поэтому далеко не очевидно, какими сообщениями должны обмениваться такие объекты и какой смысл должен вкладываться в эти сообщения.
Многое зависит от того, на каком уровне абстракции будет использоваться объектно-ориентированный механизм. Если объекты представляют собой низкоуровневую реализацию определенной схемы формирования суждений, то отпадает необходимость в использовании каких бы то ни было эпистемологических последовательностей. Если же объекты будут видимы и для эксперта в процессе разработки и совершенствования системы, и для пользователя во время эксплуатации системы, то схема отображения понятий и категорий на программные объекты должна быть тщательно продумана
17.3.3. Языки логического программирования экспертных систем
Критически оценивая первый опыт применения инструментальных средств типа оболочек при проектировании экспертных систем, в частности опыт использования EMYCIN, многие исследователи полагали, что более перспективным является альтернативный подход, основанный на логическом программировании (см., например, [Kowalski, 1982]). Например, предполагалось, что порождающие экспертные системы, аналогичные MYCIN, могут быть довольно просто реализованы на языке PROLOG [Clark and McCabe, 1982]. Правила можно представить в виде фраз Хорна (см. об этом в главе 8), в которых головной (позитивный) литерал соответствует заключению, а прочие (негативные) литералы будут соответствовать условиям.
Встроенный в PROLOG режим управления приблизительно соответствует стратегии обратного логического вывода, которая используется в системах, подобных MYCIN. Таблицы знаний и другие данные можно представить с помощью утверждений. Рекурсивные структуры данных — графы и деревья — можно организовать с помощью фраз языка PROLOG, которые содержат комплексные термы. Языковые средства PROLOG позволят программисту разработать собственный механизм обработки неопределенности, причем не исключается и использование коэффициентов уверенности.
С практической точки зрения, пользуясь языком PROLOG, программист в качестве "бесплатного приложения" получает в свое распоряжение следующие возможности:
индексированную базу данных фраз, которые можно использовать для представления правил, процедур или данных;
универсальный механизм сопоставления, который позволяет выполнять сопоставление данных и шаблонов, включающих переменные, и возвращать подстановку, которая может обеспечить их совпадение;
стратегию управления (поиск в глубину — depth-first search), основанную на правилах нисходящего поиска (фразы, которые размещены в базе данных ближе к "голове", обрабатываются первыми) и вычислении слева направо (подцели обрабатываются в том порядке, в котором они перечислены в списке).
Действительно, дедуктивную порождающую систему довольно ПРОСТО эмулировать на языке PROLOG. Можно без особого труда разработать и простой интерпретатор, реализующий стратегию построения прямой цепочки вывода. Модификация рабочей памяти выполняется операторами assert и retract, которые добавляют или удаляют формулы из базы данных. Вы уже знаете из главы 11, как можно организовать локальное управление ходом процесса в системе, основанной на фреймах, как организовать обработку значений по умолчанию и исключений, хотя эти методы и не вписываются в стандартную логику.
Успешный опыт применения идей логического программирования, в частности создание программы МЕСНО (см. главу 11), продемонстрировал ряд явных отклонений от синтаксиса исчисления предикатов первого порядка и его процедурной интерпретации в стандартной версии PROLOG. Некоторые семантические и синтаксические ограничения в программах МЕСНО и PLANNER до сих пор не преодолены в системах, базирующихся на языках логического программирования.
17.3.4. Многофункциональные программные среды
Многофункциональные программные среды позволяют опытному программисту экспериментировать при решении новых классов проблем, выбирая подходящие сочетания различных методов, представленных в имеющемся модульном наборе. Поскольку не существует единственного универсального языка представления знаний для произвольной экспертной системы, у разработчиков возникает желание объединить несколько различных схем представления, особенно на этапе создания прототипа. Хотя исчерпывающей теории таких гибридных систем и не существует, эксперименты с разными схемами представления и логического вывода показали, что каждая из них имеет свои слабые стороны. Поэтому понятно желание объединить разные методики таким образом, чтобы достоинства одних компенсировали слабости других.
Мы уже не раз обращали ваше внимание на то, что порождающие правила позволяют представить в программе эмпирически выявленные связи между условиями и действиями, между наблюдениями и гипотезами, но они значительно хуже подходят для представления отношений между объектами предметной области, включая и такие важнейшие, как отношения множество/элемент или множество/подмножество. Структурированные объекты, например фреймы, оказываются более удобным средством для хранения и манипулирования описаниями объектов предметной области, но применение таких знаний требует включения в программу фрагментов программного кода (например, на языке LISP), которые затем трудно анализировать. Рациональное зерно в первых попытках свести вместе стили, основанные на правилах и фреймах, состояло в том, чтобы объединить способность представлять объекты, характерные для фреймов, с возможностями связывать условия и действия с помощью порождающих правил.
Одной из первых многофункциональных сред искусственного интеллекта является LOOPS [Bobrow and Steflk, 1983], в которой в рамках единой архитектуры обмена сообщениями были объединены четыре парадигмы программирования, перечисленные ниже.
Процедурно-ориентированное программирование. Эта парадигма была представлена языком LISP, в котором активным компонентом являются процедуры, а пассивным — данные, несмотря на то, что в LISP процедуры сами по себе также являются данными, поскольку имеют вид списков. В рамках единой среды процедуры могут быть использованы для обработки внешних данных, в частности изменения значений общедоступных переменных.
Программирование, ориентированное на правила. Эта парадигма аналогична предыдущей, но роль процедур играют правила "условие-действие". В среде LOOPS наборы правил сами по себе являются объектами, которые можно рекурсивно вкладывать один в другой. Таким образом, часть "действие" одного правила, в свою очередь, может активизировать подчиненный набор правил. С множествами правил связываются управляющие компоненты, с помощью которых в простейшей форме выполняется разрешение конфликтов.
Объектно-ориентированное программирование. Структурированные объекты обладают свойствами и процедур, и данных, причем побочные эффекты обычно локализуются в пределах объекта. Обработка поступающих сообщений приводит к передаче данных или изменению их значений, но все манипуляции данными выполняются под управлением того компонента, который обратился к объекту. При этом вызывающий объект совершенно не интересует, как хранятся данные и как они модифицируются внутри объекта.
Программирование, ориентированное на данные. Доступ к данным и обновление данных запускает определенные процедуры, причем не имеет значения, почему изменен компонент данных, — то ли это результат побочного эффекта, то ли результат действия других процедур. С переменными, в которых хранятся значения данных, связываются определенные процедуры, подобно тому, как это делается в слотах фрейма, причем такие переменные часто называют активными величинами. В таких приложениях, как моделирование, этот стиль программирования оказывается довольно продуктивным, поскольку позволяет распространить эффект изменения какого-либо компонента на прочие, с ним связанные.
В рамках основной объектно-ориентированной парадигмы модули среды, поддерживающие разные стили программирования, можно комбинировать. Обычно условия в порождающих правилах и логические фразы связываются со значениями слотов структурированных объектов, а правила модифицируют значения этих слотов. Именно такой стиль объединения парадигм в настоящее время реализован в языке CLIPS.
В системах КЕЕ и LOOPS поведение объектов описывается в терминах множества порождающих правил, как это сделала Эйкинс (Aikins) в системе CENTAUR (см. об этой системе в главах 13 и 16). В средах КЕЕ и Knowledge Craft к перечисленным выше парадигмам добавлено и логическое программирование в стиле языка PROLOG. Новая версия КЕЕ, известная под названием КАРРА-РС, предоставляет в распоряжение программиста еще более широкий набор стилей для комбинирования правил, объектов и процедур.
17.1. CUPS как многофункциональная среда программирования
Кроме поддержки интерпретатора порождающих правил, описанного в главе 5, CLIPS обладает следующими функциональными возможностями:
для определения стандартных функций используется синтаксис, подобный LISP (сведения о LISP вы найдете в главе4);
предоставляет в распоряжение разработчика родовые функции, аналогичные мультиметодам CLOS (см. главу 7);
располагает встроенным объектно-ориентированным языком COOL, который, в отличие от CLOS, включает и средства поддержки обмена сообщениями.
Обращение к стандартным функциям допускается включать в правую часть правил и в этом случае они выполняются так, как если бы являлись компонентом действий, специфицированных в правиле. Функции вызываются либо с целью получить побочный эффект, либо для использования явно возвращаемого функцией результата, который может быть сохранен с помощью оператора присваивания. Для работы с переменными в этом случае используется тот же синтаксис, что и в языке описания правил. Например, можно определить функцию between (X, Y, 2), оперирующую с целыми переменными. Эта функция будет проверять выполнение неравенств X[Y[Z:
(deffunction between (?lb ?value ?ub)
(and (<= ?lb ?value) (<=?value ?ub))),
Родовые функций (generic function) в CLIPS играют ту же роль, что и перегружаемые операторы в языке C++. Они обеспечивают возможность выполнять обработку разными методами последовательностей данных различного типа. Например, для конкатенации двух строковых значений оператором + можно следующим образом перегрузить этот оператор:
(defmethod + ((?a STRING) (?b STRING)) (art-cat ?a ?b)}
Тогда результатом вычисления выражения
(+ "dog" "fish") будет "dogfish".
В такой функции можно смешивать ограниченные и неограниченные параметры, причем ограничение может касаться типов данных на произвольном уровне обобщения, например числовых данных, целых, положительных целых чисел и т.д.
Вычисление родовых функций выполняется под "надзором" родового алгоритма диспетчирования (generic dispatch algorithm), который формирует индексированный список подходящих методов. Методы из этого списка затем вызываются соответственно уровню ограничений, указанному для параметров при обращении к функции. Алгоритм также принимает во внимание любые управляющие программные конструкции, представленные явно в тексте программы метода, например call-next-method или override-next-method.
Механизм передачи сообщений реализован по тому же способу, что и в языках SmallTalk и LOOPS, и требует, чтобы программист разработал свой обработчик сообщений для каждого отдельного класса. Диспетчер сообщений работает так? же, как в исполняющей системе языка CLOS, и различает обработчики типов primary, around, before и after.
В программе на языке CLIPS можно вызывать и функции, написанные на языке С, хотя это и выполняется несколько необычно. Исполняющая система CLIPS может выступать в качестве внедренного приложения, т.е. программа на CLIPS может быть скомпилирована и скомпонована с программой на языке С, которая будет вызывать CLIPS-фрагменты как подпрограммы. Это позволяет внедрять функции искусственного интеллекта в компоненты больших программных комплексов
17.3.5. Дополнительные модули
Под дополнительными модулями понимаются те полезные программы, которые можно выполнять вместе с приложением. Как правило, такие программы реализуют некоторые специальные функции, как бы "снимая их с полки", причем для обращения к таким функциям не требуется что-либо программировать в основном приложении или заниматься его индивидуальной настройкой. Одним из примеров такого рода дополнительного модуля может служить программный пакет Simkit из комплекта среды КЕЕ. Этот пакет позволяет оснастить экспертную систему методами моделирования.
Другой функцией, которая поддерживается дополнительными модулями сред КЕЕ и ART, является механизм обработки множества различных контекстов логических рассуждений. В первом приближении можно считать, что контексты формируются теми ветвями в пространстве поиска, которые допускают использование более чем одного оператора. Рассмотрим представленный ниже сценарий, в котором имеются два правила, в каждом из которых условная часть удовлетворяется в текущем контексте рассуждений.
[Правило 1]
ЕСЛИ: сегодня рабочий день И
нет признаков недомогания, ТО: посетить занятия по информатике.
[Правило 2]
ЕСЛИ: сегодня рабочий день И
погода прекрасна, ТО: покататься на яхте.
В большинстве систем, основанных на порождающих правилах, выбор того единственного правила, которое будет активизировано, зависит от реализуемой стратегии разрешения конфликтов. Но в некоторых приложениях предпочтительным вариантом будет разделить текущий контекст на два разных, в одном из которых будет активизировано правило 1, а в другом — правило 2 (рис. 17.1). В каждом из этих контекстов будет сделано разное заключение, однако можно так организовать процесс, чтобы в каждый контекст была включена и информация из родительского контекста. Тогда в обоих контекстах будет учитываться, что сегодня понедельник и за окном прекрасная погода.
Теперь можно раздельно обрабатывать каждый контекст, причем в процессе дальнейшей обработки не исключено и аналогичное повторное разделение контекстов. В результате будет сформировано несколько вариантов решения проблемы.
Но можно в процессе обработки попасть в такую ситуацию, которая расценивается как неудача процесса вывода, например нарушение исходных ограничений. В нашем примере такой неудачей может быть заключение о том, что экзамен по информатике будет провален вследствие выполнения правила
[Правило 3]
ЕСЛИ: не посещать занятия по информатике,
ТО: экзамен по информатике будет провален
Получение такого заключения должно было бы привести к тому, что линию рассуждений, порожденную, правилом 2, следует исключить из рассмотрения. Говорят, что соответствующий контекст отравлен. Как правило, удаляется вся цепочка рассуждений, вплоть до последнего "размножения" контекстов. Таким образом, контексты, выделенные утолщенными прямоугольниками на рис. 17.1, должны быть исключены из рассмотрения, и останется только одна цепочка, в соответствии с которой будет сделан вывод о необходимости посетить занятия по информатике, несмотря на все соблазны.
Таким образом, множество контекстов соответствует альтернативным вариантам решений или альтернативным предположениям на разных стадиях процесса логического вывода. Проблема обработки множества предположений и зависимостей между ними достаточна сложна и выделена в отдельное направление исследований, получившее наименование обработки правдоподобия (truth maintenance) или обработки причинности (reason maintenance). Детальнее мы остановимся на этом вопросе в главе 19, где будут рассмотрены альтернативные варианты организации вычислений.
Рис. 17.1. Пример множества контекстов
Тенденция использования дополнительных модулей будет скорее всего развиваться, поскольку пользователи экспертных систем часто нуждаются в разного рода дополнительных функциональных возможностях, специфичных для конкретного приложения, а также в возможности интегрировать экспертную систему с программными продуктами других классов. На практике экспертная система часто используется вместе в базой данных или системой управления движением робота, получает информацию от систем обработки сигналов или пакетов статистической обработки.
Мы постарались дать вам общее представление о возможностях инструментальных средств, применяемых при разработке и эксплуатации экспертных систем, не вдаваясь в подробности реализации разных моделей таких средств. В следующем разделе основное внимание будет уделено выбору подходящих средств, обучению методике работы с ними и внедрению этих средств в практику проектирования систем. Вы увидите, что каждая из этих фаз сопряжена со множеством проблем, но некоторых из них при рациональном подходе можно избежать.
17.2. Логический вывод в разных контекстах
Ниже приведен программный код на языке CLIPS, в котором реализована описанная выше стратегия работы со множеством контекстов.
;; ШАБЛОНЫ
;; Fact представляет собой субъект с определенными
;; свойствами.
;; Поле "world" несет информацию о контексте,
(deftemplate fact
(field subj (type SYMBOL))
(field attr (type SYMBOL))
(field world (type INTEGER))
)
;; Act представляет действие с объектом.
;; Поле "world" несет информацию о контексте.
(deftemplate act
(field action (type SYMBOL))
(field object (type SYMBOL))
(field world (type INTEGER))
)
;; Context имеет статус либо OK ,
;; либо NG (no good - плохой).
(def template context
(field id (type INTEGER))
(field status (type SYMBOL))
)
;; Модель мира в исходном состоянии.
(def facts model
(context (id 1) (status OK))
(fact (subj weather) (attr sunny) (world 1))
)
; ; ПРАВИЛА
; ; Если дождя нет,
;; создать новый контекст, в котором можно
;; пропустить занятия.
(def rule skip
(fact (subj weather) (attr ?W&~rainy) (world ?C)) =>
(assert (act (action skip) (object class)
(world (+ ?C 1)))) (assert (context
((id (+ ?C 1)) (status OK)))
)
;; Если пропустить занятия,
;; то на экзамене вас ждет провал.
(defrule fail
(act (action skip) (object class) (world ?W)) =>
(assert (act (action fail) (object exam) (world (?W)))
)
;; Если контекст содержит действие fail,
;; пометить его маркером NG. (defrule poison
(act (action fail) (world ?W)) .
?C <- (context (id ?W) (status OK)) =>
(modify ?C (status NG))
)
Как только контекст будет помечен маркером NG, с ним можно будет выполнять операции, предусмотренные для отравленного контекста, например удалить все связанные с ним факты и действия (см. упр. 8 в конце главы).
17.4. Использование инструментальных средств
Хотя на этапе внедрения экспертной системы возникает очень много сложностей, до сих пор не предпринималось попытки их каким-либо образом систематизировать. В этом разделе мы ставили перед собой задачу познакомить пользователя с проблемами, наиболее часто возникающими при внедрении, и тем, как их избежать, как выбрать подходящие инструментальные средства для инженерии знаний, как организовать освоение и использование этих средств на практике. Возможно, приведенный ниже материал покажется вам в определенной мере противоречивым, но мы старались представить в нем как можно более широкий спектр существующих на сей счет мнений
17.4.1. Характерные сложности и способы их избежать
В своей книге Уотерман перечисляет следующие "ловушки", поджидающие разработчика экспертной системы на этапе внедрения, и дает рекомендации, как их избежать [Waterman, 1986, Chapter 19].
Знания, касающиеся предметной области, слишком тесно переплетены с остальной частью программы. В частности, невозможно разделить эти знания и знания общего применения, касающиеся способов поиска в пространстве решений. Уотерман предполагает, что этого можно достичь, положив в основу организации базы знаний набор правил, хотя из замечаний, сделанных Кленси и Эйкинс, следует, что такая организация отнюдь не гарантирует достижение ожидаемого результата.
Та база знаний, которая сформировалась после извлечения и представления сотен правил в процессе опроса экспертов, может оказаться все-таки настолько неполной, что не позволит решить и простую задачу, поскольку в ней отсутствуют фундаментальные концепты предметной области или эти концепты представлены с ошибками. Уотерман рекомендует последовательно наращивать объем базы знаний, причем начинать с фундаментальных понятий. Это позволит еще на ранних стадиях разработки обнаружить указанную проблему. Он советует выполнять тестирование на каждом этапе разработки, используя для этого подходящие инструментальные средства инженерии знаний.
Среда разработки не располагает встроенными средствами формирования функций пояснения экспертной системы, а добавление таких функций в уже спроектированную систему — задача не из легких. Уотерман советует позаботиться о прозрачности экспертной системы с первых же шагов ее разработки. Это очень ценный совет, поскольку без хорошего "окна", через которое можно заглянуть в "машинный зал" программы, даже ее создатель не сможет понять, что же она на самом деле делает.
Система содержит чрезмерно большое количество слишком специфических правил. Это, во-первых, приводит в замедлению работы системы, а во-вторых, затрудняет управление ею. Уотерман рекомендует объединять, где только возможно, мелкие правила в более общие. Как мы видели в разделе 17.2, это не что иное, как стремление найти компромисс между более мощными правилами и правилами, более понятными.
В следующих трех разделах мы остановимся на важных и сложных вопросах, которые следуют из представленного ниже перечня.
Как подобрать подходящий инструментарий для проектирования экспертной системы?
Насколько в действительности такие средства просты в обращении?
Что такое "хороший стиль программирования" в выбранной среде разработки?
Ответы на эти вопросы оттодь не очевидны, но любой разработчик экспертных систем не избежит необходимости отыскать их. Тот поход, которым я воспользовался при поиске этих ответов, базируется частично на авторитетном мнении ведущих специалистов в этой области, а частично на анализе имеющегося опыта проектирования. В конце главы будут приведены некоторые полезные рекомендации, почерпнутые из литературы.
17.4.2. Выбор подходящего инструментария для разработки экспертной системы
В работе [Hayes-Roth et al, 1983, Chapter 1] собраны рекомендации по выбору подходящих инструментальных средств построения экспертной системы. В основу рекомендаций положено сопоставление характеристик задач, решаемых проектируемой экспертной системой, и необходимых функциональных возможностей инструментального комплекса.
Общность. Выбрать инструмент со степенью общности, не превышающей той, которая необходима для решения данной задачи. Например, если для данной задачи сложный механизм управления не является жизненно необходимым, использовать его не только расточительно, но и нежелательно.
Выбор. Выбор инструментария должен определяться в первую очередь характеристиками задачи, решаемой экспертной системой, а не другими привходящими обстоятельствами, например тем, что какой-то инструмент уже есть под рукой или знаком вам лучше остальных. Авторы цитируемой работы затем развили свою мысль, опираясь на классификацию экспертных систем, о которой речь пойдет ниже.
Быстрота. Если успех проекта зависит от срока разработки, то следует выбирать инструментальную среду со встроенными средствами формирования пояснений и развитым пользовательским интерфейсом. Разработка интерфейса — одна из наиболее трудоемких стадий проектирования системы, и чем большую часть этой работы можно переложить на среду разработки, тем быстрее будет завершен проект.
Испытание. Постарайтесь как можно быстрее провести испытания новой для вас инструментальной среды. Без сомнения, это полезный совет, однако открытым остается вопрос о том, как определить степень совершенства инструмента по результатам испытаний.
Важнейшим для выбора инструментальной среды является вопрос о способе определения характеристик проблемы, решаемой проектируемой экспертной системой. Этот вопрос обсуждается в работе [Stefik et al, 1983], где предлагается схема анализа, основанная на свойствах пространства поиска решения. Я позволил себе несколько обобщить предлагаемые авторами работы категории проблем и свел 11 Категорий к четырем, хотя основные принципы классификации остались прежними.
(1) Малое пространство решений, надежные данные и знания. Предполагается, что количество альтернатив, которые следует принимать во внимание при поиске решения, невелико и что все данные достоверны, а истинность правил не вызывает сомнений. В таком случае возможно выполнять исчерпывающий поиск в пространстве решений и при необходимости организовать возврат с прослеживанием в обратном порядке. Для решения проблем этой группы можно воспользоваться готовыми решениями, т.е. ранее созданной оболочкой на базе экспертной системы, решавшей аналогичную проблему в другой предметной области. Распространено мнение, что такой подход позволяет получить удовлетворительное, а не оптимальное решение проблемы, т.е. достаточно хорошее, а не лучшее решение. Учтите, что попытка отыскать оптимальное решение неизбежно сопряжена с перебором нескольких вариантов, что таит в себе опасность "комбинаторного взрыва".
(2) Ненадежные данные или знания. Если данные и/или знания ненадежны, т.е. существует опасность, что вводимые в систему данные недостоверны, а правила в базе знаний неоднозначны, то в экспертной системе нужно комбинировать информацию от нескольких источников и использовать в какой-либо форме логику неточных рассуждений. Авторы цитируемой работы весьма мудро решили воздержаться от конкретных рекомендаций, какой именно формализм неточных рассуждений следует выбрать, но круг кандидатов в любом случае довольно ограничен — формализм коэффициентов уверенности (см. главу 3) или нечеткой логики (см. главу 9). Обсуждение альтернативных методов, таких как использование функций доверия (belief function) и обновляемых оценок по Байесу (Bayesian belief updating), мы отложим до главы 21.
(3) Большое, но факторизуемое пространство решений. В литературе можно найти два варианта толкования термина "факторизуемый". Пространство поиска можно назвать факторизуемым, если существует "правило исключения", которое помогает уменьшить размер пространства на ранней стадии решения проблемы [Stefik et al, 1983, p. 99]. Есть и другое определение — пространство поиска является факторизуемым, если возможно разделить его на несколько независимых подпространств, которые можно обрабатывать по отдельности, причем для разных подпространств могут быть использованы и разные множества правил или отдельные подмножества одного и того же множества правил [Nilsson, 1980, р. 37]. Обычно такое разбиение выполняется на уровне решаемой проблемы, т.е. большая общая проблема разбивается на несколько более мелких. Успех в достижении главной цели, таким образом, оценивается по совокупности успехов в достижении более или менее независимых подцелей. .Если система потерпит неудачу в достижении одной из подцелей, то это будет означать неудачу и решения проблемы в целом. В любом случае для решения проблем такого класса наиболее предпочтительным является метод порождения и проверки (generate-and-test). Этот метод позволяет "обрезать" ветви, уводящие нас от решения, и разделить большое пространство решений на подпространства.
(4) Большое нефакторизуемое пространство решений. Пространство решений может оказаться и нефакторизуемым, в каком бы смысле мы не трактовали этот термин. Очень часто оказывается, что проблема проектирования допускает выработку частного решения какого-либо компонента только в контексте всего проекта. При сборке головоломки нельзя предсказать, найдено ли верное решение, пока последний элемент мозаики не станет на свое место. Общий подход к работе в большом пространстве поиска состоит в том, чтобы последовательно рассматривать его на разных уровнях абстракции, т.е. использовать варианты описания пространства с разным уровнем учета деталей. Решение проблемы таким методом часто называют нисходящим уточнением (top-down refinement) (см. об этом в главе 14). Применение метода нисходящего уточнения требует исключить, по возможности, обратное прослеживание между уровнями, реализация которого требует значительных вычислительных ресурсов. Но это срабатывает только в случае, если между уровнями нет тесного взаимодействия. Как было показано в главе 15, эффективной стратегией решения такого рода задач является стратегия наименьшего принуждения (least commitment), подкрепленная адекватным механизмом разрешения конфликтов.
В книге [Hayes-Roth et al, 1983] проблема выбора инструментальных средств представлена в терминах схемы рис. 17.2. Выяснив характеристики проблемы, решаемой проектируемой экспертной системой, можно определиться со свойствами пространства решений, которые перечислены выше. Затем они рассматриваются совместно с предполагаемыми характеристиками разрабатываемой системы — характеристиками порождающих правил, прямой цепочки вывода или возможностями формирования пояснений, — и вырабатываются желаемые характеристики инструментальной среды. Последние и позволяют подобрать нужную модель инструментальной среды. Нужно сказать, что все это прекрасно выглядит на картинке, но очень сложно реализуется на практике, хотя вряд ли кто-нибудь будет спорить с тем, что такой подход более логичен, чем какой-либо другой. Как показывает практика, большинство разработчиков явно или неявно следует именно такому подходу при создании экспертных систем.
Рис. 17.2. Схема выбора инструментальной среды проектирования экспертной системы
Например, разработчики экспертной системы COMPASS, описанной в главе 10, следующим образом аргументировали свое решение выбрать для выполнения проекта инструментальную среду КЕЕ.
Эта среда предоставляет в распоряжение разработчика большее разнообразие парадигм программирования, чем какая-либо другая.
Среда оснащена лучшими средствами интерфейса и более развитыми средствами редактирования.
Поддержка этой среды со стороны фирмы-производителя организована лучше, чем у ее конкурентов.
Проанализировав возможные варианты, разработчики остановились на выборе в качестве основного инструментального средства компонента COTS среды КЕЕ.
При выборе инструментальной среды немаловажное значение имеет и то, насколько проста среда в обращении и как быстро проектировщики экспертной системы смогут овладеть методикой работы в этой среде, какую поддержку в этом готова оказать им фирма-изготовитель среды, и, конечно же, цена этого программного продукта
17.4.3. Практическое освоение инструментальных средств
В рекламном проспекте множества программных средств для проектирования экспертных систем можно встретить утверждение, что данным инструментом "может успешно пользоваться даже непрограммист" или программист, малознакомый с технологиями искусственного интеллекта. В этом разделе мы попытаемся критически рассмотреть, насколько справедливы подобные утверждения, основываясь на имеющихся обзорах и опубликованных сведениях об опыте работы с такого рода программами. Имеющиеся в нашем распоряжении данные свидетельствуют, что, как правило, овладение типовыми инструментальными средствами проектирования экспертных систем не легче, чем овладение новым языком программирования. Даже опытный программист на начальном этапе освоения такой программы допускает ошибки, свойственные только студентам-новичкам, приступившим к изучению обычного программирования.
В работе [Ward and Sleeman, 1987] представлены результаты мониторинга процесса изучения опытными программистами методики работы с оболочкой для проектирования экспертных систем S.1 [Teknowledge, 1985]. Прародителем S.1 является известная система EMYCIN, а дальнейшим развитием — система М.4. Базы знаний в S.1 содержат множество объектов разного назначения — управляющие выражения, классы, типы классов, порождающие правила, иерархии значений и функций. Таким образом, выбранная для S.1 архитектура, с одной стороны, позволила расширить возможности, которыми обладала система EMYCIN, а с другой — весьма усложнила саму систему. Это замечание еще более справедливо в отношении системы М.4 (см. врезку 17.3).
Среда S.1 поддерживает четыре режима работы:
подготовка и редактирование базы знаний;
использование базы знаний для выполнения консультации, т.е. прогон программы;
выявление и устранение ошибок на стадии компиляции;
выявление и устранение ошибок на стадии выполнения.
Как показал опрос, программисты с трудом осваивают методику совместного использования этих режимов в процессе проектирования экспертной системы, хотя все они имеют большой опыт работы и владеют такими распространенными навыками, как работа с файлами, компилирование файлов, выполнение программ, поиск и устранение ошибок. Те сообщения об ошибках, которые формируются инструментальной средой, несут информации не больше, чем стандартные сообщения об ошибках в большинстве компиляторов обычных языков программирования. По этим сообщениям трудно отличить место возникновения ошибки от места в программном коде, в котором эта ошибка проявилась. Учитывая, что разработка базы данных ведется в режиме постепенного наращивания ее объема (а такая стратегия рекомендуется всеми авторитетными специалистами), переключение с режима на режим в среде разработки должно выполняться как можно проще, поскольку инженеру по знаниям приходится выполнять итеративные процедуры пополнения базы знаний значительно чаще, чем обычному программисту выполнять расширение функций программы.
Анализ опыта освоения этой инструментальной среды также показал, что если программисты отдают предпочтение простейшей стратегии отладки (эта стратегия включает этапы ввода данных, обращения к системе с запросом о значении какого-либо параметра на основе анализа небольшого множества правил и вывода результата), то они сталкиваются с рядом проблем, касающихся методов представления информации и управления поиском. По мере увеличения сложности проектируемой системы — увеличение объема базы знаний, включение в рассмотрение неопределенностей разного рода, включение в алгоритм работы системы дополнительных режимов — стратегия проектирования требует все более тщательной предварительной подготовки. Авторы обзора [Ward and Sleeman, 1987] пришли к выводу, что хотя освоение системы S.1 и не сложнее освоения нового языка программирования уровня PASCAL, но утверждать, что эта система проще, тоже нельзя.
Утверждение, что эту систему могут освоить люди, не имеющие навыков программирования, "не нашло подтверждения на практике", а если уж говорить совсем откровенно, то это не более чем рекламный трюк. Мой собственный опыт наблюдения за аспирантами, которые пользовались такого рода инструментальными системами, полностью согласуется с этими выводами.
В своих аналитических заметках Робинсон [Robinson, 1987] обращает внимание на то, что выбор инструментальной среды разработки экспертной системы представляет собой достаточно сложную задачу по следующим причинам:
большинство развитых сред разработки настолько дороги, что покупать их для проведения сравнительного анализа перед выбором подходящего не по средствам разработчикам;
время, необходимое для освоения навыков работы с системой и выявления ее сильных и слабых сторон, также слишком велико, а потому редко кто может себе позволить проводить сравнение конкурирующих моделей на практике;
терминология, которую применяют в документации изготовители разных систем, существенно отличается, причем это относится даже к понятиям и технологиям, ставшим стандартными в области искусственного интеллекта. Поэтому проводить сопоставление разных моделей по тем сведениям, которые публикуются в технической документации, также достаточно трудно.
Последнее замечание справедливо в отношении большинства программных продуктов, предлагающихся на рынке. Когда же речь идет о программных средствах, связанных с областью искусственного интеллекта, то новизна и необычность терминологии еще более усугубляет проблему. Уже давно в среде специалистов бытует мнение, что сравнение конкурирующих систем одного класса можно выполнять только после тщательного изучения их на практике.
17.3. Правила и процедуры в инструментальной среде М.4
Основным средством представления знаний в оболочке М.4 являются порождающие правила, ориентированные на построение обратной цепочки логического вывода, причем применяется тот же синтаксис, что и в системе EMYCIN (см. главу 1.1), Приведенное ниже правило выбирает болт определенного размера, принимая во внимание ограничения на длину, диаметр и шаг резьбы. Прописными буквами в тексте правила выделены наименования переменных.
If recommended type = bolt and
recommended length = LENGTH and
recommended diameter = DIAMETER and
recommended thread_pitch = PITCH and
fastener(bolt, LENGTH, DIAMETER, PITCH) = BOLT
then recommended fastener = BOLT
Построение прямой цепочки логического вывода моделируется конструкциями whenfound и whencached, которые выполняют функции демонов (см. главу 6). Например, оператор whencached разрешает выполнение определенного действия при установке значения определенного элемента данных. Выполнение такого действия, как правило, включает вызов процедуры, причем на его характер накладывается меньше ограничений, чем на характер действия, специфицированного в правой части порождающего правила в CLIPS. Например, в приведенном ниже фрагменте утверждается, что обнаружен самолет в определенной точке LOC в момент времени TIME, как только при считывании показаний сенсора в момент времени TIME обнаруживается наличие реактивного двигателя или пропеллера, и эти показания согласуются с аналогичными показаниями соседнего сенсора в предыдущий момент времени.
whencached (sensor_reading
( SENSOR, TIME) = SIGNATURE) =
((signature-type (SIGNATURE) = jet or
signature-type (SIGNATURE) = prop)
and TIME -1 = PREVIOUS and cached
( sensor jreading) OTHER, PREVIOUS = SIGNATURE)
and
neighbor (SENSOR) = OTHER and location
(SENSOR) = LOC and do ( set plane_detected ( LOC , TIME ) ) ) .
Насколько этот фрагмент программы читабелен, судить вам.
Процедуры в М.4 имеют синтаксис, весьма напоминающий синтаксис языка программирования С или PASCAL. Например, ниже приведен текст простой процедуры.
procedure ( determine_and_display recs ( FAULT ) ) =
{
f ind_recomendations( FAULT) ;
LIST := listof( recommendations (FAULT) };
COUNT := 1;
while (LIST == [ITEM | REST])
{
display ([COUNT, ". ", ITEM, nl]);
COUNT := COUNT + 1; LIST := REST;
)
В этом фрагменте конструкция LIST == [ITEM (REST] заимствована из языка PROLOG. Она разделяет список LIST на головной элемент ITEM и хвост REST. Читатель может судить по этому фрагменту, насколько просто в среде М.4 программировать процедуры
17.4.4. Стиль программирования
В литературе о программировании задач общего назначения часто обсуждается понятие "стиль программирования". Существует огромное множество книг о том, как писать программы, и кажется, что в них можно найти рекомендации на все случаи жизни.
Но эти рекомендации слабо соотносятся со спецификой программирования задач искусственного интеллекта и, в частности, систем, основанных на знаниях. Тот массив программ на языке LISP, который накопился за многолетнюю практику применения этого языка в программировании задач искусственного интеллекта, повергнет в ужас любого студента, проштудировавшего классические труды по структурному программированию. В программах зачастую используются нестандартные способы управления последовательностью выполнения операторов, непредусмотренное никакими канонами динамическое связывание переменных и совершенно "безответственные" манипуляции со структурами данных, такими как списки свойств. Но в последние годы ситуация здесь значительно улучшилась (с точки зрения приверженцев строго структурированного стиля оформления текста программы). Чтобы убедиться в этом, сравните, например, обзоры [Winston and Horn, 1983] и [Winston and Horn, 1981]. Как бы там ни было, но написать хорошую программу на языке LISP — это искусство, которым владеют единицы, хотя тексты большинства самых лучших программ искусственного интеллекта можно демонстрировать студентам в качестве наглядного пособия, как не надо писать программы.
Но, к сожалению, более чем 25-летний опыт совершенствования стиля программирования на LISP не востребуется разработчиками новых языков и инструментальных сред. Для меня, например, остается загадкой, что же представляет собой хороший стиль программирования по отношению к языку (и среде) КЕЕ. Мне приходилось наблюдать, как инженеры по знаниям, много лет проработавшие с языками структурного программирования, буквально падали в обморок от мешанины подключения процедур, комбинированных методов и активных значений в КЕЕ-программах. Это не следует рассматривать как серьезную критику в адрес функциональных возможностей языка, а скорее как констатацию того факта, что любые сложные инструментальные средства нуждаются в адекватной методологии пользования ими. Единственным исключением, на мой взгляд, является язык OPS5, о методике использования которого написана прекрасная книга [Brownston et al, 1985].
17.5. Некоторые максимы разработки экспертных систем
Чтобы не заканчивать эту главу на такой печальной ноте, я решил включить в последний раздел избранные максимы о построении экспертных систем, почерпнутые из классической работы Бучанана [Buchanan et al., 1983]. Следование им избавит проектировщика экспертных систем от опасности "наступить на грабли", многократно "опробованной" его коллегами. Другим прекрасным источником умных мыслей по тому же поводу может служить книга Преро [Ргегаи, 1990].
Нежизнеспособность некоторых проектов закладывается еще на самых ранних стадиях работы над ними. Приведенные ниже рекомендации помогут избежать этого.
Задача, которую предполагается решать с помощью проектируемой системы, должна быть вполне под силу эксперту-человеку.
Задача должна быть четко сформулирована.
Уже на первой стадии работы над системой подумайте над тем, как она будет совершенствоваться.
Особенно важно с самого начала очертить границы, которых должна достичь система в процессе эволюции. Для этого весьма полезно четко определить, что система не сможет делать. Лучше создать систему, которая сможет надежно решать ограниченную задачу, чем систему, претендующую на решение широкого класса задач, но дающую верное решение лишь время от времени. Конечно, надежность системы, т.е. степень ее правоты, можно оценить, только располагая соответствующим критерием этой самой правоты.
Тщательно отработайте поведение системы на наборе репрезентативных частных случаев и организуйте библиотеку таких случаев для проектируемой системы.
Отделите те знания, которые специфичны для определенной предметной области, от знаний, касающихся общей методики решения проблем. Старайтесь, насколько это возможно, упростить машину логического вывода в системе.
Убедитесь, что те примеры, которыми вы располагаете на этапе проектирования, репрезентативны. С самого начала постарайтесь либо самостоятельно разработать, либо заимствовать программный код, который упростит опробование принятых проектных концепций на этих примерах. Большую помощь в этом может оказать программная среда, которая позволяет подробно документировать сеанс работы с такой экспериментальной системой, включая и фиксацию всех вводимых пользователем данных. Проблема разделения различных видов знаний довольно подробно освещалась в главах 10, 11 и 16.
В отношении формулировки правил авторы упомянутых работ советуют следующее.
Если правило выглядит большим, то так оно и есть.
Если несколько правил очень похожи друг на друга, обратите внимание на те концепты проблемной области, на которых они базируются.
Как и при программировании задач общего назначения, следуйте золотому правилу "краткость — залог надежности". Наличие избыточности почти всегда является признаком того, что возможна какая-то упрощающая абстракция.
У Преро вы встретите и рекомендации, касающиеся этапа реализации экспертной системы. Ниже приведены некоторые из них.
Группируйте правила в отдельные множества.
В системе COMPASS все правила разделены на 18 групп. Только семь из них относятся действительно к процессу решения проблем, т.е. к тому, чем в обычной "бескомпьютерной" жизни занимается эксперт, а остальные обеспечивают выполнение функций поддержки, сбора данных и т.п. В системе используются также демоны, которые расширяют возможности выполнения действий, в частности организуя передачу сообщений между объектами (см. о демонах в главе 6).
Постарайтесь на самых ранних стадиях разработать систему соглашений об оформлении программы. Это придаст ей единообразный вид.
Как уже отмечалось выше, многие программисты, попав в ситуацию, когда можно использовать множество парадигм программирования, забывают о необходимости (или желательности) разрабатывать структурированный программный код. Единственный способ избежать этого — стараться реализовать похожие функции похожими методами во всех компонентах программного кода и оформлять их в едином стиле. Тогда, увидев в каком-либо модуле такой фрагмент кода, программист сможет легко распознать применяемый в данном фрагменте метод или подход. Особенно важно следовать этой рекомендации при разработке отдельных модулей базы данных или индивидуальных баз данных.
Пожертвуйте производительностью программы, если это сделает ее более понятной (в том числе и в смысле читабельности программного кода) и упростит сопровождение.
Программисты часто состязаются друг с другом, кто придумает более "сжатый" код, разобраться в котором постороннему зачастую просто невозможно. От такого кода в подавляющем большинстве экспертных систем нет никакого проку, поскольку в интерактивных консультирующих системах все равно большая часть времени уходит на диалог с пользователем и обращение к базам данных.
Бучанан также останавливается на проблеме разработки системы-прототипа, называя его условно системой Mark I. Он советует заняться разработкой такого прототипа, как только станут понятными два-три типовых примера (типовых задачи) для проектируемой экспертной системы. Однако действительным самородком в наборе советов является следующий.
Как только встанет вопрос о разработке второго прототипа, выбросите первый в мусорную корзину.
Многие проекты "пошли ко дну" лишь потому, что их авторы не могли избавиться от приверженности к первому варианту реализации собственных идей. В связи с этим возникает и такой вопрос, а когда имеет смысл прекратить отработку первого прототипа. Программисты часто впадают в состояние бесконечного "вылизывания" программного кода, которому все равно уже уготовано место на свалке. Конечно, при разработке второго прототипа нужно учитывать опыт создания первого, но опыт, а не программный код.
Процесс проектирования экспертной системы неразрывно связан с экспериментированием.
Этот принцип не утратил своей актуальности и на сегодняшний день. Тех, кто, прочитав какую-нибудь брошюру под броским названием "Экспертная система за NN часов", доверят ее проектирование первому встречному, ожидает горькое разочарование. Разработка приложения, которое будет успешно работать, требует настойчивости и терпения профессионального программиста, привлечения к работе опытного эксперта в своей области и определенного уровня принуждения со стороны руководства.
Рекомендуемая литература
Каталог экспертных систем, разработанных в 70-х — начале 80-х годов, опубликован в книге [Waterman, 1986, Chapters 27-28]. К сожалению, сейчас этот материал уже устарел. Критический анализ некоторых инструментальных средств для инженерии знаний, разработанных в 80-х годах, можно найти в работе [Laurent et al, 1986]. Обзор современных средств разработки экспертных систем и используемых при этом методологий, в который включены как системы, базирующиеся на правилах, так и более современные, базирующиеся на прецедентах (case-based), и объектно-ориентированные, приведен в работе [Harmon and Hall, 1993].
Читатели могут и самостоятельно сравнить характеристики имеющихся на рынке систем подобного назначения, заглянув на Web-сайты фирм Intellicorp, Teknowledge и Inference Corp. Немало полезной информации можно найти и в разделах FAQ (часто задаваемые вопросы) многочисленных групп новостей, имеющих отношение к проблематике искусственного интеллекта. Перечень ftp-серверов таких разделов можно найти по адресу http://hps.elte/hu/ai-faq.html. Но я не могу гарантировать, что представленная на них информация будет полной и злободневной.
Упражнения
1. Проведите сравнительный анализ возможностей инструментальных средств разных классов — оболочек, языков программирования высокого уровня и многофункциональных сред— применительно к проектированию экспертных систем для задач классификации и проектирования.
2. Почему бывает желательно строить рассуждения в разных контекстах и почему некоторые контексты оказываются "отравленными"?
3. Насколько сказываются на конечном варианте проектируемой экспертной системы характеристики начального прототипа?
4. Критически проанализируйте характеристики той инструментальной среды разработки экспертных систем, с которой вы лучше всего знакомы. Анализ должен включать следующие моменты:
I) детальное рассмотрение функциональных возможностей среды, наиболее привлекательных с вашей точки зрения; каким образом эти возможности облегчают проектирование?
II) детальное рассмотрение тех характеристик среды, которые вы считаете неудачными; почему, на ваш взгляд, эти характеристики затрудняют работу?
III) перечень дополнительных возможностей, которые, по-вашему, имеет смысл реализовать в этой среде разработки.
В последнем разделе анализа выделите те дополнительные функции, которые довольно легко встроить в имеющийся вариант, и те, которые потребуют его значительной переделки или приведут к снижению производительности существующего варианта.
5. Попробуйте сформулировать рекомендации, касающиеся инженерии знаний, основываясь на собственном опыте, например на опыте выполнения упражнений из предыдущих глав этой книги. (Только не нужно приводить вариации Законов Мерфи.)
6. Постарайтесь задокументировать процесс освоения новой для вас инструментальной среды. Попробуйте классифицировать те трудности, с которыми вам довелось столкнуться. Например, можно начать с выделения проблем следующих видов.
Проблема управления режимами работы среды — насколько болезненным был процесс освоения пользовательского интерфейса таких компонентов, как редактор, отладчик, интерпретатор и т.п.
Проблемы освоения синтаксиса языка — как быстро вы освоились с правилами расстановки скобок, знаков препинания и т.п.
Концептуальные проблемы. Сложности в освоении процедурных или декларативных конструкций. Например, методики работы с демонами, контекстами и т.п.
7. В этом примере демонстрируется, как в языке CLIPS организована интеграция правил и объектов. Основной механизм взаимодействия правил и объектов состоит в том, что действия, специфицированные в правилах, посылают сообщения экземпляру класса.
Предположим, например, что мы имеем дело с экспертной системой, которая дает пользователю советы, касающиеся покупки музыкальных инструментов. Пусть это будет гитара, причем ее характеристики представлены содержимым слотов. Тогда в этой экспертной системе должны быть правила, подобные приведенному ниже.
(defrule describe-guitar
(option ?guitar) =>
(send (symbol-to-instance-name ?guitar) show) )
В этом правиле show — метод класса guitar, который выводит на экран содержимое слота экземпляра класса в нужном формате. Определение класса guitar может иметь следующий вид:
(defclass guitar (is-a USER) (slot make)
(slot model) (slot wood) (slot pickups))
Метод show этого класса можно представить следующим образом:
(definessage-handler guitar show ()
(printout t
"The " ?self:make " " ?self:model "
is a " ?self:wood " guitar with " ?selfspickups " pickups.")
;; ?self:make " " ?self:model " это "
;; ?self:wood " гитара с "
;; ?self:pickups " звукоснимателем.")
)
Для экземпляра этого класса
(GibSG of guitar
(make Gibson)
(model SG)
(wood mahogany)
(pickups humbucking) )
метод выведет сообщение
"The Gibson SG is a mahogany guitar
with humbucking pickups."
Включите подобную функцию в одну из программ-советчиков, которые предлагалось разработать в упражнениях предыдущих глав, в частности в упр. 7главы 14 и в упр. 4 главы 16.
8. Разработайте два правила, которые будут удалять все действия и факты, связанные с "отравленным" контекстом, в примере, представленном в разделе 17.3.5. Почему таких правил должно быть два?
ГЛАВА 18. Системы с доской объявлений
18.1. Принципы организации систем с доской объявлений
18.2. Системы HEARSAY, AGE и ОРМ
18.2.1. Почему для HEARSAY-1I выбрана такая архитектура
18.2.2. Использование источников знаний в HEARSAY-II
18.2.3. Система HEARSAY-III — оболочка для создания систем с доской объявлений
18.2.4. Инструментальные среды AGE и ОРМ
18.3. Среда с доской объявлений ВВ
18.3.1. Уровни абстракции в среде ВВ
18.3.2. Системы ВВ1 и ACCORD
18.3.3. Система PROTEAN
18.3.4. Интеграция стратегий логического вывода
18.3.5. Общая характеристика ВВ
18.4. Эффективность и гибкость модели с доской объявлений
18.4.1. Организация доски объявлений в системе GBB
18.4.2. Компоновка доски объявлений в среде ERASMUS
18.5. Организация параллельных вычислений в системах CAGE и POLIGON
Рекомендуемая литература
Упражнения
ГЛАВА 18. Системы с доской объявлений
18.1. Принципы организации систем с доской объявлений
18.2. Системы HEARSAY, AGE и ОРМ
18.3. Среда с доской объявлений ВВ
18.4. Эффективность и гибкость модели с доской объявлений
18.5. Организация параллельных вычислений в системах CAGE и POLIGON
Рекомендуемая литература
Упражнения
В последние годы в разработке архитектуры экспертных систем появилось новое направление, которое получило название системы с доской объявлений (blackboard sys-tems)u. Системы с такой архитектурой могут эмулировать режим построения как прямой цепочки логического вывода, так и обратной, а также попеременно применять эти режимы в процессе работы. Кроме того, применение систем с доской объявлений побуждает инженеров по знаниям к иерархической организации и знаний относительно предметной области, и пространства частичных и полных решений. Таким образом, эта архитектура очень хорошо подходит для решения задач проектирования, для которых характерно большое, но факторизуемое многомерное пространство решений. Системы с подобной архитектурой уже успешно применяются для интерпретации данных (например, распознавания графических изображений и речи), анализа и синтеза многокомпонентных структур (например, структуры протеинов) и планирования.
Но следует отметить, что реализация и внедрение систем с доской объявления — довольно сложный процесс, а сами системы требуют значительных вычислительных ресурсов. В этой главе будут рассмотрены следующие вопросы:
структура систем с доской объявлений;
анализ существующих на сегодняшний день систем этого типа и областей их применения;
обсуждение проблем реализации систем с доской объявлений и их эффективности.
Будет показано, что в системах с доской объявлений применяется комбинация нескольких схем представления знаний, которые мы рассматривали в предыдущих главах, но при этом между отдельными схемами существует значительно более тесная связь, чем в многофункциональных инструментальных средах, о которых упоминалось в главе 17.
18.1. Принципы организации систем с доской объявлений
В основу организации систем этого типа положена следующая идея [Corkill, 1991].
Представьте себе группу экспертов, которые сидят возле классной доски (или большой доски объявлений) и пытаются решить какую-либо проблему.
Каждый эксперт является специалистом в какой-то определенной области, имеющей отношение к решению проблемы.
Формулировка проблемы и исходные данные записаны на доске.
Эксперты пытливо вглядываются в то, что написано на доске, и каждый из них думает над тем, чем он может помочь в решении проблемы.
Если кто-либо из экспертов чувствует, что ему есть что сказать по этому поводу, он выполняет соответствующие вычисления и записывает результат все на той же доске.
Этот новый результат может позволить и другим экспертам внести определенный вклад в решение проблемы.
Процесс прекращается (а эксперты расходятся по домам), когда проблема будет решена.
Такая методика совместного решения проблем будет эффективна, если соблюдаются определенные соглашения, а именно:
все эксперты должны говорить на одном и том же языке, хотя при записи результатов на доске могут использоваться и разные схемы обозначений;
должен существовать какой-то протокол определения очередности "выступлений", который вступает в силу в ситуации, когда сразу несколько экспертов хватаются за мел и направляются к доске.
Эти соглашения есть не что иное, как уже знакомые нам по предыдущим главам схемы представления управления.
Если рассматривать работающую по такому принципу систему с точки зрения организации процесса вычислений, то в системе можно выделить следующие структурные компоненты. Знания о предметной области разделены между независимыми источниками знаний (KS— knowledge sources), которые работают под управлением планировщика (scheduler). Решение формируется в некоторой глобально доступной структуре, которую мы будем называть доской объявлений (blackboard). Таким образом, в этой системе все знания "как поступить" будут представлены не в виде единственного набора правил, а в виде набора программ. Каждый из компонентов этого набора может располагать собственным набором правил либо смесью правил и процедур.
Функции доски объявлений во многом сходны с функциями рабочей памяти в продукционных системах, но ее организационная структура значительно сложнее. Как правило, доска объявлений разделяется на несколько уровней описания, причем каждый уровень соответствует определенной степени детализации. Данные в пределах отдельных уровней доски объявлений представляют иерархии объектов или графы, т.е. структуры более сложные, чем векторы, которые использовались в рабочей памяти продукционных систем. В самых современных системах может быть даже несколько досок объявлений.
Источники знаний формируют объекты на доске объявлений, но это выполняется посредством планировщика. Обычно записи активизации источников знаний (knowledge source activation records) помещаются в специальный список выбора (agenda), откуда их извлекает планировщик. Источники знаний общаются между собой только через доску объявлений и не могут непосредственно передавать данные друг другу или запускать выполнение каких-либо процедур. Здесь есть определенная аналогия с организацией работы продукционных систем, в которых правила также не могут непосредственно активизировать друг друга: все должно проходить через рабочую память.
В этой главе будет представлен обзор становления архитектуры систем с доской объявлений и рассказано о том, как в настоящее время эта модель используется в качестве базовой при создании инструментальных систем общего назначения для проектирования экспертных систем. Принципы работы модели будут проиллюстрированы примерами, но основное внимание мы сосредоточим на общей архитектуре систем такого типа, а не на детальном описании отдельных моделей. В заключительном разделе будет рассказано о попытках повысить производительность системы с помощью методов параллельного поиска.
18.2. Системы HEARSAY, AGE и ОРМ
Архитектура на основе доски объявлений "выросла" из разработанной в конце 70-х годов системы распознавания речи HEARSAY [Erman et al., 1980]. Программирование компьютера с целью распознавания речи — это одна из наиболее сложных задач, за которые когда-либо брались специалисты в области искусственного интеллекта. Ее решение требует:
сложной обработки сигналов;
сопоставления физических характеристик звуковых сигналов с символическими элементами естественного языка;
выполнения поиска в большом пространстве возможных интерпретаций, в котором объединены эти разные по своей природе элементы.
Для решения этой проблемы была выбрана методика, основанная на выделении нескольких уровней абстракции описания анализируемых данных. Самым нижним является уровень физических акустических сигналов, на котором формируется звуковой спектр анализированных сигналов. На последующих уровнях информация проходит через напластование лингвистических абстракций со все более увеличивающимся уровнем общности понятий — фонемы, силлабы (созвучия), морфемы, слова, выражения и предложения
18.2.1. Почему для HEARSAY-II выбрана такая архитектура
Приступая к разработке системы, ее создатели прекрасно понимали, что с каждым уровнем анализа связана отдельная отрасль знаний — анализ звуковых сигналов, фонетика, лексический анализ, грамматика, семантика, ораторское искусство. Ни одна из этих отраслей по отдельности не способна предоставить достаточно информации для того, чтобы решить проблему. Представим, например, что, пользуясь методами обработки акустических сигналов, мы смогли разложить исходный звук на фонемы. Но без дополнительной информации все равно не удастся выделить смысл выражений, подобных следующим: l scream (я восклицаю) и ice cream (мороженое) или please let us know (пожалуйста, дайте нам знать) и please lettuce no (пожалуйста,- без салата). Таким образом, хотя каждый отдельный вид (набор) знаний играет существенную роль в решении проблемы и каждый из них может быть представлен в программе более или менее независимо от остальных, автоматическое распознавание речи требует использования всех этих знаний совместно.
При распознавании речи исследователям приходится сталкиваться еще с одной проблемой, которую также можно отнести к числу ключевых, — проблемой неопределенности. Она проявляется на всех уровнях представления информации:
данные неполные и зашумлены;
отсутствует однозначное соответствие между данными на соседних уровнях; примером может служить соответствие между уровнями фонем и лексических единиц при анализе фраз / scream и ice cream;
важную роль играют лингвистический и смысловой контексты; интерпретация соседних элементов делает более или менее вероятными разные варианты интерпретации текущего сегмента.
Более традиционные подходы к распознаванию речи основаны на использовании статистических моделей из теории передачи информации для определения корреляционной связи между сегментами. Подход, базирующийся на знаниях, потребовал существенного пересмотра методов обработки неопределенности.
В работе [Erman et al., 1980] перечислены следующие требования, которым должна удовлетворять эффективно работающая система распознавания речи, основанная на знаниях.
(1) Из всех возможных последовательностей операций (частных решений) хотя бы одна должна приводить к корректной интерпретации.
(2) Процедура анализа имеющихся вариантов интерпретации должна давать корректному варианту более высокую оценку, чем другим конкурирующим вариантам. Другими словами, правильная интерпретация с учетом произношения должна быть оценена выше, чем другие варианты интерпретации, не учитывающие особенностей индивидуальной дикции.
(3) Вычислительные ресурсы (память и время вычислений), необходимые для отыскания правильной интерпретации, не должны превышать определенный порог. Система распознавания, которая через пару дней выдаст результат, пусть и правильный, и потребует памяти объемом несколько гигабайт, вряд ли кому-нибудь будет нужна.
В приведенном списке первое и третье требования в определенной мере противоречат друг другу. Для того чтобы корректное решение изначально присутствовало в пространстве гипотез, на стадии формирования гипотез поневоле приходится быть довольно расточительным, что при большом словаре может привести к комбинаторному взрыву элементов решений. Выход может быть найден только при использовании чрезвычайно остроумных эвристик. Таким образом, важнейшей предпосылкой достижения успеха в создании такой системы является разработка подходящей процедуры оценки вариантов (второе из перечисленных выше требований).
18.2.2. Использование источников знаний в HEARSAY-II
Для генерации, комбинирования и развития гипотез интерпретации в системе HEARSAY-II используется несколько источников знаний. Созданные гипотезы (интерпретации) разного уровня абстракции сохраняются на доске объявлений.
Каждый источник знаний можно считать в первом приближении набором пар "условие-действие", хотя они могут быть реализованы и в форме, отличной от порождающих правил (например, условия и действия могут быть в действительности произвольными процедурами). Поток управления в этой системе также отличается от потока управления в продукционных системах. Вместо того чтобы в каждом цикле интерпретатор анализировал выполнение условий, специфицированных в источниках знаний, источники знаний загодя объявляют об активизированных в них условиях, извещая, какой вид модификации данных будет влиять на выполнение этих условий. В результате система управляется прерываниями, а этот режим управления значительно эффективнее, чем режим циклического просмотра состояния, который является основным для продукционных экспертных систем. Такой режим напоминает использование демонов во фреймовых системах, где поток управления регулируется обновлением данных.
Источники знаний связываются с уровнями доски объявлений следующим образом. Условия, специфицированные в источнике знаний, будут удовлетворяться в результате обновления данных на определенном уровне доски объявлений. Источник знаний также может записывать данные в определенный уровень, причем не обязательно в тот же, который влияет на выполнение условий. Большинство источников знаний в системе HEARSAY-II организовано так, что они распознают данные на определенном уровне лингвистического анализа, а выполняемые ими операции относятся к следующему по порядку уровню. Например, некоторый источник активизируется данными на силлабическом уровне и формирует лексическую гипотезу на уровне слов.
В несколько упрощенном виде архитектура системы HEARSAY-II представлена на рис. 18.1. Стрелки, направленные от уровней доски объявлений к источникам знаний, указывают, данные какого уровня изменяют выполнение условий, специфицированных в источнике знаний. Стрелки в обратном направлении указывают, на какой уровень помещает данные тот или иной источник знаний. Ответвление от стрелки "действия" источника знаний к монитору доски объявлений означает, что изменение данных, выполненное одним источником знаний, фиксируется в мониторе и затем используется планировщиком для активизации другого источника знаний.
Рис. 18.1. Упрощенная структурная схема системы HEARSAY-II
Самое главное отличие архитектуры с доской объявлений от всех, рассмотренных ранее, заключается в том, что такая система не диктует проектировщику определенный режим управления знаниями в системе, например нисходящую или восходящую стратегию построения рассуждений. Например, в той области, для которой создавалась система HEARSAY-II, можно применять и нисходящую стратегию — строить гипотезы о словах, а затем искать подтверждения этим гипотезам на уровне фонем, а можно и восходящую — собирать гипотезы о фонемах и формировать по ним гипотезы о словах. Какой источник знаний будет активизирован, определяется монитором и планировщиком системы, а это решение можно сделать или независимым от предметной области, т.е. от соответствующих источников знаний, или зависимым от них. Здесь архитектура системы никак не связывает разработчика в выборе проектного решения
18.2.3. Система HEARSAY-III— оболочка для создания систем с доской объявлений
Система HEARSAY-III — это оболочка системы с доской объявлений, созданная на базе HEARSAY-II точно так же, как оболочка продукционной системы EMYCIN была создана на базе MYCIN [Erman et al, 1983]. В структуру HEARSAY-III, помимо источников знаний и доски объявлений, включена еще и реляционная база данных, с помощью которой выполняется обслуживание объектов доски объявлений и планирование. Это позволило существенно упростить механизм выбора записей активизации источников знаний. Язык управления базой данных АРЗ основан на языке InterLISP и позволяет программировать выполнение ряда функций оболочки [Goldman, 1978].
Структурные компоненты доски объявлений— это объекты языка АРЗ. Такой объектно-ориентированный подход упрощает представление и операции с данными и частными решениями.
Активизация источников знаний реализуется с помощью управляемых образцами демонов АРЗ (о демонах рассказано в главе 6).
АРЗ поддерживает и операции с базой данных контекстов (о контекстах см. в главе 17), а условия превращения контекста в "отравленный" представлены в виде ограничений языка. Контексты можно использовать для организации набора альтернативных способов продолжения вычислений.
Источник знаний в экспертной системе, создаваемой на базе оболочки HEARSAY-I1I, должен состоять из пускового образца (trigger), первичной программы (immediate code) и тела (body). Обнаружив соответствие между текущим содержимым доски объявлений и пусковым образцом, оболочка создает узел записи активизации для этого источника знаний и запускает на выполнение первичную программу. Спустя некоторое время запись активизации источника знаний выбирается планировщиком и тогда запускается на выполнение тело источника знаний, которое представляет собой программу на языке LISP. В состав HEARSAY-III входит простейший планировщик, который выполняет базовые функции планирования в экспертной системе: выбор очередной записи в списке актуальных и запуск на выполнение программного кода соответствующего источника знаний.
Пусковой образец имеет вид шаблона на языке АРЗ и представляет собой предикат, примитивами которого являются шаблоны фактов и произвольные предикаты языка LISP. Всякий раз, когда база данных модифицируется и оказывается, что текущие данные в ней сопоставимы со всеми шаблонами в образце, создается узел записи активизации, который хранит название источника знаний, пусковой контекст и значения переменных, полученные в результате сопоставления. При создании записи активизации выполняется первичная программа источника знаний. Эта программа, написанная на языке LISP, может связывать с узлом записи активизации некоторую информацию, которая позже может быть использована при выполнении тела источника. Первичная программа выполняется в пусковом контексте и в ней могут использоваться конкретизированные в этом контексте переменные образца. Значение, возвращаемое первичной программой после завершения, — это имя какого-либо из классов узлов доски объявлений. Затем запись активизации помещается на доску объявлений в качестве узла этого класса.
Некоторое время спустя базовый планировщик системы, который входит в состав оболочки HEARSAY-III, инициирует выполнение какой-либо операции с записью активизации. Как правило, это выполнение тела источника знаний в пусковом контексте с означенными переменными. Каждый сеанс выполнения тела источника знаний неделим — это аналог транзакции в системах управления базами данных. Сеанс продолжается до полного завершения и не может быть прерван для активизации любого другого источника знаний.
При проектировании прикладной экспертной системы на базе оболочки HEARSAY-III нужно самостоятельно разработать процедуру базового планировщика, которая будет вызываться оболочкой после запуска. Эта процедура может быть достаточно простой, поскольку большая часть знаний о планировании может быть включена в планирующие источники знаний. Например, базовый планировщик может представлять собой простейшую циклическую процедуру, которая извлекает первый элемент из очереди, организованной планирующими источниками знаний, и запускает его выполнение. Если обнаруживается, что очередь пуста, базовый планировщик завершает работу системы.
Основные достоинства среды HEARSAY-III — это, во-первых, использованный в ней режим управления, который предоставляет разработчикам прикладных экспертных систем большую свободу в выборе способов представления и применения эвристик отбора активизируемых записей источников знаний, а во-вторых, структуризация множества объектов доски объявлений
18.2.4. Инструментальные среды AGE и ОРМ
Инструментальная среда AGE представляет собой набор заранее сформированных модулей — компонентов, из которых пользователь может создавать прикладную экспертную систему [Nii and Aiello, 1979]. Компонент— это набор переменных и функций на языке LISP, которые описывают как реальные, так и концептуальные объекты. Из компонентов можно "собирать" и продукционную экспертную систему, использующую стратегию обратной цепочки логического вывода, как в MYC1N, и систему на основе доски объявлений. Источник знаний в структуре с доской объявлений представляет собой помеченный набор порождающих правил, с которым связаны предусловия для его активизации. Эти предусловия специфицируют ситуации, в которых применимы правила из данного источника. По отношению к каждому источнику может быть использована как стратегия активизации единственного правила, так и стратегия параллельной активизации нескольких правил.
Описания концептуальных и реальных объектов, а также связей между ними могут иметь объектно-ориентированное представление, как это сделано в пакете UNITS, созданном в среде AGE [Stefik, 1979]. (Пакет UNITS является прототипом системы КЕЕ, о которой упоминалось в главе 17.) Правила в источниках знаний имеют доступ к управляющей информации на доске объявлений. В результате одни источники знаний могут манипулировать другими и всю конструкцию можно считать частью управляющей структуры.
Правила в источниках знаний могут быть активизированы в разных режимах применимости — когда выполняются все условия, специфицированные в левой части правила или когда выполняется только часть этих условий. Среда предоставляет пользователю (разработчику экспертной системы) определить, какой именно режим применимости следует использовать в отношении того или иного правила. В состав среды входит набор простых функций оценки (например, функция "все-условия-должны-быть-истинными"), которые пользователь может встраивать в проектируемую систему. В правой части правил специфицируются изменения, которые нужно внести в структуру гипотезы или в базу знаний. Возможные изменения разбиты на три группы (типа):
события— реальные изменения элементов гипотезы, связей или базы знаний; информация о таких изменениях немедленно помещается в список событий на доске объявлений и становится доступной другим источникам знаний;
предполагаемые изменения структуры гипотезы или базы знаний помещаются в список ожидаемых на доске объявлений; этот список также доступен другим источникам знаний как часть управляющей информации;
желательные изменения структуры гипотезы или базы знаний — цели; эти изменения помещаются в список целей.
Те изменения, которые вносятся правилами, можно связать с параметром, отражающим степень уверенности в импликации, которую необходимо вывести при условиях, указанных в левой части правила. Этот параметр конструктор экспертной системы должен выразить в тройках "атрибут-значение-вес" элемента гипотезы, задействованного при выполнении правила. Веса в правилах и значения параметров, присвоенные атрибуту гипотезы, должны быть каким-то образом объединены. В целях достижения максимальной гибкости среда AGE предлагает пользователю задать предпочтительный метод вычисления такой комбинированной оценки в виде функции, которая служит для корректировки весов. Пользователь может выбрать либо одну из встроенных в среду функций, либо разработать ее самостоятельно.
В работе [Aiello, 1983] описаны три варианта реализации экспертной системы PUFF с помощью среды AGE, в которых использованы разные модели структуры.
Экспертная система ОРМ [Hayes-Roth, 1985], предназначенная для планирования выполнения множества задач, представляет собой систему управления доской объявлений. В ней решение проблем из предметной области и управления объединены в едином цикле управления, причем не предусматривается использование какой-либо заранее запрограммированной стратегии управления. Выбор очередной операции выполняется на основании независимых суждений о том, какие операции желательны в текущей ситуации и какие возможны, причем при принятии решения используется комбинация множества управляющих эвристик. Основное назначение системы — планирование мероприятий. Программа использует четыре глобальных структуры данных.
(1) Доска объявлений, которая разбита на пять "панелей":
метапланирование (цели планирования);
абстракции планирования (решения о планировании);
база знаний;
план (выбранные действия);
исполнение (выбранные для выполнения записи активизации источников знаний).
(2) Список событий для хранения изменений, вносимых на доску объявлений.
(3) Карта соответствия, указывающая пункты проведения мероприятий.
(4) Список актуальных записей источников знаний.
Источники знаний содержат в своем составе и пусковые образцы, с помощью которых определяется соответствие источника знаний текущему узлу на доске объявлений, и программы проверки, с помощью которой выясняется, возможно ли применение определенной записи активизации в текущей ситуации. При планировании работы с источниками знаний предпочтение отдается тем записям активизации, которые влияют на текущий узел доски объявлений.
Хотя при разработке системы ОРМ предполагалось использовать ее как инструмент моделирования процесса принятия решений человеком, у нее есть несомненные достоинства и с точки зрения системной организации. Возможность интегрировать управляющие знания в однородную среду знаний открывает довольно интересные перспективы для реализации метауровневой архитектуры
18.3. Среда с доской объявлений ВВ
В работе [Hayes-Roth et al, 1988] описана среда ВВ для построения экспертных систем, использующих модель доски объявлений с трехуровневой структурой. Система четко разделена на три уровня — прикладные программы, оболочки задач и архитектуры, — которые, несмотря на такое явное разделение, довольно тесно интегрированы. При разработке акцент сделан на те интеллектуальные системы, которые должны обладать способностью судить о собственном поведении, используя для этого знания о возникающих событиях, состояниях, действиях, которые можно предпринять, и отношениях, существующих между событиями, действиями и состояниями
18.3.1. Уровни абстракции в среде ВВ
На верхнем уровне абстракции — уровне архитектуры — представлен набор базовых структур знаний (представляющих действия, события, состояния и т.п.) и механизм, который служит для отбора и реализации действий. Этот вид знаний обособлен не только от конкретной предметной области, но также независим и от метода решения отдельных задач и проблемы в целом. Идея состоит в том, что архитектура проектируемой системы должна обеспечивать поддержку решения разнообразных задач в множестве предметных областей (точно так же и способность человека мыслить не связана с какой-либо отдельной задачей или областью знаний). На этом же уровне представлены и способности рассуждать о поведении, обучаться и пояснять свои действия.
Оболочки задач — это следующий, более низкий уровень абстракции. На нем представлены промежуточные структуры знаний о действиях и событиях, касающихся определенной задачи, например о неисправностях в тестируемой системе или о конструкциях, удовлетворяющих определенным ограничениям. Методы, которые представлены на этом уровне, могут быть общими для нескольких родственных предметных областей. Здесь есть прямая аналогия с тем, как человек планирует свои действия в разных ситуациях, используя ограниченный набор опробованных стратегий. Примером такой оболочки может служить система ACCORD, которая решает задачу планирования сборки изделия из множества компонентов.
Наиболее специфический уровень — прикладной, на котором сконцентрированы структуры знаний о конкретных действиях в конкретных обстоятельствах и методы решения конкретных классов проблем. Примером системы, в которой используется этот уровень, являются PROTEAN — система вывода структуры протеинов при заданных ограничениях [Hayes-Roth et al, 1986] и SIGHTPLAN — система проектирования архитектурных планировок [Tommelein et al., 1988].
18.3.2. Системы ВВ1 и ACCORD
Перечисленные выше особенности архитектуры среды ВВ можно проиллюстрировать на примере систем ВВ 1 и ACCORD.
Как и в других системах, использующих модель доски объявлений, в системе ВВ 1 источники знаний активизируются событиями на связанном с этими источниками уровне доски объявлений, в результате чего формируется запись активизации источника знаний [Johnson and Hayes-Roth, 1986]. Собственно активизация источника знаний откладывается. Запись активизации находится в списке заявок до тех пор, пока не будут выполнены все предусловия, которые, как правило, связаны со свойствами объектов доски объявлений. Но помимо доски объявлений и источников знаний предметной области, система ВВ1 управляет также и источниками знаний управляющей доски объявлений. Планировщик организует исполнение активизированных источников знаний обоих типов — и предметной области и управления — в соответствии с планом, который динамически корректируется компонентами управляющей доски объявлений. Результат активизации источника знаний сказывается на состоянии уровня доски объявлений, подключенного к его выходу, и таким образом активизируются другие источники знаний.
Основной цикл работы ВВ1 состоит из следующих операций.
(1) Интерпретация действия, предусмотренного очередной записью активизации источника знаний.
(2) Обновление списка заявок — добавление в него новых записей, порожденных изменением данных, вызванных предыдущей операцией, — и сортировка всех записей в списке заявок в соответствии с текущим планом.
(3) Выбор записи с наибольшим рейтингом.
ACCORD — это язык для представления знаний, касающихся выполнения задач сборки многокомпонентных объектов с соблюдением заданных ограничений. Метод сборки компонентов не предусматривает какого-либо наперед заданного режима управления, но требует принятия множества решений при конструировании отдельных узлов. Основной механизм представления предполагает использование иерархии понятий — типов, представителей и экземпляров.
Типы определяют родовые понятия и их роли, в отличие от того, как это делается в семантических сетях с помощью связей типа IS-A (это есть). Представители — это конкретизированные типы, а экземпляры — объекты, созданные при означивании представителей в определенном контексте. Понятия могут иметь атрибуты и входить в определенные отношения с другими понятиями. Здесь имеется определенная аналогия со связями типа IS-A в семантических сетях.
Оболочка, таким образом, предоставляет в распоряжение пользователя скелетные ветви иерархической структуры объектов-компонентов, которые должны образовать единый ансамбль, контексты их компоновки и ограничения, в которые эта компоновка должна "вписываться". Например, ACCORD представляет следующие роли, независимые от предметной области: arrangement (сборка), partial-arrangement (узел) и included-object (компонент). Между ролями имеется отношение типа includes (включает). Среди ролей included-object важное место отводится роли anchor (якорь), представляющей объект, положение которого в общем ансамбле (сборке) должно быть фиксированно, и таким образом определяет локальный контекст для узла. Ролью anchoree представлен объект included-object, который имеет, как минимум, одно ограничение, связанное с его положением относительно объекта anchor.
18.3.3. Система PROTEAN
Система PROTEAN [Hayes-Roth et al., 1986] предназначалась для идентификации трехмерных структур протеинов. Комбинаторные свойства пространства решений не позволяют использовать методику исчерпывающего поиска, поэтому в программе реализована стратегия последовательного уточнения на основе определенного плана управления.
При формировании гипотез в системе PROTEAN локальные и глобальные ограничения используются в комбинации. Локальные ограничения дают информацию о близости атомов в молекуле, а глобальные — информацию о размерах молекулы и ее форме.
Вместо того чтобы пытаться применить все ограничения к анализируемой молекуле в целом, в системе PROTEAN успешно используется подход "разделяй и властвуй" при определении частных решений, которые могут включать разные подмножества элементов структуры протеина и разные подмножества ограничений.
Логический вывод в системе PROTEAN двунаправленный и базируется на использовании доски объявлений с четырьмя уровнями. Когда реализуется нисходящая стратегия (сверху вниз), система использует гипотезы на одном уровне для определения положения на другом, более низком; когда же реализуется восходящая стратегия (снизу вверх), гипотезы на одном уровне используются в качестве ограничений для другого, более верхнего.
Управляющие знания в системе PROTEAN также разделены на разные уровни абстракции. Самый верхний уровень определяет стратегию решения конкретной проблемы. На промежуточном уровне система фиксирует отдельные этапы, необходимые для реализации общей стратегии, а потому программа всегда может получить информацию о том, на какой стадии решения она находится. Нижний уровень управления отвечает за ранжирование записей активизации источников знаний.
Система PROTEAN представляет для нас особый интерес тем, что она демонстрирует, как в рамках архитектуры ВВ1 можно комбинировать независимые от предметной области механизмы логического вывода и зависимые от предметной области знания об ограничениях.
18.3.4. Интеграция стратегий логического вывода
Джонсон и Хейес-Рот обратили внимание на то, что рассуждения, ведомые целью, можно объединить и с иерархическим планированием, и с выбором подходящего контекста в PROTEAN [Johnson and Hayes-Roth, 1986]. Стратегию формирования суждений на основе заданной цели нужно использовать в тех случаях, когда перед выполнением желаемой операции нужно выполнить некоторые подготовительные процедуры. Например, в записях активизации источников знаний, представляющих желаемые операции, могут быть специфицированы определенные предварительные условия, и эти предусловия можно трактовать как подцели, достижение которых будет способствовать активизации указанных источников знаний.
Знания о целях можно дифференцировать, различая причины, побуждающие нас сформировать ту или иную цель. Причинами могут быть стремление
(1) выполнить определенную операцию (например, активизировать определенный источник знаний, представленный в записи активизации);
(2) установить определенное состояние, которое будет способствовать удовлетворению предусловий активизации;
(3) вызвать определенное событие, которое поставит в очередь запись активизации источника знаний с желаемой операцией.
Цели первого типа представляют операции, которые приводят к удовлетворению предусловий. Цели второго типа имеют отношение к ситуации, когда текущий контекст не позволяет запустить на выполнение выбранную запись. В этом случае можно воспользоваться родовым источником знаний, который в ВВ1 имеет наименование ЕпаЫе-Priority-Action. Этот источник и активизируется в тех случаях, когда не удовлетворяются предусловия в выбранной записи. Цели третьего типа имеют отношение к ситуации, когда в списке выбора отсутствуют записи, которые могут привести к выполнению желаемой операции. В этом случае потребуется вмешательство специального источника управляющих знаний, способного отыскать среди прочих источников знаний такой, который содержит в себе желаемую операцию. Создать условия для его активизации — это и есть цель третьего типа.
Указанные две стратегии могут работать совместно, устраняя препятствия для выполнения желаемых операций
18.3.5. Общая характеристика ВВ
Архитектура ВВ, конечно, довольно сложная, но эта сложность оправдывается следующими ее преимуществами по сравнению с более простыми системами.
В этой архитектуре решена задача разделения управляющих знаний и знаний, специфичных для предметной области. Источники родовых управляющих знаний могут без всякой модификации использоваться в экспертных системах самого разнообразного назначения, хотя источники знаний о предметной области при этом будут совершенно различными.
Эта архитектура предполагает дифференциацию источников знаний каждого из указанных типов. Знания о предметной области в системе ACCORD разделены на знания о действиях, событиях, состояниях, объектах, их компоновках и роли объектов в компоновках. Управляющие знания также разделены на знания о стратегии, предусловиях, эвристиках и т.д.
Эта архитектура позволяет формировать пояснения поведения системы в терминах выполняемого плана.
Архитектура предполагает широкое использование языков высокого уровня, подобных ACCORD.
Модули, которые входят в состав среды, могут быть использованы повторно в множестве создаваемых на ее основе прикладных экспертных систем.
Как это случалось и с прежними разработками, выполненными в стенах Станфордского университета, предлагаемый подход интересен не только с точки зрения теории построения систем искусственного интеллекта, но имеет и большую практическую ценность
18.4. Эффективность и гибкость модели с доской объявлений
Широкие функциональные возможности и универсальность архитектуры на основе доски объявлений приводят к увеличению объема вычислений, необходимых для ее реализации. Ниже мы рассмотрим проблемы, возникающие при построении прикладных экспертных систем с такого рода архитектурой.
18.4.1. Организация доски объявлений в системе GBB
В реальной экспертной системе доска объявлений представляет собой ассоциативную память для источников знаний. Вычислительные операции, связанные с манипуляцией данными в этой памяти, отнимают львиную долю ресурсов всей системы. Поэтому понятно, насколько важно использовать для работы с доской объявлений эффективные алгоритмы доступа к данным и добавления новых данных. Хотя мы и не располагаем конкретными данными об эффективности выполнения вычислений в современных системах с такой архитектурой, но в разработанной в 70-х годах системе HEARSAY-II до половины машинного времени уходило на организацию работы с доской объявлений, а уже оставшееся время тратилось на собственно обработку информации от источников знаний.
В ранних системах для повышения производительности операций с доской объявлений использовалось разбиение ее на уровни или "панели", что позволяло сократить пространство поиска, поскольку определенный источник знаний требовал просмотра только части всей структуры данных.
Ниже мы несколько подробнее рассмотрим современную систему, названную создателями GBB (Generic Blackboard Builder). Ее можно рассматривать как типичного представителя нового поколения систем с такой архитектурой.
Разделы доски объявлений в GBB называются пространствами (spaces), причем они, в свою очередь, разделены на размерности (dimensions), для доступа к которым используется специальный атрибут индексации. Элементы структуры данных доски объявлений "живут" в этих пространствах, причем оснащены собственными атрибутами индексации, позволяющими реализовать множество различных методов быстрого обращения к ним. Если пользоваться терминологией баз данных, то эти индексы являются, по существу, ключами, хотя и довольно сложными.
Размерности, используемые для дальнейшей структуризации пространств, могут быть упорядоченными (ordered) или перечислимыми (enumerated). Индексы могут быть скалярными, т.е. состоять из единственного элемента данных, или составными, состоящими из множества компонентов. Скалярные индексы упорядоченных размерностей представляют собой числа из некоторого диапазона, а составные индексы могут быть либо набором меток, либо последовательностью, упорядоченной в соответствии с какой-либо другой размерностью, например по времени.
В каждом цикле выполнения программы отыскивается элемент в определенном пространстве доски объявлений, сопоставимый с пусковым образцом источника знаний. Такой пусковой образец в GBB чаще всего представляет собой не левую часть порождающего правила, а шаблон, ссылающийся на элементы доски объявлений. При работе с размерностями процесс извлечения элемента из доски объявлений состоит из четырех этапов.
(1) Первичное извлечение. Выбирается множество всех элементов данного пространства доски объявлений, которые "претендуют" на сопоставление с шаблоном. Каждое пространство имеет карту элементов, с помощью которой можно определить, как элементы хранятся в этом пространстве. Можно, конечно, хранить их и в виде последовательного списка, но такой способ недостаточно эффективен. Элементы в упорядоченных размерностях со скалярными индексами можно хранить в виде "пакетов", т.е. наборов, имеющих индексы в определенном диапазоне, а элементы перечислимых размерностей, имеющие составные индексы, — в виде хешированных таблиц.
(2) Предварительная фильтрация. К элементам в отобранном множестве применяются какие-либо процедуры предварительного отбора, позволяющие отсеять некоторые из них еще до сопоставления с шаблоном.
(3) Фильтрация по шаблону. Каждый элемент отобранного множества сравнивается с шаблоном и проверяется, удовлетворяет ли он заданным в шаблоне ограничениям. В каждом шаблоне специфицированы определенные критерии сопоставления— должен ли элемент доски объявлений точно соответствовать шаблону, включать в себя шаблон или представлять собой часть шаблона. Поскольку шаблоны могут включать и индексированные компоненты, должны существовать правила, определяющие дисциплину сопоставления таких компонентов.
(4) Постфильтрация. К каждому отобранному элементу доски объявлений применяются дополнительные процедуры проверки. Этот этап необязателен, как, впрочем, и этап предварительной фильтрации. В результате множество элементов-претендентов еще более сужается.
Та схема обработки, которую мы здесь представили, отображает процесс только в самых общих чертах. В действительности все происходит значительно сложнее, но в этой книге мы не будем останавливаться на всех деталях его реализации. Но уже и из этого описания ясно, что уровень сложности обработки в системах с доской объявлений на порядок выше, чем в системах с другой архитектурой, использующих в чистом виде представление знаний в виде правил или объектов. Для того чтобы помочь пользователю справиться с возросшей сложностью системы, в состав оболочки включено множество заготовок типовых модулей, из которых пользователь может достаточно просто скомпоновать прикладную экспертную систему
18.4.2. Компоновка доски объявлений в среде ERASMUS
Практически все компоненты системы с доской объявлений имеют ярко выраженную модульную структуру. Это в равной мере относится и к структурам данных самой доски объявлений, и к источникамзнаний, и к средствам управления режимом работы системы. Например, существует множество способов представления элементов данных доски объявлений, в источниках знаний можно использовать множество разных форматов представления знаний (порождающие правила, программный код на языке LISP и т.п.), по-разному можно настраивать процесс активизации источников знаний, планирования выполнения заявок.
Вслед за средами разработки ВВ1 и GBB мы рассмотрим в этом разделе еще одну систему — ERASMUS, которая разработана в компании Boeing на основе опыта, полученного при работе с ранее созданной системой с доской объявлений ВВВ (Boeing Blackboard System). Система ВВВ разрабатывалась в среде ВВ1, а элементы данных в ней представляли собой объекты языка КЕЕ (см. об этом языке в главе 17). Система была задумана как инструментальная среда, предоставляющая в распоряжение разработчика множество самых различных средств, которые можно использовать в прикладной системе в разных сочетаниях. Фактически ERASMUS является развитием ВВВ, причем при модернизации преследовались следующие цели [Байт et al., 1989].
(1) Конфигурация системы должна настраиваться пользователем.
(2) Должна обеспечиваться максимально высокая производительность, возможная при заданной конфигурации.
(3) Система должна допускать наращивание.
(4) Система должна поддерживать множество схем представления объектов доски объявлений.
Специалисты фирмы Boeing пришли к выводу, что многие приложения, с которыми им приходится иметь дело, достаточно хорошо вписываются в подход, который был использован в среде ВВ1. По образу и подобию ВВ1 в фирме была разработана среда ВВВ, но после нескольких лет ее эксплуатации сложилось мнение, что использованная в ней схема представления и управления накладывает чрезмерные ограничения. Поэтому, например, при создании на основе ВВВ системы планирования производства Phred пришлось дополнительно разрабатывать механизм поддержки некоторых фаз решения проблем, подобный описанному в главе 13. Оказалось также, что на некоторых фазах процесса можно организовать более эффективное планирование активизации источников знаний, допустив исполнение нескольких заявок. При работе с другой экспертной системой, Cockpit Information Manager, оказалось, что нужно повысить скорость поиска объектов на доске объявлений. Реализация элементов данных доски объявлений в виде объектов языка КЕЕ не позволяет получить максимальную производительность системы, хотя в системе GBB этого удалось достичь за счет использования изощренного метода индексации при извлечении объектов из доски объявлений.
Разработчики системы ERASMUS охарактеризовали ее как "генератор систем с доской объявлений", хотя больше ей подходит характеристика "система с конфигурируемой архитектурой" (configurable architecture). Возможность по-разному компоновать структуру системы, создаваемой в этой среде, позволяет оптимально настроить ее архитектуру в соответствии с характеристиками конкретного приложения.
Среда ERASMUS поддерживает четыре опции конфигурации.
(1) Blackboard (доска объявлений). Пользователь может выбрать одну из четырех структур данных для доски объявлений в создаваемой системе, в том числе и формат, подобный GBB, или на основе объектов языка КЕЕ.
(2) KS structure (структура источника знаний). Источники знаний могут быть реализованы в формате языка FLAVOR (см. об этом языке в главе 7), а записи активизации источников знаний представляют собой экземпляры объектов этого языка. Пользователь может специфицировать предусловия активизации источников знаний, условия устранения, при выполнении которых запись активизации источника знаний удаляется из списка выбора, фазы процесса решения проблемы и т.п.
(3) Control (режим управления). Пользователь может выбрать режим управления, аналогичный используемому в системе ВВ1, либо режим, ведомый эвристиками, назначающими веса записям активизации источников знаний.
(4) Runtime (опции времени выполнения). Эти опции позволяют пользователю выбрать механизм формирования пояснений, трассировки и различные средства отладки, которые должны быть включены в состав компонуемой прикладной экспертной системы.
Таким образом, модульная организация систем с доской объявлений позволяет разработчикам гибко варьировать структуру конкретной системы с такой архитектурой, добиваясь оптимального соответствия между функциональными возможностями и производительностью системы.
18.5. Организация параллельных вычислений в системах CAGE и POLIGON
При анализе работы систем с доской объявлений сам собой напрашивается вопрос, а нельзя ли, учитывая наличие нескольких независимых источников знаний, общающихся друг с другом через глобальную структуру данных, организовать их параллельную работу. Очевидно, что параллелизм можно внедрить на разных уровнях систем с такой архитектурой:
на уровне активизации источников знаний;
на уровне обработки пускового образца и предусловий в процессе работы с отдельным источником знаний;
на уровне выполнения действий, предусмотренных записью активизации источника знаний.
Хотя процессам первой группы параллелизм присущ по самой их природе, процессы двух других групп могут включать и последовательно выполняемые шаги. Например, предусловия разных правил могут использовать одни и те же переменные, а операции, специфицированные разными активизированными правилами, могут потребовать соблюдения определенной последовательности выполнения.
В Станфордском университете в рамках проекта Advanced Architectures Project созданы два прототипа систем с доской объявлений, в которых использованы разные методики организации параллельной работы компонентов системы. Ниже мы приведем краткое описание этих разработок. Более детально читатель может познакомиться с ними в работе [Nii et al., 1988].
Система CAGE [Aietlo, 1986] является модификацией описанной выше инструментальной среды AGE и представляет собой мультипроцессорную вычислительную систему с общей памятью. В язык программирования системы включены конструкции, позволяющие описать параллельное выполнение некоторых фрагментов кода на уровне прикладной программы. В проекте параллельное выполнение реализовано на трех уровнях системы.
Параллельная работа источников знаний. Источники знаний могут параллельно работать с разными сегментами структуры данных доски объявлений или может быть использован режим конвейерной обработки, когда разные операции выполняются с разными сегментами данных, которые по очереди извлекаются из конвейера.
Параллельная реализация правил. Условия, специфицированные в разных правилах, могут анализироваться параллельно. Действия, указанные в правых частях правил, могут быть реализованы затем либо параллельно, либо поочередно.
Параллельный анализ условий. Условия, специфицированные в одном и том же правиле, также могут анализироваться параллельно.
Параллельная обработка источников знаний может выполняться как в синхронном, так и в асинхронном режимах. В первом приближении синхронизация нужна в том случае, когда выходные данные множества параллельных этапов обработки буферизуются до тех пор, пока не закончится выполнение всех параллельных процессов. Таким образом, передача выходных данных на доску объявлений задерживается до тех пор, пока все активизированные источники знаний не завершат свои операции. Пользователь также может задать в программе, как должны быть реализованы действия, предусмотренные в активизированных правилах, — параллельно или поочередно.
Эксперименты с системой CAGE разочаровали ее создателей. В системе, насчитывающей восемь процессоров, было достигнуто только двукратное повышение скорости вычислений в режиме параллельной синхронной обработки источников знаний, а при использовании четырех процессоров вообще не наблюдалось никакого изменения производительности. В асинхронном режиме при использовании восьми процессоров удалось повысить быстродействие менее чем в четыре раза. Эксперименты с использованием параллельной обработки правил привели примерно к пятикратному повышению производительности системы, состоящей из 16 процессоров.
Другая система, POLIGON, была разработана "с чистого листа" на базе мультипроцессорного вычислительного комплекса с распределенной памятью. В ней используется распараллеливание задачи на множестве уровней. Эксперименты с этой системой дали значительно более обнадеживающие результаты. Оказалось, что эффективность распараллеливания существенно увеличивается по мере роста объема данных в источниках знаний и количества правил, претендующих на активизацию.
Из сравнительного анализа двух систем был сделан вывод, что попытка запаралле-лить обработку отдельных этапов при сохранении режима централизованного управления всей системой (вариант системы CAGE) не может привести к успеху, а использование децентрализованного управления снижает возможности программного управления процессом логического вывода. Таким образом, первые работы в направлении реализации параллельного режима в системах с доской объявлений показали, что это задача далеко не тривиальная. Параллелизм может оправдать себя только в тех областях применения, где возрастающая сложность системы и значительное увеличение объема вычислений оправдываются результатами работы экспертной системы.
Рекомендуемая литература
Для первого знакомства с принципами построения экспертных систем на основе доски объявлений я бы рекомендовал прочесть обзорные работы [Nil, 1986, а, b]. Подборка статей об исследованиях в этом направлении опубликована в сборнике [Englemore and Morgan, 1988]. С точки зрения технологии экспертных систем особый интерес представляют главы 5 и 6, в которых описаны некоторые ранние системы с такой архитектурой, не рассмотренные в данной книге, глава 12, содержащая достаточно подробное описание системы AGE, и глава 26, в которой кратко описана реализация системы GBB.
Тем, кто желает детальнее познакомиться с системами GBB и ERASMUS, я рекомендую работу [Jagannathan et al., 1989]. Информация о проекте Advanced Architectures Project и разработанных в его рамках системах CAGE и POLIGON опубликована в работе [Rice, 1989]. Прилагаемый к ней список публикаций результатов, полученных в ходе работы над этим проектом, послужит хорошим путеводителем тем, кто захочет глубже с ним познакомиться.
Среди прочих работ, касающихся проблематики систем с доской объявлений, я бы выделил книгу [Craig, 1995] и обзорную статью [Carver and Lesser, 1994].
Упражнения
1. Что такое источник знаний в системе с доской объявлений?
2. Сравните использование разных вариантов архитектуры экспертных систем — продукционную систему и систему с доской объявлений. При каких условиях можно считать оправданным усложнение системы, использующей модель с доской объявлений.
3. В чем различие между системами с доской объявлений и многофункциональными инструментальными средами, описанными в главе 17.
4. Прочтите работу [Nil et al, 1988] и составьте краткий обзор характеристик систем CAGE и POLIGON. Особое внимание в этом обзоре уделите анализу отличий между методами принятия решений, использованными в каждой из систем, их достоинствам и недостаткам.
5. Подумайте над тем, как в рамках архитектуры систем с доской объявлений организовать систему планирования мероприятий, выполняющую те же функции, что и описанная в главе 15. Какие источники знаний целесообразно использовать в ней для формирования начального наброска плана, для его уточнения и для окончательной проверки совместимости всех этапов.
6. Придумайте задачу, при решении которой в полной мере могут проявиться достоинства структуры с доской объявлений. Какие источники знаний должны быть использованы в системе, предназначенной для решения этой задачи. Например, при расследовании происшествия, повлекшего за собой смерть пловца, пользовавшегося для плавания под водой дыхательным аппаратом, власти стараются рассмотреть множество аспектов происшествия, которые могут быть представлены в разных источниках знаний. Ниже приводится их примерный перечень.
Условия, связанные с внешней средой:
состояние воды;
неблагоприятные течения;
потенциальные ловушки;
опасности, связанные с судоходством;
опасности, исходящие от обитателей морских глубин.
Нарушения в работе технических средств:
пользование техническими средствами;
обслуживание технических средств. Характеристика потерпевшего:
опыт и тренировка;
психологические проблемы;
химические проблемы, например употребление наркотиков;
физическое состояние.
Подумайте над тем, как управлять применением знаний в приложении. Будут ли источники знаний функционировать независимо друг от друга, посылая в любое время сообщения доске объявлений, или будут активизироваться по очереди. Например, в описанной выше задаче расследования можно организовать режим поочередного использования источников знаний каждой из перечисленных категорий в заранее заданном порядке.
ГЛАВА 19. Система отслеживания истинности предположений
19.1. Отслеживание зависимостей
19.1.1. Релаксация в сети
19.1.2. Пересмотр допущений
19.2. Пересмотр теорий высказываний
19.3. Немонотонное обоснование
19.4. Работа со множеством контекстов
19.4.1. Отслеживание истинности предположений, основанное на анализе допущений
19.4.2. Использование систем отслеживания истинности предположений для диагностирования на основе моделей
19.5. Сравнение различных вариантов организации систем отслеживания истинности предположений
Рекомендуемая литература
Упражнения
ГЛАВА 19. Система отслеживания истинности предположений
19.1. Отслеживание зависимостей
19.2. Пересмотр теорий высказываний
19.3. Немонотонное обоснование
19.4. Работа со множеством контекстов
19.5. Сравнение различных вариантов организации систем отслеживания истинности предположений
Рекомендуемая литература
Упражнения
Во всех экспертных системах мы тем или иным образом стремимся представить модель окружающего нас мира или, по крайней мере, какой-либо предметной области этого мира. Думаю, не следует тратить время на доказательство того очевидного факта, что программе нельзя позволять выполнять произвольные манипуляции над представлением мира, которое в ней имеется. Как правило, предположения в таком представлении влияют друг на друга, и существуют ограничения, которым должно удовлетворять любое множество предположений. Если такое влияние и ограничения игнорировать, то могут возникнуть серьезные расхождения между представлением мира в программе и реальностью. Системы, располагающие механизмом отслеживания зависимостей между предположениями и выявления их несовместимости, получили название систем отслеживания истинности предположений (truth maintenance systems). В литературе можно встретить и аналогичный по смыслу термин система отслеживания причинности (reason maintenance systems).
В этой главе мы в общих чертах представим вычислительные методы, которые используются для отслеживания зависимостей между представлением в программе состояний, действий и предположений. Начнем мы с относительно простых систем, затем перейдем к более сложным. Там, где без этого можно обойтись, мы будем пренебрегать строгими математическими формулировками и заменять их менее формальным описанием того, что делается в системе, почему делается именно так и какую пользу из этого можно извлечь.
19.1. Отслеживание зависимостей
В главе 15 рассказывалось о том, что в экспертной системе VT для фиксации зависимостей между решениями, принимаемыми в процессе проектирования, используется сеть зависимостей. В такой сети узлы соответствуют присвоению значений конструктивным параметрам, причем между узлами существуют два вида связей— связи содействия (contributes-to) и связи принуждения (constrains). Узел А содействует узлу В, если значение параметра А появляется в результате вычисления значения В, а узел А принуждает узел В, если значение параметра A запрещает параметру В принимать определенные значения. В дальнейшем для некоторой формализации изложения будем обозначать узлы прописными буквами, а строчными— значения соответствующих параметров. Например, значение, присваиваемое узлу (параметру) А в какой-либо момент времени, будем обозначать как а
19.1.1. Релаксация в сети
Основное назначение связей в сети зависимостей состоит в том, чтобы, во-первых, показать, как изменение значения какого-либо параметра распространяется от узла к узлу, а во-вторых, выявить противоречия между значениями, присвоенными разным узлам.
Пусть, например, в сети имеются узлы А и М. Узел А представляет ускорение некоторой детали механизма, а М— массу этой детали. Оба узла, А и М, содействуют узлу F, который представляет силу, действующую на деталь. Более того, учитывая знакомую всем со школьной скамьи формулу f= та, узлы А и М также и принуждают узел F, поскольку если а и т известны, то значение f определяется этой формулой и не может быть произвольным, т.е. если а - 2 и от = 3, то мы можем присвоить узлу F только значение f= 6. Если же этому узлу уже ранее было присвоено значение f= 7, то сеть переходит в состояние противоречия.
Формула f= та играет роль принудительного ограничения для сети, описанной в этом примере. Если все ограничения в сети удовлетворяются, то она пребывает в состоянии релаксации. Рассмотрим варианты сетей, представленные на рис. 19.1. Сеть а) находится в промежуточном состоянии, поскольку узлу F не присвоено какого-либо определенного значения, сеть б) находится в состоянии релаксации, а сеть в) — в состоянии противоречия.
Строго говоря, термин "релаксация" относится к сети, а не к теории13. Но сеть есть не что иное, как только представление определенной теории, например сеть а) является представлением теории
f= mа
т=3
а = 2,
в которой формула f= та играет роль принудительного ограничения. Сеть б) представляет теорию
f= mа
т=3
а = 2
f=6,
которая находится в состоянии релаксации по отношению к ограничению f= та, а сеть в) представляет противоречивую теорию
f= mа
т=-3
а = 2
f=7.
По ходу изложения, не оговаривая отдельно, мы будем "перескакивать" от сетей к теориям, а для простоты использовать термин "представление", если нежелательно подчеркивать различие между этими двумя способами-реализации фактов и ограничений.
а
б
с
Рис. 19.1. Сети зависимостей с принудительными ограничениями. Окружностями представлены узлы сети, а прямоугольниками — связи
19.1.2. Пересмотр допущений
Практически во всех программах экспертных систем в процессе решения проблемы обязательно тем или иным образом обновляются представления реального мира вещей, с которыми эта программа имеет дело (например, так происходит в программе планирования поведения роботов STRIPS, которую мы рассматривали в главе 3). В программах с разным уровнем "интеллектуальности" для пересмотра допущений в этом представлении применяются более или менее сложные методы. В литературе можно найти такую классификацию этих методов.
(1) Монотонный пересмотр (monotonic revision). Это самый простой метод, при котором программа принимает информацию о новых фактах и вычисляет, как эти факты могут повлиять на имеющееся представление, чтобы оно перешло в результате в состояние релаксации. При этом предполагается учитывать "важные" последствия, хотя определить, какие последствия важные, а какие не очень, зависит от уровня интеллектуальности программы. Например, к важным скорее будет отнесен вывод q из р и (рq), чем вывод (pvq) из q. "Монотонным" этот способ пересмотра называется по той причине, что правдоподобность допущений в результате его применения по крайней мере не уменьшается.
(2) Немонотонный пересмотр (nonmonotonic revision). Иногда бывает желательно "взять назад" принятые ранее допущения и урезать сделанные на их основе заключения. Если я вижу вас за рулем "Мерседеса", то первое предположение — что он ваш собственный, а следовательно, вы, мягко говоря, человек не бедный. Но если через некоторое время я узнаю, что вы его, пользуясь терминологией Гека Финна, "позаимствовали", то я должен буду отбросить не только предположение, что он ваш собственный, но и предположение о вашем богатстве.
(3) Немонотонное обоснование (nonmonotonic justification). Дальнейшее усложнение метода происходит в тех программах, в которых определенные предположения полагаются истинными в том случае, когда нет никаких явных свидетельств против такого предположения. Например, программа может предполагать, что все студенты малообеспечены. Отказ от такого предположения в отношении определенного студента выполняется в программе только в том случае, если на лицо явные признаки более чем среднего материального благополучия. Здесь именно отсутствие информации, противоречащей первоначальному допущению, а не наличие подтверждающей информации является обоснованием его правдоподобия.
(4) Гипотетическое суждение (hypothetical reasoning). В программе можно сначала принять во внимание определенные предположения, а затем посмотреть, что из них следует. Далее из этих предположений можно отобрать правдоподобные допущения. Таким образом, в этом способе предполагается формировать рассуждения в разных мирах, т.е. в таких состояниях представления о реальной области знаний, которые могут соответствовать или не соответствовать реальности. Отслеживание множества теорий такого вида требует определенных дополнительных ресурсов по сравнению с методами, предполагающими исследование единственной теории.
Методы первой из перечисленных категорий довольно тривиальны: нужно добавить в имеющуюся теорию новую информацию и некоторые дополнительные факты, которые необходимы, чтобы перевести новую теорию в состояние релаксации по отношению к имеющимся ограничениям. Простой метод, демонстрирующий реализацию второй из перечисленных категорий, мы рассмотрим в следующем разделе, а в разделах 19.3 и 19.4 рассмотрим методы третьей и четвертой категорий.
19.1. Запись информации о связях
Программой на языке CLIPS несложно проиллюстрировать простую процедуру записи зависимостей между данными в продукционной системе с прямой цепочкой вывода. Если в рабочей памяти имеются только два типа выражений — выражения импликации типа "Р имплицирует Q" и атомы, такие как "Р" и "Q", — то можно зафиксировать зависимости между элементами рабочей памяти в виде извлеченных из них характеристик влияния. Объекты литералов имеют поля support, в которых записывается, какие выражения используются для вывода этих литералов. Может оказаться так, что некоторые литералы не имеют соответствующих выражений, поскольку представляют собой предположения, формируемые при инициализации рабочей памяти на основе конструкций def facts. В поле support таких литералов устанавливается значение -1. И литералы, и выражения импликации имеют нумерованные идентификаторы, которые позволяют отслеживать их состояние посредством специальных списков.
;; ШАБЛОНЫ
;; Литерал - атомарное высказывание,
(deftemplate literal (field id (type INTEGER))
(field atom (type SYMBOL))
(multifield support (type INTEGER) (default -1))
| )
Условие является импликацией в форме
;; "Р имплицирует Q", где "P" является левой частью правила
;; (left-hand side = Ihs),
;; "Q" - правой частью
;; (right-hand side = rhs).
(deftemplate conditional
(field Id (type INTEGER))
(multifield Ihs (type SYMBOL))
(multifield rhs (type SYMBOL)) )
;; Нам понадобится индекс в рабочей памяти, чтобы
;; можно было присваивать идентификаторы новым
;; производным высказываниям, (deftemplate index
(field no (type INTEGER)) )
;; Исходная модель мира. (deffacts model
(conditional (id 0) (Ihs P) (rhs Q);
(literal (id 1) (atom P)) )
;; ПРАВИЛА
;; Присвоить значение индекса очередному идентификатору,
(defrule init
?F <- (initial-fact)
(literal (id ?N))
(not (literal (id ?M&:{> ?M ?N)))) =>
(assert (index (no (+ ?N 1))))
(retract ?F) )
;; Применить правило modus ponens, чтобы можно было
;; вывести "Q" из "Р" и "Р имплицирует Q", формируя
;; указатели на "Р" и "Р имплицирует Q" в попе
;; support литерала "Q". (defrule mp ?I <- (index (no ?N))
(conditional (id ?C) (Ihs $?X) (rhs $?Y)) (literal (id ?A)
(atom $?X)) (not (literal (atom $?Y)))
(assert (literal (id ?N) (atom $?Y) (support ?C ?A)))
(modify ?I (no (+ ?N 1)))
Эта примитивная программа имеет дело только с условными выражениями и атомами. Например, нельзя, используя правило modus fallens (см. главу 8), вывести "не Р" из "Р имплицирует Q" и "не Q".
19.2. Пересмотр теорий высказываний
Систему отслеживания истинности предположений, разработанную Мак-Аллестером [McAllester, 1980], нельзя отнести к самым первым, но ее, пожалуй, лучше всего использовать в качестве наглядного пособия. Использованный им метод пересмотра предполагает наличие в системе базы данных утверждений, в которой пользователь может квалифицировать формулы как "истинные", "ложные" или "неопределенные". Таким образом, в основе метода лежит трехзначная логика, в отличие от классической двузначной, которую мы рассматривали в главе 8. Система представляет утверждения в виде узлов, которые хранят соответствующие значения.
Ограничения, которые накладывает на содержимое базы данных утверждений система отслеживания истинности, представляют собой фундаментальные аксиомы логики высказываний. Например, аксиома
¬(U^¬U)
утверждает, что высказывание U может быть одновременно и истинным, и ложным. (Учтите, что -U является метапеременной, которая представляет любое высказывание.) Система отслеживания истинности предположений, разработанная Мак-Аллестером, как и большинство других подобных систем, имеет дело только с формулами, которые не содержат кванторов. Например, в теорию может входить высказывание DEAD(fred), но не может входить (любой X)(DEAD(X)). Это ограничение существует по той простой причине, что не всегда возможно установить совместимость теории первого порядка, как это отмечалось в главе 8.
Система отслеживания истинности выполняет по отношению к базе данных четыре функции.
(1) Реализует множество дедукций высказываний, которые Мак-Аллестер назвал распространением пропозициональных принуждений (propositional constraint propagation).
(2) Формирует обоснования при присвоении высказываниям значений истинности, когда такое присвоение выполняется в результате распространения принуждений (а не при установке значения пользователем). Таким образом, если мы приходим к заключению, что q истинно, поскольку истинны p и (pq), то р и (pq) образуют часть обоснования для q.
(3) Обновляет базу данных утверждений, как только какое-либо высказывание удаляется. Так, если мы приходим к выводу, что q истинно, поскольку истинны р и (pq), а затем удаляем р, то нужно соответственно и "дезавуировать" относящееся к q обоснование {р, (pq)}, и аннулировать сделанное ранее присвоение q до тех пор, пока истинность этого высказывания нельзя будет вывести из других высказываний, остающихся в базе данных.
(4) Отслеживает цепочку предположений, которые привели к противоречию, с помощью метода, получившего наименование обратное прослеживание, ведомое зависимостями (dependency-directed backtracking). После этого пользователю предлагается удалить одно из предположений, "виновных" в появлении противоречия.
Задавшись предположениями р и (— p v q) и пользуясь механизмом распространения принуждений, система отслеживания истинности может получить q. Затем она формирует поддерживающую структуру, представленную на рис. 19.2. Каждый узел в этой сети представляет собой фрейм (см. о фреймах в главе 6) с набором слотов, один из которых хранит наименование узла, другой — значение истинности, а третий — указатель на обоснование. Обоснование представлено другим фреймом, который содержит таблицу поддерживающих высказываний и их значения истинности. В структуре на рис. 19.2 истинность узла q подтверждается тем фактом, что узлы, представляющие р и (— p v g), отмечены как имеющие значения "истина". Обратите внимание на то, что узлы, представляющие предположения, как, например, р, не имеют указателей на фреймы обоснования, поскольку они полагаются истинными по определению.
Если в дальнейшем окажется, что значение q несовместимо с содержимым остальной базы данных утверждений, то, анализируя описанную структуру данных, можно будет выйти на фреймы обоснования. После этого пользователю будет предоставлена возможность проследить цепочку зависимостей, связанную либо с р, либо с (-p v q). Для выполнения такого отслеживания очень важно, чтобы структуры поддержки были убедительными. Убедительность структуры означает отсутствие зацикливания, т.е. отсутствие такой ситуации, когда некоторое высказывание не подтверждает через "посредников" само себя.
Обратите внимание — все утверждения являются либо предположениями, введенными пользователем, либо обосновываются наличием других утверждений. В следующем разделе мы рассмотрим другую, более сложную систему отслеживания истинности предположений, в которой допускается использовать в качестве обоснования отсутствие запрещающей информации.
Рис. 19.2. Структура представления связей между высказываниями
19.3. Немонотонное обоснование
Подход, предложенный Дойлом [Doyle, 1979], отличается от того, который применил Мак-Аллестер. Он основан на философии "здравого смысла", в частности на презумпции значения по умолчанию. В первом приближении, помимо хранения допущений, подтвержденных какими-либо свидетельствами, хранятся также допущения, основанные на резонном предположении, т.е. допущения, свидетельства против которых отсутствуют.
Обоснования (или, пользуясь терминологией Доила, резоны) в пользу допущения Р представляют собой упорядоченную пару списков (INP, OUTp ). Список INp— обычные обоснования в форме, которая аналогична использованной Мак-Аллестером. Он содержит высказывания, истинность которых является необходимым условием истинности Р. Список OUTp содержит высказывания, присутствие которых во множестве допущений указывает на ложность Р. Это множество получило название множества немонотонных обоснований (nonmonotonic justification), поскольку добавление высказывания в него потребует отказаться от сделанного ранее допущения. В подходе, который рассматривался Мак-Аллестером, этот вариант не анализировался.
Пусть, например, обоснование для значения р имеет вид
({}, {-p}).
Это означает, что можно предполагать наличие р до тех пор, пока это обоснование не станет ложным. Обоснование для q пусть имеет вид
({p}, {r}).
Такое обоснование означает, что можно предполагать наличие q до тех пор, пока высказывание р присутствует в множестве текущих допущений (в терминологии Доила — получает статус поддержки (support status) "включено" — in), а высказывание r отсутствует в множестве допущений (в терминологии Доила — получает статус поддержки "исключено" — out). Обратите внимание на то, что обоснования могут быть связанными, как в приведенном выше примере. Если -р имеет статус исключено, то, следовательно, р имеет статус включено, а тогда и q имеет статус включено до тех пор, пока r имеет статус исключено.
Такая цепочка причинно-следственных связей называется SL-обоснованием (SL — сокращение от support list). Общее правило для SL-обоснований гласит, что допущение Р присутствует в текущем множестве допущений только в том случае, если каждое из допущений, перечисленных в списке IN, имеет статус включено, а каждое из допущений, перечисленных в списке OUT, имеет статус исключено.
Дуальная структура обоснований, предложенная Дойлом, может быть использована для разделения допущений на три группы.
(1) Посылки (premises), т.е. высказывания, которые полагаются истинными без всякого обоснования (по определению). Пользуясь обозначениями из теории множеств, можно следующим образом представить определение посылки:
{Р В | INp= OUTp = не существует } .
(2) Дедукции (deductions), т.е. высказывания, которые являются заключениями нормальной монотонной дедукции. В обозначениях теории множеств дедукции представляются выражением
(2) Проверить консеквенсы данного узла. Если таковых не существует, то изменить статус узла с исключено на включено, сформировать связанные с ним списки IN и OUT и на этом закончить. В противном случае сформировать список L, в который включить узел и его множество последствий, зафиксировать статус включено-исключено каждого из этих узлов, временно присвоить им статус nil и перейти к шагу (3).
(3) Для каждого узла N из списка L попытаться отыскать действительное и убедительное обоснование, которое позволяет изменить статус этого узла на включено. Если таковое найдено не будет, присвоить узлу статус исключено. В любом варианте изменения статуса узла распространить это изменение на его консеквенсы. (Примечание. Обоснование является действительным, если каждый узел, перечисленный в его списке IN, имеет статус включено, а каждый узел, перечисленный в списке OUT, — статус исключено. Обоснование является убедительным в том случае, когда в его логической цепочке отсутствует зацикливание. Например, обоснования ({-Р},{}) и ({},{Р}) являются зацикленными по отношению к Р. Из первого следует, что Р имеет статус включено только в случае, если —P также имеет статус включено, а из второго следует, что Р имеет статус включено только в случае, если Р имеет статус исключено. Таким образом, каждое обоснование, если применить его в отношении высказывания Р, приводит к противоречию.)
(4) Если некоторый узел в списке L имеет состояние включено и отмечен как противоречивый, то запустить процедуру обратного прослеживания, ведомого зависимостями (dependency-directed backtracking). Если в процессе выполнения этой процедуры вновь возникнут условия для запуска процесса отслеживания истинности предположений (шаги (1)-(3)), повторять эти шаги до тех пор, пока не будут разрешены все противоречия.
(5) Сравнить текущий статус поддержки каждого узла из списка L с его прежним статусом, зафиксированным ранее, и известить пользователя обо всех произведенных изменениях статуса.
Обе системы — и Мак-Аллестера, и Доила — демонстрируют более "интеллектуальный" подход к решению проблемы адекватного и непротиворечивого описания мира, чем тот, который был использован в рассмотренной ранее системе STRIPS (см. главу 7). В обоих случаях системы отслеживания истинности предположений берут на себя заботы об обновлении модели мира посредством распространения аналогов операций ADD и DELETE по сети зависимостей. Если при этом обнаруживается, что в модели возникли противоречия, пользователю предлагается отказаться от какой-либо из посылок, которые послужили причиной такого противоречия, и восстановить тем самым целостность модели.
19.2. Пара конфликтующих выражений
Приведенная ниже программа на языке CLIPS реализует простой алгоритм отслеживания истинности предположений по отношению к простым атомарным выражениям. Литералы являются атомарными высказываниями, имеющими статус либо включено, либо исключено. Список inlist некоторого выражения включает те выражения, которые должны иметь статус включено для того, чтобы и данное выражение имело статус включено. Список outlist некоторого выражения включает те выражения, которые должны иметь статус исключено, для того, чтобы данное выражение имело статус включено. Как и ранее, пустые списки поддержки по умолчанию имеют значение -1.
;; ШАБЛОНЫ
;; Литерал - атомарное высказывание.
(deftemplate literal (field id (type INTEGER})
(field atom (type SYMBOL))
(field status (type SYMBOL) (default unk))
(multifield inlist (type INTEGER) (default -1))
(multifield outlist (type INTEGER) (default -1))
)
;; Исходная модель мира.
(deffacts model
(literal (id 0) (atom P) (status in) (outlist 1) )
(literal (id 1) (atom Q) (status in) (outlist 0) )
)
;; ПРАВИЛА
;; Если выражение в списке outlist
;; выражения S имеет статус out
;; и выражение S имеет пустой список inlist,
;; то присвоить выражению S статус in.
(defrule in
(literal (id ?A) (status out)) ?F <-
(literal (status out) (inlist -1) (outlist ?A))
=> (modify ?F (status in))
)
Если выражение в списке outlist выражения S имеет статус in, то присвоить выражению S статус out. Обратите внимание на то, что в этом правиле наличие списка inlist для выражения S не имеет значения,
(defrule out
(literal (id ?A) (status in)) ?F <-
(literal (status in) (outlist ?A)) =>
(modify ?F (status out)) )
;; Это правило предлагает пользователю удалить
;; выражение и таким образом уладить конфликт,
(defrule deny
(declare (salience -10))
?L <- (literal (atom ?X) (status in) (inlist -1)) =>
(printout t crlf "Deny " ?X "? ")
(bind ?ans (read)) (if (eq Pans yes)
then (modify PL (status out)))
;; Что произойдет после того, как вы
;;запустите эту программу на выполнение?
;;Как ! будет вести себя программа, если
;;в ответ на запрос, сформированный правилом
;; deny, ввести yes? Как будет
;;вести себя программа, получив ответ по?
19.4. Работа со множеством контекстов
Те системы отслеживания истинности предположений, которые мы рассматривали в предыдущих разделах, работали с единственной непротиворечивой моделью мира. Однако иногда возникает необходимость строить логический вывод в контексте разных моделей гипотетических миров, которые могут совпадать, а могут и не совпадать с реальностью (см. главу 17). Например, при решении задачи диагностирования часто бывает полезно предположить, что возникла какая-то ошибка, и выдвинуть предположение на основе какого-нибудь допущения, а затем посмотреть, не подтверждается ли оно имеющимися фактами. Особенно уместна такая стратегия в ситуации, когда результаты наблюдений дают пищу для множества конкурирующих гипотез и скорее всего потребуется какая-либо комбинация гипотез, чтобы объяснить всю совокупность наблюдений. Другая область применения, в которой потребуется рассмотреть несколько вариантов модели мира, — проектирование. Вот тут-то уж точно потребуется несколько гипотетических "миров", чтобы представить разные варианты конструкции, удовлетворяющей заданным ограничениям
19.4.1. Отслеживание истинности предположений, основанное на анализе допущений
В системах отслеживания истинности предположений, основанных на анализе допущений {assumption-based truth-maintenance system), программа имеет дело с несколькими отличающимися контекстами, которые принято называть средами обитания (environments) [De Kleer, 1986]. Удобнее всего представить себе среду обитания как взгляд на мир через призму определенных допущений. Можно считать, что модель мира, которая использовалась в предыдущих разделах, характеризуется пустым множеством допущений. Все прочие среды, имеющие непустое множество допущений, представляют модели гипотетических миров.
В системах отслеживания истинности предположений, основанных на допущениях, различные варианты сред обитания можно организовать в виде решетки, поскольку допущения носят инкрементальный характер. Модель, показанная на рис. 19.3, представляет на самом нижнем уровне автомобиль, в котором не горит свет и который не удается завести. На более верхнем уровне решетки находятся гипотетические миры, в которых сделаны некоторые допущения о неисправностях в автомобиле, например разряжена аккумуляторная батарея. На еще более высоком уровне можно комбинировать сделанные допущения. Обратите внимание — чем выше мы поднимаемся "по ступеням решетки", тем более специфическими становятся гипотетические миры в том смысле, что мы характеризуем их все полнее.
Не всегда можно делать произвольные допущения. Например, нельзя объединить допущения {p,q} и {—p,r}, поскольку такая комбинация будет противоречивой. Более того, хотя само множество допущений может и не быть антагонистическим, определенные комбинации допущений могут привести к противоречию, если принять во внимание и другую имеющуюся в нашем распоряжении информацию.
Предположим, что наша модель неисправного автомобиля содержит информацию о том, что одновременно не может случиться так, чтобы и карбюратор не работал из-за избытка топлива, и в баке отсутствовал бензин. Следовательно, в том варианте среды, в котором сделано допущение "в баке отсутствует бензин", не может присутствовать допущение "избыток топлива в карбюраторе". Такое логическое заключение образует контекст среды — множество высказываний, производных от сделанных допущений, и фактов, имеющихся в исходной модели мира. Например, мы можем оказаться в ситуации, представленной схематически на рис. 19.4. Здесь среда, образованная в результате объединения двух допущений, должна быть исключена из рассмотрения, поскольку ее контекст становится несовместимым (nogood).
Рис. 19.3. Решетка сред
Приведенный выше пример может служить наглядной иллюстрацией того очевидного факта, что имеющуюся теорию мира (предметной области) допускается расширять, только принимая во внимание "фоновые" знания об этой предметной области. Другими словами, между отдельными допущениями существуют определенные зависимости, которые мы должны каким-либо образом зафиксировать и не нарушать.
В системах отслеживания истинности предположений, основанных на анализе допущений, такие зависимости называются обоснованиями (justification). Конечно, такая вольная трактовка термина "обоснование" вносит некоторую неоднозначность в изложение материала (ранее мы придавали этому термину несколько другой смысл), но дело в том, что обоснование в тех системах, которые рассматриваются в данном разделе, играет роль, отличную от обоснований в простых системах отслеживания истинности, анализированных Мак-Аллестером и Дойлом. В тех системах обоснования формировались программой в результате распространения принуждений и связывались с узлами сети зависимостей, которые представляли высказывания.
Рис. 19.4. Решетка сред, в которой выделен несовместный контекст
В системах отслеживания истинности предположений, основанных на анализе допущений, обоснования являются частью исходной информации, которой программа располагает в момент запуска на выполнение. Затем система для каждого узла высказывания формирует ярлык (label), который содержит список сред, имеющих отношение к этому высказыванию ("интересующих" это высказывание). Ниже мы увидим, что скрывается за этим "интересом", но сначала рассмотрим пример.
На рис. 19.4 отрицание высказывания "Нет бензина в баке" существует в среде, в которой сделано допущение "Избыток топлива в карбюраторе", причем в модели имеется обоснование, которое гласит примерно следующее:
"Если в карбюраторе имеется избыток топлива, то бензин не может отсутствовать в баке".
Теперь интересующее нас высказывание будет "по наследству" истинно и в несовместимом контексте, но такая среда не представляет интереса для этого высказывания и, следовательно, в список ярлыка не включается.
Предположим также, что в модели имеется обоснование
"Если свечи влажные, то бензин не может отсутствовать в баке".
В этом случае отрицание высказывания "Нет бензина в баке" имеет место в среде, в которой сделано допущение "Влажные свечи", как показано на рис. 19.5. Эту среду уже имеет смысл включить в список ярлыка. Теперь ярлык интересующего нас высказывания будет содержать список, в котором перечислены два варианты среды, причем каждый из вариантов не содержит противоречий. На рисунке эти варианты среды заштрихованы. Как и ранее, варианты, представляющие несовместимый контекст (на рисунке они выделены прямоугольниками с утолщенными линиями контура), мы будем игнорировать.
Рис. 19.5. Решетка сред, в которой узлы, имеющие непустые списки ярлыков,заштрихованы
Очевидно, что высказывание также будет иметь место и в комбинированной среде, которая образуется совмещением обоих допущений, или в любой другой комбинированной среде, образованной в результате добавления к исходным каких-либо других допущений. Однако вряд ли имеет смысл фиксировать этот факт в списке ярлыка. В этот список желательно включать только те варианты среды, которые характеризуются минимальным множеством допущений, необходимых для истинности высказывания.
Таким образом, из всего сказанного выше вытекает, что основная забота системы отслеживания истинности предположений, основанной, на анализе допущений, состоит в формировании списка сред для узлов высказываний. Такой список может быть созвучным (sound), завершенным (complete), совместимым (consistent) или минимальным (minimal) ярлыком. В эти термины вкладывается следующий смысл.
Ярлык является созвучным, если высказывание, к которому он относится, является производным от каждой среды, включенной в этот ярлык, т.е. оно имеет статус включено в контексте каждой такой среды.
Ярлык является завершенным, если любая непротиворечивая среда, в которой имеет место соответствующее высказывание, либо присутствует в списке, либо образована включением дополнительных допущений в ту среду, которая присутствует в списке.
Ярлык является совместимым, если любая среда, включенная в список, является непротиворечивой.
Ярлык является минимальным, если ни одна среда, включенная в список, не образуется добавлением какого-либо допущения к той среде, которая также присутствует в списке.
Если узел высказывания в сети имеет пустой ярлык, это означает, что высказывание не является производным ни от какого совместимого множества допущений. Другими словами, это высказывание не может быть истинным ни при каких совместимых комбинациях допущений. Например, ярлык узла, соответствующего высказыванию "отсутствует бензин в баке и влажные свечи", будет иметь пустой список.
19.4.2. Использование систем отслеживания истинности предположений для диагностирования на основе моделей
Выше, в главах 11 и 12, были рассмотрены экспертные диагностические системы, в которых использовался метод эвристической классификации. Этот метод предполагает, что большая часть знаний представлена в виде эвристических правил, связывающих абстрактные категории данных (типичные симптомы) с абстрактными категориями решений (типичные неисправности). Такая форма представления знаний иногда называется "поверхностной", поскольку знания не содержат информации о причинных связях между симптомами и неисправностями (теорию функционирования диагностируемого объекта — машины или живого организма), а отражают только эмпирический опыт. Информация о причинно-следственных связях, определяющих поведение и свойства диагностируемого объекта, принято называть "глубинным" знанием.
Диагностирование, основанное на моделях анализируемых объектов, использует не столько эмпирический опыт эксперта, сколько более или менее полную и непротиворечивую теорию корректного поведения этих объектов. Идея состоит в том, чтобы, располагая на входе данными о наблюдаемых отклонениях в поведении, высказать предположение об одном или нескольких возмущениях в описании системы, которые могли бы объяснить эти отклонения.
Очевидные преимущества подхода, при котором сначала принимаются во внимание знания о принципах поведения объекта, а уже затем эмпирические знания, состоят в следующем.
Располагая информацией о принципах структурной организации объекта и причинно-следственных связях между свойствами его компонентов и наблюдаемыми проявлениями, разработчик программы может значительно сократить трудоемкий процесс извлечения эмпирических знаний эксперта.
Используемый метод анализа причинно-следственных связей не зависит от самого анализируемого объекта, а следовательно, отпадает необходимость в трудоемкой настройке механизма логического вывода для каждого отдельного приложения.
Поскольку требуется знание только о корректном поведении объекта, потенциально метод должен сработать и при диагностировании неисправностей, которые ранее не возникали и незнакомы эксперту-человеку.
Прототипом подобного рода диагностических экспертных систем можно считать программу DART [Genesereth, 1984]. Хотя предметной областью, для которой предназначалась эта программа, является анализ цифровых схем, но использованные в ней язык представления знаний и механизм логического вывода более или менее независимы от этой предметной области. Для представления описания конструкции диагностируемого устройства используются формализм исчисления предикатов и форма доказательства теорем, с помощью которых формируются множества "подозрительных" компонентов и тестов, призванных подтвердить или опровергнуть гипотезы о причинах неисправностей. Метод решения проблем, использованный в DART, опирается на три упрощающих допущения.
(1) Предполагается, что связи между компонентами функционируют правильно, и задача состоит в том, чтобы отыскать те компоненты, неисправность которых может объяснить наблюдаемые симптомы неправильной работы устройства.
(2) Отказы не носят случайного во времени характера, т.е. все компоненты в процессе выполнения диагностических тестов работают стабильно (правильно или неправильно — это уже другой вопрос).
(3) В устройстве имеется единственный отказ.
Каждое из этих предположений, конечно же, очень ограничивает возможность практического применения системы, но в работе [De Kleer and Williams, 1987] было показано, что использование систем отслеживания истинности предположений, основанных на анализе допущений, поможет снять третье из перечисленных ограничений. Это было продемонстрировано в программе GDE (General Diagnostic Engine — система диагностирования общего назначения).
В системе диагностирования, допускающей наличие нескольких неисправностей в устройстве, приходится иметь дело с экспоненциальным ростом пространства гипотез. Чтобы преодолеть возникающие при этом сложности, нужно формировать гипотезы в определенном порядке, принимая во внимание их "конструктивность", а затем выполнять такие процедуры тестирования, которые позволят выбрать из набора конкурирующих гипотез наиболее подходящую, проведя при этом минимальное количество дополнительных измерений. Реализуется такой процесс с помощью комбинации методов отслеживания истинности предположений, основанных на анализе допущений, и методов вероятностного логического вывода.
Как было показано ранее в этом же разделе, методы отслеживания истинности предположений, основанные на анализе допущений, имеют дело с решеткой сред — альтернативных состояний модели мира, которые согласуются с некоторой теорией, но используют при этом отличающиеся допущения. В диагностических приложениях такой неявной теорией является описание диагностируемого устройства, а альтернативные состояния модели мира характеризуются различными комбинациями отказавших компонентов устройства. Если устройство состоит из п компонентов, то теоретически может существовать 2" комбинаций отказов компонентов. Решетка вариантов сред является перечислимым множеством присоединений: элемент с наименьшим номером соответствует отсутствию отказов в компонентах, а элемент с наибольшим номером — отказу всех компонентов устройства. Каждая такая среда называется кандидатом, т.е. гипотезой о том, что именно произошло в неисправном устройстве. Вся решетка сред при такой постановке проблемы будет представлять собой пространство кандидатов.
Если устройство работает нормально, то гипотеза, соответствующая кандидату' с наименьшим номером, прекрасно "объясняет" наблюдаемую ситуацию. Если наблюдаются какие-либо отклонения от нормального функционирования устройства, то наблюдаемые проявления можно считать свидетельствами в пользу той или иной гипотезы в пространстве кандидатов. Поскольку объем этого пространства связан с количеством компонентов в анализируемых устройствах экспоненциальной зависимостью, необходимо использовать в нем какой-либо метод эффективного поиска кандидатов.
Ключевым понятием для такого метода должно быть конфликтующее множество — множество таких компонентов, которые в данной ситуации (т.е. при данных симптомах) не могут одновременно быть исправными. Конфликтующее множество, таким образом, это именно то множество допущений, которое в системе отслеживания истинности предположений, основанной на анализе допущений, формирует среды, несовместимые с данными. Их можно определить, формируя дедуктивное замкнутое выражение для среды и данных, а затем выискивая в нем противоречие. Главная цель системы отслеживания истинности предположений состоит при этом в том, чтобы идентифицировать все минимальные конфликтующие множества. После этого можно определить минимальное множество отказавших компонентов, которое объяснит все наблюдаемые проявления ненормальной работы устройства.
В качестве простого примера рассмотрим решетку сред, представленную на рис. 19.6. В этой решетке C1, C2 и СЗ— компоненты анализируемого устройства. Пусть S — множество наблюдаемых проявлений ненормальной работы этого устройства. Предположим, нам известно, что если наблюдается множество проявлений S, то С1 и С2 не могут быть исправными одновременно, а также С1 и СЗ. Тогда можно выделить среды, помеченные на схеме решетки значками 0, С2 и СЗ (они выделены на схеме как несовместные). Каждая из этих сред имеет какое-либо запрещенное сочетание исправных компонентов. Все другие среды являются кандидатами в пространстве гипотез, но очевидно, что минимальные множества среди них — (С1} и {С2, СЗ}.
В системе отслеживания истинности предположений используется несколько стратегий управления обработкой пространства кандидатов, например:
стратегия, основанная на предоставлении преимущества тем гипотезам, которые поясняются проще всего; поиск решения начинается с минимальных по объему (количеству элементов) конфликтных множеств;
сохранение в системе просмотренной цепочки логического вывода, что позволяет исключить ее повторный просмотр.
В системе GDE также используется мера неопределенности, основанная на теоретико-информационном подходе, с помощью которой выясняется, какие измерения следует выполнить в анализируемой системе. Наилучшей полагается такая измерительная процедура, которая минимизирует энтропию (см. об этом в главе 20), т.е. та, которая вносит наибольшее разнообразие в набор значений вероятностей кандидатов. Предполагается, что априорная вероятность отказа отдельных компонентов известна и что отказы компонентов в вероятностном смысле независимы. Эти же вероятности используются при определении порядка формирования гипотез-кандидатов.
Рис. 19.6. Решетка сред, представляющая пространство кандидатов. Несовместные контексты выделены утолщенным контуром, а минимальные кандидаты заштрихованы
19.5. Сравнение различных вариантов организации систем отслеживания истинности предположений
Функции компонента отслеживания истинности предположений в контексте более общей программы поиска решения проблемы можно сформулировать следующим образом:
кэшировать логический вывод, выполненный решателем проблем, чтобы однажды сформулированное заключение не пришлось выводить повторно;
предоставить в распоряжение решателя проблем средства формирования конструктивных допущений и анализа полезности заключений, выведенных на основе таких допущений;
анализировать и устранять возможные противоречия в моделях среды.
Подходы к построению системы отслеживания истинности предположений, предлагаемые Дойлом и Мак-Аллестером, можно использовать для нахождения единственного решения проблемы, удовлетворяющего заданным ограничениям. Прекрасным примером использования этого подхода на практике является экспертная система VT, описанная в главе 15,
Если же необходимо отыскать несколько вариантов решения или все возможные решения, понадобится более сложный механизм отслеживания. Работа с единственным состоянием сети зависимостей не позволяет выполнять сравнение альтернативных вариантов решения проблемы. Например, при выполнении дифференциального диагностирования желательно сравнивать конкурирующие гипотезы, поскольку среди них может оказаться такая, которая позволит объяснить все наблюдаемые проявления.
Подход, предложенный Де Клером, ориентирован именно на отыскание всех вариантов решения, удовлетворяющих заданным ограничениям. Если среди всех возможных решений система должна будет выбрать "наилучшее" по какому-либо критерию, понадобится оснастить ее дополнительным механизм управления
Рекомендуемая литература
Сети зависимостей рассматриваются в работе [Charniak et al., 1987]. Статьи [De Kleer, 1986] и [Doyle, 1979] довольно сложные для неподготовленного читателя, а потому я бы посоветовал начинать углубленное изучение этой темы с работы [Forbus and De Kleer, 1993]. В этой же книге вы найдете и листинги множества программ, которые демонстрируют использование описанных в ней методов. Читатели, интересующиеся теоретическим обоснованием методов отслеживания истинности предположений, могут найти много интересного для себя в книге [Ginsberg, 1987] и сборнике статей [Martins and Reinfrank, 1991].
Упражнения
1. Как вы понимаете смысл термина "релаксация" по отношению к сетям зависимостей?
2. Поясните отличие между монотонным и немонотонным пересмотром.
3. Если ({},{¬^р}) является причиной для и ({},{->р}) — причиной для q, что произойдет с р и q, если добавить ¬р в базу данных немонотонной системы отслеживания истинности?
4. Если ({
5. Заполните значения истинности г в структуре поддержки системы Мак-Аллестера, представленной на рис. 19.7.
Рис. 19.7. Структура представления связей между высказываниями для упр. 5
6. Рассмотрите набор обоснования для системы отслеживания истинности предположений, основанной на анализе допущений:
р^ qr
¬р^qs
р^¬qt
¬p^¬qu
7. Положим, что существуют четыре возможных допущения, которые можно использовать по отдельности или в сочетании друг с другом: р, —р, q и —q. Какие варианты сред для этого множества обоснований при таких допущениях будут непротиворечивыми?
ГЛАВА 20. Формирование знаний на основе машинного обучения
20.1. Индуктивное обучение
20.2. Система Meta-DENDRAL
20.2.1. Формирование и уточнение правил
20.2.2. Пространство версий
20.2.3. Алгоритм отсеивания кандидатов
20.2.4. Сопоставление экземпляров с образцами в Meta-DENDRAL
20.3. Построение дерева решений и порождающих правил
20.3.1. Структура дерева решений
20.3.2. Алгоритм формирования дерева решений по обучающей выборке
20.4. Уточнение наборов правил
Рекомендуемая литература
Упражнения
ГЛАВА 20. Формирование знаний на основе машинного обучения
20.1. Индуктивное обучение
20.2. Система Meta-DENDRAL
20.3. Построение дерева решений и порождающих правил
20.4. Уточнение наборов правил
Рекомендуемая литература
Упражнения
В главе 1 мы уже вскользь упоминали о связи между приобретением знаний экспертной системой и использованием автоматизированных методов формирования знаний на базе машинного обучения (machine learning). Было отмечено, что в ряду тех проблем, с которыми сталкивается разработчик экспертной системы, приобретение знаний является одной из наиболее трудоемких. В главе 10 было рассмотрено множество методов извлечения знаний, но ни один из них не позволяет избавиться от услуг человека-эксперта и соответственно от значительного объема работы, выполняемой "вручную".
Можно предложить три варианта приобретения знаний, которые позволят обойтись без создания базы знаний "вручную" объединенными усилиями человека-эксперта и инженера по знаниям.
(1) Использовать интерактивные программы, которые извлекали бы знания непосредственно у человека-эксперта в процессе диалога за терминалом. Различные варианты такого рода программ мы рассматривали в предыдущих главах. Вы могли убедиться, что такой вариант может успешно использоваться на практике в том случае, если диалоговая система обладает некоторым запасом базовых знаний об определенной предметной области.
(2) Использовать программы, способные обучаться, читая тексты, аналогично тому, как учится человек в процессе чтения технической литературы. Этот метод "упирается" в более общую проблему машинного распознавания смысла естественного языка человека. Поскольку сложность этой проблемы, пожалуй, на порядок выше, чем проблемы приобретения знаний о конкретной предметной области, вряд ли на таком пути мы быстро достигнем цели (по крайней мере, при современном уровне решения проблемы распознавания естественного языка).
(3) Использовать программы, которые способны обучаться под руководством человека-учителя. Один из подходов состоит в том, что учитель предъявляет программе примеры реализации некоторого концепта, а задача программы состоит в том, чтобы извлечь из предъявленных примеров набор атрибутов и значений, определяющих этот концепт. Такой подход уже успешно опробован в ряде исследовательских систем, и использованные при этом базовые методы составляют предмет обсуждения данной главы.
За последние 10 лет в области исследования методов формирования знаний на основе машинного обучения (в дальнейшем для краткости мы будем употреблять термин машинное обучение — machine learning) наблюдается бурный прогресс. Но мы не будем в этой главе делать широкого, а следовательно, и поверхностного обзора имеющихся работ, а сконцентрируемся на тех методах, которые имеют прямое отношение к проблематике экспертных систем:
извлечение множества правил из предъявляемых примеров;
анализ важности отдельных правил;
оптимизация производительности набора правил.
Существуют и другие аспекты машинного обучения, которых мы здесь касаться не будем, поскольку пока что еще не видно, как они смогут повлиять на технологию экспертных систем (но нельзя исключать, что в будущем дело может радикально измениться). Читатели, которых заинтересуют такие аспекты, могут обратиться к работам, перечисленным в конце главы.
20.1. Индуктивное обучение
Точное определение термину "обучение" дать довольно трудно, но большинство авторов сходятся во мнении, что это — качество адаптивной системы, которая способна совершенствовать свое поведение (умение справляться с проблемами), накапливая опыт, например опыт решения аналогичных задач [Simon, 1983]. Таким образом, обучение — это одновременно и способность, и действие. Любая программа обучения должна обеспечивать возможность сохранять и анализировать полученный опыт решения проблем, а также обладать способностью применять сделанные выводы для решения новых проблем.
В работе [Carbonell et al, 1983] представлена классификация программ обучения на основе используемой стратегии. Попросту говоря, использованная стратегия зависит от того, насколько глубоко может программа проникнуть в суть той информации, которую она получает в процессе обучения.
На одном конце спектра находятся программы, которые обучаются, непосредственно воспринимая новые знания, и не выполняют при этом никакого логического анализа. Обычно такую методику обучения называют rote learning ("зубрежка", а программы соответственно — "зубрилками"). Аналогов такой методике в обычной жизни не счесть. Самый знакомый всем — зазубривание таблицы умножения (или "Отче наш..."). На другом конце спектра обучающих программ находятся те, которые пользуются методикой unsupervised learning, т.е. обучение без преподавателя. Под этим подразумевается способность формулировать теоремы, которая имеет очевидную аналогию с образом мышления человека, делающего научное открытие на основе эмпирических фактов.
В этой главе мы рассмотрим методики, лежащие посередине между этими двумя крайностями. Они получили наименование супервизорного обучения (supervised learning). Программам, использующим такую методику, демонстрируются ряд примеров. Программа должна проанализировать набор свойств этих примеров и идентифицировать подходящие концепты. Свойства примеров известны и представлены парами "атрибут-значение". "Надзор" за процессом обучения заключается, главным образом, в подборе репрезентативных примеров, т.е. в формировании пространства атрибутов, над которым будет размышлять программа.
Наиболее общая форма задач, решаемых в такой системе обучения, получила наименовании индукции (induction). Таким образом, индуктивная программа обучения — это программа, способная к обучению на основе обобщения свойств предъявляемых ей примеров (экземпляров, образцов). В работе [Michalski, 1983, р. 83] дано такое определение процессу обучения:
"Эвристический поиск в пространстве символических описаний, сформированный применением различных правил вывода к исходным наблюдаемым проявлениям".
Символические описания представляют собой, как правило, обобщения, которые можно сделать на основе наблюдаемых проявлений. Такие обобщения являются формой логического заключения, т.е. они предполагают выполнение определенных, регламентируемых некоторыми правилами трансформаций символических описаний, которые представляют наблюдаемые проявления. Одна из форм индуктивного обучения предусматривает демонстрацию примеров двух типов — тех, которые соответствуют концепту (позитивные экземпляры), и тех, которые ему не соответствуют (негативные экземпляры). Задача программы обучения — выявить или сконструировать подходящий концепт, т.е. такой, который включал бы все позитивные экземпляры и не включал ни одного негативного. Такой тип обучения получил название обучение концептам (concept learning).
Рассмотрим набор данных, представленный в табл. 20.1.
Таблица 20.1. Обучающая выборка примеров
Экземпляр
Страна-изготовитель
Размер
Старая модель
Позитивный/ негативный
Oldsmobile Cutlass
США
Большой
Нет
Негативный
BMW 31 6
Германия
Малый
Нет
Позитивный
Thunderbird Raodster
США
Малый
Да
Негативный
VW Cabriolet
Германия
Малый
Нет
Позитивный
Rolls Royce Corniche
Великобритания
Большой
Да
Негативный
Chevrolet Bel Air
США
Малый
Да
Негативный
Предположим, что концепт, которому мы хотим обучить программу, это Немецкий автомобиль. Тогда позитивными экземплярами для этого концепта будут BMW 316 и VW Cabriolet, а остальные— негативными. Если же целевой концепт— Американский автомобиль старой марки, то позитивными экземплярами будут Thunderbird Raodster и Chevrolet Bel Air, а остальные — негативными.
Очень существенно предъявлять программе и позитивные, и негативные экземпляры. В первой из рассмотренных выше задач и BMW 316, и VW Cabriolet являются малыми автомобилями, поэтому если программе не представить в качестве негативного экземпляра Chevrolet Bel Air, то она может сделать вывод, что концепт Немецкий автомобиль совпадает с концептом Малый автомобиль. Аналогично, если во второй задаче не будет представлен негативный экземпляр Oldsmobile Cutlass, то программа может посчитать концепт Американский автомобиль старой марки совпадающим с более общим концептом Американский автомобиль.
С формальной точки зрения любое множество данных, в котором выделены положительные и отрицательные экземпляры, можно считать обучающей выборкой для индуктивной программы обучения. В обучающей выборке также нужно специфицировать некоторый набор атрибутов, имеющих отношение к обучаемым концептам, а запись каждого экземпляра должна содержать значения этих атрибутов. В табл. 20.1 представлены значения атрибутов обучающей выборки для концепта Немецкий автомобиль.
Другая задача обучения получила наименование обобщение дескрипторов (descriptive generalization). Формулируется задача следующим образом: программе обучения предъявляется набор экземпляров некоторого класса объектов (т.е. представляющих некоторый концепт), а программа должна сформировать описание, которое позволит идентифицировать (распознавать) любые объекты этого класса. Пусть, например, обучающая выборка имеет вид
{Cadillac Seville, Oldsmobile Cutlass, Lincoln Continental},
причем каждый экземпляр выборки имеет атрибуты размер, уровень комфорта и расход топлива. Тогда в результате выполнения задачи обобщения дескрипторов программа сформирует описание, представляющее набор значений дескрипторов, характерный для данного класса объектов:
{большой, комфортабельный, прожорливый}.
Отличие между задачами обучение концептам и обобщение дескрипторов состоит в следующем:
задача обучения концептам предполагает включение в обучающую выборку как позитивных, так и негативных экземпляров некоторого заранее заданного набора концептов, а в процессе выполнения задачи будет сформировано правило, позволяющее затем программе распознавать ранее неизвестные экземпляры концепта;
задача обобщения дескрипторов предполагает включение в обучающую выборку только экземпляров определенного класса, а в процессе выполнения задачи создается наиболее компактный вариант описания из всех, которые подходят к каждому из предъявленных экземпляров.
Обе задачи относятся к классу методик, который мы назвали супервизорным обучением, поскольку в распоряжении программы имеется и специально подготовленная обучающая выборка, и пространство атрибутов.
В следующем разделе мы рассмотрим две программы обучения, которые разработаны в связи с созданием экспертной системы DENDRAL. Первый вариант реализации программы обучения нельзя отнести ни к одной из перечисленных выше категорий, но второй вариант использовал методику, которую мы сейчас можем отнести к категории "индуктивное обучение". В оригинальном описании программы авторы назвали ее version space (пространство версий). Постановка задачи очень напоминает обучение концептам, поскольку предусматривает включение в обучающую выборку позитивных и негативных экземпляров концепта.
Интересно сравнить оба варианта системы и выяснить, как знания, специфичные для определенной предметной области (в данном случае, химии), могут быть использованы алгоритмом обучения, независящим от предметной области.
В разделе 20.3 описана современная программа индуктивного обучения, на примере которой будет продемонстрировано, как формируются правила для экспертных систем. В разделе 20.4 мы затронем вопрос настройки отдельных правил и набора связанных правил.
20.2. Система Meta-DENDRAL
В рамках проекта DENDRAL, который был начат в Станфордском университете в 1965 году, была разработана первая система, продемонстрировавшая, что программа может успешно конкурировать с человеком-экспертом в определенной предметной области. Перед экспертной системой стояла задача определения молекулярной структуры неизвестного органического соединения. В экспертной системе использовался слегка модифицированный вариант метода порождения и проверки. Исходной информацией были показания масс-спектрометра, который бомбардировал образец соединения потоком электронов. В результате происходила перестройка структуры соединения и его компонентов. Перемещение отдельных атомов в структуре соединения соответствует отсоединению узла от одного подграфа и присоединению его к другому. Изменение структуры молекул соединения и улавливалось масс-спектрометром.
Проблема состояла в том, что для любой сложной молекулы существует множество вариантов разделения на фрагменты, поскольку в результате бомбардировки могут разрываться разные связи в молекуле, а соответственно и перемещаться могут разные фрагменты молекулы. В этом смысле теория масс-спектрометрии являетсл неполной— мы можем говорить только о вероятности разрыва определенной связи, но никогда не можем точно предсказать, как разделится молекула на фрагменты.
В рамках проекта DENDRAL была разработана программа CONGEN, которая формировала описание полной химической структуры, манипулируя символами, представляющими атомы и молекулы. В качестве входной информации эта программа получала формулу молекулы и набор ограничений, накладываемых на возможные взаимные связи между атомами. Результатом выполнения программы является список всех возможных комбинаций атомов в структуре молекулы с учетом заданных ограничений.
В состав DENDRAL входят также программы, которые помогают пользователю отбрасывать одни гипотезы и ранжировать другие, используя знания о связях показаний масс-спектрометра со структурой молекул соединения. Например, программа MSPRUNE отсеивает те гипотезы-кандидаты, которые предполагают варианты фрагментации, не совпадающие с полученными от масс-спектрометра данными. Программа MSRANK ранжирует оставшиеся гипотезы-кандидаты в соответствии с тем, какая часть пиков масс-спектрограммы, предсказанных этой гипотезой, была действительно обнаружена в полученных экспериментально данных. Таким образом, в экспертной системе DENDRAL фактически реализована стратегия "формирование гипотез и их последующая проверка". Исходные данные служат для формирования некоторого пространства гипотез, которые предсказывают наличие и отсутствие определенных свойств масс-спектрограммы, а затем эти гипотезы сопоставляются с результатами экспериментов.
20.2.1. Формирование и уточнение правил
Программа Meta-DENDRAL формирует на основе рассуждений правила, которые затем используются программой DENDRAL в процессе определения молекулярной структуры неизвестного органического соединения. В первой версии программы Meta-DENDRAL гипотетические правила (гипотезы о правилах) формировались в процессе эвристического поиска, подобного тому, который использовался в самой программе DENDRAL. Другими словами, для формирования правил в этой версии использовалась та же стратегия, что и в системе, применяющей эти правила.
Роль программы Meta-DENDRAL во всем комплексе состояла в хом, чтобы помочь химику выявить взаимосвязи между вариантами фрагментации молекул в процессе получения массового спектра и структурными характеристиками компонентов молекулы. Работая совместно, программа и химик решают, какие данные о структуре компонентов представляют интерес, а затем отыскивают спектрометрический процесс, который может объяснить появление таких данных. В результате формируются правила, связывающие структуру с масс-спектрограммой. Затем программа тестирует эти правила и при необходимости модифицирует их так же, как это сделал бы химик.
Те правила масс-спектрометрии, которые химик использует для описания фрагментации молекулы, могут быть символически представлены в виде порождающих правил. Например, следующее правило расщепления позволяет представить в программе связь между определенной структурой молекулы и определенным процессом ее расщепления в процессе масс-спектрометрии. Здесь значком "-" представлена связь в молекуле, а значком "*" — место разрыва под воздействием бомбардировки электронами:
N-C-C-C-> N-C*C-C.
В левой части правила представлены характеристики структуры, а в правой — процесс расщепления при формировании массового спектра.
Для обучения Meta-DENDRAL используется набор молекул, структура и массовый спектр которых известны. Для этого набора молекул формируются пары "структура-спектр", которые и включаются в обучающую выборку.
Хочу обратить ваше внимание на следующее. Хотя "словарь" атомов в подграфах структуры молекулы и невелик, а "грамматика" конструирования подграфов проста, количество формируемых подграфов может быть довольно велико. Поэтому существует опасность экспоненциального взрыва. Учитывая потенциальную опасность экспоненциального взрыва, в Meta-DENDRAL (как, впрочем, и в DENDRAL) используется стратегия "планирование— формирование гипотез— проверка". Фаза планирования в Meta-DENDRAL выполняется программой INTSUM (сокращение от interpretation and summary — интерпретация и суммирование данных). Эта программа должна предложить набор простых процессов, которые можно включить в обучающую выборку. Процессы
Выходная информация программы INTSUM передается программе эвристического поиска RULEGEN, которая играет в Meta-DENDRAL, ту же роль, что и программа CONGEN в DENDRAL. Но в отличие от CONGEN, она формирует не гипотезы о структурах молекул, а более общие гипотетические правила расщепления, которые, например, могут предполагать и множественные разрывы связей в молекулах. Эти правила должны охватывать все случаи, представленные в обучающей выборке, сформированной программой INTSUM. После того как будет сформировано множество гипотетических правил, в дело вступает программа RULEMOD, на которую возложено выполнение последней фазы процесса, — фазы тестирования и модификации правил.
Разделение нагрузки между программами RULEGEN и RULEMOD следующее: программа RULEGEN выполняет сравнительно поверхностный поиск в пространстве правил и формирует при этом приблизительные и избыточные правила, а программа RULEMOD выполняет более глубокий поиск и уточняет набор гипотетических правил.
Алгоритм работы программы RULEMOD и по сей день представляет определенный интерес, хотя со времени ее создания прошло более 30 лет. Задачи, которые решает эта программа, типичны для всех программ тонкой настройки правил.
(1) Устранение избыточности. Данные, поступающие на вход программы (гипотетические правила), могут быть переопределены, т.е. несколько правил, сформированных на предыдущем этапе, объясняют одни и те же факты. Обычно в окончательный набор правил нужно включить только часть из них. При выполнении этой задачи также удаляются правила, которые вносят противоречие во всю совокупность или порождают некорректные предсказания.
(2) Слияние правил. Иногда несколько правил, взятых в совокупности, объясняют сразу множество фактов, и эту совокупность имеет смысл объединить в одно, более общее правило, которое будет включать все позитивные свидетельства и не содержать ни одного негативного. Если удастся отыскать такое совокупное правило, то им заменяются в окончательном наборе все его исходные компоненты.
(3) Специализация правила. Иногда оказывается, что слишком общее правило порождает некорректные предсказания, т.е. в его "зону охвата" попадают и негативные свидетельства. В таком случае нужно попытаться добавить в правило уточняющие компоненты, которые помогут исключить из "зоны охвата" правила негативные свидетельства, но сохранят охват всех позитивных свидетельств. В результате правило станет более специализированным.
(4) Обобщение правила. Поскольку порождение правил выполняется на основе обучающей выборки ограниченного объема, то среди сформированных правил могут оказаться и такие, в которых специализация выходит за рамки разумного. Программа пытается сохранить только минимальный набор условий в левой части правила, необходимый для обеспечения корректности правила на данной тестовой выборке.
(5) Отбор правил в окончательный набор. После обобщения и специализации правил в наборе вся совокупность может снова стать избыточной. Поэтому программа снова повторяет процедуру устранения избыточности, описанную в п. 1.
Все описанные процедуры могут итеративно повторяться до тех пор, пока пользователь не будет удовлетворен сформированным набором правил. Единственное, что после этого еще остается сделать пользователю — присвоить правилам веса. Ниже в этой главе мы покажем, как на практике выполняется формирование набора правил.
Качество правил, сформированных системой Meta-DENDRAL, проверялось на наборе структур, не включенных в обучающую выборку. Они также сравнивались с теми правилами, которые имеются в опубликованных источниках, и анализировались опытными специалистами по спектрометрии органических соединений. Программа успешно "открыла" опубликованные правила и, более того, нашла новые. Способность сформированных правил предсказать вид спектра соединений, ранее ей неизвестных, поразила специалистов. Однако ни DENDRAL, ни Meta-DENDRAL не стали коммерческими программными продуктами, хотя многие идеи, рожденные в процессе работы над этим проектом, и нашли широкое применение в компьютерной химии. Различные модули этих программ были включены в состав других программных комплексов, в частности в системы управления базой данных химических соединений [Feigenbaum and Buchanan, 1993].
20.2.2. Пространство версий
В этом разделе мы рассмотрим одну из методик обучения, которая получила в литературе наименование пространство версий (version space) [Mitchell, 1978], [Mitchell, 1982], [Mitchell, 1997]. Эта методика была реализована во второй версии системы Meta-DENDRAL. При выводе общего правила масс-спектрометрии из набора примеров, демонстрирующих, как определенные молекулы расщепляются на фрагменты, в этой версии Meta-DENDRAL интенсивно используется механизм обучения концептам, о котором мы рассказывали выше. В работе [Mitchell, 1978] так формулируется проблема обучения концептам.
"Концепт можно представить как образец, который обладает свойствами, общими для всех экземпляров этого концепта. Задача состоит в том, чтобы при заданном языке описания образцов концептов и наличии обучающей выборки — наборе позитивных и негативных экземпляров целевого концепта и способе сопоставления данных из обучающей выборки и гипотез описания концепта — построить описание концепта, совместимого со всеми экземплярами в обучающей выборке".
В этом контексте "совместимость" означает, что сформированное описание должно охватывать все позитивные экземпляры и не охватывать ни один негативный экземпляр.
Для того чтобы "рассуждать" о правилах, касающихся масс-спектрометрии, система Meta-DENDRAL должна располагать языком представления концептов и отношений между ними в этой предметной области. В Meta-DENDRAL это объектно-ориентированный язык (см. главу 6), который описывает сеть с помощью узлов и связей между ними. Узлы представляют атомы в структуре молекулы, а связи — химические связи в молекуле. В этом языке некоторый экземпляр в обучающей выборке соответствует образцу в том случае, если сопоставимы все их узлы и связи и удовлетворяются все ограничения, специфицированные в описании образца.
В контексте проблемы обучения концептам пространство версий есть не что иное, как способ представления всех описаний концептов, совместимых в оговоренном выше смысле со всеми экземплярами в обучающей выборке. Главное достоинство использованной Митчеллом (Mitchell) методики представления и обновления пространств версий состоит в том, что версии могут строиться последовательно одна за другой, не оглядываясь на ранее обработанные экземпляры или ранее отвергнутые гипотезы описаний концептов.
Митчелл отыскал ключ к решению проблемы эффективного представления и обновления пространств версий, заметив, что пространство поиска допустимых описаний концептов является избыточным. В частности, он пришел к выводу, что можно выполнить частичное упорядочение образцов, сформированных описаниями концептов. Самым важным является отношение "более специфичный чем или равный", которое формулируется следующим образом.
"Образец Р1 более специфичен или равен образцу Р2 (это записывается в форме Р2 =< Р2) тогда и только тогда, когда Р1 сопоставим с подмножеством всех образцов, с которыми сопоставим образец Р2".
Рассмотрим следующий простой пример из обучающей программы для "мира блоков" [Winston, 1975, а]. На рис. 20.1 образец Р1 более специфичен, чем образец Р2, поскольку ограничения, специфицированные в образце Р1, удовлетворяются только в том случае, если удовлетворяются более слабые ограничения, специфицированные в образце Р2. Можно посмотреть на эту пару образцов и с другой точки зрения: если в некотором экземпляре удовлетворяются ограничения, специфицированные в образце Р1, то обязательно удовлетворяются и условия, специфицированные в образце Р2, но не наоборот.
Рис. 20.1. Отношения между образцами
Обратите внимание на следующий нюанс. Для того чтобы программа смогла выполнить упорядочение представленных образцов, она должна быть способна разобраться в смысле множества понятий и отношений между ними, которые специфичны для данной предметной области.
Программа должна понимать, что если В — это "брусок", то, значит, В — это одновременно и "объект произвольной формы", т.е. в программу должны быть заложены определенные критерии, которые помогут ей выделить категории сущностей, представленных узлами в языке описания структуры образцов.
Программа должна знать, что если А "поддерживает" В, то, следовательно, А "касается" В в мире блоков, т.е. программа должна обладать способностью разобраться в избыточности отношений между объектами в предметной области.
Программа должна понимать логический смысл таких терминов, как "не", "любой" и "или", и то как они влияют на ограничения или разрешения в процессе сопоставления образцов.
Все эти знания необходимы программе для того, чтобы она смогла сопоставить образец Р1 с Р2, т.е. узлы и связи в одном образце с узлами и связями в другом, и выяснить, что любое ограничение, специфицированное в Р1, является более жестким, более специфичным, чем соответствующее ему ограничение в образце Р2. Если программа сможет во всем этом
разобраться, то открывается путь к представлению пространств версий в терминах большей "специфичности" или большей "общности" образцов в этом пространстве. Тогда программа может рассматривать некоторое пространство версий как содержащее:
множество максимально специфических образцов;
множество максимально обобщенных образцов;
все описания концептов, которые находятся между этими двумя крайними множествами.
Все это в совокупности называется представлением пространств версий граничными множествами (boundary sets). Такое представление, во-первых, компактно, а во-вторых, легко обновляется. Оно компактно, поскольку не хранит в явном виде все описания концептов в данном пространстве. Его легко обновлять, так как определение нового пространства можно выполнить перемещением одной или обеих границ.
20.2.3. Алгоритм отсеивания кандидатов
Пространство версий, как следует из приведенного описания, есть не что иное, как структура данных для представления множества описаний концептов. Однако термин "пространство версий" часто применяется и по отношению к технологии обучения, использующей при работе с этой структурой данных алгоритм, известный как алгоритм отсеивания кандидатов (candidate elimination). Этот алгоритм манипулирует с граничными множествами, представляющими определенное пространство версий.
Выполнение алгоритма начинается с инициализации пространства версий — заполнения его множеством всех описаний концептов, совместимых с первым позитивным экземпляром в обучающей выборке. Другими словами, множество максимально специфических образцов (S) заполняется наиболееспецифическими описаниями концептов, которые способен сформировать язык образцов, а множество максимально обобщенных образцов (G) заполняется наиболее обобщенными описаниями концептов. При анализе каждого последующего экземпляра в обучающей выборке множества S и G модифицируются таким образом, чтобы отсеять из пространства версий те описания концептов, которые несовместимы с анализируемым экземпляром.
Таким образом, в процессе обучения границы монотонно "движутся" навстречу друг другу. Перемещение границы S в направлении большей общности можно рассматривать как выполнение поиска в ширину от специфических образцов к более общим. Цель поиска — сформировать новое граничное множество, которое будет обладать минимально достаточной общностью, чтобы "охватить" новый позитивный экземпляр обучающей выборки. Другими словами, граница 5 перемещается в том случае, если новый позитивный экземпляр в обучающей выборке не сопоставим ни с одним из образцов в множестве S. Точно так же и перемещение границы G в направлении большей специфичности можно рассматривать как поиск в ширину от более общих образцов к более специфичным. Цель такого поиска— сформировать новое граничное множество, которое будет обладать минимально достаточной спецификой, чтобы не "накрыть" очередной негативный экземпляр в обучающей выборке. Коррекция границы G происходит в том случае, когда программа обнаруживает, что очередной негативный экземпляр сопоставим с каким-либо образцом в G.
В этом алгоритме нет никакой эвристики, поскольку ограничения четкие и тем самым гарантируется сходимость алгоритма. Монотонность поиска оказалась тем "золотым ключиком", с помощью которого удалось решить проблему комбинаторики обновления пространств.
Технология пространства версий обладает множеством привлекательных свойств, которые стоят того, чтобы их здесь перечислить.
Гарантируется совместимость всех описаний концептов со всеми экземплярами в обучающей выборке.
Пространство поиска суммирует альтернативные интерпретации наблюдений.
Результат не зависит от порядка обработки обучающей выборки.
Каждый экземпляр в обучающей выборке анализируется только один раз.
Не возникает необходимость возвращаться к однажды отвергнутой гипотезе.
Тот факт, что пространство версий суммирует данные, означает, что его можно использовать в качестве базиса для формирования новых экземпляров для обучающей выборки, т.е. экземпляров, которые могли бы еще более сблизить границы. То, что программа анализирует каждый экземпляр только один раз, позволяет обойтись без сохранения ранее обработанных экземпляров. Следовательно, и время обучения пропорционально объему обучающей выборки, а не связано с количеством экземпляров в ней какой-либо показательной функцией. Поскольку отпадает необходимость в обратном прослеживании, эффективность процедуры должна быть довольно высокой. Наиболее серьезным "подводным камнем" в этой технологии является фактор ветвления в процессе частичного упорядочения образцов, который имеет тенденцию к комбинаторному росту по мере увеличения количества дизъюнктов в описаниях концептов
20.2.4. Сопоставление экземпляров с образцами в Meta-DENDRAL
Для описания экземпляров обучающей выборки в Meta-DENDRAL используется тот же язык, что и для описания образцов. Каждый образец представляет собой описание определенной цельной молекулы, причем основное внимание уделяется описанию компонентов.
При сопоставлении экземпляров с образцами отыскивается цепочка связных отображений узлов образца и узлов экземпляра. Отображение X является связным, если оно является однозначным и допускающим вставку и если каждая пара узлов экземпляра Х(р1), Х(р2), соответствующая узлам образца р1 и р2, разделяет общую связь в том и только в том случае, если р1 и р2 также разделяют общую связь. Требуется также, чтобы значения характеристик каждого узла экземпляра Х(р) удовлетворяли ограничениям, определенным для соответствующего узла p образца.
Теперь открывается возможность дать определение частичного упорядочения по Митчеллу, специфичное для той предметной области, в которой используется система Meta-DENDRAL. В этом определении будет использовано и приведенное выше определение связности. Строчными буквами будем обозначать узлы образца, а прописными — весь образец в целом. Образец Р1 является более специфическим или равным образцу Р2 в том и только в том случае, когда существует такое связанное отображение X узлов в Р2 на узлы в Р1, что для каждой пары узлов р2, Х(р2) ограничения на значения свойств, ассоциированные с Х(р2), являются более специфическими или равными ограничениям, ассоциированным с р2. Для того чтобы разобраться в существе этого определения, имеет смысл вновь вернуться к примеру из мира блоков, который мы рассматривали выше. В мире химических структур аналогами блоков являются атомы и "суператомы", а аналогами пространственных отношений между блоками, такими как "поддерживает" или "касается", — химические связи.
Специфические знания из области химии могут быть двояко использованы алгоритмом отсеивания кандидатов.
(1)Язык представления химических структур допускает такие языковые формы представления образцов, которые синтаксически отличны, но семантически эквивалентны, т.е. на этом языке один и тот же образец можно описать разными выражениями. Следовательно, для удаления избыточных образцов из граничных пространств версий требуется знание семантики образца, представленного в описании. Это не оказывает никакого влияния на полноту подхода, основанного на пространстве версий.
(2) Для некоторых проблем граничные пространства версий могут вырасти и достичь достаточно большого объема. Следовательно, было бы очень полезно использовать какие-либо правила для сокращения объемов граничных пространств. Однако, если использовать для этого эвристические методы, нет уверенности, что программа сможет определить все описания концептов, совместимые с обучающей выборкой.
Митчелл утверждает, что подход, основанный на пространстве версий, добавит новые возможности первоначальному варианту программы Meta-DENDRAL.
Можно модифицировать существующий набор правил новой обучающей выборкой и при этом не повторять анализ ранее представленной выборки.
Процесс обучения будет носить явно выраженный инкрементальный характер. Можно будет индивидуально решать для каждого правила, до какой степени имеет смысл его уточнять в процессе обучения.
Новая стратегия формирования правил позволит избежать использования "поиска со спуском" в программе RULEGEN и сосредоточить в первую очередь внимание на наиболее интересных экземплярах в обучающей выборке.
Метод анализа альтернативных версий каждого правила является более полным, чем операции обобщения и специализации в программе RULEMOD.
Суммируя все сказанное выше, приходим к выводу, что использование подхода, основанного на пространствах версий, позволяет реализовать методику инкрементального обучения (обучения с последовательным наращиванием уровня полноты знаний). Стратегия отсеивания кандидатов может быть противопоставлена стратегии поиска в глубину или в ширину, поскольку она позволяет отыскать не единственное приемлемое описание концепта, как при выполнении поиска в глубину, или максимально специфические описания, как при поиске в ширину, а все описания концептов, совместимые с обучающей выборкой. Митчелл также специально акцентирует внимание на том, что ключевым вопросом применения такой технологии является разработка методов формирования обучающей выборки
20.3. Построение дерева решений и порождающих правил
Правила являются не единственно возможным способом представления информации о концептах в виде пар- "атрибут-значение" для целей классификации. Альтернативный метод структурирования такой информации — использование дерева решения. Существуют эффективные алгоритмы конструирования таких деревьев из исходных данных. Мы обсудим их в разделе 20.3.1.
За последние 30 лет создано довольно много систем обучения, в которых использована эта методика. Среди них системы CLS [Hunt et al., 1966], ID3 [Quinlan, 1979], ACLS [Paterson and Niblett, 1982], ASSISTANT [Kononenko et al., 1984] и IND [Buntine, 1990]. Система ACLS (развитие системы ID3) стала базовой для множества коммерческих экспертных систем, таких как Expert-Ease и RuleMaster, которые нашли широкое применение в промышленности. Несколько подробнее об алгоритме работы системы ID3 будет рассказано в разделе 20.3.2.
Программный комплекс С4.5 [Quinlan, 1993] использует алгоритмы ЮЗ и включает программу C4.5Rules. Этот модуль формирует порождающие правила, используя в качестве входной информации описание дерева решений. Подробное описание этой программы имеется в технической литературе, а потому мы не будем останавливаться на ней в данной книге. В последней версии этой системы, С5.0, реализована еще более тесная интеграция форматов представления деревьев решений и правил
20.3.1. Структура дерева решений
Дерево решений представляет один из способов разбиения множества данных на классы или категории. Корень дерева неявно содержит все классифицируемые данные, а листья — определенные классы после выполнения классификации. Промежуточные узлы дерева представляют пункты принятия решения о выборе или выполнения тестирующих процедур с атрибутами элементов данных, которые служат для дальнейшего разделения данных в этом узле.
В работе [Quinlan, 1993] дерево решений определено как структура, которая состоит из
узлов-листьев, каждый из которых представляет определенный класс;
узлов принятия решений, специфицирующих определенные тестовые процедуры, которые должны быть выполнены по отношению к одному из значений атрибутов; из узла принятия решений выходят ветви, количество которых соответствует количеству возможных исходов тестирующей процедуры.
Можно рассматривать дерево решений и с другой точки зрения: промежуточные узлы дерева соответствуют атрибутам классифицируемых объектов, а дуги — возможным альтернативным значениям этих атрибутов. Пример дерева представлен на рис. 20.2.
На этом дереве промежуточные узлы представляют атрибуты наблюдение, влажность, ветрено. Листья дерева промаркированы одним из двух классов П или Н. Можно считать, что П соответствует классу позитивных экземпляров концепта, а Н — классу негативных. Например, П может представлять класс "выйти на прогулку", а Н — класс "сидеть дома".
Хотя очевидно, что дерево решений является способом представления, отличным от порождающих правил, дереву можно сопоставить определенное правило классификации, которое дает для каждого объекта, обладающего соответствующим набором атрибутов (он представлен множеством промежуточных узлов дерева), решение, к какому из классов отнести этот объект (набор классов представлен множеством значений листьев дерева). В приведенном примере правило будет относить объекты к классу П или Н. Можно прямо транслировать дерево в правило, показанное ниже:
если наблюдение = облачно
v
наблюдение = солнечно &
влажность = нормально
v
наблюдение = дождливо &
ветрено = нет то П
Рис. 20.2. Дерево решений (заимствовано из [Quinlan, 1986, a])
Единственное приведенное правило, созданное непосредственно после преобразования дерева, можно разделить на три отдельных правила, которые не требуют использования логической дизъюнкции, а затем представить каждое из них на языке описания порождающих правил, например CLIPS:
if наблюдение = облачно
then П
if наблюдение = солнечно &
влажность = нормально then П
if наблюдение = дождливо &
ветрено = нет then П
Причина, по которой предпочтение иногда отдается деревьям решений, а не порождающим правилам, состоит в том, что существуют сравнительно простые алгоритмы построения дерева решений в процессе обработки обучающей выборки, причем построенные деревья могут быть использованы в дальнейшем для корректной классификации объектов, не представленных в обучающей выборке. Алгоритм системы ID3, который используется для построения дерева по обучающей выборке, мы рассмотрим в следующем разделе. Этот алгоритм достаточно эффективен с точки зрения количества вычислительных операций, поскольку объем вычислений растет линейно по отношению к размерности проблемы.
В табл. 20.2 показана обучающая выборка, которая использовалась для формирования дерева на рис. 20.2.
Таблица 20.2. Обучающая иыборка (заимствовано us [Quinlan, 1986,a])
Номер
Наблюдение
Температура
Влажность
Ветрено
Класс
1
Солнечно
Жарко
Высокая
Нет
Н
2
Солнечно
Жарко
Высокая
Да
Н
3
Облачно
Жарко
Высокая
Нет
п
4
Дождливо
Умеренно
Высокая
Нет
п
5
Дождливо
Холодно
Нормальная
Нет
п
6
Дождливо
Холодно
Нормальная
Да
Н
7
Облачно
Холодно
Нормальная
Да
п
8
Солнечно
Умеренно
Высокая
Нет
Н
9
Солнечно
Холодно
Нормальная
Нет
п
10
Дождливо
Умеренно
Нормальная
Нет
п
11
Солнечно
Умеренно
Нормальная
Да
п
12
Облачно
Умеренно
Высокая
Да
п
13
Облачно
Жарко
Нормальная
Нет
п
14
Дождливо
Умеренно
Высокая
Да
Н
Читатель может самостоятельно проверить, насколько корректно классифицируется каждый из 14 экземпляров, представленных в этой выборке. Обратите внимание на то, что атрибут температура в дереве отсутствует, поскольку он оказался излишним при выполнении классификации.
20.3.2. Алгоритм формирования дерева решений по обучающей выборке
Ниже будет описан алгоритм формирования дерева решений по обучающей выборке, использованный в системе IDЗ. Задача, которую решает алгоритм, формулируется следующим образом. Задано:
множество целевых непересекающихся классов {С1, С2, ..., Сk};
обучающая выборка S, в которой содержатся объекты более чем одного класса.
Алгоритм использует последовательность тестовых процедур, с помощью которых множество 5 разделяется на подмножества, содержащие объекты только одного класса. Ключевой в алгоритме является процедура построения дерева решений, в котором нетерминальные узлы соответствуют тестовым процедурам, каждая из которых имеет дело с единственным атрибутом объектов из обучающей выборки. Как вы увидите ниже, весь фокус состоит в в выборе этих тестов.
Пусть Т представляет любую тестовую процедуру, имеющую дело с одним из атрибутов, а {О1,O2,...,On} — множество допустимых выходных значений такой процедуры
при ее применении к произвольному объекту х. Применение процедуры Т к объекту х будем обозначать как Т(х). Следовательно, процедура Т(х) разбивает множество S на составляющие {S1, S2, ..., Sn}, такие, что
Si= {x|T(x) = Oi}. Такое разделение графически представлено на рис. 20.3.
Рис. 20.3. Дерево разделения объектов обучающей выборки
Если рекурсивно заменять каждый узел Si, на рис. 20.3 поддеревом, то в результате будет построено дерево решений для обучающей выборки S. Как уже отмечалось выше, ключевым фактором в решении этой проблемы является выбор тестовой процедуры — для каждого поддерева нужно найти наиболее подходящий атрибут, по которому можно выполнять дальнейшее разделение объектов.
Квинлан (Quinlan) использует для этого заимствованное из теории информации понятие неопределенности. Неопределенность — это число, описывающее множество сообщений M= { m1, т2,..., тn}. Вероятность получения определенного сообщения mi из этого множества определим как р(тi). Объем информации, содержащейся в этом сообщении, будет в таком случае равен
I(mi) = -logp(mi).
Таким образом, объем информации в сообщении связан с вероятностью получения этого сообщения обратной монотонной зависимостью. Поскольку объем информации измеряется в битах, логарифм в этой формуле берется по основанию 2.
Неопределенность множества сообщений U(M) является взвешенной суммой количества информации в каждом отдельном сообщении, причем в качестве весовых коэффициентов используются вероятности получения соответствующих сообщений:
U(М) = -Sumip[(mi) logp(mi), i = 1,..., п.]
Интуитивно ясно, что чем большую неожиданность представляет получение определенного сообщения из числа возможных, тем более оно информативно. Если все сообщения в множестве равновероятны, энтропия множества сообщений достигает максимума.
Тот способ, который использует Квинлан, базируется на следующих предположениях.
Корректное дерево решения, сформированное по обучающей выборке S, будет разделять объекты в той же пропорции, в какой они представлены в этой обучающей выборке.
Для какого-либо объекта, который нужно классифицировать, тестирующую процедуру можно рассматривать как источник сообщений об этом объекте.
Пусть Ni — количество объектов в S, принадлежащих классу Сi. Тогда вероятность того, что произвольный объект с, "выдернутый" из S, принадлежит классу Сi, можно оценить по формуле
p(c~Ci) = Ni/|S|,
а количество информации, которое несет такое сообщение, равно I(с ~ Сi) = -1оg2р(mi) (с ~ Сi) бит.
Теперь рассмотрим энтропию множества целевых классов, считая их также множеством сообщений {С1 C2, ..., Ck}. Энтропия также может быть вычислена как взвешенная сумма количества информации в отдельных сообщениях, причем весовые коэффициенты можно определить, опираясь на "представительство" классов в обучающей выборке:
U(M) = -Sumi=1...,k[ р(с ~ Ci)x I(с ~ Сi)] бит.
Энтропия U(M) соответствует среднему количеству информации, которое необходимо для определения принадлежности произвольного объекта (с ~ S) какому-то классу до того, как выполнена хотя бы одна тестирующая процедура. После того как соответствующая тестирующая процедура Т выполнит разделение S на подмножества {S1, S2, ..., Sn}, энтропия будет определяться соотношением
Uт(S) = -Sumi=1,...k(|S|/|Si|)х U(Si).
Полученная оценка говорит нам, сколько информации еще необходимо после того, как выполнено разделение. Оценка формируется как сумма неопределенностей сформированных подмножеств, взвешенная в пропорции размеров этих подмножеств.
Из этих рассуждений очевидно следует эвристика выбора очередного атрибута для тестирования, используемая в алгоритме, — нужно выбрать тот атрибут, который сулит наибольший прирост информации. Прирост информации GS(T) после выполнения процедуры тестирования Т по отношению к множеству 5 равен
GS(7)=U(S)-Uт(S).
Такую эвристику иногда называют "минимизацией энтропии", поскольку увеличивая прирост информации на каждом последующем тестировании, алгоритм тем самым уменьшает энтропию или меру беспорядка в множестве.
Вернемся теперь к нашему примеру с погодой и посмотрим, как эти формулы интерпретируются в самом простом случае, когда множество целевых классов включает всего два элемента. Пусть р — это количество объектов класса П в множестве обучающей выборки S, а п — количество объектов класса Н в этом же множестве. Таким образом, произвольный объект принадлежит к классу П с вероятностью p / (p + п), а к классу Н с вероятностью n /(p + п). Ожидаемое количество информации в множестве сообщений М = {П, Н} равно
U(M) = -p / (p + п) log2(p/(p + n )) -
n / (p + n) 1оg2(n/(р + п))
Пусть тестирующая процедура Т, как и ранее, разделяет множество S на подмножества {S1, S2.....Sn}, и предположим, что каждый компонент S, содержит pi, объектов класса
П и и, объектов класса Н. Тогда энтропия каждого подмножества Si будет равна
U(Si) = -рi/(рi + ni) log2(pi/(pi + ni)) -
n/(рi + ni) log2(ni/(pi +ni))
Ожидаемое количество информации в той части дерева, которая включает корневой узел, можно представить в виде взвешенной суммы:
Uт(S) = -Sumi=1,...n((pi, + ni)/(р + n)) х U(Si) Отношение (р, + п,)/(р + п) соответствует весу каждой i-и ветви дерева, вроде того, которое показано на рис. 20.3. Это отношение показывает, какая часть всех объектов S принадлежит подмножеству S,.
Ниже мы покажем, что в последней версии этого алгоритма, использованной в системе С4.5, Квинлан выбрал слегка отличающуюся эвристику. Использование меры прироста информации в том виде, в котором она определена чуть выше, приводит к тому, что предпочтение отдается тестирующим процедурам, имеющим наибольшее количество выходных значений {O1 O2,..., Оп}.
Но несмотря на эту "загвоздку", описанный алгоритм успешно применялся при обработке достаточно внушительных обучающих выборок (см., например, [Quintan, 1983]). Сложность алгоритма зависит в основном от сложности процедуры выбора очередного теста для дальнейшего разделения обучающей выборки на все более мелкие подмножества, а последняя линейно зависит от произведения количества объектов в обучающей выборке на количество атрибутов, использованное для их представления. Кроме того, система может работать с зашумленными и неполными данными, хотя этот вопрос в данной книге мы и не рассматривали (читателей, интересующихся этим вопросом, я отсылаю к работе [Quinlan, 1986, b]).
Простота и эффективность описанного алгоритма позволяет рассматривать его в качестве достойного соперника существующим процедурам извлечения знаний у экспертов в тех применениях, где возможно сформировать репрезентативную обучающую выборку. Но, в отличие от методики, использующей пространства версий, такой метод не может быть использован инкрементально, т.е. нельзя "дообучить" систему, представив ей новую обучающую выборку, без повторения обработки ранее просмотренных выборок.
Рассмотренный алгоритм также не гарантирует, что сформированное дерево решений будет самым простым из возможных, поскольку использованная оценочная функция, базирующаяся на выводах теории информации, является только эвристикой. Но многочисленные эксперименты, проведенные с этим алгоритмом, показали, что формируемые им деревья решений довольно просты и позволяют прекрасно справиться с классификацией объектов, ранее неизвестных системе. Продолжение поиска "наилучшего решения" приведет к усложнению алгоритма, а как уже отмечалось в главе 14, для многих сложных проблем вполне достаточно найти не лучшее, а удовлетворительное решение.
В состав программного комплекса С4.5, в котором используется описанный выше алгоритм, включен модуль C4.5Rules, формирующий из дерева решений набор порождающих правил. В этом модуле применяется эвристика отсечения, с помощью которой дерево решений упрощается. При этом, во-первых, формируемые правила становятся более понятными, а значит, упрощается сопровождение экспертной системы, а во-вторых, они меньше зависят от использованной обучающей выборки. Как уже упоминалось, в С4.5 также несколько модифицирован критерий отбора тестирующих процедур по сравнению с оригинальным алгоритмом, использованным в ID3.
Недостатком эвристики, основанной на приросте количества информации, является то, что она отдает предпочтение процедурам с наибольшим количеством выходных значений {О1, O2, ..., Оn}. Возьмем, например, крайний случай, когда практически бесполезные тесты будут разделять исходную обучающую выборку на множество классов с единственным представителем в каждом. Это произойдет, если обучающую выборку с медицинскими данными пациентов классифицировать по именам пациентов. Для описанной эвристики именно такой вариант получит преимущество перед прочими, поскольку UT(S) будет равно нулю и, следовательно, разность Gs(T) = U(S) - UT(S) достигнет максимального значения.
Для заданной тестирующей процедуры Т на множестве данных S, которая характеризуется приростом количества информации GS{T), мы теперь возьмем в качестве критерия отбора относительный прирост НS(Т), который определяется соотношением
НS{Т) = GS(Т)/V(S),
где
V(S) = -Sumi=1,..., (|S|/|Si|) x log2(|S|/|Si|).
Важно разобраться, в чем состоит отличие величины V(S) от U(S). Величина V(S) определяется множеством сообщений {О1, О2,...,Оn] или, что то же самое, множеством подмножеств {S1 S2,...,Sn}, ассоциированных с выходными значениями тестовой процедуры, а не с множеством классов {С1 C2,...,Ck}. Таким образом, при вычислении величины V(S) принимается во внимание множество выходных значений теста, а не множество классов.
Новая эвристика состоит в том, что выбирается та тестирующая процедура, которая максимизирует определенную выше величину относительного прироста количества информации. Теперь те пустые тесты, о которых мы говорили чуть выше и которым прежний алгоритм отдал бы преимущество, окажутся в самом "хвосте", поскольку для них знаменатель будет равен log2(N), где N— количество элементов в обучающей выборке.
Оригинальный алгоритм формирования дерева страдает еще одной "хворью" - он часто формирует сложное дерево, в котором фиксируются несущественные для задачи классификации отличия в элементах обучающей выборки. Один из способов справиться с этой проблемой — использовать правило "останова", которое прекращало бы процесс дальнейшего разделения ветвей дерева при выполнении определенного условия. Но оказалось, что сформулировать это условие не менее сложно, а потому Квинлан пошел по другому пути. Он решил "обрезать" дерево решений после того, как оно будет сформировано алгоритмом. Можно показать, что такое "обрезание" может привести к тому, что новое дерево будет обрабатывать обучающую выборку с ошибками, но с новыми данными оно обычно справляется лучше, чем полное дерево. Проблема "обрезания" довольно сложна и выходит за рамки данной книги. Читателям, которые заинтересуются ею, я рекомендую познакомиться с работами [Mingers, 1989, b] и [Mitchell, 1997], а подробное описание реализации этого процесса в С4.5 можно найти в [Quinlan, 1993, Chapter 4].
Для того чтобы сделать более понятным результат выполнения алгоритма, в системе С4.5 дерево решений преобразуется в набор порождающих правил. Мы уже ранее демонстрировали соответствие между отдельным путем на графе решений от корня к листу и порождающим правилом. Условия в правиле — это просто тестовые процедуры, выполняемые в промежуточных узлах дерева, а заключение правила — отнесение объекта к определенному классу.
Однако строить набор правил перечислением всех возможных путей на графе — процесс весьма неэффективный. Некоторые тесты могут служить просто для того, чтобы разделить дерево и таким образом сузить пространство выбора до подмножества, которое в дальнейшем уточняется с помощью проверки других, более информативных атрибутов. Это происходит по той причине, что не все атрибуты имеют отношение ко всем классам объектов.
Квинлан применил следующую стратегию формирования множества правил из дерева решений.
(1) Сформировать начальный вариант множества правил, перечислив все пути от корня дерева к листьям.
(2) Обобщить правила и при этом удалить из них те условия, которые представляются излишними.
(3) Сгруппировать правила в подмножества в соответствии с тем, к каким классам они имеют отношение, а затем удалить из каждого подмножества те правила, которые не вносят ничего нового в определение соответствующего класса.
(4) Упорядочить множества правил по классам и выбрать класс, который будет являться классом по умолчанию.
Упорядочение правил, которое выполняется на шаге (4), можно рассматривать как примитивную форму механизма разрешения конфликтов (см. главу 5). Порядок классов внутри определенного подмножества теперь уже не будет иметь значения. Назначение класса по умолчанию можно считать своего рода правилом по умолчанию, которое действует в том случае, когда не подходит ни одно другое правило.
Полученное в результате множество правил скорее всего не будет точно соответствовать исходному дереву решений, но разобраться в них будет значительно проще, чем в логике дерева решений. При необходимости эти правила можно будет затем уточнить вручную.
Квинлан очень осторожно подошел к формулировке тех условий, при которых созданная им система С4.5 может быть использована как подходящий инструмент обучения, позволяющий ожидать удовлетворительных результатов. Подход, основанный на использовании дерева решений, можно применять для решения далеко не всех задач классификации. Определенные ограничения свойственны и тем конкретным алгоритмам, которые использованы в системе С4.5. Необходимым условием успешного применения этой системы является выполнение следующих требований.
Перечень классов, с которыми в дальнейшем будет оперировать экспертная система, необходимо сформулировать заранее. Другими словами, алгоритмы, положенные в основу функционирования системы С4.5, не способны формировать перечень классов на основе группировки обучающей последовательности объектов. Кроме того, классы должны быть четко очерченными, а не "расплывчатыми" — некоторый объект либо принадлежит к данному классу, либо нет, никаких промежуточных состояний быть не может. И, кроме того, классы не должны перекрываться.
Применяемые в системе методы обучения требуют использовать обучающие выборки большого объема. Чем больше объем выборки, тем лучше. При малой длине обучающей выборки на полученных в результате правилах будут сказываться индивидуальные особенности экземпляров в обучающей выборке, что может привести к неверной классификации незнакомых объектов. Методы "усечения" дерева решений, использованные в С4.5, будут работать некорректно, если длина обучающей выборки слишком мала и содержит нетипичные объекты классов.
4 Данные в обучающей выборке должны быть представлены в формате "атрибут-значение", т.е. каждый объект должен быть охарактеризован в терминах фиксированного набора атрибутов и их значений для данного объекта. Существуют методы обработки, которые позволяют справиться и с пропущенными атрибутами, — предполагается, что в таких случаях выход соответствующей тестирующей процедуры будет в вероятностном смысле распределен по закону, определенному на основе тех объектов, в которых такой атрибут определен.
В тех областях применения, в которых можно использовать и подход, базирующийся на дереве решений, и обычные статистические методы, выбор первого дает определенные преимущества. Этот подход не требует знания никаких априорных статистических характеристик классифицируемого множества объектов, в частности функций распределения значений отдельных атрибутов (использование статистических методов зачастую основано на предположении о существовании нормального распределения значений атрибутов). Как показали эксперименты с экспертными системами классификации разных типов, те из них, в которых используются деревья решений, выигрывают по сравнению с другими по таким показателям, как точность классификации, устойчивость к возмущениям и скорость вычислений.
20.4. Уточнение наборов правил
Проблеме отладки и уточнения характеристик правил посвящено множество исследований. Ниже мы рассмотрим только пару примеров, которые позволят читателям понять суть этой проблемы, слегка "прикоснуться" к методам ее решения и послужат отправной точкой для более углубленного изучения этой темы. Несмотря на то что эта работа имеет теоретическую направленность, ее практическая ценность несомненна. Появление любого инструментального средства, которое поможет повысить производительность набора взвешенных правил в экспертной системе, будет только приветствоваться инженерами по знаниям.
Если в нашем распоряжении имеется набор правил, сформированный по индукции программой обучения или извлеченный в процессе собеседования с экспертом, то нас, как правило, больше всего интересует следующее:
"взнос" отдельных правил в результат;
эффективность набора правил в целом и достоверность получаемого результата.
В отношении отдельных правил наибольшую озабоченность вызывают характеристики "применимости": насколько часто правило применяется корректно, а насколько часто оно приводит к ошибочному заключению. В отношении набора правил в целом желательно знать, какова полнота набора, т.е. насколько этот набор позволяет охватить все возможные комбинации исходных данных, не является ли он избыточным, т.е. нет ли в нем правил, которые можно удалить без ущерба для качества результата. При этом нужно учитывать, что хотя само по себе "избыточное" правило может быть вполне корректным, удаление его из набора может положительно сказаться на производительности экспертной системы.
В работе [Langlotz et al, 1986] представлен метод теории принятия решений, который позволяет уточнять характеристики отдельных правил. Если в спецификации правила имеются свойства, которые можно варьировать, например связанные с вероятностными характеристиками, очень полезно выяснить, как сказывается изменение этого параметра на результатах работы системы.
В качестве иллюстрации авторы работы рассматривали простое правило системы MYCIN, которое "оппонирует" применению тетрациклина при лечении детей, поскольку этот препарат оказывает нежелательный побочный эффект на состояние зубов ребенка.
ЕСЛИ
1) против инфекции предполагается применение тетрациклина;
2) возраст пациента (лет) менее 8,
ТО
есть серьезное основание полагать (0.8), что применение тетрациклина не рекомендуется против этой инфекции.
Это правило содержит в себе возможность варьирования между воздействием на поразившую пациента инфекцию и риском отрицательного побочного эффекта. Ожидаемая полезность применения этого правила является функцией полезности результатов правила и вероятностей реального получения этих результатов.
В теории принятия решений ожидаемая полезность (EU — expected utility) действия А, возможные результаты которого есть элементы множества {О1, О2, ...,Оn}, причем исходы характеризуются вероятностями р1,р2, ...,рn, выражается формулой
EU(A) = Sumi[pi u(Oi) i=1,..,n.]
В этой формуле и(Оi) означает оценку полезности отдельного варианта результата операции (исхода) Оi. Нас интересует, как будет меняться полезность действия, которое рекомендуется правилом, при изменении вероятностей рi и оценок полезности и(Оi). Если, например, инфекция, к которой имеет отношение это правило, устойчива против всех прочих препаратов, кроме тетрациклина, а вероятность побочного эффекта довольно мала, то значение EU(A) будет более высоким по сравнению с ситуацией, когда против инфекции можно применить и другие препараты, не имеющие побочных эффектов, а вероятность побочного эффекта от применения тетрациклина довольно высока.
Авторы описывают применение методов анализа чувствительности, которые позволяют выявить зависимость между полезностью исходов и их вероятностями. Точка, в которой рекомендации альтернативных курсов лечения имеют равную полезность, представляет пороговое значение вероятности. Анализируя эти пороговые значения, можно определить, насколько далеко отстоит оценка вероятности в модели от того значения, при котором потребуется изменить принятое оптимальное решение. Усилия, затраченные на выполнение описанного анализа, окупаются тем, что инженер по знаниям и эксперт получают более точное обоснование рациональности применения того или иного правила. В частности, методы теории принятия решений позволяют определить в явном виде значения тех переменных, от которых зависит применимость отдельных правил. Это поможет инженеру по знаниям отыскать нежелательные взаимосвязи между правилами в наборе, включая и такие, которые являются результатом вероятностных зависимостей, рассмотренных нами в главе 9.
В работе [Wilkins and Buchanan, 1986] основное внимание уделено комплексной отладке набора эвристических правил. Авторы работы утверждают, что поочередная (инкрементальная) модификация отдельных правил в процессе настройки и эксплуатации экспертной системы (например, как это делается в программе TEIRESIAS, описанной в главе 10) не гарантирует сходимости процесса к оптимальному набору правил. Они предостерегают против применения "универсальных стратегий" делать правила более общими или более специализированными в тех случаях, когда обнаруживаются неверные результаты работы системы в целом. Эвристические правила по самой своей природе являются приблизительными и их нельзя модифицировать только потому, что обнаружен отдельный неправильный результат. Фактически любое эвристическое правило представляет определенный компромисс между общностью и специализацией в терминах некоторой общей линии поведения, а потому вполне целесообразно уделить основное внимание именно этой линии поведения, а не вносить судорожно изменения в отдельные правила.
Авторы дают определение оптимальному набору правил, как такому, который минимизирует вероятность получения неверных результатов. Предполагается, что отдельные правила в наборе соответствуют определенному стандарту качества, а главные усилия направляются на выбор в существующем наборе подмножества правил, наилучшего в определенном смысле. Процесс отбора такого оптимального подмножества формулируется как проблема минимизации двудольного графа (bipartite graph minimization problem), которая базируется на отображении множества вершин, представляющих объекты обучающей выборки, на множество вершин, представляющих исходное множество правил. Показано, что хотя в общем виде эта проблема относится к классу необозримых, но существует эвристический метод ее решения для конкретной постановки, связанной со спецификой экспертных систем. Предлагаемое решение в основном сводится к тому, чтобы минимизировать в наборе вредные взаимные связи между "хорошими" эвристическими правилами, которые сформированы индуктивными методами.
Другая работа, имеющая отношение к проблематике настройки наборов порождающих правил, посвящена описанию системы LAS (Learning Apprentice System) [Smith et al, 1985]. LAS представляет собой интерактивный инструментальный комплекс для создания и настройки баз знаний. В системе частично автоматизирован процесс формирования эвристических правил на основании теории предметной области и отладки этих правил при возникновении каких-либо проблем с их применением в экспертной системе. Работа LAS базируется на формализме сетей зависимостей (они обсуждаются в главе 19), который используется для представления обоснования правил в терминах теории предметной области. Эти же структуры используются и для формирования пояснений при возникновении сбоев в работе системы.
Разработки, упоминавшиеся в этой главе, демонстрируют возможность создания средств автоматизации формирования баз знаний. Хотя некоторые из них носят исследовательский характер, совершенно очевиден прогресс в этой области искусственного интеллекта, который позволяет надеяться, что в недалеком будущем будет устранено наиболее узкое место в создании экспертных систем — найдено эффективное решение задачи приобретения знаний.
Подводя итог всему сказанному об исследованиях в области машинного обучения, отметим, что эти исследования обещают внести значительный вклад в теорию и практику не только экспертных систем, но и других проблем искусственного интеллекта.
Рекомендуемая литература
Как отмечалось в самом начале этой главы, существует множество проблем, связанных с машинным обучением, о которых мы даже не упоминали в данной книге. Читателям, которые заинтересуются этой проблемой, я бы порекомендовал начинать знакомство с ней с обзоров [Michalski et al, 1983] и [Michalski et al., 1986] и работы [Winston, 1984, Chapter 11]. В этих статьях рассматриваются разнообразные виды машинного обучения, приложимые не только к экспертным системам.
Множество статей на эту тему публикуется в журнале Artificial Intelligence. В частности, я рекомендую познакомиться со статьями [Winston, 1982J и [Lenat, 1982]. Классификация программ обучения, основанная на анализе базовых алгоритмов, представлена в работе [Bundy et al., 1984]. Но учтите, что эта статья предполагает предварительное знакомство с основными концепциями работы систем, анализируемых в ней. Сравнительные анализ существующих систем можно найти также в работах [O'Rourke, 1982] и [Dietterich and Michalski, 1983].
Из поздних работ я бы отметил статью [Buchanan and Wilkihs, 1993], в которой вы найдете много информации о современном состоянии проблемы извлечения знаний и машинного обучения. Довольно подробное описание системы С4.5 представлено в [Quintan, 1993], причем в описание включены и листинги программ. Пространство версий рассматривается в книге [Mitchell, 1997, Chapter 2
Упражнения
1. В чем отличие методик супервизорного обучения и "обучения без преподавателя"?
2. Проведите разграничение между задачами "обучение концептам" и "обобщение дескрипторов".
3. По образцу, приведенному в тексте главы, постройте обучающую выборку для следующих концептов:
I) иностранная машина,
II) маленькая иностранная машина,
III) маленькая американская машина.
Как вы думаете, можно ли использовать в обучающей выборке для концептов II) и III) те же экземпляры, что и представленные в табл. 20.1?
4. На рис. 20.4 показаны три пары образцов. Скажите, во всех ли парах имеются более и менее специфические образцы, а если это так, то какой именно из них является более специфическим.
5. Рассмотрите обучающую выборку, представленную в табл. 20.2. Из 14 объектов 9 относятся к классу П, а 5 — к классу Н. Следовательно, энтропия множества сообщений будет равна
-(9/14)log2(9/14) - (5/14)*log2(l/J4) = 0.94 бит.
Рис. 20.4. Пары образцов
I) Чему равно ожидаемое количество информации для атрибута наблюдение?
II) Чему равен прирост количества информации после анализа атрибута наблюдение?
III) Повторите этот анализ по отношению к атрибутам влажность и ветрено.
IV) Анализ какого атрибута сулит наибольший прирост количества информации?
6. Перечислите несколько методик обучения, которые используются в практике работы с людьми, и постарайтесь разграничить эти методики по характеру. Например, методика обучения таблице умножения существенно отличается от методики обучения игре на музыкальных инструментах. Какая из методик легче всего реализуется программно и почему?
ГЛАВА 21. Сети доверия
21.1. Теория Демпстера—Шефера
21.1.1. Функции доверия
21.1.2. Применение теории Демпстера—Шефера к системе MYCIN
21.2. Методика Перла
21.3. Сравнение методов неточных рассуждений
21.4. Резюме
Рекомендуемая литература
Упражнения
ГЛАВА 21. Сети доверия
21.1. Теория Демпстера—Шефера
21.2. Методика Перла
21.3. Сравнение методов неточных рассуждений
21.4. Резюме
Рекомендуемая литература
Упражнения
В этой главе мы рассмотрим два количественных метода реализации логических рассуждений при наличии неопределенности в структурированном пространстве гипотез, базирующихся на теории свидетельств Демпстера—Шефера [Gordon and Shortliffe, 1985] и Байесовском формализме [Pearl, 1986]. Каждый из этих подходов предполагает, что на множестве гипотез каким-то способом определена функция доверия (belieffunction), а затем по мере накопления новых свидетельств применяется специфический механизм обновления текущего множества допущений.
Оба подхода будут описаны достаточно подробно, а затем будет проведено их сравнение. Будет показано, что оба метода имеют под собой более убедительное математическое обоснование, чем метод, базирующийся наэмпирических коэффициентах неопределенности, о котором шла речь в главе 9. Их можно рассматривать как альтернативу эвристическим методам обработки неопределенности, использованным в системах INTERNIST и CENTAUR, описанным в главе 13.
21.1. Теория Демпстера—Шефера
В теории Демпстера—Шефера (Dempster—Shafer) предполагается, что гипотезы — компоненты пространства гипотез 6 — являются взаимно исключающими, а набор гипотез — исчерпывающим. В терминологии авторов пространство гипотез 0 называется областью анализа (frame of discernment). Также предполагается, что мы располагаем средством получения свидетельств не только в пользу отдельных гипотез h1.....hn, принадлежащих 6, но и в пользу подмножеств гипотез A1 ..., Ak, которые могут перекрываться.
Можно рассматривать эти свидетельства как элементы множества U и построить отображение
Г:U -> 2O,
которое будет связывать каждый элемент в U с подмножеством пространства в. Такое подмножество называется фокальным элементом. Отметим, что предположение об исчерпывающей полноте набора гипотез означает, что ни один из элементов u U не отображается на пустое множество. Другими словами, для любого свидетельства существует хотя бы одна гипотеза, достоверность которой подтверждает это свидетельство.
Теория Демпстера—Шефера предлагает средства вычисления функции доверия на таких множествах гипотез и правила объединения функций доверия, сформулированных на основании разных свидетельств.
21.1.1. Функции доверия
В теории Демпстера—Шефера т — это функция присвоения базовых вероятностей (bра — basic probability assignment), которая определена на множестве 2O значений из интервала [0,1], такая, что
m(пустое множество) = 0
и
[(т(Аi) - 1];
суммирование выполняется по всем
Ai 2O.
Суммарное доверие Bel для любого фокального элемента А может быть найдено суммированием значений т по всем подмножествам в А. Таким образом, Bel является функцией, определенной на множестве 2е значений из интервала [0,1], такой, что
Bel(A) = B Am(B).
Ве1(0) всегда равно 1, независимо от значения т(O). Это следует из определения функции присвоения базовых вероятностей. Соотношение Ве1(O) = 1 означает следующее: можно с полной уверенностью утверждать, что в пространстве 0 обязательно имеется корректная гипотеза, поскольку по определению набор гипотез является исчерпывающим. Значение m(O) отображает вес свидетельства, еще не учтенного в подмножествах, входящих в пространство 0. Значения Bel и т будут равны для множеств, состоящих из единственного элемента.
Оценка вероятности фокального элемента А будет ограничена снизу оценкой доверия к А, а сверху — оценкой привлекательности А, которая равна 1 - Веl(Aс)> где Aс — дополнение к A.
Оценка привлекательности A, Рls(A), представляет степень совместимости свидетельства с гипотезами в А и может быть вычислена по формуле
Рls(A)= A^B не равно пустому множеству m(B).
Поскольку определенная таким образом оценка привлекательности А есть не что иное, как мера нашего недоверия к -A, то можно записать:
Рls (A) = 1 - Вel (-A).
Значение оценки привлекательности А можно рассматривать как предел, до которого можно улучшить гипотезы из А при наличии свидетельств в пользу гипотез-конкурентов. Удобно рассматривать информацию, содержащуюся в оценке Bel для данного подмножества, в виде доверительного интервала в форме [Вel(A), Pls(A)]. Ширина интервала может служить оценкой неуверенности в справедливости гипотез из А при имеющемся наборе свидетельств.
Правила Демпстера позволяют вычислить новое значение функции доверия по двум ее значениям, базирующимся на разных наблюдениях. Обозначим Bel1 и Веl2 два значения функции доверия, которым соответствуют два значения функции присвоения базовых вероятностей т1 и тг. Правило позволяет вычислить новое значение т1+т2, а затем и новое значение функции доверия Веl1+ Веl2, основываясь на определениях, приведенных выше.
Для гипотезы А значение т1+т2(А) есть сумма всех произведений в форме т1(Х) m2(Y), где X и Y распространяются на все подмножества в в, пересечением которых является А. Если в таблице пересечений будет обнаружен пустой элемент, выполняется нормализация. В процедуре нормализации значение k определяется как сумма всех ненулевых значений, присвоенных в множестве 0, затем т1+т2(0) присваивается значение нуль, а значения m1+m2 для всех других множеств гипотез делится на (1 - k).
Таким образом,
m1+m2= X^Y=A[m1(X)m2(Y)]/[1- X^Y=пустое множество{m1(X)m2(Y)}]
Следует учитывать, что значения т1 и m2 сформированы по независимым источникам свидетельств в пределах того же пространства гипотез. Обратите внимание и на тот факт, что вследствие коммутативности операции умножения правило Демпстера дает один и тот же результат при любом порядке объединения свидетельств.
21.1.2. Применение теории Демпстера—Шефера к системе MYCIN
Гордон (Gordon) и Шортлифф (Shortliffe) предложили использовать теорию Демпстера—Шефера в качестве альтернативы операциям с коэффициентами уверенности, применяемым в системе MYCIN. Они обратили внимание на то, что при определении организмов система MYCIN часто сужает множество рассматриваемых гипотез до определенного подмножества, включая в него, например, только грамотрицательные микроорганизмы. (Это пример того, что Кленси (Clancey) назвал применением структурных знаний.) Правила, которые порождают такое сужение пространства гипотез, ничего не говорят об относительном правдоподобии отобранных гипотез.
При использовании Байесовского подхода можно было бы предположить, что отобранные гипотезы об искомых микроорганизмах имеют равные априорные вероятности, и, следовательно, равномерно распределить между этими гипотезами веса свидетельств. Но это может привести к тому, что система не будет способна отличить случаи, когда имеются равные свидетельства в пользу каждой гипотезы, от случаев, когда такие свидетельства отсутствуют вовсе. Функция присвоения базовых вероятностей в теории Демпстера—Шефера не делает различия между априорными и апостериорными вероятностями, а потому и не приводит к такому распределению вероятностей.
Функции доверия в теории Демпстера—Шефера позволяют также избежать и другого следствия применения Байесовского подхода, противоречащего нашей интуиции. При использовании Байесовского подхода субъективная интерпретация вероятностей означает, что, доверяя в определенной степени гипотезе Я, мы тем самым изменяем степень доверия к остальным гипотезам, т.е.
Р(H) = 1 - Р(-H).
Однако одна из слабостей модели подтверждения, которая в MYCIN использует коэффициенты уверенности, состоит в том, что свидетельство, частично подтверждающее определенную гипотезу, не может рассматриваться одновременно и как свидетельство, эту гипотезу опровергающее. В теории Демпстера—Шефера изменение степени доверия к подмножеству гипотез А не принуждает к изменению степени доверия к остальным гипотезам, поскольку Веl(A) + Веl(Aс)=< 1. Остаток после суммирования степеней доверия А и к Ас — это степень игнорирования гипотезы А.
Гордон и Шортлифф показали также, как можно применить теорию Демпстера— Шефера в MYCIN для вывода суждений о гипотезах на основании поступивших свидетельств. Триада (объект-атрибут-значение), включенная в правую часть правил, представляет в каждом из них единственную гипотезу (т.е. множество гипотез, состоящее из единственного элемента), "ответственную" за данное значение определенного атрибута в определенном объекте. Следовательно, любое множество таких триад, имеющих те же самые объекты и те же самые атрибуты, например (ORGANISM-1 IDENTITY <значенае>), образует пространство гипотез в том смысле, как это трактуется в теории Демпстера— Шефера. Если параметр имеет единственное значение, условие взаимной исключительности гипотез не нарушается. Набор значений в правилах также должен быть исчерпывающим.
Таким образом, правила в системе должны быть построены как своего рода описания функций доверия в теории Демпстера—Шефера. Если посылка в правиле подтверждает заключение о гипотезе H со степенью d и d имеет значение, превышающее определенный порог активизации правила, то значение коэффициента уверенности, связанного с этой гипотезой H, можно рассматривать как функцию присвоения базовых вероятностей, которая присваивает значение d множеству {H}, состоящему из одной гипотезы, а значение 1 - d— пространству 6. Если же посылка опровергает гипотезу со степенью уверенности d, то мы присваиваем значение d множеству {H}c, значение 1 -d— пространству O, а значение коэффициента уверенности, связанного с этой гипотезой Я, будет равно -d.
Авторы выделили три варианта комбинирования свидетельств в результате выполнения правил при использовании модели Демпстера—Шефера.
(1)Оба правила либо подтверждают, либо опровергают одно и то же заключение {H}, причем правила характеризуются базовыми вероятностями т1 и т2. В этом случае некоторый вес свидетельства будет распределен между {H} и O. Обновленные значения доверия для этих двух множеств будут иметь вид т1+т2({Н}) и т1+т2(O). При этом нет необходимости применять k-нормализацию, поскольку {H} ^ O не равно 0. Оказывается, что в этом случае теория Демпстера—Шефера дает тот же результат, что и метод обработки коэффициентов уверенности.
(2) Одно правило подтверждает гипотезу {H} со степенью т1, а другое правило ее опровергает со степенью т2, т.е. подтверждает {H}с. В этом случае необходима нормализация, поскольку {H}^{H}с = 0. Иначе значения вероятностей будут комбинироваться, как и ранее:m1+m2({H}), т1+т2({Н}с) и т1+т2(O).
В этом случае результаты отличаются от полученных при использовании коэффициентов уверенности. Если применить правило Демпстера, то оказывается, что такое противоречивое свидетельство приводит к снижению поддержки и гипотезы {H}, и ее оппонентов {H}с, а растет доверие к 0. (В результате появления противоречивого свидетельства для каждого из множеств гипотез увеличивается оценка привлекательности Pls, поскольку поддержка оппонента снижается. Этот результат не согласуется с нашим интуитивным представлением о привлекательности, но следует отметить, что в теории Демстера—Шефера этот термин имеет несколько отличный от обыденного смысл.) Применение тех функций комбинирования коэффициентов уверенности, которые используются с MYCIN, скажется только на той гипотезе, которая характеризуется большим значением коэффициента уверенности.
(3) Правила выносят заключения, касающиеся двух конкурирующих гипотез {H1} и {H2}, т.е. двух множеств, каждое из которых содержит только по одному элементу. Если {H1} ^ {H2} =0, то потребуется нормализация и нужно будет вычислить значения оценок m1+m2({H1}), ml+m2({H2}) и т1+т2(O).
Правило Демпстера и в этом случае оказывается более общим, чем функции комбинирования коэффициентов уверенности в MYCIN. Это проявляется в том, что если между {H1} и {H2} существует отношение подмножества, то доверие к подмножеству будет расцениваться как доверие к супермножеству, но не наоборот. Таким образом, при использовании модели Демпстера—Шефера появление нового свидетельства оказывает большее влияние, чем при использовании прежней модели, основанной на коэффициентах уверенности.
Гордон и Шортлифф предложили приближенные методы вычислений, позволяющие снизить объем вычислительных операций по сравнению с оригинальной теорией Демпстера—Шефера. Они также обратили внимание на то, что разделение пространства поиска, подобное выполненному в системе INTERNIST, поможет выделить достаточно малое множество конкурирующих гипотез, образующих текущую область анализа. Однако в таких системах, как INTERNIST, при формировании множества конкурирующих гипотез невозможно выполнить прямое отображение вида Г:U —> 2O между отдельными свидетельствами и множествами гипотез, полагая, что симптомы могут быть причастны к разделению множеств гипотез на уровни иерархии.
За последние десять лет популярность теории Демпстера—Шефера неуклонно растет. Она находит применение в различных областях, например при решении задач диагностирования [Biswas and Anand, 1987] и машинного зрения [Provan, 1990]. Хотя эта теория и не позволяет решить проблему условной зависимости, о которой шла речь в главе 9, она предоставляет инженеру по знаниям определенную гибкость в том, что можно назначать степень доверия к подмножествам в пространстве гипотез, состоящим более чем из одного элемента. Такое назначение может служить средством кодирования зависимостей между группами свидетельств. Иерархическая организация областей распознавания способствует упрощению этой технологии обработки
21.2. Методика Перла
Альтернативой теории Демпстера—Шефера является методика Перла [Pearl, 1986], в которой свидетельства учитываются на основе Байесовского подхода к группированию и распространению влияния свидетельств на достоверность гипотез. Как и в методике, предложенной Гордоном (Gordon) и Шортлиффом (Shortliffe), предполагается, что в пространстве гипотез выделено некоторое подмножество гипотез, представляющих интерес в определенном семантическом контексте, причем это подмножество имеет иерархическую структуру.
Предполагается также, что еще до получения свидетельств с каждой отдельной гипотезой связано определенное значение степени доверия к ее правдоподобности. Перл не уточняет, каким именно способом формируются эти исходные значения, но скорее всего это должен сделать эксперт в предметной области при формулировке гипотез.
От эксперта также требуется выделить множество гипотез S, на которые непосредственно распространяется определенное множество свидетельств Е. Если свидетельства из Е непосредственно влияют на гипотезы из S, то должен существовать какой-то причинный механизм, связывающий каждый член множества S со свидетельствами, причем он является уникальным для каждого из них. Однако сами по себе свидетельства в множестве Е не несут никакой информации, которая позволила бы нам отдать предпочтение одному из членов S перед другими.
Это отображение множеств друг на друга позволяет ввести понятие условной независимости между свидетельствами и отдельными гипотезами hi:
Р(Е | S, hi) = Р(Е | S, h1), для всех hi S.
С помощью отношения вероятностей можно количественно оценить степень, с которой свидетельства подтверждают или опровергают множество гипотез S:
лS=[P(E|S)] / [P(E|-S)].
Влияние свидетельств Е на множество S вычисляется следующим образом. Каждая отдельная гипотеза hi, принадлежащая множеству S, получает вес Wi = лS , в то время как каждая гипотеза из дополняющего множества SC получает вес Wi = 1. Все это выполняется на фазе распределения весов.
Затем, когда наступает фаза обновления, вычисляется новое значение функции доверия ВЕL'(hi) по ее прежнему значению ВЕL(hi):
BEL'(hi) = P(hi | Е) = asWiВЕL(hi),
где as — коэффициент нормализации, заданный соотношением
as=( i[WiBEL'(hi))-1.]
Таким образом, степень доверия, назначенная множеству гипотез, распределяется между членами этого множества как функция их априорных вероятностей. В то же время степень доверия, назначенная группе гипотез, является суммой соответствующих показателей элементов этой группы. Обновление значений показателей доверия может выполняться рекурсивно, т.е. апостериорные оценки, полученные на основании одних свидетельств, могут использоваться в качестве априорных оценок для следующего цикла обновления при получении новых свидетельств.
Вся схема вычислений основана на предположении об условной независимости и соблюдении симметричности множеством SC, дополняющим S. Из соотношения
Р(Е | SC, hi) = Р(Е | SC, hi)
для всех
hi SC следует,
что Р(Е | hi) = Р(Е | S), если hi, hi S, иначе Р(Е | SC).
Из этого соотношения и правила Байеса следует, что P(h,| Е) = asXsP(h,), если Л, е S, иначе asP(h,).
Но, хотя Перл использует формализм Байеса, частичное свидетельство в пользу какой-либо гипотезы не может быть истолковано и как частичная поддержка отрицания этой гипотезы. Свидетельство в пользу подмножества гипотез S не может быть истолковано как свидетельство в пользу дополнения к этому подмножеству 5е.
Распределение свидетельств в пользу подмножества между отдельными гипотезами восстанавливает точечное распределение вероятностей на пространстве гипотез, но это происходит за счет точности оценок для отдельных гипотез. Перл утверждает, что нет необходимости распределять общий показатель, взятый для всего подмножества S, на его элементы до тех пор, пока не будут получены дополнительные свидетельства (или все возможные). Нормализацию также можно отложить до тех пор, пока полученные свидетельства не подтолкнут систему к выделению определенных гипотез (возможно, разных). Например, если получены свидетельства Е1, ..., Еn соответственно в пользу гипотез S1, ..., Sn, то веса будут комбинироваться мультипликативно
Wi(E1,...,En)=W1,i,W2,i... Wn,i
где
Wk,i =лSk если hi Sk,
иначе 1 .
Перл предложил также и альтернативный механизм обновления, который позволяет обойтись без нормализации и включает распространение пересмотра параметров гипотез как вверх, так и вниз по иерархической структуре с помощью передачи сообщений. С точки зрения практической реализации этот механизм кажется более привлекательным, чем правило Демпстера. Перл утверждает, что метод распространения, основанный на передаче сообщений, достаточно прозрачен, поскольку пути влияния имеют семантическое обоснование. Отказ от глобальной нормализации позволяет лучше понять результаты на промежуточных этапах распространения. Остается только один числовой параметр — отношение вероятностей, — смысл которого достаточно понятен.
21.1. Байесовские сети
В работе [Pearl, 1988] описан формализм, которому автор присвоил название Байесовские сети. Этот механизм можно рассматривать как обобщение описанных в данном разделе иерархических сетей доверия. В Байесовской сети дуги между узлами также представляют причинные зависимости, но допускается ситуация, когда некоторые узлы имеют множество родителей, причем структура сети может содержать петли. Обновление оценок доверия выполняется с помощью передачи сообщений, как и в случае строгой иерархической организации, хотя действие этого механизма очевидно только для полидеревьев, т.е. сетей, в которых между любыми двумя узлами существует единственный путь.
Представляет интерес сравнение формализма Перла и теории Демпстера — Шефера.
В системе Перла нужно присваивать априорные оценки доверия отдельным событиям, а в теории Демпстера — Шефера оценка распространяется на всю область анализа.
В системе Перла определение функции ВЕL(h1) через P(h1) и BEL'(h1) через P(h, | E) позволяет более корректно обосновать эти функции на основе выводов теории вероятностей, чего нельзя сказать о правилах комбинирования Демпстера, с чем согласился и Шефер в работе [Shafer, 1976].
Йен [Yen, 1986] обратил внимание на то, что в формализме Перла теряется понятие доверительного интервала, внутри которого могут изменяться вероятностные оценки. Доверительные интервалы очень удобно использовать в экспертных системах, поскольку они позволяют судить о "качестве" гипотез, возможности их совершенствования и ассоциированной степени неопределенности.
В своей книге [Pearl, 1988] Перл совершенно справедливо отмечает, что теория Демпстера—Шефера основана на неполной вероятностной модели, а потому может дать только частичные ответы. Вместо того чтобы непосредственно оценить, насколько близка гипотеза к тому, чтобы ее можно было считать истинной, эта теория говорит, как сильно полученное свидетельство должно продвинуть нас к убеждению, что данная гипотеза истинна. В этом отношении теория Демпстера—Шефера значительно больше напоминает объективистские методы проверки значимости с использованием доверительных интервалов, чем субъективистские методы на основе Байесовского подхода [Neapolitan, 1990].
Но, несмотря на отмеченные различия, в обоих подходах есть много общего, почему мы и рассматриваем их совместно в рамках одной главы. Ассоциирование свидетельств с подмножествами гипотез в рамках метода Перла не противоречит отображению одного множества на другое в теории Демпстера—Шефера. Оба варианта можно рассматривать как использование метафоры "массового распределения" в том смысле, что основное внимание уделяется распределению полученных свидетельств в контексте структурированного пространства альтернатив, причем оба метода позволяют вычислять значения функции доверия на основе простых вероятностных оценок.
21.3. Сравнение методов неточных рассуждений
В работе [Horvitz et al, 1986] предлагается обобщенная модель, которая может служить в качестве оболочки для сравнения альтернативных формализмов оценок доверия к гипотезам. Описанная модель появилась в ходе обширной дискуссии, призванной пролить свет на проблемы неточных рассуждений, которые проявились в процессе эксплуатации системы MYCIN. Авторы этой работы, основываясь на работах Кокса [Сох, 1946], выделили набор свойств, которыми должны обладать параметры, предлагаемые в качестве меры доверия. Идея состояла в том, чтобы обеспечить некоторый единый теоретико-вероятностный базис для сравнения альтернативных формализмов.
Предлагаемые Горвицем свойства перечислены ниже.
(Р1) Ясность. Высказывания должны быть сформулированы настолько четко, чтобы всегда можно было выполнить проверку истинности условий в них.
(Р2) Скалярная непрерывность. Степень доверия к высказыванию должна выражаться действительным числом, значение которого может непрерывно изменяться в диапазоне от полного доверия к истинности до полного отрицания истинности.
(РЗ) Полнота. Должна быть обеспечена возможность приписать значение степени доверия любому правильно сформулированному высказыванию.
(Р4) Зависимость от контекста. Степень доверия к одному высказыванию может зависеть от степени доверия к другим высказываниям.
(Р5) Гипотетическая условность. Должна существовать функция, которая позволяла бы вычислить оценку доверия к совокупности высказываний по степени доверия к одному из высказываний и оценкам доверия к другим высказываниям в предположении, что первое истинно.
(Р6) Комплементарность. Оценка доверия к отрицанию высказывания должна быть монотонно убывающей функцией от оценки доверия к самому высказыванию.
(Р7) Совместимость. Высказывания с одинаковыми значениями истинности должны иметь одинаковые оценки доверия.
Можно показать, что аксиомы теории вероятности являются логическим следствием из этих аксиом, т.е. существует непрерывная монотонная функция Ф, такая, что
(А2) Ф(TRUЕ|е)=1;
(А4) Ф(QR |e)=Ф(Q|e)Ф(R | е).
Семантические свойства оценки доверия (Р1)-(Р7) могут служить базисом для сравнения таких формализмов, которые сложно сравнивать по их аксиоматике. Этот же перечень свойств может помочь исследователям выделить такие области, в которых применение теории вероятностей в качестве базиса для оценки степени доверия не подходит. И наконец, этот перечень может помочь определить ситуации, в которых различные формализмы действительно вступают в противоречие с аксиомами теории вероятностей.
Для классификации подходов к оценке степени доверия, не основанных на теории вероятностей, Горвиц использует четыре категории:
(С1) обобщение — определенные свойства ослабляются или исчезают вовсе;
(С2) специализация — определенные свойства усиливаются или добавляются новые;
(СЗ) внутренняя несовместимость — (С2) приводит к тому, что набор свойств становится несовместимым;
(С4) подстановка — изменения свойств нельзя отнести к категориям (С1) или (С2).
Для демонстрации практического использования предлагаемой модели Горвиц сравнивает формализмы нечеткой логики (см., например, [Zadeh, 1981]), теории Демпстера — Шефера [Shafer, 1976] и коэффициентов уверенности в системе MYCIN с теорией вероятностей.
Для нечетких логик характерно ослабление свойства (Р1), поскольку в них предполагается назначение оценки доверия расплывчатым высказываниям. Формализм нечеткой логики может быть отнесен к категории (С 1 ). Расплывчатость представления об истинности в нечетких логиках несовместима со свойством гипотетической условности (Р5). Формализм нечеткой логики оценивает доверие к совокупности высказываний по минимальному значению оценки для компонентов, что противоречит аксиоме (А4). В результате Горвиц относит эти формализмы к категории (С4).
Наиболее существенным отличием теории Демпстера—Шефера от классической теории вероятностей Горвиц считает ослабление свойства полноты (РЗ). Эта теория позволяет утверждать, что определенные априорные и условные вероятности не могут быть оценены, и в ней вводится понятие отношения совместимости между допущениями. Это приводит к нарушению свойств скалярной непрерывности комплементарноети (Р6). В результате Горвиц относит эту теорию к категории обобщения теории вероятностей (С1).
В использованной в MYCIN модели на основе коэффициентов уверенности применяются более строгие предположения, чем в вероятностной модели оценки доверия, а потому ее следовало бы отнести к категории (С1). Но мы уже отмечали, что для этой модели характерна внутренняя несовместимость, и Горвиц относит ее к категории (СЗ). Предложенная в [Heckerman, 1986] новая формулировка коэффициентов уверенности в терминах отношения вероятностей является, однако, весьма удачной специализацией
21.4. Резюме
В работах Горвица (Horvitz) и Гекермана (Heckerman) продемонстрирован типичный теоретический подход к проблеме неопределенности, в котором основное внимание сосредоточено на сравнении семантик различных формальных языков вычисления оценки степени доверия. Однако нужно иметь в виду, что классическая теория вероятностей также допускает неоднозначное семантическое толкование. Например, в работе [Shafer and Tversky, 1985] отмечаются три способа интерпретации формализма Байеса:
семантика частотности — мы задаемся вопросом, как часто при наличии данного свидетельства гипотеза оказывается истинной;
семантика пари — мы определяем, каковы шансы на успех при заключении пари в пользу истинности определенной гипотезы в свете имеющихся свидетельств;
семантика склонности — мы изучаем причинно-следственную модель и пытаемся ответить на вопрос, насколько хорошо данная гипотеза объясняет наблюдаемую ситуацию.
Частотная интерпретация меры доверия используется в экспертных системах чрезвычайно редко. Например, в работе [Buchanan and Shortliffe, 1984, Chapter 11] авторы предпочитают рассматривать оценку доверия как степень подтверждаемости гипотезы, что очень близко к семантике пари. Эта же интерпретация имеет совершенно очевидную связь с оценкой степени риска, используемой в эвристических правилах MYCIN. Модель, используемая в системе INTERNIST, ближе к интерпретации склонности, поскольку в ней значительное внимание уделено возможности формирования пояснений и анализу причинно-следственных связей между свидетельствами и гипотезами.
Таким образом, ясно просматривается тенденция к повышению уровня обоснованности как в теоретических работах, так и в практическом воплощении соответствующих методов в реальных системах.
Рекомендуемая литература
В своей книге [Pearl, 1988] Перл уделяет основное внимание методам, основанным на Байесовском подходе, демонстрируя их возможности на множестве примеров, взятых из различных областей искусственного интеллекта. Эту книгу можно рекомендовать в качестве отправной точки для детального изучения проблемы обработки неопределенности в задачах искусственного интеллекта, поскольку изложенный в ней материал является самодостаточным. Структура книги позволяет читателям с разным уровнем подготовки выбирать нужный для себя материал. Более поздняя работа [Pearl, 1997] содержит описание последних исследований в этой области, включая и теорию сетей доверия. Среди других книг на эту тему я бы выделил [Jensen, 1996] и [Shafer and Pearl, 1990].
Упражнения
1. На рис. 21.1 приведена схема простого пространства гипотез для задачи поиска неисправности в автомобиле. Корневой узел, неисправность автомобиля, представляет множество неисправностей {неисправность системы подачи топлива, неисправность электрооборудования}. Узел неисправность системы подачи топлива представляет множество {неисправность карбюратора, неисправность бензопровода}, а узел неисправность электрооборудования — множество {неисправность аккумуляторной батареи, неисправность распределителя}. Таким образом, узел неисправность автомобиля можно рассматривать как представляющий всю область анализа.
Э = {неисправность системы подачи топлива, неисправность электрооборудования, неисправность карбюратора, неисправность бензопровода}.
Рис. 21.1. Пространство гипотез о неисправностях в автомобиле
I) Предположим, что степень подтверждения диагноза неисправность карбюратора имеющимися свидетельствами оценивается значением 0.8. Вычислите т(неисправность бензопровода), т(неисправность электрооборудования) и m(0).
II) Предположим, что степень опровержения диагноза неисправность системы подачи топлива имеющимися свидетельствами оценивается значением 0.6. Вычислите т{неисправность электрооборудования).
Ill) Предположим, что степень подтверждения диагноза неисправность карбюратора имеющимися свидетельствами оценивается значением 0.2, а диагноза неисправность бензопровода— значением 0.5. Вычислите т(неисправность системы подачи топлива). .
2. Используя пространство гипотез, представленное на рис. 21.1, предположим, что степень подтверждения диагноза неисправность системы подачи топлива имеющимися свидетельствами оценивается значением 0.3, а диагноза неисправность аккумуляторной батареи — значением 0.6. Вычислите значения т для всех узлов графа, используя правило Демпстера.
3. Пусть на пространстве гипотез, представленном на рис. 21.1, априорные вероятности отдельных гипотез равны:
Равноправность карбюратора) = 0.4;
Р(неисправность бензопровода) = 0.1;
Р(неисправность аккумуляторной батарей) = 0.3.
Предположим, что имеется свидетельство е, такое, что
Р(е| неисправность карбюратора) = 0.3;
Р(е| —неисправность карбюратора) = 0.5;
Р(е| неисправность бензопровода) = 0.2;
Р(е| —(Неисправность бензопровода) = 0.4;
Р(е| неисправность аккумуляторной батареи) = 0.6;
Р(е| —(Неисправность аккумуляторной батареи) - 0.3;
Р(е| неисправность распределителя) = 0.7;
Р(е| —(неисправность распределителя) = 0.1.
Вычислите новые значения оценок доверия к каждой из гипотез, используя метод Перла.
ГЛАВА 22. Рассуждения, основанные на прецедентах
22.1. База прецедентов
22.1.1. Программа CHEF
22.1.2. Методы извлечения и адаптации прецедентов
22.2. Обучение с помощью компьютера: система САТО
22.2.1. Предметная область программы САТО
22.2.2. Расследования и рассуждения в юриспруденции
22.2.3. Обучение с помощью системы САТО
22.3. Формирование отчетов в системе FRANK
22.4. Сравнение систем, основанных на правилах и прецедентах
Рекомендуемая литература
Упражнения
ГЛАВА 22. Рассуждения, основанные на прецедентах
22.1. База прецедентов
22.2. Обучение с помощью компьютера: система САТО
22.3. Формирование отчетов в системе FRANK
22.4. Сравнение систем, основанных на правилах и прецедентах
Рекомендуемая литература
Упражнения
В главе 2 мы отмечали, что в ранних программах искусственного интеллекта отчетливо прослеживалась тенденция использовать по возможности единообразные методы решения проблем. Логические рассуждения строились на основе небольшого количества предположений или аксиом, а множество правил, применяемых для формирования нового состояния проблемы, также было невелико. Такие классические области искусственного интеллекта, как игры и доказательство теорем, являются формальными системами, которые по самой своей сути годятся для подобной комбинации логического анализа и эвристического поиска. Хотя в подавляющем большинстве экспертных систем применяется большое количество правил, специфичных для определенной предметной области, и используются разнообразные методы решения проблем, способы поиска и организации логического вывода, по сути, не очень отличаются от тех, что использовались в ранних программах искусственного интеллекта.
Например, в процессе работы производящей системы представление состояния проблемы в рабочей памяти последовательно изменяется, все более приближаясь к состоянию, характеризующему искомое решение. Такой пошаговый процесс очень напоминает последовательность ходов, дозволенных правилами игры, а отличие заключается в основном в семантике используемых правил. Программа игры в шахматы, основанная на знаниях, должна опираться не только на правила выполнения ходов, но и на информацию о стратегии, типовых ситуациях на доске, способах распознавания стадий игры (дебют, миттельшпиль или эндшпиль) и т.д.
Существует, однако, множество рутинных задач, выполняемых человеком, которые не вписываются в эту парадигму. Трудно себе представить, что, решая задачу, куда пойти сегодня вечером (в какой ресторан или кинотеатр), человек сознательно или подсознательно выполняет логический анализ или эвристический поиск. Если обратиться к менее тривиальным примерам, то также трудно поверить, будто судья, архитектор или ваш шеф, принимая решение, всегда прибегают к логическому анализу. Скорее всего, в большинстве случаев в основе наших действий в повседневных ситуациях лежит другой механизм рассуждений и принятия решения.
В отличие от большинства машин, человек почти всегда чем-то занят или озабочен, а потому при решении повседневных проблем уже на подсознательном уровне стремится сэкономить время и силы. И здесь на помощь всегда приходят память и прежний опыт — для человека проще распознать ситуацию и найти для нее аналог, чем заново формировать решение.
Но как все это можно реализовать в компьютерной модели рассуждений? Мы уже знаем, что воспоминания и приобретенный опыт не так просто свести к набору правил, но можно представить себе некоторую "библиотеку" ситуаций, встречавшихся в прошлом, которые имеют отношение к возникшей проблеме, например "репертуар" указаний шефа, или судебные решения, принятые в прошлом по аналогичным делам, или наброски архитектурных планов для сооружений аналогичного назначения и т.п. Естественно, что такая библиотека должна быть индексирована каким-то разумным способом, чтобы в массиве хранящихся описаний ситуаций можно было довольно быстро распознать аналогичную текущей. Кроме того, понадобится также и некоторый механизм, который позволит адаптировать ранее принятое решение к новой проблеме (текущей ситуации).
Описанный подход получил наименование рассуждение, основанное на прецедентах (case-based reasoning). Мы рассмотрим эту новую технологию на трех примерах, взятых из разных предметных областей, — кулинарии, юриспруденции и делопроизводства. После этого мы вновь вернемся к сравнению рассуждений, основанных на прецедентах, с более привычной технологией логического вывода в экспертных системах и покажем, что эти технологии не противоречат, а дополняют друг друга. В главе 23 этот тезис будет подкреплен примерами и дальнейшим анализом.
22.1. База прецедентов
Приведенная выше аналогия с библиотекой удобна, но является далеко не полной. Прецеденты — это не книги; хотя их и связывают с книгами некоторые общие абстрактные свойства, имеются и существенные отличия.
Прецеденты напоминают книги (конечно же, не из разряда беллетристики) тем, что содержат определенную специфическую информацию, "вставленную" в некоторый контекст. Содержимое прецедента — это знание, а контекст описывает некоторое состояние внешнего мира, в котором это знание применяется. Однако прецедент содержит знание в такой форме, которая может быть воспринята программой. Другими словами, знания, содержащиеся в описании прецедента, "готовы к употреблению" в том же смысле, в каком порождающие правила готовы к применению.
Прецедент должен представлять решение проблемы в определенном контексте и описывать то состояние мира, которое получится, если будет принято предлагаемое в нем решение. Это свойство часто можно встретить и в содержимом книг, но, опять же, разница состоит в том, что информация не представлена в форме, удобной для восприятия программой.
Хотя описания прецедентов и варьируются по размеру, они все-таки значительно уступают книгам в этом смысле. Информация в описаниях прецедентов значительно более сжата и представляется на каком-либо формальном языке.
Если прецедент — это модуль знаний, который может быть считан программой, то в чем его отличие от других способов представления знаний, множество которых мы уже рассмотрели в этой книге? Самый короткий ответ на этот вопрос — прецедент, как правило, реализуется в виде фрейма (см. главу 6), в котором структурированы информация о проблеме, решение и контекст. Так же, как фрейм или порождающее правило, описание прецедента может быть сопоставлено с данными или описанием цели. Но для извлечения описания прецедента из базы таких описаний используется совсем другой механизм, чем для извлечения фрейма или порождающего правила. Первое, что делается в процессе применения прецедента, — его адаптируют к текущей ситуации. Поэтому поиск описания прецедента требует использования достаточно сложного механизма индексирования.
22.1.1. Программа CHEF
Для демонстрации возможностей экспертной системы, базирующейся на прецедентах, рассмотрим систему CHEF, которая предназначалась для формирования кулинарных рецептов [Hammond, 1986]. Эта программа принимает информацию о целевых характеристиках блюда (тип, вкусовые качества, своеобразие) и формирует подходящий рецепт. Например, программа может получить следующий "заказ":
блюдо из баранины (beef);
включает брокколи (broccoli);
использует поджаривание (stir-fry);
блюдо должно получиться хрустящим (crisp).
Заказ оформляется в виде выражения на специальном формальном языке:
dish(beef), include(broccoli), method(stir-frv), texture(crisp)
Результатом работы программы должен быть рецепт— последовательность операций, позволяющая приготовить такое блюдо.
Получив заказ, программа просматривает свою базу прецедентов, отыскивает в ней рецепт приготовления аналогичного блюда и адаптирует его в соответствии с особенностями текущего заказа (проблемы). Например, если в базе уже имеется рецепт для баранины с зеленым горошком, его можно скопировать и вместо горошка вставить брокколи. Этим, правда, адаптация не исчерпывается, поскольку горошек варится, а не жарится, как указано в заказе. Раз блюдо будет жариться, значит, брокколи придется сначала измельчить (если бы нужно было варить, то качанчики брокколи можно было бросать в воду целиком), следовательно, первоначальный план придется дополнить еще одной операцией. Кроме того, если кусочки баранины и броколли жарить вместе, то броколли, вероятно, пропитается соком. Значит, в системе нужно иметь правило, которое определит этот факт и изменит первоначальный простой план, — предложит сначала обжарить брокколи, а затем вынуть их.
На рис. 22.1 представлена упрощенная схема той части программы CHEF, которая имеет отношение к манипуляциям с базой прецедентов.
Рис. 22.1. Архитектура программы CHEF
Модель извлечения отыскивает в базе прецедентов рецепты, наиболее близкие к текущему заказу. Очевидно, что этот модуль должен обладать способностью обращаться к базе прецедентов как к памяти, адресуемой по содержанию, оценивать степень соответствия между набором входных спецификаций и характеристиками выбранного прецедента и ранжировать отобранные прецеденты на основании этой оценки.
Модуль модификации затем копирует и переименовывает выбранный прецедент и пытается скорректировать его в соответствии с полученной целевой спецификацией. В приведенном выше примере подстановка "брокколи" вместо "зеленый горошек" и модификация плана выполняются именно этим модулем.
После выполнения всех необходимых коррекций новый рецепт записывается модулем сохранения в базу прецедентов.
В программе CHEF корректировка неудачного плана (рецепта) в действительности выполняется отдельным модулем, который имеет доступ к специальному словарю термов, описывающих отказы, и индексированному множеству стратегий восстановления. Имеется также и специальный "симулятор", который позволяет "проиграть" сформированный рецепт и выявить в нем подводные камни, не заметные на первый взгляд. По основные модули работы с прецедентами выполняют именно те функции, которые мы описали выше.
22.1.2. Методы извлечения и адаптации прецедентов
В системах формирования суждений на основе прецедентов используются разные схемы извлечения прецедентов и их адаптации к новым проблемам.
В таких программах, как CHEF, сопоставляются описания имеющихся прецедентов и полученная спецификация цели, причем в качестве основного средства сопоставления выступает семантическая сеть (см. главу 6). В примере, рассмотренном в предыдущем разделе, модулям извлечения и модификации известно, что и брокколи, и зеленый горошек — это свежие овощи. Модуль извлечения использует эту информацию для вычисления оценки степени близости прецедента и целевой спецификации, а модуль модификации использует эту же информацию для подстановки в рецепт одного ингредиента вместо другого. Это фоновое знание играет весьма существенную роль в решении обеих задач.
Сложность поиска решения и выявления различий между прецедентами в значительной степени зависит от используемых термов индексации. По сути, прецеденты в базе прецедентов конкурируют, пытаясь "привлечь" к себе внимание модуля извлечения, точно так же, как порождающие правила конкурируют за доступ к интерпретатору. В обоих случаях необходимо использовать какую-то стратегию разрешения конфликтов. С этой точки зрения прецеденты должны обладать какими-то свойствами, которые, с одной стороны, связывают прецедент с определенными классами проблем, а с другой — позволяют отличить определенный прецедент от его "конкурентов". Например, в программе CHEF прецеденты индексируются по таким атрибутам, как основной ингредиент блюда, гарнир, способ приготовления и т.п., которые специфицируются в заказе.
Механизм сопоставления должен быть достаточно эффективным, поскольку исчерпывающий поиск можно применять только при работе с базами прецедентов сравнительно небольшого объема. Одним из популярных методов эффективного индексирования является использование разделяемой сети свойств (shared feature network). При этом прецеденты, у которых какие-либо свойства совпадают, включаются в один кластер, в результате чего формируется таксономия типов прецедентов. Сопоставление в такой разделяемой сети свойств выполняется с помощью алгоритма поиска в ширину без обратного прослеживания. Поэтому время поиска связано с объемом пространства логарифмической зависимостью. Индивидуальное сопоставление, как правило, выполняется следующим образом.
Каждому свойству (или размерности)присваивается определенный вес, соответствующий степени "важности" этого свойства. Если, например, прецеденты включают счета пользователей, то имя пользователя, скорее всего, не имеет значения при поиске группы прецедентов с похожими счетами. Следовательно, свойство имя может иметь вес 0. А вот остаток на счете (в долларах) имеет очень существенное значение и ему следует придать вес 1.0. Чаще всего значения весов — это действительные числа в интервале [0,1].
Из всех этих рассуждений вытекает простой алгоритм сопоставления прецедентов, представленный ниже.
Присвоить MATCH = 0.0;
Для каждого свойства в исходной спецификации
{
2. Найти соответственное свойство в хранимых прецедентах.
3. Сравнить два значения и вычислить степень близости т.
4. Умножить эту оценку на вес свойства с.
5. Присвоить MATCH = MATCH + cм.
}
Возвратить MATCH.
Базовая процедура называется сопоставлением с ближайшим соседом (Nearest-Neighbor matching), поскольку прецеденты, которые имеют близкие значения свойств, и концептуально ближе друг другу. Это может найти отражение и в структуре сети, где степень близости прецедентов будет соответствовать близости их свойств.
Вычисленное по этому алгоритму значение MATCH обычно называется агрегированной оценкой совпадения (aggregate match score). Естественно, что из базы прецедентов выбирается тот, который "заслужил" самую высокую оценку. Если же алгоритм работы системы предполагает и исследование альтернативных прецедентов, то оставшиеся должны быть ранжированы по полученным оценкам. Большинство доступных на рынке программ, имеющих дело с базами прецедентов, использует именно этот простой алгоритм. Применяемый на шаге (2) метод вычисления степени близости зависит от типа данных в каждом конкретном случае. При качественном сопоставлении свойств достаточно будет использовать двоичные оценки или вычислять расстояние в абстрактной иерархии. Так, в абстрактной иерархии ингредиентов кулинарных рецептов "брокколи" ближе к "горошку", чем к "цыплятам", и вычисленное значение должно отражать этот неоспоримый факт. Количественное сопоставление будет включать и шкалирование.
Для адаптации найденного прецедента к текущим целевым данным программы также используют разные методы. В большинстве случаев можно обойтись заменой некоторых компонентов в имеющемся решении или изменением порядка операций в плане. Но существуют и другие подходы, которые перечислены ниже.
Повторная конкретизация переменных в существующем прецеденте и присвоение им новых значений. Например, сопоставление переменной овощи со значением брокколи вместо прежнего значения горошек.
Уточнение параметров. Некоторые прецеденты могут содержать числовые значения, например время выполнения какого-либо этапа плана. Это значение должно быть уточнено в соответствии с новым значением другого свойства. Например, если в рецепте требуется заменить один ингредиент другим, то, вероятно, придется соответственно изменить и время его обработки.
Поиск в памяти. Иногда требуется найти способ преодоления затруднения, возникшего как побочный эффект замены одних компонентов решения другими. Примером может послужить уже упоминавшийся выше эффект нежелательного изменения свойств брокколи при обжаривании вместе с кусочками баранины. Такой способ можно отыскать в той же базе прецедентов или в специальной базе знаний.
Большинство из перечисленных методов жестко связано со способом представления иерархии абстракций, который используется в конкретной программе. Это может быть система фреймов или семантическая сеть, и в каждом из этих вариантов подстановка одних концептов вместо других должна быть организована по-своему.
В следующем разделе мы рассмотрим систему, в которой используется довольно специфический способ представления знаний для моделирования предметной области. Для организации базы прецедентов в этой системе используется не разделяемая сеть свойств, а факторы более высокого уровня абстракции, связанные со спецификой предметной области. Такое представление требует применения более сложного механизма индексирования прецедентов и их поиска, чем тот, который использовался в модуле извлечения программы CHEF.
22.2. Обучение с помощью компьютера: система САТО
В главах 11 и 12 мы уже говорили о том, что при работе над экспертными системами второго поколения исследователи пришли к выводу, что представление знаний внутри экспертной системы должно со временем привести к созданию систем обучения с помощью компьютера (CAI — computer-aided instruction). Если в нашем распоряжении имеется программа, которая успешно решает определенный круг проблем, то она, вероятно, может быть использована и для того, чтобы научить студентов решать аналогичные проблемы.
Однако оказалось, что превратить экспертную систему в эффективное средство обучения далеко не так легко, как это кажется с первого взгляда. Программа должна отдавать себе отчет в том, как именно она решает проблему и почему на данном этапе процесса отдает предпочтение именно таким знаниям. Исследователи пришли к выводу, что в процессе обучения особую важность имеет набор стратегий решения проблем и что эти стратегии должны быть представлены в программе в явном виде, а не просто реализованы в программном коде.
В этом разделе мы опишем программу САТО, которая была создана для обучения студентов-юристов методике ведения судебных дел. В основу программы положена абстрактная модель процесса прения сторон. Программа является развитием системы HYPO, в которой используется описанная выше методика анализа прецедентов для юриспруденции. База прецедентов этой системы содержит множество отчетов о судебных делах; получив спецификацию нового дела, система отыскивает наиболее близкий прецедент и анализирует отличия между ним и полученными данными. Мы увидим, что методика сравнения и противопоставления (compare and contrast) является таким же мощным средством решения проблем, как и ранее рассмотренные методики предложение и применение и предположение и проверка.
22.2.1. Предметная область программы САТО
Ежедневно в апелляционных судах США выносится около 500 судебных решений. Каждое из них представляет собой определенный прецедент в судебной практике (подборки таких отчетов распространяются через сеть World Wide Web или на компакт-дисках). Решение, принимаемое апелляционным судом, как правило, основывается на так называемом "прецедентном праве" и включает интерпретацию соответствующих статей существующего законодательства и набор прецедентов, в которых были приняты аналогичные решения. Для юриста одним из главных компонентов знания законодательства, касающегося дел определенного вида, например о банкротстве или об ответственности за выпуск продукции, является знакомство с ранее расследованными подобными делами.
Другая часть юридического знания — умение найти в законодательстве аргументы за или против определенных обстоятельств в конкретном деле. Поскольку квалифицированный юрист должен уметь выступать в обеих ипостасях— и как защитник, и как прокурор, — такие знания должны быть обобщены. Они непременно должны включать стратегию поведения обеих сторон в судебном процессе при определенных обстоятельствах. Эти обстоятельства включают по большей части мириады фактов, сопряженных с рассматриваемым делом, т.е. кто кому что сделал или что точно сказал и в каком контексте.
Хотя кажется невероятным, что компьютер может взять на себя роль советчика в юридических делах, юристы вполне могут воспользоваться им для поиска прецедентов, имеющих отношение к тому, что их интересует в настоящее время. Поиск и интерпретация таких прецедентов представляет собой отнюдь не тривиальную задачу, которую с полным правом можно отнести к классу интеллектуальных. Однако нас сейчас интересует не столько такая экспертная система, сколько структура программы, которая могла бы обучить будущего юриста.
22.2.2. Расследования и рассуждения в юриспруденции
И расследования, и рассуждения в юриспруденции направляются аргументацией, а более точно — аргументами, выражающими противоположные интересы, с помощью которых стороны процесса пытаются склонить на свою строну судью или присяжных, убедить их в том, что именно предлагаемая интерпретация закона и фактов является корректной в данном случае. Забота сторон в процессе, т.е. юристов, выступающих от имени сторон, не столько установить истину (это — забота судьи и присяжных), сколько наилучшим образом представить в судебном процессе интересы клиента. Следовательно, в том, что происходит в судебном заседании, имеется некоторый аспект игрового соперничества — стороны делают определенные ходы в борьбе за преимущество.
Базовая предпосылка, сделанная разработчиками системы САТО, состоит в том, что эти ходы могут быть описаны в рамках какой-то системы и затем использованы для обучения. Для выполнения очередного хода в игре нужно выбрать прецеденты в базе знаний о прецедентах, причем выбор должен учитывать как информацию о текущем случае, так и возможные ходы оппонентов. Таким образом, поведение сторон можно рассматривать как планирование трехходовой комбинации в игре:
одна сторона с помощью своего набора прецедентов "продвигает" свою позицию в игре;
противоположная сторона выдвигает другой набор прецедентов для представления своих аргументов;
первая сторона наносит новый удар, выдвигая соображения, парирующие в определенной степени аргумент противной стороны.
Ходы и контрходы можно анализировать в терминах суждений, основанных на прецедентах. Эшли считает, что в основе такой модели аргументации лежит следующий процесс [Ashley, 1990].
(1) Сравнение текущего случая с прецедентом с прицелом на обоснование аналогичного результата.
(2) Определение отличия (противопоставление) между текущим случаем и прецедентом, чтобы найти аргумент против того же результата.
(3) Поиск контрпримера к (1), в котором аналогичный прецедент привел к другому результату.
(4) Формулировка гипотетических прецедентов, которые дали бы аргументы за и против определенной позиции.
(5) Комбинирование сравнений и противопоставлений в аргумент, который включает оценку конкурирующих аргументов.
Эта модель аргументации реализована в системе HIPO, в которой процесс формирования аргумента выполняется за шесть шагов.
(1) Анализ факторов, присущих текущему случаю.
(2) Извлечение прецедентов на основе этих факторов.
(3) Упорядочение извлеченных прецедентов по степени близости к текущему случаю.
(4) Выбор наиболее подходящих прецедентов как с точки зрения одной стороны, так и с точки зрения другой.
(5) Формирование аргументов для трехходовой комбинации по каждому из пунктов текущего дела.
(6) Проверка результатов на гипотетических случаях.
Выполнение шага (5) усложняется тем обстоятельством, что судебное дело может содержать более одного пункта. Например, дело о разводе может содержать множество пунктов, касающихся раздела имущества, обеспечения детей и т.д., по каждому из которых стороны должны представить свои аргументы.
22.2.3. Обучение с помощью системы САТО
При разработке системы САТО преследовалась цель предоставить в распоряжение студентов-юристов среду, в которой они могли бы научиться вести рассуждения в ходе разбора судебного дела и проверять гипотезы относительно применения статей закона [Ashley and Aleven, 1997], [Aleven and Ashley, 1997]. Как было сказано в предыдущем разделе, в процессе обсуждения дела в судебном заседании нужно уметь формулировать собственные аргументы и опровергать аргументы противной стороны. Важной частью судебных прений является также умение формулировать и проверять гипотезы о возможности применения тех или иных статей закона к рассматриваемым обстоятельствам дела.
Задача студента при работе в этой среде состоит в том, чтобы проанализировать обстоятельства дела с юридической точки зрения и сформулировать аргументы в пользу обеих сторон, т.е. как в пользу истца, так и в пользу ответчика. Эти аргументы должны включать список прецедентов, выбранных из базы прецедентов системы, которые каждая из сторон может использовать, отстаивая свою точку зрения. В той версии системы, которая существует в настоящее время, представлены юридические знания о соблюдении секретности при выполнении торговых сделок, т.е. законы, касающиеся контроля конфиденциальной коммерческой информации, которая не должна использоваться в нечестной конкурентной борьбе.
В типичном судебном деле о торговых секретах истец утверждает, что ответчик каким-то образом получил доступ к конфиденциальной информации и затем использовал ее для получения преимущества в конкурентной борьбе. Сторонами в процессе, как правило, но не всегда, являются компании, а конфиденциальная информация носит технический характер. Для всех дел такого рода характерны некоторые общие черты. Например, предпринимал ли истец меры для защиты информации от несанкционированного доступа, давал ли ответчик обязательство не использовать полученную информацию или воспрепятствовать доступу к ней со стороны третьих лиц.
Для анализа конкретного дела можно использовать специальный словарь, ассоциированный с этими темами. База системы САТО содержит около 150 прецедентов, которые проанализированы в отношении ряда факторов. Ниже представлены примеры типичных факторов и их определения.
Преимущество в конкуренции. Получение ответчиком доступа к секретной информации истца дает ответчику преимущество в конкуренции.
Раскрытие секретов. Истец по собственной воле не предоставлял посторонним доступ к информации.
Подкуп служащих. Ответчик подкупил служащих истца, для того чтобы они нарушили обязательства, данные при приеме на работу.
Такие факторы используются для организации индексации прецедентов в базе. Факторы классифицированы в соответствии с тем, аргументы какой из сторон они поддерживают. Эта информация вместе со знанием, какая же из сторон в конце концов выиграла дело, позволяет выполнить довольно интересный анализ прецедентов.
Задав булеву комбинацию факторов по своему выбору, студент может извлечь из базы соответствующие прецеденты и выяснить, какая часть дел была выиграна каждой из сторон в указанных обстоятельствах.
Студент может выбрать из базы те прецеденты, в которых сочетание факторов аналогично рассматриваемому случаю, и проанализировать поведение сторон в ходе судебных прений.
База данных САТО содержит не полные отчеты о судебном разбирательстве, а "выжимки" из него, но поиск в базе осуществляется не по тексту протокола заседания, а по индексированным факторам, что упрощает общение студента со средой.
Информация о прецеденте, извлеченная из базы данных, содержит список факторов этого прецедента, указание, какие из факторов обнаружены и в текущем деле, а какие в нем отсутствуют, в пользу какой из сторон "сыграл" каждый из факторов. Использование более сложного механизма индексации позволяет моделировать и более интеллектуальные методы рассуждений.
Спор вокруг подобия и различия между рассматриваемым делом и прецедентами в значительной мере зависит от того, на каком уровне абстрагирования он ведется. Каждая из сторон выбирает определенную интерпретацию пунктов текущего дела в сравнении с прецедентами. Аргументируя близость, адвокат должен выбрать такие факторы, которые подобны в рассматриваемом деле и прецеденте, и доказать, что именно они играют существенную роль на данном уровне абстракции, в то время как несовпадающие факторы можно игнорировать как несущественные. Если же цель состоит в том, чтобы отвергнуть прецедент, на который ссылается противоположная сторона, нужно доказать, что наиболее существенные факторы в рассматриваемом случае как раз отличаются от прецедента.
Такой способ рассуждения уже не может опираться на обычную семантическую сеть. В иерархии факторов, помимо маркирования каждого из факторов, в чью пользу, истца или ответчика, он "играет", в явном виде должны быть представлены отношения между ними. Лучше проиллюстрировать это соображение примером.
На рис. 22.2 показан фрагмент иерархии факторов в системе САТО. Верхний узел на представленном фрагменте, средства поддержания секретности, представляет фактор, посредством которого истец, ссылающийся на нарушение режима конфиденциальности, утверждает, что с его стороны были предприняты необходимые меры обеспечения секретности. (Утолщенная рамка вокруг этого узла указывает, что данный фактор "работает" в пользу истца.)
Рис. 22.2. Фрагмент иерархии факторов в системе САТО ([Ashley and Aleven, 1997])
Существуют субфакторы, которые поддерживают это утверждение. Например, факт, что были предприняты определенные меры обеспечения безопасности, которые должны были предотвратить утечку информации, очевидно, поддерживает в споре позицию стороны истца. (Связи таких субфакторов с родительским узлом помечены знаком "плюс", поскольку они поддерживают родительский узел в иерархии — "усиливают" завоеванную им позицию.) Существуют, однако, и субфакторы, которые "ослабляют" эффект утверждения, порождаемого родительским фактором. Например, если истец однажды подписал отказ от режима конфиденциальности или разрешил своему служащему ознакомить с этой информацией посторонних на каком-нибудь общедоступном форуме, например, на технической конференции. Такие факторы ослабляют позицию, завоеванную родительским фактором, и потому соответствующие связи маркируются знаком "минус".
Субфакторы, в свою очередь, могут иметь собственные субфакторы, которые также объединены с родительскими узлами положительными или отрицательными связями. В САТО используется несколько алгоритмов, с помощью которых выносится решение, на каком уровне абстракции в этой иерархии нужно сфокусировать аргументы, если желательно подчеркнуть подобие случаев или их различие. Подробное .описание этих алгоритмов выходит за рамки настоящей книги, но главная их особенность заключается в том, что они основаны на применении очень специфичной схемы индексирования, связанной с базой знаний о предметной области.
22.3. Формирование отчетов в системе FRANK
Работая над каким-либо отчетом, авторы могут преследовать совершенно различные цели. В одних случаях составляется беспристрастный обзор состояния дел, в других материал отчета должен подвести читателя к определенному выводу (желательному для автора), в третьих — обосновать определенное решение, принятое ранее. От того, с какой целью составляется отчет, зависит и подбор информации в нем, и стратегия ее освещения. Например, готовя обзор состояния исследований в определенной области для научного журнала, автор старается охватить как можно больший материал, в то время как адвокат в своем отчете ограничивается только теми прецедентами, которые интересуют его клиента.
Система FRANK [Rissland et al., 1993] относится к классу систем с доской объявлений, в которой объединены парадигмы вывода суждений на основе правил и прецедентов и которая предназначена для формирования отчетов по медицинской диагностике. (Название FRANK — искаженная аббревиатура от Flexible Report and Analysis System.) Основной упор при разработке системы был сделан на взаимодействие между целями высокого уровня, которые ставит перед собой автор отчета, и информационными подцелями, такими как извлечение подходящих прецедентов.
В состав системы FRANK входят три главных компонента (рис. 22.3).
Модуль планирования обеспечивает управление функционированием системы. Он выбирает заготовку плана из библиотеки планов, а затем выполняет иерархическое планирование, конкретизируя выбранную заготовку.
Модуль формирования суждений на основе прецедентов и модуль продукционной системы (в действительности эту функцию выполняет модуль OPS5) выполняют логический вывод в предметной области, опираясь на соответствующие базы знаний.
Модуль формирования отчета для пользователя имеет в своем распоряжении разнообразные стратегии, которые базируются на знаниях из области риторики.
Знания, которыми располагает система FRANK, разделены между тремя иерархическими структурами.
В иерархии отчетов отчеты классифицированы соответственно целям их создания. Например, является ли отчет суммирующим или аргументирующим, отстаивающим определенную позицию или нейтральным и т.д.
В иерархии стратегий решения проблем представлены знания о том, как собирать информацию для отчета определенного типа, например как отыскать подходящие данные или как поступать с данными, поддерживающими противоположное заключение.
Из иерархии стратегий презентации система черпает знания о том, как скомпоновать выводы в отчете. Например, стоит ли сначала располагать веские аргументы или лучше начать с анализа достоинств и недостатков альтернативных вариантов.
Рис. 22.3. Архитектура системы FRANK
Поток управления в системе можно описать в терминах последовательности шагов обращения к источниками знаний, которые манипулируют данными на доске объявлений (см. об этом в главе 18). Вместо того чтобы по очереди описывать каждый источник знаний, мы представим основные этапы обработки, в результате которых формируется и выполняется план построения отчета. Исходные данные имеют формат перечня тем (например, нужно ли, чтобы определенная медицинская процедура была подтверждена случаями из практики), а выход системы — это отчет, в котором темы изложены в соответствии с заявленными предпочтениями.
Начальный источник знаний формирует скелет отчета, в котором зарезервированы разделы для определенных фрагментов информации.
Затем формируются стратегии для отдельных разделов, для чего привлекаются другие источники знаний. Стратегии извлекают планы разделов из библиотеки планов.
Специальный источник знаний конкретизирует каждый план и выполняет его, активизируя соответствующую цель. После формирования цепочки "цель—подцель" удовлетворяются цели нижних уровней. Как правило, такие подцели заполняют слоты шаблона отчета.
Другие источники знаний проверяют совместимость разделов отчета. Если противоречия не обнаруживаются, выходной документ формируется в соответствии со стратегией презентации. В противном случае корректируется план.
Таким образом, сначала система на основании введенной пользователем информации выбирает тип отчета. Например, пользователь может запросить у системы отчет с предложением, который должен обосновать определенный диагноз. В этом случае система FRANK выберет отчет типа Diagnosis-with-Alternatives (диагнозы и варианты) и воспользуется стратегией уравнивающее сравнение (equitable comparison), которая назначается для этого типа отчета по умолчанию.
Комбинируя тип отчета и стратегию, система строит определенный план, в котором, в частности, есть место и для информации о прецедентах, подходящих для текущего диагноза. Наиболее подходящий прецедент выбирается по совпадению большинства симптомов с анализируемым случаем, но возможны и другие стратегии.
Например, более аргументированная стратегия может потребовать, чтобы прецедент считался подходящим, если:
он совпадает по большинству симптомов с текущим случаем; Ф имеет совпадающий диагноз;
не содержит никаких свойств, подобных прецедентам, имеющим другой диагноз.
А что произойдет, если не будет найден прецедент, отвечающий перечисленным требованиям? Тогда требования ослабляются (например, убирается последнее из перечисленных), и поиск повторяется.
Формирование запросов к базе прецедентов выполняется под присмотром источника знаний, который играет роль механизма планирования задач. Такие запросы могут быть частичными, т.е. определенные атрибуты запроса заполняются значениями по умолчанию. Этот же модуль обеспечивает различные варианты поведения системы, если поиск не даст результата. В частности, могут быть изменены ограничения на значения параметров в запросе, после чего поиск возобновляется.
Система FRANK поддерживает две методологии формирования суждений на основе прецедентов:
стиль поиска ближайшего соседа, как в системе CHEF;
группирование прецедентов по степени "похожести" в соответствии с определенным набором факторов верхнего уровня, как в системе САТО.
Выбор той или иной методологии зависит от контекста отчета. Например, атрибуты низкого уровня (вроде возраста и пола пациента) могут быть менее важными, чем факторы высокого уровня, используемые для классификации медицинских процедур. Но возможен и такой вариант, когда к определенной проблеме никак не удается применить факторы верхнего уровня и остается полагаться только на атрибуты нижнего уровня.
Такая гибкость в выборе методологии позволяет уравновесить влияние целей высокого уровня и результатов низкого уровня
22.4. Сравнение систем, основанных на правилах и прецедентах
Существует достаточно сильная аналогия между системами, основанными на правилах и прецедентах. И те и другие необходимо каким-то образом индексировать, чтобы обеспечить эффективное извлечение. И те и другие выбираются в результате сопоставления, причем выбор и ранжирование производятся на основании фоновых знаний, хранящихся в каких-либо дополнительных структурах, например в виде фреймов (в MYCIN аналогичную роль выполняют таблицы знаний).
Однако нас больше интересуют различия между этими двумя классами систем. Они суммированы в работе [Kolodner, 1993].
Правила являются образцами — содержат переменные и не описывают непосредственно решение, а прецеденты являются константами.
Правило выбирается на основе точного сопоставления антецедента и данных в рабочей памяти. Прецедент выбирается на основе частичного сопоставления, причем учитываются еще и знания о сущности характеристик, по которым выполняется сопоставление.
Применение правил организовано в виде итерационного цикла — последовательности шагов, приводящих к решению. Прецедент можно рассматривать как приближенный вариант полного решения. Иногда, однако, появляется возможность итеративно проводить аналогию с разными прецедентами, которые "подходят" для различных частей проблемы.
Построение суждений на основе прецедентов поддерживает и другую стратегию решения проблем, которую мы назвали "извлечение и адаптация". Эта стратегия существенно отличается и от эвристической классификации, и от стратегии "предложение и проверка", как, впрочем, и от всех остальных, рассмотренных в главах 11-15. В новом подходе есть нечто очень близкое нам интуитивно, поскольку весьма напоминает наш повседневный опыт. Даже на первый взгляд ясно, как привлекательно вспомнить аналогичный случай, принесший успех в прошлом, и поступить так же. Редко кто из нас затрудняет себя "нудными рассуждениями", когда можно быстро извлечь готовое решение.
Нужно, однако, предостеречь тех, кто считает, будто использование прецедентов поможет нам избавиться от утомительной работы по извлечению знаний и построению обоснованного логического заключения.
Человеческая память подвержена сильному эмоциональному влиянию — нам свойственно помнить успехи и забывать о неудачах. Прошлые успехи всегда предстают в розовом свете, а потому во многих случаях нельзя рассматривать прецеденты как достаточно надежную основу для правильных выводов. Есть и еще одно существенное соображение, которое не позволяет нам безоговорочно довериться прецедентам, — масштабность. Можно говорить об анализе десятков прецедентов, но когда масштаб решаемой проблемы потребует сопоставления сотен и тысяч прецедентов, существующему механизму анализа задача окажется не по плечу.
Но, тем не менее, мы можем оптимистически смотреть на перспективы систем, использующих в ходе рассуждений прецеденты. Это, без сомнения, один из способов использовать прошлый опыт, и будет весьма интересно проследить, как исследователи и инженеры смогут воспользоваться потенциальными достоинствами этой технологии
Рекомендуемая литература
Единственной книгой, в которой достаточно полно рассмотрена технология использования прецедентов в системах искусственного интеллекта, является [Kolodner, 1993]. В перечень кратких обзорных статей, которые можно рекомендовать для первого знакомства, я бы включил [Blade, 1991], [Harmon, 1992], [Kolodner, 1992] и [Watson and Marir, 1994]. Обзор инструментальных средств, предназначенных для работы с базами данных прецедентов, представлен в работе [Harmon and Hall, 1993].
Описания действующих систем, основанных на прецедентах, читатель найдет в работах [Acorn and Walden, 1992], [Allen, 1994], [Nguyen et al, 1993], [Hislop andPracht, 1994],-[Barren etal, 1993].
ГЛАВА 23. Гибридные системы
23.1. Методы обучения в системе ODYSSEUS
23.2. Системы ODYSSEUS и MINERVA
23.2.1. Оболочка экспертной системы MINERVA
23.2.2. Обучение в системе ODYSSEUS
23.3. Использование прецедентов для обработки исключений
23.4. Гибридный символический подход и нейронные сети
23.4.1. Нейронные сети
23.4.2. SCALIR — гибридная система для извлечения правовой информации
23.4.3. Организация обучения в системе SCALIR
23.5. Будущее гибридных систем
Рекомендуемая литература
Упражнения
ГЛАВА 23. Гибридные системы
23.1. Методы обучения в системе ODYSSEUS
23.2. Системы ODYSSEUS и MINERVA
23.3. Использование прецедентов для обработки исключений
23.4. Гибридный символический подход и нейронные сети
23.5. Будущее гибридных систем
Рекомендуемая литература
Упражнения
Раньше уже неоднократно высказывалась идея, что экспертная система может содержать не одну форму представления знаний. Даже в таких ранних системах, как MYCIN (см. главу 3), информация, специфическая для предметной области, хранилась в разных формах — например, в виде порождающих правил и в виде таблиц медицинских параметров. Программы, аналогичные CENTAUR (см. главу 13), уже можно было считать гибридными в том смысле, что в них объединялись разные способы представления знаний, а затем эти знания использовались с разной целью — для решения проблемы и формирования пояснений.
Поздние исследовательские системы, такие как XPLAN (см. главу 16), имели более сложную архитектуру, в которой для разработки и обслуживания экспертных систем объединялись разнообразные программные инструменты и модели. Такие системы можно рассматривать как очередной шаг вперед по сравнению с простейшей оболочкой, поддерживающей единственную парадигму программирования. В системах на базе доски объявлений (см. главу 18), подобных HEARSAY и ВВ, объединялись разнообразные источники знаний, которые могли иметь совершенно отличную внутреннюю структуру.
Системы, которые мы рассмотрим в этой главе, ознаменовали дальнейшее продвижение по этому пути — в них объединяются традиционные программы решения проблем и компоненты самообучения и критического анализа. Система ODYSSEUS [Wilkins, 1990] способна обучаться тому, как уточнять базу знаний. Для этого используются две разные методики: одна основана на анализе прецедентов, а вторая — на анализе пояснений. Обе методики являются сравнительно новыми, и читатель сможет вкратце ознакомиться с ними в данной главе. Далее будет описана программа, в которой логический вывод на основе прецедентов используется для обработки исключений из правил, а основным инструментом решения проблем являются порождающие правила. Программа обладает потенциальными возможностями обучения новым правилам [Golding and Rosenbloom, 1991]. В конце главы будет рассмотрена система извлечения информации SCALIR [Rose, 1994], в которой множество обычных символических методов комбинируется с подходом, основанным на сетях подключений.
Хотя все перечисленные системы нельзя считать полноценными коммерческими продуктами — это скорее инструменты исследования новых методик и алгоритмов, — мы уделяем им внимание в данной книге, поскольку, по нашему мнению, за ними будущее
23.1. Методы обучения в системе ODYSSEUS
Методы обучения, которые рассматривались в главе 20 (пространство версий и IDЗ), иногда называют методами, основанными на подобии (similarity-based). Реализация обучения на основе этих методов требует обработки больших объемов информации — позитивных и негативных примеров, — из которой извлекаются характерные свойства нового концепта.
Альтернативой таким методам являются методы, основанные на пояснениях (explanation-based), которые позволяют выполнить обобщение на осно.ве единственного обучающего экземпляра. Это становится возможным, поскольку в таких методах процессом обобщения "руководят" знания, специфические для конкретной предметной области. Обучение, основанное на пояснениях, является дедуктивным или аналитическим, а не эмпирическим или индуктивным [Bergadano and Gunetti, 1996]. Иными словами, при такой методике описание нового концепта формируется в результате анализа предъявленного экземпляра в свете имеющихся фоновых знаний.
Методика логического вывода на основе прецедентов, которой была посвящена глава 22, позволяет решить новую проблему, адаптируя ранее полученные решения аналогичных проблем. Эта же методика может быть использована и для обучения, поскольку если уж ранее сформированное решение адаптировано применительно к новой проблеме, его можно добавить в базу прецедентов для использования в будущем.
Ниже будут более подробно рассмотрены методика обучения на основе пояснений и возможность использования прецедентов для машинного обучения.
Термином обобщение на основе пояснений (EBG — explanation-based generalization) обозначается независимый от, предметной области метод использования знаний, специфических для предметной области, для контроля процесса обобщения по единственному обучающему экземпляру.
Использование метода EBG предполагает, что система располагает следующей информацией:
позитивным экземпляром обучающей выборки;
теорией предметной области;
определением концепта, который система должна "изучить".
Для формализации этих идей обычно используется язык логического программирования (см. главу 8). В частности, концепт, как правило, представляется в форме предиката, который характеризует то подмножество пространства объектов, которое нас интересует. Например, предикат сuр(Х) может представлять понятие "cuphood" (чашкообразность), которое определено в стиле языка PROLOG как сосуд малого объема (small), обладающий свойствами open (открытый), stable (устойчивый). Напомним, что выражение
а :-b.
читается как "а истинно, если b истинно". Тогда:
cup(X) :- small(X), stable(X), open(X).
Знания о предметной области должны включать описания условий, выполнение которых необходимо для того, чтобы объект можно было считать "устойчивым" (stable), например указано, что объект должен иметь плоское дно, определение свойства "открытый" (open) — например, объект должен иметь вогнутую форму, причем центр кривизны должен быть расположен выше основания.
В качестве экземпляра обучающей выборки укажем объект с плоским дном вогнутой формы, диаметр которого не превышает нескольких дюймов. Экземпляр должен "сопровождаться" пояснением, что указанные свойства вполне достаточны для представления понятия "cuphood". Образец обычно описывается некоторым количеством фундаментальных литералов (ground literals), например:
color(red, obj). diameter(4, obj).
flat(bottom, obj). concave(top, obj).
Эти литералы представляют определенный объект obj красного цвета (red) с плоским дном (flat bottom), вогнутый, причем центр кривизны располагается сверху (concave top). Знания о предметной области, представленные ниже, позволяют распознать этот экземпляр как представляющий концепт сир:
small(X) :- diameter(Y, X), Y < 5.
stable(X) :- flat(bottom, X).
open(X) :- concave(top, X).
Обратите внимание — то, что объект obj является чашкой, логически следует из этого фрагмента знаний. Наше пояснение, почему obj является чашкой, фактически есть доказательство. Этим завершается фаза пояснений в EBG.
Далее начинается фаза обобщения— вырабатывается набор достаточных условий, которые существовали при пояснении. Главное, что нужно при этом сделать, — определить самые слабые условия, которых достаточно, чтобы на основании имеющихся знаний прийти к заключению, что obj — это чашка. Полученное в результате обобщение концепта состоит в том, что чашкой является объект с плоским дном, вогнутый, с центром кривизны вверху и диаметром менее 5:
cup(X) :- flat (bottom, X), concaveftop, X), diameter(Y, X), Y < 5.
Обратите внимание на то, что это обобщение логически следует из исходного определения понятия "чашкообразности" и базовых знаний о том, что такое "малый объем", "устойчивость" и "открытость". В этом смысле новое обобщение уже было неявно представлено в ранее имевшихся знаниях. Анализ представленного образца позволил сделать это обобщение явным. Кроме того, использование сформированного заранее обобщенного определения "чашкообразности" позволило нам совершенно безболезненно проигнорировать несущественные характеристики, в данном случае — цвет.
Обучение на основе прецедентов (CBL — case-based learning) представляет собой подход к обучению, совершенно противоположный методу EBG. Как было показано в главе 22, извлечение информации при таком подходе базируется в основном на подобии аргументов, а не на их логическом анализе. Можно с полным правом утверждать, что процесс адаптации сформулированного ранее решения к новой проблеме не включает обобщения в смысле логического программирования. В качестве дополнительного средства, обеспечивающего использование знаний об отношениях между сущностями предметной области, можно использовать иерархию абстракций, в частности в форме семантической сети. Однако результатом будут не новые правила, включающие переменные, а скорее новые прецеденты, сформированные из старых подстановкой констант.
Рассуждения на основе прецедентов — это, по сути, рассуждения по аналогии, а не логический вывод. Если некто придет к заключению, что Джон, владелец Порше, — водитель, склонный к риску, поскольку имеется прецедент, что Джек, который ездит на Ферра-ри, тоже склонен к риску, то фактически по аналогии делается вывод— Джон похож на Джека, так как автомобиль Порше имеет много общего с Феррари. Напрашивается заключение, что, когда строится такая аналогия, каждый прецедент неявно генерирует определенное правило. В нашем примере такое обобщенное правило состоит в том, что люди, которые ездят на спортивных автомобилях, склонны к риску. Но такое правило не является полным. Все ли водители спортивных машин склонны к риску, или только водители-мужчины, или молодежь? Программа, использующая методику рассуждений на основе прецедентов, не может ответить на такой вопрос. Она способна только отыскать прецедент, наиболее близкий к рассматриваемому случаю.
Между методами CBL и EBG есть и кое-что общее. Оба метода можно противопоставить индуктивным методам, рассмотренным в главе 20, поскольку ни тот ни другой не предполагает анализа большого количества данных. Мы уже показали, что методу EBG достаточно иметь один обучающий экземпляр, а метод CBL для формирования аналогии может обойтись одним подходящим прецедентом.
Но обучение — это нечто большее, чем просто накопление сведений. Система, основанная на анализе прецедентов, должна обладать способностью выявить неподходящие прецеденты, которые не позволяют получить удовлетворительное решение насущной проблемы. В противном случае она будет накапливать прецеденты с ошибочными решениями.
Программа CHEF, описанная в главе 22, способна выявить ситуацию, в которой она формирует неудачный рецепт, и предпринимает попытку исправить его. Чтобы сделать это, программа должна объяснить, почему она полагает рецепт неудачным. Для этого программе требуется воспользоваться определенными знаниями из предметной области, которые в таком случае должны иметь форму правил причинной связи.
Например, модули извлечения и модификации могут предложить замариновать креветок, а потом уже их чистить. Но в этом случае креветки станут слишком влажными, и в рецепте не удастся реализовать заданное в заказе свойство "очищенные креветки". Программа обнаружит это, когда попытается смоделировать процесс приготовления блюда по созданному рецепту. Тогда другой модуль системы, ответственный за восстановление, обратится к знаниям о типах ошибок в рецептах, отыщет подходящую стратегию исправления ситуации и повторит этап составления рецепта. В новом рецепте сначала нужно очистить креветки, а уже потом их мариновать.
Даже после того, как будет получено решение для нового случая, программа не сможет его правильно индексировать до тех пор, пока не поймет, почему это решение считается успешным. Если пользователь заказывает легкое, нежирное блюдо и если программа, манипулируя прежними рецептами, сформировала новый, то этот результат можно использовать в будущем только после того, как с ним будут ассоциированы признаки "легкий" и "нежирный".
23.2. Системы ODYSSEUS и MINERVA
Программа ODYSSEUS обучается тому, как совершенствовать базы знаний экспертных систем, предназначенных для решения проблем эвристической классификации (см. главы 11 и 12). Она наблюдает за тем, как эксперт решает проблему, и формирует пояснение каждого действия эксперта (например, запрашивая эксперта, почему некоторому атрибуту присвоено то или иное значение). Формирование пояснений базируется на тех знаниях о проблемной области и стратегии решения проблем, которыми располагает программа. Если программе не удается сформировать пояснение, инициируется процесс коррекции базы знаний.
23.2.1. Оболочка экспертной системы MINERVA
MINERVA— это оболочка экспертной системы, разработанная на базе EMYCIN и NEOMYCIN (см. главы 10-12). Система MINERVA обеспечивает ODYSSEUS базой знаний и методом решения проблем и разработана специально для поддержки метода обучения EBL. Одно из главных отличий системы MINERVA от EMYCIN состоит в том, что в ней представлены не только знания о предметной области, но и стратегические знания, отражающие способ мышления практикующего врача. Такие знания можно рассматривать как дальнейшее развитие метаправил систем MYCIN, EMYCIN и NEOMYCIN.
Главным компонентом этой системы является база медицинских знаний о диагностировании менингита и других неврологических заболеваний. MINERVA реализована на языке PROLOG, и знания о предметной области представлены в этой системе в виде фраз Хорна (см. главу 8), но правила по содержанию аналогичны тем, что использовались в MYCIN. Например, следующее выражение представляет тот факт, что фотофобия может быть связана с головной болью:
conclude(migraine-headache, yes)
:- finding(photophobia, yes).
Знания о состоянии проблемы записываются в виде выражений для фактов в процессе работы системы. Например, выражение
rule-applied(rulel63).
утверждает, что в процессе работы системы было активизировано правило 123 и что эта информация доступна программе в процессе дальнейшей работы. Другое простое выражение
differential(migraine-headache, tension-headache).
зафиксирует тот факт, что мигрень и повышенное давление — текущие гипотезы, выдвинутые программой.
Очевидно, что такая информация может быть представлена изарегистрирована любым способом, например установкой флагов или переменных, но наиболее целесообразно использовать такое же представление, какое принято в базе знаний предметной области.
Несложное метаправило может быть представлено в следующем виде: goal(findout(Р)) :- not(concluded(P)), ask-user(P).
Это правило утверждает, что если текущая цель системы — найти значение параметра Р и если система не может прийти к заключению о значении этого параметра на основании имеющихся у нее знаний, то она должна запросить его у пользователя. Поскольку Р является переменной, то головная часть выражения goal (findout (Р)) сопоставляется с выражением цели системы, представленным в явном виде, например goal (f indout (temperature)). Подцели вроде not(concluded(P)) могут быть сопоставлены (успешно или нет) с системными данными, описывающими текущее состояние процесса вычислений, например concluded (temperature).
Такие стратегические знания используются для выработки суждения о текущем состоянии проблемы и принятия решения о том, располагает ли система в данном случае достаточными знаниями. Кроме того, наличие таких знаний упрощает программу обучения, которая может обращаться к структурам на метауровне экспертной системы.
23.2.2. Обучение в системе ODYSSEUS
Способ обучения, который используется в системе ODYSSEUS, существенно отличается от рассмотренных в главе 20. При разработке этой системы преследовалась цель наделить ее способностью расширять существующую неполную базу знаний, а не включать в базу знаний новые понятия на основании анализа обучающей выборки большого объема. Система обучается, "наблюдая" за тем, как эксперт решает задачу, примерно так, как прилежный ученик постигает таинства мастерства учителя, стоя у него за спиной.
Основной вид действий, которые выполняются экспертом в процессе решения проблемы диагностики, — определение значений разнообразных переменных, т.е. характеристик пациента, таких как температура и т.п. Программа, наблюдая за работой эксперта, расширяет свои знания, пытаясь понять, почему эксперту понадобился ответ на тот или иной вопрос.
Таким образом, концепция процесса обучения в системе ODYSSEUS очень близка к формулированию пояснений. Фактически в контексте работы этой системы смысл термина "пояснение" отличается как от общепринятого, так и от того, какой мы придавали ему в главе 16. В ODYSSEUS пояснение — это вид доказательства, которое несет информацию о том, почему эксперт задает определенный вопрос на конкретном этапе решения проблемы диагноза. Смысл определенного вопроса связан как с текущим состоянием проблемы, так и с той стратегией, которой пользуется эксперт. Поэтому, "уразумев", почему был задан вопрос, программа как бы постигает стратегию действий эксперта.
Если программа располагает исчерпывающими знаниями, она способна сформулировать вопрос (а точнее, высказывание, которое стоит за ним) как логическое следствие текущего состояния проблемы, стратегических знаний, заключенных в метаправилах, знаний о предметной области и одной из текущих целей.
Например, если задан вопрос askuser(temprature), то обратный просмотр приведет нас к ближайшей цели goal (f indout (temperature)).
Но эта цель, в свою очередь, сформирована целью более высокого уровня, например желанием применить определенное правило или произвести разделение гипотез. Наличие в текущей ситуации такой цели высокого уровня объясняет, почему была сформирована цель более низкого уровня, а следовательно, почему был задан определенный вопрос. Эта обратная цепочка рассуждений от подцелей к целям выполняется обычными средствами языка PROLOG или даже MYCIN, но обратите внимание — эти рассуждения выполняются на метауровне, т.е. на уровне, который определяет, почему программа работает именно так, а не иначе. Применяемая в системе ODYSSEUS стратегия обучения "из-за спины" включает три основные фазы.
Определение изъяна в базе знаний. Такой изъян обнаруживает себя, когда не удается сформировать объяснения действиям эксперта, используя описанный выше метод обратного просмотра. Неудача такого рода служит сигналом, что пора приступить к обучению.
Формирование предложений для внесения изменения в базу знаний. Если не удалось сформировать доказательство (пояснение в терминологии ODYSSEUS), значит, можно предположить, что в знаниях о предметной области или о состоянии проблемы имеется какой-то изъян. Если это изъян в знаниях о предметной области, можно временно добавить в базу подходящую фразу и посмотреть, будет ли после этого сформировано доказательство. Если же изъян существует в знаниях о состоянии проблемы, программа должна поискать другое доказательство.
Внесение изменения в базу знаний. Метод, который используется в системе ODYSSEUS для внесения изменений в базу знаний, называется "процедурой подтверждения принятого решения". Если не вдаваться в детали, то при этом требуется, чтобы разработчик системы сформировал процедуру, которая будет обрабатывать новые правила, определив, например, на сколько сократится количество конкурирующих гипотез в результате применения правила.
Детали реализации перечисленных фаз выходят за рамки обсуждения в данной книге, но основные принципы довольно очевидны. В применяемой методике экземпляр обучающей выборки представляет собой отдельную пару атрибут—значение, но в процессе сеанса обучения может возникнуть множество таких пар, так как программа пытается объяснить, почему она придает значение каждому из этих экземпляров. Если сформировать объяснение не удается, программа предпринимает попытку модифицировать базу знаний.
Для модификации правил или добавления новых правил в базу знаний программа ODYSSEUS использует также в примитивном виде и метод CBL. Программа располагает библиотекой прецедентов, каждый из которых содержит и соответствующий правильный диагноз. Эту библиотеку программа может использовать для тестирования. Если при тестировании окажется, что сформирован неверный диагноз, программа назначает использованным при этом правилам нечто вроде штрафов.
Предпосылки правил, которые привели к ошибочному заключению, "ослабляются", т.е. сужается зона их" применения. Если же применение правил подтвердило вынесенный ранее правильный диагноз, то соответствующие предпосылки "усиливаются". В этой процедуре есть много общего с тем методом, который используется в системе Meta-DENDRAL, описанной в главе 20. Конечно, этот метод модификации правил не гарантирует решения проблемы, но он может пригодиться для настройки новых правил.
23.3. Использование прецедентов для обработки исключений
В этом разделе мы рассмотрим способ совместного использования правил и прецедентов, отличный от того, какой применен в системе ODYSSEUS. Роль прецедентов при новом подходе состоит не в том, чтобы содействовать модификации правил, а в том, чтобы при обработке исключений служить дополнением тем знаниям, которые представлены в правилах. Таким образом, каждый из компонентов занимается тем, что у него лучше получается, — правила имеют дело с обобщениями предметной области, а прецеденты — с отдельными нетипичными случаями.
Как уже было не раз продемонстрировано в предыдущих главах (см., например, главы 10-15), построение набора правил для экспертной системы— задача далеко не тривиальная. Помимо сложностей, сопряженных с извлечением и представлением знаний, существует еще и проблема полноты охвата предметной области набором правил. В идеале база правил должна быть корректной, непротиворечивой (по крайней мере, в рамках принятой стратегии разрешения конфликтов) и полной. Но по мере того, как количество правил расширяется, а сами правила усложняются, достичь такого идеального состояния становится все труднее.
Особенно сложно учесть в правилах все возможные исключения. Такая попытка приводит к чрезвычайному усложнению правил. Утверждение, что не бывает правил без исключений, давно уже стало общим местом. Иногда эту проблему пытаются решить включением в набор множества "мелких" правил, которые должны активизироваться в таких исключительных ситуациях. Но это означает возлагать на правила несвойственную им функцию — обрабатывать не общий случай, а частный.
Голдинг и Розенблум предложили использовать в экспертных системах гибридную архитектуру, в которой при решении проблем методика использования порождающих правил сочетается с методикой использования прецедентов [Gaiding and Rosenbloom, 1996]. Идея состояла в том, что механизм обработки прецедентов должен использоваться для критического анализа результатов применения правил. Это выполняется путем поиска прецедентов, аналогичных рассматриваемому случаю, если последний можно считать исключением из правила. Такой подход требует, чтобы база прецедентов была индексирована по применяемым правилам. Авторы предложили и соответствующую меру близости, которая позволяет оценить степень подобия текущего случая и прецедента (рис. 23.1).
Рис. 23.1. Архитектура гибридной системы, использующей правила и прецеденты
Основная идея системы очень проста и элегантна. Сначала для решения текущей проблемы применяются правила, в результате чего формируется некоторое решение. Затем просматривается библиотека прецедентов на предмет выявления в ней ранее ветречавшегося случая исключения из использованных правил. Алгоритм работы системы приведен ниже.
Цикл, ПОКА не будет получено решение
{
1 . Для выбора следующей операции использовать правила.
2. Поиск в библиотеке "неотразимых" прецедентов, которые предлагают противоположный вариант выбора операции.
3. Если прецедент найден, использовать предлагаемый в нем вариант операции. Иначе использовать тот вариант, который предлагается правилами.
}
Обратите внимание на то, что обращение к правилам и прецедентам выполняется в каждом цикле. (Если программа не сможет найти ни правила, которое можно было бы применить, ни прецедента, она останавливается.)
Для того чтобы предложенная идея стала работоспособной, прецеденты в библиотеке должны быть проиндексированы по правилам, которым они противоречат. Рассмотрим, например, правило страховки водителей транспортных средств:
"Мужчины не старше 25 лет платят страховой взнос по повышенному тарифу".
Такое правило должно быть связано в библиотеке с прецедентом, в котором упоминается 18-летний юноша, успешно прошедший тесты повышенной сложности и выплачивающий взнос по сниженному тарифу.
На основании каких соображений принимается решение, является ли прецедент "неотразимым" или нет? Предложенное Голдингом решение состоит в следующем. Когда мы проводим аналогию между прецедентом и текущим случаем, мы тем самым формируем некое неявное правило, скрытое от посторонних глаз. Предположим, что в нашем примере речь идет о водителе-мужчине 20 лет, который имеет квалификацию повышенной категории, и мы обнаружили аналогичный прецедент, но в нем речь шла о 1 8-летнем водителе. Эта аналогия сформирует неявное правило в виде
"Мужчины не старше 25 лет, имеющие повышенную квалификационную категорию, платят страховой взнос по сниженному тарифу".
Предположим, что при оценке степени близости, которая необходима для извлечения и последующего анализа прецедентов, возраст водителей разделяется на диапазоны, скажем "до 25 лет", "от 25 до 65 лет" и "свыше 65 лет". Эта мера близости оценит рассматриваемый нами случай и прецедент как очень похожие, поскольку совпадают возрастная категория и пол.
Можно протестировать это правило и на остальных прецедентах в библиотеке и оценить, какой процент выявленных прецедентов оно накрывает. Любой прецедент с мужчиной-водителем повышенной квалификационной категории, чей возраст не превышает 25 лет и который выплачивает взнос по повышенному тарифу, будет считаться исключением и, следовательно, снижать рейтинг прецедента. Если же случаи достаточно похожи, а правило достаточно точное, то аналогия считается "неотразимой" и компонент обработки прецедентов "выигрывает". В противном случае выигрыш будет за применяемым правилом, и в окончательном решении будет использован вариант, следующий из правила.
Таким образом, "неотразимость" зависит от трех факторов:
степени близости случаев, которая должна превышать определенный порог;
точности неявного правила, сформулированного в результате выявленной аналогии; в качестве меры точности берется пропорция прецедентов, которые подтверждают применение этого правила;
4 достоверности оценки точности, которая определяется размером выборки, на которой эта оценка сформирована.
Авторы продемонстрировали возможности предложенной архитектуры на примере задачи определения произношения имен. Реализованная ими система, получившая название ANAPRON, содержит около 650 лингвистических правил и 5000 прецедентов. Результаты испытания системы показали, что она обладает более высокой производительностью, чем системы-аналоги, использующие либо только правила, либо только прецеденты.
23.4. Гибридный символический подход и нейронные сети
В этом разделе будет рассмотрена перспектива использования нейронных сетей в экспертных системах. Нейронные сети предполагают совершенно другую модель вычислительного процесса, принципиально отличную от той, которая традиционно используется в экспертных системах. В качестве примера будет рассмотрена система SCALIR (Symbolic and Connectionist Approach to Legal Information Retrieval) [Rose, 1994].
Эта система помогает пользователю отыскать правовые документы — описания прецедентов или статьи законов, — имеющие отношение к определенному делу. Поскольку юридическая практика охватывает все области жизни современного общества, использование традиционного подхода, основанного на обычных базах знаний, к поиску и извлечению правовой информации потребует представления в системе огромного объема знаний, в большинстве нетривиальных, представляющих такие сложные понятия, как права, разрешения, обязанности, соглашения и т.п. Проблема усугубляется использованием естественного языка при составлении запросов. Большинство поисковых систем, имеющих дело с запросами на естественном языке, которые используются для поиска в сети World Wide Web, основаны на статистическом подходе, а не на базах знаний.
В системе предпринята попытка решить эту проблему посредством сочетания статистического подхода к извлечению информации и подхода, основанного на базах знаний, в которых учитываются смысловые связи между документами.
23.4.1. Нейронные сети
В отношении систем искусственного интеллекта вообще и экспертных систем, в частности, иногда можно услышать следующие критические замечания.
Такие системы слишком "хрупкие" в том смысле, что, встретившись с ситуацией, не предусмотренной разработчиком, они либо формируют сообщения об ошибках, либо дают неправильные результаты. Другими словами, эти программы довольно просто можно "поставить в тупик".
Они не способны непрерывно самообучаться, как это делает человек в процессе решения возникающих проблем.
Еще в середине 1980-х годов многие исследователи рекомендовали использовать для преодоления этих (и других) недостатков нейронные сети.
В самом упрощенном виде нейронную сеть можно рассматривать как способ моделирования в технических системах принципов организации и механизмов функционирования головного мозга человека. Согласно современным представлениям, кора головного мозга человека представляет собой множество взаимосвязанных простейших ячеек — нейронов, количество которых оценивается числом порядка 1010. Технические системы, в которых предпринимается попытка воспроизвести, пусть и в ограниченных масштабах, подобную структуру (аппаратно или программно), получили наименование нейронные сети.
Нейрон головного мозга получает входные сигналы от множества других нейронов, причем сигналы имеют вид электрических импульсов. Входы нейрона делятся на две категории — возбуждающие и тормозящие. Сигнал, поступивший на возбуждающий вход, повышает возбудимость нейрона, которая при достижении определенного порога приводит к формированию импульса на выходе. Сигнал, поступающий на тормозящий вход, наоборот, снижает возбудимость нейрона. Каждый нейрон характеризуется внутренним состоянием и порогом возбудимости. Если сумма сигналов на возбуждающих и тормозящих входах нейрона превышает этот порог, нейрон формирует выходной сигнал, который поступает на входы связанных с ним других нейронов, т.е. происходит распространение возбуждения по нейронной сети. Типичный нейрон может иметь до 10J связей с другими нейронами.
Было обнаружено, что время переключения отдельного нейрона головного мозга составляет порядка нескольких миллисекунд, т.е. процесс переключения идет достаточно медленно. Поэтому исследователи пришли к заключению, что высокую производительность обработки информации в мозге человека можно объяснить только параллельной работой множества относительно медленных нейронов и большим количеством взаимных связей между ними. Именно этим объясняется широкое распространение термина "массовый параллелизм" в литературе, касающейся нейронных сетей.
Подход, базирующийся на нейронных сетях, часто рассматривается как несимволический, или субсимволический (subsymbolic), поскольку основная информационная единица, подлежащая обработке, является не символом (как это определено в главе 4), а чем-то более примитивным. Например, символ в LISP-программе, скажем МУ LAPTOP, можно было бы представить схемой активности некоторого числа связанных нейронов в нейронной сети. Но, поскольку нейронные сети часто моделируются программно, сам нейрон представляется некоторой программной структурой, которая, в свою очередь, может быть реализована с использованием символов. Например, роль нейрона может исполнять объект данных, располагающий подходящими свойствами и методами и связанный указателями с другими объектами в сети. Таким образом, на концептуальном уровне в субсимволической системе, реализованной компьютерной программой, которая содержит символы, нет ничего парадоксального.
Независимо от способа реализации, нейронную сеть можно рассматривать как взвешенный ориентированный граф такого типа, который описан в главе 6. Узлы в этом графе соответствуют нейронам, а ребра — связям между нейронами. С каждой связью ассоциирован вес — рациональное число, — который отображает оценку возбуждающего или тормозящего сигнала, передаваемого по этой связи на вход нейрона-реципиента, когда нейрон-передатчик возбуждается.
Поскольку нейронная сеть носит явно выраженный динамический характер, время является одним из основных факторов ее функционирования. При моделировании сети время изменяется дискретно, и состояние сети можно рассматривать как последовательность мгновенных снимков, причем каждое новое состояние зависит только от предыдущего цикла возбуждения нейронов.
Для выполнения обработки информации с помощью такой сети необходимо соблюдение определенных соглашений. Для того чтобы сеть стала активной, она должна получить некоторый входной сигнал. Поэтому некоторые узлы сети играют роль "сенсоров" и их активность зависит от внешних источников информации. Затем возбуждение передается от этих входных узлов к внутренним и таким образом распространяется по сети. Это обычно выполняется посредством установки высокого уровня активности входных узлов, которая поддерживается в течение нескольких циклов возбуждения, а затем уровень активности сбрасывается.
Часть узлов сети используется в качестве выходных, и их состояние активности считывается в конце процесса вычислений. Но часто интерес представляет и состояние всей сети после того, как вычисления закончатся, либо состояние узлов с высоким уровнем активности. В некоторых случаях интерес может представлять наблюдение за процессом установки сети в стабильное состояние, а в других — запись уровня активизации определенных узлов перед тем, как процесс распространения активности завершится.
На рис. 23.2 показан фрагмент нейронной сети, состоящий из четырех сенсорных узлов S1—S4, возбуждение от которых передается другим узлам сети. Один узел, R, является выходным. Если веса связей в сети неизвестны, то узел R будет возбужден тогда, когда будут возбуждены узлы S1 и S4 Но если будут возбуждены также узлы S2 и S3, это приведет к подавлению возбуждения R даже при возбужденных узлах 5) и S4. Будет ли узел R действительно возбужден при таком состоянии сигналов на входах сенсорных узлов, зависит от весов связей в сети.
Количество возможных конфигураций сети такого типа очень велико. Велико и количество способов вычисления состояния нейрона при заданной сумме состояний на его входах. Эти детали теории нейронных сетей выходят за рамки данной книги. Далее мы будем следовать идеям Роуза (Rose) и рассмотрим относительно простую модель нейронной сети, в которой любой узел может быть связан с любым другим узлом и в которой выходом узла является его состояние активности (т.е. не делается различия между активностью нейрона и сигналом на его выходе).
Рис. 23.2. Фрагмент нейронной сети с возбуждающими и тормозящими связями
Для более строгой формулировки такой модели введем следующие обозначения:
wij — вес связи от узла j к узлу i,
neti = Zj wij— состояние в текущий момент времени входов узла l, связанного с другими узлами сети.
При любом определении нейронной сети необходимо принимать во внимание и фактор времени, поскольку состояние любого нейрона в некоторый момент времени зависит от его предыдущего состояния и от предыдущего состояния нейронов, связанных с его входами.
Определение
Сеть связности (connectionist network) может рассматриваться как взвешенный ориентированный граф, в котором для каждого узла i выполняются следующие требования:
(1) состояние активности узла в любой момент времени t является действительным числом (будем обозначать его как ai(t));
(2) вес связи, которая связывает узел i с любым другим узлом у сети, является действительным числом wij,
(3) активность узла в момент t+1 является функцией от
его активности в момент времени t, ai(t);
взвешенной суммы сигналов на входах в момент времени t, neti{f);
произвольного внешнего входного сигнала xi(t).
Простая функция вычисления состояния активности узла i, удовлетворяющая требованию (3) приведенного выше определения, имеет вид
ai(t+1) = Cуммаj [wijaj(t)+xl(t)]
Это, однако, не единственно возможный способ определения активности. Функции других видов включают добавление термов, соответствующих росту или спаду активности, или имеют вид нелинейных дифференциальных функций (см., например, [Hinton, 1989]). В данной книге они рассматриваться не будут.
При конструировании сети веса связей могут быть назначены априори или изменяться со временем. В последнем случае изменение весов является одним из следствий активности сети. Веса можно рассматривать как отражение знаний, а процесс их настройки и уточнения — как процесс обучения системы. Поскольку веса существенно влияют на распространение активности по сети, от них во многом зависит и поведение сети, а следовательно, изменяя веса, можно изменять поведение сети в желаемом направлении.
Как отмечено выше, знания в сети связности представлены неявно, поскольку нельзя выделить один определенный структурный элемент сети, который представлял бы отдельное правило или сущность предметной области. Знание отражено именно во взвешенных связях между мириадами отдельных элементов сети. Таким образом, в данном случае мы имеем дело с распределенными знаниями, которые нельзя представить в виде простого перечисления числовых или символических элементов. По этой причине часто можно встретить утверждение, что в нейронных сетях выполняется субсимволическая обработка информации.
В сетях связности знания сохраняются не в декларативном виде, а потому они не могут быть доступны для интерпретации со стороны какого-либо внешнего процессора [Rumelhart and McClelland, 1986]. Доступ к знаниям и процесс логического вывода могут быть описаны только в терминах активности сети.
Конечно, ничто не препятствует конструктору сети ассоциировать отдельные ее узлы с определенными сущностями предметной области, как это сделал Роуз в системе SCALIR. Однако такое отражение понятий на узлы сети не противоречит ранее сделанному утверждению, что отношения между сущностями неявно представлены в виде связей между узлами и обычно не могут интерпретироваться в форме правил. Следовательно, хотя мы и частично приоткрыли завесу таинственности, скрывающую, что же стоит за узлами сети, сущность взвешенных связей между ними остается по-прежнему "субсимволической".
Даже в случае, если узлы представляют сущности предметной области, общая картина активности мириад узлов сети может скрывать понятия достаточно высокого уровня, объединяющие определенные аспекты сущностей, представленных узлами. Пусть, например, узлы представляют слова и пусть узлы "гонки", "машина", "водитель" возбуждены. Этим может быть представлено понятие "водитель гоночной машины" или, наоборот, факт вождения гоночной машины. В любом случае такое представление может расцениваться как субсимволическое, поскольку составляющие его узлы не могут быть оформлены в виде какой-нибудь синтаксической структуры, имеющей явно выраженный смысл. Точно так же нельзя выполнить и семантический анализ состояния мириад узлов с помощью какого-либо внешнего набора правил.
23.4.2. SCALIR — гибридная система для извлечения правовой информации
Узлы в сетевой структуре системы SCALIR представляют прецеденты (дела, ранее рассмотренные судами), статьи правовых актов и важные (ключевые) слова, которые встречаются в подобных документах. Таким образом, структурно сеть разделена на три части (слоя), как показано на рис. 23.3. В этой сети слой прецедентов и слой законодательных актов разделены слоем узлов, представляющих ключевые слова (термины). Последние связаны с документами, в которых они встречаются.
Таким образом, в базовой структуре сети связь между узлами терминов и документов образует схему индексации с взвешенными связями. В результате массив терминов отображается как на массив прецедентов, так и на массив правовых актов.
Вместо того чтобы связывать каждый термин с каждым документом, в котором он встречается, в SCALIR вычисляется вес термина для каждого ключевого слова, связанного с документом, как функция от частоты упоминания этого термина в данном документе и частоты его упоминания во всем массиве документов. Интуитивно кажется, что термином, наиболее подходящим для индексации некоторого документа, будет такой, который часто появляется в этом документе, но редко во всех остальных. Полученное значение сравнивается с пороговым, в результате чего каждый документ индексируется примерно десятком ключевых слов. (Обращаю ваше внимание на тот факт, что на схеме сети системы SCALIR показаны двунаправленные связи. Фактически каждая из них представлена в системе парой однонаправленных связей, причем эти связи могут иметь разные веса. Таким образом, не только термин позволяет найти документ, но и по документу можно отыскать термин.)
Рис. 23.3. Сеть связности в системе SCAUR ([Rose, 1994])
При конструировании сети в SCALIR сначала были организованы узлы для всех отобранных терминов, а затем они связывались с узлами документов, причем связям назначались веса в зависимости от значимости того или иного термина в контексте данного документа.
Такой тип связей (в документации они названы С-связями) не является единственным в SCALIR. Существуют и символические связи (S-связи), которые во многом напоминают связи в семантических сетях, поскольку маркированы и имеют постоянные веса. С помощью связей этого типа в сети представлены отношения между документами, например один документ цитирует другой, в одном судебном решении критикуется другое, один правовой акт ссылается на другой и т.д. Таким образом, S-связи представляют знания в явном виде.
В целом сеть сиетемы SCALIR содержит порядка 13 000 узлов терминов, около 4 000 узлов прецедентов и около 100 узлов законодательных актов. Между узлами терминов и прецедентов организовано приблизительно 75 000 связей, а между узлами терминов и законодательных актов — около 2 000 связей. Кроме того, существует около 10 000 символических связей между узлами прецедентов. Роуз не счел нужным останавливаться на том, каких усилий потребовало создание подобной сети, но можно предположить, что такие ключевые задачи, как извлечение терминов и цитирование, были решены программно, а затем на основании этой информации автоматически сформированы узлы сети и связи между ними. Нужно принять во внимание и тот факт, что большинство горидических документов было уже ранее обработано публикаторами, которые составили достаточно полные индексы цитирования и ключевых слов.
Описанная сеть была затем использована в качестве базовой информационной структуры для извлечения документов. В основу функционирования системы положен принцип распространяющейся активности (spreading activation). Этот принцип не нов — ранее он использовался Квиллианом для работы с семантическими сетями (см. об этом в главе 6). Использование этого формального аппарата позволяет выяснить, существует ли какое-либо отношение между узлами в сети. Для этого запускается процесс распространения маркеров от узлов, представляющих интерес, и анализируется, произошло ли где-либо в сети "пересечение" распространяющихся маркеров.
Основная идея, положенная в основу работы SCALIR, состоит в том, что уровень активности данного узла должен быть пропорционален его "уместности" в рассматриваемом контексте. Если в результате обработки запроса возбуждается некоторое число узлов слоя терминов, это должно привести к возбуждению узлов тех документов, которые касаются данного запроса, причем уровень возбуждения зависит от того, насколько тот или иной документ отвечает сути запроса. Узлы, воспринимающие запросы, являются, по сути, сенсорными узлами нейронной сети, от которых возбуждение по С-связям передается другим узлам. В процессе распространения возбуждения в дело включаются и S-связи, которые передают возбуждения от одних узлов документов другим, связанным с ними. Таким образом, символические связи отражают знания о том, что если определенный документ имеет отношение к полученному запросу, то, скорее всего, и связанный с ним другой документ также имеет отношение к этому запросу. Веса символических связей фиксированы, поскольку сила такой ассоциативной зависимости может быть оценена заранее.
Существуют два свойства функции активизации сети, которые представляются крайне желательными с точки зрения приложений, требующих ассоциативного поиска информации. Эти свойства влияют на выбор способа возбуждения сенсорных узлов, воспринимающих запросы пользователей, методики назначения весов связям и формы функции активизации.
(1) Количество активности, которое вносится в систему, не должно зависеть от размерности запроса.
(2) В каждом очередном цикле распространения активность не должна возрастать.
Если первое из указанных требований не будет выполняться, то запрос, состоящий из одного слова, приведет к меньшей активности сети, чем многословный. При этом окажется, что в ответ на более ограниченный многословный запрос система извлечет больше документов, чем в ответ на более свободный однословный, а это противоречит нашим интуитивным ожиданиям. Если же сеть не обладает вторым из сформулированных свойств, то будет извлечено слишком много документов, имеющих крайне слабое касательство к сути запроса, т.е. система будет производить много "информационного мусора".
Для того чтобы система обладала первым свойством, нужно на стадии предварительной обработки запроса распределить между входными узлами фиксированное количество активности. Вторым свойством система будет обладать в том случае, если сумма весов выходных связей не будет превышать единицы и, следовательно, значение функции активизации будет меньше или равно ее аргументу.
С-связи используют линейную функцию активизации, которая содержит константу сдерживания (retention constant) р, как показано в приведенном ниже выражении. Значение этой константы определяет, какая часть активности узла сохраняется в последующем цикле возбуждения, а какая распространяется дальше по сети.
ai(t + 1) = р аj(t) + (1 - p) Sumj [Wij aj(t)]
Совершенно очевидно, что приведенная функция активизации будет удовлетворять сформулированным требованиям, поскольку ai(t +1)=< ai(t) до тех пока, пока Sumj[Wij= < 1]
Функция такого же вида использована и в работе [Belew, 1986]. Роуз следует идеям, изложенным в этой работе, и в отношении организации управления активностью сети в SCALIR.
Для выделения узлов, активность которых достаточна для участия в процессе извлечения информации, вводится параметр Os — порог значимости (significance threshold). Значение этого порога уменьшается по мере распространения активности по сети.
Для выделения узлов, активность которых слишком слаба и которые поэтому можно игнорировать в процессе извлечения информации, вводится параметр Oq — порог успокоения (quiescence threshold). Использование этого порога позволяет избежать непроизводительных затрат времени на анализ малоактивных узлов.
Эти параметры используются в алгоритме распространения активности по сети SCALIR, который в упрощенном виде представлен ниже. Этот алгоритм реализует метод поиска в ширину, начиная со входных узлов восприятия запроса (QUERY-NODES) и заканчивая всеми взвешеннымисвязями.
Установить исходное значение OS.
Включить в множество ACTIVE-NODES узлы из множества QUERY-NODES.
Цикл {
Если имеется запрос, установить уровни активности узлов в QUERY-NODES.
Включить в множество RESPONSE-SET все узлы из ACTIVE-NODES, чья активность превышает OS.
Удалить из множества ACTIVE-NODES все узлы, чья активность ниже Oq.
Добавить в множество ACTIVE-NODES все узлы, связанные с узлами, уже включенными в ACTIVE-NODES.
Обновить значение активности всех узлов множества ACTIVE-NODES, используя функцию активизации.
Рассортировать узлы в множестве ACTIVE-NODES по уровню активности. Уменьшить значение Os.
}
пока не будет выполнено (OS =< Oq) или (ACTIVE-NODES = 0).
В упрощенном варианте не рассматривается использование параметра, ограничивающего ширину пространства поиска. Кроме того, мы опустили в этой формулировке алгоритма и анализ максимального размера множества выходных узлов. Ограничение множества выходных узлов прекращает выполнение поиска после того, как выделено предельное количество извлекаемых документов.
Значение большинства параметров, используемых в процессе управления активностью сети, устанавливается эмпирически. Настройка же весов связей между узлами сети Wij представляет собой, по сути, процесс обучения системы, который мы вкратце рассмотрим в следующем разделе.
23.4.3. Организация обучения в системе SCALIR
Поскольку веса С-связей могут регулироваться системой в процессе работы, она способна таким образом самообучаться в соответствии с информацией, вводимой пользователем. Ниже мы опишем, как это делается в системе SCALIR, опуская несущественные детали.
Предположим, что один из входов узла i связан с выходом узла j, причем связь имеет вес Wij. Если узел i представляет документ, имеющий отношение к термину, представленному узлом j, то в процессе обучения нам может потребоваться усилить эту связь. Если же пользователь посчитает, что документ имеет мало общего с этим термином, то потребуется ослабить эту связь. Главный вопрос, который нужно при этом решить, — в какой степени нужно менять значение веса. Одно из простых правил вычисления значения изменения веса Wij может быть выражено формулой
Wi = nfiaj,
где n| — константа скорости обучения (learning rate), a fi — коэффициент обратной связи от пользователя, который, например, может принимать значение +1 или—1.
Однако применение такого правила не настолько очевидно, как это может показаться с первого взгляда, по следующим причинам.
Определить значения уровня активности а, не так просто, поскольку активизированный при возникновении запроса входной узел может снизить свою активность после того, как запрос будет снят.
Соседи узлов, которые получают обратную связь, также должны, по-видимому, получать некоторую информацию обратной связи от пользователя, подтверждающую, что они представляют документы, имеющие отношение к запросу.
Узел i может находиться в конце сети распространения активности, а следовательно, информация от пользователя (обратная связь) должна распространяться по сети в обратном направлении.
Таким образом, получаемая от пользователя информация обратной связи должна распространяться по сети примерно так же, как активность. Максимальное значение обратной связи для каждого узла записывается и обновляется в процессе распространения, и эти значения в дальнейшем играют роль членов fi и аj в приведенном выше выражении. Далее полученные значения весов нормализуются таким образом, чтобы их сумма для каждого отдельного узла была равна 1.0.
Конечно, в реальной системе SCALIR процесс самообучения несколько сложнее, поскольку в ней существуют связи разных типов. Читателям, интересующимся деталями этого процесса, следует познакомиться с работой [Rose, 1994], Но идея комбинированного использования символических и субсимволических методов заслуживает дальнейшего углубленного изучения. В системе SCALIR продемонстрирован довольно прагматический компромисс между чисто статистическим подходом к извлечению информации и традиционным подходом для экспертных систем, требующим большого объема знаний о предметной области.
23.5. Будущее гибридных систем
Итак, вы могли убедиться на представленном в этой главе материале, что гибридные системы потенциально являются довольно мощным инструментом решения сложных проблем, которые не под силу отдельным "чистым" подходам. На примере сравнения систем ODYSSEUS и EMYCIN вы могли убедиться в том, что в первой использована гораздо более сложная методология построения и настройки базы знаний, которая не идет ни в какое сравнение с методикой синтаксического контроля, примененной в EMYCIN. Предстоит еще очень много сделать в теории экспертных систем, прежде чем такие системы смогут эмулировать способность к постоянному совершенствованию, которой обладает человек-эксперт.
Аналогично, комбинирование парадигм использования правил и прецедентов позволяет повысить эффективность обработки исключений, не усложняя при этом набор правил.
В системе SCALIR продемонстрирована возможность комбинированного использования в рамках одной системы символического и субсимволического подходов, которые обычно рассматриваются многими специалистами как взаимно исключающие.
Следует надеяться, что в будущем мы станем свидетелями еще более значительного прогресса в этом направлении. Однако в теории искусственного интеллекта наблюдаются и тенденции движения в совершенно другом направлении, противоположном созданию гибридных систем. Имеет смысл здесь кратко упомянуть о них.
Программное обеспечение систем искусственного интеллекта в значительной мере привязано к определенным платформам и реализовано на языках, которые используются только в области искусственного интеллекта.
Методология разработки программного обеспечения систем искусственного интеллекта все еще отстает от современной практики создания программ, предполагающей использование объектно-ориентированного анализа и разработки, так же, как и технологии разработки распределенных многокомпонентных приложений.
Для программ систем искусственного интеллекта характерны все недостатки, присущие исследовательским продуктам, — отсутствие полноценной документации, низкая надежность, возможность использования только в организации, где она была создана.
Существует еще и психологический барьер, который трудно преодолеть современным исследователям, многие из которых стояли у истоков тех или иных подходов и не склонны переходить на сторону "конкурентов". Но этот барьер, скорее всего, будет преодолен новым поколением исследователей и разработчиков.
Рекомендуемая литература
В последнее время появилось множество программных продуктов, в которых комбинируются методики, основанные на применении правил и прецедентов. Примером может служить система CBR Express, разработанная фирмой Inference Corp., которая используется в качестве надстройки над системой ART-IM [Davles and May, 1995].
Разработки оболочек экспертных систем, в которых комбинируется применение правил логического вывода и обучения или нейронных сетей, находятся пока что в зачаточном состоянии. Попытки использовать нейронные сети в сочетании с традиционными экспертными системами описаны в работе [Кат et al, 1991]. В этой связи следует упомянуть и систему NeuroShell 2, разработанную фирмой Neuron Data, в которой порождающие правила используются для предварительной обработки информации, после чего она передается в нейронную сеть. Полученная на выходе нейронной сети информация также может быть обработана с помощью системы правил
Упражнения
1. В какой мере можно отнести MYCIN и CENTAUR к гибридным системам?
2. Можно ли считать системы с доской объявлений гибридными?
3. Почему компонентам, реализующим обучение, отводится такая важная роль в экспертных системах?
4. Какой смысл придается термину "обобщение на основе пояснений"? В чем отличие этой функции экспертной системы от методов обучения, рассмотренных в главе 20?
5. Рассмотрите следующее определение арки, состоящей из двух колонн (pillar) и перемычки (lintel), вместе с представленными за ним фактами.
Arch(X, Y, Z) :-left_pillar(X),
right_pillar(Y), lintel(Z),
supports(X, Z), supports(У, Z), apart(X, Y).
supports(X, Z), on(X, ground),
on(Y, X), not(on(Y, ground)).
apartfX, Y) :- not(touch(X, Y)).
;; Факты
left_pillar(objl). right_pillar(obj2).
on(obj1, ground). on(obj2, ground).
Iintel(obj3). on(obj3, p1). on(obj3, p2).
Как из этих фактов и правил, пользуясь методикой обобщения на основе пояснений, можно вывести определение понятия "арочность" (archhood)?
6. В чем заключаются сильные и слабые стороны подходов на основе правил и прецедентов и как их можно использовать совместно?
7. Что такое нейронная сеть? Какие преимущества сулит использование нейронных сетей по сравнению с символическими методами?
8. Проанализируйте фрагмент нейронной сети, представленный на рис. 23.4.
Рис. 23.4. Фрагмент нейронной сети
I) Что случится с узлом R, если узлы S1, и S3 будут возбуждены?
II) Как изменится состояние узла R, если дополнительно будет возбужден и узел S2?
9. Можете ли вы предложить вариант комбинирования символических и субсимволических парадигм, отличный от того, который использован в системе SCALIR? Сначала задумайтесь над возможностями его использования в задачах извлечения информации, а затем в других задачах, связанных с обработкой больших объемов информации, например распознавания речи.
ГЛАВА 24. Заключение
24.1. Загадка искусственногоинтеллекта
24.2. Представление знаний
24.3. Языки программирования систем искусственного интеллекта
24.4. Решение практических проблем
24.5. Архитектура экспертных систем
Рекомендуемая литература
ГЛАВА 24. Заключение
24.1. Загадка искусственного интеллекта
24.2. Представление знаний
24.3. Языки программирования систем искусственного интеллекта
24.4. Решение практических проблем
24.5. Архитектура экспертных систем
Рекомендуемая литература
В этой главе мы еще раз вспомним темы, рассмотренные в данной книге, и порекомендуем, что нужно прочесть тем, кто пожелает еще глубже изучить их. Обзор организован таким образом, что в нем в сжатом виде будет суммирован материал, разбросанный по разным разделам. В ходе изложения тех или иных тем вам встретятся ссылки на предыдущие главы, но я старался не злоупотреблять ими. В этой главе представлены некоторые прогнозы дальнейших путей развития исследований в области искусственного интеллекта и, в частности, экспертных систем, которые могут послужить материалом для последующей очной или заочной дискуссии. Эти прогнозы представляют мое личное мнение, если только не оговорено обратное, и читатели вольны отнестись к ним с известной долей скептицизма
24.1. Загадка искусственного интеллекта
Тема искусственного интеллекта всегда была в информатике "страной плохишей", населенной массой "неправильных" проблем, не поддающихся решению традиционными способами. Эта область привлекла внимание прежде всего разносторонних специалистов, которых не испугало ее открытое, лишенное всякой организации пространство, — людей, которых влечет задача узнать, как мы мыслим. Такие исследователи, как Марвин Минский (Marvin Minsky), Джон Мак-Карти (John McCarthy), Герберт Саймон (Herbert Simon), Пат Хейес (Pat Hayes), Дональд Мичи (Donald Michie) и Бернард Мельтцер (Bernard Meltzer), стали первопроходцами для тех, кто следовал за ними по пути, пролегающем через информатику, психологию и математическую логику.
Я предлагаю вам задуматься над вопоосами: "Зачем при построении экспертных систем нам вообще нужны технологии, используемые в задачах искусственного интеллекта? Почему нас не устраивают традиционные информационные технологии, такие как матемагическое моделирование? Или, другими словами, тот факт, что экспертные системы начали развиваться в русле задач искусственного интеллекта, является случайностью либо в этом была своя логика?"
Не вдаваясь в длительные рассуждения, можно ответить, что нет ничего плохого в использовании для построения экспертных систем подходящих традиционных технологий, если это приводит к желаемому результату. Например, генерация гипотез в системе DENDRAL (см. главу 20) основана на алгоритме перечисления вершин плоского графа, а в системе MYCIN (см. главу 3) использован статистический подход для выбора способа лечения на основе анализа чувствительности организма к тем или иным лекарственным препаратам. Использование методов поиска или языков программирования, характерных для систем искусственного интеллекта, не запрещает инженерам по знаниям применять методики, заимствованные из прикладной математики, исследования операций или других подходящих дисциплин. Для некоторой части рассматриваемой проблемы решение может быть получено чисто алгоритмически или математически, и было бы непозволительной роскошью отказываться от таких методов, если они способствуют достижению нужного результата.
Более пространный ответ (который я также постараюсь изложить покороче) состоит в том, что экспертные системы не смогли бы получить столь широкого распространения в настоящее время, если бы в свое время в их развитие не внесли существенный вклад идеи искусственного интеллекта. То, что предлагает искусственный интеллект, — это множество концепций, технологий и архитектур, пригодных для решения комплексных проблем в тех случаях, когда чисто арифметические или математические решения либо неизвестны, либо малоэффективны. За последние 30 лет появился ряд работ, в которых предпринималась попытка приспособить к проблематике экспертных систем теоретические и практические результаты, полученные в соответствующих областях математики, информатики или общественных наук. Однако, как правило, оказывалось, что перенос результатов из других дисциплин сопряжен с появлением новых нетривиальных проблем представления информации и управления процессом.
В предыдущих главах мы акцентировали ваше внимание на тех концепциях искусственного интеллекта, которые положены в основание технологии проектирования экспертных систем. Ниже мы кратко перечислим их.
Большой круг проблем, начиная от решения головоломок и заканчивая обучением новым понятиям, может быть сведен к проблеме поиска, если только мы сможем достаточно точно ее сформулировать.
Если мы имеем дело с проблемами, изоморфными абстрактным проблемами (такими, как поиск в лабиринте, оптимизация маршрута и т.п.), о которых известно, что они требуют экспоненциально возрастающих ресурсов, то такой поиск может эффективно выполняться на основе знаний в том смысле, что он направляется знаниями о предметной области.
Представление знаний является не менее важным фактором конструкции экспертной систем, чем механизм логического вывода, поскольку именно представление знаний определяет характеристики пространства поиска, на котором работает механизм вывода.
В ряде глав данной книги мы рассмотрели и технологии искусственного интеллекта, используемые в практике построения экспертных систем. Перечислим их.
Широкий набор языков программирования высокого уровня, которые применяются для представления знаний разного рода, таких как эмпирические ассоциации и иерархии концептов.
Интерактивные стратегии извлечения знаний, их преобразования и представления, управление применением знаний в процессе решения проблем.
Методологии проектирования, обеспечивающие создание таких экспертных систем, которые "прозрачны" как для пользователя, так и для инженеров по знаниям, сопровождающих систему в процессе эксплуатации.
Эти технологии оформлены в виде блоков-компонентов, из которых формируется архитектура экспертной системы. В настоящей книге вы познакомились со следующими методами.
Методы комбинирования различных парадигм представления знаний, которые позволяют выявить сильные стороны компонентов и компенсировать слабые.
Методы послойной организации вычислительной структуры, позволяющие структурно разделить знания о предметной области и методике решения в рамках единой интегрированной системы.
Инструментальные средства расширения функциональных возможностей решателя задач, позволяющие подключить к нему программы обучения и трассировки процесса.
Мы еще вернемся в данном обзоре к этим структурным компонентам экспертных систем. Но нужно подчеркнуть, что извлечь реальную пользу из перечисленных компонентов можно только на основе изложенных ранее базовых концепций. Даже такие ранние системы, как MYCIN и DENDRAL, успех которых удивил всех в свое время, появились не сами по себе, а явились закономерным результатом исследований в области искусственного интеллекта.
Хотя в этот успех внесли свой вклад и традиционные дисциплины (например, исследование операций и стратегий поиска), решающим фактором все-таки оказались идеи искусственного интеллекта. В настоящее время уже общим местом стало утверждение, что по определению предметом интереса области искусственного интеллекта являются те информационные проблемы, которые не могут быть решены с помощью традиционных технологий. Я думаю, что так оно останется и в обозримом будущем.
24.2. Представление знаний
В определенном смысле любая компьютерная программа содержит знания. Программа сортировки по методу "пузырька", написанная на языке BASIC, содержит знания программиста о том, как упорядочить элементы списка. Так чем же все-таки представление знаний отличается от обычного программирования?
Разобраться в сути компьютерной программы, решающей задачу сортировки списков, совсем непросто. Она, конечно же, содержит знания программиста о методе решения задачи, но, помимо этих знаний, в ней содержатся и другие:
как манипулировать языковыми конструкциями используемого языка программирования;
как добиться высокой производительности программы;
как выбрать подходящие методы решения частных проблем обработки данных, играющих, тем не менее, важную роль в достижении конечного результата, и как организовать управление процессом.
Языки представления знания являются языками высокого уровня, специально предназначенными для кодирования в явном виде фрагментов знаний человека, таких как правила влияния и набор свойств типовых объектов, причем высокий уровень языка проявляется в том, что от пользователя скрываются, насколько это возможно, технические подробности механизма представления знаний. Конечно, пользователь при желании может познакомиться со всеми деталями, но идея состоит в том, что это совсем не обязательно делать в процессе разработки программы. В отличие от более привычных языков профаммирования, языки представления знаний исключительно экономичны в смысле объема программного кода. В значительной мере это объясняется тем, что заботу о множестве мелочей берет на себя интерпретатор языка. Можно показать, что большинство из них обладает всеми признаками машины Тьюринга, другими словами, такие интерпретаторы теоретически способны выполнять любые вычисления, которые под силу машине, реализующей программу, написанную на любом из "обычных" языков программирования.
Несмотря на отмеченные достоинства таких языков, нельзя забывать и о существовании определенных проблем при их применении.
Переход от описания знаний о предметной области на всем понятном "человеческом" языке к их представлению в виде какого-либо формализма, воспринимаемого компьютером, требует определенного искусства, поскольку невозможно (по крайней мере, на сегодняшний день) описать, как механически выполнить такое преобразование. Так как возможности логического вывода, которые может реализовать программа, напрямую связаны с выбором способа представления знаний, то, по моему мнению, именно представление знаний, а не их извлечение является самым узким местом в практике проектирования экспертных систем.
Существует определенный баланс противоречий между выразительностью языка представления знаний и простотой трактовки представленных в нем процедур определения логического влияния. Другими словами, чем более концентрировано будут представлены знания в языковой форме, тем сложнее, а значит, и дольше будет процесс их осознания.
В большинстве случаев представление знаний осложняется неуверенностью в них или неопределенностью высказываемых суждений. Наши знания по самой своей природе часто являются неполными и содержат множество догадок и предположений.
Вызов со стороны проблемы представления знаний состоит в том, что мы не можем себе позволить опустить руки перед сложностями, связанными с передачей знаний от человека программе, возможностью их адекватной трактовки и неопределенностью знаний.
Мы вынужденно согласились на довольно эмпирический подход к переводу знаний на язык формальных правил или описаний объектов. Это действительно больше искусство, чем наука, и чем больше вы создадите правил и объектов в процессе своей деятельности, тем более высокого уровня совершенства добьетесь в этом деле. Вопреки распространенному мнению, эта работа далеко не каждому по плечу.
Желая добиться логической полноты, мы часто сталкиваемся с проблемой необозримости. Но чаще всего нам совсем нет нужды получать все логически возможные решения проблемы — можно отыскать только оптимальное или любое, удовлетворяющее заданным ограничениям.
При работе с неопределенностями мы согласны закрыть глаза на некоторую математическую некорректность. Хотя многие используемые на практике варианты схем влияния и не вполне согласуются с аксиомами теории вероятностей, мы идем на определенные упрощения ради практической выгоды.
Сказанное выше нужно расценивать как констатацию реально существующей ситуации. Я не сомневаюсь, что дальнейшие исследования методов представления знаний позволят нам лучше понять смысл этих компромиссов, но в настоящее время мы располагаем методами, которые вполне устраивают нас на практике.
Отошли в прошлое оживленные дискуссии на отвлеченные темы вроде "Может ли машина мыслить?" или "Как действительно представляются знания в мозге человека?" Сейчас чаще всего задаются вопросом: "Что позволяет сделать данная технология?", а ответ на него может быть получен только программой, в которой сконцентрированы результаты теоретической и практической работы, а не метафизические спекуляции.
24.3. Языки программирования систем искусственного интеллекта
Правила логического вывода, теория ориентированных графов и математическая логика были изобретены задолго до появления такой области исследований, как искусственный интеллект. Но именно исследования в этой области позволили адаптировать формальный аппарат этих теорий к задачам представления знаний и отыскать высокоэффективные средства их реализации. Развитие современных продукционных, объектно-ориентированных систем и систем процедурной дедукции в значительной мере определяется такими приложениями искусственного интеллекта, как проблемы классификации и конструирования, описанные в ряде глав данной книги.
Хотя в ходе исследований искусственного интеллекта появилось множество самых различных языков представления, все они обладают рядом сходных свойств.
Во-первых, все такие языки являются декларативными в том смысле, что позволяют описывать знания, имеющие отношение к решению конкретной задачи, а не способ ее решения. В большинстве экспертных систем используется архитектура, в которой знания отделены от машины логического вывода. Это позволяет проводить эксперименты с использованием одних и тех же знаний в разных режимах обработки. Некоторые новые архитектурные решения, например использующие доску объявлений, позволяют представлять управляющие знания декларативно и обрабатывать их так же, как и другие виды знаний.
Во-вторых, все такие языки организованы по модульному принципу. Подобно тому, как сам язык скрывает от пользователя детали механизма реализации, отдельные модули знаний скрывают детали своей реализации друг от друга, общаясь через глобальную структуру данных (в продукционных системах и системах на основе доски объявлений) или посредством определенных протоколов (в объектно-ориентированных системах). Это позволяет наращивать объем базы знаний и использовать методику отработки проектируемой системы на прототипах.
В-третьих, механизм вызова процедур в таких языках основан на сопоставлении образцов в той или иной форме. Активизация правил в продукционных системах, включение источников знаний в системах с доской объявлений и резолюция фраз в дедуктивных системах в той или иной форме используют такое сопоставление. Это очень мощный и достаточно общий механизм, который способствует модульной организации компонентов системы, хотя и требует определенных вычислительных ресурсов.
Языки представления знаний обычно реализуются в виде системы логического вывода, управляемой сопоставлением образцов. Программа на любом из языков такого рода состоит из множества относительно независимых модулей (правил, структур или фраз), которые сопоставляются со входными данными и манипулируют имеющимися в памяти данными. В любой такой системе имеются три существенных компонента.
Набор модулей, каждый из которых может быть активизирован данными, поступающими на вход системы, если эти данные соответствуют образцу, определенному для этого модуля.
Одна или несколько динамических структур данных, которые могут анализироваться и модифицироваться активизированным модулем.
Интерпретатор, который циклически управляет выбором и активизацией модулей.
Исследования в этой области в последние годы концентрируются вокруг следующих задач:
поиск эффективных методов реализации интерпретаторов;
создание на основе "чистых формализмов" программных средств, пригодных для практического применения;
проведение экспериментов со "смешанными" формализмами, объединяющими разные парадигмы.
На сегодняшний день такие языки, как CLIPS, предоставляют в распоряжение пользователя множество разнообразных средств представления знаний и манипулирования ими, которые в руках специалистов позволяют создавать программы для решения широкого круга практических проблем.
24.4. Решение практических проблем
В главах с 10 по 15 мы познакомили вас с идеей, которая состоит в том, что существует несколько обобщенных задач, которые в том или ином виде решаются в большинстве экспертных систем. В частности, мы показали, чем отличаются задачи классификации от задач конструирования, и что для своего решения эти задачи требуют применения совершенно разных стратегий поиска.
При решении задач классификации основной акцент делается на отыскании приемлемого, но, возможно, приближенного соответствия между данными и решениями на некотором уровне абстракции. Нужно учесть все имеющиеся свидетельства, объединить их каким-то образом, а затем уточнить и ранжировать решения-кандидаты. В таких задачах пространство решений, как правило, известно заранее, и представленные в нем категории могут быть перенумерованы. Для работы с таким пространством вполне подходят методы исчерпывающего поиска, которые используют наличие определенности для упорядочения и отсечения путей поиска. Для работы с пространствами поиска большого объема, которые не удается разбить на несколько относительно независимых подпространств, приходится использовать более сложные методы, настроенные на определенную форму организации пространства гипотез (например, иерархическую и причинную).
Суть задачи конструирования состоит в построении некоторого сложного объекта, который должен удовлетворять заданным ограничениям. Естественно, что при этом пространство решений оказывается очень большим. Обычно не удается проследить все возможные пути на пространстве решений в поиске оптимального, чаще всего отыскивается одно из приемлемых решений, удовлетворяющих ограничениям. Ограничения могут влиять друг на друга, и в такой ситуации для разрешения конфликтов нужно использовать знания о предметной области. Наиболее общей для решения задач конструирования оказалась стратегия предложение и пересмотр. Суть ее состоит в том, что частичные решения расширяются до тех пор, пока не будут нарушены заданные ограничения, а затем такое нарушение устраняется с помощью эвристик.
Несмотря на то, что в большинстве случаев можно считать, что типичной задачей классификации является диагностирование, а задачей конструирования — планирование, соответствие между реальными приложениями и обобщенными задачами носит более сложный характер.
Вы имели возможность убедиться, что такие программы диагностирования, как INTERNIST, фактически используют методику решения задачи конструирования. Элементами решения являются отказы, которые объединяются в составную гипотезу. Таким образом, оказывается, что нет никакого смысла заранее нумеровать узлы пространства решений, поскольку пациент может страдать десятью и более заболеваниями. Более того, в общем виде проблема отыскания "наилучшего" объяснения имеющемуся набору симптомов относится к классу необозримых. Без использования мощного механизма концентрации внимания программы на определенном участке пространства не удается отыскать даже приблизительное решение проблемы. Поэтому для решения подобных задач дифференциального диагностирования используются средства, типичные для задач конструирования.
Ряд программ, например R1/XCON, обладает знаниями, достаточными для того, чтобы решить задачу конструирования без использования рекурсии предположений и возврата назад. В рамках стратегии нисходящего уточнения, которая предполагает разбиение задачи построения конфигурации вычислительной системы на ряд практически независимых подзадач, система R1 иногда переключается на восходящую методику логического вывода. На примере системы планирования ONCOCIN мы показали, что для решения проблемы планирования могут иногда использоваться стратегии, характерные для задач эвристической классификации. Благодаря тому, что в этой системе применяется довольно жестко формализованное представление протоколов лечения онкозаболеваний, появилась возможность выбирать подходящую заготовку плана лечения из библиотеки, а затем адаптировать ее к конкретному случаю.
Но как бы там ни было, разграничение задач классификации и конструирования оказалось исключительно полезным, поскольку помогло автоматизировать процесс приобретения знаний. Было также показано, что функциональные возможности программных средств извлечения знаний могут быть существенно расширены, если такие средства будут включать в свой состав декларативную модель предметной области и некоторые знания, касающиеся решаемой задачи, в частности — как будут использованы в приложении получаемые знания. Хотя разработка систем извлечения знаний с ограничением ролей, таких как MORE и RIME, еще не вышла из стадии лабораторных экспериментов, они ознаменовали собой появление новой мощной методологии построения баз знаний. В ее основу положена концепция "извлечение знаний также должно базироваться на знаниях". Первые полученные результаты дают основание надеяться, что на основе этой методологии будут созданы эффективные средства, которые позволят устранить одно из основных "узких" мест в практике проектирования экспертных систем. Автоматический анализ целостности базы знаний и компиляция их в форму выполняемых модулей также в значительной мере упрощается при использовании модели предметной области и информации о принципах решения проблем, используемых в проектируемом приложении.
24.5. Архитектура экспертных систем
В данной книге мы представили классификацию инструментальных средств для проектирования экспертных систем, которая учитывает разнообразные подходы к представлению знаний и управлению процессом принятия решений. В частности, были выделены следующие категории систем.
Оболочки экспертных систем, которые поддерживают какой-либо язык представления знаний и комбинацию режимов управления. Такие оболочки хорошо зарекомендовали себя в ряде приложений, разработанных во времена становления экспертных систем.
Языки программирования высокого уровня, такие как интерпретаторы порождающих правил и объектно-ориентированные системы, которые образуют основные компоненты для представления знаний и управления ходом логического вывода.
Программные среды, использующие смешанные парадигмы, которые обеспечивают пользователя широким спектром средств представления и множеством механизмов управления.
Архитектуры решения проблем, такие как системы с доской объявлений, представляют собой объектно-ориентированные оболочки, на основе которых можно создавать конкретные приложения.
Полезные программные пакеты, которые можно использовать для решения определенных подзадач, например моделирования или анализа правдоподобия. Такие пакеты могут работать в тесном взаимодействии с основной программой решения проблемы.
Было показано, что программы построения экспертных систем первого поколения представляли собой, по существу, адаптацию экспертных систем, хорошо зарекомендовавших себя на практике. Многие из них показали затем свою жизнеспособность и эффективность. Например, система EMYCIN была использована для построения множества прикладных экспертных систем для областей, весьма далеких от медицины, включая структурный анализ и поиск неисправностей в электронных схемах. К этому же периоду относится и появление специализированных языков программирования, таких как OPS5 и FLAVORS.
Для систем второго поколения характерно использование смешанной архитектуры, объединяющей различные парадигмы. Использование соответствующих инструментальных средств продемонстрировало, что с их помощью можно создавать системы с самой разнообразной архитектурой, поддерживающей разные способы представления знаний и механизмы управления процессом.
В прошлом часто высказывалось предположение, что использование в процессе разработки более мощных инструментальных средств будет способствовать упрощению программирования экспертных систем. Существует, однако, некоторый баланс между "мощностью" инструмента, принимающего решение за разработчика, и гибкостью, допускающей возможность выбрать решение, наиболее подходящее для конкретной системы. Чрезмерное упрощение оболочек зачастую оборачивалось слишком большими ограничениями для разработчиков прикладных систем, в то время как смешивание разных парадигм программирования предоставляло такую свободу, с которой не всякий программист мог разумно управиться. Как показала практика, наиболее эффективным путем оказалось предоставление разработчику тщательно продуманных готовых модулей, таких как системы анализа правдоподобия, которые способны эффективно решать отдельные важные нетривиальные задачи. Применение таких модулей существенно сокращает сроки разработки прикладных экспертных систем.
Рекомендуемая литература
Для рядового читателя лучшим источником сведений о последних событиях в мире искусственного интеллекта является журнал Al Magazine. Множество интересных обзоров можно найти и на страницах Knowledge Engineering Review, который будет весьма полезен студентам и инженерам.
Тем, кого интересуют определенные темы исследований, я рекомендую регулярно просматривать материалы конференций
IJCAI (International Joint Conference on Artificial Intelligence),
AAAI (The National Conference on Artificial Intelligence). Эта конференция проводится при поддержке Американской ассоциации искусственного интеллекта (American Association for Artificial Intelligence);
ECAI (European Conference on Artificial Intelligence).
О новых областях применения методов искусственного интеллекта можно узнать в трудах специализированных конференций, касающихся космических исследований, автоматизации проектирования, производства, правоведения и др. Обычно календарь проведения подобных конференций публикуется на страницах журналов AI Magazine и Communications of the Association for Computer Machinery. В рамках Association for Computer Machinery работает Special Interest Group on Artificial Intelligence (SIGART), которая ежеквартально публикует собственный сборник сообщений.
Прекрасным источником работ прошлых лет является журнал Artificial Intelligence. В электронном журнале Journal of Artificial Intelligence Research вы найдете рефераты материалов, распространяемых по сети Internet с 1993 года. Его адрес
http: //www. cs/washington. edu/research/ jair/home. html
В Internet существует и много других источников информации по проблемам искусственного интеллекта. Ниже приведены только некоторые из них.
http://www.aaai.org— сервер Американской ассоциации искусственного интеллекта (American Association for Artificial Intelligence);
http://www.cs.cmu.edu/Groups/AI/html/repository.html - хранилище публикаций по искусственному интеллекту при университете Карнеги-Меллона;
http://www.comlab.ox.ac.uk/archive/comp/ai.html— включает каталоги отдельных лабораторий, занимающихся проблемами искусственного интеллекта;
http://www.jsc.nasa.gov/~clips/CLIPS.html — сервер CLIPS;
http://www.ai-cbr.org/theindex.html— источники, касающиеся методики использования прецедентов в системах искусственного интеллекта.
Литература
Abelson H., Sussman G. J. and Sussman J. (1996). Structure and Interpretation of Computer Programs. Cambridge MA: MIT Press.
Abu-Hakima S., Halasz M. and Phan S. (1993). An approach to hypermedia in diagnostic systems. In Intelligent Multi-Media Interfaces (Maybury M., eds.). AAAI Press/MIT Pressi
Acorn T. L. and Walden S. (1992). SMART: Support Management Automated Reasoning Technology for Compaq customer service. In Proc. Innovative Applications of Artificial Intelligence (IAAI-92), p. 3-18.
Adams J. B. (1976). A probability model of medical reasoning and the MYCIN model. Mathematical Biosciences, 32, p. 177-186. See also Buchanan and Shortliffe (1984), Chapter 12.
Aiello N. (1983). A comparative study of control strategies for expert systems: AGE implementation of three variations of PUFF. In Proc. National Conference on Artificial Intelligence, p. 1-4.
Aiello N. (1986). User-Directed Control of Parallelism: The CAGE System. Technical Report No. KSL-86-31, Knowledge Systems Laboratory, Stanford University.
Aikins J. S. (1983). Prototypical knowledge for expert systems. Artificial Intelligence, 10, p. 163-210.
Aikins J. S., Kunz J. C., Shortliffe E. H. and Fallat R. J. (1984). PUFF: an expert system for interpretation of pulmonary function data. In Readings in Medical Artificial Intelligence (Clancey W. J. and Shortliffe E. H., eds.). Chapter 19. Reading, MA: Addison-Wesley.
Aleven V. and Ashley K. D. (1997). Evaluating A Learning Environment For Case-Based Argumentation Skills. In Proc. Sixth International Conference on Artificial Intelligence and Law, ACM Press, p. 170.
Alexander J. H., Freiling M. J., Shulman S. J., Staley J. L., Rehfuss S. and Messick S. L. (1986). Knowledge level engineering: ontological analysis. In Proc. National Conference on Artificial Intelligence, p. 963-968.
Allen B. (1994). Case-based reasoning: business applications. Communications of the ACM, 37(3), p. 40^2.
Allen J.F. (1983). Maintaining knowledge about temporal intervals. Communications of the ACM, 26(11), p. 832-843.
Allen J. F. (1995). Natural Language Understanding, 2nd edn. Menlo Park, CA: Benja-min/Cummings.
Amarel S. (1968). On representations of problems of reasoning about actions. In Machine Intelligence 3 (Michie D., eds.), p. 131-171. Edinburgh: Edinburgh University Press.
Anderson J. R. (1976). Language, Memory and Thought. Hillsdale NJ: Lawrence Eribaum. Andrews P. B. (1986). An Introduction to Mathematical Logic and Type Theory: To Truth
through Proof. Orlando FL, Academic Press. Ashley K. D. (1990). Modeling Legal Argument: Reasoning With Cases and Hypothetical.
Cambridge MA: MIT Press.
Ashley K. and Aleven V. (1997). Reasoning symbolically about partially matched cases. International Joint Conference on Artificial Intelligence, IJCAI-1997. San Francisco: Morgan Kaufmann, p. 335-341.
Ashley K. D. and Rissland E. L. (1988). A case-based approach to modelling legal expertise. IEEE Expert, 3(3), p. 70-77.
Bachant J. (1988). RIME: preliminary work towards a knowledge acquisition tool. In Automating Knowledge Acquisition for Expert Systems (Marcus S., eds.), Chapter 7. Boston: Kluiver Academic.
Baldwin J. E, eds. (1996). Fuzzy Logic. New York: Wiley.
Barr A. and Feigenbaum E. A., eds. (1981). The Handbook of Artificial Intelligence Vol. 1. Los Altos CA: Morgan Kaufmann.
Barr A. and Feigenbaum E. A., eds. (1982). The Handbook of Artificial Intelligence Vol. 2. Los Altos CA: Morgan Kaufmann.
Baum L. S., Dodhiawala R. T. and Jagannathan V. (1989). The Erasmus System. In Blackboard Architectures and Applications (Jagannathan V, Dodhiawala R. and Baum L., eds.), p. 347-370. New York: Academic Press.
Belew R. K. (1986). Adaptive information retrieval: machine learning in associative networks. PhD thesis, University of Michigan, Computer Science Department, Ann Arbor, MI.
Bennett J. S., Creary L., Englemore R. and Melosh R. (1978). SACON: A Knowledge Based Consultant for Structural Analysis. Report No. HPP-78-23, Computer Science Department, Stanford University.
Bergadano F. and Gunetti D. (1996). Inductive Logic Programming: From Machine Learning to Software Engineering. Cambridge MA: MIT Press.
Biswas G. and Anand T. S. (1987). MIDST: an expert system shell for mixed initiative reasoning. In Proc. International Symposium on Methodologies for Intelligent Systems, p. 1-8.
Bobrow D. G. and Collins A., eds. (1975). Representation and Understanding. New York: Academic Press.
Bobrow D. G. and Stefik M. (1983). The LOOPS manual. Xerox Corporation.
Bobrow D. G. and Winograd T. (1977). An overview of KRL, a knowledge representation language. Cognitive Science, 1(1).
Bobrow D. G. and Winograd T. (1979). KRL: another perspective. Cognitive Science, 3(1).
Booch G. (1994). Object-Oriented Analysis and Design with Applications, 2nd edn. Redwood City CA: Benjamin/Cummings. (Русский перевод первого издания: Буч Г. Объектно-ориентированное проектирование с примерами применения. — М.: Конкорд, 1992.)
Boose J. H. (1986). Expertise Transfer for Expert System Design. New York: Elsevier.
Boose J. H. (1989). A survey of knowledge acquisition techniques and tools. Knowledge Ac-^ quisition, 1(1), p. 3-37.
Boose J. H. and Bradshaw J. M. (1987). Expertise transfer and complex problems: using. AQUINAS as a workbench for knowledge based systems. International Journal of Man-Machine Studies, 26, p. 1-28.
Boose J. H. and Gaines B. (1988). Knowledge Acquisition Tools for Expert Systems. New York: Academic Press.
Borron J., Morales D. and Klahr P. (1996). Developing and deploying knowledge on a global scale. In Innovative Applications of Artificial Intelligence 8, Proceedings of AAAI-96. Menlo Park CA: AAAI Press.
Brachman R. J. and Levesque H. J. (1985). Readings in Knowledge Representation. Los Altos CA: Morgan Kaufinann.
Brachman R. J. and Schmolze J. G. (1985). An overview of the KL-ONE knowledge representation system. Cognitive Science, 9, p. 171-216.
Bratko I. (1990). PROLOG Programming for Artificial Intelligence, 2nd eds. Wokingham, UK: Addison-Wesley. (Русский перевод первого издания: Братко И. Программирование на языке PROLOG для искусственного интеллекта. — М.: Мир, 1990. — 559 с.)
Breuker J. A. and van de Velde W., eds. (1994). The CommonKADS Library for Expertise Modelling. Amsterdam: IOS Press.
Brown D. C. and Chandrasekaran B. (1989). Design Problem Solving: Knowledge Structures and Control Strategies. Los Altos CA: Morgan Kaufmann.
Brown J. S., Burton R. R. and De Kleer J. (1982). Pedagogical, natural language and knowledge engineering techniques in SOPHIE I, II and III. In Intelligent Tutoring Systems (Sleeman D. and Brown J. S., eds.), Chapter 11. London: Academic Press.
Brownston L., Farrell R., Kant F. and Martin N. (1985). Programming Expert Systems in OPS5. Reading MA: Addison-Wesley.
Buchanan B. G. and Feigenbaum E. A. (1978). DENDRAL and META-DENDRAL: their applications dimension. Artificial Intelligence, 11, p. 5-24.
Buchanan B. G. and Shortliffe E. H., eds. (1984). Rule-Based Expert Systems. Reading MA: Addison-Wesley.
Buchanan B. G. and Wilkins D. C., eds. (1993). Readings in Knowledge Acquisition and Learning. Los Altos, CA: Morgan Kaufmann.
Buchanan B. G., Barstow D., Bechtel R., Bennet J., Clancey W., Kulikowski C., Mitchell Т. М. and Waterman D. A. (1983). Constructing an expert system. In Building Expert Systems (Hayes-Roth F, Waterman D.A. and Levat D., eds.), Chapter 5. Reading, MA: Addison-Wesley.
Bundy A. (1978). Will it reach the top? Prediction in the mechanics world. Artificial Intelligence, 10, p. 129-146.
Bundy A., Byrd L., Luger G., Mellish C. and Palmer M. (1979). Solving mechanics problems using metalevel inference. In Expert Systems in the Micro-Electronic Age (Michie D., eds.), p. 50-64. Edinburgh: Edinburgh University Press.
Bundy A., Silver B. and Plummer D. (1985). An analytical comparison of some rule-learning programs. Artificial Intelligence, 27, p. 137-181.
Buntine W. L. (1990). Myths and legends in learning classification rules. In Proc. National Conference on Artificial Intelligence, p. 736-742.
Bylander T. (1994). The computational complexity of prepositional STRIPS planning. Artificial Intelligence, 69, p. 165-204.
Cannon H. I. (1982). FLAVORS: a non-hierarchical approach to object-oriented programming. Unpublished paper.
Carbonell J. G., Michalski R. and Mitchell T. (1983). An overview of machine learning. In Machine Learning (Michalski R. S., Carbonell J. S. and Mitchell Т. М., eds.), Chapter 1. Palo Alto, CA: Tioga.
Carver N. and Lesser V. (1994). The evolution of blackboard control architectures. In Expert Systems with Applications: Special Issue on the Blackboard Paradigm and its Applications, 7(1), p. 1-30.
Cendrowska J. and Bramer M. (1984). Insdie an expert system: A rational reconstruction of the MYCIN consultation system. In Artificial Intelligence: Tools, Techniques and Applications (O'Shea T. and Eisenstadt M., eds.). Chapter 15. New York: Harper and Row.
Chandrasekaran B. (1983). Towards a taxonomy of Problem solving types. Al Magazine, 4(1), Spring, p. 9-17.
Chandrasekaran B. (1984). Expert systems: matching techniques to tasks. In Artificial Intelligence Applications for Business (Reitman W, eds.). Norwood, NJ: Ablex.
Chandrasekaran B. (1986). Generic tasks in knowledge-based reasoning: high-level building blocks for expert systems design. IEEE Expert, 1(3), p. 23-30.
Chandrasekaran B. (1988). Generic tasks as building blocks for knowledge-based systems: the diagnosis and routine design examples. Knowledge Engineering Review, 3(3), p. 183-210.
Chandrasekaran B. and Mittal S. (1984). Deep versus compiled knowledge approaches to diagnostic problem solving. In Developments in Expert Systems (Coombs M. J., eds.), Chapter 2. London; Academic Press.
ChappellD. (1996). Understanding ActiveX and Ole. Microsoft Press.
Charniak E. and McDermott D. (1985). Introduction to Artificial Intelligence. Reading, MA: Addison-Wesley.
Charniak E., Reisbeck C. and McDermott D. (1987). Artificial Intelligence Programming, 2nd ed. Hillsdale, NJ: Lawrence Eribaum.
Cheeseman P. (1985). In defense of Probability. In Proc. 8th InternationalJoint Conference on Artificial Intelligence, p. 1002-1009.
Church A. (1941). The Calculi of Lambda Conversion. Annals of Mathematics Studies, Princeton University Press.
Clancey W. J. (1983). The epistemology of a rule-based expert system: a framework for explanation. Artificial Intelligence, 10, p. 215-251.
Clancey W. J. (1985). Heuristic classification. Artificial Intelligence, 27, p. 289-350.
Clancey W. J. (1987, a). Knowledge-Based Tutoring, The GUIDON Program. Cambridge, MA: MIT Press.
Clancey W. J. (1987, b). Intelligent tutoring systems: a tutorial survey. In van Lamsweerde and Dufour (1987), Chapter 3.
Clancey W. J. (1987, c). From GUIDON to NEOMYCIN and HERACLES in twenty short lessons, In Current Issues in Expert Systems (van Lamsweerde A. and Dufour P., eds., Chapter 4. London: Academic Press.
Clancey W. J. (1993, a). Notes on "Heuristic Classification". Artificial Intelligence, 59, p. 191-196.
Clancey W. J. (1993, b). Notes on "Epistemology of a rule-based expert system". Artificial Intelligence, 59, p. 197-204.
Clancey W. J. and Letsinger R. (1984). NEOMYCIN: reconfiguring a rule-based expert system for application to teaching. In Readings in Medical Artificial Intelligence (Clancey W. J. and Shortliffe E. H., eds.). Chapter 15. Reading, MA: Addison-Wesley.
Clancey W. J. and Shortliffe E. H., eds. (1984). Readings in Medical Artificial Intelligence. Reading, MA: Addison-Wesley.
Clark K. L. and McCabe F. (1982). PROLOG: a language for implementing expert systems. In Machine Intelligence 10 (Hayes J. E., Michie D. and Pao Y. H., eds.). Chichester, UK: Ellis Horwood.
Clark K. L. and Tarnlund S.-A., eds. (1982). Logic Programming, London: Academic Press
Cohen P. and Feigenbaum E. A., eds. (1982). The Handbook of Artificial Intelligence, Vol. 3. Los Altos, CA: Morgan Kaufinann.
Collins A. M. and Quillian M. R. (1969). Retrieval time from semantic memory. Journal of Verbal Learning and Verbal Behavior, 8, p. 240-247.
Coombs M. J., eds. (1984). Developments in Expert Systems. London: Academic Press.
Cooper G. F. (1990). The computational complexity of probabilistic inference using Bavesian belief networks. Artificial Intelligence, 42, p. 393-405.
Corkill D. D. (1991). Blackboard systems. Al Expert, 6(9), p. 40-47. Coyne R, (1988). Logic Models of Design. London: Pitman.
Cox R. (1946). Probability frequency and reasonable expectation. American Journal of Physics, 14(1), p. 1-13.
Craig I. (1995). Blackboard Systems. Norwood, NJ: Ablex.
Davies J. and May R. (1995). The development of a prototype "correctly dressed" case-based reasoner: Efficacy of CBR-Express. In Progress in Case-Based Reasoning (Watson I., eds.). Lecture Notes in Artificial Intelligence, 1020. Berlin: Springer-Verlag.
Davis R. (1980, a). Meta-rules: reasoning about control. Artificial Intelligence, 15, p. 179-222.
Davis R. (1980, b). Applications of meta-level knowledge to the construction, maintenance and use of large knowledge bases. In Knowledge-Based Systems in Artificial Intelligence (Davis R. and Lenat D., eds.) p. 229-490. New York: McGraw-Hill.
Davis R. (1982). Expert systems: Where are we? And where do we go from here? Al Magazine, 3(2).
Davis R. (1984). Diagnostic reasoning based on structure and behavior. Artificial Intelligence, , 24, p. 347-410.
Davis R. (1989). Expert systems: how far can they go? Part Two. Al Magazine, 10(2), Summer 1989, p. 65-77.
Davis R. and King J. (1977). An overview of production systems. In Machine Intelligence 8 (Elcock E. W. and Michie D., eds.), p. 300-332. New York: Wiley.
Davis R. and Lenat D. (1980). Knowledge-Based Systems in Artificial Intelligence. New York: McGraw-Hill.
De Kleer J. (1986). An assumption based TMS. Artificial Intelligence, 28, p. 127-162.
De Kleer J. and Williams В. С. (1987). Diagnosing multiple faults. Artificial Intelligence, 32, p. 97-130.
Dean T. L. and Wellman M. (1991). Planning and Control. Los Altos, CA: Morgan Kaufinann.
Dietterich T. G. and Michalski R. (1983). A comparative review of selected methods for learning 'from examples. In Machine Learning (Michalski R. S., Carbonell J. G. and Mitchell T. M., eds.), Chapter 3. Palo Alto, CA: Tioga.
Doyle J. (1979). A truth maintenance system. Artificial Intelligence, 12, p. 231-272.
Dubois D., Prade H. and Yager R. R., eds. (1996). Fuzzy Information Engineering: A Guided Tour of Applications. New York: Wiley.
Elcock E. W. and Michie D., eds. (1977). Machine Intelligence 8. New York: Wiley.
Englemore R. and Morgan Т., eds. (1988). Blackboard Systems. Reading, MA: Addison-Wesley.
Eriksson H., Shahar Т., Tu S. W., Puerta A. R. and Musen M. A. (1995). Task Modeling with reusable problem-solving methods. Artificial Intelligence, 79 (2), p. 293-326.
Erman L., Hayes-Roth R., Lesser V. and Reddy D. (1980). The HEARSAY-II speech understanding system: integrating knowledge to resolve uncertainty. Computing Surveys, 12(2), p. 213-253.
Erman L. D., London P. E. and Fickas S. F. (1983). The design and an example use of HEARSAY-III, InProc. National Conference on Artificial Intelligence, p. 409^415.
Eshelman L. (1988). A knowledge acquisition tool for cover-and-differentiate systems. In Automating Knowledge Acquisition for Expert Systems (Marcus S., eds.), Chapter 3. Boston: Kluiver Academic.
Eshelman L. and McDermott J. (1986). MOLE: a knowledge acquisition tool that uses its head. In Proc. National Conference on Artificial Intelligence, p. 950-955.
Eshelman L., Ehret D., McDermott J. and Tan M. (1987). MOLE: a tenacious knowledge acquisition tool. InternationalJournal of Man-Machine Studies, 26, p. 41-54.
Feigenbaum E. A. (1977). The art of artificial intelligence: themes and case studies of knowledge engineering. In Proc. 5th International Joint Conference on Artificial Intelligence, p. 1014-1029.
Feigenbaum E.A. and Buchanan B.G. (1993). DENDRAL and Meta-DENDRAL: roots of knowledge systems and expert systems applications. Artificial Intelligence, 59, p. 233-240.
Feigenbaum E. A. and Feldman J., eds. (1963). Computers and Thought. New York: McGraw-Hill.
Feigenbaum E. A., McCorduck P. and Nii H. P. (1988). The Rise of the Expert Company. Times Books.
Feiner S. K. and McKeown K. R. (1991). Automating the generation of coordinated multimedia explanations. In Intelligent Multi-Media Interfaces (Maybury M., eds.), Chapter 5. AAAI Press/MIT Press.
Fikes R. E. and Nilsson N. J. (1971). STRIPS: a new approach to the application of theorem proving to problem solving. Artificial Intelligence, 2, p. 189-208. (Русский перевод: Файкс Р., Нильсон Н. Система STRIPS — новый подход к применению методов доказательства теорем при решении задач.— В сб. Интегральные роботы, вып. 1. Под. ред. Г. Е. Поздняка. — с. 382^103.)
Findler N. V., eds. (1979). Associative Networks. New York: Academic Press.
Forbus K. and de Kleer J. (1993). Building Problem Solvers. Cambridge, MA: MIT Press.
Forgy C. L. (1982). Rete: a fast algorithm for the many pattern/many object pattern match
problem. Artificial Intelligence, 19, p. 17-37.
Gale W. A. (1986). Artificial Intelligence and Statistics. Reading, MA: Addison-Wesley. Gale W. A. (1987). Knowledge-based knowledge acquisition for a statistical consulting system.
International Journal of Man-Machine Studies, 26, p. 54-64.
Genesereth M. R. (1984). The use of design descriptions in automated diagnosis. Artificial Intelligence, 24, p. 411-436. Genesereth M. R. and Nilsson N. J. (1987). Logical Foundations of Artificial Intelligence. Los
Altos, CA: Morgan Kaufmann. Giarratano J. and Riley G. (1994). Expert Systems: Principles and Programming, 2nd edn.
Boston, MA: PWS Publishing.
Gil Y. and Paris C. L. (1994). Towards method-independent knowledge acquisition. Knowledge Acquisition, 6(2), p. 163-178. Ginsberg M., eds. (1987). Readings in Nonmonotonic Reasoning. Los Altos, CA: Morgan
Kaufmann.
Ginsberg M. (1993). Essentials of Artificial Intelligence. Los Altos, CA: Morgan Kaufmann. Givan R. and Dean T. (1997). Model minimization, regression, and propositional STRIPS planning. In Proc. 15th International Joint Conference on Artificial Intelligence, p. 1163-1168. Glaser H., Hankin C. and Till D. (1984). Functional Programming. Englewood Cliffs, NJ:
Prentice-Hall. Goldberg A. and Robson D. (1983). Smalltalk-80; The Language and its Implementation.
Reading, MA: Addison-Wesley. Golding A. R. and Rosenbloom P. S. (1991). Improving rule-based systems through case-based
reasoning. In Proc. National Conference on Artificial Intelligence, p. 22-21. Golding A. R. and Rosenbloom P. S. (1996). Improving accuracy by combining rule-based and
case-based reasoning. Artificial Intelligence, 87, p. 215-254. Goldman N. (1978). АРЗ User's Guide. Information Sciences Institute, University of Southern
California.
Gordon J. and Shortliffe E. H. (1985). A method of managing evidential reasoning in a hierarchical hypothesis space. Artificial Intelligence, 26, p. 323-357. Graham P. (1994). On Lisp: Advanced Techniques for Common Lisp. Englewood Cliffs, NJ:
Prentice-Hall.
Haberi J. S., Norford L. K. and Spadaro G. V. (1989). Diagnosing building operational problems. ASHRAE Journal, June, p. 20-30.
Hammond K. J. (1986). CHEF: a model of case-based planning. In Proc. AAAI-86 Harmon P. (1992). Case-based reasoning III. Intelligent Software Strategies, 8(1). Harmon P. and Hall C. (1993). Intelligent Software Systems Development: An IS Manager's Guide. New York: Wiley.
Harmon P. and Sawyer B. (1990). Creating Expert Systems for Business and Industry. New York: Wiley.
Hasling D. W., Clancey W. J. and Rennels G. (1984). Strategic explanations for a diagnostic consulting system. InternationalJournal of Man-Machine Studies, 20(1), p. 3-19.
Hayes J. E. and Michie D., eds. (1984). Intelligent Systems - The Unprecedented Opportunity. Chichester, UK: Ellis Horwood.
Hayes J. E., Michie D. and Pao Y. H., eds. (1982). Machine Intelligence 10. Chichester, UK: Ellis Horwood.
Hayes-Roth B. (1985). Blackboard architecture for control. Artificial Intelligence, 26, p. 251-321.
Hayes-Roth F., Waterman D. A. and Lenat D., eds. (1983). Building Expert Systems. Reading, MA: Addison-Wesley. (Русский перевод: Хейес-Рот Ф., Уотерман Д., Ленат Д. Построение экспертных систем. — М.: Мир, 1987. — 430 с.)
Hayes-Roth В., Buchanan В., Lichtarge О., Hewett M., Altaian R., Brinkiey J., Cornelius С., Duncan В. and JardetzkyO. (1986). PROTEAN: deriving protein structure from constraints. In Proc. National Conference on Artificial Intelligence, p. 904-909.
Hayes-Roth В., Garvey A., Johnson M. V. and Hewett H. (1987). A Modular and Layered Environment for Reasoning About Action. Technical Report No. KSL 86-38, Knowledge Systems Laboratory, Stanford University.
Hayes-Roth В., Johnson M. V., Garvey A. and Hewett H. (1988). Building systems in the BB* environment. In Blackboard Systems (Englemore R. and Morgan Т., eds.), Chapter 29. Reading, MA: Addison-Wesley.
Heckerman D. (1986). Probabilistic interpretation for MYCIN's certainty factors. In Uncertainty in Artificial Intelligence (Kanal L. N. and Lemmer J. E., eds.), p. 169-196. Amsterdam: North-Holland.
Henderson P. (1980). Functional Programming: Application and Implementation. Englewood Cliffs, NJ: Prentice-Hall.
Hendrix G. G. (1979). Encoding knowledge in partitioned networks. In Associative Networks (Findler N. V., eds.), p. 51-92. New York: Academic Press.
Henrion M., Shachter R. D., Kanal L. N. and Lemmer J. E., eds., (1990). Uncertainty in Artificial Intelligence 5. Amsterdam: North-Holland.
Hewitt C. (1972): Decription and Theoretical Analysis (Using Schemata) of PLANNER, a Language for Proving Theorems and Manipulating Models in a Robot. Report No. TR-258, AI Laboratory, MIT.
Hinton G. E. (1989). Connectionist learning procedures. Artificial Intelligence, 40, p. 185-234.
Hislop C. and Pracht D. (1994). Integrated problem resolution for business communications. In Innovative Applications of Artificial Intelligence 6, Proceedings of AAA1-94, p. 63-74, Memo Park, CA: AAAI Press.
Hopcroft J. E. and Ullman J. D. (1979). Introduction to Automata Theory, Languages and Computation. Reading, MA: Addison-Wesley.
Horty J. R., Thomason R. H. and Touretzky D. S. (1987). A skeptical theory of inheritance in nonmonotonic semantic nets. In Proc. National Conference on Artificial Intelligence, p. 358-363.
Horvitz E. and Heckerman D. (1986). The inconsistent use of measures of certainty in artificial intelligence research. In Uncertainty in Artificial Intelligence (Kanal L. N. and Lemmer J. R., eds.), p. 137-151. Amsterdam: North Holland.
Horvitz E., Heckerman D. and Langlotz C. P. (1986). A framework for comparing formalisms for plausible reasoning. In Proc. National Conference on Artificial Intelligence, p. 210-214.
Hunt E. В., Mann I. and Stone P. T. (1966). Experiments in Induction. New York: Academic Press.
Jagannathan V., Dodhiawala R. and Baum L. S., eds. (1989). Blackboard Architectures and Applications. New York: Academic Press.
Jamshidi M, Tilti A., Zadeh L. and Boverie S., eds. (1997). Applications of Fuzzy Logic: Towards High Machine Intelligence Quotient Systems. Englewood Cliffs, NJ: Prentice Hall.
Jensen R V. (1996). Introduction to Bayesian Networks. Berlin: Springer Verlag.
Johnson M. V. and Hayes-Roth B. (1986). Integrating Diverse Reasoning Methods in the BB1 Blackboard Control Architecture. Technical Report No. KSL 86-76, "Knowledge Systems Laboratory, Stanford University.
Kahn G. (1988). MORE: from observing knowledge engineers to automating knowledge acquisition. In Automating Knowledge Acquisition for Expert Systems (Marcus S., eds.), Chapter 2. Boston: Kluiver Academic.
Kahn G. and McDermott J. (1984). The MUD system. In Proc. 1st IEEE Conference on Artificial Intelligence Applications.
Kahn G., Nowlan S. and McDermott J. (1985). MORE; an intelligent knowledge acquisition tool. In Proc. 9th International Joint Conference on Artificial Intelligence, p. 581-584.
Kahn G., Kepner A. and Pepper J. (1987). TEST: a model-driven application shell. In Proc. National Conference on Artificial Intelligence, p. 814-818.
Kahneman D. and Tversky A. (1972). Subjective probability: a judgement of representativeness. Cognitive Psychology, 3, p. 430-454.
Kahneman D., Slovic P. and Tversky A., eds. (1982). Judgement under Uncertainty: Heuristics and Biases. Cambridge: Cambridge University Press.
Kam M., ChowJ.-C. and Fischi R. (1991). Hybrid expert system/neural network architecture for classifying power system contingencies. In Proc. First International Forum on Applications of Neural Networks to Power Systems, p. 76-82.
Kanal L. N. and Lemmer J. R., eds. (1986). Uncertainty in Artificial Intelligence. Amsterdam: North-Holland.
Keene S. E. (1989). Object-Oriented Programming in COMMON LISP. Reading, MA: Addi-son-Wesley.
Kingston J. K. C. (1997). Designing knowledge based systems: The CommonKADS design model. In Research and Development in Expert Systems XIV, Proceedings ofBCS SGES, Expert Systems '97, Cambridge University Press.
Kingston J. K. C., Doheny J. G. and Filby I. M. (1995). Evaluation of workbenches which support the CommonKADS methodology. Knowledge Engineering Review, 10, 3.
Klahr P. and Waterman D., eds. (1986). Expert Systems: Techniques, Tools, and Applications. Reading, MA: Addison-Wesley.
Kodratoff Y. and Michalski R. S., eds. (1990). Machine Learning: An Artificial Intelligence Approach, Vol. III. Los Altos, CA: Morgan Kaufrnann.
Kolodner J. L. (1991). Improving human decision making through case-based decision aiding. AIMagazine, 12 (2), p. 52-68.
Kolodner J. L. (1993). Case-Based Reasoning. Los Altos, CA: Morgan Kaufrnann.
Kononenko I., Bratko I. and Riskar E. (1984). Experiments in Automatic Learning of Medical Diagnostic Rules. Jozef Stefan Institute, Ljubljana, Yugoslavia.
Korf R. E. and Reid M. (1998). Complexity analysis of admissible heuristic search. In Proc. 15th National Conference on Artificial Intelligence (AAAI-98). p. 305-310, AAAI Press.
Kowalski R. A. (1979). Logic for Problem Solving. Amsterdam: North-Holland.
Kowalski R. A. (1982). Logic as a computer language. InLogic Programming (Clark K. L. and Tarnlund S. -A., eds.) Chapter 1. London: Academic Press.
Kunz J. C, Fallal R. J., McClung D. H, Osborn J. J, Votteri R. A., Nii H. P., Aikins J. S, Fa-gan L. M. and Feigenbaum E. A. (1978). A Physiological Rule-Based System for Interpreting Pulmonary Function Test Results. Report No. HPP 78-19, Heuristic Programming Project, Computer Science Department, Stanford University.
Kunz J. C., Kehler T. P. and Williams M. D. (1984). Applications development using a hybrid AI development system. AlMagazine, 5(3), Fall, p. 41-54.
Lan M. S., Panos R. M. and Balban M. S. (1987). Experience using S.I: an expert system for newspaper printing press configuration. Knowledge Engineering Review, 2(4), p. 277-285.
Langlotz C. P., Shortliffe E. H. and Fagan L. M. (1986). Using decision theory to justify heuristics. In Proc. National Conference on Artificial Intelligence, p. 215-219.
Laurent J. P., Ayel J., Thome F. and Ziebelin D. (1986). Comparative evaluation of three expert system development tools: KEE, Knowledge Craft, ART. Knowledge Engineering Review, 1(4), p. 19-29.
Lehnert W. and Wilks Y. (1979). A critical perspective on KRL Cognitive Science, 3, p. 1-28. Lenat D. B. (1982). The nature of heuristics. Artificial Intelligence, 19, p. 189-249.
Levesque H. and Mylopoulos J. (1979). A procedural semantics for semantic networks. In Associative Networks (Findler N. V., eds.), p. 93-120. New York: Academic Press.
Linster M. and Musen M. A. (1992). Use of KADS to create a conceptual model of the
ONCOCINtask. Knowledge Acquisition, 4, p. 55-87. MacGregor R. (1991). Inside the LOOM classifier. SIGART Bulletin, 2(3), p. 70-76.
Mamdani E. H. and Gaines B. R. (1981). Fuzzy Reasoning and its Applications. London: Academic Press.
Marcus S., eds. (1988, a). Automating Knowledge Acquisition for Expert Systems. Boston: Kluiver Academic.
Marcus S. (1988, b). A knowledge acquisition tool for propose-and-revise systems. In Automating Knowledge Acquisition for Expert Systems (Marcus S., eds.). Chapter 4. Boston: Kluiver Academic.
Marcus S., Stout J. and McDermott J. (1988). VT: an expert elevator configurer that uses knowledge-based backtracking. AI Magazine, 9(1), p. 95-112.
Marir F. and Watson I. (1994). Case-based reasoning: a categorized bibliography. Knowledge
Engineering Review, 9(4), p. 355-381. Martins J. P. and Reinfrank M. (1991). Truth Maintenance Systems. Lecture Notes in Artificial
Intelligence, No. 515. Berlin: Springer Verlag. Maybury M., eds. (1993). Intelligent Multi-Media Interfaces. Cambridge, MA: AAAI
Press/MIT Press.
McAllester D. (1980). An Outlook on Truth Maintenance. Report No. AIM-551, Artificial Intelligence Laboratory, Massachusetts Institute of Technology.
McArthur D., Klahr P. and Narain S. (1986). ROSS: an object-oriented language for constructing simulations. In Expert Systems: Techniques, Tools and Applications (Klahr P. and Waterman D., eds.). Chapter 3. Reading, MA: Addison-Wesley.
McCarthy J. (1960). Recursive functions of symbolic expressions and their computation by machine. Communications of the Association for Computing Machinery, April, p, 184-195. McCarthy J. and Hayes P. (1969). Some philosophical problems from the standpoint of artificial intelligence. In Machine Intelligence 4 (Meltzer B. and Michie D., eds.), p. 463-502. Edinburgh: Edinburgh University Press.
McCarthy J., Abrahams P. W., Edwards D. I., Hart T. P. and Levin M. I. (1965). LISP 1.5 Programmer's Manual, 2nd edn. Cambridge, MA: MIT Press.
McDermott J. (1980). Rl: an expert in the computer system domain. In Proc. National Conference on Artificial Intelligence, p. 269-271. McDermott J. (1981). Rl's formative years. AIMagazine, 2(2).
McDermott J. (1982, a). Rl: a rule-based configurer of computer systems. Artificial Intelligence, 19, p. 39-88. McDermott J. (1982, b). XSEL: a computer sales person's assistant. In Machine Intelligence JO
(Hayes J. E., Michie D. and Pao Y. H., eds.), p. 325-337. Chichester, UK: Ellis Horwood. McDermott J. (1984). Building expert systems. In Artificial Intelligence Applications for Business (Reitman W., eds.). Norwood, NJ: Ablex.
McDermott J. (1988). Preliminary steps towards a taxonomy of problem solving methods. In Automating Knowledge Acquisition for Expert Systems (Marcus S., eds.), Chapter 8. Boston: Kluiver Academic. McDermott J. (1993). Rl ("XCON") at age 12: lessons from an elementary school achiever.
Artificial Intelligence, 59, p. 241-247. McDermott J. and Bachant J. (1984). Rl revisited: four years in the trenches. AI Magazine,
5(3), Fall, p. 21-32.
McDermott J. and Forgy C. L. (1978). Production system conflict resolution strategies. In Pattern Directed Inference Systems (Waterman D. A. and Hayes-Roth F., eds.), p. 177-199. New York: Academic Press.
McNeill D. and Freiberger P. (1993). Fuzzy Logic. New York: Simon and Schuster. Meltzer B. and Michie D., eds. (1969). Machine Intelligence 4. Edinburgh: Edinburgh University Press.
Meyers S. (1995). More Effective C++ : 35 New Ways to Improve Your Programs and Designs. Reading, MA: Addison-Wesley.
Meyers S. (1997). Effective C++ ; 50 Specific Ways to Improve Vom Programs and Designs, 2nd edn. Reading, MA: Addison-Wesley.
Michalski R. S. (1983). A theory and methodology of inductive learning. In Machine Learning (Michalski R. S., Carbonell J. G. and Mitchell T. M., eds.), Chapter 4. Palo Alto, CA: Tioga.
Michalski R. S., Carbonell J. G. and Mitchell T. M., eds. (1983). Machine Learning. Palo Alto, CA: Tioga.
Michalski R. S., Carbonell J. G. and Mitchell T. M, eds. (1986). Machine Learning Vol. II. Palo Alto, CA: Tioga.
Michie D., eds. (1968). Machine Intelligence 3. Edinburgh: Edinburgh University Press.
Michie D., eds. (1979). Expert Systems in the Micro-Electronic Age. Edinburgh: Edinburgh University Press.
Mingers J. (1989, a). An empirical comparison of selection measures for decision tree induction. Machine Learning, 3, p. 319-342.
Mingers J. (1989, b). An empirical comparison of pruning methods for decision tree induction. Machine Learning, 4, p. 227-243.
Minsky M., eds. (1968). Semantic Information Processing. Cambridge, MA: MIT Press. Minsky M. (1972). Computation: Finite and Infinite Machines. London: Prentice-Hall.
Minsky M. (1975). A framework for representing knowledge. In The Psychology of Computer Vision (Winston P. H., eds.) p. 211-277. New York: McGraw-Hill. (Русский перевод: Минский М. Структура для представления знания. — В сб. Психология машинного зрения. Под. ред. П. Уинстона. М.: Мир, 1978. — с. 249-338.)
Mitchell Т. М. (1978). Version Spaces: An Approach to Concept Learning. Report No. STAN-CS-78-711, Computer Science Department, Stanford University.
Mitchell Т. М. (1982). Generalization as search. Artificial Intelligence, 18, 203-226.
Mitchell Т. М. (1997). Machine Learning. New York, NY: McGraw-Hill.
Mitchell T. M., Keller R. M. and Kedar-Cabelli S. T. (1986). Explanation-based generalization:
A unifying view. Machine Learning, 1(1), p. 47-80. Moore J. D. (1995). Participating in Explanatory Dialogues. Cambridge MA: MIT Press.
Moser M. G. (1983). An Overview of NIKL, the New Implementation of KL-ONE. Technical Report No. 5421, Cambridge MA: Bolt, Beranek and Newman.
Moore J. D. and Paris C. L. (1993). Planning text for advisory dialogues: capturing intentional and rhetorical information. Computational Linguistics, 19(4), p. 651-695.
Moore J. D., Lemaire B. and Rosenblum J. A. (1996). Discourse generation for instructional applications: identifying and exploiting relevant prior explanations. Journal of the Learning Sciences, 5(1), p. 49-94.
Musen M. A. (1992). Overcoming the limitations of role-limiting methods. Knowledge Acquisition, 4(2), p. 165-170.
Musen M. A. (1989). Automated support for building and extending expert models. Machine Learning, 4(3-4), p. 347-376.
Musen M. A., Gennari J. H. and Wong W. W. (1995). A rational reconstruction of INTERNIST-I using PROTEGE-II. Knowledge Systems Laboratory, Medical Computer Science, KSL-95-46.
Neale I. M. (1988). First generation expert systems: a review of knowledge acquisition methodologies. Knowledge Engineering Review, 3(2), p. 105-145.
Neapolitan R. E. (1990). Probabilistic Reasoning in Expert Systems: Theory and Algorithms. New York: Wiley.
Neches R., Swartout W. R. and Moore J. (1985). Explainable (and maintainable) expert systems. In Proc. 9th International Joint Conference on Artificial Intelligence, p. 382-389.
Newell A. (1981). Physical symbol systems. In Perspectives on Cognitive Science (Norman D. A., eds.), Chapter 4. Norwood, NJ: Ablex.
Newell A. (1982). The knowledge level. Artificial Intelligence, 18, p. 87-127. Newell A. and Simon H. A. (1972). Human Problem Solving. Englewood-Cliffs, NJ: Prentice-Hall.
Newell A. and Simon H. A. (1976). Computer science as empirical enquiry. Communications of the Association for Computing Machinery, 19(3), p. 113-126.
Nguyen Т., Czerwinski M. and Lee D. (1993). Compaq QuickSource: Providing the consumer with the power of artificial intelligence. In Innovative Applications of Artificial Intelligence 5, Proceedings ofAAAI-93, p. 142-151. Menlo Park, CA:. AAAI Press.
Nii H. P. (1986, a). Blackboard systems (Part 1). AIMagazine, 7(2), p. 38-53. Nii H. P. (1986, b). Blackboard systems (Part 2). Al Magazine, 7(3), p. 82-106.
Nii H. P. and Aiello N. (1979). AGE (Attempt to GEneralize): a knowledge-based program for building knowledge-based programs. In Proc. 6th International Joint Conference on Artificial Intelligence, p. 645-655.
Nii H. P., Aiello N. and Rice J. (1988). Frameworks for concurrent problem solving: a report on CAGE and POLIGON. In Blackboard Systems (Englemore R. and Morgan T, eds.), Chapter 25. Reading, MA: Addison-Wesley.
Nilsson N. J. (1971). Problem Solving Methods in Artificial Intelligence. New York: McGraw-Hill. (Русский перевод: НильсонН. Искусственный интеллект. Методы поиска решений. — М.: Мир, 1973. — 265 с.)
Nilsson N. J. (1980). Principles of Artificial Intelligence. Palo Alto, CA: Tioga. (Русский перевод: НильсонН. Принципы искусственного интеллекта.— М.: Радио и связь, 1985. —376с.)
Norman D. A., eds. (1981). Perspectives on Cognitive Science. Norwood NJ: Ablex.
Norvig P. (1992). Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp. Los Altos, CA: Morgan Kaufrnann.
O'Rourke P. (1982). A Comparative Study of Two Inductive Learning Systems AQ11 and ID3 Using a Chess Endgame Test Problem. Report No. 82-2, Department of Computer Science, University of Illinois.
O'Shea T. and Eisenstadt M., eds. (1984). Artificial Intelligence: Tools, Techniques, and Applications. New York: Harper and Row.
Paterson A. and Niblett T. (1982). ACLS Manual, Version 1. Glasgow, UK: Intelligent Terminals.
Pearl J. (1982). Reverend Bayes on inference engines: a distributed hierarchical approach. In Proc. National Conference on Artificial Intelligence, p. 133-136.
Pearl J. (1984). Heuristics. Intelligent Search Strategies for Computer Problem-Solving. Reading, MA: Addison-Wesley.
Pearl J. (1986). On evidential reasoning in a hierarchy of hypotheses. Artificial Intelligence, 28, p. 9-15.
Pearl J. (1988). Probabilistic Reasoning for Intelligent Systems. Los Altos, CA: Morgan Kauf-mann.
Pearl J. (1997). Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference. Los Altos, CA: Morgan Kauftnann.
Pepper J. and Kahn G. (1987). Repair strategies in a diagnostic expert system. In Proc. 10th International Joint Conference on Artificial Intelligence, p. 531-534.
Peterson G. E., eds. (1987). Object-oriented computing, Vols 1 and 2. Washington DC: The Computer Society Press of the IEEE.
Poeson M. C. and Richardson J. (1988). Foundations of Intelligent Tutoring Systems. Hillsdale, NJ: Lawrence Erlbaum.
Pople H. E. Jr. (1977). The formation of composite hypotheses in diagnostic problem solving: an exercise in synthetic reasoning. In Proc. 5th International Joint Conference on Artificial Intelligence, p. 1030-1037.
Pople H. E. Jr. (1982). Heuristic methods for imposing structure on ill-structured problems: the structuring of medical diagnosis. In Artificial Intelligence in Medicine (Szolovits P., eds.), p. 119-190. Boulder, Co: Westview Cress.
Post E. L. (1943). Formal reductions of the general combinatorial decision problem. American
Journal of Mathematics, 65, p. 197-268. Poundstone W. (1988). Labyrinths of Reason. New York: Doubleday.
Prerau D. S. (1990). Developing and Managing Expert Systems. Reading, MA: Addison-Wesley.
Provan G. M. (1990). The application of Dempster-Shafer theory to a logic-based visual recognition system. In Uncertainty in Artificial Intelligence (Henrion M., Shachter R. D., Ka-nal L. N. and Lemmer J. E., eds.), p. 389^405. Amsterdam: North Holland.
Puerta A. R., Neches R., Eriksson H., Szeleky P., Luo P. and Musen M. A. (1994). Toward ontology-based frameworks for knowledge acquisition tools. In Proc. 8th Banff Knowledge-Based Systems Workshop, 26, p. 1-14.
Quillian M. R. (1968). Semantic memory. In Semantic Information Processing (Minsky M., eds.), p. 227-270. Cambridge, MA: MIT Press.
Quine W. V. O. (1979). Methods of Logic. London: Routledge Kegan Paul.
Quinlan J. R. (1979). Discovering rules from large collections of examples: a case study. In Expert Systems in the Micro-Electronic Age (Michie D., eds.), p. 168-201. Edinburgh: Edinburgh University Press.
Quinlan J. R. (1983). Learning efficient classification procedures and their application to chess endgames. In Machine Learning (Michalski A. S., Carbonell J. G. and Mitchell Т. М, eds.). Chapter 15. Palo Alto, С A: Tioga.
Quinlan J. R. (1986, a). Induction of decision trees. Machine Learning, 1, p. 81-106.
Quinlan J. R. (1986, b). The effect of noise on concept learning. In Machine Learning Vol. II (Michalski R. S., Carbonell J. G. and Mitchell T. M., eds.). Chapter 6. Palo Alto, CA: Tioga.
Quinlan J. R., eds. (1987). Applications of Expert Systems. Sydney: Addison-Wesley.
Quinlan J. R, (1993). C4.5: Programs for Machine Learning. San Mateo, CA: Morgan Kauf-mann.
Raphael B. (1976). The Thinking Computer: Mind inside Matter. San Francisco: W. H. Freeman.
Rayward-Smith V. J. (1994). Applications of Modern Heuristic Methods. Alfred Waller.
Rayward-Smith V. J., Osman I. H. and Reeves C. R., eds. (1996). Modern Heuristic Search Methods. New York: Wiley.
Reichgelt H. and van Harmelen E. (1986). Criteria for choosing representation languages and control regimes for expert systems. Knowledge Engineering Review, 1(4), p. 2-17.
Reitman W., eds. (1984). Artificial Intelligence Applications for Business. Norwood, NJ: Ablex.
Reynolds D. (1988). MUSE: a toolkit for embedded, real-time, AI. In Blackboard Systems (Englemore R. and Morgan Т., eds.), Chapter 27. Reading, MA: Addison-Wesley.
Rice J. (1986). POLIGON: A System for Parallel Problem Solving. Technical Report No. KSL-86-19, Knowledge Systems Laboratory, Stanford University.
Rice J. (1989). The advanced architectures project. AI Magazine, 10(4), p. 26-39. Rich E. and Knight K. (1991). Artificial Intelligence. New York: McGraw-Hill.
Richer M. H. and Clancey W. J. (1985). A graphic interface for viewing a knowledge based system. IEEE Computer Graphics and Applications, 5(11), p. 51-64.
Rine D. C., eds. (1975). Computer Science and Multiple-Valued Logic Theory and Applications. Amsterdam: North-Holland.
Rissland E. L., Daniels J. J., Rubinstein Z. B. and Skalak D. B. (1993). Case-based diagnostic analysis in a blackboard architecture. In Proc. llth National Conference on Artificial Intelligence, p. 66-72.
Robinson J. A. (1965). A machine-oriented logic based on the resolution principle. Journal of the Association for Computing Machinery, 12, p. 23-41. (Русский перевод: Робинсон Дж. Машинно-ориентированная логика, основанная на принципе резолюции. — В кн. Кибернетический сборник, вып. 7, 1970, — с. 194-218.)
Robinson J. A. (1979). Logic: Form and Function. Edinburgh: Edinburgh University Press.
Robinson V., Hardy N. W, Barnes D. P., Pace C. J. and Lee M. H. (1987). Experiences with a knowledge engineering toolkit: an assessment in industrial robotics. Knowledge Engineering Review, 2(1), p. 43-54.
Rose D. E. (1994). A Symbolic and Connectionist Approach to Legal Information Retrieval. Hillsdale, NJ: Lawrence Erlbaum.
Rosenman M. A., Coyne R. D. and Gero I. S. (1987). Expert systems for design applications. In Applications of Expert Systems (Quinlan J. R., eds.). Chapter 4. Sydney: Addison-Wesley.
Rothenfluh T. E., Gennari J. H., Eriksson H., Puerto A. R., Tu S. W. and MusenM. A. (1994). Reusable ontologies, knowledge acquisition tools, and performance systems: PROTOGE-II solutions to Sisyphus-2. In Proc. 8th Banff Knowledge-Based Systems Workshop, 43, p. 1-30.
Rumelhart D. E. (1988). Parallel Distributed Processing: Explorations in the Microstructure of Cognition. Cambridge, MA: MIT Press.
Rumelhart D. E. and McClelland J. L. (1986) Parallel Distributed Processing: Explorations in the Microstructure of Cognition: Foundations. Cambridge, MA: MIT Press.
Russell S. J. and Norvig P. (1995). Artificial Intelligence: A Modern Approach. Englewood Cliffs, NJ: Prentice-Hall.
Sacerdoti E. D. (1974). A Structure for Plans and Behavior. Amsterdam: Elsevier North-Holland.
Sandewall E. (1986). Nonmonotonic inference rules for multiple inheritance with exceptions. In
Proc. IEEE, 74, p. 81-132. Sanford A. J. (1987). The Mind of Man: Models of Human Understanding. Brighton: Harvester
Press.
Schach S. R. (1993). Software Engineering. Richard D. Irwin.
Schank R. C. (1975). Conceptual Information Processing. Amsterdam: North-Holland.
Schank R. C. and Abelson R. (1977). Scripts, Plans, Goals and Understanding. Hillsdale, NJ: Lawrence Erlbaum.
Schank R. C. and Colby K., eds. (1973). Computer Models of Thought and Language. New York: W. H. Freeman.
Schmolze J. G. (1991). Guaranteeing serializable results in synchronous parallel production systems. Journal of Parallel and Distributed Computing, 13(4), p. 348-365.
Schreiber A. Th., Wielinga B. J. and Breuker J. A., eds. (1993). KADS: A Principled Approach to Knowledge-Based System Development. London: Academic Press.
Schubert L. K. (1976). Extending the expressive power of semantic networks. Artificial Intelligence, 1, p. 163-198.
Selman B. and Levesque H. J. (1989). The tractability of path-based inheritance. In Proc. llth International Joint Conference on Artificial Intelligence, p. 1140—1145.
Shafer G. (1976). A Mathematical Theory of Evidence. Princeton NJ: Princeton University Press.
Shafer G. and Pearl J. (1990). Readings in Uncertain Reasoning. Los Altos, CA: Morgan Kauffman.
Shafer G. and Tversky A. (1985). Languages and designs for probability judgment. Cognitive Science, 9, p. 309-339.
Shannon С. Е. (1950). Automatic chess player. Scientific American, 182(48). (Русский перевод: Шеннон К. Работы по теории информации и кибернетике. — М.: ИЛ., 1963.)
Shepherdson J. С. (1984). Negation as Failure. Journal of Logic Programming, 1, p. 51-81.
Shepherdson J. C. (1985). Negation as Failure II. Journal of Logic Programming, 3, p. 185-202.
Shortliffe E. H. (1976). Computer-Based Medical Consultations: MYCIN. New York: Elsevier.
Shortliffe E. H., Scott A. C, Bischoff M. В., van Melle W. and Jacobs C. D. (1981). ONCOCIN: an expert system for oncology protocol management In Proc. 7th International Joint Conference on Artificial Intelligence, p. 876-881.
Sime M. E. and Coombs M. J., eds. (1983). Designing for Human Computer Communication. London: Academic Press.
Simon H. A. (1983). Why should machines learn? In Machine Learning (Michalski R. S., Car-bonell J. G. and Mitchell T. M., eds.), Chapter 2. Palo Alto, CA: Tioga.
Slade S. (1991). Case-based reasoning: A research paradigm. Al Magazine, 12(1), Spring, p. 42-55.
Sleeman D. and Brown J. S., eds. (1982). Intelligent Tutoring Systems. London: Academic Press.
Smith B. C. (1982). Reflection and Semantics in a Procedural Language. MIT-TR-272, Massachusetts Institute of Technology. Also in Readings in Knowledge Representation (Brachman R. J. and Levesque H. J., eds.), 1985. Los Altos, CA: Morgan Kaufmann.
Smith R. G., Winston H. A., Mitchell T. and Buchanan B. G. (1985). Representation and use of explicit justifications for knowledge base refinement. In Proc. 9th International Joint Conference on Artificial Intelligence, p. 673-680.
Smullyan R. (1978). What Is the Name of this Book? New York: Simon and Schuster.
Stefik M. (1979). An examination of a frame-structured representation system. In Proc. 6th International Joint Conference on Artificial Intelligence, p. 845-852.
Stefik M. (1981, a). Planning with constraints. Artificial Intelligence, 16, p. 111-140. Stefik M. (1981, b). Planning and meta-planm'ng. Artificial Intelligence, 16, p. 141-169. Stefik M. (1995). Introduction to Knowledge Systems. San Francisco, CA: Morgan Kaufmann.
Stefik M. and Bobrow D. G. (1986). Object-oriented programming: themes and variations. Al Magazine, 6(4), p. 40-62.
Stefik M., Aikins J., Balzer R., Benoit J., Bimbaum L,, Hayes-Roth F. and Sacerdoti E. (1983). The architecture of expert Systems. In Building Expert Systems (Hayes-Roth F., Waterman D. A. and Lenat D., eds.). Chapter 4. Reading, MA: Addison-Wesley.
Sterling L. and Shapiro E. (1994). The Art of Prolog, 2nd edn. Cambridge, MA: MIT Press. (Русский перевод первого издания: Стерлинг Л., Шапиро Э. Искусство программирования на языке ПРОЛОГ. — М.: Мир, 1990.)
Stroustrup В. (1997). The C++ Programming Language, 3rd ed. Reading, MA: Addison-Wesley.
Studer R., Benjamins V. R. and Fensel D. (1998). Knowledge Engineering: Principles and Methods. Data and Knowledge Engineering, 25(1, 2), p. 161-198.
Sussman G. J. (1975). A Computer Model of Skill Acquisition. New York: American Elsevier.
Suwa W., Scott A. C. and Shortliffe E. H. (1982). An approach to verifying completeness and consistency in a rule-based expert system. Al Magazine, 3(4), p. 16-21.
Swartout W. R. (1983). XPLAIN: a system for creating and explaining expert consulting programs. Artificial Intelligence, 21, p. 285-325.
Szolovits P., eds. (1982). Artificial Intelligence in Medicine. Boulder, CO: Westview Press.
Tate A. (1977). Generating project networks. In Proc. 5th International Joint Conference on Artificial Intelligence, p. 888-893.
Teknowledge (1985). S.I. Reference Manual. Palo Alto, CA: Teknowledge.
Thomason R. (1992). NETL and subsequent path-based inheritance theories. Computers Math. Applic., 23 (2-5), p. 179-204.
Tommelein I. D., Johnson M. V., Hayes-Roth B. and Levitt R. E. (1987). SIGHTPLAN— a blackboard expert system for the layout of temporary facilities on a construction site. In Proc. IFIP WG5.2 Working Conference on Expert Systems in Computer-Aided Design, Sydney, Australia.
Touretzky D. S. (1986). The Mathematics of Inheritance Systems. London: Pitman.
Touretzky D. S., Horty J. F. and Thomason R. H. (1987). A clash of intuitions: the current state of nonmonotonic multiple inheritance systems. In Proc. 10th International Joint Conference on Artificial Intelligence, p. 476-482.
Tu S. W., Eriksson H., German J., Shahar Y. and Musen M. A. (1995). Ontology-based configuration of problem-solving methods and generation of knowledge-acquisition tools: application of PROTEGE-II to protocol-based decision support. Artificial Intelligence in Medicine, 1, p. 257-289.
Tversky A. and Kahneman D. (1974). Judgment under uncertainty: Heuristics and biases. Science, September. Also in Readings in Uncertain Reasoning (Shafer G. and Pearl J., eds.), 1990. Los Altos, CA: Morgan Kaufrnarm.
van Lamsweerde A. and Dufour P., eds. (1987). Current Issues in Expert Systems. London: Academic Press.
van Melle W. J. (1981). System Aids in Constructing Consultation Programs. Ann Arbor MI: UMI Research Press.
von Luck K. and Marburger H., eds. (1994). Management and Processing of Complex Data Structures, Third Workshop on Information Systems and Artificial Intelligence, Proceedings. Lecture Notes in Computer Science Vol. 777. Berlin: Springer Verlag.
Walker E. A. and Nguyen H. T. (1996). A First Course in Fuzzy Logic. Boca Raton, FL: CRC Press.
Ward R. D. and Sleeman D. (1987). Learning to use the S.I knowledge engineering tool. Knowledge Engineering Review, 2(4), p. 265-276.
Waterman D. A. (1986). A Guide to Expert Systems. Reading, MA: Addison-Wesley. (Русский перевод: Уотермен Д. Руководство по экспертным системам. —М.: Мир, 1989.)
Waterman D. A. and Hayes-Roth F. (1978). Pattern Directed Inference Systems. New York: Academic Press.
Watson I. (1995). Progress in Case-Based Reasoning. Lecture Notes in Artificial Intelligence, 1020. Berlin: Springer-Verlag.
Watson I. and Marir F. (1994). Case-Based Reasoning: A Review. The Knowledge Engineering Review, 9 (4), p. 355-381.
Weiss S, M. and Kulikowski C. A. (1983). A Practical Guide to Designing Expert Systems. London: Chapman and Hall.
Wielinga B. J. and Breuker J. A. (1986). Models of expertise. In Proc. 7th European Conference on Artificial Intelligence, p. 306-318.
Wielinga B. J. and Schreiber A. Th. (1994). Conceptual modelling of large reusable knowledge bases. In Management and Processing of Complex Data Structures, Third Workshop on Information Systems and Artificial Intelligence, Proceedings (von Luck K. and Mar-burger H., eds.), p. 181-200. Lecture Notes in Computer Science, Vol. 777. Berlin: Springer Verlag.
Wielinga B. J., Schreiber A. Th. and Breuker J. A. (1992). KADS: A modelling approach to knowledge engineering. Knowledge Acquisition, 4(1), p. 5-53. Special issue: The KADS approach to knowledge engineering. Reprinted in Readings in Knowledge Acquisition and Learning (Buchanan B. G. and WilkinsD. G., eds.), 1992. Los Altos, CA: Morgan Kauf-mann.
Wilkins D. C. (1988). Knowledge base refinement using apprenticeship learning techniques. In Proc. National Conference on Artificial Intelligence, p. 646-651.
Wilkins D. C. (1990). Knowledge base refinement as improving an incomplete and incorrect domain theory. In Machine Learning: An Artificial Intelligence Approach, Vol. Ill (Kodratoff Y. and Michalski R. S., eds.), p. 493-514. Los Altos, .CA: Morgan Kaufmann.
Wilkins D. C. and Buchanan B. G. (1986). On debugging rule sets when reasoning under certainty. In Proc. National Conference on Artificial Intelligence, p. 448—454.
Winograd T. (1972). Understanding natural language. Cognitive Psychology, 1, p. 1-191. (Русский перевод первого издания: Виноград Т. Программа, понимающая естественный язык. — М.: Мир, 1976.)
Winograd Т. (1975). Frame representations and the declarative/procedural controversy. In Representation and Understanding (Bobrow D. G. and Collins A., eds.). New York: Academic Press.
Winston P. H. (1975, a). Learning structural descriptions from examples. In The Psychology of Computer Vision (Winston P. H., eds.), Chapter 5. New York: McGraw-Hill.
Winston P. H., eds. (1975, b). The Psychology of Computer Vision. New York: McGraw-Hill. Winston P. H. (1982). Learning new principles from precedents and examples. Artificial Intelligence, 19, p. 321-350.
Winston P. H. (1984). Artificial Intelligence. Reading, MA: Addison-Wesley Winston P. H. (1992). Artificial Intelligence, 3rd edn. Reading, MA: Addison-Wesley. (Русский перевод первого издания: Уинстон П. Искусственный интеллект. — М.: Мир, 1980. — 519с.)
Winston P. H. and Brown R. H. (1979). Artificial Intelligence: An MIT Perspective, Vols 1 and 2. Cambridge, MA: MIT Press.
Winston P. H. and Horn K. P. (1981). LISP. Reading, MA: Addison-Wesley. Winston P. H. and Horn K. P. (1984). LISP, 2nd ed. Reading, MA: Addison-Wesley. Winston P. H. and Horn K. P. (1988). LISP, 3rd ed. Reading, MA: Addison-Wesley.
Winston P. H. and Shellard S. A. (1990). Artificial Intelligence at MIT: Expanding Frontiers, Vols 1 and 2. Cambridge, MA: MIT Press.
Wise B. P. and Henrion M. (1986). A framework for comparing uncertain inference systems to probability. In Uncertainty in Artificial Intelligence (Kanal L. N. and Lemmer J. F., eds.) p. 69-83. Amsterdam: North-Holland.
Woods W. (1975). What's in a link: Foundations for semantic networks. In Representation and Understanding (Bobrow D. G. and Collins A., eds.). New York: Academic Press.
Yager R. R. and Filev D. P. (1994). Essentials of Fuzzy Modeling and Control. New York: Wiley.
Yen J. (1986). A reasoning model based on an extended Dempster-Shafer theory. In Proc National Conference on Artificial Intelligence, p. 125-131. Yen J., Juang H. and MacGregor R. (1991, a). Using polymorphism to improve expert system maintainability. IEEE Expert, April. Yen J., Neches R. and MacGregor R. (1991, b). CLASP: Integrating term subsumption systems and production systems. In IEEE Transactions on Knowledge and Data Engineering, 3, 1, March.
Zadeh L. A. (1965). Fuzzy sets. Information and Control, 8, p. 338-353. Zadeh L. A. (1975). Fuzzy logic and approximate reasoning. Synthese, 30, p. 407-428. Zadeh L. A. (1978). Fuzzy sets as a basis for a theory of possibility. Fuzzy Sets and Systems 1, p. 3-28. Zadeh L. A. (1981). PUF — a meaning representation language for natural languages. In Fuzzy
Reasoning and its Applications (Mamdani E. H. and Gaines B. D., eds.), p. 1-66. London:
Academic Press.
