От 3000 сессий в месяц до 100 в секунду: как LLM заменила ручную оценку ботов поддержки

На связи Ангелина Большина, Денис Толкачев и Игорь Буянов, команда Customer Support NLP, мы разрабатываем ботов для службы поддержки клиентов. И наша работа полезна для развития продукта MWS AI Клиентский сервис. Сегодня мы расскажем вам про то, как мы автоматизировали оценку наших ботов с помощью специально разработанной метрики. Мы разделили материал: сначала расскажем про бизнес-составляющую, а затем – про технические детали. Итак, поехали!

Почему нельзя просто посчитать процент автоматизации

Когда у компании десятки миллионов клиентов, контакт-центр работает в режиме постоянного аврала: обращения идут по всем каналам сразу тысячами. Значительную часть этого потока принимают ИИ-операторы — голосовые и текстовые боты на правилах и на LLM.

Чтобы понимать, насколько хорошо клиентские ИИ-боты справляются со своей задачей, обычно используют две метрики:

1. GROSS: отслеживает процент автоматизации обработки обращений. Если бот не перевел клиента на человека-оператора, сессия считается автоматизированной.

2. tNPS: метрика лояльности. В конце сессии мы спрашиваем клиента, порекомендует ли он бота друзьям, по шкале от 0 до 10. Ответивших на 9–10 мы считаем промоутерами, на 7–8 — нейтральными, остальных — критиками. tNPS считается как разница между количеством промоутеров и количеством критиков, поделенная на весь объем оценок.

У обеих метрик есть слабые места. Для GROSS: если бот не перевел разговор на человека, это еще не значит, что он решил проблему клиента. И наоборот, передача диалога оператору не всегда означает, что бот сработал плохо. С tNPS еще сложнее, и дело в выборке. Оценку оставляет далеко не каждый: для текстового бота число оценок отличается от числа чатов в 34 раза, а для голосового в 471 раз. Люди не любят тратить время на обратную связь. Задерживаются в основном те, у кого проблема не решена, а значит, в выборке систематически больше критиков, чем довольных клиентов. Следовательно, возникает перекос в сторону негативных оценок. Нам захотелось понять, что конкретно не нравится клиентам, и мы решили провести прямой опрос. Оказалось, 40% опрошенных вообще не хотели общаться с ботом, им сразу был нужен оператор. 26% просто переносили на бота накопленное раздражение. И только треть ответивших была недовольна именно работой нашего ИИ-бота: он не понял запрос или не смог на него ответить.

Очевидно, нам нужна была еще одна метрика – более объективная, чем tNPS и менее двусмысленная, чем GROSS, которая оценивала бы не факт передачи диалога оператору, и не недовольство клиента, а именно качество работы самого бота с запросом.

Как мы придумали метрику, которая считает решенные проблемы

Нам нужен был простой ответ на простой вопрос – «решил ли бот проблему клиента?». Сначала мы разработали метрику с названием Goal Completion Rate (GCR). Правила просты: человек-проверяющий смотрит на диалог и ставит 1, если проблема решена ботом, и 0, если нет. Сессии, где клиент сразу звал оператора, просто здоровался или не сформулировал внятного запроса, помечаются как skip и не учитываются в финальной оценке. В конце получаем итоговую метрику, деля количество решенных сессий на весь объем.

Однако, чтобы получить эту оценку, мы вынуждены ждать, пока завершится ручная разметка. Чем больше сессий, тем дольше ждать. В случае поломки бота это серьезно бьет по оперативности. А бинарная оценка слишком жесткая: бот может частично решить задачу, но мы все равно ставим ноль.

Так появилась GCR 2.0. Вместо бинарной оценки мы ввели шкалу от двух до пяти, плюс можно поставить теги конкретных проблем, которые помешали боту. На картинке приведены примеры сессий на оценку «3» и «5» в готовом для оценки формате. Обратите внимание, что в репликах клиента после прямой черты идут предсказания намерений клиента от нашей гибридной системы распознавания интентов:

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

С чего мы начали разработку пайплайна

На старте у нас было много необработанных диалогов бота с клиентами и всего 120 сессий, размеченных вручную по новой методологии. Немного, если честно, но работаем с тем, что есть.

Задача классификационная, поэтому метрики стандартные:

• точность — доля верных предсказаний среди всех предсказаний;

• полнота — доля верных предсказаний относительно всех истинных объектов.

Чтобы учитывать оба показателя сразу, использовали F1-меру в нескольких вариантах подсчета: micro, macro, weighted и samples. Последний нужен для мультилейбл-задачи: простановки тегов, где на одну сессию может приходиться сразу несколько проблем.

С метриками и данными разобрались, теперь про модели. Мы опирались на три критерия:

• показатели на бенчмарках MERA и LLM Arena Ru;

• размер модели;

• возможность быстро развернуть ее в своем контуре.

По этим критериям прошли наши внутренние модели Cotype Pro и Cotype Pro 2, DeepSeek-v2-Lite-Chat и Vikhr-Nemo-12B-Instruct-R-21–09–24. Отдельно протестировали сверхбольшую Qwen3-235B-22A, запустив ее через llama-cpp. Эксперименты шли летом 2025 года, так что набор моделей соответствует тому времени.

Из-за небольшого количества размеченных примеров мы могли экспериментировать только с вариантами промптинга: few-shot, chain-of-thoughts и Prompt Aggregation. Сверхбольшую модель мы тоже попробовали в режиме few-shot, отдельным экспериментом.

Zero-shot решили не запускать. Исходный промпт уже содержал примеры, и задача была непростой, так что выбрасывать их не имело смысла.

Пара слов про Prompt Aggregation: это когда мы слегка меняем промпт, чтобы получить другую перспективу, своего рода ансамбль. В нашем случае меняли примеры внутри few-shot.

Результаты вышли такие:

Чистым победителем вышла Qwen3, но она обходится слишком дорого на инференсе, поэтому в качестве рабочей модели выбрали Cotype Pro 2, следующую по качеству. Заодно подтвердился тезис, что размер модели пока (год назад, во всяком случае) имеет значение: Qwen выигрывала во многом за счет масштаба. Добавление примеров в проблемные классы улучшало результат ценой небольшого замедления инференса. Еще мы экспериментировали с тем, сколько и как лучше добавлять примеры. Результаты показали, что для хорошего прироста можно не заморачиваться и случайным образом добавить три примера.

Как мы собрали основной датасет и что показала первая модель в проде

Пока шли эксперименты с промптингом, разметчики готовили основной набор данных по GCR 2.0. Мы отобрали почти пять тысяч сессий с помощью процедуры, которая учитывает тематику обращений, длину диалога и эмоциональный настрой клиента. Качество разметки проверяли пятью раундами перекрестной сверки с коллегами.

Когда была готова первая половина датасета, перезамерили и бейзлайн, и лучший вариант промптинга. Теги проблем до этого момента оставались в стороне: данных под них было слишком мало, а в приоритете было качество основной оценки. На новом объеме удалось замерить и их. В этой таблице сравнение для оценок:

А в этой — результаты для тегов для Cotype Pro 2 также в режиме few-shot:

С этими результатами мы отправили модель в прод и пошли на вторую итерацию.

Что дало дообучение через LoRA

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

Сразу к результатам:

Здесь выбор моделей был продиктован в первую очередь размером. Как видите, лучший результат показала Cotype Pro 3, которую мы успели выпустить к моменту тестов. При этом отрыв в качестве колоссальный: прирост составил 0.25 /0.31/0.25 по разным вариантам F1, для задачи такого рода это много. Бонусом к этому Cotype Pro 3 немного компактнее Cotype Pro 2, так что потребление памяти не выросло.

При обучении тегов возникла проблема. Это задача мультилейбл, и если не ограничивать модель, она начинает генерировать все теги подряд. Решение оказалось простым: мы обязали модель отдавать ответ в формате JSON. Закрывающая скобка служила эдаким end-of-sequence, на который опиралась модель. Прирост на тегах тоже получился космический:

В этом же раунде мы существенно переработали инструкцию для разметчиков, учтя весь опыт ранних проверок и обратную связь от команды разметки. Чтобы проверить эффект, провели эксперимент: отдали разметчикам 100 сессий со старой и новой инструкцией и замерили согласованность оценок через альфу Криппендорфа. Старая инструкция дала альфу 0.33, новая 0.65.

Разница напрямую бьет в качество разметки, ведь повышение согласованности значит, что разметчики стали лучше понимать задачу. Это в свою очередь делает разметку качественнее, что напрямую влияет на процесс обучения модели. Кроме того, высокая согласованность ускоряет процесс и экономит деньги. Разметчики в любом случае устраняют несогласованность оценок вручную, но чем выше исходная согласованность, тем меньше времени уходит на перепроверку, а значит меньше трудозатрат для бизнеса.

В итоге получилась модель, которая работает и сейчас.

Как устроен пайплайн целиком

Теперь давайте посмотрим на схему пайплайна:

Сначала пайплайн получает логи из хранилища. Они хранятся в ClearML, нашей основной MLOps-платформе. Затем логи проходят предобработку, во время которой мы выявляем skip-сессии. Для этого у нас есть набор эвристик, которые определяют, не звал ли клиент всю сессию оператора, и классификаторы, которые отлавливают бессмысленные тексты.

Из обработанных логов часть сессий сэмплируется для ручной разметки. Так мы следим, что модель не деградирует со временем. Затем большая языковая модель размечает оставшиеся сессии: одна модель работает как каркас, а к ней подключаются LoRA-модули отдельно для оценок и тегов. Далее мы объединяем сессии с отобранными ранее skip-сессиями, сохраняем в ClearML для истории, а также через Kafka передаем данные на дашборд. Там любой пользователь, будь то бизнес-аналитик или продакт, может смотреть метрики в разных разрезах, например по периодам.

Пайплайн запускается ежедневно по шедулеру ClearML, который сам поднимает инстанс vLLM перед началом работы и выключает его по завершении. Все укладывается в одну H100 с потреблением около 65 Гб VRAM.

Отдельно пришлось повозиться с совместимостью. LoRA мы обучали через bitsandbytes, а встроенный в ClearML vLLM его из коробки не поддерживал. Включить bitsandbytes так и не вышло, зато была поддержка GPTQ, но LoRA поверх GPTQ-модели обучить не получилось. В итоге развернули исходную fp16-модель и подключили к ней LoRA, обученную через bitsandbytes, и стоило это нам один пункт качества.

Скорость обработки у нас получилась примерно 100 сессий в секунду. При суточном потоке порядка 100 тысяч сессий на текстовый бот пайплайн справляется с запасом. Напомню, что люди размечали 3000 сессий в месяц. Это примерно одна тысячная сессии в секунду.

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

На этом все, мы очень надеемся, что вы смогли почерпнуть для себя что-то полезное и новое. До скорого!