Как перевести отзывы пользователей в метрику качества сервиса

Что проверяют

Умеете ли вы превратить неструктурированный текст в число, которому можно доверять и по которому можно действовать. Одного «посчитаем тональность» мало: ждут, что вы определите, что именно измеряется. Следом обычно спрашивают, как убедиться, что рост метрики связан с качеством сервиса, а не с тем, кто пишет отзывы.

Как отвечать

Начните с определения: качество сервиса складывается из аспектов (доставка, поддержка, цена, приложение), поэтому одна общая тональность почти бесполезна. Дальше каркас:

• аспекты и тональность: aspect-based sentiment analysis, у каждого отзыва набор пар «аспект, оценка». Для русского текста дообучают модель семейства ruBERT на своей разметке. LLM удобна для первичной разметки, а в проде держат дешёвый классификатор;
• поиск новых тем: кластеризация эмбеддингов или BERTopic, чтобы не пропустить проблему, которой нет в списке аспектов;
• сама метрика: доля негативных упоминаний аспекта, нормированная на число заказов или обращений, а не на число отзывов. Для маленьких сегментов нужны доверительные интервалы (Уилсона) или байесовское сглаживание;
• валидация: ручная выборка с согласованностью разметчиков (каппа Коэна), macro-F1 модели и, главное, связь метрики с поведением: повторные заказы, отток, CSAT.

Итог выглядит как недельный дашборд по аспектам и сегментам с порогами для алертов.

Где спотыкаются

Удаляют стоп-слова по стандартному списку и вместе с ними теряют «не». Для тональности это переворачивает смысл: «не понравилось» превращается в «понравилось».

Берут для русских отзывов англоязычные инструменты вроде TextBlob или VADER из NLTK. Они обучены на английском, и на русском тексте дают шум вместо оценки.

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