4. Тестирование экспертной системы

Построенные ЭС оцениваются с позиции двух основных групп критериев – точности (правильности) работы и полезности. С точностью связаны такие характеристики, как правильность делаемых заключений, адекватность БЗ проблемной области, соответствие методов решения проблем экспертным. Поэтому конечные оценки системе ставят специалисты в проблемной области – эксперты.

Полезность ЭС характеризуется удовлетворением требований пользователей в части получения необходимых рекомендаций, легкости и естественности взаимодействия с системой, надежности, производительности и стоимостных затрат, способности объяснения решения и обучения, настройки на изменения потребностей. Полезность обычно оценивается пользователем-прикладником.

Тестирование ЭС проводится на всех этапах жизненного цикла ее создания. Причем, критерии оценки системы необходимо определить еще на этапе идентификации проблемной области.

Создание работающей версии ЭС рассматривается как итерационный процесс, в течение которого неоднократно осуществляется процесс решения тестовых примеров, оценка их со стороны экспертов, пробная эксплуатация заинтересованными пользователями и перестройка системы с учетом поступающих критических замечаний. Для качественного проведения испытаний очень важно подобрать тестовые примеры, которые бы представляли собой типично решаемые задачи и проверяли бы все возможные граничные значения получаемых результатов, а также работали в условиях нечеткости и неопределенности. Лучше всего в качестве таких примеров использовать задачи, которые раньше решались экспертами и по которым есть апробированные эталонные результаты. В этом случае, если по некоторым задачам такого накопленного опыта решений нет, то устанавливаемая степень точности экспертизы со стороны экспертов всегда будет иметь субъективный фактор. Чтобы преодолеть предвзятость отношений экспертов к автоматизированной системе, имеет смысл давать ее решения вместе с результатами, полученными другими специалистами.

После того, как ЭС начнет успешно справляться с определенным набором тестовых примеров, необходимо провести статистическое изучение экспертами функционирования системы на случайном наборе задач и определить степень точности экспертизы, т.е. отношения числа правильно полученных результатов к общему числу решенных задач.

Показатель точности имеет относительный характер и к его оценке нужно подходить реалистически. В случае неточности экспертизы приходится пересматривать проектные решения, детально анализировать работу механизмов вывода и сформированную базу знаний. Не менее важно организовывать статистическое исследование эксплуатации ЭС со стороны пользователей, оценку их удовлетворенности в интерфейсе системы, во времени реакции после того, как компетентность системы достигла необходимого уровня. В результате такого изучения могут возникнуть также потребности в перестройке архитектуры ЭС.

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

Наконец, последняя стадия – это оформление экспертной системы в виде коммерческого товара, и тогда уже рынок, в конечном счете, определяет качество созданного продукта.

В случае некачественного выполнения необходимых функций ЭС необходимо анализировать ход решения задачи, для чего инженерам и экспертам предоставляется ряд сервисных средств (трассировка, семантический анализ и т.д.), к которым, в частности, относится ретроспективный (выдается цепочка выполненного вывода) режим объяснения.

Для этого в GURU используются в основном две команды: «HOW» (как?), описывающая полученный результат и применяемые к нему правила, и «WHY» (почему?), объясняющая причину выполнения правила, т.е. аргументы его посылки. Комбинируя эти команды, можно получить всю цепочку вывода от полученного значения целевой переменной до исходных данных.

Пример тестирования приведен в приложении 1 (листинг 2).

Последовательность объяснения применяемых правил можно представить в виде процедуры, в которой организуется цикл на число выполненных правил, зафиксированных в утилитной переменной #HCNT. При этом запрашивается объяснение, почему (WHY) выполнено каждое правило, номер которого хранится в списке, содержащемся в утилитной переменной #HOW. Недостаток этой процедуры заключается в том, что в случае неудачи экспертизы целевая переменная остается неизвестной (получает значение UNKNOWN), а утилитные переменные #HCNT и #HOW имеют пустые значения, т.е. объяснение становится невозможным.

Для преодоления этого недостатка GURU предоставляет средство трассировки, включаемое системной переменной E.TRAC = TRUE. B этом случае процесс вывода сопровождается сообщениями о рассмотренных (attempting) и выполненных (firing) правилах с указанием их имен. Однако никакие сообщения о причинах и результатах выполнения правил не приводятся, и разработчик вынужден самостоятельно заполнять этот пробел. С этой точки зрения GURU не обладает сильными средствами объяснения и трассировки. Нет также средств, обеспечиваю­щих контрольные точки для прерываний. Сбор статистики, кроме запоминания в ути­лит­ной переменной #HOW списка номеров выполненных правил, отсутствует. Ре­дак­тор ввода не обладает средствами семантического анализа проводимых кор­рек­ти­ро­вок на соответствие имеющейся базе знаний, и нет средств самообучения.

Процесс тестирования ЭС продолжается до тех пор, пока не будут исправлены все дефекты и пользователь не получит надежный инструмент, которому он полностью доверяет и который по уровню компетентности не уступает в рассматриваемой проблемной области эксперту.