17.5. Некоторые максимы разработки экспертных систем
Чтобы не заканчивать эту главу на такой печальной ноте, я решил включить в последний раздел избранные максимы о построении экспертных систем, почерпнутые из классической работы Бучанана [Buchanan et al., 1983]. Следование им избавит проектировщика экспертных систем от опасности "наступить на грабли", многократно "опробованной" его коллегами. Другим прекрасным источником умных мыслей по тому же поводу может служить книга Преро [Ргегаи, 1990].
Нежизнеспособность некоторых проектов закладывается еще на самых ранних стадиях работы над ними. Приведенные ниже рекомендации помогут избежать этого.
- Задача, которую предполагается решать с помощью проектируемой системы, должна быть вполне под силу эксперту-человеку.
- Задача должна быть четко сформулирована.
- Уже на первой стадии работы над системой подумайте над тем, как она будет совершенствоваться.
Особенно важно с самого начала очертить границы, которых должна достичь система в процессе эволюции. Для этого весьма полезно четко определить, что система не сможет делать. Лучше создать систему, которая сможет надежно решать ограниченную задачу, чем систему, претендующую на решение широкого класса задач, но дающую верное решение лишь время от времени. Конечно, надежность системы, т.е. степень ее правоты, можно оценить, только располагая соответствующим критерием этой самой правоты.
- Тщательно отработайте поведение системы на наборе репрезентативных частных случаев и организуйте библиотеку таких случаев для проектируемой системы.
- Отделите те знания, которые специфичны для определенной предметной области, от знаний, касающихся общей методики решения проблем. Старайтесь, насколько это возможно, упростить машину логического вывода в системе.
Убедитесь, что те примеры, которыми вы располагаете на этапе проектирования, репрезентативны. С самого начала постарайтесь либо самостоятельно разработать, либо заимствовать программный код, который упростит опробование принятых проектных концепций на этих примерах. Большую помощь в этом может оказать программная среда, которая позволяет подробно документировать сеанс работы с такой экспериментальной системой, включая и фиксацию всех вводимых пользователем данных. Проблема разделения различных видов знаний довольно подробно освещалась в главах 10, 11 и 16.
В отношении формулировки правил авторы упомянутых работ советуют следующее.
- Если правило выглядит большим, то так оно и есть.
- Если несколько правил очень похожи друг на друга, обратите внимание на те концепты проблемной области, на которых они базируются.
Как и при программировании задач общего назначения, следуйте золотому правилу "краткость — залог надежности". Наличие избыточности почти всегда является признаком того, что возможна какая-то упрощающая абстракция.
У Преро вы встретите и рекомендации, касающиеся этапа реализации экспертной системы. Ниже приведены некоторые из них.
- Группируйте правила в отдельные множества.
В системе COMPASS все правила разделены на 18 групп. Только семь из них относятся действительно к процессу решения проблем, т.е. к тому, чем в обычной "бескомпьютерной" жизни занимается эксперт, а остальные обеспечивают выполнение функций поддержки, сбора данных и т.п. В системе используются также демоны, которые расширяют возможности выполнения действий, в частности организуя передачу сообщений между объектами (см. о демонах в главе 6).
- Постарайтесь на самых ранних стадиях разработать систему соглашений об оформлении программы. Это придаст ей единообразный вид.
Как уже отмечалось выше, многие программисты, попав в ситуацию, когда можно использовать множество парадигм программирования, забывают о необходимости (или желательности) разрабатывать структурированный программный код. Единственный способ избежать этого — стараться реализовать похожие функции похожими методами во всех компонентах программного кода и оформлять их в едином стиле. Тогда, увидев в каком-либо модуле такой фрагмент кода, программист сможет легко распознать применяемый в данном фрагменте метод или подход. Особенно важно следовать этой рекомендации при разработке отдельных модулей базы данных или индивидуальных баз данных.
- Пожертвуйте производительностью программы, если это сделает ее более понятной (в том числе и в смысле читабельности программного кода) и упростит сопровождение.
Программисты часто состязаются друг с другом, кто придумает более "сжатый" код, разобраться в котором постороннему зачастую просто невозможно. От такого кода в подавляющем большинстве экспертных систем нет никакого проку, поскольку в интерактивных консультирующих системах все равно большая часть времени уходит на диалог с пользователем и обращение к базам данных.
Бучанан также останавливается на проблеме разработки системы-прототипа, называя его условно системой Mark I. Он советует заняться разработкой такого прототипа, как только станут понятными два-три типовых примера (типовых задачи) для проектируемой экспертной системы. Однако действительным самородком в наборе советов является следующий.
- Как только встанет вопрос о разработке второго прототипа, выбросите первый в мусорную корзину.
Многие проекты "пошли ко дну" лишь потому, что их авторы не могли избавиться от приверженности к первому варианту реализации собственных идей. В связи с этим возникает и такой вопрос, а когда имеет смысл прекратить отработку первого прототипа. Программисты часто впадают в состояние бесконечного "вылизывания" программного кода, которому все равно уже уготовано место на свалке. Конечно, при разработке второго прототипа нужно учитывать опыт создания первого, но опыт, а не программный код.
- Процесс проектирования экспертной системы неразрывно связан с экспериментированием.
Этот принцип не утратил своей актуальности и на сегодняшний день. Тех, кто, прочитав какую-нибудь брошюру под броским названием "Экспертная система за NN часов", доверят ее проектирование первому встречному, ожидает горькое разочарование. Разработка приложения, которое будет успешно работать, требует настойчивости и терпения профессионального программиста, привлечения к работе опытного эксперта в своей области и определенного уровня принуждения со стороны руководства.
