微调 vs RAG vs Prompt：如何选对 LLM 定制路径

结论先行：先 Prompt，再 RAG，最后才微调。90% 的"要不要微调"其实是"知识没喂对"或"prompt 没写好"。微调解决的是行为/风格/格式问题，不是知识新鲜度问题——后者是 RAG 的活。

相关阅读：RAG 架构、Prompt 工程模式、LLM 应用评估、LLM 应用架构。

1. 三条路各解决什么问题

路径	擅长	不擅长	成本/门槛
Prompt	快速试错、通用任务、注入少量上下文	大量私有知识、稳定风格	最低
RAG	私有/时效知识、可溯源、易更新	改变模型"说话方式"、复杂推理风格	中（需检索基建）
微调	固定风格/格式/领域语气、压缩长 prompt、提升特定任务一致性	注入会变的知识、可解释性	高（数据+训练+评估+运维）

一句话：知识用 RAG，行为用微调，其它用 Prompt。

2. 决策树

需求来了
  │
  ├─ 只是通用任务/少量上下文？        → Prompt（先做到位）
  │
  ├─ 需要私有/最新/可溯源的知识？      → RAG
  │
  ├─ 需要稳定的风格/格式/领域语气，
  │   或想压缩超长 prompt 降本？        → 考虑微调（PEFT/LoRA）
  │
  └─ 既要新知识又要稳风格？            → RAG + 微调 组合

3. 微调前的自检清单（很多人跳过）

在投入微调前，先确认：

Prompt 已认真优化（结构化、few-shot、锚点）——见 Prompt 工程模式。
知识类需求已用 RAG 覆盖。
有 ≥ 数百条高质量标注样本（微调吃数据质量）。
有一套评估集能证明微调后确实更好——见 LLM 应用评估。
想清楚模型迭代后重新微调的运维成本。

缺任意一条，先别微调。

4. 微调的现实选择

PEFT / LoRA：只训练少量适配参数，成本低、可多适配器切换，是当下主流性价比之选。
全参微调：成本高，除非有强算力和明确收益，一般不需要。
偏好对齐（DPO 等）：当你有"更好/更差"成对反馈、想对齐输出偏好时使用。
蒸馏：用强模型产出数据训小模型，为降本/降延迟服务（见成本与延迟优化）。

5. 常见误判

"模型不知道我们公司的规章" → 这是知识问题，用 RAG，不是微调。
"模型偶尔幻觉" → 微调救不了，靠 RAG 溯源 + 拒答出口 + 评估。
"想让它永远用我们的话术/JSON 格式" → 这才是微调（或强约束解码）的场景。
"微调一次一劳永逸" → 基座换代、业务变化都要重训，是持续成本。

小结

把三者当互补层而非竞争项：Prompt 打底、RAG 供知识、微调定行为。按"低成本→高成本"顺序推进，每一步都用评估验证收益，别一上来就烧微调。