Eval Engineering: gate, который позволяет агентам merge без вас

Оригинал: X Article. Автор: Hanako.

Конечное состояние описать легко. Агент заканчивает изменение, открывает его, и оно попадает в merge без того, чтобы человек читал diff.

Не потому, что кто-то решил доверять модели. А потому, что gate прочитал доказательства и у него было правило для решения.

Почти ни у кого такого gate нет, и причина не в смелости.

Доказательств, которые он должен был бы читать, в большинстве систем пока просто не существует.

Вот что должно быть правдой, прежде чем его можно открыть, в шесть шагов.

Шаг 1 - оценка, которую вы читаете, частично говорит о вашем судье

Автоматическая оценка началась с сильного результата.

Zheng и коллеги из UC Berkeley в 2023 году показали, что GPT-4 соглашался с человеческими оценщиками более чем в 80% случаев, примерно на уровне согласия людей друг с другом. Индустрия почти за одну ночь перешла к API-вызовам.

Последующие работы обнаружили, что судьи реагируют не только на содержание перед ними.

Frontier-судьи систематически завышают оценки ответам моделей из собственной семьи.

В одном бенчмарке 2026 года GPT-5.2 и Gemini 3.1 Pro отдавали моделям своих семейств 75-84% побед. Claude Opus 4.7, наоборот, занижал оценки своей семье до 10,6-41,2%.

На ArenaHard измеренный bias разных судей лежит в диапазоне от -38% до +90%.

Один и тот же набор ответов прогнали через двух разных судей. У одного модель получила 93,3%. У другого те же самые ответы получили 39,5%.

Параллельно идёт bias к многословию: судьи награждают длину независимо от того, несут ли дополнительные слова информацию.

Все это не делает метод бесполезным. Это делает саму настройку несущей конструкцией, и три правила закрывают большую часть проблемы:

• Судья должен быть из другой модельной семьи, чем генератор. Та же семья означает общие слепые зоны.
• Для всего, что имеет высокую цену ошибки, используйте панель судей от разных вендоров, а не одного судью. Усреднение по семьям ломает коррелированные ошибки.
• Все, что можно проверить объективно, отправляйте в код, а не судье. Прошел ли тест, существует ли файл, изменилось ли состояние.

Gate, который питается biased-судьей, хуже, чем отсутствие gate.

Он отмывает догадку в число, а потом действует на основании этого числа.

Шаг 2 - вердикт, который не меняет ход выполнения, это отчет

Большинство команд останавливаются на один шаг раньше.

Они получают число, кладут его на dashboard, и dashboard не меняет ничьего поведения.

Сдвиг, который созрел в 2026 году, состоит в том, чтобы запускать evals внутри агента, а не после него. Pre-production оценки становятся production guardrails, и score управляет тем, что агент может делать дальше: к каким инструментам он получит доступ, будет ли принят handoff, нужно ли эскалировать run человеку.

Это разница между термометром и термостатом.

Каждый вердикт должен отображаться в структурное действие над текущим run.

Низкая groundedness отклоняет handoff.

Ошибка schema блокирует edge.

Подозрение на fabrication помещает branch в quarantine вместо того, чтобы дать ему слиться в main thread.

Только подтвержденное завершение может завершить run.

Агент, который перестал вызывать инструменты, закончил свой turn. Это не то же самое, что завершить задачу, и только внешняя проверка знает разницу.

Это первое, что gate переиспользует. В системе, где вердикты уже управляют run, есть вердикты, которые стоит читать при merge.

Шаг 3 - оценивайте путь, а не только ответ

Оценивать только финальный ответ - это способ получить ситуацию, где агент приходит к правильному результату через сломанную последовательность, и месяц никто этого не замечает.

Оценка агента делится на три уровня, и нужны все три.

End to end спрашивает, была ли задача выполнена.

Trajectory level спрашивает, был ли путь корректным: здесь всплывают циклы, лишние вызовы и потраченные впустую шаги.

Component level спрашивает, какой retriever, tool или sub-agent сломался. Только этот уровень говорит, куда идти и что чинить.

Для старта достаточно трех метрик.

Faithfulness: ответ опирается на то, что реально вернули инструменты, а не на то, что модель додумала, когда tool вернулся пустым.

Tool parameter accuracy: правильный инструмент с правильными аргументами.

Task completion: завершение задачи, оцененное по реальному сигналу, а не по заявлению самого агента.

Faithfulness прячется лучше всего. Агент, который пишет гладко и выдумывает обменный курс, будет хорошо выглядеть по всем quality-метрикам на вашей доске, а выдумка всплывет только тогда, когда клиент на нее опирается.

Для gate траектория важнее финального ответа.

Изменение, пришедшее чистым путем, имеет другой риск, чем идентичное изменение после сорока шагов метания, даже если diff выглядит одинаково.

Шаг 4 - ваши лучшие тесты уже лежат в логах

Тесты, придуманные за столом, защищают от отказов, которые вы уже смогли вообразить.

Дорогие случаи прямо сейчас сидят в ваших traces, с timestamp.

Возьмите небольшой набор полных runs и подберите их так, чтобы рабочее и сломанное поведение стояли рядом:

Запрос, который завершился чисто, как baseline того, как выглядит рабочее поведение.

Запрос, который пользователь переформулировал или исправил, потому что исправление - это бесплатная метка.

Run, где tool вернул пустой результат или был вызван дважды с одинаковыми аргументами.

Run, где что-то внешнее ушло в timeout, и проверяется только то, как ваш агент ведет себя, когда мир говорит «нет».

Опишите каждый в четыре строки: что сделал агент, что сработало и что нет, была ли причина в агенте или зависимости, и какую capability должен защищать eval.

Attribution - место, где люди теряют неделю.

Один и тот же lookup дважды с одинаковыми аргументами - это loop в вашем агенте.

Rate limit в ответе - чужая проблема, и он становится вашим eval только если агент должен был от него восстановиться.

Два правила держат это честным.

Trace говорит, что сделал агент, но никогда не говорит, что он должен был сделать. Поэтому answer key берется из тестов, записей, policy или от человека.

И проверяйте verifier, прежде чем доверять ему. Дайте ему один явно правильный результат и один правдоподобно неправильный. Если что-то классифицируется неверно, сломана rubric, а не агент.

Каждый failure, превращенный таким образом, становится чем-то, чем gate не сможет удивиться дважды.

Шаг 5 - закрепите версию судьи или потеряете месяц

Судьи - это software с версиями.

Судья, который незаметно обновляется, делает все оценки до и после несравнимыми.

Сбой тихий. Судья поднимает minor-версию в один месяц и major-версию в следующий, ваш suite продолжает выдавать числа, а эти числа уже несколько недель не означают одно и то же.

Закрепите версию и логируйте ее с каждой оценкой.

Запишите rubric одной строкой в форме: pass, если независимо наблюдаемый outcome произошел, а не набор proxy-scores.

И никогда не награждайте форму ответа. Никаких баллов за длину, наличие keywords, количество citations или similarity to reference.

Последнее - не вкусовая претензия.

Достаточно сильно оптимизируйтесь под судью, и агент научится выглядеть правым вместо того, чтобы быть правым. Так защита превращается в attack surface. Goodhart's law с моделью в loop.

Еще кое-что стоит знать, прежде чем опираться на self-review.

Huang и коллеги из DeepMind показали на ICLR 2024, что intrinsic self-correction - когда модель просят проверить и исправить собственную работу без внешнего grounding - не помогает надежно и часто делает хуже.

Grounding должен приходить извне модели.

Размер suite должен переживать столкновение с реальностью.

Рабочая рекомендация 2026 года: минимум 500 cases, прежде чем доверять aggregate number, и run достаточно короткий, чтобы вокруг него кто-то реально планировал работу.

Suite, который длится дольше перерыва на кофе, превращается в квартальный ритуал.

Шаг 6 - открывайте gate по blast radius, а не по confidence

Здесь ошибается большинство разборов.

Они строят confidence score, задают threshold и пропускают все, что выше.

Confidence - самая слабая переменная в этом решении.

Сильная переменная - что произойдет, если change окажется неправильным.

Разделите работу по тому, насколько дорого откатывать ошибку, и задайте разные gates для каждого lane:

• Reversible and contained. Copy change, test, isolated function with coverage. Один плохой merge стоит revert. Этот lane можно открыть первым.
• Reversible but wide. Shared utility, schema addition, все, что трогает десяток callers. Этот lane нужно gate на deterministic checks плюс clean trajectory.
• Hard to reverse. Migrations, deletions, все, что пишет в production data или двигает деньги. Этот lane не открывается независимо от score.

Внутри открытого lane gate читает evidence, а не opinions.

Сначала deterministic results, потому что модели там нет: tests, types, schema, sandbox execution.

Затем eval trajectory для этой версии агента.

Затем history: как часто работа этого агента на этой поверхности раньше откатывалась.

Собственная оценка модели - вход, которому gate должен давать наименьший вес, потому что это единственный input, на который модель может влиять.

Включайте осторожно.

Сначала запустите shadow mode: gate оценивает каждое изменение, но не merge-ит ничего, пока у вас не будет достаточно реального traffic для сравнения.

Отслеживайте, как часто gate и human reviewer расходятся, и держите gate закрытым, пока это число заметно выше нуля.

И держите перед глазами одно предупреждение. Suite может быть полностью зеленым, пока продукт, который он защищает, разваливается, потому что тесты сходятся к тестам, а не к spec.

Green - это evidence, не proof.

Честная версия того, что вы строите, - не trust in the agent.

Это constraint, достаточно плотный, чтобы trust перестал быть вопросом.

Дисциплину держат три строки.

Измеряйте путь, а не только ответ, на котором он приземлился.

Вердикт, который не меняет, что запускается дальше, - это report.

Любой failure, который вы не превращаете в постоянный тест, вы встретите снова.

Модель в вашей выписке по карте - аренда. Экзаменатор вокруг нее - единственная часть, которая остается у вас.

Follow me for more on agent internals, and subscribe to my Telegram channel:

https://t.me/+75nMf005jRpjMDU1