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

Retrieval-Augmented Generation (RAG) è fondamentale per l’architettura moderna dell’AI, fungendo da 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 ostacoli significativi nella raccolta dei dati, nella consolidazione del contesto e nella sintesi delle risposte.

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

L’anatomia della rottura di RAG – 7 punti di fallimento (FP)

Secondo i ricercatori Barnett et al., i sistemi di generazione aumentata di recupero (RAG) incontrano sette punti di fallimento specifici in tutta 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 esecuzione. I punti di fallimento identificati in questo studio sono mostrati in scatole rosse (fonte)

Esaminiamo ogni FP disposto in base alla 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 un documento corretto esiste nel negozio di vettori, ma il recupero non riesce a classificarlo abbastanza in alto da includerlo nei documenti principali forniti 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 un documento corretto esiste 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 adattarli alla finestra di contesto di un LLM, ai limiti di token o ai limiti di velocità.

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 vengono gestiti con successo, ma l’LLM non riesce a seguire le istruzioni di formattazione specifiche fornite nel prompt, come un formato di tabella, un elenco puntato o uno schema JSON.

FP6. Specificità errata

L’output di un LLM è tecnicamente presente, ma troppo generale o troppo complesso 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 di informazione chiave 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 sono presenti informazioni mancanti o errate, 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à, mancando pezzi importanti.

Ottimizzazione del recupero e collo di bottiglia dell’efficienza

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

• FP2 (Documenti classificati in alto mancanti): Il modello di embedding non riesce a selezionare i principali embedding.
• FP3 (Strategia di consolidamento): Lo script per tagliare i documenti per adattarli ai limiti dell’LLM scarta le parti più importanti.

Errori di esperienza utente e formattazione

Sebbene corretta, un output con scarsa leggibilità 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 un output lungo per una 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 deploy

DeepEval calcola un punteggio ponderato in base ai criteri.

Un LLM come giudice (ad esempio, GPT-4o) valuta ogni criterio rispetto all’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 un punteggio ponderato atteso per ogni criterio.

Caso 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: Non c’è prova quantitativa che il bot possa ancora rispondere alla query dell’utente (pensi solo che funzioni…).
• Soluzione: Integra 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 dello sviluppatore – Il caso di test per DeepEval
Un set di oggetti LLMTestCase definisce il caso di test che DeepEval esegue.

In pratica, questo caso di test dovrebbe contenere la maggior parte delle query degli utenti e degli output etichettati con il contesto recuperato.

Questi possono essere recuperati da un file JSON o CSV.

RAGAS – L’ottimizzatore dell’aia

Retrieval Augmented Generation Assessment (Ragas) mira a valutare RAG senza un set di dati annotati manualmente generando set di test sintetici.

Quindi, calcola metriche di bandiera:

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

Le metriche di bandiera sono categorizzate in tre gruppi:

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

Caso comune nella pratica

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

Tabella 1. Matrice di diagnostica e azione di RAGAS – Mappatura dei punteggi agli aggiustamenti del sistema.

TruLens – L’esperto di 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.

Caso comune nella pratica

• Situazione: Un bot consulente medico risponde correttamente a una domanda dell’utente ma aggiunge un consiglio che non è presente nella base PDF verificata.
• Problema: Il consiglio aggiuntivo potrebbe essere utile, ma non è basato su fatti.
• Soluzione: Utilizzare TruLens per implementare una funzione di feedback di fondamento 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 di fallimento silenziosa

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

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

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

Questa analisi degli embedding rivela matematicamente se le query fallite sono raggruppate semanticamente insieme, indicando un gap nel database di vettori.

Caso 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 di embedding UMAP (UEV), una mappa 3D per il database di vettori – per sovrapporre le query degli utenti ai chunk dei documenti.
• Risultati attesi: Vedere visivamente un cluster di query degli utenti che atterrano 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.

Caso comune nella pratica

• Situazione: Un team di ingegneri aggiorna il prompt da “Rispondi alla domanda” (Caso A) a un’istruzione di sistema più complessa di 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 affiancato (SxS) ogni volta che il team aggiorna una sola parola nel prompt:

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

Riepilogo

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, la Tabella 2 mostra quali metriche di valutazione applicare per ogni FP trattato in questo articolo:

Tabella 2. La matrice di mitigazione dei punti 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 del contesto/richiamo 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 nella comparazione dei set di dati di verità di base.