← all posts
// ocr · ocr-models

OCR models for technical documents and labels: layout and reading order

Route every character through a deterministic, coordinate-aware OCR stage first. Let a generative or vision-language model touch a page only where it demonstrably earns its place, never as the entry point. That's the whole call.

Manuals, schematics, part labels stamped into curved metal, drawings with rotated callouts: the target is part numbers, warnings, measurements, symbols, and how each callout relates to its label. Lose that geometry and you lose the meaning. Capture fights you too: engraving, curved surfaces, low contrast, tiny fonts, line art, identifiers a digit apart. A vision-language model can untangle an ambiguous layout, or swap an uncertain character for smoother-sounding text. Fluent and wrong costs more than garbled. Garbled gets caught.

Coordinates first, confidence second

Start with high-resolution region OCR and dictionaries that validate format without auto-correcting identity: a part number that fails a checksum gets flagged, not rewritten. Bring in a generative or multimodal model only for handwriting, irregular layouts, cross-page field ties, and the exception queue once upstream gives up. It shouldn't replace what already works cheaply.

Test it like it matters: annotate multi-column layouts, sidebars, headers, footers, and page-spanning tables, then score structure separately from text, since nailing transcription doesn't guarantee correct order. Keep the source file untouched, assign every page an identifier, and log the chain end to end: file hash, capture device, preprocessing version, model, runtime, dictionaries, and what the recognizer saw kept separate from what normalization proposed. Store both readings whenever a decimal point, minus sign, O-versus-zero, or diacritic is ambiguous.

Grade the pipeline on exact-string accuracy for identifiers, unit preservation, region association, warning recall, and unsupported-normalization rate. Character and word error rate are a fine general signal, but they weight a dropped comma the same as a wrong account-number digit, and those aren't the same mistake.

Wrong but fluent is the one to fear

The characteristic failure is a part number, decimal, unit, or safety label normalized into something more familiar and wrong. The language-model-specific trap is flattening a page into one string and asking the model to guess back the destroyed geometry. Neither looks broken: a model completes a damaged surname or a smudged total with whatever looks most plausible, because that's the job it trained for.

Build a real path to "I don't know." A blurry region, a clipped page, glare, unreadable handwriting, a total that doesn't add up: raise an exception, not a guess. Confidence scores alone won't save you, they're model-specific and poorly calibrated: pair them with image-quality checks, format validators, cross-field arithmetic, dictionaries, and disagreement between recognition passes.

What makes review sustainable is evidence next to the claim: store the page number and bounding polygon for each key field, and show the crop beside the proposed value. A reviewer settles an ambiguous digit in seconds with the region right there. Take the coordinates away and it means searching a page, or reopening the physical document.

Treat the model's output as a claim, not a fact

Keep a vision-language model's job narrow: separate observation from inference, and never let it write straight to a database or call a tool unsupervised. Schema validation and business rules live outside the model. Text on a scanned page is data, not an instruction; a model that treats a buried sentence as a new command doesn't belong in production.

Multi-page work needs the same discipline: preserve page order and header identity instead of merging invoices at random, split documents on purpose, tag each piece with an identifier, and decide whether a table may cross a page boundary.

Preserve spatial structure through the pipeline and flatten it only for consumers that don't need geometry. Version the model, preprocessing, dictionaries, and validation together, and replay a fixed set, clean pages, ordinary noise, hard layouts, fields that must never be wrong, a few built to fail, whenever any of it changes.

This is mostly economics once the pipeline is sound. Local deployment keeps documents under your control, cheaper at steady, high volume, counting storage, accelerator time, and review hours. A hosted API buys elasticity and a wider exception ceiling, at the cost of upload time, retention, residency, and per-page fees. Route between the two by sensitivity, provided the escalation path is visible.

Keep the deterministic, geometry-preserving stage as the backbone. Let the model in only where it earns the seat.

#ocr-models#document-ai#vision