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

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

Die beiden Engines stehen auf gegenüberliegenden Seiten einer grundlegenden architektonischen Kluft, und diese Kluft — nicht ein Code- oder Abstimmungsunterschied — ist die gesamte Geschichte dieser Seite. docTR ist eine neuronale OCR-Engine mit einem einzigen Durchlauf: Eine Erkennungsstufe lokalisiert Textbegrenzungsrahmen, und eine Erkennungsstufe transkribiert die Zeichen darin, zusammengesetzt zu einem OCR-Prädiktor, dessen Durchlauf von vorne nach hinten rohe Textzeilen erzeugt. Es gibt kein Layoutmodell, keinen Tabellenparser und keine Rekonstruktion der Lesereihenfolge — was gedruckt wird, kommt heraus, in der Reihenfolge, in der der Erkerner liest. Docling ist keine OCR-Engine und kein Vision-Language-Modell; es ist eine Dokument-Parsing-Pipeline. Laut eigenem technischem Bericht (zitiert für Architekturkontext, nicht für eine Zahl auf dieser Seite) stufenweise eine Sequenz von Modellen pro Seite — Layoutanalyse, Tabellenerkennung, Inferenz der Lesereihenfolge — aggregiert sie und erstellt ein intermediäres Dokumentobjekt, bevor Text ausgegeben wird, weshalb seine Ausgabe Struktur (Labels, Reihenfolge, Zonen) trägt, die docTR’s Zeilen nicht haben.

Warum dieser Mechanismus für einen Benchmark wichtig ist: Jedes gestufte Modell in Doclings Kette existiert, um Layoutstruktur auszunutzen — eine Tabelle zum Parsen, ein zweispaltiges Formular, ein Lesepfad, der nicht lexikalisch ist. Ein einfacher englischer Beleg hat fast nichts davon: eine Spalte, ein paar Zonen, ein meist vorhersehbarer Pfad von oben nach unten, keine Tabellen. Die gestufte Maschinerie läuft trotzdem auf jeder Seite — deshalb ist sie langsamer und teurer — aber ohne zu nutzende Struktur kann der Overhead nicht in besseren Text umgewandelt werden. Diese Seite isoliert genau diese Kosten und zeigt, was sie kauft — und was nicht.

Zeichengenauigkeit: Die Pipeline-Abgabe auf Rohtext

Bei SROIE 2019 ist die Rohtext-Lücke nicht knapp: CER 0,1971 (docTR) gegenüber 0,5909 (Docling) — ein 3,0×-Nachteil — und WER 0,3199 gegenüber 0,7596. Die Zeichenfehlerrate misst Einfügungen, Löschungen und Ersetzungen geteilt durch die Grundwahrheitszeichen — 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 rangiert 7. von 8 Engines im zugrunde liegenden Lauf, nur vor Unlimited-OCR (0,6552, Spalte cer in summary_metrics.csv, alle sroie_2019-Zeilen) — der docTR-vs-Surya2-Geschwistervergleich dokumentierte docTR als einen der beiden besten Erkerner in derselben Benchmark, und diese Seite zeigt dieselbe Engine am anderen Ende der Textgenauigkeitstabelle: Das ist eine Pipeline, keine schwächere Erkennungsfamilie.

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

Tabelle: summary_metrics.csv — Spalten cer / wer / error_rate, sroie_2019-Zeilen. Genaue 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 Lauf (nur vor Unlimited-OCRs 0,6552) — die rohe Zeichengenauigkeit ist der Ort, an dem sich die Pipeline-Abgabe zuerst zeigt.

Die Umkehrung: Regex-Feldextraktion dreht das Ergebnis um

Wenn man den Text beider Engines mit denselben festen Regex-Mustern auf die vier SROIE-Belegfelder (Firma, Datum, Adresse, Gesamtbetrag) benchmarkt — der traditionelle OCR- und regelbasierte Ansatz zur Schlüsselinformationsextraktion (KIE) — dreht sich die Rangfolge um: Docling extrahiert Felder mit einem F1-Wert von 0,2237 gegenüber 0,0766 bei docTR, ein 2,9-facher Vorteil. Dies sind die postprocessed_sroie_receipt_regex_*-Metriken des Benchmarks: feste Muster, die auf den OCR-Text jeder Engine angewendet werden — nachbearbeitet, nicht nativer strukturierter Output einer der beiden Engines, und Doclings natives Dokumentmodell wird hier nicht bewertet.

Der Feldwert-F1 ist das harmonische Mittel aus Präzision und Recall über extrahierte Feldwerte im Vergleich zur Ground Truth — 1,0 bedeutet, dass jedes Belegfeld perfekt wiederhergestellt wurde, 0 bedeutet nichts. Der Mechanismus hinter der Umkehrung ist derselbe Architekturunterschied, der die CER-Lücke verursacht hat, nur in die entgegengesetzte Richtung wirkend: Doclings Dokumentmodell ordnet Text in einen Lesepfad und verknüpft Beschriftungen mit Werten, sodass sein ausgegebener Text in seiner Form näher an dem liegt, was die festen Muster erwarten; docTRs sauberer, aber roher Zeilentext — genau nach CER, aber mit ursprünglicher Groß-/Kleinschreibung, Trennzeichenrauschen und ohne Beschriftungsrahmen — überwindet die Muster nicht. docTRs Regex-Feld-F1 von 0,0766 ist der schlechteste aller acht Engines im zugrunde liegenden Lauf, trotz seiner besten CER-Werte in ihrer Klasse (summary_metrics.csv-Felder field_f1_regex und cer, alle sroie_2019-Zeilen); Doclings 0,2237 belegt den sechsten Platz. Dieselbe Entkopplung, die der parallele Vergleich an der Spitze der Genauigkeitsleiter dokumentiert hat (docTR vs. Surya2), wiederholt sich hier am unteren Ende: Textgenauigkeit ist nicht Feldgenauigkeit.

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-Spalten, sroie_2019-Zeilen. Dies sind postprocessed_sroie_receipt_regex_*-Metriken: feste Muster, die auf den OCR-Text jeder Engine angewendet werden, keine native strukturierte Extraktion. Keine der beiden Engines erhält durch Regex bei einem einzigen SROIE-Beleg alle vier Felder exakt richtig (0.0000, eine wörtliche Null in der CSV). docTRs Regex-Feld-F1 von 0.0766 ist der niedrigste aller acht Engines im zugrunde liegenden Lauf.

LLM-Nachbearbeitung stellt das Ranking wieder her — teilweise

Füttert man den Text beider Engines einem LLM-Nachbearbeiter (deepseek-v4-flash bei Temperatur 0) mit einem Prompt zur strukturierten Extraktion, gewinnt docTR die Führung zurück: Feld-F1 0.6171 gegenüber 0.5685 — ein Vorsprung von 0.049 Punkten, klein im Vergleich zur rohen CER-Lücke, aber nicht ausgelöscht. Der sauberere Basistext bringt mehr wiederherstellbare Feldwerte hervor; das LLM gleicht Doclings Layout-Artefakte teilweise aus, löscht sie aber nicht vollständig.

Dies ist dasselbe Konvergenzband, das im gesamten Acht-Engine-Benchmark zu sehen ist — LLM-Nachbearbeitung bringt gesunde Engines zusammen, weil sie Semantik (Zahlen, Daten, Namen) versteht, statt Zeichenformen abzugleichen — und die verbleibende Lücke ist relevant: docTRs 0.6171 ist die beste LLM-Feld-F1 aller acht Engines, während Doclings 0.5685 auf Rang sechs liegt (field_method_comparison.csv llm_field_value_f1, alle sroie_2019-Zeilen). Die strengere Messlatte — Dokumente, bei denen alle vier Felder exakt übereinstimmen — trennt sie um das 2,7×-Fache: docTR 0.1496 gegenüber Docling 0.0554. Mit dem Hebel sind zwei Kosten verbunden: Ein LLM-Aufruf addiert ~2,0–2,4 s mediane Latenz pro Dokument zusätzlich zur OCR-Zeit (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 entsteht über die API und ist getrennt von der Engine-Latenz (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-Abgabe ist dort am höchsten, wo die Durchsatzplanung stattfindet. Auf derselben RTX 4090 zum gleichen aufgezeichneten Satz von 0,76 $/Std. erreicht docTR 449,3 Seiten/Min. bei 108,7 ms p50 pro Seite für 0,048 $ pro 1.000 Seiten; Docling erreicht 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 Endbereich ist für die Pipeline proportional schlechter: p95 281,4 ms gegenüber 3.239,8 ms, eine 11,5× Lücke, weil Doclings gestaffelte Modelle ihre Worst-Case-Zeiten Seite für Seite summieren.

Die Kosten werden als Wanduhr-Laufzeit × dem RunPod-RTX-4090-Satz (0,76 $/Stunde, Preis mit Zeitstempel in den Laufmanifesten) berechnet, einschließlich der Modellinitialisierung — der Preis, den Sie tatsächlich für die GPU-Zeit zahlen würden. Der Durchsatz ist die Wanduhr-Seitenzahl pro Minute einschließlich derselben Initialisierung. Die Latenz p50/p95 sind die stationären Inferenzzeiten pro Seite, gemessen warm-dann-bewertet (Modellladung ausgeschlossen). docTR ist die schnellste und günstigste Engine aller acht im zugrunde liegenden Lauf auf SROIE; Docling liegt bei 56,7 Seiten/Min. und 0,398 $ pro 1.000 Seiten in der unteren Hälfte der Betriebsbereichstabelle (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, alle sroie_2019-Zeilen).

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

Quelle: summary_metrics.csv — Spalte cost_per_1000_pages, sroie_2019-Zeilen. docTR 0,0479, Docling 0,3978. Kosten = Wanduhr-Laufzeit × 0,76 $/Std. einschließlich Modellinitialisierung, Preis mit Zeitstempel in den Laufmanifesten (August 2026). docTR ist die günstigste Engine der acht im zugrunde liegenden 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/Std. Preis in Manifests zeitgestempelt); Kosten inklusive Modellinitialisierung. Exakte Werte: docTR p50 108,72 / p95 281,38 / 449,31 Seiten/Min. / $0,0479; Docling p50 732,00 / p95 3239,79 / 56,66 Seiten/Min. / $0,3978.

CORD (indonesische Belege): Beide scheitern, docTRs LLM-Feldwiederherstellung führt weiterhin

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 scheitern beim rohen CER: 0.9101 (docTR) und 0.9219 (Docling), ein sprachbedingter Gleichstand. Gemäß Benchmark-Protokoll werden die CORD-Zahlen getrennt vom SROIE-Vergleich gehalten — niemals in ein Ranking eingemischt — da der Ground-Truth-Text von CORD Annotationsstrukturen enthält, die das rohe CER für jede Engine zusätzlich zur echten Sprachdiskrepanz erhöhen.

Bei den Feldmetriken schrumpft Doclings einzig verbliebener Vorteil auf fast nichts: Über Regex-Muster stellen beide Engines fast keine CORD-Felder wieder her (docTR 0.0000 — eine buchstäbliche Null in der CSV — gegenüber Doclings 0.0612, da die englischen Muster nie für indonesischen Text geschrieben wurden). Der LLM-Postprozessor absorbiert den Sprachschock auf beiden Seiten, hält docTR aber vorn: Feld-F1 0.5500 gegenüber 0.4695. CORD wird hier für den Kontext der Sprachrobustheit angeführt; es wird bewusst nie mit den SROIE-Zahlen zu einer einzigen Rangliste zusammengeführt.

Tabelle: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) und field_method_comparison.csv (Feld-F1), cord_v2-Zeilen. CORD-Zahlen nicht in ein SROIE-Ranking einmischen: Der CORD-CER kombiniert echte Sprachabweichung mit einer durch die Annotationsstruktur bedingten Verzerrung in der Ground Truth, und die Regex-Muster wurden für englische Formate geschrieben. docTRs CORD-Regex-Feld-F1 von 0.0000 ist eine im CSV erfasste buchstäbliche Null, kein fehlender Wert.

Wer gewinnt wann: Die Übersichtstabelle

“Besser” hängt vom Arbeitsaufkommen ab, und dieser direkte Vergleich trennt die Achsen sauber: bei einer einfachen englischen Quittung sprechen alle Geschwindigkeits-/Kostenachsen und die Rohtext-Achse für docTR; die Out-of-the-Box-Regex-Feldinversion spricht für Docling; ein LLM-Nachbearbeitungsschritt bringt sie auf einen 0.049-Punkte-Vorsprung für docTR zurück; und die Fähigkeiten, für die Docling existiert — Layout, Tabellen, Lesereihenfolge, lange Dokumente — sind hier nicht gemessen, nicht widerlegt.

Häufig gestellte Fragen

Ist Docling bei Belegen genauer als docTR?

Nein — bei der rohen Zeichengenauigkeit ist Docling 3,0× schlechter: SROIE CER 0,5909 gegenüber 0,1971 und WER 0,7596 gegenüber 0,3199 (summary_metrics.csv, cer / wer, sroie_2019-Zeilen). Docling “gewinnt” nur bei einer gemessenen Kennzahl: der Feld-Extraktion mit festen Regex-Mustern ohne weitere Verarbeitung (0,2237 gegenüber 0,0766 Feld-F1) — und ein LLM-Nachbearbeitungsschritt dreht das wieder zugunsten von docTR (0,6171 gegenüber 0,5685).

Warum extrahiert Docling Felder mit Regex besser, obwohl der rohe Text deutlich schlechter ist?

Weil die beiden Metriken unterschiedliche Dinge bewerten und die Ausgabeform von Docling zufällig zu den Mustern passt. Die Dokument-Pipeline von Docling ordnet Text in eine Lesereihenfolge und verknüpft Beschriftungen mit Werten, sodass der ausgegebene Text strukturell näher an dem liegt, was die festen Regex-Muster erwarten; docTR liefert sauberen rohen Zeilentext, der nach CER genau ist, aber die Muster nicht erfüllt (0,0766 Feld-F1, der schlechteste Wert der acht Engines, bei bester Zeichengenauigkeit in seiner Klasse). Dabei handelt es sich um postprocessed_sroie_receipt_regex_*-Werte — OCR-Text, der durch feste Muster läuft — nicht um native strukturierte Ausgabe (field_method_comparison.csv, regex_field_value_f1, sroie_2019-Zeilen). Dieselbe Entkopplung von Textgenauigkeit ≠ Feldgenauigkeit zeigt sich in diesem gesamten Benchmark.

Warum ist Docling pro Seite so viel langsamer und teurer?

Weil auf jeder Seite eine gestufte Dokument-Pipeline läuft — Layout-Analyse, Tabellenerkennung, Rekonstruktion der Lesereihenfolge und ein Zwischen-Dokumentmodell — selbst wenn die Seite ein einfacher Beleg ohne ausnutzbare Struktur ist. Bei SROIE beträgt dieser Aufwand 6,7× beim p50 (108,7 gegenüber 732,0 ms), 11,5× beim p95, 7,9× geringerer Durchsatz (449,3 gegenüber 56,7 Seiten/min) und 8,3× höhere Kosten pro 1.000 Seiten ($0,048 gegenüber $0,398) — gleiche GPU, gleiches Protokoll (summary_metrics.csv, sroie_2019-Zeilen).

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

Größtenteils, aber nicht vollständig: Das LLM-nachbearbeitete Feld-F1 bei SROIE liegt bei docTR 0,6171 gegenüber Docling 0,5685 — ein Vorsprung von 0,049 Punkten für docTR, der die teilweise Kompensation der Layout-Artefakte von Docling durch das LLM übersteht (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen). Die Kosten der Annäherung betragen ~2,0–2,4 s zusätzlicher medianer LLM-Latenz pro Dokument (llm_median_latency_ms, gleiche Zeilen).

Bedeutet dieses Benchmark, dass Docling schlecht ist?

Nein — es bedeutet, dass die Stärken von Docling hier nicht gemessen werden. Docling ist eine Dokument-Parsing-Pipeline, deren Nutzenversprechen — Layout-Struktur, Tabellen, Lesereihenfolge, Formulare, lange Dokumente — genau das ist, was ein reines Beleg-Benchmark nicht testen kann. Was diese Seite zeigt, ist enger gefasst: Bei einem einfachen einseitigen Beleg rechtfertigt der Pipeline-Overhead seine Kosten nicht (3,0× schlechteres CER, 8,3× Kosten), und sein einziger gemessener Vorteil (2,9× Regex-Feld-F1) wird durch ein LLM-Nachbearbeitungsmodul zunichtegemacht. Die ehrliche Einordnung ist der Umfang, nicht das Urteil.

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

Zwei sich überlagernde 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 Ground-Truth-Text von CORD — das CER liegt bei 0,9101 (docTR) und 0,9219 (Docling) (summary_metrics.csv, cer, cord_v2-Zeilen). Unter einem LLM-Nachbearbeitungsmodul hält docTRs Feld-F1 bei 0,5500 gegenüber Doclings 0,4695 — die SROIE-Reihenfolge, komprimiert. CORD-Zeilen werden zitiert und nie in eine kombinierte Rangliste aufgenommen.

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

Für hohe Mengen an Belegtext mit abgerechneten 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 zugrunde liegenden Acht-Engine-Lauf. Wenn Ihre Pipeline strukturierten Text ohne Nachbearbeitung direkt nutzt, ist Doclings Regex-Feld-Vorteil (0,2237 vs. 0,0766) ein echter Startvorteil. Wenn LLM-Nachbearbeitung Teil des Designs ist, bleibt docTR um 0,049 vorn und ist günstiger zu speisen. Wenn Ihre Arbeitslast aus layoutlastigen Dokumenten besteht — Tabellen, Formularen, langen Berichten —, ist dieser Benchmark nicht der richtige Beleg für die Entscheidung; er 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 unter ImageToTableai/benchmark-ocr, mit einer 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 Latenzzahlen 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). 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 NVIDIA RTX 4090 (24 GB); die GPU-Kosten wurden zum On-Demand-Tarif von RunPod von 0,76 $/Std. berechnet, der Preis ist in jedem Lauf im geschwärzten Manifest mit Zeitstempel versehen (August 2026).
• Engines: Standardkonfiguration, ohne Feintuning. Versionen festgelegt: docTR v1.0.1 (einzelner neuronaler OCR-Durchlauf — Erkennungs- und Erfassungsstufe zu einem OCR-Prädiktor zusammengefasst, GPU) und Docling 2.119.0 (Dokumentenanalyse-Pipeline — Layoutanalyse, Tabellenerkennung, Lesereihenfolge-Rekonstruktion, gestuft um einen OCR-Kern, GPU) — gemäß der öffentlichen Modelltabelle des Repos (README.md) und der Lauf-Manifeste.
• 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 auf beiden Engines verwendet wurde.
• Kostenbasis: Wanduhr-Laufzeit × 0,76 $/Std., einschließlich Modellinitialisierung — Stapelverarbeitung senkt die Kosten pro Seite.
• Feldnachbearbeitung: Die SROIE-Regex-Feldmetriken sind postprocessed_sroie_receipt_regex_* (field_method_comparison.csv regex_*-Spalten) — Felder, die aus dem OCR-Text durch einen festen Mustersatz extrahiert wurden. 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 nie vermischt, und das native Dokumentmodell von Docling wird von diesem Benchmark nicht bewertet.

Metrikdefinitionen

• CER (Zeichenfehlerrate): Editierdistanz (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 Editierdistanzberechnung auf Wortebene.
• Feldwert-F1 (Regex): harmonisches Mittel aus Präzision und Recall über extrahierte Feldwerte unter Verwendung fester Regex-Muster auf OCR-Text (traditionelle OCR + regelbasierte KIE-Pipeline). Spalte: regex_field_value_f1. Ein Wert von 0 bedeutet, dass keine Feldwerte wiederhergestellt wurden.
• Feldwert-F1 (LLM): dieselbe Metrik auf der Ausgabe des LLM-Nachbearbeiters (OCR-Text → deepseek-v4-flash → Felder). Spalte: llm_field_value_f1. Die beiden Pipelines sind unterschiedlich und werden nie vermischt.
• Dokumentfelder exakt: Anteil der Dokumente, bei denen alle Zielfelder exakt übereinstimmten — eine 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.
• Kosten pro 1.000 Seiten: abgerechnete GPU-Stunden für 1.000 Seiten zum aufgezeichneten Tarif von 0,76 $/Std., einschließlich Modellinitialisierung.

Quellenverzeichnis

1. summary_metrics.csv (GitHub raw). 16 Zeilen = 8 Modelle × 2 Datensätze. Spalten: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Jede CER/WER-, Latenz-, Kosten- und Durchsatzzahl auf dieser Seite stammt aus den doctr- und docling-Zeilen hier.
2. field_method_comparison.csv (GitHub raw). 16 Zeilen; Spalten model, dataset, llm_model (= deepseek-v4-flash), regex/llm-Feldwertgenauigkeit und F1, document-fields-exact, llm_median_latency_ms, Tokenanzahl. Jede Regex/LLM-Feld-F1-Zahl stammt aus den doctr- und docling-Zeilen hier (sowie aus allen acht sroie_2019-Zeilen im Ranking-Kontext).
3. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository mit den Ergebnis-CSVs, redigierten Lauf-Manifesten, eingefrorenem Protokoll und Datensatz-Stichprobenlisten (feste Test-Splits) zur Reproduktion.
4. results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf (16 Läufe) mit Modellversionen, GPU/Treiber, torch/CUDA/Python-Versionen, Kostenmetadaten mit Preiszeitstempel und Artefakt-Hashes.
5. Huang et al., „ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction“ (2019). SROIE-2019-Datensatzdefinition, Aufgabenstruktur und Lizenz (CC-BY-4.0).
6. Park et al., „CORD: A Consolidated Receipt Dataset for Post-OCR Parsing“ (2020). CORD-v2-Datensatzdefinition, verschachteltes Feldschema und Lizenz (CC-BY-4.0).
7. Auer et al., „Docling Technical Report“ (2024). Nur Architekturhintergrund — beschreibt Doclings gestufte Pipeline (Layoutanalyse, Tabellenerkennung, Lesereihenfolge-Inferenz, Dokumentaufbau). Keine Benchmark-Zahlen auf dieser Seite stammen daraus.

Einschränkungen

• Dokumentumfang — nur Belege: SROIE + CORD. Hier wird nichts an Layout-, Tabellen-, Lesereihenfolge- oder Langdokument-Verarbeitung gemessen, die Doclings Wertversprechen ausmachen; diese Fähigkeiten sind außerhalb des Rahmens, nicht widerlegt. Verwenden Sie diese Seite nicht, um zu schlussfolgern: „Docling ist schlecht.“ Sie kommt zu dem Schluss: Bei einem einfachen einseitigen Beleg rechtfertigt der Pipeline-Overhead seinen Aufwand nicht.
• Stichprobengröße: 361 englische + 100 indonesische Belege. Feld-F1 und CER sind korpusabhängig; die hier dokumentierten Lücken (3,0× CER, 6,7× p50, 8,3× Kosten) liegen weit außerhalb des Rauschbands, aber Unterschiede im einstelligen Prozentbereich sollten als Rauschen behandelt werden, nicht als technische Wahrheit.
• Einzelne GPU-Stufe und einzelner Preis: Alle Zahlen stammen von einer RTX 4090 bei 0,76 $/Std., Preisstand August 2026 in den Run-Manifesten. Andere GPUs, Multi-GPU-Serving, Batch-Scheduling oder Preisänderungen verschieben Latenz, Durchsatz und Kosten — leiten Sie Kosten zu aktuellen Sätzen neu ab, bevor Sie budgetieren.
• Einzelner LLM-Postprozessor: Alle LLM-Zeilen verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt die absolute Feld-F1; der 0,049-Punkte-Vorsprung von docTR kann sich an den Rändern bewegen. LLM-Latenz (~1.996–2.365 ms Median auf SROIE, field_method_comparison.csv llm_median_latency_ms) ist API-bedingt und nicht Teil der Latenz einer der beiden Engines.
• Regex-Abstimmung: Das Musterset wurde einmal pro Datensatz geschrieben. Eine pro-Format, stark abgestimmte Musterbibliothek könnte bei eigenen Layouts höher punkten — zu den Wartungskosten, die das LLM entfernt; Doclings 2,9×-Regex-Vorsprung wird gegen dieses einzelne feste Musterset gemessen.
• Doclings natives Ergebnis wird nicht bewertet: Docling gibt ein strukturiertes Dokumentmodell aus, aber der Benchmark bewertet Text + Postprozessoren, nicht natives strukturiertes Ergebnis. Eine Benchmark-Variante, die Doclings native Felder bewertet, wäre ein anderes Experiment; diese Seite versucht es nicht.
• CORD-CER ist keine Qualitätsmessung pro Modell: Die CORD-Ground-Truth enthält Annotationsstruktur, und keine der beiden Engines wurde überwiegend mit Indonesisch trainiert; CORD-CER (~0,91–0,92) spiegelt Sprachmismatch + Ground-Truth-Aufblähung wider. CORD-Zeilen werden mit Rahmen zitiert und niemals in ein SROIE-Ranking eingemischt (Protokollregel).
• Versions-Pinning: Ergebnisse gelten für docTR v1.0.1 und Docling 2.119.0 (August 2026). Neuere Versionen einer der beiden Engines können jede Zahl auf dieser Seite verschieben.

Verwandte Referenzen: docTR vs. Surya2-Beleg-Benchmark · PaddleOCR vs. EasyOCR-Beleg-Benchmark · Traditionelle OCR vs. Dokument-Parsing-VLMs · Regelbasierte Extraktion vs. LLM-Extraktion · Feldebene vs. Zeichenebene-Genauigkeit

Verwandte Lektüre: die Genauigkeitslücke zwischen KI und traditioneller OCR · KI-Bildextraktion im Vergleich zu traditioneller OCR · KI-Dokumentextraktions-Preise (2026)