// data & ai · giornale tecnico MILANO ● LIVE 00:00:00

Le allucinazioni del RAG sono spesso fallimenti del retrieval

Quando un sistema RAG risponde con sicurezza ma in modo sbagliato, la causa è quasi sempre a monte: il retrieval decide cosa il modello può vedere, e quindi cosa può inventare.

Quando un sistema RAG restituisce una risposta sicura ma sbagliata, l’istinto è agire sulla generazione: prompt più severo, modello più grande, temperature a zero. Kezhan Shi, su Towards Data Science, sostiene che questo tratta un fallimento del retrieval come se fosse un fallimento della generazione. Il modello ha ricevuto le pagine sbagliate e ha fatto il suo lavoro su quelle: è il retrieval a decidere cosa il modello può vedere, e quindi cosa può inventare.

Una misurazione concreta

L’esempio usa il NIST Cybersecurity Framework v1.1, uno standard reale di 55 pagine di dominio pubblico. La pipeline naive è una dozzina di righe: embedding di ogni pagina con un sentence-transformer (all-MiniLM-L6-v2), embedding della domanda, ranking per cosine similarity, top-k. La domanda riguarda le pratiche di backup per mantenere i dati disponibili dopo un attacco ransomware; la risposta è nella subcategory PR.IP-4, a pagina 41. Il risultato: la cosine similarity classifica quella pagina 55esima su 55, l’ultima del documento. La parola “backup” compare in una sola pagina, proprio quella, ma è stata “mediata via” dal resto della domanda.

Tre condizioni di retrieval che causano allucinazioni

L’autore separa tre casi, nessuno dei quali è colpa del modello. Primo: la risposta non è stata recuperata (recall failure), il caso classico dell’invenzione sicura, ma anche il più facile da diagnosticare misurando il rank. Secondo: è stato recuperato il passaggio sbagliato, un controllo che sembra giusto (PR.DS su protezione dei dati) ma risponde a un’altra domanda; questo sopravvive alla review perché arriva con una citazione valida. Terzo: la risposta è sepolta tra distrattori, subcategory quasi identiche nella stessa tabella, e aggiungere più contesto peggiora la situazione invece di migliorarla.

Il punto è che la cosine similarity ordina per significato superficiale, un cattivo proxy per capire dove vive davvero la risposta, e un embedding più grande non risolve il problema: può anzi ordinare peggio i controlli quasi-sinonimi.

Come il retrieval ferma le allucinazioni

La correzione è nel retrieval, non in un prompt più severo, e si basa su due discipline. La prima: ancorarsi allo span giusto con segnali che sopravvivono al mismatch di vocabolario, cioè keyword matching su un dizionario validato da esperti, la struttura del documento e l’embedding come voto parallelo. Un semplice conteggio della parola “backup” per pagina porta la risposta dal rank 55 al rank 1, prima ancora che la generazione parta. La seconda: restringere il contesto alla subcategory corretta e ai suoi vicini, non all’intero framework.

  • Il retrieval decide cosa il modello può vedere: molte allucinazioni loggate come colpa del modello sono in realtà fallimenti di retrieval.
  • Le tre modalità di fallimento lasciano tracce diverse nei log; le ultime due arrivano con una citazione e passano la review.
  • Come seconda linea di difesa, un answer contract tipizzato (valore, evidence span, confidence) intercetta le risposte prive di supporto nel contesto.

Fonte: Most RAG Hallucinations Are Retrieval Failures — https://towardsdatascience.com/most-rag-hallucinations-are-retrieval-failures-how-the-retrieval-brick-decides-what-the-model-can-invent/

Condividi X Facebook LinkedIn WhatsApp Email

// scritto da

Fernando

Hai qualcosa da aggiungere? Unisciti alla discussione.

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altri dell'autore

dalla stessa firma