很多团队第一次认真考虑模型微调，不是因为想研究算法，而是被一个小问题卡住了：通用模型回答得挺流畅，一放到自己的业务语境里，就开始说外行话。产品名、内部流程、客户常见问法，它都能接住表面，却接不住细节。提示词改了几轮，效果时好时坏，于是“要不要微调”被摆上桌面。
这个念头很自然，但微调不是把模型送去上课那么简单。它像是在已有能力上做局部塑形：用一批带有任务指向的样本，让模型熟悉某种输入输出关系。关键不在训练动作本身，而在样本能否稳定表达你希望它学会的判断。
先看问题，再决定要不要动参数
有些问题看起来像“模型不懂业务”，实际是知识没有送到它面前。比如政策口径、产品参数、流程说明，这类内容更新频繁，硬写进参数里未必划算。检索、规则表、结构化查询，往往能让答案对齐。反过来，如果任务反复出现，判断标准相对稳定，而且很难用几句话讲清楚，模型微调才有发挥空间。它适合学“怎么表达”和“怎么归类”，不一定适合记住随时会变的事实。
另一个容易被忽略的点是任务定义。想让模型“更专业”不是任务，想让模型把客服对话归到售后、物流、账务等类别，才是可操作的任务。样本需要围绕这个任务组织，而不是把一堆文档直接喂进去。数据里如果夹着前后矛盾的标注，模型学到的也会是摇摆。
评估不是跑一次分数就结束
微调之后，容易出现的错觉是“看起来变好了”。演示几个例子，回答确实贴近业务口吻，但真实流量里的边角问题可能被掩盖。评估集要尽量贴近实际输入，包含那些表达含糊、信息缺失、容易混淆的样本。除了看答案对不对，也要看它是否学会在不确定时收住，而不是硬编一个结论。
这里有个现实取舍：微调能提升一致性，也会带来维护成本。数据分布变了，业务口径变了，模型可能慢慢偏掉。把微调当成一次性的项目交付，后面往往要补课；把它当成持续维护的资产，才符合实际。
它更像一道边界题
我倾向于把模型微调看作一种承诺：你愿意为某类任务准备样本、定义标准、持续评估，并接受它不解决所有问题。若只是想让模型多知道几份文档，先试试检索和提示词；若任务稳定、样本可控、评估可做，再考虑动参数。这个顺序不新鲜，但能省下不少无效训练。
回到开头的场景，真正要回答的不是“微调能不能做”，而是“这个问题值不值得用微调来解决”。想清楚这一点，训练参数才有意义，模型也才可能在业务语境里减少外行话。