Экспертная система как сделать

Добавил пользователь Евгений Кузнецов
Обновлено: 04.10.2024

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

Содержание

Требования по созданию

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

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

Оправданность использования

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

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

Соответствие приложения методам ЭС

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

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

Концепция быстрого прототипа

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

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

Этапы разработки

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

идентификация
концептуализация
формализация
выполнение
тестирование
опытная эксплуатация

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

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

Формализация подразумевает выбор инструментов и способов представления всех видов знаний. На этом этапе формализуются основные понятия, определяются способы интерпретации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решений, средств представления знаний и управления ими.

Данная работа посвящена разработке и созданию экспертных систем, их применения в медицине.

Ключевые слова: экспертная система, медицина

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

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

На этапе идентификации определяются задачи, которые подлежат решению, выявляются цели разработки, определяются эксперты и типы пользователей.

На этапе концептуализации проводится содержательный анализ проблемной области, выявляются используемые понятия и их взаимосвязи, определяются методы решения задач [6, с.151].

Второй подход, называемый структурным (или когнитивным), осуществляется путем выделения элементов предметной области, их взаимосвязей и семантических отношений [3, с. 20].

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

Структурный подход к построению модели предметной области предполагает выделение следующих когнитивных элементов знаний:

Понятия;
Взаимосвязи;
Метапонятия;
Семантические отношения.

Выделяемые понятия предметной области должны образовывать систему, под которой понимается совокупность понятий, обладающая следующими свойствами: уникальностью (отсутствием избыточности); полнотой (достаточно полным описанием различных процессов, фактов, явлений и т. д. предметной области); достоверностью (валидностью — соответствием выделенных единиц смысловой информации их реальным наименованиям) и непротиворечивостью (отсутствием омонимии) [10, с. 133].

– Он используется в большом числе подзадач;

– Используется с большим числом других элементов данных.

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

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

Кроме рассмотренных выше неформальных методов для установления взаимосвязей между отдельными понятиями применяются также формальные методы. Сюда в первую очередь относятся методы семантического дифференциала и репертуарных решеток [12, с. 138].

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

Последним этапом построения модели предметной области при концептуальном анализе является установление семантических отношений между выделенными понятиями и метапонятиями. Установить семантические отношения — это значит определить специфику взаимосвязи, полученной в результате применения тех или иных методов. Для этого необходимо каждую зафиксированную взаимосвязь осмыслить и отнести ее к тому или иному типу отношений [11, с. 124].

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

На этапе формализации выбираются ИС и определяются способы представления всех видов знаний, формализуются основные понятия, определяются способы интерпретации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решений, средств представления и манипулирования знаниями [8, с. 61].

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

При проектировании ЭС типичными ресурсами являются источники знаний, время разработки, вычислительные средства и объем финансирования. Для эксперта источниками знаний служат его предшествующий опыт по решению задачи, книги, известные примеры решения задач, а для инженера по знаниям — опыт в решении аналогичных задач, методы представления знаний и манипулирования ими, программные инструментальные средства [14, с. 102].

При идентификации целей важно отличать цели, ради которых создается ЭС, от задач, которые она должна решать. Примерами возможных целей являются: формализация неформальных знаний экспертов; улучшение качества решений, принимаемых экспертом; автоматизация рутинных аспектов работы эксперта (пользователя); тиражирование знаний эксперта [13, с. 51].

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

Как уже было отмечено выше, архитектура различных ЭС, с точки зрения входящих в нее программных модулей, идентична практически для любых задач. Детали реализации модулей, конечно, могут сильно отличаются в различных проектах, но их базовый состав и взаимодействие четко определено. Большинство современных ЭС основываются на знаниях и отличаются от обычных программ (табл. 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, так как система полностью интегрирована со своим окружением – она представляла собой интеллектуальное расширение аппарата исследования легких, который врачи давно использовали.

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

Читайте также: