为什么需要上下文窗口管理
即便是旗舰档模型,上下文窗口也不是无限的。当对话轮次增加、RAG 检索结果膨胀或需要处理长文档时,开发者必须主动决定哪些内容保留、哪些丢弃。不同的管理策略直接影响应用的响应质量、成本和用户体验。
五种主流方案对比
1. 硬截断(Truncation)
最简单粗暴:超过窗口上限就从头或从尾切掉。适合单次查询场景,比如文档摘要、代码审查。优势是实现零成本,劣势是可能丢失关键信息——假设你让模型总结一份 20 页报告,硬截断可能导致结论部分被砍掉。
工程建议:仅用于无状态任务;如果必须用,优先保留尾部(最新信息通常更重要)。
2. 滑动窗口(Sliding Window)
保留最近 N 条消息,旧消息自动淘汰。这是多轮对话的标准做法。假设窗口设为 10 条,第 11 条消息进来时,第 1 条被移出。优势是保持对话连贯性,劣势是长期上下文会丢失——用户在第 1 轮提到的需求,第 15 轮时模型已经"忘记"。
工程建议:配合系统提示词固定关键信息(如用户偏好、任务目标),避免核心指令被滑出窗口。
3. 摘要压缩(Summarization)
定期用轻量档模型把旧对话压缩成摘要,摘要本身占用更少 token。假设一个客服 Agent 已经聊了 50 轮,可以每 10 轮生成一次摘要,后续请求只带摘要 + 最近 10 条原始消息。优势是兼顾长期记忆与成本,劣势是摘要质量依赖模型能力,且增加额外调用。
工程建议:用异步任务做摘要,避免阻塞主流程;摘要粒度可按业务调整(技术支持场景保留问题编号,销售场景保留客户意向)。
4. 语义检索(Semantic Retrieval)
把历史对话存入向量库,每次请求时检索最相关的 K 条。这是 RAG 的变体,适合知识密集型应用。假设一个法律咨询 Bot,用户第 20 轮问到合同条款,系统可以召回第 3 轮讨论过的相关内容,即便中间隔了 17 轮无关对话。优势是精准调用长期记忆,劣势是引入向量库依赖和检索延迟。
工程建议:对话嵌入时加时间戳和角色标签(user/assistant),检索时可按时间衰减权重;冷启动阶段直接用滑动窗口,对话超过阈值(如 20 条)再启用检索。
5. 混合策略(Hybrid)
组合上述方案:系统提示词(固定)+ 语义检索(长期记忆)+ 滑动窗口(短期上下文)+ 当前输入。假设构建一个项目管理 Agent:
- 系统提示词:团队规则、术语表(200 token)
- 检索:相关历史任务讨论(500 token)
- 滑动窗口:最近 5 轮对话(800 token)
- 当前输入:用户新问题(200 token)
总计 1700 token 送入模型,既保留全局视野又控制成本。
工程建议:预留 20% buffer 应对输入波动;监控各部分 token 占比,动态调整窗口大小。
选型决策树
- 单次任务(翻译、摘要):硬截断
- 短对话(客服前 10 轮):滑动窗口
- 长对话 + 预算有限:摘要压缩
- 长对话 + 需要精准记忆:语义检索
- 复杂业务场景:混合策略
实施注意事项
- Token 计数精度:不同模型的 tokenizer 不同,用官方库计数(如 tiktoken),别用字符数估算
- 优雅降级:窗口满时给用户明确提示("对话过长,已保留最近内容"),别让模型突然"失忆"
- 成本监控:摘要和检索都有额外调用,记得在日志里拆分各环节成本
如果你的团队正在构建 LLM 应用,需要在上下文管理、成本优化或多模型编排上获得定制化建议,欢迎联系 Taylent Labs 探讨技术方案。