Workflow RAG end-to-end: come funziona la Retrieval Augmented Generation

La Retrieval Augmented Generation (RAG) è un pattern di architettura AI che collega i modelli linguistici di grandi dimensioni (LLM) a fonti di conoscenza esterne in fase di inferenza, consentendo a tali modelli di generare risposte accurate e sensibili al contesto che vanno oltre i loro dati di addestramento statici. Invece di affidarsi alla conoscenza codificata durante il pre-addestramento, un sistema RAG recupera i documenti rilevanti da un database esterno in risposta a ogni query dell'utente e inserisce tale contenuto nel prompt dell'LLM prima della generazione. Il risultato è un sistema di AI generativa che produce risposte accurate e specifiche per il dominio, basate su fonti verificate, senza richiedere il riaddestramento completo del modello ogni volta che la conoscenza sottostante cambia.

Gli LLM forniscono spesso risposte obsolete a causa dei limiti di aggiornamento delle conoscenze (knowledge cutoff) e non possono accedere a documenti interni proprietari o a fonti di dati esterne in tempo reale. La RAG affronta direttamente questa limitazione. Oltre il 60% delle organizzazioni sta sviluppando attivamente strumenti di recupero basati sull'AI, il che riflette un cambiamento fondamentale: dal fare affidamento esclusivamente sulla memoria del modello al collegare dinamicamente l'AI a knowledge base attive contenenti documenti interni, documentazione di prodotto e dati aggiornati.

Questa guida illustra l'intero workflow RAG — dai componenti dell'architettura e l'ingestione dei dati al recupero ibrido, alla progettazione dei prompt, alla valutazione e al deployment — con indicazioni pratiche per i team che creano pipeline RAG di produzione.

Componenti chiave di un'architettura RAG

I sistemi RAG contengono quattro componenti principali: una knowledge base che memorizza la conoscenza esterna, un componente di recupero delle informazioni (il retriever) che trova i documenti rilevanti per ogni query, un livello di integrazione che assembla il contesto recuperato in un prompt per l'LLM e un generatore (l'LLM) che produce la risposta finale. Ogni componente può essere ottimizzato in modo indipendente e la qualità complessiva della pipeline è limitata dall'anello più debole: un LLM di alta qualità non può compensare un retriever che propone costantemente documenti irrilevanti.

Il retriever e il database vettoriale

Il retriever accetta una query dell'utente, la converte in una rappresentazione comparabile e restituisce i documenti più rilevanti dalla knowledge base. La qualità del retriever è il singolo fattore più importante per determinare la qualità dell'output RAG. Il database vettoriale memorizza rappresentazioni numeriche di frammenti di documenti — chiamati embedding — consentendo una rapida ricerca per somiglianza su larga scala. A differenza dei database relazionali che effettuano la corrispondenza su valori esatti, i database vettoriali trovano i documenti il cui significato è semanticamente più vicino alla query utilizzando metriche di distanza come la somiglianza del coseno.

Il generatore e il livello di orchestrazione

Il generatore è il modello linguistico di grandi dimensioni che riceve il prompt aumentato — la domanda originale dell'utente combinata con il contesto recuperato — e produce la risposta finale. Il livello di orchestrazione collega tutti i componenti in una pipeline RAG coerente, gestendo l'assemblaggio dei prompt, la cronologia delle conversazioni e la gestione degli errori. Framework come LangChain e LlamaIndex forniscono primitive di orchestrazione comuni, mentre piattaforme come Databricks offrono un'infrastruttura gestita per l'intero stack.

Fonti di dati e conoscenza esterna

La gamma di fonti di dati valide per un sistema RAG è ampia: dati strutturati in tabelle relazionali, testo non strutturato in file PDF e markdown, documenti interni come runbook di ingegneria e policy HR, documentazione di prodotto e knowledge base esterne. I dati specifici del dominio — contenuti direttamente rilevanti per le domande che gli utenti porranno — dovrebbero essere acquisiti per primi e gestiti con la massima cura. I dati interni, inclusi i documenti interni e le ricerche proprietarie, generano il vantaggio più difendibile in un'implementazione RAG perché rappresentano una conoscenza su cui nessun LLM pubblico è stato addestrato.

La domanda pratica quando si selezionano le fonti di dati riguarda la densità di rilevanza: quale percentuale di documenti indicizzati verrà effettivamente recuperata in risposta a query reali? Le fonti ad alta rilevanza giustificano i costi computazionali e finanziari di embedding e indicizzazione; le fonti a bassa rilevanza diluiscono la qualità del recupero aumentando il rumore che il retriever deve filtrare.

Più fonti di dati possono essere combinate in un unico sistema RAG — ad esempio, associando un corpus di documentazione di prodotto a un database clienti in tempo reale — purché la pipeline di ingestione normalizzi ciascuna fonte in un formato di testo coerente. I team dovrebbero documentare la data lineage di ogni fonte indicizzata in modo che l'origine di qualsiasi documento recuperato possa essere ricondotta alla sua fonte autorevole, abilitando workflow di audit e conformità nei settori regolamentati.

Modello di embedding e vector store

Selezione di un modello di embedding

Un modello di embedding è un modello linguistico specializzato che converte il testo in rappresentazioni numeriche — vettori ad alta dimensione che codificano il significato semantico. Quando un utente invia una query, lo stesso modello di embedding converte l'input dell'utente in un vettore comparabile, consentendo il confronto matematico tra la query e tutti gli embedding dei documenti memorizzati. Il modello di embedding utilizzato durante l'ingestione deve essere identico a quello utilizzato al momento della query.

La selezione del modello comporta compromessi tra qualità della rappresentazione, dimensionalità dei vettori, latenza di inferenza e costi finanziari. I modelli generici come bge-large-en producono vettori a 1.024 dimensioni che offrono buone prestazioni in diversi domini. I modelli di embedding specifici per il dominio, sottoposti a fine-tuning su testi tecnici, spesso superano i modelli generici in compiti di recupero specifici. I modelli di embedding trasformano il testo non elaborato nelle rappresentazioni numeriche che rendono possibile la ricerca per somiglianza vettoriale.

I modelli di embedding possono anche essere valutati in base alla loro capacità di gestire query formulate in modo diverso rispetto ai documenti che devono recuperare — una proprietà chiamata robustezza multilingue o alla parafrasi. In contesti aziendali in cui gli utenti pongono domande in modo colloquiale mentre la documentazione è scritta in modo formale, questo collegamento semantico è fondamentale. Testare il modello di embedding su un campione rappresentativo di query reali degli utenti prima di avviarlo in una sessione di indicizzazione in produzione può evitare in seguito un costoso re-embedding dell'intero corpus.

Strategia di chunking e indicizzazione

I documenti di grandi dimensioni devono essere suddivisi in frammenti (chunk) più piccoli prima dell'embedding, sia perché la finestra di contesto del modello di embedding è limitata, sia perché frammenti più piccoli consentono un recupero più preciso. La dimensione dei chunk influisce direttamente sulla qualità dell'output: chunk troppo piccoli perdono il contesto circostante, mentre chunk troppo grandi diluiscono il passaggio specifico più rilevante per la domanda dell'utente. Le strategie comuni includono la suddivisione a dimensione fissa in base al numero di token e la suddivisione ai limiti delle frasi con sovrapposizione per ridurre il rischio che il contesto chiave si trovi su un confine.

Una volta creati gli embedding, i vettori vengono memorizzati e indicizzati nel vector store. Un indice vettoriale che utilizza algoritmi come HNSW organizza gli embedding per consentire la ricerca approssimativa dei vicini più prossimi (approximate nearest-neighbor) su larga scala, riducendo il tempo di recupero da una scansione lineare di tutti gli embedding a una ricerca inferiore al millisecondo.

Recupero delle informazioni e ricerca ibrida

La ricerca semantica — la spina dorsale della maggior parte dei sistemi RAG — trova i documenti il cui significato è più vicino alla query dell'utente, gestendo in modo naturale parafrasi e sinonimi. Databricks AI Search implementa la ricerca vettoriale semantica con sincronizzazione automatica dalle tabelle Delta, in modo che la knowledge base rifletta i nuovi dati senza necessità di re-indicizzazione manuale.

La ricerca semantica pura presenta un punto debole noto con le query a corrispondenza esatta: codici di errore specifici, numeri di versione o entità denominate. La ricerca ibrida affronta questo problema combinando la ricerca vettoriale semantica con la ricerca per parole chiave BM25 — un modello probabilistico di frequenza dei termini che eccelle nella corrispondenza di termini esatti e rari. L'esecuzione in parallelo di entrambi i percorsi di ricerca e l'unione dei risultati tramite reciprocal rank fusion migliora l'efficienza del recupero su una distribuzione di query più ampia.

Una fase di reranking può migliorare ulteriormente i risultati applicando un modello cross-encoder per assegnare un punteggio a ciascun documento recuperato rispetto alla query e riordinare i risultati in modo che i documenti più rilevanti appaiano in cima. I metodi di recupero come il reranking migliorano significativamente la precisione e sono particolarmente preziosi quando la finestra di contesto dell'LLM limita il numero di documenti che possono essere passati al generatore.

Le soglie di somiglianza aggiungono un controllo di qualità finale: i documenti il cui punteggio di rilevanza scende al di sotto di una soglia minima dovrebbero essere completamente esclusi, anziché essere passati al generatore come contesto di bassa qualità. Passare un contesto irrilevante è peggio che non passare alcun contesto: consuma la finestra di contesto e aumenta il rischio che l'LLM mescoli informazioni corrette e non corrette nella risposta generata. L'impostazione di soglie conservative e il monitoraggio del tasso di filtraggio nel tempo è un modo semplice per mantenere la qualità del recupero senza modifiche architetturali.

Come funziona la RAG: dall'ingestione alla generazione

Il workflow RAG segue cinque fasi sequenziali che trasformano la domanda di un utente in una risposta accurata e fondata.

Fase 1: Ingestione e normalizzazione dei dati esterni

La pipeline RAG inizia con l'ingestione dei dati. I documenti non elaborati vengono caricati in una pipeline ETL che pulisce e normalizza il testo — rimuovendo il boilerplate, standardizzando gli spazi vuoti ed estraendo contenuti strutturati da tabelle e codice. L'architettura data lakehouse centralizza l'ingestione di contenuti sia strutturati che non strutturati sotto una governance unificata, rendendola una base naturale per la knowledge base RAG.

Fase 2: Suddivisione in chunk, embedding e indicizzazione

I documenti puliti vengono suddivisi in chunk, ogni chunk viene passato attraverso il modello di embedding per generare un vettore, e gli embedding risultanti vengono scritti nel vector store insieme al testo originale e ai metadati (titolo del documento, data, URL di origine). I metadati consentono il recupero filtrato — limitando i risultati ai documenti pubblicati entro un intervallo di date o accessibili a uno specifico ruolo utente. RAG richiede aggiornamenti continui per mantenere la rilevanza dei dati; i sistemi di produzione hanno bisogno di pipeline automatizzate che rilevino i documenti di origine aggiornati e avviino il re-embedding su base pianificata o guidata da eventi.

Fase 3: Recupero dei documenti rilevanti

Quando un utente invia una query, il sistema RAG applica lo stesso modello di embedding per convertire l'input dell'utente in una rappresentazione vettoriale e interroga il vector store, eseguendo una ricerca di similarità che restituisce i top-k chunk di documenti più rilevanti. Il valore k — quanti chunk recuperare — rappresenta un compromesso tra la copertura del recupero e il consumo della finestra di contesto, e deve essere ottimizzato per l'LLM di destinazione.

Fase 4: Arricchimento del prompt dell'LLM

I documenti recuperati vengono assemblati nel prompt arricchito. Una struttura tipica colloca prima un'istruzione di sistema ("Rispondi alla domanda dell'utente basandoti solo sul contesto fornito. Se non riesci a trovare la risposta nel contesto, dillo."), seguita dai chunk di testo recuperati, e infine dalla domanda originale dell'utente. Posizionare i documenti più rilevanti all'inizio tende a migliorare la focalizzazione, in particolare per i modelli inclini al fenomeno "lost in the middle" (perso nel mezzo), in cui il contesto vicino all'inizio e alla fine riceve maggiore attenzione rispetto al contenuto centrale.

Fase 5: Generazione della risposta finale

Il generatore riceve il prompt arricchito e produce la risposta finale. Il post-processing può aggiungere citazioni delle fonti, filtrare gli output fuori tema o strutturare i risultati in un formato coerente. L'LLM genera risposte accurate perché ha accesso al contesto recuperato anziché affidarsi esclusivamente ai dati di addestramento statici del pre-addestramento.

La gestione della cronologia delle conversazioni è un aspetto importante a livello di generazione per le applicazioni RAG multi-turno. Quando il sistema RAG deve ricordare gli scambi precedenti di una sessione — in modo che gli utenti possano porre domande di follow-up che fanno riferimento alle risposte precedenti — la cronologia della conversazione deve essere incorporata nel prompt arricchito. Ciò aumenta la lunghezza effettiva del prompt e riduce la finestra di contesto disponibile per i documenti appena recuperati. I team dovrebbero implementare una gestione esplicita del budget di contesto che allochi i token tra cronologia, contesto recuperato e query corrente dell'utente.

IA generativa, progettazione dei prompt dell'LLM e orchestrazione

Un modello di prompt dell'LLM riutilizzabile separa le istruzioni statiche — ruolo del sistema, vincoli comportamentali, formato di output — dal contenuto dinamico inserito a runtime: contesto recuperato e query dell'utente. L'istruzione di rispondere "solo in base al contesto fornito" è particolarmente importante per i sistemi RAG. Senza di essa, i modelli di IA generativa integreranno il contenuto recuperato con i dati di addestramento memorizzati, producendo risposte che fondono informazioni verificate con conoscenze del modello potenzialmente errate.

L'inserimento di citazioni — ovvero l'aggiunta dei metadati del documento di origine a ciascuna risposta generata — consente ai revisori umani di verificare che le risposte siano basate su dati reali recuperati. Nelle distribuzioni aziendali, il supporto alle citazioni e le istruzioni di sistema che limitano l'ambito dell'argomento, la lunghezza della risposta e il comportamento di escalation sono requisiti di produzione fondamentali per ottenere risposte accurate.

Fine-tuning, conoscenza del dominio e alternative

Il fine-tuning adatta un modello pre-addestrato a uno specifico dominio modificando i pesi del modello su un dataset curato. A differenza di RAG, il fine-tuning modifica il comportamento del modello sottostante — il suo vocabolario, il tono e la conoscenza implicita del dominio — anziché inserire il contesto al momento dell'inferenza. Il fine-tuning è indicato quando il modello di base fraintende costantemente la terminologia specifica del dominio o quando lo stile di risposta richiesto non può essere ottenuto solo tramite il prompt engineering.

Il fine-tuning non è un sostituto efficace di RAG quando l'obiettivo è l'accesso a informazioni aggiornate. Il fine-tuning degli LLM su nuovi dati comporta costi computazionali e finanziari significativi e non può tenere il passo con knowledge base in continua evoluzione. La maggior parte dei sistemi di produzione combina entrambi: un modello sottoposto a fine-tuning gestisce il tono e la terminologia del dominio, mentre il flusso di lavoro RAG fornisce l'accesso alla conoscenza. Affidarsi esclusivamente al fine-tuning per l'accesso alla conoscenza è un errore comune e costoso.

Il prompt engineering — la progettazione di istruzioni di sistema ed esempi few-shot per guidare il comportamento del modello — rimane il punto di partenza fondamentale per qualsiasi personalizzazione dell'LLM. Non richiede infrastrutture aggiuntive e produce risultati immediati. Per i sistemi RAG, il prompt engineering controlla il modo in cui il contesto recuperato viene presentato al modello e come il modello segnala l'incertezza quando i documenti recuperati non rispondono completamente alla domanda dell'utente. Ogni sistema RAG incorpora il prompt engineering per definizione, poiché l'assemblaggio del prompt arricchito è di per sé una forma di progettazione del prompt.

Valutazione di RAG e test di recupero

Misurazione della qualità del recupero

La valutazione di RAG deve esaminare in modo indipendente la componente di recupero delle informazioni e la componente di generazione. La valutazione del recupero utilizza la metrica precision@k: dei k documenti recuperati per una determinata query, quale frazione è effettivamente rilevante? Un dataset di valutazione ground-truth — query associate a documenti e risposte notoriamente corretti — è il prerequisito necessario. La creazione di questo dataset richiede molto lavoro ma è essenziale; senza di esso, i team non possono distinguere i reali miglioramenti della valutazione di RAG dalle variazioni casuali.

Misurazione della fedeltà della generazione

La valutazione della generazione misura se le risposte del modello sono fedeli al contesto recuperato — ovvero se la risposta generata contiene informazioni errate o inventate derivanti dai dati di addestramento del modello anziché dalle fonti recuperate. La valutazione LLM-as-judge, in cui un secondo LLM assegna un punteggio di fedeltà a ciascuna risposta, offre una copertura scalabile su ampi set di test. La valutazione degli LLM con MLflow integra le metriche di recupero e generazione in un framework unificato di tracciamento degli esperimenti. RAG riduce le allucinazioni nei modelli di IA generativa, ma non può eliminare tutte le allucinazioni dell'IA nelle risposte generate.

Monitoraggio, governance e sicurezza

I sistemi RAG ereditano i requisiti di governance delle loro origini dati. Gli utenti dovrebbero recuperare solo i documenti che sono autorizzati ad accedere. Unity Catalog offre una governance granulare su tutta la knowledge base di RAG — indici vettoriali, tabelle Delta e endpoint del modello governati da un modello di controllo degli accessi comune con tracciamento completo della data lineage. L'assegnazione di tag di provenienza — che associa ciascuna risposta generata ai chunk di documenti specifici che l'hanno prodotta — consente ai revisori umani di verificare le fonti citate e controllare i contenuti generati dall'IA. Nei settori regolamentati, la provenienza è spesso un requisito di conformità.

Il monitoraggio dovrebbe anche tracciare l'obsolescenza della knowledge base — il divario temporale tra l'ultimo aggiornamento dei documenti di origine e l'ultimo aggiornamento dell'indice RAG. Una knowledge base che restituisce costantemente documenti obsoleti è operativamente equivalente a un LLM con un limite di addestramento non aggiornato; entrambi producono risposte che erano accurate in un determinato momento ma che non riflettono più le informazioni attuali. Gli avvisi automatici di obsolescenza che si attivano quando un documento di origine non è stato reindicizzato entro un SLA definito prevengono il degrado silenzioso dell'accuratezza delle risposte nel tempo.

I vector store dovrebbero essere crittografati a riposo, gli endpoint di inferenza degli embedding e dell'LLM distribuiti all'interno di confini di rete sicuri, e i log di controllo dovrebbero registrare tutte le query e gli eventi di recupero per rilevare accessi anomali.

I controlli di accesso basati sui ruoli a livello di recupero sono particolarmente importanti nelle distribuzioni RAG multi-tenant, in cui utenti o team diversi dovrebbero recuperare documenti solo dai domini di dati autorizzati. Senza controlli di accesso a livello di recupero, una query dell'utente potrebbe far emergere documenti riservati di una business unit non correlata — un fallimento della governance dei dati che è invisibile nella risposta generata ma presente nel log di recupero sottostante. Progettare il controllo degli accessi nell'architettura RAG fin dall'inizio è significativamente più semplice rispetto a integrarlo successivamente, dopo che i dati sono già stati indicizzati.

Scalabilità operativa e best practice di distribuzione

L'ingestione iniziale di un'ampia knowledge base richiede l'embedding in batch su larga scala. Dopo il caricamento iniziale, l'ingestione incrementale esegue il re-embedding solo dei documenti nuovi o aggiornati. I sistemi devono scalare automaticamente le risorse di calcolo per l'embedding durante i caricamenti iniziali e ridurle per i successivi aggiornamenti incrementali. L'embedding in batch è significativamente più economico per documento rispetto all'embedding in tempo reale; i sistemi di produzione dovrebbero utilizzare l'elaborazione in batch per i carichi di lavoro di ingestione e riservare l'embedding in tempo reale per l'elaborazione delle query degli utenti.

L'inferenza dell'LLM domina tipicamente i costi operativi di RAG. Il passaggio di un numero maggiore di documenti recuperati all'LLM aumenta proporzionalmente il costo di inferenza per query; i team dovrebbero stabilire policy esplicite sul numero massimo di documenti recuperati e sulla lunghezza del prompt per limitare i costi. Ogni componente — inferenza dell'embedding, vector store, servizio di orchestrazione, endpoint dell'LLM — dovrebbe essere containerizzato per una distribuzione riproducibile, con logica di retry e pattern circuit-breaker per il failover.

Databricks MLflow offre tracciamento degli esperimenti, registro dei modelli e strumenti di valutazione integrati con l'intero stack RAG, consentendo ai team di gestire le versioni dei modelli di embedding, tracciare gli esperimenti di recupero e gestire il ciclo di vita delle pipeline RAG in produzione.

Domande frequenti

In che modo il flusso di lavoro RAG si differenzia dal fine-tuning di un LLM?

Il workflow RAG recupera i documenti rilevanti al momento dell'inferenza e li inserisce nel prompt dell'LLM, mentre il fine-tuning modifica i pesi del modello addestrandolo su nuovi dati prima del deployment. Il RAG fornisce un accesso dinamico a informazioni aggiornate senza dover riaddestrare il modello, rendendolo più conveniente per le conoscenze che cambiano frequentemente. Il fine-tuning è più adatto per adattare lo stile di risposta, il vocabolario del dominio o la specializzazione dei task. La maggior parte dei sistemi di produzione combina entrambi: un modello sottoposto a fine-tuning per il tono del dominio, abbinato a un workflow RAG per l'accesso alla conoscenza.

Qual è la modalità di errore più comune in un sistema RAG?

La scarsa qualità del recupero è la modalità di errore più comune del RAG. Se la componente di recupero delle informazioni restituisce documenti irrilevanti, l'LLM genera risposte che sembrano sicure ma non sono basate su informazioni corrette — un errore più difficile da rilevare rispetto a evidenti allucinazioni. Gli errori di recupero derivano da un chunking inadeguato, da una discrepanza tra lo spazio semantico del modello di embedding e la distribuzione delle query, da un'insufficiente copertura della ricerca ibrida o da una knowledge base che semplicemente non contiene le informazioni richieste dagli utenti. Valutare la precisione del recupero separatamente dalla fedeltà della generazione è essenziale per diagnosticare questa classe di errori.

In che modo il RAG riduce le allucinazioni dell'AI?

Il RAG riduce le allucinazioni nei modelli di AI generativa fornendo all'LLM un contesto specifico e verificato per ogni query, anziché richiedere al modello di rispondere a memoria. Quando il prompt istruisce esplicitamente il modello a rispondere solo sulla base del contesto recuperato, il modello ha meno margine per inventare informazioni. La riduzione è proporzionale alla qualità del recupero: più i documenti recuperati sono rilevanti e completi, meno il modello deve dedurre. Il RAG non può eliminare tutte le allucinazioni dell'AI, poiché i modelli a volte interpretano erroneamente il contesto recuperato, ma ne riduce sostanzialmente la frequenza rispetto alla generazione senza recupero.

Quali fonti di dati esterne funzionano meglio con il RAG?

Le fonti ad alta densità e specifiche del dominio producono i migliori risultati di recupero: documentazione di prodotto, knowledge base tecniche, documenti sulle policy aziendali e repository interni curati. Le fonti con una formattazione coerente e confini di paragrafo chiari consentono di eseguire il chunking e l'embedding in modo più affidabile rispetto a contenuti con una struttura debole. Le fonti di conoscenza esterne di fornitori terzi — documenti normativi, standard di settore, letteratura accademica — estendono la copertura oltre i contenuti proprietari. I sistemi RAG dipendono dalla qualità delle fonti di dati esterne; documenti sorgente imprecisi o formattati in modo incoerente producono risposte imprecise, indipendentemente dalla qualità dell'architettura di recupero.

Quali sono i componenti chiave di un'architettura RAG?

Un'architettura RAG contiene quattro componenti principali: la knowledge base (l'archivio dati esterno indicizzato), il retriever (la componente di recupero delle informazioni che individua i documenti rilevanti), il livello di integrazione (la logica di orchestrazione che assembla il contesto in un prompt per l'LLM) e il generatore (il modello linguistico di grandi dimensioni che produce la risposta finale). Il database vettoriale è un elemento infrastrutturale critico della knowledge base, che memorizza le rappresentazioni numeriche dei chunk di documenti e consente una rapida ricerca per somiglianza semantica. Scopri di più sui pattern di architettura di retrieval augmented generation nella pagina del glossario Databricks.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale