RAG non riuscito — Ma quale livello ha effettivamente fallito? Un metodo diagnostico

Un sistema RAG restituisce una risposta debole, errata, incompleta o non supportata. La diagnosi abituale è "il retrieval ha fallito" o "il modello ha allucinato". Entrambe le etichette sono troppo generiche per essere utili. Una pipeline RAG di produzione può fallire prima del retrieval, durante il retrieval, durante il ranking, durante l'assemblaggio del contesto, durante la generazione o dopo la generazione, quando vengono verificati evidenza e validità.

Perché "il RAG ha fallito" non è una diagnosi

La generazione aumentata dal recupero combina diversi meccanismi: una richiesta dell'utente viene interpretata, vengono costruite una o più ricerche, viene recuperato materiale candidato, i risultati vengono filtrati o riordinati, l'evidenza selezionata viene inserita in un contesto del modello e un modello genera una risposta. I sistemi di produzione possono aggiungere permessi, filtri sui metadati, regole di freschezza, citazioni, riscrittura delle query, ricerca ibrida, chiamate a strumenti, memoria e stato esterno.

Una risposta finale errata quindi non ti dice quale componente ha fallito. Il modello potrebbe aver ricevuto l'evidenza sbagliata. Potrebbe aver ricevuto l'evidenza giusta mescolata con troppo rumore. L'evidenza potrebbe essere corretta ma obsoleta. La fonte potrebbe non aver mai contenuto la risposta. Oppure il modello potrebbe aver ignorato un contesto perfettamente adeguato.

La guida RAG di OpenAI stabilisce già una distinzione fondamentale tra fallimento del retrieval e fallimento del modello: un sistema può fornire il contesto sbagliato, oppure può fornire il contesto giusto e generare comunque la risposta sbagliata. AWS separa analogamente la valutazione di solo retrieval dalla valutazione di retrieve-and-generate. Per la diagnosi di produzione, tale distinzione dovrebbe essere portata oltre.

Il RAG Failure Stack

Livello 1 — Copertura della fonte: il sistema può rispondere affatto?

Prima di ottimizzare embedding, reranker o prompt, verifica che la risposta esista nello spazio di conoscenza che il sistema è autorizzato a usare. Sembra ovvio, ma molti fallimenti del RAG sono in realtà fallimenti del corpus. Il fatto richiesto può essere assente, nascosto in un allegato non indicizzato, disponibile solo in un documento più recente, memorizzato in un sistema esterno al corpus RAG o bloccato da permessi.

Una metrica di retrieval non può recuperare informazioni che non sono mai state indicizzate. Un top-k più grande non può recuperare un documento che la pipeline non contiene. Se il test di copertura della fonte fallisce, la correzione corretta è l'ingestione, la selezione della fonte, i permessi o un comportamento esplicito di "non rispondibile dall'evidenza disponibile".

Livello 2 — Costruzione della query: il sistema ha posto al corpus la domanda giusta?

La query dell'utente non è sempre la query di retrieval. I sistemi di produzione riscrivono le domande, risolvono i pronomi, estraggono entità, traducono lingue, aggiungono vincoli sui metadati, dividono domande complesse o generano più ricerche. Ogni trasformazione può migliorare il retrieval, ma ogni trasformazione può anche distruggere informazioni.

Una richiesta come "La policy si applica ancora ai contraenti in Germania dopo l'aggiornamento di settembre?" contiene almeno un'entità, una popolazione, una giurisdizione e un confine temporale. Una query riscritta che diventa "policy contraenti" può recuperare testo semanticamente correlato perdendo le variabili che decidono se la risposta è valida.

Livello 3 — Recupero dei candidati: le prove rilevanti sono entrate nell'insieme?

Il recupero dei candidati è principalmente un problema di richiamo. La domanda diagnostica non è ancora se il risultato migliore si è classificato primo; è se le prove rilevanti sono apparse ovunque nel pool di candidati. Se la fonte corretta nota non appare, indagare su indicizzazione, suddivisione in blocchi, embedding, corrispondenza lessicale, metadati, ricerca ibrida, gestione della lingua, sinonimi ed espansione delle query.

È qui che la valutazione solo del recupero è preziosa. AWS espone la rilevanza del contesto e la copertura del contesto per la valutazione RAG solo di recupero. L'abitudine di produzione importante è valutare il recupero prima della generazione, in modo che una risposta finale rifinita non possa nascondere un insieme di candidati debole.

Livello 4 — Classificazione e filtraggio: le prove giuste sono state scartate o sepolte?

Un sistema può avere un buon richiamo e fallire comunque perché le prove rilevanti si classificano al di sotto di materiale rumoroso ma semanticamente simile. Reranker, potenziamenti di recenza, pesi di autorità, preferenze linguistiche, filtri tenant, controlli di accesso, filtri di stato del prodotto e deduplicazione cambiano tutti ciò che sopravvive nel contesto finale.

Il debug dovrebbe quindi preservare l'elenco completo dei candidati, non solo i top-k finali. Se la prova d'oro è stata recuperata al rango 18 e un reranker l'ha rimossa, la correzione non è la stessa di un mancato recupero.

Livello 5 — Assemblaggio del contesto: le prove utili sono diventate un contesto utilizzabile?

Il successo del recupero non garantisce il successo del contesto. I blocchi rilevanti possono essere troncati, separati dai loro qualificatori, duplicati fino a dominare il prompt, mescolati con versioni contraddittorie o circondati da abbastanza testo irrilevante che il passaggio decisivo perde salienza.

I confini dei blocchi sono particolarmente importanti. Una frase può contenere la regola mentre la frase successiva contiene l'eccezione. Se sono indicizzati separatamente e viene recuperata solo la prima, il retriever può apparire rilevante mentre il contesto assemblato diventa fuorviante.

Livello 6 — Generazione: il modello può usare correttamente le prove corrette?

Una volta che il sistema ha dimostrabilmente fornito prove sufficienti, la generazione diventa testabile in modo indipendente. Il modello può generalizzare eccessivamente, combinare passaggi incompatibili, ignorare un'affermazione negativa, non seguire il formato di risposta richiesto, inventare un ponte tra i fatti o rispondere dalla memoria parametrica invece che dalle prove recuperate.

Ecco perché la correttezza end-to-end da sola è insufficiente per la diagnosi. OpenAI raccomanda la valutazione come un modo strutturato per comprendere il comportamento dell'applicazione, mentre la guida alla valutazione degli agenti di Anthropic enfatizza prove multiple, valutatori, tracce e casi di fallimento realistici. Per RAG, il generatore dovrebbe essere testato sia con il recupero normale sia con un contesto d'oro controllato.

Livello 7 — Attribuzione delle prove: la risposta è effettivamente supportata?

Una risposta plausibile con citazioni può comunque essere debolmente fondata. Il documento citato può essere rilevante per l'argomento ma non supportare l'affermazione specifica. Una frase può essere supportata mentre un'altra è inferita. Una citazione può puntare a una fonte che contraddice la risposta una volta lette le sue condizioni.

La valutazione delle citazioni appartiene quindi dopo la generazione. AWS distingue la precisione delle citazioni dalla copertura delle citazioni: se i passaggi citati sono citati correttamente e se la risposta è sufficientemente supportata dalle citazioni. In produzione, il supporto a livello di affermazione è più utile che trattare la presenza di qualsiasi citazione come qualità delle prove.

Livello 8 — Validità e freschezza: le prove erano corrette per questa versione della realtà?

RAG può recuperare una fonte perfettamente autentica, altamente rilevante e fedelmente citata e produrre comunque una risposta sbagliata se la fonte non è più valida per la domanda attuale. Le politiche cambiano. Le API vengono deprecate. I prezzi si muovono. Il comportamento del software cambia tra le versioni. L'inventario dei prodotti cambia. I permessi cambiano. Le patch dei giochi cambiano la meccanica.

Questa è una classe di fallimento separata dall'allucinazione. Le prove sono reali; la loro applicabilità è sbagliata. Un sistema robusto necessita quindi di timestamp, metadati di versione o giurisdizione ove rilevante, autorità della fonte, regole di supersessione e un meccanismo esplicito per decidere quando le prove più vecchie devono essere limitate o abbandonate.

Il metodo di isolamento più rapido: il test del contesto oracolare

La prima suddivisione più utile è semplice: fornire manualmente al generatore un piccolo insieme di prove che sai essere sufficienti per rispondere alla domanda. Mantieni il compito e la risposta attesa invariati.

Una sequenza diagnostica di produzione

Non cambiare tre livelli contemporaneamente

Un errore comune di debug è cambiare embeddings, dimensioni dei chunk, top-k, prompt e modello in una sola iterazione. Se il punteggio migliora, non sai perché. Se peggiora, non sai quale modifica ha causato la regressione.

Tratta il debug del RAG come una diagnosi sperimentale: mantieni costante quanta più pipeline possibile e sostituisci un componente incerto con un input controllato. I documenti gold isolano il retrieval. I chunk gold isolano la selezione dei chunk. Un contesto fisso isola la generazione. Un modello fisso isola le modifiche al retrieval. Un corpus fisso isola le modifiche a ingestione e indicizzazione.

Una matrice dei fallimenti per i sintomi comuni del RAG

Misura ogni livello con la metrica che può effettivamente influenzare

Una risposta corretta può comunque nascondere un difetto del RAG

Anche il problema inverso è importante. Un sistema RAG può produrre la risposta corretta mentre il retrieval è rotto. Il modello potrebbe già conoscere la risposta dall'addestramento, inferirla da prove deboli o indovinare correttamente. Se la valutazione guarda solo alla risposta finale, il sistema può sembrare sano finché la domanda non raggiunge informazioni che esistono solo nel corpus privato.

È lo stesso problema di affidabilità che emerge più in generale nei sistemi ad agenti: la correttezza dell'esito non basta a provare che il percorso di esecuzione fosse affidabile. Per il RAG, le tracce dovrebbero conservare almeno la query di retrieval, l'insieme dei candidati, il ranking, il contesto finale, la risposta, le citazioni, la versione del modello, la versione del corpus/indice e i filtri rilevanti.

Usa ipotesi concorrenti, non una spiegazione preferita

Se una risposta sbagliata diventa immediatamente "un problema di embedding", l'indagine è già prevenuta. Un metodo di debug più solido annota ipotesi concorrenti prima di modificare il sistema: fonte mancante, riscrittura della query errata, basso recall nel recupero, reranking errato, troncamento del contesto, versioni in conflitto, fallimento della generazione, fallimento della citazione o evidenza obsoleta.

Poi scegli un test che separi quelle ipotesi. Questo è più efficiente che raccogliere altri esempi che supportano la prima spiegazione. Lo stesso principio si applica al ragionamento tecnico assistito dall'IA in generale: una diagnosi utile è quella che sopravvive a test discriminanti, non quella che suona semplicemente plausibile.

Cosa cambierebbe questa risposta?

I livelli diagnostici esatti cambiano con l'architettura. Una semplice applicazione RAG a documento singolo può non avere riscrittura della query, reranker o livello di citazione. Un sistema di recupero agentico può aggiungere pianificazione, ricerche multiple, selezione degli strumenti, memoria, permessi e raccolta iterativa di evidenze. Una ricerca in un database strutturato può non utilizzare affatto chunk o embedding.

Il metodo di base rimane valido: identificare i componenti che possono cambiare indipendentemente il risultato, costruire test controllati che sostituiscono i componenti incerti con input noti come corretti e misurare ciascun componente utilizzando evidenze appropriate a quel livello.

Limitazioni

I fallimenti reali sono spesso accoppiati. Una query debole può ridurre il recall, che cambia il reranking, che cambia il contesto, che aumenta la varianza della generazione. Il test del contesto oracolare è una scorciatoia diagnostica, non la prova che un componente sia l'unico responsabile. Anche i dataset di valutazione possono essere non rappresentativi, e i valutatori basati su modelli possono introdurre i propri errori.

Lo stack proposto è quindi meglio utilizzato come struttura di indagine: registrare la pipeline, isolare le variabili, riprodurre i fallimenti, testare spiegazioni concorrenti e mantenere la valutazione end-to-end dopo le correzioni a livello di livello.

Conclusione

"RAG ha fallito" dovrebbe essere l'inizio dell'indagine, non la conclusione. Una diagnosi utile identifica se al sistema mancava l'evidenza, ha cercato in modo errato, non è riuscito a recuperarla, l'ha classificata male, ha assemblato un contesto inutilizzabile, ha generato in modo errato, ha attribuito male le affermazioni o ha applicato evidenze al di fuori del suo confine di validità.

La regola pratica è semplice: sostituire l'incertezza con evidenze controllate un livello alla volta. Iniziare con il test del contesto oracolare. Separare la valutazione del solo recupero dalla valutazione della generazione. Conservare la traccia completa. Poi correggere il componente che ha effettivamente fallito invece di ottimizzare l'intero stack RAG per intuizione.

FAQ

Glossario

Fonti primarie e ulteriori letture