Datalab 发布 OmniParseBench：面向文档解析的开放基准

Datalab 已发布 OmniParseBench，这是一套面向 OCR 与文档解析的开放基准。该公司表示，这套基准围绕 16,288 项测试设计而成。根据 PyPI 项目页面和 Datalab 的博客文章，这一基准不是把系统输出与某一个参考答案做编辑距离比对，而是通过针对单页文档的一系列二元判断来评估结果。具体来说，每个测试都会检查某个元素是否出现在提供方的输出中、是否处于正确顺序、是否位于指定表格单元格，或者是否被放进某一种特定类型的版面块中。Datalab 将这种方法描述为：把重点放在系统是否提取到了正确内容，而不是是否匹配某一种被偏好的输出格式。

以“单元测试”方式构建的基准

PyPI 上描述的协议以页面级的“是或否”断言为核心。一项测试可以检查一个或多个参数，而每个参数都对应页面中某一处内容。该基准把结果归入三大类：文本、表格和版面布局。对外展示的总分，则是这三类得分的平均值。

这一设计之所以重要，是因为按照 Datalab 的说法，较早的一些基准已经更容易通过格式调整或针对基准的后处理来优化成绩。该公司在博客中称，一些被广泛使用的替代方案，奖励的可能更多是对预期输出规范的迎合，而不一定是真正的底层模型质量。需要指出的是，这些批评来自 Datalab 自身的陈述，并不是本次提供材料中的独立研究结论；但这些说法解释了该公司为何要构建 OmniParseBench，也解释了它为什么计划将这一基准用于自身发布结果的汇报。

在覆盖范围方面，PyPI 页面说明，每项测试都会按多个维度打标签。这些维度包括：结构标签，例如 table、math、form 和 multi_column；渲染标签，例如 handwriting、tiny、rotated 和 degraded；角色标签，例如 heading、caption、footnote、list、code、figure 和 header_footer；基于 ISO 15924 的书写系统标签；以及基于 ISO 639-3 的语言标签。这些标签本身并不决定测试是否通过，它们的作用是帮助用户按条件切分基准数据，并对不同子集分别计分。由于单个测试可以同时带有多个标签，因此按标签得到的分数会彼此重叠，不能简单平均回到总分。

评分方式与运行机制

根据 PyPI 描述，这套基准既可以运行在 Datalab 托管于 Hugging Face 的数据集上，也可以运行在用户自己的数据集上。它还暴露了更底层的评分与预测原语，方便团队将其接入自己的评估流水线。一次运行支持中断后继续，每一种 provider 设置都被视为一次独立运行。项目说明称，每次运行都会写出一个 scores.jsonl 文件，其中每一行对应一项测试；而汇总结果则可以从 summary.json 中读取。

评分并不是把所有结果都简单压缩为通过或失败。PyPI 列出了四种判定结果：

• 通过
• 失败
• 不支持：当某个提供方无法产生所请求的输出时
• 错误：当评分过程本身出现问题，而不是提供方输出失败时

一个值得注意的方法学选择是，“不支持”和“错误”这两类判定不会被算作失败，而是从所有分数中排除。PyPI 表示，这样做是为了避免因为提供方无法生成某种输出，或因为评分器自身存在缺陷，而对供应商进行惩罚。与此同时，这也意味着，不同系统之间的比较，部分上会受到各家支持哪些输出类型的影响。如果某个系统不能生成某一种表示形式，那么对应测试可能会直接从其得分中剔除，而不是按零分处理。

项目还表示，provider 适配器对每次调用使用相同的超时设置，并且默认采用各提供方“最准确”的参数配置。Datalab 的工具链可以直接调用供应商 API，但在执行前会要求用户确认，因为这些调用会产生费用。该软件包要求 Python 3.11 或更高版本。代码部分采用 Apache 2.0 许可发布，而数据与测试则因来源不同而采用混合许可。

哪些内容公开，哪些内容未公开

从本次提供的资料来看，公开发布的内容明确包括代码、文档以及在 PyPI 上打包发布的基准。PyPI 页面还表示，代码仓库中包含一种运行方式，既可以用 Datalab 在 Hugging Face 上的数据集来跑基准，也可以用用户自己的数据。该页面同时把用户指向相关文档，内容涵盖 API、基准设计、测试构造、providers 以及标签体系。页面还写明，如果用户发现某个测试有误，可以提交 issue，这表明这一基准被设计成可检查、可修正的形式。

不过，现有资料并没有给出这 16,288 项测试按类别、语言、书写系统或文档类型划分的完整细目。资料中也没有提供 OmniParseBench 自身的汇总排行榜结果。因此，文中的“16,288 项测试”只能作为该基准自我框定的一部分来转述，而已提供文本并未详细说明这个总数背后的具体拆分。同样，现有源材料中也没有全基准范围的性能数字，无法显示哪些提供方在文本、表格或版面布局上领先。

围绕其他基准提出的结果与主张

在本次提供材料中，Datalab 的博客并没有发布 OmniParseBench 的排行榜结果，而是把重点放在它为何认为现有基准不充分。该公司表示，olmOCR 已经出现“饱和”，并举例称，后处理就可能让报告分数变化约 1 到 2 分。它还认为，ParseBench 会受到提示词措辞、格式约定以及专门化流水线的强烈影响，尤其是在图表和视觉定位方面。这些都是 Datalab 提出的实质性指控，但应被视为该公司的说法；在所提供来源中，并没有附带独立验证。

即便如此，这些主张仍有助于理解 OmniParseBench 想要优化什么。该基准明确把自己的“是或否”检查描述为比参考答案匹配式方法更不容易被“钻空子”。Datalab 认为，这种结构应当能产生更清晰的错误信号，因为某个失败测试对应的是某一页上的某一个具体错误。这样一来，模型开发者和企业采购方就更容易看出，一个系统究竟是在旋转文本、表单、手写内容，还是表格结构上存在问题，而不是只能看到一个混合在一起的总分。

从发布内容本身可见的局限

OmniParseBench 自身的设计也带来了若干限制。第一，现有资料没有展示完整的基准级结果，因此外部读者目前还无法判断，这套基准产生的排名是否会与较早的替代方案形成实质差异。第二，由于“不支持”的输出会被排除在评分之外，这套基准可能更多奖励的是提供方在其已支持输出范围内的质量，而不是输出类型覆盖面的广度。第三，标签切片按设计就是重叠的，这对诊断问题很有帮助，但也会让汇总结果的解释变得不那么直观。

此外还存在一些实际约束。运行供应商模型需要 API 密钥，并且会产生付费调用。虽然基准支持恢复运行，也可以跨多次运行做比较，但可复现性仍可能随 provider 设置而变化，因为每一种设置都会被视为一次独立运行。最后，该数据集继承了来源不一的混合许可，Datalab 也提到，上游数据集同样应被引用。这并不会削弱该基准的价值，但意味着如果要把它纳入生产级评估流程，往往仍需要经过法律和运营层面的审查。

对于中文语境下关注文档 AI 的企业与团队来说，OmniParseBench 带来的直接变化在于：它提供了一种更便于检查的方式，能够逐页测试文档 AI 系统，并按表格、版面、书写系统以及困难渲染条件等维度切分结果，而不是只给出一个不透明的总分。实际使用中，这或许能帮助团队围绕自己真正关心的文档特征，比较不同供应商或内部模型；但同时也应核查哪些输出被标记为“不支持”，认真审阅基准的许可条款，并避免把任何单一总分视为对文档理解质量的完整衡量。