在 LLM 上盖东西的团队最后都会问同一个问题:我们该不该微调?通常是在 prompt 已经膨胀到 3000 token、模型还是不稳、有人读到博客说微调解决一切之后。
通常答案是:不。或更精确说:还不要。Prompt 工程、RAG、few-shot 范例 —— 按这个顺序 —— 解决 90% 的「模型没做我要它做的事」问题。微调是剩下 10% 的对的答案,把那 10% 做对需要知道你真的在那 10% 里。
这是决策树。
各个技巧实际在做什么
快速复习:
- Prompt 工程。 改 prompt 的措辞、结构、范例,引出更好响应。不改模型、不要数据、不要训练。
- Few-shot prompting。 Prompt 工程的子集:在 prompt 里塞 2-10 个 input/output 配对,教格式跟行为。
- RAG。 检索相关文档、注入 prompt 当 context、模型用它们回答。加知识,不加行为。
- 微调。 拿基底模型在你的数据上继续训练。改模型实际权重,跨调用持续,不需要每次 prompt 都送范例。
各自解不同问题。
决策树
给一个问题,按顺序走这个列表。别跳步。
第 1 步:更好 prompt + few-shot 范例
大部分「模型错了」问题是 prompt 问题。试:
- 更具体。 「总结这个」→「用 3 个 bullet 总结这个,每个 bullet 用动作动词开头。」
- 加 few-shot 范例。 给模型看 3-5 个你要的 input/output 配对。
- 用更强模型。 Claude Sonnet 有时在同一 prompt 上赢 Haiku;付 4× 跳过工程。
- 约束输出。 用结构化输出 / tool use / JSON mode 强制形状。
- 重读你的 system prompt。 超过 1000 token 大概在某处自相矛盾。
解:格式遵守、语气、简单分类、基本抽取、大部分「请用这个风格回答」问题。
第 2 步:RAG
如果问题是「模型不知道我的数据」—— 内部文档、最近事件、客户特定脉络 —— 95% 时候 RAG 才是答案。微调修不了这个,模型需要在推理时拿到实际信息。
解:「回答关于我们公司的问题」、「参考我们的文档」、「总结这个特定文档」。
第 3 步:更好的 tool use / agent 设计
如果模型「能力缺失」—— 不能搜网络、不能跑代码、不能更新 DB —— 给它工具。别微调它来假装有能力。
解:「我要它真的做事」、「我要它抓最新数据」、「我要它跟我们系统互动」。
第 4 步:微调
现在才考虑微调。到这里你已经试完便宜选项了。微调对的时机:
- 格式 / 行为一致而 prompt 强制不可靠。 你要每个输出长得完全像 X,即使 10 个 few-shot 加结构化输出,5% 还是漂掉。
- 你的 prompt 太长以致成本不划算。 每次请求送 5000 token prompt 很贵,微调把行为烤进权重,prompt 降到 200 token。
- 延迟重要而 token 是瓶颈。 同上,进的 token 少 = 响应快。
- 隐私 / 合规需要本地跑。 自家部署的微调开源权重模型。
- 基底模型搞砸的特定领域语言。 法律术语、医疗缩写、交易词汇,基底模型默认用门外汉解释。
微调不可靠地教新事实。如果模型要知道你公司的 API endpoint,微调勉强可以但 RAG 更好。微调教行为,不教知识。
真实数字
2025 年一个我合作的团队跑这个实验。任务:把客服工单分到 18 个类别。
- 基线(Sonnet 没范例): 71% 准确率。
- + 5 个 few-shot 范例: 84% 准确率。
- + 带类别描述的更强 system prompt: 88% 准确率。
- 换 Opus: 92% 准确率。(每千次分类 $60 vs $5。)
- 800 个标记范例上微调 Haiku: 91% 准确率。(每千次分类 $0.40。)
微调 Haiku 在 1/150 成本下打平 Opus 准确率。那就是微调赚到的时候 —— 规模、可量差距、稳定任务上。
如果他们是 100 次分类/天,微调的力气不值得。他们是 50,000/天,数学很残酷。
微调失败(或浪费时间)的时机
已知反 pattern:
- 少于 200 个范例微调。 你会教风格不教能力,省时间。
- 微调来教事实。 「我的产品 2026 年三月上线」—— 微调不会可靠编码这个。用 RAG。
- 没验证的合成数据微调。 LLM 生的训练数据有 bug,模型学到 bug。
- 微调代替 debug prompt。 Prompt 迭代修得了的东西,先做那个。微调一个不稳问题只是让它变成你不容易改的不稳问题。
- 在 RAG + 开源权重就够用时微调前沿闭源模型。 永远锁在那厂商的定价。
LoRA 在开源权重上呢?
LoRA 显著改变数学。对比 GPT-4 全微调,Llama 3.3 70B 上 LoRA:
- 训练便宜 100×。
- 部署便宜 1000×。
- Adapter 200MB,好换好版本控制。
- 同样的根本取舍(还是教行为、不教事实)。
有 LoRA,「微调值得吗?」门槛大幅降低。5,000 次分类/天的团队可能在 LoRA 上打平,在前沿 API 微调上打不平。
微调的隐藏成本
大家忘记的三个成本:
- 维护。 基底模型定期更新。你的微调版本不会免费拿到那些升级。Llama 3.4 出货在你任务上好 8%,你必须重微调。
- 评测债。 微调需要 hold-out 测试集。之前没评测就现在要盖,大部分团队跳过然后后悔的三天工作。
- Catastrophic forgetting。 窄微调让模型在通用任务上变差。产品扩展到训练分布之外时,你会看到没预期的 regression。
务实操作顺序
对任何「模型没做我要它做的事」问题:
- 把你的 prompt 大声念出来,清楚吗?
- 加 3-5 个 few-shot 范例。
- 试下一个更强模型(Haiku → Sonnet → Opus),记成本差。
- 加结构化输出 / tool use 约束形状。
- 如果是知识问题:加 RAG。
- 如果是能力问题:加工具。
- 现在对你的 eval set benchmark,差距多大?
- 差距小或可以付更大模型钱:停,你完了。
- 差距大、任务稳定、有 500+ 标记范例:微调。
- 微调了,跑同一个 eval set,比较。要愿意 roll back。
什么时候完全不要微调
- MVP 之前。 最快迭代是 prompt + 基底模型,别把自己锁在下个月会改的权重上。
- 数据集很小。 200 个以下只是风格转移,用 few-shot。
- 需求快速变动。 产品需要每周变,你微调不了那么快。黏 prompt。
- 你还没量 prompt 工程够不够。 没 eval set 你就蒙眼飞,微调让 bug 更难找。
下一步
- 本 Learn 库的「在本机微调 Llama」那篇。
- Fine-tuning vs RAG —— Microsoft Research 文章,仍然相关。
- PEFT survey(Hu et al, 2024)—— LoRA、DoRA、adapter 方法总览。
- 查这些词:catastrophic forgetting、instruction tuning、parameter-efficient fine-tuning、LoRA vs RAG。