Kezhan Shi, su Towards Data Science, propone un cambio di vocabolario che ha conseguenze pratiche: nella maggior parte dei casi, quando una pipeline RAG dà una risposta sbagliata non è un’allucinazione. Un’allucinazione, in senso stretto, è una fabbricazione dalla memoria parametrica del modello. Ma nel RAG il modello legge il contesto: se la risposta è errata, la causa è a monte, nella catena di extraction (parsing, query, retrieval o il contratto di generazione). Chiamare tutto “hallucination” chiude il dibattito su dove intervenire.
La proposta è smettere di trattare la generazione come “manda i chunk più la domanda al LLM, ricevi una stringa”. La risposta non è una stringa: è un oggetto tipizzato (uno schema Pydantic) con citazioni, flag di fedeltà e campi di self-assessment. Il LLM è una funzione, non un oracolo; lo schema è il contratto e il validator gira prima che l’utente veda qualcosa. L’autore elenca sette pattern.
1) Il LLM è una funzione, non un oracolo: ogni campo dello schema è una domanda verificabile, con valore già tipizzato ed evidence che punta alla riga esatta. 2) Estrai valori tipizzati, non calcolare: il modello estrae Amount(value, currency, unit) e il calcolo lo fa Python con un tasso di cambio visibile e riproducibile. 3) Completezza dalla struttura, non dall’auto-valutazione: il retrieval tira una pagina in più e la pipeline verifica il confine di sezione, invece di chiedere al modello “la lista è completa?”. 4) Due booleani invece di un singolo float di confidence: answer_found e complete_answer_found mappano su tre azioni chiare (continuare il retrieval, spedire, rifiutare).
5) Un prompt per ogni “shape”: un dispatcher compone un prompt BASE più un frammento per tipo di risposta e registra quali frammenti ha usato, così un formato sbagliato mesi dopo resta tracciabile. 6) Niente reasoning model sull’extraction JSON: lo schema vincola già il lavoro, e il “pensiero” extra aggiunge latenza senza precisione. 7) Decomponi per i modelli piccoli: un frontier model riempie uno schema composto in una chiamata, un modello piccolo no e inventa i campi derivati. La dimensione del modello determina il numero di chiamate, non la forma dello schema.
Perché conta. Il messaggio per chi costruisce sistemi RAG in produzione è spostare l’affidabilità dal prompt al contratto: schema tipizzato, citazioni e validator deterministico rendono ogni risposta auditabile e dicono dove intervenire quando qualcosa non torna.
In sintesi
- Nel RAG l’errore è quasi sempre di extraction, non un’allucinazione: nominare la causa giusta dice dove agire.
- Il contratto è uno schema tipizzato con citazioni e self-assessment, validato prima dell’utente.
- I modelli piccoli richiedono di decomporre lo schema in stadi, con Python a fare i calcoli.
Fonte: Most RAG Hallucinations Are Extraction Errors: Seven Patterns for a Typed Generation Contract — https://towardsdatascience.com/most-rag-hallucinations-are-extraction-errors-seven-patterns-for-a-typed-generation-contract/
Hai qualcosa da aggiungere? Unisciti alla discussione.