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

Character Error Rate (CER) ist der klassische OCR-Maßstab: Einfügungen, Löschungen und Ersetzungen geteilt durch die Zeichen im Originaltext — ein CER von 0,197 bedeutet etwa 19,7 falsch gelesene Zeichen pro 100. Word Error Rate (WER) wendet dieselbe Edit-Distanz-Berechnung auf Wortebene an. In dieser Dimension sind die beiden Engines nicht zu trennen.

Bei SROIE 2019 sind docTR und Surya2 die beiden stärksten Zeichenerkennungs-Engines des Benchmarks, getrennt nur durch 0,006 Punkte — innerhalb der Rauschbandbreite für einen Datensatz mit 361 Proben. WER erzählt dieselbe Geschichte: Surya2 0,2735, docTR 0,3199. Die Erzählung „VLMs schlagen traditionelle OCR" überleht diesen Vergleich bei der reinen Zeichengenauigkeit englischer Quittungen 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 ortet Wörter und ein Erkennungsmodell transkribiert sie, wobei die Groß-/Kleinschreibung und das Layout des gedruckten Textes erhalten bleiben. Surya2 ist ein dokumentenparsendes Vision-Language-Modell (VLM): Es liest das gesamte Dokumentbild und gibt verstandenen Text aus — in Kleinschreibung umgewandelt, Label/Wert-Paare zusammengeführt, Zeilen neu angeordnet — was näher an dem ist, was nachgelagerte Systeme wollen, aber weiter weg von exakten Zeichenübereinstimmungen. CER bewertet exakte Zeichenübereinstimmungen, daher ist es leicht konservativ gegenüber Surya2; die Tatsache, dass das Unentschieden trotz dieser Asymmetrie bestehen bleibt, ist es, was es bedeutsam macht.

Tabelle: summary_metrics.csv — cer- und wer-Spalten, sroie_2019-Zeilen. 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: Out-of-Box-Feldextraktion dreht das Ergebnis um

Benchmarken Sie den Rohtext der Engines mit denselben festen Regex-Mustern auf den vier SROIE-Belegfeldern (Unternehmen, Datum, Adresse, Gesamtbetrag) — der traditionelle OCR- + regelbasierte Schlüsselinformationsextraktions-Ansatz (KIE) — und das Ranking dreht sich um: Surya2 extrahiert Felder mit 0,3183 Field F1 gegenüber docTRs 0,0766, ein 4,2×-Vorteil. docTR hat die zeichengenaueste und die schlechteste Regex-Feldextraktion im Acht-Engine-Lauf — Textgenauigkeit und Feldgenauigkeit sind entkoppelt.

Field-Value F1 ist der harmonische Mittelwert von Präzision und Recall über die extrahierten Feldwerte gegenüber dem Soll: 1,0 bedeutet, jedes Belegfeld wurde perfekt wiederhergestellt, 0 bedeutet nichts. Der Mechanismus hinter der Umkehr ist die oben beschriebene Unterschiedlichkeit der Ausgabeform. Reguläre Ausdrücke wurden für formatierte Werte wie RM 12,00 oder 14/08/2020 geschrieben; Suryas2 normalisierte, beschriftungsstrukturierte Ausgabe (fallunabhängig, Schlüssel-Wert-Verschmelzung) stimmt diesen Mustern viel häufiger überein, während docTRs Rohzeilentext — genau nach CER, aber mit originaler Groß-/Kleinschreibung und Trennzeichenrauschen — sie scheitern lässt. Die Spalten „Regex-Feldextraktion" sind die Benchmarks postprocessed_sroie_receipt_regex_*-Metriken: Sie messen OCR-Text + nachgelagerte regelbasierte Extraktion, nicht native strukturierte Ausgabe.

Quelle: field_method_comparison.csv — Spalten regex_field_value_f1 / llm_field_value_f1, sroie_2019-Zeilen (0–1 gespeicherte Dezimalzahlen als %). LLM-Nachbearbeiter: 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 jedes Engines angewendet wurden (nachverarbeitet, nicht native Extraktion). docTRs Regex-Feld-F1 von 0,0766 ist trotz des zweitbesten CER der niedrigste aller acht Engines im zugrunde liegenden Durchlauf.

Der LLM-Hebel: Die Engine-Auswahl hört auf, wichtig zu sein

Speisen Sie den OCR-Text beider Engines einem LLM-Postprozessor (deepseek-v4-flash, Temperatur 0) mit einem strukturierten Extraktions-Prompt, und die Feldlücke verschwindet beinahe: docTR 0,6171 gegenüber Surya2 0,6139 Feld-F1 — ein Vorsprung von 0,003 Punkten für den traditionellen Engine, in der Praxis ein Unentschieden. Der Postprozessor, nicht der OCR-Engine, wird zur entscheidenden Komponente.

Dies ist dasselbe Muster, das im gesamten Acht-Engine-Benchmark zu beobachten ist: LLM-Postprozessierung zieht leistungsfähige Engines in eine konvergente Feld-F1-Bandbreite, weil sie Semantik versteht (Zahlen, Daten, Namen) anstatt Zeichenformen abzugleichen. docTRs sauberer Basistext gewinnt hauchdünn; Surya2s normalisierte Struktur verliert diesen minimalen Vorteil unter dem LLM. Zwei Kosten kommen mit dem Hebel: Ein LLM-Aufruf fügt pro Dokument etwa 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 kann Text nicht retten, den ein 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). LLM-Latenz ist API-bedingt und getrennt von der Engine-Latenz (summary_metrics.csv latency_p50_ms).

Der Betriebsbereich: Wo der eigentliche Unterschied liegt

Zeichengenauigkeit ist gleich, Feldgenauigkeit konvergiert unter einem LLM — aber eine Batch-Pipeline ist beides egal, wenn die Zahlen nicht fertig werden. Auf demselben RTX 4090 mit derselben erfassten Rate von $0,76/Stunde hält docTR 449,3 Seiten/Minute bei 108,7 ms p50 pro Seite für $0,048 pro 1.000 Seiten; Surya2 hält 12,1 Seiten/Minute bei 2.668,0 ms p50 für $1,061 pro 1.000 Seiten — eine 37×-Lücke im Durchsatz, eine 24,5×-Lücke in der Latenz und eine 22,2×-Lücke in den Kosten. Eine Pipeline, die auf das Tempo von Surya2 ausgelegt ist, ist ein anderes Architekturgespräch als eine, die auf das Tempo von docTR ausgelegt ist.

Die Kosten werden berechnet als Laufzeit in Echtzeit × die RunPod RTX 4090-Rate ($0,76/Stunde, Preis mit Zeitstempel in den Ausführungsmanifesten), einschließlich Modellinitialisierung — der Preis, den Sie tatsächlich für die GPU-Zeit zahlen würden. Der Durchsatz sind Echtzeit-Seiten pro Minute, einschließlich derselben Initialisierung. Die Latenz p50/p95 sind steady-state Inferenzzeiten pro Seite, gemessen warm-then-scored (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 auf den ersten Seiten dominieren.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, sroie_2019-Zeilen. docTR 108,7166, Surya2 2667,9800. Steady-state-Latenz (Messmodus warm_then_scored).

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, sroie_2019-Zeilen. docTR 0,0479, Surya2 1,0609. Kosten = Laufzeit in Echtzeit × $0,76/Stunde inklusive Modellinit, Preis mit Zeitstempel in Ausführungsmanifesten (August 2026).

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, sroie_2019 Zeilen. Beide Engines GPU (RTX 4090, $0.76/hr Preis mit Zeitstempel in Manifests); Kosten beinhalten Modellinitialisierung, nicht reinen stationären Durchsatz. 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 Quittungen): Beide Engines brechen zusammen, nach Protokoll isoliert

Keine Engine wurde überwiegend auf indonesischen Quittungen trainiert, daher dient CORD v2 (100 Stichproben, verschachtelte Felder menu/sub_total/total) als sprachübergreifender Stresstest — und beide brechen zusammen: CER 0.8959 (Surya2) und 0.9101 (docTR). Gemäß dem Benchmark-Protokoll werden die CORD-Zahlen von SROIE-Vergleichen isoliert — sie werden in kein Ranking einbezogen —, da CORDs Bodenwahrheitstext Annotationsstruktur einbettet, was den rohen CER für jede Engine zusätzlich zum tatsächlichen Sprachmismatch aufbläht.

Bei den Feldmetriken hält dasselbe Divergenzmuster wie bei SROIE an, komprimiert: Durch Regex-Muster stellt docTR keine Felder wieder her (0.0000 field F1 — ein wörtlicher Nullwert in der CSV, kein fehlender Wert), da die englischformatierten Muster in indonesischem Text nichts trafen, während Surya2s normalisierte Ausgabe 0.2458 erreicht. Das LLM konvergiert das Paar dann zu 0.5500 (docTR) und 0.5203 (Surya2) — der Sprachschock wird vom Postprozessor absorbiert, nicht von der Engine. CORD wird hier für den Kontext der Sprachrobustheit zitiert; es wird absichtlich nie mit den SROIE-Zahlen zu einem einzigen Leaderboard zusammengefasst.

Tabelle: summary_metrics.csv (cer) und field_method_comparison.csv (field F1), cord_v2 Zeilen. Diese Zahlen nicht in irgendein SROIE-Ranking einbeziehen: CORD CER kombiniert echten Sprachmismatch mit der Aufblähung durch Annotationsstruktur in der Bodenwahrheit; die Regex-Muster wurden für englische Formate geschrieben. docTRs Regex field F1 von 0.0000 ist ein wörtlicher Nullwert in der CSV, kein fehlender Wert.

Wer gewinnt wann: Die Zusammenfassungstabelle

„Besser" ist arbeitslastabhängig. Diese beiden Engine teilen die Achsen sauber auf, und diese Aufteilung ist die Erkenntnis: Zeichengenauigkeit ist gleichauf, die Bequemlichkeit bei strukturierten Feldern favorisiert Surya2, jede Kosten-/Latenz-/Durchsatz-Achse favorisiert docTR, und ein LLM-Postprozessor macht die Engine-Auswahl für die finale Feldqualität nahezu irrelevant.

Häufig gestellte Fragen

Ist Surya2 bei Quittungen genauer als docTR?

Nein — bei der reinen 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 rows). Wo sie sich unterscheiden, ist die strukturierte Feldausgabe direkt aus der Box (Surya2 gewinnt 4,2× bei Regex) und der Einsatzbereich (docTR gewinnt 24,5× bei Latenz, 22,2× bei Kosten, 37× bei Durchsatz).

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

Weil die beiden Metriken verschiedene Ausgaben bewerten. docTR gibt sauberen rohen Zeilentext zurück — unter Beibehaltung der ursprünglichen Groß-/Kleinschreibung und Trennzeichen — und die festen Regex-Muster, die für formatierte Werte geschrieben wurden, scheitern größtenteils dagegen: Sein SROIE Regex-Feld-F1 ist 0,0766, der niedrigste aller acht Engines im zugrunde liegenden Durchlauf, gegenüber dem zweitbesten CER (0,1971) (summary_metrics.csv cer, field_method_comparison.csv regex_field_value_f1). Surya2’s fallunabhängige, beschriftungsstrukturierte Ausgabe trifft die Muster zufällig mit 0,3183. Füttern Sie beide stattdessen mit einem LLM, schrumpft die Lücke auf 0,003 — der Flaschenhals war das Regex, nicht die OCR.

Gleicht ein LLM-Nachbearbeiter docTR und Surya2 an?

Nahezu genau — docTR 0,6171 vs. Surya2 0,6139 LLM-Feld-F1 auf SROIE (field_method_comparison.csv, llm_field_value_f1, sroie_2019 rows). Der Preis für diese Konvergenz ist eine zusätzliche mediane LLM-Latenz von ~2,0–2,3 s pro Dokument (llm_median_latency_ms, gleiche Zeilen), was eher für asynchrone Stapelverarbeitung als für synchrone Wartezeiten pro Seite geeignet ist.

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

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

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

Zwei sich verstärkende Ursachen, die das Benchmark-Protokoll von der SROIE-Rangliste trennt: eine echte Sprachdiskrepanz (indonesische Belege außerhalb des Trainingsfokus beider Engines) und eine Annotationstruktur-Inflation im CORD-Ground-Truth-Text — 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 ein kombiniertes Ranking einbezogen.

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

Es hängt von der Achse ab, die Ihre Pipeline verarbeitet. Für Rohtext in großen Mengen mit abgerechneten Kosten dominiert docTRs Leistungsumfang (108,7 ms, 449,3 Seiten/min, $0,048/1K Seiten). Für strukturierte Felder ohne jeglichen Nachprozessor ist Surya2s Regex-F1-Wert aus der Box (0,3183 vs. 0,0766) der bessere Ausgangspunkt. Für die finale Feldqualität mit LLM-Nachbearbeitung 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 neu ausgeführt werden (siehe Einschränkungen).

Woher stammen die Zahlen auf dieser Seite?

Jede Zahl 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-Nachbearbeitung, llm_model = deepseek-v4-flash) — gehostet unter ImageToTableai/benchmark-ocr, mit einem geschwärzten manifest.json pro Durchlauf für Umgebungsfingerabdrücke. Datensatzdefinitionen stammen aus den unten zitierten SROIE-2019- und CORD-Papers.

Methodik & Quellen

Protokoll

Diese Seite berichtet einen direkten Vergleich aus einem unabhängigen, reproduzierbaren Benchmark-Lauf (offizielle Stufe) — keine Umfrage von Drittanbieter-Aussagen und keine Hersteller-Vergleichsseite. Nur feste Test-Splits: SROIE 2019 test (361 englische Quittungen, flache Felder Firma/Datum/Adresse/Gesamtbetrag) und CORD v2 test (100 indonesische Quittungen, verschachtelte Felder Menü/Teilsumme/Gesamtbetrag); Trainings-Splits wurden nie ausgewertet. Beide Engines sahen dieselben Bilder, dieselben Ground Truths und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenz-Werte im steady state liegen). Beide Läufe schlossen mit error_rate 0.0 ab (Spalte error_rate in summary_metrics.csv). Der zugrunde liegende Lauf umfasste insgesamt acht Engines; diese Seite vergleicht nur die beiden genannten Engines, und die vollständigen 8-Engine-Ergebnisse werden separat auf 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-Tarif von $0.76/hr, Preis mit Zeitstempel im redigierten Manifest jedes Laufs (August 2026).
• Engines: Out-of-the-box, kein Fine-Tuning. Versionen fixiert: docTR v1.0.1 traditionelles zweistufiges neurales OCR, GPU und Surya2 (surya-ocr 0.22.1) dokumentparsender VLM, vLLM-geservt — gemäß der Modelltabelle im öffentlichen Repo (README.md) und den Lauf-Manifesten.
• LLM-Postprozessor: deepseek-v4-flash via API bei Temperatur 0 für deterministische Ausgabe (Spalte llm_model in field_method_comparison.csv); es war das einzige Modell für alle LLM-Felder-Zeilen beider Engines.
• Kostenbasis: Echte Laufzeit × $0.76/hr, inklusive 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 dem OCR-Text durch ein festes Muster-Set extrahiert wurden. Sie messen OCR + nachgelagerte Extraktion, nicht die native strukturierte Ausgabe irgendeines Modells; die Spalten LLM_* messen OCR-Text + LLM-Extraktion. Die beiden Pipelines werden nie vermischt.

Metrikdefinitionen

• 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 (Fallfolding, Label/Wert-Verschmelzung).
• WER (Word Error Rate): dieselbe Editierdistanz-Berechnung auf Wortebene.
• Feld-Wert-F1 (Regex): harmonisches Mittel aus Precision 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.
• Feld-Wert-F1 (LLM): dieselbe Metrik für die Ausgabe des LLM-Postprozessors (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie gemischt.
• Dokumentfelder exakt: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — ein viel strengerer Maßstab als der Feld-F1-Wert.
• Latenz p50/p95 & Seiten/min: stationäre Inferenzzeit pro Seite (warm-then-scored, schließt Modellladen aus) und Durchsatz in Echtzeit inkl. Modellinitialisierung.
• Kosten pro 1.000 Seiten: abgerechnete GPU-Stunden für 1.000 Seiten zum erfassten Satz von $0,76/Stunde.

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 lässt sich auf die doctr- und surya2-Zeilen hier zurückführen.
2. field_method_comparison.csv (GitHub raw). 16 Zeilen; Spalten model, dataset, llm_model (= deepseek-v4-flash), Regex/LLM Feld-Wert-Genauigkeit und F1, Dokumentfelder-exakt, llm_median_latency_ms, Token-Zahlen. Jede Regex/LLM Feld-F1-Zahl lässt sich auf die doctr- und surya2-Zeilen hier zurückführen.
3. ImageToTableai/benchmark-ocr Repository. Öffentliches Repo mit den Ergebnis-CSVs, geschwärzten Ausführungsmanifesten, eingefrorenem Protokoll und Datensatz-Beispiellisten (feste Testsplits) zur Reproduktion.
4. results/manifests/ (GitHub). Ein geschwärztes manifest.json pro veröffentlichter Ausführung (16 Ausführungen) mit Modellversionen, GPU/Treiber, torch/CUDA/Python-Versionen, Kostenmetadaten mit Preismarke 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 Feldaufmaß und Lizenz (CC-BY-4.0).

Einschränkungen

• Dokumentbereich — nur Belege: SROIE + CORD. Hier wird nicht die Layout-/Tabellen-/Formel-/Langdokumentverarbeitung gemessen, in der dokumentparsende VLMs ihre größten Vorteile behaupten; die vermarkteten Stärken von Surya2 sind ungetestet. Verwenden Sie diese Seite nicht, um zu dem Schluss zu kommen „docTR gewinnt bei allem."
• Stichprobengröße: 361 englische + 100 indonesische Belege. Field F1 und CER sind korpusabhängig; einstellige Unterschiede von wenigen Hundertstelen (einschließlich der 0,006 CER-Lücke und der 0,003 LLM-F1-Lücke) sollten als Rauschen und nicht als ingenieurtechnische Wahrheit behandelt werden.
• Einzelne GPU-Klasse und einzelner Preis: Alle Zahlen stammen von einer RTX 4090 zu $0,76/Stunde, Preis mit Zeitstempel August 2026 in den Ausführungsmanifesten. Andere GPUs, Multi-GPU-Bereitstellung, Stapelplanung oder Preisänderungen verschieben Latenz, Durchsatz und Kosten — leiten Sie die Kosten vor der Budgetierung zu aktuellen Raten ab.
• Einzelner LLM-Postprozessor: Alle LLM-Zeilen verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt den absoluten Field F1; die Konvergenzreihenfolge kann an den Rändern schwanken. Die LLM-Latenz (~2,0–2,3 s Median, field_method_comparison.csv llm_median_latency_ms) wird durch die API verursacht und ist nicht Teil der Latenz der jeweiligen Engine selbst.
• Regex-Abstimmung: Das Musterensemble wurde einmal pro Datensatz geschrieben. Eine pro-Format, stark abgestimmte Musterbibliothek könnte auf eigenen Layouts höher punkten — mit dem Wartungsaufwand, den das LLM eliminiert.
• CORD CER ist keine qualitätsbezogene Einzelmodell-Messung: CORD Ground Truth enthält Annotationstrukturen, und keine der beiden Engines wurde überwiegend auf Indonesisch trainiert; CORD CER (0,90–0,91) spiegelt Sprachmismatch + Ground-Truth-Inflation wider. CORD-Zeilen werden mit Einordnung zitiert und nie in irgendein SROIE-Ranking einbezogen (Protokollregel).
• CER-Gerechtigkeit für VLMs: CER bewertet exakte Zeichenübereinstimmungen, daher wird Suryas fallgefoldete, label-verschmolzene Ausgabe mild für Ausgabekonventionen und nicht für Fehllesungen bestraft (siehe bezügliche Referenz zu CER). Das CER-Unentschieden unterschätzt daher leicht Surya2; Feldmetriken sind der fairere vergleichbare Maßstab über Familien hinweg.
• Nur zwei Engines: Dieser Vergleich schließt bewusst die anderen sechs Engines des zugrundeliegenden Durchlaufs, Cloud-/API-OCR-Dienste und gehostete VLM-APIs aus; deren Latenz- und Preismodelle unterscheiden sich grundlegend von den hier gemessenen lokalen Engines.
• Versionssperre: Die Ergebnisse gelten für docTR v1.0.1 und Surya2 0.22.1 (August 2026). Neuere Versionen einer der beiden Engines können jede Zahl auf dieser Seite verschieben.

Verwandte Referenzen: Traditionelles OCR vs. Dokument-parsende VLMs · Regex vs. LLM-Feldextraktion · Feld- vs. Zeichenebene-Genauigkeit · Beleg-OCR-Genauigkeit

Verwandte Lektüre: KI-OCR vs. traditionelles OCR – Genauigkeit · KI-Bilddatenextraktion vs. traditionelles OCR · KI-Dokumentextraktionspreise (2026)