ИНЖЕНЕРИЯ ЗНАНИЙ С ПРИМЕНЕНИЕМ ЛОГИКИ ПЕРВОГО ПОРЯДКА

В предыдущем разделе иллюстрировалось использование логики первого порядка для представления знаний в трех простых проблемных областях. В этом разделе рассматривается общий процесс конструирования базы знаний, называемый инженерией знаний. Инженером по знаниям называется специалист, который исследует конкретную проблемную область, определяет, какие понятия важны в этой проблемной области, и создает формальное представление объектов и отношений в этой проблемной области. В данном разделе процесс инженерии знаний будет проиллюстрирован на проблемной области проектирования электронных схем, которая должна быть уже довольно знакомой читателю, поэтому мы можем сосредоточиться на самих относящихся к этой теме проблемах представления знаний. Применяемый в этом разделе подход является приемлемым для разработки баз знаний специального назначения, проблемная область которых тщательно очерчена и спектр запросов известен заранее. Базы знаний общего назначения, которые предназначены для поддержки запросов, касающихся полного спектра человеческих знаний, обсуждаются в главе 10.
Процесс инженерии знаний
Безусловно, проекты в области инженерии знаний во многом отличаются друг от друга по своему содержанию, охвату и сложности, но все эти проекты включают перечисленные ниже этапы.
1. Идентификация задания. Инженер по знаниям должен очертить круг вопросов, которые должна поддерживать база знаний, и виды фактов, которые будут доступными применительно к каждому конкретному экземпляру задачи. Например, должна ли база знаний о вампусе предоставлять возможность выбирать действия, или от нее требуется только поиск ответов на вопросы о содержании различных компонентов среды? Должны ли факты, полученные от датчиков, включать данные о текущем местонахождении? Само задание определяет, какие знания должны быть представлены в базе, чтобы можно было связать экземпляры задачи с ответами. Этот этап аналогичен процессу PEAS проектирования агентов, описанному в главе 2.
2. Сбор относящихся к делу знаний. Инженер по знаниям может уже быть экспертом в рассматриваемой проблемной области или ему может потребоваться общаться с настоящими экспертами для выявления всего, что они знают — этот процесс называется приобретением знаний. На этом этапе знания еще не представлены формально. Его назначение состоит в том, чтобы понять, каким должен быть спектр знаний в базе знаний, определяемый самим заданием, а также разобраться в том, как фактически функционирует рассматриваемая проблемная область.
Относящиеся к делу (релевантные) знания для мира вампуса, который определен с помощью искусственного набора правил, выявить несложно. (Но следует отметить, что определение понятия соседства квадратов не формулировалось явно в правилах функционирования мира вампуса.) Тем не менее для реальных проблемных областей задача выявления релевантных знаний может оказаться весьма сложной; например, система для эмуляции работы спроектированных СБИС может требовать или не требовать учета паразитных емкостей и поверхностных эффектов.
3. Определение словаря предикатов, функций и констант. В иной формулировке
этот этап можно определить как преобразование важных понятий уровня
проблемной области в имена логического уровня. Для этого необходимо ответить на многие вопросы в стиле инженерии знаний. Как и от стиля программирования, от стиля инженерии знаний может существенным образом зависеть окончательный успех проекта. Например, должны ли ямы быть представлены с помощью объектов или с помощью унарного предиката, определенного на квадратах? Должна ли ориентация агента быть задана в виде функции или предиката? Должно ли местонахождение вампуса зависеть от времени? Результатом выбора наиболее подходящих средств представления становится словарь, известный под названием онтологии проблемной области. Само слово онтология в данном контексте означает конкретную теорию пребывания в определенном состоянии, или теорию существования. Онтология определяет, какого рода объекты существуют, но не определяет их конкретные свойства и взаимосвязи.
4. Регистрация общих знаний о проблемной области. Инженер по знаниям записывает аксиомы для всех терминов словаря. Тем самым он закрепляет (в возможной степени) смысл этих терминов, позволяя эксперту проверить их содержание. На этом этапе часто обнаруживаются неправильные трактовки или пропуски в словаре, который необходимо исправить, возвратившись на этап 3 и снова пройдя данную итерацию в текущем процессе проектирования.
5. Составление описания данного конкретного экземпляра задачи. Если онтология хорошо продумана, этот этап будет несложным. Он сводится к написанию простых атомарных высказываний об экземплярах понятий, которые уже являются частью онтологии. Для логического агента определения экземпляров задачи поставляются датчиками, а сама "бестелесная" база знаний снабжается дополнительными высказываниями таким же образом, как традиционные программы снабжаются входными данными.
6. Передача запросов процедуре логического вывода и получение ответов. Именно здесь нас ожидает награда: теперь мы можем применить процедуру логического вывода к аксиомам и фактам о конкретной задаче для получения фактов, которые нам хочется узнать.
7. Отладка базы знаний. К сожалению, ответы на запросы при первой попытке редко оказываются правильными. Точнее, ответы будут правильными для базы знаний в том виде, в каком она написана, при условии, что процедура логического вывода является непротиворечивой, но они не будут такими, каких ожидает пользователь. Например, если недостает какой-то аксиомы, то на некоторые запросы из этой базы знаний нельзя будет найти ответ. В этом может помочь продуманный процесс отладки. Недостающие или слишком слабые аксиомы могут быть легко выявлены путем обнаружения участков, на которых неожиданно обрывается цепочка этапов логического вывода. Например, если база знаний содержит одну из диагностических аксиом, касающихся ям,
Vs Breezy(s) => 3r Adjacent (r, s) л Pi t(r)
но не содержит другую, то агент не сможет доказать отсутствие ям. Неправильные аксиомы могут быть выявлены на основании того, что они представляют собой ложные утверждения о мире. Например, аксиома Vx NumOfLegs(х, 4) => Mammal (х)
является ложной, поскольку относит к млекопитающим рептилий, амфибий и, что еще важнее, столы с четырьмя ножками. Ложность этого высказывания может быть определена независимо от остальной части базы знаний. В отличие от этого, типичная ошибка в программе выглядит примерно таким образом:
offset = position + 1
Невозможно определить, является ли этот оператор правильным, не изучив остальную часть программы для определения того, что, например, переменная offset используется для ссылки на текущую позицию или на позицию, которая следует за текущей позицией, а также происходит ли изменение значения переменной position в другом операторе и поэтому возникает необходимость снова изменять значение переменной offset.
Чтобы лучше понять этот процесс, состоящий из семи этапов, мы теперь применим его к расширенному примеру — к проблемной области электронных схем.







Материалы

Яндекс.Метрика