Warum CER bei dokumentverarbeitenden VLMs in die Irre führt
Quantifiziert mit First-Party-Benchmark-Daten (2026)

CER ist ein Exact-Match-Bewertungsalgorithmus, kein Qualitätsmaß

CER ist die Levenshtein-Bearbeitungsdistanz zwischen erkanntem und Referenztext — die minimale Anzahl an Zeicheneinfügungen, -löschungen und -ersetzungen, die nötig sind, um den einen in den anderen zu verwandeln, geteilt durch die Länge des Referenztextes (die formale Definition wird in der OCR-D-Evaluierungsspezifikation veröffentlicht). Er zählt Unterschiede und kann eine Fehllesung nicht von einer legitimen Neugestaltung unterscheiden. Wenn die Ausgabekonvention einer Engine vom Referenztext abweicht — Groß-/Kleinschreibung, Trennzeichen, Zeilenreihenfolge — berechnet CER Fehler für Verhalten, das überhaupt keine Fehllesung ist.

Traditionelle OCR-Engines (Tesseract, PaddleOCR, EasyOCR, docTR) geben rohe Zeichenströme aus, die die ursprüngliche Groß-/Kleinschreibung und Zeilenanordnung beibehalten, sodass ihre Ausgabekonvention nahe am Referenztext liegt und CER etwas misst, das einem echten Lesefehler nahekommt. Dokument-parsende VLMs (Surya2, Unlimited-OCR, PaddleOCR-VL) geben verstandenen Text aus: Sie wenden Fallnormalisierung an (TAN CHAY YEE wird zu tan chay yee), Label/Wert-Verschmelzung (INVOICE NO\n: PEGIV wird zu Invoice No : PEGIV) und Zeilenumordnung — die Ausgabekonventionen eines Lesers, nicht eines Scanners. Jede normalisierte Groß-/Kleinschreibung und verschmolzene Zeile ist ein Bearbeitungsstrafpunkt, selbst wenn der zugrunde liegende Feldwert korrekt ist.

Die Protokollanalyse des Benchmarks zu den veröffentlichten SROIE-Vorhersagen zerlegt das rohe CER-Budget eines VLMs grob in ~76% Zeichen identisch mit Referenztext, ~18% Groß-/Kleinschreibungs-Ersetzungen und ~10% Zeilenverschmelzungen / weggelassene Trennzeichen — wobei die tatsächlichen Feldwerte (Firma, Gesamtbetrag, Datum, Adresse) korrekt sind. Diese Aufschlüsselung ist eine aus dem Protokoll abgeleitete Schätzung aus den Analyseanmerkungen des Benchmarks, keine CSV-Spalte; betrachten Sie die Aufteilung als Richtungswert, nicht als präzise Angabe. Die Richtung ist entscheidend: Fallnormalisierung allein kann einen großen Teil des “schlechten” CER eines VLMs bei sauberen englischen Quittungen erklären.

Zwei CSV-Zeilen machen den Mechanismus ohne jede Zerlegung sichtbar. Unlimited-OCR erreicht CER 0,6552, aber WER 0,4779 bei SROIE — seine Zeichen wirken verbogen, während seine Wörter überleben, weil Fallnormalisierung Zeichen ersetzt, ohne Wörter zu zerbrechen (summary_metrics.csv, cer / wer, unlimited_ocr/sroie_2019 Zeile). Und das VLM, das am wenigsten normalisiert, Surya2, erreicht CER 0,1915 — den besten rohen CER im gesamten 8-Engine-Lauf, nicht zu unterscheiden von einer starken traditionellen Engine (summary_metrics.csv, cer, surya2/sroie_2019 Zeile). Die Ausgabekonvention des VLMs, nicht seine Lesefähigkeit, ist es, was die CER-Spalte hauptsächlich misst.

Der Beweis liegt in den Umkehrungen: CER und Feld-F1 widersprechen sich

Das CER-Ranking des Benchmarks und sein Ranking der Feldextraktion widersprechen sich wesentlich. Rangordnen Sie die acht Engines nach SROIE-CER, ist Surya2 der Gewinner (0,1915); rangordnen Sie sie nach Regex-Feld-F1 — der Metrik, die am ehesten dem entspricht, was eine Produktionspipeline verarbeitet — ist Unlimited-OCR der Gewinner (0,3376), die Engine, die im CER-Ranking ganz unten steht. Eine der beiden Spalten misst nicht das, was nachgelagerte Systeme tatsächlich verarbeiten.

Feld-F1 ist der harmonische Mittelwert von Präzision und Recall über die extrahierten Feldwerte (Firma, Datum, Adresse, Gesamtbetrag bei SROIE): Ein Feld ist eine binäre Einheit — es stimmt überein oder es scheitert. Die Regex-Spaltewendet dasselbe feste Mustermuster auf den Text jeder Engine an, sodass die einzige Variable die Ausgabe der Engine ist. Die folgende Tabelle ordnet jedem Engine sein CER und sein Regex-Feld-F1 auf denselben 361 Quittungen zu, mit dem Rang jedes Engines unter beiden Metriken.

Quelle: summary_metrics.csv — Spalten cer und field_f1_regex, Zeilen sroie_2019 (361 Stichproben pro Engine, error_rate 0,0 für alle 8). Die beiden Reihen sind als Größen nicht miteinander vergleichbar (unterschiedliche Einheiten), aber ihre Rankings widersprechen sich, und genau das ist der Punkt.

Tabelle: summary_metrics.csv — cer / wer / field_f1_regex-Spalten, sroie_2019-Zeilen. Ränge wurden innerhalb der 8 Zeilen dieser Tabelle berechnet (1 = bestes Ergebnis für diese Metrik: niedrigstes CER, höchstes Feld-F1). Dies sind postprocessed_sroie_receipt_regex_*-Metriken: feste Muster, die auf den OCR-Text jeder Engine angewendet wurden, keine native strukturierte Ausgabe. Tesseract lief im reinen CPU-Modus (compute_type=cpu).

Lesen Sie die beiden Umkehrpaare explizit. Unlimited-OCR: schlechtester CER (0,6552), bestes Feld-F1 (0,3376) — die Engine, die das Roh-OCR-Metrik auf den letzten Platz setzt, wird durch die Feld-Perspektive auf den ersten Platz gehoben. docTR: zweitbester CER (0,1971), schlechtestes Feld-F1 (0,0766) — textperfekt, feldmäßig gescheitert. PaddleOCR-VL kehrt ebenfalls am Rand um (CER-Rang 6, Feld-Rang 2), während die beiden übereinstimmenden Zeilen (PaddleOCR 3./3., Tesseract 5./5.) beide traditionelle Engines sind, deren Roh-Text-Ausgabekonvention genau das ist, was CER bewerten soll. Rangfolgen Sie Engines nur nach CER, erhalten Sie einen anderen Gewinner als bei einer Rangfolge nach dem, was die Produktion tatsächlich verbraucht — die Umkehrung ist der Beweis, keine Anomalie.

Das Feld-Metrik ist die zuverlässige übergreifende Perspektive

Führen Sie den Roh-Text jeder Engine durch denselben LLM-Feld-Extraktions-Nachbearbeiter (deepseek-v4-flash, Temperatur 0), und die sechs Engines mit verwendbarem OCR-Text konvergieren bei 0,57–0,62 Feld-F1 — die VLM-gegenüber-traditionelle Familien-Grenze, die die CER-Rangfolge riesig erscheinen lässt (0,19 bis 0,66), verschwindet beinahe. Zwei Engines fallen unter die Bandbreite: EasyOCR mit 0,3717 und Tesseract mit 0,4389. Das Feld-Metrik trennt Engines nach dem, was tatsächlich zählt — der nachgelagerten Feld-Wiederherstellung — und tut dies konsistent über die Familien-Grenze hinweg.

Dies ist dieselbe Engine-Auswahl wie in der CER-Tabelle oben, neu bewertet nur in der Felddimension: Die CER-Umkehrung zwischen Unlimited-OCR und docTR ist verschwunden, weil die Feld-Wert-Wiederherstellung das ist, was die Pipeline verbraucht. Der Mechanismus ist, dass der Nachbearbeiter die Ausgabekonvention-Unterschiede absorbiert, die CER bestraft hat — er liest den fallnormalisierten, label-verschmolzenen Text und extrahiert die Werte. Das LLM-Feld-F1 hier ist die Spalte llm_field_value_f1 im Methodenvergleich des Benchmarks, mit dem LLM-Modell pro Zeile vermerkt.

Tabelle: field_method_comparison.csv — llm_field_value_f1 Spalte, sroie_2019 Zeilen, llm_model=deepseek-v4-flash. CER-Spalte aus summary_metrics.csv nur zur Referenz wiederholt. Das „Konvergenzband" ist der beobachtete Bereich von 0,5685–0,6171 der sechs Engines mit verwendbarem Text; die beiden unterhalb des Bands liegenden Zeilen sind Beobachtungen, keine Klassifizierung der Engines.

CORD fügt eine zweite Inflationsschicht hinzu: Referenztext-Struktur

CORDs veröffentlichter Referenztext (gt_text) enthält Annotationsstruktur — Feldbezeichnungen, Menüeinträge und Koordinaten — anstelle von reinem sichtbarem Text. CER berechnet die Editierdistanz zu dieser strukturell erweiterten Zeichenkette, sodass der CORD CER jedes Engines systematisch aufgebläht wird, bevor überhaupt ein Lesefehler berücksichtigt wird. Das Ergebnis: Alle acht Engines gruppieren sich bei CORD CER 0,90–1,08 — ein nutzlos komprimierter Bereich, der so gut wie nichts über die Textqualität aussagt.

Das extreme Artefakt ist PaddleOCR-VLs CORD CER von 1,0805, der schlechteste aller 8 Engines — keine Messung seiner Textqualität, sondern die strukturelle Aufblähung, die am stärksten gegen die sauberste, kürzeste Ausgabe arbeitet, die die größte relative Editierdistanz zu CORDs strukturlastigem Referenztext hat. Im Feld-Lens erzielt derselbe Engine den besten CORD Regex-Feld-F1 (0,3412) des Benchmarks. CORD CER ist strukturell unbrauchbar; Feldmetriken sind die einzige faire CORD-Perspektive und werden in diesem Benchmark streng von jeder SROIE-Rangliste getrennt (andere Sprache — Indonesisch — und andere Referenztext-Struktur).

Quelle: summary_metrics.csv — Spalten cer und field_f1_regex, cord_v2-Zeilen (100 Stichproben pro Engine). CORD CER ist nicht über Engine-Familien oder sogar zwischen Engines vergleichbar — der Referenztext enthält Annotationsstruktur, sodass CER die Distanz zu einer strukturell erweiterten Zeichenkette misst, nicht zu sichtbarem Text.

Tabelle: summary_metrics.csv — cer / field_f1_regex Spalten, cord_v2 Zeilen. CORD wird in keinem SROIE-Ranking zusammengeführt (Protokollregel): Die Referenztextstruktur erhöht den CER für jede Engine, und die Regex-Muster wurden für englische Formate geschrieben. Feldmetriken sind die einzige faire CORD-Betrachtung. Sortiert nach Feld-F1, nicht CER — denn die CER-Spalte enthält kein Sortiersignal.

Die Feldbetrachtung dreht die CORD-Tabelle komplett um. Die Engine mit dem schlechtesten CORD CER im Benchmark (PaddleOCR-VL, 1.0805) hat das beste CORD-Feld-F1 (0.3412); docTRs CORD-Feld-F1 ist buchstäblich 0.0000 — nichts extrahiert — während sein CORD CER (0.9101) mittig im Cluster liegt und nichts darüber aussagt. Bei CORD ist die Veröffentlichung von CER ohne die Feldzahlen nicht nur informativ, sondern ordnet die Engines aktiv in die falsche Reihenfolge.

Wann CER tatsächlich die richtige Metrik ist

CER misst immer noch etwas Reales — die exakte Zeichenwiedergabe — und ist die richtige Metrik, wenn der nachgelagerte Verbraucher wörtlichen Text benötigt, keine Felder. Die Schlussfolgerung dieser Seite lautet “CER ist für den Vergleich von VLM-Ausgaben über Familien hinweg irreführend,” nicht “CER ist immer falsch.”

• Innerhalb der Raw-OCR-Familie behält CER seinen Wert. Traditionelle Engines geben rohen Text mit erhaltener Groß-/Kleinschreibung und Layout aus, sodass CER die tatsächliche Lesbarkeit misst: Die CER-Spalte der traditionellen Engine in diesem Benchmark (0,1971–0,3347 auf SROIE) verfolgt ihre Feldleistung viel genauer als die der VLMs (Rangkorrelation mit Regex-Feld-F1: PaddleOCR und Tesseract sind genau auf Platz 3/3 bzw. 5/5 abgestimmt).
• Anwendungsfälle für wörtlichen Text. Exakt-Übereinstimmende nachgelagerte Verbraucher — Volltextsuche, die einen wörtlichen String finden muss, Prüfpfade, die die Zeichen eines Dokuments wiedergeben, oder Bestätigungsprüfungen gegen eine vorgegebene Zeichenfolge — verarbeiten Zeichen, nicht Felder. Für diese ist die exakte Zeichenwiedergabe (CER) die zutreffende Metrik und Feld-F1 der falsche Maßstab.
• Publikations-Regel. Wenn Sie eine CER-Zahl veröffentlichen, geben Sie sowohl die Ausgabekonvention der Engine an (wird Fallnormalisierung durchgeführt? Werden Labels verschmolzen? Werden Zeilen umsortiert?) als auch die Referenztext-Erstellung (reiner sichtbarer Text oder annotierungsverstärkt wie CORDs gt_text). Wenn eines davon unbekannt ist, ist die Zahl nicht über Engines oder Datensätze hinweg übertragbar.
• Die Grenzregel dieses Benchmarks. CER ist fair innerhalb der Raw-OCR-Familie und unfair über die Grenze zwischen traditioneller OCR und dokumentparsenden VLMs hinweg; Feld-F1 (Regex- oder LLM-nachbearbeitet) ist fair über beides hinweg. Verwenden Sie CER für die Textqualität innerhalb derselben Familie, Feld-F1 für den Vergleich über Familien hinweg — und geben Sie immer den Hinweis zur Dekomposition für VLM-Zeilen an.

Häufig gestellte Fragen

Warum ist CER bei der Vergleich von OCR-Engines und VLMs irreführend?

Weil CER ein exakter Zeichen-Edit-Distanz-Score ist, und dokumentenparsende VLMs Zeichen absichtlich nicht exakt reproduzieren — sie normalisieren die Groß-/Kleinschreibung, verschmelzen Label/Wert-Zeilen und ordnen Text neu an. Jede dieser Normalisierungen wird als Fehler gewertet, selbst wenn der Feldwert korrekt ist. In diesem Benchmark erzielt Unlimited-OCR den schlechtesten SROIE CER (0.6552), während es gleichzeitig das beste Regex-Feld-F1 (0.3376) auf denselben 361 Quittungen erzielt (summary_metrics.csv, cer / field_f1_regex, unlimited_ocr/sroie_2019 Zeile) — die CER-Rangfolge und die Feldrangfolge wählen unterschiedliche Gewinner.

Ist CER überhaupt noch eine nützliche OCR-Metrik?

Ja — innerhalb der Raw-OCR-Familie und für Verbatim-Text-Verbraucher. Traditionelle Engines (Tesseract, PaddleOCR, EasyOCR, docTR) geben rohe Zeichenströme aus, die CER fair misst: In diesem Benchmark reicht ihr SROIE CER von 0.1971–0.3347 und korreliert mit der Feldleistung (PaddleOCR 3./3., Tesseract 5./5. bei CER und Feld-F1). CER ist die falsche Metrik, wenn die Engine ihre Ausgabe normalisiert (VLM-Stil) oder wenn der Referenztext Struktur statt sichtbarem Text enthält (CORD).

Warum haben VLM-OCR-Modelle hohe Zeichenfehlerraten?

Hauptsächlich wegen der Ausgabekonvention, nicht wegen der Lesefähigkeit. Die Protokollanalyse des Benchmarks schreibt etwa ~18% des SROIE-CER-Budgets eines VLMs Groß-/Kleinschreibungs-Substitutionen und ~10% Zeilenverschmelzungen/ausgelassene Trennzeichen zu (aus der Benchmark-Analyse abgeleitete Schätzung, nicht eine CSV-Spalte) — während die Feldwerte selbst korrekt sind. Unlimited-OCRs CER 0.6552 im Vergleich zu WER 0.4779 zeigt die Signatur: Zeichen werden normalisiert, Wörter überleben (summary_metrics.csv, cer / wer, unlimited_ocr/sroie_2019 Zeile).

Was ist die beste Metrik zum Vergleich von OCR-Engines und dokumentenverarbeitenden VLMs?

Feld-F1 — mit Regex-Nachbearbeitung für eine reine OCR-Pipeline, mit LLM-Nachbearbeitung für beide Familien. Bei SROIE konvergiert das LLM-Feld-F1 von sechs Engines auf 0,57–0,62 unabhängig von der Familie (field_method_comparison.csv, llm_field_value_f1, sroie_2019-Zeilen), und das Regex-Feld-F1 ist die einzige Metrik, die die CORD-Tabelle sinnvoll rankt, wobei PaddleOCR-VL’s 0,3412 der Benchmark-Beste ist (summary_metrics.csv, field_f1_regex, cord_v2-Zeilen). Nennen Sie immer den Nachbearbeiter und die Ausgabekonvention zusammen mit der Zahl.

Warum ist PaddleOCR-VL’s CER bei CORD so hoch, aber sein Feld-F1 das Beste?

Weil CORD’s Referenztext Annotationsstruktur einbettet (Feldbeschriftungen, Koordinaten, Menüeinträge) und nicht reinen sichtbaren Text, und PaddleOCR-VL’s Ausgabe ist die sauberste — kürzeste, am stärksten normalisierte — weshalb seine Editierdistanz zu diesem strukturell erweiterten String am größten ist (CER 1,0805, schlechtester von 8). Bei der Feld-Metrik extrahiert derselbe Text indonesische Quittungsfelder mit 0,3412 Feld-F1, dem Benchmark-Besten (summary_metrics.csv, cer / field_f1_regex, paddleocr_vl_vllm/cord_v2-Zeile). CORD-CER ist strukturell für jede Engine unbrauchbar; Feldmetriken sind der einzige faire CORD-Vergleich.

Was ist Fallnormalisierung und warum erhöht sie den CER?

Fallnormalisierung bedeutet, den gesamten Text in eine einzige Groß-/Kleinschreibung zu bringen — TAN CHAY YEE wird zu tan chay yee. CER vergleicht Zeichen exakt, daher ist jeder normalisierte Buchstabe eine Substitution gegenüber dem Referenztext in Großbuchstaben, obwohl der Wert identisch ist. In der Protokollanalyse dieses Benchmarks machen Fallsubstitutionen etwa ~18% des SROIE-CER-Budgets eines VLM aus (aus dem Protokoll abgeleitete Schätzung) — weshalb ein VLM eine Quittung perfekt lesen und trotzdem einen CER berichten kann, der wie ein scheiterndes Modell aussieht.

Sollte ich OCR-Engines anhand von CER oder anhand von Feld-F1 vergleichen?

Anhand von Feld-F1 für jeden Vergleich, der sowohl traditionelle OCR- als auch VLM-Engines betrifft — denn Ihre Pipeline verarbeitet Felder, nicht Zeichenströme, und CER wird für normalisierte VLM-Ausgaben und strukturierte Referenztexte systematisch aufgebläht. Verwenden Sie CER nur innerhalb der Raw-OCR-Familie oder wenn der nachgelagerte Verbraucher wörtlichen Text benötigt (Suche, Prüfung, exakter Abgleich). Die beiden Metriken weichen in diesem Benchmark stark voneinander ab: CER ordnet docTR als 2. und Unlimited-OCR als 8. ein; Regex-Feld-F1 ordnet docTR als 8. und Unlimited-OCR als 1. ein (summary_metrics.csv, sroie_2019-Zeilen).

Woher stammen diese CER- und Feld-F1-Zahlen?

Jede Tabellenzahl ist eine Zeile der veröffentlichten results/summary_metrics.csv oder results/field_method_comparison.csv des internen Benchmarks, gehostet unter ImageToTableai/benchmark-ocr, mit einer geschwärzten manifest.json pro Durchlauf, die Modellversionen und Umgebungsfingerabdrücke aufzeichnet. Die ~76%/~18%/~10% CER-Zerlegung ist eine aus dem Protokolldokument abgeleitete Schätzung aus den Analyseanmerkungen des Benchmarks und explizit keine CSV-Spalte. Datensatzdefinitionen stammen aus den unten zitierten SROIE- und CORD-Publikationen.

Methodik & Quellen

Protokoll

Diese Seite berichtet über die Metrik-Fairness-Dimension eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — nicht über eine Umfrage von Drittanbieter-Aussagen. Nur feste Testsplits: SROIE 2019 test (361 englische Quittungen, flache Felder Firma/Datum/Adresse/Gesamt, CC-BY-4.0) und CORD v2 test (100 indonesische Quittungen, verschachtelte Felder Menü/Teilsumme/Gesamt, CC-BY-4.0); Trainingssplits wurden nie ausgewertet. Acht Engines liefen out-of-the-box, ohne Feinabstimmung, unter dem eingefrorenen Protokoll reports/receipt_v1_official_protocol.md (warm-then-scored, nur offizielle Stufe). Alle 16 bewerteten Läufe schlossen mit error_rate 0.0 ab (summary_metrics.csv error_rate-Spalte). Die Daten wurden im August 2026 erhoben.

Laufzeitumgebung

• Hardware: Alle GPU-Läufe auf einer einzigen NVIDIA RTX 4090 (24 GB); Tesseract lief nur auf CPU (compute_type=cpu) und ist in jeder Tabelle als solcher gekennzeichnet.
• Engines und Versionen (aus den Lauf-Manifesten): Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR vLLM-served, PaddleOCR-VL 1.6.
• Feld-Nachbearbeitung: Regex Feld-F1 = feste sroie_receipt_regex/cord_receipt_regex-Muster, die auf den OCR-Text jeder Engine angewendet wurden (nachbearbeitet, nicht native Extraktion); LLM Feld-F1 = deepseek-v4-flash (Temperatur 0), der denselben Text liest (Spalte llm_model in field_method_comparison.csv).

Metrikdefinitionen

• Character Error Rate (CER): Levenshtein-Bearbeitungsdistanz zwischen erkanntem und Referenztext — minimale Einfügungen/Löschungen/Ersetzungen geteilt durch die Länge des Referenztextes (OCR-D-Evaluierungsspezifikation). Niedriger ist besser. Misst nur die exakte Zeichenwiedergabe.
• Word Error Rate (WER): dieselbe Edit-Distanz-Logik auf Wortebene — ein Wort überlebt eine einzelne Fallnormalisierung, daher zeigt eine Divergenz von CER/WER Normalisierungen auf, die Zeichen ändern, ohne Wörter zu verändern.
• Feld-Wert-F1: harmonisches Mittel von Präzision und Recall über die extrahierten Feld-Werte; ein Feld stimmt nur überein, wenn es exakt dem Referenztext entspricht. Die Regex- und LLM-Spalten sind zwei Nachbearbeitungsstufen über denselben OCR-Text, niemals gemischt.
• Ausgabekonvention: wie eine Engine ihren Text formatiert (Groß-/Kleinschreibung, Trennzeichen, Zeilenreihenfolge). Traditionelle Engines bewahren sie; dokumentenparsende VLMs normalisieren sie — die Achse, die diese Seite misst.
• Referenztext-Struktur: ob der Referenztext reiner sichtbarer Text (SROIE) oder mit Annotationstruktur angereichert ist (CORD gt_text), was den CER für jede Engine erhöht.

Quellenverzeichnis

1. summary_metrics.csv (GitHub raw). 16 Zeilen = 8 Engines × 2 Beleg-Datensätze. Spalten umfassen cer, wer, field_f1_regex, field_acc_regex, compute_type, error_rate. Jede CER/WER- und Regex-Feld-F1-Zahl auf dieser Seite lässt sich auf eine Zeile hier zurückführen, zitiert auf Datei-/Modell-/Datensatz-/Metrik-Ebene.
2. field_method_comparison.csv (GitHub raw). Regex vs. LLM-Feldextraktion im Vergleich (llm_field_value_f1, llm_model=deepseek-v4-flash). Quelle für die LLM-Feld-F1-Tabelle.
3. ImageToTableai/benchmark-ocr Repository. Öffentliches Repository mit den Ergebnis-CSVs, geschwärzten Ausführungs-Manifesten, dem eingefrorenen Protokoll (reports/receipt_v1_official_protocol.md) und festen Stichprobenlisten zur Reproduktion.
4. results/manifests/ (GitHub). Ein geschwärztes manifest.json pro veröffentlichtem Durchlauf mit Modellversionen, Umgebungsfingerabdrücken und Artefakt-Hashes.
5. receipt_v1_official_protocol.md. Der eingefrorene Ausführungsvertrag: feste Test-Splits, offizielle Stufe, Warm-up-then-Scored-Messung, CORD-vs-SROIE-Trennungsregeln. Quelle für die auf protokollebene zitierten Regeln auf dieser Seite.
6. Benchmark-Protokoll-Analyse-Notizen (interne Ausführungsdokumentation, WRITING_BRIEF §8.2/§8.3). Der VLM-Normalisierungsmechanismus (Fallnormalisierung, Label/Wert-Verschmelzung, Zeilenumordnung), der CORD-Referenztext-Strukturmechanismus und die SROIE-CER-Zerlegung (~76% identisch / ~18% Fall / ~10% Zeilenverschmelzung). Hier zitiert mit dem expliziten Label “protokollbasierte Schätzung — keine CSV-Spalte”; die Aufteilung ist richtungsweisend, nicht präzise.
7. OCR-D-Projekt — Spezifikation zur Qualitätssicherung. Formale CER-Definition (Einfügungen + Löschungen + Substitutionen) / Gesamtzeichen und das WER-Analogon. Formaler definitorischer Anker.
8. Huang et al., “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction” (2019). SROIE-2019-Datensatzdefinition, Aufgabenstruktur, Lizenz (CC-BY-4.0).
9. Park et al., “CORD: A Consolidated Receipt Dataset for Post-OCR Parsing” (2020). CORD-Datensatzdefinition, verschachteltes Feldschema, Lizenz (CC-BY-4.0).

Einschränkungen

• Zerlegungszahlen sind protokollbasierte Schätzungen, keine Messungen: Die ~76%/~18%/~10% SROIE-CER-Zerlegung stammt aus den Protokollanalyse-Notizen des Benchmarks (WRITING_BRIEF §8.2), nicht aus einer CSV-Spalte. Die Richtung (Normalisierung, nicht Fehllesung, dominiert den VLM-CER) ist robust; die genauen Prozentsätze sollten als Richtungsschätzungen und nicht als Punktmessungen behandelt werden.
• Nur Quittungen: SROIE (Englisch) und CORD (Indonesisch) Quittungen. Das Verhalten bei Rechnungen, Formularen, Tabellen oder langen Dokumenten ist ungemessen; der Mechanismus verallgemeinert sich, die Zahlen nicht.
• Einzelner LLM-Nachbearbeiter: Alle LLM-Feld-F1-Werte verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt die absoluten F1-Werte und möglicherweise den Konvergenzbereich; die reihenfolgebasierte Rangfolge innerhalb des Bereichs ist das stabile Signal.
• CER gilt weiterhin für wörtliche Textfälle: Die Schlussfolgerung ist auf den vergleichenden Vergleich von VLM-Stil-Ausgaben beschränkt. Für den direkten Vergleich innerhalb derselben OCR-Familie und für nachgelagerte Anwendungen, die exakte Zeichen benötigen (Suche, Prüfung), bleibt CER eine legitimes Maß — diese Seite ist kein Argument gegen CER in diesen Kontexten.
• CORD nicht in SROIE-Rankings eingeflossen: Andere Sprache, andere Referenztextstruktur. CORD wird nur anhand von Feldmetriken verglichen, gemäß dem Benchmark-Protokoll.
• Versionen und Hardware-Fixierung: Die Zahlen gelten für die im August 2026 aufgeführten Modellversionen und eine GPU-Klasse (RTX 4090). Neuere Versionen verschieben CER und Feld-F1; Unterschiede im einstelligen Prozentbereich sollten als Rauschen behandelt werden.
• Stichprobengröße: 361 + 100 Stichproben; Bootstrap-Konfidenzintervalle werden in der Auswertung des Benchmarks berichtet, aber nicht zeilenweise auf dieser Seite wiedergegeben.

Verwandte Referenzen: Feld- vs. Zeichenebene-Genauigkeit (Definition) · Traditionelles OCR vs. Dokument-Parsing-VLMs · Regex vs. LLM-Feldextraktion · PaddleOCR vs. EasyOCR bei Quittungen · Surya2 vs. Unlimited-OCR vs. PaddleOCR-VL · OCR-Latenz-Benchmark · OCR-Kosten pro 1.000 Seiten

Verwandte Lektüre: KI-OCR vs. Traditionelles OCR: Genauigkeit · KI-Bildextraktion vs. Traditionelles OCR