pdf-inspector 究竟有多快、多准？与其听我们自夸，不如直接看官方在 opendataloader-bench 语料库上公布的那组横向数据。

测试方法

• 样本：opendataloader-bench 语料库，200 份真实 PDF
• 工具：pdf-inspector、liteparse、opendataloader、pymupdf4llm、markitdown，共五家（均为本地解析引擎、关闭 OCR，不含基于模型的 PDF 解析）
• 维度：综合质量、阅读顺序、表格结构（TEDS）、标题识别，得分 0–1 越高越好
• 速度：完整跑完语料库的总耗时（Apple M4 Pro，预热后取五次完整运行的中位数）

结果总表

工具	综合评分	阅读顺序	表格 (TEDS)	标题	速度
pdf-inspector	0.875	0.915	0.814	0.788	0.470s
liteparse	0.873	0.913	0.693	0.811	0.750s
opendataloader	0.831	0.902	0.489	0.739	2.569s
pymupdf4llm	0.735	0.886	0.401	0.424	17.117s
markitdown	0.589	0.844	0.273	0.000	16.165s

数据更新于 2026 年 7 月 31 日。完整方法论和版本信息见仓库 README，原始计时与产物在结果分支。

怎么读这张表

综合质量：0.875，第一名。 与第二名 liteparse（0.873）咬得很紧，但拉开差距的是下面两项。

表格识别：TEDS 0.814，断层领先。 第二名 liteparse 是 0.693，opendataloader 只有 0.489。框线检测 + 文本对齐启发式的双模式设计在财务报表、跨页续表这类硬骨头上明显占优——而表格恰恰是 LLM 场景里最容易「喂错」的结构。

速度：0.470s 跑完 200 份文档，最快。 比第二快的 liteparse 快约 37%，比 opendataloader 快 5 倍多，比 pymupdf4llm 和 markitdown 快 30 多倍。批量入库、实时解析的场景下这是体验级别的差距。

阅读顺序 0.915 同样居首。 多栏、报纸式版面重建得最接近人眼阅读的自然顺序，这直接决定了转出的 Markdown 通不通顺。

标题识别 0.788，仅次于 liteparse（0.811）。 markitdown 在这项上是 0.000——它基本不还原标题层级。

为什么 pdf-inspector 能又快又准

速度不是靠魔法，而是架构选择的结果：

1. 单次加载——文档只解析一次，检测、布局、表格、Markdown 各阶段共享同一次解析结果
2. 纯 Rust——默认构建没有 ML 模型、没有外部服务调用，唯一依赖是 lopdf
3. 双模式表格检测——绘制操作与对齐启发式互补，而不是押注单一启发式
4. 版面优先——先重建行/段落/阅读顺序再输出，而不是按内容流顺序硬排

局限性也要说清楚

• 基准不含 OCR：所有引擎都关闭了 OCR、只比本地解析。扫描件的差距要看各自的 OCR 方案。
• 基准是官方样本：200 份文档有代表性但不是全宇宙，特殊排版的极端情况仍需实测。
• 速度标注为总耗时中位数：单份超大文件的耗时会更高，文本型 PDF 的典型全流程耗时在 200ms 以内。

想自己跑一遍？

方法学与版本见官方仓库 README 的 Benchmark 一节，原始计时和产物在 opendataloader-bench 的结果分支里公开可查。

想看两大热门工具的正面 PK？

对比绕不开它——markitdown vs pdf-inspector：谁更适合 PDF 转 Markdown？