RAG: cos’è la Retrieval-Augmented Generation e come funziona

La RAG, acronimo di Retrieval-Augmented Generation (generazione potenziata dal reperimento di informazioni), è un’architettura che combina un modello linguistico di grandi dimensioni con un sistema di recupero dati esterno. Invece di affidarsi esclusivamente alla conoscenza acquisita durante l’addestramento, il modello interroga una knowledge base aggiornata e integra le informazioni recuperate nella risposta. Questo approccio migliora l’accuratezza degli output, riduce le risposte inventate e consente di operare su domini specializzati o dati privati senza riaddestrare il modello.

Definizione di RAG Retrieval-Augmented Generation

La Retrieval-Augmented Generation è un paradigma architetturale introdotto da Lewis et al. nel 2020 che separa la capacità generativa di un LLM dalla gestione della conoscenza fattuale. Il modello linguistico produce testo fluente e coerente, mentre un componente di recupero estrae in tempo reale le informazioni pertinenti da archivi strutturati o non strutturati.

Il meccanismo si distingue da un semplice sistema di ricerca perché il risultato finale è sempre testo generato, non un documento recuperato. Le informazioni estratte entrano nel prompt come contesto aggiuntivo e il modello le usa per formulare una risposta coerente, citabile e ancorata a fonti verificabili.

Relazione tra LLM, knowledge base e recupero informazioni

Un LLM addestrato su dati statici possiede una rappresentazione compressa del linguaggio e della conoscenza disponibile fino alla data di chiusura del training. Una knowledge base esterna, invece, può essere aggiornata in modo indipendente e continuo. La RAG collega questi due elementi: il modello di fondazione genera, la knowledge base informa.

Il recupero delle informazioni avviene prima della generazione. Quando arriva una query, il sistema cerca nella base di conoscenza i passaggi più pertinenti, li inserisce nel prompt e solo allora il modello produce la risposta. Questo flusso consente di separare le responsabilità: il modello linguistico non deve memorizzare fatti specifici, ma sa come usarli quando vengono forniti.

Differenza tra generazione pura e generazione con contesto recuperato

Un LLM senza recupero genera testo a partire da pattern statistici appresi durante l’addestramento. Su domande fattuali, soprattutto quelle che riguardano eventi recenti o dati specializzati, il modello può produrre risposte plausibili ma errate, un fenomeno noto come allucinazione.

Con la RAG, il modello riceve nel prompt i documenti o i passaggi recuperati dalla knowledge base. La risposta viene costruita a partire da queste informazioni concrete, non da pattern probabilistici sul training set. La differenza pratica è misurabile: in benchmark come i dataset RAG di Meta AI, i sistemi con recupero mostrano tassi di correttezza fattuale significativamente superiori rispetto alla generazione pura sullo stesso modello di base.

Processo operativo della RAG

Una pipeline RAG attraversa quattro fasi sequenziali: preparazione e indicizzazione dei dati, recupero dei passaggi pertinenti, costruzione del prompt arricchito, generazione della risposta. Ogni fase ha requisiti tecnici distinti e influenza la qualità dell’output finale in modo cumulativo.

Preparazione dei dati esterni e indicizzazione

I documenti che alimentano la knowledge base vengono prima pre-elaborati: il testo viene estratto, pulito e suddiviso in segmenti (chunk). La dimensione ottimale dei chunk dipende dal tipo di contenuto e dalla finestra di contesto del modello, ma nella pratica si lavora spesso tra i 256 e i 512 token per chunk, bilanciando granularità e completezza semantica.

Ogni chunk viene trasformato in un vettore numerico tramite un modello di embedding. Questa rappresentazione vettoriale cattura il significato semantico del testo in uno spazio ad alta dimensionalità. I vettori vengono poi indicizzati in un database vettoriale, che consente ricerche per similarità in tempi dell’ordine dei millisecondi anche su corpus di milioni di documenti.

La qualità dell’indicizzazione dipende anche dalla tokenizzazione e dalla gestione dei metadati. Includere informazioni come data di pubblicazione, fonte, sezione o categoria permette di filtrare i risultati prima della ricerca per similarità, riducendo il rumore e migliorando la pertinenza dei passaggi recuperati.

Recupero delle informazioni pertinenti

Quando arriva una query utente, il sistema la converte nello stesso spazio vettoriale usato per i documenti e calcola la similarità semantica tra il vettore della query e i vettori indicizzati. I passaggi con punteggio più alto vengono selezionati come contesto candidato.

Il numero di passaggi recuperati (top-k) è un parametro di configurazione. Valori tipici vanno da 3 a 10, ma dipendono dalla lunghezza dei chunk e dalla finestra di contesto disponibile. Un top-k troppo alto introduce rumore; uno troppo basso rischia di omettere informazioni rilevanti.

Aumento del prompt e generazione con grounding

I passaggi recuperati vengono inseriti nel prompt LLM insieme alla query originale. Questa fase, chiamata aumento del prompt, definisce come il modello deve usare le informazioni: può ricevere istruzioni esplicite per rispondere solo sulla base dei documenti forniti, citare le fonti o segnalare l’assenza di informazioni pertinenti.

Il grounding è il risultato di questo meccanismo: la risposta generata è ancorata a testi reali presenti nella knowledge base. Un modello con grounding corretto produce affermazioni tracciabili, ovvero collegabili a uno specifico documento di origine, il che consente verifiche successive e riduce il rischio di output inventati.

Aggiornamento delle fonti e manutenzione della base conoscitiva

A differenza del fine-tuning, che richiede un nuovo ciclo di addestramento per incorporare conoscenze aggiornate, la RAG permette di aggiornare la knowledge base in modo indipendente dal modello. Nuovi documenti possono essere indicizzati in tempo reale o con cicli di aggiornamento programmati.

La manutenzione include anche la rimozione di documenti obsoleti o superati, la verifica della coerenza tra fonti diverse e il monitoraggio della qualità del recupero. In ambienti enterprise con documentazione che cambia frequentemente, come normative, manuali tecnici o dati di prodotto, questo disaccoppiamento tra modello e knowledge base è uno dei principali vantaggi architetturali della RAG.

Componenti tecnici della pipeline RAG

Una pipeline RAG si compone di tre blocchi tecnici principali: il sistema di indicizzazione e rappresentazione vettoriale, il modulo di ricerca e ranking, e il livello di integrazione tra query, contesto recuperato e modello generativo. La qualità complessiva del sistema dipende dall’equilibrio tra questi blocchi, non dalla sola scelta del modello linguistico.

Database vettoriali, embedding e rappresentazioni numeriche

I database vettoriali sono sistemi di archiviazione e ricerca ottimizzati per vettori ad alta dimensionalità. Soluzioni come Weaviate, Pinecone e Milvus implementano algoritmi di ricerca approssimata come HNSW (Hierarchical Navigable Small World), che bilanciano velocità e accuratezza nel recupero dei vicini più simili.

Gli embedding sono la rappresentazione numerica del testo: modelli come text-embedding-3 di OpenAI o i modelli della famiglia Sentence-BERT trasformano frasi e paragrafi in vettori densi, dove testi semanticamente simili risultano vicini nello spazio vettoriale. La scelta del modello di embedding influenza direttamente la qualità del recupero, indipendentemente dall’LLM usato per la generazione.

Ricerca semantica, ricerca ibrida e re-ranker

La ricerca semantica individua passaggi pertinenti in base al significato, non alla corrispondenza lessicale. Questo consente di recuperare documenti rilevanti anche quando la query usa termini diversi da quelli presenti nel testo. La limitazione principale è la sensibilità alle query molto specifiche con terminologia tecnica precisa.

La ricerca ibrida combina la ricerca semantica per similarità vettoriale con la ricerca lessicale basata su BM25, un algoritmo di ranking documentale consolidato nell’information retrieval. I due segnali vengono fusi tramite strategie come Reciprocal Rank Fusion (RRF), che produce liste di risultati più robuste rispetto a ciascun metodo preso singolarmente.

Un re-ranker è un modello secondario che riordina i passaggi recuperati in base alla loro pertinenza rispetto alla query specifica. Modelli cross-encoder come quelli della famiglia Cohere Rerank o cross-encoder su Hugging Face calcolano la rilevanza di ogni coppia (query, passaggio) in modo più preciso rispetto alla sola similarità vettoriale, a costo di una latenza maggiore.

Query, contesto e finestra del modello

La finestra di contesto (context window) di un LLM determina quanti token può elaborare in un singolo passaggio. Modelli come GPT-4o supportano fino a 128.000 token, mentre altri operano su finestre più ridotte. Nella RAG, questa finestra ospita sia la query che i passaggi recuperati: se il contesto è troppo esteso rispetto alla finestra disponibile, i passaggi vengono troncati o filtrati.

La gestione della finestra di contesto è uno dei punti critici della pipeline. Inserire troppi passaggi riduce la precisione perché il modello deve estrarre l’informazione rilevante da un contesto rumoroso. Il fenomeno noto come “lost in the middle” mostra che i LLM tendono a utilizzare meglio le informazioni posizionate all’inizio e alla fine del contesto, trascurando quelle centrali, come documentato in ricerche sulla posizione del contesto.

Accuratezza, grounding e controllo delle risposte

Il valore principale della RAG non è solo la capacità di rispondere a domande, ma la possibilità di produrre risposte verificabili. Grounding, citazioni e controllo delle fonti trasformano un sistema generativo in uno strumento che può essere auditato, corretto e migliorato nel tempo.

Informazioni aggiornate e riduzione delle risposte obsolete

I dati di addestramento di un LLM hanno una data di chiusura oltre la quale il modello non conosce eventi o aggiornamenti. Su domande che richiedono informazioni recenti, un modello senza recupero produce risposte basate su dati superati. La RAG risolve questo limite: se la knowledge base viene aggiornata con nuovi documenti, il sistema risponde con informazioni attuali senza necessità di riaddestramento.

Questo aspetto è particolarmente rilevante in domini dove la conoscenza evolve rapidamente: normative fiscali, linee guida cliniche, documentazione software, cataloghi prodotto. La separazione tra modello e base di conoscenza consente aggiornamenti mirati, rapidi e controllabili.

Fondatezza fattuale e mitigazione delle allucinazioni

Le allucinazioni nei LLM sono affermazioni false o inventate presentate con lo stesso stile fluente di quelle corrette. Nella generazione pura, il modello produce testo plausibile anche in assenza di basi fattuali, perché ottimizza la coerenza linguistica, non la verità.

La RAG riduce questo rischio vincolando la generazione ai passaggi recuperati. Se il prompt include istruzioni esplicite per rispondere solo sulla base dei documenti forniti, il modello non ha motivo di inventare informazioni non presenti nel contesto. La fondatezza fattuale non è garantita al 100% nemmeno con la RAG, perché il modello può ancora interpretare male un passaggio o generalizzare in modo errato, ma la frequenza delle allucinazioni si riduce in modo misurabile su task document-centric.

Citazioni, fonti autorevoli e fiducia dell’utente

Uno dei vantaggi pratici della RAG è la possibilità di includere nella risposta riferimenti espliciti ai documenti di origine. L’utente può verificare l’affermazione risalendo al testo sorgente, il che aumenta la fiducia nel sistema e consente una verifica autonoma.

La qualità delle citazioni dipende dalla qualità dei documenti indicizzati. Se la knowledge base contiene fonti autorevoli, verificate e ben strutturate, le citazioni prodotte sono affidabili. Se contiene contenuti di bassa qualità o contraddittori, il sistema può recuperare e citare informazioni errate pur rispettando formalmente il grounding. La curation della base di conoscenza è quindi una responsabilità editoriale, non solo tecnica.

Controllo degli sviluppatori su fonti e autorizzazioni

Una pipeline RAG consente un controllo granulare sulle fonti accessibili. È possibile definire quali documenti o archivi sono interrogabili per ciascun utente o ruolo, implementare filtri per categoria o data, e limitare il recupero a subset specifici della knowledge base in base al contesto della query.

Questo livello di controllo è rilevante in ambienti enterprise dove i dati hanno classificazioni di riservatezza diverse. Un sistema RAG ben configurato può esporre ai dipendenti solo i documenti autorizzati per il loro profilo, senza che il modello abbia accesso all’intera base di conoscenza. L’autenticazione e l’autorizzazione a livello di recupero sono componenti architetturali distinte dalla sicurezza del modello linguistico stesso.

Applicazioni RAG in agenti e chatbot

La RAG trova applicazione in qualsiasi sistema conversazionale o agenziale che deve rispondere con precisione su un dominio specifico. Chatbot di supporto, assistenti interni, motori di ricerca aziendali e agenti autonomi che operano su documentazione tecnica sono tutti contesti in cui l’architettura RAG produce vantaggi concreti rispetto alla generazione pura.

Chatbot, agenti LLM e applicazioni conversazionali

Nei chatbot basati su RAG, ogni messaggio utente innesca un ciclo di recupero prima della generazione. Il sistema recupera i passaggi pertinenti dalla knowledge base, li inserisce nel contesto e genera una risposta coerente con la conversazione in corso. Rispetto a un chatbot che usa solo il modello di base, la versione RAG può rispondere a domande specifiche su prodotti, policy o procedure senza che queste informazioni siano state incorporate nel modello durante il training.

Gli agenti conversazionali più avanzati combinano la RAG con strumenti esterni (API, database, motori di calcolo) e con meccanismi di pianificazione. In questi sistemi, la RAG gestisce il recupero di conoscenza dichiarativa, mentre gli strumenti gestiscono azioni procedurali. Il confine tra recupero di informazioni e esecuzione di task diventa una scelta architetturale esplicita.

Knowledge base interne e dati privati o specializzati

Uno degli use case più diffusi della RAG in ambito enterprise è la costruzione di sistemi che interrogano documentazione interna: manuali operativi, contratti, ticket di supporto, basi di conoscenza HR, specifiche tecniche. Questi dati non sono presenti nei dati di addestramento di nessun modello pubblico, e il fine-tuning su dati proprietari è costoso, lento e richiede aggiornamenti frequenti.

Con la RAG, i dati privati o specializzati restano nella knowledge base aziendale. Il modello linguistico accede a queste informazioni solo in fase di inferenza, tramite il meccanismo di recupero. Questo approccio riduce i rischi legati alla privacy dei dati, perché le informazioni sensibili non vengono incorporate nei pesi del modello ma rimangono nei sistemi di archiviazione controllati dall’organizzazione.

Casi d’uso aziendali e domini con conoscenza aggiornata

I settori con la più alta densità di adozione RAG sono quelli dove la conoscenza cambia frequentemente e l’accuratezza delle risposte ha conseguenze operative dirette.

• Supporto clienti e IT helpdesk: i sistemi RAG recuperano soluzioni da ticket storici, manuali e FAQ aggiornati, riducendo i tempi di risposta e il volume di escalation verso operatori umani.
• Legal e compliance: assistenti RAG su corpus normativi, giurisprudenza e policy interne consentono ricerche veloci su documenti che cambiano con aggiornamenti regolatori.
• Ricerca e sviluppo: team di R&D usano la RAG per interrogare archivi di brevetti, paper scientifici e report tecnici interni, con recupero contestuale rispetto alla query specifica.

Valutazione e scelta dell’architettura RAG

Progettare un sistema RAG richiede scelte architetturali esplicite su ogni componente della pipeline. La valutazione delle performance non può limitarsi alla qualità percepita delle risposte, ma richiede metriche misurabili sul recupero, sulla generazione e sull’integrazione tra i due moduli.

Metriche di pertinenza, coerenza e qualità della risposta

Le metriche di valutazione di un sistema RAG operano su due livelli distinti: il recupero e la generazione. Sul lato recupero, le metriche principali sono precision@k (quanti dei passaggi recuperati sono effettivamente pertinenti) e recall@k (quanti dei passaggi pertinenti esistenti vengono effettivamente recuperati). Sul lato generazione, si misurano fedeltà (faithfulness), ovvero quanto la risposta è ancorata ai passaggi recuperati, e pertinenza della risposta rispetto alla query.

Framework di valutazione come RAGAS automatizzano queste misurazioni usando un LLM come giudice. Le metriche di coerenza e fluidità valutano la qualità linguistica dell’output, mentre metriche come “answer relevancy” e “context precision” misurano l’allineamento tra recupero e generazione. In ambito RAG Ops, queste misurazioni vengono integrate in pipeline di monitoraggio continuo per rilevare degradazioni di performance nel tempo.

Differenza tra RAG e ricerca semantica

La ricerca semantica restituisce documenti o passaggi ordinati per rilevanza rispetto a una query. Il risultato è una lista di testi che l’utente deve leggere e interpretare autonomamente. La RAG usa la ricerca semantica come componente interno, ma aggiunge un passaggio generativo: il modello linguistico elabora i passaggi recuperati e produce una risposta sintetica in linguaggio naturale.

Le due architetture hanno casi d’uso distinti. La ricerca semantica è preferibile quando l’utente deve esplorare un corpus, verificare le fonti in modo diretto o lavorare con documenti complessi che richiedono lettura integrale. La RAG è più efficace quando l’utente ha bisogno di una risposta precisa a una domanda specifica, senza dover leggere e sintetizzare manualmente più documenti.

Piattaforme cloud, servizi gestiti e componenti proprietari

Le principali piattaforme cloud offrono servizi gestiti che coprono uno o più componenti della pipeline RAG. Su AWS, Amazon Bedrock Knowledge Bases integra il recupero vettoriale con modelli fondazionali selezionabili, mentre Amazon Kendra offre un motore di ricerca enterprise con supporto nativo per fonti documentali aziendali. Su Google Cloud, Vertex AI Agent Builder e Vector Search coprono rispettivamente l’orchestrazione degli agenti e l’indicizzazione vettoriale ad alta scala, con integrazione diretta con BigQuery per dati strutturati.

La scelta tra componenti open source e servizi gestiti dipende da requisiti di controllo, latenza, costo e scalabilità. I servizi gestiti riducono il tempo di sviluppo e la complessità operativa, ma introducono dipendenze da vendor specifici e possono avere costi variabili al crescere dei volumi. Soluzioni self-hosted su database vettoriali open source offrono maggiore controllo su dati, configurazione e costi, ma richiedono competenze di infrastruttura più elevate.

In entrambi i casi, la qualità del sistema RAG dipende più dalla cura nella preparazione dei dati e nella configurazione del recupero che dalla scelta della piattaforma. Un’architettura ben progettata su componenti open source supera spesso una configurazione predefinita su servizi gestiti, soprattutto su domini altamente specializzati o con requisiti di sicurezza stringenti sui dati privati.