大模型微调入门: SFT、LoRA 与何时不该微调

这一课解决一个非常具体的问题：当工程师或供应商对你说”这个需求得微调”时，你能判断这句话是对是错。学完你会知道大模型微调到底改了模型的什么、SFT 和 LoRA 是什么关系、哪三类场景值得花这个钱、哪三类场景微调纯属浪费，以及为什么这笔账的大头从来不在训练上。

先把结论放在最前面：绝大多数产品需求不需要微调。微调是能力升级路径上的最后一站，前面还有提示词、Few-shot、RAG、工具调用整整四站。跳站直达的结局通常是——团队花几周攒数据、跑训练，最后发现效果还不如把 prompt 认真改三遍。

本课是《AI 产品经理课》专题的第 11 课，不需要任何算法背景，所有原理只讲到”能和工程师平等对话”的程度，数学一概不碰。

本文是《AI 产品经理课》第 11 课 · 专题目录 · 学习路线 · 上一课: 第 10 课 · 下一课: 第 12 课

全部 13 篇目录

微调是什么: 换脑子, 不是递小抄

先给微调（Fine-tuning）一句白话定义：拿你自己的数据，继续训练一个已经训练好的模型，让它的权重朝你要的方向偏移。权重就是模型内部那几十亿个参数，你可以把它理解成模型的”脑回路”——微调就是在动脑回路本身。

这和前面几课讲的所有手段都有本质区别。写 prompt、加 Few-shot 示例、挂 RAG 知识库，这些全都是”改上下文”：模型本体一个参数都没动，你只是在它答题之前往桌上递了一张小抄。微调不一样，它是把这个学生送去封闭培训，回来之后脑子就变了——不用小抄，也按你要的方式答题。

用招新员工的场景把四种手段排一排，差别一目了然：

写 prompt，等于发一份工作手册，告诉他规矩；
Few-shot，等于给他看两三个做好的样例，照葫芦画瓢；
RAG，等于给他配一个随查随用的资料库；
微调，等于送他去脱产培训三个月，改的是肌肉记忆。

关键差别在可逆性和成本。改上下文是可逆的、便宜的、当天生效的，写错了删掉重来就是；改权重则要数据、要训练、要验证，改坏了只能回滚到旧模型重训。站内《上下文即软件，权重即硬件》把这层关系讲得很准：上下文像软件，随时改随时生效；权重像硬件，动一次周期长、代价高，但有些能力确实只有动硬件才能得到。

给产品经理一个快速判断句式：你想改的是”模型知道什么”，还是”模型本身是什么样”？前者递小抄就够了，后者才轮得到换脑子。

方法谱系: 从全参微调到 LoRA

“微调”是个统称，下面有一整个谱系。产品经理不需要会操作，但要分得清工程师嘴里几个高频词各自指什么。

全参微调: 动整个大脑

全参微调就是让模型的全部权重都参与更新。效果上限最高，代价也最高——需要装得下整个模型加训练状态的算力集群，通常是模型厂商和大厂研究团队的玩法。对产品团队来说，知道有这个选项、并且知道基本轮不到自己用，就够了。

SFT: 用示范教模型做事

SFT（Supervised Fine-Tuning，有监督微调）的白话解释：给模型看大量”输入→标准输出”的成对示范，让它学着模仿。第 1 课讲大模型训练三阶段时提过，模型厂商在预训练之后就是用 SFT 教会模型”听懂指令”的；你自己做微调，绝大多数时候做的也是 SFT——只不过示范数据换成了你的业务样本。

注意 SFT 回答的问题是”用什么数据、朝什么目标训”，它和下面的 LoRA 不是二选一的关系：一个说训什么，一个说怎么省着训。

LoRA: 只训一层薄薄的增量

LoRA（Low-Rank Adaptation，低秩适配）的白话解释：完全不动原模型的权重，只在旁边训练一小块”增量补丁”，推理的时候把补丁叠加上去用。定性地讲，这块补丁的参数量只有原模型的百分之几甚至更少，所以训练便宜、存储便宜、切换方便——同一个底座模型可以配好几个不同任务的 LoRA 补丁，像同一台游戏机插不同的卡带。

便宜在哪就一句话：要更新的参数少了几个数量级，算力和显存需求跟着掉下来，很多任务在消费级硬件上就能训。想往下多钻一层的读者，站内有LoRA 与权重衰减效应的研究解读，也有一篇保姆级 LoRA 炼制教程——后者是生图场景，但”训一块低秩增量”的思路完全相通。系统性的方法图谱可以看从 LoRA 优化到 RLHF 对齐的微调实战图谱。

对 PM 来说记住一句就够：今天业界说”微调”，十有八九指的是”SFT + LoRA”这套组合——用示范数据，训低秩补丁。

该微调的三类场景

微调有明确的适用区。共同特征是：任务定义清楚、输入输出可枚举、对错有客观标准。

场景一: 输出格式高度固化

输出必须是严格结构的 JSON、固定版式的报告、逐字段对齐的表单。你在 prompt 里写满格式说明、贴了示例，格式还是隔三差五漂移——字段名换写法、多包一层数组、突然冒出一句解释性废话。这种”格式肌肉记忆”是微调的强项：几百条格式严格一致的示范样本训下去，模型输出格式的稳定性通常远超靠 prompt 反复叮嘱。

场景二: 领域黑话与口径

行业术语、内部产品名、法务审过的固定话术、特定文风。如果黑话词表小，塞进 prompt 就能解决；但当口径规则多到 prompt 塞不下、或者塞了也执行不稳时，微调能把这些说法炼进模型本身。典型如医疗、法律文书的行文规范，或客服场景里”哪些词绝对不能说”的口径约束。

场景三: 小模型降本

这是当下 ROI 最清晰的微调场景：任务很窄，但你在用一个大而全的模型硬扛，等于杀鸡用牛刀。标准打法是三步——先用大模型把任务跑通、顺手积累高质量的输入输出数据，再用这批数据微调一个小模型，最后让小模型接管这个单一任务。站内实战微调 Qwen 0.6B 做意图分类就是教科书案例：一个能在本地跑的小模型，微调后在单一分类任务上顶替了大模型，调用成本掉了几个数量级。更极端的例子是Needle 把 Gemini 的工具调用能力蒸馏进一个 26M 参数的小模型——蒸馏就是拿大模型的输出当教材去训小模型，本质上也是微调的一种玩法。

不该微调的三类场景

比”什么时候微调”更值钱的知识是”什么时候别微调”。以下三类需求最常被错误地推向微调。

想灌新知识: 用 RAG

头号误区：”把公司文档微调进模型，它就懂我们业务了。”不成立。微调学到的是”模式”，不是”事实”——拿少量文档去微调，模型往往学会了你们的腔调，却记不住具体数字和条款，该幻觉照样幻觉。而且知识会过期：文档天天更新，你不可能天天重训模型。

知识注入这件事，正确工具是第 7 课讲的 RAG——把资料放在库里，答题时检索出来递给模型。一个反向佐证：有研究展示了通过微调破防、让模型逐字背出版权书籍——要让模型可靠”背住”原文，得往死里训，还伴随各种失控副作用。这恰恰说明权重不是给你存知识用的仓库。

想调行为: 先把 prompt 写到位

“语气再亲切一点””回答短一点””别用列表体”——这些是行为调整，是第 2 课提示词工程一两句话的事。见过太多团队，prompt 总共写了五行字，测试集一条没建，就开始讨论微调排期。

一条硬性的资格线：你的 prompt 有没有认真迭代过十个以上版本？有没有一个哪怕只有几十条样本的小测试集来验证效果？两个问题有一个答”没有”，就还没到谈微调的时候。

需求还在变: 等稳定

微调等于把当前需求”焊死”进权重。需求一变，就要重标数据、重新训练、重新评估，整条链路再走一遍。产品还在快速迭代期就上微调，相当于往流沙上浇混凝土。

一个值得玩味的行业信号：连模型厂商自己都在重新权衡微调的分量——传 Gemini 3.5 Pro 放弃微调重注预训练，理由之一就是过度微调会牺牲通用能力。基座模型几个月一次大升级，你的微调成果是锚死在旧基座上的，这一点我们在成本账里展开。

成本账: 大头在数据, 不在训练

微调最反直觉的一点：听名字以为贵在训练，实际上钱和时间大头都在数据。

数据准备占七八成工作量。 一次像样的微调，通常需要几百到几千条高质量样本的量级——重音在”高质量”。样本要人工写或至少人工审，要覆盖边界情况，口径要前后一致。这活外包不出去，因为”什么算标准答案”只有你的业务团队说得清。很多项目卡死在这一步：数据凑数，训出来的模型把错误口径学得炉火纯青。

训练本身反而是便宜的一环。 LoRA 时代，训练几轮实验的算力开销，通常明显低于标注数据的人力成本。这也是为什么”训练很快就能跑完”完全不代表”项目很快能上线”。

评估集必须先建，而且要花真功夫。 留出一批不参与训练的样本做考卷，训练前先测基线，训练后对比。跳过这一步，你连”微调之后是变好了还是变坏了”都说不清——这是微调项目里最常被省略、也最致命的一步。

给 PM 一个排期直觉：数据、训练、评估的工作量比大致是六比一比三。如果供应商的报价单里训练费用占大头、数据和评估一笔带过，这个方案要打个大大的问号。

决策顺序: 逐级升舱, 别跳级

把前面几课串起来，就是一张从便宜到贵的升舱清单。每一级卡住了、验证过了确实不够用，才升下一级：

Prompt：把角色、指令、约束、输出要求写清楚。八成的”模型不行”死在 prompt 没写好这一级。像 Claude Code 这类工具的系统提示词就是工程化 prompt 的范本，Claude Code 专题里有不少拆解。
Few-shot：加两三个高质量示例，锁住格式和口径。比堆形容词管用得多。
RAG：需要私有知识、时效知识？挂知识库，第 7 课的活。
Function Calling：需要查库、计算、操作外部系统？接工具，第 9 课的活。更多实践在AI Agent 专题。
微调：前四级都认真做过，仍然卡在格式漂移、黑话学不会或成本压不下来，而且需求已稳定、几百条以上高质量样本已就位、评估集已建好——满足全部条件，才轮到微调。

这个顺序的逻辑很简单：越靠前的手段越便宜、越可逆、生效越快；越靠后越贵、越不可逆、维护负担越重。另外别忘了还有一个第零级选项——换个更合适的基座模型，有时候比任何优化都直接，选型可以参考模型对比专题。

把这张清单贴在评审会的白板上。任何人提”我们微调一下吧”，先按清单从第一级问起。

产品经理视角: 微调是资产, 也是负债

最后从产品视角算总账。微调模型的资产面很诱人：它是竞争壁垒——你的业务数据以模型的形式变现，对手拿不走；它是成本优势——小模型接管高频窄任务；它是体验一致性——不依赖 prompt 的脆弱约束。还有一层容易被忽略的资产：那套训练数据和评估集本身，比模型更长命——模型会过时，好数据能陪你换好几代基座。

但负债面必须同时写进方案：

版本绑定：微调锚定特定基座版本，基座升级你就得重训、重评估。而基座半年一大版是常态。
持续维护：需求漂移就要补标数据、跑回归评估。这是持续成本，不是一次性投入。
评估的持续性：别人的榜单分数说明不了你的问题——GLM-5.2 登顶微调榜引发的争议就是提醒：没有自己业务场景的评估集，一切效果宣称都无法验证。
组织成本：得有人真正对这个模型的全生命周期负责，否则它会在三次需求变更后变成没人敢动的遗留系统。

所以汇报口径上，不要说”我们微调了一个模型”，要说”我们建了一条数据到训练到评估的流水线”。前者是一次性交付物，后者才是团队能力。老板问值不值，就把这两面摆出来算。

FAQ

微调和 RAG 可以同时用吗?

可以，而且是成熟产品的常见组合。分工很清楚：微调管”怎么说”——格式、风格、流程习惯；RAG 管”说什么”——事实、条款、时效知识。比如客服机器人，用微调固化话术口径和应答格式，用 RAG 提供最新的产品资料和政策条款，两边互不抢活。

微调到底需要多少数据?

定性地说：任务越窄，需要越少。格式固化、分类打标这类任务，几百条高质量样本就能起步；复杂生成任务通常要上千条。但记住质量远比数量重要——一条口径错误的样本造成的伤害，大于十条正确样本带来的收益，因为模型会忠实地把错误也学进去。

团队没有算法工程师, 能做微调吗?

托管微调服务和开源训练工作台已经把操作门槛压得很低，跑通流程不难。但瓶颈从来不在训练操作，而在数据和评估：得有人能定义”什么样的输出算好”、能审样本口径、能设计评估集——这些恰恰是产品经理和业务专家的活，不是算法的活。

LoRA 的效果比全参微调差吗?

定性回答：在窄任务上通常够用，差距主要出现在需要大幅改造模型能力的场景。产品场景里九成的微调需求，LoRA 的效果和成本平衡都优于全参。合理路径是先用便宜方案验证业务价值，真撞到天花板再考虑升级。

微调会让模型忘掉原来的能力吗?

有这个风险，术语叫”灾难性遗忘”——模型学新技能时把旧能力冲掉了。LoRA 因为不动原模型权重，风险比全参微调小得多。这也是为什么评估集里除了业务样本，还应该放一部分通用能力的题目，训完对比着测。

结语

微调不是更高级的 prompt，而是升级路径上的最后一级火箭。先把便宜可逆的手段用尽，等需求稳定、数据就位、评估先行，再去动权重。下一课把全系列的术语串成产品经理的概念地图。