先记住这个答案
现有观察表明，语言模型处理长上下文时，对输入中段信息的记忆和利用往往不如开头和结尾，具体原因可能与训练数据分布、注意力机制和任务类型有关，不同模型表现不一。实践上，将关键指令放在系统提示或用户消息末尾，重要资料放在提示词开头或结尾，避免埋在中间，可有效提升信息被利用的概率。
- 中间位置召回率低是常见位置偏置
- 关键内容放开头或结尾可减少丢失
- 长语境下应主动截断或重排输入
位置偏置如何导致中部遗忘
语言模型在长序列任务中常常对输入中段的信息利用不足。可能原因包括模型训练时上下文长度有限、注意力机制更偏好局部与邻近内容，以及解码过程中对近因信息的依赖。但这并非仅由位置编码决定，不同模型表现也存在差异。中段信息如果缺乏结构化引导，容易被模型忽略。
实验与用户反馈都显示，当关键内容位于输入中段时，模型准确率往往会下降。这一现象与上下文内干扰、任务类型以及模型对远端信息的整合能力有关。末尾信息因为靠近当前生成位置，常被优先引用，但该效应并非由位置编码单独决定。
一个RAG问答中的证据排布场景
假设客服系统需要从5份手册（约8000 token）中定位退款规则。输入按顺序拼接，中间一份文档恰好包含退款条件。起初模型错误地回答了流程，忽略该规则。随后改成将最可能的文档片段裁剪后置于用户问题之前，并在系统提示中说明“优先参考刚插入的文档”，模型便能正确引用规则。
处理手段是先用检索器粗筛，再将高相关证据放在提示词顶部或底部，中间只放支撑性材料。若检索仍无法确定位置，就显式要求模型逐条引用证据再输出结论。这种重排没有改变模型权重，但改变了注意力分配的对象，是工程上最直接的缓解方法。
边界条件：重排并非万能
当上下文长度超过模型有效压缩能力（如10万token以上），即使证据在开头或结尾，模型也可能因整体信息过载而忽略。此时位置偏置依然存在，但更根本的限制是模型无法对所有token保持相等表征，需采用摘要、滑动窗口或记忆机制主动缩减上下文。
另一种失效场景是多个关键事实互相依赖，需要从不同位置同时引用。此时简单重排打散了全局顺序，反而可能导致推理错乱。对策是使用结构化提示，如给每个片段编号并让模型在输出中引用编号，或者将推理步骤拆解为多次调用。代价是增加延迟与token消耗，但准确率收益更大。
容易答错的地方
- 认为加大上下文窗口就不需要裁剪
- 窗口加大只是允许更多输入，并不增强对中段的记忆。只要超过数千token，中部位置仍会丢失信息，盲目堆料反而增加成本。应该主动裁剪和重排，使高价值内容处于显眼位置。
- 把关键内容放在正中间并期望模型抓住
- 有些开发者为了保持顺序，把最重要的结论放在长文档中段，结果常被忽略。正确做法是将核心结论前置或后置，或额外让模型先输出对证据的定位。位置偏置不是纯粹概率问题，而是可观测的系统性偏差，必须用结构去对抗。
面试官还会怎么问？
为什么开头和结尾信息保留得更好？
尚无统一理论解释，但实验显示两端内容往往更容易被模型提取。一种常见解释是开头信息常作为任务设定的基础，结尾信息则最晚进入上下文，可能与当前生成目标联系更直接；中间内容需要在更复杂的注意力路径中被整合。具体机制仍需进一步研究。
在API调用中如何利用这一现象写提示词？
把关键指令塞进system prompt或最后一句用户消息，将参考文档按相关度降序放在开头附近，并在需要引用的地方显式要求“从文档A中找依据”。避免所有内容平铺，用层次化结构制造注意力锚点。
模型有“多个关键点”时，重排会相互干扰吗？
会。如果两个前提分别位于两端，模型需要跨越长距离建立联系，可能无法同时保持。可以用链式提示，先让模型分别提取每个点，再综合回答，或者使用JSON模式强制结构化输出，降低跨位置关联的负担。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。