Судье нужен судья — как проверить, что LLM-грейдер соглашается с человеком, прежде чем он начнёт блокировать релизы
Саммари
В пайплайнах с coding-агентами всё чаще CI-гейтом выступает второй LLM — «судья», который ставит pass/fail на выходы агента, но его самого никто не проверяет: команда никогда не сравнивала вердикты грейдера с вердиктами человека на тех же прогонах. Статья разбирает опубликованный случай, где расхождение двух судей на одних и тех же 594 прогонах составило 74,6% против 37,9% успеха, и даёт пошаговую процедуру валидации судьи по «золотому набору» с человеческими метками — с порогом 80–85% согласия и CI-гейтом, который ловит и недооценку, и переоценку.
Из этого следует, что пайплайн eval без валидации самого судьи даёт число с неизвестной погрешностью, и погрешность может быть катастрофической: разрыв 74,6% vs 37,9% на одних и тех же прогонах означает, что зелёный CI ничего не гарантирует.
На практике для Revit-агентов и AI-инструментов: если автомат проверяет выходы агента (например, «правда ли модель содержит искомый элемент»), на него нужен отдельный golden set с человеческими метками и свой гейт — иначе вы оптимизируете агента под слепого судью.
Важный нюанс: апгрейд судьи — не безупречное улучшение, он смещает ошибку в другую сторону (ложные отказы растут), поэтому после каждой смены модели/промпта судьи проверку согласия надо повторять, а версию модели пиннить.
Ограничение подхода: полоса 80–85% на 30 примерах — это tripwire, а не точное измерение; набор надо наращивать из реального трафика, иначе судья градится на старых проблемах.