微调与 RAG

微调教的是怎么说，RAG 给的是说什么。想补知识却去微调，是这个领域最贵的一类误判——几个月之后才会发现。

在 AI 项目里，这个岔路口选错要付的代价最高——通常几个月之后才暴露。但绝大多数情况下答案只有一个：要补知识，用检索，不要用微调。rag-wiki

读完你能回答：

• 一句话怎么分清该用哪个？
• 为什么微调装不进事实，它实际学到的是什么？
• 光论补知识这一件事，微调为什么还额外吃亏？
• 模型表现不够好时，正确的尝试顺序是什么？

判断只需要一个问题

微调动的是模型本身。做法是准备一批「输入—输出」样本，让它继续学，模型内部的权重随之被调整，之后它输出的偏好就不一样了。

RAG 动的是递到它眼前的那份材料。权重完全没有变化，区别只发生在提问的那一刻——相关资料被放进了这一次请求里。

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

不知道你们对外承诺的响应时限是几个工作日——那是缺知识，用 RAG。时限背得出来，但答得又长又生硬、不像客服——那是表达的问题，提示词先试，实在不行再谈微调。

一句话记住：微调管的是怎么讲，检索管的是拿什么讲。

训练锤的是表达，不是那张事实清单

这个结论反直觉，所以值得多花几句：把公司的文档拿去训练，听上去是再自然不过的做法。

但训练过程让模型掌握的，是文字的统计规律和表达习惯。事实并不会像往表格里填行那样被存下来。假如你喂进去几百份工单处理记录，它从中得到的是「这类文本长什么样、惯用哪些词、通常按什么结构展开」，而「超时工单要在四小时内升级」这种一条一条的具体内容，并不在其中。

于是就出现了那个很典型的失败：训练结束后，它的语气确实带上了你们文档的味道，但一问具体条款，照样是编——而且因为腔调对了，编出来更像真的。这比以前更麻烦：错的答案披上了可信的外衣。

光论补知识，微调还多背三笔账

上面说的是机制使然，接下来是工程上的三笔账——它们全都指向同一个方向：凡是「让模型知道点什么」的需求，微调都比检索吃亏。

一、查不到出处。这些内容已经化进权重里，任何一句话都追不回来源。而 RAG 能给出引用，在企业里这经常是必须满足的条件。

二、改动生效很慢。一条政策变了，样本要重做、训练要重跑、评测也要重来。RAG 那边只是把文档换一份，重新入库就结束了。

三、原有能力可能被削弱。只拿窄领域的语料训练，模型在别的方面的表现有可能变差。要发现这一点必须跑完整评测，而很多团队没有做。

微调该用在哪儿

话说到这儿，微调的价值反而更清楚：它的适用面很明确——全都落在「形式」上，没有一条落在「事实」上。

一、输出格式或风格要极其稳定。提示词能兜住大部分调用，但你要的是在几十万次调用里一次都不飘，那就得把它训进去。

二、领域里有特殊的表达习惯。招标文件、检测报告各自都有固定体例：用提示词去描述，篇幅会拉得极长，而且每次调用都得把这些描述重新发一遍。

三、想把长提示词的账单压下来。这是一笔实打实的账：提示词很长、调用又频繁时，把这些规则直接训进模型，往后每次请求就不用再带上它们了。

四、想让小模型干出大模型的效果。只针对某一个窄任务训练小模型，它可能接近大模型的水平，花费却低不少。任务重复度高、又只做这一件事时，这笔账很划算。

四条放在一起看：没有一条是冲着「让它知道新知识」去的。

选了这条路，价格也要算进来：高质量样本得备很多（备样本这件事本身就是个不小的项目）、训练要花钱、还要有一套评测集用来确认没退步；而厂商一发布新版本，前面这些可能得再做一遍。厂商自己的模型优化文档也没有把微调排在第一位，它被放在「评估 → 提示词 → 微调 → 再评估」这样一条流程中间。openai-finetune

遇到表现不够好，按这个次序试

只要遇到「模型表现不够好」，就沿着这个次序往下走，多数团队走到第二档问题就没了。

第一档，改提示词。花费最少、见效最快、随时能退回去。提示词该有的部分补齐、再添几个例子，大部分问题到这一步就结束了。

第二档，上 RAG。缺的如果是知识，方向只有这一个。

第三档，换一个更强的模型。卡在推理能力上时，换模型远比微调省事，价钱也可能更低。

第四档，微调才排得上。而且要先讲清楚：前面三档都解决不了的那具体是哪一个问题？讲不出来就别做。

最后补一句：两者并非只能选一个。做得成熟的产品常常是「微调过的模型 + RAG」的组合——输出风格和格式由微调固定住，实时而准确的事实交给 RAG 提供。两个问题本来就不一样，叠在一起用很自然。

这一章留下的判断

这一章讲的是一件事的九个侧面：模型自己不记得任何东西，它「知道」的一切都是你的系统在这一次请求里放进去的。

先把放进上下文的那几段找对。向量与相似度 说明相似度不是相关性，两路找法各有盲区 说明要混着用再重排。

然后看容器装不装得下。一次请求能装下的就这么多 是一份预算，开头和结尾看得最清 说明位置也是权重，聊长了会自动丢 说明该活下来的别只放在对话里，让它记住你有代价 说明跨会话的记忆也是同一套存取流程。

最后把两段接起来：先检索再回答：四步 是这套流程的骨架，而它答错时 按四步往前查 能定位到具体哪一环。

合起来是一句判断：这一层你能控的部分，远多于模型层。模型选错了只能换，但检索、切分、排序、预算、位置这些全是你自己写的代码，每一项都能改、都能测、都能回滚。所以「它答不准」在多数情况下不是一个模型问题，是一个工程问题。

下一步在系统层。检索只能保证「找出可能相关的内容」，保证不了「该知道的都拿到了」——复杂场景里真正决定判断对不对的那些约束，往往措辞和问题并不相似，也不会自然地出现在检索结果里。所以知识这件事的下一步不是把检索调得更好，而是先把知识结构立起来：知识库要先对齐领域，不是先上 RAG。

知识这条线到这里交代完了：装得下、找得到、接得上。接下来换一笔更具体的账——用它一次，到底花什么。入口是它不按字数收费。