模型对比排名

想给项目选模型时，你大概会先搜「模型对比排名」，然后打开一堆榜单，发现同一家模型在不同页面名次不一样，越看越糊涂。问题不在你，在于榜单口径、题目集和更新节奏本来就不同。这篇不给结论，给一套取数与解读的顺序：先明确要比什么，再去站内对应页面拿当期数字，最后用几个固定动作把噪声排掉。

想给项目选模型时，你大概会先搜「模型对比排名」，然后打开一堆榜单，发现同一家模型在不同页面名次不一样，越看越糊涂。问题不在你，在于榜单口径、题目集和更新节奏本来就不同。这篇不给结论，只给一套取数与解读的顺序：先明确要比什么，再去站内对应页面拿当期数字，最后用几个固定动作把噪声排掉。

先把预期放正：排名是筛子，不是判决书。它的用处是帮你从一长串候选里砍掉明显不合适的，把精力留给真正跑得动的少数几个。凡是把某张榜的名次直接当成采购结论的做法，换一个业务场景大概率翻车。

先想清楚你到底要比什么

「哪个模型强」这句话没法比，因为它没说是哪方面强、在什么约束下强。先把它拆成四个可比维度：单次回答质量、长文与多轮稳定性、单位成本下的产出、可接入性与限流。四个维度各自对应不同的站内页面，混在一起看只会互相干扰。

拆完之后，写一句自己的判定句，比如「在给定的月度预算内，把某类任务做到可交付」。判定句要包含约束条件和交付标准，不然后面所有对比都会退化成凭感觉吵架。判定句一旦定下，哪些指标重要、哪些可以忽略，基本就自动清楚了。

站内几类对比入口，各拿什么数

站内的对比资源大致分三类，用途差别很大。测评类入口适合看能力分布和题目维度，能告诉你谁在某类题上更稳，但它不是采购依据，因为题目集和你的业务分布往往对不上。价格与用量类入口适合看当期单价、订阅额度折算和真实用量结构，这类数字变得快，一律按页面当期为准，别记在脑子里。

第三类是目录与规格类入口，适合做减法。上下文长度、是否支持结构化输出、有没有你需要的模态，这些硬性条件先筛一遍，可能一半候选就没了。先做减法再做横评，比一上来就把十几个模型拉进同一张表要省力得多。

• 一次只开三类页面各一个，页面开太多会互相污染判断
• 测评页看完先记下「它测的是什么任务」，别只记名次
• 价格与用量数据一律当场截图或记录取数时间，方便日后复盘
• 规格页用来淘汰，不用来排名，它的价值在排除而不在排序

同一家模型名次不一样，通常是这几件事

同名次冲突几乎都出在三个地方：题目集不同、评分方式不同、版本快照不同。偏学术推理、偏代码、偏中文长文的题目集，各自捧出来的赢家本来就不一样；自动判分、模型互评、人工投票这三种方式的误差方向也不一致，同一个回答在三种口径下可能得到相反的相对位置。

更容易被忽略的是版本与快照。页面上写的是哪个时间点的权重、有没有开推理档、是不是默认系统提示词，这些都决定它和另一张榜能不能直接比。两张榜的取数时间差得远，就别硬放在一起排名次，当成两个时代的两份材料看更合适。

看数字的三条纪律

第一条是看区间不看单点。把并列几名的差距当噪声处理，只对明显分层做结论，比如「第一梯队」和「明显掉队」这种粒度。盯着小数点后几位去排名次，多半是在给随机波动赋予意义。具体到当期是几分、差多少，到 /rankings 核对当时的数字。

第二条是看更新时间。旧榜不是错，是不该拿来描述今天，尤其在这类更新密集的领域。第三条是看对比基线：领先多少永远是相对谁而言，换一个基线，结论可能直接翻转。指标本身是什么意思、怎么算的，拿不准就去术语类页面把定义查清，别靠猜。

1. 先看更新时间页面上标的取数或更新时点距今太远，就只当历史参考，不当当期结论用。
2. 再看指标定义点进术语说明，确认这个分数是自动判分还是人工投票，误差方向不同，解读方式也不同。
3. 最后看对比基线确认它领先或落后的是谁，换一组对照模型后这个差距还算不算大。

成本侧的对比别只比单价

成本对比最常见的错误是拿一个单价乘总量。输入输出往往不同价，缓存命中、图片、语音这些按量项要分开算，混着算必然错。订阅制还要按额度折算成等效用量，否则和按量计价的方案根本没法对齐。折算公式各个服务商口径不同，别硬套，按站内页面给的说明来。

还有一块隐性成本经常被漏掉：限流、并发上限和失败重试。一个单价更低的方案，如果在你的峰值时段频繁被限，重试带来的额外请求和人工兜底时间可能把省下的钱全吃掉。这部分比单价更能决定最终花多少。

• 把输入、输出、缓存、多模态按量项分行列出，逐行对比
• 订阅制先折算成等效用量，再和按量方案对齐
• 把峰值时段的限流与并发写进对比表，不只比理想状态
• 用同一份用量假设跑两三个候选，避免各算各的
• 算完和官方价目页对一遍，确认口径和当期数字一致

按场景抄近路的对比顺序

不同场景里，几个维度的权重差得很远，所以可以走不同的比较顺序。顺序对了，同样几份材料能省一半时间；顺序错了，容易在最不重要的维度上纠结半天。下面这张表按常见场景给出先后顺序，具体强弱仍要去对应目录页看当期。

举两个通用例子。一家 5 人小团队做内部知识库，先卡上下文和检索方案，生成的文风差异其实可以后置；一家做批量数据抽取的团队，先算清单价和吞吐，能力差距只要够到可交付线就行。注意这两个顺序都有不适用的时候：如果任务对准确性要求极高、错一条代价很大，那能力的排序要提前，成本反而次要。

把对比结果留成一份可复用的记录

横评这件事最大的浪费是做完就散。隔一个月模型换代，同样的功课重做一遍，还得重新回忆当初为什么淘汰某个候选。解决办法很朴素：每次横评记四样东西——候选名单、判定句、用到的页面与取数时间、被淘汰的理由。记完就存着，后续只做增量。

换代时不用整轮重来，只重跑和判定句相关的那部分。比如判定句是「在给定预算内把某类任务做到可交付」，那只需重测交付质量和成本两项，规格类条件没变就不用再筛。另外，把「什么情况下这个结论不成立」写在同一份记录里，换场景时先看这句，能避免直接套用旧结论。

• 候选名单：进了哪几个，为什么进
• 判定句：约束条件和交付标准分别是什么
• 取数来源与时间：用了哪些站内页面、当时是什么数字
• 淘汰理由：被砍掉的候选具体卡在哪一条