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