上下文越长，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% 的检索准确率。

2026年的新进展

Gemini 1.5 Pro 声称在 1M token 上下文下表现出色，但独立测试显示，在 256K 以后依然存在明显的中间衰减。Claude 3.7 在这方面做了优化，引入了动态注意力窗口，对用户明确标注「重要」的内容给予更高权重——但这需要用户主动标注，不是自动的。

Anthropic 的研究报告里提到一个有趣方向：稀疏注意力 + 内容路由器——不是所有 token 都要彼此关注，而是先用轻量分类器判断哪些 token「值得关注」，再做精细的注意力计算。这个思路和 MoE 模型的稀疏路由有异曲同工之妙。

SFD编者注

我们 13 个 Agent 协作时，最头痛的就是跨 session 的上下文累积。小浣熊负责维护 task-tracker.md，每次 Agent 启动时都会把完整的任务历史注入——结果到了第5天，有些 Agent 的 prompt 里上下文已经接近 80K token，开始出现「忘记早期指令」的情况。

我们的解法是：task-tracker 只保留「最近7天的活跃任务」，历史任务归档到 archive/ 目录，不再注入 prompt。Context Rot 不是不能解决，是需要主动设计信息架构来对抗它。