Why Your Benchmark Score Is Lying to You

为什么你的基准测试分数在欺骗你

2018 年，一支团队在 ImageNet 上把分类错误率压到了 3.57%，足以让论文登上顶级会议；2023 年，一批模型在 MMLU、HumanEval、GSM8K 等基准上轮番刷榜，动辄逼近人类水平。然而，当这些模型真正进入生产环境、面对真实用户时，团队逐渐发现一件令人不安的事实：榜单成绩与用户留存、转化率、满意度之间，几乎不存在稳定的正相关关系。基准测试分数，正在系统性地误导我们。

1.1 排行榜分数衡量的是排行榜表现，而非用户结果

这是本书最重要的一条命题，必须在第一章里把它的逻辑讲透。

基准测试之所以被相信，前提是三条隐含假设

一个基准（benchmark）要充当"代理指标"，至少需要满足三条隐含假设。

第一条，分布对齐。测试样本的分布必须与目标场景的分布大致对齐。换句话说，如果基准来自学术数据集，那么它必须能够代表真实用户实际遇到的问题。

第二条，训练-测试隔离。模型在测试时遇到的样本，不能在训练阶段以任何形式出现过——这既包括直接的训练样本复用，也包括通过教科书、题库、维基百科、常见问答等"灰色地带"的间接污染。

第三条，用户价值代理性。衡量指标本身必须是"用户价值"的有效代理。准确率高，并不一定意味着响应更有用、更安全、更合乎用户预期；F1 分数高，也不意味着在长尾样本上稳定。

只要这三条假设中任意一条被破坏，基准测试就开始偏离现实。但更现实的情况是：三条假设会同时松动，且每一代新基准都会以新的方式松动。

从 ImageNet 到 MMLU：我们曾经相信过的故事

ImageNet 之所以在 2010 年代成为深度学习的"北极星"，并不是因为它能衡量视觉智能本身，而是因为它在相当长一段时间内近似满足上述三条假设。1000 个类别、120 万张图像、与网络爬取的图片分布大致对齐、严格的训练-测试隔离，使得模型之间可以通过 Top-5 准确率公平比较，ResNet、Inception、ViT 等架构的优劣因此被清晰排序。

但即使是 ImageNet，也曾被学界报告存在系统性标签噪声、类别重叠和分布偏移——更致命的是，模型最终被优化的，不再是"识别自然图像"这一原始目标，而是"在 1-ImageNet 协议下拿到尽可能高的分数"。这种"指标漂移"，本质上是经济学中 Goodhart's Law 在机器学习领域的再现：一旦指标成为目标，它就不再是好指标。

在 LLM 时代，基准测试的演化路线可以概括为三个阶段。第一阶段（约 2019–2021）以 GLUE、SuperGLUE 为代表，规模适中、污染风险低，但很快被 BERT 时代之后的模型刷爆。第二阶段（约 2022–2023）以 MMLU、HellaSwag、AI2 Reasoning Challenge 为代表，考察更复杂的知识和推理，但也因此更容易被题库泄漏影响。第三阶段（约 2023 至今）以 HumanEval、MBPP、GSM8K、MT-Bench、Chatbot Arena 为代表，本意是引入更接近人类的判断，但很快被特定的刷分套路和风格对齐污染。

每个阶段，我们都以为终于找到了"公正衡量模型能力"的方法；每个阶段，新方法都会在 18–24 个月内被"刷榜"，并被新一代基准取代。

为什么榜单分数几乎不等于用户结果

把这条命题换成今天的产品语言，可以分四层来看。

第一层，分布差异。榜单题目来自题库、人工编写或人工标注，与真实用户在生产环境中输入的 prompt 之间存在显著差距。生产环境的 prompt 通常更长、更口语化、夹杂错别字、包含多轮上下文，且常常跨越多个领域。

第二层，信号粒度差异。用户满意度、留存、转化率本质上是稀有事件，分布厚尾、对短周期内的微小变化不敏感；而榜单分数是确定性指标，对单一参数的微小调整就会显著波动。两者根本不在同一个量纲上。

第三层，博弈结构差异。榜单是公开竞争，参赛者拥有极强的优化动机。当分数成为融资、招聘、发布的硬通货，参与者会投入不对称的资源去优化这个具体数字，包括人工标注对应答案、组织专门的人工修订流程。

第四层，评估与部署错位。模型在基准测试时通常以"一次回答一个题目"的形式给出；但在生产环境中，模型需要在多轮对话、检索增强、工具调用、安全护栏下工作。任何一处环节失守，都会让榜单上的优势在终端变成劣势。

理解这四层，足以让大多数从业者承认一件事：把基准测试分数当作生产系统的核心 KPI，是把"高中模拟考"等同于"高考成绩"使用——既不符合统计直觉，也对真实损失负不起责任。

1.2 污染、选择性偏差与过度拟合：基准测试为何如此脆弱

榜单分数之所以容易崩溃，根源在于三类机制同时发力：污染（contamination）、选择性偏差（selection bias）、过度拟合（overfitting）。它们不是孤立的 bug，而是任何"公开、固定、可优化"的评估方式都会内生的结构性弱点。

污染：测试样本进入训练集

污染最直观的形态是测试样本被复制到训练集。在 LLM 之前，要做到这一点需要大规模的爬取与清洗；在 LLM 之后，网络本身就是训练数据，任何公开的测试集都会以极高概率被吸入模型参数。这一事实在 2023 年由多项独立审计证实：MMLU、HumanEval、GSM8K 等基准被发现在多个主流模型的训练语料中以原文或近似形式出现，比例从 5% 到 60% 不等。

更隐蔽的污染来自"合成变体"：模型开发者可以请人工改写测试题目，或者让另一个 LLM 生成"风格相似但答案不变"的题目作为微调数据；从数值指标看，这些题目从未与测试集重叠，但它们确实让模型学会了"应对这种风格"。

第三种污染来自社区层面的 prompt 工程。当一个基准足够流行，它的解题策略会被总结成模板在 Twitter、Reddit、知乎、Hugging Face 讨论区流传；这些模板最终反过来成为训练集的一部分，形成"模型—社区—模型"的反馈环。

选择性偏差：报告偏倚与幸存者偏差

在任何公开榜单上，胜出者是"被发现并被报告"的模型。落选者、表现一般的小模型、没有 7B 以上参数的社区项目，都因为没有汇报机制而没有被纳入主流叙事。由此，榜单分数呈现的是"有动机竞争的人"在"有动机的题目"上的成绩，不是"全部模型面对全部任务"的成绩。

更微妙的选择性偏差来自题目的演化。每当某个基准被刷爆，组织者会设计新一代基准。新基准天然偏向于更难的题目，而更难往往意味着更接近题库深处、更接近"百科条目式"的题目，与生产环境中的真实问题进一步远离。结果是：每一代新基准都比上一代"更难刷"，也都比上一代"更脱离实际"。

过度拟合：把基准当作目标本身

最后一个机制，也是最普遍的：当指标成为目标，它就不再是好指标。具体到基准测试，过度拟合表现为三种形态。

第一种，指标层面的过拟合。研发团队开始针对基准的评分细节调优，而非针对问题本身调优。比如 HumanEval 看重函数签名与 docstring 的格式，团队就会按这一格式生成训练数据；GSM8K 看重最终数字答案，团队就让模型在最后强制输出规范的答案样式。

第二种，协议层面的过拟合。基准测试规定了上下文窗口、温度、解码方式、是否使用 system prompt 等。模型在提交之前，已经被反复调整到最适合这套协议的状态。这与生产环境的部署条件往往差别很大。

第三种，训练-评估耦合过拟合。团队把基准分数当作模型选择的核心标准，按周甚至按天迭代。这种做法在监督学习时代是合理的，但在 LLM 时代存在放大效应：基础模型每两周迭代一次，每次都在新基准上重新定胜负，使得"榜单最新高分"与"真实生产表现"几乎解耦。

一个典型的代际循环

把三类机制放在一起看，可以观察到基准测试的代际循环：

```mermaid flowchart LR A[发布新基准] --> B[社区发现刷分套路] B --> C[训练语料纳入对应样本] C --> D[榜单分数快速攀升] D --> E[基准被刷爆或宣布"毕业"] E --> F[推出更难的新基准] F --> A ```

要点不在于循环本身，而在于循环每转一圈，基准与真实用户之间的距离都会悄然扩大。第一代基准还能代表一部分真实问题，第三代基准往往只剩下"领域专家级题目"。这就是为什么把今天的基准当成"权威判断"使用，本身就是把一代以前的现实当成现在的现实。

1.3 三个真实团队的惨痛教训

理论之外的证据更重要。下面三个案例均经过匿名化处理，但产业结构、技术栈、损失量级都来自公开可考的从业者访谈。

案例 A：聊天机器人创业公司的"六月清退"

A 公司在 2023 年初开发了一款陪伴型聊天机器人，目标用户为 25–35 岁女性。在上线前的内部评估中，团队对比了五个候选基模型，最终选择了一款在 MT-Bench 上得分 9.1/10 的开源模型，同时在"中文对话流利度"的内部榜单上领先。

问题在于他们没有做用户级的小切分评估。MT-Bench 主要评估开放式回答的"质量"，而 A 公司真正关心的是"第七轮对话之后的留存率"。两者高度相关吗？模型上线六周后，数据给出了答案：第七轮留存率与 MT-Bench 得分的相关系数仅为 0.12，统计上不显著。

更深的问题指向污染。A 团队事后在 prompt 集合里发现，约 8% 的用户问题与 MT-Bench 的题目集重合度超过 60%。这些用户是从社交媒体的"测评 prompt 列表"复制粘贴而来的，导致模型在这些 prompt 上表现得异常"专业"——但这种"专业"完全是学到的措辞，不能迁移到 A 公司关心的真实对话流上。

最终结果是：A 公司在 2023 年 6 月失去了两位核心付费用户群，季度留存下降 14 个百分点，估值在下一轮融资中被打折 30%。教训是：榜单高分与目标用户留存之间，未必有可估计的统计关系。

案例 B：编程 Copilot 选型的"通过率陷阱"

B 公司为一家大型企业提供内部代码补全服务。供应商提供了一款代码模型，在 HumanEval 上得分 78%，在 MBPP 上得分 71%，分别为当时开源模型的前列。B 公司的工程团队在做选型时，几乎一致地选择了这款模型。

但 B 公司内部的需求与 HumanEval 差异巨大：他们的代码库以 Java 为主，含有大量遗留代码、强类型注解、复杂业务逻辑和长达数百行的上下文。HumanEval 主要是 Python 函数补全，签名清晰、注释简洁、不依赖外部类型系统。结果是：上线三个月后，B 公司内部用户的"建议接受率"只有 14%，而他们在 HumanEval 上看到的"潜在接受比例"超过 60%。

更麻烦的是去污染：HumanEval 的测试集在多个 LLM 的训练语料中以原文形式出现。即使供应商声称做过"去污染"，实际范围也有限——模型没有"背诵"原始测试函数，但它在归纳层面上的"风格记忆"依然存在，让基准得分虚高。

B 公司最终决定更换另一款在 MBPP+、LiveCodeBench 等更新基准上更强、但不在 HumanEval 上领先的模型。代价是六个月的重构和迁移。

案例 C：视觉 QA 服务商的"97% 准确率"事件

C 公司向一家零售品牌提供自动化商品视觉质检服务。他们的模型在内部测试集上宣称 97% 准确率，几乎成了市场宣传的核心卖点。然而在真实部署后，该品牌连续两次重大促销活动出现严重的质检漏检——例如，把带污渍的包装箱判为合格。

调查发现，所谓 97% 准确率来自一个精心挑选的 5000 张"内部测试集"。这个测试集主要包含标准光照下的正面商品图，与生产线上的实际情况差异巨大。生产线上的图片背景杂乱、光照不均、角度刁钻，且有相当比例的商品在运输过程中被部分遮挡。C 公司的"测试集"实际上是一个"理想化摄影棚"的产物，与真实部署条件完全脱节。

更糟的是，C 公司的客户每次续签都要查看这份"准确率报告"。C 团队曾多次内部讨论是否要更新测试集，但都因为"准确率下降会影响续约谈判"而搁置。这种把基准测试当成"商业宣传工具"而非"工程决策工具"的用法，正是教科书级的代理指标失效。

三个案例的共性

把三个案例放在一张图里看，可以提炼出一组反复出现的失误：

```mermaid flowchart LR T1[第 1 版发布<br/>榜单 70 用户指标 70] --> T2[第 2 版发布<br/>榜单 82 用户指标 62] T2 --> T3[第 3 版发布<br/>榜单 90 用户指标 50] T3 --> T4[第 4 版发布<br/>榜单 95 用户指标 40] ```

这张图描绘的是同一支团队在不同发布周期内，榜单分数与用户侧核心指标的共同走势。可以清楚看到：榜单单边上行，而用户侧指标却在悄悄下行。这正是 A、B、C 三家公司在不同时间、不同任务上反复经历的同一种模式——一次模型发布，榜单在涨，财报在跌。

这三个案例中共性的失误可以总结为三件没做对的事：

第一，没有切分评估（slice evaluation）。团队只看总指标，没有在用户群体、行业切片、prompt 长度切片、上下文类型切片等维度分别测量。

第二，没有去污染审计（contamination audit）。团队没有测试基准样本是否出现在训练数据中，也没有针对"非泄露但风格相似"的样本做对照测试。

第三，没有把基准分数与业务 KPI 绑在一起。基准分数与留存、付费、转化等终端 KPI 之间没有建立统计桥梁，导致"分数升高但业务不增长"的悖论无人察觉。

这三件缺失，将在整本书中反复出现。第一章把它们摆出来，是为了让后面的章节有共同的"对症"对象。

1.4 四层评估栈：让基准分数回归它该有的位置

认清基准测试为什么不足够，我们就可以正面回答本章的第二个核心问题：如果基准分数不能预测生产成功，我们该相信什么？

答案是：相信一个四层评估栈——离线（offline）、在线（online）、对抗（adversarial）、业务（business）。这四层共同构成一个真正能衡量"模型价值"的证据体系。

第一层：离线评估

这是大家最熟悉的层：在一个固定的数据集上，用脚本化、可重现的方式评估模型。

但与传统做法的不同在于，离线评估必须满足三条新约束：

第一条，多维度切分。除总体指标外，必须强制汇报在至少 8–12 个语义切片上的指标，包括 prompt 长度、用户群体、领域、时间段、语言、安全敏感度。

第二条，去污染审计。每一个测试样本都必须经过对训练集的 N-gram 重叠、近似匹配检测。重叠率超过阈值的样本不应进入正式指标，应进入"污染估计"小节单独报告。

第三条，指标家族。单一的"准确率/通过率"远远不够，必须辅以校准误差、拒答率、推理时延、token 经济性、安全触发率等指标。

第二层：在线评估

离线指标告诉你模型在"已知分布"上的表现；在线评估则告诉你模型在"真实分布"上的表现。最常见的形式是 A/B 实验，但也包括影子流量、canary release、interleaving 等更精细的方法。

关键不在于"做不做 A/B"，而在于：实验单元是什么？是以会话为单位、以用户为单位，还是以请求为单位？实验周期多长？何时停止？这些选择，往往决定了 A/B 的统计功效能否支撑业务决策。

举例来说，对于客服机器人，应使用"会话级别"的二项指标加上"用户级别"的留存指标；对于代码补全，应使用"建议级别"的接受率加上"开发者级别"的每周活跃天数。错误的实验单元会同时稀释信号和放大噪声。

第三层：对抗评估

第三层专门捕捉"真实世界中有人故意使坏"的情况。生产环境永远不会是真空实验：用户会探查安全边界，竞争对手会故意构造边界样本，监管会要求在某些切片上具备特定能力。

对抗评估的形式包括：

• **红队测试（Red Teaming）**。让一组经过训练的人员对模型进行系统性的越狱、隐私提取、危险指令探查。
• **对抗样本库**。针对具体任务构造对抗样本，例如 OCR 任务的微小扰动图像、ASR 任务的远场混响样本、对话任务中的诱导角色。
• **情境压力测试**。在高温、断网、多设备切换、低光照、低内存等极端条件下评估模型表现。

这一层在 2024 年以后变得越来越重要，因为模型的能力上限已经不再是稀缺资源，模型"在对抗条件下的稳健性"才是真正的护城河。

第四层：业务评估

这是最终的"裁决层"：用户的付费意愿、续约概率、NPS、转介绍率、市场份额。这层指标的特点是慢、贵、稀有、不可主动实验化，但它是所有上层评估的"锚点"。

四层之间的关系可以这样理解：

• 离线评估告诉你"能不能做对"。
• 在线评估告诉你"用户实际感知到的是不是做对"。
• 对抗评估告诉你"在试图做坏事的人面前是不是仍然做对"。
• 业务评估告诉你"做对这件事在公司层面是否值回票价"。

```mermaid flowchart TD L1[离线评估 Offline] --> L2[在线评估 Online] L2 --> L3[对抗评估 Adversarial] L3 --> L4[业务评估 Business] L4 -.反馈修正.-> L1 ```

四层形成闭环：业务信号持续回流到离线评估，作为下一阶段的数据采集和评估协议设计的依据。任何一层单点优化都不足够；只有四层彼此校准，模型才能真正"对用户产生价值"。

这四层如何与基准测试共存

一个常见的误解是：提出四层评估栈，意味着要抛弃基准测试。这并不准确。基准测试仍然是离线评估的一部分，只是必须按新的约束运行：多维度切分、去污染审计、指标家族。榜单分数本身不再是 KPI，而是 8–12 个切片指标中的一个维度。

四层评估栈也不是平摊的精力分布。早期阶段，团队应当用 80% 的精力建设离线与对抗评估，因为这两者最具可重复性、可自动化、能揭示工程问题；中期阶段，把 50% 的精力转向在线评估，让模型真正进入用户视野；晚期阶段，业务评估应当成为模型开发节奏的节拍器，新模型未通过业务层验证就不允许发布。

把"基准 = 终点"改为"基准 = 起点"，是本书从第一章就要种下的种子。

1.5 本周可用的诊断清单

理论说再多，不如一份能立即动工的清单。下面这份是你可以在本周内对自家团队的基准测试体系进行 5 项快速诊断的模板，每一项的输出是一行判断（绿/黄/红）。

诊断 1：切分覆盖度

• 任务：在你的主基准测试结果旁边，列出 8–12 个用户语义切片（prompt 长度、用户群、领域、语言等），并汇报每个切片上的主指标。
• 判断标准：已有正式切片报告且近 6 周内更新——绿