PaddleOCR vs EasyOCR bei Quittungen
Genauigkeit vs. Kosten-Benchmark (2026)

Die beiden Engines repräsentieren zwei Generationen von Deep-Learning-OCR. PaddleOCR (basiert auf PaddlePaddle, PP-OCR-Architektur, v3.7.0) ist eine moderne Zweistufen-Pipeline: Eine Erkennungsstufe lokalisiert Textregionen, dann transkribiert eine Erkennungsstufe sie — entwickelt für hohe Genauigkeit bei gedrucktem Text im großen Maßstab. EasyOCR (basiert auf PyTorch, 1.7.2) ist ein klassischer Einzel-Durchlauf-CNN + RNN + CTC-Erkennungsmodell — ein ResNet-Feature-Extraktor, der ein Sequenzmodell speist, das mit Connectionist Temporal Classification decodiert wird. Es ist bekannt für sehr breite Sprach- und Schriftabdeckung (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 Zeichen der Referenz — eine CER von 0,204 bedeutet ~20,4 falsch gelesene Zeichen pro 100; die Wortfehlerrate (WER) wendet dieselbe Edit-Distanz-Logik auf Wortebene an. Bei beiden gilt: Je niedriger, desto besser.

Textgenauigkeit bei SROIE (englische Quittungen): PaddleOCR’s klarer Vorsprung

Bei den 361 englischen Quittungen des SROIE 2019-Testsiegs 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 — EasyOCR’s WER ist fast doppelt so hoch. Die WER-Lücke ist größer als die CER-Lücke, was darauf hindeutet, dass EasyOCR Zeichenfehler in diesem Corpus zu ganzen Wortfehlern kumuliert. Beide Engines laufen fehlerfrei (error_rate 0,0 in jeder SROIE- und CORD-Zeile in der CSV).

Quelle: summary_metrics.csv — cer- und wer-Spalten, sroie_2019-Zeilen. PaddleOCR cer 0,20449 / wer 0,32563; EasyOCR cer 0,28327 / wer 0,61578. Je niedriger, desto 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. Niedrigerer CER/WER ist besser. Keine der Engines ist der Gesamtgenauigkeits-Champion des Benchmarks — dieser Titel gehört Surya2 (CER 0.1915) und docTR (CER 0.1971) im selben 8-Engine-Lauf (summary_metrics.csv, surya2 und doctr sroie_2019 Zeilen).

Feldextraktion: KIE über Regex und über ein LLM

Die Textgenauigkeit ordnet die Engines an; die Feldextraktion ist das, was nachgelagerte Systeme tatsächlich verarbeiten. Die SROIE-Feldmetriken des Benchmarks zielen auf vier flache Belegfelder (Unternehmen, Datum, Adresse, Gesamtbetrag) ab und verwenden für jedes Engine-OCR-Text zwei Nachbearbeitungsverfahren: feste Regex-Muster (der traditionelle OCR- + regelbasierte KIE-Ansatz) und einen LLM-Nachbearbeiter (deepseek-v4-flash bei Temperatur 0) mit einem strukturierten Prompt. Über Regex extrahiert PaddleOCR Felder mit 0.3254 Feld-F1, EasyOCR mit 0.1477 — ein 2,2×-Vorsprung; über das LLM bleibt der Abstand bei 0.5810 gegenüber 0.3717 (1,56×).

Das Feldwert-F1 ist der harmonische Mittelwert von Präzision und Recall über die extrahierten Feldwerte gegenüber dem Ground Truth — 1,0 bedeutet, jedes Belegfeld wurde perfekt wiederhergestellt, 0 bedeutet nichts. Die SROIE-Regex-Feldspalten sind die postprocessed_sroie_receipt_regex_*-Metriken des Benchmarks: feste Muster, die auf den OCR-Text jeder Engine angewendet werden (nachbearbeitet, nicht native strukturierte Ausgabe). Beachten Sie den Ranking-Kontext: PaddleOCR’s 0.3254 ist das drittbeste Regex-Feld-Ergebnis im 8-Engine-Benchmark (hinter Unlimited-OCR 0.3376 und PaddleOCR-VL 0.3368) und das Beste unter den vier rein traditionellen Engines; EasyOCR’s 0.1477 rangiert auf dem siebten von acht Plätzen (summary_metrics.csv, field_f1_regex, sroie_2019 Zeilen).

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).

Tabelle: field_method_comparison.csv — regex- und llm-Spalten, sroie_2019-Zeilen. Die Regex-Spalten sind postprocessed_sroie_receipt_regex_*-Metriken: feste Muster, die auf den OCR-Text jeder Engine angewendet werden. LLM-Nachbearbeiter: deepseek-v4-flash bei Temperatur 0 (llm_model-Spalte). Die LLM-Latenz wird durch die API verursacht und ist von der Engine-Latenz getrennt (summary_metrics.csv latency_p50_ms). „Dokumente mit exakten Feldern" ist der Anteil der Dokumente, bei denen jedes Zielfeld exakt übereinstimmte — ein viel strengerer Maßstab als der Feld-F1-Wert; EasyOCR hat bei 0,28 % der Belege alle vier Felder exakt richtig.

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

Dies ist der auffälligste Datenpunkt dieser Seite, und er ist tatsächlich kontraintuitiv: EasyOCR’s OCR-Text liegt im Mittelfeld bei der Zeichengenauigkeit (SROIE CER 0.2833, vierter von acht Engines) — doch wenn dieser Text demselben LLM-Nachbearbeiter wie bei allen anderen Engines zugeführt 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 hat sich 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 nachgelagerte LLM-Feldextraktion aus Gründen zu beeinträchtigen, die nicht mit der rohen Zeichengenauigkeit zusammenhängen. Der Benchmark hat diesen Mechanismus nicht isoliert; das Ergebnis wird hier als reproduzierbar und stabil dokumentiert (EasyOCR’s SROIE-Zeile wurde in einem torch 2.8-Rerun am 17.08.2026 überprüft, r1/r2/r3 byte-identisch; die veröffentlichte CSV enthält bereits diese korrigierten Werte), aber es wird kein kausaler Anspruch erhoben. Die praktische Implikation ist das Gegenteil der Marketing-Fassade: Bei diesem Korpus bedeutet die Wahl von EasyOCR für “ausreichend guten” Text, mit der schlechtesten LLM-nachgelagerten Feldwiederherstellung aller getesteten Engines zu kalkulieren.

Quelle: field_method_comparison.csv — llm_field_value_f1, alle acht sroie_2019-Zeilen, jeweils 361 Samples (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.

Tabelle: field_method_comparison.csv — llm_field_value_f1, alle sroie_2019-Zeilen; CER-Spalte aus summary_metrics.csv, cer, sroie_2019-Zeilen. EasyOCR’s CER (0.2833) rangiert auf Platz vier von acht — mittlerer Text mit der schlechtesten LLM-Nachbearbeitung der Feldextraktion (0.3717, unterhalb von Tesseract’s 0.4389). Das Paradoxon ist als beobachtet und reproduzierbar dokumentiert; sein Mechanismus wird durch dieses Benchmark nicht isoliert.

Der Einsatzbereich: Wo EasyOCR wirklich wettbewerbsfähig ist

Die Genauigkeit ist nicht die einzige Achse, und auf der operativen Achse hat EasyOCR echte, gemessene Vorteile. Auf demselben RTX 4090 zum selben Preis von $0,76/Stunde verarbeitet EasyOCR SROIE zu $0,110 pro 1.000 Seiten gegenüber PaddleOCR’s $0,221 (ein 2,0-facher Unterschied), hält 124,5 Seiten/Minute gegenüber 79,7 (1,56-fach) und behält seinen schlechtesten Fall eng: p95 960,4 ms gegenüber PaddleOCR’s 3.331,4 ms Spitze bei der ersten Seite (ein 3,5-fach engerer Bereich). Sein Einsatz ist auch einfacher zu implementieren — eine einzige PyTorch-Laufzeitumgebung mit breiter Sprachabdeckung, im Gegensatz zu PaddlePaddle’s schwererem Framework-Stack.

Ein scheinbarer Widerspruch verdient eine ehrliche Erklärung: PaddleOCR hat die niedrigere mediane Latenz pro Seite (297,0 ms p50 gegenüber EasyOCR’s 413,6 ms), aber die niedrigere Seiten-pro-Minute-Zahl (79,7 gegenüber 124,5). Die beiden Zahlen messen verschiedene Uhren. Die Latenz p50 ist die Inferenz pro Seite im稳态, gemessen warm (Modell bereits geladen); Seiten/Minute ist der Durchsatz der gesamten Laufzeit anhand der Echtzeituhr, was die Modellinitialisierung und Stapel-Effekte einschließt. EasyOCR’s kleinere, schneller ladende Laufzeitumgebung gewinnt den Durchsatz-Wettlauf anhand der Echtzeituhr; PaddleOCR’s Inferenz pro Seite ist einzeln schneller, sobald das Modell warm ist. Beide Zahlen sind real; sie beschreiben unterschiedliche Dinge, und eine Arbeitslast, die von der Modell-Lade-Überlast dominiert wird (viele kleine Stapel, häufige Kaltstarts), wird EasyOCR’s Vorteil anhand der Echtzeituhr erfahren, während eine warme, lang laufende Pipeline PaddleOCR’s Vorteil pro Seite erfahren wird.

Die Kosten werden berechnet als Laufzeit anhand der Echtzeituhr × der 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 Seiten pro Minute anhand der Echtzeituhr, einschließlich derselben Initialisierung. Die Latenz p50/p95 sind稳态 Inferenzzeiten pro Seite, gemessen warm-und-dann-bewertet (Modellladen ausgeschlossen); PaddleOCR’s p95 von 3.331 ms ist eine Spitze bei der ersten Seite/Vorabfüllung, nicht sein稳态 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.稳态 Latenz (Messmodus warm_then_scored, schließt Modellladen aus).

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen sroie_2019. PaddleOCR 0,2214, EasyOCR 0,1098. Kosten = Laufzeit anhand der Echtzeituhr × $0,76/Stunde einschließlich Modellinit, Preis mit Zeitstempel in Lauf-Manifesten (August 2026). Keine der Engines ist die günstigste im Benchmark — docTR hält das 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/Stunde Preis mit Zeitstempel in Manifesten); Kosten beinhalten Modellinitialisierung. Exakte Werte: PaddleOCR p50 296.99 / p95 3331.35 / 79.71 pg/min / $0.2214; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. Die p50-gegen-Seiten/Minuten-Umkehr wird im vorherigen Text erklärt: Echtzeit-Inferenz pro Seite (PaddleOCR gewinnt) vs. Echtzeit-Durchsatz inklusive Initialisierung und Batch-Effekte (EasyOCR gewinnt).

CORD (Indonesische Belege): Beide brechen ein, aber PaddleOCR’s LLM-Feldwiederherstellung überlebt

Keine der beiden Engines wurde überwiegend auf indonesischen Belegen trainiert, sodass CORD v2 (100 Beispiele, verschachtelte Felder menu/sub_total/total) als sprachübergreifender Stresstest dient — und beide brechen beim rohen CER ein: 0.9083 (PaddleOCR) und 0.9185 (EasyOCR), ein Sprach-Mismatch-Wasch mit beiden Engines, die den Text effektiv nicht lesen können. Gemäß dem Benchmark-Protokoll werden CORD-Zahlen von SROIE-Vergleichen ferngehalten — nicht in ein Ranking eingemeischt —, weil 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 erzählen eine andere Geschichte als die nahezu identischen CERs. Über den LLM-Nachbearbeiter hält PaddleOCR’s Feld-F1 bei 0.5527 gegenüber EasyOCR’s 0.3378 auf CORD — dasselbe SROIE-Muster, erweitert: PaddleOCR’s LLM-abwärts gerichtete Wiederherstellung hält dem Sprachschock stand, dem EasyOCR’s nicht standhält, selbst wenn beide Texterkennungs-Engines auf Zeichenebene versagen. EasyOCR’s CORD LLM-Feld-F1 ist der zweitniedrigste der acht Engines (nur über Tesserals 0.1627, summary_metrics.csv/field_method_comparison.csv cord_v2-Zeilen) — wiederum hinter Engines mit schlechterem CER, wobei das Paradoxon über beide Datensätze hinweg anhält. CORD wird hier für den Kontext der Sprachrobustheit zitiert; es wird absichtlich nie mit den SROIE-Zahlen zu einer einzigen Rangliste zusammengefasst.

Tabelle: summary_metrics.csv (CER / cost_per_1000_pages / pages_per_minute) und field_method_comparison.csv (Feld-F1), cord_v2-Zeilen. Vermischen Sie keine CORD-Zahlen mit irgendeinem SROIE-Ranking: Der CORD-CER kombiniert echte Sprachunterschiede mit einer Annotation-Struktur-Inflation in den Ground-Truth-Daten. Die Regex-Muster wurden für englische Formate geschrieben, weshalb das Feld-F1 von Regex bei beiden Engines auf ~0–2% einbricht. PaddleOCR’s LLM-Feld-F1 von 0,5527 auf CORD wiederholt seinen SROIE-Vorteil (0,5810 vs. 0,3717) — seine LLM-Downstream-Erholung übersteht den Sprachschock, den EasyOCR’s nicht übersteht.

Wer gewinnt wann: Die Zusammenfassungsmatrix

“Besser” ist arbeitslastabhängig, und dieser direkte Vergleich trennt die Achsen sauber: Jede Genauigkeitsachse bei englischen Quittungen bevorzugt PaddleOCR; Kosten, Durchsatz, Spitzenlatenz und Einfachheit der Bereitstellung bevorzugen EasyOCR; und die reine Textgenauigkeitsmeisterschaft gehört keinem (Surya2/docTR) — während EasyOCR’s LLM-Downstream-Ergebnis sein größter Vorbehalt ist, nicht sein Verkaufsargument.

Häufig gestellte Fragen

Ist PaddleOCR bei Quittungen genauer als EasyOCR?

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

Ist EasyOCR günstiger als PaddleOCR?

Ja — etwa 2× günstiger pro 1.000 Seiten bei englischen Quittungen: $0,110 vs. $0,221 bei SROIE 2019, steigend auf $0,086 vs. $0,342 bei CORD, auf demselben RTX 4090 mit $0,76/Stunde inkl. Modellinitialisierung (summary_metrics.csv, cost_per_1000_pages, sroie_2019- und cord_v2-Zeilen). Der insgesamt günstigste Engine im Benchmark ist docTR mit $0,048 pro 1.000 Seiten.

Was ist schneller: PaddleOCR oder EasyOCR?

Das hängt davon ab, was Sie mit „Schnelligkeit" meinen. PaddleOCR hat eine niedrigere mediane Latenz im stabilen Zustand (297,0 vs. 413,6 ms p50), aber EasyOCR hat einen höheren Durchsatz in Echtzeit (124,5 vs. 79,7 Seiten/Minute), da der Echtzeit-Durchsatz Modellinitialisierung und Batch-Effekte einschließt und EasyOCR's leichtere Laufzeitumgebung schneller startet (summary_metrics.csv, latency_p50_ms / pages_per_minute, sroie_2019-Zeilen). Für eine warme, lang laufende Pipeline ist PaddleOCR pro Seite schneller; für viele kleine oder häufige Kalibrierungs-Batches gewinnt EasyOCR das Echtzeit-Rennen.

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 Ausgabeformat-Konvention in der Art und Weise, 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).

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

Zwei sich verstärkende Ursachen, die das Protokoll von der SROIE-Rangliste getrennt hält: eine echte Sprachdiskrepanz (indonesische Belege außerhalb des Trainingsfokus beider Engines) und eine Aufblähung der Annotationsstruktur im CORD-Ground-Truth-Text — der CER liegt bei 0.9083 (PaddleOCR) und 0.9185 (EasyOCR) (summary_metrics.csv, cer, cord_v2-Zeilen). Was sie weiterhin unterscheidet, ist die LLM-Nachbearbeitung: PaddleOCR 0,5527 vs. EasyOCR 0,3378 Feld-F1 — das SROIE-Muster setzt sich fort, selbst wenn beide Erkennungsmodelle auf Zeichenebene versagen.

Welchen Engine sollte eine Belegverarbeitung wählen, PaddleOCR oder EasyOCR?

Wenn Ihre Pipeline Felder verarbeitet — extrahierte Werte für Unternehmen, Datum, Summen —, ist PaddleOCR die klare Standardwahl für Belege: 2,2× Feld-F1 unter Regex, 1,56× unter einem LLM und eine LLM-Nachbearbeitung, die den CORD-Schock übersteht (field_method_comparison.csv). Wenn Sie günstiges Volumen, einen engen Worst-Case-Schwanz, einen leichten Stack oder eine breite Sprachabdeckung zum Einstieg benötigen, ist EasyOCR im operativen Bereich wirklich wettbewerbsfähig (2× günstiger, 1,56× Durchsatz, 3,5× engere p95, 80+ Sprachen) — aber kalkulieren Sie seine schwache LLM-Nachbearbeitung ein, bevor Sie sich festlegen. Diese Ergebnisse gelten für englische und indonesische Belege auf einer GPU-Stufe im August 2026; führen Sie die Tests vor Produktionsentscheidungen auf Ihrem Zielkorpus erneut durch (siehe Einschränkungen).

Woher stammen die Zahlen auf dieser Seite?

Jede Zahl ist eine Zeile der veröffentlichten CSVs des internen 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 unveröffentlichten manifest.json pro Durchlauf für Umgebungsfingerabdrücke. Datensatzdefinitionen stammen aus den unten zitierten SROIE-2019- und CORD-Papers.

Methodik & Quellen

Protokoll

Diese Seite präsentiert einen direkten Vergleich aus einem unabhängigen, reproduzierbaren Benchmark-Lauf (offizielle Stufe) — keine Umfrage von Drittanbieter-Aussagen und keine Hersteller-Vergleichsseite. Nur feste Test-Splits: SROIE 2019 test (361 englische Quittungen, flache Felder Firma/Datum/Adresse/Summe) und CORD v2 test (100 indonesische Quittungen, verschachtelte Felder Menü/Teilsumme/Summe); Trainings-Splits wurden nie ausgewertet. Beide Engines erhielten dieselben Bilder, dieselben Ground-Truth-Daten und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenz-Werte 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 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-Tarif von $0.76/hr, Preis-Stempel im redaktierten Manifest jedes Laufs (August 2026).
• Engines: Out-of-the-box, kein Fine-Tuning. Versionen fixiert: PaddleOCR 3.7.0 (moderne zweistufige Deep-Learning-OCR — PP-OCR Detektion + Erkennung, GPU) und EasyOCR 1.7.2 (klassisches ResNet+CRNN mit CTC-Dekodierung, GPU) — laut Modelltabelle im öffentlichen Repo (README.md) und den Lauf-Manifesten. Die SROIE-Zeile von EasyOCR wurde in einem erneuten Lauf am 17.08.2026 mit torch 2.8 überprüft (Wiederholungsläufe r1/r2/r3 byte-identisch); die veröffentlichten CSVs enthalten diese korrigierten Werte.
• LLM-Nachbearbeitung: 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 beider Engines.
• Kostenbasis: Echtzeitlaufzeit × $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 wurden. Sie messen OCR + nachgelagerte Extraktion, nicht native strukturierte Ausgabe durch 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.
• Feld-Wert-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.
• Feld-Wert-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 kombiniert.
• Dokumentfelder exakt: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — ein viel strengerer Maßstab als der Feld-F1-Wert.
• Latenz p50/p95 & Seiten/min: stationäre Inferenzzeit pro Seite (warm-then-scored, ohne Modell-Laden) und Durchsatz in Echtzeit inklusive Modellinitialisierung. Sie messen unterschiedliche Uhren; die p50-vs-Seiten/min-Invertierung 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/Stunde, inklusive 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 Durchsatz-Zahl auf dieser Seite lässt sich auf die paddleocr- und easyocr-Zeilen hier zurückführen.
2. field_method_comparison.csv (GitHub raw). 16 Zeilen; Spalten model, dataset, llm_model (= deepseek-v4-flash), Regex/LLM Feld-Wert-Genauigkeit und F1, Dokumentfelder-exakt, llm_median_latency_ms, Token-Anzahlen. Jede Regex/LLM-Feld-F1-Zahl lässt sich auf die paddleocr- und easyocr-Zeilen hier (und auf alle acht sroie_2019-Zeilen in der Paradox-Tabelle) zurückführen.
3. ImageToTableai/benchmark-ocr Repository. Öffentliches Repository mit den Ergebnis-CSVs, geschwärzten Ausführungsmanifesten, eingefrorenem Protokoll und Datensatz-Beispiellisten (feste Testsplits) zur Reproduktion.
4. 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.
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 Felda Schema und Lizenz (CC-BY-4.0).

Einschränkungen

• Dokumentbereich — nur Belege: SROIE + CORD. Hier wird weder PaddleOCRs PP-Structure-Layout-/Tabellen-/Dokumentfähigkeiten noch EasyOCRs 80+ Sprachenbreite bei Nicht-Belegtexten noch ein anderer Dokumenttyp gemessen. Verwenden Sie diese Seite nicht, um zu schlussfolgern, dass eine der Engines „in allem gewinnt."
• Stichprobengröße: 361 englische + 100 indonesische Belege. Feld-F1 und CER sind korpusabhängig; einstellige Unterschiede von einigen Hundertsteln sollten als Rauschen und nicht als ingenieurtechnische Wahrheit behandelt werden — wobei 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 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ößenordnung 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 (~1.817–2.005 ms 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 selbst.
• EasyOCR-Paradoxon-Mechanismus nicht verifiziert: Der Benchmark dokumentiert, dass EasyOCRs mittleres CER-Text das schlechteste LLM-nachgelagerte Wiederherstellungsergebnis (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 auf eigenen Layouts höher punkten — mit dem Wartungsaufwand, den das LLM eliminiert.
• 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 + Grundwahrheitsinflation wider. CORD-Zeilen werden mit Einordnung zitiert und nie in irgendein SROIE-Ranking eingeflossen (Protokollregel).
• Versionsspezifikation: Die 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 · Traditionelles OCR vs Dokument-Parsing-VLMs · Regex vs LLM-Feldextraktion · Feld- vs Zeichenebene-Genauigkeit · Beleg-OCR-Genauigkeit

Verwandte Lektüre: KI-OCR vs Traditionelles OCR-Genauigkeit · KI-Bilddatenextraktion vs Traditionelles OCR · KI-Dokumentextraktionspreise (2026)