大型言语模型大有用处，在设计 prompt 方面，人们通常建议为言语模型提供详尽的恣意描述和背景信息。
近期的一些言语模型有能力输出较长的上下文，但它究竟能多好地利用更长的上下文？这一点却相对少有人知。
近日，斯坦福大学、加州大学伯克利分校和 Samaya AI 的研究者发布了一篇实证研究论文，探究了这个问题。
结论令人意外：如果上下文太长，言语模型会更关注其中的前后部分，中间部分却几乎被略过不看，导致模型难以找到放在输出上下文中部的有关信息。
论文链接：https://arxiv.org/pdf/2307.03172.pdf
他们对多种不同的开源（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%），但却显著提升了输出上下文长度（由此延迟和成本都大幅提升）。
图 14
这些结果表明，如果能有效地对检索文档排序（让有关信息与输出上下文的起始处更近）或对已排序的列表进行截断处理（必要时返回更少的文档），那么也许可以提升基于言语模型的阅读器应用检索上下文的能力。