百万 token 上下文普及后，RAG 还值不值得做

上周连着两条模型更新又把上下文窗口这个参数往上推了一截。9 月 22 日 Anthropic 发布 Claude Opus 5.5默认上下文 100 万 token、单次最多输出 12.8 万 token输入输出定价每百万 token 4 美元和 20 美元缓存读取 0.2 美元一周后 9 月 29 日OpenAI 的 GPT-6.1 Sol 把上下文拉到约 105 万 token定价 2 美元和 10 美元以上均据报道。同一个星期里两家头部厂商在做同一件事把能塞进去的文档量做大同时把单价往下压。每次这种新闻出来评论区都会冒出一句RAG 要死了。这话 2024 年就说过一轮2025 年又反转回去。所以先把两件事分清楚窗口变大是真的但能塞进去和该塞进去是两码事。变了什么没变什么变的是三样东西。窗口到了百万级把一整份合同、一个中小型仓库的代码、一整本操作手册塞进去已经技术上可行单价这一代普遍降了 20% 左右缓存读取更便宜输出速度也提了一档。以前要绕着走的场景现在能直着走。没变的是另外三样。一是上下文窗口不等于有效上下文。据相关的模型评测研究上下文腐烂是个真实现象——模型性能随输入变长是非均匀退化的真正的有效上下文大概只有窗口的 30% 到 60%具体看任务。也就是说 100 万 token 的窗口能稳定用上的可能就几十万中间位置的信息最容易被忽略。二是成本仍随 token 线性增长。把 100 万 token 整篇喂进去光输入就 4 美元一次。对话还得每轮重发长链路 Agent 每一轮都要重传上下文和工具描述账单很快就不是订阅费能覆盖的。缓存能把重复部分压到 0.2 美元/百万但缓存有生存时间过期后第一次仍按标准价重算。三是延迟。token 越多首字延迟越长这是 transformer 的结构决定的短时间改不了。结论很朴素这两年在长上下文和 RAG 之间来回摇摆、还按整个产品押注单一架构的团队很多是当年没把账算细。2026 年更合理的做法是按单个功能分别决定。上手先算账再选架构别凭感觉选。下面这段纯标准库的 Python 可以直接跑改数字就行# 长上下文 vs 检索单次请求成本粗算纯标准库可运行defcost(input_tokens,output_tokens,price_in,price_out):returninput_tokens/1_000_000*price_inoutput_tokens/1_000_000*price_out OPUS_IN,OPUS_OUT4.0,20.0# 美元/百万 tokenOpus 5.5 标准价SOL_IN,SOL_OUT2.0,10.0# GPT-6.1 Sol 标准价full_doc300_000# 把 30 万 token 的文档整篇塞进去retrieved6_000# 检索后只带 6 千 token 的片段out800# 回答长度print(整篇塞入 Opus:,cost(full_doc,out,OPUS_IN,OPUS_OUT))print(检索后 Opus: ,cost(retrieved,out,OPUS_IN,OPUS_OUT))print(整篇塞入 Sol: ,cost(full_doc,out,SOL_IN,SOL_OUT))print(检索后 Sol: ,cost(retrieved,out,SOL_IN,SOL_OUT))跑一下就能看到整篇塞入比检索贵一到两个数量级。再乘上每轮对话的次数、每天的调用量差距就非常具体了。注意价格会随版本变跑之前去官网核一遍。第二个动作是把便宜的地方用满。把重复的前缀——系统提示、工具定义、固定的参考文档——固定放在最前面并打开缓存缓存读按 0.2 美元/百万算能压掉大头但记住缓存会过期隔一段时间没命中就得重算。调接口时模型 id 用官方公布的那个这一代是claude-opus-5-5走标准 messages 结构即可# 真实的 Anthropic 调用形态模型 id 与请求结构以官方文档为准fromanthropicimportAnthropic clientAnthropic()# 读环境变量 ANTHROPIC_API_KEYrespclient.messages.create(modelclaude-opus-5-5,max_tokens4096,system把固定不变的系统提示放这里便于命中缓存,messages[{role:user,content:把这份模块重构一下并说明改动原因。}],)print(resp.content[0].text)## 几个容易踩的坑-**把大窗口当成越大越稳。**中间位置的信息最容易被跳过。长文档里插一句关键约束模型未必抓得住重要要求尽量放头尾、或者重复一次。--**忽略阶梯定价。**有的模型输入超过某一档比如27万 token会整次请求按更高倍率计费长文档加长回答很容易踩线成本不是线性的。--**忘了输出也是钱。**输出单价通常是输入的五倍上下。让模型顺手把全文总结一遍会同时顶高输入和输出两头。--**觉得检索是免费的。**向量库要维护重新切块和重新嵌入的预算一般占每月推理支出约两成还要算上维护 pipeline 的人力。只比模型账单会比出错误结论。## 收尾窗口变大是好事但它解决的是能不能放进去不是该不该放进去。真正决定架构的是每个功能的四个属性数据量、查询频率、对延迟的容忍度、以及缓存能不能命中。 你现在做知识库、做 Agent是整篇塞还是老老实实检索还是两者混着用评论区聊聊你的选择和踩过的坑。