RAG: anatomia di un'architettura

Introduzione: il ponte tra generazione e realtà

I Large Language Model sono straordinari nel generare testo fluido, coerente e apparentemente competente. Ma hanno un problema fondamentale: non sanno quello che non sanno. La loro conoscenza è congelata al momento dell'addestramento, e quando non trovano un pattern statistico adeguato, inventano. Con grande sicurezza.

Per le aziende che vogliono usare l'AI su documenti interni, normative aggiornate, cataloghi prodotti o basi di conoscenza proprietarie, questo è un problema bloccante. Non basta un modello brillante: serve un modello che sappia dove cercare le risposte prima di generarle.

La Retrieval-Augmented Generation — RAG — è la risposta architetturale a questo problema. Non è un singolo algoritmo, ma un paradigma progettuale: prima cerca, poi genera. Un ponte tra il mondo dei motori di ricerca e quello dei modelli generativi, progettato per ancorare le risposte dell'AI a fonti documentali verificabili.

In questo articolo esploreremo ogni componente dell'architettura RAG, dalla teoria agli errori pratici più comuni, con l'obiettivo di fornire una mappa completa a chi vuole progettare, valutare o semplicemente comprendere questi sistemi.

Il problema delle allucinazioni

Per capire perché la RAG è necessaria, bisogna prima capire perché i Large Language Model sbagliano. E non sbagliano come sbaglierebbe un essere umano — per distrazione o ignoranza consapevole — ma in un modo strutturalmente diverso: generano la sequenza di token più probabile, indipendentemente dalla sua veridicità.

La natura statistica della generazione

Un LLM non “sa” che Roma è la capitale d'Italia. Ha semplicemente osservato, durante l'addestramento, che dopo la sequenza “la capitale d'Italia è” il token “Roma” compare con altissima probabilità. Quando questa correlazione statistica funziona, il risultato sembra intelligenza. Quando non funziona — perché i dati di training erano incompleti, contraddittori o assenti — il modello produce comunque una risposta, semplicemente meno affidabile. Ma con la stessa sicurezza.

Questo fenomeno si chiama allucinazione: il modello genera informazioni plausibili ma false. Citazioni di libri mai scritti, statistiche inventate, riferimenti normativi inesistenti, date errate. Il tutto con una prosa fluida e convincente che rende l'errore particolarmente insidioso.

Perché il fine-tuning non basta

Una prima reazione naturale è: “addestriamo il modello sui nostri dati”. Il fine-tuning è utile per insegnare al modello uno stile, un formato o un dominio specifico, ma presenta limiti strutturali:

• Conoscenza statica: dopo il fine-tuning, le informazioni restano congelate. Se un documento viene aggiornato, serve un nuovo ciclo di addestramento.
• Costo elevato: il fine-tuning richiede GPU, tempo, competenze e un processo di validazione rigoroso.
• Nessuna tracciabilità: non c'è modo di sapere da quale documento proviene una specifica risposta. Il modello ha “assorbito” i dati nei suoi pesi, ma non può citare la fonte.
• Rischio di overfitting: su dataset piccoli, il modello può memorizzare invece di generalizzare.

La necessità del grounding

Quello che serve è un meccanismo di grounding: ancorare ogni risposta generata a fonti documentali concrete e verificabili. L'utente deve poter risalire al paragrafo esatto da cui proviene un'informazione. Il sistema deve poter dire “non ho trovato informazioni pertinenti” invece di inventare.

La RAG nasce precisamente per questo: non per sostituire la capacità generativa del modello, ma per nutrirla con informazioni reali, aggiornate e tracciabili.

L'architettura RAG

Il termine Retrieval-Augmented Generation è stato formalizzato nel 2020 da Patrick Lewis e colleghi in un paper di riferimento pubblicato da Facebook AI Research (oggi Meta AI). L'intuizione fondamentale è semplice: dare al modello generativo accesso a una memoria esterna interrogabile.

L'architettura si articola in tre fasi principali, ciascuna con le proprie sfide tecniche e scelte progettuali.

Il pipeline nel dettaglio

Ecco il flusso completo di un sistema RAG dalla ricezione della domanda alla risposta finale:

1. 1L'utente pone una domanda in linguaggio naturale al sistema.
2. 2La query viene trasformata in un vettore (embedding) usando lo stesso modello utilizzato per indicizzare i documenti.
3. 3Il vettore della query viene confrontato con i vettori dei frammenti documentali nel database vettoriale tramite una metrica di similarità.
4. 4I frammenti più rilevanti (tipicamente i top-k, dove k va da 3 a 10) vengono estratti dal database.
5. 5I frammenti vengono inseriti nel prompt del modello generativo come contesto, insieme alla domanda originale e alle istruzioni di sistema.
6. 6Il modello genera la risposta basandosi sul contesto fornito, idealmente citando o parafrasando le fonti.

Embedding e spazi vettoriali

Il cuore di qualsiasi sistema RAG è la capacità di trasformare il testo in numeri che ne catturino il significato. Questo processo si chiama embedding e rappresenta forse il concetto più importante dell'intera architettura.

Come il testo diventa un vettore

Un modello di embedding prende una sequenza di testo — una frase, un paragrafo, un frammento di documento — e produce un vettore: una lista ordinata di numeri (tipicamente da 384 a 1536 dimensioni). Ogni dimensione cattura un aspetto del significato.

L'analogia più efficace è quella delle coordinate GPS per il significato. Come le coordinate geografiche collocano un punto sulla superficie terrestre, un vettore di embedding colloca un concetto in uno spazio semantico multidimensionale. Testi con significato simile avranno coordinate vicine; testi con significato diverso saranno distanti.

Modelli di embedding

Non tutti i modelli di embedding sono uguali. La scelta del modello influenza direttamente la qualità del retrieval:

• Sentence-Transformers: famiglia di modelli open-source ottimizzati per la similarità semantica a livello di frase. Modelli come all-MiniLM-L6-v2 offrono un buon compromesso tra qualità e velocità.
• OpenAI Embeddings: modelli come text-embedding-3-small e text-embedding-3-large offrono alte prestazioni tramite API cloud.
• Cohere Embed: modelli multilingue progettati specificamente per il retrieval.
• BGE e E5: modelli open-source di nuova generazione che competono con le soluzioni proprietarie.

Similarità coseno

Per confrontare due vettori si usa tipicamente la similarità coseno (cosine similarity): una misura che calcola l'angolo tra due vettori nello spazio multidimensionale. Un valore di 1 indica identità semantica perfetta, 0 indica assenza di relazione, -1 indica significato opposto.

La formula è elegantemente semplice: il prodotto scalare dei due vettori diviso per il prodotto delle loro norme. Ma la sua potenza sta nel fatto che ignora la “lunghezza” dei vettori (ciòè la quantità di testo) e si concentra sulla “direzione” (ciòè il significato).

Database vettoriali

Una volta generati, i vettori devono essere archiviati e interrogabili in modo efficiente. Qui entrano in gioco i database vettoriali:

Chunking: spezzare i documenti

Un documento intero — un PDF di 50 pagine, un manuale tecnico, un contratto — non può essere trasformato in un singolo vettore di embedding. I modelli di embedding hanno un limite di token in input (tipicamente 256–512 token) e, anche quando accettano input più lunghi, la qualità della rappresentazione degrada: troppa informazione compressa in un unico vettore produce un embedding “annacquato” che non cattura bene nessun concetto specifico.

Per questo i documenti vengono spezzati in frammenti (chunks) prima dell'indicizzazione. La strategia di chunking è una delle decisioni progettuali più critiche in un sistema RAG.

Strategie di chunking

• Fixed-size chunking: il testo viene diviso in blocchi di dimensione fissa (es. 500 token). Semplice da implementare, ma può spezzare frasi a metà o separare concetti correlati.
• Sentence-based chunking: la divisione avviene ai confini delle frasi. Preserva l'integrità sintattica ma produce frammenti di dimensione variabile.
• Semantic chunking: usa un modello di embedding per identificare i punti in cui il significato cambia, creando frammenti semanticamente coerenti. Più costoso ma più efficace.
• Recursive chunking: tenta la divisione usando prima i separatori più grandi (paragrafi), poi quelli più piccoli (frasi, parole) solo se necessario. È la strategia usata da LangChain per default.

Il ruolo dell'overlap

Quasi tutte le strategie prevedono un overlap (sovrapposizione) tra chunk consecutivi: gli ultimi N token di un chunk vengono ripetuti all'inizio del successivo. Questo serve a preservare il contesto ai confini: se un concetto si trova a cavallo di due frammenti, l'overlap garantisce che almeno uno dei due lo contenga interamente.

L'overlap tipico va dal 10% al 20% della dimensione del chunk. Troppo poco e si perdono informazioni ai confini; troppo e si spreca spazio di archiviazione e si introduce rumore nel retrieval.

Retrieval: trovare l'informazione giusta

Il retrieval è il momento decisivo dell'intero pipeline. Se il sistema recupera i frammenti sbagliati, nessun modello generativo, per quanto potente, potrà produrre una risposta corretta. È il principio garbage in, garbage out applicato all'AI generativa.

Dense retrieval vs sparse retrieval

Esistono due paradigmi fondamentali per cercare informazioni in una collezione di documenti:

Ricerca ibrida

La soluzione più efficace nella pratica è la ricerca ibrida (hybrid search): combinare i risultati del dense retrieval e dello sparse retrieval, tipicamente con una fusione pesata dei punteggi (Reciprocal Rank Fusion o semplice media pesata). Questo permette di sfruttare la comprensione semantica dei modelli neurali e la precisione lessicale di BM25.

Re-ranking

Dopo il retrieval iniziale, un passaggio di re-ranking può migliorare significativamente la qualità dei risultati. Un modello di re-ranking (come Cohere Rerank o un cross-encoder) prende la query e ciascun frammento candidato, li analizza congiuntamente e produce un punteggio di rilevanza più accurato.

Il re-ranking è più lento del retrieval iniziale (perché analizza coppie query-documento invece di fare semplici confronti vettoriali), ma applicato ai top-20 o top-50 risultati del primo stadio, il costo computazionale resta contenuto e il guadagno in qualità è sostanziale.

Generazione aumentata

Una volta che il retrieval ha identificato i frammenti più pertinenti, questi vengono “iniettati” nel prompt del modello generativo come contesto. È qui che avviene la vera “augmentation”: il modello non genera più dal nulla, ma a partire da informazioni concrete.

Come il contesto entra nel prompt

Un prompt RAG tipico ha questa struttura logica:

1. 1System prompt: istruzioni che definiscono il comportamento del modello (“Rispondi solo basandoti sul contesto fornito. Se non trovi l'informazione, dillo esplicitamente.”)
2. 2Contesto recuperato: i frammenti documentali, tipicamente preceduti da un'etichetta (“Contesto:”) e separati da delimitatori.
3. 3Domanda dell'utente: la query originale.
4. 4Istruzione finale: eventuali vincoli aggiuntivi sul formato della risposta (“Cita le fonti tra parentesi quadre.”)

Gestione della finestra di contesto

Ogni modello ha un limite alla quantità di testo che può elaborare simultaneamente (la context window). Se i frammenti recuperati sono troppi o troppo lunghi, rischiano di non entrare nella finestra, o di spingere fuori la domanda dell'utente e le istruzioni di sistema.

La gestione della finestra di contesto richiede un equilibrio attento:

• Troppo contesto produce risposte vaghe (il modello non sa su cosa concentrarsi).
• Troppo poco contesto produce risposte incomplete o allucinazioni.
• Il contesto più rilevante dovrebbe trovarsi all'inizio o alla fine del prompt (effetto “lost in the middle” documentato dalla ricerca).

Fedeltà vs creatività

Nella RAG esiste una tensione fondamentale tra faithfulness (fedeltà al contesto fornito) e creatività (capacità di sintetizzare, riformulare, connettere). Un sistema RAG per un chatbot di assistenza legale deve essere rigidamente fedele; un sistema RAG per un assistente di ricerca può permettersi più libertà nella sintesi.

Il parametro di temperature del modello, le istruzioni nel system prompt e la qualità del contesto recuperato sono le tre leve principali per calibrare questo equilibrio.

Valutare un sistema RAG

Costruire un sistema RAG è relativamente semplice. Costruire un sistema RAG che funzioni bene è enormemente più difficile. E la differenza sta nella capacità di misurare.

Le metriche fondamentali

La valutazione di un sistema RAG richiede metriche su più livelli:

• Faithfulness (fedeltà): la risposta generata è coerente con il contesto recuperato? Il modello ha inventato informazioni non presenti nei documenti?
• Answer Relevance (pertinenza della risposta): la risposta risponde effettivamente alla domanda posta?
• Context Relevance (pertinenza del contesto): i frammenti recuperati sono davvero pertinenti alla domanda? Questa metrica valuta la qualità del retrieval, non della generazione.
• Answer Correctness (correttezza): la risposta è fattualmente corretta rispetto a una ground truth nota?

Il framework RAGAS

RAGAS (Retrieval Augmented Generation Assessment) è un framework open-source che automatizza la valutazione di sistemi RAG. Usa un LLM come “giudice” per valutare ciascuna delle metriche sopra, senza bisogno di annotazioni umane per ogni singola domanda.

Il framework genera punteggi da 0 a 1 per faithfulness, answer relevance, context precision e context recall, permettendo di identificare rapidamente dove il sistema fallisce: se il problema è nel retrieval o nella generazione.

Valutazione umana

La valutazione umana è il gold standard ma anche la più costosa. Tipicamente si procede con:

• Un set di domande di test rappresentative del dominio.
• Risposte di riferimento (ground truth) validate da esperti.
• Valutatori umani che giudicano correttezza, completezza e utilità.
• Metriche di inter-annotator agreement per garantire la coerenza tra valutatori.

La combinazione di valutazione automatica per le iterazioni quotidiane e valutazione umana per i rilasci principali è l'approccio più pragmatico.

Errori comuni e soluzioni

Dopo aver progettato, implementato e valutato decine di sistemi RAG, alcuni errori ricorrono con prevedibile regolarità. Ecco i più comuni e le relative contromisure.

1. Chunking inadeguato

Errore: usare chunk troppo grandi (“tanto il contesto è ampio”) o troppo piccoli (“così sono più precisi”) senza testare l'impatto sul retrieval.

Soluzione: sperimentare con dimensioni diverse (256, 512, 1024 token) sullo stesso set di domande di test. Misurare la context relevance per ogni configurazione.

2. Modello di embedding sbagliato

Errore: usare un modello di embedding generico per un dominio altamente specializzato (es. testi legali, documentazione medica).

Soluzione: valutare modelli di embedding specifici per il dominio o effettuare fine-tuning dell'embedding model. Verificare che il modello supporti adeguatamente la lingua dei documenti.

3. Assenza di re-ranking

Errore: fidarsi ciecamente dei risultati del retrieval iniziale senza un secondo stadio di riordino.

Soluzione: aggiungere un re-ranker (anche leggero) dopo il retrieval. Il miglioramento è quasi sempre significativo, specialmente su query ambigue.

4. Context overflow

Errore: inserire troppi frammenti nel prompt, saturando la finestra di contesto e causando l'effetto “lost in the middle”.

Soluzione: limitare il numero di frammenti (3–5 è spesso sufficiente). Posizionare i frammenti più rilevanti all'inizio e alla fine del contesto.

5. Ignorare i metadati

Errore: indicizzare solo il testo, senza conservare metadati come la data del documento, l'autore, la sezione di appartenenza o il tipo di documento.

Soluzione: arricchire ogni chunk con metadati strutturati e usare il filtraggio per metadati nel retrieval. Se l'utente chiede “la normativa più recente”, il sistema deve poter filtrare per data.

6. Nessuna strategia di fallback

Errore: non gestire il caso in cui il retrieval non trova risultati pertinenti. Il modello genera comunque una risposta, ma senza contesto valido: il risultato è un'allucinazione.

Soluzione: definire una soglia minima di similarità. Se nessun frammento supera la soglia, il sistema deve rispondere “Non ho trovato informazioni pertinenti nella base documentale” invece di inventare.

Il futuro della RAG

L'architettura RAG è giovane — il paper fondante ha solo pochi anni — e il campo sta evolvendo rapidamente. Diverse direzioni di ricerca stanno ampliando le capacità e i limiti del paradigma.

Agentic RAG

Nella RAG tradizionale, il flusso è lineare: query, retrieval, generazione. Nella Agentic RAG, il modello può decidere autonomamente se e quando fare retrieval, riformulare la query se i primi risultati non sono soddisfacenti, combinare informazioni da fonti diverse e persino verificare la coerenza della propria risposta. L'agente diventa un ricercatore attivo, non un semplice consumatore di contesto.

GraphRAG

GraphRAG, introdotto da Microsoft Research, sostituisce (o affianca) il database vettoriale con un grafo della conoscenza. Invece di cercare frammenti di testo simili, il sistema naviga relazioni strutturate tra entità (persone, organizzazioni, concetti, eventi). Questo permette di rispondere a domande che richiedono ragionamento multi-hop: “Quali aziende hanno collaborato con il fornitore X che ha sede nella regione Y?”

Multi-modal RAG

La RAG non si limita al testo. Sistemi di multi-modal RAG possono indicizzare e recuperare immagini, tabelle, diagrammi e persino video. Un sistema RAG per la manutenzione industriale potrebbe recuperare lo schema tecnico di un componente insieme alla procedura testuale di riparazione.

Self-RAG

Nei sistemi Self-RAG, il modello impara a decidere autonomamente quando ha bisogno di informazioni esterne e quando può rispondere dalle proprie conoscenze. Genera “token di riflessione” speciali che valutano la necessità del retrieval e la qualità dei frammenti recuperati, rendendo il processo più efficiente e adattivo.

Glossario

Definizioni dei termini tecnici principali utilizzati in questo articolo.