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. Dat ligt zelden aan het model. Het systeem eromheen deed maar één poging 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: één retriever, één generator en éé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. Het gebruikt dezelfde data en dezelfde modellen, maar de control flow eromheen ziet er anders uit. Dat verschil zit in de juistheid van de antwoorden, 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 gaat 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 heeft geen mechanisme om te controleren of het fout zit.
Het verschil met de agentic variant zit hem in de besturing eromheen, en dat laat zich zo samenvatten:
| 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" |
De agentic RAG-flow
Agentic RAG introduceert beslismomenten bij elke stap. Het diagram hierboven is één veelgebruikte blueprint van de vele die in omloop zijn, 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 gaat verder 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. 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. Let op de plaats van die controle: hier wordt het gegenereerde antwoord getoetst. Er bestaan ook varianten die juist de opgehaalde documenten beoordelen voordat er iets gegenereerd wordt, en in een volwassen systeem doe je allebei.
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 bewaakt de retrievalprecisie. De router bewaakt dat de juiste bron bevraagd wordt. De validator bewaakt 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, weegt een gevalideerd en trager antwoord vrijwel altijd zwaarder.
Wanneer naïef volstaat en wanneer je de loop nodig hebt
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 dat 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. Voeg eerst een validator toe aan je bestaande systeem, daarna query rewriting. Eén nuchtere kanttekening uit de Nederlandse praktijk: vaak zit het probleem in de data en niet in de architectuur. Verouderde documentatie die zichzelf tegenspreekt laat de mooiste control loop tegen ruis valideren. Opruimen komt dan eerst, extra agents daarna.
Hoe productie eruitziet in 2026
Het diagram hierboven is één blueprint van de vele mogelijke. Productiesystemen combineren en variëren:
- Corrective RAG waarbij een aparte evaluator de opgehaalde documenten beoordeelt en per uitkomst een actie kiest: gebruiken, verwerpen of aanvullen met een websearch
- Adaptive RAG voor de routinglogica die op basis van querycomplexiteit tussen strategieën kiest, van helemaal geen retrieval tot een meerstapszoektocht
- Self-RAG waarbij het model expliciet "retrieve"-tokens afgeeft om halverwege de generatie opzoekingen te triggeren, en met vergelijkbare tokens zijn eigen antwoord beoordeelt
- 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 validatielus is gebouwd naar het Corrective RAG-idee, met een budget van 2 iteraties. Self-RAG zit er niet in, want voor dat domein woog de latencykost niet op tegen de accuraatheidswinst.
Je hoeft niet elke variant te implementeren. Waar het om gaat, is erkennen dat "RAG" in 2026 een familie van patronen is geworden in plaats van één architectuur. Naïeve RAG is daarvan het simpelste lid. Gebruik het waar het past, en grijp naar de agentic versies wanneer juistheid zwaarder weegt 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 een prima interne tool, maar als klantgericht product schiet het tekort. 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. In de projecten die ik heb begeleid, tilde een goede validator de accuraatheid van rond de 60% naar rond de 85%, zonder dat er aan de retriever gesleuteld werd.
- 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.