RAG 检索还是长上下文？先算一笔账再决定

长上下文和 RAG 检索不是二选一的信仰之争，是一道算术题：文档是否稳定复用、每次是否只用到一小部分、是否需要跨全文的关联。这三个问题的答案决定了哪种更省，而不是哪种更时髦。

这篇给判断规则和成本口径。想边看边算，用上下文长度计算器把两种方案的 token 量分别换算一遍。

两种方案的成本长什么样

整份塞进上下文：每次请求都要为整份文档付输入费。文档十万 token，问十个问题就是一百万 token 的输入——除非命中缓存。而且长上下文常常跳到更贵的计费档。

检索出片段：每次只为相关的几段付费，可能只有几千 token。但你多了两笔成本：切片和向量化的一次性费用（embedding 通常很便宜），以及检索服务的运维成本（自建索引或用托管服务）。

粗略地说：问的次数越多，检索的优势越大；只问一两次的一次性任务，整份塞进去反而更省事。

但成本不是唯一维度，效果也不同

一个常见误解是「全塞进去信息最全，所以效果最好」。实际上超长上下文里，关键信息被埋在中间时，模型的召回稳定性通常不如短上下文。噪声多了，模型也会被带偏。

检索的效果风险在另一头：检索不到就等于没有。如果切片策略差、查询改写没做好，相关段落根本没被召回，模型只能基于残缺信息回答，而且它不会告诉你缺了什么。

所以两者的失败模式不同：长上下文是「有信息但没找准」，检索是「压根没给到信息」。前者靠缩短上下文缓解，后者靠改进召回缓解。

三个问题决定选哪个

问题一：这份文档会被反复用吗？

会——优先考虑长上下文加提示缓存。固定前缀命中缓存后按很低的折扣计费，重复问的成本大幅下降。这是最容易被忽略的组合。

不会，每次文档都不同——检索的一次性索引成本摊不下来，如果文档不算太长，直接塞进上下文更省事。

问题二：每次问题是否只涉及文档的一小部分？

是——检索完胜。用户问的是第三章的一个细节，没必要为整本书付费。

不是，问题需要跨章节汇总——检索会切断关联，长上下文更合适。典型例子：让模型总结整份报告的核心矛盾、检查整个代码库的命名一致性。

问题三：文档库有多大？

超过窗口上限的，检索不是选择而是唯一解。这时候问题不再是「哪个更省」，而是「怎么把检索做准」。

常见的是两者叠加，不是二选一

成熟系统里最常见的架构其实是组合：

检索缩范围 + 缓存复用固定前缀。先用检索把候选压到几千 token，再把稳定不变的部分（system prompt、工具定义、常驻知识）放在请求前缀交给缓存。前者控住变量部分的长度，后者压住固定部分的单价。

粗检索 + 长上下文精读。先用便宜的检索召回一批候选段落（宁多勿少），再一次性塞进长窗口让模型自己筛。这种做法在召回质量不稳定时很实用——用长窗口的容错换检索精度的不足。

小模型检索判断 + 大模型回答。用轻量档模型判断「这个问题需要哪些片段」，再让旗舰模型基于这些片段回答。省下的是旗舰模型的输入 token。

算账的模板

拿你的真实场景代一遍：

• 方案 A（整份）：文档 token × 日提问次数 × 30 × 输入单价。若能命中缓存，把命中部分按缓存价重算一遍。
• 方案 B（检索）：（片段 token + 固定前缀 token）× 日提问次数 × 30 × 输入单价 + 索引与检索服务成本。

两个数字代进月成本估算器对比。多数情况下，提问次数超过某个临界点后 B 会明显便宜；临界点具体在哪，取决于文档长度和缓存命中率。

检索方案里，切片策略直接影响成本

同一份文档，切法不同，最终送进上下文的 token 量能差一倍。

切太碎：单片信息不完整，为了保证覆盖只能召回更多片，总 token 反而上去了，而且拼接起来的上下文支离破碎，模型容易答偏。

切太大：一片里塞了大量无关内容，召回一片就带进来一堆噪声，既费钱又干扰判断。

实用的折中是按语义边界切（标题、段落、条款），并在片与片之间留少量重叠避免边界信息丢失。重叠是有成本的，但通常比因为切断关键句而答错要划算。

另一个常被忽略的成本项是召回数量。很多实现默认召回固定条数，不管相关性如何。更省的做法是设相关性阈值，低于阈值的不带进去——宁可少给，也别用无关片段填满上下文。

怎么判断召回质量够不够

检索方案最危险的失败模式是「静默漏召」：相关段落没被找到，模型基于残缺信息编了一个看起来合理的答案。这个问题不看指标是发现不了的。

最小可用的评估方法：准备三十到五十条真实问题，人工标注每条问题应该命中哪些片段，然后跑检索看实际命中率。这件事一次性投入不大，但能把「检索到底行不行」从感觉变成数字。

命中率不达标时，优先级依次是：改进查询改写（把用户口语转成检索友好的表述）、调整切片策略、加入关键词与向量的混合检索、最后才是换更强的 embedding 模型。

文档更新频率也是决策变量

一个容易被忽略的维度：你的文档多久变一次。

几乎不变的文档（法规、产品手册、历史资料）：检索索引建一次能用很久，摊销成本极低；也很适合提示缓存，因为前缀稳定。两种方案都好，按提问频次选即可。

每天都在变的文档（工单、日志、实时数据）：索引需要持续增量更新，运维成本明显上升；提示缓存也会因为内容变化频繁失效。这种场景下，直接把当次需要的数据塞进上下文往往更简单，尤其当单次数据量不大时。

部分变动的文档（知识库有新增但旧条目稳定）：最适合分层——稳定部分做索引加缓存，变动部分每次实时带上。

所以「检索还是长上下文」这个问题，除了看提问频次和文档大小，还要看变更频率。三个维度一起看，结论通常就很清楚了。

别忽略工程复杂度这笔隐性成本

检索方案要做切片、向量化、索引维护、查询改写、召回评估，还要处理文档更新后的重建。这些都是持续的工程投入。

如果你的项目还在验证阶段、文档量不大，先用长上下文把功能跑通，等量上来再上检索，通常比一开始就搭一套检索系统更划算。先让它对，再让它省。

想把上下文这一侧的取舍看得更细，接着读上下文长度怎么选和长文本任务的四个成本陷阱。