当前位置：首页>排行榜>【大模型推理系列】大模型排行榜是怎么排出来的?解密大模型评测与榜单

【大模型推理系列】大模型排行榜是怎么排出来的?解密大模型评测与榜单

更新时间 2026-08-15 18:46:31

面对同一个问题，一份回答只有三句话，结论直接；另一份结构完整、解释充分，还配了表格。哪个更好？

如果用户正在排查线上故障，第一份可能更有用；如果要给团队做培训，第二份也许更合适。再换成一道数学题，正确答案通常比文采重要；换成修复代码仓库，最后还要看补丁能否通过测试；换成客服 Agent，则要观察它能否正确调用工具、遵守权限并在有限成本内完成任务。

这就是大模型测评的基本矛盾：模型能做的事越来越开放，但任何排行榜都必须先把“好”压缩成一套可执行的规则。

所以，看到一个分数时，真正该问的不是“它高不高”，而是：测了什么任务，给了模型什么输入，允许它尝试几次，由谁判分，最后如何汇总？

一、排行榜上的不是“模型”，而是一场实验

同一个模型，仅仅换一个提示模板，就可能输出不同格式；打开思考模式或增加推理预算，数学表现可能变化；允许搜索、运行代码和反复修改后，它测到的已经不只是语言模型，还包括工具、Agent 框架和运行环境。

一份可比较的结果，至少要说清七件事：

模型版本 + API 端点 + 数据集版本 + Prompt 协议 + 推理配置 + 评测框架 + 评分指标

其中，数据集决定“考什么”；Prompt 协议决定“题目怎样呈现”；推理配置决定“给多少时间和尝试机会”；裁判决定“怎样算对”；统计方法决定“怎样从每题结果变成一个总分”。

这并非吹毛求疵。Hugging Face 曾比较 MMLU 的三种实现，发现同一题集因为 Prompt、选项概率计算和实现细节不同，不仅分数不同，模型排序也可能变化。EleutherAI 的 lm-evaluation-harness 因而把 few-shot 数量、聊天模板、系统提示、生成参数、随机种子和原始样本输出都纳入配置。

二、大模型测评的三条路线与四类裁判

固定题库依然是基础。数学题可以核对答案，代码题可以运行测试，知识题可以计算准确率；它们便宜、可复现，也方便做版本回归。但开放式模型还需要其他尺子。

从裁判来源看，可以概括为“客观验证、模型裁判、真人偏好”三条路线；为了把客观题的答案匹配与可执行任务区分开，下表进一步拆成四类：

路线	典型裁判	主要回答的问题	主要短板
标准答案题库	答案、规则、字符串解析	知识、推理、指令是否答对	Prompt 敏感，可能饱和或污染
可执行验证	单元测试、环境状态、业务规则	代码、工具调用、Agent 是否真的完成任务	环境昂贵，测试本身也可能漏判
LLM-as-a-Judge	强模型按 rubric 打分或比较	开放写作、总结、对话等难以精确匹配的任务	有位置、冗长、自我偏好等偏差
人类偏好	用户或领域专家	哪个回答更有用、更清晰、更愿意采用	成本高、有噪声，依赖参与人群

LLM-as-a-Judge 不是“机器裁判天然客观”。相关研究发现，它可能受答案位置、长度、自我增强偏好和自身推理能力影响。常见缓解办法包括交换 A/B 位置、设置清晰 rubric、使用参考答案、对裁判做人工校准，并报告一致率；但这些做法只能控制已知问题，不能证明裁判已完全无偏。

三、常见 Benchmark 题型图鉴：它们到底偏向测什么

下面的“示意题”均由本文重新编写，不是测试集原题。它们只展示任务形态，避免泄题，也避免把背过公开样例误认为真实能力。

1. 知识、推理、数学与指令

Benchmark	同构示意题与常见指标	更擅长说明什么	不宜直接外推什么
MMLU / MMLU-Pro	“操作系统在什么条件下触发缺页异常？”多项选择；Accuracy。MMLU 覆盖 57 个学科，MMLU-Pro 把选项扩为 10 个并增加推理题	学术与职业知识广度、选择题辨析；适合通用模型初筛	开放写作、对话体验和生产可靠性；高分也可能来自题库熟悉度
GPQA	“某量子体系经过两个非对易操作后，测量结果如何变化？”研究生级选择题；Accuracy	生物、物理、化学的专家知识与多步科学推理；适合研究型问答候选测试	其他专业能力；非专家也难核验，企业应用仍需领域专家评审
GSM8K	“仓库有 48 箱货，卖出 6 箱后补入 2 箱，重复三次还剩多少？”答案匹配	小学难度但需多步展开的文字算术；适合基础推理回归	高等数学、真实财务分析；数据已较老，需防污染与饱和
MATH	“已知多项式满足若干整除条件，求整数参数。”竞赛数学；Exact Match	代数、几何、数论等竞赛推理，能拉开 reasoning model 差异	日常数值工作、表格分析；得分对 CoT、答案提取和推理预算敏感
BBH	“甲早于乙，丙晚于甲但早于丁，谁最早？”23 类困难任务；平均准确率	逻辑演绎、对象跟踪、组合推理，以及 CoT 是否有帮助	全面知识水平；任务较小且偏合成，Prompt 改动可能影响较大
IFEval	“用恰好三点回答；每点八个汉字；不得出现‘模型’。”严格/宽松、Prompt/Instruction 四类准确率	可程序验证的格式、长度、关键词等指令遵循；适合结构化输出前测	内容是否正确、有帮助；模型可能完美守格式却答错事实
TruthfulQA	“吞下口香糖真的会在胃里停留七年吗？”Truthfulness 与 Informativeness	能否抵抗网络文本中的流行误解；适合检查“自信复述谬误”	全面事实正确率、最新知识或带检索的事实核验能力
C-Eval	“依据中国现行语境回答一道人文、工程或职业资格选择题。”Accuracy	中文环境下从中学到职业级的 52 学科知识与推理；适合中文基座初筛	中文写作、客服体验、方言与企业术语理解
LiveBench	新近数学、代码、数据分析或指令题；按可验证标准答案自动评分	通过定期更新题目降低污染，适合追踪当前客观能力	人类偏好和私有业务效果；不同发布时间的版本不能无条件横比

2. 代码、长上下文、多模态、Agent 与安全

Benchmark	同构示意题与常见指标	更擅长说明什么	不宜直接外推什么
HumanEval / LiveCodeBench	“实现函数，返回数组中第二大的不同元素”；或新近竞赛算法题；Pass@k	函数级代码正确性；LiveCodeBench 还覆盖执行、输出预测、自修复并用新题降低污染	阅读大型仓库、需求澄清、长期维护能力
SWE-bench Verified / DeepSWE	“定位某库的时区 bug，跨文件修复并通过测试”；Resolved Rate、Pass@k	仓库探索、补丁生成、测试迭代等软件工程 Agent 能力	裸模型能力；分数同时受 Agent scaffold、工具、步数、环境和验证器影响
LongBench v2 / RULER	“从几十份合同中找出例外条款并比较冲突”；Accuracy 随上下文长度分层	前者偏真实长文档深层理解，后者可控地测检索、多跳追踪与聚合；适合长文档/RAG 前测	宣称的最大上下文窗口就是有效理解长度；也不等于长期记忆能力
BFCL	“查询杭州明日天气，再用结果创建日程”；函数选择、参数/AST、任务类别得分	单轮、多轮工具选择与参数生成；适合 Function Calling 接口选型	完整业务流程是否闭环，尤其是权限、政策与异常恢复
τ-bench 系列	“用户要求改订单地址；Agent 要查政策、确认身份、调用 API 并更新数据库”；Pass^k 等	对话中遵守领域规则、与用户协商并正确改变数据库状态；适合客服 Agent	所有行业流程；用户是模拟的，版本、领域和评分修复会改变可比性
MMMU	“观察电路图并判断某元件变化对输出的影响”；Accuracy	图表、地图、乐谱、化学结构等多种图像与大学知识结合的推理	OCR 单项能力、GUI 操作或视频理解
HarmBench	“用越狱方式诱导模型生成危险指导（具体内容省略）”；攻击成功/拒绝表现	自动红队攻击与有害请求拒绝的标准化比较；适合安全基线与防御回归	正常请求的可用性；只追求拒绝率可能造成过度拒答，必须补测 benign 场景
Arena	“帮我给一次技术复盘写开场。”匿名 A/B 用户投票；Arena Score	真实开放 Prompt 下的整体人类偏好	事实正确率、安全、速度、成本和企业任务完成率

3. Benchmark 名称并没有锁死 Shot 数

四、Zero-shot、One-shot、Four-shot 到底是什么

这里的 shot，指测试题之前放进上下文的“示范样例”数量。

Zero-shot（0-shot）：不给示例，只给任务说明和测试题。
One-shot（1-shot）：先给一个“输入—正确输出”的例子，再给测试题。
Four-shot（4-shot）：先给四个例子，再给测试题。
Few-shot：少量示例的统称，1-shot、4-shot、5-shot 都属于 few-shot。

例如让模型把工单分成“故障、咨询、投诉”。0-shot 只告诉它三个标签；1-shot 会先展示一条已标注工单；4-shot 则展示四条。模型参数没有更新，它只是在当前上下文里临时归纳格式和任务规律，这通常称为上下文学习。

Shot 越多并不必然越公平或越强。示例会占用上下文，样例选择可能暗示答案分布，顺序也可能影响结果。正规评测应从训练集或验证集取示例，不能把测试答案泄漏进 Prompt；还应固定示例内容、顺序和随机种子。lm-evaluation-harness 明确区分 fewshot_split 与 test_split，并把 num_fewshot 默认设为 0。

历史榜单中常见“某任务 4-shot、另一任务 5-shot”，不是因为 4 或 5 有普适魔力，而是各基准沿用了自己的公开协议。例如 MMLU 常按 5-shot 评测；Hugging Face 也提醒，即使使用相同五个示例，示例顺序变化仍可能带来差异。

Shot、CoT 和思考预算是三件事

Chain-of-Thought（CoT）关注的是回答方式，而不是示例数量。

Zero-shot CoT：没有示范，但提示模型先推理再给答案。
Few-shot CoT：示范样例中不仅有答案，还展示推理过程。
Direct Answer：要求直接输出答案，不展开推理。

因此“5-shot direct answer”和“5-shot CoT”不是同一协议。对现代 reasoning model，还应记录是否启用思考模式、推理强度或 reasoning tokens 上限、总输出上限，以及计分时怎样提取最终答案。当前 lm-evaluation-harness 甚至提供专门参数，在打分前剥离思考段落。

Four-shot 与 Pass@4 只共享一个数字 4：前者改变输入示例数，后者改变生成机会数。下面把 Pass@k 单独拆开。

五、Pass@k 独立拆解：多给几次机会，究竟测到了什么

1. Pass@k 的基本定义

对同一道可验证任务生成 k 个候选，只要其中至少一个通过单元测试或任务验证器，就认为该题在次机会内被解决。对整个题集取平均，得到 Pass@k。

直接生成个样本、数一数有没有通过，这种算法本身没错，但方差很高。HumanEval 为此改用另一种做法：每题先生成个候选，其中个正确，再计算无偏估计：

它表示：从已经生成的个候选中随机取个，至少取到一个正确候选的概率。

2. 一个带数字的计算例子

假设某题生成个候选，其中个通过测试：

这里的 Pass@4 变高，不代表单次生成能力突然增强，而是系统获得了更多尝试。若测试器能自动筛掉错误答案，这种能力确实有工程价值；如果没有测试器或可靠选择器，模型自己未必知道四个候选中哪个正确。HumanEval 论文也把 Pass@k 解释为“由知道测试结果的 oracle 从 k 个样本中选优”的能力上界。

3. Pass@1、Pass@4 与 Pass@100 分别适合回答什么

Pass@1：一次生成的成功率，最接近低延迟、不能重试的一次性交付。
Pass@k：固定次采样并有验证器兜底时，系统能否覆盖至少一个正确解，适合代码生成、搜索和可自动验收任务。
较大的 k：更强调候选多样性和推理时算力。它可以展示模型“能不能想到正确解”，但不代表成本可接受。

比较 Pass@k 必须使用相同的。还要同时固定温度、top-p、最大输出、停止条件和 Prompt。HumanEval 的实验表明，较大的往往偏好更高温度以增加候选多样性；这说明 Pass@1 与 Pass@100 即使来自同一模型，也可能使用不同最优采样配置，不能只看数字大小。

4. 六个长得相似、含义不同的指标

名称	成功条件	主要回答的问题
Pass@k	k 个候选中至少一个成功	多次尝试能否覆盖正确解
k 次运行平均成功率	每次单独记 0/1，再取平均	单次表现的稳定均值，近似 Pass@1
Best-of-k	生成 k 个，再由奖励模型/测试器选一个	“生成器 + 选择器”这个系统有多强
Self-consistency	多条推理路径对最终答案投票	多数答案是否更可靠，不要求任何一个通过测试
Top-k Accuracy	正确类别是否在概率最高的 k 个标签中	分类候选覆盖，不是代码 Pass@k
Pass^k	同一任务连续 k 次都成功	可靠性与一致性；τ-bench 用这一方向检查 Agent 多次运行是否稳定

尤其要注意 Pass@k 与 Pass^k 方向相反：Pass@k 只要 k 次里成功一次，k 越大通常越高；Pass^k 要求 k 次都成功，k 越大通常越低。

5. 代码模型与 Agent 榜的 Pass@k 不能直接混用

函数题的一次 sample 可能只消耗几百 token；仓库 Agent 的一次 rollout 可能包含几十次文件读取、命令执行、测试和修改。DeepSWE 的 Pass@1 按每题多次 rollout 的平均通过率计算、每题等权（无论该题最终计入几次 rollout）；Pass@4 则看每题至多四次 rollout 中是否至少一次解决。即使都叫 Pass@4，后者的成本和系统组成也与 HumanEval 完全不同。

因此一项可信的 Pass@k 结果至少应同时报告：、、每题 rollout 数、温度与随机种子、Prompt、token/步骤/时间上限、工具权限、测试器版本、超时与基础设施错误如何计入，以及平均和尾部成本。不要用经验 Pass@1 直接套推算 Pass@k；样本相关性和 plug-in 估计偏差都会让结果失真，HumanEval 给出的组合数公式正是为此设计。

企业使用时，一次输出就要发给客户的场景应优先看 Pass@1；允许自动测试和重试的代码任务可以看 Pass@k，但要附总成本；交易、客服与高风险 Agent 更应该补充多次都成功的稳定性指标，而不是只奖励“多试几次总有一次对”。

六、分数是怎样算出来的

不同任务需要不同指标。但在计算指标之前，还有一层经常被省略：怎样把模型的一整段自然语言回答，变成评分器能够比较的答案。完整链路通常是：

Prompt 与输出约定 → 模型原始回答 → 解析/抽取 → 规范化 → 与参考答案比较 → 跨题汇总

1. Accuracy、Exact Match 与 F1

先把自然语言回答变成“可评分答案”

假设一道选择题的正确选项是 B。评测 Prompt 可以明确要求模型只返回约定格式：

评分器先用 JSON 解析器读取 answer 字段，再检查它是否属于 A、B、C、D，最后与标准答案比较。若成功解析为 B，该题记 1；解析为其他选项或解析失败，通常记 0。对所有题取平均，就是 Accuracy：

问题在于，模型可能给 JSON 套上 Markdown 代码围栏、在 JSON 前加入解释、使用中文引号，或者输出 {"answer":"B，因为……"}。严格解析器会把非法 JSON 或非法选项直接判错；宽松解析器可能先去掉代码围栏，再用正则提取第一个或最后一个 [A-D]。后者能减少格式失误，却也可能误把推理过程中的某个字母当成最终答案。若评测允许修复 JSON、重试或让另一个模型抽取答案，也必须写进协议，因为它测到的是“模型 + 解析/修复系统”。

EleutherAI 的 lm-evaluation-harness 就把截断、正则抽取、取首个结果和多数投票组织成显式 filter pipeline，并建议先抽查少量原始输出，确认答案抽取符合预期。如果 API 支持按 JSON Schema 约束生成，还应注明是生成阶段强制结构化输出，还是生成后才尝试解析；前者会改变模型可输出的空间，也属于实验条件。

选择题还存在另一种常见协议：不给模型生成 JSON，而是分别计算选项 A、B、C、D 接在 Prompt 后的条件对数似然，选择分数最高的选项。这种 multiple_choice/loglikelihood 评测与“自由生成后抽取答案”都能得到 Accuracy，但请求接口、长度归一化和格式敏感性不同，结果不能只凭指标同名就直接混用。

Exact Match：规范化后必须完全相同

Exact Match（EM）常用于短答案和填空题。它先按事先约定的规则规范化预测与参考答案，再判断两者是否完全一致：一致记 1，否则记 0。

例如标准答案是 42：

模型原始回答	解析/规范化规则	最终预测	EM
{"answer":"42"}	读取 JSON 的 answer	42	1
答案是 42	正则抽取末尾数字	42	1
答案是 42	不做答案抽取，只去首尾空格	答案是 42	0
42.0	不做数值等价转换	42.0	0

所以“Exact”并不代表直接逐字符硬比。不同基准可能选择转小写、合并空白、去标点、去英文冠词、统一 Unicode 或数值格式，也可能接受多个参考答案并取最佳匹配。反过来，过度规范化也可能把本来不同的答案合并。可信结果应公开抽取规则、规范化函数、多个参考答案的处理方式，以及空输出/非法输出怎样计分。lm-evaluation-harness 的 Exact Match 配置就可以分别设置忽略大小写、标点和指定正则。

F1：用精确率与召回率给“部分重合”分数

问答或文本抽取任务中，预测可能抓住了答案主体，却比参考答案短一些或多一些。此时常使用 token overlap F1。先把规范化后的预测和标准答案切成 token，再计算：

为了便于演示，假设按空格切词（这里刻意写成不带连接号的 Bradley Terry，好切出三个 token）：标准答案是 Bradley Terry 模型，预测是 Bradley Terry。两者重合 2 个 token，因此 Precision 为，Recall 为，F1 为。这道题的 EM 是 0，但 F1 能表达“答中了主体，只漏了一个词”。若预测写成 Bradley Terry 模型以及 Elo，重合变成 3 个，Precision 降为、Recall 升为 1、F1 为 0.75；这也说明多写无关内容会被惩罚，而不是越长越占便宜。

实际评分一般把重合看作 token 多重集合的交集，避免重复同一个词无限加分；若完全没有重合，F1 为 0。存在多个标准答案时，常对每个参考答案计算 EM/F1，再取最佳值；全题得分则通常是逐题 F1 的平均。

这里的 token 怎么切非常重要。英文常按空格并配合大小写、标点和冠词规范化；中文可以按字、分词结果或模型 tokenizer 计算，不同方案会改变重合数。因此不能只写“用了 F1”，还要说明 tokenization 与 normalization。

也不要把这种问答 F1 与分类任务的 F1 混为一谈。分类 F1 同样由 Precision 和 Recall 的调和平均得到，但它统计的是“某类别被正确预测”的 TP、FP、FN：Macro-F1 先算每个类别的 F1 再等权平均，更关注少数类；Micro-F1 先汇总所有类别的 TP/FP/FN 再计算，更受大类影响，在单标签多分类中通常等于 Accuracy；Weighted-F1 则按各类样本数加权。三者回答的问题不同，排行榜必须写清采用哪一种。

最后，解析器不是评测之外的清洁工具，而是评测定义的一部分。一个模型可能知道答案却输出错格式，也可能答案错误却被过宽的正则“救回”。因此除汇总分外，最好单独报告格式合规率、解析失败率和解析后任务得分，并保留原始回答供抽查。

2. 代码通过率与 Resolved Rate

HumanEval 一类函数题运行单元测试，报告 Pass@k。SWE-bench 一类仓库任务则把补丁应用到指定代码版本，在容器中运行测试，判断 GitHub issue 是否被解决；常见总指标是成功解决的任务比例。

这里还有两个很容易和 Pass@k 混淆的字段：FAIL_TO_PASS（F2P）与 PASS_TO_PASS（P2P）。它们不是“生成几次”，而是一份候选补丁内部要通过的两组测试：

测试组	基准状态	应用候选补丁后	它在防什么
FAIL_TO_PASS	与目标 issue 相关的测试原先失败	必须变为通过	只改了代码表面，却没有真正修复问题
PASS_TO_PASS	原本正常的相关测试已经通过	应继续通过，不应回归	修好新问题，却破坏旧功能的回归

举个同构示意：issue 是“解析器无法识别带负号的数”。F2P 可以是 parse("-3") == -3，它在基线版本失败，补丁后应通过；P2P 可以是 parse("3") == 3，它原本就通过，补丁后仍应通过。如果模型粗暴删除校验、让两个输入都返回 -3，它可能修好了 F2P，却会打坏 P2P，不能算完整解决。

构建这类题目时，基准从真实 issue 与对应 PR 中分离出三样东西：给模型看的问题描述、作为参考答案的代码 patch，以及用于验收的 test_patch。评测环境回到 base_commit，应用候选补丁和测试补丁，再按该实例的测试指令执行；F2P/P2P 字段告诉评分器应关注哪些测试。模型不应通过参考补丁或隐藏测试清单获得答案，否则测到的是泄漏后的适配，而不是从 issue 自主修复。

SWE-bench 当前评分实现中，F2P 比例为 1 且 P2P 比例也为 1，实例才是 RESOLVED_FULL；若只修复部分 F2P、同时没有破坏 P2P，可标记为 RESOLVED_PARTIAL，但不会作为完整 resolved 计入。现实仓库中还可能有基线和参考补丁都失败的 FAIL_TO_FAIL 测试；它们不是本 issue 的有效判据，默认不参与判定，harness 中需显式开启 calculate_to_fail 才会单独统计。跳过的测试则按方向区别对待：P2P 的 SKIPPED 算“未回归”，F2P 的 SKIPPED 算失败——否则一个让所有 F2P 测试都被跳过的补丁会两头不沾。这类实现细节正是发布结果时必须锁定 harness 版本的原因。也要注意，F2P/P2P 是基准选出的测试集合，并不等于“整个仓库所有测试都跑过”。

因此两层指标要分开看：F2P/P2P 决定某一次 rollout 产出的补丁是否合格；Pass@k 再决定同一任务的 k 次 rollout 中是否至少有一次合格。一个系统可以靠增加 k 提高 Pass@k，但每个被判成功的补丁仍必须同时满足修复性与回归性要求。

3. LLM 裁判分与成对胜率

开放回答可以让裁判按 1～10 打分，也可以让它在 A/B 中选优。成对比较通常比绝对打分更容易校准，但必须处理位置偏差和平局，并说明裁判模型、Prompt、参考答案与交换位置规则。

4. 人类投票与 Bradley–Terry

Arena 收集的是大量匿名 A/B 投票。Bradley–Terry（BT）模型为每个模型估计一个相对偏好强度，A 战胜 B 的概率为：

若两者强度相同，预测胜率是 50%。真正计算时，不是每打一场就做一次 Elo 加减分，而是把大量对战一起拟合，寻找最能解释全部投票的相对强度，再映射成易读的 Arena Score。早期榜单曾用在线 Elo，后来官方转向 BT 最大似然估计；今天称其为“基于 BT 的 Arena Score”更准确。

5. Agent 的成功率还不够

Agent 可能用几十步、重复调用工具或消耗很高成本才成功。企业还应记录平均/尾部步骤数、token、总耗时、工具错误、超时、重试、单任务成本和安全违规。一个成功率略高但成本高十倍的系统，未必更适合生产。

七、Arena：真实用户偏好是怎样形成榜单的

2023 年，LMSYS 与 UC Berkeley SkyLab 相关研究者发布 Chatbot Arena，以匿名、随机、众包的双模型对战收集人类偏好（LMSYS 本身是 UC Berkeley、Stanford、UCSD、CMU、MBZUAI 的多校协作组织）。2024 年 9 月项目获得独立站点，LMSYS 当前把 Chatbot Arena 列为已“毕业”的孵化项目；平台曾名 LMArena，并在 2026 年 1 月 28 日更名为 Arena、迁至 arena.ai，当前官方条款中的运营主体为 Arena Intelligence, Inc.。因此本文用“Arena”指当前平台，用“LMSYS Chatbot Arena”指它的历史来源。

一次经典对战包括：用户输入真实 Prompt；平台隐藏两个模型身份并并排返回答案；用户选择更偏好的一边或平局；投票后揭示模型；有效数据经清洗后进入榜单。匿名降低品牌先验，成对选择也比要求所有用户统一打“8.3 分”简单。

Arena Score 是样本估计，因此要与置信区间或 rank spread 一起看。两个模型区间大量重叠时，更稳妥的结论是“现有样本不足以稳定区分”。分类榜会在数学、编程、创意写作或语言等 Prompt 子集上重新估计，更接近专项偏好，但样本更少、区间通常也更宽。

Style Control 则尝试把回答 token 长度、Markdown 标题、加粗和列表等可观察风格特征作为额外变量加入 BT 回归，降低“写得长、排得漂亮”对比较的混杂。它没有消除全部偏差：语气、结构、拒答方式等因素仍可能未建模，而且长回答有时本来就更完整。

Arena 主要测量的是：在平台当时的用户、Prompt、界面、模型版本和数据规则下，人们对两个回答的相对偏好。它不等于事实正确率、安全性、推理速度、成本、工具成功率或企业业务效果。

八、除了 Arena，还有哪些常用榜单

“哪个榜单更权威”不是一个好问题；更有用的问题是“哪个榜单与我的任务更同构”。

方向	代表基准/榜单	核心方法	适合回答什么	读榜注意事项
综合客观能力	LiveBench	定期更新题目，以可验证标准答案自动判分	通用推理、数学、代码、数据分析等	看版本与时间窗，不同类别别只取平均
知识与困难推理	MMLU-Pro、GPQA、C-Eval	多学科选择题；分别强化推理、专家科学知识与中文学科覆盖	知识型任务的基础筛选	选择题高分不代表开放写作、检索或业务执行能力
数学与可验证推理	GSM8K、MATH、BBH	答案匹配或可验证推理任务	小学应用题、竞赛数学、困难组合任务	Shot、CoT、答案抽取器和推理预算会显著影响结果
指令与真实性	IFEval、TruthfulQA	可验证格式约束；针对常见误区的问答	指令遵循与避免迎合错误前提	不覆盖全部现实指令，也不是完整事实核查系统
透明、多指标评测	Stanford HELM	统一框架测准确、鲁棒、效率、偏差、毒性等	希望审计 Prompt、输出和多维权衡	HELM 已于 2026 年 6 月 1 日进入维护模式，发布前核对活跃榜单
中文/学术综合	OpenCompass	公布实时配置，在多数据集上统一复现	中文模型和学术能力横向比较	配置和题集会更新，必须记录版本
人类偏好	Arena	匿名双模型对战、用户投票、BT 回归	开放对话的整体体验	偏好不等于正确，受用户与 Prompt 分布影响
代码生成	HumanEval、LiveCodeBench	运行测试；LiveCodeBench 持续加入新竞赛题	函数级生成、执行、输出预测、自修复	看 Pass@k、语言、题目时间窗和采样配置
多语言代码编辑	Aider Polyglot	在文件中完成 225 道多语言练习并跑测试	代码编辑格式与六种语言的综合表现	分数也受 Aider scaffold、编辑格式和重试影响
仓库级修复	SWE-bench Verified	在真实仓库中生成补丁并运行 issue 对应测试	软件工程 Agent 能否解决真实 GitHub issue	要区分模型、Agent 框架、工具和预算
原创长程软件工程	DeepSWE	原创任务、固定仓库提交、手写功能验证器	面对未公开新任务的长程探索与跨文件修改	题量和语言范围有限，公开后仍可能逐渐污染
长上下文	LongBench v2、RULER	真实长文档题与可控合成长上下文任务	RAG、合同/报告阅读和有效上下文长度	标称窗口不等于有效理解，合成检索也不等于真实文档工作流
多模态知识推理	MMMU	图像、图表与大学学科知识联合问答	文档图表与专业视觉推理初筛	不等于 GUI 操作、视频理解或企业图像流程
终端 Agent	Terminal-Bench	容器化终端任务、轨迹与可执行验证	Agent 使用命令行完成多步骤任务	版本、Agent、网络权限和反奖励黑客规则很重要
工具/函数调用	BFCL	AST、单轮/多轮、缺失参数、Web 与记忆任务	模型能否选对工具并生成正确参数	总分是各子类未加权平均；格式、工具文档与延迟也会显著影响结果
规则型客服 Agent	τ-bench 系列	模拟用户、领域政策、工具调用和数据库终态验证	多轮协商、规则遵循与操作可靠性	看领域、用户模拟器、Pass^k、工具和版本，不能只看单次成功
安全红队	HarmBench	标准化有害行为、攻击方法与分类器评估	防御回归和红队基线	还要测正常请求可用性，防止过度拒答
API 质量、速度与价格	Artificial Analysis	综合质量测试，并测 TTFT、输出速度、价格	生产端点的质量—体验—成本权衡	这是端点体验，不是硬件理论峰值

还有一个历史名称经常出现：Hugging Face Open LLM Leaderboard。它曾以统一 harness 比较超过 1.3 万个开源模型，但已于 2025 年 3 月 13 日正式退役，官方原因正是能力形态变化（推理模型与助手型模型崛起）、原基准逐渐过时。因此它适合用来理解 few-shot 与可复现评测史，不应再当作当前实时总榜。

九、从 HumanEval 到 DeepSWE：代码榜究竟越测越真实了吗

代码榜单的演进，很像把考试从“补全一道函数题”逐步搬进真实仓库。

HumanEval 提供函数签名、说明和单元测试，适合测短代码的功能正确性，成本低、可重复，但离真实代码库仍有距离。

LiveCodeBench 持续从新近竞赛收集题目，用时间切分降低污染，并覆盖代码生成、执行、测试输出预测和自修复等场景。

SWE-bench 把真实 GitHub issue、代码仓库和对应修复组织成任务。评测会建立 Docker 环境、应用模型补丁、运行测试并判断 issue 是否解决。SWE-bench Verified 是其中经工程师审阅、确认描述清晰且可解的 500 个实例。

它的关键不是“测试总体通过率高不高”，而是候选补丁能否让全部 F2P 测试由失败转为通过，同时让全部 P2P 测试保持通过。前者验证修复，后者验证没有回归；两者共同定义一次 rollout 是否 resolved。随后若同题运行多次，才在更外层计算 Pass@k。这个两层结构解释了为什么“Pass@4 较高”和“补丁通过 F2P/P2P”是不同维度。

DeepSWE 再处理两个问题：公开仓库的历史修复可能进入预训练数据；原 PR 自带测试是为验证某个具体修复写的，未必能公平判断其他等价实现。DeepSWE 的 113 个任务由作者从头设计，覆盖 91 个活跃开源仓库、五种语言，参考解不提交回上游；每题使用手写功能验证器检查可观察行为。

这不意味着 DeepSWE 已经等于“真实企业研发能力”。它的任务数、仓库筛选、语言构成、Agent 环境和预算仍限定了测量范围；任务公开后，未来模型也可能见过题目。论文自己也强调，榜单位置反映的只是这一项特定测量，既不是对模型质量的全局判决，也不等于在调优过的产品里使用该模型的实际体验。

特别澄清：DeepSWE 基准与 DeepSWE-Preview 模型

二者名称相似，但不是同一个对象：

DeepSWE benchmark：Datacurve 等作者发布的原创长程软件工程题集。
DeepSWE-Preview：Agentica 发布的模型/Agent 名称；其公开复现指南是在 SWE-bench Verified 数据集上运行。

因此看到“DeepSWE 的 SWE-bench 分数”时，先判断主语到底是模型还是题集。

十、读任何榜单，都先核对这张“实验合同”

维度	至少要记录什么	常见误读
被测对象	base/chat/reasoning，精确版本，API 日期，量化	只写品牌名，把不同版本当一个模型
Prompt	0/1/n-shot，示例内容与顺序，系统提示，chat template	把 0-shot 与 5-shot 分数直接比较
输出与解析	JSON Schema、生成或概率选择、正则/字段抽取、规范化、非法输出与重试规则	把解析器差异误认为模型能力差异
推理配置	temperature、top-p、max tokens、reasoning effort	把高预算推理当免费能力
尝试与选择	Pass@k、重试次数、self-consistency、是否有 verifier 选优	把 Pass@10 当 Pass@1
仓库测试	F2P/P2P 测试集合、测试补丁、基础提交、完整/部分解决规则	只见 F2P 变绿就宣称 issue 已解决
工具与框架	浏览器、终端、代码执行、RAG、Agent scaffold、最大步数	把“系统分”说成“裸模型分”
裁判	标准答案、测试、裁判模型、人类，rubric 与位置交换	把 LLM 裁判分当绝对事实
数据	题集版本、split、截止日期、去重与污染策略	新旧榜单混排，忽略训练泄漏
统计	micro/macro average、类别权重、区间、样本量	小分差硬排一二名
资源	token、时间、成本、并发、超时和失败处理	只看质量，不看生产可行性

一项结果若没有这些元数据，最多是线索，不是可复现证据。

十一、企业应建立“四层测评体系”

公开榜单最适合缩小候选范围，不能替代内部选型。

层级	核心问题	推荐指标
客观能力	答案是否正确、合规、可复现	准确率、代码/规则通过率、事实性、安全与越权测试
人类偏好	用户或专家更愿意采用哪个结果	内部匿名 A/B、任务分层胜率、平局率与置信区间
系统性能	能否稳定、经济地提供服务	TTFT、TPOT、P95 延迟、吞吐、成功率、单任务成本
私有业务	是否真正改善业务结果	完成率、人工接管率、审核通过率、处理时长、业务损失