Технология создания экспертных систем

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

Таблица 1.2 - Различия между обычными программами и экспертными системами

Характеристика	Обычные программы	Экспертные системы
Управление по	порядку операторов	машине вывода
Управление и данные	Неявные объединения	Явные разделения
Мощность управления	Высокая	Низкая
Решение по	Алгоритму	Правилам
Поиск решения	В малой степени или отсутствует	В большой степени
Решение проблем	По известному алгоритму	По правилам
Входные данные	Точные	Неполные, неточные
Неожиданные входные данные	Не обрабатываются	Обрабатываются
Выходные данные	Всегда корректные	Зависят от проблемы
Объяснение	Отсутствует	Обычно присутствует
Приложения	Обработка чисел, текстовых файлов	Символические рассуждения
Выполнение	Обычно последовательное	Подходящие правила
Разработка программы	Структурированный подход	Неструктурированный подход

Рисунок 1.5 – Основные факторы, учитывающиеся при создании ЭС

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

Учитывая вышесказанное, технологию разработки ЭС можно представить схемой, включающей следующие этапы (рис. 1.6):

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

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

3. Этап доработки – это по сути основной, наиболее рутинный и продолжительный этап работы над ЭС. Все компоненты многократно тестируются и доводятся до соответствия требованиям проекта. Наибольшую сложность вызывает доработка и доказательство адекватности и эффективности БЗ, так как количество записей в ней может быть на порядок больше, чем в прототипе.

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

Рисунок 1.6 - Этапы разработки ЭС

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

Критериями, указывающими на необходимость создания ЭС, являются также следующие:

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

- потребность в многочисленном коллективе специалистов, поскольку ни один из них не обладает достаточным знанием; система 1SIS помогала планировать промышленные заказы.

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

- большое расхождение между решениями самых опытных экспертов и новичков; система XCON, разработанная для конфигурирования компьютеров VAX – 1/780/ ошибалась на порядок меньше, по сравнению со специалистом средней руки.

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

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

Реализация прототипа возможна с применением специализированных инструментальных средств. На рынке представлен достаточно большой их спектр, начиная от языков программирования (LISP, Prolog, Python и др.), оболочек ЭС (Exsys и пр.) и кончая дорогостоящими комплексами (Gensym G2). Выбор инструментария в основном зависит от имеющихся ресурсов и времени. Распространен также вариант, когда на ранних стадиях для реализации прототипа используют инструмент, позволяющий сократить время разработки (например, оболочку ЭС), а в последствии, для реализации окончательной версии, переходят на более низкоуровневый, но и более эффективный язык программирования.

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

Объем первоначальных версий БЗ прототипа обычно составляет несколько десятков записей. Этого вполне достаточно, чтобы смоделировать процесс принятия экспертом отдельных решений по одному или нескольким вопросам. В тоже время разработка этих нескольких десятков правил требует прохождения всего цикла проектирования. Сама процедура создания прототипа имеет итеративный характер. Шаги повторяются, пока не будет получен удовлетворительный результат. Можно условно выделить следующие основные стадии разработки прототипа:

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

2. Извлечение знаний – процесс взаимодействия эксперта и инженера по знаниям, являющимся основным разработчиком БЗ. В результате этого взаимодействия инженер по знаниям получает наиболее полное представление о предметной области и способах решения задач в ней. Происходит перенос компетентности экспертов на инженеров по знаниям с использованием различных методов: анализ текстов, диалоги, экспертные игры, лекции, дискуссии, интервью, наблюдение и другие.

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

4. Формализация знаний – разработка базы знаний на языке, который, с одной стороны, соответствует структуре поля знаний, а с другой – позволяет реализовать прототип системы на следующей стадии программной реализации. Строится формализованное представление концепций предметной области на основе выбранного языка представления знаний (ЯПЗ). Традиционно на этом этапе используются: логические методы (исчисления предикатов I порядка и др.), продукционные модели (с прямым и обратным выводом), семантические сети, фреймы, функциональное программирование, объектно-ориентированные языки, основанные на иерархии классов, объектов и др., а также комбинация указанных методов.

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

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

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

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

- демонстрационный прототип ЭС – система решает часть задач, демонстрируя жизнеспособность подхода (несколько десятков записей БЗ);

- исследовательский прототип ЭС – система решает большинство задач, но не устойчива в работе и не полностью проверена (несколько сотен записей БЗ);

- действующий прототип ЭС – система надежно решает все задачи на реальных примерах, но для сложной задачи, возможно, потребуется много времени и памяти;

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

- коммерческая система – рабочая система, пригодная к продаже, т.е. хорошо документирована и снабжена необходимым сервисом по распространению.

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

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

- критерии пользователей (понятность и «прозрачность» работы системы, удобство интерфейсов и др.);

- критерии приглашенных экспертов (оценка советов-решений, предлагаемых системой, сравнение ее с собственными решениями, оценка подсистемы объяснений и др.);

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

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

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

Другой пример стыковки системы со своим окружением, это система САТ-1 – экспертная система для диагностики неисправностей дизелей локомотивов. Эта система была разработана также на LISP, а затем переведена на FORTH, чтобы ее можно было более эффективно использовать в различных локомотивных цехах. Мастер по ремонту запрашивал систему: определить возможные причины неисправности дизеля. Система связана с видеодиском, с помощью которого мастеру дают визуальные объяснения и подсказки относительно более подробных проверок, которые ему нужно сделать. Кроме того, если оператор не уверен в том, как устранить неисправность, система предоставляла ему обучающие материалы, которые фирма подготовила предварительно. Таким образом, мастер по ремонту может с помощью экспертной системы мог диагностировать проблему, найти нужную тестовую процедуру, получить на дисплее объяснение, как провести тест, или получить инструкции о том, как справиться с возникшей проблемой.

При перекодировании системы на язык, подобный Си, повышается ее быстродействие и увеличивается переносимость, однако гибкость при этом уменьшается. Это приемлемо лишь в том случае, если система сохраняет все знания о проблемной области, и это знание не будет изменяться в ближайшем будущем. Однако, если экспертная система создана именно из-за того, что проблемная область изменяется, то необходимо поддерживать систему в инструментальной среде разработки. Удачным примером ЭС, внедренной таким образом, является XCON (R1) – ЭС, которую фирма DEC использовала для комплектации ЭВМ семейства VAX. Одна из ключевых проблем, с которой столкнулась фирма DEC, – это необходимость постоянного внесения изменений в БЗ для новых версий оборудования, новых спецификаций и т.д. Для этой цели XCON была состыкована со средой проектирования OPS5, в которую поступали все необходимые материалы о новом оборудовании. Таким образом новые данные автоматически попадали в БЗ ЭС, что позволяло практически без дополнительных затрат осуществлять обновление БЗ.