登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  人工智能

多轮对话如何避免上下文越变越长:摘要触发点与最近消息窗口

来源:17golang原创

时间:2026-08-27 05:48:38 328浏览 收藏

客服助手上线一周后,最先暴露的通常不是模型不会回答,而是同一个会话聊到几十轮以后,旧约束悄悄消失:用户说过“只查华东仓”,后面的摘要只留下了“查库存”,模型于是把全国结果混进来。解决办法不是把窗口一味做大,而是把历史消息分成可压缩内容、必须保留的事实和最近对话三层,并在接近预算时才触发摘要。

实践要点:
  • 用输入 token 预算决定摘要触发点,不等请求失败才处理。
  • 保留一份带来源的关键事实,摘要只覆盖更早历史。
  • 最近消息按 token 预算保留,压缩后用固定回放样例检查约束和未完成动作。

先把上下文拆成三块,再决定删什么

一个稳定的请求上下文可以写成:

系统规则 + 关键事实 + 最近消息窗口 + 本轮用户问题

系统规则负责行为边界,关键事实保存用户明确给出的约束,最近消息窗口保留语气、指代和正在进行的动作。最早的闲聊、已经完成的搜索过程和重复解释,才适合进入摘要。这里别急着按消息条数截断,因为一条很短的消息可能包含“不要修改生产库”这样的高价值约束。

区域默认处理不能丢的内容
系统规则每次都带上安全边界、工具权限、输出格式
关键事实结构化保存范围、偏好、已确认参数、未完成任务
最近消息保留最近 6–12 轮当前指代、错误信息、用户刚改的要求
更早历史摘要或移除只保留仍影响当前任务的结论

摘要触发点不要等到请求失败才处理

触发点应该由预算倒推,而不是等接口返回“上下文过长”。假设模型上下文上限是 128000,给输出预留 4096,系统还需要 8000 的安全余量,那么历史区的目标上限大约是:

history_budget = 128000 - 4096 - 8000 - current_user_tokens

实际项目里可以在达到历史预算的 70%~80% 时启动压缩,给摘要请求和重试留出空间。摘要请求本身也要使用独立的小窗口,不要把全部原文再塞回去。

if estimated_tokens(system + facts + recent + current) > history_budget:
    summary = summarize(older_messages, keep=facts_and_open_tasks)
    context = system + facts + summary + recent + current

估算值不必假装精确。只要 tokenizer、模型和计费口径保持一致,触发点稳定比“刚好卡在上限前”更重要。

关键事实要带来源,摘要不能凭空改写约束

建议把摘要结果和事实分开存储。事实不是一段漂亮的自然语言,而是下一轮仍要执行的约束:

{
  "scope": "华东仓",
  "format": "只返回缺货商品",
  "confirmed_at_turn": 8,
  "source": "user_message_8",
  "open_task": "等待用户确认是否导出 CSV"
}

摘要可以描述“前面已经查过华东仓库存”,但不能覆盖结构化事实中的范围字段。若摘要模型把“只看华东仓”改成“优先看华东仓”,就应该被事实一致性检查拦住,而不是继续发送给主模型。

多轮对话上下文治理决策路径:预算接近阈值后拆分关键事实、摘要与最近消息窗口

最近消息窗口保留多少轮,取决于任务形态

固定保留 10 轮只是起点。指代密集的客服对话可能需要更多最近消息;单次任务型助手则更适合保留最近动作、工具结果和未完成清单。可以先按 token 而不是轮数截取:

recent = take_from_newest(messages, max_tokens=12000)
older = messages[0:len(messages)-len(recent)]

如果一轮包含很长的工具返回,先压缩工具原始输出,只保留查询条件、结果摘要、错误码和可追溯 ID。不要把完整日志当作聊天记忆;需要时再通过 ID 读取。

用回放样例验证压缩后有没有“记错人和事”

上线前至少准备三类回放:约束保持、指代保持和未完成动作。每类都记录压缩前的期望结果,然后在相同随机参数下运行压缩后的上下文。

  1. 约束保持:用户先指定“华东仓、只看缺货”,压缩后追问库存,结果中不得出现华南仓或有货商品。
  2. 指代保持:用户说“把第二个方案改成按周统计”,压缩后仍能知道“第二个方案”指哪一项。
  3. 动作保持:对话停在“等待确认后导出 CSV”,压缩后不能直接声称文件已经生成。

验收结果至少看三项:关键事实命中率、未完成任务保留率、压缩前后答案是否引入新实体。只看最终文本像不像人写的,抓不住最危险的约束漂移。

上下文压缩回放验收:压缩前后的关键事实、最近消息和未完成动作逐项对照

相关问题:摘要成功了,答案却更不可靠

为什么摘要越短,回答反而越容易跑偏?

因为摘要把条件和结论一起压掉了。保留“查过库存”没有保留“只查华东仓、只看缺货”,主模型当然无法恢复这些细节。短不是目标,影响当前任务的事实完整才是目标。

关键事实应该每轮都重新抽取吗?

不必每轮全量抽取。可以只对新消息做增量提取,再与已有事实合并;当用户明确说“改成”或“取消”时,要求新事实覆盖旧事实,并保留变更来源。

什么时候应该彻底开启新会话?

当任务目标、权限范围或数据主体发生变化,继续复用旧摘要的风险通常高于重新开始。新会话可以携带经过确认的少量事实,但不要直接复制整段历史。

一份可落地的上线检查清单

发布前逐项确认:是否有明确的 token 预算;是否把系统规则、关键事实、最近消息和更早历史分层;摘要是否记录来源和未完成动作;工具长输出是否可按 ID 追溯;压缩触发后是否只请求一次摘要;回放样例是否覆盖约束、指代和恢复路径。

上下文管理的核心不是让模型“记住更多”,而是让它在有限窗口里记住正确的东西。把触发点、事实存储和回放验收连成一条流水线,长对话才不会在最关键的一轮突然换了范围。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>