很多团队第一次接触模型微调，是因为通用模型在业务问答里“差一点”：格式不稳定，术语回答泛泛，偶尔把流程说反。于是很自然想到拿几百条对话喂一遍，期待它立刻变成熟手。可从工程角度看，微调更像改衣服，不像换引擎。你得先知道哪里不合身：是知识缺失，还是输出格式不守规矩，抑或任务边界不清。不同问题，解法不一样。
先分清“不会”和“不听话”
如果模型缺少的是事实，比如某项内部规定、某个产品参数，微调未必是稳妥的入口。参数更新能改变表达习惯和任务模式，却不等同于可靠的知识库。把频繁变动的事实塞进权重里，维护成本高，更新也笨重。更常见的做法，是用检索把资料摆在模型面前，让它基于材料回答。反过来，如果模型知道该怎么做，却总是答得太散、格式漂移，那才更接近微调擅长处理的范畴：用一批稳定、干净、标注一致的样本，把行为往目标格式上收。
样本质量先于数量
准备数据时，常见误区是“先攒够量”。可从实践看，几十条自相矛盾的样本，足以让模型学到模糊的边界。更值得先做的，是把任务写成可判定的样子：输入是什么，期望输出是什么，异常输入怎么处理，哪些内容必须拒答。标注者如果对标准理解不一致，训练集里就会埋下互相拉扯的信号。这样的模型微调，最后往往不是能力不足，而是目标本身没对齐。
轻量与全参，不只是成本选择
训练方式上，轻量微调通常只调整少量附加参数，保留原模型的大部分能力；全参微调改动更广，适合任务形态与原始模型差异较大的情况。选择时不必只盯着显存和时长，还要看后续维护：业务规则变更时，能不能快速重训，能不能回滚，能不能解释这次改动带来的影响。把模型微调当成一次性的项目交付，容易在上线后被动；把它当成持续维护的资产，才会认真对待版本、评估集和回归测试。
评估集是训练的刹车
很多演示很漂亮，因为问题都是围绕训练样本挑的。真正上线后，用户会带着错别字、省略上下文、前后矛盾的需求进来。因此，在训练之前就该留出一批不参与训练的评估样本，覆盖正常请求、边界请求和明显越界的请求。每次调整数据或参数，都拿同一套标准去跑。不是为了追求一个漂亮分数，而是为了看清这次改动有没有伤到其他能力。没有评估的训练，像闭着眼睛调音，响是响了，但未必在调上。
有些问题不该交给训练
还有一种常见冲动：把产品体验问题都推给模型。回答慢，可能是检索链路太长；回答空泛，可能是提示词没有约束；回答前后不一致，可能是资料源本身冲突。这些环节不先排查，直接开始训练，往往只是把症状挪了个位置。更稳妥的顺序是，先确认通用模型加提示词能做到什么程度，再补检索，最后才判断是否需要通过训练去固化行为。这个顺序不绝对，但能减少无效投入。
所以，这项训练值得认真对待，但不是“让模型更懂业务”的快捷按钮。它更像一次有边界的工程改造：目标要窄，样本要稳，评估要独立，维护要提前想好。下一次有人提出“拿数据微调一下”，不妨先追问一句：我们缺的到底是知识、格式，还是任务定义？这个问题答清楚了，训练才开始有意义。