Regex vs. LLM-Feldextraktion bei Belegen
First-Party-Benchmark-Ergebnisse (2026)

SROIE-Ergebnisse: Englische Belege (361 Stichproben)

Bei englischen Belegen schlägt das LLM regex für alle 8 Engines — der kleinste Zuwachs beträgt 1,76× (PaddleOCR-VL 0,337 → 0,592), der größte 8,1×. Und das LLM gleicht die Modellunterschiede nahezu aus: 6 der 7 Nicht-Tesseract-Engines liegen innerhalb eines 0,05-Punkte-Bandes (0,569–0,617), während ihre regex-Ergebnisse über 0,26 Punkte verteilt waren (0,077–0,338).

SROIE (Scanned Receipt OCR and Information Extraction, ICDAR 2019) ist der Standard-Benchmark für englische Belege: 361 Testbelege mit vier Zielfeldern — Unternehmen, Datum, Adresse und Gesamtsumme (Huang et al., 2019). Jede Engine erzeugte zunächst OCR-Text auf einer gemeinsamen RTX-4090-Umgebung; dieser Text wurde dann zwei parallelen Nachverarbeitern zugeführt: einem festen Satz von regex-Mustern (der traditionelle OCR- und regelbasierte KIE-Ansatz) und dem LLM deepseek-v4-flash mit einem strukturierten Extraktions-Prompt. Beide wurden gegen dieselben Ground-Truth-Felder bewertet. Das Diagramm zeigt regex-Feld-F1 (blau) vs. LLM-Feld-F1 (grün) pro Engine.

Quelle: field_method_comparison.csv — Zeilen für dataset=sroie_2019, Spalten regex_field_value_f1 / llm_field_value_f1 (als 0–1-Dezimalen gespeichert, als % angezeigt). LLM-Nachverarbeiter: deepseek-v4-flash (Spalte llm_model). 361 Stichproben pro Engine (llm_ok_count).

Quelle: field_method_comparison.csv — sroie_2019-Zeilen: regex_field_value_f1 / llm_field_value_f1 / regex_field_value_accuracy / llm_field_value_accuracy (0–1-Dezimalen als % angezeigt). docTR F1 0,0766 → 0,6171; Surya2 0,3183 → 0,6139; PaddleOCR 0,3254 → 0,5810.

CORD-Ergebnisse: Indonesische Belege (100 Stichproben, Stresstest)

CORD vergrößert die Kluft – nicht weil das LLM besser wird (das tut es nicht), sondern weil regex zusammenbricht: Sechs der acht Engines erreichen beim regex-Feld-F1 höchstens 10,8 %, und zwei (docTR 0,0 %, EasyOCR 0,7 %) gewinnen fast nichts zurück. Das LLM hebt dennoch jede Nicht-Tesseract-Engine auf mindestens 33,8 %, was beweist, dass seine Extraktion sprach- und layoutübergreifend generalisiert, wo handgeschriebene Muster versagen.

CORD v2 ist ein indonesischsprachiger Belegdatensatz mit verschachtelten Feldern (menu, sub_total, total) (Park et al., 2019), der als sprachübergreifender Stresstest dient: Keine der 8 Engines wurde primär mit indonesischen Belegen trainiert. Beim Lesen dieser Tabelle gelten zwei Einschränkungen. Erstens enthält der Ground-Truth-Text von CORD Annotationsstruktur- und VLM-Ausgabenormalisierungsunterschiede, die den rohen CER für jede Engine systematisch erhöhen – daher sind die Feldmetriken unten, nicht der CER, der faire Modellvergleich. Zweitens wurden die regex-Muster für das flache englische SROIE-Schema geschrieben; CORDs verschachteltes Schema und die indonesische Formatierung (Rp-Währung, Datumskonventionen) überfordern sie – was selbst das Ergebnis ist: Regeln, die auf einen Markt zugeschnitten sind, übertragen sich nicht.

Quelle: field_method_comparison.csv — Zeilen für dataset=cord_v2, Spalten regex_field_value_f1 / llm_field_value_f1 (0–1 Dezimalstellen als % angezeigt). 100 Stichproben pro Engine (llm_ok_count).

Quelle: field_method_comparison.csv — cord_v2-Zeilen (regex/LLM-Feldwert-F1 und -Genauigkeit, 0–1 Dezimalstellen als % angezeigt). PaddleOCR LLM F1 0,0154 → 0,5527; docTR 0,0 → 0,5500; tesseract 0,0752 → 0,1627.

Warum das LLM die Lücke schließt — und wo seine Grenze liegt

Drei Muster in den Zahlen erklären, was an der Oberfläche geschieht. Jedes ist eine überprüfbare Aussage mit den genauen CSV-Zellen darunter.

(a) Das LLM verwandelt eine Modelllücke von 0,26 Punkten in ein Band von 0,05 Punkten

Mit regex spielte die Wahl der Engine eine enorme Rolle: Der SROIE-Feld-F1 reichte von 0,077 (docTR) bis 0,338 (Unlimited-OCR) — eine Spanne von 0,26 Punkten. Mit dem LLM landen sechs der sieben Nicht-Tesseract-Engines zwischen 0,569 (Docling) und 0,617 (docTR) — ein Band von 0,05 Punkten (field_method_comparison.csv, sroie_2019-Zeilen, regex_field_value_f1 vs. llm_field_value_f1). Die vorgelagerte OCR muss nur lesbaren Text liefern; das LLM extrahiert Felder daraus mit weitgehend engine-unabhängiger Qualität. Zwei Engines bleiben hinter diesem Band zurück: EasyOCR mit 0,372 (der niedrigste LLM-F1 auf englischen Belegen) und Tesseract mit 0,439. Bei CORD wird Tesseract zum klaren Schlusslicht — sein 0,163 ist das schlechteste LLM-Ergebnis in der gesamten Tabelle.

(b) Tesseracts Grenze wird von seiner OCR gesetzt, nicht von seinem Postprozessor

„Müll rein, Müll raus" gilt auch für die LLM-Nachverarbeitung. Tesseracts roher OCR-Text auf indonesischen Belegen hat eine Zeichenfehlerrate von 0,9523 (summary_metrics.csv, tesseract/cord_v2, cer) — etwa 95 von 100 Zeichen sind falsch oder falsch angeordnet. Sein LLM-Feld-F1 bei CORD liegt folglich bei 0,1627 (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1): Ein LLM kann keinen Firmennamen oder Gesamtbetrag aus Text extrahieren, den es nicht lesen kann. Die Grenze jedes Postprozessors wird durch die darunterliegende OCR-Basisqualität gesetzt — eine Einschränkung, die kein Prompt-Engineering beseitigt.

(c) docTR ist der größte Gewinner: vom regex-Tiefstwert zum LLM-Höchstwert

docTRs Geschichte ist die klarste Demonstration, dass das Problem der Postprozessor war, nicht die OCR. Sein regex-Feld-F1 bei SROIE war mit 0,0766 der niedrigste aller 8 Engines — sein sauberer, genauer Text (SROIE-CER 0,1971, der beste im Benchmark, summary_metrics.csv-Zeile für doctr/sroie_2019) passte einfach nicht auf die regex-Muster für Summen mit Tausendertrennzeichen oder mehrzeilige Adressen. Mit dem LLM liefert derselbe Text das höchste SROIE-Ergebnis des Benchmarks, 0,6171 — eine 8,1×-Steigerung und die größte in der Tabelle (field_method_comparison.csv, doctr/sroie_2019, regex_field_value_f1 0,0766 → llm_field_value_f1 0,6171). Bei CORD wiederholt sich der Effekt: 0,0 mit regex, 0,5500 mit dem LLM.

Wann Regex ausreicht vs. wann Sie ein LLM verwenden sollten

Der ehrliche Kompromiss ist nicht „Regex ist kaputt“, sondern „Regex ist fragil, wo Belege variabel sind.“ Regex-Nachbearbeitung ist deterministisch, kostenlos und sofort; ein LLM-Nachbearbeiter fügt Tokens und 1,8–2,4 s Median pro Dokument hinzu (field_method_comparison.csv, llm_median_latency_ms über alle 16 Zeilen). Im Gegenzug hat das LLM auf SROIE 1,76–8,1× mehr Felder wiederhergestellt — und auf CORD, wo Regex für die meisten Engines auf nahezu Null fiel, hat das LLM 33,8–55,3 % der Felder wiederhergestellt, die regelbasierte Extraktion schlicht nicht erreichen konnte.

Wann Regex ausreicht: Wenn Ihre Dokumente aus einem kleinen, stabilen Satz von Layouts stammen und die benötigten Felder in nahezu konstanten Formaten erscheinen — ein festes Rechnungsnummernmuster, eine einzige Datumskonvention, eine Währung — ist Regex das richtige Werkzeug: Es kostet nichts, läuft in Mikrosekunden, und seine Fehler sind vorhersehbar. Die Basisfälle des Benchmarks zeigen dies: Engines mit belegangepasstem Regex erreichten auf SROIE immer noch 0,34 Feld-F1 (Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368).

Wann Sie ein LLM verwenden sollten: Sobald Formatvarianz ins Spiel kommt — mehrere Währungen, regionale Datumsformate, mehrzeilige Adressen, Verkäufernamen in unterschiedlichen Stilen oder eine zweite Sprache. Jede davon bricht ein Muster; das LLM absorbiert sie alle in einem Prompt. Die CORD-Ergebnisse des Benchmarks quantifizieren, was „eine weitere Sprache“ eine regelbasierte Pipeline kostet: Die Regex-Feld-F1 fiel von 0,08–0,34 (englisch SROIE) auf 0,00–0,34 (indonesisch CORD), während das LLM 0,16–0,55 hielt — eine Strafe, die der Regex-Ansatz zu 100 % zahlte und das LLM nur teilweise. Die richtige Architektur für die meisten Produktionsabläufe ist hybrid: LLM-Extraktion für variable Felder, Regex- oder regelbasierte Validierung für Felder mit strengen erwarteten Formaten, wobei die 1,8–2,4 s LLM-Kosten pro Dokument in asynchroner Batch-Verarbeitung amortisiert werden, statt in synchronen Benutzerwartezeiten.

Häufig gestellte Fragen

Ist die LLM-Feldextraktion genauer als die Regex-Extraktion?

Ja, in diesem Benchmark, in jeder Zeile: Die LLM-Nachbearbeitung (deepseek-v4-flash) schlug die Regex-Nachbearbeitung bei allen 8 OCR-Engines auf beiden Datensätzen (field_method_comparison.csv, alle 16 Zeilen). Bei SROIE-englischen Belegen lag der LLM-Feld-F1 bei 0.37–0.62 gegenüber Regex 0.08–0.34; bei CORD-indonesischen Belegen 0.16–0.55 gegenüber 0.00–0.34.

Welches OCR-Modell extrahiert Belegfelder mit LLM-Nachbearbeitung am besten?

docTR auf SROIE, mit 0.6171 Feld-F1 — aber die Unterschiede zwischen den Engines verschwinden größtenteils, sobald ein LLM im Spiel ist: Sechs der sieben Nicht-Tesseract-Engines liegen zwischen 0.569 und 0.617 (field_method_comparison.csv, sroie_2019-Zeilen, llm_field_value_f1). Auf CORD führt PaddleOCR mit 0.5527, dicht gefolgt von docTR mit 0.5500.

Warum fällt Tesseract selbst mit einem LLM zurück?

Weil sein OCR-Text zu stark degradiert ist, als dass ein Nachbearbeiter Felder daraus wiederherstellen könnte. Bei indonesischen Belegen liegt seine Zeichenfehlerrate bei 0.9523 (summary_metrics.csv, tesseract/cord_v2), was seinen LLM-Feld-F1 auf 0.1627 begrenzt — das schlechteste LLM-Ergebnis im Benchmark (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1).

Wie stark verbessert ein LLM die Feldextraktion gegenüber Regex?

Zwischen 1.76× und 8.1× bei englischen Belegen, je nach Engine, mit dem größten Anstieg bei docTR (0.077 → 0.617 Feld-F1, field_method_comparison.csv sroie_2019-Zeilen). Bei indonesischen Belegen ist der Anstieg weitaus größer — 36× für PaddleOCR und praktisch unbegrenzt für docTR (0.0 → 0.55), da Regex fast nichts wiederherstellen konnte.

Erfasst die LLM-Nachbearbeitung wirklich jedes Feld korrekt?

Nein — und das sollte auch nicht erwartet werden. Der beste LLM-Feld-F1-Wert im Benchmark liegt bei 0,617 (docTR, SROIE), was bedeutet, dass etwa 38% der Felder weiterhin übersehen oder falsch waren, und die beste exakte Übereinstimmungsrate für ganze Dokumente liegt bei 15,5% (Surya2, SROIE, llm_document_fields_exact) — d. h., höchstens etwa 1 von 6 Dokumenten hatte alle vier Felder exakt richtig. Die LLM-Extraktion ist eine große Verbesserung gegenüber regex, aber kein Allheilmittel; eine feldbezogene Konfidenzbewertung und menschliche Überprüfung bleiben für den Produktionsbetrieb notwendig.

Wie langsam oder teuer ist die LLM-Nachbearbeitung?

In diesem Benchmark erhöhte der LLM-Aufruf die mediane Latenz pro Dokument um 1,8–2,4 s (field_method_comparison.csv, llm_median_latency_ms, alle 16 Zeilen), und der vollständige 16-Gruppen-Lauf verbrauchte etwa 1,33 Mio. Prompt- + 0,28 Mio. Completion-Tokens (Summe aus llm_prompt_tokens / llm_completion_tokens). Dies ist keine Echtzeit-Feldextraktionslatenz — es eignet sich für asynchrone Batch-Verarbeitung, nicht für interaktive Abfragen.

Funktioniert die LLM-Nachbearbeitung bei nicht-englischen Belegen?

Besser als regex, aber mit einer geringeren Obergrenze. Bei indonesischen CORD-Belegen hielt der LLM den Feld-F1-Wert bei 0,16–0,55, während regex auf 0,00–0,34 einbrach (field_method_comparison.csv, cord_v2-Zeilen) — aber das beste CORD-Ergebnis (0,5527) bleibt hinter dem besten englischen Ergebnis (0,6171) zurück, was sowohl die schwierigere Schrift als auch die schlechtere OCR-Basis widerspiegelt. Für englische Belege geschriebene Regeln funktionierten praktisch nicht mehr; der LLM verschlechterte sich stattdessen graduell.

Methodik & Quellen

Protokoll

Diese Seite berichtet den Feld-Extraktionsvergleich des ImageToTable.ai Open-Source-OCR-Benchmarks — ein unabhängiger, reproduzierbarer experimenteller Durchlauf (offizielle Stufe), keine Übersicht über Behauptungen Dritter. Die Pipeline für jedes (Modell × Datensatz)-Paar: Die OCR-Engine erzeugt Text aus Belegbildern; dieser Text wird dann zweimal extrahiert — einmal durch einen festen Satz von regex-Mustern und einmal durch den LLM-Nachbearbeiter — und beide Ausgaben werden gegen dieselben Ground-Truth-Felder bewertet. Der LLM-Nachbearbeiter ist deepseek-v4-flash (die llm_model-Spalte in der Vergleichs-CSV), ausgeführt bei Temperatur 0 für deterministische Ausgabe. Alle 361 SROIE- und 100 CORD-Stichproben wurden erfolgreich abgeschlossen (llm_ok_count = 361 / 100).

Laufzeitumgebung

• Hardware: alle GPU-Läufe auf NVIDIA RTX 4090 (24 GB). Die PyTorch-basierten Engines (docTR, EasyOCR, Docling) liefen mit PyTorch 2.8.0+cu128 (CUDA 12.8); Tesseract lief nur auf CPU (keine GPU-Kosten); die vLLM-basierten Engines (Surya2, Unlimited-OCR, PaddleOCR-VL) liefen auf einem vLLM-Pod. Treiber- und Python-Versionen variieren leicht pro Lauf und sind exakt in den redigierten Lauf-Manifesten dokumentiert (siehe Artefaktzugriff unten).
• LLM-Nachbearbeiter: deepseek-v4-flash über API, Temperatur 0.
• Messmodus: warm_then_scored — ein fester Aufwärmdurchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte im stationären Zustand liegen.
• Datensätze: SROIE 2019-Test — 361 englische Belege, flache Felder (Firma, Datum, Adresse, Gesamtsumme), CC-BY-4.0; CORD-v2-Test — 100 indonesische Belege, verschachtelte Felder (Menü, Zwischensumme, Gesamtsumme), CC-BY-4.0.
• Stichprobenanzahl: SROIE 361 / CORD 100, alle aus den festen Test-Splits (kein Trainingsdaten-Leak).

Der vorgelagerte OCR-Text, den beide Nachbearbeiter verarbeiten, stammt aus diesen Engine-Versionen:

Vollständige Reproduzierbarkeits-Fingerabdrücke pro Lauf finden Sie in den redigierten Lauf-Manifesten des Benchmarks unter results/manifests/ im öffentlichen Repository (ein manifest.json pro veröffentlichtem Lauf, insgesamt 16). Jedes offenbart: Lauf-ID, Modell + Version, Hash des Runner-Skripts (SHA-256), GPU-Modell/Treiber/VRAM, torch/CUDA/torchvision/torchaudio-Versionen, Python-Version, pip-freeze-Hash, Kostenmetadaten (GPU $/Stunde und Preiszeitstempel), Messmodus und Artefakt-Hashes (Stichprobenliste, Vorhersagen, Metriken, Leistung).

Metrikdefinitionen

• Feldwert-F1 (regex-Ansatz): harmonisches Mittel aus Präzision und Recall über extrahierte Feldwerte, mit regex-Nachbearbeitung — der traditionelle OCR- und regelbasierte KIE-Ansatz. Spalte: regex_field_value_f1.
• Feldwert-F1 (LLM-Ansatz): dieselbe Metrik, berechnet auf der Ausgabe des LLM-Nachbearbeiters — der OCR- und LLM-Nachbearbeitungsansatz. Spalte: llm_field_value_f1. Diese beiden Ansätze sind unterschiedliche Pipelines und werden niemals vermischt.
• Feldwert-Genauigkeit: Anteil der extrahierten Feldwerte, die exakt mit der Ground Truth übereinstimmen (regex_field_value_accuracy / llm_field_value_accuracy).
• Dokumentfelder-exakt: Anteil der Dokumente, bei denen jedes Zielfeld exakt übereinstimmte (regex_document_fields_exact / llm_document_fields_exact).
• CER/WER (nur Kontext): Zeichen-/Wortfehlerrate des rohen OCR-Texts, auf dieser Seite nur zur Erklärung der LLM-Obergrenze von Tesseract verwendet.

Zugriff auf Artefakte

1. field_method_comparison.csv (GitHub raw). 16 Zeilen = 8 Modelle × 2 Datensätze; Spalten: model, dataset, llm_model (= deepseek-v4-flash), regex/llm-Feld-F1 + Genauigkeit, Dokumentfelder-exakt, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens. Jede Feld-F1- und Genauigkeitszahl auf dieser Seite lässt sich auf eine Zeile hier zurückführen.
2. summary_metrics.csv (GitHub raw). CER/WER pro Modell × Datensatz, verwendet für die Tesseract-Obergrenzen-Erklärung (tesseract/cord_v2 cer 0.9523) und docTRs SROIE-CER 0.1971.
3. ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository mit den Ergebnis-CSVs, Laufmanifesten und Datensatz-Stichprobenlisten zur Reproduktion.
4. results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf (16 Läufe), mit dem Umgebungs-Fingerabdruck und den Artefakt-Hashes pro Lauf wie oben aufgeführt.
5. Huang et al., „ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). SROIE-Datensatzdefinition und Lizenz.
6. Park et al., „CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2019). CORD-v2-Datensatzdefinition und Lizenz.

Einschränkungen

• Dokumentumfang: Nur Belege (SROIE + CORD). Die Ergebnisse lassen sich ohne weitere Tests nicht auf Rechnungen, Formulare oder lange Dokumente verallgemeinern.
• Stichprobengröße: 361 englische + 100 indonesische Belege. Das Feld-F1 reagiert empfindlich auf die Korpuszusammensetzung; behandeln Sie Einzelpunktdifferenzen von einigen Hundertstel als Rauschen.
• Einzelnes LLM-Modell: Alle LLM-Zeilen verwenden deepseek-v4-flash. Ein anderes LLM (Größe, Prompting oder Anbieter) würde andere absolute Zahlen liefern; die Reihenfolge regex-vs-LLM kann sich an den Rändern verschieben.
• Hinweis zu CORD-Ground-Truth: CORD gt_text enthält Annotationsstruktur und VLM-Normalisierungsunterschiede, daher ist das rohe CER auf CORD für jede Engine systematisch erhöht (z. B. ist PaddleOCR-VL CER 1.08 ein Artefakt, keine echte Messung seiner Textqualität). Feldmetriken sind der faire Vergleich; CER wird hier nur für die Tesseract-Erklärung verwendet.
• Latenz ist keine Echtzeit-Extraktionslatenz: llm_median_latency_ms (1,8–2,4 s) umfasst den gesamten OCR-Text → LLM-Feldextraktionsaufruf, nicht die Suche pro Feld, und beinhaltet nicht die OCR-Zeit selbst.
• Regex-Abstimmung: Die Regex-Muster sind ein fester Satz, der einmal pro Datensatz (SROIE-flat-Schema) geschrieben wurde; eine stark abgestimmte Regex-Bibliothek pro Anbieter könnte bei eigenen Formaten höhere Werte erzielen — auf Kosten des Wartungsaufwands, den das LLM beseitigt.

Verwandte Referenzen: die Lücke zwischen Feld- und Zeichengenauigkeit · Beleg-OCR-Genauigkeit · Genauigkeits-Benchmarks nach Dokumenttyp

Weiterführende Lektüre: So lesen Sie OCR-Genauigkeitsangaben