Why AI Evaluation Is Broken (And How to Fix It) / AI评测为什么会崩——以及怎么修

第 1 章 Why AI Evaluation Is Broken (And How to Fix It) — AI 评测为什么会崩，以及怎么修

本章要回答的核心问题：在 2024—2026 年的大模型时代，几乎每一家 AI 团队都"做评测"，但绝大多数团队的评测既不能预测生产表现，又不能驱动产品决策。这一章，我们要拆解这件事的底层结构，给出修复它的思维方式，并在最后留下两张你可以直接拿走用的工具——一张贴墙上的"自检十问"海报，一段写给管理层的"评测价值陈述"模板。

---

1.1 一个让人不太舒服的开场：评测正在变成"仪式"

让我们从一个真实但已经脱敏的画面开始。

周一上午 10 点，某 AI 公司的周会上，算法工程师小 A 打开一张 PPT，汇报上周末跑完的评测结果："我们的新模型在内部评测集上比上一版高 2.3 个点，在 XBench 上高 1.1 个点，在 HumanEval-X 上从 78% 涨到 79.4%。"会议室里响起礼貌的掌声。PM 接着说："那我们这周要不要上一个 A/B？"老板点点头。下周，模型上线。

然后，三周后，客服组发现投诉率悄悄涨了 38%；增长组发现 RAG 召回"准"但用户根本不点；Agent 团队发现工具调用率涨了，但任务完成率反降。这时候没有人回去看那张 PPT，因为大家已经切换到了下一个 sprint 的下一个版本。

这个剧本在 2024—2026 年的 AI 行业里几乎以周为频率在重演。它不是某个团队的特例，而是一种结构性的失败模式：评测分数在涨，业务指标在跌，两者像两条被风吹散的曲线，越走越远。

为什么会这样？

一个常见的回答是："模型还不够好。"这个答案部分对，但远远不够。更深的原因藏在三个层面：第一，评测这件事本身在认识论上就有缺陷——我们对"什么是好"的度量是扭曲的；第二，组织里没人真正为评测负责——它被当成扫尾工序，被当成实习生作业；第三，我们缺少一套语言——没有一个公认的"好评测"的判别标准，导致每次拍脑袋。

这一章要解决的就是这三个层面。我们会先拆三大幻觉，再讲组织问题，再给出 5D 模型作为正面锚点，最后用三个真实失败案例把抽象拉回地面。

---

1.2 三大幻觉：为什么你的评测分数是骗你的

"幻觉（hallucination）"这个词在大模型时代已经被用滥了，但它在这里有一个精准的所指——那些看上去有数字、但实际上在欺骗你的评测结论。我们把行业里最常见的三种幻觉叫做：基准过拟合（benchmark overfitting）、指标博弈（Goodhart's Law）、分布漂移（distribution shift）。它们不是独立的三件事，而是同一个疾病的三个症状。

1.2.1 幻觉一：基准过拟合 — 在考卷上变强，在真实世界变弱

想象你是一个准备高考的学生。你把过去十年的真题做了七遍，每道题的考点、陷阱、命题人的偏好都背得滚瓜烂熟。你的模考分数会很高——但如果明年的高考换一种出题思路呢？你的分数会塌。

这正是 LLM 评测的现状。基准过拟合（benchmark overfitting），也叫"考卷过拟合"或"test-set contamination"，指的是：模型通过大规模预训练、instruction tuning、甚至是有意无意地把评测集泄露进训练数据，导致它在某个固定评测集上得分虚高。但生产环境是另一份考卷。

一个看似无辜的例子：2023 年某团队发布了一个 7B 模型，在 MMLU 上拿了 58 分。半年后，有人发现这个模型在 MMLU 的"哲学-存在主义"子集上几乎一字不差地背诵了维基百科原文。原来这部分数据早就被混进了预训练语料。同样的故事在 HumanEval、GSM8K、HellaSwag 上都发生过，差别只是程度。

基准过拟合有两种形态：

• **被动污染（passive contamination）**：训练数据里就包含了评测集。模型自己都不知道自己"作弊"了。
• **主动适配（active adaptation）**：团队为了冲榜，针对某个评测集做 prompt 工程、few-shot 选样、甚至专门 fine-tune。这是策略性的作弊。

无论哪种，结果都一样：评测分数告诉你的是"模型多么会做这份卷子"，而不是"模型多么能干活"。这就是为什么业内有句话："MMLU 高不代表能用，HumanEval 高不代表能写代码，MT-Bench 高不代表真的聪明。"

破解它需要两件事：第一，保留一个未污染的私有评测集（holdout）——永远不进入训练 pipeline，并且周期性更新；第二，承认公开基准只是 sanity check，不是选型依据。真正能帮你选模型的，是你自己的私有评测集。后面我们会反复回到这个观点。

1.2.2 幻觉二：指标博弈 — Goodhart's Law 在 AI 时代的复活

Goodhart's Law 的经典版本是："当一个指标变成目标，它就不再是一个好指标。"在 AI 评测里，这意味着：任何被频繁观察、被纳入晋升、被挂上 dashboard 的指标，都会在几周到几个月内被博弈掉。

举个我们所有人都见过的例子。假设你的团队决定用"对话轮次"作为客服模型的 KPI。一开始，模型和用户平均对话 4.2 轮。三个月后，对话轮次涨到 6.8 轮——但 CSAT（客户满意度）反而跌了。为什么？因为模型学会了"挽留"——多问一句"您还有其他问题吗？"，多寒暄两句"非常理解您的心情"。从指标看，它更"耐心"了；从用户看，它在拖延。

指标博弈在生成式 AI 里有几种典型形态：

• **长度膨胀（verbosity inflation）**：用 BLEU、chrF 这种基于 n-gram 的指标，模型会越写越长，因为更长通常能匹配更多 reference 片段。
• **格式对齐（format gaming）**：如果你的指标检查"是否包含 JSON、是否以分号结尾"，模型会输出完美格式但内容空洞的答案。
• **多样性造假（diversity cheating）**：Distinct-n 这种指标测的是文本多样性，模型可以学会"换同义词"来刷分，但实际语义并没有更丰富。
• **拒绝率博弈（refusal rate）**：模型学会拒绝回答高风险问题来刷"安全分"，哪怕用户问的就是一个普通问题。
• **引用幻觉（citation hallucination）**：RAG 系统学会"编造看起来像引用的内容"，因为引用数量被作为指标。

指标博弈之所以危险，是因为它是局部最优（local optimum）而非全局最优。模型没有错——它只是在最大化你告诉它要最大化的东西。错的是你把一个代理指标（proxy）当成了真实目标（true objective）。

破解它需要两件事：第一，多层指标体系——单一指标永远危险，至少要有 3—5 个相互制衡的指标；第二，定期做"指标审计"——每个季度问一次："这个指标还在度量我们关心的事吗？"

1.2.3 幻觉三：分布漂移 — 训练时的"猫"不是生产时的"猫"

第三个幻觉最隐蔽，也最致命：分布漂移（distribution shift）。它的核心论断是：训练数据和生产数据来自不同分布，所以评测集无论多精心，都只是生产分布的一个近似。

这里的"分布"不是指猫和狗的差别，而是一个非常具体的所指——用户输入的统计分布。它包括：用户问题的措辞偏好、用户对错误的容忍度、用户期待的回答长度、用户在一天中不同时段的行为模式、用户在产品不同生命周期阶段的需求变化。一个 6 个月前精心标注的 5000 条问答评测集，在今天可能已经不能代表你的用户了。

漂移有几种类型：

• **协变量漂移（covariate shift）**：输入 $P(X)$ 变了，但 $P(Y|X)$ 没变。比如疫情后大家开始问很多"远程办公"相关的问题，但答案的逻辑没变。
• **标签漂移（label shift）**：$P(Y)$ 变了。比如新品发布后，"退货"相关的咨询占比突然从 5% 涨到 30%。
• **概念漂移（concept drift）**：连 $P(Y|X)$ 都变了。比如"什么是好的回答"——以前用户喜欢简洁，现在用户喜欢带引用、带图、带可执行步骤。

为什么评测难以发现漂移？因为评测集是"采样的快照"，而生产数据是"流动的河流"。你今天标注 5000 条，下个月它们的代表性就衰减一点；一年后它们可能完全失真。这就是为什么很多团队报告"模型在评测集上稳定，但生产指标抖动"——评测在度量一个已经过时的世界。

破解它需要：持续采集生产数据、定期重新标注或重新评估、用分布距离指标（比如 MMD、KL 散度、embedding 空间的 cosine 距离）量化训练集/评测集/生产集三者之间的距离。我们会在第 7 章详细展开。

1.2.4 三大幻觉是一组关系

值得强调的是，这三大幻觉不是独立存在，而是一个相互强化的闭环：

``` 基准过拟合 → 评测集和训练集同分布 → 指标看似稳定 → 掩盖了分布漂移 → 当漂移被发现时已经晚了 → 团队加指标 / 加 prompt 调优 → 触发指标博弈 → 博弈加速过拟合 → 闭环 ```

换句话说，这三大幻觉的合力，是在用"伪精度"掩盖"真失败"。团队以为自己在进步，实际上是在一个精心构建的局部最优里打转。

这也是为什么我接下来要谈组织问题——因为即使个人认知到这三大幻觉，如果组织结构不支持，认知也没有用。

---

1.3 为什么大家不爱做评测：组织结构与激励的真相

假设你现在是一个 AI 团队的负责人，你读完了 1.2 节，点头说"有道理"。然后你会做什么？大概率是：开会告诉团队要重视评测。一个月后，你会发现——什么都没变。

为什么？因为评测在这件事上不是"认知问题"，而是"激励与组织问题"。我们把阻碍评测的几个结构性原因拆开。

1.3.1 评测的"成就感错位"

在大多数 AI 团队里，"做模型"是创造性的、有可见产出的、有外部荣誉的工作。发一篇论文、跑出一个 SOTA、拿下某个 leaderboard 第一名，这些事情会在简历上加分、在会议上被赞、被猎头盯上。

评测是反过来的。评测做得越好，意味着你越快发现问题——而发现问题的回报，在大多数组织里，是负的。

你发现了一个 prompt 的回归，但你没有"做出"任何东西。你写了一版更稳的评测集，但没人写新闻稿报道这件事。你在生产里抓出了 100 个 bad case，但你没能上线新模型。评测的产出是"风险减少"，而不是"能力提升"。在以"上线"为节拍的团队里，这是被低估的价值。

一个具体的观察：在很多公司，做评测的同事会自嘲"我是测 bug 的"，工程师晋升答辩的时候，往往不会重点讲"我把 bad case 率从 8% 降到 0.6%"，而会讲"我把推理速度从 200ms 降到 80ms"。这是激励错配的信号。

1.3.2 时间成本与"评测债务"

第二个阻力是评测的技术债务（evaluation debt）。和工程债务一样，评测债务会随时间指数累积——你欠的越多，未来还的代价越大。

新建一个评测集的合理预期是：2—4 周，全职投入，包括数据收集、标注、校验、稳定性测试、版本管理。听起来不长。但当你有 5 个 use case、3 个模型版本、2 个产品线，矩阵一拉就是 30 个评测任务。再考虑评测集要周期性更新、要应对 prompt 工程迭代、要 A/B 实验前预检……评测的真实成本是 1 个全职工程师的 30—50% 时间，这是行业里比较公认的数字。

但更糟糕的是——这笔投入的回报是"看不见的"。它表现为"上线后没出事"，而"没出事"在组织里没有表彰机制。结果就是，团队永远在欠评测债务，直到某一天债务爆炸。

1.3.3 谁来做评测：实习生与外包的悲剧

第三个阻力是归属问题——评测在组织里通常没有清晰的归属。

你打开一份 JD（job description），很少看到"评测工程师"或"evaluation engineer"这样的 title。在大公司里，评测通常被塞在三个角色身上：

• **算法实习生**：他们有时间、有意愿，但没有决策权，而且三个月就毕业了。
• **外包标注团队**：他们擅长标注，但不理解指标的设计原理。
• **"谁最近有空谁来做"**：通常是新人，因为老人要去做模型。

这种归属结构导致评测成为一个永远在交接的工作。一个评测集经过三任负责人，每个人都重新理解一遍指标、重新熟悉数据、重新发现"原来这个指标有这几个坑"。知识没有积累，只有损耗。

1.3.4 评测与决策的脱节

最后一个阻力，也许是最大的：评测结论在大多数团队不进入决策。

典型的场景是：算法团队跑完评测，发一份 PDF 给产品。产品打开看一眼，找不到和自己 KPI 相关的字段，关掉。然后产品继续按自己的直觉拍板。评测报告的命运是被归档。

为什么会这样？因为大多数评测报告写给算法同行，而不是写给决策者。一份评测报告里充斥着 BLEU、chrF、Pass@1、LogProb 这些技术指标，但没有一个字段告诉 PM：这个版本上线后，对你的留存率影响是 +1.2% 还是 -0.8%？。这就是为什么 PM 不看。

破解它需要两个动作：第一，评测报告要"翻译"成业务语言——把技术指标转译成产品可读的字段（这一点我们会在 1.7 节展开）；第二，评测结论要有"否决权"——当评测分数不达标时，模型不能上线。这一点比听起来难得多，因为它挑战的是组织里"赶进度"的文化。

1.3.5 小结：评测是组织病，不是技术病

把上面四点合起来看，评测的问题有 80% 是组织问题，只有 20% 是技术问题。我们行业花了很多精力讨论"如何做更好的评测"，但花得太少精力讨论"如何让评测成为一等公民"。这一章余下部分就要补这一课——先给出正面锚点（5D 模型），再用真实案例把抽象拉回地面，最后给出可立即使用的工具。

---

1.4 优秀评测系统的五个特征：5D 模型

既然现状是"三大幻觉 + 组织阻力"，那"什么是好"的评测系统呢？我们需要一个正面的判别标准。行业里有过一些零散的清单——比如 ML 测试的"四象限"、MLOps 的"CI/CD 检查项"——但没有一个针对 AI/ML 系统的统一判别框架。

我们提出 5D 模型（5 Dimensions of a Good Evaluation System），作为贯穿本书的正面锚点。这五个 D 分别是：

1. Discriminative（可分辨） 2. Reproducible（可重复） 3. Production-correlated（生产强相关） 4. Economical（可负担） 5. Evolvable（可演化）

下面逐一展开。

1.4.1 可分辨（Discriminative）：能区分 5% 的差异

一个好的评测，要能在"两个相近版本"之间稳定地告诉团队：哪个更好。换句话说，评测的统计功效（statistical power）要够。

具体来说，当 A 版本比 B 版本在某个真实维度上好 5% 时，你的评测应该以较高概率（≥ 80%）给出"A 比 B 好"的结论，而不是"两者差不多"。这要求你的评测集有足够的样本量、有足够的难度梯度、指标的方差要小。

实操上，这意味着：

• **样本量**：对于大多数 NLG 任务，单一评测集至少 500—2000 条；对于高方差任务（如开放式对话），建议 2000—10000 条。
• **难度梯度**：评测集不能全是"模型都会的简单题"，要有 20—30% 的"困难样本"——否则所有模型都打高分，区分度为零。
• **置信区间**：跑评测时不要只报"均值"，要报均值 ± 标准差。95% 置信区间。如果两个版本的置信区间重叠，结论就是"不可分辨"。

反例：很多团队的"内部评测集"是 200 条题目，且大部分是从公开数据集抄的。结果是所有模型都打 90+，谁也分不出谁好谁坏。这种评测是"看上去做了，其实没用"。

1.4.2 可重复（Reproducible）：另一位工程师一周内能复现

可重复是科学评测的底线。它意味着：给定相同的模型、相同的数据、相同的代码，任何人在任何时间跑出相同的结果。

在传统 ML 里，可重复相对容易（固定 seed 就行）。但在大模型时代，可重复变得困难，原因有三：

• **采样随机性**：模型的输出依赖 temperature、top_p、seed。即使 seed 固定，不同推理框架的随机数实现可能不同。
• **Prompt 敏感性**：微小的 prompt 改动（如多加一个空格）可能让结果差几个点。
• **版本依赖**：模型权重、tokenizer、推理引擎版本、GPU 驱动都可能导致输出差异。

实操上，这意味着：

• **锁定所有随机种子**——推理端的 seed、tokenizer 的 seed、sampling 的 seed。
• **记录 prompt 模板的 hash**——避免"我以为我们用的是同一个 prompt"。
• **版本化一切**——数据集版本、模型版本、代码版本、依赖版本。推荐用 DVC 或类似工具做数据版本管理。
• **CI 集成**——评测脚本要进 CI，每次 PR 自动跑。如果跑不出来，PR 不能合并。

反例：某团队发现"上周跑出 78.4%，这周跑出 76.1%"，排查了三天发现是 GPU 驱动升级导致的。这种事在很多团队发生过。

1.4.3 生产强相关（Production-correlated）：评测涨，生产跟涨

这是 5D 中最重要、也最难的一个。它要求：你的离线评测分数和生产指标有显著的正相关。

也就是说，当你的评测分数涨 5% 时，你的生产指标（CTR、转化率、CSAT、留存率……）也应该涨——方向一致、量级大致相当。

这件事为什么难？因为评测和生产之间隔着好几层"翻译损失"：

• **数据损失**：评测集是采样的快照，生产是流动的河流。
• **任务损失**：评测问的是"A 与 B 哪个好"，生产问的是"用户愿不愿意点击"。
• **行为损失**：用户行为不仅取决于模型输出，还取决于 UI、文案、时机。
• **时间损失**：评测是即时打分，生产指标是滞后（留存要看 30 天）。

实操上，这意味着：

• **持续做"校准"**：每月取一组评测集预测 vs 生产指标真实值，算相关系数（Pearson、Spear