聊天记录、知识库片段和工具返回结果不断累积后，AI应用很容易遇到上下文过长、响应变慢和成本上升的问题。把全部历史内容原样传给模型，看似不会遗漏信息，实际却会增加噪声。
长上下文带来的三个问题
第一是输入Token增加，单次请求价格上升；第二是模型需要在大量无关内容中寻找重点；第三是上下文接近上限后，系统必须截断内容，导致结果突然不稳定。
历史消息不能简单按条数删除
只保留最近十条消息，可能删除了用户最初的目标、重要约束和已确认结论。更合理的方式是按照信息价值裁剪：保留当前任务、关键事实、未完成事项和用户明确偏好。
- 删除寒暄和重复确认；
- 合并已经解决的问题；
- 保留尚未完成的行动项；
- 为每条重要信息附上时间和来源。
分层摘要比一份长摘要更好维护
可以把记忆分成会话摘要、用户画像、项目事实和任务状态四层。会话摘要记录最近进展，项目事实保存稳定信息，任务状态说明下一步动作。不同请求只加载需要的层级。
摘要要避免把推测写成事实
模型生成摘要时，应该区分用户明确说过的内容、系统确认过的内容和模型推测。可以使用“已确认”“待确认”“可能”这样的状态字段，避免错误记忆长期影响后续答案。
检索片段也要做压缩
RAG系统不应把整篇文档全部塞入上下文。检索后可以保留标题、相关段落、结论、来源和更新时间，删除与问题无关的导航、重复说明和页面模板。
什么时候适合使用摘要
长对话、会议纪要、客服记录和项目文档适合使用摘要。法律条款、金额、技术参数和安全规则等高风险内容，不应只保留模型摘要，必要时仍要回到原文核对。
用数据衡量压缩效果
- 平均输入Token是否下降；
- 答案命中率是否变化；
- 摘要后关键信息保留率；
- 延迟、失败率和重试率；
- 不同场景下的实际成本。
总结
长上下文优化不是无条件删除历史，而是对信息分层、压缩和按需加载。保留目标、事实、证据和状态，减少重复与噪声，才能同时改善效果、速度和Token成本。
评论 0