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

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

Die gesamte Geschichte dieser Seite dreht sich um 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 eine Tradition von etwa 35 Jahren mitbringt. Ihre Pipeline ist klassisches Computer Vision: adaptive Binarisierung, Seitensegmentierung, Verbundkomponentenanalyse und Zeichenerkennung — seit Version 4 LSTM-basiert — alles auf der CPU ausgeführt, ohne GPU-Abrechnung in diesem Benchmark (compute_type = cpu in der CSV). PaddleOCR ist eine moderne Deep-Learning-Engine aus dem PaddlePaddle-Ökosystem: eine Zweistufen-Pipeline aus der PP-OCR-Familie — eine Erkennungsstufe, die Textbereiche lokalisert (DBNet-Stil), und eine Transkriptionsstufe, die sie liest — die auf einer GPU läuft. Die eine Engine liest, indem sie Zeichenformen mit gelernten Mustern abgleicht; die andere liest, indem sie lernt, wo Text steht und was er sagt. Dieser Benchmark setzt beide denselben Belegen, demselben Protokoll und derselben Maschine aus.

Warum dieser Mechanismus wichtig ist: Tesserals Ansatz ist kostengünstig und benötigt keine GPU — aber sein Zeichenmodell ist seit Jahrzehnten in der klassischen Erkennung eingefroren, was sich als harte Grenze für die Textqualität zeigt. PaddleOCR’s Ansatz kostet GPU-Zeit, liefert aber wesentlich saubereren Text. Die Aufgabe des Benchmarks ist es, für beide Seiten dieses Kompromisses aus einem kontrollierten Durchlauf eine Zahl zu ermitteln — und die Überraschung ist, wie gering die Betriebskostenseite des Kompromisses ausfiel.

Zeichengenauigkeit: Die moderne Architektur gewinnt bei jedem Textmetrik

Bei SROIE 2019 ist die Lücke bei der Textgenauigkeit groß und einseitig: CER 0.2045 (PaddleOCR) vs. 0.3347 (Tesseract) — eine 39% relative Verbesserung — und WER 0.3256 vs. 0.5591, eine 42% relative Lücke. Tesserals CER von 0.3347 rangiert auf dem fünften Platz der acht Engines im zugrunde liegenden Durchlauf — mittelfeld, nicht letzter — aber jede Engine darüber mit einer Ausnahme ist eine Deep-Learning-Engine, und die Lücke zwischen Tesseract und der Deep-Learning-Schicht (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 Zeichen der Referenz — eine CER von 0.335 bedeutet etwa 33,5 falsch gelesene Zeichen pro 100. Die Wortfehlerrate (WER) wendet dieselbe Edit-Distanz-Berechnung auf Wortebene an. Bei beiden gilt: Je niedriger, desto besser. Die WER-Lücke (42%) ist breiter als die CER-Lücke (39%), was bedeutet, dass Tesserals Zeichenfehler sich in diesem Korpus zu ganzen Wortfehlern aufschaukeln — der klassische Fehlermodus einer Engine, den ein nachgelagerter Feldextraktor direkt übernimmt.

Quelle: summary_metrics.csv — cer- und wer-Spalten, sroie_2019-Zeilen. PaddleOCR cer 0.20449 / wer 0.32563; Tesseract cer 0.33468 / wer 0.55915. Je niedriger, desto besser. 361 Stichproben pro Engine; beide error_rate 0,0.

Tabelle: summary_metrics.csv — cer / wer / error_rate Spalten, sroie_2019 Zeilen. Exakte Werte: Tesseract cer 0.33468 / wer 0.55915; PaddleOCR cer 0.20449 / wer 0.32563. Niedrigere CER/WER ist besser. Ranking-Kontext aus derselben CSV: SROIE CER über alle acht Engines läuft 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. Keine der hier gezeigten Engines ist der Genauigkeits-Champion des Benchmarks — docTR und Surya2 halten die beiden Spitzenplätze bei CER.

Feldextraktion: Die Lücke, die Produktionsentscheidungen bestimmt

Die Textgenauigkeit ordnet die Engines; 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 zwei Nachbearbeiter für den OCR-Text jedes Engines: feste Regex-Muster (der traditionelle OCR- + regelbasierte Schlüsselinformations-Extraktions-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 gegenüber Tesserals 0.2335 — ein 1,39×-Vorteil; über den LLM bleibt die Lücke bei 0.5810 gegenüber 0.4389 (1,32×). Der LLM-Vorteil hilft beiden Engines, aber er startet von Tesserals schwächerer Basis — und das Deckungsargument, das Produktionspipelines entscheidet, folgt im nächsten Abschnitt.

Der Feldwert-F1 ist der harmonische Mittelwert von Precision und Recall über die extrahierten Feldwerte im Vergleich zum Sollwert — 1.0 bedeutet, dass jedes Belegfeld perfekt wiederhergestellt wurde, 0 bedeutet nichts. Die SROIE-Regex-Feldspalten sind die Benchmark-Metriken postprocessed_sroie_receipt_regex_*: feste Muster, die auf den OCR-Text jeder Engine angewendet werden — nachverarbeitet, nicht native strukturierte Ausgabe. Einordnung: PaddleOCRs Regex-F1 von 0,3254 ist der Beste unter den vier rein traditionellen Engines im 8-Engine-Benchmark (hinter nur Unlimited-OCR 0,3376 und PaddleOCR-VL 0,3368); Tesserals 0,2335 ist das viertbeste Regex-Ergebnis insgesamt (summary_metrics.csv, field_f1_regex, sroie_2019 Zeilen) — die klassische Engine ist ein mittelmäßiger Feldextraktor bei sauberem englischen Text, und genau dort hört sie auf, wettbewerbsfähig zu sein.

Quelle: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1 Spalten, sroie_2019 Zeilen (0–1 gespeicherte Dezimalzahlen als % angezeigt). LLM-Nachbearbeiter: deepseek-v4-flash (llm_model Spalte). 361 Stichproben 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 (Spalte llm_model). Die LLM-Latenz wird durch die API verursacht und ist von der Engine-Latenz getrennt (summary_metrics.csv latency_p50_ms). “Dokumente mit allen exakten Feldern” ist der Anteil der Dokumente, bei dem jedes Zielfeld genau übereinstimmt — ein viel strengerer Maßstab als der F1-Wert pro Feld. Ranking-Kontext (llm_field_value_f1, alle sroie_2019-Zeilen): PaddleOCR 0.5810 Rang 5 von 8; Tesseract 0.4389 Rang 7, nur vor EasyOCR mit 0.3717.

Die Überraschung: CPU-Durchsatzparität an der Wanduhr

Die schlagzeilentaugliche Erkenntnis der Seite ist die, die in keinem Drittanbieter-Vergleich dokumentiert ist: Bei denselben Belegen erreicht eine reine CPU-Klassik-Engine bei der Wanduhr-Seiten pro Minute einen modernen GPU-Engine — 78,6 vs. 79,7 (PaddleOCR), etwa 1,4% Unterschied, statistische Parität. Die Klassik-Engine ist nicht “langsam bei hohem Volumen”: Sie ist pro Seite langsam, aber konstant — und auf diesem Korpus übertrifft sie vier der sieben GPU-Engines im zugrundeliegenden Durchlauf (docling 56,7, paddleocr_vl 68,2, unlimited_ocr 34,4, surya2 12,1 Seiten/min).

Dies scheint ein Widerspruch zu den Latenzzahlen zu sein und verdient eine ehrliche Erklärung, nicht nur einen Fußnoten. Die p50-Latenz ist die stabile pro-Seiten-Inferenz, gemessen nach Aufwärmen und ohne Modell-Ladezeit — PaddleOCRs 297,0 ms sind tatsächlich schneller als Tesseracts 670,9 ms. Seiten pro Minute ist der Wanduhr-Durchsatz des gesamten Durchlaufs, einschließlich Modellinitialisierung und Batch-Effekte. Rechnen Sie den Durchsatz aus der CSV in Wanduhr-Zeit pro Seite um (60 Sekunden ÷ Seiten_pro_Minute): PaddleOCR benötigt ~753 ms pro Seite Wanduhr gegenüber 297 ms p50 — etwa 456 ms pro Seite für Initialisierung/Vorlauf und Batch-Overhead; Tesseract benötigt ~763 ms pro Seite Wanduhr gegenüber 671 ms p50 — etwa 92 ms Overhead. Tesserkts schlankes CPU-Laufzeitmodell startet schnell und arbeitet gleichmäßig; PaddleOCRs GPU-Pipeline zahlt einen höheren Lade-/Vorlaufpreis pro Durchlauf, der seinen schnellen stabilen Zustand auf diesem 361-seitigen Korpus fast aufhebt. Eine lang laufende, aufgewärmte Pipeline sieht PaddleOCRs Vorteil pro Seite; eine Pipeline, die von kalten Starts, kleinen Batches oder häufiger Neuinitialisierung dominiert wird, sieht die beiden Engines auf Klassik-Seite auf Augenhöhe oder besser.

Der p95-Schwanz 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 GPU-Engines Erste-Seite/Vorlauf-Spike — derselbe Ladevorgang, der seine Wanduhr-Zeit pro Seite aufbläht — dominiert seinen schlimmsten Fall im Schwanz, während die CPU-Engine keinen solchen Spike hat. Für latenzempfindliche oder kapazitätsgeplante Workloads ist die Klassik-Engine die vorhersagbarere.

Quelle: summary_metrics.csv — Spalte pages_per_minute, Zeilen sroie_2019. Tesseract 78,63285, PaddleOCR 79,71298. Seiten pro Minute inkl. Modellinitialisierung; die Latenz pro Seite im stabilen Zustand ist in der Spalte latency_p50_ms (siehe Diagramm unten). Abgleich: 60 ÷ 78,63285 = 763 ms/Seite vs. 60 ÷ 79,71298 = 753 ms/Seite (Wall-Clock).

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 stabilen Zustand (Messmodus warm_then_scored, ohne Modellladen). Das Spannungsfeld zwischen p50 und Seiten/Minute wird im obigen Text erläutert: 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 pg/min; PaddleOCR p50 296,99 / p95 3331,35 / 79,71 pg/min. Latenz ist die stabile pro Seite (nach Aufwärmphase und Scoring, ohne Modellladen); Seiten/Minute ist Wall-Clock inkl. Initialisierung und Batch-Effekte — die Parität und die p95-Umkehr sind Messmodell- und Architekturmerkmale, keine Widersprüche.

Die Kosten: Wo die Legacy-Engine klar gewinnt

Kosten sind die einzige Achse, in der das Alter von Tesseract ein Vorteil ist, und zwar ein struktureller: Tesseract ist nur CPU-basiert, daher ist seine Kostenzelle in der CSV von vornherein leer — keine GPU-Abrechnung zu messen —, während PaddleOCR auf derselben RTX 4090 bei den erfassten $0,76/Stunde $0,2214 pro 1.000 Seiten berechnet. Für eine durchsatzgebundene Arbeitslast (die obige Parität) sind die Betriebskosten der klassischen Engine auf GPU-scheuer Infrastruktur spürbar niedriger — der Preisanker für die Entscheidung „Lohnt sich ein Upgrade?".

Die Kosten werden berechnet als Wanduhr-Laufzeit × die RunPod RTX 4090-Rate ($0,76/Stunde, Preis mit Zeitstempel in den Ausführungsmanifesten), einschließlich Modellinitialisierung. Die leere Tesseract-Zelle ist kein Nullwert — es ist ein fehlender Wert, da die Engine das GPU nie berührt hat; der Benchmark zeichnet sie als leer auf, anstatt eine Zahl anzunehmen (Protokollregel: eine leere Zelle ist not_applicable, niemals 0). Zwei Kontextzahlen halten dies ehrlich: PaddleOCRs $0,2214 liegt im Mittelfeld der sieben GPU-Engines (docTR hält die günstigste GPU-Zeile des Benchmarks mit $0,048 pro 1.000 Seiten), und auf CORD steigen PaddleOCRs Kosten auf $0,3419 pro 1.000 Seiten bei 141,0 Seiten/Minute.

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, Zeilen sroie_2019. PaddleOCR 0,2214. Tesserals Wert ist leer (Zelle in der CSV leer): Nur CPU-Berechnungstyp, keine GPU-Abrechnung — dargestellt als weggelassen, nicht null. Kosten = Wanduhr-Laufzeit × $0,76/Stunde inkl. Modellinit, Preis mit Zeitstempel in Ausführungsmanifesten (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. Tesserals Kostenzelle ist leer (leer, nicht 0,0000), da die Engine nur CPU-basiert ist; PaddleOCRs GPU-Kosten beinhalten Modellinit bei den erfassten $0,76/Stunde. Auf CORD betragen PaddleOCRs Kosten $0,3419 pro 1.000 Seiten bei 141,0 Seiten/Minute (Zeile paddleocr/cord_v2).

CORD (Indonesische Quittungen): Beide brechen zusammen — und die größte Feldlücke im Benchmark öffnet sich

Keine der beiden Engines wurde überwiegend auf indonesischen Quittungen trainiert, daher dient CORD v2 (100 Stichproben, verschachtelte Felder menu/sub_total/total) als sprachübergreifender Stresstest — und beide brechen beim rohen CER zusammen: 0.9083 (PaddleOCR) und 0.9523 (Tesseract), ein Sprach-Mismatch-Wasch. Gemäß dem Benchmark-Protokoll bleiben die CORD-Zahlen von SROIE-Vergleichen isoliert — nie in ein Ranking eingemeischt —, da CORDs Ground-Truth-Text Annotationsstruktur einbettet, was den rohen CER für jede Engine zusätzlich zum echten Sprach-Mismatch aufbläht.

Wo die beiden Engines sich wirklich trennen, ist der LLM-Feldhebel, und dies ist der stärkste einzelne Datenpunkt der Seite: Durch den LLM-Nachbearbeiter bleibt PaddleOCRs CORD-Feld-F1 bei 0.5527 — das Beste aller acht Engines bei CORD —, während Tesserts auf 0.1627 einbricht, das Schlechteste aller acht Engines im gesamten Benchmark. Diese 0,39-Punkte-Differenz ist die größte Lücke zwischen zwei Geschwister-LLM-Feld-Zeilen im Durchlauf. Der Mechanismus ist das Deckel-Argument in konkreter Form: Tesserts CORD-Text ist so unlesbar (CER 0.9523), dass kein Nachbearbeiter — weder Regex noch LLM — Felder daraus wiederherstellen kann. Der LLM-Hebel hilft (Tesserts SROIE-F1 steigt von 0,2335 Regex auf 0,4389 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 zitiert; es wird absichtlich nie mit den SROIE-Zahlen zu einem einzigen Leaderboard zusammengefasst.

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 irgendein SROIE-Ranking einbeziehen: CORD CER kombiniert echte Sprachunterschiede mit einer Annotation-Struktur-Aufblähung in den Ground-Truth-Daten, und die Regex-Muster wurden für englische Formate geschrieben (beider Engines Regex F1 bricht auf ~1–8% ein). 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 Differenz zwischen Geschwisterzeilen im Benchmark. Tesserals Kostenzelle ist leer (nur CPU), nie 0.

Wer gewinnt wann: Die Zusammenfassungsmatrix

“Besser” hängt von der Arbeitslast ab, und dieser direkte Vergleich trennt die Achsen mit ungewöhnlicher Klarheit: Jede Genauigkeitsachse begünstigt PaddleOCR; Kosten, CPU-Einfachheit und die enge p95-Schwanzverteilung begünstigen Tesseract; die Durchsatzrate pro Zeiteinheit ist ein statistisches Unentschieden; die Seitentaktzeit begünstigt PaddleOCR; und die reine-CER-Meisterschaft gehört keinem (docTR/Surya2).

Häufig gestellte Fragen

Ist PaddleOCR bei Belegen genauer als Tesseract?

Ja — bei jeder in diesem Benchmark gemessenen Genauigkeitsachse. Auf 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-nachverarbeitetes 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 Gesamttext-Champion des Benchmarks — Surya2 (CER 0,1915) und docTR (0,1971) halten diesen Titel.

Warum erreicht Tesseract trotz CPU-Betrieb eine vergleichbare Seitenleistung wie PaddleOCR?

Weil Seiten pro Minute die Durchsatzleistung in Echtzeit ist, nicht die Inferenzgeschwindigkeit pro Seite. Der stabile p50-Wert von PaddleOCR (297,0 ms) ist tatsächlich 2,3× schneller als der von Tesseract (670,9 ms), aber der Echtzeitdurchsatz umfasst Modellinitialisierung und Stapel-Effekte: Bei 79,7 Seiten/min verbringt PaddleOCR ~753 ms pro Seite in Echtzeit gegenüber seinem p50 von 297 ms, während Tessereacts reduzierte CPU-Laufzeit ~763 ms pro Seite gegenüber seinem p50 von 671 ms verbraucht — die GPU-Engine zahlt einen höheren Lade-/Prefill-Preis pro Durchlauf, der ihren Geschwindigkeitsvorteil bei diesem 361-seitigen Korpus fast aufhebt (summary_metrics.csv, pages_per_minute / latency_p50_ms, sroie_2019-Zeilen).

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

Weil der Spitzenwert bei der ersten Seite/Prefill der GPU-Engine ihren schlimmsten Fall 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). Die CPU-Pipeline von Tesseract hat keinen Ladespitzenwert und läuft gleichmäßig; der schnelle stabile Zustand von PaddleOCR geht mit einem aufwändigeren Initialisierungspfad bei jedem Durchlauf einher. Die beiden Uhren messen unterschiedliche Dinge, und beide sind real.

Ist Tesseract günstiger als PaddleOCR?

Bei GPU-Abrechnung, ja — Tesseract hat keine: Es ist nur CPU-basiert, 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 berechnet, auf demselben RTX 4090 mit $0,76/Stunde, wobei die Kosten die Modellinitialisierung einschließen (summary_metrics.csv, cost_per_1000_pages, sroie_2019 und cord_v2 Zeilen). Die günstigste GPU-Engine im gesamten Benchmark ist docTR mit $0,048 pro 1.000 Seiten.

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

Weil der LLM-Nachbearbeiter den Text nicht wiederherstellen kann, den die OCR-Engine nie gelesen hat. Tesserals CORD-CER beträgt 0,9523 — effektiv unlesbar auf indonesischen Quittungen — daher bricht sein LLM-Feld-F1 auf 0,1627 ein, den schlechtesten Wert aller acht Engines, während PaddleOCR bei 0,5527 bleibt, dem besten Wert der acht (field_method_comparison.csv, llm_field_value_f1, cord_v2 Zeilen). Derselbe Hebel bei sauberem Englischtext (SROIE) hebt Tesseract auf 0,4389 — aber die Grenze wird durch die grundlegende Textqualität gesetzt.

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

Zwei sich verstärkende Ursachen, die das Protokoll von der SROIE-Rangliste trennt: eine echte Sprachdiskrepanz (indonesische Quittungen außerhalb des Trainingsfokus beider Engines) und eine Aufblähung der Annotationsstruktur im CORD-Grundwahrheitstext — der CER liegt bei 0,9083 (PaddleOCR) und 0,9523 (Tesseract) (summary_metrics.csv, cer, cord_v2 Zeilen). Was sie immer noch trennt, ist die LLM-Nachbearbeitung: PaddleOCR 0,5527 vs. Tesseract 0,1627 Feld-F1 — die größte Differenz zwischen Schwesterzeilen im Benchmark. CORD-Zeilen werden mit Einordnung zitiert und nie in ein kombiniertes Ranking einbezogen.

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

Wenn Ihre Pipeline Felder — extrahierte Werte für Unternehmen, Datum, Summen — verarbeitet, ist PaddleOCR die klare Standardwahl für Belege: 1,39× Feld-F1 bei Regex, 1,32× bei einem LLM und LLM-Downstream-Recovery, die den CORD-Schock übersteht (field_method_comparison.csv). Wenn Sie hochvolumigen Rohtext auf sauberen englischen Dokumenten ohne GPU-Kosten, CPU-only-Infrastruktur oder vorhersagbare Spitzenlatenz benötigen, bleibt Tesseract eine legitime Option: Die Durchsatzzeiten sind gleichauf (79,7 vs. 78,6 Seiten/min), p95 ist 2,2× enger, und es gibt keine GPU-Abrechnung — aber kalkulieren Sie mit einem mittelmäßigen Text-Output (CER 0,3347, 5. von 8), der 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 Zahl ist eine Zeile der veröffentlichten CSVs des internen Benchmarks — results/summary_metrics.csv (CER/WER, Regex-Feld-F1, Latenz, Kosten, Durchsatz; Tesseract-Zeilen tragen compute_type=cpu und eine leere Kostenzelle) und results/field_method_comparison.csv (Regex vs. LLM-Nachbearbeitung, llm_model = deepseek-v4-flash) — gehostet bei ImageToTableai/benchmark-ocr, mit einem geschwärzten manifest.json pro Lauf für Umgebungs-Fingerabdrücke. Datensatzdefinitionen stammen aus den unten zitierten Arbeiten SROIE 2019 und CORD.

Methodik & Quellen

Protokoll

Diese Seite berichtet einen direkten Vergleichsausschnitt eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Umfrage zu Drittanbieter-Aussagen und keine Hersteller-Vergleichsseite. Nur feste Testsplits: SROIE 2019 Test (361 englische Belege, flache Felder Unternehmen/Datum/Adresse/Summe) und CORD v2 Test (100 indonesische Belege, verschachtelte Felder Menü/Zwischensumme/Summe); Trainingssplits wurden nie ausgewertet. Beide Engines sahen dieselben Bilder, dieselben Ground-Truth-Werte und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Lauf geht dem bewerteten Lauf voraus, sodass die Latenzwerte im steady-state liegen). Beide Läufe schlossen mit einer Fehlerrate von 0,0 auf beiden Datensätzen ab (Spalte error_rate in summary_metrics.csv). Die CPU/GPU-Asymmetrie ist diesem Vergleich inhärent: Tesseract lief auf CPU (compute_type=cpu) gegen GPU-beschleunigte Engines, per Design — seine Kostenzelle ist leer, da keine GPU-Zeit abgerechnet wurde, und seine Latenz/Durchsatz wurden auf derselben Maschine unter demselben Protokoll gemessen. Der zugrunde liegende Lauf umfasste insgesamt acht Engines; diese Seite vergleicht nur die beiden genannten Engines, wobei andere Engines nur als Ranking-Kontext zitiert werden. Die vollständigen 8-Engine-Ergebnisse werden separat auf Traditional OCR vs Document Parsing VLMs veröffentlicht.

Laufzeitumgebung

• Hardware: Beide Engines liefen auf derselben Maschine mit einer NVIDIA RTX 4090 (24 GB); GPU-Kosten berechnet zum RunPod-On-Demand-Tarif von $0.76/hr, Preis mit Zeitstempel im redigierten Manifest jedes Durchlaufs (August 2026). Tesseract lief auf CPU und verursachte keine GPU-Kosten; seine Kostenzelle ist absichtlich leer.
• Engines: Out-of-the-box, kein Fine-Tuning. Versionen fixiert: 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 (moderne zweistufige Deep-Learning-OCR — PP-OCR-Erkennung + Erkennung, GPU) — gemäß der öffentlichen Repo-Modelltabelle (README.md) und den Durchlauf-Manifesten.
• LLM-Nachbearbeiter: deepseek-v4-flash via API bei Temperatur 0 für deterministische Ausgabe (die llm_model-Spalte in field_method_comparison.csv); es war das einzige Modell für alle LLM-Felder-Zeilen beider Engines.
• Kostenbasis: Wanduhr-Laufzeit × $0.76/hr, einschließlich Modellinitialisierung — Batch-Verarbeitung senkt die Kosten pro Seite; nicht anwendbar auf Tesseract (nur CPU).
• Feld-Nachbearbeitung: SROIE-Regex-Feldmetriken sind postprocessed_sroie_receipt_regex_* (field_method_comparison.csv regex_*-Spalten) — Felder, die aus OCR-Text durch ein festes Musterset extrahiert werden. Sie messen OCR + nachgelagerte Extraktion, nicht native strukturierte Ausgabe durch eines der Modelle; die LLM_*-Spalten 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 Ground-Truth-Zeichen. Niedriger ist besser.
• WER (Word Error Rate): dieselbe Editierdistanz-Berechnung auf Wortgranularität.
• Feld-Wert-F1 (Regex): Harmonisches Mittel aus Precision/Recall über extrahierte Feldwerte mit festen Regex-Mustern 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 gemischt.
• 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, schließt Modellladen aus) und Wanduhr-Durchsatz einschließlich Modellinitialisierung. Sie messen verschiedene Uhren; die p50-vs-Seiten/min-Parität auf dieser Seite ist eine Messmodell-Tatsache, kein Fehler, und wird im Abschnitt „Durchsatzparität“ erläutert.
• Kosten pro 1.000 Seiten: Abgerechnete GPU-Stunden für 1.000 Seiten zum erfassten Tarif von $0.76/hr, einschließlich Modellinitialisierung. Tesseras Zelle ist leer (nur CPU) — eine leere Zelle ist not_applicable, niemals 0.

Quellenliste

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 lässt sich auf die tesseract- und paddleocr-Zeilen hier zurückführen (tesseract: compute_type=cpu, Kostenzelle leer).
2. field_method_comparison.csv (GitHub raw). 16 Zeilen; Spalten model, dataset, llm_model (= deepseek-v4-flash), regex/llm field-value accuracy and F1, document-fields-exact, llm_median_latency_ms, token counts. Jede regex/LLM field-F1-Zahl lässt sich auf die tesseract- und paddleocr-Zeilen hier (und auf alle acht sroie_2019 / cord_v2-Zeilen im Ranking-Kontext) zurückführen.
3. ImageToTableai/benchmark-ocr Repository. Öffentliches Repo 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 Feldschema und Lizenz (CC-BY-4.0).

Einschränkungen

• CPU/GPU-Asymmetrie ist inhärent, kein Fehler: Tesseract lief auf CPU gegen GPU-beschleunigte Engines. Seine Kostenzelle ist absichtlich leer (keine GPU-Abrechnung, nie 0), und seine Latenz/Durchsatz sind CPU-Zahlen, die auf demselben Gerät unter demselben Protokoll gemessen wurden — eine andere Geräteklasse könnte seinen Betriebsbereich verschieben. Betrachten Sie den Kostenvergleich als „GPU-Abrechnung vs. keine“, nicht als hardwareunabhängige Wahrheit.
• Dokumentbereich — nur Quittungen: SROIE + CORD. Hier wird nichts über das Verhalten von Tesseract bei komplexen Layouts, Tabellen, Handschrift oder langen Dokumenten gemessen — Dokumenttypen, bei denen klassische Engines bekanntlich noch stärker abnehmen — noch über die PP-Structure Layout-/Tabellenfähigkeiten von PaddleOCR. Verwenden Sie diese Seite nicht, um zu schlussfolgern, dass eine der Engines „in allem gewinnt“.
• Stichprobengröße: 361 englische + 100 indonesische Quittungen. Feld-F1 und CER sind korpusabhängig; einstellige Unterschiede von einigen Hundertsteln sollten als Rauschen und nicht als ingenieurtechnische Wahrheit behandelt werden — wobei die hier dokumentierten Lücken (39% CER, 1,39× Regex-F1, die 0,39-Punkt-CORD-LLM-F1-Spanne) weit außerhalb dieses Bereichs liegen.
• Einzelne GPU-Stufe und einzelner Preis: Alle GPU-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 werden Latenz, Durchsatz und Kosten verschieben — leiten Sie die Kosten vor der Budgetierung zu aktuellen Raten 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-Punkt-CORD-Lücken könnten an den Rändern schwanken. LLM-Latenz (~1.817–1.837 ms Median bei SROIE, field_method_comparison.csv llm_median_latency_ms) wird durch die API verursacht und ist nicht Teil der Latenz der jeweiligen Engine selbst.
• Regex-Abstimmung: Das Musterset wurde einmal pro Datensatz geschrieben. Eine pro-Format, stark abgestimmte Musterbibliothek könnte bei eigenen Layouts höher punkten — mit den Wartungskosten, die das LLM eliminiert.
• CORD-CER ist keine qualitätsbezogene Einzelmodell-Messung: CORD-Ground Truth enthält Annotationsstruktur, und keine der Engines wurde überwiegend auf Indonesisch trainiert; CORD-CER (0,91–0,95) spiegelt Sprachinkongruenz + Ground-Truth-Inflation wider. CORD-Zeilen werden mit Einordnung zitiert und nie in irgendein SROIE-Ranking einbezogen (Protokollregel).
• Versionsfixierung: Die Ergebnisse gelten für Tesseract 5.3.4 und PaddleOCR 3.7.0 (August 2026). Neuere Versionen beider Engines könnten jede Zahl auf dieser Seite verschieben; die Ergebnisse von Tesseract spiegeln speziell 5.3.4 wider und wurden in einem Wiederholungslauf am 14.08.2026 erneut überprüft.

Verwandte Referenzen: PaddleOCR vs EasyOCR Quittungs-Benchmark · docTR vs Surya2 Quittungs-Benchmark · Traditionelle OCR vs Dokument-Parsing-VLMs · Regex vs LLM-Feldextraktion · Feldgenauigkeit vs Zeichengenauigkeit

Weiterführende Lektüre: AI-OCR vs. traditionelle OCR-Genauigkeit · KI-Bilddatenextraktion vs. traditionelle OCR · KI-Dokumentextraktion Preise (2026)