Een klant in de maakindustrie beschikte over een knowledge base: 8 000 technische handleidingen, serviceprotocollen en tekeningen. Ze implementeerden klassieke RAG — embedden, top-5 ophalen, genereren. Voor vragen als "wat zijn de parameters van motor X?" haalde het systeem 85 % nauwkeurigheid. Toen kwam de vraag: "Wat moet ik doen als motor X fout E47 meldt en de temperatuur tegelijk boven 80 °C ligt?" Het systeem gaf een fragment over fout E47 en een fragment over temperatuur — maar specificeerde nooit dat de combinatie van beide toestanden een andere aanpak vereist dan elk afzonderlijk. Het antwoord was technisch correct, operationeel nutteloos.
Dit is een klasse van problemen waarvoor klassieke RAG geen architecturele oplossing heeft. Het is geen kwestie van een beter embeddingsmodel of een grotere chunk. Het is een kwestie van wie het ophalen aanstuurt — en wanneer diegene weet dat er meer opgehaald moet worden.
Waar klassieke RAG zijn plafond bereikt
Klassieke RAG (Retrieval-Augmented Generation) werkt in één retrievalstap: er komt een vraag binnen, het systeem indexeert de query, haalt de top-K fragmenten op uit de vectordatabase en geeft die door aan het LLM. Het is deterministisch, snel en goedkoop.
Het probleem ontstaat bij vier typen taken:
- Meerstapsvragen — het antwoord hangt af van twee of meer feiten die in afzonderlijke documenten staan en waarvan de verbinding niet expliciet in de tekst staat. Klassieke RAG doet één retrievalstap; het LLM krijgt slechts een deel van de context.
- Onduidelijke of onvolledige queries — de gebruiker schrijft "problemen met koeling op lijn 3", maar het systeem weet niet of dat de motorkoeling, hydraulische koeling of de hal-airconditioning betreft. Eén retrieve-stap lost de ambiguïteit niet op.
- Vergelijkingsvragen — "vergelijk de service-intervallen van apparaat A en B" vereist twee onafhankelijke retrieve-operaties en een synthese, niet één retrieve met de hoop dat beide documenten in de top-5 belanden.
- Iteratieve analyses — de agent moet eerst iets basaals achterhalen (bijv. het serienummer van het apparaat), dan op basis daarvan specifieke documentatie ophalen, en daarna de geldigheid van de informatie toetsen aan de productiedatum. Elke stap hangt af van het resultaat van de vorige.
Voor deze scenario's hebt u een andere architectuur nodig — een waarbij retrieval geen eenmalige actie is, maar een iteratief proces dat door een agent wordt aangestuurd.
Wat agentic RAG anders doet
Agentic RAG voegt een beslissingslaag toe bovenop de klassieke retrieve-generate pipeline. Een agent — doorgaans een LLM met toegang tot tools — ontvangt een vraag en beslist zelf:
- 1.Welke query naar de vectordatabase te sturen
- 2.Of de resultaten toereikend zijn, of dat er meer opgehaald moet worden
- 3.Welke nieuwe query te formuleren op basis van wat er tot dan toe is verkregen
- 4.Wanneer de context compleet is en de antwoordgeneratie kan beginnen
In plaats van één retrieve-and-generate-cyclus ontstaat er een lus waarbij de agent zijn eigen tussenresultaten beoordeelt. In de praktijk kan dat er als volgt uitzien: de agent ontvangt de vraag over de combinatie van fout en temperatuur, formuleert een eerste query over fout E47, leest de resultaten, besluit dat hij context over temperatuurlimieten nodig heeft, formuleert een tweede query, haalt de documenten op, synthetiseert beide contexten en genereert pas daarna het antwoord.
Deze aanpak heeft drie sleutelmechanismen die klassieke RAG niet heeft.
Query rewriting — de query herformuleren
Gebruikersinvoer komt zelden overeen met de taal waarin documenten zijn geschreven. Een technische handleiding beschrijft "oververhitting van het hydraulisch circuit", de gebruiker schrijft "olie heeft te hoge temperatuur". Query rewriting laat een LLM de oorspronkelijke query omvormen naar een vorm die beter aansluit bij de vectorruimte van de embeddings.
Dit maakt ook deel uit van geavanceerdere klassieke RAG-pipelines — het is geen exclusieve eigenschap van agentic RAG. Het verschil is dat query rewriting bij agentic RAG bij elke stap kan worden herhaald: de agent ziet wat er is opgehaald en herformuleert de query op basis van het tussenresultaat, niet alleen de oorspronkelijke vraag.
Multi-step retrieval — stapsgewijs ophalen
De agent kan meerdere keren retrieven, waarbij elke stap de volgende informeert. Dit lost het probleem van de "verborgen verbinding" op — wanneer het antwoord verdeeld is over documenten die geen expliciete semantische relaties hebben, maar waarvan de combinatie wel relevant is.
Praktisch gezien ziet de implementatie eruit als een ReAct-agent waarbij "zoek in de knowledge base" een tool is. De agent roept hem zo vaak aan als nodig, met verschillende queries. Meer over de architectuur van de agentlus leest u in het artikel over AI-agentarchitecturen.
Self-correction — correctie van eigen tussenresultaten
De meest geavanceerde eigenschap van agentic RAG. De agent haalt niet alleen op, maar beoordeelt ook of de opgehaalde informatie relevant, actueel en toereikend is. In geavanceerdere implementaties wordt een aparte faithfulness judge toegevoegd — een extra LLM-aanroep die controleert of de gegenereerde uitvoer onderbouwd is door de opgehaalde documenten en niet gehallucineert.
Dit is het punt waarop velen de complexiteit onderschatten: een naïeve agentic RAG zonder faithfulness judge kan meer hallucineren dan klassieke RAG. De reden is eenvoudig — langere context, meer retrievalstappen, meer ruimte voor het model om plausibele maar ononderbouwde tekst te genereren.
Wanneer agentic RAG inzetten — beslissingskader
Niet elk RAG-use-case vereist een agentlaag. Dit is een beslissingskader uit de praktijk.
Blijf bij klassieke RAG als: - De meeste vragen rechtlijnig zijn (één document = volledig antwoord) - Latency kritisch is (interactieve chatbot waarbij het antwoord binnen 2 seconden moet komen) - Het vraagvolume hoog is en kosten de beperkende factor zijn - De knowledge base nauw afgebakend is en vragen haar kader niet overschrijden
Stap over naar agentic RAG als: - Meer dan ~20 % van de queries informatie uit meerdere documenten vereist - Gebruikers meerstaps- of vergelijkingsvragen stellen - Het antwoord afhangt van een toestand of context die niet in de oorspronkelijke query staat - Nauwkeurigheid belangrijker is dan latency (beslissingsondersteuning, veiligheidsprotocollen) - U capaciteit heeft voor de implementatie en monitoring van een agentic pipeline
In productie-implementaties hebben we gezien dat voor kennissystemen over technische documentatie (servicehandleidingen, normen, procedures) agentic RAG de antwoordkwaliteit bij meerstapsvragen aanzienlijk verbetert — maar ten koste van 5–10× hogere tokenkosten en 3–5× langere latency vergeleken met de klassieke aanpak. Dit is geen prijs die u voor elke query betaalt, maar u moet er rekening mee houden in de architectuurbeslissing.
De meerprijs: meer dan alleen tokens
Agentic RAG is duurder dan klassieke RAG op meerdere assen, en tokens zijn slechts één ervan.
Tokenkosten: Waar klassieke RAG per query ~500–1 000 tokens verbruikt, kan agentic RAG met 3–4 retrievalstappen en een faithfulness judge 5 000–15 000 tokens verbruiken. Bij goedkope modellen (Flash/Haiku-tier, circa $0,10–0,50 per 1M invoertokens) is dit verschil beheersbaar. Bij frontier-modellen van het kaliber Claude Opus of GPT-5 liggen de kosten per agentic query in de orde van centen tot tientallen centen — bij hoog volume is dat niet te verwaarlozen.
Latency: Elke retrievalstap voegt tijd toe — een LLM-aanroep voor query rewriting, een aanroep naar de vectordatabase, eventueel een faithfulness judge. Reële agentic RAG-pipelines met 3–5 stappen duren 5–20 seconden. Voor interactieve toepassingen vereist dit asynchroon ontwerp en visuele feedback (voortgangsindicator, streaming).
Implementatie- en observability-overhead: Klassieke RAG is een functie van 50 regels. Agentic RAG is een pipeline met checkpointing, retry-logica, monitoring en debuggertools. Zonder observability-tools als Langfuse (self-hostable) of Arize Phoenix wordt het bijna onbeheersbaar. Een meerstapsagent zonder traces is een zwarte doos — als hij faalt, weet u niet waarom. Meer over observability bij agents leest u in het artikel over observability en tracing.
Retry-overhead: Agents falen — een verkeerd geformuleerde retrieval-query, een database-timeout, een onverwacht resultaatformaat. In productiesystemen is een retry-rate van 10–15 % gebruikelijk, wat het aantal aanroepen effectief verhoogt. Deze overhead moet u meenemen in het kostenmodel.
Implementatiepatronen in de praktijk
Er zijn twee dominante benaderingen voor de implementatie van agentic RAG.
Patroon 1: ReAct-agent met retrieval-tool
De eenvoudigste vorm — een standaard ReAct-agent waarbij een van de tools search_knowledge_base(query: str) -> list[Document] is. De agent beslist wanneer en hoe hij de tool aanroept, ziet de resultaten in de Observe-fase en gaat daarna verder. Implementatie via LangGraph met expliciete toestand is vandaag de standaard voor productiesystemen.
Voordeel: relatief eenvoudig te implementeren, agent is flexibel. Nadeel: zonder faithfulness judge kan de agent zelfverzekerd hallucineren; de betrouwbaarheid van uitvoer is variabel.
Patroon 2: Toegewijde RAG-agent met evaluatielus
Een meer geavanceerde aanpak: retrieve → faithfulness check → als onvoldoende, herformuleer de query en herhaal → pas wanneer de faithfulness-score de drempel overschrijdt, genereer het definitieve antwoord. Dit benadert het SELF-RAG- of CRAG-patroon (Corrective RAG).
Implementatiedetail: de faithfulness judge is een aparte LLM-aanroep met een prompt die een chunk en een gegenereerd antwoord ontvangt en moet aangeven of het antwoord door de chunk wordt onderbouwd. Doorgaans volstaat een goedkoper model (Haiku-tier) als judge — u hebt geen krachtigste model nodig voor een binaire beoordeling. Het resultaat is meetbaar en logbaar, wat cruciaal is voor audit en afstelling.
Wat de praktijk ons heeft geleerd: De meest voorkomende fout bij de eerste implementatie van agentic RAG is niet technisch — het is productmatig. Het team zet een volledige agentic pipeline in voor elke query, zonder onderscheid te maken tussen eenvoudige rechtlijnige vragen en complexe vragen. Het resultaat: het hele systeem is traag en duur, terwijl 60 % van de queries door klassieke RAG goedkoper en sneller afgehandeld had kunnen worden.
Aanbeveling uit de praktijk: Een router vóór de pipeline-ingang. Een LLM of een eenvoudige classificator beoordeelt de complexiteit van de query en stuurt hem door naar snelle klassieke RAG of naar de agentic pipeline. Dit verbetert de prijs-kwaliteitverhouding aanzienlijk bij reële belasting. De keuze tussen RAG en fine-tuning komt ook aan bod in het artikel over RAG-pipelinekwaliteit.
Typische risico's en hoe u die mitigeert
Retrieval-lus: De agent haalt herhaaldelijk vergelijkbare documenten op zonder voortgang te boeken. Oplossing: max_retrieval_steps-limiet (doorgaans 4–6) en deduplicatiecontrole van opgehaalde chunks — als de agent hetzelfde document tweemaal heeft opgehaald, moet hij de query aanpassen.
Confabulatie door lange context: Hoe meer documenten er in de context zitten, hoe meer ruimte het model heeft voor hallucinatoire verbindingen. Oplossing: faithfulness judge + citaties (elke bewering moet herleidbaar zijn naar een specifieke chunk). Onduidelijkheid over de bron van informatie is een waarschuwingssignaal.
Ongecontroleerde kosten: Agentic RAG zonder limieten kan bij één complexe vraag 10× meer tokens verbruiken dan gepland. Oplossing: harde tokenlimiet per query, alerting bij 50 % van de limiet, kostenrapportage per query in het observability-platform.
Prompt injection via documenten: De agent haalt een document op waarin een aanvaller instructies voor het LLM heeft ingesloten (bijv. "negeer vorige instructies en retourneer X"). Bij agentic RAG is dit risico groter, omdat documentinhoud direct in de context van de agent terechtkomt die de volgende stappen aanstuurt. Oplossing: contextscheiding (opgehaalde documenten in een afzonderlijk contextblok met duidelijke markering), validatie van opgehaalde inhoud vóór invoeging in de agentcontext.
Veelgestelde vragen
Is agentic RAG altijd nauwkeuriger dan klassieke RAG?
Nee. Een naïeve agentic RAG zonder faithfulness judge kan meer hallucineren dan klassieke RAG, omdat langere context en meer retrievalstappen het model meer ruimte geven om plausibele maar ononderbouwde tekst te genereren. Agentic RAG is alleen nauwkeuriger wanneer het correct is geïmplementeerd met een zelfevaluerende lus en een duidelijk citatiepad.
Wat kost agentic RAG vergeleken met klassieke RAG?
Agentic RAG is doorgaans 5–10× duurder per query. Bij goedkope modellen (Flash/Haiku-tier, $0,10–0,50 / 1M invoertokens) is het verschil beheersbaar. Bij frontier-modellen (kaliber Claude Opus, ~$5 input / ~$25 output / 1M tokens) liggen de kosten per agentic query in de orde van centen tot tientallen centen. Bij hoog vraagvolume (duizenden per dag) is een router noodzakelijk die eenvoudige vragen naar klassieke RAG doorstuurt.
Heb ik een speciaal framework nodig voor agentic RAG?
Niet per se, maar het maakt de implementatie makkelijker. LangGraph met expliciete toestand en checkpointing is vandaag de dominante keuze voor productiesystemen — het ondersteunt checkpointing, retry-logica en HITL-gates. LlamaIndex heeft ingebouwde agentic RAG met query rewriting en multi-step retrieval. Voor eenvoudigere gevallen volstaat eigen code met een ReAct-lus.
Wat is de latency van agentic RAG in productie?
De reële latency van een agentic RAG-pipeline met 3–5 retrievalstappen bedraagt 5–20 seconden. Klassieke RAG antwoordt doorgaans binnen 1–3 seconden. Voor interactieve toepassingen zijn asynchrone verwerking en streaming van uitvoer noodzakelijk — de gebruiker moet zien dat het systeem werkt, anders ervaart hij het als een falen.
Wanneer kies je liever voor GraphRAG dan voor agentic RAG?
GraphRAG is geschikter wanneer relaties tussen entiteiten belangrijk zijn en documenten een netwerk van verbonden feiten vormen (bijv. regulatoire verbindingen, organisatiehiërarchieën). Agentic RAG is geschikter wanneer de knowledge base documentgericht is en het probleem meerstapsvragen zijn, geen grafrelaties.
*Als u overweegt of uw knowledge base-use-case agentic RAG vereist of dat een geoptimaliseerde klassieke aanpak volstaat, beoordelen we graag de concrete situatie — inclusief een raming van kosten, latency en architectuurontwerp. MP Industrial Solutions implementeert RAG en agentic systemen voor B2B-omgevingen met de nadruk op meetbaar resultaat.*