- \n
- Klassieke RAG faalt vooral op twee punten: ze kan niet naar hele documenten “uitzoomen” en ze kan geen echte data-analyse over tabellen uitvoeren.<\/li>\n
- Agentic RAG geeft de AI-agent meerdere instrumenten in plaats van alleen een zoekfunctie \u2013 hij bepaalt zelf hoe hij de kennisdatabase doorzoekt.<\/li>\n
- Tabellen (CSV\/Excel) worden apart opgeslagen, zodat ze via SQL bevraagd kunnen worden \u2013 zonder voor elk bestand een eigen tabel aan te leggen.<\/li>\n
- De agent kan documenten opsommen, hele bestanden ophalen, bronnen citeren en zo nodig de zoekopdracht verbeteren.<\/li>\n
- De getoonde n8n-opzet is een uitbreidbaar sjabloon, geen kant-en-klaar product \u2013 prompts en instrumenten moeten aan de eigen toepassing worden aangepast.<\/li>\n<\/ul>\n<\/div>\n
![\"Vergelijking](\"https:\/\/pletzenauer.com\/wp-content\/uploads\/2026\/06\/1487-1.png\")
Agentic RAG geeft de AI-agent meerdere instrumenten in plaats van alleen een zoekfunctie.<\/figcaption><\/figure>\n Waarom klassieke RAG in de praktijk teleurstelt<\/h2>\n
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.<\/p>\n
Medin noemt twee concrete zwakke plekken:<\/p>\n
- \n
- Geen blik op hele documenten:<\/strong> RAG haalt alleen losse fragmenten aan. Wie trends in een tabel wil analyseren, krijgt misschien maar een kwart van de rijen \u2013 en daarmee een verkeerd resultaat.<\/li>\n
- Geen echte data-analyse:<\/strong> Sommen of maximumwaarden over een tabel laten zich met een pure tekstzoekopdracht niet betrouwbaar berekenen.<\/li>\n<\/ul>\n
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 \u2013 hoewel de datum in de titel staat. En verschillende documenten met elkaar verbinden om een breder verband te leggen, lukt zelden.<\/p>\n
Wat agentic RAG anders doet<\/h2>\n
De kerngedachte is eenvoudig: in plaats van de AI-agent slechts \u00e9\u00e9n zoekinstrument te geven, krijgt hij er meerdere \u2013 en mag hij zelf bepalen hoe hij de kennisdatabase ontsluit. Medin definieert agentic RAG zo:<\/p>\n
Agentic RAG betekent de agent het vermogen geven om na te denken over hoe<\/strong> hij de kennisdatabase doorzoekt \u2013 in plaats van hem op \u00e9\u00e9n instrument vast te pinnen.<\/p><\/blockquote>\n
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.<\/p>\n
De vier instrumenten van de agent<\/h3>\n
In de n8n-workflow staan de agent de volgende instrumenten ter beschikking:<\/p>\n
- \n
- RAG-zoekopdracht<\/strong> \u2013 de klassieke gelijkenis-zoekopdracht, in de verbeterde versie inclusief bronvermelding.<\/li>\n
- Documenten opsommen<\/strong> \u2013 de agent haalt alle documenten met titels en ID’s op en overweegt welke relevant kunnen zijn.<\/li>\n
- Bestandsinhoud ophalen<\/strong> \u2013 via de bestands-ID haalt hij de volledige tekst van een bepaald document op (bijvoorbeeld de notulen van 23 februari, herkenbaar aan de titel).<\/li>\n
- SQL-query over tabellen<\/strong> \u2013 CSV- en Excel-bestanden worden als SQL-tabellen bevraagd, om sommen, maxima en soortgelijke analyses mogelijk te maken.<\/li>\n<\/ul>\n
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 \u2013 dus open zeggen wanneer er geen antwoord is gevonden \u2013 vermindert hallucinaties merkbaar.<\/p>\n
Hoe tabeldata worden opgeslagen<\/h2>\n
Het technisch interessantste deel betreft tabellen. In Supabase worden daarvoor drie tabellen aangelegd:<\/p>\n
- \n
- documents<\/strong> \u2013 bevat de embeddings voor RAG, metadata en de inhoud van de afzonderlijke chunks.<\/li>\n
- document_metadata<\/strong> \u2013 slaat overkoepelende informatie op: titels, URL’s voor bronvermeldingen en \u2013 bij tabellen \u2013 het schema (dus de kolomnamen).<\/li>\n
- document_rows<\/strong> \u2013 legt de tabelrijen vast. De eigenlijke data belanden in een flexibele JSONB<\/strong>-kolom met de naam
row_data<\/code>.<\/li>\n<\/ul>\nDe 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<\/code>. Medin wijst er uitdrukkelijk op dat deze opzet vereenvoudigd is \u2013 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.<\/p>\nDe RAG-pijplijn: van Google Drive naar Supabase<\/h2>\n
Voordat de agent kan werken, moet de kennisdatabase gevuld worden. De pijplijn verloopt daarbij in meerdere stappen:<\/p>\n
- \n
- Trigger:<\/strong> 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.<\/li>\n
- Meerdere bestanden tegelijk:<\/strong> Een nieuw ingebouwde lus verwerkt nu ook meerdere bestanden die in hetzelfde polling-interval binnenkomen \u2013 een bekend tekort van de vorige versie.<\/li>\n
- Oude data verwijderen:<\/strong> V\u00f3\u00f3r elke import worden bestaande records bij de betreffende bestands-ID verwijderd. Zo blijft er geen verouderde chunk achter wanneer een document korter is geworden.<\/li>\n
- Inhoud extraheren:<\/strong> Een switch-knooppunt vertakt per bestandstype \u2013 PDF, Google Doc, tekst of tabel worden verschillend uitgelezen. Verdere formaten zoals JSON of HTML laten zich via extra knooppunten aanvullen.<\/li>\n
- Tabellen dubbel opslaan:<\/strong> CSV-bestanden worden enerzijds als tekstdocument voor RAG klaargezet, anderzijds rij voor rij in
document_rows<\/code> opgeslagen voor SQL-query’s.<\/li>\n<\/ul>\nEen praktisch struikelblok bij de inrichting: voor de Postgres-verbinding met Supabase moet volgens de video de transaction pooler<\/strong> worden gebruikt (poort 6543), niet de directe verbinding. De n8n-documentatie zou op dit punt onduidelijk zijn.<\/p>\n
Gebruikte modellen<\/h3>\n
Voor de embeddings komt OpenAI’s
text-embedding-3<\/code> aan bod, als taalmodelGPT-4o mini<\/code> \u2013 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.<\/p>\nDrie voorbeelden uit de video<\/h2>\n
Medin demonstreert hoe de agent afhankelijk van de vraag verschillende instrumenten kiest:<\/p>\n
- \n
- Tabelvraag:<\/strong> 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) \u2013 in plaats van op onvolledige chunks te vertrouwen.<\/li>\n
- Pure RAG-vraag:<\/strong> Op “Waar kunnen we beter worden?” vindt de gelijkenis-zoekopdracht het feedbackdocument, hoewel het woord “verbetering” bewust niet is gebruikt.<\/li>\n
- Bestand ophalen met bron:<\/strong> Bij het ophalen van complete vergadernotulen levert de agent de action items en op navraag een aanklikbare link naar de bron.<\/li>\n<\/ul>\n
Conclusie<\/h2>\n
De bijdrage laat nuchter zien waarom na\u00efeve 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 \u2013 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.<\/p>\n
- Pure RAG-vraag:<\/strong> Op “Waar kunnen we beter worden?” vindt de gelijkenis-zoekopdracht het feedbackdocument, hoewel het woord “verbetering” bewust niet is gebruikt.<\/li>\n
- Meerdere bestanden tegelijk:<\/strong> Een nieuw ingebouwde lus verwerkt nu ook meerdere bestanden die in hetzelfde polling-interval binnenkomen \u2013 een bekend tekort van de vorige versie.<\/li>\n
- document_metadata<\/strong> \u2013 slaat overkoepelende informatie op: titels, URL’s voor bronvermeldingen en \u2013 bij tabellen \u2013 het schema (dus de kolomnamen).<\/li>\n
- Documenten opsommen<\/strong> \u2013 de agent haalt alle documenten met titels en ID’s op en overweegt welke relevant kunnen zijn.<\/li>\n
- Geen echte data-analyse:<\/strong> Sommen of maximumwaarden over een tabel laten zich met een pure tekstzoekopdracht niet betrouwbaar berekenen.<\/li>\n<\/ul>\n
- Geen blik op hele documenten:<\/strong> RAG haalt alleen losse fragmenten aan. Wie trends in een tabel wil analyseren, krijgt misschien maar een kwart van de rijen \u2013 en daarmee een verkeerd resultaat.<\/li>\n