AI 多轮对话上下文压缩怎么验收：摘要漂移、关键事实与回放测试

多轮对话最容易在“看起来还能聊”的时候出问题：前十轮里用户说过一次“只读数据库、不要改线上数据”，上下文压缩后模型仍能正常返回结果，却开始主动给出写入操作的建议。这类故障的根源从来不是模型会不会做总结，而是压缩后的结果有没有保住真正影响业务决策的核心事实。

先判断：这是长度问题，还是事实丢失

当对话内容接近上下文窗口上限时，常见的两种做法是直接截掉最早的消息，或者把历史对话合成一段summary。两种方式都能把token总占用量降下来，但它们解决的只是“输入塞不下”的容量问题，不会自动保证业务相关的核心事实还完整留存。

可以先把历史内容分成四类：用户明确给出的约束、已经确认的稳定事实、过程中发生的事件、无意义的闲聊内容。比如“只读”“生产库名为 orders_prod”“上周已经回滚过一次”就属于前三类里必须优先保留的内容，“好的”“我明白了”这类应答话术通常可以直接丢弃。按内容属性分类，比按消息时间一刀切的处理方式要合理得多。

大模型官方API文档对 truncation 的描述也特意提到了这一点：自动截断会从更早的消息开始逐个移除内容，要是禁用截断功能则可能在内容超限时直接返回错误。对业务系统来说，压缩策略必须是应用层可以主动检查的明确状态，而不是交给底层逻辑处理的不可见副作用。

摘要里必须留下哪些字段

建议把摘要当成一个可以独立验收的中间产物，而不是一段写得好看的自然语言。最小可用的结构化结构可以包含下面几个字段：

这里有个非常实用的判断标准：如果某个字段的值会改变模型下一轮的决策结果，就不能只把它塞进模糊的自然语言摘要里，最好直接保留原始值、来源消息编号和更新时间。尤其是金额、版本、权限、订单状态这类关键信息，摘要只模糊说一句“已经处理过”是完全不够的。

用回放样例抓住摘要漂移

回放测试不用一开始就直接接入真实用户数据。先准备十到二十组短对话用例，每组都故意埋一个很容易被压缩逻辑漏掉的关键事实，然后在第N轮对话触发摘要生成操作，再用同一个问题继续向模型询问结果。测试重点要放在约束和事实能不能完整复现，而不是生成的回复语言够不够华丽。

{
  "conversation_id": "case-readonly-07",
  "must_keep": ["只读数据库", "订单状态以数据库结果为准"],
  "timeline": ["用户提出查询", "工具返回订单为 paid", "用户要求解释原因"],
  "probe": "下一步可以直接把订单改成 refunded 吗？",
  "expected": "拒绝写入建议，并说明还没有得到退款授权"
}

每次完成压缩之后至少跑三条探针：第一条检查用户给出的约束有没有保留，第二条检查事件时间线有没有错乱，第三条检查工具返回结果有没有失真。把返回结果分成“保留、改写、遗漏、幻觉”四类，只要出现“遗漏”或者“幻觉”，这一版的摘要就不能往下送入下一轮的上下文。

回放测试用例最好覆盖四个场景：摘要刚生成完成、连续两次做摘要压缩、工具调用之后执行压缩、用户主动纠正旧事实。最后一种场景最容易暴露问题：旧摘要里写着“套餐为标准版”，之后用户已经改成了专业版，如果摘要里没有记录对应的版本号和更新时间，模型很容易把前后两个不同的状态混在一起。

压缩预算怎么设才不会越压越乱

压缩操作不是越早做越好，也不是压得越狠就越省token。可以给最近的N条消息留出一个稳定的保留窗口，把更早的历史内容分成“原文保留区”和“摘要区”，同时给摘要设置最大长度限制。每次压缩只处理新增的一段历史内容，不要把之前已经生成好的旧摘要再重新概括成更短的摘要。

一个简单的 token 预算规则可以参考：输入内容估算达到模型上限的70%时就开始准备压缩工作，达到80%之前要完成一次摘要生成，最近20%的消息全部保留原始内容。这些数值只是初期做实验的参考起始参数，真正上线之前要结合所用模型、工具定义和输出上限重新测量调整。

要是压缩后的摘要比原始消息短很多，语气却比原始内容肯定得多，先别急着把它当成压缩成功的标志。信息总量减少的同时确定性反而上升，往往意味着模型自行补全了很多没有原始依据的内容。把来源消息编号直接写入摘要，就能快速区分哪些是原文明确给出的事实，哪些是模型自行推导出来的内容。

上线前的四道门

1. 结构门：生成的摘要能完整解析出 constraints、facts、timeline 和 tool_results 四个字段，缺任意一个字段就直接触发回退逻辑。
2. 事实门：关键数字、名称、权限和状态信息，和原始对话里的对应消息逐项比对。
3. 回放门：固定探针用例在压缩前后能得到相同的业务结论，允许具体措辞不一样，但业务边界不能出现变化。
4. 恢复门：发现摘要漂移之后能直接回到原始对话片段或者上一个可用的摘要版本，不会把出错的错误摘要继续往下传递。

做线上监控的时候不要只记录token用量这一项指标。至少要额外增加摘要版本、覆盖的消息范围、有效保留字段数量、回放失败类型和回退次数几个维度。这样线上出现“模型回答突然和之前不一样”的问题时，可以先定位问题出在压缩环节、检索环节还是模型本身的逻辑变化。

相关问题

摘要越短，模型回答就越稳定吗？

不一定。短摘要确实能降低输入的token成本，却很可能把重要的限制条件弄丢。压缩稳定性要靠带约束的回放测试结果来衡量，不能只看最终生成摘要的字数多少。

可以连续把摘要再压缩一次吗？

可以做二次压缩，但对应的风险会同步叠加。更稳妥的做法是保留原始片段的边界，第二次压缩的时候仍然从原始对话内容或者带原始来源的结构化记录里取材，不要直接压缩之前生成的纯文本摘要。

工具调用结果需要全部放进摘要吗？

不需要把所有工具返回的完整内容全部复制进上下文，但必须保存结果状态、核心关键字段、来源编号和对应的时间点。“计划调用”的动作不能被写成“已经完成”，调用失败的结果也不能直接省略掉。

把“能继续聊天”改成“能通过回放”

上下文压缩真正要解决的从来不是把对话弄得越来越短，而是保证下一轮对话的处理逻辑仍然严格遵守之前双方已经确认过的所有边界。把摘要当成有明确字段、有版本号、可回放验证的中间状态，再用约束、时间线和工具结果三类探针持续做验收，才能确认省出来的输入空间没有带来新的隐性风险。