Il modulo è stato inviato con successo.
Ulteriori informazioni sono contenute nella vostra casella di posta elettronica.
AssumeteciSelezionare la lingua
Chi siamoServiziTecnologieIndustriePortafoglio
La tua app LLM è in grado di generare migliaia di risultati all’ora. A tali volumi, la revisione manuale non è più sufficiente come principale controllo di qualità. Metriche come BLEU e ROUGE misurano la somiglianza superficiale dei testi, ma non sono in grado di indicare se una risposta utilizzi i fatti corretti o sia pertinente al prodotto. E man mano che il sistema cresce, aumentano anche i suoi punti ciechi.
Il metodo di valutazione “LLM-as-a-judge” Colma questa lacuna facendo sì che un modello linguistico ne valuti un altro in base a criteri definiti dall’utente. I team ottengono un'indicazione su cui possono agire su ampi insiemi di output senza dover ricorrere a un revisore umano per ogni prompt. L'approccio funziona, ma solo con la giusta configurazione. Una rubrica inadeguata, un prompt di parte o un modello che si autovaluta possono far sembrare utili i punteggi, mentre gli stessi problemi di qualità rimangono nascosti.
In questa sede tratterò cos'è un LLM che funge da giudice, come funziona, cosa rende i suoi punteggi utili o fuorvianti e in quali casi il metodo tende a fallire. Esamineremo inoltre la configurazione necessaria ai team prima di poter fare affidamento su tali punteggi in un prodotto di IA reale.
Se hai già familiarità con il Spiegazione del titolo di LLM come giudice, puoi dare una rapida occhiata a questa sezione. Altrimenti, ecco una semplice Definizione di “LLM-as-a-judge”. Il metodo “LLM-as-a-judge” è una tecnica di valutazione in cui un modello linguistico esamina l’output di un altro modello alla luce di una griglia di valutazione stabilita dal team. Questo approccio può essere applicato anche agli output provenienti da un sistema di intelligenza artificiale più ampio o da un agente.
Il valutatore di solito prende visione della richiesta dell'utente, della risposta del modello e della griglia di valutazione che spiega quali aspetti verificare. A seconda dell'attività, può esaminare il risultato in diversi modi:
È proprio la griglia di valutazione a rendere utile la recensione. Senza di essa, il giudice deve cercare di indovinare cosa sia considerato bene. Grazie a una rubrica, il team può indirizzare il modello verso gli indicatori di qualità rilevanti per il proprio flusso di lavoro.
Alcuni criteri comuni sono l'accuratezza, la pertinenza, la fondatezza, la sicurezza, la chiarezza e l'utilità. In un sistema RAG, il valutatore potrebbe verificare se la risposta è supportata dalla fonte recuperata. Nell’assistenza clienti, potrebbe verificare se la risposta è conforme alle linee guida e risponde effettivamente alla domanda del cliente. Nei flussi di lavoro relativi ai contenuti, potrebbe valutare il tono, la chiarezza e se la bozza è adeguata al canale.
Perché le aziende utilizzano la LMetodo di valutazione "LM-as-a-judge"? I sistemi di intelligenza artificiale si evolvono a un ritmo troppo veloce perché la revisione manuale riesca a stare al passo. All’inizio, revisionare manualmente i risultati è sufficiente: si controllano alcune risposte, si forniscono feedback e si correggono gli errori evidenti. Ma quando il sistema inizia a gestire centinaia di domande su numerosi argomenti, la revisione manuale non riesce più a tenere il passo.
La revisione umana rimane il modo migliore per cogliere le sfumature, valutare i rischi aziendali e gestire i casi insoliti. La sfida riguarda la copertura. I revisori possono calibrare una griglia di valutazione, controllare i risultati sensibili e indagare sugli errori, ma non possono esaminare ogni risposta dopo ogni aggiornamento.
Anche i parametri tradizionali come BLEU, ROUGE e i controlli di corrispondenza esatta sono utili, ma solo in caso di verifiche rigorose quali risposte esatte, schemi, formati ed etichette note. Essi, tuttavia, non tengono conto di aspetti quali il significato, la fondatezza, la conformità alle linee guida e la qualità complessiva del compito.
I giudici LLM sono in grado di esaminare grandi insiemi di test e valutare aspetti che le metriche fisse non rilevano, tra cui la pertinenza, la fondatezza, il tono, la sicurezza e il rispetto delle istruzioni. I team li utilizzano per i test di regressione, i controlli di rilascio, i confronti tra modelli e il monitoraggio della qualità post-lancio.
La maggior parte delle aziende non si affida a un unico metodo. Una buona configurazione combina controlli deterministici per le regole rigide, valutazioni basate su modelli di linguaggio di grandi dimensioni (LLM) per le valutazioni aperte e l'intervento umano per la calibrazione e le scelte ad alto rischio.
| Metodo | Il migliore per | Limiti | Ruolo nella produzione |
| Revisione umana | Risultati ad alto rischio, sfumature aziendali, casi limite e decisioni in cui il contesto conta più di un punteggio | Troppo lento per essere ripetuto dopo ogni modifica al prompt, aggiornamento del modello, modifica al recupero o aggiornamento delle politiche | Calibra le griglie di valutazione, esamina i casi controversi, indaga sui fallimenti e approva i flussi di lavoro ad alto impatto |
| Metriche tradizionali e controlli fissi | Test con risposte prestabilite, convalida dello schema, campi obbligatori, regole di formattazione, etichette con corrispondenza esatta e controlli rigorosi di superamento/fallimento | Mancanza di significato, supporto alla fonte, adeguatezza alle linee guida, tono e risposte che possono essere corrette in più di un modo | Fungono da "hard gate" per i controlli che devono essere superati ogni volta |
| Giudici dell'LLM | Risposte libere, controlli di qualità RAG, confronto tra modelli, rispetto delle istruzioni, tono, sicurezza e pertinenza | Può premiare l'eccessiva verbosità, attenersi a criteri di valutazione poco chiari o non cogliere i rischi quando le indicazioni del giudice sono vaghe | Fornire ai team un'indicazione rapida e attendibile sui grandi insiemi di test e indirizzare i risultati poco convincenti verso la revisione umana |
Bene, vediamo un po' Come funziona il modello LLM nel ruolo di giudice in un processo di valutazione dei prodotti. A prima vista, il sistema sembra semplice. Un modello redige una risposta e un altro la verifica utilizzando una griglia di valutazione. Il valutatore esamina il compito, la risposta e la griglia di valutazione, quindi fornisce un risultato strutturato che il team può utilizzare.
Ecco una guida di base Diagramma del flusso di valutazione dell’LLM nel ruolo di giudice:
Per facilitare la comprensione, immaginate un’azienda che sta testando un assistente basato sull’intelligenza artificiale per l’assistenza clienti. In pratica, il processo funziona come segue:
Il sistema riceve la richiesta originale. Nel nostro esempio, un cliente desidera sapere perché la sua ultima fattura sia più alta dopo aver cambiato piano. In altri prodotti, l'attività potrebbe consistere in un messaggio standard, una query RAG o un'istruzione per un agente AI.
L'IA principale genera tre possibili risposte alla domanda del cliente. Una risposta è breve e diretta. Un'altra spiega la logica di fatturazione in modo più dettagliato. La terza utilizza un tono più cordiale e colloquiale.
Il sistema integra la domanda del cliente, le tre opzioni di risposta e una rigorosa griglia di valutazione. Poiché questo assistente utilizza il metodo RAG, include anche la politica di fatturazione, in modo che il giudice possa verificare i fatti.
Il giudice esamina ogni risposta in base alla griglia di valutazione. Verifica se la risposta spiega correttamente la fattura, utilizza la fonte corretta, evita di fare supposizioni e rispetta il tono del marchio. Il giudice fornisce quindi un risultato strutturato, spesso in formato JSON, con un punteggio e una breve spiegazione relativa a tale punteggio.
Il sistema seleziona la risposta con il punteggio più alto da inviare al cliente. Inoltre, salva in un database i punteggi assegnati dai valutatori, le motivazioni, la versione della richiesta e il contesto di origine. Questo registro consente al team di monitorare come cambia la qualità delle risposte quando aggiornano il sistema.
Le risposte con punteggio basso, i casi di parità e quelli ad alto rischio vengono sottoposti a revisori umani. Un revisore potrebbe notare che una risposta è cortese ma non spiega il vero motivo della variazione di prezzo. Il feedback umano contribuisce a migliorare la griglia di valutazione e a correggere eventuali punti ciechi sfuggiti al giudice.
Il sistema riceve la richiesta originale. Nel nostro esempio, un cliente desidera sapere perché la sua ultima fattura sia più alta dopo aver cambiato piano. In altri prodotti, l'attività potrebbe consistere in un messaggio standard, una query RAG o un'istruzione per un agente AI.
L'IA principale genera tre possibili risposte alla domanda del cliente. Una risposta è breve e diretta. Un'altra spiega la logica di fatturazione in modo più dettagliato. La terza utilizza un tono più cordiale e colloquiale.
Il sistema integra la domanda del cliente, le tre opzioni di risposta e una rigorosa griglia di valutazione. Poiché questo assistente utilizza il metodo RAG, include anche la politica di fatturazione, in modo che il giudice possa verificare i fatti.
Il giudice esamina ogni risposta in base alla griglia di valutazione. Verifica se la risposta spiega correttamente la fattura, utilizza la fonte corretta, evita di fare supposizioni e rispetta il tono del marchio. Il giudice fornisce quindi un risultato strutturato, spesso in formato JSON, con un punteggio e una breve spiegazione relativa a tale punteggio.
Il sistema seleziona la risposta con il punteggio più alto da inviare al cliente. Inoltre, salva in un database i punteggi assegnati dai valutatori, le motivazioni, la versione della richiesta e il contesto di origine. Questo registro consente al team di monitorare come cambia la qualità delle risposte quando aggiornano il sistema.
Le risposte con punteggio basso, i casi di parità e quelli ad alto rischio vengono sottoposti a revisori umani. Un revisore potrebbe notare che una risposta è cortese ma non spiega il vero motivo della variazione di prezzo. Il feedback umano contribuisce a migliorare la griglia di valutazione e a correggere eventuali punti ciechi sfuggiti al giudice.
Spesso le persone rivedono il proprio lavoro. Lo rileggiamo, individuiamo i punti deboli e apportiamo miglioramenti. Allora perché dovrebbe essere diverso per un modello?
Potrebbe sembrare ragionevole che un modello riveda ciò che ha scritto e lo valuti. Ma in realtà, quando un modello controlla il proprio testo, può scambiare una formulazione scorrevole per vera qualità. Si tratta del cosiddetto «pregiudizio di auto-valorizzazione». Il modello potrebbe trascurare una logica debole, frasi ripetitive o conclusioni banali, poiché queste corrispondono agli stessi schemi che ha utilizzato per scrivere la risposta. Di conseguenza, il proprio risultato può apparire migliore di quanto non sia in realtà.
Ad esempio, Sergei Molchanov, direttore della Business Unit presso Innowise, si è imbattuto in questo problema mentre stava sviluppando un motore di contenuti automatizzato per i post su X. Ogni mattina, il sistema gli inviava tre varianti di post su Telegram. Lui ne sceglieva una, a volte la modificava e la pubblicava manualmente. La domanda era semplice: quale bozza era effettivamente la migliore?
Inizialmente, Sergei ha chiesto al modello generatore di valutare le proprie bozze utilizzando una griglia di valutazione. Ma questo non gli ha fornito un’indicazione utile. I punteggi erano molto simili tra loro, compresi tra 36 e 40. Una bozza chiaramente più debole ha ottenuto un punteggio solo leggermente inferiore rispetto alla preferita, quindi la valutazione faceva sembrare la scelta più facile di quanto non fosse in realtà.
Il risultato è cambiato quando Sergei ha suddiviso i ruoli. Un modello si occupava di scrivere i post, mentre un altro modello, fungendo da valutatore, li valutava utilizzando una griglia di valutazione composta da 9 criteri. Da quel momento in poi, bozze simili hanno iniziato a ricevere punteggi più variabili, come 26, 32 e 39. Il valutatore separato ha notato alcuni problemi che il generatore aveva mascherato: espressioni di esitazione come potrebbe e probabile, metafore già utilizzate in post precedenti e frasi di chiusura prive di significato come il tempo lo dirà.
Compiti di valutazione diversi richiedono configurazioni diverse. Alcuni team verificano le risposte confrontandole con un riferimento noto, mentre altri valutano le risposte in casi in cui potrebbero essere valide più versioni. Ecco perché i flussi di lavoro di produzione utilizzano spesso diverse tTipi di LLM nel ruolo di giudice sistemi.
I giudici di valutazione confrontano l'output di un'intelligenza artificiale con una risposta di riferimento verificata, nota anche come "ground truth". Verificano se la risposta corrisponde ai fatti, segue la logica corretta o produce il risultato atteso.
Questo approccio funziona al meglio quando esiste una risposta chiara. Ad esempio, un bot di assistenza potrebbe dover fornire la regola esatta relativa alla garanzia, oppure un assistente di programmazione potrebbe dover utilizzare un algoritmo specifico. Anche i test di benchmark spesso hanno un solo risultato corretto da verificare.
Lo svantaggio è che i giudici basati sul confronto non sono molto flessibili. Possono risultare troppo rigidi per compiti in cui è corretta più di una risposta, specialmente quando la formulazione, il tono o il contesto sono importanti.
Molti compiti di intelligenza artificiale non hanno un'unica risposta corretta. Ad esempio, una risposta a un cliente, un riassunto o un post generato possono essere tutti validi in modi diversi. In questi casi, il valutatore utilizza una griglia di valutazione anziché una risposta di riferimento per esaminare il risultato.
I criteri di valutazione aperti sono utili per verificare il tono, la chiarezza, la completezza, l'utilità e la qualità dei contenuti. Il valutatore verifica se la risposta è in linea con il compito richiesto, se copre i punti chiave e se è adeguata all'uso previsto.
In questo caso la griglia di valutazione riveste particolare importanza. Se le istruzioni si limitano a dire “valuta la qualità della risposta”, il valutatore ha troppa libertà di interpretazione. Se invece la griglia di valutazione indica di “verificare che la risposta copra tutti i passaggi richiesti ed eviti affermazioni prive di fondamento”, il punteggio risulta più utile.
I giudici incaricati della valutazione comparativa esaminano diversi risultati relativi allo stesso compito e selezionano quello migliore. A volte ciò comporta il confronto diretto tra due risposte, altre volte la classificazione di diverse opzioni per individuare la scelta migliore.
Sergei ha utilizzato questa configurazione nel suo motore di contenuti. L'autore ha redatto tre versioni di un post X sulla base dello stesso brief. Il giudice ha utilizzato la stessa griglia di valutazione per esaminarle e ha contribuito a individuare la bozza migliore.
Questo tipo di valutazione è utile per i test rapidi, la selezione dei modelli e i flussi di lavoro relativi ai contenuti in cui il team deve scegliere tra diverse versioni. Tuttavia, l’ordine o la lunghezza delle risposte possono comunque influenzare i risultati, pertanto i team spesso randomizzano le opzioni e confrontano le decisioni dei valutatori con una revisione umana.
Ecco perché Metodologia di valutazione dell’LLM in veste di giudice è utile per la valutazione del RAG. Consente al team di verificare separatamente ogni parte della pipeline, invece di limitarsi a esaminare il risultato finale e cercare di indovinare cosa sia andato storto. Questa revisione passo dopo passo viene spesso definita “triade RAG”.
Questa distinzione rende il debug meno vago. Un problema di recupero significa che il sistema non ha restituito il materiale corretto. Un problema di aderenza alla realtà significa che il materiale corretto era presente, ma il modello non è rimasto fedele ad esso. Se la risposta è pertinente solo in apparenza, il team deve riesaminare il modo in cui il modello trasforma il contesto in una risposta.
Anche i giudici LLM contribuiscono all'addestramento del modello. Il loro compito in questo caso è quello di creare un segnale di preferenza, ovvero un suggerimento di addestramento che indichi al ciclo quale risposta debba essere classificata più in alto e perché.
Nel apprendimento per rinforzo basato sul feedback umano, o RLHF, questo segnale di solito ha origine dalle persone. I revisori confrontano due risposte modello e selezionano quella migliore. Queste scelte diventano dati di preferenza per un modello di ricompensa, che in seguito aiuta il ciclo di addestramento a privilegiare risposte simili.
Il collo di bottiglia è il volume. Man mano che il set di esempi cresce, i revisori non riescono a controllare ogni coppia allo stesso ritmo. Un giudice LLM aiuta a smistare i risultati in una prima fase, in modo che le persone possano concentrarsi sui casi incerti o sugli esempi in cui una preferenza errata potrebbe danneggiare il modello.
Ottimizzazione relativa delle politiche di gruppo, o GRPO, opera su un gruppo di risposte. Il modello genera diverse risposte allo stesso prompt e il ciclo di addestramento richiede un segnale di ricompensa per ciascuna risposta all’interno di quel gruppo. Il GRPO non necessita sempre di un giudice LLM. Per la matematica o il codice, la ricompensa può essere fornita da una regola o da un verificatore. Per i compiti che non hanno una risposta fissa, un valutatore assegna un punteggio alle risposte in base a una griglia di valutazione. Ciò è utile quando la qualità dipende dall’adeguamento alle politiche e dal rispetto delle istruzioni.
Esiste un rischio simile a quello legato alla valutazione dei prodotti: una volta che i punteggi dei giudici vengono inseriti nell’addestramento, il modello inizia ad apprendere dalle preferenze dei giudici. Se un giudice premia la verbosità, il modello potrebbe imparare a essere verboso. Se un giudice trascura scorciatoie non sicure, il modello potrebbe ripeterle. I punteggi assegnati dai giudici devono essere calibrati prima di influire sull’addestramento.
Nei compiti di ragionamento, la valutazione basata sulla risposta finale può non rilevare errori gravi. Un modello potrebbe ottenere il risultato corretto dopo aver compiuto un passo errato. Nel codice o in matematica, quell’errore nascosto è rilevante perché lo stesso passo potrebbe fallire in un compito più difficile.
Modelli di ricompensa dei processi, o PRM, valutano il percorso di ragionamento man mano che il modello procede verso la risposta finale. Un valutatore a livello di processo controlla ogni fase e individua i punti in cui la logica presenta delle incongruenze.
Una volta che i punteggi dei giudici vengono inseriti nel processo di addestramento, iniziano a influenzare il comportamento del modello. I team dovrebbero testare il giudice, concentrare l’attenzione sui campioni ad alto rischio e aggiornare la griglia di valutazione quando il modello inizia ad acquisire abitudini errate.
Ora che abbiamo visto come sono configurati questi sistemi e come si comportano in un processo di valutazione reale, parliamo dei vantaggi concreti. Perché dovresti prenderti la briga di configurare un sistema di valutazione LLM nel tuo progetto e quali vantaggi ne ricavi?
I team umani addetti al controllo qualità raggiungono un limite nel numero di log di chat o di generazioni che riescono a esaminare ogni giorno. Un sistema di valutazione basato su modelli di linguaggio di grandi dimensioni (LLM) consente di analizzare campioni molto più ampi, compreso il traffico di produzione che sarebbe troppo costoso da controllare manualmente. Ciò offre ai team maggiori possibilità di individuare problemi di qualità sfuggiti durante le piccole revisioni manuali.
La valutazione basata sui judge richiede solitamente solo pochi secondi. I team possono integrarla nei controlli CI/CD o utilizzarla come filtro prima che un messaggio venga inviato all'utente. Gli sviluppatori possono vedere cosa è cambiato dopo una piccola modifica al prompt senza dover attendere giorni per una revisione manuale.
Le metriche tradizionali dei software si basano sulla corrispondenza esatta delle parole chiave o sulla sovrapposizione dei caratteri. Ad esempio, se un modello dice “Il cliente è soddisfatto” anziché “L'utente è soddisfatto”,” Un sistema di valutazione rigido potrebbe segnalarla come errata. Un valutatore LLM è in grado di riconoscere che il significato è sufficientemente vicino e di verificare se la risposta soddisfa i criteri di valutazione. Ciò è importante per quanto riguarda il tono e la struttura, ambiti in cui le espressioni regolari non forniscono quasi nessun indicatore utile.
L'annotazione manuale può risultare costosa, soprattutto nel caso di attività complesse di ragionamento o di codifica che richiedono revisori esperti. Le revisioni tramite API LLM hanno in genere un costo molto inferiore per campione.
In un recente progetto, un sistema automatizzato di assistenza clienti via e-mail ha generato tre bozze di risposta cortesi per circa $0.05 in token API. L'utilizzo di un valutatore per esaminare tutte e tre le bozze alla luce dei criteri del nostro marchio e scegliere quella migliore è costato circa $0.01. Questa fase di revisione è costata circa un centesimo.
I revisori umani si stancano. Ad esempio, un addetto all’etichettatura potrebbe valutare un testo in modo diverso alla fine di un venerdì rispetto all’inizio di un lunedì. I modelli di linguaggio di grandi dimensioni (LLM) hanno i propri pregiudizi tecnici, come la preferenza per testi più lunghi, ma non si stancano. Con impostazioni fisse e una griglia di valutazione collaudata, applicano gli stessi criteri in modo più coerente rispetto a un team umano che deve smaltire una lunga coda di lavoro.
Quando si modifica l’oggetto dei test del proprio sistema, spesso non è necessario riscrivere centinaia di righe di codice Python. In molti casi, basta aggiornare la griglia di valutazione ed eseguire nuovamente il test. Ad esempio, un criterio di valutazione che verifica l’accuratezza dei fatti può essere adattato per valutare l’empatia e la voce del marchio.
"Non dovresti considerare un giudice LLM semplicemente come uno strumento di controllo della qualità di tipo “scatola nera”. Funziona al meglio quando il tuo team segue una griglia di valutazione chiara, tiene traccia di ogni punteggio e confronta le sue decisioni con le revisioni effettuate da esseri umani. Altrimenti, otterrai solo numeri, invece di una reale comprensione della qualità.."
Responsabile della competenza tecnica AI
Il concetto di “LLM-as-a-judge” È utile, ma presenta alcuni difetti. Se si permette a un'intelligenza artificiale di valutare un'altra, si introducono nuovi punti ciechi nel processo di valutazione. Senza un attento monitoraggio, il sistema potrebbe assegnare punteggi alti a risposte poco convincenti.
Ecco i principali ostacoli a cui faccio attenzione quando configuro un sistema di valutazione automatizzato.
Quando un giudice valuta diverse bozze contemporaneamente, potrebbe preferire la prima o l’ultima opzione che vede. A volte, l’ordine in cui una bozza appare è più importante della sua qualità. Per evitare questo, rimescolate l’ordine delle bozze prima di inviarle al giudice.
I modelli di linguaggio di grandi dimensioni (LLM) tendono spesso a preferire risposte più lunghe. Un valutatore potrebbe assegnare un punteggio più alto a una risposta lunga e prolissa piuttosto che a una breve e chiara, anche se quest’ultima è più utile. Per evitare che ciò accada, la griglia di valutazione dovrebbe indicare al valutatore di penalizzare le digressioni superflue.
Un modello "giudice" potrebbe preferire le risposte fornite dalla propria famiglia di modelli. Ad esempio, se si utilizza GPT-5.5 come modello di valutazione, questo potrebbe assegnare un punteggio più alto alle risposte di GPT-5.5 rispetto a quelle di Claude Sonnet 5 o Gemini. Spesso il modello di valutazione predilige formulazioni e strutture familiari, anche se un'altra risposta è migliore. Per ottenere risultati più equi, i team utilizzano in genere più modelli di valutazione e ne confrontano i punteggi.
Anche una piccola modifica nella rubrica può influire sui punteggi finali. Ad esempio, cambiare l’istruzione da “Valuta l’utilità” a “Valuta quanto sia utile” potrebbe far scendere la media dei punteggi di superamento da 80% a 60%. Il giudice è sensibile al modo in cui vengono formulate le regole, pertanto le istruzioni devono essere sottoposte a diverse versioni e controllate da persone.
Se utilizzi un'API ospitata come GPT-5.5 o Claude Sonnet 5 come sistema di valutazione, il fornitore potrebbe aggiornare il modello senza preavviso. Quando ciò accade, i tuoi punteggi di riferimento potrebbero cambiare da un giorno all'altro. Una risposta che in precedenza aveva ottenuto un punteggio di 4 su 5 potrebbe ora ricevere un 3, rendendo più difficile il confronto con i risultati precedenti.
Se si continua ad addestrare un modello generativo utilizzando il feedback dello stesso valutatore LLM, il generatore potrebbe imparare a aggirare il sistema. Anziché migliorare le risposte per gli utenti, il modello finisce per individuare le parole e i formati preferiti dal valutatore. Potrebbe persino imitare il tono che ottiene punteggi più alti. I punteggi aumentano, ma la qualità effettiva del prodotto può diminuire.
Aggiungere un giudice LLM al proprio flusso di lavoro è semplice, ma rendere i suoi punteggi sufficientemente affidabili per le decisioni relative alla pubblicazione è più complesso. Se si utilizza solo un prompt di base e si chiede al modello di valutare il testo, i risultati saranno spesso incoerenti.
Durante la configurazione di queste pipeline, ho raccolto i più diffusi Tecniche di LLM nel ruolo di giudice che contribuiscono a mantenere stabili i modelli di valutazione per compiti di valutazione reali.
È importante strutturare i risultati della valutazione fin dall'inizio. Anziché utilizzare commenti in formato libero, fai in modo che il modello restituisca i punteggi per ciascun criterio, una breve spiegazione e un voto finale in un formato facilmente leggibile dalla tua pipeline.
Ad esempio, evita che il giudice fornisca risposte in formato libero del tipo “Questo testo è piuttosto buono, gli do un 8/10”. Queste risposte sono difficili da elaborare nel codice. Piuttosto, fai in modo che il modello utilizzi uno schema JSON rigoroso con output strutturati, oppure ricorri all’utilizzo di strumenti e Indicatori relativi al titolo di LLM come giudice.
Istruzioni poco chiare portano a punteggi poco chiari. Ad esempio, se chiedi a un giudice di valutare la “creatività” da 1 a 5, il modello si limiterà a tirare a indovinare. Utilizza invece criteri specifici che riducano il margine di interpretazione.
Ad esempio, quando valuto articoli o post scritti, evito di attribuire punteggi generali sulla qualità. Preferisco invece suddividere la griglia di valutazione in controlli più specifici, come questi:
È importante strutturare i risultati della valutazione fin dall'inizio. Anziché utilizzare commenti in formato libero, fai in modo che il modello restituisca i punteggi per ciascun criterio, una breve spiegazione e un voto finale in un formato facilmente leggibile dalla tua pipeline.
Ad esempio, evita che il giudice fornisca risposte in formato libero del tipo “Questo testo è piuttosto buono, gli do un 8/10”. Queste risposte sono difficili da elaborare nel codice. Piuttosto, fai in modo che il modello utilizzi uno schema JSON rigoroso con output strutturati, oppure ricorri all’utilizzo di strumenti e Indicatori relativi al titolo di LLM come giudice.
Mantenete separati il generatore e il valutatore. Si tratta di uno dei controlli fondamentali in una configurazione in cui un modello di linguaggio di grandi dimensioni (LLM) funge da valutatore, poiché il modello che ha generato la risposta potrebbe non riconoscere i propri schemi ricorrenti o sopravvalutare le formulazioni a lui familiari. Ad esempio, se si utilizza GPT-5.5 per generare testo, è consigliabile impiegare Claude Sonnet 5 come valutatore, o viceversa. È inoltre possibile utilizzare per la valutazione un modello open-weight più piccolo e ottimizzato, come una variante specializzata di Llama 4 Maverick o Llama 4 Scout. Questo approccio può contribuire a ridurre i costi e a minimizzare il bias di auto-valorizzazione.
Come abbiamo visto nella sezione dedicata ai rischi, i modelli possono mostrare un “bias di posizione”. Per evitarlo, randomizza l’ordine delle risposte in ogni confronto. Nel valutare coppie o più risultati, un modello potrebbe scegliere la prima risposta semplicemente per via della sua posizione. Mescola le opzioni prima di procedere alla valutazione, quindi ricollega la risposta scelta al modello o al prompt originale nel tuo codice. Per i test importanti, provate a invertire l’ordine e prendete nota di eventuali casi in cui il risultato cambia dopo l’inversione.
Per ridurre il rischio di parzialità sistematica, assicurati che il valutatore non veda alcun metadato relativo alla generazione del testo. Il valutatore non deve sapere quale modello abbia generato il testo né quale prompt sia stato utilizzato. Fornisci al valutatore solo il testo grezzo e la griglia di valutazione.
La scrittura e la valutazione richiedono impostazioni diverse del modello. Quando si genera del testo, è consigliabile utilizzare una temperatura più alta, ad esempio da 0,7 a 0,9, per favorire la varietà e un flusso naturale. Per la valutazione, invece, è opportuno impostare una temperatura bassa, spesso pari a 0, in modo che il modello assegni punteggi più coerenti per lo stesso input.
Ma attenzione: una temperatura pari a 0 rende i controlli ripetuti più stabili solo quando l'input rimane invariato. Non risolve i problemi legati alla sensibilità del prompt, alle modifiche della griglia di valutazione o alla distorsione dovuta alla posizione. Se si riscrive la griglia di valutazione o si inverte l'ordine delle risposte, il punteggio può comunque variare.
Quando OpenAI, Anthropic o Google aggiornano gli endpoint dei propri modelli, il tuo judge potrebbe diventare più indulgente o più severo. Per individuarlo, crea un piccolo dataset di riferimento composto da 50 a 100 risposte storiche che sono già state valutate e approvate da esseri umani. Esegui il tuo sistema di valutazione LLM su questo dataset una volta alla settimana. Se i punteggi aumentano o diminuiscono improvvisamente, il modello potrebbe aver subito una deriva e potrebbe essere necessario modificare i prompt o bloccare l’API su una versione statica.
Un sistema di valutazione automatizzato è un supporto, non un sostituto del controllo umano. Tieni traccia del tasso di concordanza tra il sistema di valutazione LLM e il tuo team umano di controllo qualità. Se utilizzate un tasso di concordanza compreso tra 85% e 90% come obiettivo interno, consideratelo un indicatore di stato piuttosto che uno standard universale. Se tale concordanza dovesse diminuire, è possibile che i requisiti del vostro prodotto siano cambiati ed è quindi il momento di aggiornare la griglia di valutazione.
Conoscere i rischi legati ai giudici dei modelli di linguaggio di grandi dimensioni (LLM) è utile solo se il sistema prevede meccanismi di controllo per individuarli. Ad esempio, un giudice potrebbe preferire la prima risposta che vede oppure assegnare punteggi più alti alle risposte più lunghe. A volte, un aggiornamento del modello può modificare i punteggi anche se il prodotto non è cambiato affatto.
Di seguito sono riportate le pratiche che utilizzo più spesso per ridurre i pregiudizi e individuare i dati di valutazione poco attendibili.
Quando si confrontano i risultati, assicurati che il giudice non sappia quale bozza provenga da quale prompt o modello. Mescola sempre le opzioni prima di inviarle al giudice. Se il giudice sceglie l“”Opzione A”, il tuo codice dovrebbe ricollegare silenziosamente quella scelta alla variante effettiva del modello.
Questa regola vale anche per i metadati. Le istruzioni di valutazione devono includere solo il testo grezzo e la griglia di valutazione, senza il nome del modello né i dettagli relativi alla generazione. Se il giudice vede dettagli quali le dimensioni del modello, il numero di token o il tempo di elaborazione, potrebbe utilizzarli come indicatori per valutare la qualità.
Per quanto riguarda gli indicatori di produzione importanti, un unico modello di valutazione potrebbe non essere sufficiente. Ad esempio, un modello di valutazione basato su GPT potrebbe avere preferenze diverse rispetto a quelle di Claude o di un modello Llama ottimizzato.
Per le valutazioni critiche, preferisco inviare lo stesso output a diversi modelli di valutazione e confrontare i loro punteggi. È possibile calcolare la media dei punteggi o ricorrere al voto a maggioranza, ma è importante assicurarsi che i modelli siano indipendenti. Se i modelli sono troppo simili tra loro, la giuria potrebbe sembrare più affidabile di quanto non sia in realtà. Presta particolare attenzione alle divergenze. Se due giudici assegnano un punteggio di 5 su 5 e un altro assegna 1 su 5, invia quel caso a una persona in carne e ossa per una revisione. Differenze significative indicano solitamente che la griglia di valutazione è troppo soggetta a interpretazione.
Un sistema di valutazione automatizzato dovrebbe riprodurre il modo in cui gli esperti utilizzano la griglia di valutazione. Per verificarlo, estrai un campione casuale di log valutati con codice 5% e chiedi al tuo team interno di valutarli in cieco utilizzando la stessa griglia di valutazione.
A questo punto, confronta i risultati. Alcuni team utilizzano il coefficiente Kappa di Cohen, mentre altri si limitano a considerare la percentuale di concordanza. Se il tuo obiettivo è una concordanza dell’85% e il valutatore non raggiunge tale soglia, il problema di solito è che la griglia di valutazione non è più sufficientemente chiara oppure che i requisiti del tuo prodotto sono cambiati.
Alcuni flussi di lavoro richiedono un controllo aggiuntivo: la memoria. Questo aspetto è importante per i motori di contenuti, i generatori di report giornalieri e altri sistemi che producono output simili nel corso del tempo.
Un singolo risultato potrebbe sembrare corretto di per sé. Tuttavia, se il generatore utilizza la stessa analogia per tre giorni di fila, gli utenti se ne accorgeranno. Un controllo manuale una tantum potrebbe non rilevare questo problema.
In questi casi, fornisco al giudice una memoria trasversale. Quando esamina le bozze di oggi, il prompt include un indice vettoriale aggiornato o un breve riassunto dei risultati approvati negli ultimi 7-14 giorni. Ciò consente al giudice di individuare metafore ripetute, ganci riutilizzati, parole di riempimento e frasi conclusive deboli che sfuggirebbero durante la revisione di un singolo documento.
In quali ambiti i team di ingegneri utilizzano questo approccio? Nell’ultimo anno ho visto i valutatori di modelli di linguaggio di grandi dimensioni (LLM) passare da semplici script di valutazione a flussi di lavoro di IA in produzione.
Diamo un’occhiata ai principali ambiti in cui, a mio avviso, vengono utilizzati oggi.
Come accennato in precedenza, i sistemi RAG rappresentano un chiaro caso d’uso per i giudici automatizzati. I team ricorrono ai giudici per verificare che il retriever individui il contesto corretto e che la risposta finale sia basata sui documenti di origine. Ciò contribuisce a individuare le affermazioni prive di fondamento prima che si trasformino in “allucinazioni”.
Con i motori di contenuti automatizzati, raramente è una buona idea pubblicare la prima bozza generata da un modello. Le pipeline, invece, creano diverse versioni e ricorrono a un valutatore per confrontarle con una griglia di valutazione. Il valutatore seleziona la bozza migliore e segnala eventuali formulazioni generiche prima della pubblicazione.
I bot di assistenza possono causare problemi se si discostano dal copione. I team ricorrono a dei revisori per esaminare grandi quantità di log delle chat al termine della conversazione. Il revisore verifica se il bot ha risposto alla domanda dell’utente e se ha rispettato le regole aziendali, comprese le politiche di rimborso, le procedure di escalation e le promesse relative alle funzionalità.
Le tradizionali liste di parole chiave da escludere e i filtri basati su espressioni regolari sono facili da aggirare. Un sistema di valutazione basato su modelli di linguaggio di grandi dimensioni (LLM) tiene conto del significato e del contesto, aiutando così i team di moderazione a individuare contenuti dannosi che non utilizzano parole vietate in modo evidente. È in grado di verificare sia le richieste degli utenti che le risposte del modello alla luce delle linee guida.
Man mano che gli agenti basati sull'intelligenza artificiale iniziano a compiere azioni tramite strumenti e API, non è più sufficiente valutare solo il testo finale. In questi flussi di lavoro, i valutatori esaminano l'intero processo. Verificano l'utilizzo degli strumenti, lo stato di avanzamento delle attività e se l'agente ha portato a termine il compito senza incepparsi.
Non dovresti scegliere un modello di valutazione basandoti esclusivamente sul suo punteggio nei benchmark. Il modello migliore dipende dall’attività per cui ti serve. Ad esempio, un modello che è efficace nel valutare rapidamente i log di assistenza potrebbe non essere abbastanza potente per gestire i dati relativi alle preferenze durante l’addestramento. Un modello di alto livello potrebbe essere ottimo per le valutazioni ad alto rischio, ma potrebbe risultare troppo costoso da utilizzare ogni notte su migliaia di output.
Quindi, di solito, valuto innanzitutto quattro aspetti: cosa deve valutare il giudice, quanto contesto è necessario, con quale rapidità deve essere restituito il punteggio e cosa succede se il punteggio è errato.
Le attività di generazione e valutazione richiedono spesso impostazioni e livelli di potenza diversi per i modelli.
La generazione di contenuti è un’attività creativa. A tal fine, di solito è necessario un modello potente come GPT-5.5, Claude Sonnet 5 o Claude Opus 4.8, impostato su un valore di “temperatura” più alto per rendere il testo più naturale.
La valutazione è un’attività che richiede grande concentrazione, ma la qualità viene solitamente al primo posto. Per i controlli di rilascio, i dati sulle preferenze, i controlli RAG o i risultati ad alto rischio, i team utilizzano spesso il modello di valutazione più affidabile che possono permettersi. I modelli più veloci possono essere adatti per controlli in batch a basso rischio, previa calibrazione su campioni revisionati da esseri umani.
Quando si sceglie un modello di valutazione, occorre partire dal costo di un punteggio errato. In molte configurazioni che utilizzano modelli di linguaggio di grandi dimensioni (LLM) come giudici, la qualità della valutazione è più importante della velocità o del costo in token, specialmente quando i punteggi influenzano le decisioni relative al rilascio, i dati di addestramento o i meccanismi di controllo rivolti agli utenti.
Non dovresti essere costretto ad analizzare il testo grezzo per scoprire quale punteggio abbia assegnato il giudice. Quando si sceglie un modello di valutazione, è fondamentale che segua uno schema rigoroso. Potresti utilizzare gli “Structured Outputs” di OpenAI, il “Tool Use” di Anthropic o un framework open source come Outlines. In tutti i casi, il modello dovrebbe restituire una risposta JSON pulita. Se un modello è economico e veloce ma spesso non rispetta la formattazione JSON, è difficile da utilizzare in una pipeline di valutazione automatizzata.
Non è sempre necessario scegliere un solo modello. Per i compiti importanti, di solito opto per un approccio di tipo “ensemble”. Anziché affidarmi a un unico modello costoso, invio la stessa valutazione a diversi modelli di valutazione provenienti da fornitori diversi, come OpenAI, Anthropic e un’opzione open source.
Dopodiché, è possibile confrontare i loro punteggi, calcolare una media o ricorrere al voto a maggioranza. Questo aiuta a ridurre la parzialità derivante da un singolo giudice. Tuttavia, i giudici devono essere sufficientemente diversi tra loro. Se commettono tutti gli stessi errori, il calcolo della media o la votazione non faranno altro che ripetere la stessa parzialità. Ecco perché cerco anche i disaccordi tra i giudici e invio i casi poco chiari a una persona in carne e ossa per la revisione.
L’LLM-as-a-judge è ancora un metodo innovativo per valutare i modelli. Molti team utilizzano già i judge per l’assegnazione dei punteggi, il confronto e i controlli RAG, ma la loro configurazione richiede ancora un notevole impegno manuale. Il prossimo passo consiste nel rendere i sistemi di valutazione più affidabili. Dovrebbero segnalare quando un punteggio è incerto, utilizzare strumenti per verificare i risultati e garantire prestazioni migliori in ambiti specifici.
Queste sono le aree a cui sto prestando maggiore attenzione.
Al momento, i giudici LLM possono mostrarsi eccessivamente sicuri di sé. Se un giudice riceve una richiesta poco chiara, potrebbe comunque assegnare un punteggio definitivo anziché indicare che il caso è incerto.
Mi aspetto che sempre più sistemi di valutazione inizino a indicare i livelli di confidenza insieme al punteggio. Invece di limitarsi a dire passare o fallire, il giudice potrebbe emettere una sentenza del tipo Punteggio: 4, Affidabilità: 65%. Se il livello di affidabilità è troppo basso, il sistema può inoltrare il caso a un revisore umano.
I modelli generici come GPT-5.5 o Claude Sonnet 5 funzionano bene per attività quali e-mail, sintesi e revisione di base del codice. Tuttavia, per valutazioni complesse in ambito medico o legale, è necessario un maggiore controllo sul settore specifico.
Ecco perché mi aspetto di vedere modelli di valutazione sempre più specializzati. Alcuni potrebbero essere ottimizzati per compiti specifici, come la revisione di risposte in ambito medico o la verifica di contratti legali. Questi modelli non sostituiranno gli esperti, ma potranno fornire un valido aiuto occupandosi dei casi di routine e affidando quelli più complessi alle persone.
A strumento per la valutazione dei modelli di linguaggio di grandi dimensioni (LLM) in veste di giudice probabilmente entrerà a far parte di un numero maggiore di scenari di valutazione. I giudici non dovrebbero basarsi esclusivamente sulle proprie conoscenze interne quando hanno la possibilità di verificare i compiti confrontandoli con fonti esterne.
Ad esempio, se un generatore produce uno script Python, il giudice può eseguirlo in un ambiente di test per individuare eventuali errori. Se il generatore fa un’affermazione su un evento recente, il giudice può ricorrere a una ricerca o a una fonte di dati attendibile per verificarla. L’obiettivo è quello di confrontare il risultato con le prove disponibili, anziché valutare il testo isolatamente.
Quando i team utilizzano i punteggi dei giudici nei cicli di addestramento, i modelli generativi potrebbero imparare a soddisfare il giudice piuttosto che fornire risposte migliori agli utenti. Si tratta di una forma di “reward hacking”.
Ad esempio, il generatore potrebbe capire che al giudice piacciono gli elenchi puntati o un linguaggio molto cortese. Potrebbe anche iniziare a ripetere frasi di riempimento che di solito ottengono punteggi elevati. I futuri sistemi di valutazione dovranno disporre di metodi più efficaci per individuare questi comportamenti, in modo che i punteggi riflettano la reale qualità delle risposte.
Molti team considerano ancora la valutazione come uno script a sé stante, da eseguire dopo un prompt o un aggiornamento del modello. Ritengo che questa situazione cambierà man mano che i sistemi di IA diventeranno sempre più integrati nell’ambiente di produzione. Il passo successivo consiste nell’inserire la valutazione nella pipeline di distribuzione. Prima del rilascio, i valutatori possono aiutare a individuare eventuali regressioni nei set di test. Dopo il lancio, possono monitorare i risultati campionati e inoltrare i casi a rischio al personale.
Se hai letto fino a questo punto, probabilmente stai riflettendo su un problema di valutazione nel tuo sistema di intelligenza artificiale. Forse la revisione manuale è troppo lenta. Forse i tuoi punteggi indicano che la qualità è cambiata, ma non spiegano cosa sia andato storto.
Ecco perché l’impostazione è fondamentale. Non dovrebbe essere lo stesso modello a redigere le domande e a valutare le risposte. Sono necessari criteri di valutazione chiari, un metodo strutturato per registrare i risultati e una revisione periodica da parte di persone in carne e ossa per mantenere il sistema ben calibrato.
Il vero rischio è che anche un output fluente possa comunque non soddisfare i requisiti del compito. Un modello può sembrare sicuro di sé, ma al contempo non cogliere il contesto di partenza o ignorare una parte fondamentale della richiesta dell’utente. Un livello di valutazione ben strutturato ti aiuta a individuare questa lacuna prima che lo facciano i tuoi utenti.
Noi di Innowise aiutiamo i team a sviluppare livelli di valutazione per Prodotti LLM, Agenti IA, e sistemi di intelligenza artificiale aziendali. Se il tuo prodotto basato sull'intelligenza artificiale necessita di controlli di qualità più accurati, contattaci.
L'LLM-as-a-judge è un metodo di valutazione in cui un modello linguistico (il "giudice") valuta, assegna un punteggio e fornisce una motivazione in merito ai testi generati da altri sistemi di intelligenza artificiale. Sostituisce le costose revisioni umane automatizzando i controlli di qualità relativi all'accuratezza, alla pertinenza, al tono o alla sicurezza su larga scala.
I giudici basati su modelli LLM spesso forniscono valutazioni accurate in molti compiti di valutazione, ma le loro prestazioni dipendono dal compito, dal modello, dalla griglia di valutazione e dalla calibrazione del sistema. I team dovrebbero confrontare i punteggi assegnati dai giudici con campioni revisionati da esseri umani e monitorare eventuali distorsioni, la sensibilità ai prompt e la deriva.
I giudici LLM accelerano e ampliano il flusso di lavoro di valutazione senza sostituire completamente gli esseri umani. La supervisione umana rimane necessaria per i casi delicati, la creazione di set di dati di addestramento e la definizione degli standard di valutazione.
Quando un modello valuta il proprio lavoro, tende a sopravvalutarsi. Spesso trascura i propri errori e le proprie lacune di scrittura, il che porta a punteggi troppo alti e poco utili.
La triade RAG è un quadro di valutazione progettato per i sistemi di generazione potenziata dal recupero. Misura le prestazioni in base a tre axe specifici: pertinenza del contesto, fondatezza e pertinenza della risposta finale.
Nei cicli di apprendimento per rinforzo, i giudici generati automaticamente da modelli di linguaggio di grandi dimensioni (LLM) producono rapidamente segnali di preferenza automatizzati e valutazioni passo dopo passo. Ciò consente ai modelli di ricompensa di ottimizzare l’allineamento del sistema molto più rapidamente rispetto alle valutazioni manuali effettuate da esseri umani.
I rischi principali derivano dai pregiudizi intrinseci del modello, tra cui la tendenza a privilegiare le risposte più lunghe (pregiudizio di verbosità), a preferire le risposte presentate per prime (pregiudizio di posizione) e a mostrare un’elevata sensibilità alle variazioni minime nella formulazione del prompt.
I team possono ridurre al minimo i bias separando i modelli di generazione da quelli di valutazione, randomizzando l'ordine delle risposte nei test comparativi, nascondendo i metadati dei modelli e convalidando i punteggi automatici rispetto a valori di riferimento verificati da esseri umani.
