Traditionelle OCR vs. Dokument-Parsing-VLMs
Beleg-Benchmark-Ergebnisse (2026)

Zeichengenauigkeit nach Modell bei SROIE (englische Belege)

Quelle: summary_metrics.csv – Spalte cer, Zeilen sroie_2019 (8 Zeilen). Surya2 0,1915, docTR 0,1971, PaddleOCR 0,2045, EasyOCR 0,2833, Tesseract 0,3347, PaddleOCR-VL 0,3370, Docling 0,5909, Unlimited-OCR 0,6552. Niedriger ist besser. Tesseract ist nur mit CPU nutzbar.

Tabelle: summary_metrics.csv — cer- und wer-Spalten, sroie_2019-Zeilen, jeweils 361 Stichproben (error_rate 0.0 für alle 8 Modelle). CER = Zeichenfehlerrate, WER = Wortfehlerrate; niedriger ist besser. Exakte Werte: Surya2 cer 0.19147 / wer 0.27352; docTR cer 0.19707 / wer 0.31990.

Die Wortfehlerrate erzählt dieselbe Geschichte mit einer anderen Granularität: Sie bewertet Fehler auf Wortebene statt auf Zeichenebene. Surya2 führt bei der WER mit 0.274, docTR folgt mit 0.320. Beachten Sie den Ausreißer am unteren Ende: Unlimited-OCR hat die schlechteste CER (0.655), aber eine mittlere WER (0.478) — seine Ausgabe ist stark hinsichtlich Groß-/Kleinschreibung und Format normalisiert (eine Ausgabekonvention, die im Methodik-Abschnitt erörtert wird), was die Bearbeitungen auf Zeichenebene aufbläht, selbst wenn die Wörter weitgehend intakt sind.

Docling verdient vor seinem Auftritt in Vergleichen eine Einordnung: Es ist weder eine reine traditionelle OCR-Engine noch ein VLM. Docling ist ein Pipeline-Parser — eine gestufte Toolchain, die Layout-Analyse, Tabellenerkennung und Lesereihenfolge-Rekonstruktion um einen OCR-Kern herum ausführt. Bei einem einfachen Beleg bringt dieser Pipeline-Overhead wenig Nutzen, was ein Grund dafür ist, dass seine rohe CER (0,591 auf SROIE) hinter den Single-Pass-Engines zurückbleibt.

Kosten und Latenz: Der Vorteil der traditionellen Engines

Wenn die Zeichengenauigkeit zwischen den beiden Familien nichts entscheidet, entscheiden Kosten und Latenz fast alles. Auf dem identischen Test-Split erreicht docTR 449 Seiten/min bei 108,7 ms p50 pro Seite für $0,048 pro 1.000 Seiten; Surya2 erreicht 12 Seiten/min bei 2.668 ms p50 für $1,061 pro 1.000 Seiten — ungefähr 37× der Durchsatz, 24,5× die Latenz pro Seite und 22× die Kosten pro tausend Seiten.

Die Kosten werden als Wanduhr-Laufzeit × dem RunPod-RTX-4090-Satz ($0,76/Stunde, Preis mit Zeitstempel in den Lauf-Manifesten) berechnet — der Preis, den Sie tatsächlich für die GPU-Zeit zahlen würden, einschließlich der Modellinitialisierung. Tesseract ist der Sonderfall: Nur-CPU, es hat überhaupt keine GPU-Kosten und schafft trotzdem 78,6 Seiten/min auf SROIE; seine Kosten-Zelle ist in der CSV bewusst leer, nicht weil es kostenlos ist, sondern weil es keine abgerechneten GPU-Stunden verbraucht.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, Zeilen sroie_2019. docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9 (CPU), PaddleOCR-VL 694,3, Docling 732,0, Unlimited-OCR 1600,7, Surya2 2668,0. Latenz im stationären Zustand, Messmodus warm-then-scored (Modell-Laden ausgeschlossen).

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen sroie_2019. docTR 0,0479, EasyOCR 0,1098, PaddleOCR-VL 0,2048, PaddleOCR 0,2214, Unlimited-OCR 0,3879, Docling 0,3978, Surya2 1,0609. Tesseract Nur-CPU: Zelle in der CSV leer (keine GPU-Kosten); Kosten beinhalten Modell-Init, nicht reinen stationären Durchsatz.

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, sroie_2019-Zeilen. GPU-Läufe auf RTX 4090 ($0,76/Std., Preis in Manifests zeitgestempelt); Tesseract lief nur mit CPU (leere Kostenzelle, nicht null). Durchsatz ist Wanduhr-Seiten/min inklusive Modellinitialisierung.

Die Spalte zur Tail-Latenz ist wichtig, wenn es um das Worst-Case-Verhalten geht, nicht nur um Mediane. PaddleOCRs p95 von 3.331 ms und Doclings 3.240 ms liegen weit über ihren p50-Werten — Effekte der ersten Seite und Prefill-Spitzen dominieren den Tail bei GPU-Engines — während docTRs p95 (281 ms) eng bleibt. Für interaktive Workloads (ein Nutzer wartet auf eine Seite) ist diese p95-Spanne der Unterschied zwischen einer 0,3-Sekunden-Wartezeit und einer Wartezeit von über 3 Sekunden.

CORD (indonesische Belege): Sprachmismatch und aufgeblähte Ground-Truth-Werte

CORD v2 ist ein indonesischsprachiger Belegdatensatz mit verschachtelten Feldern (Menü, Zwischensumme, Gesamtsumme). Keine der 8 Engines wurde überwiegend mit indonesischen Belegen trainiert, daher fungiert CORD als sprachübergreifender Stresstest — und die CER aller Engines fällt auf 0,90–1,08. Diese Zahlen müssen mit dem Hinweis gelesen werden, dass CORDs Ground-Truth-Text die Annotationsstruktur einbettet, was die rohe CER für jede Engine aufbläht; CORD-Ergebnisse werden strikt getrennt vom SROIE-Ranking geführt und können nicht zu einem einzigen Leaderboard zusammengeführt werden.

Zwei unterschiedliche Kräfte treiben die CORD-CER in Richtung 1,0, und nur eine davon ist die Sprache selbst. Erstens die Sprache: Auf Englisch trainierte Engines lesen indonesische Wörter tatsächlich falsch — indonesische Namen, Straßenadressen und Währungsformate (Rp) liegen außerhalb ihrer Trainingsverteilungen. Zweitens der Ground Truth: CORDs veröffentlichte Textannotationen betten die Annotationsstruktur ein (Feldbezeichnungen mit Koordinaten) statt reinen sichtbaren Texts, sodass die rohe CER die Editierdistanz gegen einen strukturell erweiterten String misst. Die saubersten VLM-Beispiele werden am härtesten bestraft — PaddleOCR-VL mit CER 1,080 ist das extreme Artefakt dieses Mechanismus, keine Aussage über seine Textqualität.

Der faire familienübergreifende Vergleich auf CORD ist daher die Feldmetrik, nicht die CER (siehe nächster Abschnitt). Was die CER-Spalten dennoch nützlich zeigen, ist, dass der Sprachmismatch real und architekturübergreifend universell ist — jede Familie, traditionell wie VLM, landet im selben 0,90–1,08-Band ohne strukturellen Vorteil für eine der beiden.

Tabelle: summary_metrics.csv — CER-Spalte, cord_v2-Zeilen, jeweils 100 Stichproben. Vergleichen Sie diese Zahlen nicht in einem kombinierten Ranking mit SROIE: CORD CER kombiniert echte Sprachabweichung mit einer durch Annotationsstruktur aufgeblähten Ground Truth (Methodik unten). Ein CER über 1,0 (PaddleOCR-VL 1,0805) ist ein Edit-Distanz-Artefakt dieser aufgeblähten Ground Truth.

Feld-F1: LLM-Nachbearbeitung führt das Feld zusammen

Die Zeichengenauigkeit ordnet die Engines ein; die Feldextraktion ist das, wofür Produktionsnutzer tatsächlich zahlen. Der Benchmark extrahiert vier Belegfelder (Firma, Datum, Adresse, Gesamtsumme) aus dem OCR-Text jeder Engine mit zwei Nachbearbeitungsmethoden — feste Regex-Muster (der traditionelle OCR- und regelbasierte KIE-Ansatz) und ein LLM (deepseek-v4-flash) mit strukturiertem Prompt. Das Ergebnis: Das LLM löscht die Engine-Lücke auf SROIE fast vollständig aus und bringt sechs von acht Engines in ein 0,57–0,62 Feld-F1-Band — während ihre Regex-Ergebnisse über eine Spanne von 0,26 Punkten verteilt waren.

Feldwert-F1 ist das harmonische Mittel aus Präzision und Recall über extrahierte Feldwerte, bewertet gegen die Ground Truth — 1,0 bedeutet, dass jeder Feldwert perfekt extrahiert wurde, 0 bedeutet, dass nichts wiederhergestellt wurde. Die Regex-Spalten verwenden einen festen Mustersatz pro Datensatz; die LLM-Spalten verwenden deepseek-v4-flash bei Temperatur 0 für deterministische Ausgabe (die llm_model-Spalte in der Vergleichs-CSV). Die beiden Metriken messen unterschiedliche Pipelines und werden nie vermischt.

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

Tabelle: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1, sroie_2019-Zeilen. LLM = deepseek-v4-flash-Nachbearbeitung (llm_model-Spalte). docTR regex 0.0766 → LLM 0.6171 (8.1× Steigerung); die 6 nicht abgeschlagenen Engines liegen zwischen 0.5685–0.6171.

Zwei kontraintuitive Ergebnisse sind in dieser Tabelle enthalten. Erstens: docTR hat den schlechtesten regex Feld-F1 auf SROIE (0.077) und den besten LLM Feld-F1 (0.617) — derselbe saubere OCR-Text, aus dem regex nur 7,7 % der Felder extrahierte, ergab unter dem LLM 61,7 %. Die Nachbearbeitung, nicht die OCR, war der Engpass. Zweitens: Die beiden Engines, die außerhalb des 0.57–0.62-Bandes liegen, sind genau die beiden mit verschlechterter OCR-Basis: EasyOCR (0.372, SROIE CER 0.283) und Tesseract — dessen CORD-Ergebnis (LLM Feld-F1 0.163) zeigt, dass ein LLM keine Felder aus Text extrahieren kann, den es grundlegend nicht lesen kann (CORD CER 0.9523). Die Obergrenze jeder Nachbearbeitung ist die Qualität der OCR-Basis darunter.

Bei CORD absorbiert das LLM ebenfalls einen Teil des Sprachschocks: Der LLM-Feld-F1 bleibt bei 0,47–0,55 für die leistungsfähigen Engines (PaddleOCR 0,553, docTR 0,550, PaddleOCR-VL 0,520, Surya2 0,520), obwohl Regex nahezu auf null zusammenbricht (docTR 0,0, EasyOCR 0,7 %) — die Muster wurden für englische Formate geschrieben, und die Strafe für „eine weitere Sprache" wird fast vollständig von den Regeln getragen, nicht vom LLM (field_method_comparison.csv, llm_field_value_f1 / regex_field_value_f1, cord_v2-Zeilen).

Warum CER Dokument-Parsing-VLMs unterbewertet

CER vergleicht die VLM-Ausgabe und die Ground-Truth zeichenweise, und VLMs werden für zwei legitime Verhaltensweisen bestraft, die keine Erkennungsfehler sind: Case-Folding und Label-/Wert-Zusammenführung. Die CER-Zerlegung des Benchmarks auf SROIE führt etwa 18 % des VLM-CER auf Formatunterschiede bei der Groß-/Kleinschreibung zurück (z. B. TAN CHAY YEE → tan chay yee) und etwa 10 % auf Zeilenzusammenführung oder entfernte Trennzeilen — wobei die Feldwerte selbst (company, total, date) tatsächlich korrekt sind (CER-Zerlegungsanalyse in den Protokollnotizen des Benchmarks dokumentiert, SROIE-Läufe).

Der Designkonflikt ist real und strukturell: Traditionelle OCR-Engines geben Rohtext mit erhaltener Groß-/Kleinschreibung aus und sind daher von Natur aus für die CER-Bewertung optimiert; Dokument-Parsing-VLMs geben „verstandenen" Text aus (normalisierte Groß-/Kleinschreibung, zusammengeführte Label-Wert-Paare, neu geordnete Zeilen), was näher an dem liegt, was ein nachgelagertes System möchte, aber weiter von exakten Zeichenübereinstimmungen entfernt ist. Deshalb verwendet die Überschrift der Seite CER nur dort, wo es ein fairer Vergleich zwischen gleichartigen Ausgaben ist, und deshalb liegt der faire familienübergreifende Vergleich in den Feldmetriken — und deshalb ist CORD-CER (das zusätzlich eine Aufblähung durch die Annotationsstruktur aufweist) in einem eigenen Abschnitt isoliert. Der übergeordnete Punkt: Eine CER-Differenz zwischen Familien ist nicht automatisch eine Genauigkeitsdifferenz, und jeder, der Modelle über Familien hinweg vergleicht, sollte prüfen, was das CER misst, bevor er schlussfolgert, dass eine Familie „besser liest".

So wählen Sie: Welche Achse zählt für Ihre Arbeitslast

„Besser" ist ohne eine Arbeitslast bedeutungslos. Die ehrliche Schlussfolgerung des Benchmarks ist, dass die beiden Familien auf unterschiedlichen Achsen gewinnen, und Belege messen genau die Achsen, auf denen traditionelle Engines gewinnen, sowie die Achsen, auf denen die Nachbearbeitung — nicht die Engine-Familie — die Feldqualität bestimmt.

Die Auswahlhilfe wird direkt aus den zitierten CSV-Zeilen abgeleitet; sie ist eine datengetriebene Lesehilfe, keine Herstellerempfehlung. Ihre genauen Ergebnisse variieren je nach Hardware, Dokumentmix und Modellversionen.

Häufig gestellte Fragen

Sind Dokument-Parsing-VLMs bei Belegen genauer als traditionelle OCR?

Nicht bei der rohen Zeichengenauigkeit — das beste VLM und die beste traditionelle Engine sind bei SROIE 2019 statistisch gleichauf (Surya2 CER 0,191 vs. docTR 0,197, summary_metrics.csv sroie_2019-Zeilen), und PaddleOCR (0,204) liegt auf Platz drei. Wenn Feldextraktion das Ziel ist, ist — VLM oder nicht — die LLM-Nachbearbeitung der entscheidende Faktor (0,57–0,62 Konvergenzband, field_method_comparison.csv).

Wann ist traditionelle OCR sinnvoller als ein Dokument-Parsing-VLM?

Wenn das Volumen hoch, die Kosten nutzungsabhängig oder die Latenz interaktiv ist. Bei SROIE verarbeitete docTR 449 Seiten/min bei $0,048 pro 1.000 Seiten und 108,7 ms p50; Surya2 verarbeitete 12 Seiten/min bei $1,061 pro 1.000 Seiten und 2.668 ms p50 (summary_metrics.csv, doctr- und surya2-sroie_2019-Zeilen). Bei einer interaktiven Wartezeit pro Seite beträgt der Unterschied 0,1 Sekunden gegenüber 2,7 Sekunden.

Warum schneiden Dokument-Parsing-VLMs beim CER manchmal schlechter ab als günstige OCR?

Weil der CER exakte Zeichenübereinstimmungen bewertet und VLMs für Case-Folding sowie Label/Wert-Zusammenführungen bestraft werden, die Ausgabekonventionen und keine Fehllesungen sind. Die CER-Zerlegung des Benchmarks bei SROIE führt rund 18% des VLM-CER auf Case-Format-Unterschiede und ~10% auf Zeilenzusammenführung/entfernte Trennzeichen zurück — wobei die Feldwerte selbst oft korrekt sind (siehe Methodik). Der CORD-CER wird zusätzlich durch die Annotationsstruktur in der Ground Truth aufgebläht, weshalb diese Seite den CORD-CER von jedem Ranking ausschließt und für familienübergreifende Vergleiche Feldmetriken verwendet.

Wie viel kostet Beleg-OCR pro Seite auf einer RTX 4090?

Zwischen $0,048 (docTR) und $1,061 (Surya2) pro 1.000 Seiten auf einer RTX 4090 bei $0,76/Std., Preisstand August 2026 in den Lauf-Manifesten (summary_metrics.csv cost_per_1000_pages, sroie_2019-Zeilen). Tesseract ist nur-CPU und verbraucht keine GPU-Stunden. Die Kosten umfassen die Modellinitialisierung, daher sinken die Kosten pro Seite mit wachsender Batch-Größe.

Warum erzielt jedes Modell einen CER über 0,90 bei CORD-Belegen?

Zwei sich überlagernde Ursachen: echte Sprachdiskrepanz (indonesische Belege außerhalb des Trainingsfokus jeder Engine) und durch die Annotationsstruktur bedingte Inflation im Ground-Truth-Text von CORD. Keine Familie entkommt dem — alle 8 Modelle landen im Band 0,90–1,08 (summary_metrics.csv cer, cord_v2-Zeilen). CORD ist ein Stress-Test für Sprach-/Layout-Robustheit, getrennt vom SROIE-Ranking gehalten.

Wird ein LLM meine schlechte OCR-Ausgabe einfach beheben?

Nur bis zur Qualität des Basistexts. Bei SROIE hob das LLM sechs Engines unabhängig von der Engine in ein Feld-F1-Band von 0,57–0,62 (field_method_comparison.csv), aber der CORD-Fall von Tesseract zeigt die Untergrenze: Bei CER 0,9523 beträgt sein LLM-Feld-F1 0,163 — ein LLM kann keine Felder aus Text extrahieren, den es nicht lesen kann.

Welches ist die schnellste OCR für Belege?

docTR in diesem Benchmark: 108,7 ms p50 pro Seite und 449 Seiten/min bei SROIE 2019 (summary_metrics.csv doctr/sroie_2019: latency_p50_ms, pages_per_minute). Das langsamste getestete, Surya2, war 24,5× langsamer bei p50 (2.668 ms) und 37× langsamer beim Durchsatz (12 Seiten/min).

Woher stammen die Zahlen auf dieser Seite?

Jede Zahl ist eine Zeile der veröffentlichten CSVs des First-Party-Benchmarks — results/summary_metrics.csv (8 Modelle × 2 Datensätze: CER/WER, Feld-F1, Latenz, Kosten, Durchsatz) und results/field_method_comparison.csv (regex vs. LLM-Nachbearbeitung) — gehostet unter ImageToTableai/benchmark-ocr, mit einem redigierten manifest.json pro Lauf für Umgebungs-Fingerabdrücke. Datensatzdefinitionen stammen aus den unten zitierten SROIE-2019- und CORD-Papieren.

Methodik & Quellen

Protokoll

Diese Seite berichtet den Dokument-Parsing-Vergleich eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Übersicht über Behauptungen Dritter. Nur feste Test-Splits: SROIE 2019 Test (361 englische Belege, flache Felder Firma/Datum/Adresse/Summe) und CORD v2 Test (100 indonesische Belege, verschachtelte Felder Menü/Teilsumme/Summe); Trainings-Splits wurden nie ausgewertet. Jedes (Modell × Datensatz)-Paar verwendet dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Aufwärmdurchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte im stationären Zustand liegen). Alle 16 Läufe wurden mit error_rate 0.0 abgeschlossen (Spalte error_rate in summary_metrics.csv).

Laufzeitumgebung

• Hardware: alle GPU-Läufe auf einer NVIDIA RTX 4090 (24 GB); GPU-Kosten berechnet zum RunPod-On-Demand-Satz von $0.76/Std., mit Zeitstempel des Preises in jedem redigierten Manifest des Laufs (August 2026). Tesseract lief nur mit CPU und hat keine GPU-Kosten (leere Kostenzelle in der CSV).
• Engines: alle Modelle laufen out-of-the-box, ohne Fine-Tuning. Versionen gemäß den Lauf-Manifesten festgelegt.
• LLM-Nachbearbeitung: deepseek-v4-flash über API bei Temperatur 0 für deterministische Ausgabe (Spalte llm_model in field_method_comparison.csv); es war das einzige Modell, das für alle LLM-Feldzeilen verwendet wurde.
• Kostenbasis: Wanduhr-Laufzeit × $0.76/Std., einschließlich Modellinitialisierung — Stapelverarbeitung senkt die Kosten pro Seite.
• Feldnachbearbeitung: SROIE-Feldmetriken sind postprocessed_sroie_receipt_regex_* / LLM-Varianten — d. h. Felder, die aus OCR-Text durch einen festen Regex-Satz oder das LLM extrahiert werden. Sie messen OCR + nachgelagerte Extraktion, nicht native strukturierte Ausgabe der Modelle.

Versionen gemäß der Modelltabelle des Benchmarks (README.md) und den redigierten Manifests pro Lauf (results/manifests/, eines pro veröffentlichtem Lauf, insgesamt 16) — jedes Manifest erfasst Lauf-ID, Modellversion, Hash des Runner-Skripts, GPU/Treiber, torch/CUDA/Python-Versionen, pip-freeze-Hash, Kostenmetadaten mit Preiszeitstempel und Artefakt-Hashes für die Reproduzierbarkeit.

Metrikdefinitionen

• CER (Zeichenfehlerrate): 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.
• WER (Wortfehlerrate): dieselbe Editierdistanz-Berechnung auf Wortebene.
• Feldwert-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.
• Feldwert-F1 (LLM): dieselbe Metrik auf der Ausgabe des LLM-Nachbearbeiters (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie vermischt.
• Latenz p50/p95 & Seiten/min: Inferenzzeit pro Seite im stationären Zustand (nach Aufwärmphase 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.; leer für CPU-only Tesseract.

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 eine Zeile hier zurückführen.
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 lässt sich auf eine Zeile hier zurückführen.
3. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository mit den Ergebnis-CSVs, redigierten Lauf-Manifesten, eingefrorenem Protokoll und Datensatz-Stichprobenlisten (feste Test-Splits) zur Reproduktion.
4. results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf (16 Läufe) mit Umgebungs-Fingerprint, Modellversion, Kostenmetadaten 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). Dieser Benchmark misst nichts über Layout-, Tabellen- oder Formelverarbeitung, lange Dokumente oder Nicht-Belegfelder — die Dokumenttypen, bei denen Dokument-Parsing-VLMs ihre größten Vorteile beanspruchen, bleiben hier ungemessen. Verwenden Sie diese Seite nicht, um zu schlussfolgern, dass „traditionelle OCR überall besser ist".
• Stichprobengröße: 361 englische + 100 indonesische Belege. Feld-F1 und CER sind korpusabhängig; Unterschiede von wenigen Hundertsteln sollten als Rauschen und nicht als technische Wahrheit behandelt werden.
• Einzelne GPU-Stufe: Alle GPU-Zahlen stammen von einer RTX 4090 bei 0,76 $/Std. Andere GPUs, Multi-GPU-Serving oder Batch-Scheduling verschieben Latenz, Durchsatz und Kosten.
• CPU/GPU-Asymmetrie: Tesseract (CPU) wird mit GPU-beschleunigten Engines verglichen; seine Latenz/Zeit spiegelt CPU-Hardware wider, während sein Kostenvorteil die fehlende GPU-Abrechnung widerspiegelt. Dies ist auf jeder relevanten Tabelle markiert, aber die Asymmetrie ist dem Vergleich inhärent.
• LLM-Nachbearbeitung ist ein einzelnes Modell: Alle LLM-Feldzeilen verwenden deepseek-v4-flash. Ein anderes LLM würde andere absolute F1-Werte erzeugen; die Konvergenzreihenfolge kann an den Rändern abweichen. Die LLM-Latenz (~1,8–2,4 s Median, field_method_comparison.csv llm_median_latency_ms) entsteht über die API und ist nicht Teil der Latenz der OCR-Engine selbst.
• Kostenzeitstempel: Der GPU-Preis von 0,76 $/Std. wurde in den Lauf-Manifesten im August 2026 erfasst. Die Spot-/On-Demand-Preise für GPUs ändern sich; leiten Sie Kosten vor der Budgetierung zu aktuellen Tarifen neu ab.
• CORD-CER ist keine Qualitätsmessung: Die CORD-Grundwahrheit enthält Annotationsstrukturen, und die Engines wurden nicht auf Indonesisch trainiert. CORD-CER (0,90–1,08 über alle 8 Modelle) spiegelt Sprachmismatch + Inflation der Grundwahrheit wider, nicht die Lesequalität pro Modell; CORD-Zeilen werden absichtlich in kein SROIE-Ranking einbezogen.
• Regex-Abstimmung: Das Regex-Muster-Set wurde einmal pro Datensatz geschrieben. Eine anbieter-spezifische, stark abgestimmte Musterbibliothek könnte bei eigenen Formaten höhere Werte erzielen — zu den Wartungskosten, die das LLM eliminiert.
• Keine Cloud/API-Modelle: AWS Textract, Google Document AI, Azure AI Document Intelligence und gehostete VLM-APIs (z. B. Cloud-OCR-Dienste) sind nicht enthalten; ihre Latenz- und Preismodelle unterscheiden sich grundlegend von den hier gemessenen lokalen Engines.
• Versionsfixierung: Die Ergebnisse gelten für die oben aufgeführten Modellversionen vom August 2026; neuere Releases jeder Engine können Ergebnisse verschieben, und die p50-Latenzen der zwei Messungen mit großen p95-Spitzen (PaddleOCR, Docling) spiegeln Prefill-/Erstseiteneffekte unter diesem Batch-Muster wider.

Verwandte Verweise: die Grenzen von Regex für die Feldextraktion · Feld- und Zeichengenauigkeit im Vergleich · Beleg-OCR-Genauigkeit · OCR-Genauigkeitsdaten nach Dokumenttyp

Verwandte Lektüre: KI-OCR vs. klassische OCR-Genauigkeit · wie KI-Visions-Extraktion Bilder anders liest als OCR · KI-Dokument-Extraktion Preise (2026)