Modello come giudice (LLM-as-a-judge): che cosa valuta e quali bias verificare
01

Definizione in una frase

Uso de un modelo para puntuar o comparar respuestas según una rúbrica, a menudo junto con controles humanos.

02

Definizione: che cos’è un modello come giudice

Un modello come giudice è un modello linguistico impiegato per valutare una risposta, un output o il comportamento di un’applicazione di IA sulla base di criteri stabiliti in anticipo. Può, per esempio, assegnare un punteggio, classificare il risultato oppure confrontare due alternative. In inglese si usa abitualmente l’espressione LLM-as-a-judge.

L’oggetto della valutazione non deve essere necessariamente un testo. A seconda dell’applicazione, può trattarsi della risposta di un chatbot, di un riepilogo, di un output generato da uno strumento o della sequenza di azioni di un agente. La valutazione può inoltre considerare informazioni di riferimento, come la domanda iniziale, un documento sorgente, una policy o un elenco di vincoli.

L’espressione descrive un metodo di valutazione, non una garanzia di accuratezza. Il giudizio prodotto resta l’output di un modello: dipende da che cosa gli viene chiesto di esaminare, dai criteri che riceve e dalle informazioni disponibili. Di conseguenza, un punteggio automatizzato non equivale di per sé a una verità verificata, a un’etichetta di riferimento indipendente o a una revisione umana.

La guida di Langfuse definisce il metodo, nel proprio ambito operativo, come l’uso di un modello linguistico per valutare la qualità degli output di un’altra applicazione basata su LLM. La documentazione di MLflow include sia applicazioni LLM sia agenti ed elenca possibili dimensioni qualitative, tra cui correttezza, pertinenza, aderenza alle fonti, sicurezza e utilità. Queste descrizioni aiutano a comprendere gli usi, ma non fanno di uno strumento specifico una definizione universale.

03

Come funziona il processo

Un flusso di valutazione sensato inizia definendo che cosa si vuole giudicare e con quale scopo. Verificare se una risposta rispetta una policy non è la stessa cosa che valutarne la chiarezza per una persona. Se l’obiettivo è ambiguo, il modello può restituire una valutazione apparentemente precisa che però non corrisponde alla necessità effettiva.

In seguito si precisano i criteri. Una rubrica può descrivere dimensioni distinte, come la fedeltà a una fonte, la copertura delle informazioni, il rispetto dei vincoli o la pertinenza. Può anche definire una scala e spiegare che cosa rappresenta ciascun livello. La rubrica non elimina il disaccordo, ma rende esplicito che cosa ci si aspetta che valuti il giudice.

Poi gli si fornisce il materiale pertinente: la risposta o la traccia da valutare e, quando serve, la domanda, il documento di riferimento, le regole vigenti o i vincoli dell’attività. Il contesto deve essere sufficiente per applicare il criterio, ma non si può presumere che aggiungere più informazioni migliori sempre il giudizio: è opportuno verificare di quale contesto abbia davvero bisogno il compito.

L’istruzione di valutazione specifica il ruolo del giudice e il formato dell’output. Il risultato può includere un punteggio, una categoria, una preferenza tra opzioni e una spiegazione. Infine, il giudizio va esaminato: si cercano errori, lo si confronta quando possibile con valutatori umani o riferimenti esterni e si decide se il risultato è adeguato all’uso previsto. Il fatto che il giudice produca una motivazione non dimostra, da solo, che sia corretta.

Flusso di base

  1. 01Definire l’oggetto della valutazione e la decisione che si vuole supportare.
  2. 02Specificare i criteri e, se opportuno, una rubrica con livelli interpretabili.
  3. 03Fornire l’output e il contesto necessario per applicare quei criteri.
  4. 04Chiedere al giudice un output strutturato: punteggio, categoria, confronto o una combinazione di questi.
  5. 05Esaminare il risultato e verificare se il metodo funziona per quel compito e per quell’uso.
04

Forme di giudizio: punteggio, classificazione e confronto

Con un punteggio basato su criteri, il giudice valuta una risposta singolarmente, per esempio usando una scala definita dal team. La scala è interpretabile soltanto se si sa che cosa rappresenta ogni valore. Un punteggio complessivo di qualità può nascondere che una risposta è fedele ma incompleta, oppure completa ma in contrasto con un vincolo; distinguere le dimensioni può rendere più leggibili questi compromessi.

Con una classificazione, il giudice assegna una categoria, come «conforme», «non conforme» o «da rivedere». Può anche ordinare più risposte in gruppi o livelli. Le categorie riducono l’apparenza di precisione numerica, ma dipendono comunque da definizioni chiare e dalla capacità del modello di applicarle correttamente.

Nel confronto a coppie si presentano due alternative e si chiede di scegliere quale soddisfa meglio un criterio, oppure di indicare un pareggio se il formato lo consente. Il risultato è relativo: preferire un’opzione non dimostra che sia corretta o che superi una soglia assoluta. Inoltre, il confronto riguarda la coppia presentata e non stabilisce automaticamente un ordinamento affidabile per tutte le risposte possibili.

Questi formati sono diversi e rispondono a domande differenti. Un punteggio cerca di esprimere la prestazione rispetto a una scala; una categoria assegna un’etichetta; un confronto indica una preferenza tra opzioni. Non bisogna presumere che uno sia sempre superiore agli altri. La scelta dipende dalla decisione da prendere e va verificata su esempi rappresentativi.

A quale domanda risponde ciascun formato

FormatoDomanda a cui rispondePrecauzione interpretativa
PunteggioIn quale misura la risposta soddisfa un criterio o una scala?Non interpretare il numero come una misura oggettiva senza aver convalidato la scala.
ClassificazioneA quale categoria definita appartiene il risultato?Le categorie richiedono confini chiari ed esempi di applicazione.
Confronto a coppieQuale alternativa è preferibile secondo il criterio?Una preferenza relativa non prova che l’opzione scelta sia corretta.
05

Esempio pratico: risposte del servizio clienti

Supponiamo che un team voglia esaminare le risposte di un assistente del servizio clienti. L’oggetto della valutazione è ogni singola risposta; il contesto pertinente può comprendere la richiesta della persona e la versione vigente della policy applicabile. Una rubrica potrebbe distinguere almeno tre aspetti: se la risposta affronta la richiesta, se è coerente con la policy fornita e se rispetta i vincoli comunicativi definiti dal team.

Il giudice potrebbe classificare ogni dimensione o assegnare punteggi separati, segnalando i casi dubbi per la revisione. Per esempio, se la risposta promette un rimborso, il criterio non dovrebbe essere che la promessa sembri ragionevole: va verificata rispetto alla policy fornita. La valutazione del modello indica come ha interpretato il materiale; non sostituisce la verifica che la policy sia aggiornata né la decisione su quale regola applicare.

Per valutare il metodo, il team può selezionare casi che coprano richieste ed eccezioni diverse, confrontare i giudizi con revisioni umane ed esaminare i disaccordi. Se il sistema viene usato per stabilire le priorità delle revisioni, è opportuno verificare anche se individua i casi che il team considera delicati o incerti. È un’indicazione progettuale: le fonti disponibili non permettono di affermare che un giudice concordi con gli esperti in ogni caso.

06

Esempio pratico: riepiloghi di documenti

Per confrontare riepiloghi, l’oggetto valutato è il riepilogo e il riferimento è il documento originale, insieme all’istruzione che ne ha richiesto la sintesi. I criteri possono distinguere la copertura dei punti rilevanti dalla fedeltà delle affermazioni al testo di partenza. Mantenere separate le due dimensioni aiuta a non confondere una prosa scorrevole con un riepilogo completo o fedele.

Un giudice potrebbe assegnare un punteggio a ciascun riepilogo singolarmente o confrontarne due per stabilire quale copra meglio i contenuti rilevanti senza introdurre affermazioni non supportate. La revisione dovrebbe verificare se la valutazione segnala omissioni specifiche o affermazioni incompatibili con il documento, invece di basarsi soltanto su una spiegazione generica come «è più completo».

La scelta delle informazioni rilevanti dipende dal compito: un riepilogo esecutivo, uno tecnico e uno destinato a rispondere a una domanda specifica possono richiedere coperture diverse. Perciò il documento di partenza e lo scopo del riepilogo devono essere disponibili al valutatore. Il punteggio del giudice non è, di per sé, un elenco verificato di fatti omessi o inventati.

07

Esempio pratico: agenti di programmazione

Quando si valuta un agente di programmazione, l’oggetto può includere il risultato finale e la traccia delle azioni, non soltanto il testo della risposta. Il compito, i test disponibili e i vincoli definiscono che cosa significhi completare il lavoro. Tra i criteri espliciti potrebbero esserci la risoluzione del compito richiesto e il rispetto di limiti come non modificare determinati file o non usare uno specifico strumento, se tali restrizioni fanno parte dell’incarico.

Un giudice può valutare ciascun criterio, riassumere quali elementi della traccia sembrino supportarlo oppure segnalare che, con le informazioni disponibili, non è possibile decidere. Il team dovrebbe verificare se il giudizio corrisponde a un risultato controllabile. Per esempio, una spiegazione convincente del completamento del compito non sostituisce l’esecuzione dei test; allo stesso tempo, superare un singolo test non dimostra necessariamente che siano stati rispettati tutti i vincoli.

Questo esempio mostra perché l’oggetto della valutazione va definito con attenzione: giudicare solo la risposta testuale può trascurare azioni rilevanti, mentre giudicare una traccia senza conoscere i vincoli può portare a una valutazione incompleta. Quali elementi siano sufficienti dipende dall’ambiente e dal compito specifico.

08

Che cosa verificare prima di fidarsi di un giudice

Una verifica centrale riguarda la corrispondenza tra i giudizi del modello e un riferimento appropriato al compito. Il riferimento può consistere in valutazioni umane, regole verificabili o risultati esterni, a seconda di ciò che si sta misurando. Non basta ottenere una percentuale complessiva di accordo senza sapere quali casi siano stati valutati, come siano stati risolti i disaccordi e se gli esempi rappresentino l’uso previsto.

È inoltre opportuno testare la stabilità del processo. Se lo stesso caso viene presentato più di una volta, il giudizio rimane sufficientemente coerente per la decisione prevista? Le valutazioni cambiano modificando elementi di presentazione non pertinenti? Nei confronti a coppie, bisogna verificare se invertire l’ordine delle alternative modifica la preferenza. Sono domande di convalida, non affermazioni che il cambiamento si verifichi sempre.

Anche la motivazione richiede un esame indipendente. Una spiegazione può aiutare a capire quale criterio abbia applicato il modello, ma non prova che il punteggio sia corretto. Si possono confrontare le ragioni con il materiale di input e verificare se rimandano a elementi pertinenti oppure se sono vaghe, incompatibili con il risultato o non supportate dalla fonte.

Infine, occorre valutare se il giudice sia adatto al compito. Un modello capace di valutare un certo tipo di risposta non è automaticamente convalidato per un altro ambito, un’altra lingua, un diverso formato di input o una decisione con conseguenze differenti. Una rassegna tecnica su LLM-as-a-judge presenta il campo come l’uso di modelli linguistici per valutare compiti complessi; la descrizione disponibile menziona anche istruzioni ed esempi per specificare i compiti. Questo, da solo, non dimostra che un particolare metodo sia affidabile in ogni applicazione.

Verifiche e domande pratiche

AspettoChe cosa controllareSegnale da approfondire
Accordo con i riferimentiConfrontare il giudice con valutazioni umane o criteri esterni appropriati.Disaccordi ricorrenti nei casi importanti o un riferimento poco rappresentativo.
Ordine di presentazioneInvertire l’ordine nei confronti a coppie e osservare se il giudizio cambia.Preferenze che variano in modo rilevante scambiando le alternative.
MotivazioniConfrontare ogni ragione con la risposta, la fonte e la rubrica.Spiegazioni generiche o ragioni che non supportano il punteggio.
Adeguatezza al compitoProvare casi rappresentativi, eccezioni e input limite dell’uso previsto.Risultati plausibili in apparenza, ma non pertinenti al criterio effettivo.
09

Concetti vicini e confusioni frequenti

Un benchmark è un insieme organizzato di compiti o casi usato per misurare o confrontare sistemi in condizioni definite. Un modello come giudice è invece un metodo per assegnare valutazioni agli output. Un benchmark può integrare un giudice, ma i due termini non sono sinonimi: l’insieme di valutazione definisce quali casi vengono testati; il giudice produce o contribuisce ai giudizi.

Una rubrica è una specifica di criteri, livelli o regole di valutazione. Non è necessariamente un modello né un risultato. Il giudice può ricevere una rubrica per orientare la valutazione, ma la sua presenza non garantisce che venga applicata correttamente.

Il punteggio di un giudice non equivale neppure a un’etichetta di riferimento o alla verità del caso. Una risposta può ottenere un punteggio alto e contenere comunque un errore non rilevato dalla rubrica o interpretato male dal valutatore. Quando esiste un controllo diretto, per esempio una regola verificabile o l’esito di un test, è opportuno non sostituirlo senza convalida con un’opinione generata.

Infine, bisogna distinguere il modello valutatore dal modello valutato. In un’applicazione possono essere sistemi dello stesso tipo o modelli diversi, ma nel processo svolgono funzioni differenti: uno genera la risposta o esegue il compito; l’altro esprime un giudizio su quell’output. E «giudizio automatizzato» non significa «senza supervisione umana»: la revisione umana può servire a convalidare il metodo, risolvere le eccezioni o prendere decisioni rilevanti.

10

Limiti e criteri pratici d’uso

Il giudizio dipende dalla definizione del compito, dai criteri e dal contesto fornito, oltre che dal comportamento del modello valutatore. Per questo, una valutazione automatizzata dovrebbe essere descritta in modo sufficientemente dettagliato da permettere ad altre persone di capire che cosa è stato giudicato, con quali istruzioni e quale output ha prodotto il giudice. La documentazione degli strumenti può proporre formati operativi e dimensioni di valutazione, ma le raccomandazioni di una piattaforma non costituiscono, da sole, una prova che quel progetto funzioni in qualsiasi applicazione.

Prima di adottare il metodo, è utile chiedersi: il criterio rappresenta una reale necessità del prodotto o soltanto un’approssimazione facile da valutare? Esistono casi di riferimento adeguati? Si sa come gestire i disaccordi e i risultati incerti? È stata verificata la sensibilità ai cambiamenti di presentazione? La decisione può essere confrontata con un controllo esterno? Le risposte aiutano a stabilire dove il giudice sia utile come supporto e dove serva un’ulteriore revisione.

Può essere utile iniziare con un impiego circoscritto e reversibile, analizzare esempi di successi ed errori e rivalutare il metodo quando cambiano policy, dati, istruzioni o modello. È una raccomandazione pratica, non una garanzia che la valutazione rimanga stabile. L’estensione della revisione umana dovrebbe dipendere dalla rilevanza della decisione, dalle conseguenze di un errore e dalle evidenze raccolte per quello specifico compito.

Per approfondire, si possono consultare le schede dedicate alla valutazione dell’IA, ai benchmark, alle rubriche e alla supervisione umana nel circuito, oltre alla voce **giudice LLM** e ai criteri di **confronto tra modelli**. Sono concetti collegati, ma non intercambiabili.

In sintesi, un modello come giudice può strutturare o automatizzare una parte del lavoro di valutazione quando l’oggetto e i criteri sono chiari. Il suo risultato va interpretato come un giudizio prodotto da un modello e verificato rispetto all’uso previsto. La domanda pratica non è se un giudice sia affidabile in astratto, ma quali evidenze ne sostengano l’impiego per un compito, dati e conseguenze specifici.

Lista di controllo prima dell’uso

  1. 01Precisare quale output, azione o comportamento sarà valutato e quale decisione dovrà supportare.
  2. 02Formulare criteri osservabili e spiegare il significato di punteggi o categorie.
  3. 03Scegliere il contesto e il formato di giudizio adatti alla domanda.
  4. 04Testare il giudice rispetto a riferimenti pertinenti e casi rappresentativi, compresi quelli difficili.
  5. 05Esaminare ordine, stabilità e motivazioni senza considerarli garanzie automatiche.
  6. 06Definire quali disaccordi richiedono revisione umana e ripetere la convalida se cambia l’applicazione.
11

Esempi rapidi

12

Concetti correlati

13

Fonti consultate