Valutare un’applicazione basata su un grande modello di linguaggio (LLM) consiste nel testarla in modo sistematico, prima e dopo ogni modifica. La guida spiega come scegliere i metodi di punteggio, progettare un giudice LLM affidabile, quindi valutare i sistemi RAG e gli agenti lungo l’intero ciclo di pubblicazione.
Leggere alcune risposte e trovarle soddisfacenti non basta. Una modifica del prompt, un cambio di modello o della ricerca documentaria può rompere un comportamento senza che ce ne si accorga, e diventa poi difficile determinare quale cambiamento ne sia responsabile. Valutare significa costituire dei casi di test, assegnare un punteggio a ogni risposta secondo criteri scritti, quindi confrontare i punteggi prima e dopo ogni modifica, sul modello dei test di non regressione del codice classico.
Le risposte di un LLM variano da un’esecuzione all’altra, e la nozione di «risposta corretta» dipende dal contesto. Un test unitario verifica un’uguaglianza, mentre «Potete restituire le scarpe entro 30 giorni» e «I resi sono accettati per un mese dopo la consegna» sono entrambe corrette. La guida distingue la valutazione, che misura una qualità relativa secondo criteri sfumati, dai test, che validano una messa in produzione tramite controlli binari, come un JSON valido o l’assenza di una formula vietata. Bloccare una distribuzione su un punteggio di fedeltà di 0,7 equivarrebbe, secondo l’autore, a dibattere ogni settimana su una soglia arbitraria.
Tre modi per valutare una risposta
Un sistema di punteggio riceve un caso di test, composto da un input, una risposta e talvolta un contesto o un riferimento, quindi restituisce un verdetto o un numero. I sistemi di punteggio basati su codice applicano regole deterministiche, per verificare il formato, la lunghezza o la presenza di determinate stringhe. Quelli basati su un riferimento confrontano la risposta con una risposta nota. Le metriche di sovrapposizione come BLEU e ROUGE, ad esempio, non riconoscono una parafrasi corretta. Il giudice LLM, infine, è un modello incaricato di applicare una griglia di criteri alla risposta di un altro modello, utile per il tono, l’ancoraggio alle fonti o l’utilità.
La guida raccomanda di iniziare con il codice ovunque una regola sia sufficiente, poiché questi sistemi di punteggio non costano nulla e danno sempre lo stesso risultato. Vengono descritte tre configurazioni del giudice: puntuale, dove assegna un’etichetta o un voto a una risposta isolata; a coppie, dove sceglie la migliore tra due risposte, metodo comune per confrontare due prompt o due modelli; e guidata da riferimento, quando dispone di una risposta di riferimento.
Rendere il giudice affidabile
Una griglia di criteri ben scritta determina la qualità del giudice. La guida la descrive in quattro parti: la definizione del criterio, i dati che il giudice può utilizzare, la procedura da seguire e un formato di output rigoroso, preferibilmente in JSON. Il ragionamento deve precedere il verdetto, e la temperatura è fissata a 0 per ridurre il rumore di campionamento, senza eliminarlo. Per i criteri sensibili, la guida suggerisce un numero dispari di esecuzioni e di mantenere il verdetto maggioritario.
Il metodo QAG (generazione di domande-risposte) chiede al giudice di rispondere a domande chiuse con sì o no, il calcolo viene poi effettuato dal codice. La fedeltà di una risposta di quattro affermazioni di cui tre supportate vale così 0,75. Per i criteri soggettivi, il metodo G-Eval calcola una media ponderata dalle probabilità dei voti possibili, così che un modello diviso 60/40 tra 4 e 5 ottiene 4,4. Dei bias sono documentati nella ricerca sul giudizio degli output degli LLM: bias di posizione, bias di verbosità e bias di auto-preferenza per i modelli della stessa famiglia. La guida propone di invertire l’ordine delle risposte, testare casi di lunghezza comparabile e utilizzare un giudice proveniente da un’altra famiglia di modelli.
La calibrazione rimane la fase più importante. La guida consiglia di etichettare autonomamente da 30 a 50 risposte, quindi confrontare queste etichette con quelle del giudice utilizzando il kappa di Cohen, che corregge l’accordo dovuto al caso. Un punteggio di 0 corrisponde a un accordo a livello del caso, e 1 a un accordo perfetto. Oltre circa 0,6, l’accordo è generalmente considerato sostanziale.
RAG, agenti e ciclo di pubblicazione
Un sistema RAG (generazione aumentata dal recupero) combina due componenti che possono fallire separatamente: il motore di ricerca, che recupera il contesto, e il generatore, che redige la risposta. La guida propone di misurare la precisione del contesto, il suo richiamo, la fedeltà della risposta ai documenti recuperati e la sua pertinenza rispetto alla domanda. Un’alta fedeltà associata a un basso richiamo segnala ad esempio una ricerca insufficiente.
Per gli agenti, la guida inizia con il completamento del compito, quindi esamina l’esattezza dello strumento scelto, quella dei suoi argomenti e la traiettoria seguita, senza chiamate ridondanti o cicli. Le valutazioni offline avvengono prima della messa in produzione, su un set di 25-50 casi versionato, con criteri di pubblicazione fissati in anticipo. Le valutazioni online riguardano un campione del traffico reale. Ogni fallimento osservato in produzione può poi diventare un caso di test di riferimento.
