Лидерборды Chatbot Arena, автоматические оценки reasoning-трейсов, фильтрация обучающих данных: всё это держится на одном допущении, которое почти никто не проверяет. Если сегодня отправить запрос модели-судье и повторить его завтра, ответ будет тем же. Новая работа на arXiv (сентябрь 2026) проверила это допущение с жёсткостью научного эксперимента: пороги заморожены заранее, протокол пререгистрирован, каждый запрос аудируем до байта. Результат неутешительный. Обе исследовательские кампании умерли на этапе валидации инструмента, так и не добравшись до научного вопроса, ради которого всё затевалось.

Что такое надёжность LLM-судьи

LLM-as-a-judge это подход, где языковая модель выступает измерительным прибором: ранжирует ответы других моделей, ставит оценки рассуждениям, решает, какие данные попадут в обучающую выборку. Надёжность здесь означает простую вещь: один и тот же запрос, отправленный одной и той же модели, должен давать один и тот же результат сегодня, завтра и через неделю. Без этого судья измеряет не качество ответов, а собственное флуктуирующее состояние.

Авторы работы «Clean Engineering, Unstable Measurement» отнеслись к судье как к лабораторному прибору. Пререгистрация, замороженные пороги, никаких постфактум-починок. Измеряемая система была простой: генератор решал детерминированные арифметические задачи с единственным каноническим ответом, а внешний наблюдатель (модель семейства qwen3.7-plus на shared endpoint) оценивал вероятность того, что видимый префикс решения приведёт к правильному ответу. Идеальная площадка для чистого измерения: ground truth известен точно, субъективности ноль.

Идеальная инженерия, провальное измерение

Первая кампания проверяла стабильность ранжирования внутри одного временного окна. Аудит исполнения показал потолок по всем инженерным метрикам: 3 312 запланированных вызовов, 3 312 доставленных ответов, ноль ретраев, ноль транспортных ошибок, ноль отказов, 100% совпадение тел запросов с замороженным планом по SHA-256. Всё, что может проверить инженерный аудит, было безупречно.

А затем сработал научный гейт. Медианный Spearman повторного ранжирования составил 0.400 против замороженного порога 0.90. Это не пограничный провал, это разгром.

Вторая кампания проверяла воспроизводимость на следующий день: сто байт-идентичных запросов, повторённых через сутки. Совпадение полных ранжирований: 78 из 100, то есть 0.78 против пререгистрированных 0.99. При этом все метаданные, которые отдаёт провайдер, оставались константными: строка модели, system_fingerprint, finish reason. По данным, доступным потребителю API, оба прогона выглядели идентичными. По результату они различались в каждом пятом случае.

Три механизма сбоя

Авторы разложили провал на три механизма, и каждый интересен сам по себе.

Первый, M1, это смещение маппинга меток. В протоколе метки A и B, означающие «верно» и «неверно», местами менялись, чтобы контролировать позиционные эффекты. Оказалось, что сама подмена метки инвертирует ранжирование: медианный Spearman на инвертированных парах составил минус 0.632. Модель реагирует не только на смысл, но и на то, какой буквой этот смысл обозначен. Величина смещения, медиана 0.250 логита, сопоставима с динамическим диапазоном самого сигнала, и оно не константно: на правильных кандидатах медиана смещения +0.531, на неправильных минус 0.250. Буква «A» подталкивает вердикт к «верно» сильнее, когда ответ действительно верен. Это не шум, это систематическая ошибка прибора.

Второй механизм, M2, это почти вырожденные различия между кандидатами. Медианный зазор между оценками составил 3 на 10 в минус десятой степени в единицах самого прибора, а треть пар давала точные ничьи. Прибор пытался ранжировать различия, которые лежат на семь порядков ниже его собственного уровня шума.

Третий, M3, самый неприятный: байт-идентичные входы возвращают разные ранжирования. А когда результат считывается как полная перестановка кандидатов, любая одиночная транспозиция обнуляет всю запись, и мелкий шум превращается в крупный расход.

Один эксперимент, три числа

Здесь кроется ловушка, о которой стоит знать каждому, кто читает бенчмарки. Одни и те же 100 дрейфующих повторов авторы посчитали тремя способами. Полное совпадение ранжирований: 0.78, провал. Совпадение по top-1: 0.95, «почти стабильно». Попарное согласие порядка: 0.986, «практически идеально».

Это не три эксперимента, это один эксперимент под тремя агрегациями. Разброс между 0.78 и 0.986 это ровно то пространство, в котором живёт motivated reasoning: хочешь опубликовать хороший результат, выбирай попарную метрику; хочешь честный, бери полное ранжирование. Пререгистрация существует именно для того, чтобы этот выбор был сделан до данных, а не после.

Усреднение не спасает

Естественная реакция на нестабильный прибор: усреднить. Прогнать не один запрос, а M независимых сэмплов и взять среднее. Авторы проверили этот путь детерминированной симуляцией на 500 репликах, масштабируя M от 8 до 500.

Арифметика безжалостна. Шум сэмплирования падает как корень из M, стандартная ошибка улучшилась в семь раз, а медиана гейта выросла лишь с 0.33 до 0.57. При M равном 500, это 748 000 вызовов наблюдателя, доля прохождения гейта осталась ровно нулевой: 0 из 500 реплик. Даже 95-й перцентиль статистики, 0.80, не дотянул до порога 0.90. Причина понятна из M2: усреднение сжимает знаменатель задачи (шум), но не трогает числитель (зазор между кандидатами, который в семь порядков меньше шума). Нельзя усреднением измерить то, что лежит ниже предела разрешения прибора.

Метаданные платформ ничего не гарантируют

Может ли потребитель API хотя бы узнать о нестабильности из метаданных? Авторы прогнали кросс-провайдерскую батарею по четырём провайдерам и проверили поле system_fingerprint. Оно отказывает тремя разными способами.

У mistral и qwen поле просто не заполняется, сгруппировать по нему ничего нельзя. У openai поле «живое»: 19 различных значений за один день батареи, 8 различных значений внутри одного окна из 37 вызовов, и пары с одинаковым фингерпринтом согласуются не лучше пар с разным (0.854 против 0.884). Самый поучительный случай deepseek: фингерпринт один, стабильный, семантически содержательный, с указанием билда, квантизации и даты. И даже под этим идеальным идентификатором полное совпадение ранжирований составило 0.879, далеко от требуемых 0.99. Недетерминизм живёт ниже уровня деплоя: ядра инференса зависят от формы батча, а батчи на shared endpoint формирует чужая нагрузка.

Дно оказалось общим для всех четырёх провайдеров, медианы от 0.74 до 0.88, и ни одно из выставляемых наружу полей его не предсказывает. Ожидание тоже не помогает: разложение дисперсии показало 0.805 согласия внутри дня против 0.800 между днями, разница 0.005. Это не «дрейф за ночь», это постоянный уровень шума.

Единственное, что реально подняло стабильность, это self-hosting на батч-инвариантных ядрах (подход, который Thinking Machines Lab описали в 2025 году). Но и там победа была условной: пока сервер простаивал. Под конкурентной нагрузкой даже батч-инвариантный стек скатился обратно в диапазон shared endpoint.

Что с этим делать

Авторы дистиллировали опыт в трёхуровневую лестницу идентичности снапшота и восемь правил дизайна. Лестница проста: L0 это shared endpoint, где имя модели не фиксирует ничего; L1 это закреплённый провайдером снапшот, который фиксирует веса, но не наблюдаемое поведение; L2 это self-hosted стек с батч-инвариантными ядрами, единственный уровень, где можно требовать побайтовой воспроизводимости, и то с оговорками про нагрузку.

Из восьми правил три заслуживают отдельного упоминания. Первое: замораживай снапшот раньше, чем доверяешь любому гейту стабильности. Второе: ни один гейт не должен замораживаться на величине, которую никто не измерил. Оба провальных гейта этой работы были заморожены на непилотированных порогах, а пилот, который вскрыл бы их недостижимость заранее, стоил 3 юаня, около 2% бюджета всего исследования. Третье: ранжирующий гейт должен считаться только по парам, которые прибор в принципе способен разрешить, а «большинство ниже предела обнаружения» нужно репортить как свойство выборки, а не как успех модели.

Для практиков вывод приземляется быстро. Если ваш RAG-конвейер гейтуется LLM-судьёй на shared endpoint, ваш CI мигает не из-за регрессий в коде. Если лидерборд строится на перестановочных метриках, его нижняя половина измеряет погоду в чужом дата-центре. И если вы сравниваете две модели через API-судью без контроля снапшота, вы не знаете, что именно сравнили.

Почему это важно именно сейчас

LLM-судья перестал быть академической игрушкой. Им гейтуют обучающие данные при пост-тренировке, им прогоняют regression-тесты в CI перед релизом агента, на его вердиктах строятся лидерборды, по которым принимают решения о закупке моделей. Экономика подталкивает именно к shared endpoints: держать собственный кластер под судью дорого, а API-вызов стоит копейки. Получается конвейер, в котором решения на миллионы долларов принимает прибор, чья стабильность никем не измерена.

Работа попадает в растущую линию исследований: позиционная предвзятость судей документирована ещё со времён MT-Bench, низкая самосогласованность при повторных вызовах измерена в 2025 году, а Thinking Machines Lab показали механизм недетерминизма на уровне ядер. Вклад этой статьи в другом: впервые нестабильность не просто описана, а поставлена в позицию пререгистрированного гейта с правом остановить исследование. Разница принципиальна. Описательное число можно обсуждать, замороженный порог имеет авторитет.

Часто задаваемые вопросы

Почему один и тот же запрос возвращает разные ответы?

Shared endpoint батчит конкурентные запросы от разных клиентов, а стандартные ядра инференса не батч-инвариантны: результат зависит от формы батча, которую формирует чужая нагрузка. Плюс деплои меняются под неизменным именем модели. Извне, по метаданным API, отличить эти состояния невозможно.

Значит ли это, что LLM-судьи бесполезны?

Нет. Работа показывает, что судья на shared endpoint это прибор с неизвестным уровнем шума, а не что он всегда неправ. Для грубых различий сигнала хватает. Провал наступает, когда от него требуют точности ниже предела разрешения: тонких ранжирований, побайтовой воспроизводимости, научных гейтов без калибровки.

Как сделать оценку LLM-судьёй воспроизводимой?

Подняться по лестнице снапшотов: в идеале self-hosted открытые веса на батч-инвариантных ядрах, как минимум закреплённый снапшот у провайдера. Затем пропилотировать уровень шума до заморозки любых порогов и считать гейты только по парам, которые прибор способен разрешить. Пилот на 2% бюджета вскрывает недостижимые пороги заранее.

Итог

52 988 аудированных запросов и две пререгистрированные кампании привели к выводу, который авторы сами формулируют как цитируемый: на shared endpoint имя модели это не замороженный прибор, и пререгистрированная оценка обязана измерить свой инструмент до того, как заморозит на нём хоть один гейт. Инженерная чистота конвейера ничего не говорит о надёжности измерения: у авторов обеих кампаний исполнение было на потолке, а наука не началась. Прежде чем в следующий раз доверять числу из лидерборда или автогейта в CI, задайте простой вопрос: а кто-нибудь мерил сам измеритель?