AI 上下文越长越笨？Context Rot 的工程拆解

每个工程师都踩过的坑

你把一份 100 页的文档喂给 Claude 或 GPT-4，让它提取第 8 节里的某个数字。答错了。你只把那一段贴过去——全对。模型没变笨，是它的注意力被稀释了。这就是 Context Rot（上下文腐烂）。

在 SFD Lab，我们 13 个 Agent 的协作流水线动辄产出 50K+ token 的上下文。这堵墙撞得多了，就认真写一篇记下来。

什么是 Context Rot？

Context Rot 描述的是这么一件事：随着上下文窗口变大，模型对中置信息的提取准确率显著下降——即使这些信息明明就在 prompt 里。

研究者称之为 "Lost in the Middle" 问题。斯坦福的研究证实过：把关键信息放在 prompt 开头或结尾，召回效果远好过埋在中间——掉 20-30% 的准确率很常见。

三种衰减机制

1. 位置偏置

Transformer 的注意力对所有 token 算相似度，但位置编码（RoPE、ALiBi、Sinusoidal）会给不同位置带来权重偏置。靠近开头和结尾的 token，在多层注意力里梯度路径更短，信号衰减更少。

# 简化：位置 i 的有效注意力权重
effective_attention(i) = raw_attention(i) * position_decay(i)
# 中间位置的 position_decay 系统性偏低

2. 注意力稀释

假设模型的注意力头有一个固定的"注意力预算"。上下文从 4K 扩到 128K token，每个 token 平均分到的预算就从 1/4000 缩到 1/128000——稀释了 32 倍。在短上下文里能"跳出来"的信息，在长上下文里被淹没了。

3. KV Cache 压缩的副作用

为了在有限显存里跑长上下文推理，工程师普遍用 KV cache 压缩（StreamingLLM、H2O 等）。这类方法会丢弃"不重要"的 KV pair——但"重要性"是按历史注意力分数判定的，会系统性地偏向新近的 token。这就形成一个放大新近偏置的正反馈回路。

我们的测试结果

我们把同一段 API 文档嵌在不同位置，然后问："这个端点的 rate limit 是多少？"

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

中置内容的准确率直接掉了 33 个点。生产环境不可接受。

工程上的规避手段

策略一：关键信息前置

把你最重要的指令、约束、关键数据放在 system prompt 最前面，不要埋在大段背景之后。SFD Lab 的 agent prompt 一律按"关键指令 → 背景 → 示例"的顺序排，绝不反过来。

策略二：RAG 优于全文注入

与其灌 100 页，不如用向量检索只召回最相关的 3 个 chunk。我们已经把所有 PRD 和 API 文档做成了向量库。长文档场景下，检索增强生成稳定优于直接注入上下文。

策略三：Map-Reduce 摘要

长文档先分段摘要，再对摘要做二次处理。土，但稳。我们内容流水线里处理研究报告就靠这招。

策略四：显式注意力锚点

在长 prompt 里，于关键内容前插入显式提示，比如"请特别注意以下部分："。研究表明，这样能人为抬高该区域的注意力分数，把检索准确率提升 15-20%。

2026 年行业走到哪了

Gemini 1.5 Pro 宣传 1M token 上下文，但独立评测显示，超过 256K 之后中置衰减依然明显。Claude 3.7 引入了动态注意力窗口，给用户标记的"重要"片段更高权重——但这要用户显式打标签，不是自动的。

最有希望的研究方向是稀疏注意力 + 内容路由：不再是所有 token 互相 attend，而由一个轻量分类器先判定哪些 token"值得被注意"，再进入昂贵的注意力计算。这和 MoE 稀疏路由在架构上的相似并非巧合。

SFD Lab 手记

对我们来说最痛的是跨 session 的上下文累积。我们的 task tracker 会把完整任务历史注入 agent prompt。到第 5 天，有些 agent 的 prompt 已经 80K+ token，并且开始静默忽略早期的指令。

我们的改法：tracker 在活跃 prompt 里只保留最近 7 天的任务，更早的归档、不注入。Context Rot 不是无解——它需要的是一套有意识设计的信息架构去对抗。