Che cos'è la RAG (Retrieval-Augmented Generation)

Nota: Questo documento è una traduzione automatica della versione originale in inglese.

Che cos'è la RAG (Retrieval-Augmented Generation)

Immagina uno studente che sostiene un esame a libro aperto. Invece di rispondere a ogni domanda solo a memoria, lo studente sfoglia un libro di testo, trova le pagine più pertinenti, le legge e poi scrive una risposta che combina le conoscenze memorizzate con i fatti appena consultati. La Retrieval-Augmented Generation (RAG) funziona allo stesso modo per un modello linguistico di grandi dimensioni. Il modello non si affida solo a ciò che ha memorizzato durante il training — prima cerca in una base di conoscenza esterna, recupera i documenti più pertinenti e li usa come contesto aggiuntivo quando genera la risposta.

Questa tecnica è importante perché anche gli LLM più potenti hanno una data limite di conoscenza, possono "allucinare" (produrre affermazioni plausibili ma errate) e possono mancare di conoscenza specialistica di dominio. La RAG affronta tutte e tre le debolezze contemporaneamente, dando al modello accesso a fonti aggiornate, specifiche del dominio e verificabili ogni volta che risponde a una domanda.

In breve: la RAG è un pattern architetturale che combina un sistema di retrieval con un LLM. Non è un tipo di modello a sé — è un modo di lavorare con conoscenza e contesto esterni.

Come funziona

Una pipeline RAG segue una chiara sequenza di cinque passaggi. Comprendere ogni passaggio aiuta a valutare se un progetto che dichiara la RAG ha un livello di retrieval genuinamente funzionante o si limita a incapsulare una normale chiamata a un LLM.

Passaggio 1 — Query dell'utente

Il processo inizia quando un utente invia una domanda, un comando o un prompt. Questa query è il punto di partenza di tutto ciò che segue. Per esempio, un utente potrebbe chiedere: "Quali sono state le principali proposte di governance su Ethereum nell'ultimo mese?" Il sistema non tenta di rispondere solo con la memoria dell'LLM — tratta invece la query come un'istruzione di ricerca.

Passaggio 2 — Embedding della query

La query testuale grezza viene convertita in una rappresentazione numerica chiamata embedding — un vettore di numeri che cattura il significato semantico della query. Questo passaggio usa un modello di embedding specializzato (come text-embedding-ada-002 di OpenAI o un'alternativa open-source come E5 o BGE). Il vettore risultante permette al sistema di eseguire una ricerca semantica — trovare documenti in base al significato anziché alla corrispondenza esatta delle parole chiave.

Passaggio 3 — Retrieval dalla base di conoscenza

L'embedding della query viene confrontato con un database vettoriale (chiamato anche vector store) che contiene embedding pre-calcolati di documenti, passaggi o frammenti di dati. Il database restituisce i top-k elementi semanticamente più simili. I database vettoriali più comuni includono Pinecone, Weaviate, Qdrant, Milvus e Chroma.

La qualità del retrieval dipende da diversi fattori:

Strategia di chunking — come i documenti originali sono stati suddivisi in pezzi più piccoli. Chunk troppo grandi diluiscono la pertinenza; chunk troppo piccoli perdono il contesto. Trovare la dimensione giusta dei chunk è una delle decisioni ingegneristiche più incisive in una pipeline RAG.
Modello di embedding — quanto accuratamente il significato viene catturato nei vettori. Un modello di embedding debole porta a un retrieval debole indipendentemente dal database.
Ranking di pertinenza — se la ricerca restituisce risultati davvero pertinenti o solo superficialmente simili. Alcuni sistemi aggiungono un passaggio di re-ranking che usa un cross-encoder per riassegnare un punteggio ai risultati iniziali.

Passaggio 4 — Iniezione del contesto

I documenti recuperati vengono combinati con la query originale dell'utente in un unico prompt (talvolta chiamato "prompt aumentato") che viene inviato all'LLM. Il prompt istruisce tipicamente il modello a rispondere alla domanda usando il contesto fornito e a indicare quando il contesto non contiene informazioni sufficienti.

Passaggio 5 — Generazione dell'LLM e output

L'LLM legge il prompt aumentato e genera una risposta fondata sia sulla sua conoscenza pre-addestrata sia sulle evidenze recuperate. Un sistema RAG ben progettato può includere anche un livello di citazioni che collega parti della risposta a specifici documenti sorgente, dando all'utente un modo per verificare le affermazioni.

Fase	Input	Output	Componente chiave
Query	Testo dell'utente	Query grezza	Interfaccia utente
Embedding	Query grezza	Vettore della query	Modello di embedding
Retrieval	Vettore della query	Documenti pertinenti	Database vettoriale
Iniezione del contesto	Query + documenti	Prompt aumentato	Template del prompt
Generazione	Prompt aumentato	Risposta finale	LLM

Perché la RAG è importante

La RAG affronta tre limitazioni ben note degli LLM autonomi:

Allucinazioni. Gli LLM possono produrre risposte sicure ma errate. La RAG le riduce ancorando le risposte a documenti reali. Quando il modello può fare riferimento a un passaggio specifico, il rischio di invenzione cala in modo significativo.
Conoscenza obsoleta. Un modello pre-addestrato ha una data limite di conoscenza. La RAG permette l'accesso a dati freschi e continuamente aggiornati — un database esterno può essere aggiornato quotidianamente o persino in tempo reale.
Specificità di dominio. Il fine-tuning di un LLM per un dominio ristretto è costoso e richiede tempo. La RAG permette a un modello generalista di lavorare con basi di conoscenza specializzate senza retraining, rendendo più rapido ed economico il deployment di applicazioni specifiche di dominio.

RAG vs fine-tuning

Sia la RAG sia il fine-tuning mirano a migliorare le prestazioni di un LLM su compiti specifici, ma funzionano in modi fondamentalmente diversi.

Aspetto	RAG	Fine-tuning
Quando viene aggiunta la conoscenza	Al momento dell'inferenza (a ogni query)	Al momento del training (una volta, poi statica)
Costo di aggiornamento	Basso — si aggiorna la base di conoscenza	Alto — si riaddestra o si ripete il fine-tuning del modello
Freschezza della conoscenza	Può essere quasi in tempo reale	Congelata alla data limite del training
Richiede infrastruttura di training	No	Sì (GPU, dataset, pipeline di training)
Più adatta per	Richiamo fattuale, Q&A sulla documentazione	Stile, tono, formato, ottimizzazione su compiti ristretti
Verificabilità	Alta — le fonti recuperate possono essere registrate nei log	Bassa — la conoscenza è incorporata nei pesi

In pratica, molti sistemi di produzione combinano entrambi: un modello sottoposto a fine-tuning fornisce il tono e il comportamento giusti per il compito, mentre la RAG fornisce l'ancoraggio fattuale aggiornato.

Pattern RAG avanzati

La pipeline di base a cinque passaggi descritta sopra è talvolta chiamata naive RAG. Con la maturazione della tecnica, gli ingegneri hanno sviluppato varianti più sofisticate:

RAG multi-step (iterativa). Invece di recuperare una sola volta, il sistema recupera, genera una risposta intermedia, identifica le lacune di conoscenza, recupera di nuovo con una query raffinata e ripete finché la risposta non è sufficientemente completa. Questo approccio gestisce domande complesse a cui non si può rispondere con un singolo passaggio di retrieval.
RAG agentica. Il passaggio di retrieval è incapsulato all'interno di un framework di agenti AI. L'agente decide quando recuperare, quale base di conoscenza interrogare, se riformulare la query e quando ha abbastanza contesto per generare una risposta finale. Questo pattern sfuma il confine tra RAG e agenti autonomi.
Ricerca ibrida. Combinare la ricerca semantica basata su vettori con la ricerca tradizionale per parole chiave (BM25) nello stesso passaggio di retrieval. La ricerca ibrida cattura sia le corrispondenze basate sul significato sia quelle basate sui termini, migliorando il recall per le query che contengono termini tecnici specifici o nomi propri.
Graph RAG. Invece di chunk di documenti piatti, la base di conoscenza è strutturata come un knowledge graph — entità e relazioni. Il retrieval segue gli archi del grafo anziché (o in aggiunta alla) similarità vettoriale, abilitando il ragionamento multi-hop su dati strutturati. Questi pattern contano ai fini della valutazione: un progetto che descrive una pipeline graph-RAG con retrieval iterativo sta facendo un'affermazione più specifica (e più difficile da falsificare) di uno che dice semplicemente "usiamo la RAG".

Esempi reali di RAG

La RAG non è un concetto teorico — alimenta alcuni dei prodotti AI più usati oggi.

Bing Chat (Microsoft Copilot). Quando fai una domanda a Bing Chat, questo cerca sul web, recupera le pagine pertinenti e usa quelle pagine come contesto per la risposta dell'LLM. Le citazioni inline che vedi nella risposta sono un risultato diretto del passaggio di retrieval.
Perplexity. Perplexity è costruito attorno a un'architettura RAG: ogni query dell'utente attiva una ricerca web, i risultati vengono passati a un LLM e la risposta include riferimenti numerati alle fonti. L'utente può cliccare per verificare ogni affermazione.
Assistenti di conoscenza aziendali. Le aziende usano sistemi RAG interni per permettere ai dipendenti di interrogare politiche HR, documentazione ingegneristica o contratti legali in linguaggio naturale. Il livello di retrieval cerca nell'archivio documentale interno dell'azienda anziché sul web aperto. Questi esempi dimostrano che la RAG è tecnologia mainstream. Quando un progetto di AI cripto dice "usiamo la RAG", la domanda non è se la RAG sia tecnologia reale, ma se l'implementazione specifica del progetto sia solida: quali dati vengono recuperati, come sono indicizzati e se la qualità del retrieval è stata misurata.

Perché la RAG compare nei progetti di AI cripto

Molti progetti di AI cripto usano la RAG o dichiarano di usarla nelle proprie architetture. I casi d'uso comuni includono:

Assistenti di documentazione — recuperare documentazione di protocollo, whitepaper o proposte di governance per rispondere alle domande degli utenti sulle regole o sui parametri di un protocollo.
Strumenti di crypto intelligence — attingere a dati di mercato in tempo reale, eventi on-chain o articoli di notizie per generare sintesi analitiche o avvisi.
Basi di conoscenza per agenti — costruire repository strutturati che gli agenti AI possono interrogare prima di agire, garantendo che le decisioni siano informate dai dati più recenti.
Ancoraggio ai dati on-chain — collegare il livello di retrieval agli indicizzatori blockchain così che l'LLM possa rispondere a domande su saldi dei wallet, storici delle transazioni o stati degli smart contract con informazioni correnti anziché con snapshot risalenti al training.

Valori tipici del componente AI nelle schede di progetto DecAIHub che coinvolgono pattern RAG includono: "3D AI agents (RAG/memory/LLM catalog)", "AI summaries + crypto intelligence terminal" e "AgentData (real-time data streams for AI agents)".

La RAG non è un modello

Un equivoco comune è trattare la RAG come un tipo di modello AI. Non lo è. La RAG è un pattern architetturale — un modo di combinare un sistema di retrieval con un LLM. Il modello all'interno di una pipeline RAG può essere GPT, DeepSeek, Mistral o qualsiasi altro LLM. Il componente di retrieval può essere un database vettoriale, un'API di ricerca o un knowledge graph strutturato.

Dire "usiamo la RAG" ti dice come è organizzato il sistema. Non ti dice quale modello viene usato, se è proprietario o quanto è buona la qualità del retrieval. Due progetti possono entrambi dichiarare la RAG pur avendo livelli di sofisticazione enormemente diversi — uno con una base di conoscenza curata con attenzione ed embedding personalizzati, l'altro con un prototipo assemblato in fretta che raramente restituisce documenti pertinenti.

Cosa la RAG non dimostra

Usare la RAG non dimostra che l'LLM sottostante sia proprietario o sottoposto a fine-tuning. Il progetto potrebbe chiamare un'API di terze parti.
Costruire una pipeline RAG non dimostra che la qualità del retrieval sia alta. La qualità dipende dalla base di conoscenza, dalla strategia di chunking, dal modello di embedding e dalla pertinenza della ricerca.
Avere un'architettura RAG non dimostra che le risposte siano accurate. Un retrieval scadente può fornire contesto irrilevante, e l'LLM può comunque allucinare.
Menzionare la RAG su una landing page non dimostra che il sistema esegua effettivamente il retrieval. Senza evidenza Tier-1 — codice, diagrammi di architettura, log di demo — l'affermazione resta non verificata. Quando valuti un progetto di AI cripto che dichiara la RAG, cerca elementi specifici: quale base di conoscenza viene interrogata, quale modello di embedding viene usato, come viene misurata la pertinenza e se vengono pubblicate metriche di qualità.

Dove appare nelle schede di progetto DecAIHub

La RAG è tipicamente citata nel campo AI component — direttamente o attraverso descrizioni che implicano una pipeline di retrieval più generazione. Il flag AI_1 verifica se il componente AI è descritto con sufficiente specificità. Scrivere semplicemente "RAG" non basta; la scheda dovrebbe spiegare cosa viene recuperato, da dove e per quale scopo.

Da non confondere con

LLM — il motore di generazione all'interno di una pipeline RAG. La RAG aggiunge il retrieval sopra di esso.
Training — la RAG è un pattern al momento dell'inferenza. Non riaddestra il modello; aumenta il prompt con contesto recuperato.
Agente AI — un agente può usare la RAG come uno dei suoi strumenti, ma la RAG da sola non rende un sistema un agente.
Fine-tuning — il fine-tuning modifica i pesi del modello durante una fase di training. La RAG inietta conoscenza esterna al momento dell'inferenza senza modificare il modello.
Livello di retrieval / conoscenza — il componente di retrieval è una metà della RAG. La RAG aggiunge il passaggio di generazione sopra il puro retrieval.

Domande frequenti

Qual è la differenza tra RAG e fine-tuning?

Il fine-tuning altera in modo permanente i pesi del modello addestrandolo su un dataset specializzato. La nuova conoscenza diventa parte del modello stesso. La RAG lascia il modello intatto e fornisce invece documenti pertinenti al momento della query. Il fine-tuning è migliore per insegnare a un modello un nuovo stile o formato di compito; la RAG è migliore per mantenere le risposte ancorate a fatti freschi e verificabili. Molti sistemi di produzione usano entrambi — il modello sottoposto a fine-tuning gestisce tono e formato, mentre la RAG fornisce l'ancoraggio fattuale aggiornato.

La RAG rende gli LLM più accurati?

La RAG può ridurre in modo significativo le allucinazioni ancorando l'output del modello alle evidenze recuperate. Tuttavia, l'accuratezza dipende dalla qualità del retrieval. Se il sistema di retrieval restituisce documenti irrilevanti o obsoleti, l'LLM può produrre risposte sicure ma sbagliate — ora sostenute dalle evidenze sbagliate. La RAG alza il tetto dell'accuratezza ma non la garantisce. Misurare precisione e recall del retrieval è essenziale per qualsiasi deployment RAG serio.

Che cos'è un database vettoriale?

Un database vettoriale è un archivio dati specializzato progettato per contenere e cercare vettori numerici ad alta dimensionalità (embedding). Quando viene inviato l'embedding di una query, il database esegue una ricerca per similarità — tipicamente usando algoritmi come HNSW o IVF — per trovare i vettori più vicini. Ciò abilita la ricerca semantica: trovare documenti in base al significato anziché alla corrispondenza esatta delle parole chiave. I database vettoriali più diffusi includono Pinecone, Weaviate, Qdrant, Milvus e Chroma.

Come viene usata la RAG nei progetti di AI cripto?

I progetti di AI cripto usano la RAG per collegare gli LLM a dati specifici della blockchain: documentazione dei protocolli, proposte di governance, storici delle transazioni on-chain, feed di prezzi in tempo reale e codice sorgente degli smart contract. Il livello di retrieval cerca in queste fonti specializzate così che l'LLM possa rispondere a domande specifiche di dominio con dati correnti invece di affidarsi a conoscenza di training obsoleta. La qualità di tali sistemi varia ampiamente — da basi di conoscenza ben indicizzate e curate fino a configurazioni minimali che recuperano poco contesto utile.

La RAG può funzionare con dati on-chain?

Sì. Il livello di retrieval in una pipeline RAG può collegarsi a indicizzatori blockchain, subgraph o API di analisi on-chain. Quando un utente chiede del saldo di un wallet, dello storico di una transazione o dello stato di uno smart contract, il sistema di retrieval recupera i dati on-chain pertinenti e l'LLM genera una spiegazione leggibile. Le sfide principali sono la latenza (le query blockchain possono essere lente), la formattazione dei dati (i dati on-chain grezzi devono essere analizzati e suddivisi in chunk per l'embedding) e la freschezza (l'indice deve essere aggiornato abbastanza frequentemente da riflettere lo stato corrente della chain).

Vedi anche

Riferimenti esterni

Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview