Als je klantdata, productdocumentatie of visueel rijke documenten moet doorzoeken, herken je het probleem: zoekresultaten zijn technisch relevant, maar missen vaak het denkwerk dat complexe vragen nodig hebben. NVIDIA NeMo Retriever ontwikkelde een agentische zoekpipeline die precies dát gat adresseert — niet door pure magie, maar door een herhaald, doelgericht samenspel tussen een taalagent en een retriever. In dit artikel leg ik uit wat dat oplevert, wanneer het wél zin heeft en hoe je er zelf mee aan de slag kunt.
Waarom semantische gelijkenis niet genoeg is
Lang leek dense retrieval — documenten zoeken op semantische gelijkenis — de logische oplossing. Maar in de praktijk missen zulke systemen twee dingen tegelijk. Ze kunnen heel veel documenten doorzoeken, maar hebben beperkt inzicht in complex redeneren. LLM’s kunnen juist goed nadenken, maar niet honderdduizenden documenten tegelijk verwerken. Het gevolg: bij meerstappige, visueel rijke of logisch veeleisende vragen levert pure semantiek vaak foute of incomplete antwoorden. Agentic retrieval probeert die kloof te dichten door een actieve, iteratieve samenwerking tussen een denkende agent en een snelle retriever.
De agentische loop: hoe het werkt in de praktijk
De pipeline gebruikt een ReACT-achtige architectuur: de agent stelt niet één vraag en stopt, maar doorloopt herhaalde stappen van plannen, ophalen en evalueren. Praktisch gezien heeft de agent een set gereedschappen: een think-tool om de aanpak te plannen, een retrieve(query, top_k)-tool om het corpus te doorzoeken en een final_results-tool om de beste documenten terug te geven. Uit die loop komen nuttige gedragingen naar voren: de agent verbetert zoekvragen op basis van nieuwe informatie, blijft herschrijven totdat er bruikbare passages verschijnen en splitst moeilijke queries op in kleinere, concrete zoektaken. Als de agent tegen limieten aanloopt (maximale stappen of contextlengte), valt de pipeline terug op Reciprocal Rank Fusion (RRF) om documenten te combineren op basis van rang over meerdere pogingen.
Engineering voor snelheid en betrouwbaarheid — de praktische aanpassing
Agentische workflows zijn van zichzelf traag en foutgevoeliger omdat ze veel componenten en calls hebben. Het oorspronkelijke ontwerp van NVIDIA koppelde de agent aan de retriever via een externe Model Context Protocol (MCP) server. Dat werkte, maar zorgde voor veel extra latency, complex beheer (separate servers per run) en een hoger risico op misconfiguraties. De simpele, maar effectieve verbetering: de retriever als thread-safe singleton in hetzelfde proces. Die singleton laadt embeddings en model één keer in GPU-geheugen, beschermt toegang met een reentrant lock en biedt een retrieve()-interface voor gelijktijdige agent-taken. Resultaat: minder netwerkoverhead, minder deployment fouten en een hogere experimentthroughput — precies de soorten praktische problemen waar je als ondernemer geen tijd aan wilt verliezen.
Generaliseerbaarheid versus specialisatie: wat de benchmarks zeggen
Een belangrijke vraag is: werkt deze aanpak alleen op één dataset, of is het breed toepasbaar? NVIDIA testte hetzelfde agentic-ontwerp op twee heel verschillende leaderboards. Op ViDoRe v3 (veel visueel rijke enterprise-documenten) behaalde de agentische pipeline de nummer 1-positie met een NDCG@10 van 69,22. Ter vergelijking: pure dense retrieval met hetzelfde embedding-model scoorde 64,36 en het INF‑X-pipeline‑ontwerp bleef op 62,31 hangen. Op BRIGHT (meer redeneerwerk) leverde de agentische aanpak een tweede plaats met een NDCG@10 van 50,90; de nummer 1-oplossing (INF‑X‑Retriever) scoorde 63,40. Die verschillen vertellen iets praktisch belangrijks: oplossingen die sterk geoptimaliseerd zijn voor één taak, presteren vaak minder goed op een andere. De agentic pipeline daarentegen past zijn zoek- en redeneerstrategie aan het type taak aan, zonder architectuurwissel — en dat is precies wat je wil als je met echte, gemengde data werkt.
Ablatie: gesloten frontmodellen versus open modellen
Om te begrijpen waar winst vandaan komt, keek het team naar combinaties van agentmodel en embedding-model. Belangrijke bevindingen: • Modelkeuze: op ViDoRe daalde NDCG@10 iets van 69,22 (Opus 4.5) naar 66,38 bij de open gpt‑oss‑120b, terwijl het aantal retrieve-calls sterk afnam. Op BRIGHT was het verschil veel groter — redeneerintensievere taken bleken nog steeds te profiteren van krachtigere, gesloten modellen zoals Opus. • Embeddings: gespecialiseerde embeddings (bijvoorbeeld nemotron‑colembed‑vl‑8b‑v2 voor ViDoRe) gaven de hoogste resultaten; een sterke baseline-retriever verhoogt het plafond waar de agent naartoe kan sturen. • Agent sluit deels de kloof: op ViDoRe bedroeg de dense‑gap tussen de sterkere en zwakkere embeddings ongeveer 8,5 punten; gekoppeld aan gpt‑oss‑120b kromp die kloof naar ongeveer 4 punten. Op BRIGHT liet een top embedding ongeveer 19 punten voorsprong zien ten opzichte van een zwakkere, maar met een open agent slinkt dat verschil tot circa 7,5. Praktische les: je krijgt sneller waarde door slimme agentlogica te combineren met goede embeddings, maar bij zware redeneertaken blijft een sterker agentmodel relevant.
De kosten van autonomie — wanneer wel en niet inzetten
Agentic retrieval heeft een prijs. In de ViDoRe‑metingen ligt de gemiddelde latency rond 136 seconden per query en verbruikt elke zoekopdracht naar schatting ~760.000 input tokens en ~6.300 output tokens. Die cijfers zijn gemeten op een enkele A100 GPU en reflecteren echte, sequentiële zoektijd — geen parallelle batchscenario’s. Conclusie: voor massale, eenvoudige zoekvragen blijft dense retrieval de juiste keuze. Voor complexe, hoog‑risico of specialistische zoekvragen — klantenservice dossiers, juridische due diligence, technisch support met visuele documenten — kan agentic retrieval de extra tijd en kosten rechtvaardigen omdat het betere, gerichtere resultaten oplevert.
Wat nu: kosten omlaag en praktische adoptie
Het team werkt aan twee praktische wegen om de kosten te verlagen. Ten eerste: distillatie — kleinere, open‑gewichten modellen trainen om de think‑en‑retrieve‑patronen na te bootsen, zodat je Opus‑achtige nauwkeurigheid kunt benaderen met veel lagere latency en kosten. Ten tweede: modulariteit in productie — koppel je agent aan een commercieel en goed supporteerd embeddingmodel (bijvoorbeeld llama‑nemotron‑embed‑vl‑1b‑v2) en implementeer de singleton‑retriever architectuur om deployment risico’s en latency te beperken. Beide stappen zijn bedoeld om agentic retrieval bedrijfspraktisch te maken, niet alleen interessant in een leaderboardcontext.
Zelf beginnen: praktische aanbevelingen
Als je dit wilt uitproberen voor je bedrijf, begin klein en meet op relevante KPI’s. Mijn aanbeveling: • Start met een duidelijke set complexe queries uit je eigen data: klantenondersteuning, technische handleidingen of sales‑documentatie. • Gebruik de NeMo Retriever‑bibliotheek als basis; de architectuur is modulair, zodat je makkelijk verschillende agentmodellen en embeddings kunt testen. • Voor productie: koppel een betrouwbare embedding (llama‑nemotron‑embed‑vl‑1b‑v2) aan een kleinere agent tijdens de proefperiode. Als resultaten substantieel beter zijn bij overleg‑ of risicovolle taken, schakel je gefaseerd op naar krachtigere agenten. Dit houdt kosten voorspelbaar en beperkt risico. • Meet latency en token‑verbruik per query en weeg die tegen het extra businessresultaat: minder handmatige interventies, hogere eerstelijns‑resolutie of snellere doorlooptijd in due diligence.
Kort samengevat — wanneer het voor jou werkt
De kern: agentic retrieval is geen universele vervanging van bestaande zoeksystemen. Het is een gericht instrument voor complexe vragen waar redeneren en iteratief zoeken echt iets toevoegen. NVIDIA’s werk laat zien dat zo’n aanpak breed inzetbaar is en in veel gevallen beter generaliseert dan sterk gespecialiseerde pipelines. Mijn advies als iemand die met ondernemers en marketeers werkt: test het op één waardevolle use‑case, meet harde verbeteringen en schaal pas op basis van resultaat en kosten. Dan blijft het een investering, geen gok.