上下文窗口不是越大越好：200K 的成本结构

今年主流模型的窗口普遍涨到 128K 到 1000K，但窗口大小和有效信息量是两件事。我们统计了自己线上的一批请求，发现超过七成的对话在 8K 以内就已经收敛，剩下三成里真正需要跨文档比对的不到 5%。也就是说，绝大多数请求把长上下文当成了默认配置，付了不必要的钱。 成本结构上，输入 token 占比高的任务对窗口最敏感。一次 60K 输入的摘要请求，按 GPT-6 Astra 官方价计算约 ¥0.72，而把同样的内容先做一次分段抽取再合并，总输入可以压到 20K，成本降到三分之一，质量损失在可接受范围内。 工程上更实用的做法是三级策略：短请求走小窗口模型，中等长度走摘要加检索，只有确实需要全局推理的任务才放开长窗口。同时把「上下文长度」作为监控指标之一，超过阈值的请求单独打点，定期回看是否真的必要。窗口是能力上限，不是默认参数。 最后是一个容易被忽略的副作用：长上下文会稀释注意力。我们对比了同一份合同在 8K 与 60K 输入下的条款抽取结果，长输入的正确率反而低 4 个百分点。窗口足够时，把内容组织好比分片塞进去更重要。