上下文中段失焦

注意力不是均匀铺在整段上下文上的：两端读得最可靠，中间随长度增加逐渐失焦。所以位置是一个设计决定。

上下文不是一块均匀的画布。同一句话，摆在开头或者结尾，与埋在中间相比，被模型用上的概率相差很大，而且上下文越长，这个差距越明显。既然模型不会均匀地读，位置就得由你来安排。lost-in-middle

读完你能回答：

• 为什么写在长提示词中间的约束经常失效？
• 为什么多塞几段资料反而让答案更差？
• 哪些内容该放开头，哪些必须放结尾？
• 什么样的长任务不受这个效应影响？

位置是一种权重

画一条曲线：横轴是一条信息在上下文里的位置，纵轴是它被正确用上的概率。两端高，中间塌下去，形状接近一个 U。这不是某一家厂商留下的缺陷，而是这类模型身上相当普遍的规律——新一代模型一直在改善，规律本身还没消失。

中段被漏掉的可能，和长度直接相关：上下文只有几千 token 的时候，这个凹陷浅到几乎察觉不到；推到几万甚至几十万 token，它就能深到把一整段关键信息盖掉。所以「窗口变大」这件事，同时也把受它影响的面积撑大了。

这条曲线从哪来

模型每预测下一个词，都要回头扫一遍前面的全部内容，并决定给各部分多少权重，这套分配方式是学出来的。而它学过的文本里有一条极强的规律：一篇文章往往把主题和设定摆在开头，把结论和当下焦点摆在结尾，中间留给展开和铺垫。 于是模型把这条规律带成了先验——两端的分量更重。再叠上内容变多以后注意力被摊薄，位于中段、性质上又属于「铺垫」的那些部分，就最先被牺牲掉。

结构化写法之所以管用，答案也在这里：给中段加上明确的小标题，等于把那部分内容重新标注成「这里开始是新的一节」，多少能抵消它被淹没的倾向。把提示词拆成几块有效，一部分功劳就在这里。

承重的约束，放两头

机制落到设计上其实只有一句话：如果一条约束被漏掉，这次回答就作废了，那它不该出现在中间。

按这条标准分位置：

• 开头放全局的、跨轮次不变的。角色设定、产品口径、长期规则。这些内容每一轮都要读到，放开头最稳。
• 结尾放本次的、最不能违反的。这次任务的具体要求、验收标准、输出格式。紧贴用户输入的位置是第二个高注意力区。
• 中间放可牺牲的。展开、示例、背景、成堆的参考资料。默认假设是：中间的东西可能只被读到一部分。

反面例子最好记：把「不要在回答里出现竞品的名字」写在长提示词的中段，它照样会写出来。这不是它不听话，而是那句话摆在那里的分量太低。

还有一招可以当补丁用：关键约束说两遍。有哪条限制绝对不能破，开头交代一次，结尾再强调一次。多花一遍 token，比起它失效的代价，这笔账划算。

少塞几段，比多塞更准

为了不漏，很多人把召回数量往上调。结果与预期相反：

• 中间那些段几乎没被用上，等于白花 token；
• 夹杂的不相关内容还会干扰判断——相似度不高的段落进入上下文后，会和中段的正确段落争夺注意力；
• 材料越长，正确那一段越可能落在中间，被漏掉的概率越高。

只送几段确实对得上的资料，比铺开几十段良莠不齐的更准。这不是省钱的建议，是准确率的建议。这也正是重排那一步存在的意义：它让你能把最相关的几段送进去，而不是把召回的上限全塞进去。

同一条机制还有一种更隐蔽的表现：对话进行到中期，早期约定的那些规矩离两头都远——开头的位置被系统提示占着，结尾紧贴用户刚说的话——它们于是待在了关注最弱的那一段。表现出来就是它渐渐不像你们的产品了。

容量归窗口，注意力不归它

长窗口是一项能力，不等于一张许可证。能装进去多少，和真正能用上多少，是两条各自独立的曲线。容量由窗口给你，注意力由位置决定——前者你控制得了，后者只能顺着它的规律去摆。

最彻底的一招是绕开机制本身：一个任务如果要模型同时消化几十页材料，别一次全塞进去，改成几轮来做——先逐段把要点提出来，再拿这些要点做综合。每一轮上下文都不长，中段失焦自然无从发生。

而当对话本身很长时，问题会从「哪一段被忽略」升级成「哪一段已经不在上下文里了」。那是压缩那一节要处理的。落到多步任务的循环上，上下文还会随步骤累积噪音，上下文是怎么变脏的讲的是这条线。