微调 vs RAG：我到底该让模型死记硬背，还是现查现答？

你好，我是小饼干。

最近在折腾大模型应用的时候，被一个问题卡了很久：我想让模型掌握我的私有知识，到底该用微调还是 RAG？

网上说的都太绕了，我用自己的笔记整理了一遍，顺便加了一些自己的理解。今天分享出来，希望能帮你少走点弯路。

---

一、先说我自己的理解

微调：相当于让模型“死记硬背”，把新知识写进它的参数里。以后再问，它直接从脑子里调出来。

RAG：相当于让模型“开卷考试”，不改变模型本身，只是临时塞给它一堆参考资料，让它照着答。

一个靠记忆力，一个靠查资料。各有各的命门。

---

二、微调：适合那些基本不变的东西

我当时考虑微调，主要是因为它够“彻底”。

微调的好处很明显：

第一，深度定制。不管你是想要特定的输出格式、行业黑话，还是某种回答风格，微调都能帮你刻进模型的骨子里。这个 RAG 做不到，RAG 只能给参考资料，没法改变模型本身的表达习惯。

第二，响应快。推理的时候不需要先检索，直接走模型生成就行，少了那几百毫秒到一秒的延迟。如果你对响应速度要求很高，这可能是决定性因素。

第三，出活儿稳定。知识已经固化到模型参数里了，不会因为检索质量波动而答得时好时坏。

但微调的坑，也不是一般人扛得住的：

第一，成本太高。你需要准备高质量的标注数据、租 GPU、跑训练。时间和钱都是实打实的投入。我试过一次，光标注数据就搞了三天。

第二，更新太难。如果你的业务数据隔三差五就变，总不能每周都花几个小时重新训练一次吧？根本扛不住。

第三，是个黑盒。模型的回答来自参数里的某个角落，你根本不知道它是从哪条知识推出来的。出错了也很难定位原因，只能靠猜。

所以我的结论是：微调适合那些基本不变的东西——输出格式、语气风格、行业术语。不适合频繁变化的具体知识。

---

三、RAG：适合那些经常变化的东西

后来我开始认真看 RAG。

RAG 的好处，刚好补了微调的短板：

第一，知识更新零成本。知识库变了？往向量库里加几篇文档就行，不需要重新训练，加完就生效。这个太爽了。

第二，可解释性强。回答的时候可以把来源 chunk 也附上，用户能自己判断答案靠不靠谱。出错了，马上知道是哪条知识有问题，不用猜。

第三，成本低。小团队用 OpenAI Embedding 加 Chroma 就能跑起来，不需要 GPU 训练。

但 RAG 也不是银弹：

第一，多了检索这一步，响应延迟肯定会增加几百毫秒到一秒。对响应速度要求特别高的场景，可能需要权衡。

第二，受限于检索质量。如果相关的 chunk 没被检索回来，LLM 再强也答不出来。这是 RAG 的天花板。

第三，对推理能力提升有限。RAG 只是给模型提供参考资料，但如果你需要模型对某个领域有更深的理解和推理能力，光靠检索资料是不够的，还是得微调。

---

四、实际工程里怎么选？我的答案是：组合

我现在的做法是两者结合，而不是二选一：

第一步，先对基础模型做一轮微调。

让它学会我想要的输出格式、语气风格、行业术语。这些东西相对稳定，不需要频繁变化。微调一次，可以用很久。

第二步，用 RAG 来提供具体的知识内容。

那些频繁变化的业务数据、实时文档、最新的问答，全部走 RAG。知识库更新了，往向量库里加文档就行，不需要重新训练。

效果就是： 模型开口的姿势是对的（微调给的），说的内容是新鲜的（RAG 给的）。延迟和成本都在可接受范围内。

---

五、一句话总结

如果你问我什么时候用微调、什么时候用 RAG，我会这样回答：

• 基本不变的东西扔给微调（格式、风格、术语）
• 经常变的东西丢给 RAG（具体知识、实时数据）
• 两个都想要？那就两个都用。

---

以上是我最近折腾的一点笔记，欢迎拍砖。如果你有更好的方案，也请告诉我，我还在学习。

—— 小饼干