The LLM Blindspot: Why Models Forget What’s in the Middle of Your Prompt

LLM的盲点：为何模型会遗忘提示中的中间信息

ByteByteGo

2026年10月5日

控制代理访问权限。不要猜测。（赞助）

AI代理正在从演示走向生产环境，它们需要的不仅仅是模型。它们需要实时数据、快速响应以及对可读、可写和可操作内容的严格限制。在12月9日举办的智能数据峰会上，"防护措施，而非猜测"专题将展示如何通过智能数据平面锁定代理访问权限。您还将看到流式处理、SQL和代理如何在一个平台上运行，并了解智能数据平面的未来发展方向。这是一场免费的虚拟会议，专为将AI代理投入生产的工程师打造。

[免费注册]

我们可以通过提示向LLM提供详尽的信息，但它仍可能无法正确使用这些信息。当所需信息位于长提示的中间部分时，这种失败的可能性会显著增加。我们称这种现象为"迷失在中间"效应或LLM盲点。

例如，假设我们给基于AI的代码助手提供了一大堆项目文档。其中有一段明确说明审计日志必须保留37天。然而，代码助手却编写了一个清理函数，在30天后删除这些日志。相关规则被清晰地提及，也包含在提示中且符合模型的限制。但答案却因为该规则位于中间部分而被忽略。

在本文中，我们将探讨LLM为何存在这种对中间信息的偏见。以下是我们将涵盖的内容：

• 模型可获取的信息
• 将相同信息移动到提示的不同位置是否会改变答案
• 为何LLM更关注提示的开头和结尾
• 更大的上下文窗口为何无法解决问题
• 减少对中间信息偏见的策略

模型可获取的信息

当应用程序向LLM发送请求时，输入内容通常包含的不只是用户的最新问题。它可能包括指令、先前消息、文档、代码以及工具返回的中间结果。所有这些内容共同构成了模型的输入上下文。

模型将所有这些信息处理为标记（tokens），这些标记基本上是文本的小单位。一个标记可能代表一个词、词的一部分、标点符号或其他文本片段。上下文窗口设定了模型可处理的标记数量上限。这个窗口还必须能够容纳生成的响应。

假设一个模型支持128,000个标记的上下文窗口。这告诉应用程序它理论上可以提供多少信息。但这并不能保证模型会正确检索每一条事实或遵循每一条指令。

这类似于系统容量与可靠性之间的差异。数据库可能存储数百万条记录，但检索到正确记录仍需要适当的查询和执行过程。同样，LLM需要选择和使用相关信息，尽管其内部处理过程与数据库查询截然不同。

LLM是否存在盲点

我们可以通过保持问题和支撑信息不变，仅将支撑信息移动到输入的不同位置来测试这一点。

例如，设想有一组项目笔记包含这样一个事实：“Cedar项目的负责人是Adam。”问题始终是：“谁拥有Cedar项目？”

在第一个测试中，相关笔记出现在输入提示的最前面。在另一个测试中，它出现在笔记集合的中间位置。在第三个测试中，笔记出现在最后。其他笔记保持不变。

如果准确性发生显著变化，说明模型对证据出现的位置很敏感。一项名为“Lost in the Middle”（2023年发布，2024年发表）的研究分析了这种现象，发现模型在开头和结尾附近的表现通常最强，而中间位置的表现较弱。这种现象形成了U型准确性曲线。具体表现如下：

• 如果信息出现在开头附近，大语言模型（LLMs）表现出更高的准确性，通常与首因偏差（primacy bias）相关。
• 如果信息出现在结尾附近，LLMs同样表现出更高的准确性。但这种现象与近因偏差（recency bias）相关。
• 最后，如果信息出现在中间位置，LLMs的准确性较低。

当然，这些更像是一种趋势而非绝对规律。即使信息出现在开头或结尾位置，也可能得到错误答案。此外，某些模型在特定任务上可能在所有位置都表现良好。

从外部视角来看，几种类型的失败可能看起来类似：

• 应用程序可能从未发送特定文档或信息。
• 应用程序可能截断对话并删除包含问题答案的早期消息。
• 检索系统可能选择了错误的段落。
• 最后，正确的段落可能已存在，但模型未能利用它生成答案。

“Lost in the Middle”现象涉及最后一种情况。信息确实存在于输入中，但其位置会影响其是否能有效贡献到答案中。

为什么大语言模型更关注提示的开头和结尾

模型不会对提示的每个部分给予同等的影响力。其内部处理过程可能更倾向于早期信息，而接近结尾的信息则因靠近即将生成的答案而受益。相比之下，中间部分则缺乏这两种优势。

大多数生成式大语言模型使用一种称为transformer的神经网络架构。这种架构的核心组件是注意力机制（attention）。

注意力机制帮助模型整合输入不同部分的信息。它使模型能够计算哪些其他标记表示应贡献到当前计算的表示中。所有这些贡献都有不同的权重，有些获得更多的影响力，而有些则较少。

以这个句子为例：“部署失败是因为配置文件包含了一个无效端口。”为了说明失败原因，模型应将“部署失败”与“无效端口”关联起来。注意力机制为跨这些位置的信息整合提供了机制。

这种整合过程会通过多个处理层重复发生。transformer架构还使用多个注意力头，提供不同的信息整合方式。最终结果比单一扫描标记句子重要性的过程复杂得多。

关键在于，仅仅拥有访问令牌的权限并不保证它会对最终答案产生显著影响。注意力取决于多种因素，例如令牌内容、学习模式、位置以及周围材料。

因果掩码在早期和晚期位置之间创建了不对称性。

标准生成式变压器使用其前面的文本预测文本。在训练过程中，模型不会提前查看它应该预测的答案。因果注意力掩码通过阻止对未来的注意力来强制执行此限制。

考虑一个包含6个令牌的提示。令牌1中的信息可以影响模型如何表示令牌2到6。令牌4中的信息可以影响后面的令牌，但不能影响令牌1到3的表示。

模型执行多层处理。在这些层中，早期信息可以通过直接方式或通过已经包含其影响的其他表示来影响后期表示。这可以为开头提供结构优势。但这并不意味着模型一定最理解第一个令牌。它只是意味着早期信息有更多途径来影响计算。

提示的结尾获得不同的优势。它更接近实际问题和答案。许多模型的注意力模式和表示机制更倾向于邻近关系。这在普通语言中很有用，因为邻近的词经常一起出现。例如，在句子“The server stopped because its disk was full”中，解释紧邻它所解释的事件。模型学习充分利用这种邻近信息。

当问题出现在长文档之后时，最后几段是邻近的，而中间段则相距甚远。根据模型的不同，这些邻近段可能更容易使用。

然而，对简化的“令牌1积累大量注意力”解释有两个重要限定：

• 首先，允许关注并不决定给予令牌的实际注意力权重。模型不会为每个令牌维护一个持续累积的重要性分数。

• 其次，在提示后生成答案时，标准的完整因果注意力可以访问所有早期提示位置，包括中间部分。

因此，中间部分并未因因果掩码而直接隐藏在答案之外。问题涉及信息在整个网络中如何表示和结合。

为什么更大的上下文窗口无法解决问题

更大的上下文窗口在增加模型整体容量方面非常有效。但它们并不能保证在使每个位置同样有用时具有均匀的可靠性。

我们可以通过最大上下文大小和任务的有效上下文大小来区分两者。前者涉及整体支持的输入大小。后者涉及在保持可接受性能的同时，应用程序实际可以使用的上下文量。

有效上下文大小取决于任务。例如，在某些文档中查找一个独特标识符的任务与比较多个文档、解决矛盾或跟踪长对话中的变化不同。

这是 RULER 基准测试发挥作用的地方。原始基准测试使用超越简单检索的任务对 17 个模型进行了评估，包括遵循信息链和聚合结果。研究发现，随着输入长度增加，模型性能普遍存在下降趋势。然而，其局限性明确指出，该基准测试仅按输入长度报告得分，而未控制并报告证据位置的影响。

缓解偏见的策略

尽管很难完全消除模型对中间信息的偏见，但我们仍可以采取一些策略来缓解这一问题。

让我们更详细地探讨这些方法：

提示优化

合理组织提示内容有助于让关键信息更易于使用。一个好的起点是让任务、关键约束条件和最终问题对模型来说更容易识别。我们不应将重要信息隐藏在大量不相关材料中。

对于编程任务，简短的开场陈述可以明确提及兼容性要求。相关源文件可以随后列出，并在最后提出明确请求。对于文档问答任务，将问题放在文档之后也是一种有效的测试方式。

使用清晰的边界标记来区分不同类型的内容也很有帮助。Markdown 标题、文档标签和 XML 风格的标签可以将指令与源材料区分开来，并分离不同文档。然而，这些方法只是实用的起点，其效果需要在所选模型上进行验证。

例如，一个应用程序可以构建如下提示：

任务：为清理工作线程提出修改建议。
关键约束：审计日志必须保留 37 天。

<document id="retention-policy">
审计日志必须保留 37 天。
</document>

<document id="cleanup-worker">
[相关实现]
</document>

请求：
识别所需的保留周期及其来源。
然后提出代码修改方案。
检查修改是否符合保留要求。

在此示例中，约束条件来自提供的源材料。文档具有明确的身份标识，最终请求指定了答案必须使用的证据。

添加这些标签不会改变模型的注意力掩码或保证合规性。它们的主要目的是减少对输入组织方式的歧义。简短的重复也可以帮助保持关键约束的可见性。然而，多次重复整个提示会增加长度，如果复制内容出现分歧，还可能引入矛盾。

剪枝不必要的上下文

相比强制执行任意的 token 限制，减少不必要的上下文信息更有实际价值。

例如，模型提供方通常会建议保持在一定 token 数量以下，如 20K tokens。这更像是一个特定于应用的预算，而非科学边界。不存在一个普遍适用的阈值，使得 19,999 tokens 可靠而 20,001 tokens 变得不可靠。一个简短的提示可能因指令冲突而失败。另一方面，当证据清晰且任务简单时，一个更长的提示可能反而更易成功。

更好的方法是在添加任务所需信息的同时，移除价值有限的材料。我们应该选择相关信息，并将上下文作为应用程序资源进行管理。假设一个AI助手正在调查数据库连接错误，提供数月的日志、所有配置文件和完整的部署历史会生成大量不必要的内容。更聚焦的输入可能只包含错误本身、相关连接设置、受影响的代码和最近的更改。

可以注意到，主要困难在于判断哪些信息是不必要的。如果我们移除了某个异常、依赖项或早期决策，虽然会使提示更简短，但也会降低准确性。因此，上下文选择需要在保留回答问题所需证据的同时，剔除无用信息。

对长对话也应采取同样的谨慎态度。应用程序可以维护一个简洁的当前需求和决策记录，并附有回溯原始材料的引用。摘要很有用，但可能省略细节，因此当精确信息至关重要的时候，摘要不应成为唯一的留存来源。

基于RAG的检索

检索可以减少模型在提示中需要搜索的信息量。

检索系统会先在更大范围内搜索，选择相关材料，然后由LLM进行回答。这种方法通常被称为检索增强生成（RAG）。

以一个基于AI的客服应用为例，该应用拥有数千页文档。当用户询问webhook重试相关问题时，系统可以检索重试策略、相关配置文档和适用的异常信息。然后LLM从这个较小的集合中进行回答。

检索可以使用关键词搜索、数据库查询、语义搜索或这些方法的组合。关键变化在于，应用程序需要负责寻找可能的证据，而不是总是将整个集合放入提示中并寄希望于最佳结果。

需要明确的是，这种方法本身也存在局限性。检索搜索仍可能遗漏相关段落，检索到的摘录可能省略必要异常，检索过多内容可能重现原始问题。

因此，RAG并不能消除“中间迷失”现象。检索到的材料仍需要合理的筛选、排序和评估。

结论

“中间迷失”问题揭示了LLM的一个盲区。信息的可用性并不能保证其被有效使用。某个事实可能位于上下文窗口内，但对答案的贡献却非常有限。看似遗忘的现象，通常是注意力机制在生成过程中让相关信息获得足够影响力的特性所致。

这种情况部分源于不同位置的信息获得的优待不同。早期信息有更多机会影响后续处理，而接近末尾的信息可能受益于其与问题和答案的邻近性。中间位置的信息则无法同时受益于这两点。不过，这种效应的强度会随着模型、训练方式和任务的不同而变化。

我们可以尝试扩大上下文窗口以提升容量，但可靠地利用这一容量仍需测试。清晰的指令、条理分明的原始材料以及对关键细节的精准布局，有助于生成更优质的输出结果。在保留重要信息和例外情况的前提下，去除冗余上下文并检索相关段落也能简化任务。这些方法能降低遗漏信息的可能性，但无法保证得出完美答案。