需求会上，常有人把一叠文档推过来，问：能不能微调一下，让模型更懂我们的业务？这句话听上去很自然，却把问题提前收窄了。模型微调确实能调整输出习惯，但它不负责替团队定义什么叫“懂”。如果数据本身没有说清楚，训练出来的只是另一种含糊。
先把“懂”拆成可观察的行为
模型微调通常不是把新知识塞进参数里，而是用一批示例告诉模型：在这类输入下，回答应该长什么样。它可能学会固定格式、专业口吻、字段抽取的顺序，也可能学会遇到信息缺失时先追问。训练集大小不是唯一问题，这些行为是否和真实工位一致，需要先看。
真实工位的输入很少干净。用户会漏填字段，会在同一句话里切换任务，会把截图和短句混在一起，也会用内部简称。训练数据若只保留整理过的长文本，模型在演示里显得顺滑，到了生产环境却容易答非所问。与其急着调参，不如先抽样比对：训练样本的句子长度、噪声程度、轮次结构和线上请求像不像。
标签口径决定模型学什么
准备训练数据时，标注规范常被当成文档工作，实际它决定了模型学什么。同一个“是否完成”字段，有人按流程节点判断，有人按用户确认判断；同一类投诉，有人按情绪归类，有人按业务类型归类。口径不统一，模型只能在不同答案之间折中。到最后，看似是模型不稳，根子却在定义不稳。
一种稳妥的做法，是先把标注分歧摊开。挑一小批样本，让不同标注者独立处理，再逐条对齐。能写成规则的就写规则，必须靠判断的保留示例。这个过程不显眼，却能减少后面反复重训。它不是一次提交，更像把团队共识固化进一组行为样本。
验证集要像“明天会来的请求”
验证阶段也容易走偏。拿随机切分的同分布数据做验证，分数通常不会太差，但它回答不了真实问题：新话术来了怎么办，长尾意图出现时会不会崩，模型是否只记住了模板。验证集应该尽量贴近上线后的请求分布，甚至刻意保留一些脏样本和边界样本。不是追求漂亮分数，而是看失败方式是否可接受。
- 输入形态是否覆盖短句、长文、缺字段和多轮追问；
- 标签是否存在同义不同标、边界模糊和多人不一致；
- 输出错误能否被人工快速发现并回流修正；
- 任务规则变化时，数据更新是否跟得上。
还要承认边界。需要频繁变化的事实、权限敏感的信息、强依赖外部系统的查询，单靠参数调整并不合适，往往要配合检索、规则或工具调用。反过来，如果任务稳定、输入输出形态清晰，微调可以帮助模型守格式、贴合内部表达。判断标准不是“能不能调”，而是“调完之后，团队能否持续维护这批数据”。
所以，下次再有人问能不能微调，我会先反问：你准备拿哪些真实请求来训练，又准备拿哪些真实失败来验证？这两个问题不清楚，模型微调很容易变成一次昂贵的形式主义。