Je kent het misschien: je stelt de interne AI-assistent een vraag, krijgt een vlot antwoord, en ontdekt een dag later dat het niet klopte. Niet omdat het model slecht is, maar omdat het systeem eromheen maar één poging deed om de juiste informatie op te halen.
Zo'n systeem, een AI die eerst relevante fragmenten uit je eigen documenten opzoekt en daarmee een antwoord bouwt, heet in het vak RAG (retrieval-augmented generation). De meeste RAG-systemen die ik in 2026 in productie zie, zijn nog steeds naïef. Eén retriever, één generator, één poging. In 2023 was dat een bruikbaar patroon. Zodra je er echte gebruikers op loslaat, faalt het op voorspelbare momenten. Agentic RAG is de doorontwikkeling daarvan. Zelfde data, zelfde modellen, fundamenteel andere control flow, en het verschil zie je terug in de juistheid, niet alleen in de afwerking.
Hieronder zie je de twee naast elkaar, en waarom de agentic versie fouten oplost voordat ze tot een verkeerd antwoord leiden.
Wat naïeve RAG eigenlijk doet
De naïeve flow is één rechte lijn:
- Zet de vraag om in een embedding (een numerieke weergave van de betekenis)
- Doorzoek daarmee de vector index met je documentfragmenten
- Stop de opgehaalde fragmenten (chunks) in de prompt
- Genereer het antwoord
Zodra dit in productie draait, komen er steeds dezelfde drie faalpatronen naar boven:
Het haalt data één keer op en genereert één keer. Als de eerste retrieval misgrijpt, heeft het systeem geen tweede kans. Het model hallucineert gewoon verder op basis van gedeeltelijke context, en doet dat met veel overtuiging.
Het behandelt elke query hetzelfde. Een simpele opzoekopdracht ("wat is ons annuleringsbeleid?") en een complexe vraag die meerdere zoekstappen combineert ("waarom liep onze Europese cohort in Q3 vorig jaar 2x harder weg dan de Amerikaanse?") lopen door exact hetzelfde retrieve-then-generate pad. De simpele query krijgt overkill, terwijl de complexe query juist te weinig krijgt.
Er is geen verificatie. Het systeem vertrouwt blindelings op wat de retriever teruggeeft. Zijn de chunks off-topic, dan is het antwoord off-topic. Het model weet niet dat het fout zit, want er is geen mechanisme om dat te controleren.
Naïeve RAG is een pipeline. Agentic RAG is een control loop. Het onderscheid zit hier:
| Naïeve RAG | Agentic RAG | |
|---|---|---|
| Zoekpogingen | Eén, ongeacht het resultaat | Meerdere, tot de validator goedkeurt |
| Bronkeuze | Altijd dezelfde vector index | Vector DB, websearch of API |
| Controle op het antwoord | Geen | Validator toetst relevantie en onderbouwing |
| Faalgedrag | Zelfverzekerd fout antwoord | Nieuwe poging, of eerlijk "ik weet het niet" |
Nu de techniek.
De agentic RAG-flow
Agentic RAG introduceert beslismomenten bij elke stap. Het diagram hierboven is één veelgebruikte blueprint, niet de enige, maar het principe is in elke variant hetzelfde: elke fase krijgt een kleine agent die maar één taak heeft, namelijk de volgende stap bewaken.
Stappen 1-2 · Query rewriting. Een rewriter-agent herformuleert de ruwe query. Dit is meer dan typefouten fixen. Het optimaliseert de query voor retrieval: vage termen worden precies gemaakt, complexe queries worden opgesplitst in subqueries, afkortingen worden uitgeschreven. "Hoe gaat het met dat EU-ding?" wordt "Wat is de huidige operationele status van de Europese marktuitbreiding die in Q1 2026 is gelanceerd?"
Stappen 3-5 · Routing. Een router-agent beslist of de query überhaupt externe context nodig heeft. Weet het model het antwoord al uit zijn trainingsdata (parametrische kennis: een definitie, basale feiten), dan wordt retrieval helemaal overgeslagen. Zo niet, dan kiest een source selector de beste backend voor dit specifieke querytype.
Stappen 6-7 · Source selection. De selector routeert naar de meest geschikte bron: vector DB voor semantisch zoeken, websearch voor realtime informatie, gestructureerde API's voor tabulaire of numerieke data. Vervolgens combineert het systeem de opgehaalde context en de herschreven query tot de uiteindelijke prompt.
Stappen 8-9 · Initiële generatie. De LLM produceert een eerste conceptantwoord.
Stappen 10-12 · Validatie (Corrective RAG). Een validator-agent controleert of het antwoord relevant is, gegrond in de opgehaalde bronnen, en compleet. Slaagt het, dan wordt het antwoord teruggegeven. Faalt het, dan gaat het systeem terug naar stap 1 met een geherformuleerde query en draait de hele flow opnieuw.
Die loop gaat door voor een begrensd aantal iteraties, totdat de validator het antwoord goedkeurt of totdat het systeem toegeeft dat het de vraag niet kan beantwoorden met de beschikbare data. Die grens is belangrijk: zonder grens blijft een onbeantwoordbare vraag eindeloos tijd en geld kosten.
Waarom dit werkt
Elke agent vormt een controlepunt op kwaliteit. De rewriter zorgt ervoor dat de retrievalprecisie klopt. De router zorgt ervoor dat de juiste bron bevraagd wordt. De validator zorgt ervoor dat de output daadwerkelijk gegrond is in wat opgehaald is. Individuele fouten worden opgevangen en gecorrigeerd in plaats van ongemerkt door te sijpelen naar de gebruiker.
Dat laatste punt benadruk ik bij klanten steeds weer. In een naïef RAG-systeem resulteert een slechte retrieval in een antwoord dat fout is, maar zelfverzekerd klinkt. In een agentic RAG-systeem wordt diezelfde slechte retrieval opgevangen bij de validator en wordt de query opnieuw gedraaid. De gebruiker ziet een trager maar correct antwoord in plaats van een snel maar fout antwoord.
Er is uiteraard een prijs. Meer agents betekent meer LLM-calls, en dat betekent meer latency en hogere kosten. Een naïeve RAG-query kost misschien €0,001 en is klaar in 800ms. Een agentic RAG-query die door drie iteraties heen loopt, kost misschien €0,008 en is klaar in 4 seconden. Of die ruil het waard is, hangt volledig af van wat fout betekent binnen jouw domein. Voor een documentatiechat waar de kosten van een fout antwoord neerkomen op "de gebruiker klikt een ander resultaat aan," is snel en af en toe fout prima. Voor een klantenservice-agent waar een fout antwoord uitmondt in een terugbetaling of een klacht, is gevalideerd en trager de enige acceptabele vorm.
Voor wie is dit nu interessant?
Veel Nederlandse bedrijven bouwen nu hun eerste AI-assistent op eigen documentatie, vrijwel altijd als naïeve RAG. Voor een interne kennisbank of documentatiechat, waar de gebruiker zelf kan checken of het antwoord klopt, is naïeve RAG een prima startpunt. Agentic RAG wordt interessant zodra antwoorden richting klanten gaan of geld kosten als ze fout zijn: klantenservice, prijzen en voorwaarden, alles wat juridisch of medisch raakt.
De realistische eerste stap is niet het hele diagram, maar eerst een validator toevoegen aan je bestaande systeem, daarna query rewriting. Eén nuchtere kanttekening uit de Nederlandse praktijk: vaak zit het probleem niet in de architectuur maar in de data. Verouderde documentatie die zichzelf tegenspreekt laat de mooiste control loop tegen ruis valideren; opruimen is dan de eerste stap, geen extra agents.
Hoe productie eruitziet in 2026
Het diagram hierboven is één blueprint, niet dé blueprint. Productiesystemen combineren en variëren:
- Corrective RAG voor de validatieloop na de generatie
- Adaptive RAG voor de routinglogica die op basis van querycomplexiteit tussen strategieën kiest
- Self-RAG waarbij het model expliciet "retrieve"-tokens afgeeft om halverwege de generatie opzoekingen te triggeren
- Hybride search die vector- en lexicale (BM25) retrieval combineert, meestal met een reranker erbovenop
Een productiesysteem dat ik vorig kwartaal opgeleverd heb, gebruikt alle vier. De router draait Adaptive RAG om op basis van query-intentie tussen drie strategieën te kiezen. Twee van die strategieën gebruiken hybride search met een Voyage AI-reranker. De validator is een Corrective RAG-loop met een budget van 2 iteraties. Self-RAG zit er niet in, want voor dat domein woog de latencykost niet op tegen de accuraatheidswinst.
Het punt is niet om elke variant te implementeren. Het punt is om te erkennen dat "RAG" in 2026 geen eenduidige architectuur meer is. Het is een familie van patronen, en naïeve RAG is het simpelste lid van die familie, zoals naive Bayes het simpelste lid is van de Bayesiaanse familie. Gebruik het waar het past. Grijp naar de agentic versies wanneer juistheid belangrijker is dan doorvoer.
Drie regels die ik mijn jongere zelf zou meegeven
- Zet geen naïeve RAG live op plekken waar een fout antwoord geld kost. Het is een prima prototype en interne tool, geen goed klantgericht product. Zodra gebruikers tweede-orde vragen beginnen te stellen, heb je op zijn minst query rewriting en validatie nodig.
- Bouw eerst de validator. Het is de meest onderschatte component in elk RAG-project dat ik geaudit heb. Een goede validator maakt van een systeem met 60% accuraatheid er een met 85%, zonder dat je aan de retriever hoeft te sleutelen.
- Behandel de router als het beslissende onderdeel. In de router bepaalt het systeem met wat voor soort probleem het te maken heeft. Slechte routing betekent dat de rest van het systeem heel precies het verkeerde werk doet.
Naïeve RAG was het juiste patroon toen LLM-agents nog broos en duur waren. Mijn inschatting: in 2026 zijn ze robuust en goedkoop genoeg dat die reden grotendeels vervallen is. Bouw de agentic variant als je wilt dat een systeem blijft doorzoeken tot het antwoord klopt, in plaats van genoegen te nemen met een half antwoord.