Cos'e la RAG
La Retrieval Augmented Generation (RAG) e 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 e 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 puo 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:
Pipeline RAG in 6 step
- Ingestion: raccolta e preprocessamento dei documenti sorgente (PDF, HTML, database).
- Chunking: suddivisione dei documenti in frammenti di dimensione gestibile.
- Embedding: trasformazione dei chunk in vettori numerici tramite un modello di embedding.
- Indexing: memorizzazione dei vettori in un Vector Database.
- Retrieval: data una query, recupero dei chunk piu semanticamente simili.
- Generation: il LLM genera la risposta usando la query e i chunk recuperati come contesto.
I primi quattro step avvengono offline (fase di preparazione), mentre retrieval e generation avvengono online a ogni query dell'utente.
Chunking dei documenti
Il chunking e una fase critica che influenza direttamente la qualita del retrieval. Le strategie principali sono:
| Strategia | Descrizione | Quando usarla |
|---|---|---|
| Fixed-size | Chunk di N token/caratteri con overlap | Testi omogenei, approccio semplice |
| Sentence-based | Suddivisione per frasi naturali | Documenti narrativi, FAQ |
| Recursive | Split gerarchico (paragrafi, frasi, parole) | Approccio generale consigliato (LangChain default) |
| Semantic | Split basato su cambi di argomento (embedding similarity) | Documenti lunghi e complessi |
| Document-aware | Rispetta la struttura (heading, sezioni, tabelle) | PDF strutturati, documentazione tecnica |
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. 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.
I vettori vengono indicizzati in un vector database che supporta la ricerca per similarita 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 necessita di filtraggio ibrido.
La qualita dell'embedding model e spesso piu determinante della qualita del LLM generatore. Un retrieval scadente fornisce contesto irrilevante, e nessun LLM puo 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 similarita (tipicamente coseno) nel vector database per recuperare i top-K chunk piu 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:
Prompt template RAG (schema semplificato):
"Rispondi alla domanda dell'utente basandoti ESCLUSIVAMENTE sui seguenti documenti. Se l'informazione non e presente, dillo esplicitamente."
[Documento 1: ...] [Documento 2: ...] [Documento 3: ...]
"Domanda: {query_utente}"
L'istruzione di basarsi solo sui documenti forniti e fondamentale per ridurre le hallucination. Il LLM sintetizza le informazioni dai chunk, le combina con le proprie capacita linguistiche e produce una risposta coerente, idealmente con citazioni delle fonti.
RAG vs Fine-Tuning
RAG e Fine-Tuning sono approcci complementari, non mutuamente esclusivi:
| Aspetto | RAG | Fine-Tuning |
|---|---|---|
| Conoscenza aggiornabile | Si, basta aggiornare il DB | No, richiede ri-addestramento |
| Citabilita | Eccellente (fonti tracciabili) | Limitata |
| Costo iniziale | Basso (infrastruttura retrieval) | Alto (GPU, dataset, tempo) |
| Latenza | Piu alta (retrieval + generation) | Piu bassa (solo generation) |
| Stile/tono | Dipende dal LLM base | Personalizzabile |
| Conoscenza profonda | Limitata dai chunk recuperati | Integrata nei pesi del modello |
In pratica, molti sistemi di produzione combinano entrambi: fine-tuning per adattare stile e formato, RAG per fornire conoscenza aggiornata e specifica. 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 piu adottato per applicazioni AI enterprise. Comprenderne la pipeline end-to-end e essenziale per progettare sistemi AI affidabili e scalabili.