EasyOCR vs. docTR bei Belegen
Geschwindigkeits-Champion vs. Feldextraktor (2026)

Die beiden Engines repräsentieren zwei Generationen von Deep-Learning-OCR und liegen beide auf der traditionellen Seite der OCR-gegenüber-VLM-Trennung. EasyOCR (PyTorch-basiert, 1.7.2) ist ein klassischer Single-Pass-CNN + RNN + CTC-Erkenner — ein ResNet-Feature-Extraktor, der ein Sequenzmodell speist, das mit Connectionist Temporal Classification dekodiert wird, mit Attention-basierter Verfeinerung. Sein Design-Schwerpunkt liegt auf sehr breiter Sprach- und Schriftsystem-Abdeckung (80+ Sprachen out of the box) und einer bekanntermaßen einfachen Installation. docTR (v1.0.1) ist eine moderne zweistufige neuronale Pipeline: Eine Erkennungsstufe lokalisiert Textregionen, dann transkribiert eine Erkennungsstufe sie — aufgebaut um DETR-artige Transformer-Erkennung und einen Transformer-Erkenner, entwickelt für Genauigkeit bei gedruckten Dokumenten. Character Error Rate (CER) misst Einfügungen, Löschungen und Ersetzungen geteilt durch die Ground-Truth-Zeichen — ein CER von 0.197 bedeutet ~19,7 falsch gelesene Zeichen pro 100; Word Error Rate (WER) wendet dieselbe Edit-Distanz-Logik auf ganzer Wortebene an. Niedriger ist bei beiden besser. Keine der beiden Engines ist ein Vision-Language-Modell (VLM) — beide geben Rohtext aus, keine verstandene Struktur.

Textgenauigkeit auf SROIE (englische Belege): docTRs klarer Vorsprung

Auf den 361 englischen Belegen des SROIE-2019-Test-Splits gewinnt die moderne Architektur bei beiden Textmetriken: CER 0,1971 vs. 0,2833 (30 % relative Verbesserung) und WER 0,3199 vs. 0,6158 — EasyOCRs WER ist fast doppelt so hoch. Die WER-Lücke (48 %) ist viel größer als die CER-Lücke (30 %), was darauf hindeutet, dass EasyOCR Zeichenfehler auf diesem Korpus zu Ganzwort-Fehlern kumuliert. Beide Engines laufen fehlerfrei (error_rate 0,0 in jeder SROIE- und CORD-Zeile der CSV). Keine der beiden Engines ist der Gesamt-CER-Champion des Benchmarks — dieser Titel gehört Surya2 (0,1915), docTR selbst liegt auf 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.

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 Abstände: CER 30 % niedriger, WER 48 % niedriger für docTR. Niedrigere CER/WER sind besser. CER-Rangfolge im Kontext desselben 8-Engine-Laufs: Surya2 0,1915, docTR 0,1971, PaddleOCR 0,2045, EasyOCR 0,2833 (summary_metrics.csv, cer, Zeilen sroie_2019).

Die Regex-Feldinversion: schlechterer Text, mehr wiederherstellbare Felder

Benchmarken Sie den Rohtext beider Engines mit denselben festen Regex-Mustern für die vier SROIE-Belegfelder (Firma, Datum, Adresse, Gesamtbetrag) — der traditionelle OCR- und regelbasierte KIE-Ansatz (Key Information Extraction) — und die Rangfolge 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 Inversion „Textgenauigkeit ≠ Feldgenauigkeit“ des Benchmarks — dasselbe Muster, das zwischen traditioneller OCR und Dokument-Parsing-VLMs bei docTR vs. Surya2 zu sehen ist — nun zwischen zwei traditionellen Engines, die dieselbe Art von Rohtextzeilen ausgeben.

Field-value F1 ist das harmonische Mittel aus Präzision und Recall über extrahierte Feld-Werte im Vergleich zur Ground Truth: 1,0 bedeutet, dass jedes Belegfeld perfekt wiederhergestellt wurde, 0 bedeutet nichts. Der Mechanismus hinter der Umkehrung ist eine Eigenschaft des Regex-Mustersatzes, 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 — laut CER genau, aber mit ursprünglicher Groß-/Kleinschreibung und Trennzeichen-Rauschen — überwindet die festen Muster nicht; EasyOCRs Ausgabe passt zufällig öfter dazu. Die Spalten „Regex-Feldextraktion“ sind die Metriken postprocessed_sroie_receipt_regex_* des Benchmarks: Sie messen OCR-Text plus nachgelagerte regelbasierte Extraktion, nicht native strukturierte Ausgabe. Eine pro Format stark abgestimmte Musterbibliothek könnte für beide Engines andere Ergebnisse liefern — der Mustersatz ist ein festes Messinstrument, kein abgestimmter Produktionsparser.

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

Tabelle: field_method_comparison.csv — Regex-Spalten, sroie_2019-Zeilen. Dies sind postprocessed_sroie_receipt_regex_*-Metriken: feste Muster, die auf den OCR-Text jeder Engine angewendet werden (nachbearbeitet, nicht native Extraktion). docTRs Regex-Feld-F1 von 0.0766 ist der zweitniedrigste aller acht Engines im zugrunde liegenden Lauf, trotz des zweitbesten CER — der Mustersatz wurde einmal pro Datensatz geschrieben, und docTRs sauberer, aber roher Zeilentext ist bei diesen vier Feldern nicht regex-freundlich.

Der LLM-Hebel: Die Rangfolge kehrt sich entscheidend um

Füttert man beiden Engines den OCR-Text an einen LLM-Nachbearbeiter (deepseek-v4-flash bei Temperatur 0) mit einem strukturierten Extraktions-Prompt, kehrt sich die Feld-Rangfolge wieder um — mit dem größten Abstand aller Paarungen im Benchmark: docTR 0,6171 gegenüber EasyOCR 0,3717 Feld-F1, eine Lücke von 1,66×. docTRs Ergebnis ist die höchste LLM-Feld-F1 aller acht Engines; EasyOCRs ist die niedrigste. Wo das Regex-Musterset docTRs sauberen Text bestrafte, 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 sehen ist — LLM-Nachbearbeitung zieht gesunde Engines in ein Feld-F1-Band von 0,57–0,62, weil sie Semantik versteht (Zahlen, Daten, Namen), statt Zeichenformen abzugleichen — mit EasyOCR als deutlicher Ausnahme. Der Hebel ist nicht kostenlos: Ein LLM-Aufruf fügt pro Dokument grob 2,0–2,1 s mediane Latenz zur OCR-Zeit hinzu (1.996,3 ms für docTRs Text, 2.004,5 ms für EasyOCRs, API-bedingt und in gleicher Art), und er rettet keinen Text, den eine Engine grundlegend nicht lesen konnte. Aber bei dieser Paarung wird der Nachbearbeiter zur entscheidenden Komponente: Mit einem LLM in der Pipeline verstärkt sich die docTR-Wahl.

Tabelle: field_method_comparison.csv — llm_*-Spalten, sroie_2019-Zeilen. LLM-Modell: deepseek-v4-flash bei Temperatur 0 (Spalte llm_model). Die LLM-Latenz ist API-bedingt und getrennt von der Engine-Latenz (summary_metrics.csv latency_p50_ms). „Dokumentfelder exakt“ ist der Anteil der Dokumente, bei denen jedes Zielfeld exakt übereinstimmte — eine deutlich strengere Messlatte als die feldweise F1; EasyOCR trifft alle vier Felder bei 0,28 % der Belege exakt.

Das EasyOCR-LLM-Paradoxon: Mittelmäßiger Text, schlechteste Downstream-Extraktion

Der kontraintuitivste Datenpunkt dieses direkten Vergleichs — erstmals dokumentiert auf PaddleOCR vs. EasyOCR und hier gegen einen anderen Gegner bestätigt: EasyOCRs OCR-Text liegt bei der Zeichengenauigkeit im Mittelfeld (SROIE CER 0,2833, vierter von acht Engines) — doch wenn dieser Text demselben LLM-Postprozessor zugeführt wird, der für alle anderen Engines verwendet wird (deepseek-v4-flash, gleicher Prompt, gleiche Belege), ist sein SROIE-LLM-Feld-F1 von 0,3717 der niedrigste aller acht Engines im Benchmark — sogar unter Tesseract (0,4389), einer CPU-Engine mit schlechterem CER (0,3347). Nur der OCR-Text änderte sich; LLM, Prompt und Belege waren identisch.

Beobachtetes Muster, Mechanismus nicht verifiziert. Eine plausible Hypothese — und nicht mehr als das — ist eine Ausgabeformat-Konvention: Wie EasyOCR Textzeilen anordnet, verbindet oder trennt, scheint die nachgelagerte LLM-Feldextraktion aus Gründen zu beeinträchtigen, die nichts mit der rohen Zeichengenauigkeit zu tun haben. Der Benchmark hat diesen Mechanismus nicht isoliert; das Ergebnis wird hier als reproduzierbar und stabil dokumentiert (EasyOCRs SROIE-Zeile wurde in einem erneuten Lauf vom 17.08.2026 mit torch 2.8 verifiziert, r1/r2/r3 byte-identisch; die veröffentlichte CSV enthält bereits diese korrigierten Werte), aber es wird kein kausaler Anspruch erhoben. docTRs saubererer Basistext + das LLM landet an der Spitze desselben Bereichs, den EasyOCR verfehlt.

Quelle: field_method_comparison.csv — llm_field_value_f1, alle acht sroie_2019-Zeilen, jeweils 361 Stichproben (llm_ok_count). LLM-Postprozessor für alle Engines identisch: deepseek-v4-flash bei Temperatur 0. CER-Kontext aus summary_metrics.csv, Spalte cer, sroie_2019-Zeilen.

Tabelle: field_method_comparison.csv — llm_field_value_f1, alle sroie_2019-Zeilen; CER-Spalte aus summary_metrics.csv, cer, sroie_2019-Zeilen. docTRs 0.6171 ist der höchste LLM-Feld-F1 im Benchmark; EasyOCRs CER (0.2833) liegt auf Rang vier von acht — mittelmäßiger Text mit der schlechtesten LLM-Downstream-Felderfassung (0.3717, unter Tesseracts 0.4389). Das Paradoxon ist als beobachtet und reproduzierbar dokumentiert; sein Mechanismus wird durch diesen Benchmark nicht isoliert.

Das Betriebsfenster: docTR ist der Geschwindigkeits- UND Kosten-Champion des Benchmarks

Die Genauigkeit entscheidet, welches System am besten liest; das Betriebsfenster entscheidet, welches zuerst fertig wird. Auf derselben RTX 4090 zum gleichen aufgezeichneten Satz von $0,76/Std. erreicht docTR 449,3 Seiten/Min. bei 108,7 ms p50 pro Seite für $0,048 pro 1.000 Seiten; EasyOCR erreicht 124,5 Seiten/Min. bei 413,6 ms p50 für $0,110 pro 1.000 Seiten — eine 3,8×-Latenzlücke, eine 3,6×-Durchsatzlücke und eine 2,3×-Kostenlücke, alle zugunsten von docTR. Über den gesamten Acht-Engine-Lauf hinweg sind docTRs 108,7 ms p50, 449,3 Seiten/Min. und $0,048 Kosten jeweils die besten aller gemessenen Engines — docTR ist gleichzeitig die schnellste und günstigste Engine des Benchmarks.

Die Kosten werden als Wanduhr-Laufzeit × dem RunPod-RTX-4090-Satz ($0,76/Stunde, Preis mit Zeitstempel in den Laufmanifesten) berechnet, einschließlich der Modellinitialisierung — der Preis, den Sie tatsächlich für die GPU-Zeit zahlen würden. Der Durchsatz ist die Wanduhr-Seitenzahl pro Minute, einschließlich derselben Initialisierung. Die Latenz p50/p95 sind die Seiteninferenzzeiten im stationären Zustand, die warm gemessen und dann bewertet werden (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 echt günstiger als die meisten anderen gemessenen Engines (seine $0,110 sind der zweitniedrigste Wert pro 1.000 Seiten im Benchmark, nur hinter docTR) — es ist mittelteuer und mittelschnell, nicht teuer oder langsam.

Quelle: summary_metrics.csv — Spalten latency_p50_ms / latency_p95_ms, Zeilen sroie_2019. docTR p50 108,72 / p95 281,38; EasyOCR p50 413,64 / p95 960,37. Latenz im stationären Zustand (Messmodus warm_then_scored, Modellladen ausgeschlossen).

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen sroie_2019. docTR 0,0479, EasyOCR 0,1098. Kosten = Wanduhr-Laufzeit × $0,76/Std. inklusive Modell-Init, Preis mit Zeitstempel in den Laufmanifesten (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).

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, Zeilen sroie_2019. Beide Engines auf GPU (RTX 4090, $0,76/Std., Preis in Manifests zeitgestempelt); Kosten umfassen Modellinitialisierung, nicht reinen Dauerbetriebsdurchsatz. Exakte Werte: docTR p50 108,72 / p95 281,38 / 449,31 Seiten/min / $0,0479; EasyOCR p50 413,64 / p95 960,37 / 124,53 Seiten/min / $0,1098. Benchmark-Bestwerte: docTR hält die niedrigste p50-Latenz, die höchste Seitenzahl pro Minute und die niedrigsten Kosten aller acht Engines (summary_metrics.csv, Zeilen sroie_2019).

CORD (indonesische Belege): Beide scheitern am Text, die LLM-Lücke wächst

Keine der beiden Engines wurde überwiegend mit indonesischen Belegen trainiert, daher fungiert CORD v2 (100 Stichproben, verschachtelte Felder menu/sub_total/total) als sprachübergreifender Stresstest — und beide scheitern bei der rohen CER: 0,9101 (docTR) und 0,9185 (EasyOCR), ein sprachbedingter Gleichstand, bei dem beide Engines den Text praktisch nicht lesen können. Gemäß Benchmark-Protokoll bleiben die CORD-Werte von der SROIE-Vergleichsanalyse getrennt — sie fließen in kein Ranking ein —, da der Ground-Truth-Text von CORD Annotationsstrukturen enthält, was die rohe CER für jede Engine zusätzlich zur echten Sprachdiskrepanz erhöht.

Die Feldmetriken zeigen, dass sich das SROIE-Muster fortsetzt — und verstärkt. Durch den LLM-Postprozessor hält docTRs Feld-F1 bei 0,5500 gegenüber EasyOCRs 0,3378 auf CORD — eine 1,63×-Lücke, dieselbe Reihenfolge wie bei SROIE mit 1,66×, selbst wenn beide Texterkenner auf Zeichenebene versagen. Mit Regex-Mustern extrahiert docTR keine Felder (0,0000 Feld-F1 — eine echte Null in der CSV, kein fehlender Wert), da die englischen Formatmuster in indonesischem Text nichts fanden, während EasyOCR 0,0067 erreicht. docTRs Kostenvorteil schrumpft und kehrt sich auf CORD um ($0,094 gegenüber EasyOCRs $0,086 pro 1.000 Seiten) — aber sein Wanduhr-Durchsatzvorteil wächst auf 500,4 gegenüber 211,8 Seiten/min (2,4×). CORD wird hier für den Kontext der Sprachrobustheit angeführt; es wird bewusst nie mit den SROIE-Werten in einer einzigen Rangliste zusammengeführt.

Tabelle: summary_metrics.csv (CER / pages_per_minute / cost_per_1000_pages) und field_method_comparison.csv (Feld-F1), CORD-v2-Zeilen. CORD-Zahlen nicht in ein SROIE-Ranking einmischen: Der CORD-CER kombiniert echte Sprachinkompatibilität mit einer Aufblähung der Annotationsstruktur in den Ground-Truth-Daten. Die Regex-Muster wurden für englische Formate geschrieben, weshalb die Regex-Feld-F1 bei beiden Engines auf ~0–1 % einbricht; docTR’s 0.0000 ist eine wörtliche Null in der CSV, kein fehlender Wert. Die LLM-Feld-F1-Lücke (0.5500 vs. 0.3378) setzt das SROIE-Muster über Sprachen hinweg fort; die Kostenreihenfolge kehrt sich um (EasyOCR $0.086 vs. docTR $0.094), während sich der Durchsatzunterschied vergrößert (2,4×).

Wer gewinnt wann: Die Übersichtstabelle

„Besser“ hängt vom Arbeitsaufkommen ab, und dieser direkte Vergleich trennt die Achsen klar: Rohtextgenauigkeit, LLM-Downstream-Felder, Geschwindigkeit, Durchsatz und Kosten sprechen alle für docTR; die feste Regex-Feldextraktion und die Bereitstellungsgeschichte sprechen für EasyOCR — mit dem Vorbehalt, dass EasyOCRs LLM-Downstream-Ergebnis sein größtes Risiko ist, nicht sein Verkaufsargument.

Häufig gestellte Fragen

Ist docTR bei Belegen genauer als EasyOCR?

Ja, bei jeder Genauigkeitsachse für Rohtext 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-nachbearbeitetes 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 der beiden Engines ist der Gesamtsieger des Benchmarks bei CER — 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 unterschiedliche Ausgaben gegen ein festes Messinstrument bewerten. docTR liefert sauberen Rohtext pro Zeile — genau nach CER, aber mit ursprünglicher Groß-/Kleinschreibung und Trennzeichen — und die festen Regex-Muster, die pro Datensatz für formatierte Werte geschrieben wurden, scheitern meist daran: SROIE-Regex-Feld-F1 0.0766 (field_method_comparison.csv, regex_field_value_f1, doctr/sroie_2019-Zeile). Die Ausgabe von EasyOCR passt zufällig mit 0.1477 zu den Mustern. Füttert man beide stattdessen an ein LLM, kehrt sich die Lücke zu docTRs Gunsten auf das 1,66-Fache um — das Regex-Musterset, nicht die OCR, war der Engpass.

Warum hat EasyOCR trotz akzeptabler Zeichengenauigkeit die schlechteste LLM-Feldextraktion?

Dies ist das dokumentierte Paradoxon des Benchmarks, derzeit ohne belegten Mechanismus. EasyOCRs SROIE-CER (0.2833) liegt auf Rang vier von acht Engines, doch sein LLM-nachbearbeitetes Feld-F1 (0.3717) liegt auf dem letzten Platz — sogar unter Tesseract (0.4389), das einen schlechteren CER hat. Die führende Hypothese ist eine Ausgabeformat-Konvention, wie EasyOCR Textzeilen anordnet oder verbindet, die die nachgelagerte LLM-Extraktion verschlechtert; sie ist als beobachtetes, reproduzierbares Muster mit unverifiziertem Mechanismus gekennzeichnet (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen). Dasselbe Paradoxon ist gegen einen anderen Gegner bei 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öherer Durchsatz (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 $/Std. (summary_metrics.csv, latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, sroie_2019-Zeilen). docTR ist das schnellste und günstigste Modul des Benchmarks auf allen drei Uhren; EasyOCR ist mittelpreisig (zweitgünstigste) und mittelschnell (zweitbester Durchsatz).

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

Zwei sich überlagernde Ursachen, die das Benchmark-Protokoll von der SROIE-Rangliste getrennt hält: eine echte Sprachdiskrepanz (indonesische Belege außerhalb des Trainingsfokus beider Module) und eine Anmerkungsstruktur-Inflation im Ground-Truth-Text 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-Downstream-Wiederherstellung: docTR 0,5500 vs. EasyOCR 0,3378 Feld-F1 — das SROIE-Muster bleibt bestehen und verstärkt sich, selbst wenn beide Erkennungsmodule auf Zeichenebene versagen.

Welches Modul sollte eine Beleg-Pipeline wählen, EasyOCR oder docTR?

Für eine Pipeline, deren Ziel extrahierte Felder in großem Umfang mit messbaren Kosten ist, dominiert docTR bei diesem Korpus: besserer Rohtext (30 % niedrigere CER), die besten LLM-Downstream-Felder aller Module (0,6171 vs. 0,3717) und ein 2,3×-Kostenvorteil, 3,6× Durchsatz, 3,8× Latenz — alle 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, mehrsprachige Massen-OCR auf sauberen Dokumenten, bei denen Regex-Extraktion oder Rohtext in moderatem Umfang die Aufgabe ist und die LLM-Downstream-Feldqualität weniger zählt — aber kalkulieren Sie vor der Entscheidung seine gemessene schwache LLM-Downstream-Leistung ein. Diese Ergebnisse gelten für englische und indonesische Belege auf einer GPU-Stufe im August 2026; führen Sie vor Produktionsentscheidungen erneute Tests auf Ihrem Zielkorpus durch (siehe Einschränkungen).

Woher stammen die Zahlen auf dieser Seite?

Jede Kennzahl ist eine Zeile aus den 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 unter ImageToTableai/benchmark-ocr, mit einem geschwärzten manifest.json pro Lauf für Umgebungs-Fingerprints. Die Datensatzdefinitionen stammen aus den unten zitierten SROIE-2019- und CORD-Publikationen.

Methodik & Quellen

Protokoll

Diese Seite berichtet einen direkten Vergleichsausschnitt eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Übersicht über Drittanbieter-Behauptungen und keine Anbieter-Vergleichsseite. Nur feste Test-Splits: SROIE-2019-Test (361 englische Belege, flache Felder company/date/address/total) und CORD-v2-Test (100 indonesische Belege, verschachtelte Felder menu/sub_total/total); Trainings-Splits wurden nie ausgewertet. Beide Engines sahen dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte den stationären Zustand widerspiegeln). Beide Läufe wurden mit error_rate 0.0 auf beiden Datensätzen abgeschlossen (Spalte error_rate in summary_metrics.csv). Der zugrunde liegende Lauf umfasst insgesamt acht Engines; diese Seite vergleicht nur die beiden genannten Engines, andere Engines werden lediglich als Ranking-Kontext zitiert. Die vollständigen Ergebnisse der 8 Engines werden separat unter „Traditional OCR vs. Document Parsing VLMs“ veröffentlicht.

Laufzeitumgebung

• Hardware: Beide Engines liefen auf derselben NVIDIA RTX 4090 (24 GB); GPU-Kosten berechnet zum RunPod-On-Demand-Satz von $0.76/Std., Preis mit Zeitstempel in jedem geschwärzten Manifest des Laufs (August 2026).
• Engines: Standardkonfiguration, kein Fine-Tuning. Versionen festgelegt: EasyOCR 1.7.2 (klassischer CNN + RNN + CTC-Erkenner, ResNet-Feature-Extraktor, GPU) und docTR v1.0.1 (moderne zweistufige neuronale OCR — DETR-artige Transformer-Erkennung + Erkennung, GPU) — gemäß der Modelltabelle im öffentlichen Repo (README.md) und den Lauf-Manifesten. Die SROIE-Zeile von EasyOCR wurde in einem Wiederholungslauf vom 17.08.2026 mit torch 2.8 erneut verifiziert (Wiederholungsläufe r1/r2/r3 byte-identisch); die veröffentlichten CSVs enthalten diese korrigierten Werte.
• 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 beider Engines verwendet wurde.
• Kostenbasis: Wanduhr-Laufzeit × $0.76/Std., einschließlich Modellinitialisierung — Batch-Verarbeitung senkt die Kosten pro Seite.
• Feldnachbearbeitung: Die SROIE-Regex-Feldmetriken sind postprocessed_sroie_receipt_regex_* (Spalten regex_* in field_method_comparison.csv) — Felder, die aus dem OCR-Text durch einen festen, pro Datensatz einmal geschriebenen Mustersatz extrahiert werden. 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 vermischt.

Metrikdefinitionen

• CER (Character Error Rate): Editierdistanz (Einfügungen + Löschungen + Substitutionen) 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/Recall über extrahierte Feldwerte unter Verwendung fester Regex-Muster auf OCR-Text (traditionelle OCR- und 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-Nachverarbeiters (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie vermischt.
• Document-fields exact: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — ein deutlich strengeres Kriterium als das feldbezogene F1.
• Latenz p50/p95 & Seiten/min: Inferenzzeit pro Seite im stationären Zustand (nach Warm-up, ohne Modellladen) und Wanduhr-Durchsatz 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/Std., einschließlich Modellinitialisierung.

Quellenverzeichnis

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

Einschränkungen

• Dokumentumfang — nur Belege: SROIE + CORD. Hier wird nichts an EasyOCRs Sprachbreite von über 80 Sprachen bei Nicht-Beleg-Texten gemessen, nichts am Verhalten von docTR bei Tabellen/Formularen/langen Dokumenten oder an anderen Dokumenttypen. Ziehen Sie von dieser Seite nicht den Schluss, dass eine der beiden Engines „bei allem gewinnt“.
• Stichprobengröße: 361 englische + 100 indonesische Belege. Feld-F1 und CER sind korpusabhängig; Unterschiede von wenigen Hundertsteln im einstelligen Bereich sollten als Rauschen betrachtet werden, nicht als technische Wahrheit — auch wenn die hier dokumentierten Abstände (30 % CER, 48 % WER, 1,66× LLM-F1) weit außerhalb dieser Bandbreite liegen.
• Eine einzige GPU-Stufe und ein einziger Preis: alle Zahlen stammen von einer RTX 4090 bei 0,76 $/Std., Preisstand August 2026 in den Run-Manifesten. Andere GPUs, Multi-GPU-Serving, Batch-Scheduling oder Preisänderungen verschieben Latenz, Durchsatz und Kosten — leiten Sie Kosten vor der Budgetplanung zu aktuellen Tarifen neu ab.
• Ein einziger LLM-Postprozessor: alle LLM-Zeilen verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt das absolute Feld-F1; die Größenordnung des EasyOCR-Paradoxons kann sich mit dem LLM bewegen, auch wenn das beobachtete Muster für diesen einzelnen Postprozessor über beide Datensätze hinweg Bestand hatte. Die LLM-Latenz (~2,0–2,1 s Median bei SROIE, field_method_comparison.csv llm_median_latency_ms) entsteht durch die API und ist nicht Teil der Latenz der jeweiligen Engine.
• Mechanismus des EasyOCR-Paradoxons nicht verifiziert: Das Benchmark dokumentiert, dass EasyOCRs CER-Text der mittleren Stufe die schlechteste LLM-nachgelagerte Felderfassung erzeugt (0,3717 SROIE / 0,3378 CORD) — ein beobachtetes, reproduzierbares Ergebnis unter der Hypothese von Layout-Konventionen des Ausgabetexts, wobei der kausale Mechanismus ausdrücklich nicht isoliert wurde. Behandeln Sie es als gemessenes Ergebnis, mit dem Sie planen, nicht als bewiesene Eigenschaft der Bibliothek.
• Regex-Abstimmung: Das Musterset wurde einmal pro Datensatz geschrieben. Eine pro Format stark abgestimmte Musterbibliothek könnte bei eigenen Layouts höher punkten — zu den Wartungskosten, die das LLM einspart. Der Regex-Feldnachteil von docTR (0,0766 vs. 0,1477) ist eine Eigenschaft dieses festen Instruments, keine Aussage darüber, was ein abgestimmter Parser zurückgewinnen könnte.
• CORD-CER ist keine Qualitätsmessung pro Modell: Die CORD-Ground-Truth enthält Annotationsstruktur, und keine der beiden Engines wurde überwiegend auf Indonesisch trainiert; CORD-CER (~0,91) spiegelt Sprachmismatch + Ground-Truth-Aufblähung wider. CORD-Zeilen werden mit Einordnung zitiert und nie in ein SROIE-Ranking gemischt (Protokollregel).
• Nur zwei Engines: Dieser direkte Vergleich schließt bewusst die anderen sechs Engines des zugrunde liegenden Runs, Cloud-/API-OCR-Dienste und gehostete VLM-APIs aus; deren Latenz- und Preismodelle unterscheiden sich grundlegend von den hier gemessenen lokalen Engines.
• Versions-Pinning: Die Ergebnisse gelten für EasyOCR 1.7.2 und docTR v1.0.1 (August 2026). Neuere Versionen einer der beiden Engines können jede Zahl auf dieser Seite verschieben.

Verwandte Referenzen: PaddleOCR vs EasyOCR Receipt Benchmark · docTR vs Surya2 Receipt Benchmark · Traditionelle OCR vs. Dokument-Parsing-VLMs · Musterabgleich vs. modellbasierte Feldextraktion · Genauigkeit pro Feld messen, nicht pro Zeichen · OCR-Kosten pro 1.000 Seiten

Weiterführende Lektüre: Warum die KI-OCR-Genauigkeit von der traditionellen OCR abweicht · Warum KI-Extraktion bei Bildern besser ist als OCR · Preise für KI-Dokumentextraktion (2026)