# Чому оцінки LLM-суддів пливуть на спільних API

> Новий препринт arXiv показує: чорноскринькові LLM-судді дають нестабільні оцінки на спільних API-ендпоінтах через сторонні інфраструктурні фактори.

- Опубліковано: 4 вересня 2026 р. (2026-09-04T04:15:03.489616+00:00)
- Розділ: AI-дослідження
- На основі публікації: [arXiv](http://arxiv.org/abs/2609.04198v1)
- Видання: AiiN (https://aiin.news)
- URL: https://aiin.news/article?slug=%D1%87%D0%BE%D0%BC%D1%83-%D0%BE%D1%86%D1%96%D0%BD%D0%BA%D0%B8-llm-%D1%81%D1%83%D0%B4%D0%B4%D1%96%D0%B2-%D0%BF%D0%BB%D0%B8%D0%B2%D1%83%D1%82%D1%8C-%D0%BD%D0%B0-%D1%81%D0%BF%D1%96%D0%BB%D1%8C%D0%BD%D0%B8%D1%85-api

---

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

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

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

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

Ключовий факт — оцінки одного й того самого чорноскринькового LLM-судді відрізняються між запусками одного бенчмарку, коли запити йдуть через спільний API-ендпоінт, а не через виділену інстанцію моделі. [За даними arXiv](http://arxiv.org/abs/2609.04198v1), це відтворена проблема надійності: результат тримається навіть у ретельно спроєктованому бенчмарку, де дослідник контролює промпти, метрики й порядок оцінювання.

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

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

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

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

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

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

- Продуктові команди, які ганяють LLM-as-a-judge у CI/CD як gate перед релізом промпту чи моделі
- Дослідницькі групи, що будують публічні лідерборди на основі API-суддів
- MLOps-інженери, які моніторять якість відповідей у продакшені через автоматичну оцінку

Проблема системна для індустрії: подібні шумові ефекти спільної інфраструктури вже спостерігали на рівні збоїв провайдерів — ми розбирали, [чому провайдери приховують причини збоїв](https://aiin.news/article?slug=збої-openai-та-anthropic-чому-провайдери-приховують-причини), і там теж корінь проблеми ховається за фасадом API, недоступним для зовнішнього дослідника.

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

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

- Прогоняти кожен оцінюваний варіант кілька разів (мінімум 3-5) і дивитися на розкид, а не на одне число
- Там, де це можливо, використовувати виділені інстанції або self-hosted судді замість спільних публічних ендпоінтів
- Ставитися до різниці в оцінках у межах кількох відсотків як до шуму інфраструктури, а не як до сигналу про реальну регресію

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

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

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

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

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

---

Теги: LLM, AI-дослідження, бенчмарки, LLMasJudge, arXiv, MLOps

Джерело: AiiN — https://aiin.news/article?slug=%D1%87%D0%BE%D0%BC%D1%83-%D0%BE%D1%86%D1%96%D0%BD%D0%BA%D0%B8-llm-%D1%81%D1%83%D0%B4%D0%B4%D1%96%D0%B2-%D0%BF%D0%BB%D0%B8%D0%B2%D1%83%D1%82%D1%8C-%D0%BD%D0%B0-%D1%81%D0%BF%D1%96%D0%BB%D1%8C%D0%BD%D0%B8%D1%85-api. Цитуючи, посилайтесь на канонічний URL.