团队要做 AI 功能，老板问一句「RAG 和微调、prompt 到底多少钱」，很多人答不上来——不是不知道单价，而是不清楚钱花在哪几块、哪块会失控。这篇把三条路线的成本结构拆成可核对的项目，给出先算后做的顺序和判断标准，也说明每种算法在什么情况下不适用。
团队要做 AI 功能，老板问一句「RAG 和微调、prompt 到底多少钱」，很多人答不上来。不是不知道单价，而是不清楚钱花在哪几块、哪块会失控。模型调用单价只是账单里最显眼的那行，真正让预算翻倍的往往是检索条数、迭代次数和上线后的单价差。
这篇把三条路线的成本拆成能逐项核对的结构，给出先算后做的顺序和判断标准，也说明每种做法在什么情况下不适用。看完你应该能拿着一份实测数据，给出一个带假设条件的区间，而不是一个拍脑袋的数字。
先搞清楚钱花在哪：三条路线的成本结构对照
三条路线的成本结构差别很大，混在一起算必然算不清。RAG 的钱大头在检索侧和每次请求塞进上下文的 token；微调的钱压在一次性数据准备和训练上，以及之后每次调用用微调模型的单价差；提示词的钱几乎全在输入输出 token 上，隐性成本是改一次就要重跑一遍评测。
| 成本项 | RAG | 微调 | 提示词 |
|---|---|---|---|
| 一次性投入 | 文档清洗切片、向量化入库 | 数据标注清洗、训练 | 基本没有 |
| 随量变化的成本 | 每次召回的上下文 token | 微调模型调用单价差 | 输入输出 token |
| 隐性成本 | 召回条数调大、重排加一层 | 数据返工、重训 | 迭代次数与回归用例 |
| 共同固定项 | 评测、日志、监控 | 评测、日志、监控 | 评测、日志、监控 |
动手前先量自己的底：三组数字必须先有
没有底数就没法比价。三组数字优先拿到：单次任务的平均输入 token 和输出 token、每天的请求量与峰值并发、现在人工做这件事的单位时间成本。前两组决定账单，第三组决定这事值不值得做。
- 采真实样本从现有业务里挑一批真实输入，不要用自己编的示例；统计输入和输出 token 的分布，记下平均值和长尾。
- 记一周流量把每天请求量和峰值并发记下来，区分工作日与周末；这决定按量付费还是包套餐更合适。
- 算人工锚点统计人工完成同样任务的单位时间成本，作为判断投入是否划算的参照。
- 换算成钱拿上面三组数字去 /tools/token-price-calculator 和 /tools/model-cost-calculator 换算当时的报价。
拿不到数字就先小流量跑一周，别急着全量上线。这一周的数据比任何估算都可靠，也是后面回填估算表的依据。
RAG 的成本怎么估：从入库到每次问答
RAG 的成本分两段。入库是一次性的：文档清洗、切片、向量化，文档量翻倍成本大致线性上涨，所以先想清楚哪些文档真的需要入库。在线部分看每次召回几条、拼多长的上下文，召回条数是整个系统里最容易失控的旋钮。
- 召回条数从少往多试，每加一档都对照准确率收益，没有明显提升就退回去
- 上下文长度设上限，超长文档先摘要再拼，不要整篇塞进去
- 向量库选托管还是自建，差别主要在运维人力；团队没人专职维护就选托管
- 入库做增量更新，别每次全量重跑，文档多时这部分开销很显眼
- 定期抽查召回结果，长期没被召回的资料考虑下线，省存储也省检索
不适用的情况也要提前说清：知识几乎不变、问题范围很窄时，RAG 的检索开销可能不如直接把资料写进提示词；任务本身不需要外部知识，硬加检索只是多一层延迟和一层账单。
微调的成本怎么估：一次性投入加长期单价
微调最容易被低估的是数据准备。标注和清洗要按人天算，不是按卡时算，很多团队训练费没花多少，数据返工花了几周。训练本身可以先用小样本验证方向，确认有收益再上全量，别一上来就烧满。
上线后还有一笔常被忽略的钱：微调模型的调用单价往往高于基础模型，请求量大时这笔差价会反超训练费。报预算时把「训练一次性」和「调用单价差乘以请求量」分开算，别只看前者。
- 数据准备
- 标注、清洗、去重的人力成本，通常占总投入的大头
- 训练验证
- 先小样本跑通方向，再决定是否扩到全量
- 单价差
- 微调模型与基础模型的每次调用差价，乘以长期请求量
- 重训频率
- 业务变化快就要反复重训，这笔钱要按年算
不适用的情况：知识更新频繁、需要引用来源、标注数据量不足千级时，微调很难体现出优势。具体厂商的训练与托管报价，到 /stacks/fine-tuning 和 /compute/finetune 核对当时的数字。
提示词的成本怎么估：token 账加迭代账
提示词的钱看着最简单，其实有两笔账。一笔是 token 账：提示词越长越贵，而且每次请求都重复付一遍，系统提示里的冗余要定期清理。另一笔是迭代账：改一版要跑一轮回归，用例集越大单次迭代越贵，改十次的成本可能超过前两笔。
- 系统提示只留必需约束，示例按需给，不要把所有边界情况都写进去
- 固定一个小规模回归用例集，覆盖主要场景即可，不必追求大而全
- 提示词做版本管理，每次改动记录改了什么、哪条用例变化了
- 先调提示词再考虑加检索或微调，多数任务几轮之内就能达标
- 把重复出现的输出格式要求收进系统提示，避免每次用户输入里重复写
判断标准很直接：如果调整提示词几轮就能达标，先别急着上 RAG 或微调。迭代成本可控、改动可回滚，是提示词路线最大的优势。版本管理和回归的具体做法，可参考站内提示词版本与回归那篇。
三条路线怎么选：一张判断表
选型不要凭感觉，按业务特征对号入座。下面这张表给的是倾向，不是绝对结论，实际还要结合你手上的数据和预算。
| 你的情况 | 倾向路线 | 理由与注意 |
|---|---|---|
| 知识常更新、要给出处 | RAG | 检索能带来源，更新只需重入库 |
| 风格和输出格式要稳定 | 微调或提示词 | 微调更稳，但先试提示词 |
| 数据少、预算紧、要快速验证 | 提示词 | 门槛最低，迭代最快 |
| 任务对延迟敏感 | 提示词或微调 | RAG 多一次检索往返 |
| 数据量大且标注充足 | 微调 | 数据优势能转化成效果 |
| 需求还在探索期 | 提示词 | 方向没定就别做重投入 |
三条路线可以叠加，但每加一层都要有可量化的收益，否则只是把账单变复杂。加检索之前先问：不加检索的错答率是多少？加了之后降了多少？答不上来就先别加。
落地步骤：从零到能报出一个数字
按顺序做，别跳步。前两步决定估算的可靠性，后两步决定估算能不能被验证。每一步都留日志，事后复盘时能说清钱花在哪。
- 写清任务边界和验收标准明确输入是什么、输出要满足什么、什么算失败；验收标准要能量化，别写「效果好」。
- 采真实样本统计 token用真实输入统计输入输出 token 分布，记平均值和长尾，作为估算基数。
- 按成本结构列项照前面的对照表逐项填：一次性投入、随量成本、隐性成本、固定项，缺哪项标「待测」。
- 做最小可行版本跑一周选最轻的路线先跑通，记录真实请求量、失败率和 token 消耗。
- 拿实测回填估算表用一周数据修正之前的假设，把「待测」项换成实测值，重算区间。
- 再决定是否扩量对照验收标准和人工锚点，收益不明显就停在最小版本，别为了上线而上线
价格和套餐口径随时会变，报预算前到 /official-api 和 /price-watch 核对当时的数字，别拿几个月前的印象去汇报。
控成本的几条硬约束
成本失控通常不是因为单价高，而是因为某个参数没有上限。上线前把下面几条做成硬约束，比事后优化有效得多。
- 设单次请求的上下文上限和单日预算告警，超了就降级而不是继续烧
- 把检索条数、最大输出长度、重试次数做成可配置项，别写死在代码里
- 定期抽查真实请求的 token 分布，发现长尾异常请求及时处理
- 给重试加次数上限，失败就返回明确错误，别让循环把账单拉高
- 每月对一次账：实际支出与估算表的偏差在哪一项，下月修那一项
涉及成本止损的设计思路，可参考站内 Agent 跑飞之前那篇的白名单与步数上限做法。原则一样：先给系统装上刹车，再谈跑多快。
能报出带假设条件的区间，比报一个看起来很准的数字更专业。下一步把你手上的 token 分布和请求量带去换算页，先得出一个区间，再按对照表挑最轻的路线跑一周；价格口径以站内实时页面为准。→
常见问题
RAG 和微调、prompt 哪个更便宜？
没有统一答案，取决于你的知识和任务形态。经验顺序是先提示词、再 RAG、最后微调：提示词几乎没有固定投入，RAG 多一次入库和检索开销，微调有一次性的数据与训练成本。用真实样本算出三者的月成本再比，别凭感觉。
只想快速上线，能不能跳过成本测算？
能上线但不建议跳过。至少统计单次请求的输入输出 token 和日请求量，这两个数字十分钟能拿到，却能避免上线后账单失控。完整测算可以后补，但基线数字要先有。
微调之后是不是就不用 RAG 了？
不是一回事。微调改变的是模型的表达风格和行为倾向，不负责注入新知识，也很难给出引用来源。知识类需求仍然要靠检索，两者解决的是不同问题。
提示词改来改去成本很高怎么办？
把提示词纳入版本管理，固定一套几十条的小用例集，每次改动只跑这套用例，比每次全量回归便宜得多。同时清理系统提示里的冗余内容，每次请求都在为它付费。
预算有限的小团队该从哪一步开始？
先用提示词把一个具体场景跑通，拿到真实请求数据，再判断瓶颈在知识不足还是格式不稳。知识不足加检索，格式不稳加约束或微调。每一步都基于实测数据决策。
