Regex vs. LLM-Feldextraktion für Belege
Ersteigene Benchmark-Ergebnisse (2026)

SROIE-Ergebnisse: Englische Quittungen (361 Stichproben)

Bei englischen Quittungen schlägt das LLM Regex bei allen 8 Engines — der kleinste Anstieg beträgt 1,76× (PaddleOCR-VL 0,337 → 0,592), der größte 8,1×. Und das LLM löscht die Modelllücke fast aus: 6 der 7 Nicht-Tesseract-Engines liegen innerhalb eines 0,05-Punkt-Bands (0,569–0,617), während ihre Regex-Ergebnisse über 0,26 Punkte (0,077–0,338) verteilt waren.

SROIE (Scanned Receipt OCR and Information Extraction, ICDAR 2019) ist der Standard-Benchmark für englische Quittungen: 361 Testquittungen mit vier Zielfeldern — Unternehmen, Datum, Adresse und Gesamtbetrag (Huang et al., 2019). Jeder Engine erzeugte zunächst OCR-Text auf einer gemeinsamen RTX-4090-Konfiguration; dieser Text wurde dann zwei parallelen Nachbearbeitern zugeführt: einem festen Satz von Regex-Mustern (der traditionelle OCR + regelbasierte KIE-Ansatz) und dem LLM deepseek-v4-flash mit einem strukturierten Extraktionsprompt. Beide wurden gegen dieselben Ground-Truth-Felder bewertet. Das Diagramm zeigt das Regex-Feld-F1 (blau) gegenüber dem 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 (gespeichert als 0–1-Dezimalzahlen, angezeigt als %). LLM-Nachbearbeiter: deepseek-v4-flash (Spalte llm_model). 361 Stichproben pro Engine (Spalte 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-Dezimalzahlen angezeigt als %). docTR-F1 0,0766 → 0,6171; Surya2 0,3183 → 0,6139; PaddleOCR 0,3254 → 0,5810.

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

CORD vergrößert die Lücke, nicht weil das LLM besser wird — das tut es nicht —, sondern weil Regex zusammenbricht: sechs von acht Engines erzielen ein Regex-Feld-F1 von höchstens 10,8%, und zwei (docTR 0,0%, EasyOCR 0,7%) gewinnen fast nichts. Das LLM hebt jede Nicht-Tesseract-Engine dennoch auf 33,8% oder höher, was beweist, dass seine Extraktion über Sprachen und Layouts hinweg verallgemeinert, wo handgeschriebene Muster versagen.

CORD v2 ist ein indonesischsprachiges Quittungs-Dataset mit verschachtelten Feldern (menu, sub_total, total) (Park et al., 2019), das als sprachübergreifender Stresstest dient: Keine der 8 Engines wurde primär auf indonesischen Quittungen trainiert. Zwei Einschränkungen bei der Lektüre dieser Tabelle. Erstens: CORDs Ground-Truth-Text umfasst Annotationstruktur- und VLM-Ausgabenormalisierungsunterschiede, die den rohen CER für jede Engine systematisch aufblähen — daher sind die nachstehenden Feldmetriken, nicht CER, der faire Modellvergleich. Zweitens: Die Regex-Muster wurden für das flache englische SROIE-Schema geschrieben; CORDs verschachteltes Schema und indonesische Formatierung (Rp-Währung, Datumskonventionen) schlagen sie — was selbst die Erkenntnis ist: Auf einen Markt abgestimmte Regeln sind nicht übertragbar.

Quelle: field_method_comparison.csv — Zeilen für dataset=cord_v2, Spalten regex_field_value_f1 / llm_field_value_f1 (0–1 Dezimalzahlen 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 Dezimalzahlen 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 schmälert — und wo seine Grenze liegt

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

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

Bei Regex war die Wahl des Engines enorm wichtig: Der SROIE-Feld-F1-Score spannte von 0,077 (docTR) bis 0,338 (Unlimited-OCR) — eine Streuung von 0,26 Punkten. Unter dem LLM landen sechs der sieben Nicht-Tesseract-Engines zwischen 0,569 (Docling) und 0,617 (docTR) — ein Bereich von 0,05 Punkten (field_method_comparison.csv, sroie_2019-Zeilen, regex_field_value_f1 vs llm_field_value_f1). Das vorgelagerte OCR muss nur lesbaren Text erzeugen; das LLM extrahiert Felder daraus mit einer grob engine-unabhängigen Qualität. Zwei Engines bleiben hinter diesem Bereich zurück: EasyOCR mit 0,372 (der niedrigste LLM-F1 auf englischen Quittungen) und Tesseract mit 0,439. Auf CORD wird Tesseract zum klaren Schlusslicht — seine 0,163 sind das schlechteste LLM-Ergebnis in der gesamten Tabelle.

(b) Tesseras Decke wird durch sein OCR gesetzt, nicht durch seinen Nachbearbeiter

„Müll rein, Müll raus" gilt auch für die LLM-Nachbearbeitung. Tesseras roher OCR-Text auf indonesischen Quittungen 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 auf CORD beträgt daher 0,1627field_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 Decke jedes Nachbearbeiters wird durch die OCR-Grundqualität darunter gesetzt — eine Einschränkung, die kein Prompt-Engineering aufhebt.

(c) docTR ist der größte Nutznießter: Vom Regex-Boden zur LLM-Spitze

docTRs Geschichte ist der sauberste Beweis dafür, dass das Problem der Nachbearbeiter war, nicht das OCR. Sein Regex-Feld-F1 auf 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 zu den Regex-Mustern für Gesamtbeträge mit Tausendertrennzeichen oder mehrzeiligen Adressen. Unter dem LLM liefert derselbe Text das beste SROIE-Ergebnis des Benchmarks, 0,6171 — ein 8,1-facher Anstieg und der größte in der Tabelle (field_method_comparison.csv, doctr/sroie_2019, regex_field_value_f1 0,0766 → llm_field_value_f1 0,6171). Auf CORD wiederholt sich der Effekt: 0,0 unter Regex, 0,5500 unter dem LLM.

Wann Regex ausreicht und wann ein LLM eingesetzt werden sollte

Der ehrliche Trade-off 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). Dafür hat das LLM auf SROIE 1,76–8,1× mehr Felder wiederhergestellt – und auf CORD, wo Regex für die meisten Engines nahezu null erreichte, hat das LLM 33,8–55,3 % der Felder wiederhergestellt, die eine 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 – eine feste Rechnungsnummernvorlage, ein einziges Datumsformat, eine Währung –, ist Regex das richtige Tool: Es kostet nichts, läuft in Mikrosekunden und seine Fehler sind vorhersagbar. Die Benchmark-Bodenfälle zeigen dies: Engines mit auf Belege abgestimmtem Regex erreichten auf SROIE immer noch 0,34 Feld-F1 (Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368).

Wann ein LLM eingesetzt werden sollte: Sobald Formatvarianz eintritt – mehrere Währungen, regionale Datumsformate, mehrzeilige Adressen, Lieferantennamen in unterschiedlichen Stilen oder eine zweite Sprache. Jedes davon bricht ein Muster; das LLM absorbiert alles in einem Prompt. Die CORD-Ergebnisse der Benchmark quantifizieren, was „eine weitere Sprache" eine regelbasierte Pipeline kostet: Der Regex-Feld-F1 fiel von 0,08–0,34 (englisches SROIE) auf 0,00–0,34 (indonesisches 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 hybride: LLM-Extraktion für variable Felder, Regex- oder regelbasierte Validierung für Felder mit streng erwarteten Formaten, wobei die 1,8–2,4 s pro Dokument LLM-Kosten im asynchronen Batch-Processing amortisiert werden, nicht in synchronen Wartezeiten der Nutzer.

Häufig gestellte Fragen

Ist LLM-Feldextraktion genauer als Regex-Extraktion?

Ja, in diesem Benchmark schlug LLM-Nachbearbeitung (deepseek-v4-flash) in jeder Zeile die Regex-Nachbearbeitung für alle 8 OCR-Engines auf beiden Datensätzen (field_method_comparison.csv, alle 16 Zeilen). Bei SROIE-Englisch-Belegen lag der LLM-Feld-F1 bei 0,37–0,62 gegenüber Regex 0,08–0,34; bei CORD-Indonesisch-Belegen bei 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 landen 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, docTR folgt knapp mit 0,5500.

Warum hinkt Tesseract selbst mit einem LLM hinterher?

Weil sein OCR-Text zu stark beschädigt ist, als dass ein Nachbearbeiter Felder daraus extrahieren 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 viel verbessert ein LLM die Feldextraktion gegenüber Regex?

Zwischen 1,76× und 8,1× bei englischen Belegen je nach Engine, mit der größten Steigerung bei docTR (0,077 → 0,617 Feld-F1, field_method_comparison.csv sroie_2019-Zeilen). Bei indonesischen Belegen ist die Steigerung viel größer — 36× für PaddleOCR und praktisch unbegrenzt für docTR (0,0 → 0,55), da Regex fast nichts extrahieren konnte.

Korrigiert die LLM-Nachbearbeitung jedes Feld richtig?

Nein — und das sollte man auch nicht erwarten. Das beste LLM-Feld-F1 im Benchmark ist 0,617 (docTR, SROIE), was bedeutet, dass etwa 38% der Felder immer noch fehlten oder falsch waren, und die beste exakte Übereinstimmungsrate für ganze Dokumente beträgt 15,5% (Surya2, SROIE, llm_document_fields_exact) — d.h. höchstens ~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 Feld-level Vertrauensbewertung und menschliche Überprüfung bleiben für den Produktiveinsatz notwendig.

Wie langsam oder teuer ist die LLM-Nachbearbeitung?

In diesem Benchmark fügte der LLM-Aufruf eine mediane Latenz von 1,8–2,4 s pro Dokument hinzu (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-Token (Summe von llm_prompt_tokens / llm_completion_tokens). Dies ist keine Echtzeit-Latenz für die Feldextraktion — es eignet sich für asynchrone Stapelverarbeitung, nicht für interaktive Abfragen.

Funktioniert die LLM-Nachbearbeitung bei nicht-englischen Quittungen?

Besser als Regex, aber mit einer niedrigeren Obergrenze. Bei indonesischen CORD-Quittungen hielt das LLM das Feld-F1 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) liegt immer noch hinter dem besten englischen Ergebnis (0,6171), was sowohl die schwierigere Schrift als auch die verschlechterte OCR-Grundlage widerspiegelt. Für englische Quittungen geschriebene Regeln funktionierten im Wesentlichen nicht mehr; das LLM verschlechterte sich stattdessen graduell.

Methodik & Quellen

Protokoll

Diese Seite berichtet den Vergleich der Feldextraktion des ImageToTable.ai Open-Source-OCR-Benchmarks — ein unabhängiger, reproduzierbarer experimenteller Durchlauf (offizielle Stufe), keine Umfrage von Drittanbieter-Aussagen. 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 Spalte llm_model in der Vergleichs-CSV), ausgeführt bei Temperatur 0 für deterministische Ausgaben. 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-gespeisten Engines (Surya2, Unlimited-OCR, PaddleOCR-VL) liefen auf einem vLLM-Pod. Treiber- und Python-Versionen variieren leicht je nach Durchlauf und sind exakt in den geschwärzten Lauf-Manifesten dokumentiert (siehe unten Zugang zu Artefakten).
• LLM-Nachbearbeiter: deepseek-v4-flash via API, Temperatur 0.
• Messmodus: warm_then_scored — ein fester Aufwärm-Durchlauf geht dem bewerteten Durchlauf voraus, sodass die Latenzwerte im稳态 sind.
• Datensätze: SROIE 2019 test — 361 englische Belege, flache Felder (Firma, Datum, Adresse, Gesamt), CC-BY-4.0; CORD v2 test — 100 indonesische Belege, verschachtelte Felder (Menü, Zwischensumme, Gesamt), CC-BY-4.0.
• Stichprobenzahlen: SROIE 361 / CORD 100, alle aus den festen Test-Splits (kein Leakage von Trainingsdaten).

Der von beiden Nachbearbeitern verbrauchte OCR-Text der Vorstufe stammte von diesen Engine-Versionen:

Vollständige, pro Durchlauf reproduzierbare Fingerabdrücke befinden sich in den geschwärzten Lauf-Manifesten des Benchmarks unter results/manifests/ im öffentlichen Repository (ein manifest.json pro veröffentlichtem Durchlauf, insgesamt 16). Jedes enthält: Lauf-ID, Modell + Version, Hash des Laufskripts (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 von Precision und Recall über extrahierte Feldwerte, mit Regex-Nachbearbeitung — der traditionelle OCR + regelbasierte KIE-Ansatz. Spalte: regex_field_value_f1.
• Feldwert-F1 (LLM-Ansatz): dieselbe Metrik, berechnet auf der Ausgabe des LLM-Nachbearbeiters — der OCR + LLM-Nachbearbeitungs-Ansatz. Spalte: llm_field_value_f1. Diese beiden Ansätze sind verschiedene Pipelines und werden nie kombiniert.
• Feldwertgenauigkeit: Anteil der extrahierten Feldwerte, die exakt mit dem 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 Roh-OCR-Texts, hier nur verwendet, um Tesseras LLM-Obergrenze zu erklären.

Artefaktzugriff

1. field_method_comparison.csv (GitHub raw). 16 Zeilen = 8 Modelle × 2 Datensätze; Spalten model, dataset, llm_model (= deepseek-v4-flash), regex/llm field F1 + accuracy, document-fields-exact, 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 Repo mit den Ergebnis-CSVs, Ausführungsmanifesten und Datensatz-Beispiellisten zur Reproduktion.
4. results/manifests/ (GitHub). Ein geschwärztes manifest.json pro veröffentlichter Ausführung (16 Ausführungen), mit dem Umgebungs-Fingerabdruck und den Artefakt-Hashs pro Ausführung, die oben aufgeführt sind.
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 Quittungen (SROIE + CORD). Die Ergebnisse verallgemeinern sich nicht auf Rechnungen, Formulare oder lange Dokumente ohne weitere Tests.
• Stichprobengröße: 361 englische + 100 indonesische Quittungen. Der Feld-F1-Wert ist empfindlich gegenüber der Korpuszusammensetzung; behandeln Sie einzelne Unterschiede von wenigen Hundertstelsen als Rauschen.
• Einzelnes LLM-Modell: Alle LLM-Zeilen verwenden deepseek-v4-flash. Ein anderes LLM (Größe, Aufforderung oder Anbieter) würde andere absolute Zahlen erzeugen; die Reihenfolge Regex-vs-LLM könnte an den Rändern variieren.
• CORD-Ground-Truth-Hinweis: CORD gt_text enthält Annotationstruktur und VLM-Normalisierungsunterschiede, daher ist der rohe CER auf CORD systematisch für jede Engine erhöht (z.B. PaddleOCR-VL CER 1.08 ist ein Artefakt, keine echte Bewertung 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 Einzelfeldsuche, 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 auf eigenen Formaten höher punkten — auf Kosten der Wartungslast, die das LLM eliminiert.

Verwandte Referenzen: Feld- vs. Zeichenebene-Genauigkeit · Quittungs-OCR-Genauigkeit · OCR-Genauigkeit nach Dokumenttyp

Verwandte Lektüre: So lesen Sie OCR-Genauigkeitsangaben