Standaard-RAG zou een tool moeten zijn, niet de architectuur

Query-ambiguïteit heeft mijn kijk op retrieval veranderd

Ik begon met een vrij simpele vraag: wat gebeurt er wanneer de query van een gebruiker ambigu is?

Dat is geen theoretisch randgeval. AmbigQA liet zien dat meer dan de helft van de vragen in NQ-open ambigu was, onder andere door verwijzingen naar entiteiten en gebeurtenissen.[1] Later onderzoek naar clarification-based QA maakte van ambiguïteitsdetectie en het genereren van verduidelijkingsvragen expliciete stappen vóór het beantwoorden.[2]

Daardoor ben ik opnieuw gaan kijken naar wat we meestal “standaard-RAG” noemen.

Een typische pipeline ziet er ongeveer zo uit:

query → embedding → vector search → top-k chunks → LLM → antwoord

Het probleem is niet alleen de chunkgrootte. De diepere aanname is dat de oorspronkelijke gebruikersquery al de juiste retrieval-query is.

Die aanname breekt vaak.

Een gebruiker kan vaag zijn. Een vraag kan meerdere interpretaties hebben. Een vraag kan twee feiten vereisen die niet met dezelfde zoekterm gevonden worden. Het eerste gevonden document kan een term, entiteit, datum, uitzondering of relatie onthullen die de volgende zoekactie volledig verandert. In zulke situaties is retrieval geen losse handeling maar een proces.

Daarom vind ik agentic retrieval uiteindelijk een bruikbaardere architectuur.

flowchart TD
    A["Gebruikersquery"] --> B["Interpreteren / ambiguïteit detecteren"]
    B --> C["Opsplitsen of herschrijven"]
    C --> D["Retrieval"]
    D --> E["Bewijs inspecteren"]
    E --> F{"Onvoldoende / tegenstrijdig / incompleet?"}
    F -->|Ja| G["Query aanpassen"]
    G --> D
    F -->|Nee| H["Selecteren / reranken / verifiëren"]
    H --> I["Antwoord"]

Het kernverschil is eenvoudig: standaard-RAG behandelt de query als input; agentic RAG behandelt retrieval als een traject.

Het onderzoek beweegt al duidelijk in deze richting

IRCoT is een van de duidelijkste voorbeelden. De auteurs stellen dat one-step retrieve-and-read onvoldoende is voor multi-step vragen, omdat wat je daarna moet ophalen afhankelijk is van wat je uit eerder bewijs hebt afgeleid.[3] Op HotpotQA, 2WikiMultihopQA, MuSiQue en IIRC rapporteerde IRCoT verbeteringen tot 21 punten in retrieval en tot 15 punten in downstream QA door retrieval en reasoning af te wisselen.[3]

FLARE komt vanuit een andere richting tot een vergelijkbaar inzicht. In plaats van één keer aan het begin te retrieven, bepaalt het systeem tijdens het genereren actief wanneer extra informatie nodig is en maakt het nieuwe retrieval-queries op basis van verwachte volgende inhoud.[4] Op vier long-form knowledge-intensive generation-taken behaalde FLARE superieure of competitieve resultaten ten opzichte van de gebruikte baselines.[4]

Adaptive-RAG maakt het architectuurpunt nog explicieter: niet elke query verdient dezelfde retrievalstrategie.[5] Het systeem kiest dynamisch tussen geen retrieval, single-step retrieval en iterative retrieval op basis van de complexiteit van de vraag, waarbij de auteurs een betere balans tussen accuracy en efficiency rapporteren dan relevante baselines.[5]

SELF-RAG pakt nog een probleem van fixed RAG aan: blind een vast aantal passages ophalen, ongeacht of retrieval nodig is of de passages relevant zijn, kan de kwaliteit van de output verminderen.[6] Daarom laat SELF-RAG het model selectiever retrieven en het bewijs kritisch beoordelen.[6]

De rode draad is dus duidelijk: retrieval moet zich kunnen aanpassen aan de query én aan wat het systeem tijdens het oplossen leert.

Een vergelijking uit 2026 maakt de trade-off heel concreet

Het NeMo Retriever-team van NVIDIA publiceerde een agentic retrieval-pipeline voor de ViDoRe v3 Pipeline benchmark.[7] De agent kan complexe queries herschrijven, meerdere retrieval-calls doen, subvragen oplossen en uiteindelijk de beste documenten selecteren.[7]

NVIDIA rapporteert voor de agentic pipeline 69.2 nDCG@10, tegenover 64.4 voor de eenvoudige dense pipeline — ongeveer 7,4% relatieve winst.[7] Daar staat tegenover dat de search latency stijgt van 3,61 seconden naar 136 seconden, omdat de agent queries mag herschrijven en meerdere keren mag retrieven.[7]

Veel mensen stoppen hier en concluderen: “Agentic retrieval is te traag.”

Ik vind dat te kort door de bocht.

Latency is echt, maar latency is ook een productdesignprobleem

Streaming verandert 136 seconden compute natuurlijk niet in 3,6 seconden. De totale rekentijd blijft bestaan.

Maar voor een gebruiker zijn deze twee ervaringen niet hetzelfde:

136 seconden stilte

tegenover

Vraag analyseren…
Primaire corpus doorzoeken…
8 kandidaatbronnen gevonden…
Tegenstrijdig bewijs controleren…
Query herschrijven…
Opnieuw zoeken…
Finale bronnen verifiëren…
Antwoord genereren…

Door partial output, tool calls, retrieval-progress, gevonden bronnen en verificatiestappen te streamen, verandert een zwarte doos in een zichtbaar proces. Dat verlaagt de ervaren latency, ook wanneer de fysieke runtime hetzelfde blijft.

Belangrijker: een agentic systeem hoeft het dure pad niet voor iedere vraag te gebruiken. Dat is precies de les die ik uit Adaptive-RAG haal.[5]

Een goede productiearchitectuur kan bijvoorbeeld zo routeren:

eenvoudige / expliciete query
    → one-shot retrieval

ambigue query
    → verduidelijken of meerdere interpretaties maken

multi-hop query
    → iterative retrieval

zwak bewijs
    → query herschrijven + opnieuw retrieven

tegenstrijdig bewijs
    → retrieven + vergelijken + verifiëren

Het antwoord op latency is dus niet “terug naar standaard-RAG.” Het antwoord is budgeted agentic retrieval.

Agentic systemen kunnen ook falen

Er is ook nuttig negatief bewijs.

Een reproduceerbare open-source benchmark op HotpotQA vergeleek meerdere RAG-patronen met dezelfde dataset, embeddings, chunking, vector store en hetzelfde 8B Llama-model.[8] In die setup haalde Basic RAG een Recall@5 van 0.609, terwijl de ReAct-achtige Agentic RAG 0.498 haalde en ongeveer twee keer zoveel mediane latency had.[8]

Voor mij bewijst dit niet dat agentic retrieval nutteloos is. Het laat zien dat agency de kwaliteit van je reasoning- en control-loop versterkt — in positieve én negatieve zin.

Als een kleiner model slechte zoekbeslissingen neemt, queries verkeerd herschrijft of op het verkeerde moment stopt, stapelen fouten zich op. Een slechte agent kan absoluut slechter zijn dan een goede retriever.

Dat is een engineeringconstraint, geen argument om retrieval permanent tot één poging te beperken.

Een IEEE-paper uit 2026 over Agentic Self-RAG laat de andere kant zien. Die architectuur splitst query-analyse, retrievalkritiek en antwoordverificatie op in gespecialiseerde controlestappen.[9] Het paper rapporteert 54,3% exact match tegenover 45,2% voor Vanilla RAG op HotpotQA, en 68,5% tegenover 59,2% accuracy op StrategyQA.[9]

De interessante vraag is daarom niet:

“Verslaat agentic RAG standaard-RAG altijd?”

Natuurlijk niet.

De nuttige vraag is:

“Welke architectuur kan zich aanpassen wanneer de eerste retrieval-poging niet genoeg is?”

Daar heeft one-shot RAG een structurele beperking.

Cursor is voor mij een belangrijk production signal

Bij coding agents wordt dit heel zichtbaar.

Cursor documenteert dat gewijzigde bestanden in syntactische chunks worden opgesplitst en naar embeddings worden omgezet voor semantic search.[10] Cursor beschrijft daarnaast een agentic search-setup waarin agents semantic search kunnen combineren met exacte zoektools zoals grep.[11]

In Cursor’s eigen evaluatie verbeterde semantic search de accuracy van agent-antwoorden gemiddeld met 12,5%, met verschillen per model.[11] Cursor noemt semantic search een van de belangrijkste drivers van agent performance.[10]

Dit is geen gecontroleerd wetenschappelijk experiment dat bewijst dat iedere agentic RAG-architectuur beter is dan iedere standaard-RAG. Het is wel productie-evidence voor een praktisch punt: sterke agents profiteren ervan wanneer ze zelf kunnen bepalen hoe ze zoeken, waarnaar ze zoeken en welke retrievaltool ze gebruiken.

Als adaptieve retrieval fundamenteel zinloos zou zijn, is het lastig te verklaren waarom serieuze coding-agentproducten zoveel engineering investeren in indexing, semantic retrieval, exact search, querykeuze en herhaald toolgebruik.

Mijn conclusie

Ik denk niet dat standaard-RAG moet verdwijnen.

Ik denk dat het van architectuur naar tool moet worden gedegradeerd.

Dense top-k retrieval is nuttig. BM25 is nuttig. Hybrid retrieval is nuttig. Rerankers zijn nuttig. Zoeken in vaste chunks is nuttig.

Maar geen van die technieken zou vooraf moeten bepalen dat iedere gebruikersvraag exact één retrieval-pass verdient.

De sterkere architectuur is een agent die kan bepalen:

• of retrieval nodig is;
• of de query ambigu is;
• of de query herschreven moet worden;
• of de vraag opgesplitst moet worden;
• welke retriever of zoektool geschikt is;
• of het bewijs voldoende is;
• of een volgende retrieval-pass gerechtvaardigd is;
• en wanneer het systeem moet stoppen.

Voor simpele vragen kan die agent exact hetzelfde snelle pad kiezen dat we vandaag standaard-RAG noemen.

Voor moeilijke vragen kan hij iets doen wat standaard-RAG structureel niet kan: zich aanpassen.

Daarom ben ik, nadat ik begon met het probleem van query-ambiguïteit, veel sterker overtuigd geraakt van agentic retrieval.

De architectuur waarop ik zou inzetten is niet “agentic RAG in plaats van retrieval.” Het is agentic orchestration met retrieval als first-class tool — en standaard-RAG als fast path daarbinnen.

Referenties

1. Min, S. et al. (2020). AmbigQA: Answering Ambiguous Open-domain Questions. EMNLP. Bron
2. Lee, D. et al. (2023). Asking Clarification Questions to Handle Ambiguity in Open-Domain QA. Findings of EMNLP. Bron
3. Trivedi, H. et al. (2023). Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions. ACL. Bron
4. Jiang, Z. et al. (2023). Active Retrieval Augmented Generation. EMNLP. Bron
5. Jeong, S. et al. (2024). Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity. NAACL. Bron
6. Asai, A. et al. (2024). SELF-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR. Bron
7. NVIDIA NeMo Retriever Team (2026). NeMo Retriever’s Agentic Retrieval Pipeline — ViDoRe V3 Pipeline benchmark. Bron
8. Pradhan, S. (2026). RAG Architecture Benchmark — HotpotQA. Open-source reproduceerbare benchmark; niet peer-reviewed. Bron
9. Agentic Self-RAG: Multi-Agent Reasoning for Self-Correcting Retrieval-Augmented Generation (2026). IEEE ICIT. DOI: 10.1109/ICIT68548.2026.11577708. Bron
10. Cursor (2026). Securely indexing large codebases. Bron
11. Cursor (2025). Improving agent with semantic search. Bron