影子测试100%一致率背后：模型实际正确率仅75%

在昂贵模型后面换上一个便宜的模型，最直接的验证方式就是 shadow traffic：把同一个请求同时发到两边，比较返回结果，数它们有多少次一致。高度一致，就上线。

我在构建 SuperRouter 时对 60 个线上调用做了测量。路由模型和参考模型 100% 达成一致，但正确率只有 75%。

两个数字都是真实的。它们之间的差距就是整个问题的核心。

一致不等于正确

一致问的是两个模型是否输出了相同的答案，从不问答案本身对不对。而且同一时代、用重叠数据训练的模型，失败方向一致的概率远高于独立失败的概率，所以一致率最高的时候恰恰是你最没有保障的时候。

一次报告 100% 的 shadow run 可能对应两种截然不同的场景：一个是真的同样优秀的便宜模型，另一个是和昂贵模型在完全相同的地方犯错。没有一致率数字能区分这两种情况。

应该对照标准答案来评分，按失败模式分类，绝对不要对照另一个模型来评分。

标准答案是生成的，而非人工标注的。缺陷是故意植入的，这样在任何模型看到测试用例之前，正确答案就已经确定了。

植入的缺陷必须产生像素级的变化。在 18 个故障类别中，有一个返回 success 但屏幕上没有任何改变。现在每个 fixture 都要用同一屏幕的健康帧做门控对比，因为一个模型根本不可能捕捉到的故障正在悄悄抬高所有分数。

考试的两个部分都必须有难度。忠实用例都是源的逐字副本，所以误报率在七个模型上都维持在 0-3%，这个维度的测量完全形同虚设。

来自不同版本集合的 run 永远不能相互比较。每次 run 都对其所在的精确用例做指纹锁定。没有这个锁定，表格就会把一个在 90 个简单用例上测得的模型排在另一个在 592 个用例上测得的模型之上。

让我惊讶的部分

我以为公开发布的排行榜可以替代对自己产品的测量。在两个产品上，当模型做评判时，排名顺序大部分可以迁移（0.83），但每个模型在绝对分数上都下降了中位数 22 分。当任务是指向正确的 control 而非评判时，顺序几乎无法迁移（0.49）。

所以排行榜告诉你的是总体上谁表现好，而不是谁在你的场景下表现好，而第二个问题才是决定你账单的唯一因素。

如果你用路由来省钱，一致率会是你最先想到的指标，也是最容易误导你的那个。应该用你自己构建的东西来衡量正确性，按产品实际可能出现故障的方式来分类。否则你只是在衡量两个模型有多相似，然后把它称为质量。

SuperRouter is open source, Apache-2.0, with no runtime dependencies: https://github.com/M19K/superrouter