2026-03-04 · Aktualisiert 2026-07-15

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Der umfassende Leitfaden zu OCR im Jahr 2026: Vom Pipelines bis zum VLMs

OCR Die Leaderboards weichen voneinander ab, da sie unterschiedliche Dokumente sowie Ausgaben prüfen. Judges. Ein frühes 2026 Snapshot von OmniDocBench und OCR Arena erzeugte deutlich unterschiedliche Ergebnisse. Model Die Reihenfolgen sind festgelegt: Die Scores sind nicht austauschbar, doch die Abweichungen sind nützlich. Eine Entscheidung für die Produktion erfordert Dokumente sowie Metriken aus der tatsächlichen Arbeitslast.

Vision-Language Models (VLMs) ist in der Lage, Layouts, Handschrift, Tabellen sowie beschädigte Bilder zu verarbeiten – Faktoren, die eine herkömmliche Texterkennung Pipeline behindern. Traditionelle Systeme bleiben bei sauber gedruckten Inhalten konkurrenzfähig, insbesondere dann, wenn CPU Latency sowie die Betriebskosten eine Rolle spielen. Spezialisierte Models wie Punkte.ocr Die allgemeinen VLMs belegen die mittleren und oberen Ebenen und weisen unterschiedliche Kompromisse hinsichtlich Hardware, Datenschutz sowie Qualität auf.

Herkömmliche Engines bleiben die schnellste und günstigste Option für sauber gedruckte Dokumente. Kein Model ist in jedem Szenario überlegen, weshalb dieser Leitfaden von der Bewertung über die Auswahl von Model schließlich zur Implementierung in der Produktion Deployment führt.

Zusatz-Repository: Der OCR Gauntlet — eine Demonstration in einem einzigen Notebook, die fünf Dokumenttypen in drei Model Ebenen (Tesseract → dots.ocr → Gemini 3 Flash) vergleicht, um die starken Unterschiede in der Qualität sowie die damit verbundenen Kostenaufwände aufzuzeigen.

TL;DR: Beginnen Sie damit, nach einer eingebetteten Textschicht zu suchen. Benchmark einen herkömmlichen Motor für saubere Scans einzusetzen und anschließend nur für Dokumenttypen, die das Qualitätsziel nicht erreichen, einen spezialisierten oder allgemeinen VLM hinzuzufügen. Vergleichen Sie die Metriken für Text, Tabellen und Felder getrennt voneinander und leiten Sie Felder mit geringem Vertrauensgrad oder hohem Risiko an einen anderen Model oder einen Menschen weiter.

OCR legt nun die Qualität der nachgelagerten Komponenten fest

OCR wird seit Langem zur Unterstützung von Archiven, Postsystemen, Barrierefreiheitstools sowie Dokumentenverwaltungssystemen eingesetzt. Durch RAG und die Agents werden die Fehlermöglichkeiten für eine breitere Gruppe von Ingenieuren sichtbar – ein nachgeschalteter Model kann den Text oder die Tabellstruktur nicht wiederherstellen, da diese bereits bei der Extraktion entfernt wurden.

Die Retrieval-Qualität Ihres RAG-Systems wird durch die Qualität der OCR begrenzt. Wenn die Extraktion eine Tabelle verfälscht, ein Datum falsch interpretiert oder einen Absatz weglässt, können spätere Chunking- und Embedding-Anpassungen die fehlenden Informationen nicht wiederherstellen. Derselbe Fehler kann außerdem eine Vertragsklausel verbergen, die Gesamtsumme einer Rechnung ändern oder medizinische Aufzeichnungen beschädigen. OCR-Fehler wirken sich auf alle nachfolgenden Entscheidungen aus.

OCR ist daher Teil der Infrastruktur von Retrieval und Agent – genauso wie Parsing, Chunking, Embedding sowie Indexierung. Die damit verbundenen Fehler müssen separat bewertet werden, anstatt in eine einzige Gesamtbewertung eingeflossen zu sein.

Was OCR im Zeitalter von Foundation Models bedeutet

OCR hat seine ursprüngliche Definition „Gedruckter Text in maschinenlesbare Zeichen umwandeln“ weit übertroffen. Heute handelt es sich dabei um Dokumentintelligenz: das Extrahieren von Text, Struktur, Tabellen, Formeln sowie semantischem Inhalt aus beliebigen visuellen Eingaben. Der Bereich entwickelt sich von „OCR-1.0“ (modulare Pipelines) hin zu „OCR-2.0“, wobei dort ein end-to-end Model alle Phasen abdeckt.

Der herkömmliche OCR Pipeline weist drei zentrale Phasen auf:

1. Texterkennung: Lokalisierung von Bereichen, die Text enthalten (z. B. CRAFT, DBNet).
2. Textverarbeitung: Umwandlung der erkannten Bereiche in Zeichensequenzen (z. B. CRNN).
3. Nachbearbeitung: Rechtschreibprüfung sowie Korrektur der Sprache Model.

Dies funktioniert gut bei sauberen Dokumenten, doch Fehler bei der Erkennung, dem Auslesen sowie der Nachverarbeitung können sich gegenseitig verstärken. Messen Sie sowohl die Genauigkeit der Zeichen als auch die Genauigkeit der daraus generierten Felder, damit eine lesbare Seite keine falschen Gesamtwerte oder Identifikatoren verbergen kann.

OCR-2.0 fokussiert sich stärker darauf, einen Großteil von Pipeline in einen Vision-Encoder sowie einen Sprachdecoder zusammenzufassen. Models-Modelle wie GOT-OCR 2.0 können Text und Struktur gleichzeitig erzeugen, während allgemeine VLMs-Modelle außerdem Felder auf ein angefordertes Schema abbilden können. Die Abwägungen betreffen die arbeitslastbezogenen Latency-Kosten, GPU-Kosten oder API-Kosten sowie das Risiko plausibler Texte, die im Bild nicht vorhanden sind.

Praktische Einschränkung: Lassen Sie sich vom „End-to-End“-Label nicht täuschen. In der Produktion ist OCR-2.0 lediglich in der Erkennungsphase vereinheitlicht. Um Bilder zu erzeugen, ist weiterhin eine Rasterisierung des PDFs erforderlich, außerdem eine Normalisierung der Bilder (Kippkorrektur, DPI-Anpassung) zur Gewährleistung konstanter Qualität sowie eine Auswertung der Ausgabe, um strukturierte Felder aus dem Text von Model extrahieren zu können. Der Pipeline ist kürzer geworden – aber nicht verschwunden.

Was OCR Benchmarks erfasst und was nicht

Die folgenden Datasets veranschaulichen, wie unterschiedliche OCR-Aufgaben zu verschiedenen Metriken führen. Die Werte werden Snapshots gemäß ihren jeweiligen Leaderboards ermittelt und nicht auf der Grundlage einer aktuellen, cross-Dataset basierenden Rangliste.

Die Lücke zwischen „Benchmark“ und Arena

Automatisierte Ranglisten basierend auf Benchmark können mit menschlichen Präferenzen kollidieren, da sich die Eingabedistribution sowie die Bewertungskriterien unterscheiden.

Im Frühjahr 2026 OCR Arena Der hier verwendete Snapshot ermöglichte es den Nutzern, blind über die Ergebnisse von direkten Vergleichen abzustimmen. Die Reihenfolge dieser Ergebnisse unterschied sich dabei von OmniDocBench. Die beiden Tabellen sollten nicht zu einem einzigen Score zusammengeführt werden, da die eine Dataset-Metriken verwendet und die andere Präferenzstimmen.

Zu den wahrscheinlichen Einflussfaktoren gehören die Dokumentmischung, die Ausgabeformatierung, die Sprachabdeckung sowie die Kriterien von Judge. Veröffentlichte Zahlen sind nützlich zur ersten Filterung, doch für die endgültige Auswahl ist ein aus dem Zielarbeitsaufwand ausgeklammertes Testset erforderlich.

Traditionelle OCR-Engines: weiterhin relevant

Wenn herkömmliche Engine bei komplexen Daten schlechter abschneiden, warum werden sie dann verwendet? Weil sie bei sauberen, strukturierten Daten schnell und günstig sind.

Tesseract für saubere Ausdrucke

Tesseract (v5.5.x, Apache 2.0) ist ein ausgereifter Engine, der ausschließlich CPU verwendet und über mehr als 100 Sprachpakete verfügt. Bei angemessener Rasterisierung und Vorverarbeitung kann die Genauigkeit bei sauber gedruckten Texten sehr hoch sein; Handschriften, Texte in unruhigen Umgebungen sowie komplexe Layouts erfordern jedoch gesonderte Tests. Sein Hauptvorteil liegt in einer kompakten, lokalen CPU Deployment, anstatt in einer allgemeinen Überlegenheit hinsichtlich der Genauigkeit.

EasyOCR

EasyOCR kombiniert einen CRAFT-Detektor mit einem CRNN-Recognizer. Dank vollständiger PyTorch GPU-Beschleunigung stellt es eine schnelle Lösung für das schnelle Erstellen von Prototypen sowie die Erfassung von Texten in Szenen dar.

import easyocr

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

PaddleOCR

PaddleOCR (PP-OCRv5) bietet Funktionen zur Erkennung von Paketen sowie zur Identifizierung und Verwaltung von Deployment-Komponenten. Laut der Dokumentation wird eine Unterstützung für mehr als 106 Sprachen angegeben, außerdem steht eine kleine mobile Model-Version für den Einsatz an peripheren Geräten zur Verfügung. Überprüfen Sie die genaue Qualität des Model-Artikels sowie der Sprachunterstützung für die ausgewählte Version.

from paddleocr import PaddleOCR

ocr = PaddleOCR(use_angle_cls=True, lang="en")
result = ocr.ocr("receipt.jpg", cls=True)

for line in result[0]:
    bbox, (text, confidence) = line
    if confidence > 0.85:
        print(f"{text} ({confidence:.2f})")

Spezialisierte und allgemeine VLM-Optionen

Krumme Quittungen, verzerrte Produktetiketten, Handschrift sowie dichte Layouts sind genau die Fälle, in denen spezialisierte oder allgemeine VLMs-Systeme im Vergleich zu herkömmlichen Verarbeitungsalgorithmen einen Test wert sind.

Die spezialisierte OCR-Welle

Spezialisierte Dokumentanalyse-Models-Tools, die im Zeitraum 2025–2026 veröffentlicht werden, umfassen:

• Punkte.ocr (1,7 Mrd.): Ein Open-Source-Model, der die Erkennung von Layouts, die Erkennung von Zeichen sowie die Bestimmung der Lesereihenfolge vereint. Sein Bericht umfasst mehr als 100 Sprachen und bietet hohe Genauigkeit. OmniDocBench Ergebnisse.
• GOT-OCR 2.0: Ein mit 580 M Parametern ausgestatteter einheitlicher Model, der auf einem einzigen Consumer GPU (~4 GB VRAM) läuft und Markdown-, LaTeX- sowie strukturierte Ausgabeformate erzeugt.
• DeepSeek-OCR (3B): Integriert eine „kontextbasierte optische Kompression“, um die visuelle Tokens zu verringern. Die dazugehörigen Throughput-Werte sind hardware- und Dataset-spezifisch zu betrachten.
• Mistral OCR v3: Ein proprietäres Service zur Extraktion von Text und Struktur. Da sich die Preise sowie die Benchmark-Werte ändern können, sollten Sie bei der Vergleichstätigkeit stets die aktuellen Model-Konditionen sowie die Bedingungen des Anbieters prüfen.

Frontier VLMs

Allgemeine VLMs sind eine weitere Option, wenn die Aufgabe die Extraktion mit visuellen oder semantischen Reasoning verbindet. Die untenstehenden Beispiele spiegeln den Stand des Artikels aus dem frühen Jahr 2026 unter Berücksichtigung von Snapshot wider und nicht die aktuelle Rangliste.

• Qwen3-VL (Alibaba): Eine offene Weight VLM-Familie mit verschiedenen Größen sowie Varianten für den Umgang mit langen Kontexten.
• Gemini 3 Flash (Google): Ein gehosteter multimodaler Model, der in der genannten OCR Arena Snapshot eine sehr hohe Platzierung erzielte.
• Claude Opus 4.6 (Anthropic): Ein gehosteter allgemeiner VLM mit Unterstützung für strukturierte Ausgaben.
• GPT-5.2 (OpenAI): Ein gehosteter allgemeiner VLM zur Verarbeitung gemischter visueller und textbasierter Eingaben.

Latency nach Ebene

Die unten aufgeführten Bereiche sind Planning-Platzhalter. Messen Sie sie erneut unter Berücksichtigung der tatsächlichen Seitenauflösung, der Batch-Größe, der Hardware sowie der Region des Anbieters und der Ausgabellänge:

Metriken: Messung der relevanten Größen

Wählen Sie einen Metrikenwert aus, der zum Ausgabetyp passt:

• CER und WER für reinen Text. Die Fehlerraten pro Zeichen und Wort hängen von den Normalisierungsentscheidungen wie Groß-/Kleinschreibung, Leerzeichen und Satzzeichen ab; daher sollte das Vergleichsprotokoll vor dem Vergleich von Models angepasst werden.
• EMR und Field F1 für Formulare und Quittungen. Die Genauigkeitsrate ist binär, was für Steuernummern und Gesamtbeträge erforderlich ist. Field F1 gewährleistet eine angemessene Balance zwischen Präzision und Erinnerung je nach Feldtyp.
• TEDS für Tabellen. Der Baum-Edit-Distanz-Berechnung über HTML-Baumdarstellungen liegen fehlerhafte Ausrichtungen von Zellen mehrerer Ebenen zugrunde, die durch CER übersehen werden.
• ANLS für Dokument-VQA. Die durchschnittliche normalisierte Levenshtein-Similarity gewährt Teilpunkte für Antworten mit geringfügigen OCR-Fehlern.

Für Implementierungen: jiwer verarbeitet CER/WER direkt aus der Box, wobei die TEDS-Implementierungen in der Repo OmniDocBench.

Testen von VLMs mit OpenRouter

OpenRouter Es stellt einen mit OpenAI kompatiblen Gateway zu Models über mehrere Anbieter bereit. Die IDs der Model sowie die unterstützten Anfruffunktionen können sich ändern; daher sollten Sie diese vor dem Ausführen des Beispiels im aktuellen Katalog des Gateways überprüfen.

import base64
from openai import OpenAI

client = OpenAI(base_url="https://openrouter.ai/api/v1", api_key="your-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", "anthropic/claude-sonnet-4.5", "qwen/qwen3-vl-8b"]
for model in models:
    print(f"\n--- {model} ---\n{extract_text('receipt.jpg', model)[:200]}...")

Für die strukturierte Extraktion wird verwendet response_format mit einem JSON schema, sofern der ausgewählte Model sowie das Gateway dies unterstützen. Dadurch wird die Antwort parsierbar, wobei die extrahierten Werte jedoch nicht gegen das Bild überprüft werden:

import json

response = client.chat.completions.create(
    model="google/gemini-3-flash",
    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",
            "schema": {
                "type": "object",
                "properties": {
                    "vendor": {"type": "string"},
                    "date": {"type": "string"},
                    "items": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": "string"},
                                "amount": {"type": "number"},
                            },
                        },
                    },
                    "total": {"type": "number"},
                },
            },
        },
    },
)
receipt = json.loads(response.choices[0].message.content)

Benchmark Ergebnisse: Was die Zahlen tatsächlich zeigen

Die untenstehende Tabelle ist ein veraltetes Snapshot aus dem Leaderboard von OmniDocBench und Punkte. ocr, Paper (arXiv:2512.02498). Es vergleicht die in dieser Bewertung gemeldeten Ergebnisse und nicht die aktuellen Model-Versionen:

In diesem Snapshot erzielen PaddleOCR-VL sowie die entsprechenden ocr-Modelle eine höhere Bewertung als die aufgelisteten allgemeinen VLMs-Methoden. Die Schlussfolgerung beschränkt sich auf OmniDocBench: Allein die Model-Größe reicht nicht aus, um die Leistung bei der Dokumentanalyse vorherzusagen.

🔧 Ausführen Sie es selbst: Der OCR Gauntlet Es handelt sich um ein einziges, ausführbares Notebook, das fünf verschiedene Dokumenttypen (reine Rechnung, zerknitterter Beleg, handschriftliches Formular, wissenschaftlicher Artikel sowie mehrsprachiges Dokument) auf drei verschiedenen Ebenen prüft – von Tesseract über dots.ocr bis hin zu Gemini 3 Flash – und dabei die CER- sowie EMR-Werte nebeneinander mit einer Kostenanalyse darstellt.

Einsatz von OCR in der Produktion

Eine schichtbasierte Architektur ermöglicht es, die Vorausverarbeitung von CPU von GPU oder API Inference zu trennen und ressourcenintensive Verarbeitungswegen für Dokumente bereitzuhalten, die sie benötigen.

Hinweis zu Orchestration: Werkzeuge wie Docling ermöglichen die Koordination von Konvertierungen, Gruppierung in Batches sowie automatischen Wiederholungsversuchen. Für die Routing-Politik sind weiterhin eigene Qualitätslabels und Schwellenwerte erforderlich.

Das schichtbasierte Fallback-Muster

Beginnen Sie mit dem günstigsten Weg, der das Qualitätsziel erfüllt, und kalibrieren Sie anschließend Routing an den beschrifteten Seiten:

0. Prüfung auf eingebetteten Text (Ebene 0). Bei PDFs wird die Textschicht überprüft. PyMuPDF oder pdfplumber vor dem Rasterisieren muss überprüft werden, ob die Schicht vollständig ist und in der richtigen Reihenfolge vorliegt.
1. Versuchen Sie es mit einem schnellen Model. Verwenden Sie einen herkömmlichen Motor für Dokumentklassen, bei denen dieser ausreicht.
2. Bewerten Sie das kalibrierte Vertrauensniveau. Kombinieren Sie das Vertrauensniveau von Model mit der Dokumentklasse, der Kritikalität des Feldes sowie den Validierungsregeln.
3. Weiterleiten Sie den Vorgang an einen leistungsstärkeren Model. Leiten Sie unsichere Seiten an einen spezialisierten oder allgemeinen VLM weiter.
4. Leiten Sie fehleranfällige Fälle mit hohem Risiko an einen Menschen weiter. Eine menschliche Überprüfung ist erforderlich, wenn der Fehlerkosten bei bestimmten Werten die Vorteile der Automatisierung übersteigen.

Hinweis zur Zuverlässigkeit: Die rohen Zeichenträgheitswerte sind nicht automatisch auf die Korrektheit im jeweiligen Feld kalibriert. Die unten dargestellte flächengewichtete Funktion dient lediglich als Grundlage für die Aggregation auf Seitenebene und stellt keine universelle Router dar. Kalibrieren Sie sie anhand von beschrifteten Seiten und legen Sie für kritische Felder eigene Regeln fest, da ein Durchschnittswert einer Seite einen fehlerhaften ID oder eine falsche Gesamtsumme verbergen kann.

def area_weighted_confidence(ocr_result):
    """Compute area-weighted confidence from PaddleOCR output."""
    total_area, weighted_sum = 0, 0
    for line in ocr_result[0]:
        bbox, (text, conf) = line
        width = bbox[1][0] - bbox[0][0]
        height = bbox[2][1] - bbox[1][1]
        area = abs(width * height)
        weighted_sum += conf * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

Kostenanalyse in großem Maßstab

Es existiert kein universeller Punkt der Gewinnschwelle hinsichtlich des Seitenvolumens zwischen einem API und der Selbsthostung. Die Vergleichbarkeit muss daher anhand derselben Arbeitslast hergestellt werden:

Verwenden Sie eine gemeinsame Formel: monthly pages × cost per successful page + review cost + fixed operating costEine „erfolgreiche Seite“ muss an beiden Pfaden die gleichen Kriterien hinsichtlich Text, Tabellen und Feldern erfüllen. Die Preise der Anbieter sowie die Mieten für GPU ändern sich zu schnell, um als zuverlässige Schätzung für Beschaffungsentscheidungen verwendet werden zu können.

Fehlerbehandlung: Das Problem mit Hallucination

VLM-Fehler können im Kontext plausibel erscheinen, aber faktisch falsch sein. Eine Rechnungssumme von „$42,50“ könnte zu „$45,20“ werden: syntaktisch korrekt, doch für einen Rechtschreibprüfer unsichtbar.

Beispiel für eine synthetische Fehlerursache: Ein VLM extrahiert drei Posten aus der Rechnung sowie einen angegebenen Gesamtbetrag, die miteinander übereinstimmen, weisen im Vergleich zum Bild jedoch eine unterschiedliche Stelligkeit auf. Obwohl die Extraktion fehlerhaft ist, verlaufen die internen Berechnungen korrekt. Aus diesem Grund benötigt die Validierung bildbasierte Labels oder einen unabhängigen Überprüfungsprozess – und nicht nur Konsistenzprüfungen.

Einige praktische Abhilfemöglichkeiten:

• Prüfung der Checksumme. Bei Rechnungen muss sichergestellt werden, dass die Beträge der einzelnen Posten zur angegebenen Gesamtsumme addieren, und Abweichungen müssen zur manuellen Überprüfung markiert werden.
• Regulärer Ausdruck zur Überprüfung von Datumsformaten (kein Monat 13), Telefonnummern (korrekte Anzahl an Ziffern) sowie Währungskodierungen.
• Vergleich der Posten mit den Gesamtbeträgen. Der aus dem VLM extrahierte Teilbetrag wird mit der unabhängig berechneten Summe der jeweiligen Posten verglichen.
• Doppelte Model-Überprüfung. Kritische Felder werden durch zwei verschiedene Models-Verfahren geprüft, wobei Abweichungen angezeigt werden.
• Unabhängige OCR-Kontrolle. Kritische Werte werden über einen zweiten Extraktionsweg überprüft, wobei Abweichungen markiert werden. Eine Übereinstimmung erhöht das Vertrauen nur dann, wenn die beiden Verfahren unterschiedliche Fehlermuster aufweisen; sie stellt jedoch kein Beweis für Richtigkeit dar.

Wichtige Erkenntnisse

1. Ordnen Sie das Model-Niveau einer benannten Dokumentklasse zu. Herkömmliche Engines reichen für sauberen Text aus; spezialisierte sowie allgemeine VLMs-Lösungen sollten ihren höheren Preis nur dann rechtfertigen, wenn sie mit schwierigeren Seiten konfrontiert werden.
2. Führen Sie nicht unterschiedliche Leaderboards zusammen. Die Metriken von OmniDocBench und die Einstellungen der OCR-Arena beantworten jeweils andere Fragestellungen.
3. Kalibrieren Sie den Routing-Wert. Konfidenzschwellenwerte, Dokumentklassen, Feldkritikalität sowie Richtlinien zur menschlichen Überprüfung müssen in einer einzigen Bewertung berücksichtigt werden.
4. Überprüfen Sie plausible Ausgaben. Schemakonformität sowie interne Berechnungen können nicht beweisen, dass ein Wert tatsächlich in dem Bild vorhanden ist.
5. Bewerten Sie erfolgreiche Seiten angemessen. Bei dem Vergleich von APIs mit selbst gehosteten Lösungen müssen Wiederholungsversuche, Überprüfungen, Korrekturmaßnahmen sowie Qualitätskontrollen berücksichtigt werden.

Die Vorkonvertierung und Erkennung spielen weiterhin eine wichtige Rolle, doch im Produktivumfeld erfordert OCR nun auch eine Routing-basierte, auf die jeweilige Aufgabe zugeschnittene Bewertung sowie Schutzmaßnahmen gegen plausibel erscheinende Extraktionsfehler.

Referenzen

• OCR Arenen-Rangliste - Von der Community gestützte, direkte Model-Kämpfe Der OCR Gauntlet-Repo - Ausführbares Notebook zur Überprüfung der dreistufigen OCR-Architektur
• OmniDocBench - End-zu-End-Dokumentparsing Eval Punkte.ocr - 1,7 Milliarden Parameter umfassender VLM-Dokumentparser PaddleOCR - Die herkömmlichen OCR-Toolkits und Models
• OpenRouter - Einheitliches Zugangsgateway für A/B-Testing Models