Warum CER für Dokument-Parsing-VLMs irreführend ist: quantifiziert (2026)

Zuletzt geprüft: 2026-08-18 · Ausführungsstufe: offiziell · First-Party-Benchmark · 8 Engines × 2 Belegdatensätze

Geltungsbereich: Mechanismus veranschaulicht an Belegen (SROIE 2019 Englisch, 361 Testproben; CORD v2 Indonesisch, 100 Testproben) unter Verwendung der First-Party-Benchmark-Daten. Die ~76 %/~18 %/~10 %-CER-Zerlegung ist eine aus Protokollnotizen abgeleitete Schätzung, keine CSV-Spalte. CORD wird niemals in das SROIE-Ranking gemischt — andere Sprache, andere Ground-Truth-Struktur.

Die Character Error Rate (CER) ist ein Exakt-Zeichen-Abgleichsalgorithmus, kein Qualitätsmesser: Sie berechnet einen Fehler für jedes Zeichen, das vom Referenztext abweicht. In diesem Benchmark verschiebt allein diese Bewertungskonvention — noch vor jedem echten Verlesen — Engines zwischen dem oberen und unteren Ende des Rankings: Unlimited-OCR erzielt die schlechteste CER (0,6552) und das beste Regex-Feld-F1 (0,3376) auf denselben 361 SROIE-Belegen, während docTR die zweitbeste CER (0,1971) und das schlechteste Feld-F1 (0,0766) erzielt.

Die drei Zahlen, die Autoren am häufigsten benötigen: ~18 % des SROIE-CER-Budgets eines VLM entfallen allein auf Fallsubstitutionen (protokollabgeleitete Schätzung) — das Falten von TAN CHAY YEE zu tan chay yee wird als Fehler gewertet, obwohl der Feldwert korrekt ist; 1,0805, PaddleOCR-VLs CORD-CER — die schlechteste aller 8 Engines, ein Artefakt der strukturlastigen Ground Truth von CORD, während sein CORD-Feld-F1 von 0,3412 das beste des Benchmarks ist; und die 0,6552 / 0,3376-CER-schlechteste / Feld-beste-Umkehrung, die bei einem Ranking allein nach CER den falschen Gewinner auswählt.

CER ist ein Exakt-Match-Bewertungsalgorithmus, kein Qualitätsmesser

CER ist die Levenshtein-Editierdistanz zwischen erkanntem und Referenztext — die minimale Anzahl von Zeicheneinfügungen, -löschungen und -substitutionen, die nötig ist, um einen in den anderen zu überführen, geteilt durch die Länge des Referenztexts (die formale Definition ist in der OCR-D-Bewertungsspezifikation veröffentlicht). Sie zählt Unterschiede und kann eine Fehllesung nicht von einer legitimen Neuformatierung 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 das Zeilenlayout 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 jede verschmolzene Zeile ist eine Editierdistanz-Strafe, selbst wenn der zugrunde liegende Feldwert korrekt ist.

Die Protokollanalyse der veröffentlichten SROIE-Vorhersagen des Benchmarks zerlegt das rohe CER-Budget eines VLM grob in ~76 % Zeichen identisch mit dem Referenztext, ~18 % Groß-/Kleinschreibungs-Substitutionen und ~10 % Zeilenverschmelzungen / entfernte Trennzeichen — wobei die tatsächlichen Feldwerte (Firma, Gesamtsumme, Datum, Adresse) korrekt sind. Diese Zerlegung ist eine protokollbasierte Schätzung aus den Analysenotizen des Benchmarks, keine CSV-Spalte; behandeln Sie die Aufteilung als richtungsweisend, nicht als präzise. Die Richtung ist das Entscheidende: Fallnormalisierung allein kann einen großen Teil des „schlechten“ CER eines VLM auf sauberen englischen Belegen erklären.

Zwei CSV-Zeilen machen den Mechanismus ohne jede Zerlegung sichtbar. Unlimited-OCR erzielt CER 0,6552, aber WER 0,4779 auf SROIE — seine Zeichen wirken verstümmelt, während seine Wörter überleben, weil Fallnormalisierung Zeichen ersetzt, ohne Wörter zu brechen (summary_metrics.csv, cer / wer, unlimited_ocr/sroie_2019-Zeile). Und das VLM, das am wenigsten normalisiert, Surya2, erzielt CER 0,1915 — das beste rohe CER im gesamten 8-Engine-Lauf, nicht von einem starken traditionellen Engine zu unterscheiden (summary_metrics.csv, cer, surya2/sroie_2019-Zeile). Die Ausgabekonvention des VLM, nicht seine Lesefähigkeit, ist das, 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 Feldextraktions-Ranking weichen erheblich voneinander ab. Ordnet man die acht Engines nach SROIE-CER, gewinnt Surya2 (0,1915); ordnet man sie nach Regex-Feld-F1 — der Metrik, die annähernd abbildet, was eine Produktionspipeline tatsächlich konsumiert — gewinnt Unlimited-OCR (0,3376), der Engine, die im CER-Ranking auf dem letzten Platz liegt. Eine der beiden Spalten misst nicht das, was nachgelagerte Systeme tatsächlich verarbeiten.

Feld-F1 ist das harmonische Mittel aus Präzision und Recall über die extrahierten Feldwerte (Firma, Datum, Adresse, Summe bei SROIE): Ein Feld ist eine binäre Einheit — es stimmt überein oder nicht. Die Regex-Spalte wendet dasselbe feste Musterset auf den Text jedes Engines an, sodass die einzige Variable die Ausgabe des Engines ist. Die folgende Tabelle stellt das CER jedes Engines seinem Regex-Feld-F1 auf denselben 361 Belegen gegenüber, jeweils mit dem Rang des 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 in ihrer Größenordnung nicht direkt vergleichbar (unterschiedliche Einheiten), aber ihre Rangfolgen widersprechen sich — genau das ist der Punkt.

Modell	Typ	CER	WER	Regex-Feld-F1	CER-Rang	Feld-F1-Rang	Quelle
Surya2	Dokument-Parsing-VLM	0.1915	0.2735	0.3183	1	4	summary_metrics.csv · surya2/sroie_2019-Zeile
docTR	Traditionelle OCR (GPU)	0.1971	0.3199	0.0766	2	8	summary_metrics.csv · doctr/sroie_2019-Zeile
PaddleOCR	Traditionelle OCR (GPU)	0.2045	0.3256	0.3254	3	3	summary_metrics.csv · paddleocr/sroie_2019-Zeile
EasyOCR	Traditionelle OCR (GPU)	0.2833	0.6158	0.1477	4	7	summary_metrics.csv · easyocr/sroie_2019-Zeile
Tesseract	Traditionelle OCR (CPU)	0.3347	0.5591	0.2335	5	5	summary_metrics.csv · tesseract/sroie_2019-Zeile
PaddleOCR-VL	Dokument-Parsing-VLM	0.3370	0.6462	0.3368	6	2	summary_metrics.csv · paddleocr_vl_vllm/sroie_2019-Zeile
Docling	Pipeline-Parser	0.5909	0.7596	0.2237	7	6	summary_metrics.csv · docling/sroie_2019-Zeile
Unlimited-OCR	Dokument-Parsing-VLM	0.6552	0.4779	0.3376	8	1	summary_metrics.csv · unlimited_ocr/sroie_2019-Zeile

Tabelle: summary_metrics.csv — cer / wer / field_f1_regex-Spalten, sroie_2019-Zeilen. Ränge innerhalb der 8 Zeilen dieser Tabelle berechnet (1 = beste Leistung bei dieser Metrik: niedrigster CER, höchster Feld-F1). Dies sind postprocessed_sroie_receipt_regex_*-Metriken: feste Muster, die auf den OCR-Text jeder Engine angewendet werden, nicht native strukturierte Ausgabe. Tesseract lief nur mit CPU (compute_type=cpu).

Lesen Sie die beiden Inversionspaare explizit. Unlimited-OCR: schlechteste CER (0,6552), bestes Feld-F1 (0,3376) — die Engine, die die Roh-OCR-Metrik auf den letzten Platz setzt, ist die Engine, die die Feld-Perspektive auf den ersten Platz setzt. docTR: zweitbeste CER (0,1971), schlechtestes Feld-F1 (0,0766) — textperfekt, feldgescheitert. PaddleOCR-VL invertiert ebenfalls am Rand (CER-Rang 6, Feld-Rang 2), während die beiden ausgerichteten Zeilen (PaddleOCR 3./3., Tesseract 5./5.) beide traditionelle Engines sind, deren Rohtext-Ausgabekonvention genau das ist, wofür CER entwickelt wurde. Wenn Sie Engines nur nach CER einstufen, erhalten Sie einen anderen Gewinner als wenn Sie nach dem einstufen, was die Produktion konsumiert — die Inversion ist die Demonstration, keine Anomalie.

Die Feldmetrik ist die zuverlässige familienübergreifende Linse

Führen Sie den Rohtext jeder Engine durch denselben LLM-Feldextraktions-Nachbearbeitungsprozess (deepseek-v4-flash, Temperatur 0) aus, und die sechs Engines mit nutzbarem OCR-Text konvergieren auf 0,57–0,62 Feld-F1 — die VLM-gegen-traditionell-Familiengrenze, die die CER-Einstufung riesig erscheinen lässt (0,19 bis 0,66), verschwindet fast. Zwei Engines fallen unter das Band: EasyOCR bei 0,3717 und Tesseract bei 0,4389. Die Feldmetrik trennt Engines nach dem, was tatsächlich zählt — die nachgelagerte Feldwiederherstellung — und sie tut dies konsistent über die Familiengrenze hinweg.

Dies ist derselbe Engine-Satz wie in der CER-Tabelle oben, neu bewertet nur auf der Felddimension: Die CER-Inversion zwischen Unlimited-OCR und docTR ist verschwunden, weil die Feldwert-Wiederherstellung das ist, was die Pipeline konsumiert. Der Mechanismus ist, dass die Nachbearbeitung die Ausgabekonventionsunterschiede absorbiert, die CER bestraft hat — sie liest den fallnormalisierten, labelverschmolzenen Text und extrahiert die Werte. Das LLM-Feld-F1 hier ist die llm_field_value_f1-Spalte des Methodenvergleichs des Benchmarks, wobei das LLM-Modell pro Zeile erfasst wird.

Modell	Typ	CER (Kontext)	LLM-Feld-F1	Im Konvergenzband (0,57–0,62)	Quelle
docTR	Traditionelle OCR (GPU)	0.1971	0.6171	Ja — am höchsten	field_method_comparison.csv · llm_field_value_f1, Zeile doctr/sroie_2019
Surya2	Dokument-Parsing-VLM	0.1915	0.6139	Ja	field_method_comparison.csv · llm_field_value_f1, Zeile surya2/sroie_2019
Unlimited-OCR	Dokument-Parsing-VLM	0.6552	0.6054	Ja	field_method_comparison.csv · llm_field_value_f1, Zeile unlimited_ocr/sroie_2019
PaddleOCR-VL	Dokument-Parsing-VLM	0.3370	0.5921	Ja	field_method_comparison.csv · llm_field_value_f1, Zeile paddleocr_vl_vllm/sroie_2019
PaddleOCR	Traditionelle OCR (GPU)	0.2045	0.5810	Ja	field_method_comparison.csv · llm_field_value_f1, Zeile paddleocr/sroie_2019
Docling	Pipeline-Parser	0.5909	0.5685	Ja — Bandgrenze	field_method_comparison.csv · llm_field_value_f1, Zeile docling/sroie_2019
Tesseract	Traditionelle OCR (CPU)	0.3347	0.4389	Nein — darunter	field_method_comparison.csv · llm_field_value_f1, Zeile tesseract/sroie_2019
EasyOCR	Traditionelle OCR (GPU)	0.2833	0.3717	Nein — darunter	field_method_comparison.csv · llm_field_value_f1, Zeile easyocr/sroie_2019

Tabelle: field_method_comparison.csv — Spalte llm_field_value_f1, Zeilen sroie_2019, llm_model=deepseek-v4-flash. Die CER-Spalte wird zur Referenz aus summary_metrics.csv wiederholt. Das “Konvergenzband” ist der beobachtete Bereich von 0,5685–0,6171 der sechs Engines mit brauchbarem Text; die beiden Zeilen unterhalb des Bands werden als Beobachtungen angegeben, nicht als Klassifizierung der Engines.

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

Der veröffentlichte Referenztext von CORD (gt_text) enthält Anmerkungsstruktur — Feldbezeichnungen, Menüeinträge und Koordinaten — statt reinem sichtbarem Text. CER berechnet die Editierdistanz zu dieser strukturell erweiterten Zeichenkette, sodass die CORD-CER jeder Engine 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 fast nichts über die Textqualität aussagt.

Das extreme Artefakt ist die CORD-CER von PaddleOCR-VL mit 1,0805, der schlechteste Wert aller 8 Engines — kein Maß für die Textqualität, sondern die strukturelle Inflation, die am stärksten gegen die sauberste, kürzeste Ausgabe wirkt, welche die größte relative Editierdistanz zum strukturlastigen Referenztext von CORD aufweist. Bei der Feldperspektive erzielt dieselbe Engine die beste CORD-Regex-Feld-F1 (0,3412) des Benchmarks. CORD-CER ist strukturell unbrauchbar; Feldmetriken sind die einzige faire CORD-Perspektive, und sie werden in diesem Benchmark strikt von jedem SROIE-Ranking getrennt (andere Sprache — Indonesisch — und andere Referenztextstruktur).

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

Modell	Typ	CORD CER	Regex-Feld-F1	Quelle
PaddleOCR-VL	Dokument-Parsing-VLM	1.0805	0.3412	summary_metrics.csv · paddleocr_vl_vllm/cord_v2 row
Surya2	Dokument-Parsing-VLM	0.8959	0.2458	summary_metrics.csv · surya2/cord_v2 row
Unlimited-OCR	Dokument-Parsing-VLM	0.9224	0.1079	summary_metrics.csv · unlimited_ocr/cord_v2 row
Tesseract	Traditionelle OCR (CPU)	0.9523	0.0752	summary_metrics.csv · tesseract/cord_v2 row
Docling	Pipeline-Parser	0.9219	0.0612	summary_metrics.csv · docling/cord_v2 row
PaddleOCR	Traditionelle OCR (GPU)	0.9083	0.0154	summary_metrics.csv · paddleocr/cord_v2 row
EasyOCR	Traditionelle OCR (GPU)	0.9185	0.0067	summary_metrics.csv · easyocr/cord_v2 row
docTR	Traditionelle OCR (GPU)	0.9101	0.0000	summary_metrics.csv · doctr/cord_v2 row

Tabelle: summary_metrics.csv — Spalten cer / field_f1_regex, Zeilen cord_v2. CORD wird in kein SROIE-Ranking eingemischt (Protokollregel): Die Referenzstruktur erhöht den CER für jede Engine, und die Regex-Muster wurden für englische Formate geschrieben. Feldmetriken sind die einzige faire CORD-Perspektive. Sortiert nach Feld-F1, nicht nach CER — der Punkt ist, dass die CER-Spalte kein Sortiersignal trägt.

Die Feldperspektive dreht die CORD-Tabelle komplett um. Die Engine mit dem schlechtesten CORD-CER des Benchmarks (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) in der Mitte des Clusters liegt und nichts darüber aussagt. Bei CORD ist die Veröffentlichung des CER ohne die Feldzahlen nicht nur uninformativ; sie ordnet die Engines aktiv in der falschen Reihenfolge ein.

Wann CER tatsächlich die richtige Metrik ist

CER misst weiterhin etwas Reales — die exakte Zeichenwiedergabe — und ist immer dann die richtige Metrik, wenn der nachgelagerte Verbraucher wörtlichen Text benötigt, keine Felder. Die Schlussfolgerung dieser Seite lautet: “CER führt beim familienübergreifenden Vergleich von VLM-Ausgaben in die Irre”, nicht “CER ist immer falsch.”

Innerhalb der Raw-OCR-Familie behält CER seinen Wert. Traditionelle Engines geben Rohtext mit erhaltener Groß-/Kleinschreibung und Layout aus, sodass CER die tatsächliche Lesequalität misst: Die CER-Spalte der traditionellen Engines in diesem Benchmark (0.1971–0.3347 auf SROIE) korreliert deutlich enger mit ihrer Felderleistung als bei den VLMs (Rangkorrelation mit Regex-Feld-F1: PaddleOCR und Tesseract sind exakt auf 3./3. und 5./5. ausgerichtet).
Anwendungsfälle mit wörtlichem Text. Nachgelagerte Verbraucher mit exakter Übereinstimmung — Volltextsuche, die eine wörtliche Zeichenfolge finden muss, Prüfpfade, die die Zeichen eines Dokuments wiedergeben, oder Bestehen/Nichtbestehen-Prüfungen gegen eine erforderliche Zeichenfolge — verbrauchen Zeichen, keine Felder. Für diese ist die exakte Zeichenwiedergabe (CER) das getreue Maß und Feld-F1 die falsche Linse.
Faustregel für Veröffentlichungen. Wenn Sie einen CER-Wert veröffentlichen, geben Sie sowohl die Ausgabekonvention der Engine an (faltet sie Groß-/Kleinschreibung? verschmilzt sie Labels? sortiert sie Zeilen um?) als auch die Konstruktion des Referenztexts (reiner sichtbarer Text oder annotationserweitert wie CORDs gt_text). Ist einer von beiden unbekannt, ist der Wert nicht über Engines oder Datensätze hinweg übertragbar.
Die Grenzregel aus diesem Benchmark. CER ist innerhalb der Raw-OCR-Familie fair und unfair über die Grenze zwischen traditioneller OCR und Dokument-Parsing-VLM; Feld-F1 (Regex oder LLM-nachbearbeitet) ist über beide hinweg fair. Verwenden Sie CER für die Rohtextqualität innerhalb einer Familie und Feld-F1 für familienübergreifende Vergleiche — und geben Sie für VLM-Zeilen immer den Hinweis auf die Zerlegung an.

Häufig gestellte Fragen

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

Weil CER eine exakte Zeichen-Editierdistanz-Metrik ist und Dokument-Parsing-VLMs bewusst keine Zeichen exakt reproduzieren — sie führen Fallnormalisierung durch, verschmelzen Label/Wert-Zeilen und ordnen Text neu. 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 den besten Regex-Feld-F1 (0,3376) auf denselben 361 Belegen hat (summary_metrics.csv, cer / field_f1_regex, Zeile unlimited_ocr/sroie_2019) — das CER-Ranking und das Feld-Ranking wählen unterschiedliche Gewinner.

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

Ja — innerhalb der Raw-OCR-Familie und für Verbraucher von wörtlichem Text. 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 folgt der Feldleistung (PaddleOCR 3./3., Tesseract 5./5. unter 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?

Meistens ist es die Ausgabekonvention, nicht die Lesefähigkeit. Die Protokollanalyse des Benchmarks führt etwa ~18 % des SROIE-CER-Budgets eines VLM auf Fallsubstitutionen und ~10 % auf Zeilenzusammenführungen/entfernte Trennzeichen zurück (Schätzung aus den Analysenotizen des Benchmarks, keine CSV-Spalte) — während die Feldwerte selbst korrekt sind. Unlimited-OCRs CER 0,6552 gegenüber WER 0,4779 zeigt die Signatur: Zeichen werden gefaltet, Wörter überleben (summary_metrics.csv, cer / wer, Zeile unlimited_ocr/sroie_2019).

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

Feld-F1 — Regex-Nachbearbeitung für eine reine OCR-Pipeline, LLM-Nachbearbeitung für beide Familien. Bei SROIE konvergiert das LLM-Feld-F1 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 Linse, die die CORD-Tabelle sinnvoll einordnet, wobei PaddleOCR-VLs 0,3412 das beste Ergebnis des Benchmarks ist (summary_metrics.csv, field_f1_regex, cord_v2-Zeilen). Geben Sie immer die Nachbearbeitung und die Ausgabekonvention zusammen mit der Zahl an.

Warum ist PaddleOCR-VLs CER bei CORD so hoch, aber sein Feld-F1 das beste?

Weil CORDs Referenztext die Annotationsstruktur (Feldbezeichnungen, Koordinaten, Menüeinträge) statt reinen sichtbaren Texts einbettet und PaddleOCR-VLs Ausgabe die sauberste ist — am kürzesten, am stärksten normalisiert —, sodass seine Editierdistanz zu diesem strukturell erweiterten String am größten ist (CER 1,0805, schlechtester von 8). Bei der Feld-Linse extrahiert derselbe Text indonesische Belegfelder mit 0,3412 Feld-F1, dem besten Wert des Benchmarks (summary_metrics.csv, cer / field_f1_regex, paddleocr_vl_vllm/cord_v2-Zeile). CORD-CER ist für jede Engine strukturell unbrauchbar; Feldmetriken sind der einzige faire CORD-Vergleich.

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

Fallnormalisierung bedeutet, allen Text auf eine einzige Schreibweise zu bringen — TAN CHAY YEE wird zu tan chay yee. CER vergleicht Zeichen exakt, daher ist jeder normalisierte Buchstabe eine Substitution gegenüber dem Großbuchstaben im Referenztext, obwohl der Wert identisch ist. In der Protokollanalyse dieses Benchmarks machen Fallsubstitutionen etwa ~18 % des SROIE-CER-Budgets eines VLM aus (protokollbasierte Schätzung) — weshalb ein VLM einen Beleg perfekt lesen und dennoch einen CER melden kann, der wie ein fehlgeschlagenes Modell aussieht.

Sollte ich OCR-Engines nach CER oder nach Feld-F1 vergleichen?

Nach Feld-F1 für jeden Vergleich, der sowohl traditionelle OCR- als auch VLM-Engines betrifft — weil Ihre Pipeline Felder und keine Zeichenströme verarbeitet und weil CER bei normalisierter VLM-Ausgabe und strukturangereichertem Referenztext systematisch verzerrt ist. Verwenden Sie CER nur innerhalb der Raw-OCR-Familie oder wenn der nachgelagerte Verbraucher wortgetreuen Text benötigt (Suche, Audit, exakte Übereinstimmung). Die beiden Metriken weichen in diesem Benchmark stark voneinander ab: CER stuft docTR auf Platz 2 und Unlimited-OCR auf Platz 8 ein; Regex-Feld-F1 stuft docTR auf Platz 8 und Unlimited-OCR auf Platz 1 ein (summary_metrics.csv, sroie_2019-Zeilen).

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

Jede Tabellenzahl ist eine Zeile des veröffentlichten results/summary_metrics.csv oder results/field_method_comparison.csv des First-Party-Benchmarks, gehostet unter ImageToTableai/benchmark-ocr, mit einem redigierten manifest.json pro Lauf, das Modellversionen und Umgebungs-Fingerabdrücke erfasst. Die ~76%/~18%/~10%-CER-Aufschlüsselung ist eine protokollabgeleitete Schätzung aus den Analysenotizen des Benchmarks, ausdrücklich keine CSV-Spalte. Die Datensatzdefinitionen stammen aus den unten zitierten SROIE- und CORD-Publikationen.

Methodik & Quellen

Protokoll

Diese Seite berichtet die Metrik-Fairness-Dimension eines unabhängigen, reproduzierbaren Benchmark-Laufs (offizielle Stufe) — keine Übersicht über Drittanbieter-Behauptungen. Nur feste Test-Splits: SROIE-2019-Test (361 englische Belege, flache Felder company/date/address/total, CC-BY-4.0) und CORD-v2-Test (100 indonesische Belege, verschachtelte Felder menu/sub_total/total, CC-BY-4.0); Trainings-Splits wurden nie ausgewertet. Acht Engines liefen out-of-the-box, ohne Fine-Tuning, unter dem eingefrorenen Protokoll reports/receipt_v1_official_protocol.md (warm-then-scored, nur offizielle Stufe). Alle 16 bewerteten Läufe wurden mit error_rate 0.0 abgeschlossen (Spalte error_rate in summary_metrics.csv). Die Daten wurden im August 2026 erhoben.

Laufzeitumgebung

Hardware: alle GPU-Läufe auf einer einzelnen NVIDIA RTX 4090 (24 GB); Tesseract lief nur mit CPU (compute_type=cpu) und ist in jeder Tabelle entsprechend gekennzeichnet.
Engines und Versionen (laut Run-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-basiert, PaddleOCR-VL 1.6.
Feld-Nachbearbeitung: Regex-Feld-F1 = feste sroie_receipt_regex/cord_receipt_regex-Muster, angewendet auf den OCR-Text jeder Engine (nachbearbeitet, nicht native Extraktion); LLM-Feld-F1 = deepseek-v4-flash (Temperatur 0), das denselben Text liest (Spalte llm_model in field_method_comparison.csv).

Metrikdefinitionen

Character Error Rate (CER): Levenshtein-Editierdistanz zwischen erkanntem und Referenztext — minimale Einfügungen/Löschungen/Substitutionen geteilt durch die Länge des Referenztexts (OCR-D-Evaluierungsspezifikation). Niedriger ist besser. Misst nur die exakte Zeichenwiedergabe.
Word Error Rate (WER): dieselbe Editierdistanz-Logik auf Wortebene — ein Wort übersteht eine einzelne Fallsubstitution, sodass die CER/WER-Divergenz eine Normalisierung offenbart, die Zeichen verändert, ohne Wörter zu brechen.
Feldwert-F1: harmonisches Mittel aus Präzision und Recall über extrahierte Feldwerte; ein Feld stimmt nur, wenn es exakt dem Referenztext entspricht. Die Regex- und LLM-Spalten sind zwei Nachbearbeitungen desselben OCR-Texts und werden nie vermischt.
Ausgabekonvention: wie eine Engine ihren Text formatiert (Groß-/Kleinschreibung, Trennzeichen, Zeilenreihenfolge). Traditionelle Engines bewahren sie; Dokument-Parsing-VLMs normalisieren sie — die Achse, die diese Seite misst.
Referenztext-Struktur: ob der Referenztext reiner sichtbarer Text (SROIE) oder um Anmerkungsstruktur erweitert ist (CORD gt_text), was den CER für jede Engine erhöht.

Quellenverzeichnis

summary_metrics.csv (GitHub raw). 16 Zeilen = 8 Engines × 2 Belegdatensätze. Spalten umfassen cer, wer, field_f1_regex, field_acc_regex, compute_type, error_rate. Jeder CER/WER- und Regex-Feld-F1-Wert auf dieser Seite stammt aus einer Zeile hier, zitiert auf Datei-/Modell-/Datensatz-/Metrikebene.
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.
ImageToTableai/benchmark-ocr-Repository. Öffentliches Repository mit den Ergebnis-CSVs, redigierten Lauf-Manifesten, dem eingefrorenen Protokoll (reports/receipt_v1_official_protocol.md) und festen Stichprobenlisten für die Reproduktion.
results/manifests/ (GitHub). Ein redigiertes manifest.json pro veröffentlichtem Lauf mit Modellversionen, Umgebungs-Fingerprints und Artefakt-Hashes.
receipt_v1_official_protocol.md. Der eingefrorene Laufvertrag: feste Test-Splits, offizielle Stufe, Warm-up- und Bewertungsmessung, CORD-vs-SROIE-Trennungsregeln. Quelle für die auf dieser Seite zitierten Protokollregeln.
Analysehinweise zum Benchmark-Protokoll (interne Laufdokumentation, WRITING_BRIEF §8.2/§8.3). Der VLM-Normalisierungsmechanismus (Fallnormalisierung, Label/Wert-Verschmelzung, Zeilenumsortierung), der CORD-Referenztext-Strukturmechanismus und die SROIE-CER-Zerlegung (~76 % identisch / ~18 % Groß-/Kleinschreibung / ~10 % Zeilenzusammenführung). Hier zitiert mit der ausdrücklichen Kennzeichnung “protokollbasierte Schätzung — keine CSV-Spalte”; die Aufteilung ist richtungsweisend, nicht präzise.
OCR-D-Projekt — Spezifikation zur Qualitätssicherung. Formale CER-Definition (Einfügungen + Löschungen + Ersetzungen) / Gesamtzeichen sowie das WER-Pendant. Formaler Definitionsanker.
Huang et al., “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction” (2019). SROIE-2019-Datensatzdefinition, Aufgabenstruktur, Lizenz (CC-BY-4.0).
Park et al., “CORD: A Consolidated Receipt Dataset for Post-OCR Parsing” (2020). CORD-Datensatzdefinition, verschachteltes Feldschema, Lizenz (CC-BY-4.0).

Einschränkungen

Die Zerlegungszahlen sind protokollbasierte Schätzungen, keine Messungen: Die ~76 %/~18 %/~10 %-SROIE-CER-Zerlegung stammt aus den Protokollanalysehinweisen des Benchmarks (WRITING_BRIEF §8.2), nicht aus einer CSV-Spalte. Die Richtung (Normalisierung, nicht Falschlesen, dominiert die VLM-CER) ist robust; die genauen Prozentsätze sollten als Richtwertschätzungen und nicht als Punktmessungen betrachtet werden.
Nur Belege: SROIE (englisch) und CORD (indonesisch) Belege. Das Verhalten bei Rechnungen, Formularen, Tabellen oder langen Dokumenten ist nicht gemessen; der Mechanismus verallgemeinert, die Zahlen nicht.
Einzelner LLM-Nachbearbeitungsschritt: Alle LLM-Feld-F1-Werte verwenden deepseek-v4-flash bei Temperatur 0. Ein anderes LLM verschiebt die absoluten F1-Werte und möglicherweise das Konvergenzband; die familienübergreifende Reihenfolge innerhalb des Bandes ist das stabile Signal.
CER bleibt für wortgetreue Textfälle gültig: Die Schlussfolgerung ist auf den familienübergreifenden Vergleich von VLM-ähnlichen Ausgaben beschränkt. Für den Roh-OCR-Vergleich innerhalb derselben Familie und für nachgelagerte Anwendungen mit exakter Zeichenübereinstimmung (Suche, Audit) bleibt CER eine legitime Metrik – diese Seite ist kein Argument gegen CER in diesen Kontexten.
CORD nicht in SROIE-Rankings zusammengeführt: Andere Sprache, andere Referenztextstruktur. CORD wird nur anhand von Feldmetriken verglichen, gemäß dem Benchmark-Protokoll.
Versions- und Hardware-Festlegung: Die Zahlen gelten für die Modellversionen vom August 2026 und eine oben aufgeführte GPU-Stufe (RTX 4090). Neuere Versionen verschieben CER und Feld-F1; Unterschiede im einstelligen Prozentbereich sollten als Rauschen betrachtet werden.
Stichprobengröße: 361 + 100 Stichproben; Bootstrap-Konfidenzintervalle werden in der Auswertung des Benchmarks berichtet, aber auf dieser Seite nicht zeilenweise reproduziert.