Eval или не шипнул

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

Фикс — нерекламный: holdout evaluation set, прогоняется перед каждым merge, агент его никогда не видит во время разработки.

Что значит "holdout" на практике

Если ты написал агента и видел eval-инпуты — eval загрязнён. То же с prompt-tweak: каждый промпт который я трогаю видит dev split. Holdout split залочен в version control, читается CI, и людьми инспектируется только когда счёт сдвинулся достаточно сильно чтобы расследовать. Всё.

Что делает eval полезной

Три свойства, по порядку:

1. Отражает production-трафик. Умный benchmark который кто-то собрал полезен для сравнения систем, но не говорит тебе что нужно твоим юзерам. Майнь production-логи, сэмплируй, анонимизируй, курируй. Раз в квартал.
2. Скорит то, на что ты реально среагируешь. «Helpfulness 4.2/5» не actionable. «78% сценариев проходят контракт structured output» — actionable.
3. Дёшево гонять. Если eval занимает 6 часов — никто не запустит его в PR. Цельтесь в 5 минут на smoke set, час на полный.

Форма хорошего eval suite

Два слоя:

• Маленький smoke set (~30 сценариев), бежит на каждом PR. Ловит регрессии рано.
• Больший holdout set (~300 сценариев), бежит на main еженедельно. Набор который агент не видит во время разработки.

Публичные benchmarks стоят рядом — не вместо. Они полезны для разговора с другими командами, но контракт который имеет значение — это контракт с твоим собственным production-трафиком.

Что я перестал принимать

«В тестах выглядело хорошо» — не state в который я выпускаю агентов в production. Если eval не существует, агент не уходит. Если eval-score регрессирует — merge не происходит пока не разберёмся почему.

Звучит жёстко пока не посмотришь как система тихо регрессирует за шесть спринтов потому что никто не мерил. После этого звучит очевидно.