🧙 Maestro Yoda Cap. 22 · Agenti, tool use, RAG

Puntata 238

Puntata 238 — RAG: Retrieval-Augmented Generation

Livello: 🧙 Maestro Yoda · Capitolo 22 · Agenti, tool use, RAG

Quando un LLM non sa una cosa, può inventarla (hallucination) oppure chiederla. RAG è il pattern che gli insegna a chiederla — a un database tuo, prima di rispondere. Nel 2026 RAG è ovunque: dietro Perplexity, dentro Copilot, sotto ChatGPT che cerca sui tuoi PDF. Senza, l’LLM è un’enciclopedia chiusa al 2024.

un bibliotecario LLM seduto a una scrivania. Davanti a sé, un cassetto etichettato “knowledge interno (parametri)”. Alle spalle, scaffali con cartelli “Documenti aziendali”, “Manuali”, “FAQ”, “Codice civile”. Davanti a una domanda, il bibliotecario si volta, prende 3 libri, torna alla scrivania e risponde. Sotto: “se la risposta non sta nella tua testa, vai a cercarla — poi rispondi”

Il problema che RAG risolve

Un LLM ha due fonti di sapere:

  1. Sapere parametrico: quello “compresso” nei pesi durante il pretraining (knowledge cutoff incluso).
  2. Sapere in context: quello presente nel prompt corrente.

Limiti del sapere parametrico:

  • Knowledge cutoff (es. Llama 3.1: luglio 2024).
  • Niente dati privati/aziendali (mai visti).
  • Hallucination su fatti specifici (dati specifici → confabulation).
  • Non aggiornabile senza ri-addestramento.

RAG: prima di rispondere, recupera documenti rilevanti da una knowledge base esterna, e li inserisce nel context. Il modello risponde “basandosi su” quei documenti.

Risultato:

  • Knowledge always fresh (basta aggiornare il DB).
  • Knowledge privata possibile (i tuoi PDF aziendali).
  • Citation-able (mostri da dove arriva la risposta).
  • Niente fine-tuning richiesto.

La pipeline RAG base

1. INDEXING (offline, una volta o periodicamente)
   docs → chunk → embed → store in vector DB

2. QUERY (online, per ogni request)
   query → embed → similarity search → top-k chunks → inject in prompt → LLM → response

Indexing step-by-step

  1. Raccogli i documenti (PDF, HTML, MD, DB).
  2. Chunking (puntata 241): spezza in pezzi di 200-1000 token.
  3. Embedding (puntata 240): converti ogni chunk in un vettore.
  4. Store: salva in vector DB (puntata 239) o pgvector.

Query step-by-step

  1. Ricevi la query dell’utente.
  2. Embedding della query (stesso modello del 3 sopra).
  3. Similarity search: trovi i top-k chunk col vettore più simile (cosine similarity tipica).
  4. Inject: costruisci un prompt tipo: 
    Rispondi alla domanda basandoti SOLO sui seguenti documenti.
Se la risposta non è nei documenti, dì "non lo so".

Documenti:
[Doc 1: ...]
[Doc 2: ...]
[Doc 3: ...]

Domanda: {query}
  5. LLM risponde, citando opzionalmente i Doc usati.

Quando RAG serve davvero

Use case in cui RAG vince:

  • Knowledge specifica e aggiornata: docs aziendali, ticket support, manualistica.
  • Citazioni richieste: legale, medico, ricerca scientifica.
  • Knowledge troppo grande per il context: 10,000 PDF non li metti tutti in 200k token.
  • Knowledge che cambia spesso: aggiornare il DB è O(1), retraining è O(M$$$).
  • Multi-tenant: ogni cliente ha la sua knowledge base separata.

Quando RAG NON serve (overkill)

  • Knowledge piccola e statica (poche pagine): metti tutto in context, basta long context (1M token).
  • Knowledge già nel training data: domande generali (matematica, programmazione, lingue) → il modello le sa.
  • Task in cui il context lungo basta: long context model + un solo documento, non serve retrieval.
  • Task che richiedono ragionamento più che retrieval: matematica, logica, planning.

Anti-pattern 2024-25: “facciamo RAG perché si fa”. Risultato: pipeline complessa per risolvere problemi che un GPT-5 con context a 200k risolveva direttamente.

Il problema della retrieval quality

Il punto debole di RAG: se il retrieval sbaglia, l’LLM non può salvare. Se i top-5 chunk non contengono la risposta, l’LLM o ammette di non sapere (best case) o inventa (worst case).

Metriche di retrieval:

  • Recall@k: % di volte che il chunk giusto è nei top-k.
  • MRR (Mean Reciprocal Rank): 1/posizione del primo chunk corretto.
  • NDCG: rank quality pesato.

Per use case business: recall@5 ≥ 90% è il minimo accettabile. Sotto, hai un sistema che hallucinerà spesso.

Patterns per aumentare retrieval quality

Dense + sparse: combini embedding similarity (semantic) con BM25 keyword search (lexical). Recupera sia “concetti vicini” che “parole esatte”. Migliora recall del 10-30% su benchmark.

b) Reranking

Stage 2 in cui prendi i top-50 da retrieval e li riordini con un modello più costoso ma più accurato (cross-encoder, es. bge-reranker, Cohere Rerank). Migliora ordine dei top-5.

c) Query rewriting

L’LLM riformula la query utente prima di fare retrieval. Es. “Cosa dice il GDPR su deepfake?” → “GDPR articoli su deepfake immagini sintetiche persone fisiche”. Migliora match.

d) Query expansion

Generi N varianti della query (sinonimi, riformulazioni) e fai retrieval per ognuna, fondendo i risultati.

e) HyDE (Hypothetical Document Embeddings)

L’LLM genera una “risposta ipotetica” alla query, e poi fai retrieval cercando documenti simili a quella risposta (invece che alla query). Migliora su query lunghe/complesse.

f) Multi-hop retrieval

Per domande che richiedono info da più documenti: prima retrieval → riformula sotto-query → retrieval per ognuna → componi.

Patterns avanzati 2026

Agentic RAG

L’LLM è un agente con tool search_kb(query). Decide quando e come fare retrieval, non è forzato a ogni request. Più flessibile, miglior qualità su query complesse, ma più latency.

GraphRAG (Microsoft, 2024)

Costruisce un knowledge graph dai documenti (entities + relations) durante l’indexing. La query traversa il grafo + retrieval testuale. Forte su domande che richiedono “fatti correlati” (es. “chi ha lavorato con chi”). Costoso in indexing.

RAG con cache semantica

Se la stessa query (o semanticamente simile) viene posta, riusi la risposta cache senza retrieval. Speedup 10-50×, costo / 5-20×. Tool: Helicone Cache, Portkey, GPTCache.

Multimodal RAG

Indici anche immagini (es. tabelle, schemi). Embedding multimodale (CLIP, NomicEmbed) per match testo→immagine. Stato dell’arte ma fragile.

Long-context-as-RAG (Anthropic, Google)

Con context da 1M-2M token (Gemini, Claude), inserisci tutto il documento (anche 1000 pagine) e fai prompt caching. Bypassi retrieval. Eccellente quando applicabile.

Eval di un sistema RAG

Due eval indipendenti:

1. Retrieval eval

Dataset di (query, chunk_id_giusto). Misuri recall@k, MRR.

2. End-to-end eval

Dataset di (query, risposta_attesa). Misuri:

  • Faithfulness: la risposta è supportata dai chunk recuperati?
  • Answer correctness: matcha la risposta gold?
  • Citation accuracy: cita correttamente i chunk?

Tool open: RAGAS (ragas.io), TruLens, Phoenix Evals, DeepEval.

Pattern critico: valuta su query reali tue, non su benchmark generici. Le query del tuo dominio hanno pattern specifici che benchmark generici non catturano.

Architettura RAG tipica 2026

[App frontend]
     ↓
[FastAPI/Express backend]
     ↓
[Query rewrite + expansion]
     ↓
[Hybrid search]
   ├── Vector DB (Qdrant/pgvector) — semantic
   └── Elasticsearch/Tantivy — BM25 lexical
     ↓
[Reranker (bge-reranker / Cohere)]
     ↓
[Top-5 chunks + system prompt + query]
     ↓
[LLM (Claude/GPT/Llama)]
     ↓
[Response + citations]
     ↓
[Logging (Langfuse) + eval async]

Complesso? Sì. Worthy? Dipende dal volume e dalla criticità. Per <1000 docs e <10 query/giorno, una pipeline naive basta. Per 100k+ docs e 10k+ query/giorno, tutta l’architettura sopra ha senso.

RAG vs Fine-tuning: il dibattito chiuso (quasi)

Domanda eterna 2023-25: “meglio RAG o fine-tuning per la mia knowledge?”.

Consenso 2026:

  • Conoscenza fattuale (chi/cosa/quando) → RAG. FT non insegna fatti specifici, insegna pattern. Tentare di “infilare” 1000 PDF in FT è inefficiente.
  • Stile, tono, format, capacità task-specifica → FT (vedi puntata 230). RAG non cambia come il modello scrive.
  • Combinati: FT per “agire come Y” + RAG per “sapere X”. È il pattern più potente.

Esempio: chatbot legale = FT su 5k Q&A per stile italiano legale + RAG su Codice Civile per fatti.

Limiti onesti di RAG (2026)

  1. Comprende solo quello che recuperi: se il chunk giusto è in un PDF non indicizzato, l’LLM hallucina.
  2. Chunking matters enormemente (puntata 241): chunk mal fatti = recall basso.
  3. Embedding model conta (puntata 240): un embedding generico in italiano fa peggio di uno multilingua.
  4. Latency: aggiungi 100-500 ms di retrieval + reranking per ogni request.
  5. Costo embedding: ad ogni nuovo doc, costo di embedding (cents per migliaio per modelli managed, gratis per open).
  6. Privacy: i chunk passano nel context del LLM provider. Se è un provider closed, sei OK con i loro DPA?

Glossario lampo

  • RAG (Retrieval-Augmented Generation) — pattern: retrieval dalla knowledge base esterna → inject nel prompt → generation. Lewis et al., FAIR, 2020.
  • Recall@k — % di volte che il documento “giusto” è nei primi k risultati di retrieval.
  • Reranker — modello secondario, più accurato e più lento, che riordina i top-N chunk dopo retrieval iniziale.
  • HyDE — Hypothetical Document Embeddings: usi una risposta sintetica per fare retrieval invece della query.
  • GraphRAG — RAG basato su knowledge graph + retrieval testuale, forte su domande che richiedono “fatti correlati”.
  • Agentic RAG — RAG in cui un agente decide quando e come fare retrieval, invece di farlo per ogni request.

Take-away

RAG è il modo standard del 2026 per dare a un LLM accesso a knowledge fresca, privata, citabile. Non è magia: è una pipeline con 5-7 stage in cui ogni stage può fallire. Il successo dipende meno dal modello e più dalla disciplina del retrieval: chunking, embeddings, hybrid search, reranking, eval. Se vuoi che un LLM “sappia dei tuoi PDF”, RAG è la prima cosa da provare. Long context è la seconda. Fine-tuning è la terza (e raramente la migliore).

➡️ Prossima puntata: vector database — Pinecone, Weaviate, pgvector, Qdrant.