一位做售后的朋友抱怨，通用大模型回答问题意思都对，语气却不像他们公司的人。这种“差不多但不完全对”的落差，往往是把人推向模型微调的第一个理由。
它改的是倾向，不是资料库
很多人对微调的第一印象是“把公司的资料喂进去”。这个理解偏了。资料类的东西更适合检索增强：把相关片段找出来放进上下文，让模型当场读。而微调改动的是模型权重，改变的是它在给定输入下倾向于输出什么——格式、语气、判断的取舍、遇到模糊问题时的处理方式。你没法靠它可靠地记住一份价目表，但可以让它学会“遇到不确定就先问，而不是硬答”。
这也解释了为什么模型微调常被用来固化一种行为，而不是扩充知识。行为样本是可以被写出来的：输入什么，期望输出什么。知识的边界却很难用几千条问答框住，漏掉一条，模型就可能编。
数据比方法更容易出错
工具链已经很成熟，全参数微调和 LoRA 这类参数高效的做法都有现成实现，跑起来不难。难的是样本本身。常见的问题不是数量不够，而是标准不一致：同一类问题，标注的人今天这样答，明天那样答；或者样本里混着几种风格，模型学到的是一团平均。它不会告诉你哪里矛盾，只会把矛盾学进去。
另一个容易被忽略的是遗忘。模型在窄任务上训练久了，原本的通用能力会退化，回答变得机械，换个话题就露怯。实践里常见的缓解办法，是把一部分通用数据混进训练集，或者训练后做对比测试——不要只看它在训练集上多像，还要看它在没见过的输入上是否还讲道理。
什么时候不值得做
如果需求只是“让它知道我们的产品参数”，检索就够了；如果只是“让它语气客气一点”，提示词往往也够。微调的性价比出现在那些要求稳定、反复出现、又难以用文字描述清楚的场景里：输出必须严格遵循某种内部格式，或者一类判断需要长期保持一致的取舍标准。换句话说，当你在提示词里反复写同一段要求，还总被模型选择性忽略时，才值得考虑用模型微调把这件事固定下来。
还有一点常被低估：微调之后，模型的行为就和那批数据绑定了。业务规则变了，数据要重做，训练要重跑。它不是一次性投入，而是一条需要维护的链路。先想清楚这一点，再决定要不要动手，比纠结选哪个框架重要得多。