n8n RAG: come costruire un sistema di risposta intelligente sui tuoi documenti aziendali

Un sistema RAG — Retrieval-Augmented Generation — fa una cosa sola: prima cerca il contesto rilevante nei tuoi documenti, poi genera la risposta. Il modello non inventa: legge quello che hai scritto tu e lo usa. Con n8n puoi costruire questa pipeline senza un data scientist, collegando un vettore store, un modello di embedding e un LLM in un flow visuale che puoi debuggare nodo per nodo.

Il problema di affidare domande aziendali a un LLM generico è noto: risponde con sicurezza anche quando non sa. Le SOP cambiano, i listini si aggiornano, le policy interne non le conosce nessun modello addestrato sei mesi fa. Un sistema RAG risolve questo alla radice: l’unica fonte di verità è il documento che carichi tu. Se non c’è scritto lì, il sistema non risponde — o risponde dicendo che non lo sa, che è già un risultato utile. Questo articolo copre l’architettura completa: come indicizzare i documenti, come costruire il flow di retrieval in n8n, dove mettere le guardie e come sapere quando il sistema si è rotto senza che nessuno te lo abbia detto.

Cosa fa un sistema RAG e perché n8n è il posto giusto per costruirlo

Un RAG ha tre stadi. Il primo è l’ingestion: i documenti entrano, vengono spezzati in chunk, ogni chunk viene trasformato in un vettore numerico da un modello di embedding e salvato in un vettore store. Il secondo è il retrieval: quando arriva una domanda, anche quella viene trasformata in vettore e il sistema trova i chunk più vicini semanticamente. Il terzo è la generation: quei chunk vengono passati come contesto al modello, che genera la risposta.

n8n copre tutti e tre gli stadi con nodi nativi. Hai il nodo Vector Store con supporto a Pinecone, Qdrant e Supabase pgvector. Hai il nodo Embeddings per OpenAI, Cohere o modelli locali via Ollama. Hai il nodo AI Agent e il nodo Chat Model per la generation. Tutto in un canvas visuale dove vedi esattamente cosa passa da un nodo all’altro — il che, quando il retrieval torna i chunk sbagliati, ti salva ore di debug.

La ragione per cui preferisco costruire RAG in n8n rispetto a framework come LangChain non è ideologica: è che in n8n ogni nodo ha un log di input e output ispezionabile in tempo reale. Quando il sistema risponde male puoi vedere se il problema è nel retrieval — i chunk sbagliati — o nella generation — il modello che ignora il contesto. Con un framework da codice devi loggare tu. Con n8n è già lì.

L’architettura del flow: i tre nodi che contano

Ingestion: spezzare i documenti nel modo giusto

Il chunk size è la decisione più importante dell’intera pipeline. Chunk troppo grandi portano contesto irrilevante al modello. Chunk troppo piccoli perdono il filo logico tra una frase e l’altra. Una buona regola operativa: 512 token per chunk, con un overlap di 50-100 token tra un chunk e il successivo.

In n8n usi il nodo Text Splitter con strategia Recursive Character: spezza prima sui paragrafi, poi sulle frasi, poi sui caratteri. È il modo che preserva meglio la struttura semantica. Poi ogni chunk passa al nodo Embeddings — OpenAI text-embedding-3-small è il rapporto costo-qualità migliore oggi — e il vettore risultante viene scritto nel tuo store.

Un dettaglio che fa differenza: aggiungi sempre i metadati al chunk prima di vettorizzarlo. Nome del file, data di ultima modifica, sezione del documento. Quando il retrieval torna un risultato, puoi mostrare all’utente da dove viene la risposta. E quando il documento viene aggiornato, sai quali vettori invalidare senza re-indicizzare tutto.

Retrieval: trovare i chunk giusti

Il nodo Vector Store Retriever in n8n prende la query dell’utente, la trasforma nello stesso spazio vettoriale dei chunk — usando lo stesso modello di embedding dell’ingestion, questo è non negoziabile — e restituisce i k chunk più vicini per similarità coseno.

Il parametro k è il secondo punto critico. Con k=3 passi meno contesto ma più segnale. Con k=10 passi più copertura ma rischi di annacquare il prompt. Per una knowledge base aziendale tipica — SOP, policy, listini — k=4 o k=5 è il punto di partenza. Poi misuri.

Una tecnica che funziona quando la knowledge base è grande: il metadata filtering. Prima di cercare per similarità, filtri i chunk per categoria o data. Se l’utente chiede del listino 2024, il retriever cerca solo tra i chunk con source: listino e year: 2024. Meno rumore, risposta più precisa.

Generation: il prompt che tiene il modello agganciato ai fatti

Questa è la parte che la maggior parte dei tutorial salta. Il retrieval porta i chunk giusti, ma se il prompt di sistema non è scritto bene il modello li ignora e risponde con quello che sa già. Il pattern che funziona:

Sei un assistente che risponde SOLO usando il contesto fornito.
Se la risposta non è nel contesto, di' esattamente: "Non ho questa informazione nei documenti disponibili".
Non integrare con conoscenza esterna.

Contesto:
{{chunks}}

La frase «non ho questa informazione» non è un fallback: è una guardia. Un sistema RAG che ammette di non sapere è più utile di uno che inventa con sicurezza. Quel messaggio è il segnale che la tua knowledge base ha un buco — e un buco che sai di avere lo puoi chiudere.

Come costruire il flow in n8n passo per passo

Il flow di ingestion

Il trigger può essere un webhook — un documento caricato su Google Drive attiva il flow — oppure un cron se vuoi re-indicizzare periodicamente. Il percorso è lineare:

Trigger → leggi il file → Text Splitter → Embeddings → Vector Store Insert.

Aggiungi un nodo Set tra il file e il Text Splitter per costruire i metadati: source, last_modified, category. Sono campi che ti servono dopo. Se salti questo passaggio, il retriever ti torna chunk anonimi e il debug diventa un’indagine.

Per i formati supportati: n8n legge PDF tramite il nodo Extract from File, testo semplice, Markdown, e HTML. I DOCX vanno convertiti prima — un nodo HTTP verso un servizio di conversione, oppure Google Drive che esporta in testo. Questo è un punto dove il flow si rompe in silenzio se non metti una guardia sul tipo MIME del file in ingresso.

Il flow di retrieval e risposta

Il trigger qui è una chat — il nodo Chat Trigger di n8n, oppure un webhook da Slack, da un form sul sito o da una qualsiasi interfaccia. Il percorso:

Trigger → Vector Store Retriever → nodo Set per assemblare il prompt → Chat Model → risposta all’utente.

Il nodo Set assembla il prompt iniettando i chunk recuperati nella variabile {{chunks}}. Se vuoi mostrare le fonti, aggiungi un secondo output che elenca i metadati dei chunk usati — nome file e sezione. L’utente sa dove andare a verificare. Questo da solo riduce la resistenza all’adozione: le persone si fidano di un sistema che cita le fonti.

Se stai costruendo il tuo primo agente RAG in n8n, la guida sugli agenti AI in n8n copre la struttura del nodo AI Agent che puoi integrare direttamente in questo flow per aggiungere memoria conversazionale.

Dove mettere le guardie e come sapere quando si rompe

Il silenzio dei sistemi non è salute. Un RAG può degradare in tre modi senza che nessun errore appaia nei log: i documenti source vengono aggiornati ma i vettori no, il modello di embedding viene cambiato e i vettori vecchi diventano incompatibili, il vettore store supera i limiti del piano e smette di scrivere senza restituire un errore esplicito.

Le guardie che metterei in un sistema di produzione:

• Un nodo If dopo il retriever che controlla che il similarity score dei chunk superi una soglia minima — 0.75 è un punto di partenza. Sotto soglia, il flow va su un branch di fallback che risponde con il messaggio standard invece di passare chunk irrilevanti al modello.
• Un log automatico di ogni query e dei chunk usati, scritto su un foglio Google o in un database. Dopo una settimana di traffico reale hai i dati per capire dove la knowledge base è lacunosa.
• Un alert su Slack o email se il flow non viene eseguito per più di X ore — il silenzio operativo è un segnale, non normalità.

Per chi vuole approfondire la struttura dell’infrastruttura n8n prima di costruirci sopra un RAG: l’articolo sull’installazione con Docker Compose copre il setup di produzione che regge un carico reale.

Casi d’uso concreti per infobusiness e agenzie

Un RAG aziendale non è un chatbot generico. È un sistema che risponde su un perimetro preciso. I casi che funzionano in produzione:

Supporto interno sulle SOP. Il team fa domande operative — come si gestisce un rimborso, qual è il processo di onboarding — e il sistema risponde attingendo alle procedure aggiornate. Niente più catene su Slack per cercare il documento giusto.

Assistente alle vendite. Il closer carica le obiezioni frequenti, le risposte approvate, il confronto con i competitor. Prima di una call, interroga il sistema e ottiene le argomentazioni già testate. Il modello non inventa: usa solo quello che il team ha scritto e validato.

FAQ client-facing. Il RAG risponde alle domande dei clienti sul prodotto o servizio attingendo alla documentazione ufficiale. Se la risposta non c’è, dice che non la sa e scala a un umano. Zero allucinazioni su termini contrattuali o funzionalità che non esistono.

In tutti e tre i casi la logica è la stessa: la knowledge base è tua, il perimetro è definito, il modello non esce da lì. Questa è la differenza tra uno strumento utile e un sistema che ti imbarazza davanti al cliente.

Per capire come inserire questo tipo di agente in un’architettura di agenzia più ampia, l’articolo sugli agenti AI per aziende copre i criteri per decidere quando un agente è pronto per la produzione e quando è ancora un prototipo.

Il vettore store: quale scegliere

n8n supporta nativamente Pinecone, Qdrant, Supabase pgvector, Weaviate e qualche altro. La scelta dipende da dove sei nell’adozione.

Se stai costruendo il primo prototipo e non vuoi gestire infrastruttura: Pinecone piano serverless. Zero configurazione, API chiara, piano gratuito sufficiente per testare. Il limite è il vendor lock-in: i tuoi vettori sono da loro.

Se hai già Supabase nel tuo stack: pgvector dentro Supabase. I vettori stanno nel database che già usi, il backup è quello del progetto, e hai il vantaggio del metadata filtering con SQL standard.

Se vuoi tutto self-hosted: Qdrant su Docker. Documentazione buona, performance solide, e gira sulla stessa macchina di n8n se vuoi minimizzare la latenza. L’articolo sull’installazione n8n con Docker ti dà la base su cui aggiungere Qdrant come secondo servizio nel Compose.

Non esiste la scelta giusta in assoluto. Esiste quella che non ti aggiunge complessità operativa prima che il sistema abbia dimostrato di funzionare. Prima fai girare il RAG, poi ottimizzi lo store.

La documentazione ufficiale di n8n sulle integrazioni AI — disponibile su docs.n8n.io/advanced-ai — elenca i vettore store supportati con i parametri di configurazione specifici per ogni nodo. È il punto di partenza prima di aprire il canvas.

Un riferimento utile sull’architettura RAG in generale è il paper originale di Facebook AI Research su arxiv.org: capire perché funziona è più utile di copiare un template.

Un RAG in n8n non è il progetto più semplice che puoi costruire, ma è uno dei più utili in rapporto all’investimento. Tre flow — ingestion, retrieval, risposta — e hai un sistema che sa quello che sai tu, risponde in secondi e non alucina su quello che non c’è scritto. Le guardie non sono opzionali: un sistema che degrada in silenzio è peggio di nessun sistema, perché risponde con sicurezza mentre sbaglia. Metti i log, metti la soglia di similarità, metti l’alert. Poi lascialo girare.

Domande frequenti

Cos’è il RAG e perché usarlo con n8n?

RAG sta per Retrieval-Augmented Generation: il modello risponde attingendo a documenti specifici invece di usare solo la sua conoscenza generale. n8n permette di costruire la pipeline completa — ingestion, retrieval, generation — in modo visuale, con log ispezionabili nodo per nodo e senza scrivere codice.

Quale vettore store è consigliato per iniziare?

Pinecone serverless per chi non vuole gestire infrastruttura, Supabase pgvector per chi ha già Supabase nel proprio stack, Qdrant self-hosted per chi vuole tutto sotto controllo. La priorità è far girare il sistema prima di ottimizzare lo storage.

Quanto costa costruire un RAG con n8n?

I costi variabili sono due: il modello di embedding — OpenAI text-embedding-3-small costa frazioni di centesimo per chunk — e il vettore store. Con Pinecone gratuito e OpenAI il costo di ingestion di una knowledge base aziendale standard è sotto i 5 dollari. Il costo operativo dipende dal volume di query.

Come faccio a sapere se il RAG sta rispondendo correttamente?

Logga ogni query con i chunk recuperati e il similarity score. Dopo una settimana di traffico reale hai un dataset per capire dove il retrieval fallisce. Aggiungi una soglia minima di similarity: sotto quella soglia il sistema risponde che non ha l’informazione invece di passare contesto irrilevante al 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.