context-degradation

上下文退化模式

在上下文问题逐步扩散之前，诊断并修复这些问题。上下文退化并非非黑即白，而是一个连续变化的过程，会呈现五种不同且可预测的模式：中间遗忘、污染、分心、混淆和冲突。每种模式都有特定的检测信号和缓解策略。应将退化视为一个具有可测量阈值的工程问题，而非不可预测的故障模式。

何时启用

• Agent 在长时间对话中的表现意外下降
• 调试 Agent 产生错误或无关输出的情况
• 设计必须可靠处理大型上下文的系统
• 评估生产系统的上下文工程方案
• 调查 Agent 输出中的“中间遗忘”现象
• 分析 Agent 行为中与上下文相关的故障

对于由其他技能负责的相邻工作，不要启用此技能：

• 在没有实际故障时解释基础上下文机制：context-fundamentals。
• 已知故障模式后采用提高令牌效率的策略：context-optimization。

核心概念

围绕注意力 U 曲线安排上下文内容：在长上下文实验中，开头和结尾位置能获得可靠关注，而中间位置的回忆准确率会明显降低（claim-context-degradation-lost-middle-ruler）。这并非模型错误，而是注意力机制导致的结果——第一个令牌（通常是 BOS）会充当“注意力汇”，吸收不成比例的注意力预算；随着上下文增长，中间令牌获得的关注便会减少。

将上下文污染视为断路器问题。一旦幻觉、工具错误或检索到的错误事实进入上下文，就会通过反复自我引用不断累积。被污染的目标部分会导致之后的每个决策都强化错误假设。检测需要追踪声明的来源；恢复则需要截断到污染发生点之前，或使用仅含已验证内容的上下文重新开始。

加载上下文前要严格筛选——即使只有一份无关文档，也会明显降低模型在相关任务上的表现。模型无法“跳过”无关上下文；它们必须关注所提供的所有内容，从而导致相关内容与无关内容之间产生注意力竞争。对于可能需要但当前并不相关的信息，应将其置于工具调用之后，而不是预先加载。

隔离任务上下文以避免混淆。当上下文包含多种任务类型或在多个目标之间切换时，模型可能会采用错误任务中的约束、调用适用于其他上下文的工具，或混合多个来源的要求。通过明确划分任务并使用独立的上下文窗口，可以消除交叉污染。

通过优先级规则解决上下文冲突，而不是不断累加内容。当上下文中出现多个正确但相互矛盾的来源（版本冲突、观点冲突、多来源检索）时，模型无法判断哪个来源适用。应明确标记矛盾、确立来源优先级，并在过时版本进入上下文前将其筛除。

详细主题

中间遗忘：检测与信息布局策略

将关键信息放在上下文的开头和结尾，切勿放在中间。U 形注意力曲线意味着位于中间的信息，其回忆准确率会降低 10-40%。对于超过 4K 令牌的上下文，这种影响会变得显著。

使用摘要结构，将关键发现放在注意力偏好的位置。添加明确的章节标题和结构标记——这些内容能创建注意力锚点，帮助模型浏览长上下文。如果必须完整纳入某份文档，应在文档前添加要点摘要，并在末尾附上关键结论。

监测中间遗忘的迹象：上下文中存在正确的信息，但模型忽略了它；回答与所提供的数据相矛盾；或者模型“忘记”了长提示词中较早给出的指令。

上下文投毒：预防与恢复

在所有外部输入进入上下文之前进行验证。工具输出、检索到的文档和模型生成的摘要是三种主要的投毒途径。每种途径都会引入未经验证的说法，后续推理会将其视为事实依据。

通过以下信号检测投毒：此前能成功完成的任务中输出质量下降、工具不匹配（工具或参数错误），以及即使经过明确纠正仍持续出现幻觉。当这些信号同时出现时，应怀疑上下文遭到投毒，而非模型能力不足。

恢复时，应移除被投毒的内容，而不是在其上叠加纠正信息。将上下文截断至投毒发生前，从干净的上下文重新开始，并仅保留已验证的信息；或者明确标记被投毒的部分，并要求从头重新评估。在被投毒的上下文上叠加纠正信息通常难以奏效，因为原始错误仍会占据注意力权重。

上下文干扰：筛选优于累积

应筛选进入上下文的内容，而不是依赖模型忽略无关信息。研究表明，即使只有一份干扰文档，也会导致可测量的性能下降——这种影响呈阶跃式变化，而非线性变化。多份干扰文档会使问题进一步加剧。

在加载检索到的文档之前进行相关性筛选。使用命名空间和结构化组织，明确标示各个章节的边界。优先采用基于工具调用的访问方式，而不是预先加载：将参考资料存放在检索工具之后，仅在与当前推理步骤直接相关时才将其纳入上下文。

上下文混淆：任务隔离

将不同任务划分到独立的上下文窗口中。上下文混淆不同于上下文干扰——它指模型将错误上下文中的约束应用到当前任务，而不仅仅是注意力被稀释。其迹象包括：回答针对查询中的错误方面、调用适用于其他任务的工具，以及输出混合来自多个来源的要求。

在不同任务上下文之间设置清晰的切换。使用状态管理，按任务隔离目标、约束和工具定义。当无法避免在单次会话中切换任务时，使用明确的“上下文重置”标记，指明当前片段适用哪些约束。

上下文冲突：冲突解决规程

在冲突发生前确立来源优先级规则。上下文冲突不同于投毒——多条信息各自都正确，却彼此矛盾（版本冲突、视角差异、多来源检索得到的事实不一致）。

在信息进入上下文之前进行版本筛选，排除过时信息。当无法避免矛盾时，使用结构化冲突注释明确标记：说明冲突内容、每项说法的来源，以及哪个来源优先。没有明确的优先级规则，模型解决矛盾的方式将难以预测。

实证基准与阈值

使用这些基准来设定设计约束，而不要将其视为普遍真理。RULER 风格的证据表明，标称支持长上下文并不保证模型在该长度下能令人满意地完成任务（claim-context-degradation-lost-middle-ruler）。大海捞针测试接近完美的得分，并不能预测模型在真实场景中的长上下文表现。

特定模型的性能退化阈值

退化起点因模型系列和任务类型而异。一般来说，对于复杂检索任务，预计模型会在标称上下文窗口的 60–70% 处开始退化（RULER 基准发现，声称支持 32K 以上上下文的模型中，只有 50% 能在该长度下维持令人满意的性能）。主要规律如下：

• 具备扩展思考能力的模型通过逐步验证减少幻觉，但会增加延迟和 Token 成本
• 针对 Agent／编码优化的模型通常能更好地管理工具输出较多的上下文
• **上下文窗口非常大的模型（1M+）**能处理更多原始上下文，但仍呈现 U 形退化曲线——更大的窗口无法消除问题，只会推迟问题出现

务必针对自己的具体工作负载评测退化阈值，而不要依赖已发布的基准。随着每次模型更新，特定模型的阈值都会过时（参见陷阱 2）。

反直觉的发现

设计上下文策略时，请考虑以下有研究依据的意外发现：

打乱后的上下文可能优于连贯的上下文。 研究发现，对于某些检索任务，非连贯（打乱排列）的干草堆可能优于按逻辑顺序排列的干草堆（claim-context-degradation-distractor-shuffled）。连贯的上下文可能造成错误关联，干扰检索；非连贯的上下文则可能迫使模型进行精确匹配。不要认为组织得更好的上下文总会带来更好的结果——请测试这两种排列方式。

单个干扰项的影响格外显著。 与在第一个干扰项之后继续添加更多干扰项相比，单个无关文档造成的性能损失要大得多。应将干扰项预防视为非此即彼：要么保持上下文干净，要么接受显著的性能退化。

问题与目标内容的相似度低会加速退化。 需要跨不相似内容进行推理的任务，其性能随上下文长度增长而退化的速度，比表层相似度高的任务更快。设计检索时，应尽可能提高查询与检索内容之间的语义重合度。

更大的上下文何时会造成损害

不要认为更大的上下文窗口一定能提升性能。在特定模型的阈值以内，性能保持稳定；超过阈值后，性能会迅速退化——曲线并非平缓下滑，而是非线性的断崖式变化。对于许多模型，即使上下文窗口支持大得多的长度，显著退化也会在 8K–16K Token 时开始。

还要考虑成本：处理 400K Token 的上下文，在耗时和计算资源方面都比处理 200K Token 的成本高出成倍，而非线性增加。对于许多应用而言，这会使大上下文处理在经济上不切实际。

还要认识到认知瓶颈：即使上下文无限，让单个模型在数十个彼此独立的任务中始终保持高质量，也会造成无法通过增加上下文来解决的性能退化。应将任务拆分给多个子 Agent，而不是扩展上下文。

实用指南

四类缓解框架

根据当前出现的退化模式，采用以下四种策略：

写入 — 使用暂存区、文件系统或外部存储，在上下文窗口之外保存上下文。当上下文利用率超过窗口的 70% 时使用。这样可以保持活动上下文精简，同时通过工具调用保留对信息的访问。

筛选 — 通过检索、过滤和优先级排序，只将相关上下文提取到窗口中。当出现分心或困惑的迹象时使用。加载前先进行相关性评分；排除低于阈值的内容，而不是纳入所有可用内容。

压缩 — 通过摘要、抽象和观察结果屏蔽，在保留信息的同时减少令牌数量。当上下文不断增长，但所有内容都相关时使用。用简洁的结构化摘要替代冗长的工具输出；将重复模式抽象为单个引用。

隔离 — 将上下文拆分到多个子 Agent 或会话中，以避免任何单个上下文超过其退化阈值。当出现困惑或冲突的迹象，或任务彼此独立时使用。这是最激进的策略，但对于复杂的多任务系统往往最有效。

提升韧性的架构模式

实施即时上下文加载：仅在当前推理步骤需要信息时才检索，而非提前检索。处理完冗长的工具输出后，使用观察结果屏蔽将其替换为简洁的引用。采用子 Agent 架构，让每个 Agent 仅保留与任务相关的上下文。在上下文超过特定模型的退化起始阈值之前触发压缩，而不要等到出现症状后再处理。

示例

示例 1：检测退化

# Context grows during long conversation
turn_1: 1000 tokens
turn_5: 8000 tokens
turn_10: 25000 tokens
turn_20: 60000 tokens (degradation begins)
turn_30: 90000 tokens (significant degradation)

示例 2：缓解中段遗失

# Organize context with critical info at edges

[CURRENT TASK]                      # At start
- Goal: Generate quarterly report
- Deadline: End of week

[DETAILED CONTEXT]                  # Middle (less attention)
- 50 pages of data
- Multiple analysis sections
- Supporting evidence

[KEY FINDINGS]                     # At end
- Revenue up 15%
- Costs down 8%
- Growth in Region A

示例 3：上下文污染断路器

symptom: agent keeps citing an incorrect retrieved claim after correction
diagnosis: poisoned context, not a missing-instruction problem
action:
  1. identify first turn where the bad claim entered
  2. truncate or restart from before that point
  3. reload only verified sources
  4. record the rejected claim and source provenance

示例 4：上下文冲突标注

conflict:
  topic: billing API version
  source_a: docs/v1.md says endpoint is /charges
  source_b: docs/v2.md says endpoint is /payments
  precedence: docs/v2.md
  reason: current production version

指南

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

常见陷阱

1. 正常波动看起来像性能下降：模型输出质量在不同运行中会自然波动。不要仅凭一次质量下降就判定性能下降——应通过多次运行建立基线，并观察是否存在与上下文增长相关的持续性下降。单次运行中质量下降 5-10% 属于噪声；如果在 40K 个 token 后持续出现同样的下降，则是信号。

2. 特定模型的阈值会过时：基准测试表中的性能下降起始值反映的是特定模型版本。提供商更新、微调变更和基础设施调整都可能使阈值向任一方向移动 20-50%。应每季度以及每次重大模型更新后重新进行基准测试，而不要将已公布的阈值视为永久不变。

3. 大海捞针得分会造成虚假的信心：模型在大海捞针测试中得分 99%，并不意味着它在生产环境中能很好地处理 128K 个 token。大海捞针测试衡量的是从被动上下文中检索单个事实的能力；实际工作负载需要跨整个窗口进行多事实推理、遵循指令和综合信息。应使用能反映实际工作负载模式的特定任务基准测试。

4. 相互矛盾的检索文档会悄然造成影响：当检索流水线检索到两份对同一事实存在分歧的文档时，模型可能会悄然选择其中一份，而不提示存在冲突。这看起来像是正确回答，实质上却是随机选择。在文档进入上下文前，应在检索层实现矛盾检测。

5. 提示词质量问题会伪装成性能下降：提示词结构不佳（指令含糊、缺少约束、任务描述不清）会产生与上下文性能下降相同的症状——输出不一致、忽略指令、工具使用错误。在判定性能下降前，应验证同一提示词在较短上下文中能否正常工作。如果在 2K 个 token 时就失败，问题出在提示词，而不是上下文。

6. 性能下降是非线性的，会出现断崖式下跌：性能不会逐渐下降——它会一直保持稳定，直到达到特定于模型的阈值，然后急剧下跌。为“平滑降级”设计的系统往往会漏掉这种模式，因为监控检查假设性能会线性下降。应在断崖式下跌出现前很久就设置压缩触发条件（已知起始值的 70%），而不是等到起始值本身。

7. 过度整理上下文可能适得其反：直觉上，结构清晰、连贯的上下文应该优于杂乱的内容。研究表明，在检索任务中，打乱顺序的“大海”有时反而优于连贯内容，因为连贯的上下文会造成错误关联。应针对特定任务测试繁复的结构化格式是否真的有帮助，不要想当然。

集成

此技能负责诊断和缓解正在发生的上下文故障。相邻技能负责在确认故障后采取相应的实现策略：

• context-fundamentals：在故障发生前，对注意力机制和上下文窗口进行概念性说明。
• context-optimization：诊断后，采用掩码、缓存、分区及其他提高 token 效率的策略。
• multi-agent-patterns：将任务隔离到不同上下文中，以避免混淆和冲突。
• evaluation：性能下降测试和生产环境监控。

参考资料

内部参考：

• 退化模式参考 - 适用情形：调试特定退化模式，并需要实现层面的检测代码（注意力分析、投毒跟踪、相关性评分、恢复流程）

本系列中的相关技能：

• context-fundamentals - 适用情形：缺乏关于上下文窗口、令牌预算或内容放置机制的基础知识
• context-optimization - 适用情形：已诊断出退化问题，需要具体的缓解技术（压缩、摘要、掩码）
• evaluation - 适用情形：设置生产监控，在退化影响用户之前检测出来

外部资源：

• Liu 等人，2023 年，《Lost in the Middle》——适用情形：需要支持 U 形注意力主张的原始研究，或设计位置感知的上下文布局
• RULER 基准测试文档——适用情形：评估模型对长上下文支持的主张，或为上下文密集型工作负载比较模型
• AI 实验室的生产工程指南——适用情形：在生产基础设施中实现上下文管理