<- all tokdocs

Three Parsers for a Serious RAG Pipeline: MinerU, Docling, and PaddleOCR

Watch on TikTok

View on TikTok ->

Before any chunking, embedding, or retrieval happens in a RAG pipeline, the raw document has to be parsed. It's the first stage and it quietly decides the ceiling of your retrieval quality. This video lays out a pragmatic three-parser strategy — one heavyweight, one Office-native, and one lightweight — all sitting behind a single interface.

Never Rely on a Single Parser

The core insight: different document types need different parsers. Financial PDFs with complex tables need something different from a HTML page or an Office document. Instead of picking one parser and forcing everything through it, use three behind a unified interface and route per task.

1. MinerU — The Heavyweight

MinerU (from Open Data Lab) is the big gun. Used when you need full document intelligence.

  • Invoked as a CLI subprocess with output streamed through background threads in real time
  • Performs layout analysis, OCR, table structure recognition, and formula extraction to LaTeX
  • Writes a JSON content list to disk; the pipeline reads the JSON as parsed output
  • Native support: PDFs and common image formats
  • For anything else: convert to PDF first

MinerU is the choice when the document has layout that matters — financial reports, research papers, anything with tables or equations you can't lose.

2. Docling — Office-Native

Docling (from IBM Research) is the one that handles documents the other two can't touch.

  • Parses Office documents natively — no PDF conversion required
  • Handles HTML — the only one of the three that does
  • Output is a hierarchical tree with ref-based pointers between sections
  • To fit the standard interface, use a recursive walker that resolves references and flattens the tree into flat content blocks
  • Embedded images come through as base64 — decode and write as PNGs

Use Docling when the source is .docx, .pptx, .xlsx, or HTML — Office is its home turf.

3. PaddleOCR — The Lightweight Option

PaddleOCR (built on Baidu's PaddlePaddle framework) is the stripped-down option.

  • PDFs: render every page to an image using PyPDFium2 at 2× scale, then run OCR per page
  • Images: OCR directly
  • Fundamental limit: only extracts text. Tables aren't recognized as tables; images aren't recognized as images — everything comes out as plain text blocks

Use PaddleOCR when lightweight text extraction is all you need — scanned docs, simple layouts, low-latency paths.

The Unified Pattern

Parser Best For Output Shape Heaviness
MinerU PDFs with tables/formulas/complex layout JSON content list Heavy
Docling Office docs (.docx, .pptx, .xlsx) + HTML Hierarchical tree (flatten it) Medium
PaddleOCR Scanned/simple docs, plain text needs Flat text blocks Light

The architectural move that makes this work: a single Parser interface, three implementations, router decides which one based on MIME type or file extension (or sometimes content sampling). Every parser returns the same flat content block format so the downstream chunker and embedder don't need to know which parser ran.

Why This Matters

Most RAG pipelines fail at parsing, not retrieval. A bad parser turns a clean PDF into mojibake, loses table structure, or flattens a chart caption into gibberish. No amount of clever embedding will save you from that. Three parsers is not over-engineering — it's the minimum to cover the real document surface a production RAG pipeline sees.

Key Takeaways

  • Parsing is RAG's first stage and it caps retrieval quality — don't rely on a single parser
  • MinerU for heavy PDFs with layout/tables/formulas (CLI subprocess, JSON output)
  • Docling for Office documents and HTML (hierarchical tree — flatten with a walker)
  • PaddleOCR for lightweight text extraction when fidelity isn't needed
  • Hide all three behind a single interface that returns a uniform flat content block format

Resources

Published April 16, 2026. Writeup generated from a favorited TikTok.