测试无法察觉却破坏了一切的模型升级

这次升级看起来就像是白捡的便宜。供应商发布了一个更新的模型，它在每一项公开基准测试中的得分都更高，每个 token 的成本更低，且生成 token 的速度更快。你在一个配置文件里修改了模型字符串，运行了评估套件，看着 340 个测试用例全部变绿，然后在周二下午发布上线。到了周四，客服工单不断增加，却没人能指出到底是哪一个测试失败了。

这是应用层 LLM 开发中最令人困惑的失效模式，因为它违反了其他所有软件与你达成的契约：如果测试通过，行为就保持一致。在这里，该契约失效了。模型升级不是对一个你可控接口的库进行版本更新。它是一次对概率函数的无声、大规模更替，而你的评估套件只检查了你想到要写下来的那一小部分行为。

真正带来伤害的退化往往存在于你从未编码定义过的行为中——语气、冗余度、格式习惯，以及模型如何处理请求中模糊的中间地带。这些恰恰是你的用户所依赖的东西，也恰恰是 pass/fail 断言无法察觉的东西。

为什么“基准测试得分提升”是最危险的绿色信号

基准测试衡量的是综合能力。你的产品依赖的是分布中特定点上的特定行为切片，而这两者之间的关联非常微弱。一个模型可能在研究生级别的数学上表现更好，但同时变得更爱唠叨、更容易推诿，或者更倾向于用 Markdown 围栏包裹 JSON 载荷——而在此期间，基准测试的分数会一直上升。

令人不安的事实是，输出分布 就是 LLM 功能的 API 表面。你消费的不是权重；你消费的是权重发射出的 token。当供应商更改权重、分词器（tokenizer）或推理栈优化时，这种分布会发生偏移，且偏移的维度是任何排行榜都无法追踪的。从业者调查的结果往往大同小异：绝大多数生产环境中的 LLM 功能在模型更改后的头几个月内会出现可衡量的行为偏移，而从偏移开始到收到第一个用户投诉之间的时间差通常在两周或更长。

两周是一个关键数字。这意味着反馈回路（告诉你某些东西坏了）的速度比导致故障的发布要慢。你的断言显示正常，是因为它们问错了问题，而正确的问题一直在生产环境中被错误地回答着——且表现糟糕。

那些能通过所有断言的退化

命名那些悄悄潜入的具体退化类型会有所帮助，因为每一种类型都需要不同的检测策略。

• 分布偏移 (Distributional drift)：模型平均来看仍然正确，但其回答的“形态”发生了变化。回复变长了 30%，或者中等置信度的措辞从“这是”变成了“这可能是”。没有单个输出是错误的，因此不会触发断言，但整体体验下降了。
• 风格偏移 (Stylistic drift)：语气、正式程度和格式习惯发生了变化。旧模型返回精简的列表项；新模型写段落。如果你的 UI 是针对旧形态调整的，那么现在的布局看起来就坏了，尽管内容本身没问题。
• 拒绝边界偏移 (Refusal-boundary drift)：新模型的安全校准发生了移动。它现在拒绝处理旧模型可以处理的请求，或者在以前能干脆利落回答的问题上变得含糊其辞。除非你针对那个精确的提示词 (prompt) 有评估用例，否则你只能从愤怒的用户那里得知这一消息。
• 格式严格度偏移 (Format-strictness drift)：JSON 模式变得更严格或更宽松了。原本能可靠省略代码围栏的模型，现在有一半的时间会带上它，而那些假设 JSON 干净的下游解析器开始在以前从未卡过的输入上报错。
• 长尾边缘用例 (Long-tail edge cases)：那些你从未编写过测试的行为，因为你从未想象过它们。生产环境的流量具有任何精心挑选的数据集都无法捕捉的长尾效应，而新模型由于先验知识的不同，往往最先在这些长尾部分表现出差异。

请注意这些情况的共同点：在单元测试的理解范围内，它们都不是“错误答案”。它们是行为的偏移，从未出现在你的显式契约中，因为在它们发生变动之前，你根本不知道自己依赖于它们。你的评估套件是你凭想象力预见到的故障快照。从定义上讲，危险的退化往往是你没有预见到的那些。

加载中…