Автор Шьям Шинде

Платформа обслуживания клиентов Helpshift используется такими компаниями, как Epic Games, Microsoft и Zynga, для получения заявок в службу поддержки от своих пользователей через мобильные приложения, веб-чат и электронную почту. Ежедневно на платформе поступают сообщения о тысячах новых билетов от более чем 2000 клиентов и 2+ миллиардов конечных пользователей по всему миру. Каждая хорошая компания хочет, чтобы ее заявки в службу поддержки были решены как можно скорее. Чтобы добиться такого быстрого оборота, необходимо, чтобы заявка была доставлена ​​правильному агенту, который лучше всех умеет ее обрабатывать. Следовательно, классификация билетов и их маршрутизация - две важные функции для достижения стратегии эффективности обслуживания клиентов.

Как сегодня проводится классификация билетов?

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

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

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

Какие проблемы возникают при создании автоматической классификации билетов?

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

Проблемы при построении такой системы классификации состоят в следующем:

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

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

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

Как выглядит продукт классификации билетов?

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

Как использовать наклейку на билете?

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

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

Как мы создали продукт для классификации билетов?

Мы, команда аналитики данных, начали изучать различные подходы к классификации билетов. Один из способов заключался в том, чтобы найти набор ключевых слов для каждого ярлыка. Когда приходит новый билет, мы будем искать ключевые слова каждого ярлыка в тексте заявки и предсказывать ярлык в результатах поиска. Но не удалось найти уникальный набор ключевых слов для каждого ярлыка. Например, ярлыки типа order_tracking и order_nondelivery имеют общие ключевые слова, такие как order placed, return, wait и delayed.

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

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

Общий процесс построения модели

  1. Набор данных билетов в формате CSV и соответствующие им метки необходимы для обучения модели классификации. Администратор может использовать вкладку SensAI на панели инструментов для загрузки набора данных и построения модели классификации.
  2. Наша собственная платформа машинного обучения подготавливает и проверяет отправленный набор данных билетов.
  3. Наша собственная платформа машинного обучения строит модель классификации на основе проверенного набора данных.
  4. После того, как модель построена, она сохраняется в хранилище моделей. Эта модель используется для прогнозирования метки при поступлении нового билета.

Этапы машинного обучения при построении модели

Предварительная обработка

Цель этапа предварительной обработки - собрать требуемые слова из корпуса текста тикетов и найти ассоциацию этих слов в корпусе. Предварительная обработка начинается с очистки данных тикета путем удаления HTML-тегов, чисел, URL-адресов и т. Д., Которые бесполезны для поиска интересных шаблонов внутри набора данных.

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

Построение модели

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

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

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

Общий процесс прогнозирования метки на новом билете

  1. Как только поступает новый запрос в службу поддержки, он собирается серверами Helpshift. Бэкэнд-сервер Helpshift знает название компании, для которой конечный пользователь отправил заявку.
  2. Внутренняя служба собирает информацию, например, включена ли услуга прогнозирования этикеток нашим клиентом. Если прогнозирование метки включено, то серверная служба определяет язык текста заявки. Собранные функции отправляются в службу прогнозирования этикеток вместе с текстом заявки.
  3. Служба прогнозирования выбирает необходимые модели из хранилища моделей и прогнозирует оценку для каждой доступной метки в модели. К билету прикрепляется этикетка с наивысшим баллом.
  4. После того, как этикетка прикреплена к заявке, наш клиент может решить, что делать с этой меткой - маршрут к определенной группе агентов (очередь), автоответчик с определенным сообщением и т. Д. Таким образом, наш клиент может комбинировать прогнозируемую метку с мощными функциями рабочего процесса Helpshift, позволяющими автоматизировать сложные рабочие процессы.
    Например, если тикет касается lost account, может быть отправлен автоматический ответ, указывающий на FAQ, в котором объясняется необходимая информация и шаги. Другой пример: если билет имеет размер app crash, он может быть перенаправлен в очередь с высоким приоритетом, где он автоматически назначается доступным в данный момент агентам.
  5. Когда агент видит примененную метку на заявке, у него есть возможность пометить предсказанную метку как неправильную. Агент также может исправить предсказанную метку для билета. Эти исправленные данные ярлыка отправляются на платформу машинного обучения в качестве обратной связи для модели классификации. Обратная связь, полученная от агента, используется для обновления модели, чтобы модель была настроена для лучшего прогнозирования. Этот цикл обратной связи может показаться волшебным, потому что чем больше отзывов от агентов, тем точнее модель автоматически.

Это позволяет сделать две вещи:

  • Точность модели может повыситься до 90 +%.
  • Новые типы проблем могут быть идентифицированы, если агент помечает предсказанную метку как неправильную для многих заявок.

Извлеченные уроки

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

  1. Обновите модель, оставив отрицательный отзыв

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

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

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

2. Попробуйте создать ярлык для уникальной категории билетов

  • Когда модель строится для набора меток, где каждая метка представляет уникальный тип категории билета, такая модель всегда работает лучше по точности по сравнению с моделью, в которой метка представляет более одного типа категории билета.
  • Например, метки order_nondelivery и order_delayed представляют одну и ту же категорию билетов, поэтому избегайте таких меток для прогнозов.

3. Создайте отдельную модель для каждого языка

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

Если вам интересно работать над такими проблемами, мы набираем, присоединяйтесь!