Datalab brengt OmniParseBench uit, een open benchmark voor documentparsing

Datalab heeft OmniParseBench gepubliceerd, een open benchmark voor OCR en documentparsing die volgens het bedrijf is opgebouwd rond 16.288 tests. Volgens de projectpagina op PyPI en de blogpost van Datalab beoordeelt de benchmark losse pagina’s via binaire controles, in plaats van via edit distance ten opzichte van één referentie-uitvoer. In de praktijk vraagt elke test of een bepaald element aanwezig is in de uitvoer van een aanbieder, in de juiste volgorde staat, in een specifieke tabelcel voorkomt of binnen een layoutblok van een bepaald type valt. Datalab presenteert dit als een manier om te focussen op de vraag of systemen de juiste inhoud hebben geëxtraheerd, en niet op de vraag of ze exact één voorkeursstijl van uitvoer hebben nagebootst.

Een benchmark opgebouwd als unit-tests

Het protocol dat op PyPI wordt beschreven, draait om ja-of-neebevestigingen op paginaniveau. Een test kan één of meer argumenten controleren, waarbij elk argument overeenkomt met inhoud op een bepaalde plek op een pagina. De benchmark groepeert de resultaten in drie families: tekst, tabellen en layout. De hoofdcijfer-score is het gemiddelde van die drie familiescores.

Dat ontwerp is van belang omdat oudere benchmarks volgens Datalab gaandeweg makkelijker te optimaliseren zijn geworden via aanpassingen in opmaak of benchmarkspecifieke post-processing. In de blogpost stelt het bedrijf dat veelgebruikte alternatieven naleving van verwachte uitvoerconventies sterker kunnen belonen dan de onderliggende modelkwaliteit. Die kritiekpunten zijn beweringen van Datalab en geen onafhankelijke bevindingen in de aangeleverde bronnen, maar ze maken wel duidelijk waarom het bedrijf zegt OmniParseBench te hebben gebouwd en waarom het van plan is de benchmark te gebruiken in zijn eigen rapportage over releases.

Wat de dekking betreft, vermeldt PyPI dat elke test is getagd langs meerdere dimensies. Daaronder vallen structuur-tags zoals table, math, form en multi_column; rendering-tags zoals handwriting, tiny, rotated en degraded; rol-tags zoals heading, caption, footnote, list, code, figure en header_footer; script-tags op basis van ISO 15924; en taal-tags op basis van ISO 639-3. De tags bepalen niet of een test slaagt. In plaats daarvan maken ze het mogelijk dat gebruikers de benchmark opdelen en subsets van de data scoren. Omdat één test meerdere tags kan dragen, overlappen scores op tagniveau en middelen ze niet terug naar het hoofdcijfer.

Hoe scoring en runs werken

Volgens de beschrijving op PyPI kan de benchmark worden uitgevoerd op de dataset van Datalab die op Hugging Face wordt gehost, of op een eigen dataset van de gebruiker. Daarnaast stelt het project ook onderliggende scoring- en predictieprimitieven beschikbaar, zodat teams die in hun eigen evaluatiepijplijnen kunnen inpluggen. Een run kan worden hervat, en elke providerinstelling wordt als een afzonderlijke run behandeld. Volgens het project schrijft elke run een bestand scores.jsonl weg met één regel per test, terwijl samenvattende resultaten uit summary.json kunnen worden gelezen.

Scoring reduceert niet elke uitkomst tot geslaagd of mislukt. PyPI noemt vier oordelen:

• pass
• fail
• unsupported, wanneer een provider de gevraagde uitvoer niet kan produceren
• error, wanneer de beoordeling zelf op een probleem stuit in plaats van dat de provider faalt

Een opvallende methodologische keuze is dat de oordelen unsupported en error van elke score worden uitgesloten in plaats van als mislukking te tellen. Volgens PyPI is dat bedoeld om leveranciers niet te bestraffen voor uitvoer die zij niet kunnen produceren of voor fouten in de scorer. Tegelijk betekent dit dat vergelijkingen tussen systemen gedeeltelijk kunnen afhangen van welke uitvoertypen een provider ondersteunt. Een systeem dat een bepaalde representatie niet kan genereren, kan die tests buiten zijn score laten vallen in plaats van er nullen voor te krijgen.

Het project zegt ook dat provideradapters per aanroep dezelfde timeout gebruiken en standaard de meest nauwkeurige instellingen van elke provider nemen. De tooling van Datalab kan API’s van leveranciers aanroepen, maar vraagt vooraf om bevestiging omdat die aanroepen geld kosten. Het pakket vereist Python 3.11 of nieuwer en wordt voor de code verspreid onder Apache 2.0, terwijl data en tests gemengde licenties hebben afhankelijk van de bron.

Wat openbaar is, en wat niet

Op basis van de aangeleverde bronnen omvat de publieke release duidelijk code, documentatie en een verpakte benchmark op PyPI. PyPI vermeldt ook dat de repository een manier bevat om de benchmark te draaien met de dataset van Datalab op Hugging Face of met eigen data van een gebruiker. Diezelfde pagina verwijst gebruikers naar documentatie over de API, het benchmarkontwerp, de constructie van tests, providers en tagging. Er staat ook dat gebruikers een issue kunnen openen als zij een foutieve test vinden, wat erop wijst dat de benchmark bedoeld is om inspecteerbaar en aanpasbaar te zijn.

De beschikbare bronnen geven echter geen volledig overzicht van de 16.288 tests uitgesplitst naar familie, taal, schrift of documenttype. Ze bevatten ook geen geaggregeerde leaderboardresultaten voor OmniParseBench zelf. Het getal van 16.288 tests wordt hier daarom weergegeven als onderdeel van de positionering van de benchmark, maar de aangeleverde teksten lichten de exacte verdeling achter dat totaal niet toe. Evenmin staan er in het bronmateriaal benchmarkbrede prestatiecijfers waaruit blijkt welke providers vooroplopen op tekst, tabellen of layout.

Geclaimde resultaten rond andere benchmarks

In plaats van leaderboardresultaten van OmniParseBench te publiceren in het aangeleverde materiaal, richt de blog van Datalab zich op de vraag waarom het bedrijf bestaande benchmarks ontoereikend vindt. Het bedrijf zegt dat olmOCR verzadigd is en noemt voorbeelden waarin post-processing de gerapporteerde scores met ongeveer één of twee punten kan veranderen. Het stelt ook dat ParseBench sterk beïnvloed kan worden door de formulering van prompts, opmaakconventies en gespecialiseerde pijplijnen, vooral voor grafieken en visual grounding. Dat zijn inhoudelijke aantijgingen van Datalab, maar ze moeten worden gelezen als de lezing van het bedrijf. In de aangeleverde bronnen ontbreekt onafhankelijke validatie.

Toch maken die beweringen duidelijk waar OmniParseBench voor probeert te optimaliseren. De ja-of-necontroles van de benchmark worden expliciet gepresenteerd als moeilijker te manipuleren dan benaderingen die op referentiematching steunen. Datalab stelt dat deze structuur duidelijkere foutsignalen zou moeten opleveren, omdat een mislukte test overeenkomt met een specifieke fout op een specifieke pagina. Dat zou het voor modelontwikkelaars en zakelijke inkopers makkelijker kunnen maken om te zien of een systeem moeite heeft met bijvoorbeeld gedraaide tekst, formulieren, handschrift of tabelstructuur, in plaats van alleen één gemengde totaalscore te zien.

Beperkingen die in de release zelf zichtbaar zijn

Het eigen ontwerp van OmniParseBench brengt ook beperkingen met zich mee. Ten eerste laten de aangeleverde bronnen geen complete uitkomsten op benchmarkniveau zien, waardoor externe lezers nog niet kunnen beoordelen of de benchmark ranglijsten oplevert die wezenlijk afwijken van oudere alternatieven. Ten tweede kan de benchmark, doordat unsupported-uitvoer buiten de scoring blijft, kwaliteit belonen binnen het ondersteunde uitvoerbereik van een provider in plaats van de breedte van ondersteunde uitvoertypen. Ten derde overlappen tagslices bewust, wat nuttig is voor diagnose maar de interpretatie van samenvattingen minder intuïtief kan maken.

Er zijn ook praktische beperkingen. Het uitvoeren van leveranciers vereist API-sleutels en betaalde aanroepen. De benchmark kan worden hervat en runs kunnen met elkaar worden vergeleken, maar de reproduceerbaarheid kan alsnog variëren met providerinstellingen omdat elke instelling als een afzonderlijke run geldt. Ten slotte erft de dataset gemengde bronlicenties, en Datalab merkt op dat ook de onderliggende datasets moeten worden geciteerd. Dat vermindert de waarde van de benchmark niet, maar het betekent wel dat invoering in productie-evaluatieworkflows juridische en operationele toetsing kan vereisen.

Voor organisaties die document-AI evalueren, is de concrete verandering dat OmniParseBench een beter inspecteerbare manier biedt om systemen pagina voor pagina te testen, met uitsplitsingen voor tabellen, layout, schriften en lastige renderomstandigheden in plaats van één ondoorzichtige score. In de praktijk kan dat teams helpen om leveranciers of interne modellen te vergelijken op de documentkenmerken die voor hen echt tellen, maar ze doen er ook goed aan te controleren welke uitvoer als unsupported is gemarkeerd, de licentievoorwaarden van de benchmark te bekijken en geen enkel hoofdcijfer te behandelen als een volledige maat voor de kwaliteit van documentbegrip.