Come si testa un sistema LLM

Un sistema LLM non è una cosa sola. È una catena: interpretare la domanda, scegliere uno strumento, produrre gli argomenti per quello strumento, recuperare i dati, e infine scrivere. Quando si pensa ai test si va istintivamente alla fine della catena, perché è quello che l'utente vede. È il punto peggiore da cui cominciare.

Verifica gli argomenti, non la prosa

Su una piattaforma di analitica conversazionale, e poi di nuovo su un assistente RAG, abbiamo costruito suite di integrazione che fanno una cosa più semplice di come suona: dato un prompt, il test verifica che il modello abbia prodotto i filtri di retrieval corretti. Non la risposta giusta — la query giusta.

Questa singola mossa cambia l'economia del testing. L'asserzione è deterministica: un insieme di filtri corrisponde o non corrisponde. È veloce, perché confronti valori strutturati e non giudichi del testo. Gira a ogni rilascio come qualsiasi altro test, in CI, senza umani nel ciclo e senza modelli valutatori.

Il test verifica la query e non la esegue mai. Le regressioni sui filtri si catturano senza pagare il retrieval.

E impedisce al conto di crescere

C'è un secondo beneficio che nella letteratura sulle eval non si trova. Siccome la suite non esegue mai la query, non tocca l'indice di ricerca. Su un progetto il costo del retrieval era diventato significativo ai volumi di produzione — abbastanza da far notare a qualcuno una suite end-to-end eseguita a ogni commit. Testare solo il layer di tool call ha eliminato quel costo del tutto.

In questi sistemi qualità e costo di solito tirano in direzioni opposte. Questo è uno dei pochi punti in cui la stessa decisione migliora entrambi, ed è il motivo per cui oggi è la prima cosa che metto in piedi.

Cosa non copre

Non ti dice se la risposta finale è buona. Niente di economico lo fa. Per quello serve la metà lenta: un insieme di casi di riferimento con output attesi, una rubrica, a volte con un modello che la applica dove se lo merita, e soprattutto un programma di validazione condotto con le persone che rispondono del risultato.

Ognuna di quelle tre ha poi avuto il suo articolo, e conviene leggerle in quell'ordine: prima il metro, poi chi lo tiene in mano, infine chi risponde di quello che ne esce.

Sul lavoro con le linee guida ha significato un programma lungo e iterativo con gli specialisti che firmano il documento. Sono i loro feedback ad aver reso buona la pipeline, non la scelta del modello. Ci sono voluti mesi, ed è stata la parte più preziosa del progetto.

Un ordine pratico

Parti dalle asserzioni sui tool call, perché costano poco e catturano le regressioni che capitano davvero. Aggiungi casi di riferimento sull'output generato, da eseguire prima di ogni rilascio più che a ogni commit. Poi, in produzione, raccogli feedback strutturato dalle persone che lo usano: una valutazione e una riga di testo su ogni output bastano per vedere dove la qualità si sposta.

Se non è misurato, non è finito. Ma misurare non deve voler dire un'infrastruttura end-to-end costosa che nessuno esegue due volte.

La serie che ne è nata

Le tre cose che questo pezzo lascia aperte hanno poi avuto ciascuna il suo articolo, e conviene leggerle in quest'ordine.

Golden dataset e test set è il metro. Senza un insieme di esempi con la risposta attesa, «funziona meglio» resta un'opinione, e ogni altra decisione tecnica poggia su niente.

LLM-as-judge è chi tiene il metro quando i casi diventano troppi per una persona. Funziona, ma solo dopo essere stato calibrato contro giudizi umani veri — e con i suoi bias documentati sotto controllo.

Human-in-the-loop è la persona che resta nel ciclo comunque. Non è un sostituto della misura: è il modo di sopravvivere mentre la costruisci, e al terzo mese si vede se è progettato bene.