微调第一问：什么时候该调，什么时候做 RAG

聊微调之前，最容易犯的错是：先问“怎么调”，而不是先问“该不该调”。
这篇先把决策边界讲清楚，核心只回答三件事：微调到底在解决什么问题、它和 RAG/Prompt 的分工是什么、以及在项目里怎么做一个可执行的选型判断。

微调主要改“模型行为分布”，不是直接补最新知识。

  • 它擅长让模型在特定任务上更稳定：输出风格、格式约束、术语习惯、拒答边界；
  • 它不擅长单独解决“知识时效性”问题（昨天更新的条款，今天就要生效）。

所以你可以先记一条：

  • 行为一致性问题优先想微调；知识新鲜度问题优先想检索。

RAG 的核心价值是“把答案建立在可更新外部知识上”：

  • 文档变更后可快速生效，不用每次重训；
  • 回答可附引用，审计更友好；
  • 成本通常低于持续训练和多版本模型维护。

在企业场景里，如果问题是：

  • “最新制度是什么？”
  • “这个条款本周有没有更新？”

这类都更像 检索问题，不是微调问题。

可以优先考虑微调的典型信号：

  • 输出格式强约束：固定 JSON schema、严格字段语义；
  • 领域表达一致性：术语、口吻、模板长期稳定；
  • 复杂任务习惯化：同类任务高频重复，靠 Prompt 难稳定；
  • 基座模型理解不足：即便有检索，推理与归纳方式仍不达标。

换句话说：你想让模型“长期像同一个团队成员那样说话和做事”时，微调价值会变大。

把大量事实知识硬塞进权重，通常会遇到几件事：

  • 更新慢：知识一变就要重新训练；
  • 可解释性差：很难追溯某个结论来自哪条原始证据；
  • 维护重：版本管理、回滚、评估都更复杂。

工程上更稳的组合一般是：

  • RAG 负责“知道什么”；
  • 微调负责“怎么说、怎么做”。

先问四个问题：

  1. 你的问题是不是强依赖最新外部知识？
  2. 你的输出是不是有稳定格式和风格要求？
  3. 仅靠 Prompt + 检索是否已经能达到目标？
  4. 你能否承担数据标注、训练、评估和版本维护成本？

这 4 个问题里，职责不一样：

  • Q1/Q2 是“路线选择题”（选 RAG、微调还是组合）；
  • Q3/Q4 是“开工门槛题”（现在要不要上微调）。

可以按两步走：

  • Q3=是（Prompt + 检索已达标）：先不做微调，优先把评测和稳定性做扎实；
  • Q4=否（当前扛不起训练与维护成本）：先不做微调，继续走 Prompt/RAG 路线；
  • 只有当 Q3=否 且 Q4=是，才进入第二步做技术路线选择。
  • Q1=是，Q2=否：优先 RAG；
  • Q1=是，Q2=是：RAG + 轻量微调；
  • Q1=否，Q2=是：优先微调；
  • Q1=否，Q2=否：先别微调，先做 Prompt 与流程优化。
  • 微调擅长的是行为与输出一致性；
  • RAG擅长的是知识更新与可追溯；
  • 大多数真实项目里，最终不是二选一，而是分工组合。

把这条判断线先立住，后面再谈 SFT、LoRA、上线评测，才不会陷入“为了微调而微调”。