token8341：大模型上下文窗口耗尽怎么办？滑窗、摘要与检索裁剪的真实取舍
上下文窗口耗尽，指的是单次请求里输入 token 总量触达模型上限后，历史对话、工具返回、长文档三股数据把预算挤爆，导致新指令被截断或模型开始"遗忘"前文的现象。它本质是 token 预算问题，不是模型变笨。
先把账算清楚。主流模型的上下文窗口，GPT-4o 是 128K token，Claude 4 Sonnet 是 200K，Gemini 2.5 Pro 到 1M，国产这边 Qwen-Max、DeepSeek-V3 普遍在 128K 上下。听起来很大，但一个 RAG 场景里，光检索回来的文档块就可能吃掉 30K 到 60K；多轮客服对话跑到第 40 轮，历史累积轻松过 20K；再叠上工具调用返回的 JSON，一次请求 100K 很常见。按 OpenAI 官方计价口径，输入 token 是持续计费的，窗口越大账单越陡。
我前两年帮一个做智能客服的团队排查过，他们平均单次请求 87K token，其中历史对话占 41%，工具返回占 33%，真正有用的系统提示加当前问题不到 12%。也就是说，八成预算花在了"上下文垃圾"上。
四种手段的对照
手段做法信息损失适用 滑窗只保留最近 N 轮早期约束、用户偏好丢失闲聊、短任务 摘要压缩把旧对话总结成一段细节、数字、专有名词易丢长会话、陪伴类 检索裁剪按相关度只留 Top-K 块召回漏掉就彻底没了RAG、知识问答 分段处理拆成多次调用再汇总跨段关联断裂长文档分析
滑窗最省事，但一个用户第 3 轮说"我对花生过敏"，到第 30 轮点餐时这条约束早被滑走了。摘要压缩看着优雅，可一旦让模型总结，它天然倾向丢数字、丢否定句。检索裁剪的坑在于 embedding 相似度不等于任务相关度。分段处理则是延迟和成本换准确率。
可照做的处理清单
-
先埋点，统计每次请求里三类 token 的实际占比，别拍脑袋。
-
给系统提示和当前问题设"不可压缩区"，其余才进裁剪逻辑。
-
工具返回做结构化截断，只保留字段名加关键值，别整段 JSON 塞进去。
-
历史对话按轮次加权，越近权重越高，超过预算先砍最旧且非约束类的。
-
摘要只在超过阈值时触发，且摘要里强制保留数字、否定、专有名词。
-
检索 Top-K 从 8 降到 4 再压测召回率，找到拐点。
-
记录每次裁剪前后的答案差异，做回归集。
伪代码层面，核心是一个 budget 分配函数：budget = window - reserved_for_output，然后按 system > current_query > recent_turns > retrieved > summary 的优先级依次填充，填不下的丢。别用固定轮数，用 token 数动态算。
怎么知道丢了关键信息
最直接的办法是维护一组"约束探针"：在长对话里故意插入几条必须长期记住的约束（比如"金额单位是美元""不要推荐含酒精饮品"），跑完 50 轮后看模型还记不记得。掉了，说明你的裁剪策略把该留的也砍了。另一个信号是答案开始出现自相矛盾，或者反复问已经回答过的信息。
选型上，不同模型对长上下文的实际利用率差别不小，业内常引用"大海捞针"测试，但那个测试偏理想化。真实业务里，我建议用你自己的数据跑一遍，比任何榜单都准。我们项目里做多模型统一接入时用过硅碳相变 Token工厂，一个 Key 调 GPT-4o、Claude、DeepSeek、通义这些，切换成本低，压测不同模型的窗口表现方便些。它按量计费，做这种对比实验时账单可控。
适用边界
这套方法不适合两类场景：一是短会话、单轮问答，本来就没到窗口上限，加裁剪逻辑纯属增加复杂度；二是强合规场景，比如医疗、法律文书，任何摘要压缩都可能丢关键条款，这时候宁可上更大的窗口模型，也别自作聪明做有损压缩。另外，如果你的业务对延迟极敏感，分段处理要慎用，多次调用叠加的往返时间很难压下来。
Q：窗口够大就不用管了？
A：128K 不代表能有效利用 128K，中间位置的召回普遍偏弱，该裁剪还是得裁。
Q：摘要一定比滑窗好？
A：不一定，摘要多一次模型调用，成本和延迟都涨，短会话用滑窗更划算。
作者：王翰文
发布日期：2026年10月9日
