RAG — Retrieval Augmented Generation

Cos'è la RAG

La Retrieval Augmented Generation (RAG) è un paradigma architetturale introdotto da Lewis et al. (2020) che combina un componente di retrieval (recupero di informazioni) con un generatore (Large Language Model). L'idea fondamentale è semplice ma potente: invece di affidarsi esclusivamente alla conoscenza memorizzata nei parametri del modello durante il pre-training, si recuperano documenti rilevanti da una base di conoscenza esterna e li si inseriscono nel contesto del prompt.

Questo approccio risolve tre problemi critici dei LLM tradizionali:

• 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 si compone di due macro-fasi, ciascuna con sottostep ben definiti:

I primi quattro step avvengono offline (fase di preparazione), mentre retrieval e generation avvengono online a ogni query dell'utente. Questa separazione ha implicazioni pratiche concrete: l'indicizzazione, costosa in termini di tempo e calcolo, viene eseguita una sola volta e aggiornata in modo incrementale quando i documenti cambiano, mentre la parte online deve essere ottimizzata per la latenza percepita dall'utente. Nel marketing e nell'assistenza clienti, ad esempio, questo consente di alimentare un chatbot con cataloghi, listini e FAQ sempre aggiornati senza riaddestrare il modello.

Chunking dei documenti

Il chunking è una fase critica che influenza direttamente la qualità del retrieval. Le strategie principali sono:

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 avanzate di retrieval includono:

• 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 di basarsi solo sui documenti forniti è fondamentale per ridurre le hallucination. Il LLM sintetizza le informazioni dai chunk, le combina con le proprie capacità linguistiche e produce una risposta coerente, idealmente con citazioni delle fonti. Una buona pratica è chiedere al modello di indicare per ogni affermazione il documento di origine: questo rende la risposta verificabile e aumenta la fiducia dell'utente, un aspetto decisivo in contesti professionali come consulenza, supporto normativo o assistenza tecnica.

RAG vs Fine-Tuning

RAG e Fine-Tuning sono approcci complementari, non mutuamente esclusivi:

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 rappresenta oggi il pattern architetturale più adottato per applicazioni AI enterprise. Comprenderne la pipeline end-to-end è essenziale per progettare sistemi AI affidabili e scalabili.