假设一个团队把通用模型接进业务系统，回答格式总差半拍：该简洁时啰嗦，该拒答时硬答，字段偶尔还漏。下意识反应往往是找一批样本做模型微调。这个反应不算错，但值得先停一下：眼前的问题，缺的是知识，还是行为约束？
先分清：要改的是知识还是行为
微调改变的是模型对输入输出关系的偏好。它并不负责把频繁变动的文档精确塞进参数里，而是让模型稳定地遵循某种格式、语气、任务分解方式，或者学会在特定边界内拒答。若问题主要是知识更新，检索增强和工具调用对应的是另一类边界；若问题主要是行为不一致，微调才有发挥空间。两者不是互斥关系，边界取决于更新频率、错误成本和维护能力。
从训练方式看，全参数微调会改动模型全部权重，资源投入大，也可能带来通用能力回退。参数高效微调只训练少量附加参数，迭代成本可控，用于需要反复试验的场景。选择哪条路径，要看样本规模、更新节奏和团队能承担的评测负担，而不是看某种方法听起来是否时髦。
数据之外，先把边界写清楚
微调数据里容易被低估的是标注口径。同一类问题，如果标注者有的要求简短、有的要求展开，模型会学到矛盾信号。样本里缺少反例，模型就不知道什么时候该停。噪声样本还会把错误模式固化下来，训练损失下降，线上表现却可能不稳定。数量之外，先把任务边界写清楚：哪些输入必须拒答，哪些字段必须保留，哪些表达算越界。
另一个常见问题是过拟合。训练集上回答看似正常，换一种问法就露馅。留出验证集并不复杂，验证集要覆盖真实分布里的边角情况，这一点容易被忽略。只看损失曲线会漏掉问题，还要看格式遵循、事实一致性、拒答边界和通用能力是否回退。模型微调之后，输出语气可能变得笃定，但笃定不等于可靠。
评测缺位，微调容易变成盲调
没有评测标准，模型微调很容易变成凭感觉调参。今天加一批样本，明天换个学习率，到头来说不清哪次改动起了作用。一种可操作的做法是先定义任务成功标准，再建立小规模、可复现的人工评测集，记录每次数据版本和训练配置。评测集不必庞大，但要能暴露边界问题。否则线上出现一次奇怪回答，团队只能靠猜。
还要留意通用能力回退。微调后的模型在目标任务上会表现出遵循倾向，却可能在闲聊、推理或长文本处理上变得生硬。混入少量通用样本、做回归测试，都是处理这种风险的常规手段。它们不能保证万无一失，但有助于在训练阶段暴露问题。
我的判断是，模型微调不该是遇到问题的下意识反应，而应是问题被拆解之后的选项。先穷尽提示词约束、结构化输出、检索和流程拆分；如果任务稳定、样本可定义、评测可复现，再考虑训练。微调不是一次性的技术动作，它更像一项维护承诺：数据要更新，评测要迭代，版本要可回滚。没有这些准备，模型不会因为训练几轮就突然理解业务。
所以在按下训练按钮之前，不妨先写清楚：失败长什么样，谁来判定，后续数据从哪里来。想清楚这些，训练才不至于变成一场猜谜。