Масленникова О.Е., Попова И.В. Основы искусственного интеллекта

Подождите немного. Документ загружается.

- 101 -

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

более подробно отдельные понятия и зависимости, если даже эти детали

непосредственно в выводе не использовались.

Остановимся на вопросе работы с экспертной системой. Прежде всего,

важно обозначить круг лиц (ролей), которые, так или иначе, участвуют в

этом процессе. Следует отметить, что под процессом работы с экспертной

системой понимается как необходимые для еѐ создания действия, так и

непосредственное взаимодействие для получения экспертных знаний,

хранящихся в ней. Таким образом, взаимодействие с ЭС осуществляют:

− эксперт в той предметной области, задачи которой будет решать ЭС;

− инженер по знаниям – специалист по разработке ЭС;

− программист – специалист по разработке инструментальных средств

(ИС);

− конечный пользователь – человек или группа лиц, использующих

систему для получения решений.

Эксперт определяет знания (данные и правила, характеризующие

предметную область), обеспечивает полноту и правильность выведенных в

ЭС знаний.

Инженер по знаниям помогает эксперту выявить и структурировать

знания, необходимые для работы ЭС, осуществляет выбор того

инструментального средства (ИС), которое наиболее подходит для данной

предметной области, и определяет способ представления знаний в этом ИС,

выделяет и программирует (традиционными средствами) стандартные

функции (типичные для данной предметной области), которые будут

использоваться в правилах, вводимых экспертом.

Необходимо отметить, что отсутствие среди участников разработки

инженера по знаниям (т.е. его замена программистом) либо приводит к

неудаче процесс создания ЭС, либо значительно удлиняет его.

Программист разрабатывает ИС, содержащие в пределе все основные

компоненты ЭС, осуществляет сопряжение ИС с той средой, в котором оно

будет использовано.

ЭС работает в двух режимах: приобретения знаний и решения задач

(консультации или использования ЭС).

В режиме приобретения знаний общение с ЭС эксперт осуществляет

через посредничество инженера по знаниям. Эксперт описывает предметную

область в виде совокупности данных и правил. Данные определяют объекты,

их характеристики и значения, существующие в области экспертизы.

Правила определяют способы манипулирования данными, характерные для

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

приобретения знаний, наполняет систему знаниями, которые позволяют ЭС в

режиме решения самостоятельно (без эксперта) решать задачи из предметной

области. Важную роль в режиме приобретения знаний играет

объяснительный компонент. Именно, благодаря ему, эксперт на этапе

тестирования локализует причины неудачной работы ЭС, что позволяет

- 102 -

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

знания. Обычно объяснительный компонент сообщает следующее: как

правила используют информацию пользователя; почему использовались или

не использовались данные или правила; какие были сделаны выводы и т.п.

Все объяснения делаются, как правило, на ограниченном естественном языке

или языке графики.

Режиму приобретения знаний при традиционном подходе к разработке

программ соответствуют этапы алгоритмизации, программирования и

отладки, выполняемые программистом. Таким образом, в отличие от

традиционного подхода разработку программ осуществляет эксперт (с

помощью ЭС), не владеющий программированием, а не программист.

В режиме консультации общение с ЭС осуществляет конечный

пользователь, которого интересует результат и (или) способ получения

решения. Пользователь в зависимости от назначения ЭС может не быть

специалистом в данной предметной области, в этом случае он обращается к

ЭС за советом, не умея получить ответ сам, или быть специалистом, в этом

случае он обращается к ЭС, чтобы либо ускорить процесс получения

результата, либо возложить на ЭС рутинную работу. Термин «пользователь»

является многозначным, так как кроме конечного пользователя применять

ЭС может и эксперт, и инженер по знаниям, и программист. Поэтому, когда

хотят подчеркнуть, что речь идет о том, для кого делалась ЭС, используют

термин «конечный пользователь».

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

диалоговым компонентом, который выполняет следующие действия:

1) распределяет роли участников (пользователя и ЭС) и организует

их взаимодействие в процессе кооперативного решения задачи;

2) преобразует данные пользователя о задаче, представленные на

привычном для пользователя языке, во внутренний язык системы;

3) преобразует сообщения системы, представленные на внутреннем

языке, в сообщения на языке, привычном для пользователя (обычно это

ограниченный ЕЯ или язык графики).

После обработки данные поступают в РП. На основе входных данных

из РП, общих данных о предметной области и правил из БЗ решатель

(интерпретатор) формирует решение задачи.

В отличие от традиционных программ ЭС в режиме решения задачи не

только исполняет предписанную последовательность операций, но и

предварительно формирует ее. Если ответ ЭС не понятен пользователю, то

он может потребовать объяснения как ответ получен.

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

Вопросы организации знаний в ЭС связаны с рассмотрением этапов еѐ

разработки (проектирования). Процессы построения ЭС сопряжены с рядом

трудностей: от изучения предметной области и установления

информационно ѐмких отношений с экспертами, до внедрения ЭС и

- 103 -

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

знаниями, формализованными в еѐ ядре. Этапы разработки схожи с

процессами создания любой информационной системы, но имеют сои

особенности, поскольку извлечение знаний при создании ЭС на ряду с

изучением множества источников знаний (специальной литературы, баз

фактуальных знаний, отчетов о решении аналогичных проблем) требует

всестороннего анализа опыта работы специалистов в исследуемой

проблемной области - экспертов. В конечном счѐте, успех проектирования

экспертной системы во многом определяется тем, насколько компетентны

привлекаемые к разработке эксперты и насколько они способны передать

свой опыт инженерам по знаниям. Последние, в свою очередь, должны

организовать рассматриваемый процесс таким образом, чтобы при

итеративном взаимодействии с экспертами, не имеющими представления о

возможностях и ограничениях ЭС, смогли получить весь необходимый объем

знаний для решения четко очерченных проблем.

Сложность разработки (проектирования) экспертных систем связана с

рядом причин:

− слабая формализуемость процесса принятия решений, его

альтернативность и нечеткость;

− качественная и символьная природа используемых знаний;

− динамичность изменения проблемной области и др.

Большинство разработчиков ЭС сходятся во мнении, что разработка

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

Рис. 45. Этапы разработки экспертной системы

- 104 -

идентификацию, концептуализацию, формализацию, выполнение

(реализацию базы знаний), тестирование, опытную эксплуатацию (рис. 3).

Краткая характеристика обозначенных этапов представлена в табл. 9.

Таблица 9

Характеристика некоторых этапов разработки экспертной системы

№

п/п

Этап

Краткая характеристика действий

Идентификация

Определяются задачи, которые подлежат

решению, выявляются цели разработки,

определяются эксперты и типы пользователей

Концептуализация

Проводится содержательный анализ проблемной

области, выявляются используемые понятия и их

взаимосвязи, определяются методы решения задач

Формализация

Выбираются инструментальные средства и

определяются способы представления всех видов

знаний, формализуются основные понятия,

определяются способы интерпретации знаний,

моделируется работа системы, оценивается

адекватность целям системы зафиксированных

понятий, методов решений, средств

представления и манипулирования знаниями

Выполнение

(реализация базы

знаний)

Осуществляется наполнение экспертом базы

знаний

Тестирование

Оценивается ЭС с позиции двух основных групп

критериев: точности и полезности. Точность

работы: правильность заключений, адекватность

базы знаний проблемной области, соответствие

методов решения проблемы экспертным.

Полезность: ответы на запросы пользователя;

удобство интерфейса; объяснение получаемых

результатов; надежность, адаптирумость,

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

Внедрение и

опытная

эксплуатация

Переход от тестовых примеров к решению

реальных задач

Первые два этапа разработки экспертной системы составляют

логическую стадию, не связанную с применением четко определенного

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

физического создания проекта на базе выбранного инструментального

средства.

- 105 -

Вместе с тем, процесс создания экспертной системы, как сложного

программного продукта, имеет смысл выполнять методом прототипного

проектирования, сущность которого сводится к постоянному наращиванию

базы знаний, начиная с логической стадии.

Прототипная технология создания экспертной системы означает, что

простейший прототип будущей системы реализуется с помощью любого

подручного инструментального средства еще на этапах идентификации и

концептуализации, в дальнейшем этот прототип детализируется,

концептуальная модель уточняется, реализация выполняется в среде

окончательно выбранного инструментального средства. После каждого этапа

возможны итеративные возвраты на уже выполненные этапы

проектирования, что способствует постепенному проникновению инженера

по знаниям в глубину решаемых проблем, эффективности использования

выделенных ресурсов, сокращению времени разработки, постоянному

улучшению компетентности и производительности системы. Технология

разработки прототипов представлена в табл. 10.

На начальных этапах идентификации и концептуализации, связанных с

определением контуров будущей системы, инженер по знаниям выступает в

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

этапах реализации и тестирования инженер по знаниям демонстрирует

результаты разработки, адекватность которых проблемной области оценивает

эксперт.

На всех этапах разработки инженер по знаниям играет активную роль,

а эксперт – пассивную. По мере развития самообучающихся свойств

экспертных систем роль инженера по знаниям уменьшается, а активное

поведение заинтересованного в эффективной работе экспертной системы

пользователя-эксперта возрастает.

Таблица 10

Соответствие этапов разработки ЭС получаемым прототипам

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

Характер

прототипа

Количество

правил

Срок

разработки

Идентификация

Демонстрационный

50 - 100

1 - 2 мес.

Концептуализация

Исследовательский

Формализация

Исследовательский

200 - 500

3 - 6 мес.

Реализация

Действующий

500 - 1000

6 - 12 мес.

Тестирование

Промышленный

1000 - 1500

1 - 1,5 года

Опытная

эксплуатация

Коммерческий

1500 - 3000

1,5 - 3 года

Этап идентификации

На данном этапе осуществляется постановка задачи (задач),

определяются участники процесса проектирования и их роли (их количество

и взаимоотношения), ресурсы, цели.

- 106 -

Обычно в одном цикле разработки ЭС участвует не менее трех-четырех

человек – один эксперт, один или два инженера по знаниям и один

программист, привлекаемый для модификации и согласования

инструментальных средств. К процессу разработки ЭС могут привлекаться и

другие участники. Например, инженер по знаниям может привлекать других

экспертов с целью оценки правильности в понимании основного эксперта,

представительности тестов и т.п. Однако в этом случае, как правило,

требуется, чтобы один из экспертов выполнял функции руководителя

экспертов.

Что касается формы взаимоотношения экспертов и инженеров, то

применяются следующие формы: эксперт выполняет роль информирующего

или эксперт выполняет роль учителя, а инженер – ученика. По общему

мнению, форма ученик - учитель больше соответствует методологии ЭС.

Несмотря на то, что основу знаний создаваемой системы будут составлять

знания эксперта, для достижения успеха инженер по знаниям должен

использовать (особенно в начале работы) дополнительные источники знаний

в виде книг, инструкций, отчетов, которые ему рекомендовал эксперт.

Другим словами, инженер по знаниям должен быть готов и способен изучить

особенности той предметной области, в рамках которой предстоит работать

создаваемой ЭС.

Идентификация задачи заключается в составлении неформального

(вербального) описания решаемой задачи. Цель этапа идентификации задачи

– характеризовать задачу и структуру поддерживающих еѐ знаний и таким

образом обеспечить начальный импульс для развития БЗ. В результате

должны быть представлены: общие характеристики задачи; ключевые

понятия и их отношения; входные (выходные) данные; предположительный

вид решения; знания, релевантные решаемой задаче; примеры (тесты)

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

вопросы:

− какие задачи предлагается решать ЭС и как они могут быть

охарактеризованы и определены;

− на какие подзадачи разбивается каждая задача, и какие данные они

используют;

− каковы основные понятия и взаимоотношения, использованные при

формулировании и решении задачи;

− какие знания релевантны решаемой задаче;

− какие ситуации препятствуют решению; как эти препятствия будут

влиять на ЭС.

При проектировании ЭС типичными ресурсами являются: источники

знаний, время разработки, вычислительные средства (возможности ЭВМ и

программных инструментальных средств) и объѐм финансирования. Для

эксперта источниками знаний могут быть его предшествующий опыт по

решению задачи, книги, конкретные примеры задач и использованных

решений, а для инженера по знаниям – опыт в решении аналогичных задач,

- 107 -

методы решения и представления знаний, программное инструментальное

средство. При определении (назначении) времени разработки необходимо

иметь в виду, что сроки разработки и внедрения ЭС составляют не менее

года (при трудоемкости 5 чел.- лет). Задача определения ресурсов является

весьма важной, поскольку ограниченность какого-либо ресурса существенно

влияет на процесс разработки. Так, при недостаточном объеме

финансирования предпочтение может быть отдано не разработке

оригинальной новой системы, а адаптации существующей.

Идентификация целей заключается в формулировании в явном виде

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

создается ЭС, от задач, которые она должна решать. Примерами возможных

целей являются:

− формализация неформальных знаний экспертов;

− улучшение качества решений, принимаемых экспертом;

− автоматизация рутинных аспектов работы пользователя (эксперта);

− тиражирование знаний эксперта.

На первом этапе инженер по знаниям должен ответить на основной

вопрос: подходят ли методы инженерии знаний для решения предложенной

задачи? Другими словами, задача не должна быть ни слишком легкой, ни

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

данной области, а не в том, чтобы быть экспертом в этой области. Для этих

целей следует обратить внимание на точное описание входа-выхода и на

наличие разнообразных примеров решений рассматриваемой задачи.

Этап концептуализации

На этом этапе определяются следующие особенности задачи: типы

доступных данных; исходные и выводимые данные; подзадачи общей задачи;

используемые стратегии и гипотезы; типы используемых отношений

(иерархия, причина – следствие, часть – целое и т.п.); процессы

используемые в ходе решения задачи; состав знаний, используемых для

решения задачи; состав знаний, используемых для оправдания (объяснения)

решения.

На этапе концептуализации может потребоваться несколько повторных

взаимодействий между экспертом и инженером по знаниям, что приводит к

значительным затратам времени. Опыт разработок ЭС убеждает в том, что на

данном этапе невозможно, да и не нужно добиваться корректности и полноты

разрабатываемой ЭС. Необходимо как можно раньше переходить к

следующим этапам (формализации и выполнению). На данном этапе у

инженера по знаниям появляются некоторые соображения о представлении

знаний и ИС.

Инженер по знаниям на этапе концептуализации должен обеспечить

достаточность введенных ключевых понятий и отношений для описания всех

имеющихся примеров решения рассматриваемой проблемы.

- 108 -

Этап формализации

На данном этапе все ключевые понятия и отношения, введенные на

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

предложенном (выбранном) инженером по знаниям. Здесь он определяет,

подходят ли имеющиеся инструментальные средства для решения

рассматриваемой проблемы или необходимы оригинальные разработки.

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

задача может быть представлена в выбранном или разработанном

формализме.

Процесс формализации зависит от трех основных факторов:

− структуры пространства поиска, характеризующей особенности

решаемой задачи;

− модели, лежащей в основе процесса решения задачи;

− свойств данных рассматриваемой задачи.

Чтобы понять структуру пространства поиска, необходимо

формализовать понятия (объекты, их характеристики и значения) и

определить, как они могут связываться друг с другом при образовании

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

ответить на перечисленные ниже вопросы.

1. Являются понятия примитивными или имеют внутреннюю

структуру?

2. Необходимо ли представлять причинные и пространственно-

временные отношения между понятиями и должны ли они быть

представлены явно?

3. Необходима ли иерархия гипотез?

4. Относится ли коэффициент определенности (или другие средства

для выражения мнения) только к окончательным гипотезам или он

необходим для промежуточных гипотез?

5. Необходимо ли рассматривать понятия и процессы на различных

уровнях абстракции?

Важный шаг в процессе формализации знаний – построение модели

исследуемой задачи, так как наличие модели позволяет генерировать

решение. Могут использоваться как поведенческие, так и математические

модели. Если эксперт использует при рассуждении или обосновании решения

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

важные понятия и отношения. Если же эксперт использует математическую

модель (аналитическую или статистическую), то она может быть

непосредственно включена в ЭС как для формирования решения, так и для

объяснения (оправдания) причинных отношений, обнаруженных в БЗ.

Для формализации знаний весьма важно понимать природу данных

проблемной области. Необходимо определить свойства данных, которые

существенно влияют на решение исходной проблемы. Это могут быть

следующие свойства:

− данные объясняются или нет в терминах гипотез;

- 109 -

− тип отношений между данными (причинные, определительные,

корреляционные); знание типа отношений позволяет определить, как

взаимосвязаны данные, гипотезы и цели в процессе решения;

− данные редки (обильны), недостаточны (избыточны);

− данные определенны или нет, то есть требуется ли использование

коэффициента определенности;

− интерпретация данных зависит или нет от порядка их появления во

времени;

− стоимость приобретения данных;

− как данные приобретаются (какие вопросы следует задать в процессе

приобретения данных);

− как необходимые характеристики объектов могут быть извлечены из

входного сообщения (сигнал, изображение, текст на естественном

языке, устная речь и т.д.);

− данные надежны (ненадежны), точны (неточны), согласованы

(несогласованы), полны (неполны).

Часто на этапе формализации выясняется, что для различных частей

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

Этап выполнения

Цель этого этапа – создание одного или нескольких прототипов ЭС,

решающих требуемые задачи. Затем на данном этапе по результатам этапов

тестирования и опытной эксплуатации создается конечный продукт,

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

состоит в программировании его компонентов или выборе их из имеющихся

инструментальных средств и наполнении БЗ.

Обычная ошибка разработчиков при создании прототипа состоит в том,

что процесс приобретения знаний откладывают до полного завершения

программирования. В конечном итоге в процессе накопления знаний

приходится вносить изменения в уже готовые программы. Поэтому

необходимо начинать приобретение знаний, как только составлены или

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

знаний и простейшими управляющими структурами, а следовательно,

максимально рано начать выполнение отдельных подзадач и обнаружить

необходимость дополнительных знаний до их решения. Иными словами,

первый прототип экспертной системы – демонстрационный (ЭС-1) – должен

появиться через несколько месяцев (обычно два-три), а не через годы после

начала работы.

Разработка прототипа – чрезвычайно важный шаг в создании ЭС.

Главное, чтобы прототип обеспечил проверку адекватности идей, методов и

способов представления, выбранных при создании данной ЭС, решаемым

задачам. Создание первого прототипа должно подтвердить, что выбранные

методы решений и способы представления пригодны для успешного решения

ряда задач из области экспертизы, а также показать, что с увеличением

- 110 -

объема знаний и улучшением стратегий поиска ЭС сможет дать

высококачественные и эффективные решения всех задач данной предметной

области. При разработке первого прототипа обычно оставляют в стороне

вопросы, требующие значительных трудозатрат:

− понимание и синтез фраз ограниченного естественного языка;

− построение сложных моделей;

− учет сложных временных, причинных и модальных отношений;

− понимание намерений пользователей (экспертов);

− моделирование рассуждений, содержащих неточные понятия.

Итак, можно сделать вывод, что в первом прототипе реализуется

(используется) простейшая процедура вывода. При его разработке основная

цель – получить решение задачи, не заботясь пока об эффективности.

После разработки первого прототипа необходимо расширить круг

задач, решаемых системой, для того, чтобы собрать пожелания и замечания,

которые будут учтены в очередной версии системы (ЭС-2). Для этого

осуществляется развитие ЭС-1 путем добавления:

− дружественного интерфейса;

− средств для исследования как БЗ, так и цепочек вывода,

генерируемых системой (что обеспечивает прозрачность и

понимаемость системы разработчиками);

− средств для сбора замечаний пользователей;

− средств хранения библиотеки задач, решенных системой.

Библиотека необходима для того, чтобы при каждой модификации

системы можно было проверить, решаются ли все старые задачи и в новой

версии. Расширенная ЭС-1 может рассматриваться как исследовательский

прототип ЭС.

В ходе приобретения знаний инженер по знаниям должен получить

знания от эксперта, структурировать их и представить в виде, понятном ЭС.

Процесс извлечения знаний сложен и длителен, так как эксперт часто или не

осознает какими знаниями он пользуется, или не может их вербализовать.

Для достижения эффективного функционирования ЭС необходимо

осуществить структурирование знаний. Наиболее важными для этого

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

эти понятия могут явно не упоминаться (не осознаваться) экспертом.

Инженер по знаниям должен выделить эти понятия, обнаружив сходные

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

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

следует уделять двум ситуациям: 1) некоторое правило слишком громоздко;

2) имеется слишком много похожих правил.

Громоздкость правила может объясняться тем, что в нем отражено

несколько фактов из данной предметной области. Если так, то правило надо

разбить на несколько более мелких. Вторая ситуация возникает тогда, когда в

проблемной области существует понятие, явно не указанное экспертом, а

возможно, и не имеющее имени. В этом случае новое понятие необходимо