docTR vs Surya2: Beleg-OCR
Direkter Benchmark (2026)

Auf SROIE 2019 sind docTR und Surya2 die beiden stärksten Zeichenerkennungsmodelle des Benchmarks, getrennt durch 0,006 Punkte — innerhalb der Rauschgrenze für ein Korpus mit 361 Stichproben. WER erzählt dieselbe Geschichte: Surya2 0,2735, docTR 0,3199. Die Erzählung „VLMs schlagen traditionelle OCR“ übersteht diesen Vergleich bei der rohen Zeichengenauigkeit englischer Belege nicht.

Zeichengenauigkeit: Ein statistisches Unentschieden

Das Unentschieden ist bedeutsam, weil die beiden Engines architektonisch gegensätzlich sind. docTR ist eine traditionelle neuronale OCR-Pipeline in zwei Stufen: Ein Detektor lokalisiert Wörter und ein Recognizer transkribiert sie, wobei Groß-/Kleinschreibung und Layout des gedruckten Textes erhalten bleiben. Surya2 ist ein Dokument-Parsing-Vision-Language-Modell (VLM): Es liest das gesamte Dokumentbild und gibt verstandenen Text aus — in Kleinschreibung, Label/Wert-Paare zusammengeführt, Zeilen neu geordnet — was näher an dem liegt, was nachgelagerte Systeme wollen, aber weiter von exakten Zeichenübereinstimmungen entfernt ist. CER misst exakte Zeichenübereinstimmungen und ist daher leicht konservativ gegenüber Surya2; die Tatsache, dass das Unentschieden trotz dieser Asymmetrie besteht, macht es aussagekräftig.

Tabelle: summary_metrics.csv — Spalten cer und wer, Zeilen sroie_2019. Exakte Werte: docTR cer 0.19707 / wer 0.31990; Surya2 cer 0.19147 / wer 0.27352. Niedriger ist besser; beide Läufe wurden mit error_rate 0.0 abgeschlossen.

Wo sie sich unterscheiden: Feld-Extraktion ohne Anpassung dreht das Ergebnis

Vergleicht man den Rohtext der Engines mit denselben festen Regex-Mustern auf den vier SROIE-Belegfeldern (Firma, Datum, Adresse, Summe) — der traditionelle OCR- und regelbasierte Ansatz zur Schlüsselinformationsextraktion (KIE) — dreht sich das Ranking: Surya2 extrahiert Felder mit 0,3183 Feld-F1 gegenüber docTRs 0,0766, ein 4,2×-Vorteil. docTR hat die beste Zeichengenauigkeit der Klasse und die schlechteste Regex-Feldextraktion im Acht-Engine-Lauf — Textgenauigkeit und Feldgenauigkeit sind entkoppelt.

Feldwert-F1 ist das harmonische Mittel aus Präzision und Recall über extrahierte Feldwerte im Vergleich zur Ground Truth: 1,0 bedeutet, dass jedes Belegfeld perfekt wiederhergestellt wurde, 0 bedeutet nichts. Der Mechanismus hinter dem Umschwung ist der oben beschriebene Unterschied in der Ausgabeform. Reguläre Ausdrücke wurden für formatierte Werte wie RM 12.00 oder 14/08/2020 geschrieben; Surya2s normalisierte, labelstrukturierte Ausgabe (Kleinschreibung, Schlüssel-Wert-Zusammenführung) entspricht diesen Mustern weitaus häufiger, während docTRs roher Zeilentext — laut CER genau, aber mit ursprünglicher Groß-/Kleinschreibung und Trennzeichen-Rauschen — sie nicht erfüllt. Die Spalten „Regex-Feldextraktion“ sind die postprocessed_sroie_receipt_regex_*-Metriken des Benchmarks: Sie messen OCR-Text plus nachgelagerte regelbasierte Extraktion, nicht die native strukturierte Ausgabe.

Quelle: field_method_comparison.csv — Spalten regex_field_value_f1 / llm_field_value_f1, Zeilen sroie_2019 (gespeicherte Dezimalzahlen 0–1 als % angezeigt). LLM-Postprozessor: deepseek-v4-flash (Spalte llm_model). 361 Stichproben pro Engine (llm_ok_count).

Tabelle: field_method_comparison.csv — Regex-Spalten, sroie_2019-Zeilen. Dies sind postprocessed_sroie_receipt_regex_*-Metriken: feste Muster, die auf den OCR-Text jeder Engine angewendet werden (nachbearbeitet, nicht native Extraktion). docTRs Regex-Feld-F1 von 0,0766 ist der niedrigste aller acht Engines im zugrunde liegenden Lauf, trotz des zweitbesten CER.

Der LLM-Hebel: Die Engine-Wahl wird nebensächlich

Füttert man den OCR-Text beider Engines einem LLM-Postprozessor (deepseek-v4-flash, Temperatur 0) mit einem strukturierten Extraktions-Prompt, verschwindet die Feldlücke fast vollständig: docTR 0,6171 vs. Surya2 0,6139 Feld-F1 — ein Vorsprung von 0,003 Punkten für die traditionelle Engine, praktisch ein Gleichstand. Der Postprozessor, nicht die OCR-Engine, wird zur entscheidenden Komponente.

Dies ist dasselbe Muster, das im gesamten Acht-Engine-Benchmark zu sehen ist: LLM-Postprocessing bringt leistungsfähige Engines in ein konvergentes Feld-F1-Band, weil es Semantik versteht (Zahlen, Daten, Namen), statt Zeichenformen abzugleichen. docTRs saubererer Basistext liegt minimal vorn; Surya2s normalisierte Struktur verliert diesen winzigen Vorteil unter dem LLM. Zwei Kosten sind mit dem Hebel verbunden: Ein LLM-Aufruf fügt pro Dokument grob 2,0–2,3 s mediane Latenz zur OCR-Zeit hinzu (1.996,3 ms für docTRs Text, 2.261,7 ms für Surya2s, API-bedingt und in der Art identisch), und er rettet keinen Text, den eine Engine grundlegend nicht lesen konnte.

Tabelle: field_method_comparison.csv — llm_*-Spalten, sroie_2019-Zeilen. LLM-Modell: deepseek-v4-flash bei Temperatur 0 (llm_model-Spalte). Die LLM-Latenz ist API-bedingt und getrennt von der Engine-Latenz (summary_metrics.csv latency_p50_ms).

Das Betriebsfenster: Wo der eigentliche Unterschied liegt

Die Zeichengenauigkeit ist gleichauf, die Feldgenauigkeit konvergiert unter einem LLM — aber eine Batch-Pipeline interessiert sich für beides nicht, wenn die Zahlen nicht fertig werden. Auf derselben RTX 4090 zum selben aufgezeichneten Satz von $0,76/Std. erreicht docTR 449,3 Seiten/Min. bei 108,7 ms p50 pro Seite für $0,048 pro 1.000 Seiten; Surya2 erreicht 12,1 Seiten/Min. bei 2.668,0 ms p50 für $1,061 pro 1.000 Seiten — eine 37×-Durchsatzlücke, eine 24,5×-Latenzlücke und eine 22,2×-Kostenlücke. Eine Pipeline, die auf Surya2s Tempo ausgelegt ist, ist eine andere Architekturdiskussion als eine, die auf docTRs Tempo ausgelegt ist.

Die Kosten werden als Wanduhr-Laufzeit × dem RunPod-RTX-4090-Satz ($0,76/Stunde, Preis mit Zeitstempel in den Laufmanifesten) berechnet, einschließlich der Modellinitialisierung — der Preis, den Sie tatsächlich für die GPU-Zeit zahlen würden. Der Durchsatz ist die Wanduhr-Seitenzahl pro Minute, einschließlich derselben Initialisierung. Die Latenz p50/p95 sind die Seiteninferenzzeiten im stationären Zustand, warm gemessen und dann bewertet (Modellladen ausgeschlossen); Surya2s Schwanz ist proportional schlechter — 5.872,2 ms p95 gegenüber docTRs 281,4 ms — weil VLM-Prefill/Decode-Spitzen den Schwanz bei den ersten Seiten dominieren.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, Zeilen sroie_2019. docTR 108,7166, Surya2 2667,9800. Latenz im stationären Zustand (Messmodus warm_then_scored).

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen sroie_2019. docTR 0,0479, Surya2 1,0609. Kosten = Wanduhr-Laufzeit × $0,76/Std. inkl. Modellinitialisierung, Preis mit Zeitstempel in den Laufmanifesten (August 2026).

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, sroie_2019 rows. Beide Engines GPU (RTX 4090, $0.76/hr price timestamped in manifests); Kosten inklusive Modellinitialisierung, nicht reiner Durchsatz im stationären Zustand. Exakte Werte: docTR p50 108.7 / p95 281.4 / 449.3 pg/min / $0.0479; Surya2 p50 2668.0 / p95 5872.2 / 12.1 pg/min / $1.0609.

CORD (indonesische Belege): Beide Engines scheitern, durch Protokoll isoliert

Keine der beiden Engines wurde überwiegend mit indonesischen Belegen trainiert, daher fungiert CORD v2 (100 Stichproben, verschachtelte Felder menu/sub_total/total) als sprachübergreifender Stresstest — und beide scheitern: CER 0.8959 (Surya2) und 0.9101 (docTR). Gemäß Benchmark-Protokoll werden die CORD-Werte von der SROIE-Vergleichsanalyse getrennt gehalten — sie fließen in kein Ranking ein — da der Ground-Truth-Text von CORD die Annotationsstruktur enthält, was die rohe CER für jede Engine zusätzlich zur echten Sprachdiskrepanz erhöht.

Bei den Feldmetriken zeigt sich dasselbe Divergenzmuster wie bei SROIE, komprimiert: Über Regex-Muster extrahiert docTR keine Felder (0.0000 Feld-F1 — eine echte Null in der CSV, kein fehlender Wert), da die englischen Formatmuster in indonesischem Text nichts fanden, während Surya2s normalisierte Ausgabe 0.2458 erreicht. Der LLM führt das Paar dann wieder zusammen auf 0.5500 (docTR) und 0.5203 (Surya2) — der Sprachschock wird vom Postprozessor absorbiert, nicht von der Engine. CORD wird hier als Kontext zur Sprachrobustheit angeführt; es wird bewusst nie mit den SROIE-Werten in einer einzigen Rangliste zusammengeführt.

Tabelle: summary_metrics.csv (CER) und field_method_comparison.csv (Feld-F1), Zeilen cord_v2. Diese Zahlen nicht in ein SROIE-Ranking einmischen: Die CORD-CER kombiniert echte Sprachdiskrepanz mit einer Aufblähung durch die Annotationsstruktur im Ground Truth; die Regex-Muster wurden für englische Formate geschrieben. docTRs Regex-Feld-F1 von 0.0000 ist eine echte Null in der CSV, kein fehlender Wert.

Wer gewinnt wann: Die Übersichtstabelle

„Besser“ hängt vom Arbeitsaufkommen ab. Diese beiden Engines teilen die Achsen klar auf, und genau diese Aufteilung ist das Ergebnis: Die Zeichengenauigkeit ist gleich, bei strukturierten Feldern aus der Box punktet Surya2, bei allen Kosten-/Latenz-/Durchsatz-Achsen liegt docTR vorn, und ein LLM-Postprozessor macht die Engine-Wahl für die finale Feldqualität nahezu irrelevant.

Häufig gestellte Fragen

Ist Surya2 bei Belegen genauer als docTR?

Nein — bei der rohen Zeichengenauigkeit sind sie statistisch gleichwertig: SROIE CER 0,1915 vs. 0,1971 (docTR), eine Differenz von 0,006 Punkten (summary_metrics.csv, cer, sroie_2019-Zeilen). Der Unterschied liegt in der strukturierten Feldextraktion ohne weitere Anpassung (Surya2 gewinnt 4,2× mit Regex) und im Betriebsbereich (docTR gewinnt 24,5× bei der Latenz, 22,2× bei den Kosten, 37× beim Durchsatz).

Warum hat docTR die beste Zeichengenauigkeit, aber die schlechteste Regex-Feldextraktion?

Weil die beiden Metriken unterschiedliche Ausgaben bewerten. docTR liefert sauberen rohen Zeilentext — unter Beibehaltung von Groß-/Kleinschreibung und Trennzeichen — und die festen Regex-Muster, die für formatierte Werte geschrieben wurden, scheitern daran größtenteils: Der SROIE-Regex-Feld-F1 beträgt 0,0766, der niedrigste aller acht Engines im zugrunde liegenden Lauf, bei der zweitbesten CER (0,1971) (summary_metrics.csv cer, field_method_comparison.csv regex_field_value_f1). Surya2s in der Groß-/Kleinschreibung vereinheitlichte, labelstrukturierte Ausgabe passt zufällig zu den Mustern bei 0,3183. Füttert man beide stattdessen an ein LLM, schrumpft die Lücke auf 0,003 — das Regex, nicht die OCR, war der Engpass.

Macht ein LLM-Postprozessor docTR und Surya2 gleichwertig?

Fast exakt — docTR 0,6171 vs. Surya2 0,6139 LLM-Feld-F1 auf SROIE (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen). Der Preis dieser Konvergenz sind zusätzliche ~2,0–2,3 s mediane LLM-Latenz pro Dokument (llm_median_latency_ms, gleiche Zeilen), geeignet für asynchrone Batch-Verarbeitung statt synchroner Wartezeiten pro Seite.

Wie viel schneller und günstiger ist docTR als Surya2?

24,5× geringere p50-Latenz (108,7 ms vs. 2.668,0 ms), 37× höherer Durchsatz (449,3 vs. 12,1 Seiten/min) und 22,2× geringere Kosten pro 1.000 Seiten ($0,048 vs. $1,061) auf derselben RTX 4090 bei $0,76/Std. (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, sroie_2019-Zeilen).

Warum schneiden beide Engines bei CORD-Belegen so schlecht ab?

Zwei sich überlagernde Ursachen, die das Benchmark-Protokoll von der SROIE-Wertung getrennt hält: eine echte Sprachdiskrepanz (indonesische Belege außerhalb des Trainingsfokus beider Engines) und eine durch die Annotationsstruktur bedingte Inflation im Ground-Truth-Text von CORD — die CER liegt bei 0.9101 (docTR) und 0.8959 (Surya2) (summary_metrics.csv, cer, cord_v2-Zeilen). Die Feldmetriken absorbieren einen Teil des Schocks, sobald ein LLM hinzugefügt wird (0.5500 vs. 0.5203), aber CORD-Zeilen werden zitiert und nie in eine kombinierte Wertung einbezogen.

Welche Engine sollte eine Beleg-Pipeline wählen, docTR oder Surya2?

Das hängt von der Achse ab, die Ihre Pipeline konsumiert. Für Rohtext in großem Umfang mit messbaren Kosten dominiert das Envelope von docTR (108,7 ms, 449,3 Seiten/min, $0,048/1K Seiten). Für strukturierte Felder ohne jeden Postprozessor ist der Regex-F1 von Surya2 out-of-box (0.3183 vs. 0.0766) der bessere Ausgangspunkt. Für finale Feldqualität mit LLM-Postprozessor spielt die Wahl kaum eine Rolle (0.6171 vs. 0.6139). Diese Ergebnisse gelten für englische und indonesische Belege auf einer GPU-Stufe im August 2026; jede Produktionsentscheidung sollte auf dem Zielkorpus erneut ausgeführt werden (siehe Einschränkungen).

Woher stammen die Zahlen auf dieser Seite?

Jede Kennzahl ist eine Zeile der veröffentlichten CSVs des First-Party-Benchmarks — results/summary_metrics.csv (CER/WER, Feld-F1, Latenz, Kosten, Durchsatz) und results/field_method_comparison.csv (Regex vs. LLM-Postprozessor, llm_model = deepseek-v4-flash) — gehostet unter ImageToTableai/benchmark-ocr, mit einem redigierten manifest.json pro Lauf für Umgebungs-Fingerprints. Die Datensatzdefinitionen stammen aus den unten zitierten SROIE-2019- und CORD-Publikationen.

Methodik & Quellen

Protokoll

Diese Seite berichtet einen direkten Vergleich aus einem unabhängigen, reproduzierbaren Benchmark-Lauf (offizielle Stufe) — keine Umfrage zu Behauptungen Dritter und keine Anbieter-Vergleichsseite. Nur feste Test-Splits: SROIE 2019 Test (361 englische Belege, flache Felder company/date/address/total) und CORD v2 Test (100 indonesische Belege, verschachtelte Felder menu/sub_total/total); Trainings-Splits wurden nie ausgewertet. Beide Engines sahen dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Aufwärmdurchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte im stabilen Zustand liegen). Beide Läufe wurden mit error_rate 0.0 abgeschlossen (Spalte error_rate in summary_metrics.csv). Der zugrunde liegende Lauf umfasst insgesamt acht Engines; diese Seite vergleicht nur die beiden genannten Engines, und die vollständigen Ergebnisse aller 8 Engines werden separat unter Traditional OCR vs Document Parsing VLMs veröffentlicht.

Laufzeitumgebung

• Hardware: Beide Engines liefen auf derselben NVIDIA RTX 4090 (24 GB); GPU-Kosten berechnet zum RunPod-On-Demand-Satz von $0.76/Std., Preis zeitgestempelt in jedem Lauf’s redacted Manifest (August 2026).
• Engines: Standardkonfiguration, kein Fine-Tuning. Versionen festgelegt: docTR v1.0.1 (traditionelle zweistufige neuronale OCR, GPU) und Surya2 (surya-ocr 0.22.1) (Document-Parsing-VLM, vLLM-basiert) — gemäß der öffentlichen Modelltabelle im Repo (README.md) und den Lauf-Manifesten.
• LLM-Postprozessor: deepseek-v4-flash über API bei Temperatur 0 für deterministische Ausgabe (die Spalte llm_model in field_method_comparison.csv); es war das einzige Modell, das für alle LLM-Feldzeilen beider Engines verwendet wurde.
• Kostenbasis: Wanduhr-Laufzeit × $0.76/Std., einschließlich Modellinitialisierung — Batch-Verarbeitung senkt die Kosten pro Seite.
• Feld-Nachbearbeitung: SROIE-Regex-Feldmetriken sind postprocessed_sroie_receipt_regex_* (Spalten regex_* in field_method_comparison.csv) — Felder, die aus OCR-Text durch einen festen Mustersatz extrahiert werden. Sie messen OCR + nachgelagerte Extraktion, nicht native strukturierte Ausgabe eines der Modelle; die Spalten LLM_* messen OCR-Text + LLM-Extraktion. Die beiden Pipelines werden nie vermischt.

Definitionen der Metriken

• CER (Character Error Rate): Editierdistanz (Einfügungen + Löschungen + Ersetzungen) zwischen OCR-Text und Ground Truth, geteilt durch die Anzahl der Ground-Truth-Zeichen. Niedriger ist besser. Empfindlich gegenüber Groß-/Kleinschreibung und Formatierungskonventionen — leicht konservativ gegenüber Surya2s normalisierter Ausgabe (Case Folding, Zusammenführung von Label/Wert).
• WER (Word Error Rate): dieselbe Editierdistanzberechnung auf Wortebene.
• Field-Value F1 (Regex): harmonisches Mittel aus Präzision und Recall über extrahierte Feldwerte unter Verwendung fester Regex-Muster auf OCR-Text (traditionelle OCR + regelbasierte KIE-Pipeline). Spalte: regex_field_value_f1. Ein Wert von 0 bedeutet, dass keine Feldwerte wiederhergestellt wurden.
• Field-Value F1 (LLM): dieselbe Metrik auf der Ausgabe des LLM-Postprozessors (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie vermischt.
• Document-Fields Exact: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — eine deutlich strengere Messlatte als das feldbezogene F1.
• Latenz p50/p95 & Seiten/min: Inferenzzeit pro Seite im stationären Zustand (warm, dann bewertet; ohne Modell-Ladezeit) und Wanduhr-Durchsatz inklusive Modellinitialisierung.
• Kosten pro 1.000 Seiten: abgerechnete GPU-Stunden für 1.000 Seiten zum erfassten Satz von $0,76/Std.

Quellenverzeichnis

1. summary_metrics.csv (GitHub raw). 16 Zeilen = 8 Modelle × 2 Datensätze. Spalten: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Jede CER/WER-, Latenz-, Kosten- und Durchsatzzahl auf dieser Seite stammt aus den doctr- und surya2-Zeilen hier.
2. field_method_comparison.csv (GitHub raw). 16 Zeilen; Spalten model, dataset, llm_model (= deepseek-v4-flash), Regex-/LLM-Feldwert-Genauigkeit und F1, Document-Fields-Exact, llm_median_latency_ms, Token-Anzahl. Jede Regex-/LLM-Feld-F1-Zahl stammt aus den doctr- und surya2-Zeilen hier.
3. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository, das die Ergebnis-CSVs, redigierte Lauf-Manifeste, das eingefrorene Protokoll und Datensatz-Stichprobenlisten (feste Test-Splits) zur Reproduktion bereitstellt.
4. results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf (16 Läufe) mit Modellversionen, GPU/Treiber, Torch/CUDA/Python-Versionen, Kostenmetadaten mit Preiszeitstempel und Artefakt-Hashes.
5. Huang et al., „ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction“ (2019). SROIE-2019-Datensatzdefinition, Aufgabenstruktur und Lizenz (CC-BY-4.0).
6. Park et al., „CORD: A Consolidated Receipt Dataset for Post-OCR Parsing“ (2020). CORD-v2-Datensatzdefinition, verschachteltes Feldschema und Lizenz (CC-BY-4.0).

Einschränkungen

• Dokumentumfang – nur Belege: SROIE + CORD. Hier wird nichts an Layout-, Tabellen-, Formel- oder Langdokument-Verarbeitung gemessen, wo Dokument-Parsing-VLMs ihre größten Vorteile beanspruchen; Surya2’s beworbene Stärken sind nicht gemessen. Verwenden Sie diese Seite nicht, um zu schlussfolgern, dass „docTR bei allem gewinnt“.
• Stichprobengröße: 361 englische + 100 indonesische Belege. Feld-F1 und CER sind korpusabhängig; Unterschiede im einstelligen Hundertstelbereich (einschließlich der 0,006-CER-Lücke und der 0,003-LLM-F1-Lücke) sollten als Rauschen und nicht als technische Wahrheit betrachtet werden.
• Einzelne GPU-Stufe und einzelner Preis: Alle Zahlen stammen von einer RTX 4090 bei 0,76 $/Std., Preisstand August 2026 in den Lauf-Manifesten. Andere GPUs, Multi-GPU-Serving, Batch-Scheduling oder Preisänderungen verschieben Latenz, Durchsatz und Kosten – leiten Sie Kosten vor der Budgetierung zu aktuellen Preisen neu ab.
• Einzelner LLM-Postprozessor: Alle LLM-Zeilen verwenden deepseek-v4-flash bei Temperatur 0. Ein anderer LLM verschiebt die absolute Feld-F1; die Konvergenzreihenfolge kann sich an den Rändern bewegen. LLM-Latenz (~2,0–2,3 s Median, field_method_comparison.csv llm_median_latency_ms) entsteht durch die API und ist nicht Teil der Latenz der jeweiligen Engine.
• Regex-Abstimmung: Das Musterset wurde einmal pro Datensatz geschrieben. Eine pro Format stark abgestimmte Musterbibliothek könnte bei eigenen Layouts höhere Werte erzielen – zu den Wartungskosten, die der LLM eliminiert.
• CORD-CER ist keine Qualitätsmessung pro Modell: Die CORD-Ground-Truth enthält Annotationsstrukturen, und keine der beiden Engines wurde überwiegend auf Indonesisch trainiert; CORD-CER (0,90–0,91) spiegelt Sprachmismatch + Ground-Truth-Aufblähung wider. CORD-Zeilen werden mit Kontext zitiert und niemals in ein SROIE-Ranking eingemischt (Protokollregel).
• CER-Fairness für VLMs: CER bewertet exakte Zeichenübereinstimmungen, daher wird Surya2’s case-gefaltete, label-zusammengeführte Ausgabe leicht für Ausgabekonventionen bestraft, nicht für Fehllesungen (siehe zugehörige Referenz zu CER). Das CER-Unentschieden unterschätzt Surya2 daher leicht; Feldmetriken sind der fairere familienübergreifende Maßstab.
• Nur zwei Engines: Dieser direkte Vergleich schließt bewusst die anderen sechs Engines des zugrunde liegenden Laufs, Cloud-/API-OCR-Dienste und gehostete VLM-APIs aus; deren Latenz- und Preismodelle unterscheiden sich grundlegend von den hier gemessenen lokalen Engines.
• Versionsfixierung: Die Ergebnisse gelten für docTR v1.0.1 und Surya2 0.22.1 (August 2026). Neuere Versionen beider Engines können jede Zahl auf dieser Seite verschieben.

Verwandte Referenzen: Traditionelle OCR vs. Dokument-Parsing-VLMs · wo Regex bei echten Dokumenten scheitert · warum Zeichenzahlen bei der Feldextraktion irreführen · Beleg-OCR-Genauigkeit

Verwandte Lektüre: KI-OCR vs. klassische OCR-Genauigkeit · Bilddatenextraktion vs. OCR-Engines · KI-Dokumentextraktions-Preise (2026)