← 返回 2026-04-07

MinerU2.5-Pro:以数据为中心的文档解析极限突破 MinerU2.5-Pro: Pushing the Limits of Data-Centric Document Parsing at Scale

Bin Wang, Tianyao He, Linke Ouyang, Fan Wu, Zhiyuan Zhao, Tao Chu, Yuan Qu, Zhenjiang Jin, Weijun Zeng, Ziyang Miao, Bangrui Xu, Junbo Niu, Mengzhang Cai, Jiantao Qiu, Qintong Zhang, Dongsheng Ma, Yuefeng Sun, Hejun Dong, Wenzheng Zhang, Jutao Xiao, Jiayong Shi, Pengyu Liao, Xiaomeng Zhao, Huaping Zhong, Liqun Wei, Jing Yu, Jie Yang, Wei Li, Shasha Wang, Qianqian Wu, Xuanhe Zhou, Weijia Li, Zhenxiang Li, Zhongying Tu, Jiang Wu, Lijun Wu, Chao Xu, Kai Chen, Wentao Zhang, Yu Qiao, Bowen Zhou, Dahua Lin, Conghui He 📅 2026-04-06 👍 124 2026-07-13 08:36
OCR 强化学习 数据为中心AI 文档解析 视觉语言模型

用数据工程而非架构创新,让1.2B小模型在文档解析上击败200倍参数的大模型。

前置知识

文档解析(Document Parsing)

把PDF等非结构化文档转换为Markdown、HTML等机器可读结构化格式的过程,通常包含布局检测、文本识别、公式识别、表格识别和阅读顺序恢复五个子任务。它是LLM训练数据流水线和RAG系统的基础设施。

本文所有工作都围绕文档解析的子任务指标(编辑距离、CDM、TEDS)展开,必须先理解子任务定义和评价方式才能读懂模型设计与实验对比。

视觉语言模型(VLM)

结合视觉编码器(通常是ViT)和语言模型的端到端模型,可直接对图像-文本对进行理解和生成。NaViT是一种支持原生分辨率、变token数的视觉编码器;Qwen2.5是常用的语言模型。

MinerU2.5-Pro采用1.2B参数的解耦coarse-to-fine VLM(NaViT-675M + Qwen2-0.5B),理解这种"视觉编码器+小型语言模型"的组合是看懂架构不变、数据驱动这一核心立意的前提。

数据为中心AI(Data-Centric AI)

在模型架构固定的前提下,通过系统性优化训练数据(覆盖度、信息量、标注质量)来提升模型表现的方法论,与传统的以模型为中心的思路形成对比。

本文是Data-Centric AI在文档解析领域的系统化实践,DDAS、CMCV、Judge-and-Refine三大组件都围绕这个理念设计,文章的核心结论(架构成熟期数据比架构更重要)也建立在这个范式上。

GRPO(Group Relative Policy Optimization)

一种无需单独价值模型的强化学习算法。对每个输入采样G个候选输出,用任务指标直接计算奖励,再用组内相对优势引导策略更新,可直接对齐序列级或结构级评价指标。

GRPO是本文第三阶段训练的核心,文章用它直接优化编辑距离、TEDS、CDM等不可微的评价指标,弥补了交叉熵损失在结构化输出上的不足。

Hungarian匹配(匈牙利算法)

用于解决二部图最小权匹配的经典组合优化算法,可在多项式时间内找到全局最优的一对一配对方案。

OmniDocBench v1.6的Multi-Granularity Adaptive Matching(MGAM)机制依赖匈牙利算法求解预测与标注的最小代价匹配,是理解评估纠偏机制的关键。

研究动机

当前文档解析研究高度集中在架构创新与推理效率上,导致主流benchmark(OmniDocBench v1.5)上SOTA模型分数趋同,看似进入了"架构瓶颈"。然而作者对覆盖多架构、多参数规模的SOTA模型在大量真实PDF上的表现做交叉分析后发现一个反直觉现象:无论模型架构是pipeline式、端到端VLM还是解耦VLM,所有模型在同一批困难样本上呈现出高度一致的失败模式——某些复杂嵌套表格、密集公式布局、非常规多栏排版对所有系统都是难题。这说明性能瓶颈的根源不在架构,而在训练数据——具体表现为两个相互纠缠的问题:一是覆盖度不足,例如MinerU2.5的训练数据不到1000万页且分布集中在高频类别(标准学术论文、单栏报告),对长尾场景覆盖极差;二是标注质量悖论,越是对模型能力提升关键的Hard样本,自动标注越不可靠,因为没有任何主流模型能稳定解析它们,结构化标注(LaTeX转录、HTML表格)的噪声会通过监督微调直接污染模型行为。简言之,单纯扩大数据规模只会放大现有的分布偏置和标注噪声,无法真正提升性能上限。

本文的目标是本文的目标是验证一个核心假设:在模型架构趋于成熟的现阶段,系统性的数据工程(Data Engineering)比架构创新能带来更大的性能收益。作者将MinerU2.5的1.2B参数解耦coarse-to-fine架构完全冻结,把所有优化集中在Data Engine和训练策略设计上,期望在OmniDocBench v1.6上从92.98提升到明显领先所有现有方法(包括参数量超过200×的通用VLM)的水平,并提供完整可复现的数据工程方案。

与已有工作不同的是,本文的独特切入角度是把"数据构建"本身当作一个独立、系统的研究问题,而非模型训练的附属品。具体来说有三个差异化:第一,文章把数据质量拆解为覆盖度(Coverage)、信息量(Informativeness)、标注准确性(Annotation Accuracy)三个维度,并设计协同优化的机制;多数现有方案(如olmOCR只扩量、DocGenome只限学术论文、MinerU2.5/PaddleOCR-VL-1.5的UACS把三个维度独立处理)都没做到联合优化。第二,提出Cross-Model Consistency Verification(CMCV)通过异构模型输出一致性来识别"通用难题"与"模型特异性弱点",突破单模型自一致性(IMIC/UACS)只能反映单一模型认知不确定性的局限。第三,把评估协议本身作为改进对象:发现OmniDocBench v1.5的固定粒度一对一匹配存在系统偏差(语义正确的预测因切分粒度不同被打低分),通过Multi-Granularity Adaptive Matching(MGAM)+ Hard子集升级为v1.6,让benchmark本身变得更公平、更具区分度。

核心方法

MinerU2.5-Pro的整体思路可以用"冻结架构、激活数据"来概括。它继承MinerU2.5完全相同的1.2B参数解耦架构(NaViT-675M视觉编码器 + Qwen2-0.5B语言模型,从MinerU2.5的Stage 0检查点初始化),把所有性能提升都归因于Data Engine和训练策略的改进。Data Engine由三个串联协同的组件构成:先用Diversity-and-Difficulty-Aware Sampling(DDAS)在页面级和元素级两个粒度上做平衡采样,把训练数据从不到1000万扩展到65.5M;再用Cross-Model Consistency Verification(CMCV)让MinerU2.5、PaddleOCR-VL、Qwen3-VL-30B三个异构模型对候选样本独立推理,根据输出一致性把样本自动分成Easy/Medium/Hard三层;最后用Judge-and-Refine流水线对Hard样本做"渲染—再验证"的迭代纠错,残余样本再路由到专家标注。在训练侧采用三阶段递进策略:第一阶段在65.5M Easy/Medium数据上做大规模预训练(学习率1e-3,batch size 256),第二阶段在192K高质量Hard专家标注上做监督微调(学习率5e-5,batch size 128,按子任务差异化混入Stage 1回放数据防灾难性遗忘),第三阶段用GRPO强化学习直接优化编辑距离、CDM、TEDS等任务级指标(学习率1e-5,batch size 512,每样本G=16次采样)。同时发布OmniDocBench v1.6,用MGAM纠偏匹配逻辑并新增296页Hard子集,建立Base/Hard/Full三档评估协议。

本文核心创新是把"数据—模型—评测"三者作为一个闭环来设计,关键区别有三:(1)把数据难度评估从单模型自一致性(如MinerU2.5的IMIC、PaddleOCR-VL-1.5的UACS)升级为多模型跨验证(CMCV),由此区分"所有模型都做不对的真正难题"和"MinerU2.5自己的盲点"——前者需要质量精修甚至人工,后者直接用外部共识做伪标签即可解决,这是文章强调的根本性方法差异。(2)针对Hard样本的标注噪声,提出render-then-verify的判别-精修流水线:把LaTeX公式和HTML表格渲染成图像后与原图并排输入给Judge-Refine模型(Qwen3-VL-235B),利用"渲染会放大结构缺陷"的特性把抽象的token级错误转换成直观的视觉异常,绕过了模型"对自身输出天然偏向于认可"的自反射偏差。(3)评测侧的MGAM(Multi-Granularity Adaptive Matching)通过三级候选匹配(直接匹配→按LaTeX换行切分→枚举所有2^(n'-1)种相邻合并方案)+ 取全局最优的方案,把粒度敏感性从评估指标中剔除,让benchmark真正测的是内容正确性而非输出格式偏好。

方法步骤详情

方法执行分四步。第一步是DDAS双粒度采样:先用ViT-base 512维embedding对PDF Pool做K-Means聚类,在每个簇内跑页面级CMCV评估难度,按"大簇下采样/小簇上采样/无效内容过滤/Medium-Hard上调"的规则扩展为约60M页级候选集;接着用MinerU2.5和PaddleOCR-VL的布局检测把候选页拆成文本/公式/表格三种元素,每种元素类型独立做ViT特征聚类+元素级CMCV,在簇-难度联合空间上做平衡采样。第二步是CMCV难度分档:对每个样本用MinerU2.5、PaddleOCR-VL、Qwen3-VL-30B分别推理,按任务特定指标(文本编辑距离/表格TEDS/公式CDM)把样本分到三档——Easy(目标模型与至少一个外部模型高度一致,直接采用任何模型输出做标注)、Medium(两个外部模型互相一致但目标模型与它们差异显著,用外部共识做可靠伪标签)、Hard(三个模型两两都显著不一致,无模型共识可用)。第三步是Judge-and-Refine自动精修:把Hard样本的LaTeX/HTML标注渲染成图像,与原图成对送入Qwen3-VL-235B(独立于CMCV模型池),用视觉对比做多轮错误定位与定向精修;自动精修后仍失败的样本按"自动Judge定位错误修正效率高者优先"+"边际贡献大的子任务优先"两轴分配给Gemini 3 Pro做AI预标注,再交人类专家审核+自动化QA工具校验,最终产出192K高质量Hard专家标注集。第四步是三阶段递进训练:Stage 1用65.5M Easy/Medium数据按文本21M/布局14M/公式13M/表格11.5M/图像6M的子任务比例(根据baseline各任务gap和总体分权重动态调整)做1 epoch全参数训练,ViT学习率1e-4、MLP/LLM学习率1e-3、batch 256;Stage 2在192K Hard专家标注上做SFT并按子任务差异化混入Stage 1回放数据(layout 6:1/text 1:50/formula 1:25/table 1:10/image 1:4),学习率5e-5,batch 128;Stage 3用Stage 2模型做GRPO,每样本G=16次采样,奖励直接用任务评价指标(文本edit distance、公式CDM、表格TEDS、布局IoU),按DAPO做法加clip-higher和动态采样丢弃零方差组,1 epoch,学习率1e-5,batch 512。

技术新颖性

技术新颖性主要体现在三点。第一,CMCV是首次把"多模型跨验证+难度分档+下游标注策略耦合"作为一个统一闭环用于文档解析数据构建:相比MinerU2.5/PaddleOCR-VL-1.5用单模型多次推理一致性(IMIC/UACS)只能捕获单一模型的认知不确定性,CMCV用MinerU2.5、PaddleOCR-VL、Qwen3-VL-30B三种异构模型的两两一致性,巧妙地把"难度"这个无法直接观测的量转译为可计算的跨模型一致性信号,并据此触发三种完全不同的处理路径(直接采纳/外部伪标签/精修或人工),这在传统主动学习(Query-by-Committee)和集成学习文献中虽有类似思想,但本文在文档解析场景下做了端到端的工程化封装。第二,render-then-verify的判别-精修机制巧妙利用了"渲染会放大结构错误"的现象——LaTeX里漏一个对齐符号\、HTML里漏一个闭合标签,在文本域里是细微的字符级问题,但渲染后立刻变成可见的视觉异常(如公式位置错乱、表格边框缺失),这让Judge-Refine模型可以用它最擅长的视觉对比而非抽象结构推理来定位错误,从根本上绕过了自反射偏差。第三,MGAM把"评估匹配粒度"这个长期被忽视的自由度明确暴露出来,用三级匹配(直接匹配/LaTeX换行切分/全2^(n'-1)种合并方案的枚举)+ 全局最优选择做自适应粒度调整,使评估对输出粒度、格式偏好(HTML vs Markdown、整段文本 vs 逐行)完全中立。配套的OmniDocBench v1.6 Hard子集(296页专门从Data Engine标记的Hard池中筛选,覆盖嵌套表格、密集公式、非常规布局)让top模型区分度从Base子集的1.70分扩展到Hard子集的更大范围,GLM-OCR从Base第一掉到Hard第三,HunyuanOCR从92.45掉到82.69,验证了Hard子集的有效性。

Overview of the Data Engine pipeline. The system co-optimizes three dimensions—Coverage, Informativeness, and Accuracy—through three synergistic stages: Diversity-and-Difficulty-Aware Sampling (DDAS), Cross-Model Consistency Verification (CMCV), and the Annotation Pipeline for Hard Case.
Figure 2: Overview of the Data Engine pipeline. The system co-optimizes three dimensions—Coverage, Informativeness, and Accuracy—through three synergistic stages: Diversity-and-Difficulty-Aware Sampling (DDAS), Cross-Model Consistency Verification (CMCV), and the Annotation Pipeline for Hard Case.
The DDAS pipeline operates at two granularity levels.
Figure 3: The DDAS pipeline operates at two granularity levels.

实验结果

端到端解析(Table 2):OmniDocBench v1.6 Full上MinerU2.5-Pro以95.69排名第一,比同架构MinerU2.5基线92.98提升2.71分,比GLM-OCR(0.9B)95.15高0.54分、PaddleOCR-VL-1.5(0.9B)94.87高0.82分;文字编辑距离0.036、公式CDM 97.29、表格TEDS 93.42、表格TEDS-S 95.92、阅读顺序0.120均最优,且超过Gemini 3 Pro(92.85)、Qwen3-VL-235B(89.78)等百亿至千亿参数级别的通用VLM。Base子集(Table 7,1355页)top3(GLM-OCR 96.19/MinerU2.5-Pro 96.12/PaddleOCR-VL-1.5 95.72)仅相差0.5分以内,说明标准场景接近饱和;Hard子集(Table 8,296页)上MinerU2.5-Pro 94.08显著领先PaddleOCR-VL 92.48的1.60分,GLM-OCR从Base第一掉到Hard第三(96.19→92.01,下降4.18),HunyuanOCR下降9.76(92.45→82.69),而MinerU2.5-Pro只下降2.04分,鲁棒性最强。训练阶段消融(Table 3):MinerU2.5基线92.98 → Stage 1 94.29(+1.31,主要靠数据覆盖和标注质量)→ +Stage 2 95.25(+0.96,table TEDS从90.37跃升到92.87贡献最大)→ +Stage 3 95.69(+0.45,formula CDM从96.48到97.29),三阶段在Base和Hard子集上累计提升基本对称(Hard 91.65→94.08,Base 93.23→96.12)。元素级评估(Table 4-6):文本识别Full Edit Distance 0.019比MinerU2.5基线0.028降低30.5%;公式识别在9个benchmark上5项第一4项第二,仅在HWE(手写公式95.38 vs Qwen3.5-397B 97.59)和SCE(97.04 vs GLM-OCR 97.77)略逊;表格识别Overall TEDS 91.10(+3.16)、TEDS-S 94.48(+2.31)均为最高,Hard子集92.46 vs MinerU2.5基线88.28提升4.18分。

Training configurations for the three-stage progressive strategy.
Table 1: Training configurations for the three-stage progressive strategy.
Performance comparison of document parsing methods on OmniDocBench v1.6 Full across text, formula, table, and reading order extraction tasks.
Table 2: Performance comparison of document parsing methods on OmniDocBench v1.6 Full across text, formula, table, and reading order extraction tasks.
Training stage ablation on OmniDocBench v1.6.
Table 3: Training stage ablation on OmniDocBench v1.6.
Text recognition (Edit Distance↓) on OmniDocBench v1.6.
Table 4: Text recognition (Edit Distance↓) on OmniDocBench v1.6.
Formula recognition (CDM↑) across multiple benchmarks.
Table 5: Formula recognition (CDM↑) across multiple benchmarks.
Table recognition (TEDS & TEDS-S↑) across multiple benchmarks.
Table 6: Table recognition (TEDS & TEDS-S↑) across multiple benchmarks.
Detailed results on OmniDocBench v1.6 Base subset.
Table 7: Detailed results on OmniDocBench v1.6 Base subset.
Detailed results on OmniDocBench v1.6 Hard subset.
Table 8: Detailed results on OmniDocBench v1.6 Hard subset.
Performance comparison on OmniDocBench v1.6, which comprises Base (standard samples), Hard (challenging samples), and Full (overall) splits.
Figure 1: Performance comparison on OmniDocBench v1.6, which comprises Base (standard samples), Hard (challenging samples), and Full (overall) splits.
查看结构化数据
任务指标本文基线提升
OmniDocBench v1.6 Full端到端解析 Overall Score↑(综合分,text+formula+table均值) 95.69 92.98(MinerU2.5,相同1.2B架构) +2.71,且超过所有对手包括Gemini 3 Pro(92.85)和Qwen3-VL-235B(89.78)
OmniDocBench v1.6 Hard子集 Overall Score↑ 94.08 91.65(MinerU2.5) +2.43,超过第二名PaddleOCR-VL(92.48)1.60分
文本识别(Full) Edit Distance↓ 0.019 0.028(MinerU2.5) 30.5%相对降低,优于Qwen3.5-397B(0.020)和GLM-OCR(0.021)
公式识别(OmniDoc Full) CDM↑(Character Detection Matching) 97.29 95.59(MinerU2.5) +1.70,OmniDocBase上达99.20接近性能上限
表格识别(Overall) TEDS↑ + TEDS-S↑ 91.10 / 94.48 87.94 / 92.17(MinerU2.5) +3.16 / +2.31,Hard子集上92.46 vs 88.28提升4.18分
Stage 1 训练增益(数据扩展+CMCV) OmniDocBench Full 94.29(+1.31) 92.98(基线) +1.31,最大单阶段贡献,主要来自数据覆盖与标注质量
Stage 2 训练增益(Hard SFT) OmniDocBench Full 95.25(+0.96) 94.29(Stage 1) +0.96,table TEDS从90.37跃升到92.87(+2.50)贡献最大
Stage 3 训练增益(GRPO) OmniDocBench Full 95.69(+0.45) 95.25(Stage 2) +0.45,formula CDM从96.48提升到97.29(+0.81)

局限与改进

作者在文末明确列出了几个根本性局限:第一,评估本身存在固有模糊性,同一内容可以有多种等价表示(HTML vs Markdown表格、不同LaTeX命令表示同一公式),同一视觉布局也可能被合法地表达为不同元素类型(双语文本对齐可以是行对行文本对或两栏表格),即便人类标注者也难以达成一致意见,因此"匹配—打分"的范式本身有上限,"语义等价感知"的评估方法仍是开放问题。第二,OmniDocBench v1.6虽然覆盖了主流应用场景,但对垂直领域(金融、法律、医疗)需要构造专门的领域评估集;并且当模型能力接近人类水平时,评估集自身的标注精度会成为新的瓶颈。第三,本文聚焦在内容准确性的"抽取"层面,但对于下游应用,文档内部的结构化关系(标题与正文的层级、图表与正文的引用绑定、跨页内容的连续性)同样关键,从"内容抽取"走向"结构化语义理解"是自然的下一步。除此之外,从我们自己的观察看,数据工程方案仍有一些隐含的依赖与限制:(1)CMCV依赖三个异构模型(其中Qwen3-VL-30B是商用大模型),存在数据来源合规性、成本和API稳定性问题;(2)Judge-Refine用Qwen3-VL-235B做迭代精修,专家标注用Gemini 3 Pro做预标注,整个流程对外部闭源模型的依赖度较高,方法本身的"数据自主性"打了折扣;(3)render-then-verify要求LaTeX/HTML可成功渲染,密集公式或罕见环境下的渲染失败会直接卡住流水线;(4)GRPO在文本任务上增益有限(编辑距离从0.036到0.036,没变化),主要贡献集中在formula CDM上,说明不同任务的可强化学习性差异很大,文本上的奖励稀疏性问题未充分解决;(5)Hard子集仅296页,相对Full的1651页比例不到18%,且未公开基线模型在Hard上的训练数据隔离验证细节,泛化性结论的强度有限。

独立分析的弱点

独立分析看几个具体可改进的弱点:(1)数据分布仍可能不均衡。DDAS虽然做了页面级和元素级的平衡采样,但Easy:Medium:Hard的具体比例和簇大小仍靠经验设定,文本21M/布局14M/公式13M/表格11.5M/图像6M的子任务比例是按baseline的子任务gap动态调整的,这意味着如果换基线模型,最优比例会变,建议的改进方向是引入基于验证集性能的在线比例搜索。(2)CMCV的"Medium"档虽然价值最高但量最稀缺,文章承认"formula和table对Hard更敏感、text对Medium更敏感",但没有给出严格的量化边界,改进方向是用reward modeling代替固定分档,对每个样本分配连续难度分数。(3)render-then-verify的精修流水线本质上是把模型对自身输出的自反射偏差外包给了一个更强的judge模型(Qwen3-VL-235B),但如果该judge本身存在某种系统性偏见,会被放大到所有精修样本中;改进方向是引入多个独立judge模型做集成投票。(4)GRPO阶段在文本任务上几乎无提升(0.036→0.036),且阅读顺序任务被排除在GRPO之外,改进方向是设计更稀疏但更精准的文本奖励(如同义词感知编辑距离、按结构权重的奖励)。(5)三阶段训练累积增益呈递减(+1.31→+0.96→+0.45),但每阶段都用了1个epoch全量数据,总算力消耗不低,且192K专家标注的高成本没在文中充分披露,改进方向是引入课程学习或自适应epoch数。(6)评测协议虽升级到v1.6,但MGAM枚举2^(n'-1)种合并方案在最坏情况下是指数复杂度,n'很大时(如密集文本上百行)计算量会爆炸,改进方向是用动态规划或近似算法限制搜索空间。

未来方向

作者在文末给出了三个明确方向:(1)发展"语义等价感知"的评估方法,超越当前的元素匹配范式,处理格式和结构双重模糊性;(2)构造金融、法律、医疗等垂直领域的评估集,因为OmniDocBench v1.6主要覆盖主流场景;(3)把研究从"内容抽取"推进到"结构化语义理解",包括标题-正文层级、图表-正文引用绑定、跨页内容连续性等结构关系建模。基于本文成果可延伸的方向还包括:(a)把Data Engine范式推广到其他需要大规模结构化标注的视觉-语言任务(视频理解、3D文档理解、屏幕UI解析);(b)用更小的语言模型(0.5B甚至更小)配合本文数据策略,探索"小模型+大数据"的极限;(c)CMCV可以扩展为"专家模型路由"机制:不同难度的样本用不同规模的专家模型处理,进一步降低推理成本;(d)GRPO可与DPO等人类偏好学习结合,引入人类对Hard样本的偏好信号;(e)render-then-verify机制可推广到代码、MathML、SVG等其他结构化输出任务,作为通用的"自反射偏差绕过"技术。

复现评估

复现评估整体较好但有门槛。代码已在GitHub开源(https://github.com/opendatalab/MinerU),模型权重也在HuggingFace公开(opendatalab/MinerU2.5-Pro-2604-1.2B),数据生成流水线的整体设计在论文和开源代码中描述清楚,三阶段训练的超参数(学习率、batch size、epoch、ViT/MLP/LLM分层学习率)都明确给出(Table 1)。但实际复现存在几个门槛:(1)65.5M预训练数据规模和192K专家标注的获取成本很高,Data Engine本身依赖MinerU2.5、PaddleOCR-VL、Qwen3-VL-30B三个异构模型的推理(CMCV阶段)和Qwen3-VL-235B(Judge-Refine)、Gemini 3 Pro(专家预标注)两个商用模型,这意味着虽然模型权重和数据引擎代码开源,但完整复现需要相当规模的算力和外部API预算,特别是Qwen3-VL-30B和Gemini 3 Pro的推理成本。(2)专家标注涉及人类标注团队和自动化QA流程,文章提到"由专业团队标注+交叉验证"但未公开标注协议具体细节和标注人员培训流程。(3)训练规模在文中没有明确披露总GPU小时数,但Stage 1用65.5M数据、batch 256、1 epoch至少需要数百GPU-day级别,对中小团队来说有相当门槛。(4)OmniDocBench v1.6的MGAM匹配代码和Hard子集的筛选标准已在Section 5描述清楚,但具体评分实现细节在原benchmark仓库中,第三方复现需要同时关注MinerU和OmniDocBench两个repo。综合看,对工业研究团队(具备多卡训练+多模型推理能力)复现难度中等,对学术小团队难度较高。