RAG: cos’è, come funziona e quando serve davvero
Il RAG permette a un modello AI di cercare informazioni in fonti esterne prima di rispondere. Ecco come funziona davvero, quando serve e quali errori evitare.
Il RAG, acronimo di Retrieval-Augmented Generation, è un’architettura che permette a un modello di intelligenza artificiale di recuperare informazioni da fonti esterne prima di generare una risposta. Invece di affidarsi soltanto a ciò che il modello ha appreso durante l’addestramento, il sistema cerca i contenuti pertinenti, li inserisce nel contesto e chiede al modello di rispondere usando quelle informazioni.
È il meccanismo dietro molti chatbot aziendali, assistenti documentali e motori di ricerca interni. Ma la definizione semplice nasconde il problema vero: recuperare un documento non significa aver recuperato il documento giusto, e averlo recuperato non garantisce che il modello lo interpreti correttamente.
Il RAG non è quindi una cura automatica contro le allucinazioni. È una pipeline che può rendere una risposta più aggiornata, verificabile e aderente ai dati aziendali, a condizione che fonti, ricerca, permessi e valutazione siano progettati bene.
Che cos’è il RAG
Il RAG combina due operazioni: il recupero di informazioni e la generazione di una risposta. Il termine è stato formalizzato nel paper del 2020 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, che descrive modelli capaci di affiancare alla memoria incorporata nei parametri una memoria esterna interrogabile.
La distinzione è utile ancora oggi. Un modello linguistico possiede una memoria parametrica: ciò che ha appreso durante l’addestramento. Una pipeline RAG gli fornisce una memoria non parametrica: documenti, record, pagine o altri dati che possono essere aggiornati senza riaddestrare il modello.
Se chiedi a un assistente quali condizioni di reso applica il tuo e-commerce, il modello non dovrebbe inventare una politica plausibile. Il sistema dovrebbe cercare la versione vigente del documento sui resi, selezionare il passaggio pertinente e produrre la risposta a partire da quel testo, possibilmente indicando la fonte.
Questa è la promessa concreta del RAG: non rendere il modello onnisciente, ma dargli il contesto necessario al momento della domanda.
Come funziona una pipeline RAG
Una pipeline RAG funziona in due momenti distinti: prima prepara le fonti, poi recupera il contesto utile per ogni richiesta.
Nella fase di preparazione, i documenti vengono acquisiti, ripuliti e divisi in porzioni chiamate chunk. Il sistema può trasformare ogni chunk in un embedding, cioè una rappresentazione numerica del significato, e salvarlo in un indice interrogabile. Titolo, URL, data, reparto, lingua e livello di accesso possono essere conservati come metadati.
Quando arriva una domanda, il sistema la trasforma in una query di ricerca. Recupera i passaggi potenzialmente pertinenti, può riordinarli con un reranker e costruisce un prompt che contiene istruzioni, domanda e fonti. Solo a quel punto il modello genera la risposta.
Il flusso essenziale è questo:
Fonti → pulizia e suddivisione → indicizzazione → domanda → recupero → selezione del contesto → generazione → risposta con fonti
Le architetture reali aggiungono controlli di autenticazione, filtri sui metadati, logging, cache e valutazione. La reference architecture di Google Cloud separa infatti ingestione, servizio delle risposte e valutazione della qualità: un segnale chiaro che il RAG in produzione non coincide con il semplice caricamento di alcuni PDF.
Embedding, chunk e database vettoriale
Embedding, chunk e database vettoriale sono componenti frequenti del RAG, ma nessuno dei tre coincide con il RAG stesso.
Un chunk è una porzione di contenuto. Se è troppo grande contiene molto rumore; se è troppo piccolo perde il contesto che consente di comprenderlo. Non esiste una misura universale corretta. Un catalogo prodotti, un contratto e una guida tecnica hanno strutture diverse e richiedono strategie diverse.
Un embedding rappresenta un contenuto come una sequenza di numeri, così da confrontare la vicinanza semantica tra domanda e documenti. È utile quando le parole usate dall’utente non coincidono con quelle della fonte. “Non riesco più a entrare” potrebbe così recuperare una procedura intitolata “Ripristino delle credenziali”.
Il database vettoriale conserva e cerca queste rappresentazioni. Tuttavia un sistema può usare anche ricerca lessicale, SQL, filtri o una combinazione di metodi. La ricerca ibrida, che unisce corrispondenza testuale e semantica, è spesso più solida quando codici prodotto, nomi propri e termini esatti contano quanto il significato generale.
Anche i valori predefiniti vanno trattati come punto di partenza. Per esempio, la documentazione OpenAI dei vector store indica per il chunking automatico una dimensione massima di 800 token e una sovrapposizione di 400 token. È una scelta operativa del servizio, non una legge valida per ogni corpus. Il test decisivo rimane verificare se le domande reali recuperano il passaggio necessario.
RAG, fine-tuning, prompt lunghi e ricerca web
Il RAG serve a recuperare conoscenza al momento della richiesta; fine-tuning, contesto lungo e ricerca web risolvono problemi diversi.
Approccio Che cosa cambia Quando è utile Limite principale RAG Il contesto fornito a ogni domanda Dati privati, aggiornabili o molto estesi Dipende dalla qualità del recupero Fine-tuning Il comportamento appreso dal modello Formato, stile o compito ripetitivo Non è un database aggiornabile Prompt con documenti Il contesto della singola conversazione Pochi file e analisi circoscritta Costi e rumore crescono col contesto Ricerca web Le fonti pubbliche disponibili online Informazioni recenti e aperte Controllo limitato su qualità e copertura
Il fine-tuning non è il modo ideale per insegnare al modello un listino che cambia ogni mese. Il RAG consente di aggiornare la fonte, reindicizzarla e renderla disponibile senza un nuovo addestramento.
Un contesto molto ampio può invece essere sufficiente quando i documenti sono pochi e la domanda richiede una lettura complessiva. La stessa guida Google sul RAG osserva che un contesto lungo può funzionare bene per fornire direttamente il materiale, mentre il recupero diventa utile quando le informazioni superano lo spazio disponibile o quando occorre ridurre token, tempi e costi.
La ricerca web è una forma di recupero, ma non equivale a una knowledge base aziendale. Cerca fonti pubbliche; non conosce automaticamente procedure interne, permessi e versione approvata di un documento.
RAG e MCP non sono la stessa cosa
Il RAG recupera informazioni per fondare una risposta; MCP standardizza il collegamento tra un’applicazione AI e strumenti o fonti esterne.
Un MCP server può esporre un tool che interroga una knowledge base RAG. L’assistente invoca il tool, il server esegue la ricerca e restituisce i passaggi pertinenti. Ma il RAG può esistere senza MCP e un server MCP può esporre funzioni che non usano alcuna ricerca semantica, come creare un task o leggere una metrica da un’API.
Confondere i due concetti porta a progetti costruiti per moda. Prima si chiarisce il bisogno: recuperare conoscenza, eseguire azioni o entrambe le cose. Poi si sceglie l’architettura.
Quando il RAG serve davvero
Il RAG serve quando le risposte dipendono da un insieme di fonti troppo ampio, variabile o riservato per essere affidato alla sola conoscenza del modello.
Un caso evidente è l’assistenza interna: manuali, procedure, policy e documentazione tecnica cambiano, appartengono a reparti diversi e non devono essere visibili a tutti. Un altro è il supporto clienti, dove l’assistente deve distinguere prodotti, piani e condizioni contrattuali. Nei team commerciali può recuperare schede, casi studio e risposte approvate; in ambito editoriale può ritrovare dati, linee guida e materiali proprietari.
Ho costruito beknow.io proprio partendo da un problema simile: rendere interrogabili dati e operazioni SEO senza costringere l’utente a esportare ogni volta file e ricostruire il contesto. Nel collegamento tramite MCP, beknow espone 32 operazioni di lettura e 19 di scrittura sotto due strumenti di alto livello. Non tutte queste operazioni sono RAG: alcune leggono dati strutturati. È un esempio utile perché mostra che il valore non sta nell’etichetta tecnica, ma nel consegnare al modello il dato giusto attraverso il percorso più adatto.
Per i contenuti, il verticale già pubblicato su RAG e contenuti SEO personalizzati spiega come usare materiali proprietari per evitare testi generici e incoerenti con il brand. Quello è un caso specifico; l’architettura descritta qui può servire anche a supporto, ricerca interna, compliance e prodotto.
Quando il RAG è una complicazione inutile
Il RAG è una complicazione inutile quando il corpus è piccolo, stabile e può essere fornito direttamente, oppure quando il problema non riguarda la conoscenza.
Se devi sintetizzare tre documenti caricati dall’utente, può bastare inserirli nel contesto. Se vuoi che il modello rispetti sempre un formato JSON, il punto è l’output strutturato, non il recupero. Se devi conoscere il saldo aggiornato di un cliente, può essere più corretto interrogare un database tramite una funzione autorizzata invece di creare embedding dei movimenti.
Esiste poi un errore frequente: costruire una knowledge base prima di avere domande reali. Si indicizzano migliaia di pagine, si celebra la demo con due query facili e soltanto dopo si scopre che gli utenti cercano codici, confronti, eccezioni o informazioni assenti dalle fonti.
La sequenza migliore parte da un set di domande rappresentative e da risposte attese. L’architettura viene scelta in base a ciò che occorre recuperare, non al tool che si desidera provare.
Perché un sistema RAG può sbagliare
Un sistema RAG può sbagliare in almeno due punti: può recuperare un contesto inadeguato oppure generare male nonostante un contesto corretto.
Il primo è un errore di retrieval. Il documento non è stato acquisito, il chunk utile è stato separato dal titolo, i metadati sono errati oppure la ricerca privilegia un passaggio semanticamente simile ma non applicabile. In questo caso il modello parte già svantaggiato.
Il secondo è un errore di generazione. La fonte corretta è presente, ma il modello combina due regole incompatibili, ignora una data o formula una conclusione non sostenuta dal testo.
La presenza di una citazione non risolve automaticamente il problema. Una risposta può citare un documento autentico che non dimostra ciò che viene affermato. Per questo la valutazione dovrebbe distinguere almeno tre domande: il recupero ha trovato le fonti giuste? La risposta è fedele alle fonti? La risposta soddisfa davvero la richiesta?
Come progettare un RAG affidabile
Un RAG affidabile nasce da fonti governate e da test ripetibili, non dalla scelta del database vettoriale più noto.
Il primo lavoro riguarda i documenti: proprietario, data di validità, duplicati, versioni e permessi. Se nel corpus convivono due politiche di reso diverse senza metadati temporali, il sistema non ha elementi sufficienti per scegliere quella vigente.
Il secondo riguarda il recupero. Bisogna costruire un insieme di domande reali, annotare quali fonti dovrebbero essere trovate e misurare i risultati. Solo dopo ha senso confrontare chunking, modelli di embedding, ricerca ibrida e reranking.
Il terzo riguarda la risposta. Il prompt deve chiarire quando il modello può rispondere, come deve citare e cosa fare quando le fonti non bastano. In molti contesti aziendali, “non ho informazioni sufficienti” è un risultato migliore di una risposta fluida ma inventata.
Il quarto riguarda la sicurezza. I filtri di autorizzazione devono essere applicati prima che il contenuto entri nel prompt. Non basta chiedere al modello di ignorare i documenti riservati. La separazione va garantita dall’applicazione e dal livello dati.
Infine serve osservabilità: domanda, documenti recuperati, punteggi, risposta, feedback e versione della pipeline. Senza queste tracce, quando qualcosa va storto si vede soltanto l’ultima frase, non il punto in cui il sistema ha fallito.
Quanto costa realizzare un sistema RAG
Il costo di un sistema RAG dipende più dalla qualità richiesta e dall’integrazione con i processi che dal numero di documenti.
Una prova interna su un corpus limitato può utilizzare servizi gestiti di file search e richiedere poco sviluppo. Un sistema destinato ai clienti deve invece gestire autenticazione, aggiornamenti, fonti multiformato, valutazione, monitoraggio e fallback. Se tratta dati sensibili, entrano in gioco conservazione, residenza dei dati e audit degli accessi.
I costi operativi comprendono elaborazione dei documenti, storage, ricerca, eventuale reranking e token inviati al modello. Ridurre i chunk o il numero di passaggi abbassa la spesa, ma può peggiorare la copertura. Anche qui non esiste una configurazione migliore in assoluto: occorre ottimizzare rispetto a un set di richieste e a una soglia di qualità accettabile.
FAQ sul RAG
Che cosa significa RAG nell’intelligenza artificiale?
RAG significa Retrieval-Augmented Generation. È un approccio in cui il sistema recupera informazioni da fonti esterne e le fornisce a un modello generativo come contesto per costruire la risposta.
Come funziona il RAG?
Il sistema indicizza una raccolta di fonti, riceve una domanda, recupera i passaggi più pertinenti e li inserisce nel contesto del modello. Il modello genera poi una risposta usando la domanda, le istruzioni e le fonti recuperate.
Il RAG elimina le allucinazioni?
No. Può ridurre le risposte non fondate quando recupero e istruzioni funzionano bene, ma può selezionare fonti sbagliate o interpretarle male. Servono valutazione, citazioni verificabili e una gestione esplicita dei casi in cui il contesto non basta.
Per fare RAG serve un database vettoriale?
Non sempre. La ricerca vettoriale è comune, ma un sistema RAG può usare ricerca testuale, database relazionali, knowledge graph, API o una combinazione di metodi. La scelta dipende dal tipo di dati e dalle domande.
Qual è la differenza tra RAG e fine-tuning?
Il RAG fornisce conoscenza esterna al momento della richiesta; il fine-tuning modifica il comportamento appreso dal modello. Per informazioni aggiornabili è generalmente più pratico il RAG, mentre il fine-tuning è adatto a comportamento, stile o compiti ripetitivi.
RAG e MCP possono essere usati insieme?
Sì. Un server MCP può esporre a ChatGPT, Claude o un altro client uno strumento che interroga una pipeline RAG. MCP gestisce il collegamento e la descrizione dello strumento; il RAG si occupa del recupero delle informazioni.
Il punto non è collegare documenti, ma recuperare prove
Se ricordi una sola cosa di questo articolo, ricorda questa: il RAG non rende affidabile un modello per definizione. Gli offre la possibilità di cercare prove prima di rispondere. Il risultato dipende dalla qualità delle fonti, dal recupero, dai permessi e da come misuri gli errori.
Un prototipo convincente si costruisce in fretta. Un sistema che risponde bene alle domande reali e sa fermarsi quando non possiede la risposta richiede invece progettazione.
Se vuoi capire se una knowledge base RAG è davvero adatta al tuo processo, nella pagina dedicata allo sviluppo AI e alle automazioni trovi il modo in cui progetto integrazioni basate su dati, permessi e casi d’uso concreti.