Методы реализации экспертных систем

По определению, экспертная система – это компьютерная программа с некоторыми отличиями в структуре и характеристиках по сравнению с традиционными программами.

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

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

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

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

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

Эволюция средств разработки ЭС может быть разбита на четыре этапа:

• Дискретные средства
• Интегрированный набор средств
• Средства поддержки жизненного цикла
• Интеллектуальные средства поддержки жизненного цикла

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

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

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

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

Например, такие системы, как Turbo-Prolog, Interlisp-D, позволяют программисту запустить программу сразу после ввода ее в систему. В ответ на ошибку системой вызывается отладчик, чтобы дать возможность программисту изучить причину сбоя. Программист может затем отредактировать программу и продолжить ее выполнение. Этот подход сокращает время на исправление мелких ошибок в программе для экспериментального программирования (метод проб и ошибок), обычно применяемого специалистами по искусственному интеллекту.

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

lnterlisp-D, Turbo Prolog поддерживают только этапы реализации и отладки. Исследования показывают, что наибольший вклад в стоимость жизненного цикла дает этап сопровождения. Не менее важное значение имеют средства этапа требований и спецификаций, потому что любую ошибку в спецификациях очень трудно и дорого исправлять на позднейших этапах жизненного цикла. Таким образом, анализ жизненного цикла важен для любой части программного обеспечения, которая предназначена для использования конечными пользователями на заметном интервале времени.

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

В заключение отметим некоторые особенности этапов жизненного цикла экспертных систем. Тестирование экспертных систем отличается от тестирования обычных систем.

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

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

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

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