Agentic RAG i n8n: varför klassisk RAG ofta misslyckas – och hur det görs bättre

Många företag satsar i dag på AI-assistenter som ska besvara frågor om egna dokument – om mötesprotokoll, nyckeltalstabeller eller kundfeedback. Den gängse metoden bakom heter Retrieval Augmented Generation (RAG). Den är utbredd, väl understödd och snabbt genomförd i no-code-verktyg som n8n. Men: i praktiken ger klassisk RAG förvånansvärt ofta felaktiga eller ofullständiga svar. Cole Medin visar i sin video vad det beror på och hur en så kallad agentic RAG-uppsättning kringgår de typiska svagheterna. Jag sammanfattar de viktigaste punkterna nyktert.

Varför klassisk RAG gör besviken i praktiken

RAG fungerar via en likhetssökning: förfrågan jämförs med lagrade textstycken (“chunks”), och de mest passande skickas vidare till språkmodellen. Problemet är urvalet. Det missar regelbundet viktig kontext.

Medin nämner två konkreta svagheter:

• Ingen blick över hela dokument: RAG tar bara in enskilda utdrag. Den som vill analysera trender i en tabell får kanske bara en fjärdedel av raderna – och därmed ett felaktigt resultat.
• Ingen verklig dataanalys: summor eller maxvärden över en tabell går inte att beräkna tillförlitligt med en ren textsökning.

Till det kommer ett praktiskt irritationsmoment: frågar man efter protokollet från ett visst datum tar RAG ibland dokumentet från fel dag – trots att datumet står i titeln. Och att koppla ihop olika dokument för att skapa ett bredare sammanhang lyckas sällan.

Vad agentic RAG gör annorlunda

Grundtanken är enkel: i stället för att ge AI-agenten ett enda sökverktyg får den flera – och får själv avgöra hur den tar sig an kunskapsdatabasen. Medin definierar agentic RAG så här:

Agentic RAG innebär att ge agenten förmågan att tänka över hur den söker igenom kunskapsdatabasen – i stället för att spika fast den vid ett enda verktyg.

Konkret kan agenten därmed förbättra sina sökfrågor, vid behov välja ett annat verktyg och pröva flera vägar tills den har ett hållbart svar. Misslyckas den rena RAG-sökningen är den inte längre blockerad.

Agentens fyra verktyg

I n8n-arbetsflödet står följande verktyg till agentens förfogande:

• RAG-sökning – den klassiska likhetssökningen, i den förbättrade versionen inklusive källhänvisning.
• Lista dokument – agenten hämtar alla dokument med titlar och ID:n och överväger vilka som kan vara relevanta.
• Hämta filinnehåll – via fil-ID:t hämtar den den fullständiga texten i ett visst dokument (till exempel protokollet från den 23 februari, igenkännbart på titeln).
• SQL-fråga mot tabeller – CSV- och Excel-filer frågas som SQL-tabeller för att möjliggöra summor, maxvärden och liknande analyser.

I systemprompten instrueras agenten att börja med RAG och bara gå över till de övriga verktygen när sökningen inte ger rätt resultat. Ett viktigt påpekande från videon: att uttryckligen uppmana agenten till ärlighet – alltså att öppet säga när inget svar hittats – minskar hallucinationerna märkbart.

Hur tabelldata lagras

Den tekniskt mest intressanta delen gäller tabeller. I Supabase skapas tre tabeller för detta:

• documents – innehåller embeddings för RAG, metadata och innehållet i de enskilda chunkarna.
• document_metadata – lagrar övergripande information: titel, URL:er för källhänvisningar och – för tabeller – schemat (alltså kolumnnamnen).
• document_rows – lagrar tabellraderna. Själva data hamnar i en flexibel JSONB-kolumn vid namn row_data.

Knepet: via JSONB går det att lagra godtyckliga kolumnstrukturer utan att behöva skapa en egen SQL-tabell för varje CSV- eller Excel-fil. Agenten läser först schemat ur metadata, förstår vilka kolumner som finns och formulerar sedan en SQL-fråga mot row_data. Medin påpekar uttryckligen att den här uppsättningen är förenklad – schemat avslöjar till exempel ingenting om datatyper, så en summa över en kolumn med dollartecken kan misslyckas. Han är ute efter konceptet, inte ett perfekt genomförande.

RAG-pipelinen: från Google Drive till Supabase

Innan agenten kan arbeta måste kunskapsdatabasen fyllas. Pipelinen löper i flera steg:

• Utlösare: en Google Drive-trigger kontrollerar varje minut efter nya eller ändrade filer. Alternativt fungerar Dropbox eller en lokal filtrigger. Raderade filer upptäcks dock inte.
• Flera filer samtidigt: en nyinbyggd slinga bearbetar nu också flera filer som kommer in i samma pollingintervall – en känd brist i den föregående versionen.
• Radera gamla data: före varje import tas befintliga poster för respektive fil-ID bort. På så vis blir ingen föråldrad chunk kvar när ett dokument har blivit kortare.
• Extrahera innehåll: en switch-nod förgrenar beroende på filtyp – PDF, Google-dokument, text eller tabell läses ut på olika sätt. Fler format som JSON eller HTML kan läggas till via ytterligare noder.
• Lagra tabeller dubbelt: CSV-filer bereds dels som textdokument för RAG, dels lagras de radvis i document_rows för SQL-frågor.

En praktisk snubbeltråd vid uppsättningen: för Postgres-anslutningen till Supabase måste enligt videon transaction pooler användas (port 6543), inte den direkta anslutningen. n8n:s dokumentation ska vara otydlig på den punkten.

Modeller som används

För embeddings används OpenAI:s text-embedding-3, som språkmodell GPT-4o mini – medvetet valt billigt och snabbt. För mer krävande fall rekommenderar Medin kraftfullare modeller som GPT-4o eller Claude Sonnet 4. Viktigt: vid inläggning och vid hämtning måste samma embedding-modell med samma antal dimensioner användas.

Tre exempel ur videon

Medin demonstrerar hur agenten väljer olika verktyg beroende på fråga:

• Tabellfråga: på “Vilken månad hade vi flest nya kunder?” skriver agenten en SQL-fråga och ger det korrekta resultatet (december, 129 nya kunder) – i stället för att förlita sig på ofullständiga chunkar.
• Ren RAG-fråga: på “Var kan vi bli bättre?” hittar likhetssökningen feedbackdokumentet, trots att ordet “förbättring” medvetet inte användes.
• Filhämtning med källa: vid hämtning av ett komplett mötesprotokoll levererar agenten åtgärdspunkterna och på förfrågan en klickbar länk till källan.

Slutsats

Inlägget visar nyktert varför naiv RAG inte räcker för många affärstillämpningar: den missar kontext och kan inte räkna med tabeller. Den agentiska ansatsen löser det pragmatiskt genom att ge AI-agenten flera verktyg och utrymme att välja. För beslutsfattare i små och medelstora företag som överväger en dokumentassistent är det en viktig insikt: kvaliteten står och faller inte med modellen ensam, utan med arkitekturen bakom. Den som tar över den n8n-uppsättning som presenteras bör se den som en utgångspunkt – prompter, verktyg och datamodell hör hemma anpassade till det egna databeståndet. Just SQL-frågan mot tabeller och hanteringen av datatyper lämnar utrymme för förbättringar.

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