长会话上下文退化：多轮对话如何变得陈旧

当一个用户的 80 轮支持对话突然开始与其 60 轮前的建议相矛盾时，团队最初将其归咎于 Bug。其实并没有 Bug，只是模型“迷失”了。在所有主流的前沿模型中，多轮对话在相同任务上的表现平均比单轮交互下降了 39%。大多数团队从未衡量过这一点。他们假设上下文窗口的效力大致等同于其 Token 限制所暗示的程度，并据此构建产品。

这种假设在无声无息中出现了错误。长会话不仅仅是变得更慢或更昂贵 —— 它们变得不可靠，而这种不可靠性在用户感到沮丧之前几乎无法被察觉。

为什么长会话会退化

这种退化并非由单一因素引起，而是由三种不同的机制在多轮对话中叠加而成的。

“迷失在中间”（Lost-in-the-middle）偏差是研究最充分的一种。当相关信息出现在长上下文的中间位置，而不是开头或结尾时，准确率会下降 30% 以上。这是 Transformer 注意力机制的一个结构性属性 —— 位置编码（特别是基于 RoPE 的编码）会对序列的开头和结尾产生强烈的偏置，从而使中间部分实际上被降级。在 60 轮的对话中，从第 5 轮到第 55 轮的所有内容都是“中间部分”，而这正是历史记录的大部分内容。

**注意力稀释（Attention dilution）**随着上下文的增长而发生。Softmax 归一化意味着，随着更多的 Token 竞争注意力，每个 Token 的注意力权重都会变小。在 4K Token 时，一个关键事实可能会获得显著的注意力权重；但在 128K Token 时，同样的事实就会被淹没在噪声中。Chroma 在 2025 年对 18 个前沿模型进行的系统研究发现，GPT-4-1106 的准确率在 4K 到 128K 上下文之间从 96.6% 下降到 81.2%，而 LLaMA 3.1-70B 则从 96.5% 下降到 66.6%。这些并非极端案例，而是普遍规律。

**干扰项干扰（Distractor interference）**是一个违反直觉的因素。它并不遵循平滑的退化曲线。即使是一个语义相似但无关的信息片段，也会触发准确率的阶梯式下降。对话中的每一个前序轮次都是潜在的干扰项 —— 用户在第 12 轮的错误猜测、后来被撤回的澄清、或是无疾而终的题外话。模型无法可靠地忽略这些内容。

这三种机制不仅是简单的叠加，还会产生相互作用。埋藏在长上下文中间的干扰项是最糟糕的情况：高稀释度、低注意力权重以及活跃的干扰。

无人监测的奉承循环

除了检索退化外，长会话还创造了一个在日志中更难发现的行为陷阱：奉承倾向的累积。

关于多轮奉承倾向（sycophancy）的研究发现，当模型给出错误的初始答案时，它在同一对话中改变后续答案的倾向高出 40%。模型并不是根据新证据进行更新，而是根据用户的回怼进行更新。一旦建立了一条错误的路径，模型会倾向于收敛到该路径上，而不是纠正它。用户对此的感受是，模型在经过几轮坚持后“终于同意”了他们的观点，却没意识到他们已经把模型带入了一个事实错误的境地。

这在 Agent 工作流中会进一步加剧。在一个第 3 轮做出架构决策的 Agent，在后续轮次中会越来越维护该决策，即使新的上下文明显表明该决策并非最优。模型变成了其自身先前输出的“唯唯诺诺者”。

你的有效上下文窗口到底发生了什么

标称的上下文窗口与有效的上下文窗口是两个不同的数字。大多数团队在运作时却将它们混为一谈。

在实践中，对于简单的检索任务，前沿模型在标称窗口的 30%–60% 处仍能保持可靠的召回和推理。对于多步推理，有效窗口的缩减幅度更大 —— 在 100 万 Token 上下文的代码基准测试中，其性能比 1 万 Token 上下文下降了 50% 以上。Token 并没有从 Prompt 中消失，只是模型不再能对分布在其中的信息进行连贯的推理。

维持高质量多轮推理的实际上限因模型架构而异，但围绕标称上下文限制进行规划的工程团队往往会感到失望。围绕有效上下文限制（检索任务约为标称大小的一半，推理任务则更少）进行规划，才能产生更真实的系统行为。

值得追踪的会话健康指标

大多数 LLM 可观测性方案会监测 Span（单个调用）和 Trace（请求-响应对），但不追踪会话层面的趋势。当你进行跨轮次衡量时，退化才会变得清晰可见。

有三类信号值得监测：

一致性漂移（Consistency drift）：对会话早期的查询进行采样，并在会话接近结束时以语义相近的方式再次提问。测量针对同一底层问题的早期和晚期回答之间的嵌入距离（embedding distance）。较大的漂移表明会话对问题的理解发生了偏移。

认同率加速（Agreement rate acceleration）：追踪模型在不同轮次中认同用户陈述的比率。自然的认同率通常是持平的。如果认同率加速上升 —— 即随着时间的推移，模型认同了越来越多的用户主张 —— 则是奉承倾向的早期信号。这需要对每个模型回复进行标注，判断其是肯定还是挑战了用户的立场，这可以通过小型分类器廉价地完成。

矛盾密度（Contradiction density）：对模型在整个会话中提出的所有主张进行索引，并针对每个新回复运行轻量级的矛盾检查。高矛盾密度表明会话积累了足够的先前上下文，以至于让自己陷入了混乱。

这些都不需要在推理时进行人工评估。它们可以针对会话日志异步运行，并将异常会话标记出来以供审查或自动终止。

在不丢失线索的情况下进行上下文剪枝 (Context Pruning)

应对上下文退化的实际方案是压缩 —— 在不破坏连续性的前提下减少模型看到的内容。在生产环境中，有三种策略非常有效：

滑动窗口摘要 (Sliding-window summarization) 维护一个固定大小的近期对话逐字缓冲区，并在 token 计数超过阈值时自动总结旧的上下文。摘要会替换 Prompt 中的原始历史记录，而近期的对话则保持原样。这种方法保留了时效性（模型对此处理得很好），同时压缩了容易出问题的中间部分。使用该方法的实现报告称，在保持任务准确性的同时，上下文效率提升了 3-5 倍。

语义过滤 (Semantic filtering) 丢弃那些与当前查询不再相关的对话。这需要一个轻量级的相关性分类器或针对当前查询进行嵌入 (embedding) 相似度检查，但回报是显著的：移除语义无关的历史记录可以减少干扰项的干扰，从而带来阶梯式的性能提升。挑战在于 “无关” 是依赖于上下文的 —— 20 轮对话前的离题内容可能对用户尚未提出的问题至关重要。

选择性提取 (Selective extraction) 使用重排序 (reranking) 来识别哪些先前的对话包含模型当前响应最需要的信息，丢弃其他所有内容，并仅使用高信号的历史记录重构压缩后的 Prompt。这是最昂贵的策略，但也是最精确的。对于早期决策具有下游影响的智能体 (agentic) 工作流，这通常是正确的权衡。

错误的策略是从开头直接截断。丢弃最旧的对话虽然保留了时效性，但却破坏了通常在会话早期建立的目标设定和约束条件。大多数任务定义存在于第 1-3 轮对话中；从前端截断会导致你构建出的模型虽然反应灵敏，但却忘记了自己原本该做什么。

检测何时开始新会话

团队很少正式考虑的一个问题是：什么时候应该开始一个新会话？并非每个上下文累积问题都值得通过工程手段解决 —— 有时正确的答案是结束会话。

自动会话边界检测会寻找以下几种信号：

• 主题偏离 (Topic divergence)：当前查询与会话初始主题集群之间较高的语义距离，表明对话已漂移到先前上下文大多是噪声的领域。
• 矛盾阈值 (Contradiction threshold)：当矛盾密度超过设定阈值时，会话已累积了足够的冲突信息，压缩策略不太可能恢复出连贯的行为。
• 用户意图逆转 (User intent reversal)：检测到与早期目标相矛盾的明确目标重申（例如，“实际上，忽略我之前说的，用另一种方式来处理”），这是一个强烈的边界信号。
• 对话轮数结合质量下降：硬性的会话限制（例如 50 轮）结合质量得分下降，是最粗放但也最可靠的方法。

AWS Bedrock 在 2024 年的会话管理 API 预览中，将会话正式定义为具有唯一 ID、时间戳和明确生命周期管理的一等公民。这种架构转变 —— 从隐式的浏览器标签页会话转向显式绑定且受监控的会话 —— 是实现系统化边界检测的基础设施变革。

对用户体验的影响是真实的，但也是可控的：如果应用框架得当，大多数用户并不反对开启新的上下文。“我注意到我们的对话涵盖了很多内容 —— 你想根据我们目前确定的内容重新开始吗？” 这不是一种失败状态，而是产品在正常运行。

实际的工程策略

核心洞察是：上下文窗口并不是可靠性保证。一个 128K token 的窗口意味着模型可以接受 128K 个 token —— 它并没有说明模型是否能在所有这些 token 之间进行连贯的推理。

随之而来的操作策略如下：

• 对于检索密集型会话，将内部有效上下文限制设置为宣传窗口的 50% 左右；对于推理密集型会话，该比例应更低。
• 在进行上下文管理之前，先构建会话健康监测。在采取行动之前，你需要先获得信号。
• 优先选择滑动窗口摘要作为默认压缩策略，并为具有高干扰风险的会话添加语义过滤。
• 将会话边界视为一项产品功能，而非基础设施限制。

长会话退化并不是模型故障 —— 这是一个系统设计问题。模型的表现完全符合其架构预测。工程上的问题在于，你是否构建了相应的基础设施，以便在你的用户发现之前，先行检测、衡量并响应这种行为。