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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Фреймы

• ООП

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

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

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

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

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

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

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

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

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

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

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

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

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

Выделяют:

№ п/п	Наименование прототипа ЭС	Описание
1	Демонстрационный	Решает часть требуемых задач, демонстрирует жизнеспособность подхода (несколько десятков правил и понятий)
2	Исследовательский	Решает большинство поставленных задач, но неустойчив в работе и не полностью проверен (несколько сотен правил или понятий)
3	Действующий	Решает надежно все задачи на реальных примерах, но для сложной задачи требует больших затрат ресурсов: времени и памяти
4	Промышленная ЭС	Обеспечивает высокое качество решения при минимальных затратах времени и памяти,- переписывается с использованием более эффективных средств представления знаний
5	Коммерческая ЭС	Промышленная система, пригодная к продаже, то есть хорошо документированная и снабженная сервисным обслуживанием.

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

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

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

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

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

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

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

Приложение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• диаграммы "сущность-связь";

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

• диаграммы "состояния-переходы".

13