RAG 真正拉开差距的，可能是文档解析

很多人做 RAG，最容易上头的一步，就是一上来先卷后面。

模型名字先看起来，Embedding 先换起来，Chunk 先切起来，检索参数先调起来，提示词也先改起来。

忙活半天以后，系统还是不太对。

问的时候发飘，召回的时候不准，总结的时候总差一口气。

这种时候，人很自然就会继续怀疑模型。

可我最近越来越强烈的一个感觉是，很多项目其实不是输在后面。

而是输在第一步喂数据。

一份 PDF，你打开的时候看着很正常。

可一旦它进了知识库、RAG 或者 Agent 的链路，事情就变了。

标题层级乱了，双栏顺序错了，表格断了，公式没了，图注和正文脱开了，扫描件里还混着一堆 OCR 噪声。

表面上你是在给模型喂文档，实际上你喂进去的，常常已经是一份被破坏过的内容。

后面你再怎么调模型、改检索、补提示词，也多少会有一种使不上劲的感觉。

所以我这次看到 MinerU 这个项目的时候，停下来的点不只是它火。

而是它碰到的，刚好就是很多人做 RAG 时最容易忽略、但又特别影响结果的那一步。

先把项目说清楚

先把地址放前面。

它的 GitHub 在这里，https://github.com/opendatalab/mineru。

官网和在线体验入口在这里，https://mineru.net/。

如果你平时经常要处理 PDF、Word、PPT、Excel、图片、扫描件，这两个链接可以先存一下。

因为 MinerU 干的事情很直接，就是把这些原本更适合人眼读的文档，整理成模型后面还能继续用的结构化结果。

常见输出是 Markdown 和 JSON。

表格能尽量保住结构，公式可以转成 LaTeX，扫描件会走 OCR，多栏和复杂排版也会尽量按正常阅读顺序整理。

你如果只是把它理解成 PDF 转 Markdown，其实有点低估它了。

它更像是在做一层文档翻译。

把面向人阅读的复杂材料，尽量翻译成面向模型理解的输入。

这一步看着不性感，但真到自己接知识库的时候，太重要了。

真上手以后，难点根本不在“把字弄出来”

很多人没做过这件事时，会觉得文档解析不就是把字弄出来吗。

真上手以后你就会发现，难点根本不在那里。

最先坑人的，通常是阅读顺序。

人看双栏论文、研报、说明书的时候，很自然就知道先看哪一列，哪句图注跟的是哪张图，哪个标题属于下面那段话。

模型没有这种直觉。

如果一篇双栏文档在解析时就拼错了顺序，那后面的切块、召回、问答，很容易从第一步就开始歪。

再往下一个坑，是结构层级。

很多资料真正有用的，不只是某一句话，而是它放在什么章节下面，前后跟着什么解释，是不是结论，是不是表格后的补充说明。

这些关系一旦没保住，最后虽然也会产出一份 Markdown，但那更像是拆散后的文字，不是一份还能被模型顺着理解的文档。

还有一种特别现实的问题，就是复杂元素最容易掉链子。

财报和研报里最关键的信息，往往在表格里。

技术文档的约束条件，很多时候藏在图注和示意图说明里。

科研论文真正有密度的内容，也常常挤在公式、图表和图表附近那几段话里。

这些东西如果在入口处就被拆坏，后面回答再像样，也总会差那一口气。

那种“总差一口气”的感觉，到底差在哪

这种差一口气的感觉，其实很具体。

比如公司制度库里明明写了报销规则，结果一问就答偏，因为真正关键的限制条件藏在表格备注里。

比如你把一堆研报丢进知识库，模型能跟你聊行业趋势，却一到核心数据就开始含糊，因为表格在解析时已经散掉了。

再比如你拿技术手册去接 Agent，希望它自动读文档、查参数、执行下一步，结果它连前置条件和警告说明都没读完整。

这时候你会特别容易怀疑模型。

怀疑它理解不行，怀疑它幻觉重，怀疑它检索不稳定。

但有些问题，说到底根本还没轮到模型发挥。

因为它吃进去的第一口东西，就已经不够完整了。

我后来才慢慢意识到，很多人以为自己是在做模型效果优化，其实更早就在做文档善后。

而 MinerU 这种工具，碰到的正好是前面这层脏活。

它在整条链路里，到底放在哪

MinerU 不是帮你回答问题的。

它是先把文档整理到一个模型比较能接得住的状态。

从这个角度看，它就不只是一个 PDF 转 Markdown 工具了。

它更像是知识库、RAG、Agent 在入口处的一层预处理。

先把文档清一遍，再让后面的模型去读、去切、去检索、去总结。

如果把整条链路拆开看，这个位置就更明显了。

最前面是原始文档。

中间是解析和结构化。

后面才是切片、Embedding、入库、召回、问答，或者继续往下接 Agent。

很多人愿意在后半段花很多时间，研究 Chunk 怎么切，重排怎么做，提示词怎么写，回答怎么兜底。

这些当然值得做。

但前面那道工序如果一直比较糙，后面其实一直是在修补一个先天不太完整的输入。

你可以把 MinerU 理解成一层清洗和翻译。

它不是替你做判断，也不是替你做总结。

它只是尽量把原始文档翻译成机器比较容易接住的形式。

这件事不耀眼，但特别像地基。

地基没打平，楼上每一层都会晃。

这也是为什么我觉得，MinerU 真正值钱的地方，不在于功能多，而在于它碰到的是最前面那一步。

怎么用，其实没那么复杂

很多朋友看到这里，最关心的还是怎么用。

这块其实没那么复杂。

如果你只是想快速感受一下效果，最省事的方式就是直接去官网在线跑。

上传一份 PDF 或 Office 文档，先看看它吐出来的 Markdown 和结构化结果长什么样。

如果你已经在自己搭知识库，或者准备把它接进 RAG 流程，本地命令行会更顺手一些。

官方文档里给的入口很直接。

安装可以先用

pip install "mineru[all]"

跑单个文档时，最常见就是

mineru -p <input_path> -o <output_path>

如果你机器资源一般，也可以走更轻一点的后端。

再往前一步，你就可以把它放进自己的知识处理链路里了。

先用 MinerU 把 PDF、Word、PPT 这些资料转成更干净的 Markdown 或 JSON，再去做切片、入库、检索、问答。

如果你后面还想接 Agent，其实也是同一个道理。

先把文档变成机器更容易读的样子，后面那一串动作才更稳。

我会怎么测它到底行不行

如果你是自己折腾着玩，我反而建议别一上来就搭大工程。

先拿三类最容易翻车的材料去测它。

第一类，双栏论文。

看它最后吐出来的内容，顺序是不是对的，标题和正文有没有串行。

第二类，带复杂表格的财报、研报或者报价单。

看表格有没有散，备注有没有丢，关键数字和说明是不是还对应得上。

第三类，扫描版 PDF，最好再夹一点图片说明、页脚和图表。

看 OCR 噪声重不重，图注有没有乱挂，页眉页脚这些脏信息有没有被尽量清掉。

跑完以后，不要只盯着它有没有成功输出一个 Markdown 文件。

你要直接问几个更实在的问题。

这份结果，我愿不愿意拿去继续切片。

我愿不愿意把它直接送进知识库。

我敢不敢把它交给后面的 Agent 去读。

我觉得这种测试比空谈功能有用得多。

因为你最后要的不是一个看起来很强的介绍页。

你要的是，文档进来以后，后面那条链路到底能不能更稳。

别把它神化，但也别低估它

还有一点我也想顺手说清楚。

MinerU 不是那种装上就万事大吉的银弹。

复杂文档解析这件事，本来就很难。

有些版式特别奇怪的 PDF，有些扫描质量很差的材料，有些跨页特别狠的大表格，依然可能会出问题。

所以我自己的判断不是，装了 MinerU 以后你就不用再看结果了。

而是你终于有了一层更像样的前处理基础。

很多时候，我们需要的不是完美。

而是把原来七十分的脏输入，尽量往八十五分、九十分推。

只要这一层抬上去，后面的知识库、RAG、Agent 体验就会一起往上走。

7.3 万 Star 背后，真正变的是什么

我觉得这也是 MinerU 7.3 万 Star 这件事真正值得琢磨的地方。

这个数字背后，不只是一个项目火了。

更像是越来越多人都碰到了同一个问题。

以前文档解析更像一段不太起眼的小工序。

谁做 OCR，谁做 PDF 提取，谁做格式转换，很多时候只是技术链路里的边角活。

但这两年不一样了。

做知识库的人多了，做 RAG 的人多了，做 Agent 的人也多了。

大家都开始往系统里喂一堆 PDF、报告、手册、财报、课件、制度文档。

这个时候，文档解析一下就被前移了。

因为只要原始资料不够干净，模型再强，也得在一份顺序混乱、结构残缺、信息断裂的内容上硬干活。

所以我现在越来越觉得，很多 RAG 的上限，真不一定先卡在模型。

它很可能更早就卡在文档有没有先被整理好。

MinerU 被这么多人盯上，不是因为大家突然都对 PDF 转 Markdown 这件事特别兴奋。

而是因为真到自己开始搭系统的时候，都会碰上这一关。

你可以不立刻折腾它。

但如果你正在做知识库、做 RAG、做 Agent，或者平时手里就有很多 PDF 和 Office 文档要交给模型处理，我觉得这类工具早晚会进入你的工作流。

因为到最后，很多人比的已经不是谁模型名字更响。

而是谁先把文档这口数据饭做好了。

如果你觉得这篇内容有价值，欢迎点个赞、点个在看，也欢迎转发给更多朋友。

我是AI杨侦探，持续记录 AI、技术、产品和产业变化里那些真正值得看、值得想的事。

谢谢你读到这里，我们下次见。