4.5.3. Структура эс

Суть ЭС как человеко-машинной системы легче всего объяснить, показав ее структуру (рис. 4.3).

Рис. 4.3. Структура ЭС

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

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

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

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

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

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

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

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

4.5.4.1. Коллектив разработчиков

Минимальный состав коллектива: пользователь, эксперт, инженер по знаниям (аналитик), программист. Реальный коллектив разработчиков – 8 – 10 человек. Причины увеличения коллектива разработчиков:

1. Необходимость учета мнения нескольких пользователей.

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

3. Потребность в программистах различной специализации (проблемных, системных и пр.).

Дополнительные челны коллектива – менеджер и технический помощник.

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

Основные свойства пользователя:

1. Дружелюбие.

2. Умение объяснять.

3. Отсутствие психологического барьера к применению вычислительной техники.

4. Интерес к новому.

Основные свойства эксперта:

1. Доброжелательность.

2. Готовность поделиться своим опытом.

3. Умение объяснять.

4. Заинтересованность в успешности разработки.

Основные свойства программиста:

1. Общительность.

2. Способность отказаться от традиционных навыков и освоить новые методы.

3. Интерес к разработке.

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

Основные свойства инженера по знаниям:

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

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

Для аналитика важен стиль общения. Рекомендуются внимательность, ненавязчивость, умение слушать и задавать вопросы, коммуникабельность и уверенность в себе.

Инженер по знаниям работает со всеми формами знаний:

Z1 – знания в памяти;

Z2 – знания в книгах;

Z3 – поле знаний;

Z4 – модель знаний;

Z5 – база знаний.

Z1 требует от инженера по знаниям знакомства с:

1. Элементами когнитивной психологии.

2. Способами репрезентации понятий и процессов в памяти человека.

3. Основными механизмами мышления – логическим и ассоциативным.

4. Способами активизации мышления (игры, мозговой штурм и т.п.).

5. Различными моделями рассуждений.

Z2 подразумевает:

1. Широкую общенаучную подготовку.

2. Знакомство с методами реферирования и аннотирования текстов.

3. Владение навыками быстрого чтения.

4. Владение текстологическими методами извлечения знаний.

Z3 требует знакомства с:

1. Методологией представления знаний.

2. Системным анализом.

3. Теорией познания.

4. Аппаратом многомерного шкалирования, кластерным и факторным анализом.

Z4 требует владения:

1. Аппаратом математической логики.

2. Современными языками представления знаний.

3. Методологией разработки ЭС, включая методы быстрого прототипирования.

Z5 требует владения:

1. Практическими навыками работы на ЭВМ.

2. Возможно, одним из языков программирования.

4.5.4.2. Проблемы разработки промышленных ЭС

Этапы процесса разработки ЭС:

1. Выбор проблемы.

2. Разработка прототипа ЭС.

3. Доработка до промышленной ЭС.

4. Оценка ЭС.

5. Стыковка ЭС.

6. Поддержка ЭС.

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

• организация сложных расчетов;

• работа с компьютерной графикой;

• обработка текстов;

• автоматизированный документооборот.

Практика решения задач такого рода:

1. подготавливает высококвалифицированных разработчиков;

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

4.5.4.3. Этап выбора проблемы

Этот этап включает:

• определение проблемной области и задачи;

• нахождение эксперта и назначение коллектива разработчиков;

• определение предварительного подхода к решению проблемы;

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

• подготовку подробного плана разработки.

Последствия неправильного выбора проблемы:

1. Перегруженность проекта задачами, не имеющими традиционных решений.

2. Создание экспертной системы, неэффективной экономически.

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

Эта фаза наиболее приемлема для получения рекомендаций извне.

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

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

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

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

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

4.5.4.4. Этап прототипирования

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

Объем прототипа, как правило, – несколько десятков правил, фреймов или примеров.

Стадии разработки прототипа:

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

• необходимые ресурсы (кадровые, технические, временные и т.д.);

• источники знаний (книги, дополнительные эксперты, методики);

• имеющиеся аналоги разработки;

• цели разработки;

• классы решаемых задач.

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

Структурирование или концептуализация знаний (2 – 4 недели) – разработка неформального описания знаний о предметной области в виде графа, таблицы, диаграммы или текста, которое отражает основные концепции и взаимосвязи между понятиями предметной области. Определяются терминология, список основных понятий и атрибутов, отношения между ними, структура входной и выходной информации, стратегии принятия решений и т.д.

Формализация знаний (1 – 2 месяца) – разработка БЗ на ЯПЗ, который соответствует структуре поля знаний и позволит создать прототип системы. ЯПЗ основывается на одной из моделей представления знаний или их синтезе.

Реализация (1 – 2 месяца) – разработка программного комплекса, демонстрирующего жизнеспособность подхода. При реализации действующей ЭС первый прототип, как правило, отбрасывается. Способы разработки прототипа:

• использование традиционных языков и средств разработки (C, Pascal и пр.);

• использование специализированных языков, ориентированных на задачи ИИ (Lisp, SmallTalk, Prolog);

• использование инструментальных средств разработки ЭС (G2, ПИЭС);

• использование «пустых» ЭС или оболочек (ЭКСПЕРТ, ФИАКР).

Тестирование (1 – 2 недели) – выявление ошибок в подходе и реализации прототипа и выработка рекомендаций по доводке системы до промышленного варианта. Прототип проверяется на:

• удобство и адекватность интерфейсов ввода/вывода;

• эффективность стратегии управления;

• качество проверочных примеров;

• корректность БЗ.

4.5.4.5. Развитие прототипа до промышленной ЭС

Дополнительные этапы перехода:

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

Совершенствование БЗ на этапах от демонстрационного до действующего прототипа ведется в двух направлениях:

• увеличение «глубины» знаний (добавление новых знаний);

• добавление управляющих знаний о стратегиях и метазнаний.

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

4.5.4.6. Оценка системы

Оценка заключается в тестировании, к которому широко привлекаются эксперты со стороны. Критерии оценки:

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

• критерии экспертов (оценка решений, выдаваемых системой, оценка функционирования ее подсистем);

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

4.5.4.7. Стыковка системы

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