Офлайн-оценка

Офлайн-оценка — это проверка модели, промпта или конвейера на фиксированном наборе данных до того, как изменение дойдёт до пользователей. Входы держат постоянными, меняют проверяемую систему и сравнивают результаты. Это парная практика к онлайн-оценке, которая измеряет поведение на живом трафике и реальных людях, и отвечают они на разные вопросы: офлайн говорит, безопасно ли выкатывать изменение, онлайн — стоило ли его выкатывать. Ценность офлайн-оценки в воспроизводимости. Набор не двигается, поэтому два прогона сопоставимы, регресс можно отнести к конкретному изменению, а упавший случай — воспроизвести по требованию. Именно это делает офлайн-оценку естественным шлюзом в конвейере поставки: правка промпта, роняющая точность на фиксированном наборе, блокируется до того, как станет инцидентом, а тот же набор, прогнанный на кандидатной модели, превращает миграцию из акта веры в измерение. Качество живёт в наборе. Он должен собираться из настоящего трафика, а не из придуманных примеров, взвешиваться в сторону действительно важных случаев и намеренно наполняться неудобными: двусмысленные запросы, враждебные вводы, вопросы, на которые нет хорошего ответа, и каждый прошлый продовый сбой. Набор из одних чистых входов измеряет систему, которой никто не пользуется. Любой инцидент должен заканчиваться новой строкой в этом наборе — именно это превращает оценку в храповик вместо ритуала. Вторая половина — способ подсчёта. Детерминированные проверки дёшевы и должны нести как можно большую часть нагрузки: парсится ли вывод, соответствует ли схеме, есть ли обязательное поле, ссылается ли он на существующий источник. Остаётся суждение, и его оценивают либо люди по написанной рубрике, либо модель в роли судьи — масштабируемо, но требует собственной валидации против человеческих меток, прежде чем её вердиктам можно верить. Главный риск — принять число за истину. Офлайн-оценка это прокси: она измеряет качество на том распределении, что зафиксировано в наборе, а оно расходится с живым трафиком по мере изменений продукта и по мере того, как пользователи выучивают, в чём система хороша. Никогда не обновляемый набор постепенно становится экзаменом, который система научилась сдавать, а подозрительно высокий балл обычно означает, что примеры протекли в промпты или набор перестал отражать что-либо актуальное. Относитесь к этому как к набору тестов, а не к событию. Версионируйте набор рядом с кодом, прогоняйте оценку на каждое изменение промптов, поиска или конфигурации модели, храните результаты рядом с породившим их коммитом и требуйте осознанного решения, чтобы выкатить то, что роняет балл. Смысл не в достижении целевого числа, а в том, чтобы заметить изменение, которого вы не планировали.