在当今的数字环境中,我们被文档的海洋所包围。每天都有数以百万计的 PDF、扫描图像和幻灯片被生成。对于人类来说,这些文档具有清晰的结构: 顶部是标题,下面是章节、子章节、段落和图片。我们直观地理解“章节标题”是其下方“段落”的父级。
然而,对于计算机而言,扫描的 PDF 通常只是一堆像素,或者充其量只是无序的文本流和边界框。
这种感知上的脱节是人工智能的一个主要瓶颈。如果我们希望机器真正理解文档——用于信息检索、数据库存储或检索增强生成 (RAG) 等任务——我们需要它们掌握文档层级解析 (Document Hierarchy Parsing, DHP) 。
在这篇文章中,我们将深入探讨一篇最近的论文,题为 “DocHieNet: A Large and Diverse Dataset for Document Hierarchy Parsing” (DocHieNet: 一个用于文档层级解析的大型多样化数据集) 。 来自浙江大学和阿里巴巴集团的研究人员解决了该领域中的两个巨大问题: 缺乏现实的训练数据,以及现有模型无法处理长篇多页文档的问题。
问题所在: 为什么 DHP 比看起来更难
文档层级解析的任务是重建文档的“树状”结构。想象一下目录;DHP 旨在为每一页上的每个元素自动生成这种结构。
虽然光学字符识别 (OCR) 为我们提供了文本,布局分析为我们提供了框 (段落和图像的位置) ,但这两者都没有告诉我们它们是如何相互关联的。
数据匮乏
多年来,研究界一直受阻于缺乏优质数据。以前的数据集存在以下问题:
- 太小: 像 arXivdocs 这样的数据集仅包含几百页。
- 太简单: 它们通常只关注单页,忽略了跨越 50 页以上的文档的复杂性。
- 太同质化: 它们严重依赖科学论文 (其布局非常可预测) ,忽略了现实世界文档 (如财务报告、杂志或政府招标文件) 的混乱多样性。
这种多样性的缺乏意味着,在现有数据上训练的模型一旦面对光鲜亮丽的杂志排版或复杂的法律合同,就会惨遭失败。
贡献 1: DocHieNet 数据集
为了解决数据问题,作者推出了 DocHieNet 。 它是目前最大、最多样化的文档层级解析数据集。
关键统计数据:
- 1,673 份文档: 涵盖多个领域 (法律、金融、教育等) 。
- 多页: 文档长度可达 50 页。
- 双语: 包含英文和中文文档。
- 复杂布局: 超越了标准的单栏文本。

如 图 1 所示,其多样性令人震惊。我们不再只是看着学术论文;我们看到了网页、幻灯片、复杂的图表和多栏通讯。红线展示了模型需要预测的层级关系。
标注的新标准
这篇论文的一个微妙但至关重要的贡献是他们选择如何标记数据。过去,数据集使用的标准不一致。有些在文本行级别标记层级 (这过于细粒度并会产生巨大的树) ,而另一些则使用模糊的块定义。

图 2 展示了这种演变:
- (a) & (b): 以前的尝试通常难以处理逻辑流或局限于单页。
- (c) HRDoc: 使用行级标注 (绿线将行连接成段落) 。这混淆了“分组文本”与“理解层级”的任务。
- (d) DocHieNet: 在布局元素级别进行标注。这假设 OCR 系统已经将文本分组成块 (段落、标题) ,使 DHP 模型能够专注于高层级的树状结构 (红线) 。
这种设计选择使得数据集更能反映现实世界的应用场景,在这些场景中,我们通常关心整个段落与章节标题的关系,而不是第 1 行与第 2 行的关系。
从数据分布中可以看出 DocHieNet 与之前的基准相比的复杂性:

如 图 3 所示,与 arXivdocs 或 E-Periodica 等数据集相比,DocHieNet (蓝色条) 的页数分布更广 (图 a) ,并支持更深的层级结构 (图 b) 。
贡献 2: DHFormer 框架
拥有一个好的数据集只是战斗的一半。研究人员还需要一个能够处理这些长篇、复杂文档的模型。
标准的 Transformer 模型 (如 BERT 或 RoBERTa) 通常有输入长度限制 (通常为 512 个 token) 。一份 50 页的文档可能有数万个 token。如果你试图将其输入到标准的 Transformer 中,由于注意力机制呈二次方扩展 (\(O(N^2)\)) ,你会立即耗尽内存。
为了解决这个问题,作者提出了 DHFormer 。

图 4 概述了该架构,它由两个主要阶段组成: 稀疏文本-布局编码器和全局布局元素解码器。
1. 稀疏文本-布局编码器 (Sparse Text-Layout Encoder)
DHFormer 没有计算第 1 页和第 50 页上每一个单词之间的注意力 (这在计算上极其昂贵且通常是不必要的) ,而是使用了基于分块的策略 。
文档被分解成块 (子部分) 。密集注意力 仅在这些块内 计算。这使得模型能够理解文本的细粒度上下文 (单词的含义) ,而不会导致内存激增。
这种分解注意力的数学公式为:

这里,注意力 \(Att(X, C)\) 是针对特定块 \(C\) 内的输入嵌入 \(X\) 计算的。键 (Key, \(K\)) 和值 (Value, \(V\)) 矩阵推导如下:

这种方法将复杂度从二次方 \(O(N^2)\) 降低到线性 \(O(l \cdot N)\),其中 \(l\) 是块大小。
2. 专门的位置嵌入 (Specialized Position Embeddings)
标准语言模型使用 1D 位置嵌入 (词 1,词 2,词 3) 。LayoutLM 添加了 2D 位置嵌入 (x, y 坐标) 。
然而,对于多页层级结构,作者认为这还不够。他们引入了两种新的嵌入:
- 页面嵌入 (Page Embeddings): 明确告诉模型布局元素在哪一页。这对于将第 4 页的标题与第 5 页的副标题联系起来至关重要。
- 内部布局位置嵌入 (Inner-Layout Position Embeddings): 帮助模型理解文本序列中布局元素的边界。
3. 全局布局元素解码器 (Global Layout Element Decoder)
一旦稀疏编码器处理完文本,特征就会被“池化” (汇总) 为每个布局元素的表示 (例如,一个向量代表整个段落) 。
然后,这些布局向量被输入到全局解码器中。因为我们现在处理的是布局元素而不是单个 token,所以序列要短得多。这允许解码器一次性查看 整个文档 来推理全局结构。

最后,模型使用双线性层和 sigmoid 函数预测任意两个元素 \(i\) 和 \(j\) 之间的关系。这实际上是在问: “元素 \(i\) 是元素 \(j\) 的父级吗?”

实验与结果
那么,它有效吗?作者将 DHFormer 与几个最先进的基线模型进行了比较,包括 DocParser 和 DSPS。他们使用了两个主要指标:
- F1 分数: 衡量预测的父子对的正确性。
- TEDS (基于树编辑距离的相似度): 一个更严格的指标,用于查看整个树结构的准确性。
定量性能
表 2 总结了在 DocHieNet 数据集和旧数据集上的结果:

从表 2 中得出的关键结论:
- DocHieNet 很难: 注意所有模型在 DocHieNet (最右栏) 上的得分都明显低于 arXivdocs 或 HRDoc。这证实了 DocHieNet 确实是一个更具挑战性、更现实的基准。
- DHFormer 占据主导地位: DHFormer 在 DocHieNet 上达到了 77.82 的 F1 分数,大大超过了次优模型 (DSG) ,后者的得分为 53.51。它在旧数据集上也达到了最先进的结果。
LLM 不能直接做这个吗?
2024 年一个常见的问题是: “为什么要训练一个特定的模型?GPT-4 或 Llama-2 不能解决这个问题吗?”
作者通过提示 (prompting) 将布局信息输入 LLM 进行了测试。结果如 图 5 所示,非常具有启发性。

红线代表 DHFormer,而蓝线和绿线分别代表 GPT-4 和 Llama-2。
- 短文档: LLM 在非常短的文档上表现尚可。
- 长文档: 随着布局元素数量的增加 (x 轴) ,LLM 的性能会崩溃。它们难以在长序列中保持空间和层级上下文。
- 稳定性: 无论文档长度如何,DHFormer 都保持了高准确率。
这凸显了虽然 LLM 是强大的通才,但在涉及长篇、重视觉输入的结构化任务时,专用架构仍然具有优势。
消融研究
为了证明他们的设计选择至关重要,作者进行了消融研究。
编码器选择: 他们测试了编码器的不同骨干网络。如 表 4 所示,与 XLM-RoBERTa 等纯文本模型相比,使用具有几何感知能力的模型 (GeoLayoutLM) 提供了最佳结果。

嵌入的影响: 他们还验证了自定义嵌入的重要性。 表 7 显示,移除页面嵌入或内部布局嵌入都会导致性能下降,而同时移除两者会导致显著下降。

结论
DocHieNet 论文提出了一个令人信服的观点: 我们需要更好的数据和专门的模型来真正解决文档理解问题。通过创建一个反映现实世界混乱情况的数据集——多页、多领域和复杂布局——他们为该领域设立了新的基准。
此外, DHFormer 框架表明,我们不能仅仅依靠标准 Transformer 或现成的 LLM 来完成这项任务。处理长文档的几何结构和层级关系需要特定的架构选择,如稀疏注意力和层级感知嵌入。
对于文档 AI 领域的学生和研究人员来说,这项工作为更复杂的应用打开了大门。想象这样一个世界: 你可以上传一份 100 页的财务审计报告,你的人工智能不仅能立即理解文字,还能理解报告的确切结构逻辑。这就是 DocHieNet 正在帮助构建的未来。
](https://deep-paper.org/en/paper/file-2974/images/cover.png)