5 个开源 PDF 解析工具实测
PDF 解析工具很多。真正接到 RAG、企业知识库或文档智能系统里时，问题往往不是“能不能 OCR”，而是结果能不能继续用：文本是否稳定，阅读顺序是否还像人读的顺序，表格和公式有没有基本保留，后面能不能 chunk、索引和引用。
这次选了 5 个开源 PDF/文档解析工具，放在同一份公开数据集、同一台测试服务器和同一套轻量指标下跑。评测者没有参与这些项目的开发，结论也不依赖私有样本。
参评工具
| 工具 | 类型 | 评测定位 |
|---|---|---|
| Docling | 文档转换/工程基线 | 关注工程可用性、速度和 Markdown 输出 |
| MinerU | 综合 PDF 解析 | 代表 OpenDataLab 生态里的完整解析方案 |
| PaddleOCR-VL-1.6 | 多模态文档解析 | 代表 PaddleOCR 当前 VLM 文档解析路线 |
| DeepSeek-OCR 2 | VLM/OCR | 代表新一代视觉 OCR/文档理解路线 |
| dots.mocr | 多模态 OCR/解析 | 代表较新的 bbox/category/text 结构化输出路线 |
这里没有把 pdftotext 放进主表。它适合做数字 PDF 的诊断基线，但本文更关心页面图像解析，包括报纸、教材、幻灯片、扫描页、表格和公式。
数据集
主数据集是 opendatalab/OmniDocBench。它覆盖论文、教材、幻灯片、报纸、扫描件等文档类型，足够支撑一次公开可复查的 PDF 解析对比。
本文主表使用同一份 article-300 manifest：
| 项目 | 设置 |
|---|---|
| 数据集 | OmniDocBench |
| 样本数 | 300 页 |
| 输入形式 | 页面图像 |
| 任务 | 文档页面解析为文本或 Markdown/结构化内容 |
| 目标 | 比较可运行性、速度、失败率和文本相似度 |
后面的主结论只看 5 个工具都完成的同一轮结果，不混用不同样本规模、不同运行方式或没跑完的数据。
Testbed
所有工具都在同一台测试服务器上运行。性能数字只代表这个环境下的相对结果，不建议直接外推到其他部署条件。
| 项目 | 配置 |
|---|---|
| CPU | 2 x Intel Xeon Silver 4314 @ 2.40GHz |
| CPU 核心/线程 | 32 物理核心 / 64 逻辑线程 |
| 内存 | 512 GiB |
| GPU | 2 x NVIDIA GeForce RTX 3090 |
| 显存 | 24 GiB x 2 |
| NVIDIA Driver | 550.144.03 |
| CUDA | 12.4 |
指标口径
主表只使用 5 个工具都能公平比较的指标：
| 指标 | 含义 |
|---|---|
| 成功率 | 工具是否完成页面处理并产出结果 |
| 计算资源 | CPU/GPU 使用方式 |
| 运行模式 | 批处理、逐页 adapter 或 API 服务 |
| 平均秒/页 | 总耗时除以页面数 |
| 中位秒/页 | 避免少数极慢页面拉高平均值 |
| CER | 字符错误率，越低越好 |
| WER | 词错误率，越低越好 |
CER/WER 不能代表完整的 PDF 解析质量。不同工具输出格式差异很大：有的输出 Markdown，有的输出纯文本，有的输出 JSON blocks。直接和 ordered ground truth text 对齐，会把 Markdown 标记、表格格式和阅读顺序差异都算成错误。所以这里把 CER/WER 当作“文本相似度参考”，不把它当唯一排名。
Layout F1、Table F1、Formula Exact Match 不进入本文主榜。原因是 5 个工具的结构输出来源不同：Docling 来自 prov.bbox，MinerU/PaddleOCR-VL/dots.mocr 来自各自 JSON blocks，DeepSeek-OCR 2 来自 Markdown 中的 det 标记。它们可以进入结构诊断，但仍不应替代主榜结论。
为了让评测不只停留在 CER/WER，本文额外记录两类扩展指标：
| 扩展指标 | 用途 | 主榜 |
|---|---|---|
| 文本覆盖率 | 判断工具是否稳定产出可继续处理的文本结果 | 是，工程参考 |
| Blocks 覆盖率 | 判断工具是否具备结构化输出基础 | 是，工程参考 |
| JSON 有效率 | 判断结构化输出是否可被程序稳定解析 | 是，adapter 参考 |
| 表格相似度 | 评估表格内容与标注的相似度 | 否，仅诊断 |
| 公式相似度 | 评估公式内容与标注的相似度 | 否，仅诊断 |
| Layout F1 / Table Layout F1 / Formula Layout F1 | 评估 bbox/category 层面的结构恢复 | 否，仅在 schema 可比的子集里展示 |
扩展指标主要用来暴露输出形态和 adapter 成熟度。它们不能替代主表，也不能直接推出“某个模型整体更强”。要做更严格的结构化横评，5 个工具都得先转换到同等粒度的 blocks.json、table 和 formula schema。
结果
5 个工具均完成同一份 OmniDocBench article-300。
| 工具 | 计算资源 | 运行模式 | 成功率 | Mean CER | Median CER | Mean WER | Median WER | 平均秒/页 | 中位秒/页 | Pages/min | 总耗时 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Docling | CPU | per-page adapter | 300/300 | 0.534699 | 0.503003 | 2.384433 | 0.984725 | 5.97 | 3.99 | 10.05 | 29.8 min |
| MinerU | GPU/CPU pipeline | batch, amortized | 300/300 | 0.526917 | 0.309285 | 1.728110 | 0.875000 | 0.76 | 0.76 | 78.62 | 3.8 min |
| PaddleOCR-VL-1.6 | GPU | per-page HF/adapter | 300/300 | 0.859234 | 0.379661 | 3.225547 | 0.871582 | 25.67 | 15.62 | 2.34 | 128.4 min |
| DeepSeek-OCR 2 | GPU | per-page API | 300/300 | 5.869590 | 0.833291 | 7.184052 | 1.056094 | 55.32 | 28.84 | 1.08 | 276.6 min |
| dots.mocr | GPU | per-page HF/adapter | 300/300 | 1.197031 | 0.652942 | 2.971242 | 1.911991 | 68.17 | 49.38 | 0.88 | 340.8 min |
Mean 是平均值，容易被少数极难页面拉高；Median 是中位数，更接近典型页面表现。MinerU 的耗时来自 batch runner 的摊销值，不能和逐页 API/adapter 的耗时完全等价。
扩展指标：输出稳定性
下面这组指标覆盖 5 个工具，反映的是输出是否稳定、是否便于后续程序化处理。
| 工具 | 文本输出 | Blocks 输出 | JSON 有效 | 备注 |
|---|---|---|---|---|
| Docling | 300/300 | 300/300 | 300/300 | 通过 export_to_dict() 导出 prov.bbox |
| MinerU | 300/300 | 300/300 | 300/300 | 可进入结构指标计算 |
| PaddleOCR-VL-1.6 | 300/300 | 300/300 | 300/300 | 可进入结构指标计算 |
| DeepSeek-OCR 2 | 300/300 | 300/300 | 300/300 | 从 Markdown det 标记导出 blocks |
| dots.mocr | 300/300 | 300/300 | 295/300 | 有结构化输出潜力，但 JSON 稳定性需要单独关注 |
这张表比 CER/WER 更接近工程落地。RAG 前处理通常不只要一段文本，还要页码、块边界、标题层级、表格区域和可追溯信息。5 个工具在本文 adapter 下都能产出结构化 blocks，但来源和稳定性不一样；dots.mocr 有 5 页 JSON 不能直接解析，DeepSeek-OCR 2 的 blocks 来自 Markdown 内嵌检测标记，噪声更高。
扩展指标：结构化诊断
结构化指标目前只作为诊断表，不作为 5 工具主榜。Docling 此前缺少这三项，是因为第一版 adapter 只保存 Markdown/text；补充 export_to_dict() 后，可以从 Docling 的 prov.bbox 导出统一 blocks。DeepSeek-OCR 2 也可以从 Markdown ref/det 标记导出 bbox，但这一路径比原生 JSON blocks 更容易受输出格式噪声影响。
| 工具 | Layout F1 | Table F1 | Formula F1 | 表格相似度 | 公式相似度 | 口径 |
|---|---|---|---|---|---|---|
| Docling | 0.496621 | 0.876106 | 0.453172 | 0.189346 | 0.001937 | 来自 Docling prov.bbox 导出的 normalized blocks |
| MinerU | 0.500484 | 0.914980 | 0.626466 | 0.452320 | 0.283428 | 来自 normalized block JSON |
| PaddleOCR-VL-1.6 | 0.707293 | 0.970954 | 0.000000 | 0.913666 | 0.598309 | 公式 layout label 未匹配，Formula Layout F1 因此为 0 |
| DeepSeek-OCR 2 | 0.133424 | 0.560748 | 0.126354 | 0.286046 | 0.376911 | 从 Markdown det 标记抽取 bbox |
| dots.mocr | 0.605774 | 0.939271 | 0.587065 | 0.840033 | 0.611329 | 来自 bbox/category/text JSON，5 页 JSON 需修复 |
这张诊断表里有几件事比较明显。Docling 的 Table F1 较高，说明它能定位表格区域，但表格内容相似度很低；“找到表格”和“还原表格内容”是两个问题。PaddleOCR-VL-1.6 和 dots.mocr 在表格内容相似度上更强，表格密集文档可以继续单独测。DeepSeek-OCR 2 的 det 标记可以用于结构诊断，但整体 Layout F1 偏低，bbox/category 输出还需要更严格的 prompt 和解析约束。PaddleOCR-VL-1.6 的 Formula Layout F1 为 0，也不等于公式内容完全不可用，只说明当前归一化标签没有稳定匹配到公式块。
所以结构化结果只作为下一轮评测方向，不作为这次的硬排名依据。
观察一：Docling 是很好的工程基线
Docling 是这轮 CPU 路线里很好的工程基线，平均 5.97 秒/页，中位数 3.99 秒/页。安装、调用和输出路径都直接，适合衡量“快速转文本/Markdown”的工程下限。
如果任务是快速把大量文档转成可读 Markdown 或文本，Docling 值得优先验证。补充结构 adapter 后，它也能导出 bbox/category blocks，并在 article-300 上得到 0.496621 的 Layout F1。不过对表格内容、公式内容和图注关系敏感的 RAG 系统，仍需要人工抽样检查。
观察二：MinerU 的文本指标和吞吐最突出
MinerU 在这轮 article-300 中同时拿到最低 Mean CER、最低 Mean WER 和最高吞吐。不过它使用的是 batch runner，平均 0.76 秒/页是批处理摊销结果，不能简单等同于逐页在线服务延迟。
从文本指标看：
| 维度 | 当前较好 |
|---|---|
| Mean CER | MinerU |
| Median CER | MinerU |
| Mean WER | MinerU |
| Median WER | PaddleOCR-VL-1.6 |
这不等于“MinerU 全面胜出”。更准确地说，在这 300 页公开样本和当前归一化口径下，MinerU 的 ordered text 相似度和批处理吞吐更强，值得作为 RAG 前处理的主候选。
观察三：PaddleOCR-VL 更稳，DeepSeek-OCR 2 和 dots.mocr 更依赖输出归一化
PaddleOCR-VL-1.6 的 Mean CER/WER 不如 MinerU 和 Docling，但 Median CER/WER 很接近 MinerU，说明它在典型页面上并不弱，平均值主要受部分复杂页面影响。
DeepSeek-OCR 2 和 dots.mocr 都能跑通 300/300 页，但 CER/WER 明显偏高。尤其 DeepSeek-OCR 2 的 Mean CER 高于 Median CER 很多，说明少数页面输出与 ordered ground truth 差异极大，拉高了平均值。
这不能简单解释成模型质量差。输出形态影响很大：
- DeepSeek-OCR 2 当前 API prompt 和 output normalization 仍偏粗，格式差异会放大 CER/WER。
- dots.mocr 输出 bbox/category/text JSON，直接把 JSON 风格内容与 ordered text 对齐，会把结构符号也算进文本差异。
dots.mocr 的价值主要在结构化输出，而不是纯文本 CER/WER 排名。对于依赖 bbox、category、table HTML 或 formula LaTeX 的系统，它需要进入结构指标评测；但在统一 schema 建立前，本文不把结构分数作为正式排名。
观察四：结构化能力首先反映 adapter 成熟度
扩展指标说明，结构化能力不能只看模型名称，还要看输出协议是否稳定。Docling、MinerU、PaddleOCR-VL-1.6 和 DeepSeek-OCR 2 当前都能产出 300/300 的结构 blocks；dots.mocr 也产出了 300/300 的结构 blocks，但只有 295/300 可以直接按 JSON 解析。它有结构化价值，也需要 JSON 修复和 adapter 稳定性处理。
DeepSeek-OCR 2 的结构 blocks 来自 Markdown 内嵌 det 标记，不是独立 JSON schema，因此能算诊断指标，但不应过度解释。若生产系统需要可追溯 chunk、页面坐标、表格区域和公式区域，应优先验证 Docling、MinerU、PaddleOCR-VL-1.6、dots.mocr 这类结构输出更直接的路线；DeepSeek-OCR 2 需要更严格的结构化 prompt 和 adapter 才适合生产级结构评估。
结构化指标为什么单独处理
PDF 解析的真正难点是结构恢复：阅读顺序、版面块、表格、公式、图片和图注关系。理想状态下，横评应同时给出：
| 指标 | 需要统一的输出 |
|---|---|
| Layout F1 | bbox + category |
| Table F1 / TEDS | table bbox、cell 或 HTML |
| Formula Exact Match | 公式区域 + LaTeX |
| Reading order | block order 或可排序结构 |
目前 5 个工具的输出并不天然统一。为了避免不公平比较，本文主表不使用部分工具才有的结构指标。结构化横评需要先定义统一 blocks.json schema，并为 Docling、DeepSeek-OCR 2、dots.mocr、MinerU 和 PaddleOCR-VL 建立同等粒度的 adapter；在此之前，结构指标不适合作为本文正式排名依据。
选型建议
| 需求 | 建议 |
|---|---|
| 快速批量转 Markdown/文本 | 先试 Docling |
| 综合 PDF 解析和 RAG 前处理 | 优先试 MinerU，再对照 PaddleOCR-VL-1.6 |
| 新一代 VLM/OCR 方案验证 | DeepSeek-OCR 2、dots.mocr 可以进入实验池 |
| 需要结构化 block 输出 | 优先验证 Docling、MinerU、PaddleOCR-VL-1.6、dots.mocr |
| 表格内容保真 | 重点复测 PaddleOCR-VL-1.6，并补充人工失败案例 |
| 表格/公式强需求 | 不要只看 CER/WER，必须做结构指标和人工失败案例 |
| 生产上线 | 优先看失败率、输出稳定性、吞吐、许可证和部署成本 |
如果只能选两个进入生产前验证，我会优先选 MinerU 和 PaddleOCR-VL-1.6。如果需要一个 CPU 速度基线，保留 Docling。如果要跟踪结构化多模态解析，再加入 dots.mocr；DeepSeek-OCR 2 更适合作为 VLM/OCR 研究候选。
结论
这轮没有单一冠军。
- 5 个工具都能在公开 OmniDocBench article-300 上跑通，失败率均为 0。
- Docling 是最直接的 CPU 工程基线。
- MinerU 在当前文本指标和批处理吞吐上最突出，是 RAG 前处理的主候选。
- PaddleOCR-VL-1.6 的典型页面表现接近 MinerU，但复杂页面拉高了均值。
- DeepSeek-OCR 2 和 dots.mocr 有研究价值，但需要更谨慎地处理输出归一化和结构稳定性。
- 扩展指标显示，Docling、MinerU、PaddleOCR-VL-1.6 和 dots.mocr 更适合继续做结构化 block 路线验证。
- 如果要评估表格、公式、版面，必须先把 5 个工具统一到同一结构 schema，再做 Layout/Table/Formula 横评。
参考项目
- OmniDocBench: https://github.com/opendatalab/OmniDocBench
- Docling: https://github.com/docling-project/docling
- MinerU: https://github.com/opendatalab/MinerU
- PaddleOCR: https://github.com/PaddlePaddle/PaddleOCR
- DeepSeek-OCR: https://huggingface.co/deepseek-ai/DeepSeek-OCR-2
- dots.mocr: https://huggingface.co/rednote-hilab/dots.mocr
评论
评论由 GitHub Issues 提供支持，需要登录 GitHub。