LLM-as-judge: l'AI che valuta l'AI

Seconda puntata della serie sul testing dei sistemi AI. Nella prima abbiamo costruito il metro: golden dataset e test set. Qui affrontiamo chi lo tiene in mano quando il volume cresce, cioè un modello che ne valuta un altro. La persona che resta nel ciclo è il tema del terzo articolo.

Il problema di partenza

Hai messo in produzione un assistente che risponde a domande sulla documentazione interna. Funziona. Poi cambi il prompt di sistema per sistemare un caso limite segnalato da un utente, e ti fermi un attimo prima di rilasciare.

Come fai a sapere che non hai peggiorato le altre duecento risposte?

Le opzioni classiche non funzionano:

• Confronto esatto: non esiste una risposta unica. "L'endpoint richiede un token Bearer" e "Devi passare un token Bearer nell'header Authorization" sono entrambe corrette e non condividono quasi nulla a livello di stringa.
• BLEU, ROUGE e simili: contano sovrapposizioni di n-gram. Ti dicono quanto due testi si assomigliano, non se il secondo è giusto. Una risposta perfetta scritta con parole diverse dal riferimento prende un punteggio bassissimo. Una risposta sbagliata che ricicla il lessico del contesto prende un punteggio alto.
• Review umana: funziona benissimo, ed è esattamente ciò che non puoi fare a ogni commit su duecento casi.

Da qui nasce l'idea: se il giudizio richiede comprensione del linguaggio, usiamo qualcosa che comprende il linguaggio.

Cos'è esattamente

LLM-as-judge significa usare un modello linguistico come valutatore dell'output di un altro sistema (o di se stesso). Il judge riceve:

• l'input originale (la domanda dell'utente)
• l'output da valutare (la risposta del sistema)
• eventualmente un riferimento (la risposta "gold", o il contesto recuperato dal RAG)
• un criterio esplicito di giudizio

e restituisce un verdetto: un punteggio, un pass/fail, o una preferenza fra due alternative.

Detta così sembra banale. La differenza fra un judge che funziona e uno che produce rumore travestito da metrica sta interamente nei dettagli di come lo costruisci.

Le varianti principali

Pointwise scoring

"Dai un voto da 1 a 5 alla completezza di questa risposta."

È la forma più intuitiva e la più fragile. I modelli sono pessimi a calibrare scale numeriche: chiedi un voto da 1 a 10 e ottieni una distribuzione schiacciata su 7 e 8. La granularità che credi di avere è un'illusione: se il tuo sistema passa da 7,8 a 7,9 dopo una modifica, non hai imparato niente.

Funziona decentemente solo se ancori ogni livello della scala a una descrizione comportamentale concreta ("5 = risponde alla domanda e cita almeno una fonte del contesto; 3 = risponde parzialmente; 1 = non risponde o contraddice il contesto"). Senza ancore, stai chiedendo un'opinione.

Pairwise comparison

"Fra la risposta A e la risposta B, quale è migliore secondo questo criterio?"

Molto più affidabile. Il modello non deve collocare un output su una scala astratta, deve solo esprimere una preferenza relativa — un compito su cui va significativamente meglio. È la forma d'elezione per confrontare due versioni del tuo sistema, due prompt, due modelli.

Ha un difetto notevole (il position bias, ne parliamo più avanti) che va obbligatoriamente mitigato.

Rubric / criteri binari

Invece di chiedere "quanto è buona questa risposta", spezzi il concetto di qualità in domande atomiche a risposta sì/no:

• La risposta contiene affermazioni non supportate dal contesto fornito?
• La risposta affronta effettivamente la domanda posta?
• La risposta cita almeno una fonte?
• La risposta contiene consigli di natura legale?

Statisticamente è l'approccio più robusto. Ogni check è semplice, verificabile, e quando fallisce sai esattamente cosa è andato storto. Aggreghi poi come preferisci: percentuale di check passati, oppure logica a cascata (se il check 1 fallisce, il caso è bocciato e non serve valutare il resto).

Il costo è il lavoro di progettazione a monte: devi decidere davvero cosa significa "buono" per il tuo dominio. È lavoro utile a prescindere.

Reference-based vs reference-free

Con riferimento: confronti l'output con una risposta gold. Serve un dataset annotato — è il tema del primo articolo di questa serie —, ma il giudizio è molto più stabile.

Senza riferimento: valuti l'output in sé, o rispetto al contesto recuperato. È l'unica opzione praticabile in produzione, dove le domande sono nuove e non hai una gold answer.

Nel RAG il caso più utile è ibrido: il "riferimento" è il contesto recuperato, e il criterio è la groundedness — ogni affermazione della risposta deve essere supportata da quel contesto. Questo tipo di judge è affidabile perché il compito è quasi meccanico: verificare un'inclusione, non giudicare la bellezza.

G-Eval e varianti

Approccio che si è consolidato: fai produrre al judge una catena di ragionamento esplicita prima del verdetto, e — dove hai accesso alle logprob — pesi il punteggio con le probabilità dei token, ottenendo un valore continuo invece di uno scalino discreto. Riduce il problema della calibrazione grossolana.

Il punto trasferibile anche senza logprob: il ragionamento va chiesto prima del verdetto, mai dopo. Se chiedi prima il voto e poi la motivazione, ottieni una razionalizzazione a posteriori.

Jury / panel

Più judge diversi votano, si aggrega (maggioranza, media, o si escalation a un umano in caso di disaccordo). Riduce la varianza e il bias del singolo modello. Costa di più — lo si tiene per le rubriche ad alto impatto.

Agent-as-judge

L'evoluzione recente per i sistemi agentici: valutare non solo la risposta finale ma l'intera traiettoria — quali tool sono stati chiamati, in che ordine, con quali parametri, come si è recuperato dagli errori. Le rubriche pensate per i chatbot ("utilità", "fluidità") sono inadatte a un agente che deve concatenare API, e la ricerca del 2026 spinge verso rubriche generate in funzione del task specifico anziché fisse per tutto il sistema.

Quando usarlo (e quando no)

La regola pratica è: non usare un judge dove esiste un controllo deterministico.

Il pattern maturo è ibrido a tre livelli: controlli deterministici per tutto ciò che è misurabile meccanicamente, judge per ciò che richiede comprensione, umano per la piccola percentuale che uno dei due ha segnalato come dubbia.

I casi d'uso concreti

• Regression testing in CI. Il caso più solido. Hai duecento casi di test, modifichi qualcosa, il judge ti dice se sei peggiorato. Non ti serve un numero assoluto vero, ti serve un confronto ripetibile.
• Confronto fra modelli o prompt. Devi scegliere fra due fornitori, o valutare se il modello più economico basta. Pairwise su un set fisso.
• Filtraggio di dati sintetici. Generi centomila esempi, ne tieni la frazione che il judge considera valida.
• RLAIF / rubrics-as-rewards. Il judge produce il segnale di preferenza per l'allineamento al posto degli annotatori umani. Qui il judge non misura, addestra — e i suoi difetti diventano difetti del modello finale.
• Monitoraggio in produzione. Campioni una percentuale del traffico reale e la valuti in asincrono su fedeltà, tono, violazioni di policy. Vedi passare i problemi prima che li segnali un cliente.
• Guardrail online. Il judge blocca o fa rigenerare prima che l'utente veda la risposta. Qui la latenza e il costo contano molto, e serve un judge piccolo e veloce.

Storie dal campo

Il judge che premiava chi parlava di più

Su un assistente interno per la documentazione tecnica avevamo un judge pointwise con un criterio generico di "qualità della risposta", scala 1-5. Iterando sul prompt di sistema il punteggio medio saliva costantemente: 3,4 → 3,7 → 3,9. Sembrava tutto in ordine.

Poi qualcuno ha letto le risposte.

Erano diventate lunghissime. Il modello aveva imparato — attraverso di noi, che ottimizzavamo sul punteggio — ad aggiungere premesse, riepiloghi, note di contesto e disclaimer. Il judge premiava la verbosità perché una risposta lunga sembra più completa. Gli utenti reali, che volevano una riga e un link, erano più scontenti di prima.

La lezione: il punteggio saliva perché stavamo ottimizzando la metrica, non il prodotto. Abbiamo sostituito il criterio unico con quattro check binari, uno dei quali era esplicitamente "la risposta contiene informazioni non richieste dalla domanda?". Il punteggio medio è crollato ed è tornato a essere informativo.

Il giorno in cui abbiamo misurato il judge

Per mesi abbiamo usato i numeri del judge nelle slide senza mai chiederci se fossero veri. Poi abbiamo fatto la cosa ovvia: duecento casi etichettati a mano da due persone, e confronto con il verdetto del judge.

Sul criterio di groundedness l'accordo era ottimo — è un compito quasi meccanico. Sul criterio "la risposta è utile all'utente" l'accordo era appena sopra il caso. Il judge stava misurando qualcosa, ma non quello che pensavamo, e non qualcosa su cui avesse senso prendere decisioni.

Il sottoprodotto più prezioso è stato scoprire che noi due umani non eravamo d'accordo fra noi su un quinto dei casi. Prima di chiedere a un modello di applicare un criterio, il criterio deve esistere. Metà del valore dell'esercizio è stato scrivere la definizione operativa di "utile".

Il costo che nessuno aveva messo a budget

Judge con chain-of-thought, su un modello di fascia alta, su ogni risposta di produzione. Sulla carta "l'AI che valuta l'AI costa niente". Nella pratica il judge generava più token di output del sistema valutato, perché ragionava prima di rispondere, e la voce di costo era diventata paragonabile a quella del prodotto.

La soluzione è banale una volta che ci pensi: campionamento (una frazione del traffico live), judge grande solo nelle run di calibrazione, judge piccolo e specializzato in produzione, e — soprattutto — il costo del judge tracciato come voce separata invece che nascosto nel totale.

I bias: la parte che fa male

Questa sezione è la più importante. Un judge non è un misuratore neutro: è un modello linguistico con tutte le sue tendenze sistematiche.

Position bias. Nel pairwise, il modello tende a preferire la prima (o la seconda) risposta a prescindere dal contenuto. Non è rumore casuale, è sistematico e varia da modello a modello. Mitigazione obbligatoria: valuti sempre entrambi gli ordini. Se il verdetto si inverte scambiando A e B, il confronto è nullo e va trattato come pareggio o escalato.

Verbosity bias. Le risposte più lunghe vincono, anche a parità di contenuto. Nei benchmark che testano esplicitamente questo effetto, la sensibilità alla lunghezza risulta spesso più forte di quella alla posizione. Alcuni modelli sono più resistenti di altri e penalizzano il riempitivo, ma nessuno ne è immune. Mitigazione: criteri che menzionano esplicitamente la concisione, e controllo della distribuzione delle lunghezze fra i gruppi che confronti.

Self-preference / self-enhancement bias. Un modello tende a valutare meglio i propri output. La spiegazione più convincente in letteratura non è narcisismo ma perplessità: i modelli premiano i testi che trovano più familiari, cioè più probabili secondo la loro distribuzione. Il che significa che il bias colpisce anche testi non generati da loro ma stilisticamente simili. Mitigazione: judge di famiglia diversa dal generatore. Sempre.

Preference leakage. Variante più insidiosa: se hai generato i dati sintetici con il modello X e usi come judge un modello imparentato con X, il judge è contaminato. Vale anche fra modello "insegnante" e modello distillato.

Sycophancy. Il judge crede a quello che gli scrivi. Se il testo da valutare afferma con sicurezza di aver citato una fonte, il judge tende a darlo per buono senza verificare. Le citazioni inventate passano.

Overconfidence. I punteggi di confidenza che il judge dichiara sono mal calibrati verso l'alto. Non trattarli come probabilità.

Sensibilità al prompt e drift. Riformulare un criterio cambia i risultati. Cambiare la versione del modello judge cambia i risultati. Conseguenza operativa: il prompt del judge va versionato come codice, e ogni cambio del modello judge invalida lo storico delle metriche finché non ricalibri.

Non determinismo. Stesso input, verdetti diversi. Temperature a zero aiuta ma non elimina il problema.

Goodhart, ovvero: il problema di fondo

Quando una misura diventa un obiettivo, cessa di essere una buona misura.

Vale per tutte le metriche, ma con i judge è particolarmente vizioso, per due motivi.

Il primo: il ciclo di ottimizzazione è velocissimo. Cambio il prompt, guardo il punteggio, cambio ancora. In poche ore hai fatto decine di iterazioni di selezione contro le debolezze del judge, senza accorgertene. Non stai migliorando il sistema, stai facendo evoluzione diretta verso i punti ciechi del valutatore.

Il secondo: quando il judge produce il reward per un training (RLAIF, rubrics-as-rewards), il modello ottimizza direttamente contro di lui, con molta più forza e pazienza di quanta ne abbia tu. Ogni scorciatoia sfruttabile verrà sfruttata.

L'unico antidoto vero è mantenere un canale di verità indipendente: un campione di review umana che non entra mai nel ciclo di ottimizzazione, e un occhio periodico alle risposte reali. Se il punteggio sale e gli utenti non se ne accorgono, il punteggio sta mentendo.

Come costruire un judge di cui ti fidi

Una checklist operativa, in ordine di importanza.

1. Valuta il valutatore. È il passo che quasi tutti saltano. Servono 100-200 casi etichettati a mano, possibilmente da due persone, e una misura di accordo fra judge e umani (accuratezza, Cohen's kappa). Le soglie usate in pratica: sotto 0,6 di kappa il judge non è utilizzabile per decisioni; sopra 0,8 è solido. Senza questo numero non hai una metrica, hai un generatore di cifre rassicuranti.

2. Misura anche l'accordo fra i tuoi umani. Se due revisori interni non concordano, il criterio è ambiguo e nessun modello lo applicherà in modo stabile. Il judge non può essere più coerente della definizione che gli hai dato.

3. Preferisci binario e pairwise alle scale numeriche. Un pass/fail ben definito vale più di un 1-10 vago.

4. Spezza "qualità" in criteri atomici e indipendenti, ognuno con la sua definizione, esempi positivi e — soprattutto — esempi di confine. Gli esempi al margine valgono più di quelli ovvi.

5. Ragionamento prima del verdetto, output strutturato in JSON con schema fisso. Non serve solo alla qualità del giudizio: serve a te per fare debug quando qualcosa non torna.

6. Judge di famiglia diversa dal generatore.

7. Ordine alternato nel pairwise. Non negoziabile.

8. Versiona il prompt del judge, il modello, i parametri. Un cambio di uno qualsiasi dei tre invalida i confronti storici.

9. Ricalibra periodicamente. I modelli vengono aggiornati sotto di te, i tuoi dati cambiano, i criteri si logorano. Un giro di calibrazione mensile o comunque a ogni cambio rilevante.

10. Campiona, non valutare tutto. In CI puoi permetterti la copertura totale del test set; in produzione un campione basta e avanza.

11. Judge in asincrono, salvo che sia un guardrail bloccante. Non far pagare all'utente la latenza della tua metrica.

12. Traccia il costo del judge come voce separata.

Un esempio di struttura minima, giusto per fissare la forma:

Contesto fornito: {context}
Domanda: {question}
Risposta da valutare: {answer}

Per ciascun criterio, motiva in una frase e poi dai il verdetto.
1. Ogni affermazione fattuale della risposta è supportata dal contesto?
2. La risposta introduce informazioni assenti dal contesto?
3. La risposta affronta la domanda posta?

Rispondi solo con:
{"reasoning": "...", "supported": bool, "hallucinated": bool, "relevant": bool}

Nota cosa non c'è: nessuna richiesta di dare un voto complessivo, nessuna scala, nessun aggettivo vago come "buona" o "di qualità".

Dove sta andando

Tre direzioni che vale la pena tenere d'occhio.

Rubriche come reward. Il passaggio da "il judge misura" a "il judge addestra". Le rubriche diventano il ponte fra il linguaggio delle policy aziendali e un segnale che una macchina può ottimizzare. Il rovescio della medaglia è che ogni ambiguità della rubrica diventa un difetto strutturale del modello risultante.

Norma ibrida con i reward verificabili. Dove la correttezza è controllabile meccanicamente (matematica, codice, tool use) si usa la verifica deterministica; le rubriche restano per la parte aperta. La combinazione batte entrambi gli approcci presi da soli.

Rubriche adattive. Invece di applicare le stesse tre dimensioni a qualunque task, generare i criteri in funzione del task specifico. Per un agente che concatena API le dimensioni sensate sono la scelta della chiamata, la correttezza dei parametri, il recupero dagli errori — nessuna delle quali compare in una rubrica generica di "utilità".

Un collega con manie documentate

LLM-as-judge è lo strumento giusto per misurare differenze relative fra versioni del tuo sistema, su scala, a costo contenuto, su criteri che nessuna metrica sintattica sa catturare.

È lo strumento sbagliato se lo tratti come una misura oggettiva di qualità assoluta, se non lo hai mai confrontato con giudizi umani reali, o se lo usi al posto di un controllo deterministico che avresti potuto scrivere in dieci righe.

Il judge non è la verità. È un collega paziente, instancabile, molto veloce, con alcune manie ben documentate — e che va tenuto sotto controllo esattamente come terresti sotto controllo un collega con quelle caratteristiche.

Un judge va comunque confrontato con qualcosa: il golden dataset del primo articolo è quel qualcosa, e senza non c'è niente contro cui calibrarlo. Nel terzo resta la persona, che il judge non sostituisce.

Fonti

Paper

• Zheng et al. (2023), Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — arXiv:2306.05685. Il lavoro fondativo: identifica position, verbosity e self-enhancement bias, e misura l'accordo fra judge e umani.
• Liu et al. (2023), G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment — arXiv:2303.16634. Chain-of-thought più pesatura del punteggio con le probabilità dei token.
• Shi et al. (2024), Judging the Judges: A Systematic Investigation of Position Bias — arXiv:2406.07791. Dimostra che il position bias è sistematico, non rumore casuale.
• Wataoka & Takahashi (2024), Self-Preference Bias in LLM-as-a-Judge — arXiv:2410.21819. Il legame fra self-preference e perplessità.
• Li et al. (2025), Preference Leakage: A Contamination Problem in LLM-as-a-judge — arXiv:2502.01534. Contaminazione fra generatore di dati sintetici e valutatore.
• Kim et al. (2024), Prometheus 2: An Open Source Language Model Specialized in Evaluating Other Language Models — arXiv:2405.01535 · repo. Evaluator aperti addestrati su rubriche definite dall'utente.
• Tan et al. (2024), JudgeBench: A Benchmark for Evaluating LLM-based Judges — arXiv:2410.12784. Benchmark per valutare i judge stessi.
• Lambert et al. (2024), RewardBench: Evaluating Reward Models for Language Modeling — arXiv:2403.13787.
• Park et al. (2024), OffsetBias: Leveraging Debiased Data for Tuning Evaluators — arXiv:2407.06551. Mitigazione dei bias a livello di dati di addestramento del judge.
• Koo et al. (2023), Benchmarking Cognitive Biases in Large Language Models as Evaluators — arXiv:2309.17012.

Articoli e guide pratiche

• LLM-as-a-Judge in 2026: How It Works, When It Fails, and How to Calibrate — tabelle su calibrazione, soglie di kappa, costi e pattern di deployment.
• LLM-as-Judge Best Practices: Calibration, Bias, and Cost — checklist operativa.
• LLM-as-judge: A complete guide to evaluation best practices — panoramica dei metodi e della validazione contro baseline umane.
• What Is LLM-as-a-Judge? Definition and Best Practices — introduzione con focus su output strutturato e rubriche.
• LLM-as-a-Judge: Top evaluation techniques and best practices — confronto fra G-Eval, metriche a grafo decisionale e judge pairwise.
• Rubric-Based Evaluations & LLM-as-a-Judge — rubriche come ponte fra policy e reward verificabili.