前几天有人拿着一份跑了三天的训练脚本问我：损失曲线降得很漂亮，为什么上线之后还是答非所问。我打开数据目录看了一眼——几百条从聊天记录里随手导出的问答对，问题重复，答案长短不一，有几条答案本身就在推卸责任。训练过程没出问题，它只是很忠实地学会了这批数据的样子。
这种场景我见得不算少。模型微调常常被当成一个“让它懂我们业务”的开关，好像只要喂进去自家的语料，模型就会自动变得贴切。实际做下来，卡住人的往往不是训练本身，而是训练之前和之后的那两段。
它改变的是倾向，不是知识库
微调的做法，是在一个已经预训练好的模型上，用自有数据再走一小段训练，让权重朝你的任务偏一点。它偏的是倾向：说话的口吻、输出的结构、遇到某类问题时的处理路径。这类东西很难用提示词稳定约束，用几十上百条示例去“掰”，效果往往比反复改提示词更持久。
但它不擅长往模型里装新知识。产品参数、价格政策、流程细节，这些会变、需要溯源、需要随时撤回的内容，塞进权重里就等于把一份会过期的文档刻进石头。改一次要重训一次，还说不清模型到底记住了哪一句。
三种先别急着动手的情形
- 需要模型“知道”某份内部文档。先把文档放进检索链路或上下文里，内容更新只需换文件，不必动权重。
- 只是想让输出变成固定格式。提示词加少量示例通常够用，改起来是分钟级的事。
- 数据还没理清。用脏数据训出来的模型，会变成一个语气笃定地说错话的模型，而且更难排查。
绕不开的是数据
真要开始模型微调，大半时间会花在数据上。工作量主要在于想清楚每一条数据希望模型学到什么，而不只是把数量凑够。同一类问题，两个标注人给出的答案风格不同，模型学到的就是这种摇摆。边界样本尤其值得花时间：用户问得含糊、问得有歧义、问得超出范围时，你希望它怎么回应，这些决定体验的片段往往在数据里缺席。
还有一件容易被跳过的事：留一份小而干净的评测集。训练集上的损失只能说明它拟合了这批数据，说明不了它在真实场景里的表现。评测集不必大，但要覆盖你真正在意的那些情况，并且每次都人工看一眼输出，而不是只看一个分数。
把它当成收敛手段
我的看法是，模型微调是一种收敛手段，不是能力扩充手段。它能把一个泛泛而谈的模型收窄到你想要的表达和节奏，但收窄的同时也在丢掉一些东西——泛化能力、对边缘情况的宽容度。所以真正该问的问题不是“要不要微调”，而是“我到底想让模型在哪一点上变得确定”。
想清楚这一点，再去问数据从哪来、评测怎么做，最后才轮到显卡和训练参数。顺序颠倒过来，通常就是那条漂亮损失曲线的来源。