RAG 和长上下文哪个划算：RAG 成本怎么算
上下文窗口一路变长之后，我在几个群里反复看到同一个问题：既然现在能一次塞进几十万 token，那我还费劲搭什么向量库、调什么分块策略，直接把整份文档丢进去不就完了？
这个问题不能一句话回答，因为它其实是个成本问题，而不是技术问题。技术上两条路都走得通，谁更划算取决于两个变量：你的文档总量有多大，以及回答一次问题真正用得上的比例有多小。这两个数你自己算得出来，算出来之后该走哪条路基本就定了。下面我把这套账拆开算给你看，顺便把很多人只算 token 不算的那部分隐性成本补上——那部分才是 RAG 真正贵的地方。
先把判断框架立起来
抛开所有细节，两条路的本质差别就一句话：
- 全量塞入：每次调用都为整份文档付一遍输入费。文档多大，你每次就付多少。
- RAG：先付一笔一次性的索引成本，之后每次只为”检索出来的那几块”付输入费，另外每个月还要养着一套检索设施。
也就是说，RAG 做的事情是把「每次全付」换成「一次性 + 每次少付」。这是一个非常典型的固定成本换变动成本的结构。结论几乎是自动的：
调用频次越高、单次相关比例越低，RAG 越划算；调用频次越低、文档总量本来就不大，全量塞入越划算。
很多团队做决策时跳过了”调用频次”这一项，只盯着”我的文档有 30 万字，装不装得下”，那是只看了一半。一个每月被问 5 次的内部制度问答，和一个每月被问 5 万次的客服机器人，答案完全相反。
顺带说一句，如果你现在纠结的是”文档到底装不装得下”这个层面的问题，先去把窗口超限这件事本身搞清楚，见 上下文超限怎么办，本文默认你已经知道自己文档的 token 量级。
两条路的成本结构，写成公式
我们把变量定义清楚，后面所有算例都套这套符号。
| 符号 | 含义 |
|---|---|
D | 文档总量（token） |
R | RAG 每次实际拼进上下文的相关片段量（token） |
P | 输入价格（元 / 百万 token） |
N | 每月调用次数 |
c | RAG 每次调用的检索侧成本（查询向量化 + 库查询，元 / 次） |
F | 检索设施的月固定开销（实例、存储、运维分摊，元 / 月） |
C0 | 一次性全量索引成本（元，只在建库那个月付） |
两条路的月成本：
全量塞入：Cost_full = N × D × P / 1,000,000
RAG（稳态月）：Cost_rag = F + N × (R × P / 1,000,000 + c)
RAG（建库首月）：Cost_rag = C0 + F + N × (R × P / 1,000,000 + c)
令两者相等，解出盈亏平衡的调用次数：
N* = F / ( D×P/1,000,000 − R×P/1,000,000 − c )
分母那一项就是”RAG 每次比全量省下来的钱”。用每月省下的钱去摊掉每月的固定开销 F，摊得平就用 RAG，摊不平就别用。整个决策就这么一个式子。
代入数字算一遍
下面所有价格与成本参数都是我为了演示算术设的假设值，不对应任何厂商、任何产品的报价。 真实单价请查你所用服务的官方价格表和你自己的账单，把数字换掉重算——公式是通用的，数字必须是你自己的。
假设参数：
| 参数 | 假设值 | 说明 |
|---|---|---|
D | 200,000 token | 一份中等规模的产品知识库 |
R | 8,000 token | 检索出的片段 + 提示词其余部分 |
P | 2 元 / 百万 token | 假设的输入单价 |
c | 0.004 元 / 次 | 假设的检索侧每次开销 |
F | 300 元 / 月 | 假设的检索设施月固定开销 |
C0 | 100 元 | 假设的一次性索引成本 |
单次成本：
- 全量塞入：200,000 × 2 ÷ 1,000,000 = 0.4 元 / 次
- RAG：8,000 × 2 ÷ 1,000,000 = 0.016 元，加上检索 0.004 元 = 0.02 元 / 次
单次差额 = 0.4 − 0.02 = 0.38 元。
盈亏平衡点：300 ÷ 0.38 = 789.47，向上取整 790 次 / 月，约合每天 26 次。
按不同调用量摊开看：
| 月调用次数 | 全量塞入 | RAG（稳态月） | 谁便宜 |
|---|---|---|---|
| 100 | 40 元 | 300 + 2 = 302 元 | 全量便宜 262 元 |
| 500 | 200 元 | 300 + 10 = 310 元 | 全量便宜 110 元 |
| 790 | 316 元 | 300 + 15.8 = 315.8 元 | 基本打平 |
| 2,000 | 800 元 | 300 + 40 = 340 元 | RAG 便宜 460 元 |
| 10,000 | 4,000 元 | 300 + 200 = 500 元 | RAG 便宜 3,500 元 |
建库首月要把 C0 算进去：平衡点变成 (300 + 100) ÷ 0.38 = 1052.6，即 1053 次。一次性成本只影响第一个月，之后不再出现，所以别拿首月的账去否定整条路线。
这张表最该被记住的不是某个具体数字，而是它的形状：RAG 的成本曲线很平，全量塞入的成本曲线很陡。调用量从 2,000 涨到 10,000（五倍），全量的账单也涨五倍，RAG 的账单只从 340 涨到 500。规模一上来，两条线就分道扬镳了。
两个会把平衡点推着走的变量
第一个是提示词缓存。 全量塞入有个天然优势：整份文档是固定前缀，天生适合缓存。缓存命中的输入价通常低于标准输入价，具体折扣以官方价格表为准。假设命中后的有效单价是标准价的 k 倍，公式里 D×P 这一项就变成 D×k×P：
N* = F / ( D×k×P/1,000,000 − R×P/1,000,000 − c )
取 k = 0.25（同样是假设值）：全量单次变成 0.1 元，差额变成 0.1 − 0.02 = 0.08 元，平衡点 300 ÷ 0.08 = 3,750 次 / 月，约每天 125 次。缓存一开，平衡点直接右移了将近五倍。
这是很多人漏掉的一环：如果你的文档是稳定不变的固定前缀，缓存能把”每次全付”这个劣势削掉一大块，RAG 的优势区间会明显收窄。反过来，如果你的文档天天更新、缓存频繁失效，那这个优势就不存在。
第二个是单次相关比例。 上面的例子里 R/D = 8,000 / 200,000 = 4%，也就是回答一次问题只用得上 4% 的内容——这正是 RAG 的最佳场景。如果你的问题往往需要横跨半份文档，比如 R 涨到 100,000（50%）：RAG 单次变成 0.2 + 0.004 = 0.204 元，差额只剩 0.4 − 0.204 = 0.196 元，平衡点 300 ÷ 0.196 = 1,531 次 / 月，比原来翻了近一倍。相关比例越高，检索省下的那部分越少，RAG 越不值得折腾。
想把每次真正拼进去的 token 量算准，可以配合 token 成本估算方法 用真实提示词跑一遍，别靠拍脑袋。
RAG 的隐性成本：账单上看不见的那部分
上面那套算术只算了 token 和实例费。真实项目里，RAG 更贵的往往是下面这四项，它们不进 API 账单，但它们进人力和事故。
一、检索设施的存储与运维。 向量库不是丢那儿就不管了。它要占存储、要监控、要备份、要在数据涨上来之后做容量规划，还要有人在半夜挂了的时候能爬起来处理。这些成本在公式里被我压缩成一个 F，但现实中它常常主要是人的时间，而不是机器的钱。团队规模小的时候，这一项的真实代价被严重低估。
二、文档更新时的重新索引。 公式里的 C0 我写成”一次性”，那是理想情况。实际上文档是活的：产品手册改版、政策调整、新增品类，每改一次就要重新切块、重新向量化、更新索引。改动频繁的知识库，C0 根本不是一次性的，而是一个周期性重复的成本项。更麻烦的是索引和源文档不一致的时间窗——文档改了但索引没跟上，模型就会拿着旧片段一本正经地答错。
三、检索不准导致的重试与人工兜底。 这一项是四项里最贵的，也最容易被忽略。全量塞入的失败模式是”上下文太长，模型注意力分散，答得不够准”；RAG 的失败模式是召回了错误的片段，模型基于错误的资料给出一个高度自信的错误答案。这两种错误的严重程度完全不在一个量级。前者用户看得出来模型在含糊其辞，后者用户看不出来——它逻辑通顺、有引用、有细节，就是内容是错的。
一次这样的错误答案，可能引出一轮客诉、一次人工核查、一次内部复盘。你省下的那 0.38 元一次的 token 费，几百次都不够抵一次这样的事故。所以在做 RAG 成本对比时，必须把检索准确率放进决策，而不是等上线了再说。
四、分块策略调优的人力。 切多大、怎么重叠、按标题切还是按语义切、表格怎么处理，这些没有普适答案，只能拿你自己的数据反复试。这部分是纯人力投入，而且是有经验的人的时间。具体的切法取舍见 RAG 分块策略，这里只强调一点：把它当成项目里一个真实的工作量排进去，而不是”顺手调一下”。
把这四项加起来你会发现，那个 790 次的平衡点其实是偏乐观的——它只算了机器成本。加上人力和风险成本，真实平衡点会往右移不少。
什么时候干脆别用 RAG
有三类场景，我的建议是直接放弃 RAG，把文档整个塞进去，省下所有折腾。
文档总量本来就装得下，而且不会大幅增长。 比如一份几万 token 的产品手册、一套内部制度、一份 API 文档。既然一次就能装下，检索层带来的收益只是省点 token，代价却是一整套设施加上召回错误的风险。这笔交易不划算。
内容之间强交叉引用，拆开就丢关系。 法律合同的条款互相援引，技术规范的章节层层依赖，财报的数字和附注必须对照着看。这类内容的价值就在于”整体”，检索把它切成孤立片段之后，模型拿到的是残缺信息，答案质量的下降远超过省下的成本。我见过有团队给合同审查做 RAG，召回了主条款却漏了后面的例外条款，输出的结论直接是反的。
调用频次很低，摊不平固定成本。 一个每月被用几十次的内部工具，按上面的表，全量塞入才 40 元，RAG 光固定开销就 300 元，还要搭一套东西、养一套东西。这种情况下省 token 是伪命题，你省的是分子，付的是分母。
判断顺序很简单：先看装不装得下 → 装得下就看内容能不能拆 → 能拆就看调用量够不够摊平。三关都过了，再上 RAG。
混合做法：不是二选一
真实项目里最省钱也最稳的往往是中间路线，这里给两种可落地的做法。
做法一：粗检索 + 大范围完整投喂。 不追求精确召回那三五个片段，而是用检索把范围从”整个文档库”缩小到”相关的两三个章节”，然后把这几个章节较完整地放进上下文。这样既避开了全量塞入的成本，也避开了细粒度切块把上下文关系切碎的问题。检索层在这里承担的是”筛掉九成无关内容”的粗活，精读交给模型的长窗口。对交叉引用较强但总量又太大的文档，这几乎是唯一合理解。
做法二：按查询类型分流。 不同问题该走不同路：
| 查询类型 | 特征 | 走哪条路 |
|---|---|---|
| 点查型 | ”退货运费谁承担” | RAG，命中一两个片段就够 |
| 汇总型 | ”这份报告的主要结论” | 全量或大范围投喂 |
| 对比型 | ”A 方案和 B 方案差在哪” | 粗检索定位两块，完整投喂 |
| 推理型 | ”按现在的条款，这种情况适用哪条” | 粗检索 + 完整章节，避免漏例外 |
分流规则可以先用一个轻量的意图判断把查询打上标签，再路由到不同的处理链路。落地时的判断规则我一般写成三条：能被单个片段回答的走 RAG；需要跨章节归纳的走大范围投喂；拿不准的一律走大范围投喂——因为漏信息的代价高于多花点 token 的代价。
如果你决定保留检索层，重排是性价比很高的一环，它能在不增加投喂量的前提下把召回质量拉上来，见 RAG 重排怎么做；整体链路的搭法见 RAG 架构与落地。
评估检索质量的最小方法
前面反复说”检索不准的代价高于省下的 token”，那就必须有办法知道自己的检索到底准不准。我见过太多团队在这里的判断是”试了几个问题，感觉还行”——这不是评估，这是自我安慰。
最小可行的做法就三步，不需要任何复杂工具：
第一步，攒问答对。 从真实的用户提问、工单记录里挑出一批有代表性的问题，人工标出每个问题的正确答案，以及答案出自文档的哪一段。这个标注工作跑不掉，也没法自动化——它就是这套方法的成本，也是它的价值所在。覆盖面比数量重要：常见问题、边界问题、容易混淆的相似问题都要有。
第二步，分开量两件事。
- 召回质量：对每个问题跑一遍检索，看标注的那个正确段落有没有出现在返回结果里。统计”出现了的比例”。这一步只考检索，不牵扯模型。
- 答案正确率：把检索结果喂给模型生成答案，人工判定答案对不对。统计正确的比例。
分开量非常关键。合在一起量的话，答案错了你根本不知道该怪检索还是怪生成。分开之后：召回没命中就是检索的锅，去调分块和重排；召回命中了但答案还错，那是提示词或模型的锅，跟检索无关。这一步能省掉大量瞎调的时间。
第三步，记录并对比。 每次改分块参数、换检索策略、加重排，都把这套问答对重跑一遍，把两个比例记下来，形成一条能对比的曲线。有对比才知道自己是在改进还是在原地打转。
至于这两个比例要达到多少才算合格，没有普适标准——它取决于你的业务能容忍多大的错误代价。客服自动回复和合同审查的门槛完全不同。你要做的是先量出自己的基线，再定自己的门槛，而不是去套别人的数字。
另外提醒一句：这套评估本身也是成本，标注要人、复跑要时间。但它是所有 RAG 成本里最值得花的一笔，因为它是唯一能让你提前发现”检索不准”的手段。没有它，你的第一次发现会是在用户投诉里。
自查清单
上线前把这几条过一遍：
- 算清楚两个基础数字——文档总 token 量
D，以及单次回答真正用得上的比例R/D。这两个数没有，后面全是猜。 - 用本文的公式把
N*算出来，把你的真实单价和真实账单数字代进去，别用文中的假设值。 - 把预估的月调用次数和
N*比一比。如果落在平衡点附近（上下三成以内），优先选简单的那条路——运维复杂度的差距比这点钱值钱。 - 检查文档是不是稳定的固定前缀。是的话把缓存折扣代进公式重算一遍，平衡点大概率会明显右移。
- 把隐性成本单独列一行预算：重新索引的频次、分块调优的人天、检索评估标注的人天、召回错误的兜底流程。不列出来它们就会以延期的形式出现。
- 确认文档内容能不能拆。有强交叉引用的部分单独拎出来走完整投喂，别一刀切全上检索。
- 在上线前就把问答对评估集建好，跑出召回质量和答案正确率的基线数字，别等出了事再补。
- 上线后按月复算一次。调用量、文档量、单价都会变，去年算出来该走全量，今年可能就该翻过去了。