Disclaimer: этот пост не является исчерпывающим руководством по выбору предварительно обученной NLP-модели, а только призван сэкономить немного времени при этом выборе, разбирает один узкий бизнес-кейс, ориентирован на аналитиков и ML-специалистов, чей основной профиль деятельности не связан с NLP.
Привет! Я занимаюсь продуктовой аналитикой и сегодня хочу рассказать о причинах выбора одной из предварительно обученных NLP-моделей для классификации обращений пользователей в команду на примере клиентского сервиса eLama.
eLama по праву гордится работой своей Службы Заботы (так называется отдел поддержки клиентов). Многие клиенты в первую очередь отмечают ее при оценке сервиса. В том числе в Заботе помогают пользователям решать вопросы не только по взаимодействию с интерфейсом eLama, но и по работе с кабинетами рекламных систем. Для этого выстроена система грейдов в Службе Заботы по уровню экспертности специалиста.
Но пользователя не должно всё это волновать, он пишет вопрос и получает ответ максимально быстро. Вот тут и возникает сложность. Пользователи могут обращаться по любому вопросу от «... как получить закрывающие документы» до «...как настраивается динамический ремаркетинг в фб». Распределять эти вопросы между сотрудниками Заботы равномерно нельзя, вопрос определенного уровня сложности должен получить соответствующий специалист. И в этом помогают технологии обработки естественного языка.
В мире обработка естественного языка (Natural Language Processing, NLP) решает значимую часть задач бизнеса: сокращение затрат на поддержку пользователей с помощью реализации голосовых и текстовых ботов, повышение релевантности результатов поиска, маркетинговые исследования посредством анализа тональности, увеличение продаж за счет классификации намерений, повышение качества обслуживания с применением распознавания срочности и многое другое.
eLama решает множество задач с применением ML. Абсолютное большинство кейсов — классификация и регрессия на основе неоднородных (табличных) данных и прогнозирование временных рядов. Но иногда поступают задачи, связанные с прогнозированием на однородных предикторах (NLP относится к таковым). Классификации обращений — как раз такая задача.
В некоторых случаях работа с подобными задачами значительно облегчается тем, что существует множество предварительно обученных NLP-моделей и исследователь может выбрать ту, которая позволяет решить задачу с лучшими метриками.
Исходные требования к решению:
обучить классификатор текстовых обращений пользователей в поддержку с целью их распределения по трем уровням поддержки;
обучающая выборка ограничена (несколько тысяч примеров);
классы относительно не сбалансированы (примерное распределение 50% / 25% / 25%);
применение модели должно происходить с минимальной задержкой, результаты классификации назначаются перед передачей последнего в CRM;
организовать сбор ошибочных классификаций от команды поддержки и итеративное дообучение модели.
Условно (последовательность и наличие этапов обработки данных зависит от конкретной предварительно обученной модели) конвейер обучения и применения нашего классификатора будет выглядеть следующим образом:
Очистка текста обращения от символов, не имеющих отношения к естественному языку.
Токенизация (разбиение текста на слова).
Удаление токенов из списка stopwords.
Удаление некириллических токенов.
Лемматизация (приведение к нормальной форме слова).
Сокращение числа токенов, подаваемых на вход сторонней NLP-модели.
Передача текста в предварительно обученную модель, получение embedding-ов (векторов).
Передача векторов для обучения (или применения) нашему классификатору (Keras, backend - Tensorflow).
Таким образом, получаем следующие результаты (на CPU) (по F1-score, для простоты сравнения приводим одну метрику):
Пред. обученная модель | F1 | CPU time (усредненное, только получение embeddings), s | RAM usage, MiB |
Spacy | 0.8311 | 0.01 | 0.02 |
Fasttext | 0.8370 | 0.0002* | 0.00* |
Bert | 0.8935 | 0.68 | 0.01 |
* Первичная инициализация модели потребляет 7155.25 MiB RAM, CPU times: 12 s (Intel Core i7-8700)
Обратите внимание, что тренировать классификатор можно, начиная с небольших объемов данных. В случае eLama заметные результаты были впервые получены при использовании уже от 1000 примеров на класс. Далее после тестового внедрения накапливалось больше примеров и классификатор дообучался. Начиная с определенного объема выборки, прирост метрик весьма незначителен.
Безусловно, такие задачи имеют множество вариантов реализации. Уверен, ее можно решить более эффективно. Пишите в комментариях, какой подход предпочли бы вы.
Не буду сообщать, какая модель трудится в проде, выбирайте инструмент исходя из ваших требований :)
