Layout-aware parsing
Extracting text from PDFs and scans with reading order, headings, tables and figures preserved, so chunking and citations have structure to use.
A PDF stores letters and their positions on a page, not paragraphs or tables. A naive extractor reads left to right and mixes columns, headers, footers and table cells into one jumble.
Layout-aware parsing looks at the page the way a person does: it finds headings, paragraphs, columns, tables and figures, puts them in reading order, and outputs clean structured text such as Markdown. Everything after it, from Chunking to citations, depends on this step.
Retyping a magazine page: you read the left column fully before the right, skip the page number, and keep the table as a table instead of reading its cells as a sentence.
Judging retrieval quality without looking at the parsed text. Many 'embedding problems' are interleaved columns, dropped tables or headers repeated on every chunk.
A pipeline runs layout detection (a vision model labels regions: title, section-header, text, table, figure, caption, page header/footer), reading-order resolution, table structure recognition (rows, columns, spanning cells), and text from the PDF's text layer or from OCR (optical character recognition) when the page is a scan. Output is a document tree that serialises to Markdown or JSON with page numbers and bounding boxes per element.
Tools as of Oct 2026: Docling (IBM, open source; DocLayNet layout model plus TableFormer), Unstructured (open source and hosted), Marker and MinerU (open source), LlamaParse, Azure AI Document Intelligence, AWS Textract and Google Document AI (managed). Vision LLMs (Gemini 2.5, Claude, GPT-4.1-class) can transcribe pages straight to Markdown and handle odd layouts well, at 10–100× the per-page cost and with occasional hallucinated cells, so validate numbers. The output feeds structure-aware chunking, Parent-document retrieval (sections become parents) and citations (page + bounding box). Measure parse quality directly: per-document table cell accuracy and reading-order errors on 30–50 sampled pages per source type.
Docling (open source) to Markdown with page numbers and bounding boxes; tables exported as Markdown or HTML and chunked whole; page headers and footers dropped. Route low-confidence or scanned pages to OCR, and odd layouts (forms, infographics) to a vision LLM with numeric cross-checks. Sample 30 pages per source type for a parse-quality eval.
Clinical trial protocols, two-column PDFs with dosing tables. A plain pdftotext run interleaved the two columns and flattened the dosing table into 'Arm A 10 mg 20 mg Arm B…', so 'What is the Arm B starting dose?' got 0.38 recall@5.
Docling with table structure output produced Markdown tables and correct column order; recall@5 rose to 0.86. Throughput on CPU was ~1–2 s per page; 200k pages took ~3 days on one 16-core box, or 6 hours on a GPU node.
Say where quality starts: "Most RAG quality bugs I've seen were parse bugs. I run Docling or a managed parser to Markdown with page and box ids, keep tables whole, and eval parsing separately on sampled pages before touching embeddings." Expect: "when would you use a vision LLM?" For complex layouts at low volume, or as a fallback when the layout model's confidence is low, with numeric cells cross-checked against the text layer.
Naive text extraction
- Columns interleaved
- Tables flattened
- Footers in every chunk
Layout-aware
- Reading order kept
- Tables as Markdown
- Page + bbox for citations
Numbers worth knowing
- Docling throughput
- ~1–2 s/page CPU, sub-second on GPUtext-layer PDFs with table structure on (estimate; measure)
- Managed parsing price
- ~$0.01–0.015/page with tablesTextract / Document Intelligence layout tiers, list prices Oct 2026 (illustrative)
- Vision-LLM page cost
- ~1.5–2k input tokens per page imageClaude image tokens ≈ width×height/750
How to decide
| When | Do this |
|---|---|
| Born-digital PDFs with tables and columns | Docling / Unstructured / Marker with table structure on. |
| Scanned or photographed pages | OCR inside the layout pipeline; check confidence per page. |
| Under ~10k pages of complex layouts | A vision LLM to Markdown is cheaper than engineering parsers; validate numbers. |
Cost maths
Pages × price. 1M pages: Docling self-hosted on one GPU node at ~2 pages/s ≈ 140 hours ≈ $270 at an assumed $1.90/h; managed layout with tables at ~$0.015/page ≈ $15,000; a vision LLM at ~1.8k input + 800 output tokens/page with $1/M in and $5/M out ≈ $5.80/1k pages ≈ $5,800 (illustrative, Oct 2026). Batch APIs halve the LLM figure.
Operating it
- More than 5% of golden-set misses trace to parse errors: invest in parsing before embeddings
- Parsing backlog grows faster than throughput: move Docling to GPU or shard by document
- New source with forms or handwriting: add OCR/vision fallback route
- Parse failures and empty-text pages per source: alert above 2% of pages
- Tables detected per 100 pages by source: alert on a 50% drop (format change upstream)
- Sampled table-cell accuracy (monthly 30-page audit): alert below 95%
When it goes wrong
Annual-report Q&A gave revenue figures from the wrong year about 1 time in 6.
Spot checks of cited chunks showed table cells concatenated across the 2024 and 2025 columns.
The text-layer extractor read tables row-wise with no cell boundaries, so '4,210 3,980' lost its column headers.
Switched to Docling table structure, emitted tables as Markdown with headers repeated per chunk, and added a numeric-cell check comparing parsed values against the text layer.
Related terms
Where it shows up
Sources
- Docling Technical Report — Auer et al. (IBM Research), 2024paper
- LayoutLM: Pre-training of Text and Layout for Document Image Understanding — Xu et al., 2019paper
Check yourself
Three questions. Every option is explained once you answer.