Come costruire un RAG affidabile: un’analisi approfondita di 7 punti di fallimento e framework di valutazione

Retrieval-Augmented Generation (RAG) è fondamentale per l’architettura moderna dell’AI, servendo come quadro essenziale per la costruzione di agenti consapevoli del contesto.

Ma passare da un prototipo di base a un sistema pronto per la produzione comporta la navigazione di significativi ostacoli nella raccolta dei dati, nella consolidazione del contesto e nella sintesi della risposta.

Questo articolo fornisce un’analisi approfondita di sette punti di fallimento tipici del RAG e delle metriche di valutazione con esempi di codice pratici.

L’anatomia del crollo del RAG – 7 punti di fallimento (FPs)

Secondo i ricercatori Barnett et al., i sistemi di Generazione aumentata da recupero (RAG) incontrano sette punti di fallimento specifici lungo la pipeline.

Il diagramma seguente illustra queste fasi:

Figura A. Processi di indicizzazione e query necessari per creare un sistema RAG. Il processo di indicizzazione viene eseguito durante lo sviluppo e le query in fase di runtime. I punti di fallimento identificati in questo studio sono mostrati in caselle rosse (fonte)

Esaminiamo ogni FP disposto secondo la sequenza della pipeline, seguendo la progressione da in alto a sinistra a in basso a destra mostrata in Figura A.

FP1. Contenuto mancante

Il contenuto mancante si verifica quando il sistema viene chiesto una domanda che non può essere risposta perché le informazioni rilevanti non sono presenti nel negozio di vettori disponibile in primo luogo.

Il fallimento si verifica quando un LLM fornisce una risposta plausibile ma errata invece di affermare non lo sa.

FP2. Documenti classificati in alto mancanti

Questa è una situazione in cui esiste un documento corretto nel negozio di vettori, ma il recuperatore non riesce a classificarlo abbastanza in alto da includerlo nei documenti top-k alimentati a un LLM come contesto.

In conseguenza, le informazioni corrette non raggiungono mai l’LLM.

FP3. Non nel contesto (limitazioni della strategia di consolidamento)

Questa è una situazione in cui esiste un documento corretto e viene recuperato dal negozio di vettori, ma viene escluso durante il processo di consolidamento.

Ciò accade quando vengono restituiti troppi documenti e il sistema deve filtrarli per adattarsi alla finestra di contesto di un LLM, ai limiti di token o ai limiti di frequenza.

FP4. Non estratto

Questa è una situazione in cui un LLM non riesce a identificare le informazioni corrette nel contesto, anche se le informazioni corrette erano presenti nel negozio di vettori e sono state recuperate/consolidate con successo.

Ciò accade quando il contesto è eccessivamente rumoroso o contiene informazioni contraddittorie che confondono l’LLM.

FP5. Formato errato

Questa è una situazione in cui l’archiviazione, il recupero, la consolidazione e l’interpretazione dell’LLM sono gestiti con successo, ma l’LLM non riesce a seguire le istruzioni di formattazione specifiche fornite nel prompt, come un tableau, un elenco puntato o uno schema JSON.

FP6. Specificità errata

La risposta di un LLM è tecnicamente presente, ma troppo generale o troppo complessa rispetto alle esigenze dell’utente.

Ad esempio, un LLM genera risposte semplici a una query dell’utente con un obiettivo professionale complesso.

FP7. Risposte incomplete

Questa è una situazione in cui un LLM genera un output non necessariamente errato, ma mancante di pezzi chiave di informazione che erano disponibili nel contesto.

Ad esempio, quando un utente chiede una domanda complessa come “Quali sono i punti chiave nei documenti A, B e C?”, l’LLM affronta solo una o due delle fonti.

Come i FP compromettono le prestazioni della pipeline RAG

Ognuno di questi FP impatta sulle prestazioni delle pipeline RAG:

Integrità dei dati e fallimenti di fiducia

Quando le informazioni mancanti o errate sono presenti, il sistema non è più una fonte affidabile di informazioni. I principali FP includono:

• FP1 (Contenuto mancante): La risposta non è nel documento in primo luogo.
• FP4 (Non estratto): L’LLM decide di ignorare la risposta corretta nel documento.
• FP7 (Incompleto): L’LLM fornisce mezze verità, mancanti di pezzi importanti.

Colli di bottiglia di recupero ed efficienza

La pipeline RAG può essere inefficiente quando manca informazioni chiave nelle fasi di recupero e consolidamento. I principali FP includono:

• FP2 (Classificazione mancata): Il modello di embedding non riesce a selezionare i primi k embedding.
• FP3 (Strategia di consolidamento): Lo script per tagliare i documenti per adattarli ai limiti dell’LLM elimina le parti più importanti.

Errori di formattazione e di esperienza utente

Sebbene corretta, una risposta con una formattazione scadente o in un formato errato può compromettere l’esperienza utente. I principali FP includono:

• FP5 (Formato errato): L’LLM non riesce a seguire il formato di output specifico come JSON.
• FP6 (Specificità errata): L’LLM genera una risposta lunga per una semplice domanda sì/no, o viceversa (risposta troppo breve per una domanda complessa).

La pila di valutazione: framework per mitigare i FP

Le metriche di valutazione sono progettate per mitigare sistematicamente questi FP.

Questa sezione esplora le principali metriche di valutazione con casi d’uso pratici.

Principali metriche di valutazione RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Il test unitario prima del deployment

DeepEval calcola un punteggio ponderato in base ai criteri.

Un LLM come giudice (ad esempio GPT-4o) valuta ogni criterio contro l’output di un LLM:

DeepEval sfrutta G-eval, un framework chain-of-thought (CoT) che adotta un approccio multistep per valutare l’output:

1. Definisci un criterio da misurare (ad esempio “coerenza”, “fluidità” o “rilevanza”).
2. Genera passaggi di valutazione (utilizzando un LLM valutatore).
3. Segui il passaggio di valutazione e analizza l’input e l’output dell’LLM.
4. Calcola una somma ponderata attesa del punteggio di ogni criterio.

Scenario comune nella pratica

• Situazione: Un assistente di documentazione tecnica (bot) per un prodotto software complesso sembra funzionare ogni volta che il team di ingegneri aggiorna il codice.
• Problema: Nessuna prova quantitativa che il bot possa ancora rispondere alla query dell’utente (Pensi solo che funzioni…).
• Soluzione: Integrare una funzione PyTest come suite di regressione CI/CD in Github Action dove DeepEval esegue G-Eval e altre metriche su un caso di test:

• Risultati attesi: Se qualsiasi punteggio delle metriche scende al di sotto della soglia (0,85), PyTest solleva AssertionError – fallendo immediatamente la build CI, impedendo che la regressione silenziosa raggiunga la produzione.

Nota per gli sviluppatori – Il caso di test per DeepEval
Un set di oggetti LLMTestCase definisce il caso di test che DeepEval esegue.

Nella pratica, questo caso di test dovrebbe contenere le query degli utenti più importanti e i relativi output etichettati con il contesto recuperato.

Questi possono essere recuperati da un file JSON o CSV.

RAGAS – L’ottimizzatore dell’ago nella paglia

Valutazione della generazione aumentata da recupero (RAGAS) mira a valutare RAG senza un set di dati annotato da esseri umani generando set di test sintetici.

Quindi, calcola le metriche flagship:

Figura B. Il diagramma della triade di valutazione RAGAS che collega Domanda, Contesto e Risposta attraverso metriche di precisione, richiamo, fedeltà e rilevanza (Creato da Kuriko IWAI)

Le metriche flagship sono categorizzate in tre gruppi:

• Pipeline di recupero (linea nera, solida, Figura B): precisione del contesto, richiamo del contesto.
• Pipeline di generazione (linea nera, tratteggiata, Figura B): fedeltà, rilevanza della risposta.
• Verità di base (casella rossa, Figura B): similarità semantica della risposta, correttezza della risposta.

Scenario comune nella pratica

• Situazione: Il sistema RAG per contratti legali manca di clausole chiave. Non si è sicuri se il problema è nel Search (Recuperatore) o nel Reading (Generatore).
• Problema: Nessuna idea sull’ottimale top-k (numero di chunk recuperati).
• Soluzione: Utilizzare RAGAS per creare un set di test sintetico con 100 paia di domande e prove. Quindi, eseguire la pipeline RAG sul set di test per calcolare il richiamo del contesto e la precisione del contesto:
• Risultato atteso: A seconda dei risultati delle metriche, il piano d’azione può essere il seguente:

Tabella 1. Piano d’azione di diagnostica RAGAS – Mapping dei punteggi alle regolazioni del sistema.

TruLens – La specialista del ciclo di feedback

TruLens si concentra sulla meccanica interna del processo RAG piuttosto che solo sull’output finale utilizzando funzioni di feedback.

Utilizza anche un punteggio basato su LLM che riflette quanto bene la risposta soddisfi l’intento della query, utilizzando una scala Likert a 4 punti (0-3), rendendolo superiore per classificare la qualità dei diversi risultati di ricerca.

Scenario comune nella pratica

• Situazione: Un bot consigliere medico risponde a una domanda dell’utente in modo corretto ma aggiunge un suggerimento che non è nel PDF di base verificato.
• Problema: Il suggerimento aggiuntivo potrebbe essere utile, ma non è basato su fatti.
• Soluzione: Utilizzare TruLens per implementare una funzione di feedback di basatezza con una soglia come punteggio > 0,8.

• Risultati attesi: Quando l’LLM genera una risposta che contiene informazioni non presenti nei chunk recuperati, TruLens segnala il record nel pannello di controllo.

Arize Phoenix – La mappa del fallimento silenzioso

Arize Phoenix è uno strumento di osservabilità e valutazione open-source per valutare gli output LLM, inclusi sistemi RAG complessi.

Costruito su OpenTelemetry da Arize AI, si concentra sull’osservabilità trattando la valutazione LLM come un subset di MLOps.

Nel contesto della valutazione RAG, Phoenix eccelle nell’analisi dell’embedding, utilizzando Uniform Manifold Approximation and Projection (UMAP) per ridurre le embedding di vettori ad alta dimensionalità nello spazio 2D/3D.

Questa analisi dell’embedding rivela matematicamente se le query fallite sono raggruppate semanticamente insieme, indicando una lacuna nel database di vettori.

Scenario comune nella pratica

• Situazione: Un bot di supporto clienti funziona bene per i rimborsi, ma fornisce risposte insensate per le richieste di garanzia.
• Problema: Buco nei dati nel database di vettori (Impossibile trovarlo nei log).
• Soluzione: Utilizzare Arize Phoenix per generare una visualizzazione dell’embedding UMAP (UEV), una mappa 3D per il database di vettori – per sovrapporre le query degli utenti ai chunk di documenti.
• Risultati attesi: Visualizzare un cluster di query degli utenti che atterra nella zona buia dove non esistono documenti, indicando che alcuni documenti sono stati dimenticati durante l’upload nel negozio di vettori.

Braintrust – La rete di sicurezza della regressione del prompt

Braintrust è progettato per cicli di iterazione ad alta frequenza utilizzando confronto tra modelli.

Scenario comune nella pratica

• Situazione: Un team di ingegneri aggiorna il prompt da “Rispondi alla domanda” (Caso A) a un sistema di istruzioni più complesso da 500 parole (Caso B).
• Problema: Migliorare il prompt per il Caso B potrebbe accidentalmente rompere il Caso A.
• Soluzione: Utilizzare Braintrust per creare un set di dati dorati con un set di N esempi perfetti (ad esempio N = 50). Lasciare che Braintrust esegua un confronto lado a lado (SxS) ogni volta che il team aggiorna una parola nel prompt:

• Risultato atteso: Un report di differenza che mostra esattamente quali casi sono migliorati/peggiorati per ogni set di dati dorati (N = 50).

Riassunto

Quando gestito con framework di valutazione appropriati, RAG può essere uno strumento competitivo per fornire un contesto LLM più rilevante per la query dell’utente.

Strategia di implementazione: mappatura delle metriche ai punti di fallimento

Sebbene non ci sia una soluzione universale, Tabella 2 mostra quali metriche di valutazione applicare per ogni FP che abbiamo coperto in questo articolo:

Tabella 2. La matrice di mitigazione del punto di fallimento – Quale strumento risolve quale FP?

DeepEval e RAGAS possono sfruttare le loro metriche di fedeltà per misurare i fallimenti di integrità dei dati (FP1, FP4, FP7).

TruLens sfrutta la sua precisione e richiamo del contesto per misurare la rilevanza del contesto per l’output – valutando efficacemente FP2.

Arize Phoenix fornisce una traccia visiva del processo di recupero, rendendo facile vedere se il documento recuperato è stato perso durante il consolidamento (FP3).

Per i fallimenti dell’esperienza utente, DeepEval crea metriche personalizzate per valutare i fallimenti dell’esperienza utente, mentre Braintrust eccelle nel confronto del set di dati di verità.