Disclaimer: этот пост не является исчерпывающим руководством по выбору предварительно обученной NLP-модели, а только призван сэкономить немного времени при этом выборе, разбирает один узкий бизнес-кейс, ориентирован на аналитиков и ML-специалистов, чей основной профиль деятельности не связан с NLP.

Привет! Я занимаюсь продуктовой аналитикой и сегодня хочу рассказать о причинах выбора одной из предварительно обученных NLP-моделей для классификации обращений пользователей в команду на примере клиентского сервиса eLama.

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

Но пользователя не должно всё это волновать, он пишет вопрос и получает ответ максимально быстро. Вот тут и возникает сложность. Пользователи могут обращаться по любому вопросу от «... как получить закрывающие документы» до «...как настраивается динамический ремаркетинг в фб». Распределять эти вопросы между сотрудниками Заботы равномерно нельзя, вопрос определенного уровня сложности должен получить соответствующий специалист. И в этом помогают технологии обработки естественного языка.

В мире обработка естественного языка (Natural Language Processing, NLP) решает значимую часть задач бизнеса: сокращение затрат на поддержку пользователей с помощью реализации голосовых и текстовых ботов, повышение релевантности результатов поиска, маркетинговые исследования посредством анализа тональности, увеличение продаж за счет классификации намерений, повышение качества обслуживания с применением распознавания срочности и многое другое.

eLama решает множество задач с применением ML. Абсолютное большинство кейсов — классификация и регрессия на основе неоднородных (табличных) данных и прогнозирование временных рядов. Но иногда поступают задачи, связанные с прогнозированием на однородных предикторах (NLP относится к таковым). Классификации обращений — как раз такая задача.  

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

Исходные требования к решению:

• обучить классификатор текстовых обращений пользователей в поддержку с целью их распределения по трем уровням поддержки;

• обучающая выборка ограничена (несколько тысяч примеров);

• классы относительно не сбалансированы (примерное распределение 50% / 25% / 25%);

• применение модели должно происходить с минимальной задержкой, результаты классификации назначаются перед передачей последнего в CRM;

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

Условно (последовательность и наличие этапов обработки данных зависит от конкретной предварительно обученной модели) конвейер обучения и применения нашего классификатора будет выглядеть следующим образом:

1. Очистка текста обращения от символов, не имеющих отношения к естественному языку.

2. Токенизация (разбиение текста на слова). 

3. Удаление токенов из списка stopwords.

4. Удаление некириллических токенов.

5. Лемматизация (приведение к нормальной форме слова).

6. Сокращение числа токенов, подаваемых на вход сторонней NLP-модели.

7. Передача текста в предварительно обученную модель, получение embedding-ов (векторов).

8. Передача векторов для обучения (или применения) нашему классификатору (Keras, backend - Tensorflow).

Таким образом, получаем следующие результаты (на CPU) (по F1-score, для простоты сравнения приводим одну метрику):

* Первичная инициализация модели потребляет 7155.25 MiB RAM, CPU times: 12 s (Intel Core i7-8700)

Обратите внимание, что тренировать классификатор можно, начиная с небольших объемов данных. В случае eLama заметные результаты были впервые получены при использовании уже от 1000 примеров на класс. Далее после тестового внедрения накапливалось больше примеров и классификатор дообучался. Начиная с определенного объема выборки, прирост метрик весьма незначителен.

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

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