Препринт arXiv 2609.04198, опублікований у вересні 2026 року, документує конкретну і відтворену проблему: чорноскринькові LLM-судді — моделі, які автоматично виставляють бали відповідям інших моделей, — дають різні оцінки для того самого запиту залежно від того, через який API-ендпоінт цей запит пройшов.

Це не чергова методологічна причіпка до бенчмарків. Дослідники показують: навіть коли промпт, температура, seed і всі інші параметри експерименту зафіксовані, фінальна оцінка судді хитається через фактори інфраструктури провайдера, які дослідник не контролює і найчастіше навіть не бачить.

Для команд, які вбудували LLM-as-a-judge у CI-пайплайн чи в моніторинг якості продукту, висновок неприємний: червоний прапорець у нічному прогоні тестів може означати шум спільного ендпоінта, а не реальну регресію моделі чи промпту.

Що саме зафіксували дослідники?

Ключовий факт — оцінки одного й того самого чорноскринькового LLM-судді відрізняються між запусками одного бенчмарку, коли запити йдуть через спільний API-ендпоінт, а не через виділену інстанцію моделі. За даними arXiv, це відтворена проблема надійності: результат тримається навіть у ретельно спроєктованому бенчмарку, де дослідник контролює промпти, метрики й порядок оцінювання.

Головна відмінність від типової дискусії про нестабільність LLM — джерело шуму. Мова не про недетермінізм самої моделі на рівні семплінгу, а про сторонні інфраструктурні фактори — те, що відбувається на боці провайдера між моментом, коли запит іде, і моментом, коли повертається бал.

Чому спільний ендпоінт спотворює оцінку під капотом?

Спільний API-ендпоінт означає, що запит судді виконується не ізольовано, а в одному потоці з тисячами інших запитів від інших користувачів у той самий момент. Провайдер балансує навантаження, динамічно формує батчі запитів і може перемикати трафік між інстанціями чи навіть версіями розгортання моделі — і жоден з цих кроків не видно дослідникові, який просто отримує JSON-відповідь з оцінкою.

Ймовірно, саме динамічний батчинг і маршрутизація між інстанціями на спільній інфраструктурі є найбільш реалістичним поясненням: обчислення для одного й того самого промпту фактично відбуваються в різному оточенні від запуску до запуску, а LLM-судді, на відміну від простих класифікаторів, чутливі до найменших відхилень, коли справа доходить до межевих оцінок.

Кому це болить найбільше вже сьогодні?

Найбільше ризикують команди, які використовують сторонні комерційні API як суддю в оцінці якості, а не власну задеплоєну модель на виділеному залізі. Це:

Проблема системна для індустрії: подібні шумові ефекти спільної інфраструктури вже спостерігали на рівні збоїв провайдерів — ми розбирали, чому провайдери приховують причини збоїв, і там теж корінь проблеми ховається за фасадом API, недоступним для зовнішнього дослідника.

Що робити з цим прямо зараз?

Наша теза в AiiN: LLM-as-a-judge залишається корисним інструментом, але лише як відносний, а не абсолютний вимірювач — і тільки якщо оцінки збираються з контролем за варіативністю ендпоінта, а не одноразовим прогоном. Практично це означає:

Якщо ваш CI блокує реліз через падіння оцінки судді на 2-3 пункти зі 100 — це, за нашою оцінкою, вартує перевірки на повторюваність, перш ніж відкочувати реліз.

Чи означає це, що LLM-as-a-judge більше не можна довіряти?

Ні, повністю відмовлятися не варто — проблема не в самому підході, а в умовах вимірювання. Оцінка залишається корисною для порівняння варіантів у відносних термінах, якщо усунути змінну спільного ендпоінта повторними прогонами чи виділеною інфраструктурою.

Як перевірити, чи власний бенчмарк постраждав від цієї проблеми?

Прогоніть той самий набір запитів і відповідей через суддю кілька разів поспіль у різний час доби та подивіться на розкид оцінок. Якщо стандартне відхилення сумірне з різницею, яку ви вважаєте значущою для рішення про реліз, ваш бенчмарк вразливий до шуму спільного ендпоінта.