Agentic RAG in n8n: perché il RAG classico spesso fallisce – e come farlo meglio

Molte aziende puntano oggi su assistenti IA che rispondano a domande sui propri documenti – verbali di riunioni, tabelle di indicatori o feedback dei clienti. Il procedimento diffuso alla base si chiama Retrieval Augmented Generation (RAG). È molto usato, ben supportato e realizzabile in fretta con strumenti no-code come n8n. Solo che, nella pratica, il RAG classico fornisce sorprendentemente spesso risposte errate o incomplete. Cole Medin mostra nel suo video da che cosa dipenda e come un cosiddetto setup Agentic RAG aggiri le debolezze tipiche. Riassumo i punti principali con sobrietà.

Perché il RAG classico delude nella pratica

Il RAG funziona tramite una ricerca per somiglianza: la richiesta viene confrontata con frammenti di testo memorizzati (“chunk”) e i più pertinenti vengono passati al modello linguistico. Il problema è la selezione. Trascura regolarmente contesto importante.

Medin indica due punti deboli concreti:

• Nessuno sguardo sui documenti interi: il RAG considera solo singoli estratti. Chi vuole analizzare tendenze in una tabella ottiene magari solo un quarto delle righe – e quindi un risultato sbagliato.
• Nessuna vera analisi dei dati: somme o valori massimi su una tabella non si calcolano in modo affidabile con una pura ricerca testuale.

A ciò si aggiunge una seccatura pratica: se si chiede il verbale di una certa data, il RAG a volte pesca il documento del giorno sbagliato – benché la data sia nel titolo. E collegare tra loro documenti diversi per ricostruire un quadro più ampio riesce di rado.

Che cosa fa di diverso l’Agentic RAG

L’idea di fondo è semplice: invece di dare all’agente IA un solo strumento di ricerca, gliene si danno diversi – e lo si lascia decidere da sé come esplorare la base di conoscenza. Medin definisce così l’Agentic RAG:

Agentic RAG significa dare all’agente la capacità di ragionare su come interrogare la base di conoscenza – invece di inchiodarlo a un unico strumento.

In concreto l’agente può così migliorare le proprie query, scegliere all’occorrenza un altro strumento e provare più strade finché non ottiene una risposta solida. Se la sola ricerca RAG fallisce, non resta più bloccato.

I quattro strumenti dell’agente

Nel flusso di lavoro n8n l’agente dispone dei seguenti strumenti:

• Ricerca RAG – la classica ricerca per somiglianza, nella versione migliorata con indicazione della fonte.
• Elencare i documenti – l’agente recupera tutti i documenti con titoli e ID e valuta quali possano essere rilevanti.
• Recuperare il contenuto di un file – tramite l’ID del file ottiene il testo completo di un determinato documento (ad esempio il verbale del 23 febbraio, riconoscibile dal titolo).
• Query SQL sulle tabelle – i file CSV ed Excel vengono interrogati come tabelle SQL, per rendere possibili somme, massimi e analisi analoghe.

Nel system prompt l’agente riceve l’istruzione di iniziare con il RAG e di ricorrere agli altri strumenti solo quando la ricerca non fornisce quanto serve. Un’indicazione importante dal video: chiedere esplicitamente all’agente di essere onesto – cioè di dire apertamente quando non ha trovato una risposta – riduce sensibilmente le allucinazioni.

Come vengono salvati i dati tabellari

La parte tecnicamente più interessante riguarda le tabelle. In Supabase ne vengono create tre:

• documents – contiene gli embeddings per il RAG, i metadati e i contenuti dei singoli chunk.
• document_metadata – salva le informazioni di livello superiore: titolo, URL per le indicazioni di fonte e – nel caso delle tabelle – lo schema (cioè i nomi delle colonne).
• document_rows – archivia le righe delle tabelle. I dati veri e propri finiscono in una flessibile colonna JSONB chiamata row_data.

Il trucco: con JSONB si possono salvare strutture di colonne arbitrarie senza dover creare una tabella SQL dedicata per ogni file CSV o Excel. L’agente legge prima lo schema dai metadati, comprende le colonne disponibili e formula poi una query SQL su row_data. Medin sottolinea esplicitamente che questo setup è semplificato – lo schema, ad esempio, non dice nulla sui tipi di dato, per cui una somma su una colonna con il simbolo del dollaro può fallire. A lui interessa il concetto, non una realizzazione perfetta.

La pipeline RAG: da Google Drive a Supabase

Prima che l’agente possa lavorare, la base di conoscenza va riempita. La pipeline si svolge in più passaggi:

• Attivatore: un trigger di Google Drive controlla ogni minuto la presenza di file nuovi o modificati. In alternativa funzionano Dropbox o un trigger su file locali. I file cancellati, però, non vengono riconosciuti.
• Più file contemporaneamente: un ciclo introdotto di recente elabora ora anche più file che arrivano nello stesso intervallo di polling – una lacuna nota della versione precedente.
• Cancellare i dati vecchi: prima di ogni importazione vengono rimosse le voci esistenti relative al rispettivo ID di file. Così non resta alcun chunk obsoleto quando un documento si è accorciato.
• Estrarre il contenuto: un nodo Switch dirama a seconda del tipo di file – PDF, Google Doc, testo o tabella vengono letti in modo diverso. Ulteriori formati come JSON o HTML si possono aggiungere con nodi supplementari.
• Archiviare le tabelle due volte: i file CSV vengono da un lato preparati come documento testuale per il RAG, dall’altro salvati riga per riga in document_rows per le query SQL.

Un ostacolo pratico in fase di configurazione: per la connessione Postgres a Supabase, secondo il video, va usato il transaction pooler (porta 6543), non la connessione diretta. La documentazione di n8n su questo punto sarebbe poco chiara.

Modelli impiegati

Per gli embeddings viene usato text-embedding-3 di OpenAI, come modello linguistico GPT-4o mini – scelti volutamente economici e veloci. Per casi più esigenti Medin consiglia modelli più potenti come GPT-4o o Claude Sonnet 4. Importante: in inserimento e in recupero va usato lo stesso modello di embedding con lo stesso numero di dimensioni.

Tre esempi tratti dal video

Medin dimostra come l’agente scelga strumenti diversi a seconda della domanda:

• Domanda su tabella: a “In quale mese abbiamo avuto più clienti nuovi?” l’agente scrive una query SQL e fornisce il risultato corretto (dicembre, 129 clienti nuovi) – invece di affidarsi a chunk incompleti.
• Domanda puramente RAG: a “Dove possiamo migliorare?” la ricerca per somiglianza trova il documento con i feedback, benché la parola “miglioramento” non sia stata usata di proposito.
• Recupero di file con fonte: nel recupero di un verbale di riunione completo l’agente fornisce gli action item e, su richiesta, un link cliccabile alla fonte.

Conclusione

L’articolo mostra con sobrietà perché un RAG ingenuo non basti per molte applicazioni aziendali: trascura il contesto e non sa calcolare sulle tabelle. L’approccio agentico risolve la cosa in modo pragmatico, dando all’agente IA più strumenti e margine di decisione. Per i decisori delle PMI che valutano un assistente documentale questa è una constatazione importante: la qualità non dipende dal modello soltanto, ma dall’architettura che gli sta dietro. Chi adotta il setup n8n presentato dovrebbe intenderlo come punto di partenza – prompt, strumenti e modello dei dati vanno adattati al proprio patrimonio informativo. Proprio la query SQL sulle tabelle e la gestione dei tipi di dato lasciano spazio a miglioramenti.

Fonte: Cole Medin – „I Built the ULTIMATE n8n RAG AI Agent Template”, https://www.youtube.com/watch?v=mQt1hOjBH9o