ByteByteGo解析LLM的“中间遗忘”：信息在提示词中部时更易被忽略
ByteByteGo发文解释“lost in the middle”现象：同一事实放在提示词不同位置，模型使用它的效果会变化，开头和结尾往往更强，中部更弱；更大的上下文窗口并不保证每个位置都被可靠利用。
AI解读：ByteByteGo在文章中用“审计日志必须保留 37 天、代码助手却写成 30 天删除”的虚构例子说明：规则确实写进了提示词、也在模型上下文限制内，但只因位于中部就被答案忽略。这是作者为解释现象举的例子，不是公开实测数据。
文章把“中间遗忘”与另外三类失败区分开：信息根本没被发送、对话被截断删掉了含答案的早期消息、检索系统选错了段落。它只针对第四种情况——正确内容在输入里，但位置影响了它是否参与生成答案。
作者引用 2023 年发布、2024 年发表的“Lost in the Middle”研究称，模型在开头和结尾附近的准确率通常更高，中部更弱，形成U形曲线，并分别用首因偏置和近因偏置解释两端优势；文章也强调这是倾向而非严格保证，某些模型在部分任务上各位置表现都不错。
对于原因，文章归到transformer的注意力机制：因果掩码让靠前token有更多路径影响后续表示，靠后内容则靠近即将生成的答案；但作者也提醒，允许被注意不等于实际获得高权重，中部并未被掩码直接遮蔽，问题在于信息在网络中如何被表示和组合。
文章称更大的上下文窗口只提升容量，不保证每个位置同样可用，区分“最大上下文”与“有效上下文”；并引用RULER基准称其原版评测 17 个模型、在输入变长时普遍出现性能下降，但该基准明确按输入长度报告分数、未控制证据位置。
作者给出的缓解做法包括：把任务、约束和问题放在易识别位置，用Markdown标题或XML标签分隔内容，精简与任务无关的上下文，以及用RAG先检索相关段落；同时指出这些方法不能消除中间偏置，重复整个提示词会增加长度且可能引入矛盾，检索也可能漏掉必要例外。
ByteByteGo发布文章《The LLM Blindspot: Why Models Forget What’s in the Middle of Your Prompt》，讨论大语言模型的“lost in the middle”现象：当同一信息被放在长提示词的中部时，模型更可能没有把它用于回答。
文章用编程助手举例：一批项目文档中有一段写明审计日志必须保留 37 天，助手却写出 30 天后删除日志的清理函数。作者称该规则明确写在提示词里、也符合模型上下文限制，但位于中部，因而被忽略。
“中间遗忘”指的是哪一种失败
文章把类似的外部表现分成几种：应用根本没有发送某份文档或信息；应用截断对话、删掉了包含答案的早期消息；检索系统选错段落；以及正确段落已在输入中、模型却没有用它生成答案。作者说，“中间遗忘”只指最后一种：信息在输入里，但其位置影响了它是否成功参与回答。
- 应用没有发送相关信息
- 截断对话删除早期答案
- 检索系统选错段落
- 信息已在输入中，模型未使用
位置如何影响准确率
文章称，可以通过保持问题和支撑信息不变、只改变支撑信息在输入中的位置来做测试。它举了“Project Cedar的所有者是Adam”这一例子：相关信息分别出现在提示词最前、中间和最后，其他笔记不变；如果准确率明显变化，说明模型对证据出现的位置敏感。
作者引用 2023 年发布、2024 年发表的“Lost in the Middle”研究称，模型表现通常在开头和结尾附近最强，中部较弱，形成U形准确率曲线：开头高与首因偏置相关，结尾高与近因偏置相关，中部则较低。文章同时说明，这些是倾向而不是严格保证，开头和结尾也可能答错，某些模型在特定任务的各个位置都可能表现良好。
- 开头附近：文章称准确率通常更高，归因于首因偏置
- 结尾附近：文章称准确率通常也更高，归因于近因偏置
- 中部附近：文章称准确率较低
- 文章强调这是倾向，具体取决于模型和任务
注意力机制与因果掩码
文章把原因追溯到transformer的注意力机制。注意力让模型计算输入不同位置的信息应以多大权重贡献到当前表示；生成式模型用因果掩码阻止关注未来位置。文章说，在一个 6 token的提示词里，第 1 个token的信息可以影响第 2 到第 6 个token的表示，而第 4 个token不能影响第 1 到第 3 个token的表示；经过多层处理后，靠前信息有更多路径影响后续计算。
文章同时指出，提示词末尾有另一种优势：它离实际问题和答案更近，许多模型的注意力模式偏好相邻关系。作者也给出两点限定：允许被注意不代表实际获得高注意力权重，模型并没有一个持续累积的逐token重要性分数；在生成答案时，标准全因果注意力可以访问包括中部在内的所有更早提示位置，因此中部并未被因果掩码直接遮蔽，问题在于信息在网络中如何被表示和组合。
- 因果掩码让早期token能影响更多后续表示
- 末尾内容靠近问题和答案，可能更易被利用
- 允许关注不等于实际获得高权重
- 中部没有被因果掩码直接隐藏
更大的上下文窗口意味着什么
文章区分“最大上下文大小”和“有效上下文大小”：前者是模型支持的整体输入规模，后者是应用在保持可接受表现时实际能使用的上下文量。作者称，有效上下文取决于任务，比如在文档中找一个独特标识符，与比较多份文档、解决矛盾或跟踪长对话中的变化并不相同。
文章提到RULER基准：原版评测 17 个模型，任务不止简单检索，还包括沿信息链追踪和聚合结果，发现输入长度增加时性能普遍下降；但论文明确说明按输入长度报告分数，没有控制和报告证据位置。
- 最大上下文指支持的总输入规模
- 有效上下文指应用可实际使用并保持表现的规模
- 有效上下文随任务变化
- RULER原版按长度报告分数，未控制证据位置
文章建议的缓解做法
文章说，很难完全消除模型对中部信息的偏置，但可以通过一些做法减轻。提示词组织上，应让任务、关键约束和最终问题容易识别，不要把重要信息埋在大段无关材料里；用Markdown标题、文档标签或XML风格标签区分指令和源材料，减少输入结构的歧义。作者提醒，加标签不会改变注意力掩码，也不保证模型遵守。
- 把任务、约束和问题放在容易识别的位置
- 用标题、标签或XML标签标明内容边界
- 减少不必要上下文，而不是机械设定token上限
- 保留回答所需的证据和例外，摘要不能替代精确信息
检索与精简的边界
文章建议通过检索增强生成（RAG）先选出可能相关的材料，让应用承担找证据的责任，而不是总把整个集合放进提示词。它举了支持类应用处理webhook重试问题的例子：系统可以先取回重试策略、相关配置文档和适用例外，再让模型基于这个小集合回答。
作者也列出RAG的限制：检索仍可能漏掉相关段落，取回的片段可能缺少必要例外，取回太多段落又会重新造成原始问题。文章称，检索材料仍需合理选择、排序和评估；精简上下文同样困难，删掉异常、依赖或早期决定会让提示词更短但更不准确。
- RAG先用关键词、数据库查询或语义搜索选材料
- 应用负责找证据，而不是总把全部内容塞进提示词
- 检索可能漏掉相关或必要例外的内容
- 取回过多段落会重现“中间遗忘”问题
- 摘要可能省略细节，精确信息不能只靠摘要