审判的开场：为什么AI需要被持续验证 | The Trial Begins: Why AI Demands Continuous Verification
第 1 章 审判的开场：为什么 AI 需要被持续验证
> "The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function." > — F. Scott Fitzgerald
1.1 一场没有被告席的审判
2018 年 10 月的一个深夜,Google Research 的工程师们在内部 Slack 频道里贴出了一张截图:他们的新模型在 GLUE(General Language Understanding Evaluation)基准上以 87.6 分的成绩登顶,击败了此前的所有对手——其中包括被视为 NLP 领域「珠穆朗玛峰」的 BERT-Large。截图的下方是一片欢呼的 emoji,有人甚至开了一瓶香槟。
但仅仅三个月之后,在一次产线复盘会上,同一个团队的产品负责人指着用户调研报告里的一条评论,声音有些发紧:"它答非所问。"这条评论的原文更长一些,大意是:用户输入了一个关于家庭医疗设备使用的具体问题,搜索引擎顶部的 AI 生成摘要(Snippet)却回了一段关于美国医疗体系改革的宏观论述。模型在 GLUE 上是天才,在用户面前却像个走错了片场的演员。
这不是一个孤立事件。在接下来的 18 个月里,这种「离线冠军、线上哑火」的故事在每一家头部 AI 实验室的内部复盘会上反复上演。Microsoft 的 Turing-NLG 在 SuperGLUE 上拿过世界第一,但上线 Bing Chat 时也曾因「过度迎合用户」而闹出令人啼笑皆非的笑话;Meta 的 Llama-2 在 MMLU 上以 70% 以上的准确率横扫榜单,但在实际的 Reels 推荐场景中,工程师发现它的嵌入向量和用户停留时长之间的相关性只有 0.12,远低于早期 BERT 时代的 0.41。
这些故事共同指向一个让整个行业不得不正视的命题:AI 系统的评估,从来不是一个可以在发布前打勾完成的「质检环节」,而是一条必须贯穿整个产品生命周期的、持续的、可被审计的工程实践。
这正是本书第 1 章想要回答的核心问题:为什么传统软件工程的测试方法在 AI 系统上会失灵?为什么「测试通过」永远不等于「用户满意」?以及,当我们承认这一点之后,究竟应该用什么样的框架来重新组织 AI 产品的评估实践?
让我们从一个具体的反直觉案例开始。
---
1.2 案例复盘:3 个点的 F1,7 个点的点击率之谜
2021 年下半年,某国内头部搜索引擎公司(为保护当事人,本书将之称为「Nova 搜索」)的 NLP 团队启动了一次看似常规的模型升级。他们的目标很明确:把页面中实体识别(Named Entity Recognition, NER)模块的 F1 值从 92.3% 提升到 95% 以上。当时的内部基准已经陷入瓶颈,Baseline BERT-Base 在 92.3% 这个数字上停留了将近八个月,任何细微的改动都会带来回退。
团队从清华开源的 MacBERT 出发,做了若干工程上的精修:更细致的实体词典、对长尾实体(尤其是医学、法律、游戏专有名词)的过采样、引入对比学习(Contrastive Learning)来拉大正负样本之间的距离。经过六周的迭代,内部测试集的 F1 终于爬到了 95.6%。团队成员小李在庆功邮件里写了一句被后来无数次引用的话:"我们终于把这座山翻过去了。"
然而模型上线 A/B 测试的第七天,数据科学家老周在每周例会上拿出了一张让人脊背发凉的图表:首页整体点击率(CTR)下降了 7.2%。
这不是 95% 置信区间内的波动,这是断崖式下跌。
复盘花了整整三周。我们来还原一下这三周里他们究竟发现了什么。
第一步:拆分指标
老周的第一步动作不是去回滚模型,而是把 CTR 下降按照查询意图类别进行拆分。搜索引擎的查询大致可以分为导航型(Navigational)、信息型(Informational)、交易型(Transactional)三类。在信息型查询中,CTR 下降了 4.1%;在交易型查询中,CTR 下降了 12.8%。
这意味着问题并不在所有地方,而是集中在「交易型」——也就是用户带着明确购买或决策意图而来的那部分流量。
第二步:对比新旧模型的输出
第二步,他们把新旧两个模型在同一批交易型查询上的 Top-10 搜索结果并排打印出来,逐条人工比对。一个典型的反例出现了:
> 查询:"iPhone 15 Pro 256G 京东自营 价格" > > 旧模型(BERT-Base, F1=92.3%):正确识别出"iPhone 15 Pro"为产品实体,"256G"为规格,"京东"为商家,返回的摘要片段直接给出价格和优惠。 > > 新模型(MacBERT-FT, F1=95.6%):把"京东"错误地识别为一个地名(实际上在某些文本中"京东"确实出现在"北京-东京"语境里),并把"iPhone 15 Pro"识别成了"科技资讯"类别。返回的摘要片段开始讨论"京东商城的发展史"。
F1 提升了 3.3 个百分点。但对于这个具体的查询,模型的输出从「精准命中」退化为「答非所问」。
第三步:挖掘 F1 指标本身的盲区
为什么会发生这种事?团队回查了 F1 指标的构成。他们发现问题出在「分母」上:内部测试集中包含大量「北京-京东」类的歧义样本,占比高达 38%。在这些样本上,MacBERT-FT 因为引入了更好的上下文建模,确实表现得更好——它学会了在「京东快递」「京东金融」里正确识别"京东"为商家,而在「北京-东京航线」里识别为地名。
但代价是:在「京东自营」这种关键词明确、上下文单一的交易型查询上,新模型因为过度敏感地激活了「消歧路径」,反而引入了噪声。
这是一个长尾问题——离线指标的提升,是被一类相对小众但容易出错的样本「拉」起来的;而线上的损伤,集中发生在另一类高频但低难度的样本上。F1 作为一个宏平均指标,完美地掩盖了这种结构性的失衡。
第四步:重新设计评估协议
复盘结束后,团队做了一件事:他们把测试集按照「查询意图 × 上下文歧义度」二维切分,变成了 12 个子集。每个子集都单独报告 F1、Precision、Recall,并且在 CI/CD(持续集成/持续部署)流水线里加了一个回归门控(Regression Gate):如果任何一个子集的 F1 下降超过 0.5 个百分点,模型自动被阻断,不允许进入 A/B 测试阶段。
三个月后,他们基于这套新的评估协议重新训练了模型。最终上线的版本在整体 F1 上「只」达到 94.1%,比之前那个"95.6% 冠军"低了 1.5 个点,但 CTR 反而提升了 3.8%。
老周后来在一次内部分享中说了一句被团队奉为圭臬的话:"我们以为自己在做模型升级,其实我们做的是评估升级。模型只是副产品。"
---
1.3 为什么传统软件测试在 AI 上失灵?
Nova 搜索的故事不是孤例,它背后是 AI 系统相对于传统软件在工程属性上的根本差异。理解这些差异,是建立新评估范式的前提。
1.3.1 假设一:「输入-输出确定性」的崩塌
传统软件工程(以 Java、Go、C++ 这类编译型语言,以及它们所构建的信息系统为代表)的核心假设,可以用一句话概括:对于给定的输入,只要执行环境和代码版本一致,输出就是确定性的(Deterministic)。
这个假设带来了一整套工程基础设施:
- **单元测试(Unit Test)**:给定输入 `x`,断言输出 `y`。
- **集成测试(Integration Test)**:测试模块之间的契约。
- **覆盖率(Coverage)**:统计代码路径被执行的百分比。
- **回归测试(Regression Test)**:确保新代码没有破坏旧行为。
这些工具之所以有效,是因为代码的语义是封闭的——它不依赖于运行时从数据中学到的统计规律。一段排序算法,只要实现正确,无论运行多少次,结果都是一致的。
AI 系统彻底打破了这一假设。我们来形式化地说明这件事。
设传统软件为函数 $f: \mathcal{X} \rightarrow \mathcal{Y}$,其中 $\mathcal{X}$ 是输入空间,$\mathcal{Y}$ 是输出空间。确定性意味着:
$$\forall x \in \mathcal{X}, f(x) = y, \text{且此关系由代码静态确定}$$
而 AI 系统(以监督学习中的分类器为例)则是从数据中拟合得到的函数 $\hat{f}_\theta: \mathcal{X} \rightarrow \mathcal{Y}$,其中 $\theta$ 是参数。模型的行为不仅由架构决定,还由训练数据 $\mathcal{D}$ 决定:
$$\hat{f}_\theta = \arg\min_{\theta} \mathbb{E}_{(x, y) \sim \mathcal{D}}[\mathcal{L}(\hat{f}_\theta(x), y)]$$
这就引入了三个传统软件不存在的随机性来源:
1. 数据分布漂移(Data Distribution Shift):训练数据 $\mathcal{D}_{\text{train}}$ 和线上数据 $\mathcal{D}_{\text{prod}}$ 的分布不一致,导致 $P_{\text{train}}(x) \neq P_{\text{prod}}(x)$。 2. 标注噪声(Label Noise):训练数据中的标签 $y$ 本身可能存在错误,使得学到的 $\hat{f}_\theta$ 在某些区域产生系统性偏差。 3. 模型不确定性(Model Uncertainty):对于同一个输入 $x$,不同的采样路径(如 Beam Search 的不同分支、Dropout 开启时的多次前向传播)可能产生不同输出。
这意味着 AI 系统的「正确性」是一个概率命题,而不是一个布尔命题。我们无法用「断言 `output == expected`」的方式来测试一个 LLM 的回答是否「正确」,因为「正确」本身就是一个需要被定义的、有多种合法解的概念。
1.3.2 假设二:「测试即验证」的失效
传统软件工程的另一条金科玉律是:测试通过 ⇒ 代码正确。这里的「正确」由规约(Specification)定义,而规约由人类工程师书写。
AI 系统的规约从哪里来?这是一个根本性的难题。
- 在分类任务中,规约来自标注数据。但标注数据本身是**不完美的**——它可能包含主观判断(什么是「合适」的推荐?)、文化偏见(什么是「冒犯性」内容?)、时效偏差(什么是「今天」的事实?)。BERT 在 2018 年训练时,它「知道」的事实到 2024 年可能已经过时。
- 在生成任务中,规约甚至**无法被完整列出**。一个开放式对话系统,合理的回复可能有无穷多种;而「不合适」的回复也有无穷多种。你无法为它写一份穷尽的 Spec。
这就导致了「测试即验证」假设的崩塌。在 AI 系统中:
- **离线测试通过**只意味着模型在测试集上表现良好,但测试集是真实世界的一个**有偏采样**。
- **在线指标良好**只意味着模型在当前的流量结构、用户群体、内容生态下表现良好,这些条件一旦变化,表现就可能崩溃。
- **没有「最终正确」这一状态**,只有「在当前评估协议下可接受」这一状态。
1.3.3 假设三:「行为可复现」的边界
传统软件的另一个隐性假设是:同样的输入,在同样的环境下,产生同样的输出。这使得 Bug 报告(Issue Reproduction)成为可能——QA 工程师可以截取一段请求,本地复现,然后定位问题。
AI 系统在两个层面上挑战这一假设:
1. 数值层面的非完全可复现性:GPU 的浮点运算顺序可能因硬件、驱动版本、Batch Size 的不同而产生微小差异;Tokenizer 的实现可能因版本而异(尤其是多语言场景下)。同一段文本在两次推理中可能产生不完全一致的 token 序列。 2. 行为层面的非完全可复现性:对于 LLM 而言,即使温度(Temperature)设为 0,某些实现细节(例如 attention mask 的处理、KV Cache 的复用策略)也可能导致输出差异。
这意味着,当用户报告「AI 给了我一个奇怪的回复」时,工程团队往往无法在本地完整复现。问题排查从「确定性追踪」变成了「概率分布诊断」——你必须收集大量类似案例,识别其中的统计模式,才能定位问题根源。
1.3.4 一张对比表:传统软件 vs. AI 系统
| 维度 | 传统软件 | AI 系统 | | --- | --- | --- | | 输入-输出关系 | 确定性 | 概率性 | | 规约来源 | 人工编写的 Spec | 训练数据 + 任务定义 | | 行为可复现性 | 完全 | 不完全 | | Bug 修复方式 | 修改代码 | 修改数据 / 调整训练 / 改架构 / 改后处理 | | 测试通过的意义 | 规约被满足 | 在采样分布上的统计估计 | | 评估频率 | 发布前 + 回归 | 持续、在线、近实时 |
这张表不是要贬低传统软件工程,也不是要神化 AI 系统。它只是诚实地说:面对的是一类根本不同的工程对象,需要根本不同的工程方法。
---
1.4 评估四象限:一个用于诊断盲区的工具
承认 AI 系统需要新的评估范式之后,下一个问题是:新的范式应该长什么样?
本书提出的核心框架是「评估四象限」(Evaluation Four-Quadrant Framework)。这个框架不是为了取代任何现有的评估方法论,而是为了提供一个全局视角,帮助团队识别自己的评估盲区。
四个象限分别对应 AI 系统的四类核心关切:
1. 能力(Capability):模型能不能完成这个任务? 2. 对齐(Alignment):模型完成这个任务的方式是不是我们想要的? 3. 安全(Safety):模型会不会产生危害? 4. 商业(Business):模型上线后对业务指标有没有贡献?
我们逐一展开。
1.4.1 象限一:能力(Capability)
能力评估回答的是:模型在「技术上」能不能做好这件事。
这是 AI 研究者最熟悉的象限,也是公开基准(Public Benchmark)最密集的领域。GLUE、SuperGLUE、MMLU、HumanEval、GSM8K、TruthfulQA、HELM……这些基准在过去五年里如雨后春笋般涌现,共同构成了 AI 能力评估的「成绩单」。
但能力评估有一个常被忽视的陷阱:基准饱和(Benchmark Saturation)。
一个基准在诞生之初是有区分度的——它能区分出强模型和弱模型。但当最强的模型在该基准上达到 90% 以上的分数时,基准就「饱和」了:它无法再区分顶级模型之间的细微差异,而这些细微差异往往才是产品真正关心的。
MMLU 是一个教科书式的例子。这个基准在 2020 年提出时,最先进模型的准确率只有 25% 左右;到 2023 年,Claude 3 Opus 和 GPT-4 都已突破 86%;到 2024 年中,某些模型在部分学科子集上已经达到 95%+。区分度正在消失。
能力评估的工程实践要点:
- **不要只盯一个基准**,要使用**基准组合(Benchmark Suite)**,覆盖不同能力维度(知识、推理、代码、数学、长上下文、多语言)。
- **关注子集分数**,而不是总分。Nova 搜索的案例已经告诉我们,总体 F1 提升 3 个点,可能掩盖了关键子集的崩溃。
- **建立内部基准(Internal Benchmark)**,它应该反映你的产品场景,而非通用 NLP 任务。
- **警惕数据污染(Data Contamination)**。许多大模型的训练数据包含了公开基准的测试样本,导致分数虚高。
1.4.2 象限二:对齐(Alignment)
对齐评估回答的是:模型完成这件事的方式,是不是符合人类的意图、价值观和偏好。
如果说能力评估关心的是「能不能」,对齐评估关心的是「愿不愿意」和「该不该」。
对齐评估的难度远高于能力评估,因为「对齐」的标准本身就是一个动态的、多元的、有争议的概念。什么是「有帮助」?什么是「诚实」?什么是「无害」?这些问题的答案因文化、群体、个人而异。
目前主流的对齐评估方法可以分为三类:
1. 人类偏好评估(Human Preference Evaluation):让人类标注员对模型的多份输出进行两两比较或打分,代表性的有 Chatbot Arena、HHH(Helpfulness, Honesty, Harmlessness)框架。 2. 模型作为裁判(Model-as-Judge, MMaJ):用另一个强大的 LLM(通常是 GPT-4 或 Claude)来评判目标模型的输出。LMSYS 的「LLM-as-a-Judge」研究显示,这种方法的判断与人类的一致率可以达到 80% 以上,但在「创造性」「新颖性」等维度上仍弱于人类。 3. 宪法式 AI / 规则化对齐(Constitutional AI / Rule-based Alignment):预先定义一组原则(如 Anthropic 的宪法),用模型自身来检查输出是否违反原则。
对齐评估的工程实践要点:
- **对每个产品场景建立「价值维度清单」**。例如,对于一个客服 AI,价值维度可能包括「礼貌性」「准确性」「品牌调性一致性」;对于一个儿童教育 AI,还可能包括「适龄性」「无诱导性」。
- **多标注员、多文化背景**。同一个回答,来自北京、上海、班加罗尔、纽约的标注员可能有完全不同的判断。
- **动态更新价值标准**。文化在演变,产品在迭代,价值标准不能是 2020 年定下来就再也没改过。
- **警惕「对齐税(Alignment Tax)」**。过度对齐可能导致模型变得过度保守、过度冗长、拒绝回答合理问题。
1.4.3 象限三:安全(Safety)
安全评估回答的是:模型会不会产生危害?这种危害的概率和严重程度如何?
安全和对齐高度相关,但不完全重叠。Anthropic 的 HHH 框架把它们放在同一个框架内,但工程实践中,安全通常被单独处理,因为它涉及**法律合规、攻击防御、系统鲁棒