它明明读完了几万字，为什么关键信息还是漏了：lost in the middle

你大概见过这种场景：把一份 30 页的需求文档整个喂给大模型，让它总结并列出验收标准。它洋洋洒洒回你一页，结构漂亮，语料库里的术语一个不少——但恰好漏掉了第 14 页那句"退款必须在订单创建后 48 小时内发起"。

更扎心的是：参数更大的模型并不一定更靠谱。2023 年斯坦福论文 Lost in the Middle 测过一批当时主流的开源模型，把关键信息放在长文档的不同位置，看它检索回来的准确率。结果是熟悉的 U 形曲线：信息在开头或结尾，答对的概率明显更高；放在正中间，准确率掉一截，有些模型直接腰斩。后面的长文本模型把这个 U 形拉平了大半，但至今没有完全抹平。

原因可以直接写在推理引擎里，而不是抛给玄学。

第一，注意力分布不均匀。Transformer 生成第 n 个 token 时，KV cache 里存着前面所有位置，每个位置都参与 softmax 归一化。上下文越长，总注意力份额被摊得越薄，加上位置编码对远离生成位置的 token 天然不友好，中间的 chunk 实际分到的注意力权重就是个偏低值。信息还在 KV cache 里，但它"不够响"。

第二，训练分布和真实用法错位。论文里有个干净的控制实验：同一批第 k 个事实，让模型闭卷直接回答 k 是多少，准确率掉得很少；一旦换成开卷——把它放进一篇更长的文章里再问——准确率明显下滑。也就是说，它不是"记不住第 40 个事实"，而是"知道第 40 个事实，但在一堆无关上下文里不知道该看哪一个"。长文本能力训练里，有效信息基本都堆在文档两端，中间位置在预训练语料里就是垃圾堆，模型学到了"去两头找"的性价比，而不是均匀检索。

这件事对生产系统有三个直接落点。

一，别把关键要求埋在中段。长 system prompt 里的硬性约束（输出格式、红线、必须引用的数据），放开头或放结尾，中间留给背景资料。这是零成本改动，却直接对着机制来的。

二，能拆就别硬塞。文档可以先切片、做向量检索，只把 top-k 相关段落连同页码塞进上下文。检索不完美，但相关段落通常不超过几千 token，此时模型实际面对的还是"短文档"，lost in the middle 的折损基本消失。工程上这叫 RAG，但它的本体不是"省 token"，而是改写信息的位置分布。

三，把提示词和素材分层。任务指令、约束、例子是一类应紧贴生成位置的信息；事实素材是另一类。前者无论多短都放首尾，后者再长也让给检索管。很多"模型不听话"的 bug，最后发现不是它能力不行，是它的指令在 50 段资料的第 38 段。想确认自己有没有踩中这条曲线，方法很土：从那份长文档里抽出 10 条硬性要求，人工标注它们在原文的分位（前 1/4、中间半区、后 1/4），让模型逐条复述，按位置分桶统计漏答率。如果中间桶的漏答率显著高于两端，说明你喂进去的材料结构和模型的位置偏好是反向的，重排再跑一次就能对出结论。

窗口 size 是它"能塞多少"，检索和布局决定的是"塞进去之后还能不能用"。前者是硬件指标，后者是工程问题，而生产环境里翻车的大多发生在后者。

下一篇会讲注意力分布为什么对尾部更偏心，以及 sliding window attention 为什么会让长对话的状态悄悄漂移。