RAG: cos’è la generazione aumentata dal recupero e come costruirne uno
Che cos'è il RAG, come funziona passo dopo passo e quando conviene al posto del fine-tuning: la guida per far rispondere l'AI con i tuoi documenti.

Hai mai chiesto a un chatbot informazioni sul regolamento interno della tua azienda o sull’ultima versione di un tuo documento, ricevendo una risposta sicura ma completamente sbagliata? Succede perché un modello linguistico risponde in base a ciò che ha imparato durante l’addestramento, non in base ai tuoi dati. Il RAG, sigla di Retrieval-Augmented Generation, nasce proprio per risolvere questo problema.
In questa guida vedi che cos’è il RAG, come funziona passo dopo passo, quando conviene usarlo al posto del fine-tuning e come costruirne uno in modo ordinato, evitando gli errori che rovinano la maggior parte dei primi progetti.
Il testo è pensato per restare valido nel tempo: gli strumenti cambiano ogni mese, i principi no.
Che cos’è il RAG e perché serve
Il RAG, in italiano generazione aumentata dal recupero, è una tecnica che affianca a un modello linguistico un sistema di ricerca. Prima di rispondere, il sistema cerca nei documenti che gli hai messo a disposizione i passaggi più pertinenti alla domanda, li inserisce nel prompt e chiede al modello di formulare la risposta usando quei passaggi come fonte.
In pratica il modello smette di rispondere a memoria e comincia a rispondere con il libro aperto.
Il problema che il RAG risolve
Un modello linguistico ha tre limiti strutturali che chiunque lavori con l’AI prima o poi incontra. Il primo è la data di addestramento: tutto ciò che è successo dopo non è nella sua conoscenza, a meno che qualcuno non glielo fornisca. Il secondo è la mancanza di accesso ai tuoi dati privati, come contratti, manuali, ticket di assistenza, procedure interne o archivi di prodotto. Il terzo è la tendenza ad allucinare, cioè a produrre risposte plausibili ma inventate quando non conosce davvero la risposta.
Il RAG attenua tutti e tre i limiti nello stesso momento, senza ricostruire il modello da capo.
Lo fa spostando la conoscenza fuori dal modello. I documenti restano in un archivio che puoi aggiornare quando vuoi, e il modello si limita a leggerli al momento giusto. Se cambia un prezzo o una procedura, aggiorni il documento e la risposta cambia dal minuto successivo, senza alcun riaddestramento.
Una metafora utile
Immagina un consulente molto preparato che però non conosce la tua azienda. Puoi mandarlo a studiare per mesi, e questo equivale al fine-tuning, oppure puoi dargli accesso a una biblioteca ordinata e farlo consultare gli scaffali giusti prima di ogni risposta, e questo è il RAG. Nel secondo caso il consulente è operativo subito, e se un libro cambia basta sostituirlo.
Come funziona il RAG passo dopo passo
Un sistema RAG si compone di due fasi distinte. La prima avviene una volta sola, o ogni volta che aggiorni i documenti, e prepara la conoscenza. La seconda avviene a ogni domanda dell’utente, e produce la risposta.
Fase 1: preparare i documenti (indicizzazione)
Si parte dalla raccolta delle fonti: PDF, pagine web, documenti di testo, wiki interne, trascrizioni, righe di database. La qualità di questo passaggio decide gran parte della qualità finale. Se i documenti sono confusi, duplicati o scaduti, il sistema risponderà in modo confuso, duplicato e scaduto.
Il testo va poi estratto e ripulito. I PDF, in particolare, nascondono insidie: colonne mescolate, tabelle spezzate, intestazioni e piè di pagina ripetuti in ogni pagina. Una pulizia accurata qui fa risparmiare ore di debug più avanti.
Il passo successivo è il chunking, cioè la suddivisione dei documenti in porzioni di testo di dimensione gestibile. Non puoi dare al modello un intero manuale da trecento pagine a ogni domanda, sarebbe lento, costoso e dispersivo. Si ricavano quindi blocchi di poche centinaia di parole, spesso con una piccola sovrapposizione tra un blocco e il successivo, così che una frase importante non venga tagliata a metà tra due porzioni.
Il criterio di taglio conta molto. Spezzare per numero fisso di caratteri è semplice ma brutale, mentre spezzare rispettando titoli, paragrafi e sezioni conserva il senso del testo e migliora i risultati.
Fase 1 bis: trasformare il testo in numeri
Ogni blocco viene convertito in un embedding, un vettore di numeri che rappresenta il significato del testo. Due blocchi che parlano della stessa cosa, anche con parole diverse, hanno vettori vicini nello spazio matematico. Se vuoi capire meglio questo meccanismo, trovi una spiegazione dettagliata in cosa sono gli embedding e i database vettoriali.
I vettori vengono salvati in un database vettoriale, o in un normale database che supporti la ricerca per similarità, insieme al testo originale e a metadati utili come titolo, data, autore e fonte.
A questo punto la tua biblioteca è pronta e catalogata.
Fase 2: rispondere alla domanda (recupero e generazione)
Quando l’utente scrive una domanda, il sistema la trasforma in un embedding con lo stesso modello usato per i documenti. Poi cerca nel database i blocchi i cui vettori sono più vicini a quello della domanda, di solito i primi tre, cinque o dieci. È la fase di retrieval, il recupero.
I blocchi trovati vengono inseriti nel prompt insieme alla domanda, accompagnati da istruzioni chiare. Un prompt tipico dice al modello di rispondere solo usando il contesto fornito, di citare la fonte di ogni affermazione e di ammettere di non sapere quando l’informazione manca. Se vuoi approfondire come scrivere queste istruzioni, la guida su cos’è un system prompt e come scriverlo ti dà una base solida.
Infine il modello genera la risposta, che nasce dal contesto recuperato e non dalla sua memoria generale. Questa è la fase di generation.
Come il modello usa il contesto
Il modello legge i blocchi recuperati insieme alla domanda grazie al meccanismo di attenzione tipico delle architetture moderne, che puoi approfondire in Transformer in AI: cosa sono e come funziona il meccanismo di attenzione. Più il contesto è pertinente e ben ordinato, più la risposta sarà precisa.
Un contesto pieno di rumore, invece, confonde anche i modelli migliori.
RAG, fine-tuning e prompt lunghi: quale scegliere
Quando si vuole che un modello conosca dati specifici, esistono tre strade principali. Capire le differenze evita di investire settimane sulla soluzione sbagliata.
Mettere tutto nel prompt
Con le finestre di contesto sempre più ampie, a volte basta incollare i documenti direttamente nella conversazione. Per un singolo contratto o un breve manuale è la soluzione più semplice e spesso la migliore. I limiti emergono quando i documenti crescono: i costi per ogni richiesta aumentano, le risposte rallentano e il modello tende a perdere dettagli sepolti in mezzo a testi molto lunghi.
Fine-tuning
Il fine-tuning modifica i pesi del modello addestrandolo su esempi aggiuntivi. È indicato quando vuoi cambiare lo stile, il tono, il formato delle risposte o insegnare un compito molto specifico e ripetitivo. È molto meno adatto a inserire conoscenza fattuale che cambia nel tempo: le informazioni apprese in questo modo sono difficili da aggiornare, da verificare e da citare.
Il fine-tuning insegna al modello come comportarsi, il RAG gli dice cosa sapere.
RAG
Il RAG è la scelta naturale quando la conoscenza è ampia, cambia spesso e deve essere verificabile. Offre un grande vantaggio per l’affidabilità: ogni risposta può indicare da quale documento proviene, così l’utente controlla in pochi secondi. Ha però un costo di progettazione, perché richiede una pipeline da costruire, testare e mantenere.
Una regola pratica per decidere
Se i documenti entrano comodamente nel contesto e li usi raramente, incollali nel prompt. Se la base di conoscenza è grande o in continuo aggiornamento, usa il RAG. Se il problema è lo stile o il formato, valuta il fine-tuning. E nulla vieta di combinarli: molti sistemi maturi usano un modello rifinito sul tono dell’azienda, alimentato da una pipeline RAG sui dati aggiornati.
Come costruire un sistema RAG: la guida operativa
Costruire un primo prototipo è più semplice di quanto sembri, ma costruirne uno affidabile richiede metodo. Ecco il percorso consigliato.
1. Definisci il caso d’uso e le domande
Prima di scrivere codice, elenca venti o trenta domande reali che gli utenti porranno, insieme alle risposte corrette e ai documenti da cui derivano. Questo piccolo insieme diventa il tuo banco di prova: senza di esso non saprai mai se una modifica migliora o peggiora il sistema.
2. Scegli e prepara le fonti
Seleziona solo documenti affidabili e aggiornati. Elimina le versioni obsolete, i duplicati e i file irrilevanti. Aggiungi metadati sensati, come data, categoria e livello di riservatezza, perché ti serviranno per filtrare i risultati.
Meno documenti ma curati battono quasi sempre una montagna di materiale disordinato.
3. Scegli la strategia di chunking
Parti da blocchi di circa trecento o cinquecento parole con una sovrapposizione del dieci o quindici per cento, rispettando titoli e paragrafi. Poi sperimenta: documenti legali, schede prodotto e conversazioni di supporto richiedono tagli diversi. Misura i risultati sul tuo banco di prova e scegli la configurazione che funziona meglio.
4. Scegli il modello di embedding e il database
Il modello di embedding deve supportare bene l’italiano, se i tuoi documenti sono in italiano. Verifica la qualità con le tue domande reali, non solo con le classifiche generali. Per il database vettoriale, per un prototipo basta una soluzione leggera in locale. Per la produzione contano scalabilità, filtri sui metadati, costi e facilità di aggiornamento.
5. Costruisci il recupero
Il recupero decide se il modello vedrà o no le informazioni giuste, e quindi è il punto più delicato dell’intero sistema. Due miglioramenti sono ormai considerati standard. Il primo è la ricerca ibrida, che combina la ricerca semantica con quella per parole chiave: la prima capisce il significato, la seconda eccelle con codici, sigle e nomi propri. Il secondo è il reranking, un passaggio in cui un modello più preciso riordina i primi risultati prima di inviarli al modello generativo.
Questi due accorgimenti, da soli, risolvono spesso metà dei problemi di qualità.
6. Scrivi il prompt di generazione
Il prompt deve vincolare il modello al contesto. Chiedi di rispondere solo con le informazioni presenti nei blocchi forniti, di indicare la fonte e di dichiarare esplicitamente quando la risposta non è nei documenti. Una frase come “se non trovi la risposta nel contesto, dillo chiaramente” riduce molto le invenzioni.
Chiedi anche un formato di risposta coerente: una sintesi breve, poi eventuali dettagli, poi le fonti citate.
7. Valuta, misura, migliora
Usa il banco di prova per verificare due cose separate. La prima è se il recupero porta davvero i blocchi giusti tra i primi risultati. La seconda è se, dati i blocchi giusti, il modello risponde correttamente e senza aggiungere elementi inventati. Separare le due valutazioni ti dice dove intervenire: se il problema è nel recupero, lavori su chunking, embedding e ricerca ibrida, se è nella generazione, lavori sul prompt e sul modello.
Le metriche per misurare la qualità di un RAG
Per rendere concreta la valutazione conviene ragionare su quattro misure, due dedicate al recupero e due alla risposta. Tenerle separate ti evita di correggere il punto sbagliato.
- Context precision: quanti dei blocchi recuperati sono davvero pertinenti alla domanda. Se è bassa, il modello riceve molto rumore nel prompt.
- Context recall: quanti dei blocchi utili presenti nell’archivio vengono effettivamente trovati. Se è bassa, informazioni importanti restano fuori dalla risposta.
- Faithfulness: quanto la risposta è sostenuta dai documenti recuperati, oppure se il modello aggiunge affermazioni che nei testi non ci sono.
- Answer relevance: se la risposta, oltre a essere corretta, risponde proprio alla domanda posta.
Calcolare queste misure a mano su centinaia di domande è lungo. Per questo esistono framework open source come RAGAS, che usa un modello linguistico come giudice per stimarle in automatico, e alternative come TruLens e DeepEval, che aggiungono pannelli di monitoraggio per i sistemi in produzione.
Se vuoi un ripasso sui concetti di precisione e richiamo da cui derivano queste metriche, trovi una spiegazione chiara nella guida alle metriche di valutazione nel machine learning. Il giudizio automatico resta comunque un’approssimazione: affiancalo sempre a una verifica manuale su un campione di risposte.
Gli errori più comuni e come evitarli
Chi costruisce il primo RAG tende a inciampare sempre negli stessi punti. Conoscerli in anticipo è un vantaggio enorme.
Documenti sporchi, risposte sporche
L’errore più frequente è caricare tutto senza pulire. Un PDF con tabelle rovinate produce blocchi illeggibili, e il sistema recupera testo senza senso. Controlla a mano un campione dei blocchi creati: se non li capisci tu, non li capirà nemmeno il modello.
Blocchi troppo piccoli o troppo grandi
Blocchi minuscoli perdono il contesto, e una frase da sola spesso non significa nulla. Blocchi enormi diluiscono il segnale e consumano spazio nel prompt. Il giusto equilibrio si trova solo per tentativi, misurando.
Recuperare troppo o troppo poco
Passare al modello venti blocchi per sicurezza sembra prudente, ma più rumore significa più confusione. Passarne uno solo rischia di escludere l’informazione decisiva. Parti da pochi blocchi ben selezionati e aumenta solo se i test lo giustificano.
Nessun controllo sulle fonti
Un sistema che risponde senza citare le fonti non permette di verificare nulla. Mostra sempre all’utente da quale documento e da quale sezione proviene la risposta. Oltre a rafforzare la fiducia, ti aiuta a scoprire quando il sistema sbaglia.
Ignorare l’aggiornamento
Un RAG non è un progetto da consegnare e dimenticare. Documenti che cambiano, nuove versioni e file eliminati richiedono una procedura di reindicizzazione automatica, altrimenti il sistema continuerà a rispondere con informazioni superate.
Dove il RAG funziona meglio: esempi pratici
Il RAG ha trovato spazio in moltissimi contesti perché risolve un bisogno universale: far parlare i documenti.
Assistenza clienti
Un assistente alimentato da manuali, guide e storico dei ticket risponde alle domande frequenti in modo coerente e cita l’articolo di riferimento. Quando non trova la risposta, passa la richiesta a un operatore umano con il contesto già raccolto.
Knowledge base aziendale
Procedure, politiche interne, onboarding e documentazione tecnica diventano interrogabili in linguaggio naturale. Un nuovo collega non deve più cercare per mezz’ora nella wiki: chiede e riceve la risposta con il link alla pagina giusta.
Ricerca legale, medica e normativa
In settori in cui l’accuratezza è decisiva, il RAG permette di interrogare grandi raccolte di testi e di ottenere risposte ancorate a passaggi precisi. Resta indispensabile la verifica di un professionista, ma il tempo di ricerca si riduce drasticamente.
Contenuti, SEO e marketing
Chi produce contenuti può alimentare un sistema con linee guida del brand, dati di prodotto e articoli già pubblicati, ottenendo bozze coerenti con il proprio stile e con informazioni corrette. Anche il lavoro di ricerca delle fonti diventa più rapido.
Assistenti personali sui propri appunti
Anche a livello individuale il RAG è utile: note, email archiviate, articoli salvati e documenti di studio possono essere interrogati con una semplice domanda, trasformando un archivio disordinato in una memoria consultabile.
Oltre il RAG classico: le evoluzioni
Il RAG descritto finora è la versione di base, ma il campo evolve rapidamente. Vale la pena conoscere almeno le direzioni principali.
RAG agentico
Nel RAG agentico il modello non si limita a una sola ricerca. Decide da solo quali strumenti usare, riformula la domanda, cerca più volte e confronta i risultati prima di rispondere. È più potente sulle domande complesse, ma anche più lento e costoso. Un esempio di questa evoluzione lo trovi nell’approfondimento su Mistral Agentic Search e la ricerca agentica oltre il RAG.
RAG con grafi di conoscenza
Alcuni sistemi affiancano alla ricerca vettoriale un grafo di conoscenza, una rappresentazione di entità e relazioni. Questo approccio aiuta quando la risposta richiede di collegare informazioni sparse in documenti diversi, cosa in cui la semplice similarità tra testi fatica.
RAG multimodale
Le fonti non sono solo testo. Immagini, tabelle, grafici, audio e video possono essere indicizzati e recuperati. Questo apre scenari come interrogare un archivio di presentazioni o di registrazioni di riunioni.
Contesti lunghi e RAG: complementari
Con modelli capaci di gestire contesti molto lunghi, c’è chi si chiede se il RAG sia destinato a scomparire. In realtà i due approcci si completano: il RAG seleziona e riduce, il contesto lungo permette di includere più materiale utile. Una pipeline ben progettata usa entrambi, scegliendo caso per caso.
Riformulare la domanda: HyDE e scomposizione
Una parte dei problemi di recupero nasce dalla domanda stessa. Una richiesta breve, scritta come la scriverebbe un utente, spesso somiglia poco ai documenti che contengono la risposta, e la ricerca per similarità fatica a collegarli.
La tecnica nota come HyDE, da Hypothetical Document Embeddings, aggira l’ostacolo così: prima chiedi al modello di scrivere una risposta ipotetica alla domanda, poi usi quel testo, e non la domanda originale, per cercare nell’archivio. La risposta ipotetica può contenere errori, ma per forma e lessico assomiglia ai documenti rilevanti più di una domanda di poche parole, e questo migliora il recupero.
La scomposizione della domanda serve invece per le richieste complesse, quelle che richiedono di mettere insieme informazioni da più documenti. Il sistema spezza la domanda in sotto domande più semplici, esegue una ricerca per ciascuna e poi unisce i risultati prima della generazione. Per esempio, una domanda come “quali differenze ci sono tra le condizioni di garanzia dei prodotti A e B” diventa due ricerche distinte, una per prodotto.
Entrambe le tecniche aggiungono una chiamata al modello prima della ricerca, quindi costano un po’ di tempo in più: introducile solo se il banco di prova mostra che il recupero è il punto debole.
Limiti, rischi e sicurezza del RAG
Presentare il RAG come una cura per ogni male sarebbe scorretto. Ha limiti precisi che conviene conoscere.
Il primo è che non elimina del tutto le allucinazioni. Se il recupero porta blocchi sbagliati o incompleti, il modello può comunque combinare un’affermazione errata, magari con l’aria autorevole di una citazione. Per questo la valutazione continua resta necessaria.
Il secondo riguarda la riservatezza. Se indicizzi documenti sensibili, devi garantire che ogni utente veda solo ciò che ha il diritto di vedere. I permessi vanno applicati nel momento del recupero, filtrando per metadati, e non lasciati alla buona volontà del modello. Valuta con attenzione anche dove vengono elaborati i dati, soprattutto se contengono informazioni personali soggette al GDPR.
Il terzo è la prompt injection indiretta. Un documento indicizzato potrebbe contenere istruzioni nascoste pensate per manipolare il modello, per esempio una frase che gli ordina di ignorare le regole precedenti. Tratta sempre il contenuto recuperato come dato e mai come comando, limita i poteri degli agenti che leggono fonti non fidate e controlla l’origine dei documenti.
Il quarto è il costo di manutenzione. Pipeline, indici, valutazioni e aggiornamenti richiedono tempo continuativo. Calcola questo impegno prima di partire, non dopo.
Strumenti e librerie per iniziare
Non serve partire da zero. Esistono framework open source che offrono i blocchi principali di una pipeline RAG: caricamento dei documenti, chunking, embedding, collegamento ai database vettoriali e gestione dei prompt. Tra i più conosciuti ci sono LangChain e LlamaIndex, entrambi molto usati nei progetti reali.
Per i database vettoriali puoi scegliere tra soluzioni dedicate, come Qdrant, Weaviate, Pinecone o Chroma, e database tradizionali con estensioni vettoriali, come PostgreSQL con pgvector. La scelta dipende da volumi, budget e competenze del tuo team.
Se non vuoi scrivere codice, molte piattaforme AI permettono di caricare documenti e interrogarli direttamente: sono un ottimo modo per capire il concetto prima di costruire qualcosa di personalizzato. Il consiglio è procedere per gradi: prima un prototipo semplice, poi la misurazione, poi le ottimizzazioni.
Gli strumenti cambiano in fretta, quindi verifica sempre la documentazione aggiornata prima di decidere.
Domande frequenti sul RAG
Il RAG richiede di addestrare un modello?
No. Il modello resta quello che è, e la conoscenza aggiuntiva viene fornita al momento della domanda. Per questo il RAG è più rapido e più economico del fine-tuning per aggiungere conoscenza.
Quanti documenti servono per iniziare?
Per un prototipo bastano poche decine di documenti ben scelti. L’importante è che coprano le domande reali che vuoi servire.
Posso usare il RAG con modelli open source e in locale?
Sì. Molte pipeline funzionano interamente in locale con modelli aperti per embedding e generazione, una scelta frequente quando i dati sono riservati. Le prestazioni dipendono dalle risorse hardware disponibili.
Il RAG funziona bene in italiano?
Dipende dai modelli scelti. Molti modelli recenti gestiscono bene l’italiano, ma conviene sempre testare embedding e generazione sui tuoi testi reali, senza fidarsi delle sole classifiche internazionali.
Come capisco se il mio RAG funziona?
Con un banco di prova di domande e risposte attese, misurando separatamente la qualità del recupero e quella della generazione. Senza questa misura stai solo andando a intuito.
Conclusioni: dai ai tuoi dati una voce affidabile
Il RAG è oggi uno dei modi più concreti per portare l’intelligenza artificiale dentro un contesto reale: usa i tuoi documenti, resta aggiornabile e permette di verificare ogni risposta. Non è magia e non è gratuito in termini di impegno, ma con una buona preparazione dei dati, un recupero curato e una valutazione costante ottiene risultati che un modello da solo non può dare.
Il modo migliore per capirlo è provarlo. Scegli un piccolo insieme di documenti, scrivi venti domande reali, costruisci un prototipo e misura. Poi migliora un passaggio alla volta.
Hai già un’idea di dove applicare il RAG nel tuo lavoro? Continua a seguire le guide di intelligenzaartificiale.net per approfondire embedding, prompt e agenti, e trasforma i tuoi documenti in un assistente davvero utile.
Tutta l'AI della settimana, in 5 minuti, nella tua email
- Le guide e le notizie della settimana, divise per rubrica
- Solo ciò che conta, verificato e spiegato in italiano
- Niente spam, ti cancelli con un clic
Daniele Della Corte
Fondatore di IntelligenzaArtificiale.net · Consulente SEO e AI dal 2008
Prima della pubblicazione controlla fonti, numeri e nomi, e risponde personalmente di quello che leggi. Lavora con l'intelligenza artificiale da oltre 7 anni: ha fondato BeProud.ai e ha progettato la redazione di questo sito.
Consulenza AIVuoi applicare l'AI al tuo lavoro? Ti aiuto a scegliere cosa automatizzare e a realizzarlo.
Scopri la consulenza