微调还是 RAG？2026 年该怎么做决策

“想让模型懂我们的业务，该微调还是做 RAG？“这是 2026 年最常被问错的问题。答案不是二选一，而是先分清你到底缺什么。

一、先诊断：你缺的是知识还是能力

• 模型不知道某些事实（新政策、内部文档）→ 缺知识 → 偏向 RAG。
• 模型不会某种风格或格式（固定口吻、特定输出结构）→ 缺能力/行为 → 偏向微调。

一句话：RAG 补事实，微调改行为。

二、RAG：改知识，快且便宜

• 本质：外挂知识库，检索后塞进上下文。
• 优点：更新即时（改文档即可）、可溯源、成本低、无需训练。
• 缺点：受限于检索质量；上下文窗口开销；对”风格控制”无能为力。
• 适用：知识频繁变化、需要引用来源、有大量结构化文档。

三、微调：改行为，慢但深入

• 本质：用数据继续训练，把行为”刻进”权重。
• 优点：稳定复现特定风格/格式；减少长提示词开销；掌握领域语感。
• 缺点：数据准备贵、迭代慢、易过时、可能灾难性遗忘。
• 适用：固定任务、风格要求高、提示词已到瓶颈。

四、决策表

你的诉求	选 RAG	选微调
知识会变	✅	❌
需要引用来源	✅	❌
控制输出风格	❌	✅
降低提示词长度	❌	✅
快速上线	✅	❌
数据极少	✅	❌

五、别把它们对立：可以叠加

成熟方案往往是先 RAG，再微调：

1. 用 RAG 解决知识来源，快速验证价值。
2. 收集真实交互数据，找出模型反复做不好的”行为”。
3. 只对这些行为做轻量微调（如 LoRA），让模型更”听话”。
4. 微调不改知识，知识仍由 RAG 供给。

RAG 管事实，微调管表达，两者互补。

六、还有第三条路：提示词与上下文工程

在动微调之前，先问：提示词调够了吗？上下文组织合理吗？ 很多时候”模型不懂业务”其实是检索没做好、示例没给够。把上下文工程做到位，能省掉绝大部分微调需求。

七、成本与速度的现实

• RAG：改一次文档，几分钟生效，成本≈电费。
• 微调：准备数据数天，训练数小时，再验证上线，周期以周计。

先用最便宜的方案试，够用就别升级。 决策顺序永远是：提示词 → 上下文 → RAG → 微调。