83.85% vs 17.91%：FormStruct-Bench 揭开表单解析的错觉

原创于 2026-08-19 13:57:30 发布 · 316 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

智能文档

话题

#CodingPlan·八月创作之星博客挑战赛

氛围图

💡 一句话总结：FormStruct-Bench 把表单解析从“字段抽取对了几个”推进到“结构到底坏在哪一层”；它测出最强内容分数可达 83.85%，但最佳主结构指标只有 17.91%。如果你做文档 AI、RAG 前置解析或流程自动化，这篇很值得读。

🎯 导语：解析结果看起来很对，直到入库那天

先问一个可能戳到你的问题：你那个表单解析 pipeline，真的知道每个值属于哪里吗？

做文档抽取的人多半见过这种场面：模型把 “Bob”“Male”“28” 都读出来了，OCR 置信度也很漂亮。可一进数据库，年龄跑到联系方式下面，性别选项被当成普通文本，跨列合并的表格头彻底消失。人看渲染结果觉得“差不多”，机器看 JSON 只能说“完全不对”。

这不是文本识别失败，而是结构识别失败。Lujie Ban 等人的论文 FormStruct-Bench: A Hierarchical and Diagnostic Benchmark for Table-Form Document Structure Recognition 就是冲着这个问题来的：当一个表单解析错了，我们能不能知道它错在区域、网格、字段路径、控件，还是关系？

想自己动手试？

📄 论文：arXiv 2608.10396
💻 代码：GitHub · D2I-CUHKSZ/FormStruct-Bench
📊 数据集：HuggingFace · D2I-CUHK-Shenzhen/FormStruct-Bench

🤔 这篇论文到底想解决什么问题？

表单类文档很特殊。它长得像表格，但不是一张规整表格；它也像文档，但价值不只藏在段落里。申请表、税务表、医疗登记表通常同时包含语义区域、局部网格、输入框、复选框、签名区和跨区域关系。

问题是，原有两条评测路线都只覆盖了一半。

表格结构识别（TSR，Table Structure Recognition） 关心行列、span、单元格边界，但通常假设目标是一张全局表格。表单里的“个人资料区”“选项组”“签名区”不在它的核心目标里。
文档 AI / 信息抽取 关心字段和值，也做整页布局，但常常用聚合分数评价输出。你说模型得了 80 分，可它到底把区域认错了、网格拼错了，还是关系边接反了？分数不告诉你。

这会带来一个很实际的坑：文档级指标看起来不错，下游结构却不可用。尤其在 RAG、自动化审核、流程录入这些场景里，字段挂错层级比漏一个字更危险，因为它会安静地污染后续数据。

所以论文提出的是 table-form document structure recognition：给定表单图像，模型不只预测字段和值，还要恢复一个层级结构，包括类型化语义区域、每个区域自己的局部网格、字段、控件组，以及有向、有类型的关系边。

换个生活化的类比，这就像整理一间办公室。TSR 只检查桌子摆得直不直；字段抽取只检查每件东西有没有被念出名字；FormStruct-Bench 还要检查“这台显示器属于哪张桌子、插在哪台主机上、线是谁连到谁”。东西都读出来，不代表办公室能开工。

🛠️ 它的思路是什么？

论文做了三件事：构造可审计数据、定义层级目标、再给一套能定位失败层的指标。

先说数据。人工标注 7,000 个完整表单太贵，也太容易不一致。于是作者把“结构骨架”和“填充内容”拆开：先由人工标注 70 个真实模板，再通过 Director–Artist–Verifier 流水线扩展成 7,000 个实例。

FormStruct-Bench 数据流水线
图说：左边收集真实模板并人工标注；中间由 Director 规划内容、Artist 渲染、Verifier 检查；右边保留 provenance 并进入评测。

Director（导演）：根据模板字段和目标约束，采样字段值、可选路径、布局参数和视觉退化。也就是说，难度不是事后猜的，而是生成时指定的。
Artist（美术）：根据元数据渲染表单，并在渲染时同步生成精确标签。它不拿原始文档来抄，避免标签跟着图像一起漂移。
Verifier（质检）：从渲染后的图像重新抽取结构，和参考答案对比，再检查区域类型、网格、控件状态、OCR 可读性、视觉参数和关系合法性。失败就重生成。

这套流程的聪明之处在于：人工负责最难的层级和关系定义，机器负责规模化变体和自动检查。所有实例保留模板来源、生成参数、约束标签和验证结果；测试集的 1,100 个实例还全部经过人工复核。

再看评测。FormStruct-Bench 不是给一个总分就结束，而是把分数拆到不同层级：

Value-nED（值归一化编辑相似度，越高越好）：看非空字段值读得像不像，不管值挂在哪条路径上。
Schema-nTED（结构树编辑相似度，越高越好）：只看字段名、容器和层级，不看 filled value。
TSR-path（层级路径正确率，越高越好）：一条字段路径和值都完全对了才算，衡量“值有没有挂对地方”。
R-F1@0.5、LIG-F1、LG-GriTS Top、WG-F1、Rel-F1（越高越好）：分别看区域检测、重复条目组、局部网格拓扑、控件分组和类型化关系。

这组指标最关键的意图是拆失败模式。比如 Value-nED 高、TSR-path 低，说明文本读到了但层级挂错；WG-F1 低，说明复选框虽然可见，却没有被正确归到父字段；Rel-F1 低，则可能是端点没对齐，也可能是关系类型或方向错了。

📈 效果到底怎么样？

结果有点扎心：系统能读出内容，但很难恢复结构。

论文评测了 14 个 API 或本地可部署系统，加上两个 SFT 变体。最好的文档级 Value-nED 达到 83.85%，但最好的主结构指标 TSR-path 只有 17.91%；区域检测 R-F1@0.5 最好 12.49%，控件分组 WG-F1 最好 3.94%，关系 F1 最好也只有 2.81%。

系统	Value-nED	TSR-path	R-F1@0.5	WG-F1	Rel-F1
GPT-5.5	80.98	17.15	1.74	0.02	0.09
Seed 2.1 Pro	77.45	15.90	10.77	0.86	2.81
Qwen3.5-9B-SFT	83.85	17.78	10.81	0.00	0.00
Qwen3.6-35B-A3B-SFT	77.83	16.84	12.49	3.94	2.24

这张表最值得看的不是谁第一，而是“没有全家桶冠军”。GPT-5.5 读值很稳，区域分数很低；Qwen3.5-9B-SFT 内容分数最高，但控件和关系是零；Seed 2.1 Pro 关系最好，内容分数又不是最高。

难度分层结果
图说：从 L1 到 L4，内容读取比区域定位稳得多；结构越复杂，空间组织能力掉得越明显。

论文给了一个很直观的例子：Seed 2.1 Pro 的 R-F1@0.5 从 L2 的 13.76 降到 L4 的 7.23，相对下降 47.5%；Qwen3.6-35B-A3B 的区域分数也下降了 42.6%。相比之下，Value-nED 的退化幅度更小。我的读法是：模型越难时越会靠全局语义“猜出 plausible 字段”，但 precise spatial binding 更容易崩。

视觉退化结果
图说：页面级排名在退化下还算稳定，但精确路径绑定 TSR-path 在所有退化类型下都下降。

视觉退化实验也支持这个判断：页面级分数的排名大体不变，但 TSR-path 在每种退化类型和严重度下都会掉，约损失 3.8 到 6.3 个百分点。也就是说，扫描噪声伤得最重的不是“认字”，而是“把字挂回正确结构”的能力。

更有意思的是 SFT。作者用合成表单微调 Qwen3.5-9B 和 Qwen3.6-35B-A3B，再在真实表单上评测，发现两个规模的内容恢复、schema 重建和层级绑定都有提升。这说明合成模板学到的结构规律确实能迁移，不只是背数据集。

SFT 迁移结果
图说：合成表单上的监督学习让两个模型规模在真实表单的多个结构相关指标上获得提升。

还有一个很工程向的发现：关系错误不只来自端点定位。论文的定性案例里，模型找到了 “Date available to start work” 和对应值，却把 key-value 关系写成了 parent-child；另一个日文案例里，Gender 和 Female 都识别出来了，边却接反了。

关系错误示例
图说：即使端点已经对齐，模型仍可能错关系类型或方向；这解释了为什么 Rel-F1 需要单独报告。

💡 为什么你要关心？

如果你只是拿 VLM 做“读出这段文字”，这篇可能显得太严格。但只要你的下游是结构化入库、审计、流程自动化或 RAG 检索，它就很相关：因为下游消费的是结构，不是漂亮的文本片段。

我建议你关注三个可操作点：

🧪 别只用文档级指标验收。 一个 pipeline 可以 Value-nED 很高，同时 TSR-path 很低。至少加一条层级路径正确率，否则你不知道字段是不是挂错树。
🧩 把失败切片进日志。 区域、局部网格、控件状态、关系端点、关系类型分开记。调 prompt、坐标表示或后处理时，才知道到底改善的是哪层。
🏗️ 把结构约束当作测试用例。 关系密集、局部网格密集、控件密集、视觉退化这些切片，比随机抽几张 PDF 更容易暴露回归。

换个角度看，这篇论文也在提醒我们：结构化输出不是“JSON 有了”就完事。JSON 只是一种外观；坐标是否准、父子关系是否对、方向和类型是否正确，才是机器可用的结构。