评测的工程学：从直觉判断到可测量的智能 / The Engineering of Evaluation: From Intuition to Measurable Intelligence

第 1 章　评测的工程学：从直觉判断到可测量的智能

> The Engineering of Evaluation: From Intuition to Measurable Intelligence

在工程语境下，"评估一个 AI 系统"究竟意味着什么？

当你说"这个大模型表现得不错"——你指的是什么？当 PM 拒绝合并某次模型更新——你的判断依据是什么？当业务方问"它和上个月比变好了还是变差了"——你打算如何回答？

如果你的答案停留在"我看了几个 case 感觉还行"、"榜单分数涨了两个点"、"用户没怎么投诉"——那说明你的评测体系还停留在直觉层面。这不是批评，而是 2025 年绝大多数团队的现状。本章要回答的核心问题是：为什么 AI 评测必须从"感觉"走向"系统"？以及，一套真正可工程化的评测体系应该长成什么样？

我们将剖析三个最常见的误区（每个误区都付出了真实代价），建立评测工程四层模型，引入评测金字塔这个核心心智模型，提出评测成熟度模型（EMM）五级量表，最后通过头部实验室 system cards 的逆向工程分析，让你看到顶级团队实际在用什么方法论。

---

1.1　AI 评测的三大常见误区与代价分析

在讲"应该怎么做"之前，必须先看清"正在做错什么"。以下三个误区在 2023—2025 年反复出现，几乎每一个失败案例的复盘都能归因到其中之一或多个。

1.1.1 误区一：把 benchmark 当 KPI

许多团队直接把 MMLU、HELM、HumanEval、MATH、BBH、IFEval 等公开榜单上的分数作为模型的 KPI。这种做法在 2023 年的模型选型阶段可能还能勉强工作，但在 2025 年之后，它已经系统性地失效。

理由有三：

第一，榜单污染（benchmark contamination）。公开 benchmark 的题目在训练语料中可能早已被模型见过。2024 年 GPT-4o、Claude 3.5、Gemini 1.5 Pro 都出现过"刷分"嫌疑——在公开榜上表现接近人类专家，但换一组相似分布的数据立即现原形。这不是阴谋论，而是语言模型过拟合到 benchmark 分布本身的统计学结果。多个第三方研究（如 GSM-Symbolic、MATH-Plus）已经证实了这个现象：当题目被改写或换数字后，榜单分数会显著下滑。

第二，指标与业务目标错位。MMLU 衡量的是学科选择题知识，HumanEval 衡量的是 Python 函数补全能力。一个客服场景的 AI 助手的真实价值取决于"是否能在不激怒用户的前提下解决 80% 的高频问题"——这跟 HumanEval 分数的相关性极弱。把前者当 KPI，相当于用跑步机测试来选拔游泳运动员。

第三，Goodhart's Law（古德哈特定律）。一旦某个指标成为目标，它就不再是好指标。当团队把"提 MMLU"作为研发方向，所有人都会去做提分相关的优化（提示工程、模型混合、检索增强），最终结果是榜单上的数字变得好看，但业务实际收益边际递减甚至变负。

真实代价：某头部金融科技公司在 2024 年初上线了一个"在 HumanEval 上得分最高的开源代码模型"作为内部代码助手，运行三个月后，开发者满意度从预期的 80% 跌到 54%。原因并非模型"不能写代码"，而是因为该模型对企业内部 API、业务规则、版本约束一无所知。复盘报告里有一句经典总结："我们优化了一个跟业务无关的指标。"——这就是把 benchmark 当 KPI 的代价。

1.1.2 误区二：把 demo 通过当能力

第二个误区是把"演示通过"当成"能力达标"。在 demo 场景下，工程师精心挑选 5—10 个 case，模型回答得不错，看起来"很智能"。但 demo 通过跟系统级能力之间，隔着统计学的整个世界。

这是工程学与演示学的根本区别：

• 演示关心单次成功（one-shot success）；
• 工程关心分布（distribution）；
• 演示关心平均；
• 工程关心尾部（long-tail failure）、最坏情况（worst-case）、边界（boundary）。

一个模型在 1000 个 case 里 999 个表现完美，跟在 10 个 case 里 9 个表现完美，是完全不同的工程意义。前者意味着系统级可用，后者只是运气。没有置信区间（confidence interval）的准确率都是耍流氓。

更隐蔽的是 cherry-picking（挑选）。任何熟练的提示工程师都能在半小时内为一个中等模型写出几十个"看起来很惊艳"的 prompt。但这种演示既不可重复（换 prompt 就跑偏），也不可泛化（换一个领域就失效）。把它当作能力证据，等同于在医学试验里只展示成功案例、不展示失败案例。

真实代价：2023 年底某消费 AI 公司在产品发布前做了 6 次 demo 都完美，上线后第一周出现大规模"幻觉"事件，被迫 48 小时内下线。事后根因分析显示，demo 用的数据全部来自模型在训练集中见过的"高频模式"，而真实用户问的是长尾、低频、高歧义问题。该公司 CTO 在公开复盘时承认："我们犯了 demo 学而不是工程学的错误。"

1.1.3 误区三：把单次实验当结论

第三个误区是实验性错误。许多团队跑一次 A/B 测试，看到新模型胜出，就宣布"新模型更好"。这在统计学上是严重的错误，但在 AI 评测领域极其普遍。

为什么单次实验不可信：

第一，样本量不足。当你在生产环境评估一个 LLM 时，真实输入的分布非常长尾。你可能需要数千到数万个真实交互才能让置信区间收敛到工程可用的水平——例如 ±2% 的胜率窗口。

第二，抽样偏差。在生产环境做 A/B，新模型通常先分配给小流量、低风险用户，结果可能严重偏向乐观（因为这些用户的输入往往更"友好"）。

第三，没有统计检验。如果两组胜率差异在 2% 以内、置信区间重叠，正确的结论应该是"无法区分"，而不是"新模型更好"。许多团队在 95% 置信区间内做比较，却不做显著性检验。

第四，多重比较问题（multiple comparisons）。如果同时评测多个能力维度、多个用户群体、多个时间段，单纯看胜率会显著高估"赢家"——某些差异纯属随机。

真实代价：某 SaaS 公司 2024 年 Q3 跑了一次内部 A/B，结论是新模型胜出现模型胜率 8%。但因为没做显著性检验，研发团队投入三个月迁移。下一次完整重测时，新旧模型表现几乎无差异（差异在置信区间内）。三个月的人力成本归零。该团队事后在内部 wiki 写了一篇《我们从一次错误的 A/B 中学到了什么》，核心教训是："永远报告置信区间，永远报告 p-value，永远不要把单次实验当结论。"

1.1.4 三大误区的共同根源

这三大误区的共同根源是：用直觉的颗粒度做决策。

直觉的颗粒度意味着：我们用"感觉"代替"测量"，用"印象"代替"分布"，用"单次"代替"统计"。要打破这个循环，必须建立一套从指标到决策的可工程化评测体系。这就是下一节要展开的"评测工程四层模型"。

---

1.2　评测工程四层模型：指标 / 任务 / 信号 / 决策

把"评测"这个看似单一的动作，拆解成四个清晰分工的层次：

1. 指标层（Metric Layer）：我们要测的是什么？ 2. 任务层（Task Layer）：用什么场景测？ 3. 信号层（Signal Layer）：信号从哪里来？ 4. 决策层（Decision Layer）：测完怎么行动？

这四个层次不是平行的，而是有严格的依赖关系。底层出问题，上层永远不可信。

1.2.1 指标层：把"好"翻译成数字

指标层是整个评测体系的"度量衡"。一个合格的指标必须满足四个属性：

• **可解释性（Interpretability）**：业务方看一眼就知道"这意味着什么"。一个典型的反例是"embedding cosine similarity = 0.873"，业务方完全无法判断好坏。合格的正例是"客服问题解决率"——业务方立刻能判断 80% 是好还是不好。
• **可比性（Comparability）**：跨时间、跨模型、跨人群可比较。
• **可重复性（Reproducibility）**：同样的输入，同样的输出，误差在可接受范围。
• **对齐性（Alignment）**：与真实业务目标对齐（详见后文"代理指标与因果指标"）。

指标的常见分类：

| 类别 | 例子 | 适用场景 | |---|---|---| | 准确性指标 | 准确率、F1、Pass@K | 闭卷任务 | | 质量指标 | 流畅度、相关性、忠实度 | 开放式任务 | | 安全性指标 | 越狱成功率、有害率 | 安全敏感场景 | | 效率指标 | P50 延迟、Tokens/s、$/千次请求 | 工程化部署 | | 鲁棒性指标 | 对抗准确率下降幅度 | 可靠性敏感场景 |

关键判断：指标不是越多越好。真正成熟团队的指标体系通常在 20—50 个核心指标之间，并且有清晰的层级（5—10 个北极星指标、20—30 个支撑指标、若干探索性指标）。超过这个量级，几乎一定存在指标冗余和相互冲突。

代理指标与因果指标：所有可计算的指标本质上都只是业务结果的代理（proxy）。真正的因果指标往往不可测或不可低成本测。例如，我们测的"用户满意度评分"是"用户留存"的代理；我们测的"代码生成准确率"是"开发者生产力"的代理。成熟的指标体系会定期做"代理校准"——检验代理指标与因果指标的相关性是否仍然成立。一种常见做法是：在离线环境用代理指标排序，但在上线前必须做小流量 A/B 验证其与真实因果指标的一致性。

1.2.2 任务层：把"场景"切分成可测单元

任务层负责回答"用什么样本测"。常见的任务划分维度：

• **能力维度**：推理、生成、检索、规划、工具使用……
• **难度维度**：单步 vs. 多步、闭卷 vs. 开卷、单领域 vs. 跨领域
• **风险维度**：高风险（医疗、法律、金融）vs. 低风险（闲聊）
• **用户维度**：新手 vs. 专家、付费 vs. 免费

一个常见反模式是"用一套任务测所有模型"。这忽略了任务的代表性。任务集的构建需要遵循 覆盖度-难度-代表性三角：

• **覆盖度（Coverage）**：任务要能覆盖能力空间的主要区域。
• **难度（Difficulty）**：要包含足够难的样本（不能全是简单任务）。
• **代表性（Representativeness）**：要与真实生产分布对齐。

一个实操判断：如果你的评测任务集在某个能力维度上，模型 A、B、C 的得分差异小于 3%，那这个任务集在该维度上大概率缺乏足够难度梯度——需要补题。

另一个实操判断：任务集必须包含"对抗样本"。例如在客服场景，应包括带错别字、含敏感词、要求超出能力、超长输入等极端 case。没有对抗样本的任务集，无法暴露模型的真实弱点。

1.2.3 信号层：从哪里采集评测信号

信号层是评测体系的"数据来源"，也是最容易出问题的地方。常见的信号来源：

| 信号类型 | 来源 | 优点 | 缺点 | |---|---|---|---| | 离线标注 | 人工标注 / 专家标注 | 黄金标准 | 成本高、慢、有标注员偏差 | | 在线行为 | 用户点击、停留、转化 | 真实业务反馈 | 信号噪声大、归因复杂 | | LLM-as-judge | GPT-4 / Claude 评判 | 速度快、成本低 | 评分偏差、自偏好 | | 对抗攻击 | 红队 / 越狱测试 | 边界覆盖 | 样本有限 | | 对照实验 | A/B 测试 | 统计严谨 | 周期长、流量成本 |

关键判断：任何单一信号都不可信，必须多源三角验证。

LLM-as-judge 的常见偏差（这是 2024 年最被低估的工程问题）：

1. 位置偏差（Position bias）：倾向于选第一个或最后一个候选。 2. 长度偏差（Length bias）：倾向于选更长的。 3. 自偏好偏差（Self-preference）：用 GPT-4 评判 GPT-4 输出会偏高。 4. 锚定偏差（Anchoring bias）：参考标准答案会偏向参考答案。 5. 风格偏差（Style bias）：偏向某种文风（如 Markdown、加粗、表情符号）。 6. 知识偏差（Knowledge bias）：倾向于奖励"看起来自信"的回答，即使事实错误。

成熟的 LLM-as-judge 体系需要做偏差审计（bias audit），通常做法是混入已知答案的人类标注样本做对照。Anthropic、OpenAI、Google DeepMind 在他们的 system cards 里都公开承认并部分披露了这些偏差的处理方法。

1.2.4 决策层：指标如何驱动行动

最容易被忽视的层次。评测的最终目的不是"得到一个数字"，而是"驱动更好的决策"。常见的决策类型：

• **上线决策（Release Decision）**：是否发布新版本？
• **回滚决策（Rollback Decision）**：是否回滚到上一个版本？
• **优先级决策（Priority Decision）**：下一个迭代周期优化什么？
• **风险决策（Risk Decision）**：某个能力是否需要加固？
• **资源决策（Resource Decision）**：预算如何在各能力间分配？

决策层的工程化关键：

• **预注册的决策规则**：事先规定"如果指标 A 下降超过 X%，自动回滚"。而不是事后讨论。
• **决策阈值（Decision Threshold）**：每个核心指标都应有明确的"决策阈值"，例如"客服解决率 < 75% 时禁止发布"。
• **决策延迟（Decision Latency）**：从数据采集到决策的时间间隔必须足够短。延迟超过迭代周期，决策就失去价值。
• **决策回溯（Decision Retrospect）**：定期回顾"过去 90 天的决策记录"，验证当时决策的依据是否仍然成立。

真实案例：Anthropic 在其 Responsible Scaling Policy 中明确规定了"Capability Thresholds"（能力阈值）。例如当某个模型在生物风险评估上达到特定水平，就触发额外的安全评估和访问限制。这种将决策规则化、阈值化、预注册化的做法，就是决策层工程化的典型实践。

1.2.5 四个层次的整体关系

| 层次 | 输入 | 输出 | 典型失败模式 | |---|---|---|---| | 指标层 | 业务目标 | 可解释的数字 | 指标错位 | | 任务层 | 指标定义 | 标准化任务集 | 任务失代表 | | 信号层 | 任务定义 | 评测数据 | 信号噪声 | | 决策层 | 信号聚合 | 行动建议 | 决策脱节 |

当一个评测结果"看着不对劲"，工程师应该从底层往上排查：先看信号源（是不是采样偏差）、再看任务（是不是任务太简单）、再看指标（是不是指标定义错了）、最后看决策（是不是决策规则没被执行）。永远不要在没排查完四层之前下结论。

---

1.3　评测金字塔：从单元测试到端到端验证

软件工程里最经典的智力资产之一是"测试金字塔"——单元测试、集成测试、端到端测试构成的层级结构。这个模型可以直接迁移到 AI 评测。

1.3.1 第一层：能力单元测试（Capability Unit Tests）

对应到 AI 评测，单元测试是 能力单元测试。它的目的是验证"模型在单能力点上的表现"。

例子：

• 单元测试 1：模型是否能在看到 "2+3" 时回答 "5"？
• 单元测试 2：模型能否正确翻译 "Hello" 到中文？
• 单元测试 3：模型能否在单次回复中遵循 system prompt 里的格式约束？

关键特征：

• 输入可控、可重复
• 输出可对照标准答案
• 评估速度快、成本低（通常 < 1 秒/case）
• 在开发/CI 阶段运行

在评测工程中的作用：作为"能力下限"的最快过滤器。一个模型如果连单元测试都跑不过，根本不需要进入集成测试。

1.3.2 第二层：技能链测试（Skill Chain Tests）

能力单元测试只覆盖了"原子能力"，但真实场景需要组合多种能力。集成测试对应 技能链测试。

例子：

• 集成测试 1：模型能否在多轮对话中保持人物一致性？
• 集成测试 2：模型能否在长上下文（128K tokens）中检索关键信息？
• 集成测试 3：模型能否在调用工具后正确解析返回结果？

关键特征：

• 多能力组合
• 中等复杂度
• 需要更复杂的评分标准（通常需要 LLM-as-judge + 人工 spot-check）
• 覆盖真实业务场景的关键路径

一个实操经验：技能链测试最容易出现的错误是"能力相互抵消"——某两个能力各测都是 95%，但组合起来反而下降到 70%。这是因为集成场景暴露了能力之间的相互作用（interaction effects），而单元测试看不到。

1.3.3 第三层：行为漂移检测（Behavior Drift Detection）

在持续集成/持续部署（CI/CD）体系中，回归测试的核心目的是"确保改动不会破坏已有功能"。对应到 AI，回归测试对应 行为漂移检测。

关键问题：当一个模型经过再训练、fine-tuning、prompt 调整后，它在历史任务集上的表现是否保持稳定？

典型场景：

• 同一个 prompt 模板，新模型与基线模型的胜率
• 在历史生产 query 集上的胜率衰减
• 关键能力的退化（如推理能力下降但流畅度上升）

一个工程实践：建立"行为黄金集"（Behavioral Golden Set）——一组经过精心设计的、固定不变的任务集，每次模型更新都跑一遍。如果行为黄金集上的胜率下降超过阈值，则触发警报。这套黄金集应包含至少 200—500 个高质量样本，覆盖主要能力维度。

1.3.4 第四层：端到端真实业务验证（End-to-End Business Verification）

最高层级是端到端测试，对应 真实业务验证。

例子：

• 整个客服对话从用户提问到问题解决的完整链路
• 整个代码助手从需求理解到代码提交的完整链路
• 整个搜索-回答链路从用户输入到最终