Экспертные системы

     1.4. Архитектура экспертной системы реального времени

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

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

     Жизненный цикл приложения в G2 состоит из ряда этапов.

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

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

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

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

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

     Для выявления ошибок и неопределенностей  реализована возможность "Inspect", позволяющая просматривать различные  аспекты базы знаний, например, "показать все утверждения со ссылками на неопределенные сущности (объекты, связи, атрибуты)", "показать графически иерархию заданного класса объектов", "показать все сущности, у которых значение атрибута Notes не ОК". (Данный атрибут есть у всех сущностей, представимых в языке G2; его значение - либо ОК, когда нет претензий к сущности, либо описание реальных или потенциальных проблем, например, ссылка на несуществующий объект, несколько объектов с одним именем и т.п.)

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

     Для проверки выполнения ограничений используется возможность "Meters", вычисляющая  статистику по производительности и используемой памяти.

     Полученное  приложение полностью переносимо на различные платформы в среду UNIX (SUN, DEC, HP, IBM и т.д.), VMS (DEC VAX) и Windows NT (Intel, DEC Alpha). База знаний сохраняется в  обычном ASCII-файле, который однозначно интерпретируется на любой из поддерживаемых платформ. Перенос приложения не требует его перекомпиляции и заключается в простом перемещении файлов. Функциональные возможности и внешний вид приложения не претерпевают при этом никаких изменений. Приложение может работать как в "полной" (т.е. предназначенной для разработки) среде, так и под runtime, которая не позволяет модифицировать базу знаний.

     Сопровождение приложения. Не только сам разработчик данного приложения, но и любой пользователь может легко его понять и сопровождать, так как все объекты/классы, правила, процедуры, функции, формулы, модели хранятся в базе знаний в виде структурированного естественного языка и в виде графических объектов. Для ее просмотра используется возможность "Inspect". Сопровождение упрощается за счет того, что различным группам пользователей выдается не вся информация, а только ее часть, соответствующая их потребностям.

     Основные компоненты

     Экспертная  система реального времени состоит  из базы знаний, машины вывода, подсистемы моделирования и планировщика.

     База знаний

     Все знания в G2 хранятся в двух типах  файлов: базы знаний и библиотеки знаний. В файлах первого типа хранятся знания о приложениях: определения всех объектов, объекты, правила, процедуры  и т.п. В файлах библиотек хранятся общие знания, которые могут быть использованы более, чем в одном приложении, например, определение стандартных объектов. Файлы баз знаний могут преобразоваться в библиотеки знаний и обратно. 
 
 
 
 
 
 
 
 
 
 

     2. История развития  экспертных систем

     2.1. Основные линии развития экспертных систем

     Наиболее  известные ЭС, разработанные в 60-70-х  годах, стали в своих областях уже классическими. По происхождению, предметным областям и по преемственности  применяемых идей, методов и инструментальных программных средств их можно разделить на несколько семейств.

     1. META-DENDRAL. Система DENDRAL позволяет определить наиболее вероятную структуру химического соединения по экспериментальным данным (масс- спектрографии, данным ядерном магнитного резонанса и др.).M-D автоматизирует процесс приобретения знаний для DENDRAL. Она генерирует правила построения фрагментов химических структур.

     2. MYCIN-EMYCIN-TEIREIAS-PUFF-NEOMYCIN. Это семейство медицинских ЭС и сервисных программных средств для их построения.

     3. PROSPECTOR-KAS. PROSPECTOR- предназначена для поиска (предсказания) месторождений на основе геологических анализов. KAS- система приобретения знаний для PROSPECTOR.

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

     5. HEARSAY-HEARSAY-2-HEARSAY-3-AGE. Первые две системы этого ряда являются развитием интеллектуальной системы распознавания слитной человеческой речи, слова которой берутся из заданного словаря. Эти системы отличаются оригинальной структурой, основанной на использовании доски объявлений- глобальной базы данных, содержащей текущие результаты работы системы. В дальнейшем на основе этих систем были созданы инструментальные системы HEARSAY-3 и AGE (Attempt to Generalize- попытка общения) для построения ЭС.

     6. Системы AM(Artifical Mathematician- искусственный математик) и EURISCO были разработаны в Станфордском университете доктором Д. Ленатом для исследовательских и учебных целей. Ленат считает, что эффективность любой ЭС определяется закладываемыми в нее знаниями. По его мнению, чтобы система была способна к обучению, в нее должно быть введено около миллиона сведений общего характера. Это примерно соответствует объему информации, каким располагает четырехлетний ребенок со средними способностями. Ленат также считает, что путь создания узкоспециализированных ЭС с уменьшенным объемом знаний ведет к тупику⁴.

     В систему AM первоначально было заложено около 100 правил вывода и более 200 эвристических алгоритмов обучения, позволяющих строить произвольные математические теории и представления. Сначала результаты работы системы были весьма многообещающими. Она могла сформулировать понятия натурального ряда и простых чисел. Кроме того, она синтезировала вариант гипотезы Гольдбаха о том, что каждое четное число, большее двух, можно представить в виде суммы двух простых чисел. До сих пор не удалось ни найти доказательства данной гипотезы, ни опровергнуть ее. Дальнейшее развитие системы замедлилось и было отмечено, что несмотря на проявленные на первых порах “математические способности”, система не может синтезировать новых эвристических правил, т.е. ее возможности определяются только теми эвристиками, что были в нее изначально заложены.

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

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

     С 1990 года доктор Ленат во главе исследовательской  группы занят кодированием и вводом нескольких сот тысяч элементов знаний, необходимых, по его мнению, для создания “интеллектуальной” системы. Этот проект назван Cyc (“Цик”, от английского слова enciklopaedia).

     2.2. Проблемы, возникающие при создании экспертных систем

     Перспективы разработки.

     С 70-х годов ЭС стали ведущим  направлением в области искусственного интеллекта. При их разработке нашли применение методы ИИ, разработанные ранее: методы представления знаний, логического вывода, эвристического поиска, распознавания предложений на естественном языке и др. Можно утверждать, что именно ЭС позволили получить очень большой коммерческий эффект от применил таких мощных методов. В этом - их особая роль.

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

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