Методы проектирования баз знания
8. МЕТОДЫ ПРОЕКТИРОВАНИЯ БАЗ ЗНАНИЙ
В настоящее время основным «узким местом» при проектировании баз знаний экспертных систем является приобретение необходимых знаний для экспертной системы. Знания о ПО можно взять из разных источников (научные отчеты, монографии, статьи, базы данных, опытные данные и т. п., а также личный опыт эксперта-профессионала). Работа по сбору и обработке знаний выполняется специалистом — инженером по знаниям. Обычно большую часть профессиональных знаний инженер по знаниям получает в результате взаимодействия с экспертом. К настоящему времени уже сформировался ряд методов проектирования баз знаний, ориентированных на получение информации от экспертов. Рассмотрим их.
Беседы с экспертом. В данной группе методов различают наблюдательный и интуитивный подходы.
При наблюдательном подходе следят за работой эксперта, стараясь не сделать ничего, что могло бы повлиять на работу эксперта при решении задачи. За наблюдением следует этап уточнения. На этапе уточнения инженер по знаниям совместно с экспертом анализируют запись сеанса работы эксперта, выполненную наблюдателем. Такой подход еще называют «анализом протоколов».
При интуитивном подходе эксперт выступает как разработчик модели своего поведения при решении задач. Второй вариант — инженер по знаниям изучает литературу и другие источники информации, разрабатывает представление знаний о ПО и затем проверяет их достоверность с экспертами.
Инженер по знаниям использует обычно оба эти подхода, сочетая их методом интервью — беседы с экспертами.
Обсуждение задач. Инженер по знаниям подготавливает некоторый набор задач и затем в свободной обстановке обсуждает их с экспертом, стараясь определить, как организованы знания эксперта об этих задачах, какими понятиями и гипотезами по ПО он руководствуется в своей работе, как работает с неполными, неточными либо противоречивыми данными по той или иной задаче.
Описание задачи. Эксперт подготавливает описание типичных задач по ПО. Это метод очень хорошо работает на задачах диагностического типа.
Анализ задач. Инженер по знаниям подготавливает несколько задач, близких к реальным, и просит эксперта решить их цель — выявить стратегию, которой пользуется эксперт при решении задачи. При этом используются рассуждения вслух, работающие стремятся выделить как можно больше промежуточных шагов решения, проанализировать их, преследуя основную цель.
Рекомендуемые материалы
Оценивание системы. Эксперт анализирует и критически оценивает правила, введенные в базу знаний экспертной системы. Анализирует стратегии выбора правил системой при решении задач, рассматривает обоснованность их применения, постоянно сравнивая их со своими методами решения задач.
Проверка системы. Инженер по знаниям представляет задачи и результаты их решения, выполненные как экспертом, так и прототипом создаваемой системы, другим экспертам. Цель - выявление элементов, вызывающих разногласия.
Кроме названных существует еще целый ряд практических методов, используемых при проектировании базы знаний на данном этапе.
Полученные от эксперта и из других источников знания необходимо зафиксировать в виде концептуальной базы знаний первого варианта системы. Для этого выполняется следующая спецификация выявленных знаний:
1. Цели и задачи разрабатываемой экспертной системы.
2. По каждой задаче специфицировать входные данные и что требуется получить в результате решения, стратегии решения, гипотезы, которые используются в процессе решения.
Специфицировать объекты (события) ПО, отношения и атрибуты.
Специфицировать причинно-следственные, родовидовые отношения, отношения типа «часть — целое».
По каждой задаче классифицировать знания на необходимые для получения решения и необходимые для обоснования полученного решения.
Рекомендуем посмотреть лекцию "Вещества вторичного синтеза".
Отметим, что процесс концептуализации знаний — итерационный процесс.
Далее выполняется процесс формализации концептуальных знаний, в результате которого получают формальное описание базы знаний. С этой целью инженер по знаниям, консультируясь с экспертами, выбирает модель представления знаний, соответствующую рассматриваемой проблеме, и оболочку экспертной системы, поддерживающую эту модель. На входном языке системы выполняется описание концептуальных знаний.
Однако полученная на этом этапе база знаний не гарантирует работоспособность системы (первый вариант является макетом будущей системы), поскольку обязательно будут иметь место различные несоответствия: между какими-либо правилами и стратегией управления процессом получения решения, между структурами данных. Эти противоречия и несоответствия должны быть устранены.
На стадии отладки и тестирования полученного прототипа будущей системы выполняется проверка его работоспособности на разнородных примерах. Оценить работу экспертной системы трудно по той причине, что в подавляющем большинстве случаев не существует формального способа доказательства полученного системой решения. Кроме того, зачастую пользователю требуются не самые точные решения, а наиболее полезные с его точки зрения. Поэтому при проектировании системы необходимо учитывать интересы будущих пользователей и включать их как экспертов в процессе проектирования системы. Далее, с ростом объема базы знаний (когда число правил достигает нескольких сотен) добавление новых правил или исправление существующих зачастую приводит к появлению новых ошибок, количество которых сравнимо с устраняемыми ошибками. Отладка и тестирование выполняются с использованием контрольного набора задач, который желательно прогонять после каждого вносимого важного изменения в базе знаний ив стратегии управления процессом решения задач. Помимо отладки на контрольном наборе задач используется прием регистрации при функционировании системы тех правил, которые приводят к конкретным заключениям. Затем выполняется анализ результатов регистрации. Неиспользуемые правила указывают либо на неверные предпосылки в правилах, либо на ошибки в используемых стратегиях управления процессом решения задач.
В процессе проектирования и создания экспертной системы в нее постоянно вносятся различные изменения с целью ее отладки и усовершенствования. Это итерационный процесс, в результате которого и должна быть получена промышленная версия экспертной системы.
Если окажется, что многократные внесения изменений и усовершенствований не приводят к улучшению работы экспертной системы, то это служит сигналом о необходимости пересмотра структуры и состава знаний в базе, стратегий управления процессом решения задач.
