微调 vs RAG：你到底什么时候真的需要微调

要改变一个模型为你做什么，只有三种办法，而且它们不可互换。选错的代价高昂，且往往几个月后才显现。

微调到底是什么

你拿一个基础模型，在你想要的行为的示例上继续训练它：一对对的输入，配上你所在领域一位好从业者会给出的答案。模型的默认会随之偏移——它伸手去取哪些词、一个答案呈现什么形状、在回答之前它会先问什么。

它不是一个数据库。 没有任何东西被存下来再查出去。示例挪动的是模型的倾向；它们不会变成它能背诵出来的事实。

实践中它是一个适配器，而非一个新模型

重训每一个权重代价高昂，且很少必要。常规做法——LoRA，即低秩适配——训练的是一小组额外参数，坐落在一个被冻结的基础模型之上。结果是一个几十兆字节的文件，而非几十吉字节。

这带来一个值得知道的后果：一个基础模型能服务许多适配器。 一台机器可以用同一套基础权重，为一家律所、一家诊所和一家物流公司服务，只需按租户切换一个小小的适配器。按行业微调，并不意味着每个行业都要一整个模型。

你到底什么时候真的需要它

语域很重要，而提示词托不住它。 日语的商务敬语、临床用词、核保员措辞时的留有余地。你可以在提示里描述语域；但在一段长对话之下，模型会漂回它的默认。微调挪动的是那个默认。

量级上的格式合规。 如果每一条输出都必须是某个特定结构，而“通常正确”还不够好，那么示例比指令更可靠地教会它。

指令已经长过了答案。 当系统提示比它产出的东西还长，你就在每一次请求上都为那些 token 付费。微调正是把这笔成本从每次请求的路径上挪走的办法。

窄领域里的一个小模型。 一个调校得当的小模型，在一个行当之内往往能胜过一个大得多的通用模型——这既是质量决策，也同样是成本决策。参见 自带模型。

基础模型在你的语言或领域上很弱。 有些语言和专业方向在公开训练数据里很稀薄。示例正是你修补它的办法。

你什么时候不需要它

• 你还没试过一个更好的提示。 大多数“我们需要一个定制模型”的问题都是提示问题。微调是那个昂贵的答案；先挣得它。
• 你只有寥寥几个示例。 几十个挪不动一个模型。几百个好的或许可以；质量胜过数量，而坏示例会忠实地训练出坏习惯。
• 你想要的那个东西经常变。 任何你每周都想编辑的东西，都不该被烤进去。

要把它做好需要什么

示例。 几百到一两千个，取自真实工作，并由懂这个领域的人核对过。这是客户会低估的部分——数据收集通常比训练本身还长。

一套留出的评测集。 模型从没见过的示例，在前后各评分一次。没有这个，你就无法判断微调是帮了、害了，还是什么都没干——而“感觉更好了”不是一个测量。这是最常被略过的一步，也是决定这个项目值不值得做的那一步。

一套应对基础模型更迭的计划。 适配器绑定在它训练所依据的那个基础模型上。当你换到一个更新的基础模型时，调校要重做。把它当作维护来预算，而非一锤子买卖。

要设计来防住的那种失败

一个在某一种窄风格上调得过猛的模型，会在其他一切上都变差——即使问题需要另一种语域，它也用你的门面口吻作答，而且会对它从没被教过的东西变得自信而流利。这正是评测集为什么重要，也是为什么明智的目标通常是默认行为的一次适度偏移，而非一个只会做一件事的模型。