Промпт для LLM нельзя выпускать в продакшен только потому, что он «выглядит лучше» на паре примеров: Stack Overflow предлагает превратить оценку качества LLM в обязательный барьер релиза. В разобранном сценарии набор из 240 кейсов пропускает изменение лишь при результате не ниже 98%; для российских команд это вполне прикладной рецепт, как перестать ловить регрессии уже на пользователях.
Как сообщает Stack Overflow Blog, большинство команд пока относятся к evals примерно так же, как когда-то относились к тестам до появления CI: запускают вручную, эпизодически и обычно после инцидента. Для языковых моделей это особенно рискованно. Качество может ухудшиться не из-за заметного коммита в бизнес-логике, а после небольшой правки промпта, смены модели у провайдера или корректировки температуры. Внешне безобидное изменение способно испортить ответы лишь на части запросов — например, на 8% входящих обращений, — и не сразу попасть в поле зрения команды.
Основа подхода — «золотой» набор тестовых случаев, который хранится рядом с кодом и проходит ревью как обычные изменения. Каждый кейс содержит входные данные, ожидаемое решение, минимальный уровень уверенности, запрещённые варианты и метки сегмента. Авторы советуют включать в набор типовые запросы, сложные пограничные ситуации и, главное, все уже исправленные сбои. Удалять такие регрессионные случаи не стоит: иначе продукт получает шанс второй раз наступить на тот же баг, только с новым номером задачи.
Проверка должна быть формальной, а не сводиться к фразе «модель ответила разумно». Для одного кейса можно потребовать конкретное решение, например approve, задать нижнюю границу confidence в 0,80 и отдельно запретить автоматическое закрытие обращения. Сам оценщик тоже нуждается в тестах: если он не способен отличить правильное решение от заведомо неверного, весь контур контроля превращается в красивый отчёт без защитной функции.
Следующий шаг — подключить этот набор к CI. При запуске пайплайна система считает долю пройденных кейсов и завершает сборку ошибкой, если показатель ниже порога. В примере Stack Overflow 236 из 240 проверок дают 98,3%, поэтому порог в 98% пройден. Смысл не в магическом числе: конкретная планка зависит от продукта и цены ошибки. Важнее другое — автор изменения увидит, что новый промпт улучшил один сценарий, но сломал два других, ещё в pull request, а не после жалобы клиента.
Одного общего процента недостаточно. Если сервис работает с разными типами запросов, языками или сегментами клиентов, итоговые 99% могут скрывать 70% качества в одном критичном срезе. Поэтому кейсы предлагают размечать теми же атрибутами, которыми система пользуется во время работы, и автоматически запускать соответствующие поднаборы. Ручной выбор тестового набора здесь — лишняя точка отказа: команда постепенно начинает проверять не то, что реально обслуживает приложение.
Но даже строгий gate защищает только от резких провалов в момент релиза. Он хорошо ловит «обрывы»: условно, изменение сразу роняет качество ниже допустимой границы. Гораздо коварнее медленная деградация: метрика может последовательно снизиться с 0,995 до 0,990, а затем до 0,985. Каждая версия формально проходит порог 0,98, но за несколько релизов продукт заметно проседает. Для этого нужна отдельная оценка качества LLM относительно зафиксированного эталона, а не только сравнение с минимально допустимым значением.
Авторы предлагают сохранять baseline после осознанно подтверждённого хорошего релиза: среднее значение метрик, размер выборки и, где уместно, разброс результатов. Затем каждый новый запуск сравнивают с этой точкой. В приведённом примере exact match падает с 0,942 до 0,913: оба значения могут быть выше внутреннего пола, но разница в 0,029 уже повод для тревоги. При этом нельзя просто делить разброс базовой выборки на корень из её размера: сравнение должно учитывать размер и вариативность обеих выборок. Иначе 50 живых решений легко дадут статистический «инцидент» при сравнении с эталоном из 2400 строк.
Новый baseline нельзя обновлять автоматически после каждого успешного запуска. Иначе система постепенно признает нормой собственную деградацию — ровно то, что она должна была заметить. Перебазирование имеет смысл только после проверки нового релиза как действительно качественного. Для разных метрик нужны и разные пороги значимости: рост доли ручных исправлений на 0,02 для показателя около 0,06 может быть важен, тогда как такой же сдвиг confidence не всегда говорит о проблеме.
Отдельный слой — shadow evals, то есть оценка части реального, обезличенного трафика вне основного пути обработки запроса. В качестве примера Stack Overflow приводит проверку 5% решений. Выборку лучше определять стабильным хешем идентификатора, а не случайным числом: тогда один и тот же запрос попадает в контроль предсказуемо, а результаты проще сопоставлять между периодами. Случаи, на которых модель ошиблась в продакшене, затем пополняют золотой набор — так оценка качества LLM постепенно учится на самых неприятных сюрпризах реальности.
Для разработчиков и владельцев продуктов главный вывод прост: evals нельзя считать разовой демонстрацией перед запуском. Нужны одновременно жёсткий запрет на выпуск регрессии, сравнение с последним подтверждённым состоянием и наблюдение за реальным трафиком. Следующая сложность для команд — договориться не о том, как собрать больше метрик, а о том, какие ухудшения действительно нельзя выпускать и кто имеет право признать новый уровень качества нормой.