RAG: anatomia di un'architettura che unisce ricerca e generazione

I Large Language Model sono straordinari nel generare testo fluido e apparentemente competente. Ma hanno un difetto di fondo: non sanno quello che non sanno. La loro conoscenza si congela nel momento in cui finiscono l'addestramento, e quando non trovano un appiglio statistico adeguato, inventano. Con grande disinvoltura.

Per chi vuole usare l'AI sui documenti interni dell'azienda, su normative che cambiano, su un catalogo prodotti o su una base di conoscenza proprietaria, questo è un problema bloccante. Non basta un modello brillante: serve un modello che sappia dove andare a cercare le risposte prima di scriverle.

La Retrieval-Augmented Generation, in sigla RAG, è la risposta architetturale a questo problema. Non è un singolo algoritmo, ma un modo di progettare: prima cerca, poi genera. Un ponte tra il mondo dei motori di ricerca e quello dei modelli generativi, pensato per ancorare le risposte dell'AI a fonti documentali che si possono verificare.

Un LLM senza accesso a fonti esterne è come un esperto con una memoria eccellente ma nessuna biblioteca: può ragionare, ma non può verificare.

Quello che faccio qui e quello che faccio in aula: smontare il sistema un pezzo alla volta, dalla teoria fino agli errori pratici, per darti una mappa completa se vuoi progettare, valutare o semplicemente capire come funzionano questi sistemi.

01Perché gli LLM inventano

Per capire perché serve la RAG, bisogna prima capire perché i modelli linguistici sbagliano. E non sbagliano come sbaglieremmo noi, per distrazione o per ignoranza consapevole, ma in un modo strutturalmente diverso: generano la sequenza di parole più probabile, indipendentemente dal fatto che sia vera.

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 è" la parola "Roma" compare con altissima probabilità. Quando questa correlazione statistica funziona, il risultato sembra intelligenza. Quando non funziona, perché i dati di addestramento erano incompleti, contraddittori o del tutto assenti, il modello produce comunque una risposta, semplicemente meno affidabile. Ma con la stessa sicurezza di prima.

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

Perché il fine-tuning da solo non basta

La prima reazione, quando spiego questo in aula, è quasi sempre la stessa: "e allora addestriamo il modello sui nostri dati". Il fine-tuning è davvero utile per insegnare al modello uno stile, un formato o il gergo di un settore, ma ha limiti strutturali che è bene conoscere.

• Conoscenza statica. Dopo il fine-tuning le informazioni restano congelate. Se domani un documento cambia, serve un nuovo ciclo di addestramento.
• Costo elevato. Richiede GPU, tempo, competenze e un processo di validazione serio.
• Nessuna tracciabilità. Non c'è modo di sapere da quale documento arriva una certa risposta. Il modello ha "assorbito" i dati nei suoi pesi, ma non può citarti la fonte.
• Rischio di overfitting. Su dataset piccoli il modello tende a memorizzare invece di generalizzare.

Il punto chiave è questo: il fine-tuning cambia come il modello parla, la RAG cambia cosa il modello sa nel momento in cui risponde. Sono strategie complementari, non alternative. Spesso le si usa insieme.

La necessità del grounding

Quello che serve davvero è un meccanismo di grounding: ancorare ogni risposta generata a fonti concrete e verificabili. L'utente deve poter risalire al paragrafo esatto da cui arriva un'informazione. E il sistema deve poter dire "non ho trovato nulla di pertinente" invece di inventare per riempire il silenzio.

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

02L'architettura RAG in tre fasi

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 di fondo è semplice: dare al modello generativo accesso a una memoria esterna che si può interrogare.

L'architettura si articola in tre fasi, ciascuna con le sue scelte progettuali.

1. Indexing. I documenti vengono elaborati, suddivisi in frammenti e trasformati in vettori numerici, poi archiviati in un database vettoriale.
2. Retrieval. Quando arriva una domanda, viene convertita in vettore e confrontata con i documenti indicizzati per trovare i frammenti più pertinenti.
3. Generation. I frammenti recuperati vengono inseriti nel prompt come contesto, e il modello genera una risposta basata su quelle informazioni.

Il pipeline nel dettaglio

Se seguiamo una singola domanda dall'inizio alla fine, il flusso completo è questo:

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

03Embedding 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 ed è probabilmente il concetto più importante di tutta l'architettura. Se lo capisci bene, il resto viene da sé.

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 1.536 dimensioni. Ogni dimensione cattura un aspetto del significato.

L'analogia che uso sempre e 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 a molte dimensioni. Testi con significato simile finiscono con coordinate vicine, testi che parlano di cose diverse finiscono lontani.

Se un embedding è una coordinata GPS del significato, allora un database vettoriale è la mappa su cui cerchiamo i punti più vicini alla nostra posizione.

I modelli di embedding

Non tutti i modelli di embedding sono uguali, e la scelta del modello influenza direttamente la qualità del retrieval. Questi sono quelli che incontro più spesso nei progetti:

• Sentence-Transformers. Famiglia di modelli open-source ottimizzati per la similarita semantica a livello di frase. Un modello come all-MiniLM-L6-v2 offre 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 ed E5. Modelli open-source di nuova generazione che ormai competono con le soluzioni proprietarie.

La 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 a molte dimensioni. 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 in una cosa precisa: ignora la "lunghezza" dei vettori, cioè quanto testo c'era, e si concentra solo sulla loro "direzione", cioè sul significato. Due frasi che dicono la stessa cosa puntano nella stessa direzione, anche se una è lunga il triplo dell'altra.

I database vettoriali

Una volta generati, i vettori devono essere archiviati e interrogabili in modo efficiente. Qui entrano in gioco i database vettoriali, e la scelta dipende molto da volumi, competenze interne e voglia di gestire infrastruttura.

04Chunking: spezzare i documenti

Un documento intero, un PDF di 50 pagine, un manuale tecnico, un contratto, non può diventare un singolo vettore di embedding. I modelli di embedding hanno un limite di token in ingresso, tipicamente tra 256 e 512, e anche quando accettano input più lunghi la qualità della rappresentazione peggiora: 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, i chunk, prima dell'indicizzazione. La strategia di chunking è una delle decisioni progettuali più critiche di tutto il sistema, e una di quelle che si sottovaluta più spesso.

Le strategie di chunking

• Fixed-size chunking. Il testo viene diviso in blocchi di dimensione fissa, per esempio 500 token. Semplice da implementare, ma rischia di spezzare frasi a metà o di separare concetti che stavano insieme.
• Sentence-based chunking. La divisione avviene ai confini delle frasi. Preserva l'integrità sintattica, ma produce frammenti di dimensione molto variabile.
• Semantic chunking. Usa un modello di embedding per individuare i punti in cui il significato cambia, creando frammenti semanticamente coerenti. Più costoso, ma più efficace.
• Recursive chunking. Tenta la divisione partendo dai separatori più grandi, i paragrafi, e scende a quelli più piccoli, frasi e parole, solo se serve. È la strategia che LangChain usa di default.

Il ruolo dell'overlap

Quasi tutte le strategie prevedono un overlap, cioè una sovrapposizione tra chunk consecutivi: gli ultimi N token di un frammento vengono ripetuti all'inizio del successivo. 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 per intero.

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

05Retrieval: trovare l'informazione giusta

Il retrieval è il momento decisivo di tutto il pipeline. Se il sistema recupera i frammenti sbagliati, nessun modello generativo, per quanto potente, potrà produrre una risposta corretta. È il principio del garbage in, garbage out applicato all'AI generativa, e nei miei corsi è la prima cosa su cui faccio fermare le persone.

Dense retrieval e sparse retrieval

Esistono due paradigmi di fondo per cercare informazioni in una collezione di documenti, e ciascuno è bravo in cose diverse.

Il dense retrieval è l'approccio semantico: usa modelli di embedding per rappresentare query e documenti come vettori densi, e cerca per similarità coseno nello spazio vettoriale. Il suo punto di forza è che comprende sinonimi e parafrasi: "come risolvere un guasto" trova anche "procedura di riparazione". Il limite è che può confondere concetti superficialmente simili, e dipende molto dalla bontà del modello di embedding.

Lo sparse retrieval è l'approccio lessicale, basato sulla corrispondenza esatta delle parole pesata con l'algoritmo BM25, evoluzione di TF-IDF, senza bisogno di alcun modello neurale. È eccellente per termini tecnici, sigle, codici prodotto e nomi propri, dove le parole esatte contano. Il suo limite è speculare a quello del dense: non comprende i sinonimi, per lui "auto" e "macchina" sono due parole diverse.

La ricerca ibrida

Nella pratica la soluzione più efficace è la ricerca ibrida (hybrid search): combinare i risultati del dense retrieval e dello sparse retrieval, tipicamente con una fusione pesata dei punteggi, tramite Reciprocal Rank Fusion o una semplice media pesata. Così sfrutti insieme la comprensione semantica dei modelli neurali e la precisione lessicale di BM25, e copri i punti deboli di entrambi.

Il re-ranking

Dopo il retrieval iniziale, un passaggio di re-ranking può migliorare parecchio 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 insieme 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 tra vettori. Ma applicato ai primi 20 o 50 risultati il costo computazionale resta contenuto e il guadagno in qualità è sostanziale.

06La generazione aumentata

Una volta che il retrieval ha individuato i frammenti più pertinenti, questi vengono "iniettati" nel prompt del modello come contesto. È qui che avviene la vera augmentation: il modello non genera più dal nulla, ma a partire da informazioni concrete che gli hai messo davanti.

Come il contesto entra nel prompt

Un prompt RAG tipico ha questa struttura logica:

1. System prompt. Le istruzioni che definiscono il comportamento del modello: "rispondi solo basandoti sul contesto fornito; se non trovi l'informazione, dillo esplicitamente".
2. Contesto recuperato. I frammenti documentali, di solito preceduti da un'etichetta come "Contesto:" e separati da delimitatori.
3. Domanda dell'utente. La query originale, così com'è stata posta.
4. Istruzione finale. Eventuali vincoli sul formato della risposta: "cita le fonti tra parentesi quadre".

Gestire la finestra di contesto

Ogni modello ha un limite alla quantità di testo che può elaborare in una volta sola, la context window. Se i frammenti recuperati sono troppi o troppo lunghi, rischiano di non entrare nella finestra, oppure di spingere fuori la domanda dell'utente e le istruzioni di sistema. La gestione di questa finestra è un equilibrio delicato:

• Troppo contesto produce risposte vaghe, perché il modello non sa su cosa concentrarsi.
• Troppo poco contesto produce risposte incomplete o, peggio, allucinazioni.
• Il contesto più rilevante andrebbe messo all'inizio o alla fine del prompt: la ricerca ha documentato un effetto "lost in the middle", per cui quello che sta nel mezzo tende a perdersi.

Fedeltà o creatività

Nella RAG c'è una tensione di fondo tra faithfulness, la fedeltà al contesto fornito, e creatività, la capacità di sintetizzare, riformulare e collegare. Un sistema RAG per un chatbot di assistenza legale deve essere rigidamente fedele, un assistente di ricerca può permettersi più libertà nella sintesi. Non c'è un valore giusto in assoluto, dipende da cosa devi fare.

Il prompt engineering per la RAG non è un'arte: è un'attività ingegneristica fatta di test, metriche e iterazione sistematica.

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.

07Valutare un sistema RAG

Costruire un sistema RAG è relativamente semplice. Costruirne uno che funzioni bene è tutta un'altra storia, ed è qui che la maggior parte dei progetti si arena. La differenza sta nella capacità di misurare, perché senza numeri si ottimizza a sensazione, e a sensazione si sbaglia.

Le metriche fondamentali

La valutazione di un sistema RAG richiede metriche su più livelli, perché il sistema può rompersi in punti diversi:

• Faithfulness (fedeltà). La risposta generata è coerente con il contesto recuperato? Il modello ha aggiunto informazioni che nei documenti non c'erano?
• Answer relevance (pertinenza della risposta). La risposta risponde davvero alla domanda posta?
• Context relevance (pertinenza del contesto). I frammenti recuperati erano davvero pertinenti? 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, sigla di Retrieval Augmented Generation Assessment, è un framework open-source che automatizza la valutazione dei sistemi RAG. Usa un LLM come "giudice" per valutare ciascuna delle metriche di cui sopra, senza bisogno di annotazioni umane su ogni singola domanda.

Genera punteggi da 0 a 1 per faithfulness, answer relevance, context precision e context recall, e questo ti permette di capire in fretta dove il sistema sta fallendo: nel retrieval o nella generazione. Sono due problemi diversi e si risolvono in modi diversi.

La valutazione umana

La valutazione umana è il gold standard, ed è anche la più costosa. Di solito si procede così:

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

La combinazione è l'approccio più pragmatico: valutazione automatica per le iterazioni quotidiane, valutazione umana per i rilasci importanti.

08Gli errori che vedo più spesso

Quando si progettano, implementano e valutano diversi sistemi RAG, certi errori tornano con una regolarità prevedibile. Questi sono i più comuni e le contromisure che funzionano.

1. Chunking inadeguato

L'errore: usare chunk troppo grandi, "tanto il contesto è ampio", o troppo piccoli, "così sono più precisi", senza mai testare l'impatto sul retrieval.

La soluzione: sperimentare con dimensioni diverse, per esempio 256, 512 e 1.024 token, sullo stesso set di domande di test, e misurare la context relevance per ogni configurazione.

2. Modello di embedding sbagliato

L'errore: usare un modello di embedding generico per un dominio molto specializzato, per esempio testi legali o documentazione medica.

La soluzione: valutare modelli specifici per il dominio o fare fine-tuning del modello di embedding, e verificare sempre che supporti bene la lingua dei documenti. Per chi lavora in italiano questo non è un dettaglio.

3. Assenza di re-ranking

L'errore: fidarsi ciecamente dei risultati del retrieval iniziale, senza un secondo stadio di riordino.

La soluzione: aggiungere un re-ranker, anche leggero, dopo il retrieval. Il miglioramento è quasi sempre evidente, soprattutto sulle query ambigue.

4. Context overflow

L'errore: infilare troppi frammenti nel prompt, saturando la finestra di contesto e innescando l'effetto "lost in the middle".

La soluzione: limitare il numero di frammenti, da 3 a 5 spesso bastano, e posizionare i più rilevanti all'inizio e alla fine del contesto.

5. Ignorare i metadati

L'errore: indicizzare solo il testo, senza conservare metadati come data del documento, autore, sezione o tipo di documento.

La 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

L'errore: non gestire il caso in cui il retrieval non trova nulla di pertinente. Il modello genera comunque una risposta, ma senza contesto valido: il risultato è un'allucinazione.

La soluzione: definire una soglia minima di similarita. Se nessun frammento la supera, il sistema deve rispondere "non ho trovato informazioni pertinenti nella base documentale" invece di inventare.

09Dove sta andando la RAG

L'architettura RAG è giovane, il paper fondante ha solo pochi anni, e il campo si muove in fretta. Diverse linee di ricerca stanno allargando le capacità e i limiti del paradigma, e vale la pena conoscerle anche solo per capire cosa chiedere a un fornitore.

Agentic RAG

Nella RAG tradizionale il flusso e lineare: query, retrieval, generazione. Nell'Agentic RAG il modello può decidere da solo se e quando fare retrieval, riformulare la query se i primi risultati non convincono, 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

Il 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. Così riesce a rispondere a domande che richiedono ragionamento multi-hop, tipo "quali aziende hanno collaborato con il fornitore X che ha sede nella regione Y?".

Multi-modal RAG

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

Self-RAG

Nei sistemi Self-RAG il modello impara a decidere da solo quando ha bisogno di informazioni esterne e quando può rispondere con quello che già sa. Genera speciali "token di riflessione" che valutano la necessità del retrieval e la qualità dei frammenti recuperati, rendendo il processo più efficiente e adattivo.

La RAG del futuro non sara una sequenza fissa di passaggi, ma un processo intelligente di ricerca e sintesi che si adatta alla complessità della domanda. Se vuoi capire davvero come si progetta e si valuta un sistema così, oppure portarlo dentro la tua azienda, e esattamente il tipo di percorso che faccio nei miei corsi e nella formazione con Binatomy: si parte dalla teoria giusta e si arriva a metterci le mani.

10Glossario

Un promemoria rapido dei termini che ritornano più spesso quando si parla di RAG.

• RAG (Retrieval-Augmented Generation). Architettura che combina un sistema di ricerca documentale (retriever) con un modello generativo (generator). Il retriever trova informazioni pertinenti in una base documentale, il generator produce una risposta basata su quelle informazioni. Introdotta da Lewis et al. nel 2020.
• Embedding. Rappresentazione numerica del significato di un testo sotto forma di vettore a molte dimensioni. Testi semanticamente simili producono vettori vicini nello spazio vettoriale. E la base del dense retrieval.
• Vector database. Database specializzato nell'archiviazione e nella ricerca efficiente di vettori ad alta dimensionalita. Supporta query di similarita (nearest neighbor search) e filtraggio per metadati. Esempi: FAISS, ChromaDB, Qdrant, Pinecone.
• Chunking. Suddivisione di documenti lunghi in frammenti più piccoli per l'indicizzazione. Le strategie includono dimensione fissa, per frase, semantico e ricorsivo. Dimensione e strategia influenzano direttamente la qualità del retrieval.
• Retrieval. Fase in cui il sistema cerca e recupera i frammenti più pertinenti alla query. Può essere denso (basato su embedding), sparso (basato su parole chiave) o ibrido.
• Dense retrieval. Ricerca che rappresenta query e documenti come vettori densi e trova i più pertinenti per similarita coseno. Comprende sinonimi e parafrasi, ma può confondere concetti superficialmente simili.
• Sparse retrieval. Ricerca basata sulla corrispondenza lessicale delle parole, tipicamente con l'algoritmo BM25. Eccellente per termini tecnici e nomi propri, non comprende i sinonimi.
• Re-ranking. Secondo stadio di valutazione della rilevanza applicato ai risultati del retrieval iniziale. Un cross-encoder analizza insieme query e documento per un punteggio più accurato.
• Cosine similarity (similarita coseno). Metrica che misura la similarita tra due vettori calcolando il coseno dell'angolo tra di essi. Valori da -1 (opposti) a 1 (identici). Ignora la magnitudine, si concentra sulla direzione, cioè sul significato.
• Faithfulness (fedelta). Misura quanto la risposta generata e coerente con il contesto recuperato. Un sistema con alta faithfulness non aggiunge informazioni assenti dal contesto.
• Hallucination (allucinazione). Fenomeno in cui un modello produce informazioni plausibili ma false, con apparente sicurezza. E la ragione principale per cui servono architetture RAG dove conta l'accuratezza dei fatti.
• Context window (finestra di contesto). Quantità massima di testo, in token, che un modello può elaborare in una volta. Nella RAG deve contenere istruzioni di sistema, contesto recuperato e domanda dell'utente.