OCR im Jahr 2026: Klassische Pipelines, VLMs und Document AI

Viacheslav Dubrov

2026-03-04 · Aktualisiert 2026-08-10 · 12 Min. · Retrieval- und Sprachsysteme

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

OCR-Leaderboards widersprechen sich, weil sie unterschiedliche Dokumente, Outputs und Judges testen. Ein Snapshot von OmniDocBench und OCR Arena von Anfang 2026 ergab deutlich unterschiedliche Model-Reihenfolgen. Die Scores sind nicht austauschbar, aber die Abweichung ist aufschlussreich. Für eine Entscheidung im Produktivbetrieb braucht man Dokumente und Metriken aus dem tatsächlichen Workload.

Vision-Language-Models (VLMs) können mit Layout, Handschrift, Tabellen und beschädigten Bildern umgehen, an denen eine einfache Texterkennungs-Pipeline scheitert. Klassische Engines bleiben bei sauberem Druck konkurrenzfähig, insbesondere wenn CPU-Latency und Betriebskosten wichtig sind. Der untenstehende Snapshot enthält PaddleOCR-VL 1.6 und dots.mocr, die sich hinsichtlich Hardware, Datenschutz und Output-Trade-offs unterscheiden. Prüfe jedes Projekt, bevor du eine aktuelle Entscheidung triffst.

Begleit-Repo: The OCR Gauntlet enthält drei Notebooks. Das Hauptnotebook vergleicht bis zu fünf OCR-Engines anhand von fünf heruntergeladenen Samples und berichtet CER, WER, ANLS, Latency und geschätzte Kosten. Der eingecheckte Run enthält Tesseract, Docling + Tesseract, Mistral OCR v3 und einen Gemini-Run; dots.ocr war nicht verfügbar. Verwende die Gemini-Zeile nicht für Model-Vergleiche: Der Runner fordert gemini-2.5-flash an, das eingecheckte Notebook bezeichnet diesen Output jedoch als Gemini 3 Flash.

Dieser Guide richtet sich an Engineers, die eine OCR- oder Document-AI-Pipeline für reale Workloads auswählen, bei denen Text, Layout, Tabellen oder extrahierte Felder relevant sind.

Nach der Lektüre solltest du eine Baseline auswählen, Models anhand aufgabenspezifischer Metriken vergleichen und unsichere oder risikoreiche Felder zur Validierung oder Prüfung routen können.

Eine kompakte Version zur Model-Auswahl findest du unter Best OCR Models in 2026: Classical OCR, PaddleOCR-VL, VLMs.

OCR bestimmt heute die Qualität nachgelagerter Systeme

OCR treibt seit Langem Archive, Postsysteme, Accessibility-Tools und Dokumentenmanagement an. RAG und Document Agents haben seine Failure Modes für eine größere Gruppe von Engineers sichtbar gemacht: Ein nachgelagertes Model kann Text oder Tabellenstruktur, die bei der Extraktion verworfen wurden, nicht wiederherstellen.

Die Retrieval-Qualität deines RAG-Systems ist durch die OCR-Qualität begrenzt. Wenn die Extraktion eine Tabelle verfälscht, ein Datum falsch liest oder einen Absatz auslässt, können nachträgliche Änderungen an Chunking und Embedding die fehlenden Informationen nicht wiederherstellen. Solche Fehler können eine Vertragsklausel verbergen, eine Rechnungssumme verändern oder eine medizinische Akte beschädigen.

OCR ist daher neben Parsing, Chunking, Embedding und Indexing Teil der Retrieval- und Agent-Infrastruktur. Seine Fehler brauchen eine eigene Evaluation, statt in einem einzigen End-to-End-Score aufzugehen.

Was OCR im Zeitalter der Foundation Models bedeutet

OCR wandelt Text in einem Bild in maschinenlesbare Zeichen um. Document AI ist das umfassendere System darum herum: Layout-Analyse, Parsing von Tabellen und Formeln, Feldextraktion, semantisches Reasoning, Provenance und Validierung. Einige Papers verwenden „OCR-2.0“ für End-to-End-Models, die mehrere dieser Stufen kombinieren. Dieses Label sollte jedoch die Unterscheidung zwischen Recognition und Document Understanding nicht verwischen.

Die klassische OCR-Pipeline besteht aus drei Kernstufen:

1. Text Detection: Regionen mit Text lokalisieren (z. B. CRAFT, DBNet).
2. Text Recognition: Erkannte Regionen in Zeichenfolgen umwandeln (z. B. CRNN).
3. Post-Processing: Rechtschreibprüfung und Korrektur durch ein Language Model.

Das funktioniert bei sauberen Dokumenten gut, aber Fehler bei Detection, Recognition und Post-Processing können sich aufaddieren. Miss sowohl die Zeichengenauigkeit als auch die Genauigkeit nachgelagerter Felder, damit eine lesbare Seite nicht eine falsche Summe oder Kennung verbirgt.

OCR-2.0 fasst größere Teile dieser Pipeline in einem Vision Encoder und einem Language Decoder zusammen. Models wie GOT-OCR 2.0 können Text und Struktur gemeinsam ausgeben, während allgemeine VLMs Felder auch auf ein angefordertes Schema abbilden können. Die Trade-offs hängen vom Workload ab: Latency, GPU- oder API-Kosten und das Risiko plausiblen Texts, der im Bild nicht vorhanden ist.

Praktischer Hinweis: Lass dich nicht vom Label „End-to-End“ täuschen. In der Produktion vereinheitlicht OCR-2.0 die Model-Inference, nicht die gesamte Dokument-Pipeline. Du brauchst weiterhin PDF-Rasterization, um Bilder zu erzeugen, Image-Normalization (Deskew, DPI-Anpassung) für eine konsistente Qualität sowie Output-Parsing, um strukturierte Felder aus dem Model-Text zu extrahieren. Die Pipeline ist kürzer geworden, nicht verschwunden.

Was OCR-Benchmarks messen – und was ihnen fehlt

Die folgenden Datasets zeigen, wie unterschiedliche OCR-Tasks zu unterschiedlichen Metriken führen. Dataset-Größen und Metriken beziehen sich auf die jeweils genannte Dataset-Version. Verwende für Model-Scores das aktuelle Leaderboard des jeweiligen Projekts.

Die Lücke zwischen „Benchmark“ und „Arena“

Automatisierte Benchmark-Rankings können von menschlichen Präferenzen abweichen, weil sich Input-Verteilung und Bewertungskriterien unterscheiden.

In der OCR Arena stimmen Nutzer anonym über Outputs aus direkten Vergleichen ab. Am 09.08.2026 platzierte das Live-Ranking Gemini 3 Flash vor GLM-OCR und DeepSeek-OCR, während die versionierte OmniDocBench-Tabelle später in diesem Artikel spezialisierte Document Models vor Gemini 3 Flash einordnete. Arena-Werte ändern sich nach neuen Battles. Das Ranking ist daher eher richtungsweisendes Evidence als ein reproduzierbarer Benchmark-Snapshot. Die beiden Leaderboards sollten nicht zu einem Score kombiniert werden, weil das eine Dataset-Metriken und das andere Präferenzabstimmungen verwendet.

Zu den wahrscheinlichen Einflussfaktoren gehören Dokumentmix, Output-Formatierung, Sprachabdeckung und Judge-Kriterien. Veröffentlichte Zahlen sind für ein erstes Screening nützlich, aber die finale Auswahl braucht ein Held-out-Set aus dem Ziel-Workload.

Klassische OCR-Engines: weiterhin relevant

Wenn klassische Engines bei komplexen Daten schlechter sind, warum sollte man sie einsetzen? Weil sie bei sauberen strukturierten Daten schnell und günstig sind.

Klassische Engines sind nützliche Baselines, weil sie lokal auf der CPU laufen können. Ihre Latency und Accuracy hängen vom gewählten Model, der Seitenauflösung, Sprache, Preprocessing und Hardware ab. Deshalb solltest du sie auf denselben gelabelten Seiten benchmarken, die auch für die VLM-Evaluation verwendet werden.

Tesseract für sauberen Druck

Tesseract (v5.5.x, Apache 2.0) ist eine ausgereifte CPU-only Engine mit mehr als 100 Language Packs. Die Accuracy bei sauberem Druck kann nach geeigneter Rasterization und Preprocessing hoch sein. Handschrift, Scene Text und komplexe Layouts müssen jedoch separat getestet werden. Der wichtigste Vorteil ist ein kleines lokales CPU-Deployment, nicht ein universeller Accuracy-Vorsprung.

EasyOCR

EasyOCR kombiniert einen CRAFT Detector mit einem CRNN Recognizer. Mit vollständiger PyTorch-GPU-Beschleunigung ist es eine schnelle Option für schnelles Prototyping und Scene Text.

Das Snippet benötigt pip install easyocr, PyTorch, die heruntergeladenen Model Weights von EasyOCR und ein lokales receipt.jpg. Es wurde auf Syntax geprüft, aber vom Markdown-Runner des Repositorys nicht ausgeführt.

import easyocr

# Three lines for complete OCR
reader = easyocr.Reader(["en"])
result = reader.readtext("receipt.jpg")
# Returns: [(bbox, text, confidence), ...]

PaddleOCR 3

PaddleOCR 3 bündelt gepflegte OCR-, Dokument-Parsing- und Deployment-Pipelines. Der aktuelle Quick Start verwendet die predict() API und explizite Orientation Settings. Pinne das paddleocr Package und die ausgewählte Pipeline, weil Beispiele für 2.x mit .ocr(..., cls=True) nicht zur 3.x API passen.

Das Snippet benötigt pip install "paddleocr>=3,<4", eine kompatible PaddlePaddle-Runtime, heruntergeladene Model Weights und ein lokales receipt.jpg. Es wurde auf Syntax geprüft, aber vom Markdown-Runner des Repositorys nicht ausgeführt.

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
)

for result in ocr.predict("receipt.jpg"):
    result.print()
    result.save_to_json("output")

Spezialisierte und allgemeine VLM-Optionen

Schiefe Belege, verzerrte Produktetiketten, Handschrift und dichte Layouts sind die Fälle, in denen spezialisierte oder allgemeine VLMs gegenüber klassischen Engines getestet werden sollten.

Die Welle der spezialisierten OCR-Models

Die Model-Liste in diesem Abschnitt ist der am 09.08.2026 geprüfte Snapshot. Sie ist kein aktuelles Ranking. Zu den zwischen 2024 und 2026 veröffentlichten spezialisierten Document-Parsing-Models gehören:

• PaddleOCR-VL 1.6: Eine zweistufige Pipeline, die zunächst eine Layout-Analyse durchführt und anschließend eine 0,9B-VLM-Komponente auf den erkannten Regionen verwendet. PaddleOCR meldet 109 Sprachen und einen Wert von 96,3 auf OmniDocBench v1.6. Ordne dieses Vendor-Ergebnis der genannten Pipeline und Benchmark-Version zu.
• dots.mocr (3B): Der Nachfolger von dots.ocr-1.5 vom März 2026, der Text und strukturierte Grafiken einschließlich einer SVG-orientierten Variante parst. Das ursprüngliche dots.ocr bleibt ein separates Model aus dem Jahr 2025.
• GOT-OCR 2.0: Ein einheitliches Model mit 580M Parametern, das Plain Text und formatierte Outputs wie Markdown und LaTeX ausgibt. Das offizielle Repository veröffentlicht keine minimale VRAM-Angabe. Miss daher den Peak Memory mit der gewählten Runtime, Precision, Bildgröße und Output-Begrenzung.
• DeepSeek-OCR2: Der zum Snapshot-Datum im offiziellen Repository dokumentierte Checkpoint, der auf das ursprüngliche DeepSeek-OCR-Model der 3B-Klasse folgt, mit dem „contextual optical compression“ eingeführt wurde. Behandle Throughput-Angaben für beide Generationen als hardware- und datensatzspezifisch.
• Mistral OCR 4.0 (mistral-ocr-4-0), Snapshot 09.08.2026: Der von Mistral dokumentierte proprietäre Service zur Extraktion von Text und Struktur. OCR 3 (mistral-ocr-2512) bleibt für bestehende Integrationen verfügbar und wird vom Begleit-Notebook verwendet. Das Begleit-Notebook verwendet OCR 3 absichtlich zur Reproduzierbarkeit, nicht weil OCR 3 neuer wäre. Preise und Benchmark-Zahlen ändern sich. Prüfe daher beim Vergleich das aktuelle Model Card und die Provider-Bedingungen.

Frontier-VLMs

Allgemeine VLMs sind eine weitere Option, wenn der Task Extraktion mit visuellem oder semantischem Reasoning verbindet. Die folgenden Beispiele entsprechen dem Early-2026-Snapshot des Artikels, nicht einem aktuellen Ranking:

• Qwen3-VL (Alibaba): Eine Open-Weight-VLM-Familie mit mehreren Größen und Long-Context-Varianten.
• Gemini 3 Flash (Google): Ein gehostetes multimodales Model, das im zitierten OCR-Arena-Snapshot hoch platziert war.
• Claude Opus 4.6 (Anthropic): Ein gehostetes allgemeines VLM mit Structured-Output-Unterstützung.
• GPT-5.2 (OpenAI): Ein gehostetes allgemeines VLM für gemischte visuelle und textuelle Inputs.

Miss Latency nach Tier

Miss die Seiten-Latency mit der tatsächlichen Auflösung, Batch-Größe, Hardware oder Provider-Region sowie Output-Länge. Beziehe Preprocessing und Retries in die Gesamtsumme ein. Eine Messung nur für das Model kann keine erfolgreiche Seite bepreisen.

Metriken: Miss, was zählt

Wähle eine Metrik, die zum Output-Typ passt:

• CER und WER für Plain Text. Character und Word Error Rate hängen von Normalisierungsentscheidungen wie Groß-/Kleinschreibung, Whitespace und Interpunktion ab. Lege daher das Vergleichsprotokoll fest, bevor du Models vergleichst.
• EMR und Field F1 für Formulare und Belege. Exact Match Rate ist binär – genau das ist für Steuer-IDs und Summen erwünscht. Field F1 balanciert Precision und Recall pro Feldtyp.
• TEDS für Tabellen. Tree-Edit-Distance-based Similarity vergleicht vorhergesagte und referenzierte HTML-Trees und erkennt Struktur- sowie Zellinhaltsfehler, die CER verbirgt.
• ANLS für Document VQA. Average Normalized Levenshtein Similarity gibt für Antworten mit kleineren OCR-Fehlern teilweise Credit.

Für Implementierungen: jiwer unterstützt CER/WER direkt. TEDS-Implementierungen befinden sich im OmniDocBench-Repo.

VLMs mit OpenRouter testen

OpenRouter stellt ein OpenAI-kompatibles Gateway zu Models verschiedener Provider bereit. Model-IDs und unterstützte Request-Features ändern sich. Prüfe sie daher vor der Ausführung des Beispiels im aktuellen Katalog des Gateways.

Das Snippet benötigt pip install openai, einen OPENROUTER_API_KEY, Netzwerkzugriff, ein lokales receipt.jpg und von OpenRouter weiterhin unterstützte Model-IDs. Es wurde auf Syntax geprüft, aber vom Markdown-Runner des Repositorys nicht ausgeführt.

import base64
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

def extract_text(image_path: str, model: str) -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode()

    response = client.chat.completions.create(
        model=model,
        messages=[{
            "role": "user",
            "content": [
                {"type": "text", "text": "Extract all text from this image, preserving layout as markdown."},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
            ],
        }],
        max_tokens=4096,
    )
    return response.choices[0].message.content

# Compare models by changing one string
models = [
    "google/gemini-3-flash-preview",
    "anthropic/claude-sonnet-4.5",
    "qwen/qwen3-vl-8b-instruct",
]
for model in models:
    print(f"\n--- {model} ---\n{extract_text('receipt.jpg', model)[:200]}...")

Diese Model-IDs wurden am 09.08.2026 mit dem OpenRouter-Katalog abgeglichen. Prüfe den Katalog vor der Ausführung des Beispiels erneut.

Für strukturierte Extraktion kannst du response_format mit einem JSON-Schema verwenden, sofern das ausgewählte Model und Gateway dies unterstützen. Dadurch kann die Antwort parsebar werden; die extrahierten Werte werden dadurch jedoch nicht gegen das Bild validiert. Der folgende Block wiederholt sein Setup, damit er unabhängig lesbar ist. Er benötigt weiterhin pip install openai, einen OPENROUTER_API_KEY, Netzwerkzugriff, ein lokales receipt.jpg und ein Model mit Unterstützung für JSON Schema. Der Repository-Runner prüft den Block lediglich auf Syntax.

import base64
import json
import os
from openai import OpenAI

with open("receipt.jpg", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode()

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

response = client.chat.completions.create(
    model="google/gemini-3-flash-preview",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Extract the receipt fields from this image."},
            {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
        ],
    }],
    max_tokens=4096,
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "receipt",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "vendor": {"type": "string"},
                    "date": {"type": "string"},
                    "items": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": "string"},
                                "amount": {"type": "number"},
                            },
                            "required": ["description", "amount"],
                            "additionalProperties": False,
                        },
                    },
                    "total": {"type": "number"},
                },
                "required": ["vendor", "date", "items", "total"],
                "additionalProperties": False,
            },
        },
    },
)
receipt = json.loads(response.choices[0].message.content)

Benchmark-Ergebnisse: Was die Zahlen tatsächlich zeigen

Die folgende Tabelle ist ein versionierter Snapshot: OmniDocBench v1.6_full, offizielles README im Commit 09ba2b606662695b16aafe5f5e36b7ef020e11a8, veröffentlicht am 10.04.2026 und abgerufen am 09.08.2026. Alle vier Zeilen stammen aus dieser gepinnten Tabelle. Die Tabelle mischt keine Werte aus früheren Paper-Tabellen oder anderen Leaderboards.

Die Schlussfolgerung gilt nur für diese OmniDocBench-Version: Die Model-Größe allein sagt den Score beim Document Parsing nicht voraus.

Das Begleit-Notebook berechnet CER, WER, ANLS, Latency und geschätzte Kosten anhand seiner fünf heruntergeladenen Samples. Schließe die falsch bezeichnete Gemini-Zeile aus, sofern die Model-Identität nicht korrigiert und die Samples nicht erneut ausgeführt werden.

OCR in der Produktion deployen

!!! byte „Byte sagt“

Ich habe der eingebetteten Textebene eines PDF-Batches vertraut. Jedes Zeichen war korrekt – aber in der falschen Reihenfolge. Dadurch wurde jede Tabelle zu Unsinn.

Eine Tiered Architecture kann CPU-Preprocessing von GPU- oder API-Inference trennen und teure Pfade für Dokumente reservieren, die sie tatsächlich benötigen.

Hinweis zur Orchestration: Tools wie Docling können Konvertierung und Batch-Processing koordinieren. Die Retry-Policy gehört weiterhin in die umgebende Application oder den Service. Auch Routing braucht eigene Qualitätslabels und Thresholds.

Das Tiered-Fallback-Pattern

Beginne mit dem günstigsten Pfad, der das Qualitätsziel erreicht, und kalibriere das Routing anhand gelabelter Seiten:

0. Prüfe auf eingebetteten Text (Tier 0). Bei PDFs solltest du die Textebene vor der Rasterization mit PyMuPDF oder pdfplumber untersuchen und anschließend validieren, dass sie vollständig und korrekt geordnet ist.
1. Versuche es mit einem schnellen Model. Verwende eine klassische Engine für Dokumentklassen, bei denen sie das Ziel erreicht.
2. Evaluiere kalibrierte Confidence. Kombiniere die Model-Confidence mit Dokumentklasse, Kritikalität des Felds und Validierungsregeln.
3. Eskaliere zu einem stärkeren Model. Route unsichere Seiten an ein spezialisiertes oder allgemeines VLM.
4. Eskaliere risikoreiche Fehler an einen Menschen. Human Review ist ein separates Tier für Werte, bei denen die Fehlerkosten den Automatisierungsvorteil übersteigen.

Hinweis zur Confidence: Rohe Zeichenwahrscheinlichkeiten sind nicht automatisch auf die Korrektheit von Feldern kalibriert. Die folgende flächengewichtete Funktion ist eine Baseline für die Aggregation auf Seitenebene, kein universeller Router. Kalibriere sie gegen gelabelte Seiten und gib kritischen Feldern eigene Regeln, weil ein Seitenmittelwert eine falsche ID oder Summe verbergen kann.

def area_weighted_confidence(page):
    """Compute area-weighted confidence from a PaddleOCR 3.x result."""
    total_area, weighted_sum = 0, 0
    for (x_min, y_min, x_max, y_max), score in zip(
        page["rec_boxes"], page["rec_scores"]
    ):
        area = (x_max - x_min) * (y_max - y_min)
        weighted_sum += score * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

Kostenanalyse im großen Maßstab

Zwischen einer API und Self-Hosting gibt es keinen universellen Break-even bei einem bestimmten Seitenvolumen. Erstelle den Vergleich anhand desselben Workloads:

Verwende eine gemeinsame Formel: monthly pages × cost per successful page + review cost + fixed operating cost. Eine „erfolgreiche Seite“ muss auf beiden Pfaden dieselben Text-, Tabellen- und Feldkriterien erfüllen. Provider-Preise und GPU-Mieten ändern sich zu schnell, um sie als dauerhafte Beschaffungsschätzung einzubetten.

Fehlerbehandlung: Das Hallucination-Problem

VLM-Fehler können kontextuell plausibel und faktisch falsch sein. Aus einer Rechnungssumme von „$42.50“ könnte „$45.20“ werden: syntaktisch valide, aber für eine Rechtschreibprüfung unsichtbar.

Synthetisches Fehlerbeispiel: Ein VLM extrahiert drei Positionen eines Belegs und eine angegebene Gesamtsumme, die miteinander übereinstimmen, während sich eine Ziffer vom Bild unterscheidet. Die interne Arithmetik ist erfolgreich, obwohl die Extraktion falsch ist. Deshalb braucht die Validierung bildgestützte Labels oder einen unabhängigen Prüfpfad und nicht nur Konsistenzprüfungen.

Einige praktische Maßnahmen:

• Arithmetischer Abgleich. Wenn das Schema die entsprechenden Felder bereitstellt, prüfe subtotal + tax + fees + shipping - discounts innerhalb der Rundungstoleranz der Währung gegen die angegebene Gesamtsumme. Leite fehlende Komponenten oder Abweichungen zur Prüfung weiter.
• Regex-Sanity-Checks für Datumsangaben (kein Monat 13), Telefonnummern (korrekte Ziffernanzahl) und Währungsformate.
• Cross-Model-Verifikation. Verarbeite kritische Felder durch zwei unterschiedliche Models und markiere Abweichungen.
• Unabhängiger OCR-Cross-Check. Führe für kritische Zahlen einen zweiten Extraktionspfad aus und markiere Abweichungen. Übereinstimmung erhöht die Confidence nur dann, wenn sich die Failure Modes der beiden Pfade ausreichend unterscheiden. Sie ist kein Beweis für Korrektheit.

Die wichtigsten Erkenntnisse

1. Ordne das Model-Tier einer gelabelten Dokumentklasse zu. Klassische Engines können für sauberen Text ausreichen; spezialisierte und allgemeine VLMs sollten ihre zusätzlichen Kosten auf schwierigeren Seiten rechtfertigen.
2. Führe unterschiedliche Leaderboards nicht zusammen. OmniDocBench-Metriken und OCR-Arena-Präferenzen beantworten unterschiedliche Fragen.
3. Kalibriere das Routing. Confidence-Thresholds, Dokumentklassen, Feldkritikalität und Human-Review-Policy gehören in eine gemeinsame Evaluation.
4. Validiere plausible Outputs. Schema-Konformität und interne Arithmetik können nicht beweisen, dass ein Wert im Bild vorkommt.
5. Bepreise erfolgreiche Seiten. Beziehe Retries, Review, fixe Betriebskosten und Quality Gates in den Vergleich von APIs und Self-Hosting ein.

Preprocessing und Detection bleiben wichtig, aber OCR in der Produktion erfordert inzwischen auch Routing, aufgabenspezifische Evaluation und Schutzmaßnahmen gegen plausible Extraktionsfehler.

Referenzen

• OCR Arena Leaderboard – Crowdsourced Head-to-Head-Model-Battles
• The OCR Gauntlet Repo – Ausführbare Notebooks zum Vergleich von OCR-Engines, zur Untersuchung von Docling-Output und zur Kostenschätzung
• OmniDocBench – End-to-End-Eval für Document Parsing
• dots.ocr – Rund 3B Parameter insgesamt, darunter ein 1,7B Language Model
• PaddleOCR – Klassisches OCR-Toolkit und Models
• OpenRouter – Einheitliches Access-Gateway für A/B-Tests von Models