Cos’è LLM-as-a-judge e quando fidarsi del modello giudice?
Con LLM-as-a-judge è un modello a dare un punteggio alla risposta di un altro. Ecco come abbiamo verificato il nostro giudice.
In sintesi. LLM-as-a-judge (modello giudice) è il metodo in cui l’output di un modello viene valutato, con un punteggio, da un altro modello linguistico. Mentre sviluppiamo diffox lo usiamo per abbinare i rilievi della code review ai bug che delle persone hanno segnalato in anticipo. Questo articolo racconta i bias noti del metodo e come, ad agosto 2026, abbiamo verificato il nostro giudice su 891 coppie (ogni coppia è un rilievo della review e un bug segnalato).
- Al giudice non chiedere «è buono?», chiedi «è lo stesso?». Una risposta di una parola alla domanda «questi due testi descrivono lo stesso bug?» si può verificare; un punteggio dato alla domanda «questo output è buono?» no.
- L’accordo complessivo inganna. Su 945 coppie in comune i nostri due giudici erano d’accordo nel 98,8% dei casi; sulle coppie positive, quelle che decidono il risultato, l’accordo era del 93,5%.
- Il giudice economico è risultato generoso, ma ha spostato poco il punteggio. Delle 400 coppie che il giudice economico dava per abbinate, il giudice più potente ne ha respinte 24 (6,0%). Quando abbiamo valutato una configurazione con tre giudici diversi, la differenza più grande è stata 0,033: sotto la soglia di rumore della misura (0,09).
- Il rumore vero non sta nel giudice, ma nell’esecuzione. Cambiare giudice ha spostato il punteggio al massimo di 0,033; la deviazione standard dello stesso sistema da un’esecuzione all’altra è 0,094.
Cos’è LLM-as-a-judge?
Spesso l’output di un modello linguistico non si può confrontare con un’unica risposta corretta: due commenti che descrivono lo stesso bug possono essere scritti con parole del tutto diverse. LLM-as-a-judge colma questo vuoto: la valutazione la fai fare a un altro modello, a cui dai un’istruzione (una rubrica). In italiano lo chiameremo «modello giudice».
Il lavoro che ha reso popolare il nome del metodo è l’articolo di Zheng e colleghi del 2023: hanno mostrato che i modelli giudice più forti sono d’accordo con le preferenze umane in oltre l’80% dei casi, lo stesso livello di accordo che c’è tra le persone. Oggi la maggior parte dei benchmark si basa su un modello giudice. Anche ReviewBench, pubblicato da GitHub per la code review: fa valutare i rilievi a un modello linguistico con un’unica rubrica, e scrive di aver misurato un accordo del 96,6% facendo rietichettare le sue etichette a ingegneri senior.
Il modello giudice non è la prima scelta. La documentazione di Anthropic sulla valutazione dà l’ordine in modo esplicito: prima la valutazione con il codice, perché è la più veloce e la più affidabile; poi il modello giudice, per i giudizi che non si possono esprimere con una regola; e prima di usare il giudice su larga scala, verificare che sia affidabile.
| Metodo | Punto di forza | Punto debole | Quando |
|---|---|---|---|
| Valutazione con il codice | La più veloce, la più affidabile, scala senza limiti | Non sa dare un giudizio che non si può scrivere come regola | Se la risposta si può verificare con una corrispondenza esatta o una ricerca nel testo |
| Valutazione umana | La più flessibile, la qualità più alta | Lenta e costosa | Su un piccolo campione, per verificare il giudice |
| Modello giudice | Veloce, flessibile, scala | Ha dei bias; va verificato prima | Se serve un giudizio e la risposta non si può verificare con una regola |
Fonte: la documentazione di Anthropic sulla valutazione, 18 ottobre 2026.
Quali bias hanno i modelli giudice?
Lo stesso articolo elenca anche i limiti dei modelli giudice: bias di posizione, bias di lunghezza, bias verso il proprio output e capacità di ragionamento limitata. Quando costruisci il giudice, per ognuno devi prendere una contromisura.
Il bias verso il proprio output è il più facile da evitare: il modello che valuta deve essere diverso da quello che ha prodotto l’output. Il codice d’esempio di Anthropic lo indica come buona pratica. Il bias di posizione compare nelle domande che confrontano due risposte; se inverti l’ordine delle risposte e chiedi due volte, il suo effetto diventa visibile. Contro il bias di lunghezza la contromisura più efficace è chiedere al giudice non un punteggio, ma una risposta che si basi su un solo fatto.
Chiedi al giudice se due cose sono uguali, non se una è buona
L’affidabilità del giudice dipende soprattutto dalla domanda. «Questo commento di review è buono? Dagli un voto da 1 a 10» non ha una risposta corretta; due giudici, e perfino due esecuzioni dello stesso giudice, danno voti diversi. Il consiglio di Anthropic va nella stessa direzione: il giudice dica solo «corretto» o «sbagliato», oppure scelga un livello da 1 a 5; una valutazione puramente qualitativa è difficile da verificare in fretta e su larga scala.
La domanda del nostro giudice è un confronto: riceve un commento di review e un bug segnalato in anticipo nella stessa pull request, e gli si chiede una cosa sola. Il nucleo della rubrica è più o meno questo:
You are given a review comment and a known bug in the same pull request.
Do they describe the SAME defect: the same code, failing for the same reason?
- A comment about the same file but a different problem is NOT a match.
- A comment that names the symptom while the known bug names its cause IS a match.
- If the comment is too vague to tell, answer no.
Answer with one word: yes or no.Le tre righe della rubrica rispondono in anticipo ai casi in cui il giudice esita più spesso: stesso file ma problema diverso, sintomo e causa, commento vago. Se queste righe mancano, due giudici divergono proprio in questi casi.
Tra due giudici conta l’accordo sulle coppie positive
Il primo passo per verificare un giudice è sottoporre le stesse coppie anche a un secondo giudice. Noi abbiamo usato come giudici due modelli diversi con la stessa rubrica: su 945 coppie in comune erano d’accordo nel 98,8% dei casi. Preso da solo, questo numero rassicura, e inganna.
La grande maggioranza delle coppie è un «no» evidente: il commento parla di un file, il bug segnalato di tutt’altro file. Su queste i due giudici sono comunque d’accordo. A decidere il risultato sono le coppie in cui almeno un giudice ha detto «sì», e lì l’accordo era del 93,5%. Quando riporti l’affidabilità di un giudice, di’ qual è il denominatore: tutte le coppie o solo quelle positive.
Come abbiamo verificato il giudice economico con uno più potente, gruppo per gruppo
Le nostre misure di tutti i giorni le facciamo con un giudice economico. Per rispondere alla domanda «e se questo giudice valutasse male?» non serviva sostituirlo del tutto: la matrice completa richiedeva 4.185 coppie. Abbiamo invece sottoposto solo 891 coppie a un modello più potente, con l’impostazione di effort alta, e le coppie non le abbiamo scelte a caso, ma da gruppi che rispondono alla domanda.
- 91 coppie in cui tutti e due i giudici hanno detto «sì»: il giudice più potente non ne ha ribaltata nessuna. Un abbinamento su cui i due erano d’accordo è rimasto un abbinamento anche con un giudice più costoso.
- 400 coppie in cui tutti e due hanno detto «no»: ne è stata ribaltata solo 1 (limite superiore 1,4%). Il giudice non si lascia sfuggire abbinamenti.
- 400 coppie tra i «sì» che contano per il punteggio: 24 sono state respinte, cioè il 6,0%. Il giudice economico è generoso nel contare gli abbinamenti.
Il risultato sono due frasi distinte, da non confondere. I punteggi assoluti sono ottimisti di circa 0,02–0,03. Cambiare giudice non ha spostato il punteggio di una configurazione di più di 0,033: sotto la soglia di rumore della misura (0,09). Ma l’abbiamo misurato su una sola configurazione, quindi non diciamo che l’ordine tra due configurazioni resti lo stesso in ogni caso. Il difetto del giudice conta o non conta a seconda di che cosa ci fai.
Cambiare giudice sposta poco il punteggio, una nuova esecuzione molto
Quando abbiamo rivalutato la stessa configurazione con tre giudici diversi, lo spostamento più grande di F1 è stato 0,033. Quando invece abbiamo rieseguito la stessa configurazione, sulle stesse pull request e con lo stesso giudice, la deviazione standard da un’esecuzione all’altra è stata 0,094; una volta, senza cambiare nulla, tra due esecuzioni abbiamo visto una differenza di 0,058.
Quindi l’incertezza vera della misura non viene dal giudice, ma dalla casualità del sistema stesso. La regola che ne segue è semplice: se la differenza tra due configurazioni è più piccola di circa 0,09, con una sola esecuzione non la vedi; e comprare un giudice migliore non cambia le cose.
Un rilievo che il giudice non abbina non è per forza sbagliato
Nella maggior parte dei benchmark un modello giudice confronta il rilievo con un riferimento, cioè con bug segnalati in anticipo. Un rilievo che non è nel riferimento conta come «falso allarme». Ma questo dice solo una cosa: chi ha preparato il riferimento non ha scritto quel punto. Il rilievo potrebbe anche essere corretto.
Per questo ReviewBench pubblica due famiglie di metriche: una usa solo le etichette esistenti, l’altra valuta a parte anche i rilievi che non hanno un corrispondente nel golden set. Fai la stessa distinzione nelle tue misure: «non corrisponde al riferimento» e «sbagliato» sono due etichette diverse, e per dire la seconda bisogna guardare il rilievo stesso.
Salva le decisioni del giudice e misura le modifiche alle regole senza giudice
Una chiamata al giudice si paga, e non ha senso fare due volte la stessa domanda sulla stessa coppia. Salva ogni decisione insieme all’identità della coppia e del giudice: modello, impostazione di effort, versione della rubrica. Quando una di queste cambia, non mostrare le decisioni vecchie e quelle nuove nella stessa tabella; due numeri misurati con due giudici diversi non si possono confrontare.
Non tutte le modifiche hanno bisogno del giudice. Quando cambi una soglia o un filtro, puoi rigiocare la regola vecchia e quella nuova sui risultati già salvati e guardare solo i punti in cui divergono. Così abbiamo misurato una modifica a una regola di filtro: su 1.405 rilievi salvati la regola vecchia e quella nuova divergevano solo in 6 punti, ed è bastato leggerli tutti e sei a occhio. Una nuova esecuzione non sarebbe stata né gratuita né così precisa.
Queste lezioni vengono dalle misure di diffox: non decidiamo se una modifica funziona con una sola esecuzione e con un giudice non verificato. Nel prodotto, invece, la citazione su cui si basa un rilievo la controlla il codice, non un modello giudice (l’articolo sull’architettura).
Domande frequenti
Cos’è LLM-as-a-judge?
È il metodo in cui l’output di un’IA viene valutato, con un punteggio, da un altro modello linguistico a cui si dà un’istruzione (una rubrica). Si usa quando la risposta non si può confrontare con un unico testo corretto, per esempio per decidere se due commenti descrivono lo stesso bug.
LLM-as-a-judge è affidabile?
Dipende dalla domanda. Uno studio del 2023 ha mostrato che i modelli giudice più forti sono d’accordo con le preferenze umane in oltre l’80% dei casi. Nelle domande di confronto («questi due sono la stessa cosa?») i giudici sono coerenti; nelle domande aperte con un punteggio, no. Prima di fidarti, verifica il giudice su un piccolo campione, con un secondo giudice o con etichette umane.
Come si scrive una rubrica per LLM-as-a-judge?
Riducila a una sola domanda e limita la risposta: «sì/no» oppure un livello da 1 a 5. Scrivi nella rubrica i casi limite su cui il giudice esiterebbe: quale caso conta come abbinamento, quale no, che cosa rispondere se non è chiaro. La documentazione di Anthropic consiglia anche di far ragionare il giudice prima della risposta.
Quali sono le metriche di LLM-as-a-judge e quale guardare?
Per il giudice stesso: il tasso di accordo con etichette umane o con un secondo giudice, soprattutto l’accordo sugli esempi positivi; e il tasso con cui un giudice più forte ribalta le decisioni, con il suo intervallo di confidenza. L’accordo complessivo sembra più alto di quanto sia, per colpa degli esempi negativi facili.
Il modello giudice può essere lo stesso modello che viene valutato?
Meglio di no. È un bias noto che i modelli giudice diano punteggi più alti al proprio output. Il codice d’esempio di Anthropic indica come buona pratica che il modello che valuta sia diverso da quello che ha prodotto l’output.
Che differenza c’è tra LLM-as-a-judge e agent-as-a-judge?
LLM-as-a-judge valuta solo l’output finale. Agent-as-a-judge è l’estensione proposta da un articolo del 2024: la valutazione la fa un agente che può usare strumenti, e dà un feedback anche sui passi intermedi del lavoro. È pensato per valutare sistemi di agenti a più passi.
diffox usa un modello giudice nelle sue review?
Durante lo sviluppo sì: per abbinare i rilievi a bug segnalati in anticipo e misurare se una modifica funziona. Quando esamina una pull request, invece, la citazione su cui si basa un rilievo la controlla il codice, non un modello giudice: se la citazione c’è davvero nel file e se appartiene alle righe modificate.