OCR in 2026: klassieke pipelines, VLMs en Document AI

Viacheslav Dubrov

2026-03-04 · Bijgewerkt 2026-08-10 · 13 min · Zoek- en taalsystemen

Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

OCR-leaderboards spreken elkaar tegen omdat ze verschillende documenten, outputs en judges testen. Een snapshot van OmniDocBench en OCR Arena uit begin 2026 leverde sterk verschillende modelrangschikkingen op; de scores zijn niet onderling uitwisselbaar, maar het meningsverschil is nuttig. Voor een production-keuze heb je documenten en metrics uit de daadwerkelijke workload nodig.

Vision-language models (VLMs) kunnen overweg met layout, handschrift, tabellen en gedegradeerde afbeeldingen die een eenvoudige text-recognition-pipeline laten falen. Traditionele engines blijven competitief op schone afdrukken, vooral wanneer CPU-latency en operationele kosten belangrijk zijn. De gedateerde snapshot hieronder bevat PaddleOCR-VL 1.6 en dots.mocr, met verschillende trade-offs op het gebied van hardware, privacy en output. Controleer elk project voordat je een actuele keuze maakt.

Companion repo: The OCR Gauntlet bevat drie notebooks. Het hoofdnotebook vergelijkt maximaal vijf OCR-engines op vijf gedownloade samples en rapporteert CER, WER, ANLS, latency en geschatte kosten. De ingecheckte run bevat Tesseract, Docling + Tesseract, Mistral OCR v3 en een Gemini-run; dots.ocr was niet beschikbaar. Gebruik de Gemini-rij niet voor modelvergelijkingen: de runner vraagt gemini-2.5-flash aan, maar het ingecheckte notebook labelt die output als Gemini 3 Flash.

Deze guide is bedoeld voor engineers die een OCR- of document-AI-pipeline kiezen voor real-world workloads waarbij tekst, layout, tabellen of geëxtraheerde velden belangrijk zijn.

Na het lezen van deze guide moet je een baseline kunnen kiezen, models kunnen vergelijken op task-specifieke metrics en onzekere of risicovolle velden kunnen routeren naar validatie of review.

Zie voor de compacte versie over modelselectie Best OCR Models in 2026: Classical OCR, PaddleOCR-VL, VLMs.

OCR bepaalt nu de downstreamkwaliteit

OCR vormt al lange tijd de basis voor archieven, postsystemen, accessibility-tools en documentmanagement. RAG en document agents maakten de failure modes ervan zichtbaar voor een bredere groep engineers: een downstream model kan tekst of tabelstructuur die tijdens extractie verloren is gegaan niet herstellen.

De retrievalkwaliteit van je RAG-systeem wordt begrensd door de OCR-kwaliteit. Als extractie een tabel verminkt, een datum verkeerd leest of een alinea weglaat, kunnen latere wijzigingen in chunking en embedding de ontbrekende informatie niet herstellen. Zulke fouten kunnen een contractclausule verbergen, een factuurtotaal wijzigen of een medisch dossier aantasten.

OCR maakt daarom deel uit van retrieval- en agentinfrastructuur, naast parsing, chunking, embedding en indexing. De fouten ervan moeten afzonderlijk worden geëvalueerd, in plaats van te worden opgenomen in één end-to-end-score.

Wat OCR betekent in het tijdperk van foundation models

OCR zet tekst in een afbeelding om in machineleesbare tekens. Document AI is het bredere systeem eromheen: layout analysis, parsing van tabellen en formules, field extraction, semantic reasoning, provenance en validatie. Sommige papers gebruiken “OCR-2.0” voor end-to-end models die verschillende van deze stages combineren, maar dat label mag het onderscheid tussen recognition en document understanding niet uitwissen.

De traditionele OCR-pipeline heeft drie kernstages:

1. Text detection: lokaliseer regio’s die tekst bevatten (bijvoorbeeld CRAFT, DBNet).
2. Text recognition: zet gedetecteerde regio’s om in character sequences (bijvoorbeeld CRNN).
3. Post-processing: spell-checking en correctie met een language model.

Dit werkt goed voor schone documenten, maar fouten in detection, recognition en post-processing kunnen zich opstapelen. Meet zowel character accuracy als downstream field accuracy, zodat een leesbare pagina geen verkeerd totaal of verkeerde identifier verbergt.

OCR-2.0 brengt een groter deel van die pipeline onder in een vision encoder plus language decoder. Models zoals GOT-OCR 2.0 kunnen tekst en structuur tegelijk uitsturen, terwijl algemene VLMs ook fields naar een gevraagd schema kunnen mappen. De trade-offs zijn workload-specifieke latency, GPU- of API-kosten en het risico op plausibele tekst die niet in de afbeelding voorkomt.

Praktische kanttekening: laat je niet misleiden door het label “end-to-end”. In production verenigt OCR-2.0 de model inference, niet de volledige documentpipeline. Je hebt nog steeds PDF-rasterization nodig om afbeeldingen te produceren, image normalization (deskew, DPI adjustment) voor consistente kwaliteit en output parsing om structured fields uit de tekst van het model te halen. De pipeline is korter geworden, niet verdwenen.

Wat OCR-benchmarks meten en missen

De volgende datasets illustreren hoe OCR-taken tot verschillende metrics leiden. Datasetgroottes en metrics beschrijven de genoemde datasetversie; gebruik de actuele leaderboard van elk project voor modelscores.

De kloof tussen “benchmark en arena”

Geautomatiseerde benchmarkrangschikkingen kunnen botsen met menselijke voorkeuren omdat de inputdistributie en beoordelingscriteria verschillen.

In de OCR Arena stemmen users blind op head-to-head outputs. Op 2026-08-09 plaatste de live ranking Gemini 3 Flash boven GLM-OCR en DeepSeek-OCR, terwijl de versiegebonden OmniDocBench-tabel later in dit artikel gespecialiseerde document models boven Gemini 3 Flash rangschikte. Arena-waarden veranderen na nieuwe battles, dus de rangschikking is directioneel bewijs en geen reproduceerbare benchmark-snapshot. De twee leaderboards mogen niet worden samengevoegd tot één score, omdat de ene datasetmetrics gebruikt en de andere preference votes.

Waarschijnlijke oorzaken zijn de documentmix, outputformattering, language coverage en judge-criteria. Gepubliceerde cijfers zijn nuttig voor screening, maar de uiteindelijke selectie vereist een held-out set uit de target-workload.

Traditionele OCR-engines: nog steeds relevant

Als traditionele engines slechter presteren op complexe data, waarom zou je ze dan gebruiken? Omdat ze snel en goedkoop zijn op schone, gestructureerde data.

Traditionele engines zijn nuttige baselines omdat ze lokaal op CPU kunnen draaien. Hun latency en accuracy hangen af van het gekozen model, de paginapresolutie, taal, preprocessing en hardware. Benchmark ze daarom op dezelfde gelabelde pagina’s die je voor VLM-evaluatie gebruikt.

Tesseract voor schone afdrukken

Tesseract (v5.5.x, Apache 2.0) is een volwassen, CPU-only engine met 100+ language packs. De accuracy op schone afdrukken kan hoog zijn na geschikte rasterization en preprocessing, maar handschrift, scene text en complexe layouts vereisen afzonderlijke tests. Het belangrijkste voordeel is een kleine, lokale CPU-deployment, niet een universele accuracy-lead.

EasyOCR

EasyOCR combineert een CRAFT-detector met een CRNN-recognizer. Met volledige PyTorch GPU-acceleratie is het een snelle optie voor rapid prototyping en scene text.

Het snippet vereist pip install easyocr, PyTorch, de gedownloade model weights van EasyOCR en een lokale receipt.jpg. Het is syntax-checked, maar wordt niet uitgevoerd door de Markdown-runner van de repository.

import easyocr

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

PaddleOCR 3

PaddleOCR 3 bundelt onderhouden OCR-, document-parsing- en deploymentpipelines. De huidige quick start gebruikt de predict()-API en expliciete orientation settings. Pin het paddleocr-package en de geselecteerde pipeline, omdat 2.x-voorbeelden met .ocr(..., cls=True) niet overeenkomen met de 3.x-API.

Het snippet vereist pip install "paddleocr>=3,<4", een compatibele PaddlePaddle-runtime, gedownloade model weights en een lokale receipt.jpg. Het is syntax-checked, maar wordt niet uitgevoerd door de Markdown-runner van de repository.

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")

Gespecialiseerde en algemene VLM-opties

Scheve receipts, gedraaide productlabels, handschrift en dense layouts zijn situaties waarin gespecialiseerde of algemene VLMs het waard worden om tegen traditionele engines te testen.

De golf van gespecialiseerde OCR

De modellijst in deze sectie is de snapshot die op 2026-08-09 is gecontroleerd. Het is geen actuele ranking. Gespecialiseerde modellen voor document parsing die tussen 2024 en 2026 zijn gepubliceerd, omvatten:

• PaddleOCR-VL 1.6: Een two-stage pipeline die layout analysis uitvoert en vervolgens een 0.9B VLM-component gebruikt op gedetecteerde regio’s. PaddleOCR rapporteert 109 talen en 96.3 op OmniDocBench v1.6; koppel dat vendorresultaat aan de genoemde pipeline en benchmarkversie.
• dots.mocr (3B): De opvolger uit maart 2026 van dots.ocr-1.5, die tekst en structured graphics parseert, inclusief een SVG-georiënteerde variant. Het oorspronkelijke dots.ocr blijft een afzonderlijk model uit 2025.
• GOT-OCR 2.0: Een unified model met 580M parameters dat plain text en geformatteerde outputs zoals Markdown en LaTeX produceert. De officiële repository publiceert geen minimale VRAM-waarde. Meet daarom het piekgeheugen met de gekozen runtime, precision, afbeeldingsgrootte en outputlimiet.
• DeepSeek-OCR2: Het checkpoint dat op de snapshotdatum in de officiële repository is gedocumenteerd en de oorspronkelijke 3B-klasse DeepSeek-OCR opvolgt, het model dat “contextual optical compression” introduceerde. Behandel throughputcijfers voor beide generaties als hardware- en dataset-specifiek.
• Mistral OCR 4.0 (mistral-ocr-4-0), snapshot 2026-08-09: De proprietary text-and-structure extraction service die door Mistral is gedocumenteerd. OCR 3 (mistral-ocr-2512) blijft beschikbaar voor bestaande integraties en is de versie die door het companion notebook wordt gebruikt. Het companion gebruikt OCR 3 bewust voor reproduceerbaarheid, niet omdat OCR 3 nieuwer is. Pricing en benchmarkcijfers veranderen, dus controleer de actuele model card en de voorwaarden van de provider wanneer je ze vergelijkt.

Frontier VLMs

Algemene VLMs zijn een andere optie wanneer de taak extractie combineert met visual of semantic reasoning. De voorbeelden hieronder weerspiegelen de snapshot van het artikel uit begin 2026, niet een actuele ranking:

• Qwen3-VL (Alibaba): Een open-weight VLM-familie met verschillende groottes en long-context-varianten.
• Gemini 3 Flash (Google): Een hosted multimodaal model dat hoog eindigde in de genoemde OCR Arena-snapshot.
• Claude Opus 4.6 (Anthropic): Een hosted algemene VLM met structured-output-ondersteuning.
• GPT-5.2 (OpenAI): Een hosted algemene VLM voor gecombineerde visuele en tekstuele inputs.

Meet latency per tier

Meet page latency met de werkelijke resolutie, batchgrootte, hardware of providerregio en outputlengte. Neem preprocessing en retries mee in het totaal; timing van alleen het model zegt niets over de kosten van een succesvol verwerkte pagina.

Metrics: meten wat ertoe doet

Kies een metric die past bij het outputtype:

• CER en WER voor plain text. Character en Word Error Rate hangen af van normalisatiekeuzes zoals hoofdletters, whitespace en interpunctie. Leg daarom eerst het vergelijkingsprotocol vast voordat je models vergelijkt.
• EMR en Field F1 voor forms en receipts. Exact Match Rate is binair, wat je wilt voor tax IDs en totals. Field F1 balanceert precision en recall per field type.
• TEDS voor tabellen. Tree-Edit-Distance-based Similarity vergelijkt voorspelde en referentie-HTML-trees en detecteert structurele fouten en fouten in celinhoud die CER verbergt.
• ANLS voor document VQA. Average Normalized Levenshtein Similarity geeft gedeeltelijke credit voor antwoorden met kleine OCR-fouten.

Voor implementaties: jiwer ondersteunt CER/WER out of the box en TEDS-implementaties staan in de OmniDocBench-repo.

VLMs testen met OpenRouter

OpenRouter biedt een OpenAI-compatible gateway naar models van verschillende providers. Model-ID’s en ondersteunde requestfeatures veranderen, dus verifieer ze tegen de actuele catalogus van de gateway voordat je het voorbeeld uitvoert.

Het snippet vereist pip install openai, een OPENROUTER_API_KEY, netwerktoegang, een lokale receipt.jpg en model-ID’s die nog door OpenRouter worden ondersteund. Het is syntax-checked, maar wordt niet uitgevoerd door de Markdown-runner van de repository.

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]}...")

Deze model-ID’s zijn op 2026-08-09 gecontroleerd tegen de catalogus van OpenRouter. Controleer de catalogus opnieuw voordat je het voorbeeld uitvoert.

Gebruik voor structured extraction response_format met een JSON Schema wanneer het geselecteerde model en de gateway dit ondersteunen. Dit kan het antwoord parsebaar maken; het valideert de geëxtraheerde waarden niet tegen de afbeelding. Het volgende block herhaalt de setup zodat het zelfstandig leesbaar is. Het vereist nog steeds pip install openai, een OPENROUTER_API_KEY, netwerktoegang, een lokale receipt.jpg en een model dat JSON Schema ondersteunt; de repository-runner voert alleen syntax-checking uit.

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)

Benchmarkresultaten: wat de cijfers werkelijk laten zien

De onderstaande tabel is één versiegebonden snapshot: OmniDocBench v1.6_full, officiële README op commit 09ba2b606662695b16aafe5f5e36b7ef020e11a8, gepubliceerd op 2026-04-10 en geraadpleegd op 2026-08-09. Alle vier rijen komen uit die gepinde tabel. De tabel combineert geen waarden uit eerdere paper-tabellen of andere leaderboards.

De conclusie is beperkt tot deze OmniDocBench-versie: modelgrootte alleen voorspelt niet de score voor document parsing.

Het companion notebook berekent CER, WER, ANLS, latency en geschatte kosten op de vijf gedownloade samples. Sluit de verkeerd gelabelde Gemini-rij uit, tenzij de modelidentiteit wordt gecorrigeerd en de samples opnieuw worden uitgevoerd.

OCR deployen in production

Een tiered architecture kan CPU-preprocessing scheiden van GPU- of API-inference en dure paden reserveren voor documenten die dat nodig hebben.

Opmerking over orchestration: Tools zoals Docling kunnen conversie en batch processing coördineren. Het retrybeleid hoort nog steeds in de omringende applicatie of service thuis, en routing heeft eigen quality labels en thresholds nodig.

Het tiered fallback-patroon

Begin met het goedkoopste pad dat de quality target haalt en kalibreer routing vervolgens op gelabelde pagina’s:

0. Controleer op embedded text (Tier 0). Inspecteer voor PDF’s de text layer met PyMuPDF of pdfplumber voordat je gaat rasterizen, maar valideer dat de layer compleet en correct geordend is.
1. Probeer een snel model. Gebruik een traditionele engine voor documentklassen waarvoor deze de target haalt.
2. Evalueer calibrated confidence. Combineer model confidence met documentklasse, field criticality en validatieregels.
3. Escalate naar een sterker model. Routeer onzekere pagina’s naar een gespecialiseerde of algemene VLM.
4. Escalate high-risk failures naar een human. Human review is een afzonderlijke tier voor waarden waarvan de kosten van een fout groter zijn dan het automationvoordeel.

Opmerking over confidence: Raw character probabilities zijn niet automatisch calibrated voor field correctness. De area-weighted functie hieronder is een baseline voor aggregatie op paginaniveau, geen universele router. Kalibreer deze tegen gelabelde pagina’s en geef kritieke velden eigen regels, omdat een paginagemiddelde een verkeerde ID of een verkeerd totaal kan verbergen.

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 op schaal

Er bestaat geen universeel break-evenpunt op basis van page volume tussen een API en self-hosting. Bouw de vergelijking op vanuit dezelfde workload:

Gebruik een gedeelde formule: monthly pages × cost per successful page + review cost + fixed operating cost. Een “succesvolle pagina” moet op beide paden aan dezelfde tekst-, tabel- en fieldcriteria voldoen. Providerprijzen en GPU-rentals veranderen te snel om ze in een duurzame procurementschatting op te nemen.

Error handling: het hallucination-probleem

VLM-fouten kunnen contextueel plausibel en feitelijk onjuist zijn. Een receipttotaal van “$42.50” kan bijvoorbeeld “$45.20” worden: syntactisch geldig, maar onzichtbaar voor een spell-checker.

Synthetic failure example: Een VLM extraheert drie receipt line items en een opgegeven totaal die onderling overeenkomen, maar één digit verschilt van de afbeelding. De interne arithmetic klopt, terwijl de extraction toch fout is. Daarom heeft validatie image-grounded labels of een onafhankelijke review path nodig, niet alleen consistency checks.

Enkele praktische mitigaties:

• Arithmetic reconciliation. Wanneer het schema deze velden blootlegt, controleer je subtotal + tax + fees + shipping - discounts binnen de rounding tolerance van de valuta tegen het opgegeven totaal. Routeer ontbrekende componenten of mismatches naar review.
• Regex sanity checks voor datums (geen maand 13), telefoonnummers (correct aantal digits) en currency formats.
• Cross-model verification. Laat kritieke fields door twee verschillende models verwerken en markeer disagreements.
• Independent OCR cross-check. Voer een tweede extraction path uit voor kritieke cijfers en markeer disagreements. Agreement verhoogt confidence alleen wanneer de twee paden voldoende verschillende failure modes hebben; het is geen bewijs van correctheid.

Belangrijkste conclusies

1. Stem de modeltier af op een gelabelde documentklasse. Traditionele engines kunnen volstaan voor schone tekst; gespecialiseerde en algemene VLMs moeten hun extra kosten op moeilijkere pagina’s rechtvaardigen.
2. Voeg ongelijke leaderboards niet samen. OmniDocBench-metrics en OCR Arena-preferences beantwoorden verschillende vragen.
3. Kalibreer routing. Confidence thresholds, documentklassen, field criticality en het human-reviewbeleid horen in één evaluatie thuis.
4. Valideer plausibele output. Schema-conformiteit en interne arithmetic kunnen niet bewijzen dat een waarde in de afbeelding voorkomt.
5. Prijs succesvolle pagina’s. Neem retries, review, vaste operationele kosten en quality gates mee wanneer je APIs met self-hosting vergelijkt.

Preprocessing en detection blijven belangrijk, maar production OCR vereist nu ook routing, task-specifieke evaluatie en bescherming tegen plausibele extractiefouten.

Referenties

• OCR Arena Leaderboard - Crowdsourced head-to-head modelbattles
• The OCR Gauntlet repo - Uitvoerbare notebooks voor het vergelijken van OCR-engines, het inspecteren van Docling-output en het schatten van kosten
• OmniDocBench - End-to-end document-parsing-eval
• dots.ocr - Ongeveer 3B totale parameters, inclusief een language model van 1.7B
• PaddleOCR - Traditionele OCR-toolkit en models
• OpenRouter - Unified access gateway voor A/B-testing van models