Valutare un sistema RAG in produzione: dalla golden dataset alla CI

Un sistema RAG può sembrare funzionante e restare sbagliato: il retrieval recupera dei chunk, il modello generativo scrive una risposta fluente, nessun errore viene sollevato e intanto la risposta si basa sul documento sbagliato, o manca metà delle informazioni, o è fondata su qualcosa di vero ma vecchio di tre versioni. Su Towards Data Science, Priyansh Bhardwaj descrive come costruire una evaluation pipeline che intercetti questi casi prima degli utenti, trattando la valutazione come processo continuo e non come notebook aperto prima di una riunione.

Golden dataset e primo controllo manuale

Il punto di partenza è la golden dataset: un insieme di domande con risposta corretta scritta da chi conosce il dominio e l’indicazione del documento che la contiene. Quest’ultimo campo permette di distinguere un fallimento di retrieval (chunk sbagliato) da uno di generazione (chunk giusto, risposta sbagliata), che sono bug diversi con fix diversi. Bastano 20-30 domande per avere segnale, ma conta la categoria: oltre ai fatti semplici servono casi multi-hop, no answer expected, documenti in conflitto o stale, e formulazioni adversarial. La categoria più saltata, i documenti obsoleti, è anche quella che produce più incidenti in produzione. Prima di automatizzare qualsiasi scoring conviene leggere le risposte accanto alla ground truth, per scoprire prompt rotti o retriever vuoti.

RAGAS, LLM judge e human in the loop

RAGAS dà uno scoring ripetibile su quattro dimensioni: context precision, context recall, faithfulness e answer relevancy (nel run di esempio 0,81, 0,74, 0,88 e 0,85). Il limite strutturale è leggere una faithfulness alta come “risposta corretta”: la metrica verifica solo che la risposta sia sostenuta dal contesto recuperato, non che il contesto fosse quello giusto. Un documento stale, riassunto fedelmente, produce una risposta groundata e completamente sbagliata. Qui entra un LLM judge con prompt custom, da limitare alle categorie dove RAGAS non basta (conflicting docs e no answer expected) per non pagare precisione inutile. Restando LLM che valutano altri LLM, va misurato l’accordo con l’umano: valori nella fascia bassa-media dell’80% sono comuni, non un difetto ma un tetto da conoscere.

Il salto verso una vera pipeline richiede scheduling attento ai costi e un gate in CI: RAGAS sulla golden dataset a ogni pull request che tocca retrieval o prompt, judge custom solo sulle categorie flaggate, revisione umana settimanale sulla coda di disaccordo, campionamento del traffico reale settimanale. Un controllo di regressione che blocca il merge se una metrica scende oltre una soglia (nell’esempio 0,03) intercetta oggi un cambio di chunking che altrimenti diventerebbe un ticket di supporto fra tre settimane.

• Il campo source_doc nella golden dataset separa i fallimenti di retrieval da quelli di generazione.
• Faithfulness alta non significa risposta corretta: RAGAS non riconosce una fonte obsoleta ma fedelmente riassunta.
• Un gate di regressione in CI e il campionamento del traffico reale trasformano la valutazione da esercizio una tantum a parte dell’infrastruttura.

Fonte: Building Trustworthy Production RAG Systems Through Continuous Evaluation — https://towardsdatascience.com/building-trustworthy-production-rag-systems-through-continuous-evaluation/