Bez hype'u
Zacznij pisać, aby wyszukać...
nawigacjaotwórz
CtrlKszukaj
← Wszystkie notatki

LLM-as-a-judge - co wpływa na jakość recenzji, a co nie

Na jakość recenzji AI najmniej wpływa prompt. Istnieją dwie ważniejsze zmienne - relacja recenzent-autor i generacja modelu - obie zmieniają wynik o dziesiątki punktów procentowych.

Udostępnij

Branża spędza coraz więcej czasu na optymalizacji promptów do recenzji AI. Lepsze instrukcje, dłuższe checklisty, bardziej szczegółowe rubric - zakładając, że precyzyjniejsza prośba da lepszą recenzję.

Przeprowadziłem pilotaż na 216 recenzjach - 4 modele, 27 próbek kodu i treści, dwa poziomy instrukcji (zero-shot i rozbudowana konfiguracja recenzenta). Wyniki sugerują, że jakość promptu ma najmniejszy wpływ na wynik. Relacja recenzent-autor i generacja modelu zmieniają wynik wielokrotnie bardziej.

Trzy zmienne, jedna hierarchia

W pilotażu mierzyłem wpływ trzech zmiennych na wykrywalność błędów. Okazało się, że tworzą wyraźną hierarchię - każda następna ma kilkukrotnie mniejsze znaczenie od poprzedniej:

Kto recenzuje czyje

Ten sam model, ten sam prompt - a wyniki różnią się o dziesiątki punktów procentowych w zależności od autorstwa materiału:

ModelNa swoimNa cudzymRóżnicaOgólna
Claude Opus 4.614.3%93.8%79.5pp73.1%
GPT-5.5 (Codex)91.7%*41.7%-50.0pp69.4%
GPT-4o API41.7%29.2%-12.5pp36.1%
Gemini 2.5 ProN/A70.4%-70.4%

Gemini nie miał próbek własnych w benchmarku - służył jako grupa kontrolna. Kolumna “Ogólna” to wykrywalność na wszystkich próbkach (ważona liczbą próbek, nie średnia dwóch kolumn).

Claude Opus 4.6 jest najlepszym recenzentem w pilotażu - dopóki nie sprawdza własnej pracy. Wtedy traci ponad 80% skuteczności.

*GPT-5.5 na materiałach OpenAI wykazał 91.7% - ale to nie samodyscyplina. GPT-5.5 recenzował kod GPT-3.5 i GPT-4, modeli o jedną-dwie generacje starszych. To jak senior, który sprawdza kod juniora z tej samej firmy - łapie więcej, ale nie dlatego że jest obiektywny. Dlatego że jest lepszy. GPT-4o - bliższy generacyjnie GPT-4 - wykazał już tylko 41.7%. Im mniejsza luka, tym silniejszy bias.

W cross-review najnowszych generacji różnice też są wyraźne: GPT-5.5 41.7%, Gemini 70.4%, Claude 93.8%. Model ma znaczenie nawet gdy recenzuje cudzy materiał.

Ale kolumna “Ogólna” mówi coś zaskakującego - po uśrednieniu self i cross review, top 3 modele lądują blisko siebie (69-73%). Fatalne self-review Claude ściąga jego średnią w dół. Świetne self-review GPT-5.5 ciągnie w górę. Efekt netto: wyrównanie - ale z zupełnie innych powodów.

Co mówi literatura. Panickssery et al. (NeurIPS 2024) zbadali self-preference na GPT-4, GPT-3.5 i Llamie-2. Wynik: preferencja wobec własnych tekstów jest liniowo skorelowana z rozpoznawaniem ich. Im silniejszy model, tym silniejszy bias. Zmiana promptu go nie eliminuje.

Porównanie. Kierunek moich danych jest spójny z Panickssery. Skala biasu w pilotażu (79.5pp) jest dramatycznie wyższa niż w ich eksperymentach - ale oni mierzyli preferencję na streszczeniach, nie wykrywalność bugów w code review. Inna domena, inna metryka, mała próba. Pilotaż nie rozstrzyga skali, ale sygnał jest jednoznaczny: model recenzujący własny output działa fundamentalnie inaczej niż recenzujący cudzy.

Luka generacyjna

GPT-4o przez API: 36.1% wykrywalności. GPT-5.5 przez Codex CLI: 69.4%. Ten sam vendor, te same próbki, ten sam prompt. Dwukrotna różnica.

Wykrywalność to połowa historii.

ModelDodatkowe trafieniaFalse positiveRatio
GPT-5.567416.75:1
Claude5486.75:1
GPT-4o API3233~1:1

Nowszy model widzi więcej i halucynuje mniej. GPT-5.5 znalazł 67 prawdziwych problemów poza zestawem referencyjnym przy 4 false positive’ach. GPT-4o API: niemal tyle samo szumu co sygnału.

Wszystkie modele radziły sobie lepiej z treścią niż z kodem.

ModelContentKodRóżnica
Claude91.7%58.3%-33pp
Gemini79.2%63.3%-16pp
GPT-5.575.0%65.0%-10pp
GPT-4o API54.2%21.7%-33pp

Błędy treściowe (fakty, logika, AI-izmy jak “delve” czy “wieloaspektowy”) są widoczne na powierzchni tekstu. Błędy w kodzie wymagają śledzenia przepływu programu i rozumienia edge case’ów. Generacja modelu ma jeszcze większe znaczenie tam, gdzie zadanie jest trudniejsze.

Co mówi literatura. Krumdick et al. (“No Free Labels”, 2025) wykazali, że gdy model-sędzia nie zna poprawnej odpowiedzi, jego zgodność z ocenami ekspertów spada z ~0.8 do 0.30 (skala 0-1). Żadna rubric nie nadrabia braku zdolności. Jedyne co pomaga - podanie referencyjnej odpowiedzi napisanej przez człowieka.

Porównanie. Spójne. GPT-4o API nie “nie dostał instrukcji” - dostał identyczne jak GPT-5.5. Brakuje mu zdolności, nie wskazówek. Narzędzie zmienia wynik. Instrukcja obsługi - minimalnie.

Prompt ma najmniejsze znaczenie

Konfiguracja recenzenta w pilotażu obejmowała definicję roli eksperta, trzyprzebiegowy proces weryfikacji, 22-punktową listę kontrolną per domena i kalibrację zapobiegającą false positive’om. Rezultat: Claude zyskał 1.8 punktu procentowego. Gemini 7.4. GPT-4o 1.8. GPT-5.5 stracił 1.8.

Gemini wyraźnie skorzystał - co sugeruje, że bardziej potrzebuje struktury niż Claude czy GPT-5.5. Ale nawet najlepszy wynik (7.4pp) to ułamek tego, co daje zmiana modelu (33pp) lub relacji recenzent-autor (79.5pp).

Co mówi literatura. Microsoft LLM-Rubric (Hashemi et al., ACL 2024) deklaruje “2x redukcję błędu”. Gdy autorzy rozkładają system na części, obraz się zmienia: sama rubric bez sieci kalibracyjnej i ludzkich adnotacji daje ułamek tego wyniku. “2x” wymaga pełnego pipeline’u - rubric + dane treningowe + sieć neuronowa. Osobno, Pathak et al. (“Rubric Is All You Need”, ICER 2025) pokazali, że rubric specyficzna per zadanie daje 4x lepszą zgodność z ludźmi niż generyczna - ale tylko na trudnych zadaniach. Na łatwych różnica jest minimalna.

Porównanie. Moje +1.8-7.4pp mieści się w dolnym zakresie “sama rubric generyczna” z literatury. Ale jest istotna różnica w modelach: Microsoft testował na gpt-3.5-turbo, Pathak na GPT-4o-mini i Claude 3.7 Sonnet. Mój pilotaż - na Claude Opus 4.6, GPT-5.5 i Gemini 2.5 Pro. Nowsze generacje mogły zinternalizować protokoły recenzji, które starsze modele musiały dostawać w prompcie. Konfiguracja powtarza im to, co już wiedzą.

Żaden z czterech modeli nie wykrył bugów z automatycznych testów jednostkowych - 0% na całej kategorii. Recenzenci szukali wzorców w tekście kodu. Żaden nie “uruchomił kodu w głowie”. Konfiguracja nie pomoże tam, gdzie granica jest fundamentalna, nie promptowa.

Co zostaje

Niezależna literatura - Panickssery et al., Krumdick et al. i rozkład Microsoftu na komponenty - potwierdza kierunek danych z pilotażu. Kto recenzuje czyje i jakim modelem, ma wielokrotnie większe znaczenie niż forma prośby.

Ale to dane z pilotażu na 27 próbkach z przewagą oczywistych bugów. Czy hierarchia utrzyma się przy subtelniejszych problemach - błędach logiki, nieoptymalnej architekturze, pominięciu edge case’a? Czy konfiguracja recenzenta zacznie mieć znaczenie, gdy defekty przestaną być binarne?


W newsletterze rozwijam tego rodzaju tematy głębiej. Zapisz się.