Экспертная Система для выбора архитектуры Колл-Центра

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

Оглавление

Введение 2
1 Анализ исходных данных 5
2 Разработка ЭС для выбора архитектуры Колл-Центра. 44
3 Реализация ЭС. 51
4 Анализ полученных результатов 63
Список использованных источников 64

Введение
При создании контакт-центра перед любой компанией неизменно встает вопрос, делать ли его своими силами или пользоваться услугами стороннего ЦОВ. В первую очередь, выбор определяют количественные показатели, например, минимизация затрат. Однако большое значение имеют и так называемые качественные факторы, которые могут склонить компанию в пользу принятия того или иного решения.
Спор о том, делать самим или отдать "на сторону", возник не вчера, а, скорее, много веков назад при переходе от натурального хозяйства к рынку. В то время рост производительности труда и повышение его экономической эффективности стали возможны только после появления тех, которых сейчас называют "специалистами".
Экспертные системы – это направление исследований в области искусственного интеллекта по созданию вычислительных систем, умеющих принимать решения, схожие с решениями экспертов в заданной предметной области.
Как правило, экспертные системы создаются для решения практических задач в некоторых узкоспециализированных областях, где большую роль играют знания специалистов. Экспертные системы были первыми разработками, которые смогли привлечь большое внимание к результатам исследований в области искусственного интеллекта.
Экспертные системы имеют одно большое отличие от других систем искусственного интеллекта: они не предназначены для решения каких-то универсальных задач, экспертные системы предназначены для качественного решения задач в определенной разработчиками области, в редких случаях – областях [1].
Экспертное знание – это сочетание теоретического понимания проблемы и практических навыков ее решения, эффективность которых доказана в результате практической деятельности экспертов в данной области. Фундаментом экспертной системы любого типа является база знаний, которая составляется на основе экспертных знаний специалистов. Правильно выбранный эксперт и удачная формализация его знаний позволяет наделить экспертную систему уникальными и ценными знаниями. Поэтому ценность всей экспертной системы как законченного продукта на 90% определяется качеством созданной базы знаний.
Экспертная система – является плодом совместной работы экспертов в данной предметной области, инженеров по знаниям и программистов.
Но стоит отметить, что встречаются случаи, когда программы пишутся самими экспертами в данной области [2,3].
Эксперт предоставляет необходимые знания о тщательно отобранных примерах проблем и путей их решения. Например, при создании экспертной системы диагностики заболеваний врач рассказывает инженеру по знаниям об известных ему заболеваниях. Далее эксперт раскрывает список симптомов, которые сопровождают каждое заболевание и в заключение рассказывает об известных ему методах лечения. Инженер по знаниям, формализует всю полученную информацию в виде базы знаний и помогает программисту в написании экспертной системы.
Особенности экспертных систем, отличающие их от обычных программ, заключаются в том, что они должны обладать следующими качествами.
1. Компетентностью, а именно:
• достигать экспертного уровня решений, т.е. в конкретной предметной области иметь тот же уровень профессионализма, что и эксперты-люди;
• быть умелой, т.е. применять знания эффективно и быстро, избегая, как и люди, ненужных вычислений;
• иметь адекватную робастность, т.е. способность лишь постепенно снижать качество работы по мере приближения к границам диапазона компетентности или допустимой надёжности данных.
2. Возможностью к символьным рассуждениям, а именно:
• представлять знания в символьном виде;
• переформулировать символьные знания. На языке искусственного интеллекта символ – это строка знаков, соответствующая содержанию некоторого понятия. Символы объединяют, чтобы выразить отношения между ними. Когда отношения представлены в экспертной системе они называются символьными структурами.
3. Глубиной, а именно:
• работать в предметной области, содержащей трудные задачи;
• использовать сложные правила, т.е. использовать либо сложные конструкции правил, либо большое их количество.
4. Самосознанием, а именно:
• исследовать свои рассуждения, т.е. проверять их правильность;
• объяснять свои действия.
Существует ещё одна важная особенность экспертных систем. Если обычные программы разрабатываются так, чтобы каждый раз порождать правильный результат, то экспертные системы разработаны с тем, чтобы вести себя как эксперты. Они, как правило, дают правильные ответы, но иногда, как и люди, способны ошибаться.

5. Обслуживание. Под этим процессом понимают корректировку формализованных данных и знаний.
Рассмотренная выше классификация не является единственной.
Системы ОMIS (Оrgаnizаtiоnаl Mеmоrу Infоrmаtiоn Sуstеm) .
Это автоматизированные системы, предназначенные для управления и накопления знаний предприятия. Такие системы обеспечивают работу, как на первом, так и на втором уровне и часто используют вспомогательные справочные системы.
Основные функции ОMIS:
Сбор и систематическая организация информации из различных источников в централизованное и структурированное хранилище.
Организация интеграции с существующими автоматизированными системами.
Обеспечение нужной информации по запросу и при необходимости.
Конечная цель ОMIS состоит в том, чтобы в случае необходимости обеспечить быстрый доступ к знанию. Законченная система должна действовать, как интеллектуальный помощник пользователю то есть должна иметь подсистему объяснений, а именно отвечать на вопросы «Как?», «Почему?» и так далее. Так же система должна всегда быть готовой к восприятию новой информации от пользователя. Ядром системы должно быть информационное хранилище. Программный инструментарий для ОMIS включает оригинальные разработки, например KАRАT, и стандартные средства типа LОTUS NОTЕS, используется и Wеb-технология.
Особенности разработки ОMIS.
При разработке ОMIS необходимо учитывать следующие факторы:
Человеческий фактор. Нужно учитывать реальные потребности пользователей и их цели.
Стоимостной анализ. Ядро проекта должно ориентироваться на критические процессы, страдающие от недостатка информации.
Чувствительность к контексту запросов. Система должна различать термины «размножение животных» и «размножение документов».
Гибкость. Система должна обрабатывать знания в различной форме и по разным темам.
Интеллектуальность. Система должна накапливать информацию о своих пользователях и со временем самосовершенствоваться.
Визуальное проектирование баз знаний.
Визуальное проектирование является важным и достаточно эффективным инструментом познания. Методы визуальной инженерии могут применяться для углубления процесса понимания, как в школах, так и в высших учебных заведениях. Существует много систем поддерживающих визуальное проектирование. Одна из них это система KЕW – автоматизированное рабочее место инженера по знаниям. Последняя версия KЕW,созданная совместно с Воиновым А.В., предназначена для поддержки деятельности инженера познаниям на протяжении всего цикла разработки экспертной системы, включая стадии идентификации, получения, структурирования, формализации и программной реализации знаний. Центральным блоком системы является графический структуризатор знаний. Система KNОST поддерживает последовательную графическую реализацию специального алгоритма со структурированным подходом, названным ОСА и автоматическую компиляцию БЗ из графической информации.
Интерфейс KNОST состоит из трех основных частей:
Панель концептуальной структуры. Эта панель предназначена для графического структурирования знаний. Она позволяет выделить понятия и обозначить связи между ними в форме структуры Sk.
Панель гипертекста. Сюда включаются любой комментарий, связанный с графическим объектом.
Панель функциональной структуры Sf . Здесь наглядно представляется в форме строк и столбцов таблицы причинно-следственные и другие функциональные взаимосвязи между объектами. Таблица формируется операцией drаg-аnd-drор.
После того как модели Sk и Sf , созданы система автоматически компилирует базу знаний на Прологе и моделирует работу экспертной системы. Это очень удобно для быстрого и наглядного прототипирования ЭС и для отладки БЗ совместно с экспертом.
Языки программирования для ИИ и языки представления знаний.
Необходимость использования средств автоматизации программирования прикладных систем ориентированных на знания, и в частности ЭС, была осознана разработчиками достаточно давно. По существу, средства поддержки разработки интеллектуальных систем прошли в своем развитии основные стадии характерные для автоматизации программирования:
Автокоды  языки высокого уровня  языки сверхвысокого уровня  языки спецификаций.
До недавнего времени наиболее популярным базовым языком реализации систем ИИ вообще был ЛИСП. Как известно ЛИСП был разработан в Стэнфорде под руководством Дж. Маккарти в начале 60-х годов и не предназначался для программирования задач по ИИ. По первоначальным замыслам новый язык должен был иметь средства работы с матрицами, указателями, структурами из указателей и так далее. Первоначальные версии должны были быть интерпретирующими, но в дальнейшем предполагали создать компиляторы. Как отмечает сам автор на реализацию столь амбициозного проекта средств не хватило. К моменту создания первых ЛИСП интерпретаторов окончательно сформировались принципы, положенные в основу языка ЛИСП: использование единого спискового представления для программ и данных; применение выражений для определения функций; скобочный синтаксис языка. Процесс разработки языка завершился созданием версии ЛИСП 1.5, которая на многие годы определила пути его развития. К концу 80-х годов ЛИСП был реализован на всех классах ЭВМ, начиная с персональных компьютеров и кончая высокопроизводительными системами. Новый толчок к развитию ЛИСПА дало создание первых ЛИСП-машин. ЛИСП не единственный язык для ИИ. Есть, по крайней мере, два конкурента: СНОБОЛ, разработанный в лабораториях Белла и РЕФАЛ, созданный в ИПМ АН СССР. Первый из них это язык обработки строк, в рамках которого впервые появилась и была реализована в достаточно полной мере концепция поиска по образцу. С позиций сегодняшнего дня можно сказать, что СНОБОЛ был одной из первых практических реализаций развитой продукционной системы. Наиболее интересная реализация СНОБОЛ-4, в которой техника задания образцов и работа с ними существенно определили потребности практики. Это и политика активного внедрения Лиспа помешали широкому использованию СНОБОЛа в практике ИИ. В основу языка РЕФАЛ положено понятие рекурсивной функции определенной на множестве произвольных символьных выражений. Базовой структурой языка являются списки, но не односвязные Лиспа, а двусвязные.
При этом активно используется концепция поиска по образцу характерная для СНОБОЛА. РЕФАЛ вобрал в себя лучшие черты наиболее интересных языков обработки символьной информации 60-х годов. Реализован РЕФАЛ на всех типах ЭВМ и активно используется для автоматизации построения трансляторов и систем аналитических преобразований, а так же в качестве языка представления знаний. В начале 70-х годов появился ещё один язык способный составить конкуренцию Лиспу при реализации систем основанных на знаниях – ПРОЛОГ. Он не дает новых сверх мощных средств программирования, но поддерживает новую модель организации вычислений. ПРОЛОГ позволяет не заботиться о потоке выполнения в программе. Решаемая на Прологе задача представляется в виде слабо структурированной совокупности отношений. Это удобно если число отношений не слишком велико и каждое описывается небольшим числом альтернатив. В противном случае ПРОЛОГ-программа становится сложной для понимания и модификации. ПРОЛОГ разработан в Марсельском университете в 1971 году, но популярность стал приобретать лишь, после того как в начале 80-х годов математики обосновали логический базис языка, а также в силу того, что ПРОЛОГ был выбран в качестве базового для машины вывода в японском проекте вычислительных систем 5 поколения.
В 70-х годах в программировании вообще и в программировании задач ИИ в частности, центр тяжести стал смещаться от процедурных к декларативным описаниям. Один из многочисленных языков реализующих эту концепцию стал ОРS5, который претендовал на роль языка стандарта в области представления знаний для ЭС.
Wоrkbеnсh-системы.
Системы типа Wоrkbеnсh в контексте автоматизации программирования это интегрированные инструментальные системы, поддерживающие весь цикл создания и сопровождения программ.
К основным характеристикам Wоrkbеnсh-систем относятся:
Использование определенной технологии проектирования на протяжении всего жизненного цикла целевого продукта.
Вертикальная интеграция инструментальных средств, обеспечивающая связи и совместимость по данным между различными инструментами, используемыми на разных стадиях разработки.
Горизонтальная интеграция моделей и методов, используемых на одной стадии проектирования.
Сбалансированность инструментария, то есть отсутствие дублирующих компонентов, необходимость и достаточность каждого из них.
В качестве примеров Wоrkbеnсh-систем можно указать системы KЕАTS и Shеllу, которые поддерживают анализ, проектирование, кодирование знаний на ЯПЗ, проверку и верификацию, поддержку и отладку.
2 Разработка ЭС для выбора архитектуры Колл-Центра.
В настоящее время сложилась определенная технология разработки ЭС, которая включает следующие шесть этапов: идентификация, концептуализация, формализация, выполнение, тестирование и опытная эксплуатация. На рисунке 3 приведена подробная схема создание экспертных систем.
Обычно в разработке экспертной системы участвуют не менее трех-четырех человек – один эксперт, один или два инженера по знаниям и один программист, привлекаемый для модификации и согласования инструментальных средств. Также к процессу разработки экспертной системы могут по мере необходимости привлекаться и другие участники. Например, инженер по знаниям может пригласить других экспертов, чтобы убедиться в правильности своего понимания основного эксперта, представительности тестов, демонстрирующих особенности рассматриваемой задачи, совпадения взглядов различных экспертов на качество предлагаемых решений. Кроме того, для сложных систем считается целесообразным привлекать к основному циклу разработки несколько экспертов. Однако в этом случае, как правило, требуется, чтобы один из экспертов отвечал за непротиворечивость знаний, сообщаемых коллективом экспертов.
Рис. 3. Этапы разработки экспертных систем
1. Этап идентификации.
Этап идентификации связан, прежде всего, с осмыслением тех задач, которые предстоит решить будущей экспертной системе, и формированием требований к ней. Результатом данного этапа является ответ на вопрос, что надо сделать и какие ресурсы необходимо задействовать (идентификация задачи, определение участников процесса проектирования и их роли, выявление ресурсов и целей).
Идентификация задачи заключается в составлении неформального (вербального) описания, в котором указываются:
общие характеристики задачи;
подзадачи, выделяемые внутри данной задачи;
ключевые понятия (объекты), их входные (выходные) данные;
предположительный вид решения;
знания, относящиеся к решаемой задаче.
В процессе идентификации задачи инженер по знаниям и эксперт работают в тесном контакте. Начальное неформальное описание задачи экспертом используется инженером по знаниям для уточнения терминов и ключевых понятий. Эксперт корректирует описание задачи, объясняет, как решать ее и какие рассуждения лежат в основе того или иного решения. После нескольких циклов, уточняющих описание, эксперт и инженер по знаниям получают окончательное неформальное описание задачи.
При идентификации целей важно отличать цели, ради которых создается экспертная система, от задач, которые она должна решать. Примерами возможных целей являются: формализация неформальных знаний экспертов; улучшение качества решений, принимаемых экспертом; автоматизация рутинных аспектов работы эксперта (пользователя); тиражирование знаний эксперта.
2. Этап концептуализации.
На данном этапе проводится содержательный анализ проблемной области, выявляются используемые понятия и их взаимосвязи, определяются методы решения задач. Этот этап завершается созданием модели предметной области, включающей основные концепты и отношения. На этапе концептуализации определяются следующие особенности задачи:
типы доступных данных;
исходные и выводимые данные, подзадачи общей задачи;
используемые стратегии и гипотезы;
виды взаимосвязей между объектами предметной области, типы используемых отношений (иерархия, причина – следствие, часть – целое и т.п.);
процессы, используемые в ходе решения;
состав знаний, используемых при решении задачи;
типы ограничений, накладываемых на процессы, используемые в ходе решения;
состав знаний, используемых для обоснования решений.
Существует два подхода к процессу построения модели предметной области, которая является целью разработчиков экспертных систем на этапе концептуализации: признаковый и структурный.
Признаковый или атрибутивный подход предполагает наличие полученной от экспертов информации в виде троек объект – атрибут – значение атрибута, а также наличие обучающей информации. Этот подход развивается в рамках направления, получившего название формирование знаний или «машинное обучение».
Второй подход, называемый структурным (или когнитивным), осуществляется путем выделения элементов предметной области, их взаимосвязей и семантических отношений.
3. Этап формализации.
Теперь все ключевые понятия и отношения выражаются на некотором формальном языке, который либо выбирается из числа уже существующих, либо создается заново. Другими словами, на данном этапе определяются состав средств и способы представления декларативных и процедурных знаний, осуществляется это представление и в итоге формируется описание решения задачи экспертной системы на предложенном (инженером по знаниям) формальном языке.
Выходом этапа формализации является описание того, как рассматриваемая задача может быть представлена в выбранном или разработанном формализме. Сюда относится указание способов представления знаний (фреймы, сценарии, семантические сети и т.д.) и определение способов манипулирования этими знаниями (логический вывод, аналитическая модель, статистическая модель и др.) и интерпретации знаний.
4. Этап выполнения.
Цель этого этапа – создание одного или нескольких прототипов экспертной системы, решающих требуемые задачи. Затем на данном этапе по результатам тестирования и опытной эксплуатации создается конечный продукт, пригодный для промышленного использования. Разработка прототипа состоит в программировании его компонентов или выборе их из известных инструментальных средств и наполнении базы знаний.
Главное в создании прототипа заключается в том, чтобы этот прототип обеспечил проверку адекватности идей, методов и способов представления знаний решаемым задачам. Создание первого прототипа должно подтвердить, что выбранные методы решений и способы представления пригодны для успешного решения, по крайней мере, ряда задач из актуальной предметной области, а также продемонстрировать тенденцию к получению высококачественных и эффективных решений для всех задач предметной области по мере увеличения объема знаний [3,10].
5. Этап тестирования.
В ходе данного этапа производится оценка выбранного способа представления знаний в экспертной системе в целом. Для этого инженер по знаниям подбирает примеры, обеспечивающие проверку всех возможностей разработанной системы.
Различают следующие источники неудач в работе системы: тестовые примеры, ввод-вывод, правила вывода, управляющие стратегии.
Показательные тестовые примеры являются наиболее очевидной причиной неудачной работы экспертной системы. В худшем случае тестовые примеры могут оказаться вообще вне предметной области, на которую рассчитана система, однако чаще множество тестовых примеров оказывается слишком однородным и не охватывает всю предметную область. Поэтому при подготовке тестовых примеров следует классифицировать их по подпроблемам предметной области, выделяя стандартные случаи, определяя границы трудных ситуаций и т.п.
Ввод-вывод характеризуется данными, приобретенными в ходе диалога с экспертом, и заключениями, предъявленными экспертной системой в ходе объяснений. Методы приобретения данных могут не давать требуемых результатов, так как, например, задавались неправильные вопросы или собрана не вся необходимая информация. Кроме того, вопросы системы могут быть трудными для понимания, многозначными и не соответствующими знаниям пользователя. Ошибки при вводе могут возникать также из-за неудобного для пользователя входного языка. В ряде приложения для пользователя удобен ввод не только в печатной, но и в графической или звуковой форме.
Выходные сообщения (заключения) системы могут оказаться непонятны пользователю (эксперту) по разным причинам. Например, их может быть слишком много или, наоборот, слишком мало. Также причиной ошибок может являться неудачная организация, упорядоченность заключений или неподходящий пользователю уровень абстракций с непонятной ему лексикой.
Наиболее распространенный источник ошибок в рассуждениях касается правил вывода. Важная причина здесь часто кроется в отсутствии учета взаимозависимости сформированных правил. Другая причина заключается в ошибочности, противоречивости и неполноте используемых правил. Если неверна посылка правила, то это может привести к употреблению правила в неподходящем контексте. Если ошибочно действие правила, то трудно предсказать конечный результат. Правило может быть ошибочно, если при корректности его условия и действия нарушено соответствие между ними.
Нередко к ошибкам в работе ЭС приводят применяемые управляющие стратегии. Изменение стратегии бывает необходимо, например, если экспертная система анализирует сущности в порядке, отличном от привычного для эксперта. Последовательность, в которой рассматриваются данные, не только влияет на эффективность работы системы, но и может приводить к изменению конечного результата. Изменение стратегии бывает также необходимо и в случае неэффективной работы системы. Кроме того, недостатки в управляющих стратегиях могут привести к чрезмерно сложным заключениям и объяснениям.
Критерии оценки ЭС зависят от точки зрения. Например, полнота и безошибочность правил вывода. При тестировании промышленной системы превалирует точка зрения инженера по знаниям, которого в первую очередь интересует вопрос оптимизации представления и манипулирования знаниями. И, наконец, при тестировании после опытной эксплуатации оценка производится с точки зрения пользователя, заинтересованного в удобстве работы и получения практической пользы
6. Этап опытной эксплуатации.
На этом этапе проверяется пригодность экспертной системы для конечного пользователя. Пригодность для пользователя определяется в основном удобством работы с ней и ее полезностью. Под полезностью системы понимается ее способность в ходе диалога определять потребности пользователя, выявлять и устранять причины неудач в работе, а также удовлетворять указанные потребности пользователя (решать поставленные задачи). В свою очередь, удобство работы с экспертной системой подразумевает:
естественность взаимодействия – общение в привычном, не утомляющем пользователя виде;
гибкость – способность системы настраиваться на различных пользователей, а также учитывать изменения в квалификации одного и того же пользователя;
устойчивость к ошибкам – способность не выходить из строя при ошибочных действиях неопытного пользователях.
В ходе разработки экспертной системы почти всегда осуществляется ее модификация. Выделяют следующие виды модификации системы:
переформулирование понятий и требований;
переконструирование представления знаний в системе и усовершенствование прототипа.
3 Реализация ЭС.
В качестве внутреннего языка для данной работы был выбран ОbjесtРаsсаl, который используется в среде программирования Dеlрhi. Этот язык использует принципы объектно-ориентированного и визуального программирования.
Язык ОbjесtРаsсаl является одним из высокоразвитых языков объектно-ориентированного программирования. И среди других, например, таких как Visuаl Bаsiс или Visuаl С++, отличается простотой программного кода, достаточным количеством литературы по этому языку.
Объектно-ориентированное программирование (ООП) — это методика разработки программ, в основе которой лежит понятие объект. Объект — это некоторая структура, соответствующая объекту реального мира, его поведению. Задача, решаемая с использованием методики ООП, описывается в терминах объектов и операций над ними, а программа при таком подходе представляет собой набор объектов и связей между ними [7].