Новый LLM-промпт выиграл тесты, но проиграл в реальном потоке

Команда обновила промпт саппорт-бота. В тестовом наборе доля правильных ответов выросла с 80% до 85%. После выката операторы стали чаще исправлять ответы. Оказалось, половина тестов состояла из коротких вопросов о доставке, хотя в живом потоке таких запросов лишь 10%. Новая версия хорошо решает именно их и хуже отвечает на возвраты, которые занимают большую часть обращений.

Покажите качество внутри типов задач

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

Пример: на доставке качество выросло с 80% до 95%, на возвратах упало с 80% до 75%. Если в eval половина запросов относится к каждой группе, общий результат меняется с 80% до 85%. Если в реальном потоке доставка составляет 10%, а возвраты 90%, ожидаемое качество меняется с 80% до 0,1 × 95% + 0,9 × 75% = 77%. Тот же промпт «победил» в тестовом среднем и проиграл по составу реальных задач.

Соберите веса до запуска нового эксперимента

Возьмите окно трафика, которое соответствует решению о выпуске, например последние четыре недели без аварийных дней. По каждому запросу сохраните категорию, но не переносите персональные данные в eval. Зафиксируйте доли групп до просмотра результатов новой версии. Затем посчитайте взвешенное качество и отдельно покажите значения по группам. Если доля редкого, но дорогого сценария мала, оставьте для него отдельный quality-гейт: общий вес не должен скрывать критическую регрессию.

Пропуски классификации тоже видны в отчёте. Сделайте группу «другое/неразмечено» и показывайте её долю. Если она резко выросла, веса стали недостоверными. Для типов с малым числом примеров покажите количество и широкий интервал, а не точный процент до десятых. Если поведение пользователей изменилось после релиза, обновите веса по новому трафику и сравните с предыдущим окном: один замороженный eval-набор не описывает изменяющийся продукт вечно.

Проверьте, как назначаются категории. Если один и тот же запрос про возврат повреждённого товара иногда попадает в «возвраты», а иногда в «жалобы», сравнение по группам будет шумным. Зафиксируйте определения категорий, разметьте небольшую контрольную выборку вручную и измерьте долю спорных случаев. Для трафика, где категория зависит от ответа бота, не берите её как вес до ответа: новая версия может сама изменить распределение меток. Лучше использовать признаки исходного пользовательского запроса.

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

В платном курсе LLMOps & Evaluation: из песочницы в продакшн вы проектируете eval-наборы, quality-гейты и мониторинг дрейфа. Весовая проверка делает гейт полезным для продукта: релиз оценивается по тем запросам, которые пользователи действительно задают. Откройте программу курса, чтобы оформить этот процесс в постоянный контур оценки.