context-degradation

上下文退化模式

随着上下文长度增加，语言模型会呈现出可预测的退化模式。理解这些模式对于诊断故障和设计弹性系统至关重要。上下文退化并非一种非此即彼的状态，而是性能逐渐下降的连续过程，会以几种不同的方式表现出来。

适用场景

在以下情况下启用此技能：

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

核心概念

上下文退化会呈现出几种不同的模式。“中间遗失”现象会导致上下文中间的信息受到的关注较少。上下文污染会在反复引用时导致错误不断累积。上下文分心会导致无关信息淹没相关内容。上下文混淆会使模型无法判断哪些上下文适用。上下文冲突则会在信息不断累积时形成直接矛盾。

这些模式具有可预测性，可以通过压缩、屏蔽、分区和隔离等架构模式加以缓解。

详细主题

“中间遗失”现象

最有据可查的退化模式是“中间遗失”效应：在评估中，模型的任务表现曲线可能呈 U 形。上下文开头和结尾的信息能够得到可靠关注，而埋在中间的信息，其召回准确率则会大幅降低。

实证证据 《Lost in the Middle》论文报告了其所评估的检索／问答任务中对信息位置敏感的表现。影响程度取决于模型和任务；该论文并未证明存在普遍适用的 10–40% 损失，也未确定单一的因果机制。

模型会将大量注意力分配给第一个 token（通常是 BOS token），以稳定内部状态。这会形成一个“注意力汇”，吸走注意力预算。随着上下文增长，有限的预算被摊得更薄，中间的 token 因而无法获得足够的注意力权重，难以可靠地检索。

实际意义 设计上下文布局时，应考虑注意力模式。将关键信息放在上下文的开头或结尾。考虑信息会被直接查询，还是需要用于推理——如果是后者，位置的重要性较低，但整体信号质量更重要。

对于长文档或长对话，应使用摘要结构，在更容易获得关注的位置呈现关键信息。使用明确的章节标题和过渡语句，帮助模型理解结构。

上下文污染

当幻觉、错误或不准确信息进入上下文，并在反复引用中不断累积时，就会发生上下文污染。上下文一旦被污染，就会形成反馈循环，不断强化错误认知。

污染如何发生 污染通常通过三种途径进入上下文。首先，工具输出可能包含错误或意外格式，而模型会将其视为事实。其次，检索到的文档可能包含错误或过时的信息，模型会将其纳入推理。第三，模型生成的摘要或中间输出可能引入幻觉，并使其持续留在上下文中。

这种累积效应十分严重。如果 Agent 的目标部分受到污染，它就会制定需要付出大量努力才能纠正的策略。此后的每次决策都会引用被污染的内容，从而强化错误假设。

检测与恢复 注意以下症状：此前能够完成的任务如今输出质量下降；工具调用不匹配，例如 Agent 调用错误的工具或参数；以及即使尝试纠正，幻觉仍然持续。如果出现这些症状，请考虑是否存在上下文污染。

恢复需要移除或替换被污染的内容。方法包括将上下文截断到污染发生之前的位置，在上下文中明确指出污染问题并要求重新评估，或使用干净的上下文重新开始，同时仅保留已核实的信息。

上下文干扰

当上下文变得过长，以致模型过度关注提供的信息而忽视训练所得知识时，就会出现上下文干扰。无论上下文中的信息是否相关，模型都会关注所有信息，这会促使模型使用提供的信息，即使其内部知识更加准确。

干扰效应 研究表明，即使上下文中只有一份无关文档，也会降低模型在涉及相关文档的任务上的表现。多个干扰项会进一步加剧性能下降。这种效应并非源于绝对意义上的噪声，而是注意力分配问题：无关信息会与相关信息竞争有限的注意力预算。

无关 token 可能会干扰检索和推理，但干扰程度取决于架构和推理实现；不要据此推断模型必须将注意力平均分配给每个 token。

缓解策略 通过谨慎筛选进入上下文的内容来缓解干扰。加载检索到的文档前，先进行相关性筛选。使用命名空间和组织结构，让无关部分在结构上更容易被忽略。考虑信息是否确实需要放入上下文，还是可以通过工具调用来获取。

上下文混淆

当无关信息以降低回答质量的方式影响模型响应时，就会出现上下文混淆。它与上下文干扰有关，但两者并不相同：混淆关注的是上下文对模型行为的影响，而不是注意力分配。

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

混淆的迹象 注意以下情况：回答针对查询中错误的方面；工具调用似乎适用于其他任务；或输出混合了多个来源的要求。这些情况表明模型混淆了哪些上下文适用于当前情形。

架构层面的解决方案 架构层面的解决方案包括：明确划分任务，为不同任务分配不同的上下文窗口；在不同任务上下文之间设置清晰的过渡；以及通过状态管理隔离不同目标所对应的上下文。

上下文冲突

随着信息不断累积，彼此直接矛盾的内容会引发上下文冲突，产生相互矛盾的指导，从而扰乱推理。这与投毒不同：投毒是某条信息有误，而冲突是多条正确的信息彼此矛盾。

冲突来源 冲突通常源于多源检索（不同来源的信息彼此矛盾）、版本冲突（过时信息和当前信息同时出现在上下文中），以及观点冲突（不同观点各自合理，但彼此不兼容）。

解决方法 解决方法包括：明确标记冲突，指出矛盾并请求澄清；制定优先级规则，明确哪个来源优先；以及进行版本筛选，将过时信息排除在上下文之外。

实证基准与阈值

研究提供了关于性能下降模式的具体数据，可为设计决策提供依据。

RULER 基准测试结果 RULER 基准测试揭示了令人警醒的结果：声称支持 32K 及以上上下文的模型中，只有 50% 能在 32K 个 token 时维持令人满意的性能。这一结果针对论文在 2024 年评估的模型和任务，并非对当前模型的排名。在简单的“大海捞针”测试中接近满分，并不代表模型真正理解长上下文。

测量部署中的模型和工作负载 不要将缺少引用依据的通用起始阈值或供应商排行榜分数用作长上下文能力的证据。逐步改变输入长度、相关事实的位置、干扰项数量和任务复杂度，同时固定提示词、模型快照、解码设置和真实答案。记录准确率、拒答率／错误率、延迟和计费 token 数，并进行足够多次测试以揭示差异。应根据可接受的错误预算选择运行上限，而不是采用宣传中的最大上下文长度。

反直觉发现

研究揭示了几种挑战上下文管理假设的反直觉规律。

打乱顺序的干草堆优于连贯的干草堆 研究发现，打乱顺序（不连贯）的干草堆比逻辑连贯的干草堆带来更好的性能。这表明，连贯的上下文可能会形成错误关联，干扰检索；而不连贯的上下文会促使模型依赖精确匹配。

单个干扰项的影响超乎预期 即使只有一份无关文档，也会显著降低性能。这种影响并不与噪声量成正比，而是呈阶跃式变化：只要存在任何干扰项，性能就会下降。

针与问题的相似度相关性 针与问题之间的相似度越低，性能随上下文长度增加而下降得越快。需要在相似度较低的内容之间进行推理的任务尤其容易受到影响。

上下文过大时的负面影响

更大的上下文窗口并不能一概提升性能。在许多情况下，更大的上下文会带来新问题，弊大于利。

性能退化曲线 模型的性能会随着上下文长度呈非线性退化。性能在达到某个阈值之前保持稳定，随后迅速下降。阈值因模型和任务复杂度而异。对于许多模型，即使上下文窗口支持更大的长度，显著退化也会在约 8,000-16,000 个 token 时开始。

成本影响 处理成本会随着上下文长度不成比例地增长。标准密集注意力的注意力计算量随序列长度呈二次方增长，而非指数级增长；端到端成本取决于缓存、架构和服务提供商的定价。不能仅凭这种复杂度推断一次 400K 请求的账单。对于许多应用而言，这会使大上下文处理在经济上难以实施。

认知负担比喻 即使上下文无限，让单个模型在数十项独立任务中始终保持稳定的质量，也会造成认知瓶颈。模型必须不断在各项任务之间切换上下文，维护比较框架，并确保风格一致。这并不是增加上下文就能解决的问题。

实用指南

四类方法

四种策略分别应对上下文退化的不同方面：

写入：使用暂存区、文件系统或外部存储，将上下文保存在窗口之外。这样可以保持活动上下文精简，同时保留访问信息的能力。

选择：通过检索、筛选和优先级排序，将相关上下文引入窗口。这可以通过排除无关信息来减少干扰。

压缩：通过摘要、抽象和观察结果屏蔽，在保留信息的同时减少 token 数量。这可以扩展有效上下文容量。

隔离：将上下文拆分到子 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

指南

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

集成

此技能以 context-fundamentals 为基础，应在理解基本上下文概念后学习。它与以下内容相关：

• context-optimization - 缓解性能退化的技术
• multi-agent-patterns - 利用隔离避免性能退化
• evaluation - 衡量并检测生产环境中的性能退化

参考资料

主要证据：

• Lost in the Middle
• RULER

未随附单独的内部《Degradation Patterns Reference》。

此合集中的相关技能：

• context-fundamentals - 上下文基础知识
• context-optimization - 缓解技术
• evaluation - 检测与衡量

外部资源：

• 关于注意力机制和上下文窗口限制的研究
• 关于“中间遗失”现象的研究
• AI 实验室的生产工程指南

---

技能元数据

创建时间：2025-12-20 上次更新：2025-12-20 作者：Agent Skills for Context Engineering Contributors 版本：1.0.0

限制

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