Every RAG pipeline has the same boring first step: turn a stack of PDFs, scans, and slide decks into text an embedding model can actually use. It's also where most of the accuracy quietly disappears, because a two-column paper, a merged-cell table, and a crooked scan each break a naive text extractor in a different way, and nothing throws an error when they do.
The number worth sitting with this year comes from OmniDocBench v1.6, a 1,651-page benchmark across 10 document types and 5 languages. The top scorer is PaddleOCR-VL-1.6 at 96.34 overall, a 0.9 billion parameter open-weights model. Gemini 3 Pro scores 92.91. GPT-5.2 scores 86.59. A model small enough to run on one GPU is beating the frontier models at reading documents, and it ships Apache 2.0. I went deep on the pricing and licensing tradeoffs in the full writeup on DevToolLab - this is the condensed version.
That flips the usual calculus. For two years, "just hit an OCR API" was the correct default. Now the best open models are both more accurate and cheaper at any real volume, while the APIs are still good at the one thing that never changed: you don't have to run a GPU.
Why parsing quietly wrecks retrieval
Three failure modes show up over and over, and none of them crash your pipeline, which is the problem.
Reading order breaks first. Run a naive extractor over a two-column paper and the columns interleave line by line - fluent-looking nonsense that an embedding model happily indexes. Tables go next: flatten a financial statement into a paragraph and every number loses the row and column that gave it meaning, so the model will confidently tell you Q3 revenue when you asked about Q1. Headers and footers are the third leak - a repeated running title injected into every chunk adds noise to every vector you store.
None of this fails a basic "did text come out" check. It shows up later as an assistant that cites the right document and still gets the answer wrong.
Three ways to get text out of a document
Pipeline libraries chain a layout model, an OCR engine, and an assembly step into Markdown or JSON. Docling and Marker work this way, run fine on CPU, and cover formats well beyond PDF. Open-weight document VLMs collapse that chain into a single vision-language model that reads the page image and writes structured output directly - this is where PaddleOCR-VL, MinerU, and DeepSeek-OCR 2 live, and it's also where the accuracy ceiling currently is. Managed APIs bill per page and trade cost plus data residency for never touching model serving.
The open source options
Docling is the safe default for a messy, mixed corpus. IBM handed it to the LF AI & Data Foundation in April 2025, it's MIT licensed, and version 2.123.0 (August 26, 2026) sits at 65,600 GitHub stars. It ingests PDF, DOCX, PPTX, XLSX, HTML, EPUB, images, LaTeX, email, and even audio via ASR, running fully local at roughly 1.5 pages per second on CPU. It doesn't chase leaderboard scores, though - it isn't on OmniDocBench v1.6 at all, and a dedicated VLM will beat it on hard scans.
MinerU is the highest-starred tool here at 78,600 stars, and the thing that made it commercially viable happened this year: on April 18, 2026 it dropped AGPL-3.0 for a custom Apache-2.0-based license, with a commercial license required only past 100 million MAU or $20M monthly revenue. Version 3.4.5 (August 14, 2026) gives you a real backend spread - the CPU-only pipeline backend scores 86.47 on OmniDocBench at 4GB RAM, while hybrid-engine/vlm-engine hit roughly 95.3 with 8GB of VRAM. Same tool from laptop prototype to production.
PaddleOCR-VL is the accuracy ceiling if you can self-host: 96.34 on OmniDocBench, a 0.9B Apache 2.0 model pairing a vision encoder with a small ERNIE language model. The parent project has 88,300 stars, v3.7.0 shipped June 2026. The tradeoff is real: you're adopting the PaddlePaddle framework instead of plain PyTorch, and a lot of the docs lean Chinese-language.
Marker is the throughput play. v2.0.0 (July 20, 2026) rebuilt it around the Surya VLM and added CPU support; on a single B200 it does 23.7 pages/sec with OCR off, down to 2.9 pages/sec in balanced mode where it scores 76.0 on olmOCR-Bench. Read the license before you adopt it - the code is Apache 2.0 but the model weights carry a modified RAIL-M license that locks out anyone over $5M in prior-year revenue or funding, plus anyone building a competing product.
Worth a mention: olmOCR 2 is fully Apache 2.0 including weights and scores 82.4 on its own benchmark, but hasn't had a commit since March 25, 2026. DeepSeek-OCR 2 compresses text into vision tokens at roughly 10x with ~97% precision - more a token-cost story than a pure OCR one. Tesseract is still at 5.5.3 and still fine for clean scans, nothing more.
What the managed APIs actually charge
LlamaParse is the cheapest layout-aware option that's still credible: $1.25 per 1,000 credits, working out to $0.00125/page on Fast up to $0.05625/page on Agentic Plus. New accounts get 10,000 free credits and re-parsing the same file within 48 hours is free.
Reducto targets hard documents and isn't cheap: pricing shifts on September 1, 2026 to $15 per 1,000 standard pages, $30 for complex pages, double for agentic modes. It's the right tool when a misread table has a dollar cost attached.
Mistral Document AI sits in the cheap-and-fast middle at $4 per 1,000 pages ($2 via Batch API), covering 170 languages with mistral-ocr-4-1. The accuracy story is messier than the marketing: Ai2's independent olmOCR-Bench scored the older Mistral API at 72.0, while Mistral self-reports 85.20 for OCR 4 - discount vendor-run benchmarks accordingly.
The big three cloud providers have converged hard: plain OCR runs $1.50 per 1,000 pages on AWS Textract, Azure prebuilt-read, and Google Enterprise Document OCR alike, dropping to $0.60 at volume. Layout-aware parsing jumps to $10-15 per 1,000. Unstructured undercuts all of them at $0.015/page with 10,000 free pages, and keeps its library Apache 2.0.
Try it yourself: PDF to Markdown with Docling
Docling gets you from PDF to chunkable Markdown fastest, with no API key and no GPU:
python3 -m venv .venv
source .venv/bin/activate
pip install docling
from pathlib import Path
from docling.document_converter import DocumentConverter
converter = DocumentConverter()
doc = converter.convert("docling-report.pdf").document
markdown = doc.export_to_markdown()
Path("parsed.md").write_text(markdown, encoding="utf-8")
print(f"pages: {len(doc.pages)}")
print(f"tables: {len(doc.tables)}")
print(f"chars: {len(markdown)}")
Against the 9-page Docling technical report, that prints pages: 9, tables: 3, chars: 34408. Watch the table count specifically - if a document you know has tables reports zero, the parser flattened them into prose and your retrieval quality already took the hit before you even started chunking. I compare parser outputs side by side with DevToolLab's Diff Checker, which makes dropped tables and scrambled reading order obvious fast.
Picking one
Got a GPU and want max accuracy? PaddleOCR-VL. Want one tool that degrades gracefully to CPU? MinerU - the April relicensing removed the last real objection to it. CPU-only or air-gapped? Docling, for the MIT license and format coverage. Over $5M in revenue or funding? Marker's weights are off the table regardless of speed. Want zero infrastructure at low cost? LlamaParse's Cost-effective tier at $0.00375/page. Documents where a mistake is expensive? Budget for Reducto.
Whatever you land on, test against your own documents - a parser that's excellent on academic papers can fall apart on scanned invoices. The full comparison table and cost breakdown covers every tool in more depth than fits here.
Top comments (0)