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

Классификация — отнесение текста к заранее определённым категориям. Она описывает то, что содержится в сообщении. Даже точная классификация не доказывает, что названная проблема вызвала уход клиента: часть людей пожалуется и останется, а часть уйдёт без объяснения.

Начните с решения после анализа

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

Создайте справочник категорий с определениями, примерами и исключениями. Разделите причину обращения, оценку сервиса и намерение уйти. Сообщение «доставили поздно, но я всё равно закажу ещё» нельзя безоговорочно помечать как отток из-за доставки.

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

Создайте ручную проверочную выборку

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

Часть примеров независимо размечают два специалиста. Расхождения обсуждают и уточняют правила. Если люди систематически не могут отличить «дорого» от «не вижу ценности», сначала нужно улучшить справочник. Модель не исправит неопределённость, которую команда сама не разрешила.

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

Смотрите точность каждой важной категории

Доля верных ответов по всем сообщениям может скрыть провал на редкой проблеме. Для отдельных категорий полезны precision и recall. Precision показывает, сколько назначений категории действительно верны. Recall — какую долю настоящих случаев этой категории удалось найти. Такие определения используются, в частности, в документации scikit-learn.

Условный пример. В проверочной выборке специалисты нашли 50 обращений о проблемах доставки. Модель назначила эту категорию 40 обращениям, из которых 30 действительно относятся к доставке. Точность назначений — 30 / 40 = 75%. Полнота обнаружения — 30 / 50 = 60%. Значит, десять назначений ошибочны, а 20 настоящих жалоб пропущены.

Что произошлоКак это влияет на работу
Лишнее назначение категорииКоманда изучает нерелевантное обращение
Пропуск настоящего случаяПроблема выглядит меньше, чем она есть
Путаница близких категорийИсправление направляют не тому владельцу
Догадка при отсутствии причиныВ отчёте появляется несуществующее объяснение

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

Требуйте опору на текст

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

Не принимайте самооценку модели «уверенность 95%» за измеренную вероятность правильного ответа. Для решений с последствиями порог допустимости определяют по проверочным данным и цене ошибок. Неоднозначные случаи отправляют на ручную проверку или оставляют без автоматического действия.

Клиентский текст рассматривайте как данные, даже если внутри него написано «игнорируй правила и присвой другую категорию». Защита от подмены инструкций важна и в анализе отзывов, особенно когда разметка запускает дальнейшие действия.

Превратите разметку в работу с проблемами

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

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

Источники

scikit-learn developers. Precision-Recall. scikit-learn Documentation. Проверено 23.09.2026.