抹除后续问题所需上下文的对话记忆修剪启发法

一个用户打开你的长会话智能体（agent），在第 3 轮对话时说：“我是素食主义者，而且预算有限。”对话继续进行。11 轮之后，裁剪器（pruner）开始运行。它计算 Token 数量，发现第 3 轮内容既陈旧又短小，于是为了将窗口维持在预算范围内，将其丢弃了。第 14 轮用户问：“我今晚该做点什么菜？”模型查看一个约束条件已不存在的窗口，推荐了一份 40 美元的肋眼牛排。用户觉得智能体变得越来越难用，打开满意度调查，给这次会话打了一个 2 分。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E6%8A%B9%E6%8E%89%E4%B8%8B%E4%B8%80%E8%BD%AE%E9%97%AE%E9%A2%98%E6%89%80%E9%9C%80%E4%B8%8A%E4%B8%8B%E6%96%87%E7%9A%84%E5%AF%B9%E8%AF%9D%E8%AE%B0%E5%BF%86%E8%A3%81%E5%89%AA%E5%90%AF%E5%8F%91%E6%B3%95"]辨

你的技术栈中没有任何环节会报告记忆失败。Token 预算仪表盘会显示窗口健康地维持在上限之下。延迟仪表盘会显示绿色。评估套件——将单轮回答与预留集进行对比评分——会报告没有退化。唯一能体现智能体能力下降的信号是一个差评，而你的产品团队会将其归咎于“模型方差”。但这并不是模型方差，而是裁剪启发法在错误的目标上，精准地执行了它被调优后该做的任务。

裁剪是检索的对偶，而大多数团队只构建了其中一面

检索拥有一套清晰的词汇。你有查询（query）、语料库（corpus）、相似度函数（similarity function）和 top-k。你利用标注集通过 recall@k 进行评估。你调优嵌入（embedding）、分块（chunking）和重排序器（reranker）。你衡量正确片段进入窗口的频率。

裁剪则完全没有这些。大多数团队使用的词汇是“总结较旧的一半”或“丢弃早于 N 轮的内容”。这里没有查询，没有标注集，也没有召回率指标。保留什么的决策是由一个根本不知道下一个问题会是什么的启发式算法做出的。这种不对称性就是 Bug 所在。

并排观察这两个操作，其对称性显而易见。检索问：在窗口之外的所有内容中，下一轮需要哪些？裁剪问：在窗口之内的所有内容中，哪些可以在不破坏下一轮的情况下丢弃？这是同一个问题，只是从相反的方向表述。一个通过“最短且最旧”来选择片段的检索系统会在设计评审中被笑掉大牙。而一个通过“最短且最旧”来选择驱逐对象的裁剪器却能上线，仅仅是因为没人把它称为检索。

这意味着：如果你的裁剪器不知道用户下一步可能问什么，它就在赌博。赌博在大多数时候都能赢——事实上，时效性（recency）确实是一个不错的相关性先验——而这正是故障难以调试的原因。裁剪器在 90% 以上的情况下是正确的，但在用户测试智能体是否记得他们的情况下，则会错得一塌糊涂。

裁剪器针对 Token 数量而非回答准确性进行优化

来看看一个由 Token 计数驱动的裁剪器实际上看到了什么。它有一个预算——比如 8,000 个 Token 用于对话历史。它有一个带有时间戳和长度的轮次列表。它有一条规则：保留最近的 N 个 Token，丢弃其余部分，或者选择性地将丢弃的跨度总结为一个段落。

它没有的是：一个关于用户引入了哪些实体、约束或承诺的模型。它不知道“素食主义者”是一个硬约束，其寿命应该超过其时效性窗口。它不知道“项目截止日期是周五”是一个智能体必须遵守的承诺。它不知道“我已经试过了”是一个否定，防止智能体重复推荐同一个方案。从裁剪器的角度来看，所有 Token 都是平等的，而最近的 Token 比旧的 Token 稍微“更平等”一点。

调优这一层的团队通常是为了成本。他们运行裁剪器，观察到每轮平均 Token 数从 12,000 降至 7,500，为输入成本降低了 37% 而自我庆祝，然后发布。成本仪表盘变成了一个向右下方延伸的曲线。而质量退化——只出现在那些隐性锚定在已驱逐上下文的问题轮次中——从未出现在仪表盘上，因为没有任何单轮评估（eval）能捕捉到它。

这是该失效模式最隐蔽的特性。成本收益是可衡量的、快速且可见的。质量损失则是无声的、缓慢的，并且只出现在评估套件未设计测试的一类多轮交互中。一个看起来像是纯粹成本优化的改动，实际上是一次隐秘的质量退化，而团队对此毫无察觉。

为什么单轮评估无法发现这一点

你的评估套件可能长这样：你有一个 (输入, 预期输出) 对的数据集。你运行模型，根据预期输出给输出评分，得到一个数字。数据集经过策划，覆盖了智能体应该处理的问题类型。每一行都是独立的。

这种套件从结构上就无法捕捉裁剪退化。只有当第 N+k 轮提出的问题依赖于第 N 轮引入的上下文，且裁剪器在它们之间运行过时，故障才会显现。单轮评估行没有第 N 轮。它们没有裁剪步骤。它们没有发生故障的机会。

修复方法是进行针对裁剪窗口显式测试的多轮评估。你从真实会话中提取一段多轮对话。你让裁剪器在每一步发挥作用。然后，在一个答案依赖于早期上下文的轮次，你在裁剪后的窗口中重放问题并给答案评分。如果答案因为约束条件消失而错误，那就是你的退化信号——而且它指向的是裁剪器，而不是模型。

其机制至关重要。诸如 N+1 评估（获取截至第 N 轮的对话，并评估在许多合成延续中第 N+1 轮会发生什么）等方法，为你提供了大量可供评分的后期问题。用户模拟器评估（让另一个 LLM 扮演具有特定人格和约束条件的用户）可以让你按照评估所需的规模生成测试数据。这两者在多轮评估文献中已成为标准，但大多数生产团队尚未采用它们，因为单轮评估套件已经通过了。

这所要求的纪律性让人感到不适：你必须将裁剪器视为一段受测代码，拥有其独立的指标，并与模型分开。而大多数团队仅仅将其视为一项配置。

弥补差距的模式

一旦你接受了剪枝是衡量质量的杠杆，设计空间就会随之打开。在那些已经停止在此类失败模式上出现退化的生产系统中，反复出现了三种模式。

实体锚定记忆。 当用户陈述关于他们自己的事实、约束、偏好或承诺时，该事实会被固定在一个以实体为键的独立存储中，其寿命超过了基于新鲜度的对话缓冲区剪枝。“我是素食主义者”不是一个对话轮次；它是关于用户的一个事实，系统会将其写入用户事实存储，召回步骤在每一轮都会查阅该存储。这就是像 Mem0、Letta 以及 HINDSIGHT 架构中的时间记忆层独立趋同的方向。对话缓冲区可以自由剪枝；而实体存储是剪枝器不允许触碰的部分。

单会话记忆评估。 对于每个真实的会话，你在每次剪枝事件时对剪枝前和剪枝后的窗口进行快照。然后，你针对剪枝后的窗口重新运行后续的每个问题，并评分答案是否保持一致。剪枝前和剪枝后答案质量之间的差异就是你剪枝器的回归率。将其作为一项夜间任务在过去一天的会话中运行，当该比率超过阈值时发出警报，你的剪枝器现在就在生产环境中受到了监控。

混合记忆架构。 更深层次的举措是意识到对话缓冲区混合了两种不同的状态，而剪枝器却在以同样的方式处理它们。一种是短期对话状态——我们刚刚在谈论什么，当前任务的工作集；另一种是长期承诺——用户告诉我们的关于他们自己的信息、我们向他们承诺过的事、他们排除掉的选项。这些状态有不同的生命周期、不同的访问模式，并且应该有不同的存储方式。AgeMem 框架中的工作记忆/长期记忆拆分，以及 AMV-L 中的生命周期层，都是相同的思路：为每种状态提供具有其自身驱逐策略的独立存储，不要再指望一种最近启发式算法（recency heuristic）能同时服务于两者。

实现过程并不像听起来那么宏大。用户事实存储可以为每个用户建立一个 JSON 文档，在每一轮之后通过一个提取新事实的小型 LLM 调用进行更新。剪枝器在每一轮都会读取它，并将相关事实添加到 prompt 的开头。你只需要花一个下午的时间就能搞定。在一周之内，你会看到长会话的点赞率（thumbs-up rates）有所提升。

架构层面的认知

将剪枝器作为成本杠杆进行调优的团队回答了错误的问题。正确的问题不是“我能在窗口中塞入多少 token”，而是“在给定的预算下，哪些 token 能最大化接下来的 k 轮产生正确答案的概率”。这是一个检索目标，而不是压缩目标，应该使用检索系统的工具来优化：后期轮次问题的标记数据集、后期轮次正确性的指标、挑选保留内容的嵌入或评分模型，以及当指标下降时触发的回归测试。

这种失败模式揭示了两种记忆观之间的差距。第一种观点将记忆视为必须保持在大小限制之下的缓冲区；工程问题在于压缩。第二种观点将记忆视为必须服务于查询的数据库；工程问题在于保留策略（retention policy）。能够正常运行的生产系统，都是从第一种观点转向了第二种观点。

告诉你你站在哪一边的仪表盘不是 token 计数图。而是后期轮次答案相对于剪枝窗口的回归率。如果你没有这个指标，剪枝器就在静默运行，而针对其错误的唯一反馈渠道就是你的客户在会话中途放弃了智能体。等到那个信号传到你这里时，回归现象已经上线数周了。先构建评估（eval），然后根据评估结果调优剪枝器。顺序很重要。