客户支持团队升级了一个问题：“你的助手以前能正确处理退款资格问题。但上周开始出错了。”值班工程师调取了对话记录，在开发账号中使用相同的模型标识符回放了完全相同的提示词（prompt），得到了正确的回答，于是以“无法复现”为由关闭了工单。两周后，另一名客户提出了同样的投诉。工程师再次在同一个开发账号中进行回放，结果依然正确。团队开始归咎于没人做过的提示词更改。
请求中的模型标识符从未改变。响应字段中的字符串与请求字段中的字符串匹配。评估套件在六周内一直保持绿色。生产流量使用的模型权重与评估套件使用的模型权重是两套不同的集合，而且在该账号的整个生命周期中一直如此——直到过去这六周，它们变成了同一套权重，而团队注意到这一点仅仅是因为客户先发现了。
这就是当你把模型标识符视为权重的名称，而它实际上只是供应商可以自由修改的路由决策标签时会发生的情况。
标识符是路由标签，而非模型
一个高业务量的客户与他们的供应商协商了一项“首选模型”安排：该客户的流量会指向一个针对其关注的语料库训练过的租户范围内的微调变体，而该变体通过客户代码已经在调用的同一个公共模型标识符提供服务。客户不需要更新 SDK、网关配置或提示词模板。字符串 claude-sonnet-4-6（或 gpt-5.1，或任何其他标识符）持续出现在请求和响应的载荷中。微调在 API 边界是不可见的，这正是客户在签署合同时所要求的。
供应商的路由层对每个请求做出基于租户的决策。对于你的租户，标识符解析为存储在专用池中的特定权重集。对于其他所有人的租户，相同的标识符解析为基础模型。在这两种情况下，响应载荷都会回显请求的标识符，因为这就是 API 合约所保证的：模型字段告诉你请求的是哪个标识符，而不是哪个权重做出了回答。
大多数团队永远不会注意到这种差异，因为“为我们的领域微调过”和“带有系统提示词的基础模型”之间的差异平均而言足够小，以至于注册时的 A/B 测试就能证明该计划的合理性，随后便没人再进行重新验证。当以下三种情况之一发生时，这种差异就会变成问题。第一，供应商在季度中期的运营审查中发现专用容量成本不划算，将标识符重新指向了基础模型。第二，团队的评估账号由于位于没有租户范围路由的开发工作空间中，一直使用的是基础模型，从未见过微调效果。第三，生产流量向微调模型所针对的专业领域倾斜，以前被平均掉的差距在客户面前变得显而易见。
为什么评估套件一直保持绿色
该团队构建评估套件的方式和所有人一样：一个带有 API 密钥的开发账号、一套具有代表性的提示词数据集、一个评分标准以及一个每晚运行的 CI 任务。评估账号属于一个与生产环境隔离的工作空间，原因与其他所有密钥都存放在独立工作空间的原因相同。评估账号没有为专用容量付费。评估账号没有加入首选模型计划。自开发工作空间创建以来，评估账号一直运行在基础模型上，因为路由决策是绑定到租户的，而不是请求中的标识符。
评估套件的工作是证明“这个标识符会产生这些回答”。对于提供给评估账号的模型（即基础模型），它一直正确地履行着这项职责。当生产租户运行在微调模型上时，评估套件的证明并不描述生产环境。当生产租户被重新指向基础模型时，评估套件的证明突然描述了生产环境——但这种证明并没有变得更准确；只是生产环境退化到了与评估证明的准确度相匹配的程度。由于评估所测量的任何内容都没有改变，数值也就没有波动。
监控评估套件的团队看到一条平稳的绿线，得出模型稳定的结论。专业工作负载上的客户侧质量退化了微调模型原本提供的提升部分，这在特定领域的任务评分标准中很容易达到 10–15 分，但在任何平均了长尾普通流量的总指标中都是不可见的。
这种差异是如何隐藏了六周之久的
六周之所以成为时间线，是因为这种退化必须与所有其他可能导致模型输出本周比上周稍差的原因竞争。比如人们在没互相告知的情况下修改系统消息导致的提示词漂移；添加到注册表并改变模型规划的工具描述；丢弃了早期对话轮次的上游上下文窗口更改；显现出新提问模式的客户构成变化；或者是供应商侧的温度或采样器更改，这些更改表现为 system_fingerprint 的差异，但由于大家已经停止跟踪该字段而被忽视了。
在缺乏指明退化原因的信号时，团队的第一反应总是与他们在完全不理解的工作负载上遇到质量下降时一样：阅读提示词仓库的最新提交。没有最新提交。然后阅读公共模型标识符的模型发布说明。公共标识符没有发布说明，因为标识符没变。接着检查上游上下文检索器是否更改。没有。再检查客户的数据是否更改。也没有。团队现在已经排除了所有明显的嫌疑人，而真正的因——供应商侧的路由决策将相同的标识符解析为了不同的具体模型——并不在团队运行手册（runbook）的检查列表中，因为编写手册时假设了标识符就是权重的名称。
案件的突破口通常是某位能具体指出哪类问题以前能解决的客户。“你的助手以前知道在试用期内取消的订阅退款会在 5 个工作日内通过 ACH 处理，现在它却说没有这项政策。”这句话足够具体，可以检索出退化发生前的一些历史对话，并将其与当前在相同输入下的行为进行对比。这种差异是可复现的。团队终于可以写下一行事故总结：模型以前能回答这个问题，现在不能了。
要从那个总结推导到“供应商将我们的租户从微调模型重新指向了基础模型”，需要团队首先知道首选模型计划的存在。许多事故处理频道从未得出这个结论。他们止步于“模型变差了，我们会把这个加入评估集”，这完全掩盖了路由层面的问题。
弥合差距 这种差距存在于 eval 验证的标识符与生产环境接收到的权重之间。工作的重点在于使双方都具备可观测性，并为 eval 提供与生产环境流量相同的路由路径。
在生产租户上运行 eval，并使用生产路由路径。 最重大的改变是停止从开发账号运行 eval。eval 任务应该以与生产环境相同的租户身份进行身份验证，访问相同的网关端点，并携带与生产环境相同的路由相关标头。这听起来显而易见，直到你考虑到其影响：eval 现在正在消耗生产预算，在生产限流计数器中留下痕迹，并依赖生产凭据。大多数团队设立开发账号正是为了避免这些耦合。但代价是，除非 eval 经过与生产环境相同的路由决策，否则你无法拥有一个能验证生产环境所接收内容的 eval 测试集。
捕获提供商的解析记录，而不仅仅是响应字段。 响应载荷中的模型字段只是你请求的标识符。你真正想要的是提供商提供的具体权重。在 OpenAI 上，这就是 system_fingerprint 字段，它旨在标识“OpenAI 服务器用于生成补全的模型权重、基础设施和其他配置选项的当前组合”。指纹的唯一性不足以识别所有客户中特定租户的微调（fine-tune），但它们足够稳定，因此在其他所有条件保持不变的情况下，指纹的变化是服务配置发生变化的可靠信号。其他提供商以不同的名称公开类似的字段；有些甚至需要提交支持工单才能获取每个请求的解析日志。无论字段是什么，请将其存储在每个生产 span 中，存储在每个 eval span 中，并进行每日差异分析（diff）。
对比 eval 租户指纹与生产租户指纹，并针对“发散”和“收敛”发出告警。 针对“eval 指纹 == 生产指纹”设置常驻告警听起来有些反直觉，直到你意识到对于处于“首选模型计划”中的租户，这两个指纹理应不同。真正重要的告警是它们开始匹配的时刻，因为那是路由决策发生变化的时刻——要么是因为你的租户被重新指向了基础模型，要么是因为 eval 租户被提升到了一个没人告诉过你的计划中。反向告警（即指纹在原本匹配时发生发散）则是一个信号，表明之前统一的标识符刚刚开始针对你的某个环境进行不同的路由。
将路由决策纳入合同条款。 企业买家开始在 LLM 合同中写入的模型稳定性条款——通常是针对任何实质性影响输出质量的变化提前 30 天通知，并在通知期间保留对前一模型版本的访问权限——通常是围绕公共模型退役而制定的。这些条款需要扩展到涵盖租户范围内的路由变更。提供商比买家预期的更愿意做出这种承诺，因为提供商已经在跟踪哪些客户处于哪些路由决策中；这种承诺只是将提供商已经在做的决策透明化。如果没有合同约束，提供商的中期运营审查可能会在某个周二重新指向你的流量，然后在三周后的客户成功电话会议上才告诉你。
维护一个针对专业领域的回归测试集。 如果微调模型是在特定语料库上训练的，那么它与基础模型差异最大的情况，正是团队最需要微调模型生效的情况。这些案例属于回归测试集，应在每次发布和每次指纹变化时运行。在所有生产流量中平均分配的通用 eval 会将回归淹没在噪声中；而针对微调模型所关注领域量身定制的回归测试集，则会在路由切换当天出现数据飙升。从过去的事故和客户升级反馈中提取 20 到 50 个案例，就足以捕捉到那些显而易见的问题。
架构层面的认知 模型标识符是客户端发送的一个字符串，也是服务器回传的一个字符串。路由决策位于两者之间，归提供商所有。提供商可以随时出于符合合同的任何原因更改决策，而两端的字符串将保持匹配，但其下的权重却已发生漂移。
一个将标识符等同于模型的团队，实际上构建的是一个只能验证提供商当前为 eval 账号路由到什么的 eval 测试集。这很少是客户正在使用的模型，团队通过流失客户而不是通过 eval 失败来发现这种差异。解决办法不是在开发账号上运行更好的 eval。解决办法是将 eval 放在生产环境所在的同一路由路径上，捕获每个 span 上的提供商解析记录，并签署合同使路由决策成为一个通知界面，而不是内部的运营选择。
你的客户与之交互的模型，是提供商在产生响应的请求中决定为你的租户提供的模型。其他一切——标识符、SDK 版本、提示词——都只是该决策的一个标签。围绕决策构建可观测性，标签就会与那一周恰好呈现的样子保持一致。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
