Содержание |
Оболочки ориентированы на достаточно узкий класс задач, хотя и более широкий, чем та программа, на основе которой создана сама оболочка. Так, автор системы EMYCIN Ван Мелле (van Melle) одним из первых подчеркнул, что оболочки отнюдь не являются универсальной архитектурой для решения проблем. Разработанная им система EMYCIN предназначена для таких проблем медицинского диагностирования с большими объемами данных, которые поддаются решению с помощью дедуктивного подхода в предположении, что пространство диагностических категорий стационарно.
В то же время, нельзя слишком доверять рекомендациям о возможности использования оболочки для решения конкретных проблем. На сегодняшний день не существует настолько четкого представления о классификации задач, решаемых экспертными системами, чтобы можно было точно представить, к какому именно классу следует отнести конкретную систему.
Область применения оболочек
Большинство коммерческих продуктов этого типа подходит только для проблемных областей с небольшим пространством поиска. Здесь обычно используют метод исчерпывающего поиска с построением обратной цепочки вывода и ограниченными возможностями управления процессом. Но некоторые современные оболочки могут применяться для решения широкого круга задач, поскольку поддерживают множество функций представления знаний и управления, включая и моделирование прямой цепочки логического вывода, процедуры, передачу сообщений и т.п.
Простота языков представления знаний, применяемых для большинства оболочек, является, с одной стороны, достоинством, а с другой – недостатком такого рода систем. Так, используемый в некоторых экспертных системах формализм порождающих правил затрудняет разделение разных видов знаний – эвристических, управляющих, знаний об ожидаемых значениях сущностей. Ведь способность системы дифференцировать виды знаний является одним из главных условий обеспечения ее "прозрачности" для пользователя
Методы формирования суждений
Часто, как основной метод формирования суждений в оболочке экспертной системы, используют построение обратной цепочки вывода. При этом выбираются множества правил мета- и объектного уровня. В результате очень сложно формировать исчерпывающее и понятное для пользователя пояснение. Те решения, которые принимаются на этапе программирования правил, в частности, касающиеся порядка и количества выражений в антецедентной части, могут разительным образом повлиять на путь поиска в пространстве решений в процессе работы системы .
Другая проблема касается функциональных возможностей базирующихся на правилах систем в общем, а значит, и всех оболочек, в которых порождающие правила используются в качестве основного языка представления знаний. Львиной долей базы знаний являются знания о типовых случаях, о тех, которые часто встречаются в проблемной области. Эксперты легко решают типовые проблемы и способны классифицировать их в терминах идеальных прототипов даже при недостаточной полноте данных.. Такие знания, в виду их абстрактности, практически невозможно представить в экспертной системе только при помощи правил формы "условие-действие". Здесь необходим более сложный формализм, который сведет на нет одно из главных достоинств использования порождающих правил в качестве основного средства принятия решений.
Обработка неопределенности
Следующая проблема оболочек касается механизма обработки неопределенности. Некоторые оболочки уже включают в себя определенный формальный механизм работы с неопределенностью, например, основанный на использовании коэффициентов уверенности. Однако в оболочках применяются и такие механизмы, которые не согласуются с выводами теории вероятностей и обладают свойствами, тяжело поддающимися анализу. Конкретному методу обработки неопределенности при решении конкретной задачи в данной предметной области можно дать прагматическое обоснование по отношению к схеме обработки коэффициентов уверенности. Распространять этот аппарат на другие области применения, встроив его в оболочку нецелесообразно.
По сравнению с первыми разработками современные оболочки более гибкие, по крайней мере, в том, что без особого труда могут быть интегрированы в большинство операционных сред, доступных на рынке программного обеспечения, и оснащены достаточно развитыми средствами пользовательского интерфейса.
Многофункциональные среды создания оболочек
Многофункциональные программные среды позволяют опытному программисту экспериментировать при решении новых классов проблем, выбирая подходящие сочетания различных методов, представленных в имеющемся модульном наборе. Поскольку не существует единственного универсального языка представления знаний для произвольной экспертной системы, необходимо объединить несколько различных схем представления, особенно на этапе создания прототипа. Полноценной теории таких гибридных систем не существует, но эксперименты с разными схемами представления и логического вывода показали, что каждая имеет свои недостатки. Поэтому наибольший эффект приносит объединение разных методик таким образом, чтобы достоинства одних компенсировали недостатки других.
Структурированные объекты, например фреймы, оказались практичным средством для хранения и манипулирования описаниями объектов проблемной области, но применение таких знаний требует включения в программу фрагментов программного кода, которые затем трудно анализировать. Основная идея первых попыток сведения вместе стилей, основанных на правилах и фреймах, состояла в том, чтобы объединить способность представлять объекты, характерные для фреймов, с возможностями связывать условия и действия с помощью порождающих правил.TAdviser выпустил новую Карту «Цифровизация промышленности»: свыше 250 разработчиков и поставщиков услуг 
Одной из первых многофункциональных сред искусственного интеллекта является LOOPS, в которой в рамках единой архитектуры обмена сообщениями были интегрированы четыре принципа программирования:
- процедурно-ориентированное программирование. Язык LISP, в котором активным компонентом являются процедуры, а пассивным – данные.
- программирование, ориентированное на правила. Принцип аналогичен предыдущему, но роль процедур играют правила "условие-действие". Множество правил связано с управляющими компонентами, необходимых для разрешения конфликтов в простейшей форме.
- объектно-ориентированное программирование. Структурированные объекты имеют двойственную структуру: они обладают свойствами и процедур, и данных, причем побочные эффекты обычно локализуются в пределах объекта.
- программирование, ориентированное на данные. Доступ к данным и их обновление запускает определенные процедуры, причем не имеет значения, почему изменен компонент данных. Это может являться результатом побочного эффекта или действия других процедур
В рамках основного объектно-ориентированного принципа построения можно комбинировать модули среды, поддерживающие разные стили программирования. Обычно условия в порождающих правилах и логические фразы связываются со значениями слотов структурированных объектов, а правила модифицируют значения этих слотов. Именно такой стиль объединения парадигм в настоящее время реализован в языке CLIPS.
Связанные темы
- Экспертные системы
- Экспертные системы (Архитектура)
- Разработка экспертных систем
- Экспертные системы (представление знаний)
Ссылки
