8.3. Методы проектирования баз знаний

В настоящее время основным «узким местом» при проектирова­нии баз знаний экспертных систем является приобретение необхо­димых знаний для экспертной системы. Знания о ПО можно взять из разных источников (научные отчеты, монографии, статьи, базы данных, опытные данные и т. п., а также личный опыт эксперта-профессионала). Работа по сбору и обработке знаний выполняется специалистом — инженером по знаниям. Обычно большую часть профессиональных знаний инженер по знаниям получает в резуль­тате взаимодействия с экспертом. К настоящему времени уже сформировался ряд методов проектирования баз знаний, ориенти­рованных на получение информации от экспертов. Рассмотрим их.

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

При наблюдательном подходе следят за работой эксперта, стараясь не сделать ничего, что могло бы повлиять на работу эксперта при решении задачи. За наблюдением следует этап уточнения. На этапе уточнения инженер по знаниям совмест­но с экспертом анализируют запись сеанса работы эксперта, выполненную наблюдателем. Такой подход еще называют «анали­зом протоколов».

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

Инженер по знаниям использует обычно оба эти подхода, соче­тая их методом интервью — беседы с экспертами.

Обсуждение задач. Инженер по знаниям подготавливает неко­торый набор задач и затем в свободной обстановке обсуждает их с экспертом, стараясь определить, как организованы знания эксперта об этих задачах, какими понятиями и гипотезами по ПО он руководствуется в своей работе, как работает с неполными, неточными либо противоречивыми данными по той или иной за­даче.

Описание задачи. Эксперт подготавливает описание типичных задач по ПО. Это метод очень хорошо работает на задачах диаг­ностического типа.

Анализ задач. Инженер по знаниям подготавливает несколько задач, близких к реальным, и просит эксперта решить их цель — выявить стратегию, которой пользуется эксперт при реше­нии задачи. При этом используются рассуждения вслух, работаю­щие стремятся выделить как можно больше промежуточных шагов решения, проанализировать их, преследуя основную цель.

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

Проверка системы. Инженер по знаниям представляет задачи и результаты их решения, выполненные как экспертом, так и прототипом создаваемой системы, другим экспертам. Цель - выявление элементов, вызывающих разногласия.

Кроме названных существует еще целый ряд практических методов, используемых при проектировании базы знаний на дан­ном этапе.

Полученные от эксперта и из других источников знания необ­ходимо зафиксировать в виде концептуальной базы знаний первого варианта системы. Для этого выполняется следующая спецификация выявленных знаний:

1. Цели и задачи разрабатываемой экспертной системы.

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

Специфицировать объекты (события) ПО, отношения и атри­буты.

Специфицировать причинно-следственные, родовидовые от­ношения, отношения типа «часть — целое».

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

Отметим, что процесс концептуализации знаний — итерацион­ный процесс.

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

Однако полученная на этом этапе база знаний не гарантирует работоспособность системы (первый вариант является макетом будущей системы), поскольку обязательно будут иметь место различные несоответствия: между какими-либо правилами и стра­тегией управления процессом получения решения, между структурами данных. Эти противоречия и несоответствия должны быть устранены.

На стадии отладки и тестирования полученного прототипа будущей системы выполняется проверка его работоспособности на разнородных примерах. Оценить работу экспертной системы трудно по той причине, что в подавляющем большинстве случаев не существует формального способа доказательства полученного системой решения. Кроме того, зачастую пользователю требуются не самые точные решения, а наиболее полезные с его точки зрения. Поэтому при проектировании системы необходимо учитывать интересы будущих пользователей и включать их как экспертов в процессе проектирования системы. Далее, с ростом объема базы знаний (когда число правил достигает нескольких сотен) добав­ление новых правил или исправление существующих зачастую приводит к появлению новых ошибок, количество которых срав­нимо с устраняемыми ошибками. Отладка и тестирование выпол­няются с использованием контрольного набора задач, который желательно прогонять после каждого вносимого важного изме­нения в базе знаний ив стратегии управления процессом реше­ния задач. Помимо отладки на контрольном наборе задач исполь­зуется прием регистрации при функционировании системы тех правил, которые приводят к конкретным заключениям. Затем выполняется анализ результатов регистрации. Неиспользуемые правила указывают либо на неверные предпосылки в правилах, либо на ошибки в используемых стратегиях управления процессом ре­шения задач.

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

Если окажется, что многократные внесения изменений и усо­вершенствований не приводят к улучшению работы экспертной системы, то это служит сигналом о необходимости пересмотра структуры и состава знаний в базе, стратегий управления процес­сом решения задач.