供应商移除的 Logprobs 字段如何静默地破坏了你的置信度路由

在事故复盘报告中，最昂贵的代码行反而是没人写出的那一行：一个字段缺失的 200 OK。原本应该将难题上报（Escalate）给更强模型的路由，在整整六周的时间里上报的流量为零。成本看板在欢庆，质量看板却在下滑——但仅限于那组被现有评估集低估的难题切片。直到客户投诉系统以前能正确处理的特定问题时，一切看起来都还像是场胜利。

起因是协议栈上层的一个响应结构变化。供应商的中级方案取消了逐 Token 的 logprobs，这在发行说明中被称作“特定层级的特性对等调整”。客户端收到的仍是有效的 JSON，HTTP 状态码依然是 200，响应中的模型标识符与请求中的模型标识符也完全匹配。唯一的变化是，路由用来做上报决策的字段消失了，而一年前在一次事故中添加的防御性默认设置，悄然变成了每个请求的生产环境默认行为。

变成生产环境默认设置的防御性回退

置信度路由（Confidence routing）是现代 LLM 技术栈中较好的成本控制模式之一。你先询问一个便宜的模型，观察该模型对其答案的置信度。如果置信度低于阈值，你就将问题上报给更强大、更昂贵的模型。操作得当的话，你可以用极低的成本获得强模型的大部分质量。置信度阈值级联路由被广泛引用为在保留大部分回答质量的同时，能削减 45% 到 85% 的推理成本。

置信度信号通常来自 logprobs。模型生成的每个 Token 都带有一个对数概率，指示模型对该 Token 的确定程度。在整个答案中聚合这些数值会得到一个单一数字，它与答案是否正确高度相关。具体的聚合方式因团队而异——可能是答案跨度内的最小 logprob、平均 logprob、困惑度（perplexity），或者是特定答案片段的约束和——但协议的结构是一样的：路由读取响应中的一个字段，应用一个阈值，然后要么返回便宜模型的答案，要么重新询问昂贵模型。

这就是故障模式隐藏的地方。路由代码必须处理字段缺失的情况。两个自然的选择是将缺失视为“不确定，上报”或“确定，接受”。在一年前的一次事故中，供应商曾出现过短暂故障，导致部分响应缺失 logprobs。当时团队的路由将缺失视为低置信度，并将每个请求都上报到了昂贵层级，导致事故期间的支出翻了四倍。修复方案是一个防御性回退：如果 logprobs 缺失，则将答案视为高置信度并跳过上报。这种逻辑在当时背景下是合理的——供应商正处于故障中，上报成本高昂，而便宜模型的答案在故障期间通常也足够用了。没人写下这样一个假设：该回退仅适用于部分故障情况，因为在当时，那是 logprobs 唯一可能缺失的情况。

一年后，供应商修订了层级定义。Logprobs 现在是高级别服务的特性，而非中级别服务的特性。客户端继续调用中级别服务，响应结构发生了变化。旨在处理瞬时故障模式的防御性回退，变成了路由决策的稳态行为。每个答案都被视为高置信度，上报率归零。强模型不再接收难题，中级模型开始独立回答这些问题，质量自然可想而知。

这种错误的普遍形态值得明确命名：当上游协议发生变化时，为一种故障模式编写的防御性默认设置，静默地变成了另一项无关决策的生产行为。路由从未被要求去思考一个“字段被刻意移除”的世界。回退是为“字段因调用失败而偶尔缺失”编写的，而不是“字段因供应商决定该层级不包含它而永久缺失”。缺失的语义已经反转，而代码路径无法感知。

供应商层级：由财务团队谈判的动态协议

更深刻的教训关于协议边界究竟存在于何处。大多数团队将 API 表面（请求结构、响应结构、错误词汇）视为协议。他们针对它编写代码，运行集成测试，并信任它只有在发生可见变化（如大版本升级或公开迁移指南）时才会改变。他们忽略的是，你的客户端收到的响应结构是两个因素的函数，而非一个：供应商的 API 定义，以及你账号所属的服务层级。

服务层级由财务团队谈判，而 API 定义由工程团队消费。这两个边界之间没有共享的记录系统。财务看到的是季度发票和谈论每 Token 费率、吞吐量上限以及用市场语言描述的特性包含项的合同补充协议。工程看到的是 JSON Schema 和状态码。当供应商修订层级时（在这里增加一个特性，在那里删除一个），合同补充协议会落入财务的收件箱。JSON Schema 对任何人都没有改变，因为被移除的字段现在被描述为“可选且取决于层级”，而不是“保证提供”。

这就是定价层级重组如何变成静默的客户端损坏的。供应商的发行说明用专门针对采购读者的语言标记了这一变化：“特定层级的特性对等调整”、“将高级响应字段整合到顶级方案下”、“层级与更广泛产品线对齐”。工程团队如果读了这些说明，会将其视为市场文案；财务团队如果读了，会将其视为成本优化机会——甚至可能是协商降级的理由。双方都没有将这种变化与系统构建以来路由一直在消费的响应字段联系起来。

缩小这一差距的明确模式是将供应商的层级政策视为工程团队拥有的协议的一部分。你的代码为任何决策（路由、重试、成本核算、审计）所消费的每个响应字段，都需要一个清单条目，标明该字段所依赖的层级保证。当财务评估层级变动时，该清单就成了指明哪些工程系统行为依赖于该层级的凭证，在每个负责团队确认之前，变动不能生效。这听起来很繁琐，确实如此，但这是处理一个由对方控制并在你承诺的期限内不断修订的协议的唯一诚实方式。

加载中…