Этапы проектирования баз знаний

Проектирование баз знаний.

 

 

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

 

Каждая конкретная ЭС является человеко-машинной системой. В ее разработке необходимо участие экспертов, инженеров по знаниям и конструкторов.

 

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

 

Эксперт-профессионал обладает знаниями двух типов — вербализуемые и невербализуемые. Вербализуемые знания выражаются словесно или письменно, с использованием различных графиков, схем; обобщаются в виде статей, монографий, научных отчетов.

 

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

 

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

 

Инженер по знаниям выполняет сбор и формализацию экспертных знаний. Он также выполняет роль связующего звена между экспертами и конструкторами ЭС.Выделяют следующие основные технологические этапы разработки ЭС.1. Этап взаимодействия инженеров по знаниям и экспертов. На этом этапе формируется модель ПО, которая может включать в себя неформализованные компоненты, однако в ней должны быть специфицированы:все основные понятия ПО; атрибуты, их описывающие; отношения, существующие между ними;множество правил, описывающих специфические знания в анализируемой ПО (например, в форме продукции).Основным результатом взаимодействия инженера по знаниям с экспертами является выявление множества неформальных правил, которыми эксперт пользуется в своей профессиональной деятельности.2. Этап взаимодействия инженера по знаниям и конструкторов. На этом этапе выполняется настройка инструментального пакета (так называемой оболочки ЭС) на задачи ПО, выполняется загрузка собранных знаний в систему; создается макет экспертной системы и выполняется его тестирование.3. Этап взаимодействия инженеров по знаниям, экспертов и конструкторов. На данном этапе создается промышленный образец ЭС.4. Этап сопровождения и модификации ЭС.От стадии макетирования до получения промышленного образца ЭС проходит следующие стадии.1. Демонстрационный прототип (в базе знаний 50—100 правил). Система решает часть задач, демонстрируя жизнеспособность подхода.2. Исследовательский прототип (в базе знаний 200—500 правил). Система решает все задачи, но неустойчива в работе.3. Действующий прототип (в базе знаний 500—1000 правил). Система надежно решает все задачи на реальных примерах, но для сложных задач требуется много времени и памяти.4. Промышленный образец (в базе знаний 500—1500 и даже до 3000 правил). Система обеспечивает высокое качество решений при минимизации требуемого времени и памяти.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

1. Цели и задачи разрабатываемой ЭС.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

Поделиться:

Воспользуйтесь поиском по сайту: