模型漂移监控的陷阱：别把噪声当成退化

35个测试任务的评测集，如果一个模型少对了一道题，得分就会掉 2.86 分。这个数字在图表上看起来像是个“性能下滑”，但实际上它只是统计学上的随机波动。

我一直在跑一个自动化的 LLM 漂移追踪系统，每天对 16 个模型进行 35 项固定任务的探测。一旦某个模型的得分低于前一次运行，系统会自动在 GitHub 开 Issue 并帮我写好草稿。结果上周这个系统极其“勤奋”，连续四天向我预警了四次性能退化：

7月23日 Gemini 3.5 Flash -11.4 pts
7月24日 Gemini 3.1 Pro -2.9 pts
7月21日 Grok 4.3 -5.7 pts
7月22日 Llama 3.3 70B -2.9 pts

三家厂商，四次退化，如果直接发帖，这简直是最好的素材。但实测结果证明：这四次预警全部是误报。

误报原因一：API 限制被误认为“变笨”

其中两次 Google 模型的预警根本不是模型能力问题。我在监控面板上给每个得分都配了一个“可靠性（Reliability）”指标，即请求成功率。回头看日志才发现：

gemini-3.5-flash 7月22日 acc 1.000 reliability 1.000
7月23日 acc 0.886 reliability 0.914 
# 错误详情：429: Rate limit reached for model `llama-3.3-70b-versatile`
# service tier `on_demand` ... requests per minute (RPM): Limit 30, Used 30

35 次调用里有 34 次被限流了。因为系统把 429 错误直接计为 0 分，导致分值暴跌。这是漂移监控中最具欺骗性的地方——接口挂了或被限流，在数据曲线上看起来和模型被偷偷“阉割”一模一样。

误报原因二：样本量太小导致的统计噪声

另外两次预警（Grok 和 Llama）更有意思，因为它们的可靠性是 1.000，请求全部成功，但分数确实掉了：

• Grok-4.3： 0.800 -> 0.743 (-5.7 pts)
• Llama-3.3-70B： 0.800 -> 0.771 (-2.9 pts)

这里有个简单的数学问题：我的测试集只有 35 道题，每道题权重是 2.86 分。-2.9 分意味着模型刚好少对了一道题，-5.7 分意味着少对了两道。

当测试集规模只有 35 个任务时，它无法分辨“模型能力下降”和“随机抽样波动”。把一道题的答案变化定义为模型退化，其实是在把噪声当成信号。

如何构建一个不自嗨的监控工作流

很多人会建议把预警阈值调高（比如掉 10 分才报警），但我认为这不对。因为真正的模型漂移在初期可能非常细微，如果只盯着灾难性下跌，就失去了监控的意义。

正确的实战做法应该是：敏感度负责发现，人工审计负责确认。

我的自动化工作流现在是这样配置的：
1. 自动探测： 保持高敏感度，任何波动都记录。
2. 拦截层： 预警不直接发布，而是生成一个待审草稿，并在文首强制标注检查项：

> 自动日志：检测到运行回测退化。在发布前，请务必核对运行日志（Run Log）和可靠性指标（Reliability）——限流或供应商宕机会导致虚假退化。

3. 人工核验： 检查是否为 API 错误 → 检查波动是否在单题权重范围内 → 确认是否为真实漂移。

核心反思：关注“预警生存率”

在做大模型实战评测时，大家习惯盯着准确率（Accuracy），但我想提出一个更关键的指标：预警生存率（Alert Survival Rate），即经过人工审计后，依然被认定为真实退化的预警占比。

我上周的生存率是 0%。

这个数字虽然难看，但非常有价值。它直接告诉我两件事：第一，我的测试集规模太小，无法过滤单题噪声；第二，如果图表上不把可靠性指标和准确率放在一起，那这个图表就是在撒谎。

构建一个漂移追踪器的难点不在于如何捕捉波动，而在于如何不被波动欺骗。

https://egnaro9.github.io/model-drift