Kto osądza sędziego? Ukryte uprzedzenie w LLM-as-a-judge

W miarę jak pętle agentowe stają się coraz bardziej autonomiczne, dokonuje się cicha podmiana: gdzieś w pętli człowiek przestaje oceniać output, a zaczyna LLM. To niemal nieuniknione w skali. Nie sposób ręcznie przejrzeć każdego kandydującego patcha, każdego wygenerowanego testu, każdego szkicu, który produkuje agent — więc prosisz inny model, by je punktował, rankingował i decydował, który przechodzi dalej. LLM-as-a-judge stał się domyślnym ewaluatorem ery agentowej, siedzącym wewnątrz verification gates, leaderboardów i pętli patch selection.

Co rodzi pytanie, którego nikt nie zadaje wystarczająco często: kto sprawdza sędziego? Bo badania z 2026 roku są jasne, że judge ma systematyczne, mierzalne uprzedzenia — i nie są to uprzedzenia, przed którymi większość zespołów myśli się bronić.

Uprzedzenie, którego nie pilnujesz

Gdy ludzie martwią się o LLM judges, zwykle martwią się o position bias — to, że judge faworyzuje tę odpowiedź, którą pokazano pierwszą. Jest realne, jest dobrze znane, i większość poważnych setupów ewaluacyjnych już je kontroluje przez zamianę kolejności. Problem w tym, że position bias okazuje się tym małym.

Badanie z 2026 roku, Judging the Judges (arXiv 2604.23178), zmierzyło dziewięć strategii debiasingu w pięciu judge models z czterech rodzin dostawców (Google, Anthropic, OpenAI, Meta) na trzech benchmarkach. Jego czołowy wniosek przestawia listę zagrożeń: „Style bias is the dominant bias (0.76–0.92 across all models), far exceeding position bias (≤ 0.04), yet has received minimal research attention.” Przeczytaj te wielkości jeszcze raz. Uprzedzenie ku dopracowanej, pewnej siebie, dobrze sformatowanej prezentacji jest o rząd wielkości większe niż to, które wszyscy już kontrolują — i jest tym, którego niemal nikt nie mierzy.

To powinno mocno uderzyć, bo styl to dokładnie ten wymiar, który zdolny generator dobrze maksymalizuje niezależnie od substancji. Model potrafi wyprodukować pewny siebie, płynny, ładnie ustrukturyzowany output, który jest błędny, a judge z uprzedzeniem stylistycznym go nagrodzi. Badanie odnotowuje jednak uspokajający niuans — judges całkiem dobrze odróżniają jakość od surowej długości (0,92–1,00 dokładności na kontrolach przycięcia), więc nie jest to naiwny efekt „dłuższe = lepsze”. Jest subtelniejszy i groźniejszy niż to: judge daje się zwieść prezentacji, dokładnie temu, co nie koreluje ani z poprawnością, ani z tym, co próbujesz zmierzyć.

W kodzie werdykt odwraca się na sygnałach, nie na substancji

Dla każdego, kto używa judge’a do ewaluacji kodu, robi się ostrzej. Towarzyszące badanie z 2026 roku, Bias in the Loop: Auditing LLM-as-a-Judge for Software Engineering (arXiv 2604.16790), badało judges w code generation, code repair i test generation — dokładnie tych agentowo-inżynierskich ustawieniach, gdzie, jak to ujmuje, judge „can help rank candidate solutions and guide patch selection.”

Wniosek jest niepokojący: „judge decisions are highly sensitive to prompt biases even when the underlying code snippet is unchanged.” Ten sam kod, inny sygnał prezentacyjny, inny werdykt. Co gorsza, uprzedzenia „systematically shift preferences toward the option favored by the prompt, improving accuracy when that option aligns with the gold answer but substantially reducing it otherwise” — a „in some settings, these effects are large enough to change task-level conclusions and alter relative model rankings.” Konkluzja autorów jest bezceremonialna: „reported judge performance may reflect prompt artifacts rather than stable assessment ability, posing a direct threat to the validity and reproducibility of code evaluation.”

Zatrzymaj się nad tym, co to znaczy w pętli. Jeśli judge wybiera, którego patcha agent wysyła, częściowo na podstawie artefaktów prezentacji, uprzedzenie nie zostaje w ewaluacji — wpływa do twojej bazy kodu, jeden wybrany patch na raz. Brama, którą zainstalowałeś, by łapać zły output, sama podejmuje decyzje z powodów, które nie mają nic wspólnego z tym, czy output jest dobry.

Wyobraź sobie dwa kandydujące patche na ten sam bug. Jeden jest poprawny, ale zwięzły — bez komentarzy, dosadna nazwa zmiennej, jednolinijkowa poprawka. Drugi jest subtelnie błędny, ale pięknie zaprezentowany — przemyślany komentarz wyjaśniający rozumowanie, opisowe nazwy, czysta struktura. Judge z uprzedzeniem stylistycznym, zapytany, którego zmergować, skłania się ku pewnej siebie, dobrze ubranej błędnej odpowiedzi. Ludzki recenzent pędzący przez kolejkę popełniłby ten sam błąd — ale wdrożyliśmy judge’a właśnie po to, by był rygorystyczną kontrolą, którą pędzący człowiek nie jest, a zamiast tego zautomatyzował on to samo uprzedzenie w skali i z prędkością maszyny.

Dlaczego to gorsze niż zaszumiona metryka

Z zaszumionym ewaluatorem dałbyś radę żyć — szum uśrednia się przy dostatecznej liczbie próbek. Uprzedzenie nie. Jest systematyczne i jest skorelowane z niewłaściwym sygnałem, więc więcej próbek go nie wypłucze; one go utrwalają. Wynikają z tego trzy konsekwencje, a każda kąsa inną decyzję.

Po pierwsze, leaderboardy kłamią w konkretnym kierunku. Ranking zbudowany na judge’u z uprzedzeniem stylistycznym nie ma po prostu słupków błędu — systematycznie przeszacowuje model, który prezentuje się najlepiej, a który może nie być modelem najbardziej poprawnym. Jeśli wybierasz agenta z takiego leaderboardu, odziedziczyłeś uprzedzenie judge’a jako swoją decyzję zakupową. To kumuluje się z luką, o której pisaliśmy w luce niezawodności: benchmark może już mierzyć niewłaściwą właściwość, a teraz judge punktujący ten benchmark dokłada na wierzch własne zniekształcenie.

Po drugie, twój verification gate przecieka. Argumentowaliśmy, że zła pętla wysyła zły kod szybciej — a brama, która punktuje polor zamiast poprawności, to zła pętla w kitlu laboratoryjnym. Sprawia wrażenie rygorystycznej, bo jest do niej doczepiona liczba, ale ta liczba częściowo mierzy niewłaściwą rzecz.

Po trzecie, porażka jest niewidzialna. Judge z uprzedzeniem nie rzuca błędu; zwraca pewny siebie wynik. Nic w pipeline nie sygnalizuje, że wynik odzwierciedla prezentację, a nie substancję. Odkrywasz to dopiero, gdy „zewaluowany, zatwierdzony” output zawodzi na produkcji — a w tym momencie judge po cichu kierował pętlą w złą stronę przez długi czas.

Skalibruj sędziego — nie ufaj mu

Naprawa nie polega na porzuceniu LLM-as-a-judge; w skali często nie ma alternatywy. Naprawa polega na tym, by przestać traktować judge’a jak wyrocznię i zacząć traktować go jak instrument wymagający kalibracji. Kilka zasad wynika wprost z badań:

Mierz wrażliwość judge’a na uprzedzenia, nie tylko jego dokładność. Bias in the Loop argumentuje dokładnie to: raportuj wrażliwość na uprzedzenia obok dokładności i przeprowadzaj kontrolowane interwencje, które izolują jeden sygnał prezentacyjny na raz. Liczba dokładności bez audytu uprzedzeń to połowa wyniku.
Debiasinguj rozmyślnie — ale zweryfikuj, że pomogło. Debiasing działa, ale jest zależny od modelu: Judging the Judges ustaliło, że strategia łączonego budżetu poprawiła Claude Sonnet 4 o +11,2 punktu procentowego, przy czym tylko 2 z 20 konfiguracji niebazowych faktycznie obniżyły zgodność. Łagodzenie jest więc warte zachodu, ale nie jest darmowe ani uniwersalne — musisz sprawdzić, że zadziałało dla twojego judge’a.
Preferuj weryfikowalne sygnały tam, gdzie istnieją. Gdy pytanie brzmi „czy ten kod działa”, test suite jest bezstronnym sędzią — nie obchodzi go, jak pewnie brzmią komentarze. Zarezerwuj LLM judge’a dla naprawdę subiektywnych rozstrzygnięć, a wykonywalną weryfikację pozwól unieść resztę.
Nigdy nie pozwól, by jeden niezaudytowany judge bramkował cokolwiek, co ma znaczenie. Zamieniaj pozycje, zmieniaj prezentację, używaj panelu i traktuj czysty wynik judge’a jako hipotezę do potwierdzenia, a nie werdykt do działania.

Myśl przewodnia: judge jest częścią twojej aparatury pomiarowej, a nieskalibrowany instrument produkuje pewne siebie, precyzyjne, błędne odczyty.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która ma znaczenie dla tego regionu, i ma znajomy kształt. Audytowanie i kalibrowanie harnessa ewaluacyjnego to czysty inżynierski osąd — nie kosztuje żadnych GPU, żadnego frontierowego modelu, żadnego kapitału. To praca projektowania kontrolowanych testów, sondowania pod kątem uprzedzeń i odmowy zaufania liczbie, której nie przesłuchałeś. To dyscyplina, którą skupiony zespół buduje rozmyślnie, i jest warta więcej, niż na to wygląda.

Bo większość rynku robi coś przeciwnego: ufa leaderboardom dostawców i surowym wynikom judge’ów bezkrytycznie, dziedzicząc uprzedzenia, których nigdy nie zmierzyła. Zespół w Phnom Penh albo Da Nang, który buduje własne ewaluacje świadome uprzedzeń — który wie, że jego judge nadmiernie nagradza polor, i koryguje to — może ufać swoim pomiarom, gdy konkurenci nie mogą, i wybrać naprawdę lepszy model oraz naprawdę lepszego patcha, podczas gdy inni gonią za prezentacją. To dyscyplina loop-engineeringu zastosowana do tej części pętli, która decyduje, co w ogóle znaczy „dobre”. Pomyl się co do judge’a, a każda decyzja w dół strumienia odziedziczy ten błąd; zrób to dobrze, tanio, a zbudowałeś przewagę pomiarową, której żadna ilość mocy obliczeniowej nie kupi.

Agent będzie dalej generować, a ty będziesz dalej potrzebować czegoś, co to oceni. Pamiętaj tylko, że oceniający ma własne opinie — a najbardziej niedoceniana praca w stosie agentowym to upewnianie się, że te opinie dotyczą właściwej rzeczy.