Поддержка искусственным интеллектом

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

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

В практике Cleverics в последние годы эта задача в основном решается внедрением сервисных порталов. Структурирование каталога запросов в максимально удобном для пользователя виде позволяет обеспечить корректную классификацию в 75-80% случаев, что не уступает качеству классификации силами первой линии поддержки при меньших трудозатратах. Кроме того, сервисный портал обеспечивает возможность индивидуальной настройки формы обращения в зависимости от выбранной классификации. Таким образом, сервисные порталы дополнительно повышают скорость обработки запросов и за счет устранения задержки в обработке запросов на первой линии (особенно в случае регистрации запросов на основании обращений e-mail), и за счет существенного сокращения потерь времени на получение от пользователя информации, необходимой для обработки его запроса. Поэтому сервисные порталы весьма востребованы – у нас есть несколько клиентов, которые довели долю запросов, поступающих через портал, до 85-90%, а электронную почту, как канал поступления новых запросов, использовать перестали.

Однако в последнее время в общении с коллегами мы видим попытки решения задачи классификации принципиально другим способом – при помощи искусственного интеллекта. Решение по классификации получает на вход произвольный текст запроса, выполняет очистку текста от лишней информации, не нужной для классификации (приветствий и прощаний, ip-адресов и персональной информации, предлогов и вводных слов, разных чисел и падежей), и передает его нейронной сети, которая выдает идентификатор соответствующего элемента классификатора. Такие решения позволяют сохранить точность классификации на уровне 80%, сократив при этом время на классификацию с 30-50 секунд до 2-3 (при этом размер классификатора в известных мне примерах составляет 1 700-2 000 элементов). Там, где подачу запросов по электронной почте «не победить», такой способ классификации может обеспечить прямой экономический эффект за счет сокращения трудозатрат первой линии. Например, если первая линия обрабатывает 1 000 запросов в день, экономия в 40 секунд на классификацию одного запроса приводит к высвобождению 1 000 * 22 * 40 / 3 600 = 244 часа в месяц, что эквивалентно 1,5 FTE или сокращению затрат примерно на 5%. Причем, чем больше входной поток, тем больше экономический эффект и быстрее процесс обучения нейронной сети. Кроме того, такая технология, с теми или иными доработками, способна справляться с классификацией запросов, поданных голосом или в виде скриншотов.

Как вам идея? Какой способ победит? Кто использовал искусственный интеллект на практике и каковы ваши результаты?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Антон Боганов

    Пока разбор и классификация заявок реализовывались в СЭД, когда анализировались докладные и служебник, тамне. Система не смогла понять куда направить инцидент на производстве — главный инженер ушёл в лес и ... повесился... завершенных продуктов для функции Help Desk особо-то и не встречается. Может что посоветуете?  В вот отойти от запросов по электронной почте можно и командным способом.

  2. михаил

    У меня есть рабочий прототип классификатора инцидентов на базе machine learning, заточенный под определенного заказчика, и обученный на большой выборке реальных email писем в хелпдеск. Классификация выполняется сразу по нескольким свойствам — тип запроса (инцидент или запрос на обслуживание), важность (4 градации), операционная категория (порядка 20 категорий), продуктовая категория (более 500 категорий).

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

    Проблема в том, что когда мы решили похвастаться перед заказчиком данным результатом, оказалось, что точность первичной классификации инцидентов из почты человеками у них составляет ... более 98%! Как они этого добились? Дело в том, что точность первичной классификации является KPI и влияет на деньги. И если текст письма не позволяет достоверно определить классификацию инцидента, то человеки поднимают трубку телефона, дозваниваются до инициатора и таки добывают из него необходимую информацию для точной классификации.

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

      1. михаил

        Архитектурно — это веб-сервис, поддерживающий rest-json и soap вызовы.

        "Унутре у него" — нет, не неонка, а модель, подготовленная с помощью библиотеки scikit-learn. Фичи для анализа — нормализированный (слова приводятся в нормальную форму: позеленевший => позеленеть) текст email сообщений, векторизированный методом TF-IDF.

        Для моделирования типов классификаций используются различные алгоритмы: для типов с малой вариативностью — random forest, с большой вариативностью — SGD. Параметры алгоритмов подобраны "на глазок".

        Для целей POC точность предикта 85% — более чем обнадеживающий, КМК.

        Конечно же, есть мысли, как можно улучшить результаты — можно (нужно!) чистить email сообщения от малорелевантного "мусора" — подписи, заголовки форвардов или реплаев, приветствия. Дополнить анализируемые фичи адресом и свойствами отправителя (регион, подразделение). Использовать мета-алгоримты для подбора наиболее подходящих алгоритмов, параметров алгоритмов и наиболее репрезентативных фич. Но это уже уровень проработки продукта, а не POC, а до него я так и не дошел...

        1. Сергей

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

  3. Илья Рунов

    На мой взгляд портал даст лучше результаты, когда:

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

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

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

    нельзя использовать ранее «обученную» другим заказчиком систему для нового заказчика (если это вообще технически возможно)

  4. Андрей

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

    Скажем, если достаточно хорошо "надрессировать" алгоритм машинного обучения (будь то нейронная сеть или что-то другое), то вполне можно получить автомат, который доведет до 90+% количество верно адресованных заявок. 

  5. Александр

    Используем в компании такой метод (обучение с учителем) для классификации сообщений, приходящих по электронной почте. Уровень точности, в районе 85%-90%, что значительно превышает точность классификации незамотивированным человеком. Согласен с коллегой, который говорил, что человек может достичь уровня точности классификации около 99% , если будет уточнять у заяителя.

    По поводу алгоритмов 🙂 Как бы не было смешно, из многих алгоритмов, которые были мною опробованы — наивный Байес "рулит" ! Есть несколько способов для его оптимизации, которые приближают его к SVC, например взвешивание с помощью TF-SLF вместо TF-IDF (к сожалению не реализовано в scikit-learn), но учитывая его скорость , считаю, что в данном случае, он самый предпочтитетльный. Нейронная сеть это игрушка -не думаю, что у кого-то есть достаточный dataset для ее обучения. Это более 100K примеров, на меньшем количестве она проигравает многим алгоритмам, а учитывая скорость обучения...

     

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Empty