Как Machine Learning помогает при аудите качества клиентского сервиса
Можно ли за короткое время и без больших трудозатрат проанализировать обращения клиентов и выявить причины возникновения негативных отзывов? В этой статье хотим рассказать, как с помощью инструментов ML нам удалось решить эту задачу.
В своей работе мы столкнулись с необходимостью оценить качество клиентского сервиса. Перед нами стояла задача проанализировать обращения клиентов и выявить причины возникновения негативных отзывов по постпродажному обслуживанию по продуктам страхования.
Не секрет, что от качества входных данных зависит качество самой модели, поэтому независимо от выбора алгоритма первоочередной задачей является предобработка имеющейся информации. Поскольку задача относится к задачам, связанным с обработкой естественного языка, то и набор преобразований был выбран можно сказать классическим для данной области.
На первом этапе, с помощью регулярных выражений из обращений клиентов были удалены служебные поля, а также символы, не относящиеся к символам русского алфавита:
Вторым этапом стало приведение слов в обращениях в нормальную форму, попутно удаляя слова, которые ничего не значат в контексте русского языка и нашего домена. Данные стоп-слова частично позаимствованы из библиотеки NLTK и перечислены в массиве stopwords:
После этих нехитрых действий обращения приняли следующий вид:
Далее, для того, чтобы объединить похожие жалобы в группы необходимо было перейти от словесного представления жалоб к векторно-числовому. Очень часто для этой цели используют OneHotEncoding или TF-IDF. И хотя эти способы получения эмбеддингов распространены и показывают неплохие результаты в некоторых задачах, все же, у них есть серьезный недостаток – данные подходы основаны на частотных характеристиках корпуса и не учитывают семантику текста. Это означает, что, несмотря на одну и ту же смысловую нагрузку, векторы предложений «сожалеем за доставленные неудобства» и «просим прощение за возникшие трудности» не будут иметь ничего общего друг с другом, т.к. фразы состоят из разных слов.
Ввиду доступности и неплохой скорости работы нами было решено использовать модель Universal Sentence Embedder, обученной для многих языков, в числе которых и русский. Данная модель способна перевести предложения в векторное пространство с сохранением семантического расстояния между ними. Такой подход открывает перед нами возможность по оценке близости текстов по смыслу.
Как видим, для использования данной модели достаточно написать буквально 5 строк кода. Взглянем на результат работы модели, сравнив косинусное расстояние между полученными векторами от тестовых фраз:
Результат получается достаточно интересным:
Итак, модель вполне жизнеспособна и судя по всему достаточно неплохо выявляет семантику предложений, поэтому полученные с ее помощью вектора теперь можно кластеризовать для выявления тематик.
В качестве алгоритма кластеризации были использованы 4 метода: dbscan, агломеративная, kMeans и MiniBatchKMeans. В последствии мы остановились на результате работы агломеративной кластеризации, т.к., по нашему мнению, именно этот метод наиболее адекватно разделял наш набор данных на тематические подгруппы:
С помощью вышеописанного подхода были получены 5 кластеров, однако нам предстояло еще выяснить, за какую тему отвечает каждая из групп. Для этого был использован простой подход – для каждого кластера были подсчитаны все входящие слова и ТОП-10 из них были представлены в качестве основной сути:
После некоторых дополнений списка стоп-слов получились следующие результаты:
Нулевой и второй кластер фактически не содержали обращений, связанных с недовольством клиентов, что позволило уделить больше внимание именно запросам из оставшихся трех проблемных кластеров.
Данный метод помог нам сократить время и трудозатраты, автоматизировать ряд рутинных задач, уменьшить размер выборки для ручного анализа.
В результате нам удалось сопоставить информацию из разных БД, выявить отклонения и направить рекомендации по улучшению действующих процессов.
Вот здесь видно, что так же пропало и имя с отчеством. Это из-за чего произошло? Из-за stopwords NLTK? Вроде в регулярках не вижу ничего подобного
Регулярное выражение re.sub(r’crm[^\n]+’, ’’, c) в данном случае убрало строчку с именем и отчеством. Кроме того, нужно понимать, что в оригинальном коде функция cl_text имела куда больше строк кода, в статье её усеченная версия, чтобы не перегружать статью.
спасибо, круто!
ML значительно упрощает задачи. Главное, правильно составить алгоритмы.
Dasha, да, согласны! Очень упрощает!