Цели серии статей

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

В этой статье мы поговорим о втором кейсе, который нам помогла решить голосовой робот Анна.

Кейс №2. Задача и данные

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

Проблематика.

34% звонков из отдела продаж переводятся в службу техподдержки. Хочется сократить количество переводов между отделами. Для начала разберёмся, как работало раньше? Поступает звонок в call-центр компании, совершается проверка, известен этот номер или нет (существует ли в нашей crm). Если номер известен компании, значит это уже наш клиент, направляли звонок в техподдержку, если номер незнакомый, то звонок маршрутизируется в отдел продаж.

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

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

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

Решение кейса

Обучили различные модели и получили следующее качество.

Алгоритм	Класс	f-score
LogReg	продажа	0.78
LogReg	поддержка	0.69
Random forest	продажа	0.75
Random forest	поддержка	0.62
SVM	продажа	0.71
SVM	поддержка	0.62
XGBoost	продажа	0.61
XGBoost	поддержка	0.57
CNN	продажа	0.76
CNN	поддержка	0.63

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

Сложности решения. Переразметка

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

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

Как видно, большая часть слов общая для обоих классов. Ожидали, что все технические слова будут в классе техподдержки, а оказалось, что в классе “Продажа” даже слово “перезагрузка” есть. Начали разбираться в причинах этого. Выяснилось, что зачастую оператор отдела продаж консультировал на лёгкие технические вопросы, не переводя на техподдержку, от этого появилась некорректная разметка.

Переразметили датасет и снова выгрузили топ слов для каждого из классов.

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

Стало лучше, уже все “технические” слова в классе “техподдержка”, а слова, сопутствующие продаже, в классе “продажа”. Увидели это и на качестве классификации.

Алгоритм	Класс	f-score, было	f-score, стало
LogReg	продажа	0.78	0.94
LogReg	поддержка	0.69	0.87
Random forest	продажа	0.75	0.92
Random forest	поддержка	0.62	0.82
SVM	продажа	0.71	0.93
SVM	поддержка	0.62	0.86
XGBoost	продажа	0.61	0.91
XGBoost	поддержка	0.57	0.78
CNN	продажа	0.76	0.93
CNN	поддержка	0.63	0.86

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

Кейс №2. Вывод.

Какой вывод делаем по итогу статьи? Разберись в бизнес-процессе, на который влияешь. Да, можно было сказать, что важно разобраться именно в данных, ведь поэтому мы занялись переразметкой. Но если бы мы разобрались заранее в процессе принятия звонков, мы бы сразу выяснили, что операторы отдела продаж технически подкованы и не всегда переводят звонок на тех.поддержку. А значит брать наличие перевода за разметку было не совсем верным решением. Вывод — понимание бизнес-процессов приносит гораздо больше пользы, чем владение сложными алгоритмами и решение мелких технических проблем.

Итоги серии статей

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

Зачем нам это всё? Чего достигли? Во-первых, мы снизили количество переводов между отделами. На графике видно, что 19 и 20 января были тестовые дни, а с 7 февраля запустили классификатор на постоянной основе.

А во-вторых, нам удалось разработать систему, с которой комфортно общаться с роботом. Последние аудио-примеры во второй статье тому доказательство.

Выводы трёх постов

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

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

Что дальше? Наши планы

В планах у нас понимать не только первую фразу клиента, но и последующие, чтобы поддерживать беседу и не доводить «лёгкие» звонки до оператора.

Как Мефодий стал Анной: опыт разработки и запуска классификаторов голосовых сообщений. Часть 3