- \n
- RAG (Retrieval Augmented Generation) collega un modello linguistico a una base di conoscenza propria, cos\u00ec che l’agente acceda ai Suoi documenti e non solo al sapere acquisito in addestramento.<\/li>\n
- n8n si occupa dell’automazione, Supabase funge al tempo stesso da memoria della chat e da database vettoriale.<\/li>\n
- L’intera architettura funziona senza programmazione ed \u00e8 configurata, secondo il video, in meno di 15 minuti.<\/li>\n
- Due dettagli distinguono questo approccio dai tutorial superficiali: una memoria scalabile per la cronologia della chat e la cancellazione dei vettori obsoleti per evitare duplicati.<\/li>\n
- Il piano gratuito di Supabase, secondo il video, \u00e8 del tutto sufficiente per iniziare.<\/li>\n<\/ul>\n<\/div>\n
![\"Confronto](\"https:\/\/pletzenauer.com\/wp-content\/uploads\/2026\/06\/1486-1.png\")
Due dettagli spesso trascurati decidono se un agente RAG resti utilizzabile man mano che la base di conoscenza cresce.<\/figcaption><\/figure>\n Che cosa fa l’agente nella pratica<\/h2>\n
Il funzionamento viene mostrato nel video con un esempio semplice. All’inizio la base di conoscenza \u00e8 vuota, la relativa tabella in Supabase non contiene voci. A una domanda di prova sui compiti emersi da una riunione l’agente, coerentemente, non sa rispondere.<\/p>\n
Poi viene depositato un documento con gli appunti della riunione come Google Doc in una cartella monitorata. Nel giro di circa un minuto gira in background un flusso di lavoro n8n che elabora il file e lo inserisce nella base di conoscenza. Dopodich\u00e9 in Supabase compare un nuovo record con il contenuto della pagina, i metadati (tra cui l’ID del file di Google Drive) e il cosiddetto vettore di embedding. Ponendo di nuovo la stessa domanda, l’agente fornisce ora la risposta corretta tratta dal documento. Anche gli aggiornamenti del file vengono riconosciuti e recepiti.<\/p>\n
L’architettura in sintesi<\/h2>\n
Il flusso di lavoro si compone di due parti: l’agente di chat vero e proprio e un percorso separato che inserisce automaticamente i documenti nella base di conoscenza. Un template JSON gi\u00e0 pronto si pu\u00f2 scaricare, secondo il video, da un repository GitHub e caricare nella propria istanza n8n tramite “Import from file”. Dopodich\u00e9 occorre solo aggiungere le proprie credenziali e la cartella desiderata.<\/p>\n
Preparare Supabase<\/h3>\n
Supabase si configura con un account GitHub. Due sezioni delle impostazioni di progetto forniscono le credenziali necessarie:<\/p>\n
- \n
- Database:<\/strong> host, nome del database, porta, utente e password per la connessione Postgres. Questi dati vengono usati per la memoria della chat.<\/li>\n
- API:<\/strong> l’URL specifico del progetto e il service role secret. Questi dati servono per il database vettoriale.<\/li>\n<\/ul>\n
Per la ricerca vettoriale n8n mette a disposizione nella sua documentazione codice SQL gi\u00e0 pronto. Lo si esegue una sola volta nell’editor SQL di Supabase e crea automaticamente l’estensione PG Vector, la tabella dei documenti e la funzione di matching per RAG. Non serve scrivere codice proprio.<\/p>\n
L’agente di chat<\/h3>\n
L’agente viene avviato da un trigger “When a chat message is received”. Questo mette a disposizione anche una finestra di chat direttamente in n8n, con cui testare l’agente senza deployment. All’occorrenza la stessa interfaccia si pu\u00f2 integrare in un sito web tramite codice di incorporamento gi\u00e0 pronto. All’agente sono collegati tre elementi:<\/p>\n
- \n
- Modello di chat:<\/strong> nell’esempio GPT-4o mini, collegato tramite la chiave API di OpenAI. In alternativa \u00e8 possibile anche Anthropic.<\/li>\n
- Memoria della chat:<\/strong> qui si usa volutamente Postgres su Supabase al posto della memoria a finestra locale spesso consigliata. La memoria locale grava sul server n8n e scala male. La tabella necessaria la crea n8n stesso all’occorrenza.<\/li>\n
- Strumento RAG:<\/strong> il tool “retrieve documents” con Supabase come archivio vettoriale, configurato tramite nome della tabella e funzione di query.<\/li>\n<\/ul>\n
Inserire i documenti automaticamente<\/h3>\n
La seconda parte del flusso di lavoro mantiene aggiornata la base di conoscenza. Un trigger di Google Drive controlla regolarmente in una cartella definita la presenza di file nuovi o modificati. Il seguito della procedura:<\/p>\n
- \n
- L’ID del file viene estratto e passato ai passaggi successivi.<\/li>\n
- I vettori esistenti con lo stesso ID di file vengono cancellati in Supabase (pi\u00f9 avanti maggiori dettagli).<\/li>\n
- Il file viene scaricato, i documenti vengono convertiti in testo e i Google Sheets in CSV, per ricavarne il puro contenuto testuale.<\/li>\n
- Il testo viene inserito nel database vettoriale. Per i file piccoli la suddivisione in sezioni non serve; altrimenti si usa un semplice text splitter ricorsivo.<\/li>\n<\/ul>\n
Due dettagli che decidono l’idoneit\u00e0 alla pratica<\/h2>\n
L’articolo mette in evidenza due punti che in molti tutorial mancano e che creano problemi proprio dove le cose si fanno serie.<\/p>\n
Memoria della chat scalabile<\/h3>\n
La cronologia di una conversazione viene spesso salvata localmente sull’istanza n8n, perch\u00e9 \u00e8 la via pi\u00f9 semplice. \u00c8 proprio questo a sovraccaricare il server con l’aumentare dell’uso. Lo spostamento in un database Postgres su Supabase \u00e8 il passaggio che rende l’agente davvero robusto.<\/p>\n
Cancellare i vettori obsoleti<\/h3>\n
Il punto pi\u00f9 importante riguarda gli aggiornamenti. Le opzioni vettoriali in n8n non funzionano come “Upsert”: un vettore esistente, al nuovo inserimento, non viene sostituito ma duplicato, perch\u00e9 l’ID del file non funge da ID del vettore. Aggiornando pi\u00f9 volte lo stesso file si accumulano doppioni e la qualit\u00e0 delle risposte ne risente. La soluzione adottata nel flusso di lavoro: prima di ogni inserimento vengono cancellati tutti i vettori i cui metadati riportano l’ID del file del documento Google Drive corrente. Solo dopo viene inserita la nuova versione aggiornata. Cos\u00ec per ogni documento resta esattamente un record aggiornato.<\/p>\n
Inquadramento per i decisori<\/h2>\n
L’architettura mostrata \u00e8 pensata esplicitamente come un solido punto di partenza, non come soluzione finale gi\u00e0 pronta. Ampliamenti come una ricerca semantica migliore o una ricerca per parole chiave aggiuntiva sono possibili, ma vengono volutamente lasciati aperti. Per una prima base di conoscenza vicina alla produzione l’approccio \u00e8 comunque sostenibile.<\/p>\n
Notevole \u00e8 il lato dei costi: il piano gratuito di Supabase basta, secondo il video, per iniziare, e il passaggio al piano a pagamento conviene solo quando si scala. Chi lavora gi\u00e0 con n8n pu\u00f2 allestire l’agente con i propri documenti in poco tempo, senza commissionare sviluppo esterno.<\/p>\n
Conclusione<\/h2>\n
L’articolo mostra in modo sobrio e comprensibile come realizzare un agente IA RAG con n8n e Supabase senza programmazione. Il valore aggiunto reale non sta nell’effetto demo immediato, ma in due dettagli spesso trascurati: una memoria della chat scalabile e la rimozione sistematica dei vettori obsoleti. Sono proprio questi punti a decidere se un agente resti utilizzabile con una base di conoscenza crescente o se col tempo diventi inaffidabile. Chi vuole rendere ricercabili i documenti interni trova qui uno schema pragmatico, ampliabile passo dopo passo.<\/p>\n
- Memoria della chat:<\/strong> qui si usa volutamente Postgres su Supabase al posto della memoria a finestra locale spesso consigliata. La memoria locale grava sul server n8n e scala male. La tabella necessaria la crea n8n stesso all’occorrenza.<\/li>\n
- API:<\/strong> l’URL specifico del progetto e il service role secret. Questi dati servono per il database vettoriale.<\/li>\n<\/ul>\n
- Database:<\/strong> host, nome del database, porta, utente e password per la connessione Postgres. Questi dati vengono usati per la memoria della chat.<\/li>\n