上下文越长，AI 越笨？Context Rot 现象工程拆解

一个让工程师头疼的现象

你有没有发现：当你给 Claude 或 GPT-4 喂了一篇超长文档，要求它"总结第 8 节的关键数据"——它给你的答案往往不如短文档准确？不是模型变笨了，而是它的注意力被稀释了。这就是所谓的 Context Rot（上下文腐烂）。

我们在 SFD 实验室里跑了大量长上下文任务，13 个 Agent 协作时产生的上下文动辄几万 token，这个问题踩了很多次坑，今天拆解清楚。

什么是 Context Rot？

Context Rot 不是官方术语，但工程师群体里已经在使用。它描述的是这个现象：

随着上下文窗口中 token 数量增加，模型对中间位置信息的提取能力显著下降，即使这些信息明确存在于 prompt 中。

研究者把这称为 "Lost in the Middle" 问题，斯坦福的论文在 2023 年就验证过：把关键信息放在 prompt 开头或结尾，模型表现好得多；放在中间，准确率可以下降 20-30%。

三种衰减机制

1. 位置偏置（positional bias）

Transformer 的注意力机制本质上是对所有 token 做相似度计算，但位置编码（RoPE / ALiBi / Sinusoidal）会给不同位置的 token 加上权重偏差。越靠近开头和结尾的 token，在多层注意力传递中梯度路径更短，信号衰减更少。

# 简化示意：位置 i 的有效注意力权重
effective_attention(i) = raw_attention(i) * position_decay(i)
# 中间位置的 position_decay 往往小于边缘位置

2. 注意力稀释（attention dilution）

假设一个模型的注意力头有固定的"总注意力预算"。当上下文从 4K 扩展到 128K token，每个 token 分到的平均注意力权重就从 1/4000 降到 1/128000——稀释了 32 倍。那些在短上下文里能被"高亮"的关键信息，在长上下文里就被淹没了。

3. KV Cache 压缩的副作用

为了让长上下文推理在有限显存里跑通，工程师普遍使用 KV Cache 压缩技术（如 StreamingLLM、H2O）。这些方法会丢弃"不重要"的 KV 对——但"重要性"是根据过去的注意力分数判断的，会系统性地偏向最近的 token，形成正反馈偏差。

实测数据：中间位置的代价

我们做了一个简单测试：把同一份 API 文档嵌入不同位置，问模型"这个接口的 rate limit 是多少"：

| 信息位置     | 正确率 | 平均延迟 |
|-------------|--------|----------|
| 前 10%       |  94%   |  1.2s    |
| 中间 40-60%  |  61%   |  1.8s    |
| 后 10%       |  89%   |  1.3s    |

中间位置的正确率直接跌了 33 个百分点。这在生产环境里是不可接受的。

工程规避方案

方案一：关键信息前置

把最重要的指令、约束、关键数据放在 system prompt 的最前面，而不是埋在大段背景信息后面。SFD 实验室的 Agent 提示词现在都遵循"关键指令 → 背景信息 → 示例"的顺序，而不是反过来。

方案二：RAG 代替长上下文

与其把 100 页文档全塞进去，不如用向量检索只取相关段落。我们在处理 SFD 项目文档时，把 PRD / API 文档做成向量库，每次只取 top-3 相关块，效果比直接喂全文好很多。

方案三：分段摘要（map-reduce）

长文档先分段摘要，再对摘要做二次处理。这是最朴素但最稳健的方法，在我们的内容生产流程里用于处理研究报告。

方案四：显式路标（explicit anchors）

在超长 prompt 里，每隔一段插入显式引用："以下是你需要重点关注的信息："。这类"注意力锚"能拉高模型对该段的注意力分数。有研究表明这能提升 15-20% 的检索准确率。

SFD 编者注

我们 13 个 Agent 协作时，最头疼的就是跨 session 的上下文累积。解法是：task-tracker 只保留"最近 7 天的活跃任务"，历史任务归档到 archive/ 目录，不再注入 prompt。Context Rot 不是不能解决，是需要主动设计信息架构来对抗它。