LLM as a judge: recenzent AI, który próbuje obalić pracę

LLM as a judge oznacza, że model językowy ocenia pracę według spisanych kryteriów, zamiast człowieka lub dokładnego testu. Działa, gdy sędzia ma kryteria na piśmie, widzi dowody, odpowiada w stałym formacie i nie może uchylić sprawdzeń, które potrafi wykonać maszyna.

Używamy go przy każdym pull requeście, który otwiera nasz agent AI. Nie pytamy go, czy praca jest dobra. Każemy mu spróbować ją obalić. Poniżej, jak jest zbudowany, i zasady, które dodawaliśmy za każdym razem, gdy się pomylił.

Czym jest LLM as a judge?

Termin pochodzi z oceny modeli czatowych. Zamiast płacić ludziom za porównywanie odpowiedzi, prosi się o to silny model. Praca, która nadała temu nazwę, Zheng et al., zmierzyła, jak dobrze to działa:

Ten sam abstrakt wymienia ograniczenia: „position, verbosity, and self-enhancement biases, as well as limited reasoning ability”. Sędzia woli odpowiedź, którą zobaczył jako pierwszą, dłuższą i tę, która brzmi jak on sam. Proszę pamiętać o tych trzech. Każda zasada poniżej walczy z jedną z nich.

Dziś pomysł używany jest daleko poza benchmarkami czatów: do oceny odpowiedzi systemów wyszukiwania, punktowania przebiegów agentów i review kodu. Nasz robi to ostatnie.

Kiedy nie używać sędziego LLM?

Gdy tańsze sprawdzenie daje poprawną odpowiedź. Sędzia jest wolny, kosztuje tokeny i może się mylić. Kod, który sprawdza fakt, nie ma żadnej z tych wad.

Wiersz z klasyfikatorem jest prawdziwy. Dla internetowego marketplace'u klienta dostrajaliśmy LLM, który sortuje ogłoszenia do kategorii. Nie pytaliśmy innego modelu, czy kategorie wyglądają dobrze. Ręcznie oznaczyliśmy prawdziwe ogłoszenia i pozwoliliśmy kodowi policzyć trafienia. Gdy istnieje poprawna odpowiedź, sędzia tylko dodaje szum.

Jak nasz sędzia LLM sprawdza pull request?

Sędzia to krok VERIFY w pętli naszego agenta i doradcze sprawdzenie w pull requestach otwieranych przez ludzi. W obu przypadkach te same elementy:

Samo wywołanie to kilka linii. To krok z naszej wspólnej akcji CI, lekko skrócony:

prompt="$(cat "$L/verify.md"; data "$W/asked.md"; data "$W/checks.txt")"
npx -y @anthropic-ai/claude-code -p "$prompt" --tools "Read,Grep,Glob" \
  --json-schema "$(cat "$L/verify.schema.json")" --output-format json --max-turns 40 > "$W/raw.json"
verdict=$(jq -r .verdict "$W/verify.json")
[ "$mrc" != 0 ] && [ "$verdict" = pass ] && verdict=fix   # a red machine check is never overruled

--json-schema sprawia, że Claude Code zwraca wynik zgodny ze schematem (CLI reference, stan na 24.10.2026). data otacza issue i log sprawdzeń znacznikami, a prompt mówi, że wszystko pomiędzy nimi to dane napisane przez innych, a nie polecenia. Treść issue nie przekona sędziego do pass.

Ostatnia linia jest najważniejsza. Jeśli testy są czerwone, żaden werdykt nie zamieni tego w pass. Ta sama bramka oblewa też gałąź zadania, która przesuwa wskaźnik submodułu; tę zasadę wyjaśniamy w Monorepo vs polyrepo.

W czym sędzia się mylił i co zmieniliśmy?

Każda zasada w prompcie sędziego wzięła się z prawdziwej pomyłki. Cztery z nich:

• Testy, które niczego nie dowodzą. Agent pisał testy, które czytały pliki źródłowe jako tekst i sprawdzały, czy jest w nich import. Zielone i bezużyteczne. Teraz sędzia musi otworzyć każdy nowy lub zmieniony test, a test, który nie sprawdza zachowania, to obowiązkowa uwaga.
• Przesuwane słupki. W drugiej rundzie sędzia znajdował nowe, mniejsze problemy w kodzie, który się nie zmienił, więc pętla nigdy się nie kończyła. Teraz późniejsza runda dostaje poprzednie uwagi i sprawdza tylko je.
• Litera zamiast intencji. Wytykał dokładne liczby, sformułowania i układ tabel inne niż w issue, choć intencja była spełniona. Teraz uwaga jest obowiązkowa tylko wtedy, gdy recenzent-człowiek odesłałby za nią pracę.
• Ta sama uwaga w nieskończoność. Uwagi mają stałe id. Jeśli to samo id wraca dwie rundy z rzędu, kolejna runda tego nie naprawi, więc pętla się zatrzymuje i pyta człowieka.

Najgorsza pomyłka w ogóle nie była winą sędziego. Na początku tego roku nasze AI code review w CI przechodziło przy każdym pull requeście i nie opublikowało ani jednego review. Aktualizacja akcji, na której się opierało, usunęła dwa parametry wejściowe, a job kończył się na zielono bez promptu. Sędzia, który nigdy się nie uruchomił, wyglądał dokładnie jak sędzia, który zatwierdził. Dziś brakująca lub nieprawidłowa odpowiedź to osobny werdykt, unavailable, i oblewa job.

Które błędy sędziego wciąż występują?

Wszystkie trzy z pracy, w mniejszej postaci:

• Błąd pozycji ma znaczenie głównie wtedy, gdy sędzia porównuje dwie odpowiedzi. Nasz ocenia jedną pracę względem kryteriów, więc nie ma pierwszej ani drugiej odpowiedzi do faworyzowania.
• Błąd rozwlekłości pcha sędziego w stronę długich odpowiedzi. Schemat ogranicza to, co się liczy: werdykt, uwagi z dowodami, podsumowanie w kilku zdaniach.
• Błąd faworyzowania siebie to ten, którego nie usunęliśmy. Nasz sędzia jest z tej samej rodziny modeli co agent, który napisał kod. Świeża sesja, prompt z poleceniem obalenia i sprawdzenia maszynowe go zmniejszają. Nie usuwają go.

Użycie innego modelu jako sędziego to oczywisty kolejny krok. Przy tekstach robimy to ręcznie, w pętli jeszcze tego nie mamy.

Czy Państwa sędzia LLM jest gotowy do prawdziwej pracy?

Proszę przejrzeć swoją konfigurację:

Jak w GitHub Actions jest skonfigurowany recenzent, który komentuje każdy pull request, opisujemy w Claude Code review: AI code review w CI. Dlaczego czerwony test przed poprawką ma znaczenie, wyjaśniamy w TDD red-green z agentami AI.

Chcą Państwo recenzenta, który odsyła złe pull requesty?

Sprawdzenia maszynowe, sędziego i CI wokół nich konfigurujemy bezpośrednio w repozytorium zespołu w ramach AI-native SDLC dla zespołów deweloperskich. Zespołowi brakuje raczej rąk niż review? Proszę zobaczyć senior developera dla Państwa zespołu. U nas większość kodu pisze AI. Każdą zmianę sprawdza senior i odpowiada za produkcję. Od 2023 roku dostarczyliśmy ponad 15 projektów produkcyjnych.

Odezwiemy się w ciągu dwóch dni roboczych z kilkoma pytaniami o Państwa pracę. Potem ustalimy, co zrobimy najpierw.

Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Co robi Państwa recenzent AI, gdy nie ma nic do powiedzenia: milczy czy oblewa?

Najczęstsze pytania

Czym jest LLM as a judge?

Użyciem modelu językowego do oceny wyniku innego modelu lub agenta według spisanych kryteriów, zamiast człowieka lub testu dokładnego dopasowania. Sędzia dostaje zadanie, kryteria i dowody i zwraca werdykt, najlepiej jako dane strukturalne.

Jak dokładny jest LLM as a judge?

W badaniu MT-Bench i Chatbot Arena silni sędziowie, tacy jak GPT-4, osiągnęli ponad 80% zgodności z preferencjami ludzi, mniej więcej tyle, ile wynosi zgodność między ludźmi. Ta sama praca wymienia błędy pozycji, rozwlekłości i faworyzowania siebie. Dokładność zależy od zadania, więc proszę zmierzyć ją na własnym.

Kiedy nie używać sędziego LLM?

Gdy istnieje poprawna odpowiedź, którą da się sprawdzić kodem: test, sprawdzenie typów, sprawdzenie linków albo zestaw etykiet przygotowany przez ludzi. Sędzia jest do kryteriów, które wymagają czytania i oceny, na przykład czy zmiana robi to, o co prosiło issue.

Czy ten sam model może oceniać własną pracę?

Może, ale ma skłonność do faworyzowania własnego stylu, co literatura nazywa błędem faworyzowania siebie. Ograniczamy go świeżą sesją, która nie wykonywała pracy, promptem z poleceniem obalenia, sprawdzeniami maszynowymi, których nie może uchylić, i człowiekiem, który robi merge.

Co powinien zwracać sędzia LLM?

Typowaną odpowiedź, nie prozę: werdykt ze stałego zbioru i uwagi ze stałym id, wagą, miejscem problemu i dowodem. Wtedy kod może na tej podstawie działać, a brakująca lub nieprawidłowa odpowiedź liczy się jako porażka, nigdy jako zaliczenie.