Сплошная проверка вместо выборки: чему учит кейс, где оценку ботов поддержки отдали LLM

3000 сессий в месяц — это не амбиция, а потолок: порядка 140 диалогов в сутки, которые один человек внимательно не прочитает, а команда оценщиков быстро упирается в бюджет. Поэтому ручной контроль качества на практике почти всегда означает выборку: проверяем единицы процентов диалогов и переносим выводы на весь трафик. Выборка неплохо ловит частые проблемы — бот здоровается не тем именем, не находит нужный раздел, отвечает шаблоном не по теме — и почти не ловит редкие, но дорогие. Один диалог из двухсот, где бот неверно трактует условия договора, стоит больше, чем тысяча идеальных ответов про часы работы. В кейсе MWS AI обсуждается поэтому не «ускорение проверки», а смена принципа: оценка не по выборке, а по всем диалогам.

Что меняет LLM в контуре оценки. Оценка одной сессии моделью занимает секунды: в разборе команды масштаб вырос с 3000 сессий в месяц до 100 сессий в секунду, потолок пропускной способности метрики — примерно на пять порядков выше. Смысл не в скорости как таковой, а в смене постановки задачи: не «выборка, по которой судят обо всём», а «все диалоги, по которым видно распределение проблем». Метрика перестаёт быть отчётом и становится прибором: если доля плохих ответов подскочила во вторник, это видно во вторник, а не в конце квартала, когда клиенты уже ушли к конкуренту.

Сборка такой метрики в общем виде выглядит так. Сначала рубрика: какие критерии оцениваем и что считаем провалом — бот не решил задачу, нарушил регламент, выдумал факт или довёл до оператора без попытки решить сам. Затем эталон: небольшая выборка диалогов, размеченная людьми, — по ней видно, совпадает ли оценка модели с оценкой человека. Дальше модель-судья прогоняет поток по рубрике, а команда регулярно сверяет её с человеком и следит за дрейфом; после обновления бота или модели рубрику перепроверяют. Технические детали конкретной реализации — в разборе команды MWS AI, ссылка ниже. Принцип важен: рубрика важнее промпта, а эталон важнее скорости прогона.

Экономика вопроса честнее, чем кажется. LLM-судья не бесплатная надстройка: длинные диалоги съедают токены, и на миллионах сессий прогон становится отдельной статьёй расходов. Но экономия не в том, чтобы сократить часы оценщиков, а в том, чтобы отказаться от выборочного контроля вообще. Посчитайте на своих числах: сколько стоит сотрудник, читающий 30 диалогов в день, и сколько стоит потерянный клиент, которого бот неверно сориентировал по цене или срокам. В большинстве случаев вторая цифра больше — просто потому, что первая видна в зарплатной ведомости, а вторая размазана по упущенной выручке и не имеет фамилии.

Что из этого переносится в малый бизнес. У компании на 10–50 человек не 100 сессий в секунду, а 300 обращений в месяц, и это нормально: смысл кейса не в скорости, а в покрытии и едином критерии. Сплошная оценка даёт три вещи, которых обычно нет: сравнение бота до и после правок на одних и тех же правилах; предметный разговор с подрядчиком («вот 40 диалогов, где бот нарушил регламент»); раннее предупреждение о том, что после смены базы знаний бот начал путать цены. Первый шаг почти бесплатен: возьмите 20 диалогов, напишите на одной странице, что считаете браком, и разметьте их вручную — это и есть ваша рубрика.

1. Начинайте с рубрики, а не с модели: без письменного списка «что такое плохой ответ» автоматическая оценка даст красивое число без управленческого смысла.
2. Сделайте эталон до запуска потока: 50–100 размеченных человеком диалогов показывают, где модель-судья ошибается.
3. Покрытие важнее точности на старте: лучше оценка 100% диалогов с погрешностью, чем идеальная оценка на выборке в 2%.
4. Держите одну метрику долго: при смене правил каждый месяц вы не сравните бота до и после правок.
5. Заложите стоимость прогонов заранее: считайте цену оценки одной сессии в рублях и сравнивайте с ценой ошибки бота.

«Ручная оценка качества ботов поддержки ограничивала масштаб: 3000 сессий в месяц.»