针对你已不再提供服务的模型版本的 Bug 报告

一个客户支持工单在周二送达。客户附上了一张你的产品在 6 周前生成的输出截图。他们声称该输出是错误的、不安全的，或者根本不符合预期，并要求修复。你的支持工程师将提示词粘贴回同一个 API 终端，得到了一个清晰、合理的回答。就系统目前的状态而言，这个 Bug 并不存在。

Bug 是存在的，但产生这张截图的模型已经不在了。自从客户提交工单以来，你的 v1-chat 终端背后的权重已经更换了两次——一次是为了提升质量，一次是为了优化成本——而原始的检查点（checkpoint）已无法访问。客户的“这东西坏了”现在成了一个针对变动目标的无法证伪的断言，支持团队既无法确认它，也无法关闭它。

这不是一个古怪的边缘案例。这是将模型版本控制视为内部 MLOps 问题，而非客户可见的产品合约的必然结果。终端 URL 是稳定的，但它背后的产物（artifact）却不是。在你的支持流程、保留策略和客户合约承认这一差距之前，每一个针对已轮换检查点的 Bug 报告都会掉进同一个分类真空区。

终端不等于模型

你的团队围绕终端建立的心理模型是错误的，而且这种错误方式直到现在都对你们行之有效。你将路由命名为 v1-chat，并在变更日志中写道：“v1 合约是指架构（schema），而不是模型。”这句话在技术上是站得住脚的——请求格式、响应格式、认证头、速率限制，这些都没有改变。另一方面，模型在同一个 URL 后不断升级，因为这就是团队选择解释“v1”的方式。

客户对“v1”的理解则不同。对他们来说，终端是一个在特定日期产生特定输出的黑盒，门上的名字暗示着无论盒子里是什么，它的行为都会保持一致。前沿提供商已经吸取了惨痛的教训，现在同时提供固定快照 ID（pinned snapshot IDs）和浮动别名（floating aliases）——比如 Claude 的 claude-sonnet-4-5-20250929 对比 claude-sonnet-4-5，以及 OpenAI 带日期后缀的名称对比单纯的系列名称。固定快照是一种承诺，即在该 ID 的生命周期内，其背后的权重和配置不会改变。浮动别名则是一种为了方便而明确放弃该承诺的做法。

如果你只提供浮动别名，那么你交付的就是一个实质内容可变的合约。即使客户想固定版本也做不到。你出于工程原因轮换检查点（更廉价、更安全、更优质的权重）这一事实，并不能改变客户签约的初衷，即他们在试用期间看到的行为。终端名称和所提供的产物需要是两个不同的概念，当出现问题时，客户需要能够明确指出后者。

不存在的分类路径

一旦产物是可变的，整个支持流程就需要吸收这一点。大多数流程并没有做到。默认的支持工程师手册假设系统是确定的、可重现的：获取 Bug 报告中的输入，在当前系统中重新运行，观察 Bug 是否仍然存在，如果是则升级处理，如果不是则关闭。当“当前系统”不再是提交 Bug 时的那个系统时，这个手册就悄然失效了。

失败模式是这样的：客户的截图是基于检查点 A 生成的。支持工程师在检查点 C（即目前终端背后的版本）上重新运行。输出结果不同了——有时更好，有时只是以一种不再表现出原始问题的方式变得不同。工程师以“无法重现”为由关闭了工单。客户要么带着更多他们无法重新生成的检查点 A 行为截图重新开启工单，要么悄然对产品失去信心。这两种结果都不是真正的修复。

流程中缺失的是针对已退役产物提交的 Bug 的分类路径。它需要三样当前工单流水线几乎肯定不具备的东西：在工单本身中记录产生原始输出的模型版本；一种将无法重现的 Bug 路由到负责退役该检查点的团队，而不是在支持阶段就终结它的方法；以及一个已经制定并记录在案的政策决策——即当 Bug 确实存在但产物已不存在时，公司该如何告知客户。“我们更换了模型，无法重现你遇到的问题”是一个非常诚实的回答。问题在于从未有人公开这样说过，因此支持工程师只能临场发挥，而客户听到的是敷衍。

客户的评估曾是采购决策依据

这一部分将支持上的不便转化为了合约问题。在试用期间，客户针对他们自己的评估集（eval set）运行了你的终端——这是他们的合规团队批准的，也是采购委员会在签署合同时参考的。那次评估的数据现在就躺在演示文稿、备忘录、安全问卷回复或内部立项文件中。这些数据是针对检查点 A 生成的。

当你默默地轮换到检查点 C 时，你就使采购决策的经验依据失效了。客户可能没有注意到，因为轮换是悄无声息的。但他们本该注意到，因为那些数据不再成立。今天重新运行同样的评估，得分将会不同——也许更好，也许更糟，也许平均分更高，但在那些对促成交易的关键利益相关者而言至关重要的特定用例上表现更差。无论哪种情况，当初证明购买你的产品是合理的那份文件，都不再描述他们现在拥有的产品。

法律层面的麻烦通常发生在续约或第一次审计时，当时客户的合规团队调出原始评估报告，并要求 AI 团队更新数据。更新后的数据显示了不同的结果。现在必须有人以书面形式解释，为什么公司付费购买的产品与当初评估时的产品表现不一。如果你告知了他们并且他们表示同意，“供应商升级了模型”这个答案是可以接受的。但如果你没有告知，那么“我们将模型视为终端背后的实现细节”这句话对于受监管的买家来说，绝不会像对你的平台团队那样具有安慰作用。

加载中…