Come costruire un sistema RAG affidabile: sette punti di fallimento e 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 richiede di superare ostacoli significativi nel recupero dei dati, nel consolidamento 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 programmazione.

Anatomia dei malfunzionamenti RAG – 7 punti di fallimento (FP)

Secondo i ricercatori Barnett e colleghi, i sistemi di generazione potenziata dal recupero di informazioni (RAG) incontrano sette specifici punti di fallimento (FP) 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 riquadri rossi (fonte)

Esaminiamo ciascun FP nella sequenza della pipeline, procedendo dall’alto a sinistra al basso a destra come mostrato in Figura A.

FP1. Contenuto mancante

Il contenuto mancante si verifica quando al sistema viene posta una domanda a cui non può rispondere perché le informazioni rilevanti non sono presenti nell’archivio vettoriale disponibile fin dall’inizio.

Il fallimento si verifica quando un LLM fornisce una risposta plausibile ma errata invece di dichiarare di non sapere.

FP2. Il documento corretto non rientra nei primi risultati

Questa è una situazione in cui un documento corretto esiste nell’archivio vettoriale, ma il componente di recupero non riesce a posizionarlo abbastanza in alto da includerlo nei primi k documenti (top-k) forniti a un LLM come contesto.

Di 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 dall’archivio vettoriale, 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 frequenza delle chiamate.

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 nell’archivio vettoriale 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, il consolidamento 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 pone 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 mancano o sono errate, il sistema non è più una fonte affidabile di informazioni. I principali FP includono:

• FP1 (Contenuto mancante): La risposta non è nel documento fin dall’inizio.
• FP4 (Non estratto): L’LLM decide di ignorare la risposta corretta nel documento.
• FP7 (Incompleto): L’LLM fornisce mezze verità, omettendo informazioni importanti.

Colli di bottiglia nel recupero e nell’efficienza

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

• FP2 (Il documento corretto non rientra nei primi risultati): Il modello di embedding non riesce a selezionare i primi k embedding (top-k).
• 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

Anche se corretto, 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).

Il sistema 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 i passaggi di valutazione e analizza l’input e l’output dell’LLM.
4. Calcola una somma ponderata attesa dei punteggi di ciascun 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 Actions 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 le query più importanti degli utenti e gli output etichettati con il contesto recuperato.

Questi possono essere recuperati da un file JSON o CSV.

RAGAS – ottimizza la ricerca dell’ago nel pagliaio

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

Quindi, calcola metriche principali:

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 principali 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.
• Dati di riferimento (riquadro rosso, 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 (componente di recupero) o nella Lettura (Generatore).
• Problema: Non si conosce il valore ottimale di top-k (numero di chunk recuperati).
• Soluzione: Utilizzare RAGAS per creare un set di test sintetico con 100 coppie di domande e prove a supporto. 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 è supportato dalle fonti.
• Soluzione: Utilizzare TruLens per implementare una funzione di feedback che valuta il supporto nelle fonti con una soglia come score > 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 dei malfunzionamenti silenziosi

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 nell’archivio vettoriale.

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 dataset di riferimento 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 delle differenze che mostra esattamente quali casi del dataset di riferimento (N = 50) sono migliorati o peggiorati.

Riepilogo

Quando gestito con framework di valutazione appropriati, RAG può essere uno strumento competitivo per fornire all’LLM il contesto 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 dataset di riferimento.