跳到主要内容

大模型微调：什么时候该做，怎么做，和 RAG 有什么区别

“微调”这个词很容易被滥用。很多团队一遇到效果不好，就说要微调模型。这个判断往往太早。更准确的理解是：微调（Fine-tuning）不是给模型临时补资料，而是通过训练数据或反馈信号，改变模型在某类任务上的输出偏好和行为分布。

0. 面试速答（30 秒版 TL;DR）​

  • 微调本质上是改模型参数，不是改 Prompt。
  • 它更适合解决：
    • 特定格式输出不稳定
    • 特定语气风格不一致
    • 某类任务需要更高命中率
    • 想把大模型能力蒸馏到更小、更便宜的模型
  • 它不适合优先解决：
    • 知识过时
    • 需要引用最新资料
    • 只是 Prompt 还没写好
  • 常见路线包括：
    • SFT（监督微调）
    • LoRA / QLoRA 这类参数高效微调
    • 偏好优化或强化式微调
  • 一句话：RAG 主要改“上下文”，微调主要改“参数习惯”。

1. 什么是微调，别和“喂资料”混了​

很多人会说“我把公司文档喂给模型，就是微调”。这通常不对。

更准确地说：

  • RAG 是把资料在推理时临时塞进上下文
  • 微调 是通过训练，让模型本身在权重层面更偏向某种行为

所以微调更像：

  • 让模型学会某种回答风格
  • 让模型更稳定地遵循输出格式
  • 让模型在某类固定任务上命中率更高

但它并不等于：

  • 模型自动掌握了所有最新知识
  • 模型以后永远不会犯错

2. 什么时候值得做微调​

真正适合做微调的场景，通常有这几个特征：

2.1 任务长期稳定重复​

如果你的任务每天都很像，例如：

  • 工单分类
  • 结构化字段抽取
  • 特定话术生成
  • 某种固定格式报告输出

这时微调往往有价值。

2.2 基础模型能做，但稳定性不够​

比如：

  • 10 次里 6 次答对
  • JSON 格式总是偶尔跑偏
  • 专业术语风格不统一

这类“有能力但不稳定”的问题，常常比“完全不会”更适合微调。

2.3 希望用更小模型承接任务​

很多团队做微调，不是为了把模型变得“更聪明”，而是为了：

  • 用更小的模型
  • 保住可接受的效果
  • 降低推理成本和延迟

这其实是非常现实的工程目标。

3. 什么时候不要上来就微调​

3.1 你需要的是最新知识​

如果问题是：

  • 知识库经常更新
  • 答案必须引用最新文档
  • 需要查公司内部实时数据

那通常应该先做 RAG，而不是微调。

3.2 你连评估都没有​

很多团队会说“感觉模型不够好，所以去微调”。这是典型错误。

没有评估，你就不知道：

  • 现在到底差在哪
  • 微调后到底有没有提升
  • 退化发生在哪类样本

3.3 Prompt 还没认真优化​

如果你连：

  • 系统提示词
  • 示例输入输出
  • 输出约束
  • 工具选择

都没优化过，就急着微调，通常性价比不高。

4. 标准微调流程怎么走​

一个比较成熟的微调流程，通常是这样的：

这里最关键的一步，其实不是“训练”，而是：

  • 先有评估，再谈训练。

没有这一点，微调很容易变成黑盒试运气。

5. 常见微调方法怎么理解​

5.1 监督微调（SFT）​

这是最常见的一种。

做法是给模型喂大量“输入 -> 理想输出”样本，让模型学会更稳定地产生你想要的结果。

它适合：

  • 分类
  • 结构化抽取
  • 固定格式生成
  • 语气与风格统一

如果面试官问最常见的微调方法，优先答 SFT。

5.2 参数高效微调（LoRA / QLoRA）​

这类方法的核心思路是：

  • 不去全量改所有参数
  • 只训练一小部分增量参数

它的优势在于：

  • 显存压力更低
  • 训练成本更低
  • 更适合开源模型场景

所以在工程实践里，LoRA 很流行，不是因为它“理论最先进”，而是因为它更现实。

5.3 偏好优化 / 强化式微调​

这类方法不是只给“标准答案”，而是通过：

  • 偏好对比
  • 奖励信号
  • 可编程评分器

去让模型更偏向高质量输出。

它更适合：

  • 复杂推理
  • 多目标权衡
  • “没有唯一标准答案，但可以评分”的任务

但它通常也更重，更依赖评估和反馈设计。

6. 微调和 RAG，到底差在哪​

维度微调RAG
改变对象模型参数推理时上下文
适合问题风格、格式、行为稳定性最新知识、外部知识、可追溯回答
更新成本较高，需要重新训练较低，更新文档和索引即可
是否天然带引用不天然带更容易带来源
是否适合实时知识不适合优先解决非常适合

一句好记的话是：

  • RAG 像开卷考试，微调像改学生的答题习惯。

7. 数据集怎么做，往往比训练方法更重要​

这是实战里最核心的一点。

7.1 数据质量通常比数据量更重要​

如果样本本身就：

  • 逻辑不一致
  • 口径混乱
  • 标签有噪声

那微调出来的模型也会继承这些问题。

7.2 要覆盖边界情况​

很多团队只收集“正常样本”，结果上线后：

  • 口语输入不会
  • 长文本不会
  • 脏数据不会
  • 模糊问题不会

所以训练集必须覆盖难样本和边界样本。

7.3 训练集和评估集要分开​

如果你拿训练集去验证，几乎肯定会高估效果。

7.4 最小示例​

下面给一个极简的 JSONL 样本格式示意：

{"messages":[{"role":"system","content":"你是客服分类助手"},{"role":"user","content":"我要退货，包装已经拆了"}],"response":{"label":"refund_request","reason":"用户表达退货诉求"}}
{"messages":[{"role":"system","content":"你是客服分类助手"},{"role":"user","content":"为什么还没发货"}],"response":{"label":"delivery_status","reason":"用户咨询物流进度"}}

这个例子不是为了说明某家平台的精确训练格式，而是为了说明：

  • 输入要真实
  • 输出要稳定
  • 标签口径要统一

8. 评估微调效果，不能只看“感觉更像了”​

成熟团队至少会看 4 类指标：

8.1 任务准确率​

例如：

  • 分类准确率
  • 召回率
  • 命中率

8.2 格式稳定性​

例如：

  • JSON 是否总能解析
  • 字段是否总齐全
  • schema 是否总能命中

8.3 边界样本表现​

很多模型在正常样本上看着不错，一到异常输入就崩。所以一定要专门测边界集。

8.4 成本与时延​

微调有时不是为了提高“绝对智力”，而是为了让更小模型也能把任务做好。那就必须同时看：

  • 延迟
  • token 消耗
  • 单次成本

9. 面试高频追问​

9.1 为什么很多时候 RAG 比微调更应该先做？​

标准答法：

因为很多业务问题本质上是知识更新和资料引用问题，而不是模型行为偏好问题。RAG 更容易更新、更容易追溯、上线成本也更低，所以通常应该先验证 RAG 和 Prompt 工程，再决定是否微调。

9.2 微调最容易失败的地方是什么？​

标准答法：

最容易失败的是数据质量和评估设计。不是训练方法本身，而是训练数据不代表真实任务、标签口径不一致、评估集和线上问题脱节，最后导致微调后看起来“更像了”，但真实业务并没提升。

9.3 为什么 LoRA 这类方法这么流行？​

标准答法：

因为它以更低的训练和部署成本，提供了足够实用的定制能力。对很多开源模型项目来说，LoRA 的性价比远高于全量微调。

10. 常见误区​

  • 误区一：把“补知识”当成微调目标。 最新知识问题通常更适合 RAG。
  • 误区二：没有评估就开始训练。 这样很难判断是否真的提升。
  • 误区三：认为数据越多越好。 低质量大数据会把模型带偏。
  • 误区四：微调后就不需要 Prompt 了。 现实里两者往往是配合关系，不是替代关系。

11. 版本与事实说明​

截至 2026 年 3 月 30 日，商业闭源平台和开源模型生态都已经提供多种微调路线。公开文档显示，OpenAI 等平台同时支持 监督微调 和更偏反馈信号驱动的 强化式微调；而在开源模型工程实践里，LoRA / QLoRA 仍然是非常常见的落地方案。需要注意的是，不同平台可微调的基座模型、数据格式、训练额度和计费方式都可能变化，真实项目应以对应平台最新文档为准。

12. 速记要点​

  • 微调是 改参数，不是单纯改 Prompt
  • 优先适合 风格、格式、稳定性、特定任务命中率
  • 最新知识问题通常先看 RAG
  • 成败关键常常不在算法，而在 数据质量 + 评估设计
  • 开源实践里常见路线是 LoRA / QLoRA