docTR vs Docling bei Quittungen
Single-Pass-Geschwindigkeit vs. Dokument-Pipeline (2026)

Was Docling ist (und was nicht): Einzel-Pass-OCR vs. eine Parsing-Pipeline

Die beiden Engine stehen auf gegenüberliegenden Seiten einer grundlegenden architektonischen Trennlinie, und diese Trennlinie — nicht ein Code- oder Tuning-Unterschied — ist die gesamte Geschichte dieser Seite. docTR ist eine Einzel-Pass-Neural-OCR-Engine: Eine Erkennungsstufe lokalisiert Text-Bounding-Boxes und eine Transkriptionsstufe liest die Zeichen darin, die zu einem einzigen OCR-Prädiktor zusammengefasst werden, dessen Durchlauf von vorne nach hinten rohe Textzeilen erzeugt. Es gibt kein Layout-Modell, keinen Tabellenparser und keine Rekonstruktion der Lesereihenfolge — was gedruckt ist, kommt heraus, in der Reihenfolge, in der der Erkennungsalgorithmus es liest. Docling ist weder eine OCR-Engine noch ein visuell-sprachliches Modell; es ist eine Dokument-Parsing-Pipeline. Laut seinem eigenen technischen Bericht (als architektonischer Kontext zitiert, nicht für eine Zahl auf dieser Seite) führt es pro Seite eine Modellsequenz aus — Layout-Analyse, Tabellenerkennung, Lesereihenfolgen-Inferenz — fasst diese zusammen und erstellt ein intermediäres Dokumentobjekt, bevor Text ausgegeben wird, weshalb seine Ausgabe Struktur (Labels, Reihenfolge, Zonen) enthält, die docTRs Zeilen nicht haben.

Warum dieser Mechanismus für einen Benchmark wichtig ist: Jedes gestufte Modell in Doclings Kette existiert, um Layout-Strukturen auszunutzen — eine zu parsende Tabelle, ein zweispaltiges Formular, einen Leseweg, der nicht der lexikalischen Reihenfolge entspricht. Eine einfache englische Quittung hat fast nichts davon: eine Spalte, wenige Zonen, ein meist vorhersehbarer Weg von oben nach unten, keine Tabellen. Die gestufte Maschinerie läuft dennoch auf jeder Seite — deshalb ist sie langsamer und teurer — aber ohne Struktur, die ausgenutzt werden kann, kann der Overhead nicht in besseren Text umgesetzt werden. Diese Seite isoliert genau diese Kosten und zeigt, was sie — und was nicht — bringen.

Zeichengenauigkeit: Die Pipeline-Steuer auf Rohtext

Bei SROIE 2019 ist die Lücke im Rohtext nicht gering: CER 0.1971 (docTR) vs. 0.5909 (Docling) — eine 3,0× Strafe — und WER 0.3199 vs. 0.7596. Die Zeichenfehlerrate misst Einfügungen, Löschungen und Ersetzungen geteilt durch die Zeichen der Referenz — ein CER von 0,197 bedeutet ~19,7 falsch gelesene Zeichen pro 100; die Wortfehlerrate wendet dieselbe Edit-Distanz-Logik auf Wortebene an. Doclings 0,5909 belegt Platz 7 von 8 Engines im zugrunde liegenden Durchlauf, nur vor Unlimited-OCR (0,6552, summary_metrics.csv cer-Spalte, alle sroie_2019-Zeilen) — der docTR-vs-Surya2-Vergleich dokumentierte docTR als eines der beiden besten Erkennungssysteme in diesemselben Benchmark, und diese Seite zeigt, dass dieselbe Engine am anderen Ende der Textgenauigkeitstabelle eine Pipeline ist, keine schwächere Erkennungsfamilie.

Quelle: summary_metrics.csv — cer- und wer-Spalten, sroie_2019-Zeilen. docTR cer 0,19707 / wer 0,31990; Docling cer 0,59092 / wer 0,75961. Je niedriger, desto besser. 361 Samples pro Engine; beide error_rate 0,0.

Tabelle: summary_metrics.csv — cer / wer / error_rate Spalten, sroie_2019 Zeilen. Exakte Werte: docTR cer 0,19707 / wer 0,31990; Docling cer 0,59092 / wer 0,75961. Doclings SROIE CER ist der zweitschlechteste der acht Engines im zugrunde liegenden Durchlauf (nur vor Unlimited-OCRs 0,6552) — die Roh-Zzeichengenauigkeit ist der Punkt, an dem die Pipeline-Steuer zuerst sichtbar wird.

Die Umkehrung: Regex-Feldextraktion dreht das Ergebnis um

Benchmarken Sie den Text beider Engines mit denselben festen Regex-Mustern für die vier SROIE-Belegfelder (Unternehmen, Datum, Adresse, Gesamtbetrag) — der traditionelle OCR- + regelbasierte Key-Information-Extraction (KIE) Ansatz — und die Rangfolge dreht sich um: Docling extrahiert Felder mit 0,2237 Feld-F1 gegenüber docTRs 0,0766, ein 2,9-facher Vorteil. Dies sind die Benchmark-Metriken postprocessed_sroie_receipt_regex_*: feste Muster, die auf den OCR-Text jeder Engine angewendet werden — nachverarbeitet, nicht die native strukturierte Ausgabe einer der Engines, und Doclings natives Dokumentmodell wird hier nicht bewertet.

Feld-Wert-F1 ist der harmonische Mittelwert von Präzision und Recall über die extrahierten Feld-Werte gegenüber dem Ground Truth — 1,0 bedeutet, jedes Belegfeld wurde perfekt wiederhergestellt, 0 bedeutet nichts. Der Mechanismus hinter der Umkehrung ist derselbe Architekturunterschied, der die CER-Lücke verursachte, wirkt aber in die entgegengesetzte Richtung: Doclings Dokumentmodell ordnet Text in einen Leseweg neu und ordnet Labels Werten zu, sodass sein emittierter Text in der Form näher an dem ist, was die festen Muster erwarten; docTRs sauberer, aber roher Zeilentext — akkurat nach CER, aber mit originaler Groß-/Kleinschreibung und Trennzeichen-Rauschen und ohne Label-Rahmung — besiegt die Muster. docTRs Regex-Feld-F1 von 0,0766 ist der Schlechteste aller acht Engines im zugrundeliegenden Durchlauf trotz seines erstklassigen CER (summary_metrics.csv field_f1_regex und cer Spalten, alle sroie_2019 Zeilen); Doclings 0,2237 rangiert auf Platz sechs. Dieselbe Entkopplung, die der direkte Vergleich der Schwester-Engines an der Spitze der Genauigkeitsleiter (docTR vs Surya2) dokumentierte, wiederholt sich hier am unteren Ende: Textgenauigkeit ist keine Feldgenauigkeit.

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-Spalten, sroie_2019-Zilen. Dies sind postprocessed_sroie_receipt_regex_*-Metriken: feste Muster, die auf den OCR-Text jeder Engine angewendet werden, keine native strukturierte Extraktion. Keine Engine erfasst alle vier Felder exakt durch Regex auf einer einzelnen SROIE-Quittung (0.0000, ein wörtlicher Nullwert in der CSV). docTRs Regex-Feld-F1 von 0.0766 ist der niedrigste Wert aller acht Engines im zugrunde liegenden Durchlauf.

LLM-Nachbearbeitung stellt die Rangfolge wieder her — teilweise

Führt man den Text beider Engines einem LLM-Nachbearbeiter (deepseek-v4-flash bei Temperatur 0) mit einem strukturierten Extraktionsprompt zu, gewinnt docTR die Führung zurück: Feld-F1 0.6171 gegenüber 0.5685 — ein Vorsprung von 0,049 Punkten, gering im Vergleich zum rohen CER-Unterschied, aber nicht ausgelöscht. Der sauberere Basistext macht mehr wiederherstellbare Feldwerte zugänglich; das LLM kompensiert teilweise Doclings Layout-Artefakte, beseitigt sie aber nicht vollständig.

Dies ist dieselbe Konvergenzzone, die im gesamten Acht-Engine-Benchmark beobachtet wird — LLM-Nachbearbeitung zieht leistungsfähige Engines zusammen, weil sie Semantik versteht (Zahlen, Daten, Namen) anstatt Zeichenformen abzugleichen — und der verbleibende Unterschied ist bedeutsam: docTRs 0.6171 ist das beste LLM-Feld-F1 aller acht Engines, während Doclings 0.5685 den sechsten Platz belegt (field_method_comparison.csv llm_field_value_f1, alle sroie_2019-Zilen). Die strengere Messlatte — Dokumente, bei denen alle vier Felder exakt übereinstimmen — trennt sie um den Faktor 2,7×: docTR 0.1496 gegenüber Docling 0.0554. Zwei Kosten kommen mit dem Hebel: Ein LLM-Aufruf fügt ~2,0–2,4 s mittlere Latenz pro Dokument zur OCR-Zeit hinzu (1.996,3 ms für docTRs Text, 2.365,1 ms für Doclings — API-bedingt und in der Art identisch), und er kann Text nicht retten, den eine Engine grundlegend nicht lesen konnte.

Tabelle: field_method_comparison.csv — llm_* Spalten, sroie_2019 Zeilen. LLM-Modell: 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). Beide Zeilen wurden mit llm_ok_count 361 abgeschlossen.

Der Betriebsbereich: 6,7× Latenz, 7,9× Durchsatz, 8,3× Kosten

Die Pipeline-Steuer ist am höchsten dort, wo die Durchsatzplanung stattfindet. Auf derselben RTX 4090 mit derselben erfassten Rate von $0,76/Stunde hält docTR 449,3 Seiten/min bei 108,7 ms p50 pro Seite für $0,048 pro 1.000 Seiten; Docling hält 56,7 Seiten/min bei 732,0 ms p50 für $0,398 pro 1.000 Seiten — eine 6,7× Latenzlücke, eine 7,9× Durchsatzlücke und eine 8,3× Kostenlücke. Der Schwanz ist für die Pipeline proportional schlechter: p95 281,4 ms vs. 3.239,8 ms, eine 11,5× Lücke, weil Doclings gestufte Modelle ihre Worst-Case-Zeiten Seite für Seite aufsummieren.

Die Kosten werden berechnet als Wanduhr-Laufzeit × die 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 Wanduhr-Seiten pro Minute, einschließlich derselben Initialisierung. Latenz p50/p95 sind steady-state Inferenzzeiten pro Seite, gemessen warm-then-scored (Modellladen ausgeschlossen). docTR ist die schnellste und günstigste Engine aller acht im zugrundeliegenden Lauf auf SROIE; Docling, mit 56,7 Seiten/min und $0,398 pro 1.000 Seiten, liegt in der unteren Hälfte der Betriebsbereich-Tabelle (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, alle sroie_2019-Zeilen).

Quelle: summary_metrics.csv — latency_p50_ms / latency_p95_ms Spalten, sroie_2019 Zeilen. docTR p50 108,72 / p95 281,38; Docling p50 732,00 / p95 3239,79. Steady-state Latenz (warm_then_scored Messmodus, Modellladen ausgeschlossen).

Quelle: summary_metrics.csv — cost_per_1000_pages Spalte, sroie_2019 Zeilen. docTR 0,0479, Docling 0,3978. Kosten = Wanduhr-Laufzeit × $0,76/Stunde inkl. Modellinit, Preis mit Zeitstempel in Lauf-Manifesten (August 2026). docTR ist die günstigste Engine der acht im zugrundeliegenden Lauf.

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/hr Preis mit Zeitstempel in Manifesten); Kosten beinhalten Modellinitialisierung. Exakte Werte: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; Docling p50 732.00 / p95 3239.79 / 56.66 pg/min / $0.3978.

CORD (Indonesische Quittungen): Beide brechen ein, docTRs LLM-Feldwiederherstellung führt weiterhin

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 ein: 0.9101 (docTR) und 0.9219 (Docling), ein Sprach-Mismatch-Wasch. Gemäß dem Benchmark-Protokoll werden die CORD-Zahlen von SROIE isoliert gehalten — nie in ein Ranking einbezogen —, da CORDs Ground-Truth-Text Annotationsstruktur einbettet, was den rohen CER für jede Engine zusätzlich zum tatsächlichen Sprach-Mismatch aufbläht.

Bei den Feldmetriken schrumpft Doclings einziger Vorteil auf fast nichts: Über Regex-Muster erholen beide Engines fast keine CORD-Felder (docTR 0.0000 — ein buchstäblicher Nullwert in der CSV — gegenüber Doclings 0.0612, da die englischformatierten Muster nie für indonesischen Text geschrieben wurden). Der LLM-Nachprozessor absorbiert den Sprachschock auf beiden Seiten, hält docTR aber in Führung: Feld-F1 0.5500 gegenüber 0.4695. CORD wird hier für den Kontext der Sprachrobustheit zitiert; es wird bewusst 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 Sprachdiskrepanzen mit einer Annotation-Struktur-Inflation in den Ground-Truth-Daten, und die Regex-Muster wurden für englische Formate geschrieben. docTRs CORD-Regex field F1 von 0,0000 ist ein wörtlicher Nullwert in der CSV, kein fehlender Wert.

Wer gewinnt wann: Die Zusammenfassungsmatrix

“Besser” ist arbeitslastabhängig, und dieser Direktvergleich trennt die Achsen sauber: Bei einem einfachen englischen Beleg bevorzugen alle Geschwindigkeits-/Kosten-Achsen und die Rohtext-Achse docTR; die Out-of-the-Box-Regex-Feldumkehr bevorzugt Docling; ein LLM-Nachbearbeiter bringt sie wieder auf einen docTR-Vorsprung von 0,049 Punkten; und die Fähigkeiten, für die Docling existiert — Layout, Tabellen, Lesereihenfolge, lange Dokumente — werden hier nicht gemessen, aber auch nicht widerlegt.

Häufig gestellte Fragen

Ist Docling genauer als docTR bei Quittungen?

Nein — bei der Rohzeichengenauigkeit ist docling 3,0× schlechter: SROIE CER 0,5909 vs. 0,1971 und WER 0,7596 vs. 0,3199 (summary_metrics.csv, cer / wer, sroie_2019 rows). Docling “gewinnt” nur in einer gemessenen Achse: der Extraktion von Feldern mit Regex ohne Vorlage (0,2237 vs. 0,0766 field F1) — und ein LLM-Nachbearbeiter dreht das zugunsten von docTR um (0,6171 vs. 0,5685).

Warum extrahiert Docling Felder besser mit Regex, obwohl der Rohtext viel schlechter ist?

Weil die beiden Metriken unterschiedliche Dinge bewerten und die Ausgabeform von Docling zufällig zu den Mustern passt. Doclings Dokumenten-Pipeline ordnet Text in einen Leseweg um und ordnet Bezeichnungen Werten zu, sodass sein emittierter Text strukturell näher an dem ist, was die festen Regex-Muster erwarten; docTR emittiert sauberen Rohzeilentext, der nach CER genau ist, aber die Muster scheitern lässt (0,0766 field F1, der schlechteste Wert aller acht Engines, gegenüber best-in-class CER). Dies sind postprocessed_sroie_receipt_regex_*-Werte — OCR-Text, der durch feste Muster läuft — und keine native strukturierte Ausgabe (field_method_comparison.csv, regex_field_value_f1, sroie_2019 rows). Diese Entkopplung von Textgenauigkeit ≠ Feldgenauigkeit zeigt sich in diesem Benchmark durchgehend.

Warum ist Docling so viel langsamer und teurer pro Seite?

Weil es auf jeder Seite eine gestufte Dokumenten-Pipeline ausführt — Layout-Analyse, Tabellenerkennung, Lesereihenfolge-Rekonstruktion und ein intermediäres Dokumentenmodell — selbst wenn die Seite eine einfache Quittung ohne ausnutzbare Struktur ist. Bei SROIE beträgt diese Steuer 6,7× bei p50 (108,7 vs. 732,0 ms), 11,5× bei p95, 7,9× geringeren Durchsatz (449,3 vs. 56,7 Seiten/min) und 8,3× höhere Kosten pro 1.000 Seiten ($0,048 vs. $0,398) — selbes GPU, selbes Protokoll (summary_metrics.csv, sroie_2019 rows).

Schließt ein LLM-Nachbearbeiter die Lücke zwischen docTR und Docling?

Teilweise, aber nicht vollständig: Das F1-Ergebnis der feldbezogenen LLM-Nachbearbeitung auf SROIE liegt bei docTR 0.6171 gegenüber Docling 0.5685 — ein Vorsprung von 0,049 Punkten für docTR, der die teilweise Kompensation des LLM für Doclings Layout-Artefakte überlebt (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen). Der Preis für die Konvergenz sind ~2,0–2,4 s zusätzliche mediane LLM-Latenz pro Dokument (llm_median_latency_ms, gleiche Zeilen).

Bedeutet dieses Benchmark, dass Docling schlecht ist?

Nein — es bedeutet, dass Doclings Stärken hier nicht gemessen werden. Docling ist eine Dokumentenparsen-Pipeline, deren Wertversprechen — Layout-Struktur, Tabellen, Lesereihenfolge, Formulare, lange Dokumente — genau das ist, was ein Benchmark nur für Quittungen nicht testen kann. Was diese Seite zeigt, ist enger gefasst: Bei einer einfachen einseitigen Quittung lohnt sich der Pipeline-Overhead nicht (3,0× schlechterer CER, 8,3× höhere Kosten), und sein einziges gemessener Vorteil (2,9× Regex-Feld-F1) wird durch einen LLM-Nachbearbeiter zunichtegemacht. Die ehrliche Einordnung ist eine Frage des Umfangs, nicht des Urteils.

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

Zwei sich verstärkende Ursachen, die das Protokoll von der SROIE-Rangliste getrennt hält: eine echte Sprachdiskrepanz (indonesische Quittungen außerhalb des Trainingsfokus beider Engines) und eine Aufblähung der Annotationsstruktur im Referenztext von CORD — der CER liegt bei 0,9101 (docTR) und 0,9219 (Docling) (summary_metrics.csv, cer, cord_v2-Zeilen). Unter einem LLM-Nachbearbeiter bleibt das Feld-F1 von docTR bei 0,5500 gegenüber 0,4695 bei Docling — die SROIE-Rangfolge, komprimiert. CORD-Zeilen werden zitiert und nie in ein kombiniertes Ranking einbezogen.

Welche Engine sollte eine Beleg-Pipeline wählen, docTR oder Docling?

Für hochvolumigen Belegtext mit verbrauchsabhängigen Kosten ist docTRs Envelope entscheidend: 108,7 ms p50, 449,3 Seiten/min, $0,048 pro 1.000 Seiten — die schnellste und günstigste Engine im zugrundeliegenden Acht-Engine-Lauf. Wenn Ihre Pipeline strukturierten Text direkt ohne Nachbearbeitung verarbeitet, ist Doclings Regex-Feld-Vorsprung (0,2237 vs. 0,0766) ein realer Startvorteil. Wenn LLM-Nachbearbeitung Teil des Designs ist, bleibt docTR mit 0,049 vorn und ist günstiger zu speisen. Wenn Ihre Arbeitslast layoutlastige Dokumente — Tabellen, Formulare, lange Berichte — umfasst, ist dieses Benchmark nicht die richtige Entscheidungsgrundlage; es misst nur Belege (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 bei ImageToTableai/benchmark-ocr, mit einem geschwärzten manifest.json pro Lauf für Umgebungsfingerabdrücke. Datensatzdefinitionen stammen aus den unten zitierten Arbeiten zu SROIE 2019 und CORD.

Methodik & Quellen

Protokoll

Diese Seite berichtet einen direkten Vergleichsausschnitt eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Umfrage von 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ü/Teilsumme/Summe); Trainingssplits wurden nie ausgewertet. Beide Engines sahen dieselben Bilder, dieselbe Ground Truth und dasselbe Messprotokoll (warm_then_scored: ein fester Warm-up-Durchlauf geht dem bewerteten Durchlauf voraus, sodass Latenzzahlen im steady state liegen). Beide Läufe schlossen mit error_rate 0,0 auf beiden Datensätzen ab (Spalte error_rate in summary_metrics.csv). Der zugrundeliegende 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 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).
• Engines: Out-of-the-box, kein Feintuning. Versionen fixiert: docTR v1.0.1 (Single-Pass-Neural-OCR — Erkennungs- und Erkennungsphase zu einem OCR-Predictor zusammengefasst, GPU) und Docling 2.119.0 (Dokumentverarbeitungs-Pipeline — Layout-Analyse, Tabellenerkennung, Lesereihenfolge-Rekonstruktion um einen OCR-Kern herum gestaffelt, GPU) — gemäß der Modelltabelle im öffentlichen Repo (README.md) und den Durchlauf-Manifesten.
• LLM-Nachbearbeitung: deepseek-v4-flash via API bei Temperatur 0 für deterministische Ausgabe (die Spalte llm_model in field_method_comparison.csv); es war das einzige Modell für alle LLM-Felder-Zeilen beider Engines.
• Kostenbasis: Tatsächliche Laufzeit × $0.76/hr, inklusive Modellinitialisierung — Stapelverarbeitung 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 extrahiert werden. Sie messen OCR + nachgelagerte Extraktion, nicht die native strukturierte Ausgabe beider Modelle; die Spalten LLM_* messen OCR-Text + LLM-Extraktion. Die beiden Pipelines werden nie vermischt, und Doclings natives Dokumentmodell wird durch diesen Benchmark nicht bewertet.

Metrikdefinitionen

• CER (Character Error Rate): Editierdistanz (Einfügungen + Löschungen + Ersetzungen) zwischen OCR-Text und Ground Truth, geteilt durch die Ground-Truth-Zeichen. Niedriger ist besser.
• WER (Word Error Rate): dieselbe Editierdistanz-Berechnung auf Wortebene.
• Feldwert-F1 (Regex): Harmonisches Mittel aus Precision und 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.
• Feldwert-F1 (LLM): Dieselbe Metrik für die 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 — ein viel strengerer Maßstab als der Feld-F1-Wert.
• Latenz p50/p95 & Seiten/min: Stabilisierte Inferenzzeit pro Seite (warm-then-scored, ohne Modellladen) und tatsächliche Durchsatzrate inklusive Modellinitialisierung. Sie messen unterschiedliche Uhren.
• Kosten pro 1.000 Seiten: Abgerechnete GPU-Stunden für 1.000 Seiten zum erfassten Tarif von $0.76/hr, 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 doctr- und docling-Zeilen hier zurückführen.
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 doctr- und docling-Zeilen hier (und auf alle acht sroie_2019-Zeilen im Ranking-Kontext) zurückführen.
3. ImageToTableai/benchmark-ocr Repository. Öffentliches Repo mit den Ergebnis-CSVs, geschwärzten Ausführungs-Manifesten, eingefrorenem Protokoll und Datensatz-Beispiellisten (feste Test-Splits) 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 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).
7. Auer et al., "Docling Technical Report" (2024). Nur Architektur-Hintergrund — beschreibt Doclings gestuften Pipeline (Layout-Analyse, Tabellenerkennung, Lesereihenfolgen-Inferenz, Dokumentzusammenstellung). Keine Benchmark-Zahlen auf dieser Seite stammen aus dieser Quelle.

Einschränkungen

• Dokumentbereich — nur Quittungen: SROIE + CORD. Hier wird nichts von dem gemessen, was Doclings Wertversprechen ausmacht — Layout/Tabellen/Leseordnung/Langdokument-Verarbeitung; diese Fähigkeiten sind außerhalb des Geltungsbereichs, nicht widerlegt. Verwenden Sie diese Seite nicht, um zu dem Schluss zu kommen: „Docling ist schlecht." Sie kommt zu dem Schluss: Bei einer einfachen einseitigen Quittung lohnt sich der Pipeline-Overhead nicht.
• Stichprobengröße: 361 englische + 100 indonesische Quittungen. Feld-F1 und CER sind korpusabhängig; die hier dokumentierten Unterschiede (3,0× CER, 6,7× p50, 8,3× Kosten) liegen weit außerhalb des Rauschbandes, aber einprozentige Unterschiede sollten als Rauschen und nicht als ingenieurtechnische Wahrheit behandelt werden.
• Einzelne GPU-Stufe und ein 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 den absoluten Feld-F1; die 0,049-Punkte docTR-Führung kann an den Rändern wandern. Die LLM-Latenz (~1.996–2.365 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.
• 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 den Wartungskosten, die das LLM eliminiert; Doclings 2,9× Regex-Vorsprung wird gegen dieses einzelne feste Muster-Set gemessen.
• Doclings native Ausgabe wird nicht bewertet: Docling gibt ein strukturiertes Dokumentmodell aus, aber der Benchmark bewertet Text + Nachbearbeiter, nicht die native strukturierte Ausgabe. Eine Benchmark-Variante, die Doclings native Felder bewertet, wäre ein anderes Experiment; diese Seite unternimmt das nicht.
• CORD CER ist keine qualitätsbezogene Einzelmodell-Ableitung: CORD Ground Truth enthält Annotationselemente und keine der Engines wurde überwiegend auf Indonesisch trainiert; CORD CER (~0,91–0,92) 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 docTR v1.0.1 und Docling 2.119.0 (August 2026). Neuere Versionen beider Engines können jede Zahl auf dieser Seite verschieben.

Verwandte Referenzen: docTR vs Surya2 Quittungs-Benchmark · PaddleOCR vs EasyOCR Quittungs-Benchmark · Traditionelles OCR vs Dokument-Parsing VLMs · Regex vs LLM-Feldextraktion · Feld-Ebene vs Zeichen-Ebene Genauigkeit

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