供应商将你的模型标识符重定向到特定租户的微调模型，而其他人使用的却是基础模型

客户支持团队升级了一个问题：“你的助手以前能正确处理退款资格问题。但上周开始出错了。”值班工程师调取了对话记录，在开发账号中使用相同的模型标识符回放了完全相同的提示词（prompt），得到了正确的回答，于是以“无法复现”为由关闭了工单。两周后，另一名客户提出了同样的投诉。工程师再次在同一个开发账号中进行回放，结果依然正确。团队开始归咎于没人做过的提示词更改。

请求中的模型标识符从未改变。响应字段中的字符串与请求字段中的字符串匹配。评估套件在六周内一直保持绿色。生产流量使用的模型权重与评估套件使用的模型权重是两套不同的集合，而且在该账号的整个生命周期中一直如此——直到过去这六周，它们变成了同一套权重，而团队注意到这一点仅仅是因为客户先发现了。

这就是当你把模型标识符视为权重的名称，而它实际上只是供应商可以自由修改的路由决策标签时会发生的情况。

标识符是路由标签，而非模型

一个高业务量的客户与他们的供应商协商了一项“首选模型”安排：该客户的流量会指向一个针对其关注的语料库训练过的租户范围内的微调变体，而该变体通过客户代码已经在调用的同一个公共模型标识符提供服务。客户不需要更新 SDK、网关配置或提示词模板。字符串 claude-sonnet-4-6（或 gpt-5.1，或任何其他标识符）持续出现在请求和响应的载荷中。微调在 API 边界是不可见的，这正是客户在签署合同时所要求的。

供应商的路由层对每个请求做出基于租户的决策。对于你的租户，标识符解析为存储在专用池中的特定权重集。对于其他所有人的租户，相同的标识符解析为基础模型。在这两种情况下，响应载荷都会回显请求的标识符，因为这就是 API 合约所保证的：模型字段告诉你请求的是哪个标识符，而不是哪个权重做出了回答。

大多数团队永远不会注意到这种差异，因为“为我们的领域微调过”和“带有系统提示词的基础模型”之间的差异平均而言足够小，以至于注册时的 A/B 测试就能证明该计划的合理性，随后便没人再进行重新验证。当以下三种情况之一发生时，这种差异就会变成问题。第一，供应商在季度中期的运营审查中发现专用容量成本不划算，将标识符重新指向了基础模型。第二，团队的评估账号由于位于没有租户范围路由的开发工作空间中，一直使用的是基础模型，从未见过微调效果。第三，生产流量向微调模型所针对的专业领域倾斜，以前被平均掉的差距在客户面前变得显而易见。

为什么评估套件一直保持绿色

该团队构建评估套件的方式和所有人一样：一个带有 API 密钥的开发账号、一套具有代表性的提示词数据集、一个评分标准以及一个每晚运行的 CI 任务。评估账号属于一个与生产环境隔离的工作空间，原因与其他所有密钥都存放在独立工作空间的原因相同。评估账号没有为专用容量付费。评估账号没有加入首选模型计划。自开发工作空间创建以来，评估账号一直运行在基础模型上，因为路由决策是绑定到租户的，而不是请求中的标识符。

评估套件的工作是证明“这个标识符会产生这些回答”。对于提供给评估账号的模型（即基础模型），它一直正确地履行着这项职责。当生产租户运行在微调模型上时，评估套件的证明并不描述生产环境。当生产租户被重新指向基础模型时，评估套件的证明突然描述了生产环境——但这种证明并没有变得更准确；只是生产环境退化到了与评估证明的准确度相匹配的程度。由于评估所测量的任何内容都没有改变，数值也就没有波动。

监控评估套件的团队看到一条平稳的绿线，得出模型稳定的结论。专业工作负载上的客户侧质量退化了微调模型原本提供的提升部分，这在特定领域的任务评分标准中很容易达到 10–15 分，但在任何平均了长尾普通流量的总指标中都是不可见的。

这种差异是如何隐藏了六周之久的

六周之所以成为时间线，是因为这种退化必须与所有其他可能导致模型输出本周比上周稍差的原因竞争。比如人们在没互相告知的情况下修改系统消息导致的提示词漂移；添加到注册表并改变模型规划的工具描述；丢弃了早期对话轮次的上游上下文窗口更改；显现出新提问模式的客户构成变化；或者是供应商侧的温度或采样器更改，这些更改表现为 system_fingerprint 的差异，但由于大家已经停止跟踪该字段而被忽视了。

加载中…