北京
一个路由器可以为每条提示词挑出模型，却仍然交给你一份极不完整的评测。这是两件不同的事。在看到质量曲线之前，这两件事都得先看清楚。
AutoBench 新发布的 router 审计把这两件事拆得格外好查：它同时公开了决策记录和分数。作者报告称，在其头条对比中，没有任何商业配置能在质量与成本两项上同时击败某个静态模型。这是作者的结果，不是一次新的模型实测。
这里能做的检查更小、也可复现：读公开的决策账本，数一数哪些决策带有分数，再看一个号称自适应的策略是不是大部分时候都选了同一个模型。
缺分数需要自己的分母。在导出的azure_cost这一轮里，全部252条决策都写明了模型，但只有35条标记为已评分。它最常被选中的那个模型拿到了149条决策。而在orca_constrained_quality中，对应数字是 252 条决策里有245条已评分、252条都选了同一个头名模型。
第一轮暴露的是覆盖率问题，第二轮暴露的是路由问题。一个单一的质量百分比会把这两种区别一起盖住。好比只尝了前菜就写出餐厅评论，分数也许准确描述了前菜，但它需要一个标签。
对基准测试来说，每个质量数字旁边都该并排放三样东西：决策总数、已评分数、以及缺失单元格的解释。基于可用单元格算出的分数是一个条件结果，不该悄悄变成对整个工作负载的结论。
这不意味着每个不可用的单元格都是坏答案。服务方可能选了一个不在已存分数矩阵里的模型。把这类单元格一律当作失分，是另一种评测选择，而不是自动修复。
把账本打印在排行榜之前。用 Python 3.10 或更新版本运行一段标准库脚本，固定数据集版本、解析前先校验下载文件的摘要，就能得到下面这组输出：
- 导出的轮次：28，其中塌缩（单一模型占比≥90%）的有9
- orca_constrained_quality：已评分 245/252，头名模型被选 252/252
- azure_cost：已评分 35/252，头名模型被选 149/252
- nd_subset_k0：已评分 248/252，头名模型被选 252/252
- or_auto：已评分 245/252，头名模型被选 248/252
28 个导出轮次里有 9 个把至少 90% 的决策送给了同一个模型。阈值用整数运算，浮点边界不会改变分类结果。
这里有个容易踩的坑：导出的 28 个轮次并不是那篇博客里的 17 个头条设置，导出里还包含次级轮次和参考轮次。这个计数描述的是整个导出账本，并不修正也不反驳作者更窄的计数。
一个常量也可以是好策略。集中的策略并不自动等于没用。如果某个模型适合这份工作负载，一直选它可能是合理的；可靠性要求、合同约束和可用性也会收窄可用的模型池。
集中度改变的是比较方式。如果一个策略几乎总选模型 A，那就拿它和“永远选 A”比，再问剩下的决策贡献了什么。只证明它打败随机选择，并不能分离出“针对提示词做适配”的价值。
在解读质量差异之前，还该把路由器放在同一批已评分提示词集合上比较。否则一个在难题上评测的路由器，和另一个在更简单子集上评测的路由器，可能互换位置，而两者都没有变好。让缺失行保持可见，并把完整工作负载与那个对齐子集分开报告。
这项检查能确立什么、不能确立什么，需要说清：这是对已公开决策的离线审计，不是又一轮路由器或模型调用。没有复现 AutoBench 的评判器、自助过程和成本排名。来源说明其路由器调用早于本次发布，账本不构成对当前厂商行为的保证。
有用的习惯在这些限制下依然成立：在庆祝质量分数之前，先打印覆盖率和集中度。一旦知道一张路由图究竟描述了哪些决策，它才会变得有意思得多。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
