长上下文降价之后，我的RAG下线评审开了三次才通过
一个管理者的真实纠结
长上下文模型的价格持续下探，这是过去一年行业里最确定的趋势之一。百万级token窗口从旗舰特权变成标配，单位成本降到了很多团队“可以直接把整个知识库塞进去试试”的水平。
于是团队里出现了一种声音：“RAG是不是可以拆了？检索管线维护成本高，切片质量吵架吵了半年，向量库的账单也不便宜。现在长上下文这么便宜，全量塞进去，一个调用解决问题。”
作为管理者，我没有立刻表态，而是让团队做了三次评审。这篇文章记录的是这三次评审里我们讨论的问题，以及最终落地的折中方案。它不是技术结论，而是一套决策流程。
第一次评审：先算总账，不算单价
第一次评审，我们定了一条规矩：禁止只比较单价，必须比较单位任务成本。
团队很快发现，长上下文的成本结构不是线性的：
- 输入token按全量计费，且每次调用都重复计费。RAG只发送检索命中的片段，长上下文每次都发送全库。单价下降十倍，全量输入可能让总量上升百倍。
- 长上下文计费普遍分段，超长输入的单价显著更高。降价降的是“能用”，不是“随便用”。
- 缓存可以缓解，但知识库内容一旦有更新，缓存就大面积失效。我们内部Wiki的日更率不低，缓存命中率模拟下来并不乐观。
评审结论：对高频调用场景（客服机器人、内部问答），全量塞入的总成本仍高于RAG；对低频场景（周报汇总、季度文档审阅），长上下文确实已经便宜到可以直接用。
这一步的启示是：降价改变的不是“要不要RAG”，而是“哪些场景必须RAG”。 作为管理者，我要求团队按调用频率×知识库规模做了一个四象限矩阵，逐场景标记，而不是一刀切。
第二次评审：责任边界与风险控制
第二次评审讨论的是架构背后的组织问题。这是很多技术文章不谈、但管理者必须谈的部分。
RAG的一个被低估的价值是“可审计性”。 检索命中了哪些片段、来源是哪份文档、置信度如何——这些都有日志，出了错可以追溯到源头。换成全量塞入，模型的回答依据淹没在几十万token里，一旦业务方质疑“这个结论从哪来的”，排查成本急剧上升。
对涉密、合规、对外承诺类内容，这不是效率问题，是责任归属问题。我们最终的判断：凡是回答错误会引发客户投诉或合规风险的场景，保留检索层，理由不是效果，而是留痕。
另一个风险是权限控制。RAG的检索层天然可以挂权限过滤——用户能检索到的，取决于他的文档权限。全量塞入意味着每次调用都携带全库内容，权限边界从“数据层”被推到了“提示词层”，而提示词层的权限控制脆弱得多。如果通过第三方API调用，敏感文档全量出域，这个决定法务不会签字。
第三次评审：协作分工怎么变
第三次评审谈人。架构变化必然改变团队协作，管理者要提前回答“那谁来做”。
我们的调整方案：
- RAG团队不减员，转岗职责。从“打磨切片和召回”转向“维护场景路由规则和维护知识库文档治理”。降价省下的钱，一部分投到了文档质量上——这是很多团队忽略的一点：垃圾进，垃圾出，长上下文不会拯救混乱的知识库，只会让模型在一堆过期文档里更自信地胡说。
- 建立路由层的评审机制。哪些场景走长上下文直塞、哪些走RAG、哪些走混合（先检索定位文档，再以长上下文送入完整文档），从架构师的个人判断升级为每月一次的成本+质量复盘，数据说话。
- 模型选择解耦。长上下文便宜化之后，我们在网关层配置了多模型路由：简单问答走小模型+RAG，复杂分析走长上下文大模型。单一模型包打天下的时代结束了，接入层需要能灵活切换。
给开发者的应对建议
如果你也在面对同样的决策，建议按这个顺序走：
- 先做调用频率×知识规模矩阵，不要用单一场景的结论覆盖全部业务。
- 拉一个月的真实日志算单位任务成本，包含重复输入的浪费，而不是看官网单价表。
- 凡是需要回答溯源和权限隔离的场景，保留检索层，把它当作风控组件而非性能组件。
- 把省下的预算投到知识库治理，文档的时效性和结构化程度决定两种架构的上限。
- 接入层保持模型可切换，价格还在变动，别让任何架构决策焊死在某个供应商的价目表上。
结语
长上下文降价没有让RAG过时，它让RAG从“默认架构”变成了“可选组件”——而选择权，第一次真正交到了会算账的团队手里。如果你还在为多模型路由、统一接入和成本观测发愁，可以试试 Thistoken 的统一网关，注册入口在这里：https://api.thistoken.ai/register
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。