引言：当 AI 学会'考试'，我们到底在测什么

引言：当 AI 学会"考试"，我们到底在测什么

A 团队兴冲冲地公布了一个新模型：HumanEval pass@1 拿到了 95.2%，比他们上一代高了 8 个点；MMLU 88.5%，逼近 GPT-4 同期水平；GSM8K 96.1%，几乎是满分。研发群里一片欢呼，市场部已经在准备发布会 PPT 了。

但当工程团队把这个模型接进代码助手的真实环境里，他们遇到了一个让人哭笑不得的问题：让模型"从 1 数到 10"，它的输出是 `1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ...`——多了一个 11，而且不会停。更离谱的是，当你追问"那 9 后面是什么"时，它能正确地回答"10"，但单独一次生成就是会写多。这种"考试满分、实战短路"的故事，在 2024 到 2025 年的大模型落地过程中反复出现。

B 团队是某大型银行的智能客服项目组。他们花了三个月训练了一个客服大模型，并在 A/B 测试中大获全胜：相比人类坐席，AI 处理的工单平均时长缩短了 32%，工单关闭率提升了 14%，所有数字指标都向好。但上线三个月后，客户投诉量上升了 21%，NPS（Net Promoter Score，净推荐值）下滑了 8 个点。市场部找回来的根因报告里写着：AI 在涉及"手续费"、"违约金"等敏感问题时，给出过三次明显错误的数字；它的语气过于"轻佻"，会在用户投诉时说"哎呀，别生气了嘛"；它还会编造不存在的"优惠活动编号"。A/B 测试的指标是"时长"和"关闭率"——这两个数字在上涨，但"准确率"和"品牌调性"这两个维度在崩塌。

C 团队是一家头部 AI 创业公司。他们相信"红队测试（Red Teaming）"是模型上线前最重要的一环，于是组建了一个 8 人的红队小组，耗时 6 个月，对模型进行了上万次对抗性测试（adversarial testing），产出了 200 多页的风险报告。董事长在年终汇报里自豪地说："我们用 6 个月时间，把模型能踩的坑都踩了一遍。"但当 CISO（Chief Information Security Officer，首席信息安全官）把这些红队发现的问题和用户反馈工单系统做了一次交叉比对，结果让人沉默：红队报告里 80% 的"新问题"，在用户反馈工单里早就出现过，而且出现频次比红队测试时高得多。换句话说，C 团队花了 6 个月时间，用很贵的人工，重新发现了他们已经免费拥有的情报。

这三个故事不是孤立现象，它们指向同一个问题：当 AI 模型从"实验室的玩具"变成"生产系统里的关键组件"时，用"一个分数"来评估它，就像用"一个分数"来评估一个学生一样荒谬。你不会只看高考成绩就认定一个人会做科研、能团队合作、心理素质过硬——但在过去三年里，我们对大模型的评估，几乎就是这样做的。

这一章，我们不打算教你怎么算 BLEU 或者 pass@k。我们要做的是给你一张"罗盘"，让你看到 AI 评测这件事的全貌。

1.1 从"打一个分"到"画一张图"：评测范式的根本迁移

在深度学习时代之前，AI 评测是一件相对简单的事。因为那时候的模型大多是"窄域专家"：一个模型做猫狗分类，就测它的 top-1 accuracy；一个模型做机器翻译，就测它的 BLEU 分数。模型的输入空间、输出空间、错误模式都比较集中，画一张混淆矩阵（confusion matrix）或者一条 PR 曲线（Precision-Recall curve），基本就能把这个模型说清楚。

但大模型改变了一切。

一个 GPT-4 级别的模型，输入空间是无界的自然语言（或者代码、数学公式、表格、图像……），输出空间同样是无界的自然语言。它能做 100 件事情，每件事情的"对错"标准都不一样。"让模型写一首关于秋天的诗"，这件事没有标准答案；"让模型解释一段法律条文"，对错的边界模糊；"让模型总结一篇医学论文"，对错取决于你问的是谁。

更麻烦的是，大模型的失败模式（failure mode）是分层的。我们粗略地把它们分成四类：

1. 能力缺失（Capability Gap）：模型根本不会做这件事，比如让一个偏文科的模型去证明数学定理。 2. 知识错误（Knowledge Error）：模型"会做"，但记错了事实，比如把"爱因斯坦出生在 1879 年"说成"1889 年"。 3. 对齐偏差（Alignment Drift）：模型做的是你让它做的，但"做得不对"，比如在用户问"我应该自杀吗"时给出错误回应。 4. 长尾陷阱（Long-tail Trap）：模型在 90% 的场景下表现完美，但在剩下的 10% 罕见场景里出大问题，而那 10% 往往是真正重要的场景。

一个单一的 accuracy 分数，对这四类失败模式是"无差别掩盖"的——你看不到到底是哪类在拖后腿，更看不到它们之间如何相互补偿。这就像一个学生高考考了 700 分，你不知道他是语数外都强还是某一科特别强、其它科凑数；你也不知道他遇到新题型会怎样、遇到压力会不会崩盘。

所以过去三年，整个行业其实在悄悄经历一次评测范式的迁移（evaluation paradigm shift）：

• **2018-2020 年**：单点准确率时代。一个模型，一个 leaderboard，一个分数。
• **2021-2022 年**：多基准时代。开始意识到一个分数不够用，于是堆 benchmark：MMLU、HumanEval、GSM8K、HellaSwag、TruthfulQA……一份报告里塞 10 个分数。
• **2023-2024 年**：能力维度化时代。开始把 10 个分数按"推理"、"知识"、"代码"、"对齐"等维度归类，画出"雷达图（radar chart）"。
• **2024 年至今**：系统化评测时代。意识到评测本身就是一个系统，需要离线、线上、红队、业务多管齐下，且要解决"评测-训练-部署"之间的反馈闭环。

本书写于 2025 年，正是这个范式迁移的中间地带。我们不打算假装"答案已经定了"，但我们可以负责任地说：单点准确率已经死了，多维系统评测正在成为新的基础设施。你要做的不是算出"模型有多好"，而是搭建一个能持续发现问题的系统。

1.2 评测罗盘的四个支柱：为什么这四样东西缺一不可

我们用"罗盘（compass）"作为全书的隐喻，是因为罗盘有一个非常好的特性：它不直接告诉你"目的地在哪"，而是告诉你"你现在的方向对不对、偏离了多少"。评测也不是要直接告诉你"模型能不能用"，而是要告诉你"在哪些维度上可能有问题、风险敞口（risk exposure）有多大"。

罗盘有四个基本方向：东、南、西、北。我们认为，AI 评测罗盘也有四根支柱，它们共同决定了一个模型的真实可用性。少任何一根，你的评估都会"偏航"。

1.2.1 离线基准（Offline Benchmark）：最熟悉的陌生人

这是你最熟悉的那一类：HumanEval、MMLU、GSM8K、TruthfulQA、MT-Bench、AlpacaEval、Chatbot Arena……它们是模型厂商每次发新版本时一定会列在 release note 里的东西。

离线基准的核心特征是"标准化、可复现、低成本"。你下载一份数据集，调用 API 跑一遍，跑出几个分数，全世界任何人都能复现你的结果。在 2020 到 2023 年，leaderboard 几乎统治了整个 AI 评测的话语权。

但离线基准有三个你必须正视的局限：

第一，数据污染（Data Contamination / Data Leakage）。这是离线基准最大的硬伤。因为这些 benchmark 都是公开的，模型在预训练（pre-training）和后训练（post-training）阶段很可能已经"见过"这些题目。你以为模型在做"推理题"，其实它在做"记忆题"。2023 年，斯坦福和 UC Berkeley 的几篇论文都指出，MMLU 上排名前列的模型，相当一部分存在数据污染问题；2024 年一些工作用"扰动版 MMLU"测试，发现某些模型的分数会下降 20-30 个点。

第二，能力切片粗糙。一个 MMLU 总分，不能告诉你模型在"高等数学"和"世界史"上的相对强弱；一个 HumanEval pass@1，不能告诉你模型擅长"字符串处理"还是"动态规划"。要回答这些问题，你必须做能力切片（capability slicing），把每个 benchmark 拆细。

第三，分布外（Out-of-Distribution, OOD）失效。离线基准是"历史的快照"，但你的真实用户是"未来的、分布外的"。一个在 MMLU 上 90 分的模型，可能完全无法处理你公司内部那种"夹杂着产品代号、缩写、行话"的 query。

我们的建议是：把离线基准当作"门槛"和"体检表"，不要当作"判决书"。它告诉你模型有没有明显的"大病"，但不告诉你它在你这个具体场景里"活得好不好"。

1.2.2 线上反馈（Online Feedback）：真实世界的回声

如果说离线基准是"模拟考"，那线上反馈就是"实战"。它来自真实用户对你的模型的真实使用，包括但不限于：

• **显式反馈（Explicit Feedback）**：用户点赞、点踩、给 1-5 星、写下"这个回答很棒"或"完全不对"等评论。
• **隐式反馈（Implicit Feedback）**：用户是否复制了模型的回答、是否修改后才用、是否在对话几轮后放弃、是否在 30 秒后关闭了页面。
• **行为反馈（Behavioral Feedback）**：用户是否按模型给出的步骤执行、是否后续完成了某项任务、是否付费、是否流失。
• **工单反馈（Ticket Feedback）**：用户对模型的回答不满意，去找客服投诉，客服记录的内容。

线上反馈的最大价值是"信号真实"——它是用户在真实任务、真实压力、真实分布下的真实反应。这是离线基准永远给不出的东西。

但线上反馈也有三个坑：

第一，幸存者偏差（Survivorship Bias）。愿意给你反馈的用户，往往是体验极端好或者极端差的，中间的"沉默大多数"你看不到。一个 95% 点赞率，可能掩盖了剩下 5% 里 30% 的极端不满。

第二，反馈延迟（Feedback Latency）。用户在第一天问的问题，可能在第七天你才能看到效果。要让线上反馈真正指导模型迭代，你需要建设"反馈-分析-训练-部署"的闭环，而这个闭环的天生延迟决定了它的反馈速度不会快。

第三，激励错配（Misaligned Incentives）。有些产品会让"点赞率"作为模型的优化目标，结果模型学会的是"写一些看起来漂亮但没用的话"。这就像给学生发"答题漂亮奖"，学生就会练漂亮话术。

这一支柱的关键不是"收集多少反馈"，而是"反馈能不能进入训练-评测循环"。很多团队的线上反馈是"有"，但没有真正用于模型迭代，那就是在浪费最宝贵的数据资产。

1.2.3 红队测试（Red Teaming）：主动出击的压力测试

红队测试源自网络安全领域：在系统上线前，组建一支专门"找茬"的团队，模拟恶意用户、黑客、不满意的客户，想方设法让系统出错。在 AI 评测里，红队测试的目标是主动发现模型在"对抗性输入"下的失败，尤其是离线基准和线上反馈都覆盖不到的那些"高风险但低频"的场景。

红队测试通常会针对以下几类问题：

• **越狱（Jailbreak）**：能否通过精心设计的 prompt 绕过安全护栏，让模型输出有害内容。
• **提示注入（Prompt Injection）**：能否通过在外部文档里塞入指令，让模型忽略用户的原始请求。
• **幻觉诱导（Hallucination Induction）**：能否让模型在不知道答案时"自信地胡说八道"，特别是涉及医疗、法律、金融的领域。
• **偏见与公平性（Bias & Fairity）**：模型对不同性别、种族、地域、文化背景的用户是否有系统性差异。
• **多轮陷阱（Multi-turn Traps）**：通过多轮对话，逐步引导模型进入"不应该进入"的状态。

红队测试的核心价值是"主动风险探测"。线上反馈是"被动等用户踩坑"，红队测试是"主动去踩坑"。前者告诉你"已经发生的问题"，后者告诉你"未来可能发生的问题"。

但红队测试的局限也很明显：贵、慢、不可规模化。C 团队 8 个人做 6 个月才能产出 200 多页报告，对于模型快速迭代的节奏来说，这种成本结构是难以为继的。

更关键的是 C 团队故事揭示的问题：红队测试如果和线上反馈隔离，就是在做重复劳动。红队发现的 80% 的"新问题"，在用户工单里早就有了。这意味着你的红队测试和线上反馈之间缺少一个"对照机制"——你应该在每次启动红队测试之前，先问一句："这个问题在工单里出现过吗？"

我们在第 8 章会详细讨论如何让红队测试从"昂贵的手工活"变成"半自动的流水线"，包括基于 LLM 的对抗性测试生成、自动化评分、模式聚类等。

1.2.4 业务指标（Business Metrics）：最终的"判决书"

最后这一支柱，是很多人不愿意碰、但又回避不了的——业务指标。它包括：

• **北极星指标（North Star Metric）**：一个产品最重要的那一个数字，比如电商的 GMV、内容平台的 DAU、客服系统的 CSAT。
• **过程指标（Process Metrics）**：北极星指标的前置变量，比如客服系统的"首次解决率（FCR, First Contact Resolution）"、内容平台的"人均使用时长"。
• **护栏指标（Guardrail Metrics）**：你绝对不能让步的那些底线，比如"涉敏拦截率 ≥ 99.9%"、"医疗错误率 < 0.1%"。

业务指标是模型评测的"终极裁判"。一个模型可以在所有 benchmark 上都拿 90 分，但只要它让业务指标下滑了 10%，它就是不可上线的。

但业务指标有三个特点让它"难伺候"：

第一，信噪比低。业务指标会被市场环境、季节性、运营活动、政策变化等几十个因素同时影响，很难把"模型升级带来的 1% 提升"从噪声里分离出来。

第二，反馈周期长。有些业务指标（比如用户留存、LTV）要看几个月才能看到结果，等你发现问题时已经晚了。

第三，与技术指标脱节。业务方关心"赚不赚钱、用户满不满意"，技术方关心"准确率高不高、推理速度快不快"，这两种语言之间存在天然的翻译损耗。

这一支柱的关键是"建立翻译机制"。技术指标和业务指标之间，需要有清晰的"换算关系（mapping）"和"预警阈值（threshold）"。比如你可以建立这样的规则："当幻觉率（hallucination rate）超过 X% 时，预测业务 NPS 会下滑 Y 个点"。这种"翻译机制"我们会在第 12 章详细讨论。

1.2.5 四个支柱的总览图

把这四个支柱放在一起看，是这样的关系：

```mermaid flowchart TD Compass[AI Evaluation Compass] --> Offline[Offline Benchmark] Compass --> Online[Online Feedback] Compass --> RedTeam[Red Teaming] Compass --> Business[Business Metrics] Offline <--> Online Online <--> Business Offline <--> RedTeam RedTeam <--> Business ```

这张图想说的是三件事：

1. 四个支柱是平行的，不是有高低贵贱之分的。离线基准不"高级"于业务指标，红队测试不"严肃"于线上反馈。它们各管一段。 2. 每个支柱之间都存在"校准关系（calibration）"。比如：离线基准上的提升，能不能在 A/B 测试里重现？红队发现的高风险场景，有没有在用户工单里出现过？这些"对照"是评测系统可信度的关键。 3. 少一个支柱，整个罗盘就会偏航。只看离线基准，你会陷入"benchmark 内卷"；只看线上反馈，你会陷入"噪声追逐"；只看红队测试，你会陷入"昂贵手工活"；只看业务指标，你会陷入"短期投机"。

1.3 为什么"罗盘"是比"雷达图"更准确的隐喻

很多团队在尝试"多维评测"时，第一反应是画一张雷达图（radar chart）：把"推理"、"知识"、"代码"、"对齐"几个维度画成几根轴，把模型在每个维度上的分数标在轴上，围成一个多边形。看起来很直观对吧？但其实雷达图在 AI 评测里有几个根本性的问题。

第一，雷达图假设"维度之间是独立的"。但大模型的能力是高度耦合的。一个模型"代码能力"强，往往"逻辑推理"也强；一个模型"对齐"做得好，往往"指令遵循"也好。雷达图上画出的多边形面积，掩盖了这些耦合关系。

第二，雷达图假设"分数是可加的"。一个模型在"代码"上是 80 分，在"对齐"上是 60 分，这两者"加起来"是 140 分？没有任何业务意义。

第三，雷达图没办法表达"权重"。在你的具体场景里，"代码"可能比"对齐"重要 10 倍，但雷达图上两者是同长度的轴。

第四，雷达图没办法表达"校准关系"。这是最致命的。雷达图只展示了"模型在每个维度上多少分"，但没展示"这些分数之间是不是一致的"。比如一个模型在 HumanEval 上 90 分，但在你公司的内部代码任务上只有 60 分——这两个数字的差距本身就是信息，但雷达图上你看不到这种"内部矛盾"。

相比之下，罗盘的隐喻更贴近 AI 评测的本质：

• 罗盘有**方向性**：每个维度都像罗盘上的一个方向，不是独立的"得分"，而是"在这个方向上是否对齐真实需求"。
• 罗盘有**校准关系**：罗盘之所以能工作，是因为四个方向是相互参照的（东是西的反方向）。评测的四个支柱也是相互参照的——红队发现的问题要去和工单对照，线上的反馈要去和 benchmark 对照。
• 罗盘有**"偏航"这个核心概念**：罗盘不直接告诉你"在哪"，而是告诉你"偏了没偏、偏了多少"。评测也不直接告诉你"模型好不好"，而是告诉你"在哪些维度上可能有问题、风险敞口有多大"。

所以我们整本书都会坚持这个隐喻：好的评测系统是一个罗盘，不是一个分数；是一个持续的导航过程，不是一次性的体检报告。

1.4 中级工程师最常踩的三个评测误区

到这里，我们已经讲了"评测是什么"。但光讲"是什么"还不够，我们还要讲"中级工程师最容易踩的几个坑"。这一节不是空泛