PaddleOCR vs EasyOCR bei Belegen
Genauigkeits- vs. Kosten-Benchmark (2026)

Die beiden Engines repräsentieren zwei Generationen von Deep-Learning-OCR. PaddleOCR (PaddlePaddle-basiert, PP-OCR-Architektur, v3.7.0) ist eine moderne zweistufige Pipeline: Eine Erkennungsstufe lokalisiert Textregionen, eine Erkennungsstufe transkribiert sie — entwickelt für hohe Genauigkeit bei gedrucktem Text im großen Maßstab. EasyOCR (PyTorch-basiert, 1.7.2) ist ein klassischer einstufiger CNN + RNN + CTC-Erkenner — ein ResNet-Feature-Extraktor, der ein Sequenzmodell speist, das mit Connectionist Temporal Classification dekodiert wird. Bekannt für eine sehr breite Sprach- und Schriftsystemabdeckung (80+ Sprachen out of the box) und eine berühmt einfache Installation. Die Zeichenfehlerrate (CER) misst Einfügungen, Löschungen und Ersetzungen geteilt durch die Grundwahrheitszeichen — ein CER von 0,204 bedeutet ~20,4 falsch gelesene Zeichen pro 100; die Wortfehlerrate (WER) wendet dieselbe Edit-Distanz-Logik auf Wortebene an. Niedriger ist bei beiden besser.

Textgenauigkeit auf SROIE (englische Belege): PaddleOCRs klarer Vorsprung

Bei den 361 englischen Belegen des SROIE-2019-Testsplits gewinnt die moderne Architektur bei beiden Textmetriken: CER 0,2045 vs. 0,2833 (eine relative Verbesserung von 27,8 %) und WER 0,3256 vs. 0,6158 — EasyOCRs WER ist fast doppelt so hoch. Die WER-Lücke ist größer als die CER-Lücke, was darauf hindeutet, dass EasyOCR zeichenweise Fehler auf diesem Korpus zu Wortfehlern kumuliert. Beide Engines laufen fehlerfrei (error_rate 0,0 in jeder SROIE- und CORD-Zeile der CSV).

Quelle: summary_metrics.csv — Spalten cer und wer, Zeilen sroie_2019. PaddleOCR cer 0,20449 / wer 0,32563; 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: PaddleOCR cer 0.20449 / wer 0.32563; EasyOCR cer 0.28327 / wer 0.61578. Niedrigere CER/WER-Werte sind besser. Keine der beiden Engines ist der Gesamtsieger der Benchmark in puncto Genauigkeit — dieser Titel gehört Surya2 (CER 0.1915) und docTR (CER 0.1971) im selben 8-Engine-Lauf (summary_metrics.csv, Zeilen surya2 und doctr sroie_2019).

Feldextraktion: KIE per Regex und per LLM

Die Textgenauigkeit bewertet Engines; die Feldextraktion ist das, was nachgelagerte Systeme tatsächlich nutzen. Die SROIE-Feldmetriken der Benchmark zielen auf vier flache Belegfelder (Firma, Datum, Adresse, Summe) und verwenden zwei Nachbearbeitungsstufen für den OCR-Text jeder Engine: feste Regex-Muster (der traditionelle OCR- und regelbasierte Ansatz zur Schlüsselinformationsextraktion) und einen LLM-Nachbearbeiter (deepseek-v4-flash bei Temperatur 0) mit strukturiertem Prompt. Per Regex extrahiert PaddleOCR Felder mit 0,3254 Feld-F1 gegenüber EasyOCRs 0,1477 — ein 2,2×-Vorteil; per LLM bleibt die Lücke bei 0,5810 gegenüber 0,3717 (1,56×) bestehen.

Feldwert-F1 ist das harmonische Mittel aus Präzision und Recall über die extrahierten Feldwerte im Vergleich zur Ground Truth — 1,0 bedeutet, dass jedes Belegfeld perfekt wiederhergestellt wurde, 0 bedeutet nichts. Die SROIE-Regex-Feldspalten sind die postprocessed_sroie_receipt_regex_*-Metriken der Benchmark: feste Muster, die auf den OCR-Text jeder Engine angewendet werden (nachbearbeitet, nicht native strukturierte Ausgabe). Beachten Sie den Ranking-Kontext: PaddleOCRs 0,3254 ist das drittbeste Regex-Feldergebnis in der 8-Engine-Benchmark (hinter Unlimited-OCR 0,3376 und PaddleOCR-VL 0,3368) und das beste unter den vier rein traditionellen Engines; EasyOCRs 0,1477 belegt Platz sieben von acht (summary_metrics.csv, field_f1_regex, Zeilen sroie_2019).

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

Tabelle: field_method_comparison.csv — Regex- und LLM-Spalten, Zeilen sroie_2019. Die Regex-Spalten sind Metriken postprocessed_sroie_receipt_regex_*: feste Muster, die auf den OCR-Text jeder Engine angewendet werden. LLM-Nachbearbeitung: deepseek-v4-flash bei Temperatur 0 (Spalte llm_model). Die LLM-Latenz entsteht durch die API und ist getrennt von der Engine-Latenz (summary_metrics.csv latency_p50_ms). “Dokumente mit allen Feldern exakt” ist der Anteil der Dokumente, bei denen jedes Zielfeld exakt übereinstimmte — ein deutlich strengeres Kriterium als das feldbezogene F1; EasyOCR trifft bei 0,28 % der Belege alle vier Felder exakt.

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

Dies ist der markanteste Datenpunkt dieser Seite, und er ist wirklich kontraintuitiv: Der OCR-Text von EasyOCR liegt bei der Zeichengenauigkeit im Mittelfeld (SROIE CER 0,2833, vierter von acht Engines) — doch wenn dieser Text demselben LLM-Nachbearbeitungsprozessor 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 wurde geändert; 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 Downstream-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 (die SROIE-Zeile von EasyOCR 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), es wird jedoch kein kausaler Anspruch erhoben. Die praktische Implikation ist das Gegenteil des Marketing-Anstrichs: Bei diesem Korpus bedeutet die Wahl von EasyOCR für „gut genugen" Text, dass man mit der schlechtesten LLM-Downstream-Feldwiederherstellung aller getesteten Engines rechnen muss.

Quelle: field_method_comparison.csv — llm_field_value_f1, alle acht sroie_2019-Zeilen, jeweils 361 Stichproben (llm_ok_count). LLM-Nachbearbeitungsprozessor 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. EasyOCRs CER (0.2833) belegt den vierten Platz 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.

Die Betriebsgrenzen: Wo EasyOCR wirklich konkurrenzfähig ist

Genauigkeit ist nicht die einzige Achse, und auf der operativen Achse hat EasyOCR echte, gemessene Gegenargumente. Auf derselben RTX 4090 zum selben Preis von $0,76/Std. verarbeitet EasyOCR SROIE für $0,110 pro 1.000 Seiten gegenüber $0,221 bei PaddleOCR (eine 2,0-fache Lücke), erreicht 124,5 Seiten/Min. gegenüber 79,7 (1,56-fach) und hält sein Worst-Case-Ende eng: p95 960,4 ms gegenüber PaddleOCRs 3.331,4 ms First-Page-Spike (eine 3,5-fach engere Verteilung). Sein Fußabdruck ist auch einfacher bereitzustellen — eine einzelne PyTorch-Laufzeit mit breiter Sprachabdeckung, gegenüber dem schwereren Framework-Stack von PaddlePaddle.

Ein scheinbarer Widerspruch verdient eine ehrliche Erklärung: PaddleOCR hat die niedrigere mediane Latenz pro Seite (297,0 ms p50 gegenüber EasyOCRs 413,6 ms), aber die niedrigere Seiten-pro-Minute-Zahl (79,7 gegenüber 124,5). Die beiden Zahlen messen unterschiedliche Uhren. Die Latenz p50 ist die Inferenz pro Seite im stationären Zustand, warm gemessen (Modell bereits geladen); Seiten/Min. ist der Wanduhr-Durchsatz des gesamten Laufs, einschließlich Modellinitialisierung und Batcheffekten. Die kleinere, schneller ladende Laufzeit von EasyOCR gewinnt das Wanduhr-Volumenrennen; die Inferenz pro Seite von PaddleOCR ist einzeln schneller, sobald sie warm ist. Beide Zahlen sind real; sie beschreiben verschiedene Dinge, und eine Arbeitslast, die von Modelllade-Overhead dominiert wird (viele kleine Batches, häufige Kaltstarts), erfährt den Wanduhr-Vorteil von EasyOCR, während eine warme, langlaufende Pipeline den Vorteil von PaddleOCR pro Seite erfährt.

Die Kosten werden als Wanduhr-Laufzeit × der RunPod-RTX-4090-Satz ($0,76/Stunde, Preis in den Laufmanifesten zeitgestempelt) berechnet, einschließlich 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 Inferenzzeiten pro Seite im stationären Zustand, warm gemessen und dann bewertet (Modellladen ausgeschlossen); PaddleOCRs p95 von 3.331 ms ist ein First-Page/Prefill-Spike, nicht sein stationäres Verhalten.

Quelle: summary_metrics.csv — Spalten latency_p50_ms / latency_p95_ms, Zeilen sroie_2019. PaddleOCR p50 296,99 / p95 3331,35; EasyOCR p50 413,64 / p95 960,37. Stationäre Latenz (Messmodus warm_then_scored, Modellladen ausgeschlossen).

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen sroie_2019. PaddleOCR 0,2214, EasyOCR 0,1098. Kosten = Wanduhr-Laufzeit × $0,76/Std. inklusive Modell-Init, Preis in den Laufmanifesten zeitgestempelt (August 2026). Keine der beiden Engines ist die günstigste des Benchmarks — docTR hält diesen mit $0,048 pro 1.000 Seiten (summary_metrics.csv, Zeile doctr/sroie_2019).

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/Std. Preis in Manifests zeitgestempelt); Kosten inklusive Modellinitialisierung. Exakte Werte: PaddleOCR p50 296,99 / p95 3331,35 / 79,71 Seiten/min / $0,2214; EasyOCR p50 413,64 / p95 960,37 / 124,53 Seiten/min / $0,1098. Die Umkehrung von p50 vs. Seiten/min wird im obigen Text erklärt: Inferenz pro Seite im stationären Zustand (PaddleOCR gewinnt) vs. Wanduhr-Durchsatz inklusive Initialisierung und Batch-Effekten (EasyOCR gewinnt).

CORD (indonesische Belege): Beide brechen ein, aber PaddleOCRs LLM-Feldwiederherstellung überlebt

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 brechen beim rohen CER ein: 0,9083 (PaddleOCR) und 0,9185 (EasyOCR), ein sprachbedingter Gleichstand, bei dem beide Engines den Text praktisch nicht lesen können. Gemäß dem Benchmark-Protokoll werden die CORD-Zahlen von der SROIE-Vergleichsbasis ferngehalten — nicht in ein Ranking eingemischt —, da der Ground-Truth-Text von CORD die Annotationsstruktur einbettet, was den rohen CER für jede Engine zusätzlich zur echten Sprachdiskrepanz erhöht.

Die Feldmetriken erzählen eine andere Geschichte als die nahezu identischen CER-Werte. Über den LLM-Nachprozessor hält PaddleOCRs Feld-F1 bei 0,5527 gegenüber EasyOCRs 0,3378 auf CORD — dasselbe SROIE-Muster, erweitert: PaddleOCRs LLM-Downstream-Wiederherstellung übersteht den Sprachschock, den EasyOCRs nicht übersteht, selbst wenn beide Texterkenner auf Zeichenebene versagen. EasyOCRs CORD-LLM-Feld-F1 ist der zweitniedrigste der acht Engines (nur über Tesseracts 0,1627, summary_metrics.csv/field_method_comparison.csv cord_v2-Zeilen) — erneut hinter Engines mit schlechterem CER, das Paradoxon besteht über beide Datensätze hinweg. CORD wird hier für den Kontext der Sprachrobustheit zitiert; es wird bewusst nie mit den SROIE-Zahlen zu einem einzigen Leaderboard zusammengeführt.

Tabelle: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) und field_method_comparison.csv (Feld-F1), cord_v2-Zeilen. CORD-Zahlen nicht in ein SROIE-Ranking einmischen: Der CORD-CER kombiniert echte Sprachabweichung mit einer durch die Annotationstruktur bedingten Inflation in der Ground Truth. Die Regex-Muster wurden für englische Formate geschrieben, weshalb die Regex-Feld-F1 bei beiden Engines auf ~0–2 % einbricht. Die LLM-Feld-F1 von PaddleOCR von 0,5527 auf CORD wiederholt seinen SROIE-Vorteil (0,5810 gegenüber 0,3717) — seine LLM-Downstream-Wiederherstellung übersteht den Sprachschock, den EasyOCR nicht übersteht.

Wer gewinnt wann: Die Übersichtstabelle

„Besser“ hängt vom Arbeitsaufkommen ab, und dieser direkte Vergleich trennt die Achsen klar: Jede Genauigkeitsachse bei englischen Belegen spricht für PaddleOCR; Kosten, Durchsatz in Echtzeit, Latenz am Ende und einfache Bereitstellung sprechen für EasyOCR; und die Meisterschaft in der reinen Texterkennung gehört keinem von beiden (Surya2/docTR) — während EasyOCRs LLM-Downstream-Ergebnis sein größter Vorbehalt ist, nicht sein Verkaufsargument.

Häufig gestellte Fragen

Ist PaddleOCR bei Belegen genauer als EasyOCR?

Ja, bei jeder in diesem Benchmark gemessenen Genauigkeitskennzahl. Bei SROIE 2019: CER 0,2045 vs. 0,2833 (relative Verbesserung um 27,8 %), WER 0,3256 vs. 0,6158, Regex-Feld-F1 0,3254 vs. 0,1477 (2,2×), LLM-nachbearbeiteter Feld-F1 0,5810 vs. 0,3717 (summary_metrics.csv und field_method_comparison.csv, sroie_2019-Zeilen). Keine der beiden Engines ist der Gesamttext-Champion des Benchmarks — diesen Titel halten Surya2 (CER 0,1915) und docTR (0,1971).

Ist EasyOCR günstiger als PaddleOCR?

Ja — etwa 2× günstiger pro 1.000 Seiten bei englischen Belegen: $0,110 vs. $0,221 bei SROIE 2019, bei CORD auf $0,086 vs. $0,342 ansteigend, auf derselben RTX 4090 bei $0,76/Std. inklusive Modellinitialisierungskosten (summary_metrics.csv, cost_per_1000_pages, sroie_2019- und cord_v2-Zeilen). Die insgesamt günstigste Engine des Benchmarks ist docTR mit $0,048 pro 1.000 Seiten.

Welche ist schneller: PaddleOCR oder EasyOCR?

Das hängt davon ab, welche Uhr Sie meinen. PaddleOCR hat eine geringere Median-Latenz im stationären Zustand (297,0 vs. 413,6 ms p50), aber EasyOCR hat einen höheren Wanduhr-Durchsatz (124,5 vs. 79,7 Seiten/Min.), da Seiten/Min. an der Wanduhr Modellinitialisierung und Batcheffekte umfasst und die leichtere Laufzeit von EasyOCR schneller lädt (summary_metrics.csv, latency_p50_ms / pages_per_minute, sroie_2019-Zeilen). Für eine warme, langlaufende Pipeline ist PaddleOCR pro Seite schneller; bei vielen kleinen oder häufigen kalten Batches gewinnt EasyOCR das Wanduhr-Rennen.

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

Dies ist das dokumentierte Paradoxon des Benchmarks, derzeit ohne nachgewiesenen Mechanismus. Der SROIE-CER von EasyOCR (0,2833) belegt Platz vier von acht Engines, doch sein LLM-nachbearbeiteter 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 Konvention im Ausgabeformat, wie EasyOCR Textzeilen anordnet oder verbindet, die die nachgelagerte LLM-Extraktion verschlechtert; sie wird als beobachtetes, reproduzierbares Muster mit unverifiziertem Mechanismus gekennzeichnet (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen).

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

Zwei sich verstärkende Ursachen, die das Protokoll vom SROIE-Ranking trennt: eine echte Sprachdiskrepanz (indonesische Belege außerhalb des Trainingsfokus beider Engines) und eine Aufblähung der Annotationsstruktur im Ground-Truth-Text von CORD — CER liegt bei 0.9083 (PaddleOCR) und 0.9185 (EasyOCR) (summary_metrics.csv, cer, cord_v2-Zeilen). Was sie weiterhin unterscheidet, ist die LLM-Downstream-Wiederherstellung: PaddleOCR 0.5527 vs. EasyOCR 0.3378 Feld-F1 — das SROIE-Muster bleibt bestehen, selbst wenn beide Erkennungsprogramme auf Zeichenebene versagen.

Welche Engine sollte eine Beleg-Pipeline wählen, PaddleOCR oder EasyOCR?

Wenn Ihre Pipeline Felder verarbeitet — extrahierte Werte für Unternehmen, Datum, Summen — ist PaddleOCR der klare Standard bei Belegen: 2,2× Feld-F1 unter Regex, 1,56× unter einem LLM und LLM-Downstream-Wiederherstellung, die den CORD-Sprachschock übersteht (field_method_comparison.csv). Wenn Sie günstiges Massenvolumen, ein enges Worst-Case-Ende, einen schlanken Stack oder eine breite Sprachabdeckung für den Einstieg benötigen, ist EasyOCR auf der operativen Achse wirklich konkurrenzfähig (2× günstiger, 1,56× Wanduhr-Durchsatz, 3,5× engeres p95, 80+ Sprachen) — aber planen Sie vor der Entscheidung sein schwaches LLM-Downstream ein. Diese Ergebnisse gelten für englische und indonesische Belege auf einer GPU-Stufe im August 2026; führen Sie vor Produktionsentscheidungen erneut Tests 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 unter ImageToTableai/benchmark-ocr, mit einem redigierten manifest.json pro Lauf für Umgebungs-Fingerabdrücke. Datensatzdefinitionen stammen aus den unten zitierten SROIE-2019- und CORD-Papieren.

Methodik & Quellen

Protokoll

Diese Seite berichtet einen Direktvergleich aus einem unabhängigen, reproduzierbaren Benchmark-Lauf (offizielle Stufe) — keine Zusammenfassung von Behauptungen Dritter und keine Herstellervergleichsseite. 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 Aufwärmdurchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte im stabilen Zustand erfasst werden). 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 ausschließlich 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 zeitgestempelt in den redigierten Manifests jedes Laufs (August 2026).
• Engines: Standardkonfiguration, kein Feintuning. Versionen festgeschrieben: PaddleOCR 3.7.0 (moderne zweistufige Deep-Learning-OCR — PP-OCR-Erkennung + Texterkennung, GPU) und EasyOCR 1.7.2 (klassisches ResNet+CRNN mit CTC-Dekodierung, GPU) — gemäß der öffentlichen Modelltabelle des Repos (README.md) und den Laufmanifesten. 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: SROIE-Regex-Feldmetriken sind postprocessed_sroie_receipt_regex_* (Regex_*-Spalten in field_method_comparison.csv) — Felder, die durch einen festen Mustersatz aus dem OCR-Text extrahiert wurden. Sie messen OCR + nachgelagerte Extraktion, nicht native strukturierte Ausgabe eines der Modelle; die LLM_*-Spalten messen OCR-Text + LLM-Extraktion. Die beiden Pipelines werden nie vermischt.

Definitionen der Metriken

• 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.
• Feldwert-F1 (Regex): harmonisches Mittel aus Präzision und Recall über extrahierte Feldwerte unter Verwendung fester Regex-Muster auf OCR-Text (traditionelle OCR + regelbasierte KIE-Pipeline). Spalte: regex_field_value_f1. Ein Wert von 0 bedeutet, dass keine Feldwerte wiederhergestellt wurden.
• Feldwert-F1 (LLM): dieselbe Metrik auf der Ausgabe des LLM-Nachbearbeiters (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie vermischt.
• Dokumentfelder exakt: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — eine deutlich strengere Messlatte als das Feld-F1.
• Latenz p50/p95 & Seiten/min: Inferenzzeit pro Seite im stationären Zustand (nach Aufwärmphase, ohne Modellladen) und Wanduhr-Durchsatz inklusive Modellinitialisierung. Sie messen unterschiedliche Uhren; die p50-vs.-Seiten/min-Inversion auf dieser Seite ist ein Unterschied im Messmodell, kein Fehler.
• 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 paddleocr- und easyocr-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, Dokumentfelder-exakt, llm_median_latency_ms, Token-Anzahl. Jede Regex/LLM-Feld-F1-Zahl stammt aus den paddleocr- und easyocr-Zeilen hier (und aus allen acht sroie_2019-Zeilen in der Paradox-Tabelle).
3. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository mit den Ergebnis-CSVs, redigierten Lauf-Manifesten, eingefrorenem Protokoll und Datensatz-Stichprobenlisten (feste Test-Splits) zur Reproduktion.
4. results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf (16 Läufe) mit Modellversionen, GPU/Treiber, torch/CUDA/Python-Versionen, Kostenmetadaten mit Preiszeitstempel 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. Nichts hier misst die PP-Structure-Layout-/Tabellen-/Dokumentfunktionen von PaddleOCR, die Sprachbreite von EasyOCR (80+ Sprachen) bei Nicht-Beleg-Text oder andere Dokumenttypen. Verwenden Sie diese Seite nicht, um zu schließen, dass eine Engine „bei allem gewinnt".
• Stichprobengröße: 361 englische + 100 indonesische Belege. Feld-F1 und CER sind korpusabhängig; einstellige Unterschiede von einigen Hundertstel sollten als Rauschen behandelt werden, nicht als technische Wahrheit — obwohl die hier dokumentierten Lücken (27,8 % CER, 2,2× Regex-F1) weit außerhalb dieses Bereichs liegen.
• Einzelne GPU-Stufe und einzelner Preis: Alle Zahlen stammen von einer RTX 4090 bei 0,76 $/Std., Preiszeitstempel August 2026 in den Run-Manifesten. Andere GPUs, Multi-GPU-Serving, Batch-Scheduling oder Preisänderungen verschieben Latenz, Durchsatz und Kosten — leiten Sie Kosten zu aktuellen Tarifen neu ab, bevor Sie budgetieren.
• Einzelner LLM-Postprozessor: 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 bewegen, obwohl das beobachtete Muster für diesen einzelnen Postprozessor über beide Datensätze hinweg galt. LLM-Latenz (~1.817–2.005 ms Median bei SROIE, field_method_comparison.csv llm_median_latency_ms) ist API-bedingt und nicht Teil der Latenz einer der Engines.
• Mechanismus des EasyOCR-Paradoxons unverifiziert: Der Benchmark dokumentiert, dass EasyOCRs CER-Text der mittleren Stufe die schlechteste LLM-Downstream-Feldwiederherstellung erzeugt (0,3717 SROIE / 0,3378 CORD) — ein beobachtetes, reproduzierbares Ergebnis unter der Hypothese von Textlayout-Konventionen in der Ausgabe, wobei der kausale Mechanismus ausdrücklich nicht isoliert wurde. Behandeln Sie es als gemessenes Ergebnis, um das Sie herum planen können, 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 entfernt.
• CORD-CER ist keine Qualitätsmessung pro Modell: CORD-Ground-Truth enthält Annotationsstruktur und keine der Engines wurde überwiegend auf Indonesisch trainiert; CORD-CER (~0,91) spiegelt Sprachmismatch + Ground-Truth-Aufblähung wider. CORD-Zeilen werden mit Rahmung zitiert und nie in ein SROIE-Ranking gemischt (Protokollregel).
• Versions-Pinning: Ergebnisse gelten für PaddleOCR 3.7.0 und EasyOCR 1.7.2 (August 2026). Neuere Versionen einer der Engines können jede Zahl auf dieser Seite verschieben.

Verwandte Referenzen: docTR vs. Surya2-Beleg-Benchmark · der OCR- vs. VLM-Direktvergleich · Regex-Regeln gegen LLM-Extraktion · Zeichengenauigkeit vs. Feldgenauigkeit · Beleg-OCR-Genauigkeit

Verwandte Lektüre: wie KI-OCR mit klassischem OCR verglichen wird · KI-Bildextraktion im Vergleich zu traditionellem OCR · KI-Dokumentextraktions-Preise (2026)