Tesseract vs PaddleOCR bei Belegen
Legacy-CPU vs. moderne GPU (2026)

Was die beiden Engines sind: 35 Jahre OCR vs. eine CNN-Zweistufen-Pipeline

Die gesamte Geschichte dieser Seite ist eine Architekturlücke. Tesseract ist die klassische Open-Source-OCR-Engine — ursprünglich in den 1980er Jahren bei HP entwickelt und 2005 von Google als Open Source veröffentlicht, weshalb sie auf rund 35 Jahre Entwicklungsgeschichte zurückblickt. Ihre Pipeline ist traditionelle Computer Vision: adaptive Binarisierung, Seitenanalyse, Connected-Component-Analyse und Zeichenerkennung — seit Version 4 LSTM-basiert — alles läuft auf der CPU, ohne GPU-Abrechnung in diesem Benchmark (compute_type = cpu in der CSV). PaddleOCR ist eine moderne Deep-Learning-Engine aus dem PaddlePaddle-Ökosystem: eine zweistufige Pipeline in der PP-OCR-Familie — eine Erkennungsstufe, die Textregionen lokalisiert (DBNet-Stil), dann eine Erkennungsstufe, die sie transkribiert — läuft auf der GPU. Eine Engine liest, indem sie Zeichenformen mit gelernten Mustern abgleicht; die andere liest, indem sie lernt, wo Text ist und was er sagt. Dieser Benchmark stellt beide vor dieselben Belege, dasselbe Protokoll, dieselbe Maschine.

Warum dieser Mechanismus wichtig ist: Tesseracts Ansatz ist kostengünstig und benötigt keine GPU — aber sein Zeichenmodell ist ein eingefrorenes Jahrzehnt klassischer Erkennung, was sich als harte Obergrenze für die Textqualität erweist. PaddleOCRs Ansatz kostet GPU-Zeit, liest aber deutlich saubereren Text. Die Aufgabe des Benchmarks ist es, beiden Seiten dieses Kompromisses aus einem kontrollierten Lauf eine Zahl zuzuordnen — und die Überraschung ist, wie schmal die Betriebskostenseite des Kompromisses tatsächlich ausfiel.

Zeichengenauigkeit: Die moderne Architektur gewinnt jede Textmetrik

Bei SROIE 2019 ist die Textgenauigkeitslücke groß und einseitig: CER 0,2045 (PaddleOCR) vs. 0,3347 (Tesseract) — eine relative Verbesserung von 39% — und WER 0,3256 vs. 0,5591, eine relative Lücke von 42%. Tesseracts CER von 0,3347 belegt den fünften Platz der acht Engines im zugrunde liegenden Lauf — Mittelfeld, nicht Letzter — aber jede Engine darüber außer einer ist eine Deep-Learning-Engine, und die Lücke zwischen Tesseract und der Deep-Learning-Stufe (beste: Surya2 0,1915, docTR 0,1971) ist größer als die Lücke zwischen diesen Engines und PaddleOCR (0,2045, Dritter).

Die Zeichenfehlerrate (CER) ist der klassische OCR-Maßstab: Einfügungen, Löschungen und Ersetzungen geteilt durch die Grundwahrheitszeichen — ein CER von 0,335 bedeutet etwa 33,5 falsch gelesene Zeichen pro 100. Die Wortfehlerrate (WER) wendet dieselbe Editierdistanzberechnung auf Wortebene an. Beide sind niedriger-besser. Dass die WER-Lücke (42%) größer ist als die CER-Lücke (39%), bedeutet, dass sich Tesseracts Zeichenfehler in diesem Korpus zu Wortfehlern summieren — die klassische Fehlerart, die ein nachgelagerter Feldextraktor direkt übernimmt.

Quelle: summary_metrics.csv — Spalten cer und wer, Zeilen sroie_2019. PaddleOCR cer 0,20449 / wer 0,32563; Tesseract cer 0,33468 / wer 0,55915. 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: Tesseract cer 0.33468 / wer 0.55915; PaddleOCR cer 0.20449 / wer 0.32563. Niedrigere CER/WER sind besser. Ranking-Kontext aus derselben CSV: SROIE-CER über alle acht Engines: surya2 0.1915, doctr 0.1971, PaddleOCR 0.2045 (3.), easyocr 0.2833, Tesseract 0.3347 (5.), paddleocr_vl 0.3370, docling 0.5909, unlimited_ocr 0.6552. Keiner der beiden Engines ist hier der Genauigkeits-Champion des Benchmarks — docTR und Surya2 halten die beiden besten CER-Plätze.

Feldextraktion: Die Lücke, die Produktionsentscheidungen bestimmt

Textgenauigkeit ordnet Engines ein; Feldextraktion ist das, was nachgelagerte Systeme tatsächlich konsumieren. Die SROIE-Feldmetriken des Benchmarks zielen auf vier flache Belegfelder (Firma, Datum, Adresse, Gesamtbetrag) 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 einem strukturierten Prompt. Über Regex extrahiert PaddleOCR Felder mit 0.3254 Feld-F1 gegenüber Tesseracts 0.2335 — ein 1.39×-Vorteil; über den LLM bleibt die Lücke bei 0.5810 gegenüber 0.4389 (1.32×) bestehen. Der LLM-Hebel hilft beiden Engines, startet aber von Tesseracts schwächerer Basis — und das Obergrenzen-Argument, das Produktionspipelines entscheidet, liegt einen Abschnitt weiter unten.

Der Feldwert-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, dass nichts wiederhergestellt wurde. Die SROIE-Regex-Feldspalten sind die Metriken postprocessed_sroie_receipt_regex_* des Benchmarks: feste Muster, die auf den OCR-Text jeder Engine angewendet werden — nachbearbeitet, nicht nativer strukturierter Output. Einordnung im Ranking: Der Regex-F1 von PaddleOCR mit 0,3254 ist das beste Ergebnis unter den vier rein traditionellen Engines im 8-Engine-Benchmark (nur hinter Unlimited-OCR 0,3376 und PaddleOCR-VL 0,3368); Tesseract erreicht mit 0,2335 das viertbeste Regex-Ergebnis insgesamt (summary_metrics.csv, field_f1_regex, sroie_2019-Zeilen) — die klassische Engine ist ein Mittelfeld-Feldextraktor bei sauberem englischem Text, und genau dort verliert sie ihre Wettbewerbsfähigkeit.

Quelle: field_method_comparison.csv — Spalten regex_field_value_f1 / llm_field_value_f1, sroie_2019-Zeilen (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- und LLM-Spalten, sroie_2019-Zeilen. Die Regex-Spalten sind die 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 über die API und ist von der Engine-Latenz getrennt (summary_metrics.csv latency_p50_ms). “Dokumente mit allen Feldern exakt” ist der Anteil der Dokumente, bei denen jedes Zielfeld exakt übereinstimmte — eine viel strengere Messlatte als das F1 pro Feld. Ranking-Kontext (llm_field_value_f1, alle sroie_2019-Zeilen): PaddleOCR 0.5810 belegt Platz 5 von 8; Tesseract 0.4389 belegt Platz 7, nur vor EasyOCR mit 0.3717.

Die Überraschung: CPU-Durchsatzparität bei der Wanduhrzeit

Das schlagzeilenträchtige Ergebnis dieser Seite ist das, was kein Vergleich eines Drittanbieters dokumentiert: Bei denselben Belegen erreicht eine reine CPU-Engine mit klassischem Ansatz eine moderne GPU-Engine bei der Wanduhrzeit in Seiten pro Minute — 78,6 gegenüber 79,7 (PaddleOCR), etwa 1,4% auseinander, statistische Parität. Die klassische Engine ist nicht “langsam bei Volumen”: Sie ist langsam pro Seite, aber stabil — und bei diesem Korpus übertrifft sie vier der sieben GPU-Engines im zugrunde liegenden Lauf (docling 56,7, paddleocr_vl 68,2, unlimited_ocr 34,4, surya2 12,1 Seiten/min).

Das scheint ein Widerspruch zu den Latenzzahlen zu sein, und es verdient eine ehrliche Aufarbeitung statt einer Fußnote. Die Latenz p50 ist die Inferenz pro Seite im eingeschwungenen Zustand, warm gemessen und bewertet, ohne Modellladezeit — PaddleOCRs 297,0 ms sind tatsächlich schneller als Tesseracts 670,9 ms. Seiten pro Minute ist der Wanduhrzeit-Durchsatz des gesamten Laufs, einschließlich Modellinitialisierung und Batcheffekten. Rechnet man den Durchsatz der CSV in Wanduhrzeit pro Seite um (60 Sekunden ÷ Seiten pro Minute): PaddleOCR benötigt ~753 ms pro Seite Wanduhrzeit gegenüber einem p50 von 297 ms — etwa 456 ms pro Seite für Initialisierung/Vorbelegung und Batch-Overhead; Tesseract benötigt ~763 ms pro Seite Wanduhrzeit gegenüber einem p50 von 671 ms — etwa 92 ms Overhead. Tesseracts schlanke CPU-Laufzeit startet schnell und streamt gleichmäßig; PaddleOCRs GPU-Pipeline zahlt pro Lauf einen höheren Preis für Laden/Vorbelegung, der seine schnelle stabile Laufzeit bei diesem 361-Seiten-Korpus fast aufhebt. Eine lang laufende warme Pipeline sieht PaddleOCRs Vorteil pro Seite; eine Pipeline, die von Kaltstarts, kleinen Batches oder häufiger Neuinitialisierung dominiert wird, sieht die beiden Engines bei Parität oder besser auf der klassischen Seite.

Das p95-Ende erzählt dieselbe Geschichte in einer Zahl: Tesseracts p95 von 1.507,0 ms ist 2,2× enger als PaddleOCRs 3.331,4 ms. Der Erstseiten-/Vorbelegungsspike der GPU-Engine — derselbe Ladepfad, der ihre Wanduhrzeit pro Seite aufbläht — dominiert ihr Worst-Case-Ende, während die CPU-Engine keinen solchen Spike hat. Für Workloads mit empfindlicher Tail-Latenz oder Kapazitätsplanung ist die klassische Engine die vorhersehbarere.

Quelle: summary_metrics.csv — Spalte pages_per_minute, Zeilen sroie_2019. Tesseract 78.63285, PaddleOCR 79.71298. Seiten pro Minute in Wanduhrzeit inklusive Modellinitialisierung; die Latenz pro Seite im stationären Zustand ist die Spalte latency_p50_ms (siehe Diagramm unten). Abgleich: 60 ÷ 78.63285 = 763 ms/Seite gegenüber 60 ÷ 79.71298 = 753 ms/Seite Wanduhrzeit.

Quelle: summary_metrics.csv — Spalten latency_p50_ms / latency_p95_ms, Zeilen sroie_2019. Tesseract p50 670,87 / p95 1506,99; PaddleOCR p50 296,99 / p95 3331,35. Latenz im stationären Zustand (Messmodus warm_then_scored, ohne Modellladen). Die Spannung zwischen p50 und Seiten/Minute wird im obigen Text aufgelöst: unterschiedliche Uhren, beide real.

Tabelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, Zeilen sroie_2019. Exakte Werte: Tesseract p50 670,87 / p95 1506,99 / 78,63 Seiten/Min.; PaddleOCR p50 296,99 / p95 3331,35 / 79,71 Seiten/Min. Die Latenz ist pro Seite im stationären Zustand (warm-then-scored, ohne Modellladen); Seiten/Min. ist Wanduhrzeit inklusive Initialisierung und Batch-Effekten — die Parität und die p95-Inversion sind Fakten des Messmodells und der Architektur, keine Widersprüche.

Die Kostenstory: Wo die Legacy-Engine klar gewinnt

Kosten sind die eine Achse, auf der Tesseracts Alter ein Vorteil ist – und zwar ein struktureller: Tesseract ist reine CPU-Lösung, daher ist seine Kostenzelle in der CSV bewusst leer – keine GPU-Abrechnung, die gemessen werden müsste –, während PaddleOCR auf derselben RTX 4090 zum aufgezeichneten Satz von $0,76/Std. $0,2214 pro 1.000 Seiten abrechnet. Bei einem durchsatzgebundenen Workload (die Parität oben) sind die Betriebskosten der klassischen Engine auf GPU-abrechnungsscheuer Infrastruktur materiell niedriger – der Preisanker für die Entscheidung „lohnt sich das Upgrade?“.

Die Kosten werden berechnet als Wanduhr-Laufzeit × dem RunPod-RTX-4090-Satz ($0,76/Stunde, Preis in den Run-Manifesten mit Zeitstempel versehen), einschließlich Modellinitialisierung. Die leere Tesseract-Zelle ist keine Null – sie ist ein fehlender Wert, weil die Engine die GPU nie berührt hat; der Benchmark zeichnet sie als leer auf, statt eine Zahl anzunehmen (Protokollregel: Eine leere Zelle ist not_applicable, niemals 0). Zwei Kontextzahlen halten das ehrlich: PaddleOCRs $0,2214 liegt im Mittelfeld der sieben GPU-Engines (docTR hält mit $0,048 pro 1.000 Seiten die günstigste GPU-Zeile des Benchmarks), und bei CORD steigen PaddleOCRs Kosten auf $0,3419 pro 1.000 Seiten bei 141,0 Seiten/Min.

Quelle: summary_metrics.csv – Spalte cost_per_1000_pages, Zeilen sroie_2019. PaddleOCR 0,2214. Tesseracts Wert ist leer (Zelle in der CSV leer): CPU-only-Compute-Typ, keine GPU-Abrechnung – als weggelassen dargestellt, nicht als Null. Kosten = Wanduhr-Laufzeit × $0,76/Std. inklusive Modellinit, Preis mit Zeitstempel in den Run-Manifesten (August 2026). Günstigste GPU-Engine im Benchmark: docTR $0,048 pro 1.000 Seiten (Zeile doctr/sroie_2019).

Tabelle: summary_metrics.csv – Spalten cost_per_1000_pages / compute_type, Zeilen sroie_2019. Tesseracts Kostenzelle ist leer (leer, nicht 0,0000), weil die Engine nur CPU nutzt; PaddleOCRs GPU-Kosten umfassen die Modellinitialisierung zum aufgezeichneten Satz von $0,76/Std. Bei CORD liegen PaddleOCRs Kosten bei $0,3419 pro 1.000 Seiten bei 141,0 Seiten/Min (Zeile paddleocr/cord_v2).

CORD (indonesische Belege): Beide brechen ein — und die größte Feldlücke im Benchmark öffnet sich

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,9523 (Tesseract), ein sprachbedingtes Patt. Gemäß dem Benchmark-Protokoll bleiben die CORD-Werte von der SROIE-Vergleichsbasis getrennt — sie werden niemals in ein Ranking eingemischt — da der Ground-Truth-Text von CORD Annotationsstrukturen enthält, die den rohen CER für jede Engine zusätzlich zur echten Sprachdiskrepanz erhöhen.

Wo sich die beiden Engines wirklich unterscheiden, ist der LLM-Feldhebel, und dies ist der stärkste einzelne Datenpunkt dieser Seite: Durch den LLM-Nachprozessor hält PaddleOCRs CORD-Feld-F1 bei 0,5527 — der beste Wert aller acht Engines bei CORD — während Tesseracts Wert auf 0,1627 einbricht, der schlechteste Wert aller acht Engines im gesamten Benchmark. Diese Spanne von 0,39 Punkten ist die größte Lücke zwischen zwei verwandten LLM-Feldzeilen im Durchlauf. Der Mechanismus ist das konkretisierte Deckelargument: Tesseracts CORD-Text ist zu unlesbar (CER 0,9523), als dass ein Nachprozessor — Regex oder LLM — Felder daraus rekonstruieren könnte. Der LLM-Hebel hilft (Tesseracts SROIE-F1 steigt von 0,2335 per Regex auf 0,4389 per LLM), aber er startet von einer schwächeren Basis und kann keinen Text erzeugen, den die Engine nie gelesen hat. CORD wird hier für den Kontext der Sprachrobustheit angeführt; es wird bewusst nie mit den SROIE-Werten zu einer einzigen Rangliste zusammengeführt.

Tabelle: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) und field_method_comparison.csv (field F1), cord_v2-Zeilen. CORD-Zahlen nicht in ein SROIE-Ranking einmischen: CORD-CER kombiniert echte Sprachabweichung mit einer durch die Annotationstruktur bedingten Inflation in der Ground Truth, und die Regex-Muster wurden für englische Formate geschrieben (der Regex-F1 beider Engines fällt auf ~1–8 %). Ranking-Kontext (llm_field_value_f1, alle cord_v2-Zeilen): PaddleOCR 0.5527 ist der beste von acht; Tesseract 0.1627 ist der schlechteste von acht — die größte Lücke zwischen Geschwisterzeilen im Benchmark. Tesseracts Kostenfeld ist leer (nur CPU), niemals 0.

Wer gewinnt wann: Die Übersichtstabelle

„Besser“ hängt vom Arbeitsaufkommen ab, und dieser direkte Vergleich trennt die Achsen mit ungewöhnlicher Klarheit: Jede Genauigkeitsachse spricht für PaddleOCR; Kosten, CPU-Einfachheit und das enge p95-Ende sprechen für Tesseract; der Wanduhr-Durchsatz ist ein statistisches Unentschieden; die Latenz pro Seite spricht für PaddleOCR; und die Roh-CER-Meisterschaft gehört keinem von beiden (docTR/Surya2).

Häufig gestellte Fragen

Ist PaddleOCR bei Belegen genauer als Tesseract?

Ja — bei jeder in diesem Benchmark gemessenen Genauigkeitskennzahl. Bei SROIE 2019: CER 0,2045 vs. 0,3347 (39 % relative Verbesserung), WER 0,3256 vs. 0,5591 (42 %), Regex-Feld-F1 0,3254 vs. 0,2335 (1,39×), LLM-nachbearbeitetes Feld-F1 0,5810 vs. 0,4389 (1,32×) (summary_metrics.csv und field_method_comparison.csv, sroie_2019-Zeilen). Keine der beiden Engines ist der Gesamtsieger des Benchmarks bei Texten — diesen Titel halten Surya2 (CER 0,1915) und docTR (0,1971).

Warum erreicht Tesseract trotz reiner CPU-Ausführung die gleiche Seitenzahl pro Minute wie PaddleOCR?

Weil Seiten pro Minute den Gesamtdurchsatz messen, nicht die Inferenzgeschwindigkeit pro Seite. PaddleOCRs p50 im stationären Zustand (297,0 ms) ist tatsächlich 2,3× schneller als Tesseracts (670,9 ms), aber der Gesamtdurchsatz umfasst Modellinitialisierung und Batch-Effekte: Bei 79,7 Seiten/min benötigt PaddleOCR ~753 ms pro Seite (Gesamtzeit) gegenüber seinem p50 von 297 ms, während Tesseracts schlanke CPU-Laufzeit ~763 ms pro Seite gegenüber seinem p50 von 671 ms benötigt — die GPU-Engine zahlt pro Lauf einen höheren Load-/Prefill-Preis, der ihren Geschwindigkeitsvorteil bei diesem 361-Seiten-Korpus fast aufhebt (summary_metrics.csv, pages_per_minute / latency_p50_ms, sroie_2019-Zeilen).

Warum ist Tesseracts p95-Latenz enger als die von PaddleOCR?

Weil der First-Page-/Prefill-Spike der GPU-Engine ihren Worst-Case-Tail dominiert: PaddleOCR p95 3.331,4 ms vs. Tesseract p95 1.507,0 ms, eine 2,2×-Umkehrung der p50-Reihenfolge (summary_metrics.csv, latency_p95_ms, sroie_2019-Zeilen). Tesseracts CPU-Pipeline hat keinen Lastspike und streamt kontinuierlich; PaddleOCRs schneller stationärer Zustand geht mit einem schwereren Initialisierungspfad bei jedem Lauf einher. Die beiden Uhren messen verschiedene Dinge, und beide sind real.

Ist Tesseract günstiger als PaddleOCR?

Bei GPU-Abrechnung ja — Tesseract hat keine: Es ist reine CPU-Software, daher ist seine Kostenzelle in der CSV absichtlich leer (nie 0), während PaddleOCR 0,2214 $ pro 1.000 Seiten bei SROIE und 0,3419 $ bei CORD abrechnet, auf derselben RTX 4090 bei 0,76 $/Std. inklusive Modellinitialisierungskosten (summary_metrics.csv, cost_per_1000_pages, sroie_2019- und cord_v2-Zeilen). Das günstigste GPU-System im gesamten Benchmark ist insgesamt docTR mit 0,048 $ pro 1.000 Seiten.

Warum ist Tesseracts CORD-LLM-Feld-F1 der schlechteste Wert im gesamten Benchmark?

Weil der LLM-Nachprozessor Text nicht wiederherstellen kann, den die OCR-Engine nie gelesen hat. Tesseracts CORD-CER beträgt 0,9523 — auf indonesischen Belegen praktisch unlesbar — daher fällt sein LLM-Feld-F1 auf 0,1627, der schlechteste aller acht Engines, während PaddleOCR bei 0,5527 hält, dem besten der acht (field_method_comparison.csv, llm_field_value_f1, cord_v2-Zeilen). Derselbe Hebel bei sauberem englischem Text (SROIE) hebt Tesseract auf 0,4389 — aber die Obergrenze setzt die zugrunde liegende Textqualität.

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

Zwei sich verstärkende Ursachen, die das Protokoll von der SROIE-Wertung getrennt hält: eine echte Sprachdiskrepanz (indonesische Belege außerhalb des Trainingsfokus beider Engines) und eine durch die Annotationsstruktur bedingte Aufblähung im Ground-Truth-Text von CORD — der CER liegt bei 0,9083 (PaddleOCR) und 0,9523 (Tesseract) (summary_metrics.csv, cer, cord_v2-Zeilen). Was sie weiterhin unterscheidet, ist die LLM-Nachgelagerte Wiederherstellung: PaddleOCR 0,5527 vs. Tesseract 0,1627 Feld-F1 — die größte Geschwisterzeilen-Differenz im Benchmark. CORD-Zeilen werden mit Rahmen zitiert und niemals in eine kombinierte Wertung eingerechnet.

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

Wenn Ihre Pipeline Felder — extrahierte Werte für Firma, Datum, Summen verarbeitet, ist PaddleOCR bei Belegen die klare Standardwahl: 1,39× Feld-F1 unter Regex, 1,32× unter einem LLM, und eine LLM-Downstream-Wiederherstellung, die den CORD-Sprachschock übersteht (field_method_comparison.csv). Wenn Sie hohe Mengen an Rohtext bei sauberen englischen Dokumenten ohne GPU-Kosten, CPU-only-Infrastruktur oder vorhersagbare Tail-Latenz benötigen, bleibt Tesseract eine legitime Option: Der Durchsatz in Wanduhrzeit ist gleichwertig (79,7 vs. 78,6 Seiten/min), p95 ist 2,2× enger, und es gibt keine GPU-Abrechnung — aber planen Sie eine mittelmäßige Textbasis ein (CER 0,3347, 5. von 8), die jede nachgelagerte Feld-Pipeline begrenzt. Diese Ergebnisse gelten für englische und indonesische Belege 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 Kennzahl ist eine Zeile der veröffentlichten CSVs des First-Party-Benchmarks — results/summary_metrics.csv (CER/WER, Regex-Feld-F1, Latenz, Kosten, Durchsatz; Tesseract-Zeilen tragen compute_type=cpu und eine leere Kosten-Zelle) und results/field_method_comparison.csv (Regex- vs. LLM-Nachverarbeitung, llm_model = deepseek-v4-flash) — gehostet unter ImageToTableai/benchmark-ocr, mit einem redigierten 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 Firma/Datum/Adresse/Summe) und CORD-v2-Test (100 indonesische Belege, verschachtelte Felder Menü/Teilsumme/Summe); 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 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). Die CPU/GPU-Asymmetrie ist dieser Vergleichung inhärent: Tesseract lief auf CPU (compute_type=cpu) gegen GPU-beschleunigte Engines, wie vorgesehen — seine Kosten-Zelle ist leer, weil keine GPU-Zeit abgerechnet wurde, und seine Latenz/sein Durchsatz wurden auf derselben Maschine unter demselben Protokoll gemessen. Der zugrunde liegende Lauf enthält 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 sind separat unter Traditional OCR vs. Document Parsing VLMs veröffentlicht.

Laufzeitumgebung

• Hardware: Beide Engines liefen auf derselben Maschine mit einer NVIDIA RTX 4090 (24 GB); die GPU-Kosten wurden zum On-Demand-Satz von RunPod von 0,76 $/Std. berechnet, der Preis ist in den geschwärzten Manifests jedes Laufs mit Zeitstempel versehen (August 2026). Tesseract lief auf der CPU und verursachte keine GPU-Kosten; seine Kostenzelle ist bewusst leer.
• Engines: Standardkonfiguration, ohne Fine-Tuning. Versionen festgelegt: Tesseract 5.3.4 (klassische Open-Source-OCR-Engine — traditionelle CV-Pipeline mit LSTM-basierter Erkennung, nur CPU, System-Python3-Runner, keine GPU-Umgebung) und PaddleOCR 3.7.0 (modernes zweistufiges Deep-Learning-OCR — PP-OCR-Erkennung + -Klassifizierung, GPU) — gemäß der Modelltabelle im öffentlichen Repository (README.md) und den Laufmanifesten.
• LLM-Nachbearbeitung: deepseek-v4-flash über API bei Temperatur 0 für deterministische Ausgabe (die 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 — Stapelverarbeitung senkt die Kosten pro Seite; nicht anwendbar auf Tesseract (nur CPU).
• Feldnachbearbeitung: Die SROIE-Regex-Feldmetriken sind postprocessed_sroie_receipt_regex_* (regex_*-Spalten in field_method_comparison.csv) — Felder, die aus dem OCR-Text durch einen festen Mustersatz extrahiert werden. Sie messen OCR + nachgelagerte Extraktion, nicht die native strukturierte Ausgabe eines der Modelle; die LLM_*-Spalten messen OCR-Text + LLM-Extraktion. Die beiden Pipelines werden niemals gemischt.

Metrikdefinitionen

• CER (Zeichenfehlerrate): Bearbeitungsdistanz (Einfügungen + Löschungen + Ersetzungen) zwischen OCR-Text und Ground Truth, geteilt durch die Anzahl der Ground-Truth-Zeichen. Niedriger ist besser.
• WER (Wortfehlerrate): dieselbe Bearbeitungsdistanzberechnung 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 niemals gemischt.
• Dokumentfelder exakt: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — eine viel strengere Messlatte als das Feld-F1.
• Latenz p50/p95 & Seiten/Min.: Inferenzzeit pro Seite im stationären Zustand (warm, dann bewertet, ohne Modellladen) und Wanduhr-Durchsatz einschließlich Modellinitialisierung. Sie messen unterschiedliche Uhren; die p50-zu-Seiten/Min.-Parität auf dieser Seite ist eine Tatsache des Messmodells, kein Fehler, und wird im Abschnitt „Durchsatzparität“ erläutert.
• Kosten pro 1.000 Seiten: abgerechnete GPU-Stunden für 1.000 Seiten zum aufgezeichneten Satz von 0,76 $/Std., einschließlich Modellinitialisierung. Tesseracts Zelle ist leer (nur CPU) — eine leere Zelle ist not_applicable, niemals 0.

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 tesseract- und paddleocr-Zeilen hier (tesseract: compute_type=cpu, Kostenfeld leer).
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 tesseract- und paddleocr-Zeilen hier (sowie aus allen acht sroie_2019 / cord_v2-Zeilen im Ranking-Kontext).
3. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository, das die Ergebnis-CSVs, redigierte Lauf-Manifeste, das eingefrorene Protokoll und Beispiel-Datensatzlisten (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 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

• CPU/GPU-Asymmetrie ist inhärent, kein Fehler: Tesseract lief auf der CPU gegen GPU-beschleunigte Engines. Seine Kostenzelle ist bewusst leer (keine GPU-Abrechnung, nie 0), und seine Latenz/der Durchsatz sind CPU-Werte, die auf derselben Maschine unter demselben Protokoll gemessen wurden — eine andere Maschinenklasse könnte sein Betriebsfenster verschieben. Behandeln Sie den Kostenvergleich als „GPU-Abrechnung vs. keine“, nicht als hardwareunabhängige Wahrheit.
• Dokumentumfang — nur Belege: SROIE + CORD. Nichts hier misst Tesseracts Verhalten bei komplexen Layouts, Tabellen, Handschrift oder langen Dokumenten — Dokumenttypen, bei denen klassische Engines bekanntermaßen weiter abfallen — noch PaddleOCRs PP-Structure-Layout-/Tabellenfunktionen. Verwenden Sie diese Seite nicht, um zu schlussfolgern, dass eine Engine „bei allem gewinnt.“
• Stichprobengröße: 361 englische + 100 indonesische Belege. Feld-F1 und CER sind korpusabhängig; einstellige Unterschiede von ein paar Hundertstel sollten als Rauschen behandelt werden, nicht als technische Wahrheit — obwohl die hier dokumentierten Abstände (39 % CER, 1,39× Regex-F1, die 0,39-Punkte-CORD-LLM-F1-Spanne) weit außerhalb dieses Bandes liegen.
• Einzelne GPU-Stufe und einzelner Preis: Alle GPU-Zahlen stammen von einer RTX 4090 zu 0,76 $/Std., Preis zeitgestempelt August 2026 in den Lauf-Manifesten. Andere GPUs, Multi-GPU-Serving, Batch-Scheduling oder Preisänderungen verschieben Latenz, Durchsatz und Kosten — leiten Sie Kosten vor der Budgetierung zu aktuellen Sätzen neu ab.
• Einzelner LLM-Nachbearbeiter: Alle LLM-Zeilen verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt die absolute Feld-F1; die 1,32×-SROIE- und 0,39-Punkte-CORD-Abstände können sich an den Rändern bewegen. LLM-Latenz (~1.817–1.837 ms Median bei SROIE, field_method_comparison.csv llm_median_latency_ms) ist API-bedingt und nicht Teil der eigenen Latenz einer der beiden Engines.
• Regex-Abstimmung: Das Musterset wurde einmal pro Datensatz geschrieben. Eine pro Format stark abgestimmte Musterbibliothek könnte auf eigenen Layouts höher punkten — zu den Wartungskosten, die das LLM entfernt.
• 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–0,95) spiegelt Sprachmismatch + Ground-Truth-Aufblähung wider. CORD-Zeilen werden mit Kontext zitiert und nie in ein SROIE-Ranking gemischt (Protokollregel).
• Versions-Pinning: Die Ergebnisse gelten für Tesseract 5.3.4 und PaddleOCR 3.7.0 (August 2026). Neuere Versionen einer der beiden Engines können jede Zahl auf dieser Seite verschieben; Tesseracts Ergebnisse spiegeln speziell 5.3.4 wider und wurden in einem Wiederholungslauf vom 14.08.2026 erneut verifiziert.

Verwandte Referenzen: PaddleOCR vs. EasyOCR Beleg-Benchmark · docTR vs. Surya2 Beleg-Benchmark · der Acht-Engines-Vergleich von OCR und VLMs · feste Regeln vs. Sprachmodelle für Felder · warum eine korrekte Zeichenanzahl trotzdem ein falsches Feld bedeuten kann

Weiterführende Lektüre: die Genauigkeitslücke zwischen KI und traditioneller OCR · warum KI-Extraktion bei Bildern besser ist als OCR · Preise für KI-Dokumentextraktion (2026)