RAG: Retrieval Augmented Generation

Cos'è la RAG

La Retrieval Augmented Generation (RAG) è l'architettura descritta da Lewis e colleghi nel 2020: si mette davanti al modello un pezzo che recupera informazioni, e gli si passano i documenti utili dentro al prompt. L'idea è semplice e cambia tutto: invece di fidarsi di quello che il modello ha memorizzato in addestramento, gli si dà da leggere la fonte giusta al momento della domanda.

Risolve tre problemi che nell'uso vero si presentano subito:

• Conoscenza obsoleta: il modello ha una data di cutoff; la RAG accede a dati aggiornati in tempo reale.
• Hallucination: il modello può inventare fatti; con la RAG le risposte sono ancorate a documenti reali e citabili.
• Conoscenza di dominio: dati proprietari o specialistici non presenti nel training set diventano accessibili.

Architettura della pipeline

Una pipeline RAG ha due grandi fasi, ognuna con i suoi passaggi:

I primi quattro passaggi si fanno una volta sola, in preparazione; recupero e generazione avvengono a ogni domanda. La differenza è pratica: l'indicizzazione costa tempo e calcolo e la fai la notte, mentre la parte che l'utente aspetta va tenuta veloce. Nel marketing e nell'assistenza clienti è quello che ti permette di avere un chatbot che conosce catalogo, listini e FAQ aggiornati senza riaddestrare niente: cambi il documento e da quel momento risponde in modo diverso.

Chunking dei documenti

Il chunking, cioè come tagli i documenti, è il passaggio che decide la qualità di tutto il resto, e quello su cui si perde più tempo a tentativi:

Una dimensione tipica va da 256 a 1024 token per chunk, con un overlap del 10-20% per preservare il contesto ai confini. Chunk troppo piccoli perdono contesto; troppo grandi diluiscono la rilevanza e consumano context window. In pratica conviene partire dalla strategia recursive, misurare la qualità delle risposte su un set di domande reali e poi affinare dimensione e overlap: non esiste un valore universale, dipende dalla densità informativa dei documenti. Per approfondire il concetto di token, si veda l'articolo su Token e Tokenizzazione.

Embedding e indexing

Ogni chunk viene trasformato in un vettore denso (tipicamente 768-1536 dimensioni) tramite un modello di embedding. Modelli popolari includono OpenAI text-embedding-3-large, Cohere embed-v3 e modelli open-source come BGE e E5. La regola d'oro è usare lo stesso modello di embedding sia in fase di indicizzazione sia in fase di query: vettori prodotti da modelli diversi non sono confrontabili e degraderebbero la ricerca.

I vettori vengono indicizzati in un vector database che supporta la ricerca per similarità efficiente tramite algoritmi come HNSW (Hierarchical Navigable Small World) o IVF (Inverted File Index). La scelta del database (Pinecone, Weaviate, Chroma, Qdrant, pgvector) dipende da fattori come scala, latenza, costo e necessità di filtraggio ibrido. Per progetti piccoli o prototipi, una soluzione locale come Chroma è sufficiente; per cataloghi con milioni di documenti e requisiti di alta disponibilità conviene un servizio gestito.

La qualità dell'embedding model è spesso più determinante della qualità del LLM generatore. Un retrieval scadente fornisce contesto irrilevante, e nessun LLM può generare una buona risposta da premesse sbagliate.

Fase di Retrieval

Quando l'utente invia una query, essa viene trasformata in un vettore con lo stesso modello di embedding usato per i chunk. Si esegue poi una ricerca di similarità (tipicamente coseno) nel vector database per recuperare i top-K chunk più rilevanti (solitamente K = 3-10).

Tecniche di recupero più avanzate:

• Hybrid search: combina ricerca semantica (vettoriale) con ricerca lessicale (BM25) per catturare sia corrispondenze concettuali che esatte.
• Re-ranking: un modello cross-encoder ri-ordina i risultati per migliorare la precisione (es. Cohere Rerank).
• Query expansion: il LLM riformula o espande la query originale per migliorare il retrieval.
• HyDE (Hypothetical Document Embeddings): si genera prima un documento ipotetico di risposta e si usa il suo embedding per il retrieval.

Fase di Generation

I chunk recuperati vengono inseriti nel prompt del LLM, tipicamente in un formato come:

L'istruzione «rispondi solo con quello che trovi nei documenti» è quella che tiene a bada le invenzioni, e va messa sempre. Il modello prende i pezzi recuperati e li mette insieme in una risposta leggibile, meglio se con le fonti accanto. La pratica che consiglio è chiedere per ogni affermazione da quale documento arriva: la risposta diventa verificabile, e in un contesto professionale è la differenza fra uno strumento che puoi usare con un cliente e un giocattolo.

RAG vs Fine-Tuning

RAG e fine-tuning rispondono a domande diverse:

In pratica, molti sistemi di produzione combinano entrambi: fine-tuning per adattare stile e formato, RAG per fornire conoscenza aggiornata e specifica. La regola pratica è semplice: se il problema riguarda cosa il modello deve sapere, si usa la RAG; se riguarda come il modello deve rispondere (tono, formato, terminologia di settore), si valuta il fine-tuning. Per comprendere meglio le hallucination e altri problemi dei LLM che la RAG aiuta a mitigare, consulta Errori Comuni nell'AI.

La RAG è l'architettura che vedo funzionare più spesso nei progetti veri, e il motivo è prosaico: quando il documento cambia, aggiorni il documento. Con il fine-tuning riapri il cantiere.