判断一个已上线 RAG 的团队要不要引入微调，“对比 RAG 与微调的成本”通常是最先被提出的问题，但它也是最容易误导决策的开始。RAG 的成本落在系统层，由检索链路、文档处理、上下文组装和评测体系构成；微调的成本落在模型层，由训练数据、训练运行和权重版本管理构成。把两个不同层面上的成本直接相减，得不出可执行的结论。真正有意义的问题只有一个：在当前的失败查询里，哪一类适合继续投入检索侧工程，哪一类值得进入微调评估管道。成本对比必须按查询类型拆分，而不是按技术名词汇总。
先拆失效根因，再谈成本归属
RAG 上线后的“效果不好”至少对应四种不同根因：
- 知识源缺失：文档里没有目标内容。这类失效不属于检索问题，微调也只能用参数去硬记长尾知识，而知识一旦变化就会触发重新训练。从工程角度看，这是把索引层的更新成本转嫁到权重层，长期维护代价更高。
- 检索失效：内容存在，但切分、召回或排序没有把它送进上下文窗口。投入微调没有意义，因为生成模型根本没机会读到正确内容，需要检查的是切分粒度、混合检索的召回融合与排序逻辑。
- 上下文利用失效：内容已经进入上下文，但生成结果没有遵循。优先排查 prompt 结构与指令组织方式，不要在没有验证 prompt 侧已做到位之前，把问题归因给模型能力。
- 行为模式失效：输出格式、语气、领域术语或任务范式不符合业务预期。这是微调真正的作用区间，因为微调改变的主要是模型的行为分布，而不是知识存储方式。
做一次粗粒度归因并不贵：从最近一周的失败日志或评测集中抽几百条，按上述四类标注。如果第三类占主导，先重构上下文组织方式；如果前两类占主导，继续在检索侧投入的边际收益通常更高；只有当第四类占比足够高且业务损失明确时，微调才应进入候选。分类结果同时也决定了后续成本对比的范围——只针对目标类别估算，而不是对整条链路估算。
三层成本结构
按查询类别确定优化目标后，成本对比可以从三个层面展开。
工程交付成本。RAG 侧集中在数据接入与清洗、切分策略调优、索引构建、多路召回融合、重排与评测集维护，每一环都是可以持续投入的工程；微调侧则集中在训练样本的采集、标注规范、质量过滤、训练实验和权重版本管理。微调最大的隐性成本不是训练资源，而是样本工程：目标行为要被稳定地转写成输入输出对，要覆盖边界情况，还要有人工质检环节。团队如果没有做过训练数据设计，这部分成本通常会被低估。
维护成本。RAG 的维护成本是持续性的：文档持续更新，切分和检索效果会随内容分布变化而漂移，需要周期性回归。微调的维护成本是事件驱动型的：业务规则、输出格式或任务定义变化时，需要补样本、重新训练并做完整回归。微调一旦引入，评测集就变成长期固定成本；底座模型升级时也需要完整重跑，否则无法判断效果变化来自新模型还是新样本。
资源成本。RAG 的消耗体现在每次查询的检索与重排计算、以及更长的上下文 token 上；微调的消耗集中在训练阶段，上线后通过替换生成权重影响每次请求。如果微调模型在线仍然叠加检索，检索侧资源并不会消失。两边的成本都跟模型规格、QPS、文档规模与上下文长度强相关，不存在普适常数，要用自己的调用量和 token 分布去估算，不能把其他场景的数字直接当预算依据。
用最小实验替代一次性判断
正式立项微调前，建议按顺序做一轮低成本验证：
- 选定要优化的查询类别，而不是同时优化所有失败查询。
- 先做检索侧实验：调整切分粒度、召回融合权重、重排规则，逐项记录指标变化。这类改动周期短且可回滚。
- 再做 prompt 侧实验：重构指令和上下文组织方式，确认行为问题不是提示词约束不到位造成的。
- 如果两步都没有显著效果，同时归因指向行为模式失效，再启动微调可行性评估。评估只需回答四个问题：目标行为能否被精确定义；训练样本能否以可控成本构造并质检；评测与回归流程是否已存在；线上部署与回滚机制是否明确。四个问题只要有一个答不上来，微调成本就还是一个无法收敛的变量。
混合检索架构下的分流：微调是新增路径，不是替代
混合检索架构通常指多路召回并存——向量召回、关键词召回与业务过滤并行，融合后交给生成模型。在这种架构下引入微调，工程上更顺的做法不是整链路替换，而是按查询特征新增一条生成路径：
- 知识敏感型查询：依赖时效性内容、长尾知识或多篇文档交叉推理，走检索增强路径，由检索保证事实来源。
- 行为敏感型查询：格式、风格、领域表达要求稳定的高频任务，走微调路径，让权重层面的行为约束承担主要作用。
- 复合型查询：先检索，再由微调后的模型生成。检索负责知识供给，微调负责格式与领域行为，二者处理的是不同维度的失效。
分流的经济性在于避免为了少数查询类别的问题重建整条知识链路。反过来说，如果线上大部分流量是知识敏感型，把工程投入放在召回精度和索引更新上的边际收益，通常高于训练一个行为更听话的模型；如果大部分流量是规则明确、知识依赖低的任务，微调路径可以缩短上下文、降低每次生成前的处理开销——但这是以放弃实时知识为代价的，不能用于事实准确性要求高的查询。
这里需要补一个边界条件：路由层会成为新的维护成本源。一旦路由误判，知识敏感型查询可能被送进不带检索的微调路径，模型会输出流畅但没有依据的回答，这类错误的业务代价可能远高于节省下来的成本。因此分流方案必须维护覆盖两类查询边界样本的评测集，并持续监控路由决策的分布变化。没有边界评测的分流设计，不应直接上线。
结论
已上线 RAG 的团队面对微调选项时，不应先问总成本谁更低，而应先建立查询失效分类，再对不同类别分别估算投入与收益。一个可用的判断起点是：回答质量取决于“知道什么”的查询，继续投资检索链路；回答质量取决于“怎么回答”的查询，再让微调进入评估管道。混合检索架构允许两条路径并存，但任何分流设计都必须把路由误判计入成本。在团队自己的评测数据出来之前，所有关于成本高低的结论都只是待验证的假设，不是事实。