大型语言模型(LLM)在文档问答(QA)中存在一个问题,那就是当文档无法适应LLM的小范围上下文长度时。为了解决这个问题,现有的大多数工作都专注于从文档中检索相关上下文,并将它们表示为纯文本。然而,诸如PDF、网页和演示文稿等文档本质上是结构化的,具有不同的页面、表格、章节等。将这些结构化文档表示为纯文本与用户对具有丰富结构的文档的心智模型是不协调的。当系统需要查询文档以获取上下文时,这种不协调就凸显出来了,看似无关紧要的问题也可能让QA系统困惑。为了弥合处理结构化文档中的这一根本差距,我们提出了一种称为PDFTriage的方法,使模型既可以根据结构也可以根据内容检索上下文。我们的实验证明,增强了PDFTriage的模型在现有的检索增强LLM失败的几类问题上都有效。为了进一步研究这个基本问题,我们发布了一个基准数据集,其中包含900多个针对10种不同类别的问题类型的人生成的问题及其在80个结构化文档中的答案。

论文原文地址：2309.08872.pdf (arxiv.org)

一、介绍

当一个文档无法适应LLM有限的上下文窗口时,可以部署不同的策略来获取相关上下文。当前的方法通常依赖于预检索步骤来从文档中获取相关上下文(Pereira et al., 2023; Gao et al., 2022)。这些预检索步骤倾向于将文档表示为纯文本块,与用户查询共享某些相似性,并可能包含答案。然而,许多文档类型都具有丰富的结构,例如网页、PDF文件、演示文稿等。对于这些结构化文档,将文档表示为纯文本通常与用户对结构化文档的心智模型不协调。这可能导致用户认为可以轻松回答的问题,但使用目前的LLM文档QA方法失败。例如,考虑以下两个问题:

Q1 

“你能总结一下第5-7页的关键要点吗?”

Q2 “表3中哪一年的收入最大?[in table 3]”

在第一个问题中,明确参考了文档结构(“第5-7页”)。在第二个问题中,隐式引用了文档结构(“表3”)。在这两种情况下,都需要表示文档结构才能识别相关上下文并回答问题。将这样的结构化文档视为纯文本会丢弃回答这些问题所需的相关结构。

我们提出通过允许模型根据结构或内容检索上下文来解决这种对文档的简化表示。我们的方法称为PDFTriage,它为模型提供文档结构的元数据。我们通过在提示中同时增添文档结构元数据和一组可调用的针对各种结构类型的检索函数来利用文档结构。例如,我们引入了fetch_pages(pages: list[int])函数,它允许模型获取一系列页面。我们表明,通过提供结构以及对该结构发出查询的能力,增强了PDFTriage的模型可以可靠地回答纯检索增强LLM无法回答的几类问题。

二、相关工作

2.1 工具和检索增强的LLM

工具增强的LLM日益流行,因为它可以增强现有的LLM,以利用工具回应人类指令(Schick et al., 2023)。ReAct (Yao et al., 2022)是一种少样本提示方法,利用Wikipedia API生成一系列API调用,以解决特定任务。已证明这样的任务解决轨迹比基准更可解释。Self-ask (Press et al., 2022)提示在回答问题之前明确提供后续问题,并为易于解析使用特定的支架,如“后续问题:”或“所以最终答案是:”。Toolformer (Schick et al., 2023)使用自我监督来教导自己使用工具,利用LLM的少样本能力获取潜在工具使用的样本,然后在其自己的一些生成的基础上对其进行微调,这些生成基于那些提高模型预测未来标记的能力。TALM (Parisi et al., 2022)仅使用文本以及一种迭代技术来利用很少的例子增强LLM和非可微工具。最近,Taskmatrix (Liang et al., 2023) 和 Gorilla (Patil et al., 2023)专注于改进LLM处理数百万来自各种应用程序的工具的能力。还有许多工作专注于工具增强型LLM的基准测试(Li et al., 2023; Zhuang et al., 2023)。这些包括API-Bank (Li et al., 2023),侧重于评估LLM规划、检索和正确执行各种任务的API调用的能力,以及ToolQA (Zhuang et al., 2023),侧重于使用外部工具进行问答。

2.2 问答

现有的大部分QA工作没有把问题植根于结构化文档中,而是主要关注抽取式QA任务,如GLUE (Wang et al., 2018)。例如,SQuAD (Rajpurkar et al., 2016) 和 NaturalQuestions (Kwiatkowski et al., 2019)等QA数据集中的纯文本文档不包含表格或图形。近期的工作开始构建集中在文档的QA数据集。Mathew等人(2021)构建了一个视觉问答数据集DocVQA,侧重于文档扫描。Landeghem等人(2023)关注于一个称为DUDE的文档理解和评估数据集,它使用扫描和原生数码PDF。DUDE和DocVQA中的问题可以短格式回答;DUDE的答案平均大约3.35个标记,DocVQA的标记平均2.11个。QASPER (Dasigi et al., 2021)是一个关注研究论文中的信息性问题及其答案的数据集,其中文档从原始LaTeX源解析,问题主要关注文档内容。PDFTriage评估数据集旨在扩展这些数据集中的问题类型,获取可以引用文档结构或内容的问题,可以是抽取式或概括式的,并且可以需要长格式回答或重写。

三、PDFTriage：从文档元数据中进行结构化检索

PDFTriage方法包括三个步骤来回答用户的问题,如图1所示:

1. 生成文档元数据(第3.1节):提取文档的结构元素并将它们转换为可读的元数据。

2. 基于LLM的分类(第3.2节):查询LLM以从文档中选择精确的内容(页面、部分、检索到的内容)。 

3. 使用检索内容回答(第3.3节):根据问题和检索到的内容生成答案。

3.1 文档表示

我们考虑将原生数字PDF文档作为用户将交互的结构化文档。使用Adobe Extract API,我们将PDF转换为类似HTML的树,这使我们可以提取部分、部分标题、页面信息、表格和图形。Extract API为PDF生成元素的分层树,包括部分标题、表格、图形、段落等。每个元素都包含元数据,如其页面和位置。我们可以解析该树来标识部分、部分级别和标题,收集某个页面上的所有文本,或获取围绕图表和表格的文本。我们将这些结构化信息映射到JSON类型,我们将其用作LLM的初始提示。内容转换为Markdown。该过程的概述如图1顶部所示。

3.2 LLM查询文档

PDFTriage利用五个不同的函数:fetch_pages、fetch_sections、fetch_table、fetch_figure和retrieve。如表2所述,每个函数允许PDFTriage系统收集与给定PDF文档相关的精确信息,重点是标题、子标题、图表、表格和部分段落中的结构化文本。在每个回合中,PDFTriage使用一个函数来收集回答问题所需的信息,然后处理检索到的上下文。在最后一个回合中,模型输出问题的答案。在我们所有的实验中,我们都使用gpt-35-turbo-0613模型。

3.3 问答

要初始化PDFTriage进行问答,我们使用GPT-3.5的系统提示格式输入以下内容:

你是一个专家文档问答系统。您通过在文档中找到相关内容并根据该内容回答问题来回答问题。

文档:<文档的文字元数据>

使用用户提示,我们然后不带任何格式输入查询。接下来,PDFTriage系统使用第2节中建立的函数查询文档,以获取回答查询所需的任何信息。在每个回合中,PDFTriage使用一个函数来收集所需的信息,然后处理检索到的上下文。在最后一个回合中,模型输出对问题的答案。在我们所有的实验中,我们都使用gpt-35-turbo-0613模型。

四、数据集构建

为了测试PDFTriage的效力,我们构建了一组面向文档的问题解答任务。每个任务旨在评估文档问答中的不同方面,分析文档中的文本、表格和图形的推理。此外,我们希望创建从单页回答到整个文档的多步推理的问题。

为了收集各种问题,我们生成了问题类型的分类法,然后按该分类法的类型进行分层抽样。每个类别都突出显示了文档取向的QA中的不同方法,涵盖了许多其他QA数据集中找不到的多步推理。我们要求标注者在编写问题之前阅读文档。然后,他们的任务是在指定的类别中写一个相关的问题。

对于我们的分类法,我们考虑了十个不同的类别及其相关描述:

1. 图形问题(6.5%):关于文档中的一个图形提出一个问题。

2. 文本问题(26.2%):关于该文档提出一个问题。

3. 表格推理(7.4%):关于文档中的一个表提出一个问题。 

4. 结构问题(3.7%):关于文档结构提出一个问题。

5. 摘要(16.4%):请求文档的某些部分或整个文档的摘要。

6. 提取(21.2%):从文档中提取特定内容。

7. 重写(5.2%):要求对文档中的一些文本进行重写。

8. 外部问题(8.6%):提出一个仅依靠该文档无法回答的问题。

9. 跨页面任务(1.1%):提出一个需要文档的多个部分才能回答的问题。

10. 分类(3.7%):关于文档类型提出问题。

总体而言,我们的数据集由82个文档上的908个问题组成。平均而言,每个文档包含4257个标记的文本,这些文本与标题、子标题、部分段落、字幕等相关联。在图2中,我们呈现了按字数划分的文档分布。我们在附录中提供了每个类别的详细描述和示例。

五、实验

我们概述了我们方法中使用的模型和策略以及用于比较的基线。重现我们结果的代码和数据集即将发布。

5.1 PDFTriage

对于我们的主要实验,我们使用PDFTriage方法来回答所选PDF文档数据集中的各种问题。该策略利用PDF的结构化元数据来实现比现有的朴素方法更精确和准确的文档问答。

5.2 检索基线

页面检索。 对于我们的第一个基线,我们使用text-embedding-ada-002嵌入对每个文档的页面进行索引。使用余弦相似度,我们检索与查询嵌入最相似的页面。然后,我们将每个页面的文本作为上下文,以回答给定的问题,直到达到模型的上下文窗口限制。

块检索。 在我们的第二个基线中,我们首先连接文档的所有文本,然后将其分块为100字的片段。 然后,我们使用text-embedding-ada-002嵌入对每个块进行索引,然后使用余弦相似度计算来检索与查询嵌入最相似的块。 最后,我们将每个块的文本内容作为上下文,以回答给定的问题,直到达到模型的上下文窗口限制。

提示。 对于两个检索基线,我们都使用以下提示从GPT-3.5获取答案:

你是一个专家文档问答系统。您通过在文档中找到相关内容并根据该内容回答问题来回答问题。  

文档:<检索到的页面/块>

问题:<问题>

5.3 人工评估

为了衡量PDFTriage与检索基线之间的任何差异,我们在Upwork上建立了一个人工标注研究。 在研究中,我们聘请了12名有经验的说英语的标注者来判断每个系统生成的答案。

我们的问题旨在了解每个问题文档对以及相关常规问题的几个关键属性:

1. 问题的整体质量,如其难度、清晰度和回答它所需的信息。

2. 使用第4节中的分类法对问题进行分类。

3. 为给定的问题文档对生成的每个答案进行排名。

4. 每个生成答案的准确性、信息量、可读性/可理解性和清晰度。

六、结果和分析

在表1中,我们展示了样本中每个问题的标注难度。总体而言,被归类为“简单”的问题组占比较大(43.3%),而大约三分之一的问题由于各种原因被归类为“困难”。

除了问题难度之外,我们还要求标注者使用第4节中的相同类别对问题进行分类。我们的标注框架生成了一个在问题类型和问题难度方面都多样化的数据集,涵盖了文本、表格、图形和标题以及单页和多页查询。问题的多样性使我们能够稳健地评估多种文档取向的QA,测试PDFTriage对不同推理技术的效果。

6.1 PDFTriage生成的答案优于基于检索的方法

在我们的标注研究中,我们要求标注者将PDFTriage与我们的两个基线页面检索和块检索(第5节)进行排名。在图3中,我们发现标注者超过一半的时间(50.7%)更喜欢PDFTriage的答案,并且更喜欢块检索方法而不是页面检索方法。当对同一问题比较不同的提供答案时,PDFTriage的表现明显优于当前的替代方法,其排名高于所有问题类型的替代方法。

6.2 PDFTriage改善了答案质量、准确性、可读性和信息量

在我们的标注研究中,我们还要求标注者根据五个主要质量对PDFTriage、页面检索和块检索答案进行评分:准确性、信息量、可读性/可理解性和清晰度。我们希望更好地了解每个答案对用户的优势在文档问答任务中。在表3中,我们展示了与页面检索和块检索相比,PDFTriage答案在所有答案质量方面得分更高,除了清晰度。关键的是,PDFTriage在整体质量和答案准确性方面获得了最高分数。对于标注者之间的协议,我们计算了0.584的平均Cohen kappa分数。

6.3 PDFTriage需要更少的检索标记就能产生更好的答案

在我们的研究中使用的PDF文档示例中,使用GPT-3.5标记器检索到的PDFTriage文本的平均标记长度为1568个标记。文档JSON中的文本输入元数据的平均长度为4257个标记(使用GPT-3.5标记器)。

虽然PDFTriage利用的标记总数比页面检索(平均3611个标记)和块检索(平均3934个标记)多,但这些标记来自文档的多个非连续部分。此外,页面检索和块检索中使用的部分通常不足以回答问题,正如平均“整体质量”和“准确性”的较低答案质量得分所示。但是,简单连接文档的所有文本不会最终取代PDFTriage,因为上下文窗口限制和进行文档QA任务所需的多跳推理。PDFTriage有助于通过多阶段查询文档来克服这个问题,根据不同的文档QA任务需要检索和添加上下文。因此,GPT-3和其他LLM能够更好地处理缩减的上下文大小,并最终利用更少的计算和财务资源进行文档QA任务。

七、未来工作和结论

在本文中,我们提出了PDFTriage,这是一种针对面向文档任务的新颖问答技术。我们将我们的方法与现有的问答技术(如页面检索和块检索)进行了比较,以展示我们方法的优势。我们发现,与现有方法相比,PDFTriage提供了卓越的性能。PDFTriage在用于检索的各种文档长度和上下文中也被证明是有效的。我们正在考虑以下未来工作方向:

1. 开发多模态方法,将表格和图形信息整合到GPT-4问答中。

2. 在PDFTriage方法中整合问题类型,以提高方法的效率和效力。

本文的主要贡献是:

- 我们确定了当前LLM方法在结构化文档问答中存在的差距,即将文档视为纯文本而不是结构化对象;

- 我们发布了一个带有模型响应的标注问题类型数据集,以促进这一主题的进一步研究;

- 我们提出了一种称为PDFTriage的提示方法,该方法改善了LLM对结构化文档问题的处理能力。

八、论文创新点

1. 重视结构化文档本身的结构特征,而不是将其简单视为纯文本对待。该方法利用Adobe Extract API提取文档结构信息生成可查询的结构化表示。

2. 提供一组检索函数,可以根据文档结构精确定位问题需要参考的上下文,而不仅限于简单的页面/段落检索。这解决了LLM上下文窗口限制的问题。

3. 引入LLM作为智能调度器,根据问题智能选取和调用合适的检索函数去结构化文档中提取精准上下文。同时运用多轮问题回答迭代获取答案。

4. 构建了一个足够复杂的问题集,包含考察结构化文档不同特征的问题类型,如表格、图表、跨页面问题等,可以全面评估问答系统表现。 

5. 实验结果表明相比基准,PDFTriage方法在利用结构信息寻找答案上明显更准更好,特别是对于需要多步骤推理的结构化问题。

6. 论文发布了问答系统源代码和问题集,为研究提供开放资源,有利于该研究方向的深入探索。

所以总体来说,PDFTriage方法的核心创新点在于考虑结构化文档本身的结构属性,并利用此构建精细化的问题答问流程。

九、论文不足之处

1. 没有给出如何根据问题内容智能选择合适检索函数的具体算法,这是一个方法的重要组成部分但缺乏描述。

2. 实验数据集中的问题由人工收集而成,量级相对较小,没有利用深度学习训练一个自动生成高质量问题的模型。

3. 评估标准主要依靠人工标注结果,没有提出一个能量化衡量系统表现的自动评价指标。

4. 只考虑了PDF这一种结构化格式,而其他格式如HTML网页目前不能直接处理。

5. 分析结果仅仅对比了两类基准方法,没有结合更多SOTA方法进行更全面评估。

6. 方法本身没有给出如何利用现有预训练模型来实现,依赖具体实现细节。

7. 未来工作仅提出了一些可能的延伸思路,缺乏一个系统的研究路线规划。

8. 没有给出核心算法性能指标如运行时间和内存开销,难评价其实际应用效率。

9. 人工评估结果与自动评价分数匹配程度较低,自动评价质量待改进。

所以未来研究可以从这些方面着手,进一步完善和优化PDFTriage方法本身。

十、将PDFTriage方法实际应用需要解决以下几个关键问题

1. 架构设计:如何设计系统架构配合文档预处理和大语言模型实现结构化文档问答功能。

2. 数据预处理:针对PDF等文档格式实现结构提取和标记,生成标准化结构化表示作为输入。 

3. 模型训练:选择和训练合适的语言模型实现问题分类和精准上下文定位等子模块。

4. 功能开发:开发基于论文提出的检索函数集实现实际结构化文档查询能力。

5. 用户交互:设计友好的UI/UX让用户便捷提出问题和浏览答案。

6. 性能优化:关注算法和模型 infer性能,以支撑海量文档和高并发 online问答。

7. 安全认证:用户验证与答案审核机制,确保信息安全门户正常运行。

8. 应用集成:提供开放API将问答能力集成到相关产品服务中,如OA/LMS等。

9. 模型监控:线上迭代更新模型保持应对新问题和错误的能力。 

10. 市场推广:找出适合的应用场景(如金融、医疗等行业),帮助产品快速打透。

11. 后续研发:针对落地过程中出现的新问题,继续完善和优化问答方法。

只有系统解决这些问题,PDFTriage才能真正在商业和行业场景中得到广泛应用。

出自：https://mp.weixin.qq.com/s/B2Zl9hnAHxohWKRXEBaC9w