渐进式上下文替换：在长 AI 对话中保持质量的方法

你的聊天机器人在前十五轮对话中运行完美。然后，问题出现了。它与之前的决定相矛盾。它询问用户已经提供过的信息。它丢失了对话开始时明确定义的多步骤任务的脉络。对话历史在技术层面上还在那里——你没有删除任何内容——但模型的行为却好像它不存在一样。

这就是上下文腐化（context rot）：随着对话历史增长，输出质量逐渐下降的现象。2024 年对 18 个最先进模型进行的评估，涵盖近 20 万次受控调用，发现即使在名义上拥有更大窗口的模型中，可靠性在超过 30,000 个 Token 后也会显著下降。在扩展对话中，高性能模型会变得和小得多的模型一样不可靠。问题不在于你的上下文窗口耗尽了，而在于 Transformer 注意力机制是二次方的——100,000 个 Token 意味着 100 亿对关系——模型被迫将注意力分散得如此稀薄，以至于重要的早期内容实际上被忽略了。

当团队遇到这个瓶颈时，通常会采用两种解决方案之一：截断或摘要。这两种方法都会以可预见的方式让情况变得更糟。

为什么截断和朴素摘要都会失败

硬截断——当上下文填满时丢弃最旧的消息——是最简单的方法，也是最明显存在缺陷的方法。模型会丢失早期决策背后的推理逻辑。一个用户花了十分钟在第一至第五轮建立的约束条件，就这样被悄然丢弃。当矛盾浮出水面时，用户看到的不是"上下文已截断"，而是一个没有认真听讲的 AI。

朴素摘要看起来更聪明一些。当上下文填满时，用一个压缩摘要替换旧消息。历史记录被保留下来，只是以更紧凑的形式存在。然而在实践中，它引入了三种随时间累积的不同错误类型：

捏造事实。 摘要是生成的，而不是复制的。模型在总结一段长对话时，偶尔会引入隐含而非明确陈述的信息，或者是合理推断而非实际存在的内容。一旦这种捏造进入摘要，它就成为所有后续轮次的"基本事实"。

错误关系。 摘要将顺序推理压缩为并列事实。一个条件决策（"如果 API 速率限制被证明是个问题，那么使用缓存"）变成了一个扁平陈述（"正在使用缓存"）。条件性——以及背后的推理——消失了。

遗漏关键细节。 摘要优化的是显著性，而不是完整性。小但重要的细节——用户指出的特定边缘案例、被拒绝的替代方案及其原因——会在压缩过程中被剔除，因为它们在摘要时看起来不够核心。当四十轮后出现相关问题时，它们就变得至关重要了。

每次压缩传递都会略微降低摘要质量。长期运行下来，你得到的是一个"记住"了经过净化的、通用版本对话的 Agent——自信、流畅，但是错误的。

滚动替换模式

解决方案不是避免压缩，而是增量压缩而非一次性全量压缩。

在滚动替换中，你维护上下文的两个区域：

• 热区（Hot region）：最近 N 轮原始对话轮次，逐字保留（通常为 10–20 轮）。
• 暖区（Warm region）：比热区更旧的所有内容的持久化结构化摘要。

当新轮次到来且热区溢出时，你不会从头重新摘要所有内容。你识别出即将从热区边缘滑落的轮次，仅对该轮次（或一小批）进行摘要，然后将这个新的迷你摘要合并到持久化的暖区摘要中。持久摘要以增量方式增长，而不是被整体替换。

这种锚定迭代方法——更新摘要而非重建摘要——避免了全量重建的复合错误。暖区摘要永远不必"记住"它从未被直接告知的内容。每个增量都是对少数几轮特定对话的小型、可验证的摘要。

热区为即时推理提供连续性。暖区提供背景上下文和决策历史。关键是，两个区域都不会完全消失——你是在压缩，而不是在删除。

设计保留决策理由的摘要 Schema

团队在摘要 Schema 上犯的最大错误是将其视为事实提取器。一个只捕获"决定了什么"的摘要 Schema 在最重要的测试中会失败：解释为什么。

当 AI 会话跨越复杂任务的 40 多轮时，模型经常需要对早期选择进行推理。"我应该使用方法 A 还是方法 B？"——如果 A 在十二轮前被考虑并拒绝，模型需要知道这一点以及原因，而不仅仅是 B 目前正在使用。

生产级摘要 Schema 应明确分离四类信息：

加载中…