摘要
大语言模型的上下文窗口扩展最近变得非常流行。而长期以来,结合信息检索和大语言模型的方法也受到关注。这引发了几个问题:i) 在下游任务中,到底是信息检索增强更好,还是长上下文窗口更有优势? ii) 能否将这两种方法结合,以吸取各自的长处? 我们通过研究两种领先的预训练大语言模型——43B GPT 和 LLaMA2-70B,来探讨这些问题。有趣的是,我们发现,即使是使用简单的信息检索增强,在长上下文任务中具有 4K 上下文窗口的大语言模型也能达到与经过特别优化处理、具有 16K 上下文窗口的大语言模型相媲美的表现,而且所需的计算资源更少。更为重要的是,我们证明了信息检索技术能显著提升大语言模型的性能,无论其上下文窗口的大小如何。我们最优秀的模型——结合了信息检索技术的 LLaMA2-70B,并拥有 32K 的上下文窗口,在包括问答和基于查询的摘要在内的七项长上下文任务上,其平均得分超越了 GPT-3.5-turbo-16k 和 Davinci003。与此同时,这个模型在生成速度上也比它的非检索版 LLaMA2-70B-32k 快得多。我们的研究为那些在信息检索增强与大语言模型长上下文扩展之间做选择的从业者提供了宝贵的洞见。
1 引言
近来,长上下文的大语言模型(LLM)在实际应用(如 Anthropic,2023;OpenAI,2023b)、学术研究(如 Chen 等人,2023;Liu 等人,2023;Tworkowski 等人,2023)以及开源社区(如 Kaiokendev,2023)中引起广泛关注。尽管近似注意力方法已经研究多年(如 Tay 等人,2022),主要是因为自注意力机制在序列长度上的时间和内存复杂度是二次方的,但近期长上下文 LLM 的发展主要得益于更快的 GPU、更大的内存以及内存效率更高的精确注意力技术(Dao 等人,2022;Dao,2023)。
对于处理长上下文,另一种历史悠久的方法是检索。具体来说,LLM 只需读取独立检索器检索到的相关上下文(如 Karpukhin 等人,2020;Wang 等人,2022;Lin 等人,2023),这比 LLM 选择相关上下文要快得多,也更易于扩展。从概念上讲,增强检索的解码器型 LLM 可以看作是在其长上下文窗口应用稀疏注意力,其中稀疏模式不是预设的,而是由独立检索器确定。也就是说,未被检索的上下文被视为无关,其注意力权重为零。
考虑到长上下文 LLM 研究的迅速增长以及推理阶段需要的大量计算,目前尚不清楚是否扩展 LLM 的上下文窗口能比检索增强方法在下游任务中获得更高的准确率。更有意思的是,如果能结合这两种方法的优势,可能会取得更高的准确率。本研究旨在通过全面分析来探讨这些问题。
具体来说,我们的贡献包括:
-
我们使用两款先进的 LLM,包括 43B 预训练的专有 GPT 和 LLaMA2-70B(Touvron 等人,2023b)对 7 种长上下文任务进行了深入研究,包括单文档和多文档问答(QA)以及基于查询的摘要编写。
-
我们证明了检索增强显著提升了 4K 上下文 LLM 的性能。令人惊讶的是,这种简单的检索增强基准与 16K 长上下文 LLM 的表现不相上下,例如使用 GPT-43B 平均得分为 29.32 对比 29.45,使用 LLaMA2-70B 为 36.02 对比 36.78,且所需计算量大大减少。
-
此外,我们还发现对于更大型的 LLaMA2-70B,通过检索增强,即使是 16K 或 32K 的长上下文 LLM 也能提升性能。因此,我们的最佳模型,32K 上下文窗口且增强了检索的 LLaMA2-70B-32k-ret(平均得分 43.6),在平均得分上超越了 GPT-3.5-turbo-16k(平均得分 42.8)和 Davinci-003。它也显著优于未增强检索的 LLaMA2-70B-32k 基线(平均得分 40.9),且在生成速度上有显著提升(例如,在 NarrativeQA 任务上比原模型快 4 倍)。
本文的其余部分安排如下:第 2 节讨论相关工作,第 3 节介绍实验设置,第 4 节报告研究结果,最后在第 5 节总结本文。
2 相关工作
本节我们将探讨三个相关领域:长内容的大语言模型、高效的注意力机制和检索增强型语言模型。
2.1 长内容大语言模型
近年来,随着 GPU 性能提升和内存增加,以及更高效的注意力计算方法(例如 Dao 等人,2022 年研究),预训练处理大量内容的大语言模型成为可能。例如,从 GPT-2 的 1024 词元窗口(Radford 等人,2019 年)到 GPT-3 的 2048 词元(Brown 等人,2020 年),再到 Llama 2 的 4096 词元(Touvron 等人,2023 年 B 版)和 GPT-4 的 8192 词元(OpenAI,2023 年 A 版)。然而,进一步增加预训练时的内容窗口面临挑战:一方面,从头开始预训练含超过 16K 词元的模型成本高昂,因为其计算和内存需求随之大幅增加;另一方面,预训练所用的大部分文档(如 Common Crawl 数据)本身就较短。
最新研究开始通过继续训练或微调来扩展大语言模型的处理窗口(例如,Kaiokendev,2023 年;Nijkamp 等人,2023 年;Chen 等人,2023 年;Tworkowski 等人,2023 年;Mohtashami & Jaggi,2023 年)。例如,Tworkowski 等人(2023 年)通过对比训练,将 OpenLLaMA 的 3B 和 7B 模型微调到能处理 8K 长度的内容,创建了 LongLLaMA。Mohtashami 和 Jaggi(2023 年)通过引入代表内容块的“地标词元”并调整注意力机制来关注相关的内容块,成功将 LLaMA 7B 的处理窗口从 4K 扩展到 32K。Chen 等人(2023 年)和 Kaiokendev(2023 年)采用了 位置插值 方法,扩展了基于 RoPE(Su 等人,2021 年)预训练的大语言模型的内容窗口大小。特别地,Chen 等人(2023 年)在对 LLaMA 7B 至 65B(Touvron 等人,2023 年 A 版)进行微调时,仅需极少的调整步骤(不超过 1000 步)便取得了显著成效。而 ALiBi 方法(Press 等人,2021 年)通过去除位置嵌入并对键 – 查询注意力分数施加基于距离的线性调整,实现了在无需微调的情况下扩展内容窗口。Ratner 等人(2023 年)则是将长内容划分为多个子窗口,并在这些窗口中重复使用位置嵌入,从而能够处理更长的内容而无需进一步微调。
在本研究中,我们采用了 位置插值 方法,将一种专有的 43B 预训练大语言模型和 LLaMA2-70B(Touvron 等人,2023 年 B 版)的 4K 内容窗口扩展至 16K 和 32K。这两种模型在预训练阶段均采用了旋转位置嵌入技术。在评估方面,我们重点关注经过指令调整之后的下游任务表现(例如,Shaham 等人,2023 年;Bai 等人,2023 年)(Wei 等人,2021 年)。
也有研究指出,在检索增强的情况下,大语言模型(LLM)处理长篇文本时的相互影响。例如,Liu 等人在 2023 年的研究(2023)中,对包括 ChatGPT 3.5(OpenAI, 2022)、GPT-4(OpenAI, 2023a)、Claude(Anthropic, 2023)在内的几种大型语言模型的长文本处理能力进行了评估。他们发现,在这些模型处理长文本时,会出现一个“中间丢失”的现象。
2.2 高效的注意力计算方法
在以往的研究中,为了解决自注意力计算在处理长文本时计算量过大的问题,提出了多种近似的注意力方法(Tay 等人,2022)。这些方法可以分为几种类型:i) 采用预先设定的稀疏模式的稀疏注意力机制,如 Child 等人(2019)的研究;ii) 基于递归的方法,如 Dai 等人(2019)的研究;iii) 低秩投影注意力方法,如 Wang 等人(2020)的研究;iv) 基于内存的机制,如 Rae 等人(2020)的研究;v) 基于相似性和聚类的方法,如 Kitaev 等人(2020)的研究。这些方法都有自己的特点,适用于特定的场景,但在一些情况下可能会降低模型的整体质量。
最近,Dao 等人在 2022 年和 2023 年(2022; 2023)提出了一种名为 FlashAttention 的新方法,通过优化 GPU 内存之间的读写过程,提高了处理长序列时的计算效率。
2.3 检索增强的大语言模型
多年来,为了提升大语言模型在处理复杂任务时的性能,研究者们开始将检索功能整合进大语言模型。这种做法已被证实可以有效改善模型的困惑度(perplexity)(Borgeaud et al., 2022; Wang et al., 2023)、事实准确性(factual accuracy)(Nakano et al., 2021)、下游任务的准确度(downstream task accuracy)(Guu et al., 2020; Izacard & Grave, 2021; Izacard et al., 2022; Lewis et al., 2020),以及上下文学习能力(in-context learning capability)(Huang et al., 2023)。通过结合独立的检索器(retriever)(Karpukhin et al., 2020; Wang et al., 2022; Lin et al., 2023),检索增强型大语言模型在处理长篇文档和开放领域问答任务方面显示出卓越的能力。以往的研究表明,在模型推理、微调和预训练阶段结合检索功能,可以显著提升大语言模型的表现 (Khandelwal et al., 2019; Yogatama et al., 2021; Izacard et al., 2022; Lewis et al., 2020; Guu et al., 2020; Borgeaud et al., 2022; Wang et al., 2023)。近期还有研究尝试将大语言模型和检索器融合成单一模型,以构建端到端的解决方案 (例如,Jiang et al., 2022; Shi et al., 2023)。不过,大多数早期研究主要关注大约 10 亿参数规模的大语言模型,只有少数最新研究开始探索更大规模的模型 (例如,Shi et al., 2023)。
在本项研究中,我们将关注那些仅含解码器的大语言模型,它们拥有高达 43B 和 70B 的参数量,并在数万亿个标记上进行训练。这些大型模型显示出在指令调整后强大的零样本能力,能够高效地整合上下文信息 (Wei et al., 2021; 2022)。
2.4 相关并行研究
在编写本文稿期间,我们注意到了一个与我们研究内容相似的并行工作 (Bai et al., 2023),该研究于 2023 年 8 月 28 日在 arXiv 上发布。该研究探讨了检索对长上下文大语言模型的影响,包括黑盒模型 GPT-3.5-Turbo-16k (OpenAI, 2022)、白盒模型 Llama2-7B-chat-4k (Touvron et al., 2023b) 和 ChatGLM2-6B-32k (Zeng et al., 2022)。不同于我们的发现,他们认为检索功能只对 Llama2-7B-chat-4k 的 4K 上下文窗口有益,对于长上下文模型,如 GPT-3.5-Turbo-16k 和 ChatGLM2-6B-32k 并无显著帮助。我们认为这一差异的主要原因可能是:i) 使用黑盒 API 进行受控实验存在挑战,ii) 他们研究中使用的白盒大语言模型规模相对较小,因此在通过检索整合上下文时的零样本能力有限。我们的结论是基于更大规模的大语言模型的研究。特别是,我们最优秀的长上下文模型 LLaMA2-70B-32k 在性能上与 ChatGPT-3.5 相当,且通过检索功能还可进一步提升其能力(详见表 3)。
3 实验设置
在本节中,我们详细介绍了我们的实验设置。
3.1 大语言模型
本节主要比较了在生成式问答或总结任务中,如何通过检索或大语言模型自身的自我注意力机制,有效整合长篇上下文信息的零样本能力。与主要研究较小模型(如 3B 或 7B)的大部分现有工作不同(参见 Kaiokendev 等人,2023 年;Nijkamp 等人,2023 年;Tworkowski 等人,2023 年;Mohtashami 与 Jaggi,2023 年),我们的研究关注于 40B 以上大型模型。此类模型在指令调优方面显示出了独特优势,尤其是当模型达到或超过 50B 参数时,调优效果更加显著(参考 Wei 等人,2021 年和 2022 年的研究)。
在具体的实验中,我们选用了两种预训练的 GPT 模型:一是专有的 Nemo GPT-43B,二是公开的 LLaMA2-70B。GPT-43B 拥有 43 亿参数,训练数据达到 1.1T tokens,其中 70% 为英语语料,其余 30% 包括多语言和编程代码。英语预训练语料来自多个来源,包括 Common Crawl 网页档案、维基百科、Reddit、图书、古腾堡计划、ArXiv、StackExchange、PubMed 等。该模型具有 48 层结构,隐藏层维度为 8,192,训练序列长度为 4,096,采用了 RoPE 嵌入技术(详见 Su 等人,2021 年的研究)。而 LLaMA2-70B 是一个 70 亿参数的公共 GPT 模型,其训练数据量为 2T tokens,大约 90% 为英文。它包含 80 层结构,隐藏层维度同样为 8,192,并且也采用了 4,096 长度的上下文窗口和 RoPE 嵌入技术进行训练。
3.2 数据集和评价指标
在本研究中,我们选用了七个不同类型的数据集,涵盖了从单文档问答、多文档问答到基于查询的摘要等多个方面,用于进行零样本的评估。具体包括 Scroll 基准测试的验证集中的四个数据集(Shaham 等人,2022)。
-
QMSum (QM)(Zhong 等人,2021)是一款针对查询的摘要数据集,包含了 232 次会议记录及其在学术、工业产品等多个领域的摘要。注释者根据上下文编写查询,确保每个查询对应的文本至少包含 200 个词或 10 段对话。
-
Qasper (QASP)(Dasigi 等人,2021)是基于 NLP 论文的问答数据集,选自 Semantic Scholar 开放研究语料库(S2ORC)(Lo 等人,2020)。它包括了抽象型、提取型、是非题以及无法回答的问题。
-
NarrativeQA (NQA)(Kočiský 等人,2018)是一个在完整的书籍和电影剧本上进行的问答数据集,书籍来自 Project Gutenberg3,电影剧本来自多个网站。注释者利用维基百科的摘要来制作问题和答案对,每本书和剧本平均有 30 组问题和答案。每个问题都有两个参考答案。
-
QuALITY (QLTY)(Pang 等人,2022)是一个针对故事和文章的多项选择问答数据集,内容来源包括 Project Gutenberg 和开放的美国国家语料库 4。其中 50% 的问题被标记为“难”,要求仔细阅读整个文档才能找到正确答案,浏览式阅读通常无法得到正确答案。
我们还从 LongBench(Bai 等人,2023)选取了另外三个数据集。
-
MuSiQue (MSQ)(Trivedi 等人,2022)代表了通过单跳问题构建的多跳推理问答。这种自下而上的构建过程使得系统能够探索大量多跳问题,并对手动组合的问题进行更好的控制。为了正确回答问题,大语言模型需要通过减少推理捷径、最小化训练 – 测试泄露,并引入更具挑战性的干扰背景来进行连贯的推理。因此,与以往数据集相比,MuSiQue 在断开式推理上的作弊概率大大降低。
-
HotpotQA (HQA)(Yang 等人,2018)是一个基于维基百科的问答数据集,具有多个关键特征。首先,它需要阅读多个支持文档以进行回答和推理。其次,问题种类繁多,不局限于任何现有知识库。第三,它提供了句子级别的强监督支持,以满足大语言模型对推理的需求。最后,该数据集引入了新型事实比较题,测试大语言模型在文本中提取和比较各种实体属性的能力。
-
MultiFieldQA-en (MFQA)(Bai 等人,2023)是为了更好地测试模型在不同领域长文本理解能力而精心设计的。它收集了来自法律文件、政府报告、百科全书和学术论文等多个来源的文档和文章。请博士生为每篇文章制作问题和答案。为了避免出现偏见,这些证据被随机放置在文档中,不特定于文档的开头或结尾。
这些数据集的详细信息可以在表 1 中找到。我们的评估数据集在平均文档长度上有很大的范围,从 QASP 的 4.9k 字到 NQA 的 84k 字。因此,对于没有检索功能的基线模型,我们会根据需要对文档进行截断,以适应输入序列的长度。
QM | QASP | NQA | QLTY | MSQ | HQA | MFQA | |
---|---|---|---|---|---|---|---|
样本数量 | 200 | 1,726 | 2,000 | 2,000 | 200 | 200 | 150 |
平均文档长度 | 14,140 | 4,912 | 84,770 | 6,592 | 16,198 | 13,319 | 7,185 |
前 5 部分平均长度 | 2,066 | 2,071 | 2,549 | 2,172 | 2,352 | 2,322 | 2,385 |
前 10 部分平均长度 | 4,137 | 3,716 | 5,125 | 4,018 | 4,644 | 4,554 | 4,305 |
前 20 部分平均长度 | 8,160 | 4,658 | 10,251 | 5,890 | 9,133 | 8,635 | 6,570 |
表 1: 零样本评估用的七个数据集统计。所有数据长度按照 LLaMA2-70B 分词器的 token 数量来计算,而“前 N 部分平均长度”指的是从最相关的 N 部分文档中提取的平均 token 数。图 1 中有更详细的介绍。
我们根据官方标准报告了各项评估结果:QM 使用 ROUGE 得分(即 ROUGE-1/2/L)的几何平均(由 Lin 在 2004 年提出),QLTY 采用精确匹配(EM)得分,而 QASP、NQA、MSQ、HQA 和 MFQA 这五个数据集则使用 F1 得分来评估。
3.3 上下文窗口的扩展
为了提高模型处理长文本的能力,我们采用了一种简单有效的方法(由 Chen et al. 在 2023 年提出)来扩展模型的上下文窗口。具体来说,我们把 GPT-43B 的上下文窗口从原来的 4,000 个 token 扩展到了 16,000 个。对于 LLaMA2-70B 模型,我们甚至将其从 4,000 个 token 扩展到了 16,000 和 32,000 个。为了适应这种变化,我们在 Pile 数据集(由 Gao et al. 在 2021 年发布)上对这两种大语言模型进行了微调,使用了 128 的批量大小和 5e-6 的恒定学习率。
3.4 检索
在检索器的实验中,我们测试了三种检索器:1) Dragon (Lin et al., 2023),它在监督和零样本信息检索的基准测试中取得了最佳效果 (Thakur et al., 2021)。Dragon 是一种包含查询编码器和上下文编码器的双重编码模型。2) Contriever 模型 (Izacard et al., 2021),广泛应用于信息检索。Contriever 采用 MoCo 技术 (He et al., 2020),通过对比学习框架对模型进行预训练,实现了无监督训练并在 BEIR 基准的 R@100 上与 BM25 不相上下 (Thakur et al., 2021)。3) 我们还使用了 OpenAI embedding5 模型,选用了 OpenAI 推荐的最新版本“text-embedding-ada-002”。该模型能处理最多 8,191 个输入令牌的序列,输出 1,536 维的向量,并计算问题与上下文列表间的余弦相似度,以进行检索排序。
为了应用这些检索器,我们首先将每个文档分割成 300 词的小块,然后分别对问题和这些小块使用相应的编码器进行编码。接着,我们根据问题嵌入与小块嵌入的点积来排名,挑选出最相关的 N 个小块,并按照相关性从高到低的顺序将它们连接起来,作为生成提示的上下文。表 1 显示了这些顶尖小块的统计信息,而图 1 则展示了七个数据集中的令牌长度分布情况。值得注意的是,像 Qasper (QASP) 这样的数据集相对较短,不足 20 个小块,因此前 10 和前 20 小块的平均长度相差不大。我们发现,前 5 个小块通常能够适应 4k 序列长度(少数例外除外),而前 10 和前 20 个小块则能够适应 16k 序列长度。
3.5 指令微调
为了训练预先训练的大语言模型 (LLMs),使其按照指令进行问答或文本摘要,我们还进行了指令微调。我们构建了一个混合指令微调数据集,包含来自 Soda 数据集 (Kim et al., 2022)、ELI5 数据集 (Fan et al., 2019)、FLAN 数据集 (Wei et al., 2021)、Open Assistant 数据集 (Köpf et al., 2023)、Dolly (Conover et al., 2023) 和一份专有对话数据集的共 102K 训练样本,以帮助 GPT-43B 和 LLaMA2-70B 模型更好地遵循指令。在模板设计上,我们采用了System: {System}nnUser: {Question}nnAssistant: {Answer}
的格式,以支持多轮对话训练。因为所有任务在推理时都需要基于上下文进行推理,所以我们在对话前增加了上下文部分,即System: {System}nn{Context}nnUser: {Question}nnAssistant: {Answer}
。
我们对大语言模型进行了微调,只在{Answer}
部分计算损失,使用 128 的批量大小和 5e-6 的学习率进行了 1000 步的训练。在本文的后续部分,所有的结果都是基于经过指令微调的 GPT-43B 和 LLaMA2-70B 聊天模型得出的。
模型 | 序列长度 | 平均分 | QM | QASP | NQA | QLTY | MSQ | HQA | MFQA |
---|---|---|---|---|---|---|---|---|---|
GPT-43B | 4k | 26.44 | 15.56 | 23.66 | 15.64 | 49.35 | 11.08 | 28.91 | 40.90 |
+ 检索优化 | 4k | 29.32 | 16.60 | 23.45 | 19.81 | 51.55 | 14.95 | 34.26 | 44.63 |
GPT-43B | 16k | 29.45 | 16.09 | 25.75 | 16.94 | 50.05 | 14.74 | 37.48 | 45.08 |
+ 检索优化 | 16k | 29.65 | 15.69 | 23.82 | 21.11 | 47.90 | 15.52 | 36.14 | 47.39 |
LLaMA2-70B | 4k | 31.61 | 16.34 | 27.70 | 19.07 | 63.55 | 15.40 | 34.64 | 44.55 |
+ 检索优化 | 4k | 36.02 | 17.41 | 28.74 | 23.41 | 70.15 | 21.39 | 42.06 | 48.96 |
LLaMA2-70B | 16k | 36.78 | 16.72 | 30.92 | 22.32 | 76.10 | 18.78 | 43.97 | 48.63 |
+ 检索优化 | 16k | 37.23 | 18.70 | 29.54 | 23.12 | 70.90 | 23.28 | 44.81 | 50.24 |
LLaMA2-70B | 32k | 37.36 | 15.37 | 31.88 | 23.59 | 73.80 | 19.07 | 49.49 | 48.35 |
+ 检索优化 | 32k | 39.60 | 18.34 | 31.27 | 24.53 | 69.55 | 26.72 | 53.89 | 52.91 |
表 2:不同模型变体(GPT-43B 和 LLaMA2-70B)在 4k 至 32k 序列长度范围内,对七个数据集的表现进行比较。其中,“+ 检索优化”代表使用了最佳检索技术(Dragon 或 Contriever),并以检索器的前 5 名作为参考依据。
4 结果
本节将展示我们的研究成果,并对其进行详尽的分析。
4.1 主要结果
我们在表 2中展示了不同模型变体的比较,这些模型使用 GPT-43B 和 LLaMA2-70B,并且上下文长度从 4K 到 32K 不等。首先,我们注意到在 GPT-43B 和 LLaMA2-70B 上,没有检索功能且序列长度仅为 4K 的基线模型表现最差。原因在于所有任务的平均序列长度均超过 4096,即模型的上下文窗口上限,导致重要文本被随机截断。因此,对于 4K 大语言模型来说,引入检索功能尤为重要。例如,LLaMA2-70B-4K 的性能从 31.61 提高到了 35.73,GPT-43B-4K 则从 26.44 提升到了 29.32。其次,我们发现 HotpotQA(HQA)数据集特别偏好长序列模型。例如,在序列长度从 4K 增加到 16K 时,LLaMA2-70B 的得分从 34.64 提高到了 43.97,GPT-43B 则从 28.91 提升到了 37.48。这是因为 Hotpot QA 要求多次跳跃推理,尽管问题本身不难,但要正确回答需要考虑所有的中间步骤。因此,更长的上下文有助于更全面地理解和回答问题。
有一个有趣的现象是,即使使用相同的前 5 块证据,拥有检索增强功能的长上下文大语言模型(比如 16K 和 32K)的表现却优于 4K 上下文的大语言模型。我们认为这可能与“中途迷失”现象(Liu 等人,2023)有关,即大语言模型在处理输入内容时呈现出“U 形”性能曲线。具体来说,大语言模型更擅长处理位于输入上下文窗口开始或结束部分的信息。由此,4K 上下文的大语言模型可能会忽略输入中间的信息,而 32K 上下文的大语言模型则可能忽略掉输入的中间部分。从图 1中我们可以看到,前 5 块的长度大约为 2K 个标记,这可能位于 4K 上下文的中间部分而被忽略,但对于 16K 和 32K 上下文来说,这部分内容位于开始部分,因此可能不会被忽视。
需要指出的是,我们的观察结果与 LongBench 研究中得出的结论大相径庭(Bai 等人,2023):即“检索功能能提升长上下文能力较弱的模型的性能,但这些模型的整体性能仍然不如理解长上下文能力更强的模型”。我们的研究表明,无论上下文窗口的大小,检索功能都能显著提高 GPT-43B 和 LLaMA2-70B 的性能。例如,我们的最佳模型 LLaMA2-70B-32k-ret 在检索增强后的表现超过了其无检索基线,即 39.60 对比 37.36。这一差异的主要原因可能是 Bai 等人 (2023) 使用了参数更小的大语言模型(6B 和 7B),这些模型在零样本能力上整合检索到的分块上下文时通常表现较差。相比之下,像 LLaMA2-70B 这样的更大、经过指令调整的大语言模型,在整合检索到的证据方面具有更强的零样本能力。这一点在比较 GPT-43B 和 LLaMA2-70B 在检索增强后的收益时变得更加明显,其中 LLaMA2-70B 通过检索整合上下文获得了更大的益处。
表 3: 我们的最佳检索增强型 LLaMA2-70B-32k-ret 模型与 GPT-3.5-turbo-16k 和 Davinci-003(含 175 亿参数)的性能对比。在 QMSum (简称 QM),Qasper (简称 QASP),NarrativeQA (简称 NQA),QuALITY (简称 QLTY) 这几个测试中,我们使用了 ZeroSCROLLS 排行榜的测试集。这些测试集已包含了 GPT-3.5-turbo (4k 参数) 和 Davinci-003(特别标记为 *)的得分。平均 -7 指的是在全部 7 个数据集中的平均分数,而平均 -4* 则是指在 ZeroSCROLLS 的 4 个数据集中的平均分数。
Model | Avg-7 | Avg-4* | QM* | QASP* | NQA* | QLTY* | MSQ | HQA | MFQA |
---|---|---|---|---|---|---|---|---|---|
Davinci003 (175B) | – | 40.8* | 16.9* | 52.7* | 24.6* | 69.0* | – | – | – |
GPT-3.5-turbo (4k) | – | 39.2* | 15.6* | 49.3* | 25.1* | 66.6* | |||
GPT-3.5-turbo-16k | 42.8 | 42.4 | 17.6 | 50.5 | 28.8 | 72.6 | 26.9 | 51.6 | 52.3 |
LLaMA2-70B-32k | 40.9 | 42.4 | 15.6 | 45.9 | 28.4 | 79.6 | 19.1 | 49.5 | 48.4 |
LLaMA2-70B-32k-ret | 43.6 | 43.0 | 18.5 | 46.3 | 31.5 | 75.6 | 26.7 | 53.9 | 52.9 |
4.2 与 OpenAI 模型的对比分析
为了深入理解我们最优秀的模型——即增强了检索功能的 LLaMA2-70B-32k 的性能,我们将它与 GPT-3.5-turbo(4k)、GPT-3.5-turbo-16k 和 Davinci-003 在七个不同的数据集上进行了对比。我们发现,在这七个数据集上,LLaMA2-70B-32k 加上检索功能的版本在平均准确率上超越了 GPT-3.5-turbo-16k,并且在四项任务中的表现也优于配备 175B 参数的 Davinci-003。这表明,加入检索功能的 LLaMA2-70B-32k 是处理这些需要长文本理解的任务的强大模型,我们的结论是基于目前最先进技术的研究成果。
序列长度 | 配置 | 平均值 | QM | QASP | NQA | QLTY | MSQ | HQA | MFQA |
---|---|---|---|---|---|---|---|---|---|
4k | 基准配置(不含检索) | 31.61 | 16.34 | 27.70 | 19.07 | 63.55 | 15.40 | 34.64 | 44.55 |
Dragon | 35.73 | 18.14 | 29.20 | 23.39 | 70.30 | 20.09 | 41.54 | 47.45 | |
Contriever | 36.02 | 17.41 | 28.74 | 23.41 | 70.15 | 21.39 | 42.06 | 48.96 | |
OpenAI 嵌入技术 | 35.79 | 17.76 | 28.85 | 23.57 | 70.70 | 19.92 | 41.76 | 47.99 | |
32k | 基准配置(不含检索) | 37.36 | 15.37 | 31.88 | 23.59 | 73.80 | 19.07 | 49.49 | 48.35 |
Dragon | 39.60 | 18.34 | 31.27 | 24.53 | 69.55 | 26.72 | 53.89 | 52.91 | |
Contriever | 38.85 | 17.60 | 31.56 | 23.88 | 69.00 | 26.61 | 49.65 | 53.66 | |
OpenAI 嵌入技术 | 39.34 | 18.24 | 32.07 | 24.36 | 69.45 | 24.90 | 51.64 | 54.75 |
表 4:在 LLaMA2-70B 下,添加来自不同检索器的前五个检索块到上下文中的比较。公开可用的检索器可能优于 OpenAI 嵌入技术。
序列长度 | 设置 | 平均值 | QM | QASP | NQA | QLTY | MSQ | HQA | MFQA |
---|---|---|---|---|---|---|---|---|---|
4k | 基础 | 31.61 | 16.34 | 27.70 | 19.07 | 63.55 | 15.40 | 34.64 | 44.55 |
前 5 最佳 | 35.73 | 18.14 | 29.20 | 23.39 | 70.30 | 20.09 | 41.54 | 47.45 | |
前 10 最佳 | 34.62 | 16.54 | 28.67 | 24.38 | 68.70 | 19.00 | 42.18 | 42.84 | |
前 20 最佳 | 34.61 | 16.52 | 28.67 | 24.38 | 68.70 | 19.00 | 42.18 | 42.84 | |
16k | 基础 | 36.78 | 16.72 | 30.92 | 22.32 | 76.10 | 18.78 | 43.97 | 48.63 |
前 5 最佳 | 37.23 | 18.70 | 29.54 | 23.12 | 70.90 | 23.28 | 44.81 | ||
前 10 最佳 | 38.31 | 18.41 | 30.20 | 25.53 | 73.60 | 22.78 | 47.72 | 49.91 | |
前 20 最佳 | 36.61 | 17.26 | 29.60 | 25.81 | 72.30 | 22.69 | 41.36 | 47.23 | |
32k | 基础 | 37.36 | 15.37 | 31.88 | 23.59 | 73.80 | 19.07 | 49.49 | 48.35 |
前 5 最佳 | 39.60 | 18.34 | 31.27 | 24.53 | 69.55 | 26.72 | 53.89 | 52.91 | |
前 10 最佳 | 38.98 | 17.71 | 30.34 | 25.94 | 70.45 | 22.80 | 55.73 | 49.88 | |
前 20 最佳 | 38.38 | 16.36 | 30.42 | 24.42 | 69.60 | 24.51 | 54.67 | 48.65 |
表 5: 使用 LLaMA2-70B 在 4k、16k 和 32k 输入序列长度下,增加前 5/10/20 个检索块到上下文的比较。更多的上下文并不总是带来更好的结果。
4.3 不同检索器的削减实验
为了探究不同检索器对 LLaMA2-70B 的影响,我们比较了 Dragon、Contriever 和 OpenAI 嵌入(embeddings)在 LLaMA2-70B-4k 和 LLaMA2-70B-32k 上的表现。结果在表 4 中得到了确认,即我们的发现——检索可以提升短上下文和长上下文大语言模型的性能——在不同检索器上是一致的。此外,我们观察到,公开可用的检索器比商业闭环的 OpenAI 嵌入表现更佳。
4.4 提升检索内容数量
为了探究在上下文中加入更多检索内容对效果的影响,我们使用 Dragon 检索系统把检索内容的数量从 5 增加到 20,相关结果见表 5。我们发现,不同序列长度下,最好的平均效果通常出现在前 5 或前 10 的检索结果中。尽管 20 个检索内容可以被 16K 和 32K 的上下文容纳(如图 1 所示),但将检索内容增至 20 并未带来帮助,反而有时会降低性能。我们认为,这可能与“迷失在信息海洋中”现象(Liu 等人,2023)有关,或是因为模型被无关信息干扰,需要进一步研究。
5 结论
在本研究中,我们系统地探讨了在处理各种长上下文问答和基于查询的摘要任务时,采用最新的大语言模型(LLM)进行指令调整后的检索增强与长上下文延伸的比较。研究发现:i) 对于 4K 短上下文大语言模型和 16K/32K 长上下文大语言模型而言,检索功能显著提升了它们的性能。ii) 简化检索增强后的 4K 上下文大语言模型在性能上可与 16K 长上下文大语言模型媲美,且在推理过程中更加高效。iii) 在扩展上下文窗口和增强检索后,最优模型 LLaMA2-70B-32k-ret 在一系列信息丰富的查询任务上平均表现优于 GPT-3.5-turbo-16k 和 Davinci003。我们的研究指出了一个有前景的方向:结合检索和长上下文技术,以打造更出色的大语言模型。