6.1 何时微调（决策树）
Prompt Engineering、RAG、SFT 的工程决策——先问自己三个问题，再决定是否动手微调
先别急着微调
一个非常常见的错误是：业务方一说"模型在我们这边表现不好"，工程师就立刻开始规划一次微调实验。事实上，在真实项目里，微调（Fine-Tuning, FT）是最后一招，不是第一招。原因很简单——它是三种常用方案中成本最高、迭代最慢、失败风险最大的一个。
微调最常见的误用场景：希望通过微调让模型"记住新知识"。这是典型的把 SFT 当 RAG 用——几乎注定失败，因为 SFT 更改的是模型的行为分布，不是它的事实存储。
三种方案的定位
| 方案 | 解决什么问题 | 典型代价 |
|---|---|---|
| Prompt Engineering | 任务描述不清、缺少 few-shot 示例、输出格式要求 | 零训练成本，迭代速度按分钟计 |
| RAG（检索增强生成） | 模型不知道某个事实、需要访问私有知识库 | 向量库 + 检索器成本，每次调用多一次检索 |
| SFT（监督微调） | 模型不会说某种风格、不服从某种格式、领域术语偏好 | 算力 + 数据 + 部署版本管理 |
记住这张图的关键逻辑：
三个必须回答的问题
在动手微调之前，请严肃地回答以下三个问题。任何一个答案是"否"，就应当先回去用更便宜的方案。
Q1：Prompt + few-shot 能做到 80% 吗？
写一个精心设计的提示词，配上 3-5 个 few-shot 示例，如果模型在测试集上能达到 80% 的目标效果，那么通常没必要微调——迭代提示词的速度是分钟级，而微调是天级。
Q2：问题是"不知道"还是"不会说"？
- "不知道"：模型没见过某个事实（新产品文档、内部 wiki、最新 API）→ RAG
- "不会说"：模型知道事实，但输出风格 / 格式 / 语气不对 → SFT
混淆这两类是初学者最大的坑。用 SFT 教事实，模型会幻觉式地模仿风格，但事实仍然错误。
Q3：每天调用量足够大、prompt 够长吗？
即便 Prompt 方案在质量上可行，长 prompt 每天调用百万次也会让 token 费用失控。此时微调一次、把 system prompt 的能力"固化"到权重里，是合理的成本优化。关键指标：日调用量 × prompt token 数 × 单价。
微调能改什么、不能改什么
这张表几乎是全讲最重要的一张表：
| 能改变 | 不能改变（应用 RAG） |
|---|---|
| 输出风格（正式 / 活泼 / 精简 / 遵循品牌语气） | 最新事实（今年发生的事、昨天更新的政策） |
| 领域术语偏好（医学、法律、金融用语） | 私有文档里的具体数字、条款 |
| 格式遵循（永远输出合法 JSON / Markdown / XML） | 用户当天上传的 PDF 内容 |
| 任务默认行为（默认做摘要、默认拒绝某类请求） | 高频变化的数据（股价、天气、库存） |
| 语言能力（让模型更熟悉中文 / 藏语 / 蒙古语等低资源语言） | 业务数据库查询 |
| 蒸馏 / 压缩（让 1.5B 模仿 32B 的回答模式） | 联网搜索 |
底线原则：如果答案"每天都在变"，请用 RAG；如果答案"几乎永远一样但风格要稳定"，考虑 SFT。
成本对比表
以"为一个 1000-QPS 的客服机器人定制回答风格"为例，三种方案的开发期、部署期、更新期成本估算：
| 维度 | Prompt Engineering | RAG | SFT（LoRA） |
|---|---|---|---|
| 开发周期 | 1-3 天 | 1-2 周 | 2-4 周 |
| 人力成本 | 1 个提示词工程师 | 1 个后端 + 1 个 ML 工程师 | 2 个 ML 工程师 + 数据标注 |
| 一次性算力 | 0 | 向量化全部文档（~数十美元） | 1 张 A100 × 数小时（~100-500 美元） |
| 部署成本 | 与基础 API 一致 | +向量库 +检索器 QPS | 自托管 GPU 或走厂商 FT API |
| 更新成本 | 改一段话，立即生效 | 增量入库，几分钟生效 | 重新训练，数小时 |
| 推理延迟 | 同基线 | +20-100 ms（检索环节） | 同基线或更快（prompt 变短） |
| 可解释性 | 高（能直接看 prompt） | 中（能看检索结果） | 低（模型黑盒） |
| 失败的代价 | 零 | 小（退回基础 API） | 大（模型可能退化） |
组合方案
真实项目里，三种方案通常组合使用：
- SFT + RAG：微调模型学会"按公司风格回答检索到的文档"——把风格固化到权重，把事实委托给检索
- Prompt + SFT：先用 prompt 迭代到"够用"，再用 SFT 把高频场景的 long prompt 压缩成短 prompt
- 蒸馏 + RAG：用大模型 + RAG 生成高质量回答作为数据，蒸馏到小模型（SFT）
真实案例（Cursor / Perplexity / Claude Code 等产品）：几乎都是"基础模型 + 精心设计的长 prompt + RAG"为主，模型微调只出现在"默认行为"、"输出格式稳定性"等非常窄的维度上。微调不是产品的主轴。
决策清单
动手之前，把下面这份清单过一遍：
- 我明确知道"模型坏在哪里"——风格？格式？事实？推理？
- 我已经用 prompt + few-shot 跑过一个定量的评估集，知道基线分数
- 我知道自己手里有（或能在 2 周内准备出）至少 500 条高质量 SFT 样本
- 我估算过算力预算（至少 1 张 A100-40G 或等价云服务）
- 我知道如果微调失败，会退回到什么基线
只有 5 条全勾，才算真正准备好进入下一节的 SFT 流水线。
本节小结
| 决策 | 建议 |
|---|---|
| 第一招 | Prompt Engineering——零成本、分钟级迭代 |
| 事实类问题 | RAG——把知识外置，模型只做"阅读理解" |
| 风格 / 格式 / 默认行为 | SFT——把能力固化到权重 |
| 进一步对齐偏好 | DPO / GRPO（姊妹课程：大语言模型后训练） |
| 组合使用 | SFT + RAG 是工业界最常见的组合 |