# Context Degradation

> 语言模型随上下文长度增加表现出可预测的退化模式。理解这些模式对于诊断故障和设计弹性系统至关重要。

- Skill: `kscz0000/context-degradation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/context-degradation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/context-degradation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/context-degradation

---


# 上下文退化模式

语言模型随上下文长度增加表现出可预测的退化模式。理解这些模式对于诊断故障和设计弹性系统至关重要。上下文退化不是二元状态，而是性能退化的连续体，以多种不同方式表现出来。

## 何时使用

在以下情况激活此技能：
- 智能体在长对话中性能意外下降
- 调试智能体产生错误或无关输出的情况
- 设计必须可靠处理大上下文的系统
- 评估生产系统的上下文工程选择
- 调查智能体输出中的"中间丢失"现象
- 分析智能体行为中与上下文相关的故障

## 核心概念

上下文退化通过几种不同的模式表现出来。中间丢失现象导致上下文中间的信息获得较少的注意力。上下文污染发生在错误通过重复引用而累积时。上下文干扰发生在无关信息淹没相关内容时。上下文混淆出现在模型无法确定哪个上下文适用时。上下文冲突在累积的信息直接矛盾时产生。

这些模式是可预测的，可以通过压缩、掩码、分区和隔离等架构模式来缓解。

## 详细主题

### 中间丢失现象

最 documented 的退化模式是"中间丢失"效应，模型表现出 U 形注意力曲线。上下文开头和结尾的信息获得可靠的注意力，而埋在中间的信息遭受召回准确率的大幅下降。

**实证证据**
研究表明，放在上下文中间的相关信息比开头或结尾的相同信息召回准确率低 10-40%。这不是模型的故障，而是注意力机制和训练数据分布的结果。

模型将大量注意力分配给第一个 token（通常是 BOS token）以稳定内部状态。这创建了一个"注意力汇"，吸收了注意力预算。随着上下文增长，有限的预算被拉伸得更薄，中间 token 无法获得足够的注意力权重以实现可靠检索。

**实践意义**
设计上下文放置时要考虑注意力模式。将关键信息放在上下文的开头或结尾。考虑信息是否会被直接查询还是需要支持推理——如果是后者，放置位置不那么重要，但整体信号质量更重要。

对于长文档或对话，使用摘要结构在注意力优势位置呈现关键信息。使用明确的章节标题和过渡来帮助模型导航结构。

### 上下文污染

上下文污染发生在幻觉、错误或不正确信息进入上下文并通过重复引用而累积时。一旦被污染，上下文会创建强化错误信念的反馈循环。

**污染如何发生**
污染通常通过三条路径进入。首先，工具输出可能包含错误或意外格式，模型将其作为基本事实接受。其次，检索到的文档可能包含错误或过时信息，模型将其纳入推理。第三，模型生成的摘要或中间输出可能引入持续存在于上下文中的幻觉。

累积效应是严重的。如果智能体的目标部分被污染，它会发展出需要大量努力才能撤销的策略。每个后续决策都引用被污染的内容，强化错误的假设。

**检测与恢复**
观察症状，包括以前成功的任务输出质量下降、工具错位（智能体调用错误的工具或参数），以及尽管尝试纠正仍持续的幻觉。当这些症状出现时，考虑上下文污染。

恢复需要删除或替换被污染的内容。这可能涉及将上下文截断到污染点之前、在上下文中明确标记污染并请求重新评估，或使用干净的上下文重新开始并仅保留已验证的信息。

### 上下文干扰

上下文干扰出现在上下文增长到如此之长，以至于模型过度关注提供的信息，而牺牲了其训练知识。模型关注上下文中的所有内容，无论相关性如何，这产生了使用提供的信息的压力，即使内部知识更准确。

**干扰效应**
研究表明，即使上下文中只有一个无关文档也会降低涉及相关文档的任务性能。多个干扰因素会加剧退化。这种效应不是关于绝对意义上的噪音，而是关于注意力分配——无关信息与相关信息竞争有限的注意力预算。

模型没有机制来"跳过"无关上下文。它们必须关注提供的所有内容，这种义务产生了干扰，即使无关信息明显没有用处。

**缓解策略**
通过仔细筛选进入上下文的内容来缓解干扰。在加载检索到的文档之前应用相关性过滤。使用命名空间和组织结构使无关部分在结构上易于忽略。考虑信息是否真的需要在上下文中，还是可以通过工具调用访问。

### 上下文混淆

上下文混淆出现在无关信息以降低质量的方式影响响应时。这与干扰相关但不同——混淆关注上下文对模型行为的影响，而不是注意力分配。

如果你在上下文中放入某些内容，模型就必须关注它。模型可能会纳入无关信息、使用不适当的工具定义，或应用来自不同上下文的约束。当上下文包含多种任务类型或在单个会话中切换任务时，混淆尤其成问题。

**混淆的迹象**
观察解决查询错误方面的响应、似乎适合不同任务的工具调用，或混合来自多个来源要求的输出。这些表明对当前情况适用哪个上下文存在混淆。

**架构解决方案**
架构解决方案包括明确的任务分段（不同任务获得不同的上下文窗口）、任务上下文之间的清晰过渡，以及隔离不同目标上下文的状态管理。

### 上下文冲突

上下文冲突在累积的信息直接矛盾时产生，创建破坏推理的矛盾指导。这与污染不同，污染是一个信息片段不正确——在冲突中，多个正确的信息片段相互矛盾。

**冲突来源**
冲突通常来自多源检索（不同来源有矛盾信息）、版本冲突（过时和当前信息都出现在上下文中），以及观点冲突（不同观点有效但不兼容）。

**解决方法**
解决方法包括明确标记冲突（识别矛盾并请求澄清）、优先级规则（确定哪个来源优先），以及版本过滤（从上下文中排除过时信息）。

### 实证基准与阈值

研究提供了关于退化模式的具体数据，为设计决策提供依据。

**RULER 基准发现**
RULER 基准给出了令人警醒的发现：声称支持 32K+ 上下文的模型中，只有 50% 在 32K tokens 时保持令人满意的性能。GPT-5.2 在当前模型中表现出最少的退化，而许多模型在扩展上下文中仍然下降 30+ 分。在简单的大海捞针测试中的近乎完美的分数并不能转化为真正的长上下文理解能力。

**模型特定的退化阈值**
| 模型 | 退化起始 | 严重退化 | 备注 |
|------|----------|----------|------|
| GPT-5.2 | ~64K tokens | ~200K tokens | 在 thinking 模式下具有最佳的整体退化抗性 |
| Claude Opus 4.5 | ~100K tokens | ~180K tokens | 200K 上下文窗口，强大的注意力管理 |
| Claude Sonnet 4.5 | ~80K tokens | ~150K tokens | 针对智能体和编码任务优化 |
| Gemini 3 Pro | ~500K tokens | ~800K tokens | 1M 上下文窗口，原生多模态 |
| Gemini 3 Flash | ~300K tokens | ~600K tokens | Gemini 2.5 的 3 倍速度，81.2% MMMU-Pro |

**模型特定的行为模式**
不同模型在上下文压力下表现出不同的故障模式：

- **Claude 4.5 系列**：最低的幻觉率和校准的不确定性。Claude Opus 4.5 在 SWE-bench Verified 上达到 80.9%。倾向于拒绝或请求澄清而不是编造。
- **GPT-5.2**：两种模式可用 - instant（快速）和 thinking（推理）。Thinking 模式通过逐步验证减少幻觉，但增加延迟。
- **Gemini 3 Pro/Flash**：原生多模态，1M 上下文窗口。Gemini 3 Flash 比上一代快 3 倍。在跨文本、代码、图像、音频和视频的多模态推理方面表现强劲。

这些模式为不同用例的模型选择提供依据。高风险任务受益于 Claude 4.5 的保守方法或 GPT-5.2 的 thinking 模式；速度关键的任务可以使用 instant 模式。

### 反直觉发现

研究揭示了几个挑战上下文管理假设的反直觉模式。

**打乱的 Haystack 优于连贯的 Haystack**
研究发现，打乱（不连贯）的 haystack 比逻辑连贯的产生更好的性能。这表明连贯的上下文可能创建混淆检索的虚假关联，而不连贯的上下文迫使模型依赖精确匹配。

**单个干扰因素有巨大影响**
即使单个无关文档也会显著降低性能。这种效应与噪音量不成比例，而是遵循阶跃函数，任何干扰因素的存在都会触发退化。

**Needle-Question 相似性相关性**
needle 和 question 对之间的相似性越低，随上下文长度的退化越快。需要跨不相似内容进行推理的任务特别脆弱。

### 更大的上下文何时有害

更大的上下文窗口并不统一改善性能。在许多情况下，更大的上下文会产生超过收益的新问题。

**性能退化曲线**
模型随上下文长度表现出非线性退化。性能在阈值之前保持稳定，然后迅速退化。阈值因模型和任务复杂性而异。对于许多模型，即使上下文窗口支持更大的大小，有意义的退化也在大约 8,000-16,000 tokens 开始。

**成本影响**
处理成本随上下文长度不成比例地增长。处理 400K token 上下文的成本不是 200K 的两倍——在时间和计算资源上都呈指数增长。对于许多应用，这使得大上下文处理在经济上不切实际。

**认知负荷隐喻**
即使有无限上下文，要求单个模型在数十个独立任务中保持一致质量也会创建认知瓶颈。模型必须不断在项目之间切换上下文、维护比较框架并确保风格一致性。这不是更多上下文能解决的问题。

## 实践指导

### 四桶方法

四种策略解决上下文退化的不同方面：

**写入**：使用便笺、文件系统或外部存储将上下文保存在窗口之外。这保持活跃上下文精简，同时保留信息访问。

**选择**：通过检索、过滤和优先级将相关上下文拉入窗口。这通过排除无关信息来解决干扰。

**压缩**：通过摘要、抽象和观察掩码减少 tokens 同时保留信息。这扩展有效的上下文容量。

**隔离**：将上下文分割到子智能体或会话中，以防止任何单个上下文增长到足以退化。这是最激进的策略，但通常最有效。

### 架构模式

通过特定的架构模式实现这些策略。使用即时上下文加载仅在需要时检索信息。使用观察掩码用紧凑的引用替换冗长的工具输出。使用子智能体架构隔离不同任务的上下文。使用压缩在上下文超过限制之前摘要增长的上下文。

## 示例

**示例 1：检测退化**
```yaml
# 上下文在长对话中增长
turn_1: 1000 tokens
turn_5: 8000 tokens
turn_10: 25000 tokens
turn_20: 60000 tokens (退化开始)
turn_30: 90000 tokens (严重退化)
```

**示例 2：缓解中间丢失**
```markdown
# 在边缘组织上下文并放置关键信息

[CURRENT TASK]                      # 开头
- Goal: Generate quarterly report
- Deadline: End of week

[DETAILED CONTEXT]                  # 中间（较少注意力）
- 50 pages of data
- Multiple analysis sections
- Supporting evidence

[KEY FINDINGS]                     # 结尾
- Revenue up 15%
- Costs down 8%
- Growth in Region A
```

## 指南

1. 在开发过程中监控上下文长度和性能相关性
2. 将关键信息放在上下文的开头或结尾
3. 在退化变得严重之前实施压缩触发器
4. 在将检索到的文档添加到上下文之前验证其准确性
5. 使用版本控制防止过时信息导致冲突
6. 分段任务以防止不同目标之间的上下文混淆
7. 设计优雅降级而不是假设完美条件
8. 使用逐步增大的上下文进行测试以找到退化阈值

## 集成

此技能建立在 context-fundamentals 之上，应在理解基本上下文概念后学习。它连接到：

- context-optimization - 缓解退化的技术
- multi-agent-patterns - 使用隔离防止退化
- evaluation - 测量和检测生产中的退化

## 参考资料

内部参考：
- Degradation Patterns Reference - 详细技术参考

此集合中的相关技能：
- context-fundamentals - 上下文基础
- context-optimization - 缓解技术
- evaluation - 检测和测量

外部资源：
- 关于注意力机制和上下文窗口限制的研究
- 关于"中间丢失"现象的研究
- 来自 AI 实验室的生产工程指南

---

## 技能元数据

**Created**: 2025-12-20
**Last Updated**: 2025-12-20
**Author**: Agent Skills for Context Engineering Contributors
**Version**: 1.0.0

## 限制
- 仅当任务明确匹配上述描述的范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少所需的输入、权限、安全边界或成功标准，请停止并请求澄清。