Cos'è il RAG? La generazione aumentata dal recupero spiegata

La generazione aumentata dal recupero (RAG) è una tecnica in cui un sistema cerca passaggi pertinenti in un indice esterno di documenti e li passa a un modello linguistico prima che generi una risposta. Anziché affidarsi solo ai pesi fissati durante l’addestramento, il modello può rispondere usando informazioni private, interne o aggiornate di recente.

Un modello linguistico standard conosce solo ciò che era presente nei dati di addestramento fino alla sua data limite di conoscenza. Se un utente chiede informazioni sulla politica interna di rimborso della tua azienda, su una specifica API appena pubblicata o su un dato dell’account aggiornato cinque minuti fa, il modello di base non può conoscere la risposta affidandosi soltanto alla memoria. Il RAG colma questa lacuna affiancando una fase di ricerca alla generazione: prima recupera i fatti pertinenti, poi genera una risposta basata sul testo recuperato.

Che cosa significa generazione aumentata dal recupero?

La generazione aumentata dal recupero consiste nel combinare un sistema di ricerca delle informazioni con un modello di generazione del testo, affinché la risposta sia basata su documenti esterni recuperati al momento della richiesta. Invece di aspettarsi che una rete neurale memorizzi ogni fatto nei propri parametri, il RAG tratta un indice di testo esterno come un libro aperto che il modello può consultare prima di rispondere.

In generale, ogni processo RAG segue due fasi fondamentali:

1. Recupero: quando un utente invia un prompt, il sistema trasforma la richiesta in una ricerca in un archivio esterno, come un database vettoriale, un indice di ricerca per parole chiave o una combinazione dei due, e recupera i passaggi più pertinenti.
2. Generazione: il sistema inserisce i passaggi recuperati nel contesto del modello insieme alla domanda originale dell’utente, e il modello linguistico genera una risposta basata su quei passaggi.

Poiché il testo di riferimento viene recuperato dinamicamente per ogni richiesta, puoi aggiornare ciò che il sistema conosce modificando l’indice dei documenti invece di riaddestrare il modello sottostante. Per questo il RAG è una tecnica comune per creare assistenti di supporto, strumenti di ricerca nella documentazione interna e sistemi di domande e risposte specializzati. Si affianca anche ad applicazioni creative in cui i team utilizzano strumenti dedicati come AI Studio Video per la produzione multimediale e API testuali per recuperare conoscenze.

In che cosa differiva l’articolo sul RAG del 2020 dalla tecnica attuale?

Il termine «generazione aumentata dal recupero» deriva da un articolo del 2020 di Patrick Lewis e colleghi (arXiv:2005.11401), che combinava un modello sequence-to-sequence preaddestrato con un indice vettoriale denso di Wikipedia. Oggi, invece, gli sviluppatori usano di solito il termine per indicare una pipeline più semplice di costruzione del prompt. Conoscere entrambi gli approcci aiuta a capire perché il «RAG» venga descritto in due modi leggermente diversi negli articoli scientifici e nella documentazione tecnica.

L’architettura di Lewis e colleghi del 2020

Nell’articolo originale del 2020 e nel relativo approfondimento di ricerca di Meta AI, gli autori descrivevano i modelli linguistici come dotati di due tipi di memoria:

• Memoria parametrica: conoscenza conservata nei pesi della rete neurale, nello specifico un modello BART sequence-to-sequence preaddestrato.
• Memoria non parametrica: conoscenza conservata in un indice vettoriale denso esterno di articoli di Wikipedia, interrogato tramite un sistema di recupero neurale chiamato Dense Passage Retrieval (DPR).

In questa configurazione di ricerca, il sistema di recupero e il generatore venivano addestrati insieme da un capo all’altro. L’articolo presentava due formulazioni del modo in cui i passaggi recuperati influenzavano la generazione:

• RAG-Sequence: il modello usa gli stessi passaggi recuperati per generare l’intera sequenza di output.
• RAG-Token: il modello può usare passaggi recuperati diversi per ogni singolo token generato.

Nei benchmark di domande e risposte a dominio aperto riportati nelle tabelle dell’articolo (arXiv:2005.11401), RAG-Sequence ha raggiunto un punteggio di 44.5 Exact Match nel benchmark Natural Questions, superando sia i modelli di riferimento seq2seq esclusivamente parametrici sia le architetture di recupero ed estrazione testate nello studio.

L’approccio tecnico attuale

Nello sviluppo moderno delle applicazioni, i team raramente addestrano insieme un sistema di recupero e un generatore. «RAG» indica invece quasi sempre una pipeline eseguita al momento dell’inferenza, basata su modelli di embedding già pronti e API LLM per uso generale:

1. Suddividere i documenti in passaggi più piccoli, detti chunk.
2. Convertire i chunk in embedding vettoriali e salvarli in un indice.
3. Al momento della richiesta, recuperare i chunk che corrispondono meglio.
4. Se necessario, riordinare i risultati per migliorarne la pertinenza.
5. Inserire direttamente nel prompt i chunk di testo recuperati e chiedere al LLM di rispondere.

Sia l’architettura neurale end-to-end del 2020 sia l’attuale pipeline che inserisce il testo nel prompt sono chiamate RAG. Nell’ingegneria del software quotidiana, a meno che non si parli espressamente di addestrare un sistema di recupero con un modello seq2seq, si intende la pipeline moderna.

Come funziona passo dopo passo una moderna pipeline RAG?

Un sistema RAG in produzione divide il lavoro in due processi distinti: una pipeline di acquisizione offline che prepara e indicizza i documenti e una pipeline di interrogazione online che viene eseguita ogni volta che un utente pone una domanda. Guide di architettura come le indicazioni AWS sulla generazione aumentata dal recupero e la guida RAG di AWS Generative AI Innovation Center suddividono queste fasi in componenti che possono essere regolati indipendentemente.

1. La pipeline di acquisizione (indicizzazione dei dati)

Prima ancora che un utente invii un prompt, il sistema deve rendere ricercabili i documenti di origine:

• Caricamento e pulizia dei documenti: estrarre testo semplice e metadati (titoli, URL, timestamp e permessi di accesso) da PDF, wiki, database o file Markdown, eliminando formattazioni errate ed elementi ripetitivi delle pagine.
• Suddivisione in chunk: dividere i documenti lunghi in segmenti più piccoli per recuperare solo i passaggi pertinenti anziché interi manuali. Se i chunk sono troppo piccoli, perdono il contesto circostante e interrompono i concetti; se sono troppo grandi, includono informazioni irrilevanti e aumentano il consumo di token. I team spesso prevedono una piccola sovrapposizione tra chunk adiacenti, affinché le frasi ai confini non perdano significato.
• Embedding: passare ogni chunk a un modello di embedding che trasformi il testo in un vettore numerico denso rappresentativo del suo significato semantico.
• Indicizzazione: memorizzare i vettori insieme al testo originale e ai filtri sui metadati in un database vettoriale o in un motore di ricerca ibrido che combini somiglianza vettoriale e corrispondenza delle parole chiave, come BM25.

2. La pipeline di interrogazione (risposta alle domande)

Quando un utente pone una domanda durante l’esecuzione, la pipeline di interrogazione assembla il prompt:

• Elaborazione e embedding della richiesta: prendere l’input dell’utente, eventualmente riscriverlo o ampliarlo per maggiore chiarezza e convertirlo in un vettore con lo stesso identico modello di embedding usato durante l’acquisizione.
• Recupero: cercare nell’indice i chunk i cui vettori sono più vicini a quello della richiesta, combinando spesso ricerca semantica, parole chiave e filtri sui metadati, per esempio per limitare i risultati ai documenti che l’utente corrente è autorizzato a leggere.
• Riordinamento facoltativo: passare i chunk candidati iniziali a un modello di riordinamento cross-encoder, che valuta quanto direttamente ogni passaggio risponda alla richiesta e riduce l’elenco ai risultati migliori.
• Composizione del prompt e generazione: inserire i passaggi meglio classificati in un modello di prompt strutturato insieme alla domanda dell’utente, inviare l’insieme al LLM e restituire la risposta generata, spesso con citazioni che rimandano ai metadati delle fonti.

Come si confronta il RAG con le finestre di contesto lunghe e il fine-tuning?

RAG, finestre di contesto lunghe e fine-tuning risolvono aspetti diversi della personalizzazione di un modello. I sistemi in produzione spesso li combinano invece di considerarli alternative incompatibili. La scelta dipende dalla necessità di usare fatti che cambiano, comprendere molte informazioni in una singola sessione o modificare il comportamento del modello.

Aspetto	Generazione aumentata dal recupero (RAG)	Finestra di contesto lunga	Fine-tuning
Obiettivo principale	Fornire per ogni richiesta fatti pertinenti da un corpus ampio o variabile	Consentire al modello di leggere molto testo in una sola richiesta	Modificare stile, tono, formato o comportamento in attività specialistiche
Aggiornamento delle conoscenze	Aggiornare o sostituire i documenti nell’indice esterno	Sostituire i documenti originali inseriti nel prompt	Raccogliere nuovi esempi ed eseguire un altro addestramento
Impatto sui token per richiesta	Da basso a moderato (si inviano solo i chunk recuperati)	Alto (ogni documento rimane nel prompt)	Basso (conoscenze o comportamento sono incorporati nei pesi)
Attribuzione delle fonti	È semplice citare specifici chunk recuperati	Possibile, ma più difficile da individuare in input molto grandi	Difficile; i pesi non conservano citazioni esplicite dei documenti
Controllo degli accessi	Applicato a ogni richiesta tramite filtri sui metadati dell’indice	Va applicato prima di assemblare il prompt	Difficile da isolare; qualsiasi contenuto nei pesi può essere rivelato a qualsiasi utente

RAG e finestre di contesto lunghe

Poiché i modelli moderni supportano grandi finestre di contesto, può essere allettante saltare il recupero e incollare l’intera base di conoscenza in ogni prompt. Per pochi documenti brevi funziona bene, soprattutto insieme alla cache dei prompt e a una KV cache già popolata, così da non dover elaborare nuovamente da zero i prefissi ripetuti.

Quando però il corpus arriva a migliaia di file, inserire tutto nel prompt incontra due ostacoli:

1. Costi e latenza: inviare prompt enormi a ogni turno aumenta la spesa per le API e il tempo necessario a ottenere il primo token. Per questo il recupero selettivo rimane una strategia fondamentale per ridurre i costi delle API di IA.
2. Calo dell’attenzione: i modelli non prestano la stessa attenzione a ogni parte di un prompt enorme. Quando il testo irrilevante si accumula nella finestra, la precisione spesso diminuisce: il fenomeno è noto come degrado del contesto. Il RAG mantiene il prompt mirato recuperando solo i passaggi importanti per la domanda corrente.

RAG e fine-tuning

Il fine-tuning aggiorna i pesi di un modello usando esempi selezionati. È efficace quando vuoi che il modello segua uno schema di output rigoroso, adotti una specifica voce del marchio o impari una sintassi specialistica. È invece poco adatto a insegnargli fatti che cambiano rapidamente.

L’articolo di Lewis e colleghi del 2020 (arXiv:2005.11401) ha dimostrato l’importanza della memoria non parametrica per i fatti variabili mediante un esperimento di sostituzione dell’indice a caldo. Gli autori hanno testato il modello confrontando un dump di Wikipedia di dicembre 2016 con un dump di Wikipedia di dicembre 2018, usando domande su leader mondiali cambiati tra quelle date:

• Quando l’anno della domanda corrispondeva all’anno dell’indice, il modello rispondeva correttamente al 70% delle domande sui leader del 2016 con l’indice del 2016 e al 68% delle domande sui leader del 2018 con l’indice del 2018.
• Quando l’indice non corrispondeva alle domande, la precisione scendeva al 12% (indice del 2018 sui leader del 2016) e al 4% (indice del 2016 sui leader del 2018).

La semplice sostituzione dell’indice esterno ha aggiornato le conoscenze fattuali del sistema sul mondo senza riaddestrare neppure un peso del modello.

Dove fallisce il RAG?

Aggiungere il recupero a un modello linguistico riduce le supposizioni su argomenti privati o recenti, ma non elimina le allucinazioni dell’IA né garantisce risposte accurate. Poiché un sistema RAG ha più componenti, gli errori possono verificarsi sia nella ricerca sia nella generazione:

• Recupero mancato: se l’utente formula una domanda con termini diversi dal documento di origine, o se la suddivisione separa una tabella dalla sua intestazione, il sistema di recupero potrebbe non trovare il passaggio che contiene la risposta. Se il chunk giusto non arriva mai al prompt, il modello procede alla cieca.
• Documenti irrilevanti o obsoleti: un indice vale quanto i file che contiene. Se la base di conoscenza contiene sia la versione del 2023 sia quella del 2026 di una guida all’inserimento senza un filtro chiaro per le versioni superate, il sistema di recupero può fornire al modello istruzioni non aggiornate.
• Recupero eccessivo: ottenere 25 chunk «per sicurezza» è spesso controproducente. Riempire il prompt di passaggi solo marginalmente pertinenti diluisce la risposta, aumenta la latenza e può provocare il degrado del contesto, in cui il modello viene distratto da dettagli quasi pertinenti.
• Iniezione indiretta di prompt tramite il testo recuperato: se l’indice acquisisce contenuti esterni non attendibili, come email in arrivo, pagine web pubbliche o ticket inviati dagli utenti, un aggressore può inserire istruzioni malevole in un documento. Quando il documento viene recuperato e inserito nel prompt, può provocare un attacco di iniezione di prompt che dirotta il comportamento del modello.
• Contesto ignorato o interpretato male dal modello: anche quando il passaggio esatto è nel prompt, il generatore può fraintendere una negazione, combinare in modo errato due chunk separati o lasciare che le conoscenze del preaddestramento prevalgano sul testo fornito quando il passaggio recuperato contraddice le conoscenze comuni.

Lista di controllo per creare un sistema RAG affidabile

Quando un prototipo RAG passa in produzione, alcune pratiche di ingegneria rigorose evitano gli errori più comuni:

• Mantieni l’indice aggiornato e senza duplicati: crea pipeline automatiche che rimuovano i documenti eliminati, archivino le versioni sostituite e associno timestamp e URL di origine chiari a ogni chunk indicizzato.
• Recupera meno, ma meglio: invece di riempire il prompt con decine di risultati poco pertinenti, combina la ricerca ibrida (vettore + parola chiave) con filtri sui metadati e un modello di riordinamento, così da passare al generatore solo pochi passaggi informativi.
• Separa chiaramente il testo recuperato non attendibile dalle istruzioni di sistema: racchiudi i chunk recuperati in delimitatori strutturali espliciti, come tag XML o blocchi di documenti etichettati, e indica nel prompt di sistema di trattarli esclusivamente come dati di riferimento passivi, mai come comandi eseguibili.
• Indica al modello di astenersi se manca il contesto: chiedigli di dichiarare chiaramente quando i passaggi forniti non contengono informazioni sufficienti per rispondere. Un’istruzione nel prompt non garantisce che il modello obbedisca sempre, ma offre un’alternativa più chiara rispetto a indovinare in silenzio quando la ricerca non produce risultati.

Domande frequenti

Per il RAG serve sempre un database vettoriale?

No. La generazione aumentata dal recupero richiede solo un modo per ottenere testo pertinente prima di chiamare il modello. I database vettoriali sono diffusi per la ricerca per somiglianza semantica, ma molti sistemi RAG in produzione usano motori tradizionali di ricerca per parole chiave, come BM25 in Elasticsearch o la ricerca full-text di PostgreSQL, oppure ricerche ibride che combinano parole chiave e vettori.

Il RAG può impedire completamente a un LLM di avere allucinazioni?

No. Il RAG riduce le allucinazioni causate da dati di addestramento mancanti o obsoleti, perché fornisce il testo di riferimento direttamente nel prompt. Il modello può comunque leggere male un passaggio, combinare in modo errato fatti di due chunk non correlati o indovinare una risposta se il sistema di recupero trova documenti irrilevanti.

Devo usare il RAG o il fine-tuning per i documenti interni della mia azienda?

Inizia dal RAG se vuoi che un modello risponda a domande su documenti interni che cambiano nel tempo. Il RAG consente di aggiungere, modificare o eliminare immediatamente i file nell’indice e di applicare i permessi di accesso per utente al momento della richiesta. Il fine-tuning è più adatto a insegnare formati, toni o flussi di lavoro coerenti.

Fonti

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv:2005.11401
• Meta AI Research Blog — Retrieval-Augmented Generation: Streamlining the creation of intelligent natural language processing models
• AWS Prescriptive Guidance — Understanding LLMs and RAG
• AWS Machine Learning Blog — From RAG to fabric: Lessons learned from building real-world RAGs at GenAIIC – Part 1