常见的一幕是这样：业务方拿着十几条截图走过来，说模型答得不对，问能不能微调一下。截图里的毛病五花八门——有的引错了内部文档的条款，有的把输出格式写乱了，有的在明显该追问的时候硬答。它们看起来都是“模型不行”，成因却完全不同。
把这些错误摊开看，大致能分成四类：模型不知道某件事；模型知道但不会按你要的方式做；模型不该在这个场合回答；模型能做但输出不稳定。模型微调真正擅长的，是第二类和第四类——它改变的是输出的习惯，而不是往参数里塞进一份新文档。
它改的是习惯，不是条目
把微调理解成“继续教育”会更准确。基础模型在预训练阶段见过大量文本，学会了语言的一般规律；微调则用一批带答案的样本，把它往某个具体方向推一推：说话更简短、固定输出某个结构、遇到边界问题先澄清而不是硬答。这类特征在样本里反复出现，模型容易捕捉，因此对风格和格式的塑造相当有效。
但如果指望它记住一份刚更新的产品手册，效果通常不稳定。参数记住的是分布，不是条目。文档类、时效类、长尾类的知识，交给检索更省事：把相关内容取出来放进上下文，模型负责组织语言。这条路径的好处很实在——改一处文档就改一处行为，不必重新训练。
数据这一关绕不过去
真正劝退人的往往不是训练脚本，而是那几百上千条样本。从系统日志里捞出来的真实对话脏得很：用户表述含混、上下文缺失、同一个问题有好几种合理答法。标注的人如果只拿到一句“按标准回答”，也只能凭感觉，交上来的东西前后不一致，训练出来自然拧巴。
所以动手之前，通常要先把“什么算好回答”写清楚，写到别人看完能照着判断的程度。写不清楚，说明这件事本身还没想明白，训练只会把混乱固化进模型。
样本的写法也有讲究。与其只让模型看正确答案，不如在样本里保留一些“应该拒答”“应该澄清”的情形，否则它对边界的理解会偏。数量上不必贪多，一致性比规模更要紧——口径统一的一批样本，往往比几批拼凑起来的数据更管用。
有些问题一行规则就够了
在决定训练之前，值得先做一轮排除：
- 能不能用提示词把要求说清楚，把格式和口径固定下来；
- 能不能用检索补上缺失的信息，让模型只负责表达；
- 能不能在输出之后加一层格式校验或关键词拦截；
- 能不能把复杂任务拆成两步，先抽取再生成。
这些问题只要有一个答案是“能”，成本就比训练低一个量级，迭代也快得多：改一句提示，几分钟能看到效果；动一次参数，就要重新走数据、训练、评估的完整流程。一个粗略的判断标准是——如果这条错误的成因能用一句话描述，并且这句话可以直接写成规则，那就不必去动参数。只有当规则越写越长、彼此打架、维护成本开始上升时，才轮到模型微调出场。
训练完才是麻烦的开始
评估这件事比训练本身更耗费耐心。训练损失降下去，不代表线上表现变好。常见的情况是：模型学会了目标格式，却在这上面过拟合——稍微换个问法就露馅；或者在专项上进步明显，通用对话却变得生硬。后者尤其容易被忽略，因为没人会专门去测“它原来会的东西还在不在”。
所以评估集里最好同时放两类样本：一类是本次要解决的问题，另一类是与本次目标无关、但原本表现尚可的日常问题。前者看进步，后者看退化。人工抽看依然少不了，自动指标很难判断一段回答是“格式对了但意思偏了”。
回头看，那些推进顺畅的项目有个共同点：动手之前就把错误分好了类，把“什么算好”写成了别人能照着判断的标准。而卡住的项目，多半卡在同一处——说不清模型到底哪里不对，只能说“感觉不太行”。模型微调不是一个开关，它更像一次有针对性的调整：知道要改什么，才谈得上怎么改。