Datalab veröffentlicht OmniParseBench, einen offenen Benchmark für Dokumentenparsing

Datalab hat OmniParseBench veröffentlicht, einen offenen Benchmark für OCR und Dokumentenparsing, der nach Angaben des Unternehmens auf 16.288 Tests ausgelegt ist. Laut der Projektseite auf PyPI und dem Blogbeitrag von Datalab bewertet der Benchmark einzelne Seiten anhand binärer Prüfungen, statt die Ausgabe über die Edit-Distanz mit einem einzigen Referenzergebnis zu vergleichen. In der Praxis fragt jeder Test ab, ob ein bestimmtes Element in der Ausgabe eines Anbieters vorhanden ist, in der richtigen Reihenfolge steht, in einer bestimmten Tabellenzelle erscheint oder sich innerhalb eines Layout-Blocks eines bestimmten Typs befindet. Datalab stellt dies als einen Ansatz dar, der darauf zielt, ob Systeme den richtigen Inhalt extrahiert haben, und nicht darauf, ob sie genau einen bevorzugten Ausgabestil getroffen haben.

Ein Benchmark als Satz von Unit-Tests

Das auf PyPI beschriebene Protokoll ist auf Ja-nein-Aussagen auf Seitenebene ausgerichtet. Ein Test kann ein oder mehrere Argumente prüfen, von denen jedes einem Inhalt an einer bestimmten Stelle auf einer Seite entspricht. Der Benchmark fasst die Ergebnisse in drei Familien zusammen: Text, Tabellen und Layout. Der zentrale Gesamtwert ist der Mittelwert dieser drei Familienwerte.

Dieses Design ist wichtig, weil ältere Benchmarks nach Darstellung von Datalab leichter über Formatierungsanpassungen oder benchmarkspezifische Nachbearbeitung optimiert werden können. In seinem Blogbeitrag argumentiert das Unternehmen, weit verbreitete Alternativen könnten die Einhaltung erwarteter Ausgabekonventionen stärker belohnen als die eigentliche Modellqualität. Diese Kritikpunkte sind Behauptungen von Datalab und keine unabhängigen Feststellungen in den vorliegenden Quellen, sie erklären jedoch, warum das Unternehmen OmniParseBench nach eigener Aussage entwickelt hat und warum es den Benchmark für die eigene Berichterstattung zu Releases verwenden will.

Zur Abdeckung erklärt PyPI, dass jeder Test über mehrere Dimensionen hinweg mit Tags versehen ist. Dazu gehören Struktur-Tags wie table, math, form und multi_column; Rendering-Tags wie handwriting, tiny, rotated und degraded; Rollen-Tags wie heading, caption, footnote, list, code, figure und header_footer; Schrift-Tags auf Basis von ISO 15924; sowie Sprach-Tags auf Basis von ISO 639-3. Diese Tags entscheiden nicht darüber, ob ein Test besteht oder nicht. Stattdessen ermöglichen sie es Nutzern, den Benchmark in Teilmengen zu zerlegen und nur Teilbereiche der Daten zu bewerten. Da ein Test mehrere Tags tragen kann, überlappen sich die tagbasierten Werte und mitteln sich nicht wieder exakt auf die zentrale Kennzahl zurück.

Wie Bewertung und Läufe funktionieren

Der Benchmark kann laut der Beschreibung auf PyPI entweder mit Datalabs auf Hugging Face gehostetem Datensatz oder mit dem eigenen Datensatz eines Nutzers ausgeführt werden. Außerdem stellt er niedrigere Bewertungs- und Vorhersagebausteine bereit, damit Teams ihn in ihre eigenen Evaluierungspipelines einbinden können. Ein Lauf lässt sich fortsetzen, und jede Anbieterkonfiguration wird als eigener Lauf behandelt. Nach Angaben des Projekts schreibt jeder Lauf eine Datei scores.jsonl mit einer Zeile pro Test, während sich zusammenfassende Ergebnisse aus summary.json auslesen lassen.

Die Bewertung reduziert nicht jedes Ergebnis auf bestanden oder nicht bestanden. PyPI nennt vier Urteile:

• pass
• fail
• unsupported, wenn ein Anbieter die angeforderte Ausgabe nicht erzeugen kann
• error, wenn bei der Bewertung selbst ein Problem auftritt, statt dass der Anbieter scheitert

Eine auffällige methodische Entscheidung besteht darin, dass die Urteile unsupported und error aus sämtlichen Punktwerten ausgeschlossen werden, statt als Fehlschläge zu zählen. Laut PyPI soll damit vermieden werden, Anbieter für Ausgaben zu bestrafen, die sie nicht erzeugen können, oder für Fehler im Auswerter. Gleichzeitig bedeutet das, dass Vergleiche zwischen Systemen teilweise davon abhängen können, welche Ausgabetypen ein Anbieter überhaupt unterstützt. Ein System, das eine bestimmte Repräsentation nicht ausgeben kann, kann diese Tests aus seinem Wert herauslassen, statt dafür Nullen zu erhalten.

Das Projekt erklärt außerdem, dass Adapter für Anbieter denselben Timeout pro Aufruf verwenden und standardmäßig die jeweils genauesten Einstellungen des Anbieters nutzen. Datalabs Werkzeuge können APIs von Anbietern aufrufen, verlangen davor jedoch eine Bestätigung, weil diese Aufrufe Kosten verursachen. Das Paket setzt Python 3.11 oder neuer voraus und wird für den Code unter Apache 2.0 verbreitet, während Daten und Tests je nach Quelle unter gemischten Lizenzen stehen.

Was öffentlich ist – und was nicht

Aus den vorliegenden Quellen geht klar hervor, dass die öffentliche Veröffentlichung Code, Dokumentation und einen als Paket bereitgestellten Benchmark auf PyPI umfasst. Auf PyPI heißt es außerdem, dass das Repository eine Möglichkeit enthält, den Benchmark entweder mit Datalabs Datensatz auf Hugging Face oder mit eigenen Daten auszuführen. Dieselbe Seite verweist Nutzer auf Dokumentation zu API, Benchmark-Design, Testkonstruktion, Anbietern und Tagging. Dort wird auch erklärt, dass Nutzer bei einem fehlerhaften Test ein Issue eröffnen können, was darauf hindeutet, dass der Benchmark überprüfbar und anpassbar sein soll.

Die verfügbaren Quellen enthalten jedoch keine vollständige Aufschlüsselung der 16.288 Tests nach Familie, Sprache, Schrift oder Dokumenttyp. Ebenso enthalten sie keine aggregierten Leaderboard-Ergebnisse für OmniParseBench selbst. Die Zahl von 16.288 Tests wird hier daher als Teil der Rahmung des Benchmarks wiedergegeben, doch die vorliegenden Texte erläutern nicht die genaue Verteilung hinter dieser Gesamtsumme. Ebenso gibt es im Quellenmaterial keine benchmarkweiten Leistungswerte, aus denen hervorginge, welche Anbieter bei Text, Tabellen oder Layout führen.

Beanspruchte Ergebnisse rund um andere Benchmarks

Statt Leaderboard-Ergebnisse für OmniParseBench in den vorliegenden Materialien zu veröffentlichen, konzentriert sich Datalabs Blog darauf, warum das Unternehmen bestehende Benchmarks für unzureichend hält. Datalab sagt, olmOCR sei gesättigt, und nennt Beispiele, bei denen Nachbearbeitung die berichteten Werte um etwa ein oder zwei Punkte verändern könne. Außerdem argumentiert das Unternehmen, ParseBench könne stark von der Formulierung von Prompts, Formatkonventionen und spezialisierten Pipelines beeinflusst werden, insbesondere bei Diagrammen und visuellem Grounding. Das sind substanzielle Vorwürfe von Datalab, sie sollten jedoch als Darstellung des Unternehmens gelesen werden. Eine unabhängige Validierung ist in den bereitgestellten Quellen nicht enthalten.

Dennoch machen diese Aussagen deutlich, worauf OmniParseBench abzielt. Die Ja-nein-Prüfungen des Benchmarks werden ausdrücklich als schwerer manipulierbar dargestellt als Ansätze, die Referenzausgaben abgleichen. Datalab argumentiert, diese Struktur solle klarere Fehlersignale liefern, weil ein nicht bestandener Test einem konkreten Fehler auf einer konkreten Seite entspreche. Das könnte es für Modellentwickler und Unternehmenskäufer leichter machen zu erkennen, ob ein System zum Beispiel mit gedrehtem Text, Formularen, Handschrift oder Tabellenstruktur Schwierigkeiten hat, statt nur einen einzigen vermischten Wert zu sehen.

Grenzen, die schon die Veröffentlichung selbst erkennen lässt

Auch das Design von OmniParseBench bringt eigene Grenzen mit sich. Erstens zeigen die vorliegenden Quellen keine vollständigen benchmarkweiten Ergebnisse, sodass Außenstehende derzeit nicht beurteilen können, ob der Benchmark tatsächlich Rankings erzeugt, die sich wesentlich von älteren Alternativen unterscheiden. Zweitens kann der Benchmark, weil nicht unterstützte Ausgaben bei der Bewertung ausgelassen werden, eher Qualität innerhalb des von einem Anbieter unterstützten Ausgabebereichs belohnen als die Breite der unterstützten Ausgabetypen. Drittens überlappen sich Tag-Teilansichten absichtlich, was für die Diagnose nützlich ist, die Interpretation von Zusammenfassungen aber weniger intuitiv machen kann.

Hinzu kommen praktische Einschränkungen. Für die Ausführung mit Anbietern werden API-Schlüssel und kostenpflichtige Aufrufe benötigt. Der Benchmark kann fortgesetzt und über Läufe hinweg verglichen werden, doch die Reproduzierbarkeit kann weiterhin von den Einstellungen der Anbieter abhängen, weil jede Einstellung als eigener Lauf gilt. Schließlich übernimmt der Datensatz gemischte Quelllizenzen, und Datalab weist darauf hin, dass auch die zugrunde liegenden Datensätze zitiert werden sollten. Das schmälert den Wert des Benchmarks nicht, bedeutet aber, dass sein Einsatz in produktiven Evaluierungsabläufen rechtliche und operative Prüfungen erfordern kann.

Für Unternehmen im deutschsprachigen Raum besteht die konkrete Veränderung darin, dass OmniParseBench eine besser überprüfbare Möglichkeit bietet, Dokumenten-KI-Systeme Seite für Seite zu testen – mit Teilansichten für Tabellen, Layout, Schriften und schwierige Rendering-Bedingungen statt nur mit einem undurchsichtigen Gesamtwert. In der Praxis könnte das Teams helfen, Anbieter oder interne Modelle anhand genau der Dokumentmerkmale zu vergleichen, die für sie tatsächlich relevant sind. Sie sollten dabei aber auch prüfen, welche Ausgaben als unsupported markiert sind, die Lizenzbedingungen des Benchmarks sorgfältig lesen und keinen einzelnen Spitzenwert als vollständiges Maß für die Qualität des Dokumentenverständnisses behandeln.