很多朋友第一次接触 PDF 解析脑子里想的其实很简单。不就是把 PDF 里的字抠出来吗最多再加一个 OCR。如果你做过知识库或者把一堆 PDF 丢进过 RAG 流程里你大概率会很快发现事情没有这么简单。文本是出来了但顺序乱了。公式变形了。表格结构没了。两栏论文被揉成一栏。页眉页脚混进正文。图片说明和图片分家。模型看着一堆抽出来的字回答得一本正经但你知道它其实是在废墟里找路。我以前也容易把这个问题想轻了。因为从人的角度看PDF 是很稳定的。打开一页论文标题在哪里正文从哪读到哪图表说明归谁公式属于哪一段我们一眼就能看明白。可机器看到的不是这个。机器看到的是一堆位置、区域、像素、文本块、公式块、表格块还有很多看起来像正文但其实不是正文的东西。所以真正难的地方不是 OCR 准不准也不是某一页能不能转成文本。而是我们得先让机器重新理解这份文档。哪些是正文哪些是页眉页脚哪些表格应该保留结构哪些公式不能被拆散图片和说明文字应该怎么绑定两栏论文应该按什么顺序读。MinerU 这篇论文就是在这个问题上往前走了一步。它不是又做了一个 PDF 转 Markdown 工具是在回答一个更底层的问题当 PDF 不是普通文本而是一堆复杂文档结构的时候你怎么把它变成机器真的能用的内容这就是 MinerU 这篇论文的起点。论文PDF下载链接https://arxiv.org/pdf/2409.18839论文题目叫 MinerU, An Open-Source Solution for Precise Document Content Extraction。2024 年 9 月 27 日挂在 arXiv 上作者团队来自上海人工智能实验室。它要做的不是单个 OCR 模型也不是单个表格模型而是一整套开源文档内容抽取方案目标是把 PDF 变成 Markdown 或 JSON。注意这个差别不是把字抠出来是把内容抽出来。这两个东西差得很远。真实世界里的 PDF 根本不是一种东西论文里有一张表很有意思它列了 MinerU 评估时考虑的文档类型。不是只有论文也不是只有扫描件而是研究报告、标准教材、图文教材、学术论文、画册、PPT、试卷、图文试卷、历史文档、笔记、标准书籍。你想想看这里面每一种 PDF 的难点都不一样。研究报告可能有横向大表格合并单元格双栏和单栏混排。教材里可能有复杂公式矩阵图文穿插。试卷里有题干、选项、图、公式、页眉页脚。PPT 转成 PDF 以后背景颜色、文字框、图片和装饰元素全部混在一起。历史文档甚至可能是竖排、繁体、从右往左读。人看这些东西的时候会自动补很多上下文机器不会。机器要先知道哪里是标题哪里是正文哪里是表格哪里是图片哪里是图片说明哪里是公式哪里是页码哪里应该丢掉。这就是为什么普通 OCR 不够。OCR 很擅长回答一个问题图里有什么字。但复杂 PDF 需要回答的是另一组问题这些字属于哪个区域应该按什么顺序读公式应该怎么保留表格的结构怎么还原图片说明跟哪张图绑定页眉页脚是不是噪声。论文里还给了一些数据挺能说明这件事。它们为布局检测做了大约 21K 的标注数据。公式检测这块标了 24,157 个行内公式和 1,829 个展示公式来自 2,890 页中英文论文、教材、书籍和财报。这些数字不是为了显摆数据量。它们是在告诉你PDF 抽取难不是因为单个模型还不够聪明而是因为真实文档本来就长得太不一样了。你拿一个只在论文版式上表现不错的模型去处理教材、试卷、财报、PPT它很容易就懵。所以 MinerU 的思路不是押宝一个万能模型而是做一套工程系统。先判断文档拆不同区域用不同模块处理不同内容再把结果重新组织起来。MinerU 的四阶段其实就是它的实现方法论文里 Figure 1 是整套流程图。它把 MinerU 拆成四个阶段文档预处理内容解析内容后处理格式转换。图注论文 Figure 1 展示 MinerU 的四阶段处理流程。这个地方很容易被写成流程说明书。但坦率的讲如果只记住四个名词意义不大。真正要看的是每一步在解决什么问题。第一步文档预处理。它解决的是别急着 OCR先搞清楚这个 PDF 到底是什么状态。是不是加密文件是不是需要密码是文本型 PDF 还是扫描型 PDF语言是什么页面大小和页数是什么。这一步听着不起眼但很关键。因为文本型 PDF 和扫描型 PDF 的处理方式完全不同。文本型 PDF 可以用 PyMuPDF 这类库直接读文字速度快准确度也高。扫描件就不行必须走 OCR。还有一种更烦的情况PDF 里看起来有文字但复制出来是乱码这种也得提前识别否则后面全线污染。第二步内容解析。这是整篇论文信息量最大的地方。MinerU 使用 PDF-Extract-Kit 里的模型库把页面里的不同区域识别出来再交给不同模块处理。布局检测负责区分标题、正文、图片、图注、表格、表注、公式、页眉页脚这些区域。公式检测和公式识别负责公式。表格识别负责表格结构。OCR 负责普通文本区域。你会发现它不是把整页丢给 OCR 然后祈祷结果正确。它更像是先把一张复杂的地图分区再派不同的人去处理不同地块。多栏论文最怕什么最怕读错顺序。所以要先做布局检测。公式最怕什么最怕被当成普通字符识别结果变成乱码。所以要先检测公式区域再做公式识别。表格最怕什么最怕只有字没有行列关系。所以要用表格识别恢复结构。普通文本当然可以 OCR但前提是你先把它从公式、图片、表格这些区域里分出来。我觉得这是 MinerU 这篇论文最适合小白理解的地方。复杂文档不是一种内容所以不能用一种方法硬怼。第三步内容后处理。这一步是整篇文章的转折点。因为很多人会以为模型识别完了事情就结束了。其实不是。模型只是把很多区域和内容识别出来了但这些区域可能重叠可能包含彼此可能顺序不对可能还有页眉页脚这种噪声。你真正要的不是一堆识别结果而是一份人能读、机器也能继续处理的文档。这就是后处理的价值。论文里 Figure 5 展示了 BBox 重叠处理前后的效果。Figure 6 展示了区域排序也就是怎么把页面里的不同块重新组织成符合阅读顺序的结果。图注论文 Figure 5 展示 BBox 重叠处理前后的差异。我这里顺手把 Figure 7 也放上来因为它更直观。你可以看到从 layout 到 spans再到 Markdown真正有价值的不是某一步识别得漂亮而是能不能拼成一份还算可读、可用的结果。图注论文 Figure 7 展示从 layout、spans 到 Markdown 的端到端效果。这也是很多 PDF 解析工具最容易翻车的地方。你识别到了文字不代表读者能读识别到了表格不代表结构还在识别到了公式也不代表它能被正确放回正文。所以 MinerU 的后处理不是一个可有可无的收尾步骤。它是在把识别结果从「模型看见了」变成「内容可用了」。第四步格式转换。这一步反而不用讲太重。MinerU 会把处理后的中间结构转成 Markdown 或 JSON。对读者来说理解到这里就够了Markdown 更接近人类阅读和知识库导入JSON 更适合程序继续处理。也就是说MinerU 最终交付的不是一张看起来对的截图而是一份能继续进入下游流程的结构化内容。到这里四阶段就闭环了先判断文档状态再拆内容再修顺序和噪声再转成可用格式。这就是它的实现方法。那它效果怎么样论文没有只停留在架构图上它对几个核心模块做了实验。这个地方我建议不要被指标吓到。mAP、AP50、AR50、CDM 这些指标对普通读者确实不友好。你只需要抓住一个问题实验在验证哪一步。先看布局检测。前面我们说复杂 PDF 的第一件大事是把页面区域分清楚。论文 Table 3 对比了 DocXchain、Surya、360LayoutAnalysis 等开源模型。MinerU 使用的 LayoutLMv3-Finetuned 模型在学术论文验证集上 mAP 是 77.6AP50 是 93.3在教材验证集上 mAP 是 67.9AP50 是 82.7。对比下来它明显高于其他开源模型。图注论文 Table 3 展示布局检测模型对比结果。这个结果验证的是前面那句话如果你想处理复杂文档第一步区域划分就不能太差。否则后面的 OCR、公式识别、表格识别全都会被拖下水。再看公式检测。公式是学术文档和教材里特别麻烦的东西。尤其是行内公式视觉上很容易和普通文本混在一起。论文 Table 4 里YOLOv8-Finetuned 在学术论文验证集上 AP50 是 87.7在多源验证集上 AP50 是 82.4而 Pix2Text-MFD 分别是 60.1 和 58.9。这个差距说明专门针对多样化公式数据训练公式检测模块是有价值的。然后是公式识别。论文 Table 5 用 UniMER-Test 比较了 Pix2tex、Texify、Mathpix 和 UniMERNet。这里最值得看的是 CDM 指标UniMERNet 是 0.968Mathpix 是 0.951Pix2tex 是 0.636Texify 是 0.755。我不想把这篇文章写成指标解读所以数字讲到这里就够了。只要记住实验段在证明三件事。布局检测更稳说明它能更好地先把页面结构拆出来。公式检测和公式识别更强说明它没有把公式当普通文本糊弄过去。端到端可视化结果能跑通说明这些模块组合起来以后确实能产出 Markdown 结果。这就回到了前面的主线MinerU 不是靠一个模型从头猜到尾而是把复杂文档拆成多个问题再分别处理再重新组织。它不是万能工具但方向是对的说实话我自己挺喜欢这篇论文的地方是它的工程性。它没有把 PDF 解析包装成一个神秘的端到端魔法也没有说一个模型能搞定一切。它承认真实文档很杂承认不同文档类型会带来不同问题所以干脆把流程拆开用模型做模型擅长的事用规则处理规则更适合的事用数据工程去补真实世界里的坑。这事儿听着不有趣但很多真正能用的系统都是这么长出来的。当然也别把 MinerU 神化。论文里明确说了它当前主要识别和处理中英文文档其他语言质量不保证。它展示了核心模块和多类型文档的可视化效果但这不等于所有 PDF 场景都能完美处理。论文的未来工作也写得很清楚后面还要继续增强核心组件提升速度和易用性构建更系统的 benchmark。所以更准确的理解是MinerU 不是一个「万能 PDF 神器」。它更像是在告诉我们PDF 解析这件事已经不能再被当成一个小工具问题了。在 LLM 和 RAG 变得越来越常见以后文档数据会越来越重要。网页数据不够企业内部文档、论文、报告、教材、财报、合同、试卷这些东西都在 PDF 里。你想让模型真正用上这些知识就得先把它们变成可靠的、结构清楚的内容。这一步如果烂了后面的智能就会建立在一堆错乱文本上。屏幕前的你如果以后再看到 PDF 转 Markdown、文档解析、知识库导入这种词可能可以先停一下。别急着问它 OCR 准不准。先问另一个问题。它真的理解这份文档是怎么组织的吗这才是 MinerU 这篇论文真正想聊的事。