检索增强生成 (RAG) 是使用最广泛的生成式 AI 应用之一。RAG 通过从外部来源（如非结构化文档或结构化数据）检索信息，来提升大语言模型 (LLM) 的准确性。随着拥有更长上下文长度的 LLM（例如 Anthropic Claude（200k 上下文长度）、GPT-4-turbo（128k 上下文长度）和 Google Gemini 1.5 pro（200 万上下文长度））的出现，开发者可以在 RAG 应用中输入更多文档。对于这些极长的上下文长度，甚至有人开始讨论，长上下文语言模型是否会最终替代 RAG 的工作流程。如果能够直接将整个语料库放入上下文窗口中，为什么还要从数据库中检索单个文档呢？

本文将探讨上下文长度增加对 RAG 应用质量的影响。在 13 个流行的开源和商业 LLM 上进行了 2000 多次实验，以分析它们在不同领域数据集上的表现。结果显示：

检索更多文档确实有助于提高性能：为特定查询检索更多信息，可以增加正确信息传递给 LLM 的机会。现代 LLM 具有长上下文长度，可以利用这一点来提升整体 RAG 系统的效果。

长上下文并非总是对 RAG 有利：大多数模型在达到某一上下文长度后，性能会开始下降。比如，Llama-3.1-405b 在超过 32k Token 后表现下滑，GPT-4-0125-preview 在超过 64k Token 后也出现类似情况，只有少数模型能够在所有数据集上保持一致的长上下文 RAG 表现。

不同模型在长上下文下的失败方式也各不相同：本文深入研究了 Llama-3.1-405b、GPT-4、Claude-3-sonnet、DBRX 和 Mixtral，发现它们在长上下文场景下出现的失败模式各有特点，如因版权问题拒绝处理或始终生成上下文摘要。这些现象表明，许多模型在长上下文的训练方面尚显不足。

RAG：一个典型的 RAG 工作流程通常包含两个步骤：

检索：根据用户的问题，从语料库或数据库中查找相关信息。信息检索是系统设计中的一个重要领域。当前的简单方法是将每个文档嵌入为向量，并将这些向量存储在向量数据库中。系统会根据用户问题与文档的相似性，检索到相关的文档。检索过程中的一个关键因素是返回文档的数量，以及因此返回的 Token 总数。

生成：在获得用户问题和检索到的信息后，生成相应的回答（或在信息不足时拒绝生成）。生成步骤可以使用多种技术，但当下比较简单的方法是通过一个简单的提示词引导大语言模型 (LLM)，并结合检索到的信息和相关的上下文，生成回答。

长上下文大语言模型：LLM 支持越来越长的上下文长度。

虽然早期的 GPT-3.5 仅有 4k Token 的上下文长度，但 GPT-4-turbo 和 GPT-4o 已扩展到 128k Token。类似地，Claude 2 的上下文长度达到 200k Token，而 Gemini 1.5 pro 则高达 200 万 Token。开源 LLM 的上下文长度也在不断增加：例如，第一代 Llama 模型只有 2k Token，而最新的 Mixtral 和 DBRX 已经扩展到了 32k Token。最新发布的 Llama 3.1 更是支持 128k Token 的上下文长度。

长上下文对 RAG 的优势在于，系统可以在生成过程中将更多检索到的文档纳入上下文，增加模型找到相关信息的机会，从而更好地回答问题。

然而，最近对长上下文模型的研究揭示了两个主要局限性：

“中间信息丢失”问题：当模型难以保留并有效利用长文本的中间部分信息时，就会出现“中间信息丢失”问题。随着上下文长度的增加，这种情况可能导致模型整合信息的能力下降。

有效上下文长度：RULER 论文研究了长上下文模型在检索、变量跟踪、信息聚合和问答等任务中的表现，发现有效上下文长度（即模型性能开始下降时的实际可用上下文长度）通常远低于标称的最大上下文长度。

基于这些研究结果，本文设计了多个实验，旨在探讨长上下文模型的潜在价值、其在 RAG 工作流程中的有效上下文长度，并评估这些模型何时及如何失效。

为了探讨长上下文在检索与生成过程中的作用，以及其对整个 RAG 流程的影响，提出了以下研究问题：

• 长上下文对检索的影响：检索到的文档数量如何影响系统找到相关文档的几率？

• 长上下文对 RAG 的影响：随着检索文档的增多，生成结果的表现如何变化？

• 长上下文在 RAG 中的失效模式：不同模型在处理长上下文时会如何出现问题？

- 嵌入模型：(OpenAI) text-embedding-3-large

- 文档块大小：512 Token

- 跨距大小：256 Token（相邻文档块之间的重叠为 256 Token）

- 向量存储：FAISS（使用 IndexFlatL2 索引）

在实验 2 中，生成设置如下：

- 生成模型：gpt-4o、claude-3-5-sonnet、claude-3-opus、claude-3-haiku、gpt-4o-mini、gpt-4-turbo、claude-3-sonnet、gpt-4、meta-llama-3.1-405b、meta-llama-3-70b、mixtral-8x7b、dbrx、gpt-3.5-turbo

- 生成温度：0.0

- 最大输出 Token 数量：1024

在对上下文长度 X 进行基准测试时，采用了以下计算方法来确定提示词的长度：

- 先从上下文长度 X 中减去 1k Token，用于模型输出。

- 然后保留 512 Token 作为缓冲区。

- 剩余部分为提示词的最大可用长度。

在本研究中，对所有大语言模型 (LLM) 在 4 个经过精心筛选的 RAG 数据集上进行了基准测试。这些数据集包括了行业应用场景的 Databricks DocsQA 和 FinanceBench，以及更具学术性的 Natural Questions (NQ) 和 HotPotQA。

评估指标

- 检索指标：采用召回率来评估检索效果。召回率表示从数据集中检索到的相关文档数量与数据集中所有相关文档数量的比率。

- 生成指标：通过答案正确性来衡量生成效果。这个答案正确性指标由基于 GPT-4o 的校准 LLM 评判系统实现。

实验发现

长上下文对 RAG 有何作用？

在本次实验中，研究了检索到更多结果如何影响生成模型在上下文中获取相关信息的能力。假设检索器返回 X 个 Token，并在此基础上计算召回率得分。从另一个角度来看，当生成模型只能使用检索到的文档生成答案时，召回率就成为其性能的上限。

以下是 OpenAI text-embedding-3-large 嵌入模型在 4 个数据集和不同上下文长度下的召回率表现。将文档分块为 512 Token，并为提示词和生成结果预留了 1.5k 的缓冲区。

饱和点：如上表所示，每个数据集的检索召回率在不同的上下文长度下会达到饱和。例如，NQ 数据集在 8k 的上下文长度下较早达到饱和，而 DocsQA、HotpotQA 和 FinanceBench 数据集则分别在 96k 和 128k 上下文长度时达到饱和。这表明，即使使用简单的检索方法，生成模型在 96k 或 128k Token 的范围内依然能够获取额外的相关信息。因此，模型更大的上下文长度可以帮助捕获这些信息，从而提高系统的整体质量。

使用更长上下文未必能提升 RAG 性能  

在这个实验中，将检索步骤和生成步骤结合，形成一个简单的 RAG 流程。为了评估不同上下文长度下的 RAG 性能，增加了检索器返回的块数量，以填满生成模型的上下文，直到达到设定的长度。然后，让模型回答特定基准测试中的问题。结果显示：

1. 增加上下文大小能使模型利用更多检索到的文档：从 2k 到 4k 上下文长度，所有模型的性能均有所提升，并且许多模型在 16~32k 上下文长度下持续提升。

2.  大多数模型在达到一定上下文长度后性能会下降，例如：gpt-4-turbo 和 claude-3-sonnet 在 16k，mixtral-instruct 在 4k，dbrx-instruct 在 8k。

3. 近期的模型如 gpt-4o、claude-3.5-sonnet 和 gpt-4o-mini 展现了改进的长上下文处理能力，几乎没有性能下降。

为了评估生成模型在长上下文下的失败模式，分析了 llama-3.1-405b-instruct、claude-3-sonnet、gpt-4、Mixtral-instruct 和 DBRX-instruct 的样本，这些模型涵盖了一些顶尖的开源和商业模型。

提取了每个模型在不同上下文长度下的答案，手动检查了几个样本，并根据观察定义了以下失败类别：

- repeated_content:  LLM 的回答完全是重复的词语或字符。

- random_content: 模型生成的回答完全随机、与内容无关或不符合逻辑或语法。

- fail_to_follow_instruction: 模型未能理解指令意图或未能按照问题中指定的指令进行操作。例如，当指令要求基于给定上下文回答问题，而模型却尝试总结上下文。

- wrong_answer: 模型尝试按照指令操作但提供了错误答案。

- others: 其他未包含在以上类别中的失败

实验发现，claude-3-sonnet 和 DBRX-instruct 的失败模式特别引人注目，因为这些失败模式在达到一定的上下文长度后变得更加明显。例如，Claude-3-sonnet 的版权问题失败率在 16k 上下文长度时为 3.7%，在 32k 时增加到 21%，在 64k 时进一步增加到 49.5%；DBRX 的指令跟随失败率在 8k 上下文长度时为 5.2%，在 16k 时上升到 17.6%，在 32k 时达到了 50.4%。这些问题可能是由于长上下文长度下缺乏足够的指令跟随训练数据导致的。类似的观察结果也出现在 LongAlign 论文（Bai 等，2024）中，该论文表明，更多的长指令数据可以提高长任务的性能，而长指令数据的多样性有助于模型的指令跟随能力。

这些失败模式提供了额外的诊断信息，用于识别在长上下文情况下的常见失败情况，这些情况可能提示需要根据不同模型和设置调整 RAG 应用中的上下文大小。

结论与启示

- 长上下文模型和 RAG 是协同的: 长上下文使 RAG 系统能够有效包含更多相关文档 

- 许多长上下文模型仍有局限性，在长上下文中表现下降 

- 开发者需要好的评估工具来了解生成模型和检索设置如何影响最终结果质量