什么时候微调 什么时候 RAG 什么时候 prompt
一句话速记
默认顺序：prompt 工程 → few-shot → RAG → 微调（SFT/LoRA → DPO）——上层越简单越快越便宜，只在上层确实解决不了才往下走。判断标准：① 缺知识 → RAG ② 缺格式/风格/语气 → 微调 ③ 缺最简单的指令理解 → prompt + few-shot。绝大多数生产场景不需要微调，加好 RAG 已经够。
通俗解释（5 分钟版）
先看四种手段的本质区别：
| 手段 | 改变什么 | 成本 | 灵活度 | 何时用 |
|---|---|---|---|---|
| Prompt | 给模型一段指令 | 0 | 即改即用 | 调用方式问题 |
| Few-shot | prompt 里塞示例 | 仅 token 成本 | 即改即用 | 格式/示例引导 |
| RAG | 拼检索结果到 prompt | 工程 + 向量库 | 数据热更新 | 知识不在模型里 |
| 微调 | 改模型权重 | 训练 + 部署 | 慢 | 行为/格式/风格 |
决策树（最实战的版本）：
出问题：模型行为不符合预期
│
▼
┌─────────────────────────────────────┐
│ 1. 是不是 prompt 描述不清？ │
│ → 调 system prompt │
│ → 加 few-shot 示例（2-5 条） │
│ → 加输出格式约束（JSON schema） │
└────────┬────────────────────────────┘
│ 还不行
▼
┌─────────────────────────────────────┐
│ 2. 是缺知识吗（瞎编、过时）？ │
│ → 接 RAG（知识库 + 检索） │
│ → 接工具（实时查询） │
└────────┬────────────────────────────┘
│ 还不行
▼
┌─────────────────────────────────────┐
│ 3. 是格式/风格/语言习惯不对？ │
│ → SFT（用 1K-10K 标注样本） │
│ → 同时减少 prompt 长度（省钱） │
└────────┬────────────────────────────┘
│ 还不行
▼
┌─────────────────────────────────────┐
│ 4. 是模型对"什么是好回答"理解错？ │
│ → DPO（用偏好数据） │
│ → 安全对齐 / 拒答行为优化 │
└────────┬────────────────────────────┘
│ 还不行
▼
┌─────────────────────────────────────┐
│ 5. 复杂推理 / 多步任务做不好？ │
│ → Agent 化（工具 + 循环 + 反思）│
│ → 不要靠微调强行硬塞 │
└─────────────────────────────────────┘
关键细节 / 数学直觉
1）三种手段的”擅长 vs 不擅长”
Prompt 工程
✅ 改语气、加 few-shot、限定输出
✅ 0 成本、即改即用
❌ 知识缺失（模型不懂的就是不懂）
❌ 复杂多步任务（变成超长 prompt 难维护）
RAG
✅ 注入新知识（产品文档、API、KB）
✅ 数据热更新
✅ 可解释（看检索到啥）
❌ 没法改模型语气/格式
❌ 检索质量决定上限
微调
✅ 改风格、改格式、改语言
✅ 缩短 prompt（不用每次都塞示例）
✅ 学领域 jargon
❌ 学新事实（容易遗忘 + 容易过时）
❌ 要改要重训（迭代慢）
2）具体场景对照表
| 场景 | 推荐手段 | 不推荐手段 |
|---|---|---|
| 让模型回答你公司产品文档相关问题 | RAG | 微调（文档会变） |
| 让模型用某种语气说话（“萌妹子”风格） | SFT 微调 | RAG（语气不在文档里） |
| 让模型严格输出 JSON | prompt + structured output | 微调（小题大做） |
| 让模型用某领域专业 jargon | SFT + 领域语料 | RAG（不影响语言风格） |
| 让模型拒答危险问题 | DPO + 安全 prompt | RAG |
| 让模型查实时股价 | 工具调用 | RAG |
| 让模型学公司内部代码风格 | SFT（代码补全场景） | RAG |
| 让模型学一个全新概念（自创术语） | SFT + 该术语训练样本 | RAG（除非样本极少） |
| 多步骤任务规划与执行 | Agent + 工具 | 微调 |
3）常见反模式
❌ 把 RAG 该解决的问题塞给微调：
- 例：用产品手册 SFT，结果产品更新后又要重训。应该 RAG。
❌ 把 prompt 工程能解决的塞给微调：
- 例：花 2 周准备数据微调一个”输出 JSON”的模型，prompt 加 schema + structured output 当天就 work。
❌ 微调小数据 + 期待大效果：
- < 1000 个样本的 SFT 几乎没意义——除非数据极高质量。先扩 prompt + few-shot。
❌ 不评估直接上微调：
- 没有 baseline、没有 eval set，怎么知道有没有”变好”？很多团队微调完发现还不如原版。
❌ 微调后 prompt 没简化：
- 微调的省钱本质是让 prompt 变短——你改了 prompt 风格的微调，prompt 还按原来那么长写，钱白花了。
4）成本 / 时间预算估算
| 手段 | 启动成本 | 单次迭代时间 | 推理成本变化 |
|---|---|---|---|
| Prompt | 0 | 分钟 | 0 |
| Few-shot | 0 | 分钟 | 略涨（多 token） |
| RAG | 几人天搭框架 + 数据准备 | 改库即生效 | embed + 向量 + 上下文增加 |
| SFT QLoRA | 1-2 周（数据 + 训练 + 部署） | 半天-几天 | 几乎不变 |
| DPO | 几周（数据 + 训练 + eval） | 几天 | 几乎不变 |
| RLHF (PPO) | 几个月 | 几周 | 几乎不变 |
经验：每个项目设个”先用基础大模型 + RAG，撑半年再考虑微调”的纪律——不然容易陷入”微调瞎忙”。
5）混合方案（最常见的生产架构）
user query
│
▼
┌────────────────────────────────────────┐
│ Agent (LangGraph / 自研) │
│ - 用 prompt 工程 + few-shot 描述任务 │
│ - 工具调用 │
│ - 在需要时 RAG 检索知识 │
└────────────────────────────────────────┘
│
│ 调用
▼
┌────────────────────────────────────────┐
│ LLM 推理服务 (vLLM/SGLang) │
│ - base 模型（或 SFT/DPO 微调过的） │
│ - prefix caching 减重复 prompt 成本 │
└────────────────────────────────────────┘
常见的”微调点”：
- 内部 Agent 用什么样的 system prompt 风格 → 一次 SFT 把这风格”内化”，省 token
- 严格的输出格式（自家 DSL）→ SFT
- 安全/合规对齐 → DPO
6）具身机器人场景的取舍
| 需求 | 推荐 |
|---|---|
| 让 LLM 调用机器人 skill 工具 | prompt + Function Calling，不微调 |
| 让 LLM 理解新场景词汇（“客厅”=“A 区”） | RAG 场景描述 > 微调 |
| 让 LLM 输出特定格式的动作指令 | prompt + structured output；量大上 SFT |
| 提升对家务任务的常识 | 通用模型 + RAG；条件足上 SFT 任务数据 |
| VLA 模型 fine-tune（机器人动作） | 必微调（这是另一回事，本质要学动作 token） |
延伸追问
- Q： 微调后效果反而变差了，怎么办？ → 多半是过拟合 / chat template 错 / 数据质量问题。① 看 eval set loss 走势 ② 检查训前训后通用任务有没有退化（灾难遗忘）③ 缩 epochs / 减 LR / 加正则 / 数据清洗。
- Q： RAG 命中率低怎么救？ → ① 不要先想着微调，先优化检索：hybrid search、rerank、chunk 策略 ② query 改写 ③ 训 embedding 模型（如果真的需要）④ 实在不行 SFT 教模型在没检索到时怎么 fallback。
- Q： Agent 的”长上下文 + 多工具”，要不要微调？ → 多数情况不需要。优化方向：① 缩 system prompt（裁剪 tools description）② prefix caching ③ 多轮对话压缩 ④ 路由到更小模型做简单子任务。只有当固定语气/格式/拒答行为非常稳定才考虑 SFT。
- Q： “我训练了 LLM，所以我比别人懂 LLM”——这个想法对吗？ → 在工程岗位反过来：能用最便宜的方式（prompt + RAG）解决业务问题的人比一上来就微调的人更值钱。微调是工具，不是身份。
我的记法
- 顺序：prompt → few-shot → RAG → SFT → DPO → RLHF
- 缺知识 → RAG，缺风格 → 微调
- 微调省钱的本质 = 让 prompt 缩短
- 反模式三连：用微调代替 RAG / 微调小数据空望大效果 / 微调后 prompt 不简化
- 一句话：「先把 prompt 写好，再说要不要训模型」
状态
- 已背速记
- 能讲通俗版
- 能答追问
- 在自己项目里把这棵决策树用过一次