Come valutare un sistema RAG: metriche, test set e monitoraggio

Valutare un sistema RAG significa misurare due cose separate: se il recupero trova i passaggi giusti (recall@k, MRR, precision) e se la risposta generata resta fedele a quei passaggi (faithfulness, accuratezza delle citazioni). Senza un test set di domande reali e un monitoraggio continuo in produzione, un sistema che sembra perfetto in demo può dare risposte sbagliate appena cambiano i documenti o gli utenti.

Perché valutare un sistema RAG non è un optional

Un sistema RAG combina un motore di ricerca sui documenti con un modello linguistico che genera la risposta. Ognuno dei due componenti può fallire in modo indipendente: il retrieval può non trovare il passaggio rilevante, oppure il modello può trovarlo ma interpretarlo male o aggiungere informazioni che non ci sono. Il risultato in entrambi i casi è una risposta sbagliata, ma le cause e le correzioni sono completamente diverse.

Per un'azienda italiana che usa un chatbot documentale per rispondere a clienti, dipendenti o professionisti, l'errore ha un costo concreto: un ticket di assistenza risolto male, un parere tecnico impreciso, un riferimento normativo citato a sproposito. In settori regolati (sanità, legale, finanza) l'affidabilità delle risposte è anche una questione di responsabilità verso il cliente finale e, indirettamente, di conformità al GDPR quando si trattano dati personali nei documenti. Valutare il sistema prima e dopo il rilascio permette di individuare questi problemi quando costano ancora poco da correggere.

Le metriche di retrieval: recall@k, MRR e precision

Prima ancora di guardare la risposta finale, bisogna chiedersi: il motore di ricerca ha recuperato i passaggi giusti tra quelli candidati? Queste sono le metriche di retrieval, mutuate dall'information retrieval classico e applicate ai chunk indicizzati.

• Recall@k: su tutte le domande del test set, in quale percentuale dei casi il passaggio rilevante compare tra i primi k risultati restituiti? Un recall@5 dell'80% significa che in un caso su cinque il passaggio corretto non è nemmeno tra i primi cinque candidati, e quindi il modello generativo non potrà mai citarlo correttamente.
• MRR (Mean Reciprocal Rank): misura non solo se il passaggio giusto è presente, ma a che posizione. Se compare sempre primo, MRR vale 1; se compare in media in terza posizione, MRR vale circa 0,33. È utile quando l'ordine dei risultati conta, ad esempio se il modello generativo tende a dare più peso ai primi passaggi del contesto.
• Precision@k: tra i k passaggi restituiti, quanti sono effettivamente pertinenti? Una precision bassa non impedisce necessariamente una buona risposta, ma aumenta il rischio che il modello si confonda con informazioni irrilevanti mescolate a quelle corrette.

In pratica, un retrieval basato solo su ricerca semantica (embedding) tende ad avere recall buono su domande formulate in modo discorsivo ma può perdere riferimenti esatti (codici, numeri di articolo, sigle tecniche). Un retrieval che combina full-text e ricerca vettoriale, la cosiddetta ricerca ibrida, tende a dare recall e precision più stabili su entrambi i tipi di domande, ed è una delle ragioni per cui piattaforme come Kopik indicizzano i documenti con ricerca ibrida di default invece di affidarsi al solo embedding.

Faithfulness: la risposta usa solo ciò che è nei documenti?

La faithfulness (fedeltà) misura se ogni affermazione nella risposta generata è effettivamente supportata dai passaggi recuperati, senza aggiunte, estrapolazioni o invenzioni. È una metrica diversa dalla correttezza fattuale generica: una risposta può essere vera nel mondo reale ma non fedele ai documenti forniti (il modello l'ha generata dalla sua conoscenza pregressa, non dal contesto), ed è proprio questo il comportamento che un sistema RAG dovrebbe evitare quando l'obiettivo è dare risposte verificabili sui Suoi documenti.

Per misurare la faithfulness in modo sistematico esistono due approcci complementari:

• Revisione umana a campione: un revisore legge la risposta, i passaggi citati e verifica frase per frase se ogni affermazione trova riscontro nel testo. È il metodo più affidabile ma richiede tempo, quindi va applicato a un campione rappresentativo, non a tutte le risposte.
• LLM-as-judge: si usa un modello linguistico per confrontare risposta e passaggi e segnalare affermazioni non supportate. È più veloce e scalabile, ma va calibrato periodicamente contro la revisione umana per verificare che non stia convalidando errori sistematici.

Un modo pratico per ridurre i problemi di faithfulness a monte è restringere il comportamento del sistema: impostare prompt che vietano esplicitamente di rispondere oltre a quanto presente nei passaggi, usare una modalità che restituisce solo i passaggi grezzi quando serve massima trasparenza, o abbassare la soglia di confidenza richiesta prima di generare una risposta. Questo tema è approfondito in come ridurre le allucinazioni dell'IA con risposte basate sulle fonti.

Accuratezza delle citazioni: la fonte citata è quella giusta?

Un sistema RAG ben progettato non si limita a dare una risposta plausibile: cita il passaggio esatto da cui l'ha tratta. Ma la citazione stessa va verificata su due livelli distinti: esiste davvero nel documento originale (nessun collegamento rotto o riferimento inventato), e supporta effettivamente l'affermazione a cui è associata (non è solo un passaggio vagamente correlato all'argomento).

Per valutare l'accuratezza delle citazioni si può costruire una metrica semplice: su un campione di risposte, quante citazioni sono sia presenti nel documento sia pertinenti all'affermazione specifica? Se questa percentuale scende sotto una soglia accettabile per il Suo caso d'uso (ad esempio il 90% per un contesto professionale), vale la pena rivedere la strategia di chunking: passaggi troppo lunghi mescolano più concetti e rendono la citazione meno precisa, passaggi troppo corti perdono il contesto necessario per un'interpretazione corretta. I criteri per bilanciare questo compromesso sono trattati in dettaglio nella guida al chunking per RAG.

Costruire un test set di domande reali

Le metriche sopra descritte hanno senso solo se applicate a un test set rappresentativo delle domande che gli utenti faranno davvero, non a domande inventate a tavolino dal Suo team tecnico. Ecco come costruirne uno in modo efficace:

1. Raccolga 50-100 domande reali da ticket di assistenza, email, trascrizioni di call o ricerche interne già fatte sui documenti.
2. Per ogni domanda, annoti manualmente qual è il passaggio (o i passaggi) corretto nei documenti e, se possibile, una risposta di riferimento concisa.
3. Includa domande con formulazioni diverse per lo stesso bisogno informativo (sinonimi, acronimi, linguaggio colloquiale), perché il retrieval reale deve gestire anche queste varianti.
4. Aggiunga domande trabocchetto: argomenti non coperti dai documenti, per verificare che il sistema risponda «non lo so» invece di inventare.
5. Aggiorni il test set ogni volta che carica nuovi documenti o che riceve segnalazioni di risposte sbagliate dagli utenti: un test set statico perde rappresentatività nel tempo.

Un test set da 50 domande ben costruito, rivalutato manualmente su un campione ogni due o tre settimane, dà più informazioni utili di mille domande sintetiche generate automaticamente senza controllo umano.

Monitoraggio continuo in produzione

La valutazione pre-rilascio riduce i rischi evidenti, ma un sistema RAG in produzione è esposto a due fenomeni che solo il monitoraggio continuo intercetta: il drift dei documenti (nuovi contenuti caricati che cambiano la distribuzione delle risposte corrette) e il drift degli utenti (nuove tipologie di domande che il test set originale non copriva).

Un processo di monitoraggio sostenibile per una PMI italiana, senza bisogno di un team dedicato all'osservabilità, può includere:

• Un campionamento settimanale delle conversazioni reali (5-10% del volume) per una revisione rapida di faithfulness e accuratezza delle citazioni.
• Un pulsante di feedback «risposta utile / non utile» esposto agli utenti finali, con raccolta dei casi negativi per arricchire il test set.
• Un ricalcolo periodico di recall@k e MRR dopo ogni caricamento significativo di nuovi documenti nella base di conoscenza.
• Un alert quando la percentuale di risposte senza passaggi recuperati (nessun match sopra soglia) supera un livello definito, segno che mancano documenti su un argomento richiesto spesso.

Su una base di conoscenza interrogabile via API o tramite server MCP, è possibile loggare domanda, passaggi recuperati e risposta per ogni chiamata, costruendo nel tempo uno storico utile sia per il monitoraggio sia per arricchire il test set con casi reali difficili.

Domande frequenti