上下文中段丢失 | 上下文与 RAG | 做产品

上下文中段丢失

上下文窗口不是一块均匀的画布。同样一句话，**放在开头或结尾，和埋在中间，被模型用上的概率差别很大。**而且上下文越长，差别越明显。

你会遇到的现象

如果把「这条信息被正确用上的概率」画出来，形状大致就是那张图：一条 U 形曲线，两端高、中间塌。

这个现象在业内被反复观察到，通常叫「中段丢失」（lost in the middle）。它不是某一家模型的 bug，是目前这类模型比较普遍的特性。虽然新模型在持续改善，但趋势依然存在。

关键的一点是：**它随长度恶化。**上下文只有几千 Token 时，这个坑很浅，你基本感觉不到；塞到几万、几十万 Token，坑就深得能吞掉整段关键信息。

不讲数学，讲直觉。

模型在预测下一个词时，要「回看」前面所有内容并决定各部分的权重。这个分配是学出来的，而训练语料里的文本有个很强的规律：开头通常是主题和设定，结尾通常是结论和当前焦点，中间是展开和铺垫。

模型于是学到了这个先验——两端更值得重视。加上内容一多，注意力被摊薄，中间那些「铺垫性」的部分自然最先被牺牲。

这也解释了为什么结构化写法有帮助：明确的小标题相当于给中段的内容重新贴上「这是一个新章节」的标记，能部分对抗被淹没的趋势。

三种最常见的表现，认出来就能对症下药。

**一、长提示词里的限制失效。**你在一段很长的提示词中间写了「不要提及价格」，它照样提了。不是它不听话，是那句话在那个位置权重太低。

**二、RAG 塞多了反而更差。**为了保证不漏，很多人把召回数量调到十几二十段。结果中间那些段几乎没被用上，而且其中夹杂的不相关内容还会干扰判断。召回 5 段准确的，通常胜过召回 20 段良莠不齐的。

**三、长对话中期的设定漂移。**聊到二三十轮，早期的约定既不在开头（被更早的系统提示占了），也不在结尾，正好落在最容易被忽略的位置。表现就是它慢慢不像你们的产品了。

**一、重要的东西放两头。**最直接的一招。系统提示放最前，本次任务的关键指令和验收标准放在最后——紧贴用户输入的位置。四个部件那一节建议把限制和验收压在末尾，就是这个原因。

**二、关键约束重复一次。**如果一条限制绝对不能违反，在开头写一遍、在结尾再强调一遍。重复要花 Token，但比失效强得多。

**三、少塞，别多塞。**宁可召回 5 段精准的，不要 20 段掺水的。重排那一步存在的意义就在这——它让你能只送进去最相关的几段。

**四、长任务要拆。**如果一次任务需要模型同时消化几十页材料，与其一股脑塞进去，不如拆成几轮：先让它逐段提取要点，再基于这些要点做综合。每一轮的上下文都短，中段丢失就不成问题。

最后一句：**长窗口是能力，不是许可。**模型支持 100 万 Token，不代表你就该塞满它。装进去多少，和它真正能用上多少，是两条不同的曲线。

召回 20 段，为了「不漏」

绿色是真被用上的，红色是掺进来的干扰中间那一大片灰的几乎没被看见，还白付了钱

召回 5 段精准的

全部落在两端的高注意力区重排那一步存在的意义就在这里

长任务要拆

一次塞几十页 → 中段必然丢失

先逐段提要点，再基于要点综合——每轮都短

长窗口是能力，不是许可。装进去多少，和它真正能用上多少，是两条不同的曲线。

为了保证不漏而把召回数量调到十几二十段，是最常见的反向优化：**中间那些段几乎没被用上，夹杂的不相关内容还会干扰判断。**召回 5 段准确的，通常胜过召回 20 段良莠不齐的。

对话压缩历史太长时怎么处理，以及压缩会丢掉什么。

上下文窗口台面有多大，以及超出时会发生什么。

上下文预算该给什么、不该给什么，比给得多重要。