每个把大模型接进业务系统的团队，都会撞上同一个瞬间。有人问模型一条内部定价规则、一个产品SKU、或者标准合同里的某条条款，它答得斩钉截铁，而且答错了。
接下来的条件反射几乎全球统一：模型不懂我们的业务，微调它。
于是团队花几周时间导出工单和文档，清洗、格式化、转成JSONL，再掏钱跑训练。新模型说话更像公司的人了，术语用得也对。然后它继续编。
这不是运气差，是范畴错误。
微调改的是行为，不是事实
微调调整的是模型的权重，让它表现得不一样。当你想改变的东西是"行为"时，这非常有用。但请注意这些场景的共同点：它们关乎模型怎么回答，而不是它知道什么事实。
当目标变成"模型应该知道我们的退款政策、产品目录、以及上个季度的变更"时，你是在要求权重去扮演一个数据库。而权重是个糟糕的数据库。
微调过的模型并不会获得一种可靠的能力，去分辨自己知道什么、不知道什么。用你的文档训练，只是把概率分布往你的词汇表上推了一把；当问题落进知识空白区，模型还是会做它一贯做的事——生成听起来最合理的续写。
举个说明性的场景：一个用两年工单微调出来的客服助手，被问到上个月才推出的延保服务。它从没见过这条信息。它照样回答了，用完美的公司口吻，说的是旧延保的条款。这个答案比通用模型给出的更有说服力，所以它更危险，而不是更安全。
在你所在的领域里说得流利，和在你所在的领域里说得准确，是两件事。
业务知识不是静态的
价格会变，政策会修订，产品会下架，一条新规落地，三份文档要重写。
如果这些知识住在权重里，每一次更新都意味着重建数据集、重新训练、重新评估、重新部署。现实中，团队不会每周做这件事。于是模型悄悄过期，而且没人确切知道哪些事实已经陈旧。
对比一下检索方案：一份文档改了，你重新建索引，下一次查询就能看到新版本。更新周期是分钟级，不是一个项目周期。
当答案来自检索，你可以指出它依据的是哪份文档的哪个片段。你可以把它展示给用户，可以记录日志。有人质疑答案时，你能查清是来源本身错了，还是模型读错了。
当答案来自微调后的权重，没有来源可指。知识弥散在数十亿参数里。你没法引用，没法审计，也没法告诉合规团队某个说法从哪来。
对任何面向客户、受监管、或涉及合同的场景，仅这一条就足以终结讨论。
先把无聊的部分做扎实
在训练自定义权重之前，先投资那个无聊的部分：检索。一条典型的链路是这样的：
大部分质量来自那些和模型毫无关系的东西。这些活都不光鲜，但对知识密集型的用例来说，回报全都高于跑一次训练。
这不是说"永远不要微调"，而是"为正确的理由微调，而且通常要晚一点"。事实始终来自索引，权重负责行为。
微调教模型怎么说话，检索告诉它此刻什么是真的。大多数"模型不懂我们业务"的问题，其实是第二类问题，穿上了第一类问题的外衣。
热门跟贴