Искусственный интеллект и экспертные системы

4.4. Поиск решений с  использованием нескольких моделей. 

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

переход с одной модели на другую позволяет обходить тупики, возникающие при поиске в процессе распространения ограничений;

использование нескольких моделей  позволяет в ряде случаев уменьшить  вероятность потери хорошего решения (следствие неполного поиска, вызванного ограниченностью ресурсов) за счет конструирования полного решения  из ограниченного числа частичных  кандидатов путем их расширения и  комбинации;

наличие нескольких моделей  позволяет системе справляться  с неточностью (ошибочностью) данных.

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

4.5. Выбор метода решения  задач. 

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

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

     Для преодоления  трудностей, вызванных неполнотой  и (или) неточностью данных (знаний), используют вероятностные, размытые  и точные методы. Все эти методы  основываются на идее увеличения  надежности путем комбинирования  фактов и использования метазнаний  о возможностях комбинирования  фактов.

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

5.1 Классификация инструментальных  средств. 

Инструментальные средства подразделяются на следующие категории:

Языки программирования

Языки инженерии знаний

Средства автоматизации  разработки экспертных систем

Оболочки экспертных систем

5.2 Языки программирования.[18]

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

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

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

Оболочки экспертных систем (expert system shells). Системы этого типа создаются, как правило, на основе какой-нибудь экспертной системы, достаточно хорошо зарекомендовавшей себя на практике. При создании оболочки из системы-прототипа удаляются компоненты, слишком специфичные для области ее непосредственного применения, и оставляются те, которые не имеют узкой специализации. Примером может служить система EMYCIN, созданная на основе про-шедшей длительную "обкатку" системы MYCIN. В EMYCIN сохранен интерпрета-тор и все базовые структуры данных — таблицы знаний и связанный с ними меха-низм индексации. Оболочка дополнена специальным языком, улучшающим читабельность программ, и средствами поддержки библиотеки типовых случаев и заключений, выполненных по ним экспертной системой. Дальнейшим развитием оболочки EMYCIN явились системы S.1 и М.4, в которых механизм построения цепочки обратных рассуждений, заимствованный в EMYCIN, объединен с фреймоподобной структурой данных и дополнительными средствами управления ходом рассуждений.

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

Среда программирования, поддерживающая несколько парадигм (multiple-paradigm programming environment). Средства этой категории включают несколько программных модулей, что позволяет пользователю комбинировать в процессе разработки экспертной системы разные стили программирования. Среди первых проектов такого рода была исследовательская программа LOOP, которая допускала использование двух типов представления знаний: базирующегося на системе правил и объектно-ориентированного. На основе этой архитектуры во второй половине 1980-х годов было разработано несколько коммерческих программных продуктов, из которых наибольшую известность получили KEE, KnowledgeCraft и ART. Эти программы предоставляют в распоряжение квалифицированного пользователя множество опций и для последующих разработок, таких как КАРРА и CLIPS, и стали своего рода стандартом. Однако освоить эти языки программистам далеко не так просто, как языки, отнесенные нами к предыдущей категории

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

    Объектно-ориентированные  языки 

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

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

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

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

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

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

    Пример:

Smalltalk[19] — объектно-ориентированный язык программирования с динамической типизацией, разработанный в Xerox PARC Аланом Кэйем, Дэном Ингаллсом, Тедом Кэглером, Адель Голдберг, и другими в 1970-х годах. Язык был представлен как Smalltalk-80 и с тех пор широко используется. Smalltalk продолжает активно развиваться и собирает вокруг себя преданное сообщество пользователей.

     Smalltalk оказал большое влияние на развитие многих других языков, таких как: Objective-C, Actor, Java и Ruby. Многие идеи 1980-х и 1990-х по написанию программ появились в сообществе Smalltalk. К ним можно отнести рефакторинг, шаблоны проектирования (применительно к ПО), карты Класс-Обязанности-Взаимодействие и экстремальное программирование в целом. Основатель концепции WikiWiki, Вард Каннингем, также входит в сообщество Smalltalk.