Visual document retrieval indexeert een afbeelding van elke pagina in plaats van de tekst die eruit is gehaald. Op ViDoRe V3, de ACL 2026-benchmark opgebouwd uit ongeveer 26.000 zakelijke pagina's en 3.099 door mensen geverifieerde zoekvragen, verslaan visuele retrievers de tekstpijplijnen ronduit. Het addertje voor een Nederlandse lezer staat in de beperkingenparagraaf van het artikel zelf: elk document in dat corpus is Frans of Engels, en Nederlands is geen van de zes zoektalen.
Wat ViDoRe V3 werkelijk heeft gemeten
ViDoRe V3 is gebouwd door ILLUIN Technology met bijdragen van NVIDIA, en is een bewuste reactie op hoe zacht de eerdere benchmarks waren. Tien corpora, ongeveer 26.000 pagina's, 3.099 zoekvragen en 12.000 uur handmatig annotatiewerk voor het schrijven van vragen, het rangschikken van paginarelevantie, bounding boxes en referentieantwoorden. Acht datasets zijn openbaar. Twee worden privé beheerd door het MTEB-team, een set met nucleaire regelgeving en een set met telecomstandaarden, juist zodat modellen er niet op getraind kunnen worden.
De openbare corpora bestaan uit precies het soort documenten dat in de praktijk problemen geeft: Amerikaanse en Franse jaarverslagen, HR-rapportages uit de EU, Franse overheidsrapporten over energie, FDA-rapporten, technische orders van de USAF, informaticaleerboeken en Franse natuurkundecolleges. Tekst, tabellen, grafieken, infographics en foto's, op pagina's die zijn opgemaakt door mensen die niet aan uw zoekpijplijn dachten.
Drie uitkomsten zijn van belang: visuele retrievers presteren beter dan tekstuele, late-interactiemodellen en tekstuele reranking verbeteren het resultaat allebei aanzienlijk, en een genererend model dat visuele of gemengde context krijgt geeft betere antwoorden dan met tekst alleen. Het hoogste gemiddelde op de Engelse splits is 0,656 NDCG@10, van nemo-colembed-3b. Ter vergelijking: colqwen2.5 komt op 0,592 en colpali-v1.3 op 0,530 op diezelfde splits.
Lees die topscore eerlijk. Het beste beschikbare model, op een benchmark die de auteurs eerlijk in plaats van vleiend hebben ontworpen, blijft rond tweederde steken. Dit is een richting die werkt, geen opgelost probleem.
Waarom verslaat de pagina inbedden het uitlezen van de tekst?
ColPali, gepubliceerd op ICLR 2025, is de architectuur waar de hele familie van afstamt. Een schermafbeelding van een pagina gaat een vision language model in als een raster van 32 bij 32, dus 1.024 beeldpatches, plus zes instructietokens. Elk van die 1.030 tokens wordt geprojecteerd naar een vector van 128 dimensies. Een zoekvraag wordt in dezelfde ruimte getokeniseerd, en de scoring gebruikt MaxSim, het late-interactiemechanisme dat is overgenomen van ColBERT: neem voor elk zoektoken de beste match over alle paginapatches en tel die op. Het technische verslag van Vespa over het opschalen hiervan naar miljarden pagina's is de helderste openbare beschrijving van hoe het werkt.
De reden dat het wint, is wat het overslaat. Een conventionele pijplijn moet bepalen waar de cellen van een tabel beginnen en eindigen, wat de leesvolgorde is, of de stempel in de hoek inhoud is of ruis, en hoe het resultaat in stukken wordt geknipt. Elk van die beslissingen is een kans om informatie te verliezen voordat het zoeken überhaupt begint. Een pagina-afbeelding bevat geen van die beslissingen. Daarom concentreert de winst zich precies daar waar de opmaak betekenis draagt: een werkbon met handtekeningvelden en met de hand geschreven uren, een pakbon waarvan de betekenis in een tabel zit, een keuringsrapport waarin de foto de bevinding is.
Dit is meteen de eerlijke grens met ons eerdere stuk over BM25 en vector search op documenten met tabellen. Dat stuk ging over wat er gebeurt nadat de extractie misgaat. Visuele retrieval omzeilt de extractiestap volledig, en dat is een andere en sterkere claim.
Wat gebeurt er als de zoekvraag niet in het Engels is?
Hier zit het deel dat niemand die in het Engels over ViDoRe V3 schrijft enige reden heeft om te noemen. Alle 3.099 zoekvragen zijn beschikbaar in zes talen: Engels, Frans, Spaans, Duits, Italiaans en Portugees. Nederlands zit er niet bij. De corpora zijn nog smaller. De auteurs benoemen de beperking gewoon: de benchmark beperkt zich op dit moment tot Franse en Engelse documenten, omdat er niet genoeg middelen waren voor bredere dekking.
Het artikel meet wel wat een taalwissel kost. Voor de sterkste modellen kosten vertaalde zoekvragen 3 tot 5 NDCG@10-punten ten opzichte van alleen Engels. Het hoogste meertalige gemiddelde is 0,576, van jinav4, tegenover 0,656 voor de beste Engelse score. Die twee getallen meten niet hetzelfde, en het loont om ze uit elkaar te houden: die 3 tot 5 punten zijn wat het vertalen van de zoekvraag één model kost, terwijl het bredere gat van 0,656 naar 0,576 ook de Franstalige corpora meeneemt, die op zichzelf al lastigere splits zijn.
Maar dat is niet het getal dat het plan van een mkb-bedrijf zou moeten veranderen. Dat is wat dezelfde tabel met de kleine modellen doet. ColModernVBERT zakt van 0,507 op Engels naar 0,245 meertalig. ColSmol-256M zakt van 0,464 naar 0,214. De grote modellen leveren een paar punten in. De kleine modellen leveren ongeveer de helft van hun score in. En juist die kleine modellen zijn de modellen die een bedrijf van 20 tot 50 medewerkers op eigen hardware kan draaien.
Voor een Nederlandse of Vlaamse documentverzameling hebt u dus geen getal. U hebt een aannemelijke richting, een ongemeten taal, en een gedocumenteerd patroon waarbij het betaalbare deel van het modellenaanbod het hardst inzakt zodra de taal verandert.
Bouw de enige benchmark die op u van toepassing is
De oplossing is weinig spectaculair en kost een middag.
- Neem 300 pagina's uit uw eigen archief, de echte, inclusief de scheve scans.
- Verzamel 40 tot 60 vragen bij de mensen die ze daadwerkelijk stellen. De planner, de werkvoorbereider, degene die de telefoon opneemt als een klant vraagt wat er in 2023 is vervangen.
- Laat een mens markeren welke pagina of pagina's elke vraag beantwoorden. Dit is het dure deel en er is geen weg omheen.
- Meet recall@5 en recall@10 voor twee kandidaten: uw huidige zoekfunctie en een visuele retriever. Kijk daarna de fouten stuk voor stuk na.
Eén waarschuwing, rechtstreeks uit de reden waarom ViDoRe V3 12.000 mensuren kostte: laat de vragen niet door een taalmodel uit de pagina's genereren. Synthetische zoekvragen die uit een pagina zijn afgeleid hergebruiken meestal het vocabulaire van die pagina, wat elke retriever die u test vleit en u niets vertelt. De eerdere ViDoRe-versies leunden op synthetische generatie, en de auteurs van V3 zagen het herstellen daarvan als een kernbijdrage.
Valt het resultaat goed uit, dan is een Nederlandse benchmark een gemeenschapsinspanning in plaats van een onderzoeksproject. Voor het Koreaans bestaat er al een: KoViDoRe is onafhankelijk gebouwd in dezelfde vorm en wordt inmiddels gespiegeld naar MTEB. Op het moment van schrijven bestaat er geen Nederlandse tegenhanger, en dat is een gat dat iemand in Nederland of Vlaanderen binnen een kwartaal kan dichten.
Retrieval is geen extractie
Dit onderscheid verdwijnt in vrijwel elke leverancierspresentatie, en dat is precies hoe projecten het verkeerde opleveren.
ViDoRe meet of de juiste pagina terugkomt. Een werkbon in AFAS boeken vraagt om getypeerde velden: uren, materiaalregels, een projectcode, een handtekening die wel of niet is gezet. Dat is extractie, en een visuele retriever doet dat niet. Die geeft u een pagina.
De architectuur die wel werkt is allebei, in die volgorde. Visuele retrieval knijpt duizenden pagina's terug tot de handvol die ertoe doen, waarna een vision language model of een gestructureerde extractor die paar pagina's fatsoenlijk uitleest. Vespa beschrijft het net zo, en om dezelfde reden: een frontier-model over elke pagina in het archief laten lopen voor elke vraag is geen pijplijn, dat is een rekening.
Dat betekent ook: als uw hele vraagstuk is om een factuurtotaal in de boekhouding te krijgen, is niets hiervan uw probleem. Dat is een rechtstreekse route naar factuurverwerking en een koppeling met Exact, AFAS of e-Boekhouden, en daar is geen pagina-encoder voor nodig.
Wat kost het opslaan van een index van pagina-afbeeldingen?
Opslag was het standaardbezwaar tegen deze architectuur, en dat is al een tijd geen goed bezwaar meer. Neem een ronde 100.000 pagina's, ruwweg tien jaar papierwerk voor een installatiebedrijf van 30 man, en ga uit van ColPali-achtige codering met 1.030 vectoren van 128 dimensies per pagina.
- Bij float32: 1.030 x 128 x 4 bytes is ongeveer 527 KB per pagina, dus rond de 53 GB voor het archief.
- Binair gekwantiseerd: Vespa perst elke vector van 128 dimensies in 128 bits, dus 16 bytes per patch en ongeveer 16 KB per pagina. Dat is circa 1,6 GB, een besparing van 32x.
Vespa heeft ook gemeten wat dat aan kwaliteit kost, in plaats van te beweren dat het gratis was, in technisch werk dat al in september 2024 verscheen. Op DocVQA ging nDCG@5 van 52,4 met float-vectoren naar 49,5 met binaire, en terug naar 51,6 zodra er een float-rerankingstap over de binaire kandidaten werd gelegd. Hun MaxSim op basis van Hamming-afstand liep in dezelfde test ongeveer 3,5 keer sneller dan de variant met het float-inwendig product.
Twee resultaten uit 2026 gaan verder. De Visual RAG Toolkit, een preprint uit februari 2026 die is ingediend bij de SIGIR-demonstratietrack en dus niet peer-reviewed is, past training-vrije ruimtelijke pooling toe om het aantal opgeslagen vectoren per pagina terug te brengen van duizenden naar tientallen voor de kandidaatselectie, en rerankt daarna exact met de volledige multi-vector-embeddings. Het rapporteert ongeveer 4x meer doorvoer terwijl NDCG en recall op 5 en 10 grotendeels behouden blijven op ViDoRe V2. NeoMME, eind augustus 2026 uitgebracht onder Apache 2.0, rapporteert dat hiërarchische token-pooling en asymmetrische kwantisatie de eigen late-interactie-embeddings met een factor 255 comprimeren terwijl ruim 95 procent van de basis-nDCG@10 behouden blijft, met een retriever van 260M parameters die 0,523 scoort op ViDoRe V3.
Wat overblijft aan kosten is niet de index. Het is de GPU aan de invoerkant, want elke pagina moet één keer worden gecodeerd.
Moet een Nederlands mkb-bedrijf zijn documentpijplijn dan omgooien?
Doe het als alle drie kloppen: uw brondocumenten zijn scans of pdf's waarin de opmaak betekenis draagt, de vragen die mensen stellen zijn extractief of numeriek in plaats van open, en u hebt ergens een plek om een pagina-encoder te draaien. De tabel met vraagtypen in ViDoRe V3 is hier de moeite waard. Extractieve vragen scoren 0,668 en numerieke 0,633, terwijl open vragen op 0,438 uitkomen en multi-hop op 0,515. De meeste vragen die een mkb-bedrijf aan het eigen archief stelt zijn extractief. Dat is de helft van de verdeling waar dit werkt.
Wacht als uw bron al gestructureerd is. Komt de factuur binnen als Peppol-document of kunt u de gegevens uit het ERP exporteren, dan staat u op het punt een probleem op te lossen dat u niet hebt. Wacht ook als u een synthese over vijftig documenten nodig hebt, want dat is de kolom van 0,438.
En meet het in elk geval eerst in het Nederlands voordat u zich vastlegt. Dat is geen voorzichtigheid om de voorzichtigheid. Het is de enige variabele die de gepubliceerde benchmark niet dekt, en het is de variabele waarin uw gebruikers leven. We schreven apart over wat u in een pilot meet en over wat dit soort werk kost om te bouwen; kort gezegd is de evaluatieset het goedkoopste deel van het project en het enige deel dat u vertelt of u door moet gaan.
Laatst bijgewerkt op 11 september 2026. De resultaten van ViDoRe V3 komen uit de gepubliceerde benchmark en het MTEB-leaderboard; de ColPali-code staat op illuin-tech/colpali.
