中间的迷失：为何更大的上下文窗口并不总能提升 LLM 性能

Source: Dev.to

概览

把所有内容塞进一个长提示并寄希望它能正常工作是一种常见做法，但它常常适得其反。增加更多上下文实际上可能会削弱模型的回答，而明确写出的约束也可能被忽视。

“中间丢失”研究

实验设置

研究人员向语言模型提供了多篇文档，并将相关信息放在三个可能的位置：

• 在上下文的开头
• 在上下文的中间
• 在上下文的结尾

如果长上下文处理是完美的，性能应当与放置位置无关。

发现

• 最佳性能： 当所需信息位于提示的开头或结尾时。
• 最差性能： 当信息位于中间时；在某些情况下，性能甚至比根本不提供文档还要差。

这种效应相当显著，并且不限于单一模型系列。

人类记忆的类比

该模式与人类认知中观察到的序列位置效应相呼应：

• 我们更清晰地记得一本书或一次对话的开头和结尾，而中间的细节更容易淡忘。
• 中间的细节往往更快消失。

虽然理论上 Transformer 架构可以对每个 token 同等关注，但它们仍表现出对输入开头和结尾的类似偏好。

对更大上下文窗口的启示

• 更多 token ≠ 更好推理。 扩展上下文窗口（例如到 100 k 或 200 k token）并不会在输入本可以适配更小窗口时自动提升性能。
• 当你输入大型代码文件、长日志、众多约束或大量聊天记录时，位于中间的关键信息可能会被低估。
• 这解释了为何模型有时会忽视明确写出的规则——这不是随机的，而是一种系统性偏差。

实用的提示设计建议

提示结构

严格输出模式示例

{
  "type": "object",
  "properties": {
    "result": { "type": "string" },
    "metadata": {
      "type": "object",
      "properties": {
        "timestamp": { "type": "string", "format": "date-time" },
        "source": { "type": "string" }
      },
      "required": ["timestamp"]
    }
  },
  "required": ["result"]
}

使用模式的指南

• 输出必须是有效的 JSON。
• 不要包含解释或任何额外文字。
• 必须完全遵循模式。

其他提示

• 当对话变得非常冗长时，考虑启动一个新的、干净的提示，而不是继续在庞大的线程中进行。
• 将最重要的指令放在最前面，并在结尾再次重复或强化它们。
• 将提示的中间视为“支持性数据”区块；模型对其的关注度会相对较低。

通过将提示结构化为明确的层次——关键指令在前，支持信息居中，强化信息在后——你可以减轻“中间丢失”效应，获得更可靠的输出。