一个常见的场景是：团队用通用模型做了原型，演示时效果不错，真正放进业务流里却开始“跑偏”。输出格式不稳定，术语前后不一致，遇到内部流程就答得含糊。这时候，讨论很容易滑向一个答案——做模型微调。
这个答案不算错，但常常来得太早。微调不是给模型“补课”那么简单，它更像用一批示例去改变模型的行为习惯。习惯能不能被改对，取决于你给它的示例是否稳定、任务是否清晰，以及你是否知道改完之后该怎么验收。
先分清：你要补的是知识，还是行为
很多需求表面上是“模型不懂我们”，拆开看却是两类问题。一类是知识不在模型里，比如内部制度、产品参数、最新流程；另一类是知识在，但输出方式不对，比如分类口径、回复语气、字段顺序、拒答边界。前一类问题，检索增强往往更直接：把相关资料找出来，放进上下文。后一类问题，才更接近模型微调能发挥作用的地方。
如果任务本身还在变，今天要求摘要，明天要求抽取，后天又换成多轮问答，微调也很难跟上。示例集刚整理好，业务口径又改了。此时先把流程和输入输出定义清楚，比急着训练一个模型成本更可控。
数据不是越多越好，而是要能互相解释
微调对数据的要求，和很多人想象的不一样。它不只需要“量”，更需要一致性。两条示例如果对同一个输入给出互相矛盾的答案，模型学到的就是模糊边界。标注人员对口径理解不一致，也会把分歧写进训练集。
所以，在准备数据时，可以先做几件朴素的事：
- 把任务写成一句话，明确输入什么、输出什么、什么情况该拒答。
- 给标注人员同一套判断标准，先小批量试标，再讨论分歧。
- 保留一部分不参与训练的数据，用来观察模型是否只是记住了示例。
这些动作不耀眼，却决定了微调是在解决问题，还是在把问题藏得更深。
评估不是跑一次分数就结束
模型微调之后，输出往往会变得更“像”训练数据，这既是目的，也是风险。它可能更守格式，却对没见过的输入更僵硬；可能更熟悉内部话术，却在边界问题上更自信。评估时只看一个总体指标，容易漏掉这些变化。
更实际的做法，是按错误类型拆开看：格式错误、事实错误、拒答错误、语气偏差，分别占多少。再挑一些真实但未参与训练的输入，做人工复核。微调不是一次性交付，后面还有数据回流、版本管理和回滚准备。没有这些，模型会变成一笔说不清维护成本的资产。
我的判断：它是最后一公里，不是第一步
对多数团队来说，模型微调更像最后一公里：提示词、检索、流程约束都已经试过，仍然有稳定的行为偏差，才值得用它去对齐。若只是想让模型知道更多资料，先做检索；若只是想让输出更规整，先改提示词和校验规则；若任务边界还没定，先回去定义任务。
当然，这不意味着微调只能排在最后。当你有稳定示例、清晰口径和可复用的评估集，它确实能把通用模型拉近业务现场。关键不是追一个时髦动作，而是知道自己在改什么、为什么改、改完怎么判断没有走偏。