Agentic RAG i n8n: hvorfor klassisk RAG ofte fejler – og hvordan det gøres bedre

Mange virksomheder satser i dag på AI-assistenter, der skal besvare spørgsmål om egne dokumenter – mødereferater, nøgletalstabeller eller kundefeedback. Den gængse metode bag hedder Retrieval Augmented Generation (RAG). Den er udbredt, godt understøttet og hurtigt implementeret i no-code-værktøjer som n8n. Men: i praksis leverer klassisk RAG forbløffende ofte forkerte eller ufuldstændige svar. Cole Medin viser i sin video, hvad det skyldes, og hvordan en såkaldt Agentic RAG-opsætning kommer uden om de typiske svagheder. Jeg sammenfatter de vigtigste punkter nøgternt.

Hvorfor klassisk RAG skuffer i praksis

RAG fungerer via en lighedssøgning: forespørgslen sammenholdes med gemte tekststykker (“chunks”), og de bedst passende gives videre til sprogmodellen. Problemet er udvælgelsen. Den overser jævnligt vigtig kontekst.

Medin nævner to konkrete svagheder:

• Intet blik på hele dokumenter: RAG trækker kun enkelte uddrag ind. Vil du analysere tendenser i en tabel, får du måske kun en fjerdedel af rækkerne – og dermed et forkert resultat.
• Ingen egentlig dataanalyse: summer eller maksimumværdier på tværs af en tabel kan ikke beregnes pålideligt med en ren tekstsøgning.

Dertil kommer en praktisk irritation: spørger man efter referatet fra en bestemt dato, henter RAG undertiden dokumentet fra den forkerte dag – selvom datoen står i titlen. Og det lykkes sjældent at knytte forskellige dokumenter sammen for at skabe en bredere sammenhæng.

Hvad Agentic RAG gør anderledes

Kernidéen er enkel: i stedet for at give AI-agenten ét enkelt søgeværktøj får den flere – og må selv bestemme, hvordan den åbner videnbasen. Medin definerer Agentic RAG sådan:

Agentic RAG betyder at give agenten evnen til at tænke over, hvordan den gennemsøger videnbasen – i stedet for at binde den til ét enkelt værktøj.

Konkret kan agenten dermed forbedre sine søgeforespørgsler, vælge et andet værktøj ved behov og prøve flere veje, indtil den har et holdbart svar. Slår den rene RAG-søgning fejl, er den ikke længere blokeret.

Agentens fire værktøjer

I n8n-workflowet har agenten følgende værktøjer til rådighed:

• RAG-søgning – den klassiske lighedssøgning, i den forbedrede version inklusive kildeangivelse.
• Liste dokumenter – agenten henter alle dokumenter med titler og id’er og overvejer, hvilke der kunne være relevante.
• Hent filindhold – via fil-id’et henter den den fulde tekst i et bestemt dokument (f.eks. referatet fra 23. februar, genkendeligt på titlen).
• SQL-forespørgsel på tabeller – CSV- og Excel-filer forespørges som SQL-tabeller for at muliggøre summer, maksima og lignende udregninger.

I system-prompten får agenten besked på at begynde med RAG og kun gå over til de øvrige værktøjer, når søgningen ikke leverer det rigtige. Et vigtigt råd fra videoen: udtrykkeligt at bede agenten om at være ærlig – altså åbent sige, når der ikke blev fundet et svar – reducerer hallucinationer mærkbart.

Hvordan tabeldata gemmes

Den teknisk mest interessante del handler om tabeller. I Supabase oprettes der tre tabeller til formålet:

• documents – indeholder embeddings til RAG, metadata og indholdet i de enkelte chunks.
• document_metadata – gemmer overordnet information: titel, URL’er til kildeangivelser og – ved tabeller – skemaet (altså kolonnenavnene).
• document_rows – lagrer tabelrækkerne. Selve dataene havner i en fleksibel JSONB-kolonne ved navn row_data.

Fidusen: via JSONB kan vilkårlige kolonnestrukturer gemmes, uden at der skal oprettes en egen SQL-tabel til hver CSV- eller Excel-fil. Agenten læser først skemaet fra metadataene, forstår de tilgængelige kolonner og formulerer så en SQL-forespørgsel mod row_data. Medin gør udtrykkeligt opmærksom på, at denne opsætning er forenklet – skemaet røber f.eks. intet om datatyper, så en sum over en kolonne med dollartegn kan slå fejl. Han er ude efter konceptet, ikke en perfekt implementering.

RAG-pipelinen: fra Google Drive til Supabase

Før agenten kan arbejde, skal videnbasen fyldes. Pipelinen forløber i flere trin:

• Udløser: en Google Drive-trigger tjekker hvert minut for nye eller ændrede filer. Alternativt virker Dropbox eller en lokal fil-trigger. Slettede filer registreres dog ikke.
• Flere filer på én gang: en nyindbygget løkke behandler nu også flere filer, der ankommer i samme polling-interval – en kendt mangel ved den tidligere version.
• Slet gamle data: før hver import fjernes eksisterende poster for det pågældende fil-id. Sådan bliver der ingen forældet chunk tilbage, hvis et dokument er blevet kortere.
• Udtræk indhold: en switch-node forgrener efter filtype – PDF, Google-dokument, tekst eller tabel læses forskelligt. Yderligere formater som JSON eller HTML kan tilføjes med ekstra noder.
• Gem tabeller to gange: CSV-filer forberedes på den ene side som tekstdokument til RAG, på den anden side gemmes de rækkevis i document_rows til SQL-forespørgsler.

En praktisk faldgrube ved opsætningen: til Postgres-forbindelsen til Supabase skal ifølge videoen transaction pooleren bruges (port 6543), ikke den direkte forbindelse. n8n-dokumentationen skulle være uklar på det punkt.

Anvendte modeller

Til embeddings bruges OpenAIs text-embedding-3, som sprogmodel GPT-4o mini – bevidst valgt billig og hurtig. Til mere krævende tilfælde anbefaler Medin kraftigere modeller som GPT-4o eller Claude Sonnet 4. Vigtigt: ved indsættelse og ved hentning skal den samme embedding-model med samme antal dimensioner bruges.

Tre eksempler fra videoen

Medin demonstrerer, hvordan agenten vælger forskellige værktøjer alt efter spørgsmålet:

• Tabelspørgsmål: på “I hvilken måned havde vi flest nye kunder?” skriver agenten en SQL-forespørgsel og leverer det korrekte resultat (december, 129 nye kunder) – i stedet for at forlade sig på ufuldstændige chunks.
• Rent RAG-spørgsmål: på “Hvor kan vi blive bedre?” finder lighedssøgningen feedback-dokumentet, selvom ordet “forbedring” bevidst ikke blev brugt.
• Filhentning med kilde: ved hentning af et komplet mødereferat leverer agenten action items og på forespørgsel et klikbart link til kilden.

Konklusion

Indlægget viser nøgternt, hvorfor naiv RAG ikke rækker til mange forretningsanvendelser: den overser kontekst og kan ikke regne på tabeller. Den agentiske tilgang løser det pragmatisk ved at give AI-agenten flere værktøjer og råderum. For SMV-beslutningstagere, der overvejer en dokumentassistent, er det en vigtig erkendelse: kvaliteten står og falder ikke med modellen alene, men med arkitekturen bag. Overtager du den viste n8n-opsætning, bør du forstå den som et udgangspunkt – prompts, værktøjer og datamodel skal tilpasses din egen datamængde. Netop SQL-forespørgslen på tabeller og håndteringen af datatyper rummer plads til forbedringer.

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