何时该微调：微调 vs 提示工程 vs RAG

一句话定义

微调决策框架回答一个问题：当模型表现不达预期时，应该改提示、上检索，还是动权重——三者解决的是不同层面的问题。

为什么重要

微调是有真实成本的操作：要清洗数据、要占显卡、要维护训练管线、要做回归测试。大量「效果不好」的问题其实靠提示工程或 RAG 一天内就能解决；也有大量团队在提示工程的天花板上空耗数月。选错工具的代价不是慢，而是整条技术路线作废。

前置知识

kp-001 中微调的定义与两种典型用途（格式/风格类行为、领域话术流程）。

核心概念

三者的作用对象不同：

• 提示工程（Prompting）：不改模型，改输入。适合行为可以「说清楚」的任务。
• RAG（检索增强生成）：不改模型，改上下文，外挂知识库。适合知识频繁更新、需要可溯源的场景。
• 微调：改模型本身。适合行为「说不清楚但示范得出来」、或需要稳定内化的任务。

原理与机制

决策按四个问题依次过滤：

1. 失败模式是什么？ 格式总是跑偏、语气不对、指令遵从差 → 行为问题，微调/提示工程；答错事实、知识缺失 → 知识问题，RAG 优先。
2. 提示工程试过吗？ 先用 few-shot 示例 + 结构化输出约束做基线。若提示里写清规则就能解决，永远不要为此微调。
3. 知识是否频繁变化、是否需要溯源？ 是 → RAG；知识静态且需要「长在模型里」（如行业话术、固定流程）→ 微调。
4. 成本与延迟约束？ 需要私有化、要降单次成本、要小模型达标 → 微调后部署小模型。

典型组合拳是三者叠加：微调固化行为与风格，RAG 提供动态知识，提示工程处理运行时变化。生产系统很少只靠一种。

图示

模型答错/不会? ─是→ 知识更新频繁或需溯源? ─是→ RAG
     │                        └─否→ 补数据/微调注入稳定知识
     └─否(格式/风格/稳定性差)
            → few-shot 提示能解决? ─是→ 提示工程
                                 └─否→ 微调

直观类比

提示工程像给新员工写详细的操作手册；RAG 像给他配一个随问随查的资料库；微调像送他去岗前培训班，把技能长在身上。手册最便宜，培训最贵，但各有不可替代的场景。

实例或案例

某法务团队需求是「按所内固定结构输出合同审查意见，并引用最新法规」。拆解后：输出结构用 few-shot 提示即可约束（不微调）；最新法规用 RAG 注入（不微调）；但「所内审查口径」这种写不清、示范得出的风格，用 800 条历史意见微调后才稳定。最终方案是提示 + RAG + 一次 LoRA 微调的组合。

操作步骤

把「想微调」转成可验证的决策记录：写下当前失败案例 20 条 → 分类为知识问题或行为问题 → 先做提示工程基线并量化（格式遵从率、抽检合格率）→ 基线不达标且失败模式是行为类 → 才立项微调，并把 20 条失败案例转成训练数据种子。

排错清单

• 提示加示例有效但不稳定：先扩提示上下文、加输出格式校验重试，仍不稳定再考虑微调。
• RAG 后仍答错：检查检索召回（chunk 切分与排序），别急着怪模型。
• 需求方说「就是要个我们自己的模型」：回到失败案例与指标，确认微调要解决的具体可度量问题，否则不立项。

常见误区

• 把知识问题当行为问题：模型不知道法规最新修订，微调一万条也追不上法规更新。
• 跳过提示基线直接微调：没有基线，微调后无法归因是数据的功劳还是本就够用。
• 三者互斥：生产级方案几乎总是组合使用。

与其他知识点的关系

决策做完了，数据怎么来见 kp-010；怎么把它跑成一次完整训练见 kp-021。

延伸阅读

本节不适用：本节为决策方法论，无单篇奠基文献，建议结合自己业务的失败案例清单做演练。

自测题

1. 客服模型总把退款话术说得太生硬，格式没问题、知识也全，该先做什么？

答：先做提示工程基线（给风格示例与约束）；若稳定达标就不微调；若不稳定，把优质话术整理成数据做风格微调。

1. 什么信号说明该上 RAG 而不是微调？

答：知识频繁更新、需要引用溯源、或答错的是事实性内容而非行为格式。

1. 为什么微调立项前必须先量化提示工程基线？

答：为归因与验收——没有基线就无法证明微调带来的增量，也无法在微调退化时及时发现。