深入解析 MinerU2.5-Pro：当数据工程开始统治文档解析赛道

📘 原文信息

• 标题：MinerU2.5-Pro: Pushing the Limits of Data-Centric Document Parsing at Scale
• 作者：Bin Wang, Tianyao He, Linke Ouyang, Fan Wu 等（Shanghai AI Lab + Peking University + Shanghai Jiao Tong University + SenseTime）
• 发布日期：2026-04-10（v2）
• 原文链接：https://arxiv.org/abs/2604.04771 ↗
• 代码：https://github.com/opendatalab/MinerU ↗
• 模型：https://huggingface.co/opendatalab/MinerU2.5-Pro-2604-1.2B ↗

---

一、为什么这篇值得读？#

文档解析（PDF → 结构化 Markdown/HTML）是 LLM 训练数据流水线和 RAG 系统的关键基础设施。过去两年，赛道的进步主要来自两件事：VLM 端到端替代传统 pipeline、原生分辨率视觉编码器把”看清大图”这件事从研究问题变成工程问题。但 2026 年 Q1 之后，一个奇怪的现象开始浮现：架构和参数规模完全不同的 SOTA 模型，在同一批”硬样本”上犯几乎一样的错。

MinerU2.5-Pro 这篇论文给出了一个非常”反直觉但合理”的回答：当前文档解析的性能瓶颈，根本不在模型架构，而在训练数据。为了证明这一点，作者故意把 MinerU2.5 的 1.2B 参数架构原封不动，只重做数据和训练流程——结果在新建的 OmniDocBench v1.6 上拿到了 95.69 的总体分，比同架构基线高 2.71 分，击败了 Gemini-3 Pro、Qwen3-VL-235B 这些参数量 200×+ 的大模型。

本文按原文章节做一次重述与解读，重点是：

1. 怎么证明瓶颈在数据不在架构？（第 1 节）
2. Diversity-and-Difficulty-Aware Sampling（DDAS）怎么同时兼顾多样性和难度？（第 3.1 节）
3. Cross-Model Consistency Verification（CMCV）怎么用”多模型投票”代替单模型不确定性？（第 3.2 节）
4. Judge-and-Refine 标注流水线怎么突破”硬样本自动标注必然有噪声”的天花板？（第 3.3 节）
5. 三阶段渐进训练（预训练 / 高质量 SFT / GRPO）怎么和数据质量分层对齐？（第 4 节）
6. OmniDocBench v1.6 的两项关键修正是什么？（第 5 节）

下面我们按文章顺序逐节看。

二、问题诊断：瓶颈在数据，不在架构#

2.1 一个反直觉的观察#

作者先把市面上主流的 SOTA 文档解析模型拿出来——参数规模从 1B 到 200B+，架构从解耦两阶段到端到端 VLM 各异——在同一批真实 PDF 上做错误归因。结果非常有意思：这些架构完全不同的模型，在最难的那批样本上呈现高度一致的失败模式。

这个现象有两层推论：

• 架构不是瓶颈——否则不会”大家都在不同地方错，但偏偏都错在同一页上”。
• 训练数据是瓶颈——既然失败模式跨架构一致，说明底层根因在大家共享的”训练数据配比 + 标注质量”上。

💡 小吴笔记：这是一个非常漂亮的研究框架——不直接做新模型，先证明”现有 SOTA 的失败模式是共享的”，把问题归因到一个可被工程化的维度。在 2026 年的多模态赛道，这种”先归因，再工程”的论文越来越值钱，因为架构红利正在被吃干。

2.2 数据瓶颈的两个具体维度#

归因之后，问题被进一步拆成两个具体维度：

1. 覆盖度不足：MinerU2.5 原本的训练数据不足 10M 页，且分布严重集中在高频类别（标准学术论文、单栏报告），长尾场景——复杂嵌套表格、密集公式布局、非典型多栏——严重欠采样。
2. 标注质量悖论：最有训练价值的”硬样本”，恰恰是自动标注最容易出错的样本。结构复杂的表格标注和密集公式的 LaTeX 转写都是高错误率操作，噪声直接通过 SFT 灌进模型。

这两个维度相互纠缠——光堆数据量不够，会放大偏差；光加标注预算也不够，因为堆在错的位置。

2.3 评测协议同样有盲点#

除了数据，作者也指出 OmniDocBench v1.5 作为主流评测协议有两个系统性问题：元素匹配偏差（不同输出粒度的模型被不公正地惩罚）和硬样本覆盖不足（顶模型在标准样本上已经饱和，分不出高低）。这两点会在第 5 节展开。

---

三、Data Engine：把数据工程做成可复用的流水线#

为了系统化解决上面的三个维度，作者设计了一个三层协同的 Data Engine：

三模块形成粗到细的质量递进：先扩量（DDAS）→ 再分层（CMCV）→ 最后精修（Judge-and-Refine）。最终数据规模从 <10M 扩到 65.5M 页，其中 192K 高质量硬样本走专家标注。

3.1 DDAS：在两个粒度上同时兼顾多样性和难度#

长尾分布是文档训练数据的天然属性：标准论文 vs. 复杂嵌套表格的样本比例可能是 100:1。如果直接按原始分布采样，模型永远在简单样本上过拟合、在硬样本上学不到东西。

DDAS 的设计有两个关键：

• 页面级聚类 + 难度调整：用 ViT-base 把 PDF 池嵌入到 512 维向量空间，K-Means 聚类后，对每个 cluster 跑一次 CMCV 拿到难度分布。简单样本主导的 cluster → 降权；难度分布多样的 cluster → 升权；非目标语言 / 空白页主导的 cluster → 直接过滤。
• 元素级再聚类 + 再难度调整：从页面级候选集出发，用 MinerU2.5 和 PaddleOCR-VL 的 layout detection 抽出文本 / 公式 / 表格元素，每个元素类型独立聚类 + CMCV 难度标注。

最终的采样权重 = 聚类多样性 × 难度信息量的联合函数。最终输出一个 4 个子任务（layout / text / formula / table）都覆盖、且多样性与难度平衡的 SFT 数据集。

💡 小吴笔记：DDAS 本质上是把”难样本挖掘”从一维问题（“找难的”）升级成二维问题（“找难的 且 多样的”）。这是经典的 active learning / query-by-committee 思路——但作者把它和聚类结合，并跨两个粒度（页面 + 元素）跑，工程上做得比多数论文细很多。

3.2 CMCV：用多模型投票给”难度”打标签#

传统做法（IMIC、UACS）用单个模型的多次推理一致性来估计难度——本质上只能反映”模型自己不确定”，分不清”模型在这道题上特别菜”和”这道题是真的难”。

CMCV 的设计很巧妙：用 3 个异构模型（MinerU2.5、PaddleOCR-VL、Qwen3-VL-30B）独立标注同一批样本，然后按两两一致性分类：

每个难度档对应不同的下游处理：Easy/Medium 直接拿外部共识当标签；Hard 走 Judge-and-Refine 流水线。Medium 样本稀缺但最值钱——所以 DDAS 采样时主动上调 Medium 比例。

💡 小吴笔记：CMCV 是整篇论文最有方法论价值的一节。它把 ensemble-based active learning 的”委员会分歧”原则用到了工程可落地的程度——而且它不仅用来”挑样本”，还用来”出标签”，是闭环的。比起单模型不确定性，CMCV 的优势是它能直接区分”模型特异短板”（可被外部共识修）和”真难题”（需要人工介入）——这直接决定了后续标注预算的分配。

3.3 Judge-and-Refine：让硬样本的标注也能自校正#

Hard 样本是数据工程的最终难点——三方模型都不一致，传统自动标注必然引入噪声。直接灌进 SFT 等于”教错”。作者的做法分两步：

第一步：自动 Judge-and-Refine 循环

朴素的自反思有系统偏差：模型让它”检查自己输出”时，倾向于确认自己的结果是对的。根因是跨模态映射不对称——模型很擅长”图像 → 结构化文本”，但很难在脑海里”结构化文本 → 视觉”。对 LaTeX 公式和 HTML 表格这种结构化输出尤其严重。

作者的解法：render-then-verify。

1. 把 LaTeX 公式编译出来、把 HTML 表格渲染成图
2. 把原图 + 渲染图作为配对输入，连同 judge-and-refine prompt 一起送给一个独立的强 VLM（这里用 Qwen3-VL-235B——刻意避开 CMCV 模型池，避免系统性偏差）
3. 视觉对比 → 错误定位 → 定向修正 → 重新渲染验证 → …

这一步的设计有两个巧思：

• 闭合了结构化文本 → 视觉的缺失映射：模型不再靠”脑补”，而是直接看图。
• 渲染的”错误放大”效应：很多结构化错误（漏对齐符号、未闭合标签）在文本域难以察觉，但渲染后会变成显著的视觉异常或布局塌缩，肉眼一眼就能看出。

第二步：定向专家标注

经过自动循环后，还剩下一批”超复杂”样本进入专家标注。但专家预算有限，作者按两个优先级分配：

1. 修正效率：Judge 已经定位错误但 Refine 改不对的样本优先——人只需要在已定位处做局部修正，性价比最高。
2. 边际影响：在修正效率的基础上，再优先给”当前模型最弱”的子任务类别（由 CMCV 分歧模式判断）。

整个流程相当于一个梯度式预算分配：先用自动流水线吃掉 80% 的 hard 样本，剩下 20% 用最高 ROI 的方式扔给人。

💡 小吴笔记：render-then-verify 这一招是整篇论文最具工程巧思的设计。它本质上是说：“你不要让模型在脑海里做它不擅长的事——你把那个能力外化成渲染，再让模型做它擅长的视觉对比。“这种”用工程换智能”的思路在 LLM 时代越来越常见——Anthropic 的 Constitutional AI、DeepMind 的 FunSearch 都属于这一类哲学。

---

四、三阶段渐进训练：让数据和训练目标对齐#

光有数据还不够，怎么”按数据质量分层”训练？作者设计了三阶段，每阶段对应 Data Engine 产出的一个数据质量层：

4.1 Stage 1：把”量”和”质”同时吃下#

Stage 1 用的是 Easy + Medium 样本，共约 65.5M：

• 文本识别 21M
• 版面分析 14M
• 公式识别 13M
• 表格识别 11.5M
• 图像分析 6M

子任务比例是按”OmniDocBench 综合分的权重 × 基线模型在该子任务的性能缺口”动态调出来的——不是均匀分配，是”哪里差补哪里”。

训练配置上：ViT 学习率 1e-4，LLM/MLP 学习率 1e-3，batch size 256，1 epoch。相比 MinerU2.5 原版的 6.9M × 2 epoch，数据量提升近一个数量级，质量也通过 DDAS + CMCV 系统性提升。

4.2 Stage 2：在不忘记基础能力的前提下啃硬骨头#

如果直接在 192K 硬样本上微调，模型会灾难性遗忘 Stage 1 学到的”简单样本分布”。作者用 replay data 缓解，但不同子任务的 replay 比例差异极大：

为什么差异这么大？因为各子任务的”硬样本量”和”基线表现”不同。文本识别的硬样本稀少，过量 replay 才能保住泛化；版面分析的 hard 样本多且 Stage 1 已经很强，少 replay 即可。

学习率降到 5e-5（比 Stage 1 低一个数量级），保护 Stage 1 学到的基础能力，只在 hard 决策边界上做微调。

4.3 Stage 3：用 GRPO 把训练目标对齐到评测指标#

前两阶段都是 SFT，优化的都是 token-level 的交叉熵——这和最终评测的序列级 / 结构级指标（edit distance、CDM、TEDS、IoU）之间有 gap。Stage 3 用 GRPO 桥接这个 gap：

• 每个 prompt 采样 G=16 个 rollout
• reward 直接用评测指标（edit distance / CDM / TEDS / IoU），不用单独训 reward model
• 用 DAPO 的 clip-higher + dynamic sampling 保证训练稳定

训练数据来自 Stage 2 模型的 rollout，按 reward 分布筛选：reward 太高（模型已饱和，没学习信号）和 reward 太低（样本太难或标注错）的都丢掉，留中间区段——最大化有效 policy gradient 信号。

💡 小吴笔记：GRPO 用评测指标当 reward 这一步很关键——但要小心，reward 必须是和评测同分布的，否则 GRPO 会把模型优化到一个”看起来指标好、但其他维度退化”的状态。作者这里的解法是 reward 设计和评测完全同源，且筛掉了”过难 / 标注错”的样本，避免 reward hacking。

---

五、OmniDocBench v1.6：评测协议本身也要修#

论文的第三个贡献是评测协议升级。OmniDocBench v1.5 在 2025-2026 年成为文档解析事实标准后，作者发现它有两个系统性问题：

5.1 问题 1：元素匹配策略有”粒度偏差”#

v1.5 用固定粒度的 1:1 元素匹配——只要模型输出的切分粒度和 GT 不一样，分数就掉。但内容可能完全正确。

两个典型场景：

• 多行公式：GT 标成 1 个块跨 k 行；模型输出 LaTeX 完全一致，但切成 k 个块 → v1.5 直接打零分。
• 密集文本块：GT 是一个 text block，模型按行预测（甚至识别成 table） → v1.5 也打零分，因为没”text 元素”可以匹配。

这种”格式偏好”导致不同系统不可比——一个倾向切细的模型天然吃亏。

5.2 问题 2：硬样本几乎缺席#

作者用 Data Engine 的 CMCV 给 v1.5 评估集打了难度标签，结论是：v1.5 里 Hard 标签的样本几乎不存在。这就解释了为什么 2026 Q1 之后顶模型在 v1.5 上的分数越来越挤——不是大家变强了，是 benchmark 太简单。

5.3 修正 1：Multi-Granularity Adaptive Matching（MGAM）#

核心原则：GT 不动，只在预测侧搜索最优切分粒度。

具体三阶段：

1. 直接二部匹配：原粒度 Hungarian 匹配，得候选分 S1
2. 预测侧按换行符切分 + 匹配：以 LaTeX 的 \\ / \newline 等分隔符切细，再匹配，得 S2
3. 分区枚举 + 匹配：枚举所有相邻子序列的有序分区（即”哪些相邻元素合并、哪些分开”），对每个分区做匹配，取最优 S3

最终匹配 = argmax(S1, S2, S3)。这样不管模型输出粒度如何，都能找到最优匹配。

对密集文本，把同一算法用在文本元素上（相似度用 edit distance）；如果模型把文本识别成 table，反过来转成纯文本再参与匹配，避免格式偏好导致的系统性惩罚。

5.4 修正 2：Hard 子集 + 三档评测#

新增 296 页 Hard 子集（覆盖复杂嵌套表、密集公式、非典型版面），由专业团队标注并互检。所有 Hard 子集样本在训练各阶段都明确剔除（包括 Judge-and-Refine 训练数据），确保评测不污染。

OmniDocBench v1.6 建立 Base / Hard / Full 三档评测协议：

💡 小吴笔记：MGAM 是这篇论文另一个工程巧思。它的哲学是：“评测不应该惩罚’做了正确的事但风格不同’的模型”。这个原则在 NLP 评测圈并不新鲜（BLEU 之后有 sacreBLEU、BERTScore 等），但在文档解析这种”输出结构高度依赖系统设计”的领域里，匹配策略一直是评测的灰色地带。作者把它系统化处理了。

---

六、实验结果：1.2B 打败 200B+#

6.1 端到端文档解析#

Full 榜关键数字（表 2 节选）：

几个值得注意的点：

• Base 子集上，前三名（GLM-OCR 96.19、MinerU2.5-Pro 96.12、PaddleOCR-VL-1.5 95.72）差距 < 0.5 分——饱和。
• Hard 子集上，MinerU2.5-Pro 以 94.08 拉开第二名（GLM-OCR / PaddleOCR-VL-1.5 同 92.01）2.07 分——这是 Data Engine 真正发挥优势的地方。
• Gemini-3 Pro 在 v1.6 上得分 92.85，比 v1.5 上显著上涨——说明 v1.5 之前的”通用 VLM 看起来不如专用模型”有一部分是匹配偏差的假象。但即便修正后，1.2B 的 MinerU2.5-Pro 仍然领先。

6.2 训练阶段消融#

Stage 1 单阶段贡献最大（+1.31），证明 Data Engine 对覆盖度和标注质量的优化是性能提升的主要驱动。Stage 2 在表格识别上贡献最明显（TEDS 90.37 → 92.87，+2.50）。Stage 3 主要拉公式 CDM（96.48 → 97.29，+0.81）——GRPO 直接对齐 task-level metric 的回报。

6.3 元素级单独评估#

为了排除 layout detection 误差的”漏斗”干扰，作者还按 GT layout 把文档图裁出来，单独评测 text / formula / table 三个识别模块。

文本识别（Edit Distance↓，Full）：

文本识别 Edit Distance 相对基线下降 30.5%（0.028 → 0.019）。注意百亿级通用 VLM 在文本识别上和专用模型已经很接近——但端到端模型（DeepSeek-OCR 2、FireRed-OCR）没有 category prior 时退化明显。

公式识别（CDM↑，9 个 benchmark 5 个第一）：

OmniDoc Base 上 CDM 99.20/100，已经接近公式识别的性能上限。Qwen3.5-397B 在手写公式（HWE）上仍然最强，但它在 Chinese 公式上只有 78.24——这就是”大而全的通用模型在长尾上反而不如专用模型”的典型证据。

表格识别（TEDS & TEDS-S↑）：

MinerU2.5-Pro 在 Overall TEDS（91.10）和 TEDS-S（94.48）上都是第一，比 MinerU2.5 基线分别高 +3.16 / +2.31。优势在 Hard 子集上最明显：TEDS 92.46 vs. MinerU2.5 的 88.28，+4.18——Data Engine 的硬样本挖掘 + 专家标注对表格识别贡献最大。GLM-OCR 在 OmniDoc Base 和 CCOCR 上略胜，但跨 benchmark 稳定性不如 MinerU2.5-Pro。

---

七、总结与启示#

回头看 MinerU2.5-Pro 的工作，本质上是在回答一个问题：“当架构红利接近天花板，下一步该往哪走？“。答案是：把数据当成一等公民来工程化。

整篇论文的叙事线非常清晰：

最终结果是：1.2B 参数 + 同架构 + 纯数据工程 = 95.69，击败 200B+ 通用 VLM。

给做数据 / 训练 / 评测的工程师的几点启示#

1. 先归因，再工程。本文最有方法论价值的一步是”先证明现有 SOTA 的失败模式跨架构一致”，再把瓶颈归到数据上。这个套路在很多领域都能复用——当你发现一个赛道陷入”小改进 / 大论文”的怪圈时，先停下来看看根因到底在哪。
2. 数据工程的”协同优化”比”单点优化”重要得多。单独看 DDAS / CMCV / Judge-and-Refine 都不是首创，但把它们组成一个闭环、用难度信号串起采样 / 标注 / 训练三个环节，是这篇工作的真正壁垒。
3. render-then-verify 是个被低估的范式。把”结构化输出”渲染回图像再让 VLM 做对比，比让 VLM 在脑海里做跨模态推理靠谱得多。这个套路在 OCR / 公式识别 / Web agent 等”输出可渲染”的领域都适用。
4. GRPO 用评测指标当 reward 时，要小心”指标分布偏移”。本文的解法是 reward 设计和评测完全同源 + 过滤”过难 / 标注错”样本 + DAPO 稳定技巧。这种”reward hygiene”在 RLHF 时代常被忽略，但一旦上 GRPO 就立刻成为关键。
5. 评测协议本身也是研究贡献。当顶模型在某个 benchmark 上饱和时，正确做法是修 benchmark 而不是继续刷分。本文通过 MGAM + Hard 子集让一个”已经饱和”的 benchmark 重新具备区分度——这个方法论值得所有 benchmark 维护者学习。

局限与未来#

作者也诚实地指出了几个未解决的问题：

• 格式层 + 结构层双重歧义：同一内容可用多种等价形式表达（HTML vs. Markdown 表示同一表格），同一视觉布局可用多种合法元素组合（双语对齐词表既可当文本对也可当两列表格）。语义等价的评测仍是开放问题。
• 垂直域适配：v1.6 覆盖主流场景，金融 / 法律 / 医疗等高精度垂直域需要专门适配。

---

参考资料：

• MinerU2.5-Pro: Pushing the Limits of Data-Centric Document Parsing at Scale ↗
• MinerU GitHub ↗
• MinerU2.5-Pro-2604-1.2B on Hugging Face ↗
• OmniDocBench（评测协议来源） ↗
• DAPO: An Open-Source LLM Reinforcement Learning System at Scale ↗