文档解析这个领域，过去几年一直有个很尴尬的局面：模型越做越多，指标越刷越高，但真要横向比一比"谁更强"，大家心里都没底。不同团队用的测试集不一样，标注口径不一样，甚至连"什么算解析正确"的定义都不一样。你拿A模型的论文数据去对比B模型的实际表现，基本等于拿苹果比橘子。OmniDocBench 就是冲着这个痛点来的——它想给文档解析这件事画一把相对公平的尺子。这篇内容我会从它要解决的问题、评测体系怎么设计、核心指标怎么算、实际用起来有哪些坑，以及它和 CDM、TEDS 这些概念的关系，完整拆一遍。不管你是做文档结构化解析的工程师，还是需要选型评估的负责人，或者只是想把 PDF 转成结构化文本的实践者，都能从中拿到能直接用的东西。
1. 文档解析评测为什么一直缺一把"公平尺子"
1.1 各家自建测试集的三个致命问题
做文档解析的人应该都有体会：一个模型在自家测试集上跑出 95% 的准确率，换到另一批文档上可能直接掉到 60%。这不是模型不行，而是评测本身出了问题。我梳理下来，自建测试集主要有三个绕不开的毛病。
第一个是文档来源偏差。很多团队图省事，测试集直接从公开的学术论文 PDF 里抽，这类文档排版规整、字体统一、几乎没有手写和印章。模型在这种数据上表现好，不代表它能处理合同里的复杂表格、招标文件里的多级编号、或者扫描件里的倾斜文字。文档解析的真实战场从来不是干净的论文，而是那些"脏"得五花八门的业务文档。
第二个是标注口径不统一。什么叫"解析正确"？有人按字符级算，有人按行算，有人按语义块算。表格更麻烦——是把整个表格当一个整体判断对错，还是拆成单元格逐个比对？合并单元格怎么算？跨页表格怎么算？口径不同，同一个模型的分数能差出二三十个点。
第三个是指标不可复现。论文里写"我们的方法达到了 SOTA"，但代码不开源、测试集不公开、评测脚本不给，别人根本没法验证。这种"自说自话"的评测，对领域进步的推动非常有限。
1.2 一把好尺子需要满足的条件
那什么样的评测体系才算"公平尺子"？我的判断标准有这么几条。
覆盖要广。文档类型得涵盖学术论文、合同、招标文件、报表、书籍、幻灯片等主流场景，还要包含扫描件、拍照件这类非理想输入。只有覆盖面够宽，评测结果才有代表性。
标注要细。不能只标"这段文字是什么"，还要标它的位置、层级、阅读顺序、表格结构。文档结构化解析的核心价值就在于还原结构，如果标注只到文本层，那评测就丢了最关键的信息。
指标要可解释。分数高在哪、低在哪，得能拆开看。是文本识别错了，还是阅读顺序乱了，还是表格结构崩了？一个笼统的总分说明不了问题，必须能定位到具体环节。
流程要可复现。评测脚本、数据格式、计算逻辑都得公开，任何人拿同样的输入都能跑出同样的分数。这是"公平"的底线。
OmniDocBench 的设计思路基本就是照着这几条来的。它不是一个单纯的测试集，而是一整套"数据 + 标注规范 + 评测指标 + 工具链"的组合。
1.3 OmniDocBench 在评测生态里的位置
要理解 OmniDocBench 的价值，得先看清它在整个文档解析生态里扮演什么角色。
上游是各种文档解析模型和工具，比如基于 OCR 的、基于版面分析的、基于多模态大模型的，它们负责把 PDF、图片转成结构化文本。下游是各种应用，比如合同审查、招标文件比对、知识库构建、RAG 检索增强。中间缺的就是一个公正的裁判——告诉上游"你做得怎么样"，告诉下游"该选哪个"。
OmniDocBench 就是这个裁判角色。它不生产解析能力，它生产的是"衡量解析能力的标准"。这个定位很关键，因为它决定了它的设计必须中立、必须全面、必须可复现。一个偏向某类模型的评测集，比没有评测集还糟糕，因为它会误导整个领域的优化方向。
2. OmniDocBench 的评测体系是怎么搭起来的
2.1 文档类型的覆盖策略
OmniDocBench 在文档类型覆盖上下了不少功夫。它没有只盯着某一类文档，而是按"真实业务场景"来组织数据。
学术论文类是基础盘，这类文档结构清晰、层级分明，适合考察模型对标题、摘要、章节、公式、参考文献的识别能力。合同和招标文件是重头戏，这类文档的特点是条款编号复杂、表格多、有大量固定格式的字段，考察的是模型对业务结构的理解。报表和财务文档则重点考察表格解析，尤其是合并单元格、跨页表格、嵌套表头这些难点。书籍和幻灯片考察的是长文档的阅读顺序和版面理解。
除了类型覆盖，它还很重视输入质量的多样性。干净的电子版 PDF 是一种，扫描件是另一种，拍照件又是另一种。扫描件有噪点、有倾斜，拍照件有透视变形、有光照不均。模型在这些"非理想"输入上的表现，往往才是决定它能不能落地的关键。
提示：评估一个文档解析方案时，别只看它在干净 PDF 上的分数。拿一批真实的扫描合同去测，差距立刻就出来了。
2.2 标注粒度：从文本到结构的四层信息
OmniDocBench 的标注不是简单的"框 + 文字"，而是分了四个层次，这也是它区别于普通 OCR 测试集的核心。
第一层是文本内容。这是最基础的，就是每个文本块里到底是什么字。但注意，它不是按字符标注，而是按语义块标注。一个段落是一个块，一个标题是一个块，一个表格单元格是一个块。这样标注的好处是，评测时能直接对应到结构化输出的粒度。
第二层是位置信息。每个块在页面上的坐标（通常是边界框）都要标出来。位置信息决定了模型能不能准确定位内容，也决定了阅读顺序能不能还原。没有位置标注，就没法判断模型输出的顺序对不对。
第三层是层级与阅读顺序。这是文档结构化的灵魂。一个标题属于哪一级、一个段落属于哪个章节、多个栏目的阅读顺序是什么，这些都要标。很多模型文本识别很准，但阅读顺序一塌糊涂，输出来的结构化文本根本没法用。OmniDocBench 把这一层单独拎出来评，就是为了暴露这类问题。
第四层是表格结构。表格是文档解析里最难啃的骨头。OmniDocBench 对表格的标注细到单元格级别，包括每个单元格的行列位置、合并关系、表头归属。这样才能用 TEDS 这类指标去精确衡量表格解析的质量。
2.3 评测流程的标准化设计
有了数据和标注，还得有标准化的评测流程，否则不同人跑出来的结果还是没法比。
OmniDocBench 的流程大致是这样的：模型对每份文档输出结构化结果，结果按统一格式组织（通常是类似 Markdown 或 JSON 的结构化文本），然后评测脚本把模型输出和标注真值做对齐，再按不同维度计算指标。
这里有个容易被忽略的细节：对齐策略。模型输出的块和标注的块不可能一一对应，有的模型把一个段落拆成三块，有的把三块合成一块。怎么对齐？是按位置重叠度匹配，还是按文本相似度匹配？不同的对齐策略会影响最终分数。OmniDocBench 在这块有明确的规则，保证评测的一致性。
流程标准化的另一个好处是，它把"评测"这件事从"人工看"变成了"自动跑"。以前评估一个模型，得找几个人肉眼比对，费时费力还不客观。现在有了标准流程，跑一遍脚本就出结果，而且结果可复现。
3. 核心指标拆解：CDM、TEDS 到底在量什么
3.1 CDM：衡量文本与结构还原的综合指标
CDM 是 OmniDocBench 里用来衡量整体解析质量的核心指标之一。它的全称和具体定义在不同资料里表述略有差异，但核心思想是一致的：综合考察文本内容的准确性和结构的还原度。
你可以把 CDM 理解成一个"加权综合分"。它不只看你识别对了多少字，还看你的结构组织得对不对。一个模型可能文本识别率很高，但段落切分乱七八糟，那它的 CDM 分数就不会高。反过来，一个模型结构组织得很好，但个别字识别错了，CDM 会扣分但不会扣太狠。
这种设计的合理性在于，文档解析的最终目的是"可用"。用户要的不是一堆识别正确的字，而是一份结构清晰、能直接用的文档。CDM 把结构和内容放在一起评，更贴近真实需求。
实际用的时候要注意，CDM 的具体计算涉及多个子项的加权，不同版本的权重可能不同。看分数的时候，最好同时看它的子项拆解，别只盯着一个总分。
3.2 TEDS：表格解析的专用标尺
TEDS 是专门针对表格的评测指标，全称是 Tree-Edit-Distance-based Similarity，基于树编辑距离的相似度。这个指标在表格识别领域用得越来越广，OmniDocBench 也采用了它。
为什么表格要用专门的指标？因为表格的结构是树形的。一个表格有表头、有表体，表体里可能有嵌套的子表，单元格之间有合并关系。这种结构用普通的文本相似度根本衡量不了。TEDS 的思路是：把预测的表格和真值的表格都表示成树结构，然后计算两棵树之间的编辑距离，再归一化成相似度分数。
TEDS 的好处是它能同时反映结构正确性和内容正确性。如果模型把表格的行列搞错了，树结构就对不上，编辑距离大，分数低。如果结构对了但某个单元格文字识别错了，编辑距离也会增加，但增加得有限。这种"结构优先、内容其次"的权重设计，符合表格解析的实际需求——结构错了，内容再对也没用。
TEDS 还分两个版本：TEDS 和 TEDS-Struct。前者同时考虑结构和内容，后者只考虑结构。评估时两个都看，能更全面地了解模型表现。
| 指标 | 衡量对象 | 核心逻辑 | 适用场景 |
|---|---|---|---|
| CDM | 整体解析质量 | 文本准确性 + 结构还原度加权 | 综合评估模型整体能力 |
| TEDS | 表格解析 | 树编辑距离相似度 | 表格结构 + 内容评估 |
| TEDS-Struct | 表格结构 | 仅结构层面的树相似度 | 单独考察表格结构还原 |
3.3 指标背后的取舍逻辑
任何指标设计都有取舍，OmniDocBench 也不例外。理解这些取舍，才能正确解读分数。
第一个取舍是结构 vs 内容。前面说了，TEDS 偏向结构。CDM 虽然综合，但结构部分的权重也不低。这个取舍背后的逻辑是：文档解析的核心价值在结构，内容识别是基础但相对成熟。一个结构还原得好的模型，即使个别字错了，用户也能用；一个结构崩了的模型，字全对也没法用。
第二个取舍是严格 vs 宽松。比如阅读顺序的评测，是要求完全一致才算对，还是允许一定程度的偏差？完全一致太苛刻，因为有些文档的阅读顺序本身就有歧义；太宽松又失去了评测意义。OmniDocBench 在这块有明确的容差规则，保证评测既严格又合理。
第三个取舍是粒度。是按页评、按文档评，还是按块评？按页评能反映局部问题，按文档评能反映整体表现，按块评能定位具体错误。OmniDocBench 通常提供多个粒度的结果，方便不同需求的使用者。
4. 拿 OmniDocBench 做实际评测的完整流程
4.1 环境准备与数据获取
要用 OmniDocBench 做评测，第一步是把环境和数据准备好。
数据方面，OmniDocBench 的测试集和标注文件需要从官方渠道获取。拿到之后先别急着跑，花点时间看看数据格式。它的标注通常是 JSON 或类似的结构化格式，每个文档对应一个标注文件，里面包含页面信息、块信息、层级关系、表格结构等。看懂格式，后面处理结果的时候才不会懵。
环境方面，主要是 Python 环境加上一些依赖库，比如处理 PDF 的、处理图像的、计算指标的。具体依赖看官方文档，不同版本可能有差异。我的建议是直接用虚拟环境，避免和现有项目冲突。
注意：数据获取后先做一次完整性校验，确认文件没损坏、标注没缺失。我见过有人跑了一半才发现数据不全，白折腾。
4.2 模型输出的格式对齐
这是整个流程里最容易出问题的一步。OmniDocBench 对模型输出有格式要求，你的模型输出必须转成它认识的格式，才能进入评测。
通常的做法是写一个适配层，把模型的原生输出转成 OmniDocBench 要求的格式。这个适配层要处理几件事：文本块的切分方式、位置信息的坐标系统、层级关系的表达、表格结构的序列化。
坐标系统特别容易踩坑。有的模型输出的是归一化坐标（0 到 1），有的是像素坐标，有的原点在左上角，有的在左下角。OmniDocBench 有它自己的约定，转换的时候一定要对齐，否则位置匹配全错，分数会低得莫名其妙。
表格结构的序列化也是个难点。不同模型对表格的表示方式差异很大，有的用 HTML，有的用 Markdown，有的用自定义 JSON。转成 OmniDocBench 要求的格式时，要特别注意合并单元格和嵌套结构的表达。
4.3 跑评测与结果解读
格式对齐之后，就可以跑评测脚本了。脚本会输出一堆指标，包括 CDM、TEDS、文本准确率、阅读顺序准确率等。
看结果的时候，别只看总分。我的习惯是先看子项，定位问题在哪。如果文本准确率高但 CDM 低，说明结构还原有问题；如果 TEDS 低但 TEDS-Struct 高，说明表格结构对了但内容识别有误；如果阅读顺序准确率低，说明模型对版面理解不够。
定位到问题之后，再回去看具体是哪些文档、哪些页面出了问题。OmniDocBench 通常会输出详细的错误报告，能精确到具体的块和单元格。拿着这些报告去分析，比盲目调模型有效得多。
4.4 常见报错与排查思路
跑评测的过程中，报错是家常便饭。我整理几个常见的。
格式不匹配报错。最常见的就是模型输出格式和评测脚本期望的不一致。排查方法是拿一份模型输出和一份标注真值对比，看字段名、数据结构、坐标范围哪里对不上。
对齐失败报错。模型输出的块和标注的块匹配不上，可能是位置偏差太大，也可能是文本差异太大。这时候要检查坐标转换是否正确，文本是否做了归一化处理（比如全角半角、大小写）。
指标异常报错。分数低得离谱或者高得离谱，通常是数据问题。检查一下是不是把测试集当训练集跑了，或者标注文件加载错了。
内存溢出报错。文档多、图片大的时候容易遇到。解决办法是分批处理，或者降低图片分辨率（但要注意别影响评测准确性）。
5. 用 OmniDocBench 时最容易踩的几个坑
5.1 把评测集当调参集
这是最严重也最常见的坑。有人拿到 OmniDocBench 的测试集，直接在上面调模型参数，调到最后分数很高，但模型实际泛化能力很差。这等于作弊，评测失去了意义。
正确的做法是：测试集就是测试集，只能用来最终评估，不能用来调参。调参要用单独的验证集。如果 OmniDocBench 提供了划分好的验证集，就用它；如果没有，自己从训练数据里划一部分出来。
5.2 忽略标注口径导致分数虚高
前面说过，不同评测集的标注口径不一样。用 OmniDocBench 的时候，一定要先搞清楚它的口径，再对照自己的模型输出。
举个例子，OmniDocBench 对段落的定义可能是"语义完整的文本块"，而你的模型可能按行切分。如果你不调整，模型输出的一堆行和标注的一个段落对不上，分数自然低。这不是模型不行，是口径没对齐。
反过来，如果你为了迎合评测口径，把模型输出硬凑成标注的样子，分数是上去了，但模型的实际能力没变。这种"刷分"行为要不得。
5.3 只看总分不看细分
总分是个笼统的概念。一个模型总分 80，可能是文本 95 结构 65，也可能是文本 70 结构 90。这两种情况对应的问题完全不同，优化方向也完全不同。
我的建议是，评测结果至少拆到三个维度看：文本识别、结构还原、表格解析。每个维度再往下拆，比如结构还原可以拆成阅读顺序、层级关系、块切分。拆得越细，越能定位问题。
5.4 忽视文档类型的影响
OmniDocBench 覆盖多种文档类型，但不同模型在不同类型上的表现差异可能很大。一个模型在学术论文上表现优秀，在合同上可能一塌糊涂。
看评测结果的时候，一定要按文档类型分开看。如果某个类型分数特别低，那可能就是模型的短板，也是下一步优化的重点。别被一个笼统的高总分迷惑了。
6. 从评测结果反推文档解析的优化方向
6.1 文本层问题的典型表现与修复
文本层的问题相对好定位，表现也直观：识别错字、漏字、多字。
常见原因有几个。一是字体和编码问题，特殊字体、生僻字、数学符号容易识别错。解决办法是扩充训练数据里的字符集，或者针对特定字体做微调。二是图像质量问题，扫描件模糊、拍照件光照不均会导致识别错误。解决办法是加图像预处理，比如去噪、二值化、纠偏。三是版面干扰，水印、印章、页眉页脚会干扰文本识别。解决办法是加版面分析，先把干扰元素剔除。
修复文本层问题，优先级是：先解决高频错误，再解决低频错误；先解决影响面大的问题，再解决边角问题。
6.2 结构层问题的排查路径
结构层的问题比文本层隐蔽，但影响更大。典型表现是：文本都识别对了，但组织出来的结构没法用。
排查路径可以这样走。先看阅读顺序，是不是多栏文档读串了，是不是图文混排读乱了。再看层级关系，标题级别对不对，段落归属对不对。最后看块切分，段落是不是切得太碎或太粗，表格是不是被当成了普通文本。
结构问题的根因通常在版面分析环节。模型对版面的理解不够，就还原不出正确的结构。优化方向是加强版面分析能力，比如引入更强的视觉特征、增加版面标注数据、用多模态模型做联合理解。
6.3 表格解析的专项优化
表格是文档解析里最难的部分，也是 OmniDocBench 重点考察的部分。表格解析的问题通常分两类：结构错误和内容错误。
结构错误包括：行列识别错、合并单元格识别错、表头识别错、跨页表格拼接错。这类问题的根因是模型对表格结构的理解不够。优化方向是加强表格结构识别，比如用专门的表格识别模型、增加表格结构标注数据、引入表格的视觉和文本联合特征。
内容错误就是单元格里的文字识别错了。这类问题相对好解决，本质还是文本识别问题，参考文本层的优化方法。
TEDS 分数是表格解析的晴雨表。如果 TEDS 低但 TEDS-Struct 高，说明结构对了内容错了，重点优化文本识别；如果两个都低，说明结构有问题，重点优化结构识别。
7. 文档解析评测这件事的后续演进
OmniDocBench 解决的是"有没有公平尺子"的问题，但尺子本身也需要不断校准。文档解析这个领域在快速变化，新的文档类型、新的解析需求、新的模型架构不断涌现，评测体系也得跟着演进。
我观察到几个趋势。一是评测维度在扩展，从单纯的文本和结构，扩展到语义理解、信息抽取、问答能力。文档解析的终点不是结构化文本，而是可用的信息。二是评测方式在变化，从静态测试集，到动态评测、对抗评测。静态测试集容易被"刷爆"，动态评测能更好地反映模型的真实能力。三是评测和应用的结合在加强，评测指标越来越贴近下游任务的需求，比如 RAG 场景下的检索准确率、合同审查场景下的字段抽取准确率。
对于做文档解析的团队来说，我的建议是：把 OmniDocBench 当成一个参考，但别把它当成唯一标准。真实业务场景的评测同样重要，甚至更重要。毕竟，模型最终是要解决实际问题的，不是刷榜的。
我在实际项目里的体会是，评测这件事，工具是一方面，方法论是另一方面。有了 OmniDocBench 这样的工具，方法论还得自己建。你得清楚自己的业务场景需要什么样的解析能力，然后针对性地设计评测方案。通用评测告诉你模型"大概行不行"，业务评测告诉你模型"到底行不行"。两者结合，才能做出靠谱的选型决策。
最后分享一个小技巧：跑 OmniDocBench 的时候，别只跑一次。同一批数据，换个随机种子、换个批次顺序，多跑几次，看分数的波动范围。波动大的话，说明模型不稳定，实际用起来风险高。这个细节，很多评测报告里不会写，但实际选型的时候特别有用。
