Agentic RAG in n8n: waarom klassieke RAG vaak faalt – en hoe het beter kan

Veel bedrijven zetten tegenwoordig in op AI-assistenten die vragen over eigen documenten moeten beantwoorden – over vergadernotulen, kengetallentabellen of klantfeedback. De gangbare methode daarachter heet Retrieval Augmented Generation (RAG). Ze is wijdverbreid, goed ondersteund en in no-code-instrumenten als n8n snel gerealiseerd. Alleen: in de praktijk levert klassieke RAG verrassend vaak onjuiste of onvolledige antwoorden. Cole Medin laat in zijn video zien waar dat aan ligt en hoe een zogenoemde agentic-RAG-opzet de typische zwaktes omzeilt. Ik vat de belangrijkste punten nuchter samen.

Waarom klassieke RAG in de praktijk teleurstelt

RAG werkt via een gelijkenis-zoekopdracht: de vraag wordt vergeleken met opgeslagen tekstfragmenten (“chunks”), en de best passende gaan door naar het taalmodel. Het probleem is de selectie. Die mist regelmatig belangrijke context.

Medin noemt twee concrete zwakke plekken:

• Geen blik op hele documenten: RAG haalt alleen losse fragmenten aan. Wie trends in een tabel wil analyseren, krijgt misschien maar een kwart van de rijen – en daarmee een verkeerd resultaat.
• Geen echte data-analyse: Sommen of maximumwaarden over een tabel laten zich met een pure tekstzoekopdracht niet betrouwbaar berekenen.

Daar komt een praktisch ongemak bij: wordt er naar de notulen van een bepaalde datum gevraagd, dan haalt RAG soms het document van de verkeerde dag – hoewel de datum in de titel staat. En verschillende documenten met elkaar verbinden om een breder verband te leggen, lukt zelden.

Wat agentic RAG anders doet

De kerngedachte is eenvoudig: in plaats van de AI-agent slechts één zoekinstrument te geven, krijgt hij er meerdere – en mag hij zelf bepalen hoe hij de kennisdatabase ontsluit. Medin definieert agentic RAG zo:

Agentic RAG betekent de agent het vermogen geven om na te denken over hoe hij de kennisdatabase doorzoekt – in plaats van hem op één instrument vast te pinnen.

Concreet kan de agent daardoor zijn zoekopdrachten verbeteren, zo nodig een ander instrument kiezen en meerdere wegen proberen tot hij een houdbaar antwoord heeft. Faalt de pure RAG-zoekopdracht, dan zit hij niet langer vast.

De vier instrumenten van de agent

In de n8n-workflow staan de agent de volgende instrumenten ter beschikking:

• RAG-zoekopdracht – de klassieke gelijkenis-zoekopdracht, in de verbeterde versie inclusief bronvermelding.
• Documenten opsommen – de agent haalt alle documenten met titels en ID’s op en overweegt welke relevant kunnen zijn.
• Bestandsinhoud ophalen – via de bestands-ID haalt hij de volledige tekst van een bepaald document op (bijvoorbeeld de notulen van 23 februari, herkenbaar aan de titel).
• SQL-query over tabellen – CSV- en Excel-bestanden worden als SQL-tabellen bevraagd, om sommen, maxima en soortgelijke analyses mogelijk te maken.

In de systeemprompt krijgt de agent de instructie met RAG te beginnen en pas naar de overige instrumenten uit te wijken wanneer de zoekopdracht niet het juiste oplevert. Een belangrijke aanwijzing uit de video: de agent uitdrukkelijk tot eerlijkheid aansporen – dus open zeggen wanneer er geen antwoord is gevonden – vermindert hallucinaties merkbaar.

Hoe tabeldata worden opgeslagen

Het technisch interessantste deel betreft tabellen. In Supabase worden daarvoor drie tabellen aangelegd:

• documents – bevat de embeddings voor RAG, metadata en de inhoud van de afzonderlijke chunks.
• document_metadata – slaat overkoepelende informatie op: titels, URL’s voor bronvermeldingen en – bij tabellen – het schema (dus de kolomnamen).
• document_rows – legt de tabelrijen vast. De eigenlijke data belanden in een flexibele JSONB-kolom met de naam row_data.

De truc: via JSONB laten zich willekeurige kolomstructuren opslaan zonder voor elk CSV- of Excel-bestand een eigen SQL-tabel te moeten aanmaken. De agent leest eerst het schema uit de metadata, begrijpt de beschikbare kolommen en formuleert dan een SQL-query tegen row_data. Medin wijst er uitdrukkelijk op dat deze opzet vereenvoudigd is – het schema verraadt bijvoorbeeld niets over datatypes, waardoor een som over een kolom met dollartekens kan mislukken. Het gaat hem om het concept, niet om een perfecte uitvoering.

De RAG-pijplijn: van Google Drive naar Supabase

Voordat de agent kan werken, moet de kennisdatabase gevuld worden. De pijplijn verloopt daarbij in meerdere stappen:

• Trigger: Een Google Drive-trigger controleert elke minuut op nieuwe of gewijzigde bestanden. Als alternatief werken Dropbox of een lokale bestandstrigger. Verwijderde bestanden worden echter niet herkend.
• Meerdere bestanden tegelijk: Een nieuw ingebouwde lus verwerkt nu ook meerdere bestanden die in hetzelfde polling-interval binnenkomen – een bekend tekort van de vorige versie.
• Oude data verwijderen: Vóór elke import worden bestaande records bij de betreffende bestands-ID verwijderd. Zo blijft er geen verouderde chunk achter wanneer een document korter is geworden.
• Inhoud extraheren: Een switch-knooppunt vertakt per bestandstype – PDF, Google Doc, tekst of tabel worden verschillend uitgelezen. Verdere formaten zoals JSON of HTML laten zich via extra knooppunten aanvullen.
• Tabellen dubbel opslaan: CSV-bestanden worden enerzijds als tekstdocument voor RAG klaargezet, anderzijds rij voor rij in document_rows opgeslagen voor SQL-query’s.

Een praktisch struikelblok bij de inrichting: voor de Postgres-verbinding met Supabase moet volgens de video de transaction pooler worden gebruikt (poort 6543), niet de directe verbinding. De n8n-documentatie zou op dit punt onduidelijk zijn.

Gebruikte modellen

Voor de embeddings komt OpenAI’s text-embedding-3 aan bod, als taalmodel GPT-4o mini – bewust goedkoop en snel gekozen. Voor veeleisender gevallen adviseert Medin krachtiger modellen als GPT-4o of Claude Sonnet 4. Belangrijk: bij het invoegen en bij het ophalen moet hetzelfde embeddingmodel met hetzelfde aantal dimensies worden gebruikt.

Drie voorbeelden uit de video

Medin demonstreert hoe de agent afhankelijk van de vraag verschillende instrumenten kiest:

• Tabelvraag: Op “In welke maand hadden we de meeste nieuwe klanten?” schrijft de agent een SQL-query en levert het juiste resultaat (december, 129 nieuwe klanten) – in plaats van op onvolledige chunks te vertrouwen.
• Pure RAG-vraag: Op “Waar kunnen we beter worden?” vindt de gelijkenis-zoekopdracht het feedbackdocument, hoewel het woord “verbetering” bewust niet is gebruikt.
• Bestand ophalen met bron: Bij het ophalen van complete vergadernotulen levert de agent de action items en op navraag een aanklikbare link naar de bron.

Conclusie

De bijdrage laat nuchter zien waarom naïeve RAG voor veel zakelijke toepassingen niet volstaat: ze mist context en kan niet rekenen met tabellen. De agentic aanpak lost dat pragmatisch op door de AI-agent meerdere instrumenten en beslissingsruimte te geven. Voor mkb-beslissers die een documentassistent overwegen, is dat een belangrijk inzicht: de kwaliteit staat of valt niet met het model alleen, maar met de architectuur erachter. Wie de gepresenteerde n8n-opzet overneemt, moet die als vertrekpunt zien – prompts, instrumenten en datamodel horen op de eigen databestanden te worden afgestemd. Juist de SQL-query over tabellen en de omgang met datatypes bieden ruimte voor verbetering.

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