EMNLP2022 | 文档格式千千万，统一预选模型XDoc给你办！(微软 & 含源码)

点击下方卡片，关注‘’AINLPer‘’

更多干货，第一时间送达

引言

 不论在学术还是在工作中，相信很多做文档理解的小伙伴都知道，预训练模型需要微调才能适用不同格式的文档，但是「现实文档格式千千万，怎么才能训练一个统一的模型用来处理不同格式文档呢」？为此今天给大家分享的这篇EMNLP2022的文章给出了解决思路。最近EMNLP2022接受论文不断更新，给大家整理了第二波接受论文供大家下载，下载方式回复：历年EMNLP

背景介绍

 文档理解无疑是一个重要的研究课题，因为在我们日常生活中，文档的信息传递中起着至关重要的作用。在过去的几年里，由于深度学习的蓬勃发展，我们也见证了各种格式（纯文本、文档文本、web文本）的文档理解。最近，预训练技术已经成功应用到文档理解，其中模型首先以自监督的方式在规模语料上进行预训练，然后对一系列下游任务进行微调，如问答、关键信息提取等。「尽管在特定任务上取得了不错的效果，但现有的预训练模型并不灵活，因为它们只能处理单一格式的文本」（例如 LayoutLM是为处理文档文本而设计的，不适合 Web文）。这使得很难结合来自多种文档格式的知识。同时，如果学术界进一步研究更多格式（例如 Word 和 PowerPoint），预训练模型的类别将不断增加。 「在不同的文档理解预训练模型中，可以观察到，许多预训练模型具有相似的体系结构」，如单词嵌入层、1D位置嵌入层和Transformer层(如上图所示)。相比之下，也有不同的部分作为特定格式的先验知识(例如文档文本的二维坐标和web文本的xpath)。直观上，可以发现不同部分的参数远小于共享主体的参数。例如，基于 RoBERTa的 LayoutLMBASE 包含 131M 个参数，而 2D 位置嵌入层仅包含3M个参数(2.3%)。同样，基于RoBERTa的MarkupLMBASE有138M参数，而 XPath 嵌入层仅包含11M参数 (8.0%)。「因此，必须针对各种文本格式设计统一的预训练模型，同时共享主干参数以使模型更加紧凑」。

模型介绍

 基于以上讨论，本文提出了XDoc，这是一种具有多个输入头的统一体系结构，并且专为不同类别的文档设计。 如上图所示，XDoc能够在一个模型中处理各种格式的文本(纯文本、文档文本和web文本)。对于任何输入序列，当其他先验知识可用时，XDoc 学习使用共享主干和附加嵌入层来嵌入它们。具体来说，对于任何输入文本T, XDoc首先使用WordPiece将其标记为子单词，其中L表示最大长度。随后，对于每个索引为i的子词，它首先被馈送到单词嵌入层，我们将输出表示为WordEmb()。然后添加一个可学习的一维位置嵌入1DEmb()。由于字嵌入层和一维位置嵌入层对于基于Transformer的模型是必不可少的，因此我们尝试在不同格式之间共享参数。基于此，我们将在接下来详细介绍每种文档格式的整体嵌入。

纯文本

 由于对于纯文本没有额外的先验知识，我们「简单地将单词嵌入和1D位置嵌入相加」，以构造下面Transformer层的输入。整体嵌入Emb(s^P_{i})如下：

文档文本

 文档文本的整体嵌入与纯文本不同，视觉丰富的文档文本通常以二维布局组织，其中每个文本框的坐标在理解中起着至关重要的作用。因此，在预训练期间必须考虑2D位置。「考虑到大多数参数是跨不同格式共享的，我们引入了一个自适应层来加强特定先验信息的区分」。自适应层简单地用轻量级的Linear-ReLU-Linear序列实现。我们将所有嵌入相加，构造整体嵌入Emb()如下：

web文本

 根据MarkupLM,我们将标记序列构造为[html, body, div, a, div, div, span]，表示从根到当前节点的标记顺序。此外，下标序列设置为[0,0,0,0,2]，其中，当一个父节点下有多个节点具有相同的标记名时，每个下标表示节点的索引。我们将标记嵌入和下标嵌入相加，得到XPath嵌入XPathEmb()。构造整体嵌入Emb()如下：

实验结果

 为了验证模型的准确性，我们选择GLUE基准和SQuAD来评估纯文本理解，选择FUNSD和DocVQA来评估文档理解，选择WebSRC (Chen等人，2021)来评估web文本理解。实验结果表明，XDoc在保持参数有效性的同时，在这些任务上实现了相当甚至更好的性能。具体实验结果如下：

论文&&源码

Paper：https://arxiv.org/pdf/2210.02849.pdf

Code：https://aka.ms/xdoc

点击下方链接🔗关注我们

「资料整理不易，点个赞、再看吧」