长上下文这几年像军备赛一样卷：128K、200K、1M、甚至更长。窗口越来越大，但「窗口大」不等于「用得好」。很多团队花了大价钱接入 1M 模型，结果发现实际效果还不如一个认真做 RAG 的 128K 模型。选型这件事，从「谁窗口大」变成了「谁的钱花得值」。
窗口越大，成本就一定越高吗？
表面看是——输入 token 多了，账单自然涨。但这里有个被忽略的非线性关系：长窗口模型在「无需召回」的场景下，反而比 RAG 便宜。RAG 要做切片、嵌入、向量库、多次召回、多轮拼接，工程链路长、维护成本高、召回质量还不稳。如果你的任务数据总量稳定在几十万字以内，直接整篇塞进长上下文模型，端到端成本可能比 RAG 还低。关键是算总账，不是算单 token 价。
什么场景真的需要 1M 窗口？
不是所有任务都需要。写邮件、做摘要、简单问答，8K 窗口绰绰有余。真正需要长窗口的是三类：第一，全代码库理解与跨文件重构；第二，超长文档的全局一致性分析（合同、专利、标书）；第三，长视频或多文件项目的整体理解。这些任务的共同点是——局部切片会破坏全局逻辑，你必须让模型「一眼看全」。其余场景，用短窗口加 RAG 更划算。
选型时应该看哪三个指标？
一是长上下文「末端召回率」——很多模型窗口标称 1M，但信息塞到后半段就开始失忆，要测「大海捞针」在 90% 位置还能不能准确找到。二是输出耐力——前面说过，输入大不等于输出稳。三是单位任务总成本——包括工程维护费。对一人公司和小团队，我的建议是：先用最便宜的小模型跑通业务，只有当 RAG 确实成为瓶颈时，再升级到长窗口模型。不要为你用不到的窗口买单。
去论坛讨论
前往 silicon-agi.com 论坛 参与讨论
