Zuletzt überprüft: 2026-08-18 · Ausführungsebene: offiziell · Erstanbieter-Benchmark · 8 Modelle × 2 Kassenbon-Datensätze

Geltungsbereich jeder Zahl auf dieser Seite: Kassenbons (SROIE 2019 Englisch, CORD v2 Indonesisch). Extrapolieren Sie diese Ergebnisse nicht auf Rechnungen, Tabellen oder komplexe Layouts — der Benchmark misst nur Kassenbon-OCR und Feldextraktion. Alle Zahlen stammen aus der Benchmark-Datei results/summary_metrics.csv und results/field_method_comparison.csv, die im öffentlichen GitHub-Repository gespiegelt und zeilenweise zitiert werden.

Dokument-parsende VLMs sind nicht von Natur aus besser als traditionelle OCR bei Kassenbons. Bei der rohen Zeichengenauigkeit (SROIE 2019) sind das beste VLM (Surya2, CER 0,191) und die beste traditionelle Engine (docTR, CER 0,197) statistisch gleichauf, während die traditionelle PaddleOCR mit 0,204 auf dem dritten Platz liegt. Die klaren Vorteile von VLMs — Layout, Tabellen, Formeln, lange Dokumente — zeigen sich einfach nicht bei einem einseitigen englischen Kassenbon. Was die Familien bei Kassenbons unterscheidet, ist der Betriebsbereich: Traditionelle Engines kosten und laufen viel weniger, und nach einem LLM-Nachbearbeitungsschritt konvergieren sechs von acht Engines in einen 0,57–0,62 Feld-F1-Bereich.

Der Trade-off in einer einzigen Zahlenreihe: docTR verarbeitet eine Seite mit 109 ms p50 für $0,048 pro 1.000 Seiten, während Surya2 2.668 ms p50 bei $1,061 pro 1.000 Seiten auf demselben RTX 4090, denselben Quittungen, derselben Testaufteilung benötigt — eine 24,5× Latenzlücke und eine 22× Kostenlücke. Welche Familie „gewinnt", hängt entirely davon ab, welche Achse im Vordergrund steht; der Zweck dieser Seite ist es, beide Achsen aus demselben kontrollierten Durchlauf zu zeigen.

Die Zeichenfehlerrate (CER) misst, welcher Anteil einzelner Zeichen falsch gelesen wird — Löschungen, Einfügungen und Ersetzungen geteilt durch die Zeichen der Referenz. Sie ist der klassische OCR-Maßstab, und hier bricht die Erzählung von der „Überlegenheit der VLM" bei englischen Quittungen zusammen.

Bei SROIE 2019 sind die beiden besten Texterkennungsmodelle ein VLM und eine traditionelle Engine, getrennt nur durch 0,006 Punkte: Surya2 mit 0,191 und docTR mit 0,197, PaddleOCR auf dem dritten Platz (0,204). Die drei weiteren VLM — PaddleOCR-VL 0,337, Docling 0,591, Unlimited-OCR 0,655 — liegen auf oder unter dem Niveau traditioneller Engines wie EasyOCR (0,283) und Tesseract (0,335).

Zeichengenauigkeit nach Modell auf SROIE (Englische Quittungen)

Quelle: summary_metrics.csv — Spalte cer, sroie_2019-Zeilen (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 CPU.

Modell	Familie	CER	WER	Quelle
Surya2	Dokument-Parsing-VLM	0.191	0.274	summary_metrics.csv · surya2/sroie_2019 row
docTR	Traditionelle OCR	0.197	0.320	summary_metrics.csv · doctr/sroie_2019 row
PaddleOCR	Traditionelle OCR	0.204	0.326	summary_metrics.csv · paddleocr/sroie_2019 row
EasyOCR	Traditionelle OCR	0.283	0.616	summary_metrics.csv · easyocr/sroie_2019 row
Tesseract	Traditionelle OCR (CPU)	0.335	0.559	summary_metrics.csv · tesseract/sroie_2019 row
PaddleOCR-VL	Dokument-Parsing-VLM	0.337	0.646	summary_metrics.csv · paddleocr_vl_vllm/sroie_2019 row
Docling	Pipeline-Parser	0.591	0.760	summary_metrics.csv · docling/sroie_2019 row
Unlimited-OCR	Dokument-Parsing-VLM	0.655	0.478	summary_metrics.csv · unlimited_ocr/sroie_2019 row

Tabelle: summary_metrics.csv — CER- und WER-Spalten, sroie_2019-Zeilen, jeweils 361 Stichproben (Fehlerrate 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 zeigt dasselbe Bild mit anderer Granularität: Sie bewertet Fehler ganzer Wörter statt einzelner Zeichen. 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 in Groß-/Kleinschreibung und Format normalisiert (eine Ausgabekonvention, die im Methodenabschnitt erläutert wird), was Zeicheneingriffe aufbläht, selbst wenn die Wörter weitgehend intakt sind.

Docling verdient eine Klassifizierung, bevor es in Vergleichen erscheint: Es ist weder ein reiner traditioneller OCR-Engine noch ein VLM. Docling ist ein Pipeline-Parser — eine gestufte Werkzeugkette, die Layout-Analyse, Tabellenerkennung und Lesereihen-Rekonstruktion um einen OCR-Kern herum ausführt. Bei einem einfachen Beleg bringt dieser Pipeline-Overhead wenig, was ein Grund dafür ist, warum seine rohe CER (0,591 auf SROIE) hinter den Single-Pass-Engines zurückbleibt.

Kosten und Latenz: Der Vorteil traditioneller Engines

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

Die Kosten werden berechnet als Laufzeit in Echtzeit × der RunPod RTX 4090-Preis ($0,76/Stunde, Preis-Stempel in den Ausführungs-Manifesten) — der Preis, den man tatsächlich für die GPU-Zeit zahlt, einschließlich Modellinitialisierung. Tesseract ist der Sonderfall: nur CPU, es hat überhaupt keine GPU-Kosten und schafft dennoch 78,6 Seiten/min auf SROIE; seine Kostenzelle ist in der CSV absichtlich leer, nicht weil es kostenlos ist, sondern weil es keine abgerechneten GPU-Stunden verbraucht.

Quelle: summary_metrics.csv — Spalte latency_p50_ms, sroie_2019-Zeilen. 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 stabilen Zustand, Messmodus Warm-up-then-Scored (schließt Modellladen aus).

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, sroie_2019-Zeilen. 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 Modellinitialisierung, nicht reinen Durchsatz im stabilen Zustand.

Modell	Familie	Latenz p50 (ms)	Latenz p95 (ms)	Seiten/min	Kosten / 1.000 Seiten	Quelle
docTR	Traditionelle OCR	108,7	281,4	449,3	$0,048	summary_metrics.csv · doctr/sroie_2019 row
PaddleOCR	Traditionelle OCR	297,0	3.331,4	79,7	$0,221	summary_metrics.csv · paddleocr/sroie_2019 row
EasyOCR	Traditionelle OCR	413,6	960,4	124,5	$0,110	summary_metrics.csv · easyocr/sroie_2019 row
Tesseract	Traditionelle OCR (CPU)	670,9	1.507,0	78,6	n/a (CPU)	summary_metrics.csv · tesseract/sroie_2019 row
PaddleOCR-VL	Dokument-Parsing-VLM	694,3	1.154,3	68,2	$0,205	summary_metrics.csv · paddleocr_vl_vllm/sroie_2019 row
Docling	Pipeline-Parser	732,0	3.239,8	56,7	$0,398	summary_metrics.csv · docling/sroie_2019 row
Unlimited-OCR	Dokument-Parsing-VLM	1.600,7	2.521,9	34,4	$0,388	summary_metrics.csv · unlimited_ocr/sroie_2019 row
Surya2	Dokument-Parsing-VLM	2.668,0	5.872,2	12,1	$1,061	summary_metrics.csv · surya2/sroie_2019 row

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

Die Spalte für die Spitzenlatenz ist wichtig, wenn das Worst-Case-Verhalten und nicht nur der Median interessiert. PaddleOCRs p95 von 3.331 ms und Doclings 3.240 ms liegen weit von ihren p50-Werten entfernt — Erste-Seiten-Effekte und Prefill-Spitzen dominieren die Spitze bei GPU-Engines —, während docTRs p95 (281 ms) eng bleibt. Für interaktive Workloads (ein Benutzer wartet auf eine Seite) ist dieser p95-Spread der Unterschied zwischen einer 0,3-Sekunden-Wartezeit und einer Wartezeit von über 3 Sekunden.

CORD (Indonesische Quittungen): Sprachinkongruenz und Aufblähung des Ground-Truth

CORD v2 ist ein indonesischsprachiges Quittungs-Dataset mit verschachtelten Feldern (menu, sub_total, total). Keines der 8 Engines wurde überwiegend auf indonesischen Quittungen trainiert, sodass CORD als sprachübergreifender Stresstest fungiert — und die CER jedes Engines bricht auf 0,90–1,08 ein. Diese Zahlen sind mit dem Vorbehalt zu lesen, dass der Ground-Truth-Text von CORD die Annotationsstruktur einbettet, was die Roh-CER jedes Engines aufbläht; CORD-Ergebnisse werden streng von der SROIE-Rangliste getrennt und sind nicht zu einem einzigen Leaderboard zusammenführbar.

Zwei unterschiedliche Kräfte treiben die CORD-CER in Richtung 1,0, und nur eine davon ist die Sprache selbst. Erstens die Sprache: 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: Die veröffentlichten Textannotationen von CORD betten die Annotationsstruktur (Feldbezeichnungen mit Koordinaten) ein und nicht rein sichtbaren Text, sodass die Roh-CER die Editierdistanz zu einem strukturell angereicherten String misst. Die saubersten VLM-Beispiele werden am härtesten bestraft — PaddleOCR-VL mit einer CER von 1,080 ist das extreme Artefakt dieses Mechanismus und keine Lesung seiner Textqualität.

Der faire vergleichende Test über Familien hinweg auf CORD ist daher die Feldmetrik, nicht die CER (siehe nächsten Abschnitt). Was die CER-Spalten dennoch nützlich zeigen, ist, dass die Sprachinkongruenz real und universell über Architekturen hinweg ist — jede Familie, traditionell und VLM gleichermaßen, landet im selben Bereich von 0,90–1,08, ohne strukturellen Vorteil für eine der Seiten.

Modell	Familie	CORD CER	Quelle
Surya2	Dokument-Parsing-VLM	0.896	summary_metrics.csv · surya2/cord_v2 row
PaddleOCR	Traditionelle OCR	0.908	summary_metrics.csv · paddleocr/cord_v2 row
docTR	Traditionelle OCR	0.910	summary_metrics.csv · doctr/cord_v2 row
EasyOCR	Traditionelle OCR	0.918	summary_metrics.csv · easyocr/cord_v2 row
Docling	Pipeline-Parser	0.922	summary_metrics.csv · docling/cord_v2 row
Unlimited-OCR	Dokument-Parsing-VLM	0.922	summary_metrics.csv · unlimited_ocr/cord_v2 row
Tesseract	Traditionelle OCR (CPU)	0.952	summary_metrics.csv · tesseract/cord_v2 row
PaddleOCR-VL	Dokument-Parsing-VLM	1.080	summary_metrics.csv · paddleocr_vl_vllm/cord_v2 row

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

Feld-F1: LLM-Nachbearbeitung gleicht die Felder an

Die Zeichengenauigkeit ordnet die Engines; die Feldextraktion ist das, wofür Produktionsanwender tatsächlich bezahlen. Der Benchmark extrahiert vier Belegfelder (Unternehmen, Datum, Adresse, Gesamtbetrag) aus dem OCR-Text jeder Engine mit zwei Nachbearbeitern — festen Regex-Mustern (der traditionelle OCR- + regelbasierte KIE-Ansatz) und einem LLM (deepseek-v4-flash) mit einem strukturierten Prompt. Das Ergebnis: Das LLM löscht den Engine-Unterschied bei SROIE fast aus und zieht sechs von acht Engines in eine 0,57–0,62 Feld-F1-Bandbreite — während ihre Regex-Ergebnisse über einen Bereich von 0,26 Punkten verteilt waren.

Der Feldwert-F1 ist der harmonische Mittelwert von Präzision und Recall über extrahierte Feldwerte, bewertet gegen den Ground Truth — 1,0 bedeutet, jeder Feldwert wurde perfekt extrahiert, 0 bedeutet, nichts wurde wiedergefunden. Die Regex-Spalten verwenden ein festes Mustersatz pro Datensatz; die LLM-Spalten verwenden deepseek-v4-flash bei Temperatur 0 für deterministische Ausgabe (die Spalte llm_model im Vergleichs-CSV). Die beiden Metriken messen verschiedene Pipelines und werden nie gemischt.

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

Modell	Familie	Regex-Feld-F1 (SROIE)	LLM-Feld-F1 (SROIE)	Quelle
docTR	Traditionelle OCR	0.077	0.617	field_method_comparison.csv · doctr/sroie_2019 row
Surya2	Dokument-Parsing-VLM	0.318	0.614	field_method_comparison.csv · surya2/sroie_2019 row
Unlimited-OCR	Dokument-Parsing-VLM	0.338	0.605	field_method_comparison.csv · unlimited_ocr/sroie_2019 row
PaddleOCR-VL	Dokument-Parsing-VLM	0.337	0.592	field_method_comparison.csv · paddleocr_vl_vllm/sroie_2019 row
PaddleOCR	Traditionelle OCR	0.325	0.581	field_method_comparison.csv · paddleocr/sroie_2019 row
Docling	Pipeline-Parser	0.224	0.569	field_method_comparison.csv · docling/sroie_2019 row
Tesseract	Traditionelle OCR (CPU)	0.233	0.439	field_method_comparison.csv · tesseract/sroie_2019 row
EasyOCR	Traditionelle OCR	0.148	0.372	field_method_comparison.csv · easyocr/sroie_2019 row

Tabelle: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1, sroie_2019 rows. LLM = deepseek-v4-flash Nachbearbeitung (llm_model column). docTR regex 0.0766 → LLM 0.6171 (8,1× Steigerung); die 6 leistungsstärkeren Engine decken 0.5685–0.6171 ab.

Zwei kontraintuitive Ergebnisse finden sich in dieser Tabelle. Erstens: docTR hat den schlechtesten Regex-Feld-F1 auf SROIE (0.077) und den besten LLM-Feld-F1 (0.617) — derselbe saubere OCR-Text, den Regex in 7,7 % der Felder extrahieren konnte, ergab 61,7 % unter dem LLM. Der Engpass war die Nachbearbeitung, nicht die OCR. Zweitens: Die beiden Engines, die außerhalb des 0,57–0,62-Bands liegen, sind genau die mit einer beeinträchtigten 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 er grundsätzlich nicht lesen kann (CORD CER 0.9523). Die Obergrenze jeder Nachbearbeitung ist die OCR-Basisqualität darunter.

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

Warum CER Dokument-Parsing-VLMs unterschätzt

CER vergibt VLM-Ausgabe und Ground Truth zeichenweise, und VLMs werden für zwei legitimize Verhaltensweisen bestraft, die keine Erkennungsfehler sind: Fallnormalisierung und Verschmelzung von Label und Wert. Die CER-Zerlegung des Benchmarks auf SROIE schreibt etwa 18% des VLM-CER auf Fallformat-Unterschiede (z. B. TAN CHAY YEE → tan chay yee) und etwa 10% auf Zeilenverschmelzung oder weggelassene Trennzeilen — wobei die Feldwerte selbst (Unternehmen, Gesamtbetrag, Datum) tatsächlich korrekt sind (CER-Zerlegungsanalyse im Protokollnotizen des Benchmarks, SROIE-Läufe).

Das Design-Dilemma ist real und strukturell: Traditionelle OCR-Engines geben roten Text mit erhaltener Groß-/Kleinschreibung aus und sind daher für die CER-Bewertung optimiert; Dokument-Parsing-VLMs geben „verstandenen" Text aus (normalisierte Groß-/Kleinschreibung, verschmolzene Label-Wert-Paare, umgeordnete Zeilen), was näher an dem liegt, was ein nachgelagertes System benötigt, aber weiter von exakten Zeichenübereinstimmungen entfernt ist. Deshalb verwendet die Seite CER nur dort, wo es ein fairer Vergleich unter ähnlichen Ausgaben ist, und deshalb liegt der faire Vergleich zwischen den Familien in den Feldmetriken — und deshalb wird der CER von CORD (der zusätzlich eine Aufblähung durch die Annotationsstruktur aufweist) in einen eigenen Abschnitt ausgelagert. Der weiterführende Punkt: Ein CER-Unterschied zwischen Familien ist nicht automatisch ein Genauigkeitsunterschied, und jeder, der Modelle über Familien hinweg vergleicht, sollte prüfen, was der CER misst, bevor er schlussfolgert, dass eine Familie „besser liest."

Auswahl: Welche Achse ist für Ihre Arbeitslast entscheidend?

„Besser" ist ohne Arbeitslast sinnlos. Das ehrliche Ergebnis des Benchmarks ist, dass die beiden Familien auf verschiedenen Achsen gewinnen, und Quittungen messen speziell die Achsen, auf denen traditionelle Engines gewinnen, und die Achsen, auf denen die Nachbearbeitung — nicht die Engine-Familie — die Feldqualität bestimmt.

Entscheiden Sie, was Ihre Pipeline verarbeitet: Rohtext oder Felder. Wenn ein Mensch den Text liest (Suche, Anzeige, Prüfung), ist CER/WER die ehrliche Metrik — und traditionelle Engines gewinnen oder sind gleichauf (SROIE CER: docTR 0.197 vs Surya2 0.191, summary_metrics.csv sroie_2019 rows). Wenn ein nachgelagertes System Felder verarbeitet, entscheidet der Nachprozessor mehr als die Engine: mit regex variiert der Feld-F1 zwischen 0,077 und 0,338; mit einem LLM passen sechs Engines in den Bereich 0,569 bis 0,617 (field_method_comparison.csv sroie_2019 rows).
Bei hohem Volumen und realen Kosten: Konzipieren Sie um die traditionelle Expressspur. docTR verarbeitete 449 Seiten/min für $0,048 pro 1.000 Seiten (summary_metrics.csv doctr/sroie_2019: pages_per_minute 449.3, cost_per_1000_pages 0,0479). Tesseract hat null GPU-Kosten (nur CPU) bei 78,6 Seiten/min. Eine VLM-basierte Quittungslinie mit Surya2 kostet bei $1,061 pro 1.000 Seiten etwa 22× mehr pro Seite bei gleicher Hardware.
Wenn Felder wichtiger sind als Bytes: Fügen Sie LLM-Nachbearbeitung hinzu, anstatt die Engine zu wechseln. Die größte Einzelverbesserung im Benchmark war der SROIE-Feld-F1 von docTR — von 0,077 (regex) auf 0,617 (deepseek-v4-flash), ein 8,1-facher Anstieg bei gleichem OCR-Text (field_method_comparison.csv doctr/sroie_2019 row). Der LLM-Aufruf fügt ~1,8 bis 2,4 s Median pro Dokument hinzu (field_method_comparison.csv llm_median_latency_ms, alle 16 rows) — geeignet für asynchrone Stapelverarbeitung, nicht für synchrone Benutzerwartezeiten pro Seite.
Budgetieren Sie für die Obergrenze, die Ihr OCR setzt. EasyOCR und Tesseract fallen außerhalb des LLM-Konvergenzbands, weil ihr Basistext schwächer ist; Tesseract auf CORD (LLM-Feld-F1 0,163 bei CER 0,9523) ist der harte Beweis, dass kein Nachprozessor unlesbaren Text repariert.
Validieren Sie anhand Ihrer eigenen Dokumente, bevor Sie sich festlegen. Diese Zahlen stammen von einer GPU-Stufe (RTX 4090), zwei Quittungsdatensätzen und August-2026-Modellversionen. Jede Architekturentcheidung sollte auf Ihrem eigenen Korpus erneut ausgeführt werden — der Artefakt-Satz, der diese Seite erstellt hat, existiert genau dafür.

Die Auswahlhilfe leitet sich direkt aus den zitierten CSV-Zeilen ab; sie ist ein datengestütztes Lesehilfsmittel, keine Hersteller-Empfehlung. Ihre genauen Ergebnisse variieren je nach Hardware, Dokumentenmix und Modellversionen.

Häufig gestellte Fragen

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

Nicht bei der reinen 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 dem dritten Platz. Wenn die Feldextraktion das Ziel ist, ist 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?

Bei hohem Volumen, nach Verbrauch abgerechneten Kosten oder interaktiver Latenz. 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). Für eine interaktive Wartezeit pro Seite beträgt der Unterschied 0,1 Sekunden vs. 2,7 Sekunden.

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

Weil CER exakte Zeichenübereinstimmungen bewertet und VLMs für Groß-/Kleinschreibungskorrekturen und das Zusammenführen von Bezeichnung/Wert bestraft werden, was Ausgabekonventionen sind, keine Fehlleistungen. Die CER-Zerlegung des Benchmarks bei SROIE ordnet etwa 18% des VLM-CER auf Groß-/Kleinschreibungsunterschiede und ~10% auf Zeilenzusammenführung/fehlende Trennzeichen zu — wobei die Feldwerte selbst oft korrekt sind (siehe Methodik). Der CER von CORD wird zusätzlich durch die Annotationsstruktur in seinen Ground-Truth-Daten aufgebläht, weshalb diese Seite den CER von CORD von jeder Rangliste ausschließt und Feldmetriken für den Vergleich zwischen Familien verwendet.

Was 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/Stunde, Preis-Stempel August 2026 in den Run-Manifesten (summary_metrics.csv cost_per_1000_pages, SROIE-2019-Zeilen). Tesseract ist nur CPU-basiert und verbraucht keine GPU-Stunden. Die Kosten beinhalten die Modellinitialisierung, sodass die Kosten pro Seite mit steigender Stapelgröße sinken.

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

Zwei sich verstärkende Ursachen: eine echte Sprachdiskrepanz (indonesische Belege außerhalb des Trainingsfokus jeder Engine) und eine Aufblähung der Annotationsstruktur im Referenztext von CORD. Keine Modellfamilie entgeht diesem — alle 8 Modelle landen im Bereich von 0,90–1,08 (summary_metrics.csv cer, cord_v2-Zeilen). CORD ist ein Stress-Test für Sprach-/Layout-Robustheit, der getrennt von der SROIE-Rangliste gehalten wird.

Korrigiert ein LLM einfach meine schlechte OCR-Ausgabe?

Nur bis zur Qualität des Basistextes. Auf SROIE brachte das LLM sechs Engines in einen Bereich von 0,57–0,62 Feld-F1, unabhängig von der Engine (field_method_comparison.csv), aber der CORD-Fall von Tesseract zeigt die Untergrenze: Bei einem CER von 0,9523 liegt sein LLM-Feld-F1 bei 0,163 — ein LLM kann keine Felder aus Text extrahieren, den er nicht lesen kann.

Welches ist die schnellste OCR für Belege?

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

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 geschwärzten manifest.json pro Run für Umgebungsfingerabdrücke. Die Datensatzdefinitionen stammen aus den unten zitierten Arbeiten zu SROIE 2019 und CORD.

Methodik & Quellen

Protokoll

Diese Seite berichtet den Vergleich des Dokument-Parsing eines unabhängigen, reproduzierbaren Benchmarks (offizielle Stufe) — keine Umfrage von Drittanbieter-Aussagen. Nur feste Test-Splits: SROIE 2019 test (361 englische Quittungen, flache Felder Unternehmen/Datum/Adresse/Gesamtbetrag) und CORD v2 test (100 indonesische Quittungen, verschachtelte Felder Menü/Teilsumme/Gesamtbetrag); Trainings-Splits wurden nie ausgewertet. Jedes (Modell × Datensatz)-Paar verwendet dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte im steady-state 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-Tarif von $0.76/Stunde, mit dem Preism-Zeitstempel im jeweiligen redactierten Manifest (August 2026). Tesseract lief nur auf CPU und hat keine GPU-Kosten (leere Kostenzelle in der CSV).
Engines: alle Modelle laufen out-of-the-box, kein Feintuning. Versionen laut den Lauf-Manifesten fixiert.
LLM-Nachbearbeiter: 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.
Kostenbasis: Echtzeitlaufzeit × $0.76/Stunde, inklusive Modellinitialisierung — Batch-Verarbeitung senkt die Kosten pro Seite.
Feld-Nachbearbeitung: SROIE-Feldmetriken sind postprocessed_sroie_receipt_regex_* / LLM-Varianten — d.h. Felder, die aus dem OCR-Text durch einen festen Regex-Satz oder das LLM extrahiert wurden. Sie messen OCR + nachgelagerte Extraktion, nicht die native strukturierte Ausgabe der Modelle.

Modell	Version	Typ / Backend
Tesseract	5.3.4	Traditionelle OCR — CPU (keine GPU-Kosten)
PaddleOCR	3.7.0	Traditionelle OCR — GPU
EasyOCR	1.7.2	Traditionelle OCR — GPU
docTR	v1.0.1	Traditionelle OCR — GPU
Docling	2.119.0	Pipeline-Parser (Layout + Tabelle + Lesereihenfolge) — GPU
Surya2	0.22.1	Dokument-Parsing-VLM — vLLM-bereitgestellt
Unlimited-OCR	vLLM-bereitgestellt	Dokument-Parsing-VLM — vLLM-bereitgestellt
PaddleOCR-VL	1.6	Dokument-Parsing-VLM — vLLM-bereitgestellt

Versionen wie in der Modelltabelle des Benchmarks (README.md) und den jeweiligen redactierten Manifesten (results/manifests/, eines pro veröffentlichtem Lauf, 16 insgesamt) aufgezeichnet — jedes Manifest enthält Lauf-ID, Modellversion, Hash des Runner-Skripts, GPU/Treiber-, torch/CUDA/Python-Versionen, pip-freeze-Hash, Kostenmetadaten mit Preism-Zeitstempel und Artefakt-Hashes zur Reproduzierbarkeit.

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.
WER (Word Error Rate): dieselbe Editierdistanz-Berechnung auf Wortebene.
Feldwert-F1 (regex): harmonisches Mittel aus Precision und Recall über extrahierte Feldwerte unter Verwendung fester Regex-Muster auf dem OCR-Text (traditionelle OCR + regelbasierte KIE-Pipeline). Spalte: regex_field_value_f1.
Feldwert-F1 (LLM): dieselbe Metrik für die Ausgabe des LLM-Nachbearbeiters (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie kombiniert.
Latenz p50/p95 & Seiten/min: stationäre Inferenzzeit pro Seite (warm-then-scored, Modell-Laden ausgeschlossen) und Echtzeit-Durchsatz inklusive Modellinitialisierung.
Kosten pro 1.000 Seiten: abgerechnete GPU-Stunden für 1.000 Seiten zum erfassten Satz von $0,76/Stunde; leer für CPU-only Tesseract.

Quellenverzeichnis

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 Durchschnittszahl auf dieser Seite lässt sich auf eine Zeile hier zurückführen.
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-Zahlen. Jede regex/LLM-Feld-F1-Zahl lässt sich auf eine Zeile hier zurückführen.
ImageToTableai/benchmark-ocr Repository. Öffentliches Repo mit den Ergebnis-CSVs, geschwärzten Run-Manifests, eingefrorenem Protokoll und Datensatz-Beispiellisten (feste Testsplits) zur Reproduktion.
results/manifests/ (GitHub). Ein geschwärztes manifest.json pro veröffentlichtem Run (16 Runs) mit dem Umgebungsfingerabdruck, der Modellversion, Kosten-Metadaten und Artefakt-Hashes.
Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). SROIE 2019 Datensatzdefinition, Aufgabenstruktur und Lizenz (CC-BY-4.0).
Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). CORD v2 Datensatzdefinition, verschachteltes Feldaufbauschema und Lizenz (CC-BY-4.0).

Einschränkungen

Dokumentumfang: Nur Quittungen (SROIE + CORD). Dieses Benchmark misst nichts über Layout-/Tabellen-/Formelverarbeitung, lange Dokumente oder Nicht-Quittungsfelder — die Dokumenttypen, in denen Dokument-Parsing-VLMs ihre größten Vorteile behaupten, bleiben hier ungemessen. Verwenden Sie diese Seite nicht, um zu dem Schluss zu kommen, dass „traditionelle OCR überall besser ist“.
Stichprobengröße: 361 englische + 100 indonesische Quittungen. Feld-F1 und CER sind korpusabhängig; einstellige Unterschiede von einigen Hundertsteln sollten als Rauschen und nicht als ingenieurtechnische Wahrheit behandelt werden.
Einzelne GPU-Stufe: Alle GPU-Zahlen stammen von einer RTX 4090 mit $0,76/Stunde. Andere GPUs, Multi-GPU-Bedienung oder Batch-Planung 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 in jeder relevanten Tabelle vermerkt, aber die Asymmetrie ist dem Vergleich inhärent.
LLM-Nachbearbeiter ist ein einzelnes Modell: Alle LLM-Felder verwenden deepseek-v4-flash. Ein anderes LLM würde absolute F1-Werte erzeugen, die sich unterscheiden; die Konvergenzreihenfolge könnte an den Rändern abweichen. Die LLM-Latenz (~1,8–2,4 s Median, llm_median_latency_ms in field_method_comparison.csv) wird durch die API verursacht und ist kein Teil der Latenz der OCR-Engine selbst.
Kosten-Zeitstempel: Der GPU-Preis von $0,76/Stunde wurde in den Ausführungsmanifesten im August 2026 erfasst. GPU-Spot-/On-Demand-Preise ändern sich; leiten Sie die Kosten vor der Budgetierung mit aktuellen Raten ab.
CORD CER ist keine Qualitätsmessung: CORD Ground Truth enthält Annotationstrukturen und die Engines wurden nicht auf Indonesisch trainiert. CORD CER (0,90–1,08 über alle 8 Modelle) spiegelt Sprachinkongruenz + Ground-Truth-Inflation wider, nicht die Lesepro Qualität pro Modell; CORD-Zeilen werden absichtlich in kein SROIE-Ranking einbezogen.
Regex-Abstimmung: Das Regex-Muster-Set wurde einmal pro Datensatz geschrieben. Eine pro Anbieter, stark abgestimmte Musterbibliothek könnte bei eigenen Formaten höhere Werte erzielen — auf Kosten der Wartung, 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 Versionen einer Engine können die Ergebnisse verschieben, und die p50-Latenzen der beiden Messungen mit großen p95-Spitzen (PaddleOCR, Docling) spiegeln Prefill-/Erste-Seite-Effekte unter dem Batch-Muster dieses Durchlaufs wider.

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