AI 应用工程入门（十二）：为什么微调不是第一选择？

很多人一提到定制 AI，就想到微调。但在今天的应用工程里，微调的使用场景比想象中窄。多数问题应该先看 Prompt、Skill、RAG、Tool Calling 和评测能不能解决。

题目 1：什么是微调？

标准答案：微调是在已有模型基础上，用自己的训练数据继续训练，让模型更适合某类任务、格式或风格。

工程要点：微调不是从零训练大模型，也不是把新知识可靠塞进模型。它更像改变模型的行为习惯。

题目 2：什么时候适合微调？

标准答案：当任务稳定、样本很多、格式固定、需要特定语气或高频分类抽取时，可以考虑微调。

工程要点：比如固定格式输出、客服话术风格、标注任务、海量相似分类、把复杂 Prompt 固化成模型能力，都可能适合微调。但前提是有高质量数据和评测集。

微调数据通常长得像一条条输入输出样本，而不是随便丢一堆文档：

{"messages":[{"role":"system","content":"你负责把用户反馈分类为 product、billing、bug、other。"},{"role":"user","content":"我付款后会员没有生效。"},{"role":"assistant","content":"billing"}]}
{"messages":[{"role":"system","content":"你负责把用户反馈分类为 product、billing、bug、other。"},{"role":"user","content":"导出按钮点了没有反应。"},{"role":"assistant","content":"bug"}]}

这类任务输入稳定、标签明确、样本容易积累，才有微调价值。如果只是想让模型知道一份新制度，应该优先 RAG；如果只是想固定流程，应该优先 Skill 或工作流。

题目 3：什么时候不该先微调？

标准答案：只是想让模型知道公司文档、知识经常更新、数据量很少、需求还没稳定、Prompt 还没调好、没有评测集时，不该先微调。

工程要点：公司知识库问答优先 RAG，业务系统操作优先 Tool Calling，多步骤任务优先 Agent 或 Workflow，项目规则和流程经验优先 Skill，输出格式优先结构化输出和校验。

题目 4：Skill 为什么会挤压微调场景？

标准答案：很多过去想用微调解决的问题，本质上只是模型不知道流程、规则、工具和输出格式。Skill 像给模型一本操作手册。

工程要点：Skill 更透明、更容易修改，也更适合变化快的工程流程。微调像改变模型习惯，Skill 像告诉模型这次任务应该怎么做。大多数应用问题，先给操作手册就够了。

题目 5：实用判断公式是什么？

标准答案：知识问题用 RAG，动作问题用 Tool Calling，流程问题用 Skill 或 Workflow，多步目标用 Agent，格式问题用 Structured Output，稳定行为问题再评测是否值得微调。

工程要点：微调不是主线能力，而是高级补充手段。主线能力是 Skill、RAG、Tool Calling、Agent 和 Eval。

完整示例：微调是补充手段，Skill、RAG、Tool 通常优先

这节课要纠正一个常见误解：不是一遇到定制需求就微调。很多问题本质上不是模型能力不够，而是模型不知道流程、没有资料、不能调用工具、输出没有约束。现在更常用的顺序是 Skill、Prompt、RAG、Tool Calling、Eval，最后才评估微调。

判断公式可以写得更工程化：

知识经常变化：优先 RAG。
需要查实时数据或执行动作：优先 Tool Calling。
需要遵守项目流程和操作规范：优先 Skill。
需要多步完成目标：考虑 Agent 或 Workflow。
需要稳定固定格式：优先结构化输出和校验。
任务稳定、样本多、格式固定、评测成熟：再考虑微调。

微调适合的是行为模式，不适合当知识库。比如把用户反馈分类为 billing、bug、product、other，如果每天有大量标注样本，微调可能有价值。

{"messages":[{"role":"system","content":"把用户反馈分类为 billing、bug、product、other。"},{"role":"user","content":"付款后会员没有生效。"},{"role":"assistant","content":"billing"}]}
{"messages":[{"role":"system","content":"把用户反馈分类为 billing、bug、product、other。"},{"role":"user","content":"导出按钮点了没有反应。"},{"role":"assistant","content":"bug"}]}

Skill 更像透明的操作手册，适合变化快的工程流程。比如一个项目规定了发布步骤、测试命令、禁用文件、提交格式，这些不应该拿去微调，而应该写成 Skill 或流程文档。

Skill 示例：
- 先读取项目规则。
- 修改前检查 git status。
- 只改与任务相关的文件。
- 运行 pnpm lint 和 pnpm build。
- 提交信息使用中文，并说明验证结果。

这一课的完整答案是：微调不是第一选择，也不是把知识塞进模型。它适合稳定行为和高频固定任务；知识更新、业务动作、流程规范和多步任务，通常有更透明、更便宜、更可控的方案。

这一篇最该带走的结论是：微调不是给模型塞知识，而是训练稳定行为。没有评测和高质量数据之前，不要把它当成默认答案。