Cos’è il RAG con l’intelligenza artificiale, in una frase
RAG sta per Retrieval-Augmented Generation. Un modello di linguaggio, da solo, sa solo quello con cui è stato addestrato. Il RAG aggiunge un passo prima della risposta: il sistema va a cercare il documento giusto, lo passa al modello come contesto, e il modello risponde usando quel testo. Non inventa. Legge, poi risponde.
Se hai un’agenzia o un infobusiness, questo è il pezzo che trasforma un chatbot generico in qualcosa che conosce le tue procedure, i tuoi prezzi, le tue policy. Senza RAG, l’agente AI sa tutto del mondo e niente di te. Con il RAG, sa tutto di te e lo trova in secondi. In questo articolo vediamo come funziona il meccanismo, cosa serve per costruirlo, e dove si rompe quando non è progettato bene.
Come funziona il RAG: il meccanismo reale
Il flusso ha tre fasi distinte. Capire dove sta ognuna ti evita di costruire una macchina mal collegata.
Fase 1: indicizzazione dei documenti
I tuoi documenti vengono convertiti in vettori numerici — chiamati embedding — e salvati in un database vettoriale. Un vettore è una rappresentazione matematica del significato semantico di un testo. Due frasi con significato simile finiscono vicine nello spazio vettoriale, anche se usano parole diverse. Questo è il motivo per cui puoi chiedere «politica di reso» e il sistema recupera il documento che parla di «rimborsi e restituzioni» senza che le parole coincidano esattamente.
Fase 2: recupero del documento rilevante
Quando l’utente fa una domanda, la domanda stessa viene convertita in un vettore. Il sistema calcola la vicinanza tra quel vettore e tutti quelli nel database, recupera i chunk più simili — di solito da 3 a 10 — e li passa al modello come contesto. Il modello non cerca: il retriever cerca e porta il materiale al modello. Sono due operazioni separate, anche quando sembrano trasparenti.
Fase 3: generazione della risposta
Il modello riceve la domanda originale più i chunk recuperati. Risponde basandosi su quel contesto. Se il documento è buono e il retriever ha trovato il pezzo giusto, la risposta è precisa. Se il retriever ha recuperato il chunk sbagliato, la risposta è plausibile ma errata — e questo è il punto di rottura più frequente nei sistemi mal costruiti.
La differenza tra un agente AI con RAG e uno senza
Un agente senza memoria contestuale risponde con quello che sa dal training. Va bene per compiti generici. Diventa inutile — o peggio, pericoloso — quando la domanda riguarda dati specifici: il tuo listino, le clausole del tuo contratto, le istruzioni operative del tuo team.
| Caratteristica | LLM senza RAG | Agente AI con RAG |
|---|---|---|
| Fonte delle risposte | Training data del modello | I tuoi documenti aggiornati |
| Aggiornamento informazioni | Solo con fine-tuning o nuovo modello | Basta aggiornare il documento |
| Rischio allucinazione | Alto su dati specifici | Ridotto se il retriever funziona |
| Tracciabilità della risposta | Nessuna | Il sistema indica il documento fonte |
| Costo di aggiornamento | Alto (ritraining) | Basso (upload del nuovo documento) |
La tracciabilità è spesso sottovalutata. Quando hai 50 documenti attivi — procedure, FAQ, listini, contratti — sapere da quale chunk viene una risposta non è un dettaglio tecnico: è l’unico modo per capire perché l’agente ha detto una cosa sbagliata e dove correggere.
Cosa serve per costruire un sistema RAG con un agente AI
Tre componenti, nessuna opzionale.
Un database vettoriale
Supabase con l’estensione pgvector è la scelta più comune per chi parte senza un’infrastruttura dedicata. Pinecone è più performante a scala, ma introduce un servizio esterno aggiuntivo da monitorare. Qdrant è un’alternativa self-hosted che si installa su un VPS. La scelta dipende dal volume di documenti e da quante query al giorno stimi. Sotto le mille query giornaliere e qualche decina di documenti, Supabase fa il lavoro senza sovrastimare l’infrastruttura.
Un modello di embedding
Il modello di embedding converte il testo in vettori. OpenAI mette a disposizione text-embedding-3-small e text-embedding-3-large. Il primo costa meno e per la maggior parte dei casi d’uso aziendali è sufficiente. L’importante è usare lo stesso modello sia in fase di indicizzazione sia in fase di retrieval: vettori generati con modelli diversi non sono comparabili.
Un orchestratore che tiene insieme i pezzi
Il modello da solo non si connette al database, non recupera i chunk, non gestisce gli errori. Serve un layer che esegua le azioni. n8n è quello che uso più spesso per costruire questi flow: ha un nodo dedicato per i vector store e gestisce la coda di operazioni in modo visibile. Se vuoi approfondire la costruzione concreta, ho scritto una guida specifica su n8n RAG e sistemi di risposta intelligente sui documenti aziendali.
La regola
Un agente AI con RAG si rompe in silenzio come tutte le altre automazioni
Il retriever può restituire un chunk sbagliato senza generare nessun errore. Il modello ci costruisce sopra una risposta plausibile. L’utente ringrazia. Il dato era sbagliato.
- Monitora il retriever — controlla periodicamente le query reali e i chunk che recuperano
- Testa i casi limite — domande ambigue o documenti sovrapposti producono i retrieval peggiori
- Versiona i documenti — sapere quale versione era attiva quando l’agente ha risposto vale più di qualsiasi log
RAG e intelligenza artificiale: i punti dove il sistema si rompe davvero
Il problema più frequente non è tecnico: è la qualità dei documenti. Un documento scritto male — testo scansionato, tabelle non strutturate, PDF con layout complesso — produce chunk inutilizzabili. Il retriever li recupera, il modello ci prova, la risposta è vaga o sbagliata.
Il secondo problema è il chunking. Dividere un documento in pezzi troppo piccoli spezza il contesto; pezzi troppo grandi saturano la finestra e confondono il modello. Una dimensione di chunk tra 500 e 1000 token con un overlap del 10-15% funziona bene nella maggior parte dei casi. Ma va calibrata sul tipo di documento: una policy di rimborso è diversa da un manuale operativo da 80 pagine.
Il terzo problema è il silenzio del sistema. Un’automazione senza guardie esegue sbagliato con la stessa sicurezza con cui esegue giusto. Se il tuo flow RAG non ha un log delle query senza risposta, delle risposte con bassa confidence, dei documenti non indicizzati — non sai cosa sta succedendo. Sai solo che il sistema risponde. Non sai se risponde bene.
Per capire come strutturare un agente che gestisce questi casi, la guida su cos’è un agente AI e come funziona copre le basi del loop perception-action che è alla radice di questi sistemi.
Inizia qui
Make è il layer che dà le braccia al tuo agente RAG
Con Make colleghi il tuo database vettoriale, il modello e i canali di output senza scrivere codice. Il piano gratuito parte da 1.000 operazioni al mese: abbastanza per costruire e testare una macchina reale.
- Giorno 1 — Crea uno scenario che prende un documento e lo indicizza in Supabase
- Giorno 3 — Aggiungi il nodo di retrieval e collega un LLM per la generazione
- Giorno 7 — Costruisci il log degli errori e monitora le prime query reali
Apri il piano gratuito di Make →
Link di affiliazione: se ti iscrivi da qui io prendo una commissione, tu paghi uguale. Lo linko perché ci lavoro dentro ogni giorno.
Come integrare il RAG in un workflow di agenzia o infobusiness
Il caso d’uso più immediato è il supporto: un agente AI che risponde alle domande dei clienti usando le tue FAQ, i tuoi contratti, le tue procedure. Invece di formare una persona a memoria di centinaia di casi, carica i documenti, l’agente li legge.
Il secondo caso d’uso è interno: un agente che risponde alle domande del team usando le SOP aziendali. Chi entra non deve chiedere al fondatore come si fa onboarding di un cliente — chiede all’agente e ottiene la procedura esatta, con il riferimento al documento.
Il terzo caso — meno ovvio ma più potente — è la qualificazione. Un agente RAG collegato al CRM può recuperare le informazioni di un lead, confrontarle con i criteri di qualifica definiti in un documento, e produrre una valutazione strutturata prima che un umano apra la scheda. Se stai costruendo questo tipo di infrastruttura su GoHighLevel, la guida sul GoHighLevel CRM e come riduce i costi fissi dell’agenzia mostra come il CRM si integra in un sistema del genere.
In tutti e tre i casi, la leva è la stessa: scrivi il documento una volta, l’agente lo usa mille volte. Non assumi nessuno per recuperare informazioni. La macchina scala; le persone si occupano di decisioni che la macchina non può prendere.
Per chi vuole costruire questo con n8n, l’articolo su come costruire il primo agente AI con n8n è il punto di partenza più diretto.
La parte che quasi nessuno progetta: l’aggiornamento dei documenti
Quando cambia una policy, un listino, una procedura — il database vettoriale deve essere aggiornato. Non è sufficiente caricare il nuovo documento: i vecchi chunk relativi a quel documento devono essere eliminati prima, altrimenti il retriever recupera versioni contrastanti e il modello produce risposte incoerenti.
Un sistema RAG maturo ha un flow separato per la gestione del ciclo di vita dei documenti: caricamento, indicizzazione, invalidazione dei chunk obsoleti, verifica dell’indicizzazione completata. Senza questo flow, ogni aggiornamento di contenuto è un’operazione manuale a rischio — e con dieci documenti che cambiano ogni mese, il rischio diventa sistematico.
Questo è il pezzo che separa un prototipo da una macchina in produzione. Il prototipo funziona finché i documenti non cambiano. La macchina funziona anche quando cambiano, perché il processo di aggiornamento è automatizzato e verificabile.
Il RAG e l’intelligenza artificiale, messi insieme in modo corretto, non sono una funzionalità. Sono l’infrastruttura di conoscenza dell’azienda. Se la costruisci bene la prima volta, regge anni. Se la improvvisi, regge fino alla prima modifica non gestita — e poi si rompe in silenzio, come tutte le automazioni senza guardie.
Domande frequenti
Qual è la differenza tra RAG e fine-tuning?
Il fine-tuning riscrive i pesi del modello con nuovi dati: costoso, lento, e va rifatto ogni volta che le informazioni cambiano. Il RAG non tocca il modello: porta i documenti aggiornati come contesto al momento della risposta. Per dati aziendali che cambiano spesso, il RAG è quasi sempre la scelta giusta.
Un sistema RAG funziona con qualsiasi tipo di documento?
Funziona meglio con testo strutturato e leggibile: PDF nativi, documenti Word, pagine web. I PDF scansionati, le tabelle complesse e i file con layout grafico pesante producono chunk di scarsa qualità. Prima di indicizzare, vale la pena pulire e strutturare i documenti sorgente.
Quanto costa costruire un sistema RAG?
Con Supabase nel piano gratuito, n8n self-hosted e il modello di embedding di OpenAI, il costo fisso mensile è quasi zero. Le API di embedding costano frazioni di centesimo per documento. La voce di costo principale è il tempo di progettazione, non l’infrastruttura.
Come faccio a sapere se il retriever sta recuperando i chunk giusti?
Loggando le query e i chunk restituiti. In n8n puoi salvare ogni coppia query-chunk in un foglio o in un database. Poi le revisioni periodicamente a campione. Se il retriever porta spesso chunk irrilevanti, il problema è nel chunking o nella qualità dei documenti, non nel modello.
Trasparenza: in questo articolo c’è un link di affiliazione. Se ti iscrivi da lì io ricevo una commissione, per te non cambia niente. Linko solo strumenti che uso in produzione.
