LAPDoc：布局感知文档提示

摘要

使用大量纯文本数据训练大型语言模型（大语言模型）的最新进展导致跨许多领域和任务（包括特定于文档的任务）的强泛化。 与此相反，有一种趋势是训练为文档理解量身定制的多模式 Transformer 架构，这些架构专门用于将文本输入与相应的文档布局融合。 这涉及一个单独的微调步骤，需要额外的训练数据。 目前，还没有具有与大语言模型相当的泛化能力的文档转换器，这就提出了一个问题：文档理解任务应该首选哪种类型的模型。 在本文中，我们研究了通过使用布局丰富将纯基于文本的大语言模型用于特定于文档的任务的可能性。 我们探索插入式修改和基于规则的方法，以利用布局信息丰富纯文本大语言模型提示。 在我们的实验中，我们研究了对商业 ChatGPT 模型和开源大语言模型 Solar 的影响。 我们证明，使用我们的方法，大语言模型在各种标准文档基准测试中都显示出改进的性能。 此外，我们还研究了噪声 OCR 和布局错误的影响，以及大语言模型在利用文档布局时的局限性。 我们的结果表明，与仅使用纯文档文本相比，布局丰富可以将纯基于文本的大语言模型的文档理解性能提高高达 15%。 总之，应该考虑这种方法来在基于文本的大语言模型或多模式文档转换器之间进行最佳模型选择。

1简介

在当今的商业环境中，公司面临着需要处理的数字文档数量不断增加的问题。 智能设备捕捉文档的可能性催生了新的数字商业模式，该模式大量使用相机捕捉，同时承诺高度自动化。 这导致需要处理的不同质量的数字化文档急剧增长。 除了发票、表格、投诉、收据和通知等文档类型之外，其他不太标准化的文档类型也变得越来越重要，例如合同文档、业务报告或法律文本。

理解文档完全需要理解文本和视觉模式，以及理解文档内容元素之间的空间关系，这些关系指导阅读过程，对于解释至关重要[1，p.1]。 1]。 最近，自动化文档图像理解取得了长足的进步：（i）与实际应用相一致的更大规模基准[1,2,3,4]允许现实世界的评估和训练。 (ii) 自监督预训练任务——可以利用大量数据而无需手工注释——已经产生了多模态神经模型。 这些模型可以将文档图像和文本（例如，通过 OCR 提取）作为输入[5,6,7,8]，或者可以从纯粹的视觉输入进行端到端操作，本质上也在这个过程中学习OCR[9, 10]。

人工智能领域最近最突出的发展之一是大型语言模型（大语言模型）的兴起，例如 OpenAI 的 ChatGPT [11]。 人们发现这些模型在各种自然语言理解任务中表现出色，并且经过指令调整以充当开放域问题解决器。 他们成功的关键在于规模——拥有大规模的训练数据和数十亿个参数——这带来了令人印象深刻的能力[12]。 与前面提到的多模态文档理解模型相比，传统的大语言模型仅处理文本. 这样，空间布局的形式对于文档 [6, 8] 的处理似乎至关重要，但由于其简化为一维文本序列而部分丢失。

在本研究中，我们重点关注以 LLM 为中心的文档理解管道，它将文本与文档布局融合在一起。 首先，使用 OCR 提取文档内容，生成一组带有方框几何形状的单词。 其次，这些信息被打包成纯文本表示，对文档的文本及其空间结构进行编码。 我们将在下文中将此步骤称为“语言化”。 第三，将生成的语言化文档与任务描述相结合，从而提示预先训练的生成大语言模型，无需进一步微调即可解决手头的文档理解任务。

该流程有两个好处：首先，它利用了大语言模型卓越的知识能力和推理能力——与当前的多语言模型相比，该模型目前已经进行了更大规模的训练，并提供了更大的参数容量。模态文档特定模型。 其次，与实际应用特别相关的是，管道提供了简单性的好处，因为它不涉及模型微调，从而使我们能够保留单一的通用模型。

具体来说，我们关注文档语言化的关键步骤，这提出了几个有趣的问题：即使没有/很少有关文档几何的信息，大语言模型在涉及具有挑战性的布局推理的文档理解任务中表现如何？ 我们向大语言模型提供文档表示的方式如何影响大语言模型，特别是，我们能否以允许大语言模型利用文档几何来实现与多模态模型相同的性能的方式改变文档表示？

我们通过对多个文档理解数据集进行实验来研究这些问题，包括来自 DUE 基准、SROIE、WebSRC 和专有 KIE 数据集（来自真实行业场景）的任务。 我们检查两个大语言模型，即ChatGPT3.5和开源大语言模型Solar[13]。

总的来说，我们做出了以下贡献：

1. 一种新颖的基于规则的方法，利用文档中的空间结构信息丰富现有以文本为中心的大语言模型的提示。 该方法适用于各种文档和任务，并且可以应用于各种布局，而无需进行微调。

2. 一组使用研究和现实世界文档数据集以及商业和开源模型的综合实验。 我们涵盖了各种特定于文档的任务、不同的阅读顺序以及添加到 OCR 数据中的噪声的影响。

3. 除了定量结果之外，我们还探讨了大语言模型在深入解释特别具有挑战性的案例中的文档布局时的局限性，为此我们注释了 SROIE 的一个子集。 .

4. 我们还讨论了效率问题，即将空间布局信息编码到提示中的不同方法所需的额外标记。

2相关工作

大语言模型：基于基于注意力的 Transformer 架构构建的语言模型[14]可能是目前人工智能领域研究最深入的模型之一。 由于它们经历了高速增长，通常涉及数十亿个参数，因此这些模型的容量和推理​​能力得到了快速发展[12]。 除了 OpenAI [15] 等商业提供商之外，还有 Llama 2 [16] 或 Solar[13] 等各种开源模型t2> 目前正在发展中。 模型有两种基本类型：（1）编码器，生成输入文本的表示并使用它们来做出有关文本的决策。 它们配备了额外的头层，可根据具体问题进行微调。 (2) 生成文本的解码器，可以使用提示进行训练，无需额外操作。 最近，后一种范式已成为主导方法，因为由此产生的大语言模型可以作为临时问题解决的通用代理，而无需针对特定任务进行微调。 指令调整被用作额外的训练步骤来促进这一点：它的目的是弥合大语言模型的下一个单词预测的目标和用户让大语言模型遵循人类指令的目标之间的差距。 [17]。 因此，我们在这项工作中重点关注指令调整的解码器模型。

多模态模型：许多多模态模型将 OCR 外包给预处理，并对文档图像和识别的文本+几何图形的组合输入进行操作[5,7,18]：例如，LayoutLM 系列，包括最新版本 LayoutLMv3 [19, 20, 21]，采用 BERT 型 Transformer 编码器 [22]，该编码器以词嵌入和视觉补丁嵌入的串联，并通过多个掩码语言建模（MLM）和词/补丁对齐任务进行训练。 该模型通过微调专用头部模型应用于下游任务。 同样，DocFormer [23] 应用图像和文本信号的早期融合以及全局文本图像对齐的预训练。 UDOP [24]遵循生成方法并通过编码器-解码器模型重建文本布局。

其他模型进行端到端操作，仅提供文档图像并在此过程中解决文本理解问题：Donut [9] 使用编码器-解码器架构，该架构经过预训练以识别文档图像大规模现实世界 (IIT-CDIP) 和综合文档上的文本。 同样，Dessurt [25] 将 OCR 集成为其模型的一部分。 上述许多论文都包括消融研究，证明模型受益于在输入中包含几何信息——经过相应的训练。 在这项工作中，我们将这个问题扩展到指令调整的大语言模型。

与我们最相似的工作是 Wang 等人[26]的 LATIN-Prompt，他们最近提出了布局感知文档表示和任务感知提示的组合，并且还进行了很好的研究- 过程中的调整。 我们通过以下方式扩展了这项工作：（1）研究多种语言表达策略，（2）将提示模板彻底视为一个免费的、与数据集无关的参数，以便仔细且独立于语言表达进行优化，以及（3）探索大语言的局限性通过检查挑战案例并评估布局和 OCR 不准确性的影响，更详细地验证模型的布局推理能力。

3方法

图 1 显示了我们方法的概述：给定一个文档，我们使用现成的 OCR 解决方案提取其文本和相应的单词几何形状。 使用我们称为语言化的步骤将文档转换为纯文本表示。 我们提出了不同的语言化策略，将几何和布局信息添加到文本文档表示中（参见第 3.1 节）。 为了研究语言表达相对于 OCR 几何不准确的鲁棒性，我们在语言表达之前通过对单词位置应用噪声或模拟布局分析错误来降低 OCR。 然后将口头文档与特定于任务的指令一起插入提示模板中，例如要回答的问题（第 3.3 节）。 然后将准备好的提示输入大语言模型，并从输出中解析响应。

图1： 我们的方法概述：使用不同的语言表达策略（蓝色）将文档 OCR 转换为文本表示。 在言语化之前，我们可以选择通过将噪声应用于 OCR 几何图形的空间位置（红色）来降低 OCR 性能。 然后将生成的文档文本表示插入到特定于任务的提示（黄色）中，并输入到大语言模型（绿色）中。 最后，从大语言模型输出中提取答案。

3.1 语言器

我们将语言描述器称为从有序的边界框集合以及与这些框关联的文本创建文本文档表示的策略。 该表示可以作为基于文本的大语言模型的输入。 此外，每个言语器都提供其输出格式的文本描述，以指导大语言模型解释言语器的输出。 我们在下面概述了多种不同的言语策略。 对于每个，我们都包含一个示例单词框的语言描述，其中包含文本“TAX INVOICE”、坐标 $(x_{left},y_{top},x_{right},y_{bottom})=(100,50,321,100)$ 和中心点 $(x,y)=(211,75)$：

1. PlainText 仅采用文本 $t$ 作为基线，无需额外的布局信息。 从 OCR 检索的文本行使用换行符连接以形成文档表示。 当没有可用的候选行时，我们将单词与空格连接起来。

2. BoundingBox 同时使用边界框坐标和文本。 使用自定义格式将框几何形状与每个框的文本一起编码。 坐标四舍五入为整数，并编码为“左”、“上”、“右”和“下”。 示例：
   
   左：$100$顶部：$50$右：$321$底部：$100$文本：'税务发票'

3. BoundingBoxMarkup 以 XML 样式标记格式格式化边界框坐标，后跟文本。 坐标四舍五入为整数，并编码为“左”、“上”、“右”和“下”。 示例：<box left=$100$ top=$50$ right=$321$ bottom=$100$/>TAX INVOICE

4. CenterPoint 将边界框中心点坐标格式化为 XML 样式标记格式，后跟文本。 坐标四舍五入为整数。 示例：
   
   <box x=$211$ y=$75$/>TAX INVOICE

5. SpatialFormat 使用几何图形通过插入空格和换行符来恢复原始文档布局。 为此，字符被放置在网格上，使得它们的空间位置与文档上的空间位置相似。 图2 显示了SpatialFormat 语言转换器的示例输出。 最多插入 4 个连续换行符。

6. SpatialFormatY 与SpatialFormat类似，但它只编码垂直维度上的空间信息，即只插入换行符，不使用空格进行水平对齐。 最多插入 4 个连续换行符。

7. PlainHTML 用作 WebSRC 数据集的控制运行，其中可以使用文档的结构化 HTML 表示形式。 示例：
   
   ...<h3 tid="3">税务发票</h3>...。

当使用 SpatialFormat 和 SpatialFormatY 进行口头表达时，每个页面都会单独进行口头表达。 然后将生成的页面语言与空换行符连接起来。

图2： SROIE 数据集中随机样本的语言化策略：原始（左）、SpatialFormat（中）和 PlainText（右）。

3.2噪声模型

常见 OCR 系统生成的 OCR 几何形状会出现波动，并且很少彼此完美对齐。 为了研究语言化策略相对于布局元素的顺序和空间关系不准确的鲁棒性，我们可以选择将噪声模型应用于 OCR 输出，然后再将其输入语言化器。 每个噪声模型都采用边界框的有序列表作为输入，其中初始顺序对应于底层 OCR 引擎的读取顺序。

1. NONE：恒等函数。 OCR 的坐标和文本不会被修改（用作控制运行）。

2. TRANSLATE：根据公式$(x_0,y_0,x_2,y_2)\to (x_0+{\mathrm{\Delta }}_i^x,y_0+{\mathrm{\Delta }}_i^y,x_2+{\mathrm{\Delta }}_i^x,y_2+{\mathrm{\Delta }}_i^y)$退化每个边界框$b_i$，其中${\mathrm{\Delta }}_i^x,{\mathrm{\Delta }}_i^y\in [-20,20]$是每个框均匀采样的随机数。 请注意，20px 大约是我们数据中的平均字符宽度，因此两个框相对于彼此最多可以移动 40px（或两个字母）。

3. SHUFFLE：随机打乱边界框列表。

4. NEAREST_NEIGHBOR：通过为每个边界框选择一个比 min_char_height 和 min_char_width 像素更近的后继框来重新排序边界框列表。 当没有或多个候选者时，根据框的原始顺序来选择后继框。 该程序模拟 Microsoft OCR 的自然阅读顺序模式 并且倾向于按列而不是按行读取表格，因为连续行之间的间距通常小于连续列之间的间距。

3.3提示

为了提示大语言模型，我们将语言文档插入到特定于任务的提示模板中。 由于此提示模板就像语言表达一样影响质量（顺序、措辞和措辞似乎很重要），因此我们的目标是将提示的效果与语言表达的效果严格分开。 为了确定合适的提示结构，我们将每个提示细分为常见的构建块并确定最佳组合。 遵循已知的提示创建指南[27]，我们生成 10 种不同的提示结构，并在一小部分数据上对它们进行评估。 这些结构的不同之处在于各个构建块的顺序，并使用 SROIE 挑战数据集上的 QA 任务进行评估（请参阅第 4.1 节）。

我们的提示分为四个部分： DOCUMENT 对应于语言化文档表示。 TASK 对要解决的任务进行编码。 FORMAT 描述用于语言表达的格式。 最后，OUTPUT使用示例描述了预期的输出格式。 我们确定了两种效果最好的模式 A、B:DOCUMENT TASK OUTPUT（模式 A)和 文档任务格式输出（模式B)。 基于这两种结构，我们为 KIE、QA 和 NLI 任务创建提示模板。 出于效率原因，我们将多个问题 (QA)、陈述 (NLI) 或要检索的密钥 (KIE) 分组到单个提示中。 对于包含多个需要回答的问题的 QA 和 NLI 样本，我们枚举以 0 开头的问题。 图 3 显示了包含多个问题的 QA 提示 B 的示例。。

图3： 包含三个问题的 QA 提示 B 示例。 模式B结构为：DOCUMENT（黑色）、TASK（蓝色）、FORMAT（橙色）和输出（绿色）。

3.4答案提取

由于大语言模型作为文本生成器的概率性质，它们的输出不能保证符合所请求的格式。 为了确保正确读出答案，我们按如下方式处理输出： (1) 我们请求一个 JSON 对象，该对象将答案分配给相应的枚举号（QA、NLI）或键（KIE）。 (2) 给定一个有效的响应对象，我们解析问题的答案。 (3) 给定多个有效响应对象，我们选择对所提出的问题具有最多答案的对象。 (4) 我们使用枚举数（QA、NLI）或密钥（KIE）从所选对象中提取特定答案。 (5) 如果没有返回有效的 JSON 对象，我们不会生成任何答案。 有关输出格式规范的示例，请参见图 3。

虽然 JSON 的生成在大多数情况下都能可靠地工作，但大语言模型偶尔会生成无法解析为有效 JSON 对象的输出。 我们在开发过程中观察到的边缘情况涉及 JSON 对象，其中包含正确的值但包含幻觉的键，例如price_of_green_tea 而不是 answer。 另一个常见的错误是嵌套对象，例如{“价格”：{“green_tea”：...} }。 在这些情况下，不会提取答案。

4实验

在接下来的实验中，我们研究合适的语言化策略是否能够支持具有更好布局推理的大语言模型，并提供开源和商业解决方案的示例性比较。 在大多数实验中，我们通过文档理解任务的准确性来衡量大语言模型对布局方面的意识（包括研究基准和行业数据集，请参见第 4.1 节）。 为了深入研究布局意识，我们还对手动注释的挑战案例的子集进行了定性研究（请参阅第 4.3.4 节）。

4.1数据集

DUE 基准 我们使用 DUE 基准[1] 评估我们的方法，特别是在数据集 DocVQA、InfographicsVQA、 TabFact 和 WikiTableQuestions 以及任务 VQA（DocVQA 和 InfographicsVQA）、TableNLI (TabFact) 和 TableQA (WikiTableQuestions)。 我们没有分析其他数据集 DeepForm、Kleister Charity 和 PWC，它们也是适当基准的一部分，因为这些文档的页数非常多.

WebSRC WebSRC[28] 是 36 万个问答对的集合，这些问答对是从跨越 11 个不同域的 60 个不同网站收集的。 除了 QA 对之外，数据集还包含网页片段，其中每个片段都包含源 HTML 的简化版本、屏幕截图和包含附加空间和布局信息的 JSON 文件。 由于从 JSON 和 HTML 数据中检索文本级边界框存在困难，我们手动对屏幕截图执行 OCR 并使用此数据进行进一步评估。 只有此数据集使用 PlainHTML 语言器和给定的 HTML。

SROIE 和 SROIE 挑战 SROIE [29] 是 973 张扫描收据和相应 OCR 结果的集合。 数据集的任务是 KIE，为每个样本提取 4 个键：公司、日期、地址和总计。

原始 SROIE 要求为每个样本提取相同的 4 个密钥。 我们认为，这些键尤其不需要全面了解文档的布局。 例如，公司名称几乎总是写在收据上的第一个内容，紧随其后的是日期和地址。 为了更深入地研究大语言模型对布局的理解，我们创建了一个挑战集，用于查询特定表格单元格的值(“购买了多少件‘绿茶’商品？”)或直接引用文档的布局(“哪个实体写在卡到期日期上方？”)。 为此，我们手动注释了 SROIE 数据集训练分割中的 101 个样本，以创建具有挑战性的 QA 数据集公开发布。 我们将问题分为数量、货币和字符串，其中后者指与前两种类型都不对应的任何其他问题。

专有 KIE 数据集 我们进一步评估 Insiders Technologies 的两个专有 KIE 数据集上的 KIE 性能，这两个数据集都包含来自现实世界商业信函的特别多样化且具有挑战性的示例：ITForms 是100 份德语多页表格文档，每份有 9 个键。 其中包括申请保险福利、登记车辆和银行表格等表格。开设仓库。 ITInvoices 是 104 个德语发票文档的集合，这些文档主要是单页，每个包含 21 个键。 它包括商业发票和扫描收据。

4.2设置

大语言模型 我们用两个大语言模型评估我们的方法：ChatGPT 和 Solar[13]。 为了评估 ChatGPT，我们使用 gpt-3.5-turbo-1106 JSON 模式[30]，温度为$0$，并以用户角色输入每个提示。 我们进一步评估8位量化版本。 对于 Solar，每个提示也以 user 角色输入。 除非另有说明，实验使用 ChatGPT 模型和提示模板 A，即没有语言器格式描述的模板。

OCR DUE 基准测试中的每个数据集都附带了一系列预先应用的 OCR 引擎，我们使用 microsoft_cv 和 tesseract 作为后备，以防万一前者不可用，只有 TabFact 才有这种情况。 这些数据集中的 OCR 结果包含有关页面和行索引的信息，用于将同一页面上具有相同行索引的所有单词边界框连接在一起。 Microsoft 计算机视觉 OCR 用于 WebSRC、ITForms 和 ITInvoices。 我们为 WebSRC 训练和测试分组提供 OCR。 对于 SROIE 和 SROIE 挑战赛，我们使用随数据集提供的 OCR 结果。

指标 为了评估 DUE 数据集，我们使用官方评估框架 以及 [1] 中给出的指标：DocVQA 和 InfographicsVQA 的 ANLS 以及TabFact 和 WikiTableQuestions 的准确性。 WebSRC 根据 GitHub 存储库，分数以 EM 和 F1 形式给出。 对于 SROIE、SROIE Challenge、ITForms 和 ITInvoices，我们创建了一个类型感知准确性度量：根据预期响应为每个响应分配四种类型之一，这描述了它与真实情况的比较（所描述的过程适用于GT 和从大语言模型输出中提取的响应）：对于 string 值，进行不区分大小写的比较。 date 值通过 Python dateparser 库进行解析 然后比较是否相等。 currency 值通过 RegEx，用点替换逗号，然后比较是否相等。 quantity 值通过正则表达式进行清理 然后比较是否相等。 对于字符串，以及忽略单位后的货币和数量，建议的精度度量默认为EM，即后两者不进行舍入。 如果无法将值解析为其指定类型，则返回空答案。

4.3结果

请参阅附录中的0.B节，了解每种语言化策略添加的词符开销的比较。 请参阅附录中的0.C节，分析语言器格式描述对不同提示模板$A$和$B$的影响。

4.3.1 数据集结果

我们使用 4.2 节中列出的指标报告各种数据集的结果：SROIE、SROIE Challenge、ITForms、ITInvoices 的类型感知准确性； DocVQA、InfographicsVQA 的 ANLS； TabFact、WikiTableQuestions 的准确性； WebSRC 的 F1 和 EM。 表 1 和 2 中的结果表明，我们的方法可以与最先进的模型竞争。 具体来说，表 1 中的 DUE 基准测试结果表明，在提示中引入布局信息是有益的。 我们的方法在 InfographicsVQA 和 WikiTableQuestions 上实现了最先进的性能。 在整个基准测试中，SpatialFormat 被证明是平均而言最好的语言化策略。 InfoVQA 的峰值增益为 15%（从 47.7% 到 54.9%）。

表 2 显示我们在其他一些数据集上取得了有竞争力的结果。 具体来说，我们的方法通过 SpatialFormat 语言表达在 WebSRC 上获得了第三好的 F1 分数。,PlainHTML 基线进一步显示了 HTML 格式文档表示的有希望的结果，在所有言语中实现最佳表现。 然而，这种语言化策略对于现实世界的文档来说并不可行，因为这些文档首先必须作为 HTML 文档存在，或者会在管道中引入单独的布局处理模型，从而消除了对我们方法的需要。 SROIE 上的结果表明 StructTexT 显着优于我们的方法，证明了多模态模型在数据集上的优越性。 与其他数据集进行比较很困难：对于我们自定义的 SROIE 挑战子集，当然不存在比较。 虽然 ITForms 和 ITInvoices 是专有数据集，不允许与其他方法进行直接比较，但它们使我们能够深入了解模型如何在现实世界的业务文档上运行。 这些数据集的特点是并非所有键都必须生成值。 真实文档中经常缺少信息，并且并非每个键都可以分配给一个值。 因此，模型必须具有足够的能力来拒绝某个值，即，只有在文档中可以找到该值时，它才应输出该值。 我们的结果表明，基于 LLM 的方法在这些数据集上的表现明显较差。 我们观察到，在大多数情况下，大语言模型产生输出，很少提供空响应，这降低了评估的总体得分。 我们相信，可以通过提示中更清晰的说明来减少这个问题。

在整个数据集中可以再次观察到的一个趋势是言语化策略中 SpatialFormat 和 SpatialFormatY 的良好性能。

表格1： 与 DUE-Benchmark 上发布的其他模型进行比较。 下划线表示数据集中最好的语言表达策略。 它表明，我们的方法在 InfographicsVQA 和 WikiTableQuestions 两个数据集上取得了有竞争力的结果，甚至是最先进的结果，与前者的基线相比提高了 15%。 在WebSRC上，我们的F1分数排名第三。 此外，结果表明 SpatialFormat 是测试中最好的语言化策略。 *拉丁语提示模板似乎针对特定数据集进行了优化，并且部分包含示例摘录。

Model		Modality	Question Answering			Table QA/NLI		Avg.
			DocVQA	InfoVQA		WTQ	TabFact
${\text{BERT}}_{\text{LARGE}}$ [22]		T	67.5	-		-	-	-
Donut [9]		V	72.1	-		-	-	-
${\text{T5}}_{\text{LARGE}}$+2D+U [32]		T+L	81.0	46.1		43.3	78.6	62.3
${\text{LayoutLMv2}}_{\text{LARGE}}$ + QG [20]		T+L+V	86.7	-		-	-	-
${\text{LayoutLMv3}}_{\text{LARGE}}$ [21]		T+L+V	83.4	45.1		45.7	78.1	63.1
UDOP [6]		T+L+V	84.7	47.4		47.2	78.9	64.6
LATIN-Prompt (Claude) [26]		T+L	82.6	54.5*		-	-	-
Ours	PlainText	T	76.3	47.7		45.1	68.4	59.4
Ours	SpatialFormat	T+L	79.8	54.9		47.7	70.1	63.1
Ours	SpatialFormatY	T+L	76.3	49.6		45.5	70.3	60.4
Ours	BoundingBox	T+L	74.8	46.4		35.0	68.5	56.2
Ours	BoundingBoxMarkup	T+L	74.6	45.8		36.2	68.6	56.3
Ours	CenterPoint	T+L	75.1	47.4		38.2	67.8	57.1

表2： SROIE、ITForms、ITInvoices、WebSRC 和 SROIIEChallenge 的评估结果。 下划线表示数据集的最佳语言表达策略。 其他模型的 WebSRC 结果取自官方排行榜，表明我们的方法的性能接近第三名的模型。 专有的KIE模型是指Insiders Technologies的内部模型，它是一种多模态大语言模型免费方法。：ITForms 和 ITInvoices 包含示例，并非所有键都在文档中具有值。 虽然这在某种程度上有效，但使用我们当前的提示符并不能正确支持它。 *对于 WebSRC，左侧分数为 EM，右侧分数为 F1。

Model	Modality	KIE				Question Answering
		SROIE	ITForms	ITInvoices		WebSRC*	SROIEChallenge
SageGPT-small-v0.2 [31]	?	-	-	-		89.1 / 92.2	-
DocPrompt (ErnieLayout-Large) [33]	T+L+V	-	-	-		77.4 / 85.0	-
TIE (MarkupLM-Large) [34]	T+L	-	-	-		76.3 / 80.5	-
StructTexT [35]	T+L+V	98.7	-	-	-	-
Proprietary KIE Model	T+L	91.7	86.2	90.1		-	-
PlainText	T	79.9	68.4	54.5		72.9 / 80.5	81.2
SpatialFormat	T+L	77.0	73.9	54.2		74.2 / 80.7	86.1
SpatialFormatY	T+L	79.0	69.0	54.6		72.4 / 80.3	81.2
BoundingBox	T+L	75.4	64.2	54.1		68.3 / 76.6	72.3
BoundingBoxMarkup	T+L	74.3	65.6	53.9		68.1 / 75.9	71.3
CenterPoint	T+L	73.3	65.1	51.8		68.9 / 76.9	74.3
PlainHTML	T+L	-	-	-		80.0 / 84.1	-

4.3.2 ChatGPT 与 Solar 的比较

我们比较了我们的方法应用于两个不同的大语言模型（特别是 ChatGPT 3.5 和 Solar70B8Bit）时的性能。 表 3 中的结果表明，开源大语言模型为使用我们的方法进行文档理解提供了商业解决方案的可行替代方案：两个大语言模型的结果在 SROIE 上不相上下，Solar 的表现也很出色稍微好一些。 在 SROIE 挑战赛中，ChatGPT 领先 4.8 个百分点。 一般。 此外，与 ChatGPT 相比，Solar 显然能够更好地利用 BoundingBox、BoundingBoxMarkup 和 CenterPoint 语言器提供的布局信息。

虽然尚不清楚 SROIE 是否是 ChatGPT 训练数据的一部分，但我们检查了 Solar 所示，找不到 SROIE 数据。 然而，我们可以保证这两个模型在训练过程中都没有遇到过 SROIE Challenge 的问题。

表3： Solar 和 ChatGPT 3.5 比较的评估结果。 下划线表示数据集中大语言模型的最佳语言化策略。 它表明，开源大语言模型为使用我们的方法进行文档理解的商业解决方案提供了可行的替代方案：Solar 在 SROIE 上的表现略好于 ChatGPT，而 ChatGPT 的优势为 4.8 pp。 在我们定制的 SROIE 挑战集上。

Verbalizer		Modality	SROIE			SROIE Challenge
			ChatGPT	Solar		ChatGPT	Solar
	PlainText	T	79.9	76.6		81.2	72.3
	SpatialFormat	T+L	77.0	76.7		86.1	81.2
	SpatialFormatY	T+L	79.0	77.3		81.2	79.2
	BoundingBox	T+L	75.4	76.2		72.3	66.3
	BoundingBoxMarkup	T+L	74.3	77.7		71.3	66.3
	CenterPoint	T+L	73.3	76.9		74.3	72.3
Avg.			76.5	76.9		77.7	72.9

4.3.3噪声模型分析

我们评估了我们的语言表达策略针对文档数据中引入的噪声和布局误解的稳健性。 我们通过应用噪声模型TRANSLATE、SHUFFLE和NEAREST_NEIGHBOR来模拟这一点（参见第3.2节）。 对于每个噪声模型，确定所有数据集上每个语言化策略所获得的平均分数。 图4中的结果表明SpatialFormat和SpatialFormatY受噪声模型的影响最小。 此外，它还表明 PlainText 很容易受到 OCR 系统错误布局解释的影响。

图4： 每个言语器的噪声模型的比较。 显示的值是所有数据集的平均分数。 它表明，当布局被误解时，PlainText 的性能会下降。 进一步表明，SpatialFormat 和 SpatialFormatY 语言表达器最不容易将噪声引入到 OCR 数据中。 请注意，它们不受边界框顺序更改的影响，因为它们仅使用边界框坐标进行操作。

4.3.4 定性分析：SROIE 挑战

我们在 SROIE Challenge 数据集上深入探讨了文档布局对大语言模型的影响，该数据集的特点是针对特定表格单元格和项目相对位置的苛刻问题。 有关这些挑战案例的示例，请参阅附录中的 0.D 节。 我们发现大语言模型的工作效果出人意料地好，使用所有语言器回答了 101 个问题中的 59 个问题，使用 PlainText 语言器回答了 82 个问题。 其余 19 个样本的失败与布局误解有关，这些误解直接源于有限的纯文本语言： (i) OCR 输出按列顺序而不是按行顺序 (二) 延迟表格单元格，放置在表格末尾的所有其他单元格之后。 (iii) 样本过于复杂（例如跨越 12 行和 6 列的表格） (iv) 空单元格，导致大语言模型根据边界框的顺序得出错误的结论， （五） 相邻的单元格合并到一个边界框。 特别是这些因素的组合提供了具有挑战性的案例。 总体而言，SpatialFormat 策略更可靠地解决了挑战案例（101 例中有 87 例正确）。 这表明，在有限数量的手动检查样本上，SpatialFormat 语言对于 OCR 布局误解具有更好的弹性。

5结论

我们研究了将布局信息添加到指令调整大语言模型提示中的技术，以增强文档理解性能。 这种方法只需要对文档文本和提示进行预处理，而不需要额外的微调。与跨不同文档任务的 9 个数据集中的 7 个数据集上的布局无感知文档表示相比，我们获得了更高的分数，达到了最佳状态-在两个数据集上的艺术结果，并且经常产生与经过专门训练的多模态模型相媲美的结果。 我们已经证明我们的方法适用于商业和开源大语言模型。 对有效性的潜在威胁是，标准数据集可能是专有大语言模型 ChatGPT 训练数据的一部分，而 Solar 的情况并非如此。 然而，我们的结果表明，我们对非公共数据集（ITForms、ITInvoices）和专门注释（SROIE-Challenge）的方法的改进与公共数据集的发现一致。 所提出的方法特别适合大量使用空间对齐和空白的结构化文档。 在这些情况下，我们的方法应被视为基于文本的大语言模型和多模式文档转换器之间的最佳模型选择。 它几乎没有任何开销，不需要额外的训练，同时也不会在输入中添加更多的标记。 对于未来的研究，一个有趣的研究重点是最近具有额外视觉输入的指令调整大语言模型，例如 GPT-4 [36]。 由于这些模型的成本较高，因此我们在这项工作中重点关注纯文本表示。 然而，探索包含视觉输入的好处和权衡是值得的。 我们还认为，在将我们的解决方案扩展到多页推理问题时，特别是当页面数量变大时，需要做更多的工作。

附录0.A提示模板

对于每个任务 QA、NLI 和 KIE，都会创建 2 个提示模板 A 和 B。 本节概述了所使用的提示模板。

⬇ $$$ <<<CONTENT>>> $$$ From the above document, which is enclosed by "$$$", answer the following questions: <<<QUESTION>>> <<<FORMAT>>> The questions are numbered, e.g. "(0)". Write the answers into a JSON dictionary and use the question numbers as keys and as datatype string. Here is an example of the expected JSON format: { "0": <ANSWER_TO_QUESTION_0>, "1": <ANSWER_TO_QUESTION_1>, … } Listing 1: QA prompt template B. In version A of the template <FORMAT> is removed.

⬇ $$$ <<<CONTENT>>> $$$ From the above document, which is enclosed by "$$$", validate the following statements: <<<QUESTION>>> <<<FORMAT>>> The statements are numbered, e.g. "(0)". Write the answers into a JSON dictionary and use the statement numbers as keys and as datatype string. Answer with the string value "1" in case of a true statement and with the string value "0" in case of a false statement. Here is an example of the expected JSON format: { "0": <ANSWER_FOR_STATEMENT_0> "1": <ANSWER_FOR_STATEMENT_1>, … } Listing 2: NLI prompt template B. In version A of the template <FORMAT> is removed.

⬇ $$$ <<<CONTENT>>> $$$ From the above document, which is enclosed by "$$$", extract the values to the following keys: <<<QUESTION>>> <<<FORMAT>>> Write the answers into a JSON dictionary with one entry for each requested key. Here is an example of the expected JSON format: { KEY0: <VALUE_FOR_KEY_0>, KEY1: <VALUE_FOR_KEY_1>, … } Listing 3: KIE prompt template B. In version A of the template <FORMAT> is removed.

附录0.BVerbalizer词符计数分析

我们量化每个语言策略添加到提示中的额外标记。 为此，我们将 PlainText 语言器所需的标记数量与其他语言器所需的标记数量进行比较。 Token 以tiktoken BPE tokenizer，由 OpenAI 提供，用于其模型。 图5中绘制的分析表明，与PlainText相比，SpatialFormat和SpatialFormatY言语化策略引入的词符开销最少> 基线。 与直觉相反，它进一步表明 SpatialFormatY 导致比基线更少的标记。

图5： 与 PlainText 基线相比，每种语言化策略引入的相对词符开销。 值以 PlainText 语言表达器所需的标记数量的百分比给出，并对所有数据集中的所有文档进行平均。 它表明，与其他语言器相比，SpatialFormat 和 SpatialFormatY 引入的词符开销最少。 此外，它还表明 SpatialFormatY 需要的标记比 PlainText 基线还要少。

附录0.C格式描述分析

我们评估通过包含特定于语言器的格式描述所增加的好处（请参阅第 3.1 和 3.3 节。 图6显示格式描述并没有带来显着的性能提升，并且一些语言化策略的性能实际上有所下降。 奇怪的是，结果因数据集而异，例如SpatialFormat 从格式描述中受益于 SROIE，但在所有其他数据集上的性能有所下降。 结果是不确定的，性能变化从未超过 2 pp，我们认为这是微不足道的。 除此之外，仅评估每个语言表达器的一种格式描述，而每个语言表达器都存在大量可能的格式描述。

图6： 比较提示中言语表达格式描述的影响。 显示的值是数据集 SROIE、SROIE Challenge、DocVQA、InfographicsVQA、TabFact 和 WikiTableQuestions 的平均分数。 它表明，格式描述的添加不会导致重大变化，这对某些语言化策略有利，但对其他语言化策略不利。 此外，每个数据集的结果都是不确定的并且有所不同：在某些数据集上，格式描述有利于某些语言表达者，而在其他数据集上却没有。

附录 0.D SROIE 挑战示例

图 7 显示了 SROIE Challenge 数据集中的三个困难案例，适用于第 4.3.4 节中提到的三个类别：(iii) 过于复杂的样本，(iv) 空单元格，这导致大语言模型根据边界框的顺序得出错误的结论，并且（v）相邻单元格合并到单个边界框。

(a) X51006619772

(b) X51005806679

(c) X51006332575

图7： SROIE Challenge 数据集中的三个困难情况概述：(a) 显示带有空单元格的收据，这导致大语言模型在使用 PlainText 基线时根据边界框的顺序得出错误的结论。 (b)所示的收据布局丰富，表格由6列18行组成。 由于 OCR 系统的布局错误解释，文本 QTY 和 U/PRICE 被合并到 (c) 中的单个边界框中。