先看证据
从一个总排名，转向具体页面上的判断
Datalab发布了OmniParseBench，一套面向文档解析器的公开OCR基准。它不是一个新模型，而是一套离线评测工具：对PDF页面或图像运行解析器，再用一组页面级的“是/否”测试判断输出是否满足具体条件。基准包含16,288项测试，覆盖2,937页、2,343份文档和92种语言，数据集与代码均公开。
这个设计回应了一个实际问题：团队看到排行榜上的分数，却未必知道系统是否适合自己的材料。OmniParseBench把“解析得好不好”拆成可核对的判断，并允许按标签查看结果。它因此更像一套可以审计的测试集，而不只是把不同系统排出先后的榜单。
分数如何从页面测试汇总而来
每项测试检查一个页面上的特定事实。例如，某段文字或数字是否出现，文本A是否排在文本B之前，一行是否恰好重复指定次数，表格单元格是否位于给定表头之下并与邻近单元格相符，或某个文本块是否属于标题、正文或表格。五种测试类型分别归入文本、表格和版面三类能力，最终总分是这三个家族分数的平均值。
这种统一单位让几类能力可以汇总，但“通过”并非由另一个模型主观裁判，而是由公开的评分代码判定。数字要求逐位匹配，不过1,240与1240视为相同；公式则按KaTeX渲染结果比较，因此\frac{a}{b}与\dfrac{a}{b}可以等价。每个判定可能是通过、失败、不支持或错误，后两种不计入分数。读总分时，必须同时记住它衡量的是纳入计分的测试通过率。
标签让平均分变成可定位的结果
测试结果还可以按结构、呈现方式、内容角色、书写系统和语言等维度筛选。标签描述测试涉及的页面内容，但不决定测试是否通过，也不改变总分；它们的作用是让团队对某一类材料单独计算通过率。比如，表格标签覆盖6,767项测试，来自1,000页、875份文档；英语测试有10,089项，非英语测试则有1,931项，分布在529页和321份文档中。
这类切片比单一总分更接近工程排查：如果解析器在总体上表现稳定，团队仍可查看它在表格、某种书写系统或特定语言上的表现。不过，切片也受样本规模限制。尤其是非英语测试数量明显少于英语测试，某个细分分数不能自动代表该语言的所有文档类型，也不能消除数据集覆盖不足带来的不确定性。
高分接近，来源链仍需看清
发布时的榜首是Gemini 3.8 Flash，得分92.9；Datalab自家的Datalab accurate为92.7，排名第二，前三名的总分差距在1.3分以内。这个结果说明，在这套基准的计分方式下，领先系统的总体表现相近；它并不能单独证明它们在某个企业的扫描件、表单或低质量影像上同样接近。
测试答案也有不同来源，基准记录了十种推导方式，包括出版方JATS XML、PDF文本层、作者提供的页面、olmOCR-bench测试、模型评审和人工审查。保留这些来源信息有助于读者追问答案是如何建立的，但也提醒使用者：基准并非所有测试都来自同一条验证路径。还要考虑利益关系——Datalab销售解析器，并由自己的系统参与排行榜；公开代码和可追溯来源提供了审查基础，却不等于消除了设计和覆盖选择的影响。
适合做筛查，不替代业务文档验收
对技术团队来说，OmniParseBench的落地门槛相对直接：Python 3.11及以上环境可通过uv安装，评分在本地离线运行，不需要API密钥；若要运行依赖供应商服务的解析器，则仍需相应密钥。团队可以先用公开基准筛掉明显不合适的候选，再把注意力放到与业务文档相近的标签和失败样例上，而不是只比较排行榜名次。
真正的部署判断还需要自己的文档集和验收标准。应先确认目标材料的语言、版面、表格形态和扫描质量是否被基准充分覆盖，再检查不支持与错误结果被排除后，剩余分数是否仍能代表业务要求。OmniParseBench提供的是一套更细、更可检查的比较工具；它缩短了从总分到错误类型的距离，却没有替团队决定哪些错误可以接受。