微调还是 RAG

这是 AI 项目里最贵的一个岔路口。选错的团队通常要花几个月才发现——而正确答案在绝大多数情况下都是同一个。

根本区别

微调改的是模型本身。拿一批「输入—输出」样本继续训练，调整模型内部的权重，让它的输出倾向发生变化。

RAG 改的是给它看的材料。模型一个字节都没动，只是在提问时把相关资料递到它眼前。

一句话记住：微调教「怎么说」，RAG 给「说什么」。

所以判断的第一个问题永远是：它是不知道，还是说得不对味？

不知道公司的退款政策 —— 那是缺知识，用 RAG。
知道政策但回答得啰嗦、不像客服的语气 —— 那是表达问题，先试提示词，不行再考虑微调。

为什么微调补不了知识

这一点值得讲透，因为它反直觉——「用我们的文档去训练它」听起来天经地义。

问题在于，训练过程学的是统计规律和表达模式，不是把事实条目存进一张表里。你拿一千条公司规章去微调，模型学到的是「这类文字大概长这样、用词偏正式、常出现某些结构」，而不是「退货期限是七天」这个具体事实。

结果就是那个典型的失败：微调完之后，它说话的调子确实像你们的文档了，但你问具体条款，它照样编——而且编得更像模像样，因为语气对上了。这比之前更危险。

还有三个连带问题：

一、没有出处。微调进去的东西融进了权重，你无法追溯任何一句话的来源。RAG 能标引用，这在企业场景里往往是硬要求。

二、更新极慢。政策改了一条，你得重新准备样本、重新训练、重新评测。RAG 只需要换掉那份文档重新入库，几分钟的事。

三、可能损伤原有能力。在窄领域数据上微调，模型在其他方面的表现可能下降。这个现象需要完整的评测才能发现，很多团队根本没做。

什么时候才该微调

微调不是没用，它有明确的适用场景——都和「形式」有关，不和「事实」有关。

一、需要极其稳定的输出格式或风格。提示词能做到八九成，但你需要九成九，而且这个格式要在海量调用中保持一致。

二、有特殊的领域表达习惯。比如医疗、法律、金融的特定文书体例，这些用提示词描述起来极其冗长。

三、要把长提示词的成本压下来。这是个实际的经济动机：如果你的提示词很长（几千 Token）且调用量巨大，把这些规则微调进模型，之后每次调用就不用重发了。省下来的钱可能相当可观。

四、要用小模型达到大模型的效果。在一个窄任务上微调小模型，效果可能接近大模型而成本低得多。这在高频、单一的任务上很划算。

注意这四条的共同点：没有一条是「让它知道新知识」。

还要提醒代价：微调需要几千条高质量样本（准备样本本身就是大工程）、要花训练成本、要有评测集来验证有没有变差、而且模型厂商出了新版本你可能得重做一遍。

正确的顺序

遇到「模型表现不够好」，按这个顺序往下走，绝大多数团队走到第三步就停了。

第一步，改提示词。最便宜、最快、随时可回滚。补齐四个部件、加几个例子，多数问题在这里就解决了。

第二步，上 RAG。如果是知识缺失，这是唯一正确的方向。

第三步，换个更强的模型。如果是推理能力不够，换模型比微调简单太多，成本也可能更低。

第四步，才考虑微调。而且要先明确：微调是为了解决上面三步解决不了的哪一个具体问题？答不上来就不该做。

最后一条补充：这两者不是二选一。成熟的产品经常是「微调过的模型 + RAG」——用微调固定输出风格和格式，用 RAG 提供实时准确的事实。它们解决的是两个不同的问题，本来就可以叠加。