几乎所有做知识库问答的团队都会掉进同一个坑：精心接好 RAG，回答却总是”好像知道但说不全”。排查了一圈模型、向量库、切分策略，最后发现问题根本不在检索，在入口——你把 47 页的 PDF、18 张扫描件、一个带表头的页眉页脚直接灌了进去，模型读到的是垃圾进，垃圾出。
我们花了一个半月把文档解析单独拆出来测：110 份真实文档，覆盖 MinerU 2.0、PP-StructureV3、Marker、olmOCR-2 以及最常见的 pdfplumber，回答一个问题——哪一层解析是 RAG 的地基，而不是”顺便”？
结论先放这里：多数团队的 RAG 效果被入口压住了，而入口的问题几乎全在”阅读顺序”和”表格还原”这两件事上，不在 OCR 识别率上。这句话是我们排查了三个星期才换来的。
一、实验设计：先定义”可检索性”
110 份样本按类型均分：
- 版式 PDF（22）：双栏论文、财报、合同。有正确的阅读顺序问题。
- 扫描件（22）：300dpi 与 150dpi 混采。考验 OCR。
- 表格密集型（22）：库存表、财务附注。表是嵌套的。
- 带页眉页脚（22）：常见企业文档。干扰内容。
- 混合页（22）：正文 + 图 + 表 + 脚注混在一页。
判定是两级：内容级（文字是否被检出、表格是否被正确读成结构化形式）与问答级（在统一切分策略下，RAG 回答任务的完整率）。第二级才是真正的验收标准——解析不是为生成 markdown，是为下游检索。
这里有个设计要点必须说明：切分策略保持完全一致。只把解析器换掉，其他一概不动。否则你测到的差异里混着切分的影响，根本分不清是谁的功劳。很多团队评测到这里就乱了。
另外，扫描件里刻意混了 150dpi 和 300dpi 两种。只测 300dpi 会让 OCR 指标虚高，而真实业务里企业传上来的扫描件往往是前几年打印机攒下来的，150dpi 一点都不稀奇。
二、数据：表格和扫描件是所有人的短板
| 指标 | MinerU 2.0 | PP-StructureV3 | Marker | olmOCR-2 | pdfplumber |
|---|---|---|---|---|---|
| 版式 PDF 阅读顺序正确率 | 96.4% | 92.9% | 89.7% | 93.2% | 47.3% |
| 扫描件文字检出率 | 97.6% | 94.1% | 93.8% | 95.6% | 0% |
| 表格还原为结构化 | 90.2% | 87.8% | 82.4% | 78.3% | 85.6% |
| 含嵌套 / 合并单元格 | 72.7% | 69.4% | 58.3% | 51.2% | 63.6% |
| 页眉页脚误入正文率 | 4.1% | 9.3% | 11.7% | 6.8% | 16.4% |
| 混合页完整率 | 86.8% | 81.4% | 77.5% | 80.2% | 38.6% |
| 下游 RAG 问答完整率 | 84.4% | 79.6% | 74.2% | 76.8% | 40.1% |
三个结论：
1. pdfplumber 不是解析器，是文本抽取器。它在版式 PDF 上 47.3% 的阅读顺序正确率意味着双栏论文会被拼成一句前言不接后语的废文。把它当解析主力是 RAG 的一号事故来源。它在问答级只有 40.1%，比其他方案低了一半。
2. 表格是共同的软肋，但程度有别。非嵌套表格大家都能到 82–90%，一旦出现跨页表头和合并单元格，除了 MinerU 72.7% 外全部跌到 60% 以下，olmOCR-2 甚至只有 51.2%。合并单元格不是技术难点，是它没被做优先。
3. 阅读顺序比 OCR 准确率更影响 RAG。olmOCR-2 的 OCR 检出率不错（95.6%），但它在版式 PDF 上排序 93.2%，直接把混合页完整率拖到 80.2%，问答完整率比 MinerU 低 7.6 个百分点。文字都对，顺序错了，模型照样答错。
还有一条容易被忽略的：页眉页脚是隐形的检索污染源。16.4% 的误入率听起来不高，但一页三行页眉页脚意味着每 8 段里就有 1 段被注入噪声，而切分后它们会混进相邻的内容块里。pdfplumber 的 40.1% 问答完整率，一半要归功于这里。
三、按文档组成选，不要按”最强”选
| 你的文档长什么样 | 建议 | 理由 |
|---|---|---|
| 扫描件 / 图片为主 | MinerU 2.0 | OCR 与版面还原一体的综合最优，支持中英混排 |
| 含大量表格的规范 PDF | MinerU 或 PP-StructureV3 | 表格还原能力强，后者中文表格略优 |
| 版式规整的学术文本 | Marker | 速度极快，阅读顺序足够，成本低 |
| 重点看 OCR、版式简单 | olmOCR-2 | 噪声与低质量扫描件鲁棒，但版式弱 |
| 只做全文文本检索、无 RAG | pdfplumber | 轻量、无依赖，前提是接受阅读顺序混乱 |
我们内部现在的组合是双路并行 + 路由：按页面特征判定，扫描件走 MinerU，版面规整、纯文本或表格走 PP-StructureV3。不要试图用一个解析器吃下所有文档，那是 RAG 最常见的浪费。
顺带说一个经验：路由规则可以很简单。我们用的一条就是”页面无文本层或文本层少于 200 字符 → 走 OCR 路线”，一条规则就解决了大部分分派问题，不需要上模型判定。
四、解析之后别忽略的四个动作
- 页眉页脚与页码必须剥离。把它留在正文里，等于给每段注入”第 X 页 / 文档编号”这种固定噪声，直接影响语义向量。我们补上这一步后同样内容上的问答完整率涨了 3 个百分点左右。
- 表格转 markdown 之后仍要保留一份 HTML。LLM 在 markdown 表格上的表现稳定低于 HTML 表格，复杂表格尤其明显；检索阶段也可以用两路召回。
- 统一对解析产物做一次过滤。删掉”目录页””致谢””参考文献表”这类模式化段落，它们占长度不占信息。
- 把”未能解析的页”记成指标。解析是管线的入口，入口漏 5%，下游所有指标的提升都被死死压住。这个数字应该出现在你的看板首页，而不是某个日志文件里。
总结
110 份文档测下来的答案是明确的：文档解析是 RAG 的地基，不是附加工序。MinerU 2.0 综合最稳，PP-StructureV3 在中文表格上接近，Marker 适合规范文本追求吞吐，而 pdfplumber 只适合无检索、无 RAG 的轻量文本抽取场景。
如果你现在的 RAG”答不全”，先别急着换向量库——回去看看入口的阅读顺序、表格还原率和页眉页脚剥离率。地基一旦修好，你们团队已经调过的那些参数才会重新开始发挥。
最后一个判断：这一层的工作短期不会消失，只会被更好地封装。工具会变强，但”你的文档长什么样”这件事只有你知道，路由和验收永远是你的活。
互动提问：你的知识库有没有统计过”解析失败页”的比例？很多团队以为 100% 解析成功，其实这一栏从来没被看过。
互动提问：如果要为了合并单元格表格换一次解析器，你愿意改多少代码、迁移多少存量数据？这个成本你算过吗？
— IMAI 编辑部 | 2026-10-27