闭源模型排行榜

做选型时最常见的卡点：榜单看了七八个，越看越乱，A 榜第一和 B 榜第一不是同一个模型，同事还各有各的心头好。这篇不讲谁第一，只讲怎么把榜单变成你自己能用的排序——先明确任务类型和权重，再挑可信的榜，最后用一批自有样本压一遍。走完这三步，你得到的是「你这个场景下的闭源模型排行榜」，而不是别人榜单上的名次。

做选型的时候，最常见的卡点不是模型不够用，而是榜单看了七八个，越看越乱。A 榜排第一和 B 榜排第一根本不是同一个模型，隔壁同事还各有各的心头好，谁也说服不了谁。问题不在于榜单造假，而在于大多数榜单回答的是「谁更聪明」，你要回答的是「谁在我这个任务上更合适」。这是两个问题。

这篇不评谁第一，只讲怎么把别人的榜单转成你自己能用的排序。流程就三步：先明确任务类型和各项权重，再挑可信的榜取对应分项，最后用一批自有样本压一遍。走完这三步，你手上拿到的是一份属于你这个场景的闭源模型排行榜，而不是别人表格里的名次。下面按这个顺序拆开讲。

闭源模型排行榜到底在排什么

打开任何一个榜之前，先分清它属于哪一类。三类榜的排序逻辑完全不同，混着看必然乱。第一类是通用能力综合榜，把一堆任务混成总分；第二类是单任务专项榜，只比代码、数学或长文；第三类是众测体感榜，靠真人盲评打分。你要选的东西决定了该看哪一类，而不是哪类分高看哪类。

综合榜

多个任务加权成一个总分，适合快速筛出候选池，不适合直接定选型结果

专项榜

只比一类能力，分数更贴近真实任务表现，但覆盖范围窄

众测体感榜

真人盲评，能反映语气、可读性这类主观项，样本量和人群构成影响很大

还有个容易被忽略的点：闭源模型的分数基本来自厂商自报或第三方抽样，你能拿到的线上版本不一定是打榜时的那个快照。版本更新不公告、悄悄换后端是常事。所以榜单上的名次只代表「某一时刻的那一版」，不代表你今天调到的就是同一版。

更实在的一句话是：榜上排的是「模型」，你实际用的是「模型 + 渠道 + 系统提示 + 限流」。中间任何一层变化都会改变体感，同一模型换个渠道，回答风格和延迟都可能不一样。选型时把「模型」当成一个变量而不是一个常量，后面很多困惑自然就有解释了。

挑一份可信的榜：看五件事

这五条里，防污染和验证方式最关键。老题目一旦被训练数据吸收，分数就会虚高，而且虚高得毫无规律，有的模型涨得多有的涨得少，这时候整张表的相对关系已经不可信了。单次跑分同理，模型在发布当天和上线两周后的表现差异不算小。

• 优先选题目公开、评分脚本可复现的榜，看不懂规则的不算参考
• 优先选有众测或多时段交叉验证的榜，单点数据只当线索
• 看更新口径：模型换代快，半年以上的排序参考价值明显下降
• 看是否区分推理型与通用型，混排容易得出错误结论
• 窄任务场景直接跳过综合榜，去找同类任务的专项榜更省事

把你的任务拆成权重，再让榜单排序

综合榜的总分是别人定的权重，不是你的。正确做法是先把自己的任务列出来，给每项打分权重，再只取榜单里对应的分项来对照。总分只能用来做第一轮粗筛，决定谁进候选池，不能用来定最终选择。

1. 列任务清单把真实业务拆成具体任务，比如长文摘要、结构化抽取、代码补全、多轮客服。粒度别太粗，写到「能对应到榜单某个分项」这个程度。
2. 给权重打分按调用量和业务重要性两项一起给权重，高频但简单的任务权重可以低一些，低频但出错代价大的任务权重给高。
3. 只取分项打开榜单只找你列出的那几类分项，其他分数直接忽略。总分当作候选池筛选的参考即可。
4. 算加权得分把每个候选模型在各分项上的表现乘以对应权重再求和，产出一张横向对照表，排序自然就出来了。
5. 标注不确定项对没有对应分项的任务，在表里标成待实测，别用相近分项硬顶，那是自欺欺人。

主观任务和客观任务要分开处理。文案、语气、客服话术这类偏主观的，权重应该压给众测体感榜，因为自动评分很难反映「读起来顺不顺」。抽取、计算、格式合规这类偏客观的，权重压给专项榜，因为对错能验证，人的体感反而不可靠。

如果你需要参考各家官方 API 的模型资料与计费口径来搭这张对照表，可以到 /official-api 核对当时的数字，那里是按厂商归档的资料页，别凭印象填。

分数之外：价格、限流与合规要一起看

能力分排完之后，还有三道闸门能直接毙掉候选：价格口径、工程限制、合规要求。这三项任何一项不过关，前面的能力排序都白做。所以顺序上建议把这三项放在小样本实测之前，先过滤再实测，省时间。

把候选模型的单价摊到同一张表里，注意口径要统一：有的按输入输出分开计费，有的把缓存单独算，有的按字符收费。口径不统一就比价格，结论一定是错的。换算成月成本时还要把失败重试和长上下文带来的额外消耗算进去，实际用量往往比估算高。

合规这条最容易被当成后置事项。但数据不能出内网的场景，闭源 API 这条路本身就不成立，不管分数多高都得上私有化方案。所以这一步不是审批，而是前置过滤，越早做越省钱。

用一批自有样本压一遍，出你自己的榜

榜单和权重都只是预筛，真正决定选型的是你自己的小规模实测。这一步不需要大规模，但样本必须真实。抽一批你线上真实业务样本，覆盖典型场景和边界场景，不要只用顺手的例子，顺手的例子测不出差异。

• 样本量控制在能半天跑完的规模，覆盖典型与边界两类场景
• 同一套提示词、同一组参数跑全部候选模型，参数改动要记录
• 评测维度提前写死，别看到结果再改评分标准
• 主观项至少两人交叉评分，且用盲评，不告诉评分人哪个模型出的
• 逐条记录失败样本的失败方式，是答错、漏答、格式不听话还是超时

失败方式的记录比平均分有用得多。一个模型平均分高但偶尔把格式写崩，在结构化抽取任务上就是不可用的；另一个模型平均分低一点但输出始终稳定，反而更适合上生产。这类差异只有逐条看失败样本才能发现。

评测跑完后，把结果和前面的加权分表合并成一张最终对照表，同时保留原始样本和评分记录。这张表就是你的私有排行榜，下次换模型或版本更新时，拿它做回归对比就行。

渠道和快照会让同一模型表现不一样

同一个闭源模型经过不同中转渠道，延迟、限额甚至可用参数都可能有差异。有时候不是你选的模型变差了，而是渠道换了后端或者限流变严了。遇到回答质量突然波动，排查顺序应该是先查渠道和版本，再怀疑模型本身。

1. 量延迟基线用固定请求跑一批，记录首字延迟和整体耗时。可以到 /tools/speed-test 做基线，方便多时段对比。
2. 固定样本回归拿前面那批自有样本重跑一遍，和上次结果逐条比对，看是整体变差还是个别变差。
3. 查渠道信号到 /rankings 和 /sites 交叉看看渠道侧的可信度信号，有没有异常记录或状态变化。
4. 确认快照如果渠道侧正常但质量下滑，优先怀疑版本快照变了，做一次小样本对比确认。

换模型或者换渠道之前，建议都做一次小样本回归，确认新版本在你任务上不掉线再切。回归的样本集就用前面那份，别每次新写，否则历史结果没法比。

什么情况下这份排行不适用

前面这套方法有明确的边界，越界以后结论会失真。下面几种情况要么换一套判断标准，要么干脆放弃用榜单做决策，直接靠自己标注数据。

最后一条尤其常见。如果预算有限，正确的顺序是先按成本筛出可用池，再在池内按能力排序。反过来做，你会在测完一圈之后才发现排第一的那个根本用不起，前面的实测时间全浪费。

把榜单变成一份会过期的清单

模型换代快，今天出的排序过几个月就不能用了。所以最终产出的不该是一张静态排名，而是一份带触发条件的候选清单。清单里保留「主选、备选、兜底」三个位置，任何一个位置出问题都能在一周内切过去。

• 每季度重跑一次自有样本集，保留历史结果，看趋势而不是看单点
• 维护主选、备选、兜底三个位置，每个位置都要验证过可用
• 把切换触发条件写清楚：错误率、延迟、成本任一超线就切
• 价格与额度变动定期复查，可以翻 /price-watch 和 /resets
• 每次切换后回填结果到清单，避免下次重复踩坑

触发条件要写成可执行的判断，比如「连续多少请求里错误率超过多少」「首字延迟中位数超过多少」，而不是「感觉变慢了」。模糊的触发条件等于没有触发条件，等到大家都有感觉的时候，问题通常已经影响到用户了。