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

Лекция

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

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

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

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

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

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

1.1 Соответствия между основными этапами проекта RAD и стадиями технологии быстрого прототипирования

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

CASE (Computer Aided Software Engineering) — система автоматизированной разработки программ.

CASEтехнологияавтоматизированное проектирование систем с использованием специальных пакетов инструментальных средств, так называемых CASEсредств. CALS (Computer Aided Acquisition and Logistics Support) — стандарт CALS, автоматизированная поддержка принятия решений по приобретению (изделий) и материальнотехнического обеспечения.

Развитие технологии RAD с акцентом на групповую разработку приложений привело к появлению JAD- (Joint Application Development) в условиях ограниченных сроков. Технология JAD была разработана фирмой IBM в начале 80-х годов для быстрой разработки спецификаций и требований к программным системам.

Основными рабочими продуктами RAD в порядке их формирования являются бизнес-модель, модель данных и функциональная модель.

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

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

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

1.2 О возможности и оправданности применения технологий инженерии знаний для построения систем основанных на знаниях

2. Технология быстрого прототипирования

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

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

2.1 Идентификация проблемы

Идентификация проблемыознакомление (обучение) членов коллектива разработчиков и создание предварительной (неформальной) формулировки проблемы.

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

· необходимые ресурсы (время, люди, ЭВМ, и т. п.);

· источники знаний (книги, эксперты);

· имеющиеся аналогичные экспертные системы;

· цели (распространение опыта, автоматизация рутинных действий);

· подклассы решаемых задач…

В дальнейшем начинается разработка БЗ.

2.2 Получение знаний

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

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

q Анализируется литература экспертов (текстологический метод):

§ Формируется «черновик» по предметной области;

§ Составляется вопросответная структура для БЗ;

q Используется анкетирование (активный индивидуальный коммуникативный метод):

§ Формируется анкета в соответствии с БЗ;

§ Эксперт заполняет анкету;

§ Аналитиком проводится анализ ответов эксперта;

q В режиме интервью, диалога или игры (активные индивидуальные коммуникативные методы):

§ Эксперт и аналитик проводят совместный анализ материалов;

§ Исправляются ошибки в БЗ.

q Инженер по знаниям вносит исправления.

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

2.3 Концептуализация и структурирование знаний

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

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

· Терминология;

· Список основных понятий и атрибутов;

· Отношения между понятиями

· Структура входной и выходной информации;

· Стратегии приятия решений;

· Ограничения стратегий.

2.4 Формализация знаний

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

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

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

· Логические модели (исчисление предикатами 1-го порядка)

· Продукционные модели (прямой, обратный вывод);

· Семантические сети

· Фреймы

· ООП

2.5 Реализация (выполнение)

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

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

· Программирование на высокоуровневых языках: C++, Pascal;

· Программирование на специализированных языках ИИ: LISP.

· Использование инструментальных средств разработки ЭС: G2.

· Использование «пустышек» и «оболочек» ЭС: Exsys, Kappa.

2.6 Опытная эксплуатация

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

2.7 Тестирование (диагностика)

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

2.8 Получение результата в виде прототипа

Технология гарантированно обеспечивает получение прототипа как результата разработки.

Выделяют:

2.9 Оценка, стыковка, сопровождение системы

Оценкапосле получения промышленной ЭС осуществляется анализ эффективности с использованием:

· Критерии пользователей (понятность, прозрачность, удобство интерфейсных компонентов в процессе эксплуатации);

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

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

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

Поддержкаобслуживание системы в процессе эксплуатации с целью поддержания и повышения ее функционирования.

Приложение

1. Идентификация проблемы

На этапе идентификации определяются задачи, участники процесса разработки и их роли, ресурсы и цели. Определение участников и их ролей сводится к определению количества экспертов и инженеров по знаниям, а также формы их взаимоотношений. Обычно в основном цикле разработки ЭС участвуют не менее трех-четырех человек (один эксперт, один или два инженера по знаниям и один программист, привлекаемый для модификации и согласования инструментальных средств). К процессу разработки ЭС могут привлекаться и другие участники. Например, инженер по знаниям может привлекать других экспертов для того, чтобы убедиться в правильности своего понимания основного эксперта; представительности тестов, демонстрирующих особенности рассматриваемой задачи; совпадении взглядов различных экспертов на качество предлагаемых решений. Формы взаимоотношений экспертов и инженеров следующие: эксперт исполняет роль информирующего или эксперт выполняет роль учителя, а инженер — ученика. По нашему мнению, форма «учитель — ученик» больше соответствует методологии ЭС. Вне зависимости от выбранной формы взаимоотношений инженер по знаниям должен быть готов и способен изучать специфические особенности той проблемной области, в рамках которой предстоит работать создаваемой ЭС. Несмотря на то, что основу знаний ЭС будут составлять знания эксперта, для достижения успеха инженер по знаниям должен использовать дополнительные источники знаний в виде книг, инструкций, которые ему рекомендовал эксперт.

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

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

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

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

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

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

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

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

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

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

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

Адекватным средством для выделения ключевых понятий, отношений и характеристик являются диаграммы, которые используют практически все современные ИС.

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

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

К числу базовых типов диаграмм относятся:

· контекстные диаграммы (структурно-функциональные схемы);

· диаграммы «сущность-связь» ;

· диаграммы потоков данных;

· диаграммы «состояния-переходы» .