La trappola del numero che sale
Un team lancia un chatbot RAG interno. Dopo due mesi, i dashboard mostrano "answer accuracy 87%", "relevance score 92%", "user satisfaction 4.1/5". Numeri che sembrano buoni. Poi un manager usa il chatbot per cercare una policy specifica, ottiene una risposta fluente e convincente che è sbagliata, e la fiducia crolla in un pomeriggio.
Il problema non era il modello. Era la valutazione.
Valutare un sistema RAG è più difficile che valutare un modello standalone perché stai misurando due sistemi accoppiati: il retrieval e la generation. Quando uno dei due fallisce, l'altro spesso maschera il problema.
La regola base: valuta retrieval e generation separatamente
La prima cosa da fare è smettere di guardare solo la risposta finale. Una risposta sbagliata può derivare da:
- Il retrieval ha trovato i documenti giusti, ma il modello ha generato male
- Il retrieval ha trovato documenti sbagliati, e il modello ha fatto quello che poteva
- Il retrieval ha trovato documenti parzialmente giusti, e il modello ha allucinato il resto
- Nessun documento era rilevante, e il modello avrebbe dovuto dirlo ma non l'ha fatto
Questi quattro casi richiedono fix completamente diversi. Se li tratti come un unico errore "la risposta era sbagliata", stai perdendo tempo sul problema sbagliato.
Metriche di retrieval che contano davvero
Le metriche classiche (Recall@K, MRR, NDCG) sono utili ma spesso insufficienti. Tre metriche operative che in produzione sono più diagnostiche:
Answerable Coverage: per una query data, esiste almeno un documento nel corpus che contiene la risposta corretta? Se la risposta è no e il sistema sta comunque rispondendo, hai un problema di allucinazione strutturale, non di retrieval.
Context Precision @ K: dei documenti recuperati nei top K, quanti sono effettivamente rilevanti? Un recall alto con precision bassa significa che il modello deve scavare nel rumore, e spesso sbaglia.
Redundancy Rate: quante volte i top K documenti contengono essenzialmente la stessa informazione? Tre versioni dello stesso paragrafo non sono tre fonti indipendenti. Inflazionano la confidenza apparente senza aggiungere segnale.
Metriche di generation che contano davvero
Sulle risposte, bisogna distinguere tra qualità fattuale e qualità di forma.
Faithfulness: la risposta è supportata dai documenti recuperati? Una risposta può essere corretta nel merito ma inventata rispetto al contesto fornito — e questo è un problema anche quando casualmente indovina.
Completeness: la risposta copre tutti gli aspetti della domanda, o ne ignora alcuni? Le risposte parziali sono spesso più pericolose delle risposte sbagliate, perché sembrano competenti.
Proper refusal: quando la risposta non è nel corpus, il sistema lo dichiara o prova comunque a rispondere? Un sistema che rifiuta correttamente il 20% delle query è spesso più affidabile di uno che risponde al 100%.
Il test set che serve davvero
I test set sintetici generati da LLM sono utili per iterare velocemente, ma hanno un bias strutturale: le domande generate dal modello tendono a essere facili per il modello. Misurano il sistema nelle sue condizioni ideali.
Tre fonti di test set più realistiche:
Query reali degli utenti, anonimizzate e annotate. Sono il gold standard perché riflettono come le persone formulano davvero le richieste — con errori di battitura, contesto implicito, linguaggio ambiguo.
Query adversariali costruite dagli esperti di dominio. Chiedi a chi conosce il business di pensare a domande che potrebbero mandare in tilt il sistema: policy rare, eccezioni, casi di confine.
Query deliberatamente non rispondibili. Domande la cui risposta non è nel corpus. Se il sistema prova a rispondere lo stesso, sai quanto può "inventare" in produzione.
La metrica silenziosa: tempo di debugging
Una metrica operativa che quasi nessuno traccia ma che è la più predittiva del costo reale di un sistema RAG in produzione è il tempo medio per capire perché una risposta è sbagliata.
Se ti servono 30 minuti di investigazione per ogni risposta problematica, il tuo sistema diventerà impossibile da mantenere appena supera un certo volume di query.
Due pratiche che riducono drasticamente questo tempo:
Logging strutturato ad ogni step. Per ogni risposta, registra: query originale, query riformulata (se applicabile), documenti recuperati con score, prompt finale inviato al modello, risposta generata. Senza questo trail, ogni debug è archeologia.
Trace inline nella risposta durante il testing. Durante le fasi di sviluppo, fai in modo che ogni risposta dell'assistant mostri (in modalità debug) quali documenti ha usato. Trovi bug di retrieval in cinque minuti invece che in un'ora.
Evaluation continua, non evaluation batch
Un errore comune è trattare la valutazione come un evento: "a fine sprint facciamo girare il test set". Questo funziona per una fotografia iniziale, ma non per un sistema in produzione che cambia.
Un approccio più sostenibile è valutare in continuo su un sottoinsieme del traffico reale:
- Campionare l'1-5% delle conversazioni reali
- Passarle attraverso una valutazione automatica (faithfulness, coverage) su ogni deploy
- Escalare a revisione umana i casi con score bassi
Questo pattern ti fa scoprire i problemi di drift — quando il corpus cambia, quando un prompt update peggiora un caso d'uso specifico, quando un nuovo modello si comporta diversamente — prima che li scoprano i tuoi utenti.
La domanda da porsi ogni tre mesi
Ogni 90 giorni, qualcuno del team dovrebbe prendere il test set più vecchio e rigirarlo sul sistema attuale. Non per pubblicare numeri, ma per rispondere a una domanda: stiamo migliorando davvero, o stiamo solo ottimizzando sulle query che già conoscevamo?
Spesso la risposta è la seconda. Un test set che non evolve smette di essere un benchmark e diventa una curva di comfort.
La valutazione utile non è quella che conferma che il sistema funziona. È quella che ti dice, in modo scomodo ma affidabile, quando smette di funzionare.