Document and Diagram Understanding
Documents are not photos. A PDF, scientific paper, invoice, or handwritten form carries layout, tables, diagrams, footnotes, headers, and semantic structure that plain image understanding misses. The pre-VLM stack was a pipeline of Tesseract OCR, LayoutLMv3, and table-extraction heuristics. The VLM wave replaced it with OCR-free models (Donut in 2022, Nougat in 2023, DocLLM in 2023) that emit structured markup directly. By 2026 the frontier is to feed the page image to Claude Opus 4.7 at 2576px native and get structured markup back without extra machinery. This lesson walks the three-era arc of document AI.
Learning Objectives
- Explain the three eras of document AI: OCR pipeline, OCR-free, VLM-native.
- Describe LayoutLMv3's three input streams: text, layout (bbox), image patches, with unified masking.
- Compare Donut (OCR-free, image → markup), Nougat (scientific paper → LaTeX), DocLLM (layout-aware generative), PaliGemma 2 (VLM-native).
- Pick a document model for a new task (invoices, scientific papers, handwritten forms, Chinese receipts).
The Problem
"Understand this PDF" sounds simple and isn't. The information sits in:
- Text content (90% of the signal).
- Layout (headers, footnotes, sidebars, two-column format).
- Tables (rows, columns, merged cells).
- Figures and diagrams.
- Handwritten annotations.
- Fonts and typography (title vs body).
Raw OCR dumps the text and drops the rest. A system that cares about invoices needs to know that "Total: $1,245" came from the bottom-right, not from a footnote.
The Concept
Era 1: OCR pipeline (pre-2021)
The classic stack:
- PDF → image per page.
- Tesseract (or commercial OCR) extracts text with per-word bounding boxes.
- Layout analyzer identifies blocks (header, table, paragraph).
- Table structure recognizer parses tables.
- Domain rules + regex extract fields.
This works for clean printed text. It breaks on handwriting, skewed scans, complex tables, and non-English scripts, and each failure mode tends to need its own custom exception path.
TrOCR (2021)
TrOCR (Li et al., arXiv:2109.10282) replaced Tesseract's classic CNN-CTC with a transformer encoder-decoder trained on synthetic + real text images. It was a clean win on handwritten and multilingual text. The stack was still a pipeline (detector, then TrOCR, then layout), but the OCR step got much better.
Era 2: OCR-free (2022-2023)
The first OCR-free models skipped detection entirely and mapped image pixels straight to structured output.
Donut (Kim et al., arXiv:2111.15664):
- Encoder-decoder transformer, encoder is Swin-B.
- Output is JSON for form understanding, markdown for summarization, or any task-specific schema.
- No OCR, no layout, no detection.
Nougat (Blecher et al., arXiv:2308.13418):
- Trained specifically on scientific papers.
- Output is LaTeX / markdown.
- Handles equations, multi-column layout, figures.
- A common choice for parsing arXiv.
These are specialists, not generalists. Donut on a scientific paper fails, and so does Nougat on an invoice.
LayoutLMv3 (2022)
LayoutLMv3 (Huang et al., arXiv:2204.08387) takes a different track. It keeps OCR and adds layout understanding:
- Three input streams: OCR text tokens, per-token 2D bounding boxes, image patches.
- Masked training objective across all three modalities (masked text, masked patches, masked layout).
- Downstream: classification, entity extraction, table QA.
This is the peak of OCR-based document understanding. It is strong on forms and invoices, needs OCR upstream, and had the best pre-VLM accuracy on standardized document benchmarks.
DocLLM (2023)
DocLLM (Wang et al., arXiv:2401.00908) is LayoutLM's generative sibling. It generates free-form answers conditioned on layout tokens, which suits QA on documents, but it still depends on OCR input.
Era 3: VLM-native (2024+)
By 2024 VLMs were good enough to replace the pipeline. Feed the full page image at high resolution to a VLM, ask the question, get an answer.
- LLaVA-NeXT 336-tile AnyRes works for small documents.
- Qwen2.5-VL dynamic-resolution handles 2048+ pixels natively.
- Claude Opus 4.7 supports 2576px documents.
- PaliGemma 2 (April 2025) trains specifically for documents + handwriting.
The gap between VLM-native and OCR-pipeline closed fast. By 2026, VLM-native wins on:
- Scene text (hand-written + printed, mixed scripts).
- Complex tables with merged cells.
- Math equations embedded in text.
- Figures with text annotations.
OCR pipelines still win on:
- Pure-scan workloads at massive scale where per-page latency matters.
- Pipeline reliability (deterministic failures vs VLM hallucinations).
- Regulated environments that need auditable OCR output.
The Claude 4.7 / GPT-5 frontier
At 2576-pixel native input, frontier VLMs reach near-human accuracy on document understanding. The benchmark numbers from early 2026:
- DocVQA: Claude 4.7 ~95.1, PaliGemma 2 ~88.4, Nougat ~77.3, pipelined LayoutLMv3 ~83.
- ChartQA: Claude 4.7 ~92.2, GPT-4V ~78.
- VisualMRC: Claude 4.7 ~94.
The closed-model gap comes mostly from resolution and base-LLM scale. Open models at 7B are a few points behind and catching up.
Math equations and LaTeX output
Scientific papers need exact LaTeX for equations, and Nougat was trained on exactly that. VLMs trained with LaTeX targets (Qwen2.5-VL-Math, Nougat derivatives) produce usable LaTeX. Without explicit LaTeX training, VLMs give readable but imprecise transcriptions.
For scientific-paper pipelines in 2026, chain Nougat on the PDF, then a VLM on the tricky pages.
Handwriting
Handwriting is still the hardest sub-task. Mixed printed + handwritten content (doctors' notes, filled forms) is where OCR pipelines still beat VLMs on cost. Handwritten-only VLMs are improving (Claude 4.7, PaliGemma 2).
2026 recipe
For a new document-AI project:
- Pure-printed invoices at scale: LayoutLMv3 + rules, cost-efficient.
- Mixed documents (scientific + handwritten + forms): VLM-native (PaliGemma 2 or Qwen2.5-VL).
- Full arXiv ingestion: Nougat for math, VLM for figures.
- Regulatory: OCR pipeline + VLM validator for cross-check.
Use It
code/main.py is stdlib-only and does three things:
- A toy layout-aware tokenizer: given (text, bbox) pairs, it produces the LayoutLMv3-style input.
- A Donut-style task schema generator: JSON templates for invoices and forms.
- A comparison of token budgets per page across OCR-pipeline, Donut, Nougat, and VLM-native.
Ship It
This lesson produces outputs/skill-document-ai-stack-picker.md. Given a document-AI project (domain, scale, quality, regulatory), it picks between OCR pipeline, OCR-free specialist, and VLM-native.
I'd run main.py and read its output before the prose. The mock invoice has eight tokens, and each one carries a bbox next to its text. That pairing is the whole idea behind LayoutLMv3. "Total" and "$1,245.00" sit at y=400 and y=440, well below the line-item price at y=240, so a model that sees coordinates can tell a grand total from a unit price without guessing from the text alone.
I'd also treat the toy as a shape demo and nothing more. The text_ids come from Python's hash() of each string, so they are not a real vocabulary, and string hashing is salted per process by default, so the ids can change between runs. patch_ids is just range(256) for a 16x16 grid with no pixels behind it. The token-budget table is a list of hardcoded rows, not something the script measures. I'd read it for orders of magnitude (512 for the OCR pipeline, 12000 for Claude 4.7 at 2576px) and not as a benchmark.
If I were picking a stack for a real project, I'd settle scale and audit requirements first and look at accuracy second. At 10M invoices a day the token counts in that table decide more than a few DocVQA points do, and a regulated workload wants the deterministic OCR output whatever the VLM scores.
Exercises
-
Your project is 10M invoices per day. Which stack minimizes cost-per-page without losing accuracy?
-
Why does LayoutLMv3 outperform pure-CLIP-VLMs on form QA but underperform at scene-text? What does the bbox stream give up?
-
Nougat generates LaTeX. Propose a test case where VLM-native output beats Nougat on LaTeX fidelity, and a case where Nougat wins.
-
Read PaliGemma 2 paper (Google, 2024). What was the key training-data addition that lifted document accuracy vs PaliGemma 1?
-
Design a regulatory-safe hybrid: OCR pipeline as primary, VLM as secondary cross-check. How do you resolve disagreement?
Key Terms
| Term | What people say | What it actually means |
|---|---|---|
| OCR pipeline | "Tesseract-style" | Stage-wise stack: detect -> OCR -> layout -> rules; deterministic, fragile |
| OCR-free | "Donut-style" | Image-to-output transformer that skips explicit OCR; single model |
| Layout-aware | "LayoutLM" | Input includes per-token bbox coordinates; unified masking across modalities |
| VLM-native | "Frontier VLM" | Feed page image directly to Claude/GPT/Qwen VLM at high resolution; no pipeline |
| DocVQA | "Doc benchmark" | Document VQA standard; most-cited score |
| Markup output | "LaTeX / MD" | Structured output format instead of free-form text; enables downstream automation |
Code
- main.py (python, 127 lines)