Представление знаний в информационных системах

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

     Программирование, ориентированное на правила. Эта  парадигма аналогична предыдущей, но роль процедур играют правила "условие-действие". В среде LOOPS наборы правил сами по себе являются объектами, которые можно  рекурсивно вкладывать один в другой. Таким образом, часть "действие" одного правила, в свою очередь, может  активизировать подчиненный набор  правил. С множествами правил связываются  управляющие компоненты, с помощью  которых в простейшей форме выполняется  разрешение конфликтов.

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

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

     В рамках основной объектно-ориентированной  парадигмы модули среды, поддерживающие разные стили программирования, можно  комбинировать. Обычно условия в  порождающих правилах и логические фразы связываются со значениями слотов структурированных объектов, а правила модифицируют значения этих слотов. Именно такой стиль  объединения парадигм в настоящее  время реализован в языке CLIPS.

     В системах КЕЕ и LOOPS поведение объектов описывается в терминах множества  порождающих правил, как это сделала  Эйкинс (Aikins) в системе CENTAUR. В средах КЕЕ и Knowledge Craft к перечисленным  выше парадигмам добавлено и логическое программирование в стиле языка PROLOG. Новая версия КЕЕ, известная  под названием КАРРА-РС, предоставляет  в распоряжение программиста еще  более широкий набор стилей для  комбинирования правил, объектов и  процедур. 

     Глава 3. Использование инструментальных средств 

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

3.1. Характерные  сложности и способы их избежать 

     В своей книге Уотерман перечисляет  следующие "ловушки", поджидающие  разработчика экспертной системы на этапе внедрения, и дает рекомендации, как их избежать [Waterman, 1986, Chapter 19].

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

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

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

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

     В следующих трех разделах мы остановимся  на важных и сложных вопросах, которые  следуют из представленного ниже перечня.

     Как подобрать подходящий инструментарий для проектирования экспертной системы?

     Насколько в действительности такие средства просты в обращении?

     Что такое "хороший стиль программирования" в выбранной среде разработки? 

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

3.2. Выбор  подходящего инструментария для  разработки экспертной системы 

     В работе [Hayes-Roth et al, 1983, Chapter 1] собраны  рекомендации по выбору подходящих инструментальных средств построения экспертной системы. В основу рекомендаций положено сопоставление  характеристик задач, решаемых проектируемой  экспертной системой, и необходимых  функциональных возможностей инструментального  комплекса.

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

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

     Быстрота. Если успех проекта зависит от срока разработки, то следует выбирать инструментальную среду со встроенными  средствами формирования пояснений  и развитым пользовательским интерфейсом. Разработка интерфейса — одна из наиболее трудоемких стадий проектирования системы, и чем большую часть этой работы можно переложить на среду разработки, тем быстрее будет завершен проект.

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

     Важнейшим для выбора инструментальной среды  является вопрос о способе определения  характеристик проблемы, решаемой проектируемой  экспертной системой. Этот вопрос обсуждается  в работе [Stefik et al, 1983], где предлагается схема анализа, основанная на свойствах  пространства поиска решения. Я позволил себе несколько обобщить предлагаемые авторами работы категории проблем  и свел  Категорий к четырем, хотя основные принципы классификации  остались прежними.

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

       Ненадежные данные или знания. Если данные и/или знания ненадежны,  т.е. существует опасность, что  вводимые в систему данные  недостоверны, а правила в базе  знаний неоднозначны, то в экспертной  системе нужно комбинировать  информацию от нескольких источников  и использовать в какой-либо  форме логику неточных рассуждений.  Авторы цитируемой работы весьма  мудро решили воздержаться от конкретных рекомендаций, какой именно формализм неточных рассуждений следует выбрать, но круг кандидатов в любом случае довольно ограничен — формализм коэффициентов уверенности или нечеткой логики. Обсуждение альтернативных методов, таких как использование функций доверия (belief function) и обновляемых оценок по Байесу (Bayesian belief updating).

     Большое, но факторизуемое пространство решений. В литературе можно найти два  варианта толкования термина "факторизуемый". Пространство поиска можно назвать  факторизуемым, если существует "правило  исключения", которое помогает уменьшить  размер пространства на ранней стадии решения проблемы [Stefik et al, 1983, p. 99]. Есть и другое определение — пространство поиска является факторизуемым, если возможно разделить его на несколько независимых  подпространств, которые можно обрабатывать по отдельности, причем для разных подпространств могут быть использованы и разные множества правил или отдельные  подмножества одного и того же множества  правил [Nilsson, 1980, р. 37]. Обычно такое разбиение  выполняется на уровне решаемой проблемы, т.е. большая общая проблема разбивается  на несколько более мелких. Успех  в достижении главной цели, таким  образом, оценивается по совокупности успехов в достижении более или  менее независимых подцелей. .Если система потерпит неудачу в достижении одной из подцелей, то это будет  означать неудачу и решения проблемы в целом. В любом случае для  решения проблем такого класса наиболее предпочтительным является метод порождения и проверки (generate-and-test). Этот метод  позволяет "обрезать" ветви, уводящие нас от решения, и разделить большое  пространство решений на подпространства.

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