Definizione
Retrieval-Augmented Generation (RAG) è un pattern architetturale che combina un sistema di information retrieval con un LLM generativo. Invece di affidarsi solo alla conoscenza parametrica del modello, RAG recupera documenti rilevanti da una knowledge base e li passa come contesto al LLM per generare risposte fondate.
Il pattern risolve due limiti degli LLM: la knowledge cutoff (il modello non conosce informazioni successive al training) e le hallucination (il modello inventa fatti plausibili ma falsi).
Come funziona
Il flusso base di un sistema RAG:
-
Indexing (offline): i documenti vengono segmentati in chunk, convertiti in embedding e salvati in un vector database
-
Retrieval (runtime): la query dell’utente viene convertita in embedding e usata per recuperare i chunk più simili (tipicamente top-k per cosine similarity)
-
Augmentation: i chunk recuperati vengono inseriti nel prompt come contesto
-
Generation: il LLM genera una risposta basandosi sul contesto fornito
Varianti architetturali
Naive RAG: il flusso base descritto sopra. Semplice da implementare, ma con limiti su query complesse.
Advanced RAG: aggiunge pre-retrieval (query rewriting, HyDE) e post-retrieval (reranking, filtering) per migliorare la qualità.
Modular RAG: componenti intercambiabili (retriever, reranker, generator) per ottimizzazione task-specific.
Agentic RAG: il LLM decide dinamicamente quando e cosa recuperare, con loop iterativi di retrieval-reasoning.
Metriche di valutazione
Retrieval quality:
- Precision@k: quanti documenti recuperati sono rilevanti
- Recall@k: quanti documenti rilevanti sono stati recuperati
- MRR (Mean Reciprocal Rank): posizione media del primo risultato rilevante
Generation quality:
- Faithfulness: la risposta è supportata dai documenti?
- Answer relevance: la risposta risponde alla domanda?
- Context relevance: i documenti recuperati sono pertinenti?
Framework come RAGAS automatizzano queste valutazioni.
Considerazioni pratiche
Chunking: la segmentazione dei documenti influenza la qualità del retrieval quanto la scelta dell’embedding model. Chunk troppo piccoli perdono contesto, troppo grandi diluiscono il segnale. Strategie comuni: fixed-size con overlap, semantic chunking, document-structure-aware.
Numero di chunk (k): più chunk forniscono più contesto ma aumentano costo, latenza e rischio di confondere il modello. Valori tipici: 3-10, da ottimizzare empiricamente.
Costi: il costo principale è nel LLM (i chunk vanno nel prompt). Con context window grandi e molti chunk, i costi scalano rapidamente.
Quando usare RAG vs alternative
RAG è indicato quando:
- La knowledge base cambia frequentemente
- Serve citare fonti specifiche
- Il corpus è troppo grande per il fine-tuning
- Serve combinare conoscenza parametrica e documentale
Alternative da considerare:
- Fine-tuning: per knowledge statica e task ben definiti
- Long-context models: per corpus piccoli che entrano nel context window
- Hybrid: fine-tuning + RAG per combinare i vantaggi
Fraintendimenti comuni
”RAG elimina le hallucination”
Riduce, non elimina. Il modello può ancora ignorare il contesto, interpretarlo male, o sintetizzare informazioni non presenti. Servono guardrail e valutazione.
”Basta un vector database e funziona”
Il retrieval è solo una parte. Chunking strategy, embedding model, reranking, prompt engineering sono tutti fattori critici. Un RAG mal configurato performa peggio di un LLM vanilla.
”Più documenti = risposte migliori”
No. Troppo contesto può confondere il modello (“lost in the middle” problem) e aumenta costi. La qualità del retrieval batte la quantità.
Termini correlati
- Embeddings: rappresentazioni vettoriali per il retrieval
- Vector Database: storage per embedding e similarity search
- LLM: componente generativo del sistema RAG
- Hallucination: problema che RAG mitiga parzialmente
Fonti
- Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS
- Es, S. et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. arXiv
- Gao, Y. et al. (2024). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv