In documenten die tekst en tabellen mengen — facturen, orderbevestigingen, jaarrekeningen, werkbonnen — mislukt de zoekstap veel vaker dan teams aannemen, en 73% van die fouten komt door de tabelstructuur, niet door woordkeuze. Een benchmark uit 2026 over 23.088 vragen liet zien dat gewone BM25-trefwoordzoekactie een state-of-the-art embeddingmodel op bijna elke maatstaf verslaat. De oplossing is goedkoper dan de stack die de meeste teams inkopen.
Waarom mist een embedding de regel waar u om vroeg?
Een embeddingmodel comprimeert een passage tot één vector die de algehele betekenis weergeeft. Dat werkt zolang een passage over één ding gaat. Een tabel gaat niet over één ding. Een prijslijst van veertig regels, een factuurregeltabel, een grootboekuitdraai — elke regel is een apart feit, en het middelen daarvan levert een vector op die nergens nuttig in de embeddingruimte terechtkomt.
Het tweede probleem zijn identifiers. Vraag “wat was het nettoresultaat in 2019?” aan een document waarin “nettoresultaat” een rijlabel is en “2019” een kolomkop, en de twee tokens die het antwoord bepalen staan nergens naast elkaar in de geserialiseerde tekst. Vraag naar factuur 2026-04412 en u zoekt naar een vrijwel willekeurige tekenreeks. Semantische gelijkenis heeft daar niets aan; lexicaal zoeken behandelt een zeldzaam token juist als een sterk onderscheidend signaal. Daar is inverse document frequency voor gemaakt.
Dat inzicht is niet nieuw. Wat in 2026 veranderde, is dat iemand het fatsoenlijk heeft gemeten.
Wat heeft de benchmark van 2026 precies gemeten?
Een team van de Technische Hochschule Ingolstadt, Uludağ University en Radiate vergeleek tien zoekstrategieën op T²-RAGBench: 23.088 vragen over 7.318 documenten met gemengde tekst- en tabelinhoud. De documenten tellen gemiddeld 920 tokens en zijn als geheel geïndexeerd, zonder chunking, om het effect van de zoekmethode los te trekken van chunkingkeuzes. Elk aangrenzend verschil is significant bij p<0,001, met een gepaarde bootstraptest van 10.000 herhalingen en Bonferroni-correctie.
Recall@5 — het aandeel vragen waarbij het juiste document in de top vijf staat:
- BM25 (lexicaal): 0,644
- Dense retrieval, text-embedding-3-large: 0,587
- HyDE (hypothetisch document door een LLM): 0,544
- Multi-query-expansie met RRF: 0,640
- Hybride BM25 + dense, reciprocal rank fusion: 0,695
- Contextueel hybride (LLM-samenvatting vooraan bij indexeren): 0,717
- Hybride + cross-encoder reranking: 0,816
BM25 versloeg een van de sterkste commerciële embeddingmodellen op elke maatstaf behalve Recall@20, waar de twee met 0,797 tegen 0,798 gelijk eindigen. Lees dat rustig terug: op deze documentsoort presteerde het gratis onderdeel dat al in uw database zit beter dan het betaalde onderdeel dat u over het netwerk aanroept.
De auteurs zijn eerlijk over de reikwijdte, en wie hen citeert hoort dat ook te zijn. Het is één corpus, financieel van aard, met numerieke antwoorden, één embeddingmodel en zoeken op documentniveau. Wat generaliseert is het mechanisme, niet de decimalen.
Waar breekt het zoeken werkelijk?
De nuttigste tabel in het artikel is de foutenanalyse. Van de 7.188 vragen (31,1%) waarbij hybride zoeken het juiste document niet in de top vijf kreeg, hebben de auteurs er honderd bemonsterd en de fouten ingedeeld:
- Tabelstructuur sluit niet aan — 73%
- Rekenstap vereist — 20%
- Woordkeuze sluit niet aan — 5%
- Onduidelijke vraag — 1%
- Document te lang — 1%
Bij 71% van de fouten stond het juiste document noch in de dense-top-vijf, noch in de BM25-top-vijf. Het zijn dus echt moeilijke gevallen en geen bijverschijnsel van de manier waarop de twee ranglijsten zijn samengevoegd.
Die verdeling hoort uw backlog te herschikken. Overstappen op een beter embeddingmodel pakt de 5% aan. Veranderen hoe tabellen de index in gaan pakt de 73% aan. De meeste teams die wij spreken hebben hun laatste drie sprints aan die 5% besteed.
Waarom maakte het herschrijven van vragen het slechter?
HyDE — een LLM een hypothetisch antwoord laten schrijven en dát embedden in plaats van de vraag — scoorde 0,544, onder de 0,587 van gewone dense retrieval. De reden is specifiek en de moeite waard om te onthouden: zodra de vraag om een exact getal draait, verzint het model een plausibel getal, en het hypothetische document trekt de vraagvector richting een waarde die nergens in het corpus voorkomt. Query-expansie helpt wanneer het probleem formulering is. Het schaadt wanneer het probleem precisie is.
Multi-query-expansie kwam uit op 0,640, praktisch niet te onderscheiden van niets doen naast de 0,644 van BM25. Corrective RAG haalde 0,658 — beter dan beide losse zoekmethoden, slechter dan eenvoudige fusie op 0,695 — en veelzeggend: bij 63% van de vragen (14.569 van 23.088) sloeg het correctiepad aan. Een zoekmethode die bij bijna twee van elke drie vragen gecorrigeerd moet worden, zegt iets over de zoekmethode, niet over de vragen.
De algemene les is er een die wij in agents in productie steeds opnieuw tegenkomen: een agentische lus om een zwakke zoeklaag heen geeft meer geld uit om uitgebreider fout te zitten.
Wat repareert u als eerste?
Een volgorde van werken, goedkoopst en meest opleverend eerst:
- Parseer tabellen naar doorzoekbare eenheden. Chunks op regel- of recordniveau, waarbij de kolomkoppen en de documentkop in elke regel worden meegenomen, zodat één chunk zichzelf verklaart. Dit is ondankbaar engineeringwerk en het pakt precies de dominante faalvorm aan.
- Zet een lexicale index naast de vectorindex en voeg de ranglijsten samen. Reciprocal rank fusion met k=60 is de gangbare standaard, maar de ablatie in het artikel bracht convexe combinatie met α=0,5 op 0,726 en RRF met k=10 op 0,716, tegen 0,695 voor de standaard. Dat is een configuratiewijziging van een middag.
- Rerank — over een voldoende diepe kandidatenpoule. Hier zit de grootste enkele winst, en hier laten de meeste implementaties die stilletjes liggen. Reranken van 20 kandidaten scoorde 0,458. Vijftig kandidaten scoorden 0,826. Honderd scoorden 0,888. (De hoofdtabel meldt 0,816 voor wat in feite dezelfde tweetrapspijplijn is die de ablatie op 0,826 zet; beschouw dat verschil als meetruis, niet als tuningwinst.) Wie zijn top tien rerankt, betaalt een cross-encoder om documenten te herordenen die het antwoord grotendeels niet bevatten.
- Verrijk tijdens het indexeren. Een korte, door een LLM geschreven contextsamenvatting vooraan elk document — bedrijf, periode, kerncijfers — leverde 2,8 punten op bij dense en 2,2 bij hybride zoeken, tegen eenmalige indexeerkosten.
- Pas daarna grijpt u naar een groter model.
Is een beter model goedkoper dan beter zoeken?
De benchmark beantwoordt dat rechtstreeks, en het antwoord is ongemakkelijk voor iedereen wiens verbeterplan uit een modelupgrade bestaat.
Bij gelijkblijvende hybride zoekstap leverde het vervangen van GPT-4.1-mini door GPT-5.4 een antwoordnauwkeurigheid op van 0,346 tegen 0,282: een winst van 6,4 punten. Bij het gelijkblijvende kleine model leverde het vervangen van hybride zoeken door orakelzoeken — het juiste document elke keer aangereikt — 0,350 tegen 0,282 op: een winst van 6,8 punten. Het repareren van de zoekstap was net iets meer waard dan een upgrade naar een frontier-model, en de twee stapelen: het grote model op orakelcontext haalde 0,403.
Zoekkwaliteit en antwoordkwaliteit correleerden met r = 0,98 over de zoekconfiguraties die zij end-to-end vergeleken. Er bestaat geen prompt die een document terughaalt dat het model nooit heeft gekregen, en geen contextvenster dat groot genoeg is om te vervangen dat u weet welk document erin moet.
Eén eerlijk voorbehoud: orakelzoeken is een bovengrens en geen aankoop. De beste configuratie die de studie werkelijk haalde — hybride fusie plus reranking — kwam uit op 0,816 Recall@5, niet op 1,0. De vergelijking vertelt u waar de marginale euro heen moet, niet dat perfect zoeken op de prijslijst staat.
Geldt dit ook voor Nederlandse bedrijfsdocumenten?
Het mechanisme reist mee, ook al doet de benchmark dat niet. De verzamelingen die Nederlandse mkb-bedrijven werkelijk willen doorzoeken zitten ongewoon vol identifiers: factuurnummers, artikelnummers, ordernummers, btw-nummers, KvK-nummers, postcodes, en de veldnamen die met UBL- en Peppol-facturen meekomen. Exports uit Exact Online, AFAS en e-Boekhouden zijn eerst tabel en pas daarna tekst. Een werkbon is een kopblok plus een regeltabel. Vraag “hoeveel uur is er in juni op project 4412 geschreven?” en elk token dat het antwoord aanwijst is een zeldzame tekenreeks — de best denkbare invoer voor een lexicale index en zowat de slechtste voor een dense index.
Twee praktische gevolgen voor een bedrijf van 20 tot 50 medewerkers dat al op Postgres draait. Ten eerste is een lexicale index eerder een instelling dan een project: Postgres levert stemming-configuraties voor 28 talen, waaronder het Nederlands, en pgvector kan in dezelfde tabel wonen als een full-textindex. Wilt u echte BM25-ranking in plaats van ts_rank, dan bieden pg_textsearch en pg_search dat als extensie, en is de fusiequery één statement. Geen tweede datastore, geen synchronisatietaak, geen consistentieprobleem.
Ten tweede straft een gemengd Nederlands/Engels corpus — en dat is de meeste Nederlandse technische documentatie — één embeddingmodel harder af dan BM25, omdat lexicaal zoeken nooit twee talen in dezelfde geometrie hoeft te plaatsen.
En het structurele voorbehoud: staat het antwoord in een systeem van registratie in plaats van in een document — uren in het ERP, voorraad in het WMS, saldi in het boekhoudpakket — dan is zoeken het verkeerde mechanisme en is een tool-call op de database het juiste. Wij beschreven dat onderscheid in AI trainen op eigen data, en het blijft de meest voorkomende reden dat een documentzoekproject tegenvalt. Verwant: hoe de zoeklaag in de bredere stack past in RAG vs GraphRAG, en hoe hetzelfde probleem eruitziet bij factuurverwerking.
Hoe test u dit op uw eigen documenten?
U kunt die vraag voor uw eigen documenten in één middag beantwoorden, en dat antwoord is meer waard dan welke benchmark van een ander ook.
- Stel een gouden set samen van vijftig vragen die mensen werkelijk hebben gesteld, elk met het document of de regel erbij die het antwoord bevat. Vijftig is genoeg om een verschil van tien punten te zien; het is niet genoeg om te publiceren.
- Meet Recall@5 van uw huidige zoekmethode. Dat getal is het harde plafond op uw antwoordkwaliteit — de correlatie hierboven is geen toeval.
- Leg een lexicale index over dezelfde chunks en voeg beide ranglijsten samen met RRF. Meet opnieuw. Beweegt het getal wezenlijk, dan zat uw embeddingbudget in de verkeerde laag.
- Voeg reranking toe over minstens vijftig kandidaten en meet opnieuw. Rerank 4 van Cohere, uitgebracht in december 2025, rekent voor het model Rerank 4 Pro $0,0025 per zoekeenheid, waarbij één eenheid staat voor één vraag tegen maximaal honderd documenten. Bij 200 vragen per dag over vijftig kandidaten is dat één eenheid per vraag: in de orde van $15 per maand, bovenop een eerste zoekstap die u toch al draait. Let op wat die rekening bepaalt — het aantal kandidaten, niet het aantal vragen. Boven de honderd kandidaten kost elke vraag twee eenheden.
- Deel de resterende missers in. Clusteren ze op tabelstructuur, ga dan terug naar stap één — geen enkele ranking redt een chunk die het antwoord nooit bevatte.
Die lus is ook de eerlijke manier om het werk te begroten. Hij vertelt u of u een zoekprobleem, een parseerprobleem of een dataprobleem heeft, vóórdat iemand zich aan een budget verbindt. Wilt u eerst het bredere kostenplaatje, dan houden wij de cijfers bij op wat een AI-project kost; is de zoeklaag al het knelpunt in een agent die u bouwt, dan is dat het werk dat wij doen.
Laatst bijgewerkt op 21 augustus 2026.
