LLM如何处理长上下文：Lost in the middle

论文地址：Lost in the Middle: How Language Models Use Long Contexts

论文总结：写prompt的时候，需要注意内容的顺序，把重要的信息放在最前面或者最后面。

大型语言模型大有用处，在设计 prompt 方面，人们通常建议为语言模型提供详尽的任务描述和背景信息。

近期的一些语言模型有能力输入较长的上下文，但它究竟能多好地利用更长的上下文？这一点却相对少有人知。

近日，斯坦福大学、加州大学伯克利分校和 Samaya AI 的研究者发布了一篇实证研究论文，探究了这个问题。

结论令人意外：如果上下文太长，语言模型会更关注其中的前后部分，中间部分却几乎被略过不看，导致模型难以找到放在输入上下文中部的相关信息。

他们对多种不同的开源（MPT-30B-Instruct、LongChat-13B (16K)）和闭源（OpenAI 的 GPT-3.5-Turbo 和 Anthropic 的 Claude）的语言模型进行了对照实验 —— 实验中需要模型获取并使用输入上下文中的信息。

研究者首先实验了多文档问答，该任务需要模型基于多个文档进行推理，以找到相关信息并将其用于回答给定问题。这个任务模拟了检索增强式生成任务，其是许多商用生成式搜索和问答应用（如 Bing Chat）的基础。在实验中，他们的做法是改变输入上下文长度和输入上下文中相关信息的位置，然后对照比较输出结果的表现。

更详细地说，研究者通过向输入上下文添加更多文档来增大输入上下文的长度（类似于在检索增强式生成任务中检索更多文档）；以及通过修改输入上下文中文档的顺序，将相关信息放置在上下文的开头、中间或结尾，从而修改上下文中相关信息的位置。

实验中，研究者观察到，随着相关信息位置的变化，模型性能呈现出明显的 U 型趋势，如图 1 所示。也就是说，当相关信息出现在输入上下文的开头或末尾时，语言模型的性能最高；而当模型必须获取和使用的信息位于输入上下文中部时，模型性能会显著下降。举个例子，当相关信息被放置在其输入上下文中间时，GPT3.5-Turbo 在多文档问题任务上的性能劣于没有任何文档时的情况（即闭卷设置；56.1%）。此外，研究者还发现，当上下文更长时，模型性能会稳步下降；而且配备有上下文扩展的模型并不一定就更善于使用自己的上下文。

图 1

既然已经知道语言模型在多文档问答任务中难以检索和使用相关信息，那么我们不禁要问：语言模型究竟能在多大程度上从输入上下文中检索信息？

研究者通过一个合成的键 - 值检索任务研究了这一问题。该任务被设计成一个最小化的测试平台，用于检测从输入上下文中检索出相匹配的 token 的基本能力。

在此任务中，研究者会向模型提供一个 JSON 格式的「键 - 值」对集合，然后要求模型返回与特定键关联的值。与多文档问答任务相似，键 - 值检索任务也允许对输入上下文的长度（添加更多键 - 值对）和相关信息的位置进行进行对照更改。研究者在实验中观察到了类似的 U 型性能曲线，即当匹配的 token 出现在输入上下文中部时，许多模型就难以检测出它们。

为了理解语言模型难以获取和使用输入上下文中部位置的信息的原因，研究者分析了模型架构（仅解码器和编码器 - 解码器）、查询感知型上下文化（query-aware contextualization）和指令微调的作用。

他们发现，当评估时的序列长度在训练时所用的序列长度范围内时，对于输入上下文中相关信息位置的变化，编码器 - 解码器模型是相对稳健的；但如果评估时的序列长度长于训练时的，那么模型性能会呈现出 U 型特征。

此外，查询感知型上下文化（将查询放在文档或键 - 值对之前和之后）能让模型可以完美地执行该合成键 - 值任务，但基本不会改变多文档问答任务中呈现的趋势。还有，甚至是基础语言模型（即没有指令微调）也会随输入上下文中相关信息的位置变化而呈现出 U 型性能曲线。

最后，为了更好地理解「向输入上下文添加更多信息」与「增多模型推理所用的内容量」之间的权衡，研究者进行了一个案例研究。该研究基于检索器 - 阅读器模型在开放域问答任务上的表现。相较于对照式的多文档问答任务实验（上下文总是会包含刚好一个用于问答问题的文档），在开放域问答任务中，可能会有多个或零个文档包含答案。

研究者发现，当通过检索维基百科来回答 NaturalQuestions-Open 中的查询时，模型性能在检索器召回率趋于稳定之前很久就已经饱和，这表明模型无法有效地使用额外的检索文档 —— 使用超过 20 个检索文档仅能略微提高性能（对于 GPT-3.5-Turbo 是 ∼1.5%，对于 claude-1.3 为 ∼1%）。

整体来说，这份研究能帮助人们更好地理解语言模型是如何使用输入上下文的，并为未来的长上下文模型引入了新的评估协议。为了促进未来的相关研究，研究者放出了代码和评估数据，请访问：https://github.com/nelson-liu/lost-in-the-middle

为什么语言模型难以完整使用其输入上下文？

在多文档问答和键 - 值检索实验上的结果表明，当语言模型需要从长输入上下文的中部获取相关信息时，模型性能会显著下降。为了理解原因，研究者分析了模型架构（仅解码器和编码器 - 解码器）、查询感知型上下文化和指令微调的作用。

模型架构的影响

为了更好地理解模型架构的潜在影响，研究者比较了仅解码器模型和编码器 - 解码器语言模型。

实验中使用的具体模型为 Flan-T5-XXL 和 Flan-UL2。Flan-T5-XXL 的训练使用了序列长度为 512 token 的序列（编码器和解码器）。Flan-UL2 一开始使用 512 token 长度的序列训练（编码器和解码器），但之后又在 1024 token 长度的序列上预训练了额外 10 万步（编码器和解码器），然后进行了指令微调 —— 其编码器在 2048 token 长度的序列上微调，解码器的序列长度则为 512 token。但是，由于这些模型使用相对位置嵌入，因此它们的推断能力（原则上）可以超出这些最大上下文长度 ——Shaham et al. (2023) 发现当序列长度为 8000 token 时，这两个模型都能取得不错的表现。

图 11 并排展示了仅解码器模型和编码器 - 解码器模型的性能表现。当 Flan-UL2 评估时的序列长度在其训练时的 2048 token 上下文窗口范围内时，输入上下文中相关信息的位置变化能得到稳健的应对。而当评估时的序列长度超过 2048 token 时，如果相关信息位于输入上下文中部，那么 Flan-UL2 的性能会开始下降。Flan-T5-XXL 展现出的趋势类似 —— 如果相关信息在输入上下文中部，那么更长的输入上下文会导致性能下降更多。

图 11

研究者推测编码器 - 解码器模型也许能更好地利用其上下文窗口，因为它们的双向编码器让它们可以在未来文档的上下文中处理每个文档，这或许能提升文档之间的相对重要性估计。

查询感知型上下文化的影响

实验中，研究者的做法是将查询（即要回答的问题或要检索的键）放在数据（即文档或键 - 值对）之后来处理。由此，当对文档或键 - 值对进行上下文化时，仅解码器模型无法顾及查询 token，因为查询只会出现在 prompt 末尾而仅解码器模型在每个时间步骤只能关注之前的 token。

另一方面，编码器 - 解码器模型使用了双向编码器来上下文化输入上下文，这似乎能更加稳健地应对相关信息的位置变化 —— 研究者猜想这一直观结论或许也能用于提升仅解码器模型的性能，做法是将查询同时放在数据的前面和后面，从而实现文档或键 - 值对的查询感知型上下文化。

研究者发现，查询感知型上下文化能极大提升模型在键 - 值检索任务上的表现。举个例子，当使用 300 个键 - 值对进行评估时，GPT-3.5-Turbo (16K)（使用了查询感知型上下文化）的表现堪称完美。对比之下，如果没有查询感知型上下文化，其在同样设置下的表现最低为 45.6%。

图 12

相比之下，在多文档问答任务上，查询感知型上下文化的影响很小。特别指出，当相关信息位于输入上下文的最开始时，它可以提高性能，但在其他设置中会稍微降低性能。

指令微调的影响

指令微调是指在初始的预训练之后，语言模型还会使用一个指令和响应数据集进行监督式微调。在这种监督式的指令微调数据中，任务规范和 / 或指令通常放置在输入上下文的开头，这可能会导致经过指令微调的语言模型为输入上下文的开头赋予更多权重。

为了更好地理解指令微调的潜在影响，研究者比较了 MPT-30B-Instruct 与其基础模型 MPT-30B（未经指令微调）在多文档问答任务上的性能表现。

图 13 展示了 MPT-30B-Instruct 和 MPT-30B 在多文档问答任务上的性能随输入上下文中相关信息的位置的变化。研究者惊讶地发现，MPT-30B-Instruct 和 MPT-30B 都展现出了 U 型趋势。尽管 MPT-30B-Instruct 的绝对表现优于 MPT-30B，但它们的整体性能趋势十分相似。

图 13

其实之前已有研究发现语言模型更偏向于近期的 token（即输入上下文的末端）。这种对近期 token 的偏好通常表现在预测连续文本的下一个词的语境中，此时语言模型只能从长程信息中获得极少的好处。相比之下，这里的实验结果表明，当 prompt 是指令格式的数据时，语言模型能够使用更长程的信息（即输入上下文的开头）。研究者猜想语言模型是从相似格式的数据中学习了这些上下文，而这些数据来自预训练时见过的网络文本。

上下文更多就总是更好吗？一个基于开放域问答的案例研究

在实践中，在输入上下文长度方面往往存在一个权衡 —— 如果给经过指令微调的语言模型输入更多信息，可能有助于其在下游任务上的性能，但也会增加模型需要处理的内容量。就算一个语言模型可以处理 1.6 万个 token，那么如果真的为其提供这么多 token，那会真的有用吗？这个问题的答案是：由下游任务决定。因为这取决于所添加上下文的边际价值以及模型有效使用长输入上下文的能力。为了更好地理解这一权衡，研究者在 NaturalQuestions-Open 上进行了开放域问答的案例研究。

他们使用的模型采用了标准的检索器 - 阅读器设置。一个检索系统（Contriever，基于 MS-MARCO 微调得到）从 NaturalQuestions-Open 取用一个输入查询，然后返回 k 个维基百科文档。为了在这些检索到的文档上调节经过指令微调的语言模型，研究者将它们包含到了 prompt 中。他们评估了检索器召回率和阅读器准确度（任何带注释的答案是否出现在预测输出中）随检索出的文档数 k 的变化情况。研究者使用了 NaturalQuestions-Open 的一个子集，其中长答案是一个段落（而不是表格或列表）。

图 14 给出了开放域问答的实验结果。可以看到，在检索器性能趋于稳定之前很久，阅读器模型的性能就早已饱和，这表明阅读器没有有效地使用额外的上下文。使用超过 20 个检索文档只能略微提升阅读器性能（对于 GPT-3.5-Turbo 是 ∼1.5%，对于 Claude 为 ∼1%），但却显著提升了输入上下文长度（由此延迟和成本都大幅提升）。