EasyOCR vs docTR bei Quittungen
Geschwindigkeitschampion vs. Feldextraktor (2026)
Zuletzt überprüft: 2026-08-18 · Ausführungsstufe: offiziell · Erstparteiischer Head-to-Head-Benchmark · 2 Engines × 2 Quittungs-Datensätze
Was diese Seite NICHT behandelt: Jeden Dokumenttyp außer Quittungen — keine Tabellen, Formulare, Rechnungen, Verträge oder lange Dokumente. Cloud-/API-OCR-Dienste, feinabgestimmte Engines und die anderen sechs Engines des Benchmarks (Tesseract, PaddleOCR, Docling, Surya2, Unlimited-OCR, PaddleOCR-VL) sind außerhalb des Geltungsbereichs, außer sie werden als Ranking-Kontext zitiert. Die vollständige 8-Engine-Übersicht findet sich unter Traditionelles OCR vs. Document Parsing VLMs.
Geltungsbereich: Jede Zahl auf dieser Seite gilt nur für Quittungen — SROIE 2019 englische Quittungen und CORD v2 indonesische Quittungen. Eine Hardware-Stufe (RTX 4090 für $0.76/Stunde, Preisstempel August 2026), ein LLM-Nachbearbeiter (deepseek-v4-flash bei Temperatur 0), feste Modellversionen (EasyOCR 1.7.2, docTR v1.0.1). Extrapolieren Sie diese Ergebnisse nicht auf andere Dokumenttypen, GPUs oder LLMs — der Benchmark misst nur Quittungs-OCR und Quittungs-Feldextraktion. Alle Zahlen stammen aus der results/summary_metrics.csv und results/field_method_comparison.csv des Benchmarks, die im öffentlichen GitHub-Repository gespiegelt und zeilenweise zitiert werden.
Bei sauberen englischen Quittungen gewinnt die moderne Architektur deutlich bei der reinen Textqualität: docTRs SROIE CER 0.1971 gegenüber EasyOCRs 0.2833 (30% niedriger), WER 0.3199 gegenüber 0.6158 (48% niedriger). Führt man jedoch den Text beider Engines durch dieselben festen Regex-Muster, kehrt sich die Rangfolge um: EasyOCR extrahiert Felder mit 1,93× der Rate (0,1477 gegenüber 0,0766 Feld-F1) — die „Textgenauigkeit ≠ Feldgenauigkeit“-Umkehrung des Benchmarks, nun zwischen zwei traditionellen Engines. Fügt man einen LLM-Nachbearbeiter hinzu, kehrt sich die Umkehrung wieder entscheidend um: docTR 0,6171 (bester aller 8 Engines) gegenüber EasyOCR 0,3717 (schlechtester aller 8) — eine 1,66-fache Lücke und eine der größten LLM-Feld-F1-Differenzen im Benchmark. Das Einsatzspektrum gehört komplett docTR: 3,8× schnelleres p50 (108,7 gegenüber 413,6 ms), 3,6× höhere Durchsatzrate (449,3 gegenüber 124,5 Seiten/min), 2,3× günstiger ($0,048 gegenüber $0,110 pro 1.000 Seiten) — die schnellste und günstigste Engine des Benchmarks gleichzeitig in beiden Achsen.
Der Kompromiss in einem Zahlenpaar: docTR liest eine Quittungsseite mit 108,7 ms p50 für $0,048 pro 1.000 Seiten und extrahiert über einen LLM-Nachbearbeiter Felder mit 0,6171 F1; EasyOCR liest sie mit 413,6 ms p50 für $0,110 pro 1.000 Seiten und sein LLM-abgeleiteter Feld-F1-Wert bricht auf 0,3717 ein — der schlechteste Wert aller acht getesteten Engines. Gleiche Quittungen, gleicher Testsplit, gleiche RTX 4090. Keine Engine „gewinnt"; EasyOCR behält den Regex-Feld-Vorteil und das Deployment-Argument, während docTR jede hier gemessene Genauigkeits-, Geschwindigkeits- und Kostenachse gewinnt.
Die beiden Engines repräsentieren zwei Generationen von Deep-Learning-OCR und liegen beide auf der traditionellen Seite der OCR-gegenüber-VLM-Teilung. EasyOCR (PyTorch-basiert, 1.7.2) ist ein klassischer Ein-Pass-CNN + RNN + CTC-Erkennungsmodell — ein ResNet-Feature-Extraktor, der ein Sequenzmodell speist, das mit Connectionist Temporal Classification decodiert wird, mit aufmerksamkeitsbasierter Verfeinerung. Sein Design-Schwerpunkt ist eine sehr breite Sprach- und Schriftabdeckung (80+ Sprachen out of the box) und ein berühmt einfaches Setup. docTR (v1.0.1) ist eine moderne Zweistufen-neuronale Pipeline: Eine Erkennungsstufe lokalisiert Textbereiche, dann transkribiert eine Erkennungsstufe diese — basierend auf DETR-Transformer-Erkennung und einem Transformer-Erkennungsmodell, entwickelt für Genauigkeit bei gedruckten Dokumenten. Die Character Error Rate (CER) misst Einfügungen, Löschungen und Ersetzungen geteilt durch die Zeichen der Referenz — eine CER von 0,197 bedeutet ~19,7 falsch gelesene Zeichen pro 100; die Word Error Rate (WER) wendet dieselbe Edit-Distance-Logik auf ganzer Wortebene an. Beide Werte sind umso besser, je niedriger sie sind. Keine der Engines ist ein Vision-Language-Modell (VLM) — beide geben rohen Text aus, keine verstandene Struktur.
Textgenauigkeit bei SROIE (Englische Quittungen): Klare Überlegenheit von docTR
Bei den 361 englischen Quittungen des SROIE 2019-Testsiegs gewinnt die moderne Architektur bei beiden Textmetriken: CER 0,1971 gegenüber 0,2833 (30% relative Verbesserung) und WER 0,3199 gegenüber 0,6158 — EasyOCRs WER ist nahezu doppelt so hoch. Die WER-Lücke (48%) ist viel größer als die CER-Lücke (30%), was darauf hindeutet, dass EasyOCR Zeichenfehler in diesem Korpus zu ganzen Wortfehlern kumuliert. Beide Engines laufen fehlerfrei (error_rate 0,0 in jeder SROIE- und CORD-Zeile in der CSV). Keine der Engines ist der Gesamt-CER-Champion des Benchmarks — dieser Titel gehört Surya2 (0,1915), und docTR selbst Platz zwei; EasyOCR rangiert auf Platz vier von acht.
Quelle: summary_metrics.csv — cer- und wer-Spalten, sroie_2019-Zeilen. docTR cer 0,19707 / wer 0,31990; EasyOCR cer 0,28327 / wer 0,61578. Niedriger ist besser. 361 Stichproben pro Engine; beide error_rate 0,0.
| Metrik (SROIE 2019, n=361) | docTR | EasyOCR | Quelle |
|---|---|---|---|
| Character Error Rate (CER) | 0,1971 | 0,2833 | summary_metrics.csv · cer, doctr/sroie_2019 und easyocr/sroie_2019 Zeilen |
| Word Error Rate (WER) | 0,3199 | 0,6158 | summary_metrics.csv · wer, gleiche Zeilen |
| Fehlerrate (fehlgeschlagene Seiten) | 0,0 | 0,0 | summary_metrics.csv · error_rate, gleiche Zeilen |
Tabelle: summary_metrics.csv — Spalten cer / wer / error_rate, Zeilen sroie_2019. Exakte Werte: docTR cer 0.19707 / wer 0.31990; EasyOCR cer 0.28327 / wer 0.61578. Relative Unterschiede: CER 30% niedriger, WER 48% niedriger für docTR. Niedrigerer CER/WER ist besser. CER-Ranking-Kontext innerhalb desselben 8-Engine-Runs: Surya2 0.1915, docTR 0.1971, PaddleOCR 0.2045, EasyOCR 0.2833 (summary_metrics.csv, cer, sroie_2019-Zeilen).
Die Regex-Feld-Inversion: Schlechterer Text, mehr wiederherstellbare Felder
Benchmarken Sie den Rohtext beider Engines mit denselben festen Regex-Mustern für die vier SROIE-Belegfelder (Unternehmen, Datum, Adresse, Gesamtbetrag) — der traditionelle OCR- + regelbasierte Key-Information-Extraction (KIE) Ansatz — und das Ranking kehrt sich um: EasyOCR extrahiert Felder mit 0.1477 Feld-F1 gegenüber docTRs 0.0766, ein 1,93×-Vorteil für die Engine mit der schlechteren Zeichengenauigkeit. Dies ist die wiederkehrende „Textgenauigkeit ≠ Feldgenauigkeit“-Inversion des Benchmarks — dasselbe Muster, das zwischen traditioneller OCR und dokumentenparsenden VLMs bei docTR vs Surya2 beobachtet wurde — tritt nun zwischen zwei traditionellen Engines auf, die dieselbe Art von Rohzeilentext ausgeben.
Feld-Wert-F1 ist der harmonische Mittelwert von Precision und Recall über extrahierte Feldwerte gegenüber dem Ground Truth: 1.0 bedeutet, jedes Belegfeld wurde perfekt wiederhergestellt, 0 bedeutet nichts. Der Mechanismus hinter der Umkehrung ist eine Eigenschaft der Regex-Mustersammlung, nicht der Erkennungsqualität an sich: Die Muster wurden einmal pro Datensatz für formatierte Werte wie RM 12.00 oder 14/08/2020 geschrieben. docTRs sauberer, aber roher Zeilentext — genau nach CER, aber mit Beibehaltung der ursprünglichen Groß-/Kleinschreibung und Trennzeichen-Rauschens — überwindet die festen Muster; EasyOCRs Output trifft sie zufällig häufiger. Die Spalten „Regex-Feldextraktion“ sind die postprocessed_sroie_receipt_regex_*-Metriken des Benchmarks: Sie messen OCR-Text + nachgelagerte regelbasierte Extraktion, nicht native strukturierte Ausgabe. Eine pro-Format, stark optimierte Musterbibliothek könnte für beide Engines anders abschneiden — die Mustersammlung ist ein festes Messinstrument, kein optimierter Produktionsparser.
Quelle: field_method_comparison.csv — Spalten regex_field_value_f1 / llm_field_value_f1, Zeilen sroie_2019 (0–1 gespeicherte Dezimalzahlen als % angezeigt). LLM-Nachbearbeiter: deepseek-v4-flash (Spalte llm_model). 361 Samples pro Engine (llm_ok_count).
| Regex-Nachbearbeitung (SROIE 2019, n=361) | docTR | EasyOCR | Quelle |
|---|---|---|---|
| Feld-Wert-F1 (Regex) | 0.0766 | 0.1477 | field_method_comparison.csv · regex_field_value_f1, doctr/sroie_2019 und easyocr/sroie_2019 Zeilen |
| Feld-Wert-Genauigkeit (Regex) | 0.0623 | 0.1267 | field_method_comparison.csv · regex_field_value_accuracy, gleiche Zeilen |
| Dokumentfelder exakt (Regex) | 0.0000 | 0.0000 | field_method_comparison.csv · regex_document_fields_exact, gleiche Zeilen |
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 (nachbearbeitet, nicht native Extraktion). Das Feld-Wert-F1 von docTR mit Regex liegt bei 0,0766 und ist trotz des zweitbesten CER der zweitniedrigste Wert aller acht Engines im zugrunde liegenden Durchlauf — der Mustersatz wurde einmal pro Datensatz geschrieben, und docTRs sauberer, aber roher Zeilentext ist für Regex auf diesen vier Feldern nicht geeignet.
Der LLM-Hebel: Das Blatt wendet sich endgültig
Speisen Sie den OCR-Text beider Engines einem LLM-Nachbearbeiter (deepseek-v4-flash bei Temperatur 0) mit einem strukturierten Extraktionsprompt, kehrt sich die Rangfolge der Felder wieder um — mit der größten Spanne aller Paarungen im Benchmark: docTR 0,6171 vs. EasyOCR 0,3717 Feld-F1, eine 1,66× Lücke. docTRs Ergebnis ist das höchste LLM-Feld-F1 aller acht Engines; EasyOCRs das niedrigste. Wo das Regex-Muster-Set docTRs sauberen Text bestraft hat, belohnt ihn das LLM — und EasyOCRs mittelmäßiger Text, der zufällig regex-freundlich war, verschlechtert sich unter demselben Prompt.
Dies ist dasselbe LLM-Konvergenzmuster, das im gesamten Acht-Engine-Benchmark zu beobachten ist — LLM-Nachbearbeitung zieht gesunde Engines in einen 0,57–0,62 Feld-F1-Bereich, weil sie Semantik versteht (Zahlen, Daten, Namen) anstatt Zeichenformen abzugleichen — wobei EasyOCR die deutliche Ausnahme bildet. Der Hebel ist nicht kostenlos: Ein LLM-Aufruf fügt pro Dokument auf die OCR-Zeit (1.996,3 ms für docTRs Text, 2.004,5 ms für EasyOCRs, API-bedingt und in der Art identisch) eine mittlere Latenz von etwa 2,0–2,1 s hinzu, und er kann Text nicht retten, den eine Engine grundlegend nicht lesen konnte. Aber für diese Paarung wird der Nachbearbeiter zur entscheidenden Komponente: Mit einem LLM in der Pipeline verstärkt sich die Wahl von docTR.
| LLM-Nachbearbeitung (SROIE 2019, n=361) | docTR | EasyOCR | Quelle |
|---|---|---|---|
| Feld-Wert-F1 (LLM) | 0,6171 | 0,3717 | field_method_comparison.csv · llm_field_value_f1, doctr/sroie_2019 und easyocr/sroie_2019 Zeilen |
| Feld-Wert-Genauigkeit (LLM) | 0,6170 | 0,3712 | field_method_comparison.csv · llm_field_value_accuracy, gleiche Zeilen |
| Dokument-Felder exakt (LLM) | 0,1496 | 0,0028 | field_method_comparison.csv · llm_document_fields_exact, gleiche Zeilen |
| Median LLM-Nachbearbeitungslatenz (ms) | 1.996,3 | 2.004,5 | field_method_comparison.csv · llm_median_latency_ms, gleiche Zeilen |
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). „Dokument-Felder exakt" ist der Anteil der Dokumente, bei denen jedes Zielfeld genau übereinstimmte — ein viel strengerer Maßstab als das pro-Feld-F1; EasyOCR hat alle vier Felder bei 0,28 % der Quittungen genau richtig.
Das EasyOCR-LLM-Paradoxon: Mittelmäßiger Text, schlechteste nachgelagerte Extraktion
Der kontraintuitivste Datenpunkt dieses Vergleichs — erstmals dokumentiert in PaddleOCR vs EasyOCR und hier gegen einen anderen Gegner bestätigt: EasyOCRs OCR-Text liegt im Mittelfeld bei der Zeichengenauigkeit (SROIE CER 0.2833, vierter von acht Engines) — doch wenn dieser Text demselben LLM-Nachbearbeiter wie für jede andere Engine (deepseek-v4-flash, gleicher Prompt, gleiche Belege) zugeführt wird, ist sein SROIE-LLM-Feld-F1 von 0.3717 der niedrigste aller acht Engines im Benchmark — sogar unter Tesseract (
Quelle: field_method_comparison.csv — llm_field_value_f1, alle acht sroie_2019-Zeilen, jeweils 361 Stichproben (llm_ok_count). LLM-Nachbearbeiter identisch für alle Engines: deepseek-v4-flash bei Temperatur 0. CER-Kontext aus summary_metrics.csv, Spalte cer, sroie_2019-Zeilen.
| Alle 8 Engines, SROIE 2019 (n=361 jeweils) | SROIE CER | SROIE LLM-Feld-F1 | Quelle |
|---|---|---|---|
| docTR v1.0.1 | 0.1971 | 0.6171 | field_method_comparison.csv · doctr/sroie_2019-Zeile, llm_field_value_f1 (cer: summary_metrics.csv) |
| surya2 | 0.1915 | 0.6139 | field_method_comparison.csv · surya2/sroie_2019-Zeile, llm_field_value_f1 (cer: summary_metrics.csv) |
| unlimited_ocr | 0.6552 | 0.6054 | field_method_comparison.csv · unlimited_ocr/sroie_2019-Zeile, llm_field_value_f1 (cer: summary_metrics.csv) |
| paddleocr_vl_vllm | 0.3370 | 0.5921 | field_method_comparison.csv · paddleocr_vl_vllm/sroie_2019-Zeile, llm_field_value_f1 (cer: summary_metrics.csv) |
| paddleocr | 0.2045 | 0.5810 | field_method_comparison.csv · paddleocr/sroie_2019-Zeile, llm_field_value_f1 (cer: summary_metrics.csv) |
| docling | 0.5909 | 0.5685 | field_method_comparison.csv · docling/sroie_2019-Zeile, llm_field_value_f1 (cer: summary_metrics.csv) |
| tesseract (CPU) | 0.3347 | 0.4389 | field_method_comparison.csv · tesseract/sroie_2019-Zeile, llm_field_value_f1 (cer: summary_metrics.csv) |
| EasyOCR 1.7.2 | 0.2833 | 0.3717 | field_method_comparison.csv · easyocr/sroie_2019-Zeile, llm_field_value_f1 (cer: summary_metrics.csv) |
Tabelle: field_method_comparison.csv — llm_field_value_f1, alle sroie_2019-Zeilen; CER-Spalte aus summary_metrics.csv, cer, sroie_2019-Zeilen. docTR’s 0.6171 ist der höchste LLM-Feld-F1-Wert im Benchmark; EasyOCR’s CER (0.2833) rangiert auf Platz vier von acht — mittelmäßige Texterkennung mit der schlechtesten LLM-nachgelagerten Feldwiederherstellung (0.3717, unterhalb von Tesseract’s 0.4389). Das Paradoxon ist als beobachtet und reproduzierbar dokumentiert; sein Mechanismus wird durch diesen Benchmark nicht isoliert.
Der Betriebsbereich: docTR ist der Geschwindigkeits- UND Kosten-Champion des Benchmarks
Die Genauigkeit entscheidet, welche Engine am besten liest; der Betriebsbereich entscheidet, welche zuerst fertig wird. 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; EasyOCR hält 124,5 Seiten/Minute bei 413,6 ms p50 für $0,110 pro 1.000 Seiten — eine 3,8×-Latenz-Lücke, eine 3,6×-Durchsatz-Lücke und eine 2,3×-Kosten-Lücke, alles zu docTRs Vorteil. Über den gesamten Acht-Engine-Lauf hinweg sind docTRs 108,7 ms p50, 449,3 Seiten/Minute und $0,048 Kosten jeweils die besten aller gemessenen Engines — docTR ist gleichzeitig die schnellste und billigste Engine des Benchmarks.
Die Kosten werden berechnet als Wanduhr-Laufzeit × die RunPod RTX 4090-Rate ($0,76/Stunde, Preis mit Zeitstempel in den Lauf-Manifesten), einschließlich Modellinitialisierung — der Preis, den Sie tatsächlich für die GPU-Zeit zahlen würden. Der Durchsatz sind Wanduhr-Seiten pro Minute, einschließlich derselben Initialisierung. Die Latenz p50/p95 sind stationäre pro-Seite Inferenzzeiten, gemessen warm-then-scored (Modellladen ausgeschlossen); EasyOCRs Schwanz ist proportional schlechter — 960,4 ms p95 gegenüber docTRs 281,4 ms, eine 3,4×-Lücke. EasyOCR ist immer noch wirklich billiger als die meisten der anderen gemessenen Engines (ihre $0,110 ist die zweitniedrigste pro-1.000-Seiten-Zahl im Benchmark, nur hinter docTR) — sie ist mittig im Preis und mittig in der Geschwindigkeit, nicht teuer oder langsam.
Quelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms Spalten, sroie_2019 Zeilen. docTR p50 108,72 / p95 281,38; EasyOCR p50 413,64 / p95 960,37. Stationäre Latenz (warm_then_scored Messmodus, Modellladen ausgeschlossen).
Quelle: summary_metrics.csv — cost_per_1000_pages Spalte, sroie_2019 Zeilen. docTR 0,0479, EasyOCR 0,1098. Kosten = Wanduhr-Laufzeit × $0,76/Stunde inklusive Modellinit, Preis mit Zeitstempel in Lauf-Manifesten (August 2026). DocTRs $0,048 sind die niedrigsten Kosten pro 1.000 Seiten aller Engines im Benchmark; EasyOCRs $0,110 sind die zweitniedrigsten (summary_metrics.csv, cost_per_1000_pages, alle sroie_2019 Zeilen).
| Betriebsbereich (SROIE 2019, n=361) | docTR | EasyOCR | Quelle |
|---|---|---|---|
| Latenz p50 (ms) | 108.7 | 413.6 | summary_metrics.csv · latency_p50_ms, doctr/sroie_2019 und easyocr/sroie_2019 Zeilen |
| Latenz p95 (ms) | 281.4 | 960.4 | summary_metrics.csv · latency_p95_ms, gleiche Zeilen |
| Seiten pro Minute (Echtzeit) | 449.3 | 124.5 | summary_metrics.csv · pages_per_minute, gleiche Zeilen |
| Kosten pro 1.000 Seiten | $0.048 | $0.110 | summary_metrics.csv · cost_per_1000_pages, gleiche Zeilen |
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 Manifesten); Kosten beinhalten Modellinitialisierung, nicht reinen Durchsatz im稳态. Exakte Werte: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. Benchmark-weite Bestwerte: docTR hält die niedrigste p50-Latenz, die höchsten Seiten/min und die niedrigsten Kosten aller acht Engines (summary_metrics.csv, sroie_2019 Zeilen).
CORD (Indonesische Quittungen): Beide brechen beim Text zusammen, die LLM-Lücke wird größer
Keine der beiden 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 beim rohen CER zusammen: 0.9101 (docTR) und 0.9185 (EasyOCR), ein Sprach-Mismatch-Wasch, bei dem beide Engines den Text effektiv nicht lesen können. Gemäß dem Benchmark-Protokoll werden CORD-Zahlen von SROIE isoliert gehalten — nicht in ein Ranking eingemeischt —, da CORDs Ground-Truth-Text Annotationsstruktur einbettet, was den rohen CER für jede Engine zusätzlich zum tatsächlichen Sprach-Mismatch aufbläht.
Die Feldmetriken zeigen, dass sich das SROIE-Muster fortsetzt — und verstärkt. Über den LLM-Nachbearbeiter bleibt docTRs Feld-F1 bei 0.5500 gegenüber EasyOCRs 0.3378 auf CORD — eine 1,63-fache Lücke, dieselbe Reihenfolge wie bei SROIEs 1,66-facher, selbst wenn beide Texterkennungs-Engines auf Zeichenebene versagen. Über Regex-Muster erholt docTR keine Felder (0.0000 field F1 — ein wörtlicher Nullwert in der CSV, kein fehlender Wert), da die englischformatierten Muster nichts im indonesischen Text matchten, während EasyOCR 0,0067 extrahiert. DocTRs Kostenrand schrumppt und kehrt sich bei CORD um ($0,094 gegenüber EasyOCRs $0,086 pro 1.000 Seiten) — aber sein Vorteil bei der Durchsatzzeit wächst auf 500,4 gegenüber 211,8 Seiten/Min (2,4-fach). CORD wird hier für den Kontext der Sprachrobustheit zitiert; es wird absichtlich nie mit den SROIE-Zahlen zu einem einzigen Leaderboard zusammengefasst.
| CORD v2, Indonesische Quittungen (n=100) | docTR | EasyOCR | Quelle |
|---|---|---|---|
| Character Error Rate (CER) | 0.9101 | 0.9185 | summary_metrics.csv · cer, doctr/cord_v2 und easyocr/cord_v2 Zeilen |
| Field-value F1 (Regex) | 0.0000 | 0.0067 | field_method_comparison.csv · regex_field_value_f1, gleiche Zeilen |
| Field-value F1 (LLM) | 0.5500 | 0.3378 | field_method_comparison.csv · llm_field_value_f1, gleiche Zeilen |
| Seiten pro Minute (Durchsatzzeit) | 500.4 | 211.8 | summary_metrics.csv · pages_per_minute, gleiche Zeilen |
| Kosten pro 1.000 Seiten | $0.094 | $0.086 | summary_metrics.csv · cost_per_1000_pages, gleiche Zeilen |
Tabelle: summary_metrics.csv (CER / Seiten pro Minute / Kosten pro 1000 Seiten) und field_method_comparison.csv (Feld-F1), cord_v2-Zeilen. CORD-Zahlen nicht in irgendein SROIE-Ranking einbeziehen: CORD CER kombiniert echte Sprachunterschiede mit einer Aufblähung der Annotationsstruktur in den Ground-Truth-Daten. Die Regex-Muster wurden für englische Formate geschrieben, weshalb das Feld-F1 bei Regex auf beiden Engines auf ~0–1% einbricht; docTR’s 0.0000 ist ein wörtlicher Nullwert in der CSV, kein fehlender Wert. Die LLM-Feld-F1-Differenz (0,5500 vs. 0,3378) überträgt das SROIE-Muster auf andere Sprachen; die Kostenreihenfolge kehrt sich um (EasyOCR $0,086 vs. docTR $0,094), während der Durchsatzunterschied wächst (2,4×).
Wer gewinnt wann: Die Zusammenfassungsmatrix
“Besser” hängt von der Arbeitslast ab, und dieser Vergleich teilt die Achsen klar auf: Rohtextgenauigkeit, LLM-Downstream-Felder, Geschwindigkeit, Durchsatz und Kosten sprechen alle für docTR; feste Regex-Feldextraktion und das Deployment sprechen für EasyOCR — mit dem Vorbehalt, dass EasyOCR’s LLM-Downstream-Ergebnis sein größtes Risiko ist, nicht sein Verkaufsargument.
Häufig gestellte Fragen
Ist docTR genauer als EasyOCR bei Belegen?
Ja, in jeder Metrik für Roh-Text und Feldextraktion in diesem Benchmark. Bei SROIE 2019: CER 0,1971 vs. 0,2833 (30 % niedriger), WER 0,3199 vs. 0,6158 (48 % niedriger), LLM-nachverarbeitetes Feld-F1 0,6171 vs. 0,3717 (1,66×, bestes von 8 vs. schlechtestes von 8) — aber nicht beim Regex-Feld-F1, wo EasyOCR mit 0,1477 vs. 0,0766 gewinnt (summary_metrics.csv und field_method_comparison.csv, sroie_2019-Zeilen). Keine Engine ist der CER-Gesamtsieger des Benchmarks — Surya2 (0,1915) hält diesen Titel knapp vor docTR.
Warum hat docTR eine bessere Textgenauigkeit, aber eine schlechtere Regex-Feldextraktion als EasyOCR?
Weil die beiden Metriken verschiedene Ausgaben gegen ein festes Messinstrument bewerten. docTR liefert saubere Rohe-Textzeilen — genau nach CER, aber mit Erhaltung der Originalgroß-/Kleinschreibung und Trennzeichen — und die festen Regex-Muster, die einmal pro Datensatz für formatierte Werte geschrieben wurden, scheitern größtenteils dagegen: SROIE Regex-Feld-F1 0,0766 (field_method_comparison.csv, regex_field_value_f1, doctr/sroie_2019-Zeile). EasyOCR's Ausgabe trifft die Muster zufällig mit 0,1477. Füttert man beide stattdessen mit einem LLM, kehrt sich die Lücke zugunsten von docTR um — die Regex-Mustersammlung, nicht die OCR, war der Flaschenhals.
Warum hat EasyOCR die schlechteste LLM-Feldextraktion trotz akzeptabler Zeichengenauigkeit?
Dies ist das dokumentierte Paradoxon des Benchmarks, derzeit ohne bewiesenen Mechanismus. EasyOCR's SROIE-CER (0,2833) rangiert auf dem vierten Platz von acht Engines, doch sein LLM-nachverarbeitetes Feld-F1 (0,3717) rangiert auf dem letzten Platz — sogar unter Tesseract (0,4389), das einen schlechteren CER hat. Die führende Hypothese ist eine Ausgabeformatkonvention in der Art, wie EasyOCR Textzeilen anordnet oder verbindet, die die nachgelagerte LLM-Extraktion verschlechtert; sie wird als beobachtetes, reproduzierbares Muster gekennzeichnet, wobei der Mechanismus nicht verifiziert ist (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen). Das gleiche Paradoxon ist gegen einen anderen Gegner auf PaddleOCR vs EasyOCR dokumentiert.
Wie viel schneller und günstiger ist docTR als EasyOCR?
3,8× niedrigere p50-Latenz (108,7 vs. 413,6 ms), 3,4× niedrigere p95 (281,4 vs. 960,4 ms), 3,6× höhere Durchsatzrate (449,3 vs. 124,5 Seiten/min) und 2,3× niedrigere Kosten pro 1.000 Seiten ($0,048 vs. $0,110) auf derselben RTX 4090 bei $0,76/Stunde (summary_metrics.csv, latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, sroie_2019-Zeilen). docTR ist die schnellste und günstigste Engine des Benchmarks in allen drei Zeitmessungen; EasyOCR liegt bei den Kosten im Mittelfeld (zweitgünstigst) und bei der Geschwindigkeit im Mittelfeld (zweitgrößter Durchsatz).
Warum schneiden beide Engines bei CORD-Quittungen so schlecht ab?
Zwei sich verstärkende Ursachen, die das Benchmark-Protokoll von der SROIE-Rangliste getrennt hält: eine echte Sprachdiskrepanz (indonesische Quittungen außerhalb des Trainingsfokus beider Engines) und eine Aufblähung der Annotationsstruktur im Originaltext von CORD — die CER liegt bei 0,9101 (docTR) und 0,9185 (EasyOCR) (summary_metrics.csv, cer, cord_v2-Zeilen). Was sie weiterhin unterscheidet, ist die LLM-Nachbearbeitung: docTR 0,5500 vs. EasyOCR 0,3378 Field F1 — das SROIE-Muster setzt sich fort und verstärkt sich, selbst wenn beide Erkennungsmodelle auf Zeichenebene versagen.
Welche Engine sollte eine Quittungs-Pipeline wählen, EasyOCR oder docTR?
Für eine Pipeline, deren Ziel extrahierte Felder in hohem Volumen zu kalkulierbaren Kosten sind, dominiert docTR in diesem Korpus: bessere Rohdaten (30% niedrigere CER), die besten LLM-Nachbearbeitungs-Felder aller Engines (0,6171 vs. 0,3717) und ein 2,3-facher Kostenvorteil, 3,6-facher Durchsatz, 3,8-fache Latenz — alles auf vier Achsen gleichzeitig (summary_metrics.csv / field_method_comparison.csv, sroie_2019-Zeilen). EasyOCR bleibt eine legitime Wahl für günstige, einfach zu installierende, mehrschriftliche Massen-OCR für saubere Dokumente, bei der Regex-Extraktion oder Rohdaten in moderatem Volumen die Aufgabe sind und die LLM-Nachbearbeitungs-Feldqualität weniger wichtig ist — aber kalkulieren Sie die gemessene Schwäche der LLM-Nachbearbeitung ein, bevor Sie sich festlegen. Diese Ergebnisse gelten für englische und indonesische Quittungen auf einer GPU-Stufe im August 2026; führen Sie vor Produktionsentscheidungen einen erneuten Lauf auf Ihrem Zielkorpus durch (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, Regex-Feld-F1, Latenz, Kosten, Durchsatz) und results/field_method_comparison.csv (Regex vs. LLM-Nachbearbeitung, llm_model = deepseek-v4-flash) — gehostet bei ImageToTableai/benchmark-ocr, mit einem geschwärzten manifest.json pro Durchlauf für Umgebungsfingerabdrücke. Datensatzdefinitionen stammen aus den unten zitierten Arbeiten zu SROIE 2019 und CORD.
Methodik & Quellen
Protokoll
Diese Seite präsentiert eine direkte Gegenüberstellung eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Umfrage zu Behauptungen Dritter und keine Hersteller-Vergleichsseite. Nur feste Test-Splits: SROIE 2019 test (361 englische Belege, flache Felder Firma/Datum/Adresse/Gesamtbetrag) und CORD v2 test (100 indonesische Belege, verschachtelte Felder Menü/Teilsumme/Gesamtbetrag); Trainings-Splits wurden nie ausgewertet. Beide Engines sahen dieselben Bilder, dieselben Ground-Truth-Werte und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte im steady state liegen). Beide Läufe schlossen mit einer error_rate von 0,0 auf beiden Datensätzen ab (Spalte error_rate in summary_metrics.csv). Der zugrunde liegende Lauf umfasste insgesamt acht Engines; diese Seite vergleicht nur die beiden genannten Engines, wobei die anderen Engines nur als Ranking-Kontext zitiert werden. 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-Stempel im geschwärzten Manifest jedes Laufs (August 2026).
- Engines: Out-of-the-box, kein Fine-Tuning. Versionen fixiert: EasyOCR 1.7.2 (klassischer CNN + RNN + CTC-Recognizer, ResNet-Feature-Extractor, GPU) und docTR v1.0.1 (moderne zweistufige neurale OCR — DETR-artige Transformer-Erkennung + Erkennung, GPU) — laut Modelltabelle im öffentlichen Repo (README.md) und den Lauf-Manifesten. Die SROIE-Zeile von EasyOCR wurde in einem erneuten Lauf mit torch 2.8 am 17.08.2026 überprüft (Wiederholungsläufe r1/r2/r3 byte-identisch); die veröffentlichten CSVs enthalten diese korrigierten Werte.
- 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 in beiden 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 werden, das einmal pro Datensatz geschrieben wurde. Sie messen OCR + nachgelagerte Extraktion, nicht die native strukturierte Ausgabe eines der Modelle; die Spalten LLM_* messen OCR-Text + LLM-Extraktion. Die beiden Pipelines werden nie gemischt.
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.
- WER (Word Error Rate): dieselbe Editierdistanz-Berechnung auf Wortebene.
- Field-value 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.
- Field-value 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.
- Document-fields exact: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — ein viel strengerer Maßstab als der per-Feld-F1-Wert.
- Latency p50/p95 & pages/min: Stabilisierte Inferenzzeit pro Seite (warm-then-scored, schließt Modell-Laden aus) und Durchsatz in Echtzeit inklusive Modellinitialisierung. Sie messen unterschiedliche Uhren.
- Kosten pro 1.000 Seiten: Abgerechnete GPU-Stunden für 1.000 Seiten zum erfassten Satz von $0,76/Stunde, inklusive Modellinitialisierung.
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 Durchsatzzahl auf dieser Seite lässt sich auf die easyocr- und doctr-Zeilen hier zurückführen.
- field_method_comparison.csv (GitHub raw). 16 Zeilen; Spalten model, dataset, llm_model (= deepseek-v4-flash), regex/llm field-value accuracy and F1, document-fields-exact, llm_median_latency_ms, token counts. Jede regex/LLM-Feld-F1-Zahl lässt sich auf die easyocr- und doctr-Zeilen hier (und auf alle acht sroie_2019-Zeilen in der Paradox-Tabelle) zurückführen.
- ImageToTableai/benchmark-ocr Repository. Öffentliches Repository mit den Ergebnis-CSVs, geschwärzten Ausführungsprotokollen, eingefrorenem Protokoll und Datensatz-Beispiellisten (feste Testsplits) zur Reproduktion.
- 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.
- 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 Felda Schema und Lizenz (CC-BY-4.0).
Einschränkungen
- Dokumentbereich — nur Quittungen: SROIE + CORD. Hier wird nicht die 80+ Sprachen-Breite von EasyOCR bei Nicht-Quittungstext, das Verhalten von docTR bei Tabellen/Formularen/langer Dokumenten oder anderen Dokumenttypen gemessen. Verwenden Sie diese Seite nicht, um zu schlussfolgern, dass eine der Engines „in allem gewinnt“.
- Stichprobengröße: 361 englische + 100 indonesische Quittungen. Feld-F1 und CER sind korpusabhängig; einstellige Unterschiede von wenigen Hundertsteln sollten als Rauschen und nicht als ingenieurtechnische Wahrheit behandelt werden — wobei die hier dokumentierten Lücken (30% CER, 48% WER, 1,66× LLM-F1) weit über diesem Bereich liegen.
- Einzelne GPU-Stufe 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-Bedienung, Stapelplanung oder Preisänderungen verschieben Latenz, Durchsatz und Kosten — leiten Sie die Kosten vor der Budgetierung mit aktuellen Raten ab.
- Einzelner LLM-Nachbearbeiter: Alle LLM-Zeilen verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt das absolute Feld-F1; die Größe des EasyOCR-Paradoxons kann sich mit dem LLM verschieben, wobei das beobachtete Muster für diesen einzelnen Nachbearbeiter über beide Datensätze galt. Die LLM-Latenz (~2,0–2,1 s Median auf SROIE, field_method_comparison.csv llm_median_latency_ms) wird durch die API verursacht und ist kein Teil der Latenz der jeweiligen Engine.
- EasyOCR-Paradoxon-Mechanismus nicht verifiziert: Der Benchmark dokumentiert, dass EasyOCRs mittelmäßiger CER-Text die schlechteste LLM-abgeleitete Feldwiederherstellung (0,3717 SROIE / 0,3378 CORD) erzeugt — ein beobachtetes, reproduzierbares Ergebnis unter der Hypothese von Ausgabetext-Layoutkonventionen, wobei der Kausalmechanismus explizit nicht isoliert wurde. Behandeln Sie es als gemessenes Ergebnis, um es zu planen, nicht als bewiesene Eigenschaft der Bibliothek.
- Regex-Abstimmung: Das Muster-Set wurde einmal pro Datensatz geschrieben. Eine pro-Format, stark abgestimmte Musterbibliothek könnte bei eigenen Layouts höher punkten — mit den Wartungskosten, die das LLM eliminiert. docTRs Regex-Feld-Nachteil (0,0766 vs. 0,1477) ist eine Eigenschaft dieses festen Instruments, nicht eine Behauptung darüber, was ein abgestimmter Parser wiederherstellen könnte.
- CORD-CER ist keine qualitätsbezogene Einzelmodell-Messung: CORD-Grundwahrheit enthält Annotationstruktur und keine der Engines wurde überwiegend auf Indonesisch trainiert; CORD-CER (~0,91) spiegelt Sprachinkongruenz + Grundwahrheits-Inflation wider. CORD-Zeilen werden mit Einordnung zitiert und nie in irgendein SROIE-Ranking eingeflossen (Protokollregel).
- 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.
- Versionsfixierung: Die Ergebnisse gelten für EasyOCR 1.7.2 und docTR v1.0.1 (August 2026). Neuere Versionen einer der Engines können jede Zahl auf dieser Seite verschieben.
Verwandte Referenzen: PaddleOCR vs EasyOCR Quittungs-Benchmark · docTR vs Surya2 Quittungs-Benchmark · Traditionelles OCR vs. Dokument-Parsing-VLMs · Regex vs. LLM-Feldextraktion · Feld-Ebene vs. Zeichen-Ebene Genauigkeit · OCR-Kosten pro 1.000 Seiten
Weiterführende Lektüre: KI-OCR vs. traditionelle OCR-Genauigkeit · KI-Bilddatenextraktion vs. traditionelle OCR · Preise für KI-Dokumentextraktion (2026)