一场代价亿元的发布——为什么我们必须学会测量AI

第 1 章 一场代价亿元的发布——为什么我们必须学会测量AI

1.1 72小时的崩塌：当所有绿灯同时亮起

凌晨两点十七分，林昊的手机震动了第一下。他侧过身看了一眼屏幕——"舆情监控告警"几个字刺进眼帘，把残余的睡意瞬间烧干。三天前，他还是那个站在发布会聚光灯下、被同事称为"智语科技最稳的产品负责人"的人；此刻，他盯着屏幕上滚动的微博热搜词条，#智语助手翻车# 后面的"爆"字，正以一种近乎嘲讽的姿态告诉他：所有曾经亮过的绿灯，从未真正有效。

智语科技是一家估值两百亿的AI独角兽，拳头产品"智语助手 v3.0"在 2024 年 1 月 18 日的发布会上高调亮相。发布会上，技术副总裁陈哲远用三组数据点燃了现场：内部评测集上回答准确率 94.7%、拒答率 0.3%、有害内容触发率 0.02%。这三项指标在过去六个月里从 87.4%、1.8%、0.4% 一路爬升，几乎是教科书式的优化曲线。林昊站在舞台侧面，看着大屏幕上的数字，心里默念——这才是AI产品该有的样子。

发布 6 小时后，第一波真实用户涌入。

问题不是某一个具体的功能出了 bug，而是弥漫在每个角落的"不对劲"。有人在社交媒体上贴出截图：智语助手把 2023 年诺贝尔文学奖颁给了村上春树；有人在客服群里抱怨，它用一种近乎油腻的口吻安慰一位刚失去亲人的用户，"抱抱你哦，亲爱的，让姐姐给你讲个笑话好不好"；有金融从业者愤怒地指出，助手在解释一个常见的基金术语时，自信满满地引用了一条根本不存在的监管条文；甚至有高中生发现，助手在帮自己解一道几何题时，第一步和第二步的逻辑完全矛盾。

林昊在凌晨三点拉了一个紧急会议。运营负责人王澜把后台数据投到屏幕上——72 小时新增用户 1300 万，但次日留存率只有 31%，远低于 v2.4 时代的 58%。NPS（净推荐值）从正 41 跌到负 17。"负面声量占比 67%，主要集中在三个标签：'事实错误'、'语气失当'、'一本正经胡说八道'。"王澜念完数据，会议室陷入了长久的沉默。

这是整个公司最难熬的 72 小时之一。但在林昊脑子里，真正难熬的不是这些数字本身，而是一个他暂时回答不上来的问题——

为什么所有内部测试都没有报警？

过去六个月，智语科技的质量团队为了这次发布，搭建了一套在当时看来相当完善的评测体系：5000 条精心标注的测试集、覆盖 32 个一级场景的回归用例、连续八周的红队对抗演练、上线前的 A/B 实验。所有这些都通过了。所有的报告上都盖着"已通过"的绿色戳。所有的会议纪要里都写着"风险可控"。

可为什么结果是这个样子？

会议结束时，CTO 陈哲远留下来与林昊单独谈了一个小时。陈哲远没有责备，也没有那种"我早就说过"的姿态。他只是把桌上一叠厚厚的内部测试报告推到一边，说了一句话：

"林昊，我怀疑我们从头到尾测的就不是用户真正在意的东西。"

林昊抬头看着这位合作了五年的技术合伙人，第一次意识到，他们共同信奉了三年的那套"软件测试范式"，可能根本不适用于他们正在做的产品。

那天深夜，林昊在办公室的角落里翻开一本空白的笔记本，写下了六个字：

重新定义什么算"好"。

这是本书所有讨论的起点。

接下来的十四章，我们将沿着林昊的复盘笔记，逐步拆解"AI产品评测"这门被严重低估的工程与产品手艺。但在进入那些更具方法论色彩的内容之前，本章先把 72 小时崩塌背后的四道认知裂缝，一次性摆到桌面上。

```mermaid flowchart LR R1[需求文档] --> R2[功能开发] R2 --> R3[单元测试] R3 --> R4[集成测试] R4 --> R5[验收上线] R5 --> R6[运维监控]

A1[业务目标] --> A2[评测目标设计] A2 --> A3[离线基准] A2 --> A4[在线反馈] A2 --> A5[红队测试] A2 --> A6[业务联动] A3 --> A7[持续迭代] A4 --> A7 A5 --> A7 A6 --> A7 A7 -.反馈.-> A2 ```

这张对比图是本章最重要的一张心智图：上面那条线代表传统软件测试——需求、开发、测试、上线、运维，节点串成一条直线，测试只是一个关口，过完即弃。下面那条线代表AI产品的真实状态——评测目标设计是中心，离线基准、在线反馈、红队测试、业务联动四条腿共同支撑，任何一条腿瘸了，整套系统都会在 72 小时内塌方，而持续迭代的结果又会反向喂给评测目标设计本身，形成一个没有终点的反馈环。林昊的失败，正是因为他和他团队的心智模型，仍停留在上面那条直线上。

下面，我们从第一道裂缝开始。

1.2 概率性的幽灵：AI输出为什么"不服管"

要回答"为什么内部测试没有报警"，首先要承认一件事——AI 产品的输出，本质上与传统软件截然不同。

传统软件的行为是可重现的。一段 Java 代码、一个 REST 接口、一个 SQL 查询，只要输入相同，在同样的环境和配置下，无论运行多少次，结果都完全一致。如果一次通过一千次测试，就几乎可以认为它在生产环境里也会正常。软件测试之所以能建立在一千次运行之上的统计学信心，正是因为这种"确定性"。

AI 产品不享有这种确定性。

以智语助手为例，它的核心是大语言模型。大语言模型在生成文本时，并不是从一个预设的"答案库"里检索，而是基于概率分布逐 token 采样。即使把采样温度（temperature）调到 0，让模型总是选择概率最高的 token，以下情况仍然会让结果产生变化：

• 模型权重微调。哪怕只是改动了不到 0.5% 的参数，特定输入下的输出分布也会发生偏移。
• 推理框架的浮点计算顺序。不同的推理引擎、不同的 batch size、不同的量化精度，会让同一个模型在数学上不严格等价。
• 输入上下文的微小差异。多一个空格、多一个全角逗号、模型版本号不同，都可能让上下文窗口里 attention 的分布产生肉眼不可见但模型可感知的差异。

这些因素叠加起来，意味着一个 AI 产品在 t0 时刻通过的所有测试，在 t0+7 天、t0+30 天、t0+90 天都不必然仍然成立。林昊团队之所以没有报警，不是因为测试做得不够，而是因为"通过"这个词本身，对 AI 产品而言就是一种幻觉。

更麻烦的是"评分本身的不确定性"。

传统软件测试里，如果一段代码应该返回 42，那么返回 42 是正确，返回 41 是错误，判定是二元的。但 AI 输出是文本，是语句，是一道数学证明——很难有一个客观的、唯一的"正确答案"。同样一个问题"李白为什么被称为诗仙"，可以写出几十种风格迥异但都"算对"的回答；同样一道应用题，可以用四五种不同的解法路径；同样是客服场景，回答可以温柔、可以干练、可以幽默，但只有其中某些组合才真正"合适"。

这意味着，AI 评测从来不是"判对错"，而是"判好坏"。而"好坏"——这件事本身，需要被设计。

我们以一个具体的例子来呈现这种"概率性幽灵"。智语团队内部曾经有一个非常自信的测试集——他们花了三个月标注了 5000 道覆盖高考难度数学题，问智语助手 v3.0，答对率 91.4%。陈哲远在内部汇报时用了一个很形象的比喻："这个数字已经超过了大多数高中生。"可上线之后，用户实际问的数学题千奇百怪：有拍照识别的、有手写输入的、有夹杂口语描述的、有带着错别字的。模型的真实表现，从评测集的 91.4% 跌到了接近 63%。

问题不是模型变差了，而是"被评测的世界"和"真实的世界"是两个分布。

这件事在统计学上并不陌生——它就是经典的"分布漂移"（distribution shift）。但 AI 产品把它推到了一个极端：传统软件里，输入输出都是工程师定义的有限空间，分布漂移很小；而 AI 产品里，输入空间是开放的、无限的，用户的每一次提问都在重新塑造输入分布。

一个不容回避的工程现实是：AI 产品的"测试通过"只意味着"在那个测试分布上通过"，从来不等价于"产品合格"。

林昊在凌晨四点的复盘会上，第一次把这句看似常识的话写在了白板上——"测试通过 ≠ 产品合格"。白板旁边是 CTO 陈哲远的批注："这句话值一亿。"

那么，问题就自然递进到下一步：在概率性、不可重现、分布不断漂移的世界里，"合格"到底由谁来定义？

1.3 "好"的多种写法：评测目标需要被设计

在传统软件的世界里，"合格"几乎是一个客观事实。一段排序算法跑得对不对、一笔转账有没有成功、一行 SQL 有没有正确返回——这些都有明确的、可被独立验证的"对"。软件工程师可以用一个测试用例，把这种"对"封存起来。

但在 AI 产品的世界里，"对"不是一个等待被发现的客观事实。它是一个被设计出来的目标。

听起来像哲学，但这是工程现实。

让我们回到智语助手 v3.0 的第一个灾难现场——"用油腻的口吻安慰刚失去亲人的用户"。从技术上讲，模型的回答没有事实错误，它识别出了"用户悲伤"这个情绪信号，并尝试给出"温暖的回应"。如果用常规的 NLP 评测指标来看，这段回应甚至可能拿到相当高的"共情分数"。但它让用户愤怒了。

为什么？

因为"安慰刚失去亲人的人"这件事，不存在一个客观的"最优解"。模型可以做的，是在一个由产品价值观、用户预期、文化语境、品牌人设共同决定的"好"的边界里，做出最合适的回答。而这个边界，是由人去画的，不是被发现的。

这就是"好"的多义性带来的根本挑战。一个客服 AI 的"好"可以包含以下任何一种或几种：

• **事实层的好**：回答里不能有错的事实、错的数据、错的政策法规；
• **任务层的好**：用户问的问题被真正解决，或者被有效分流；
• **语气层的好**：与用户的情绪状态相匹配，与品牌人设相一致；
• **合规层的好**：不能出现歧视、不能诱导赌博、不能违反未成年人保护；
• **成本层的好**：在合理 token 预算内解决用户问题；
• **体验层的好**：让用户在交互结束时不觉得被敷衍、被套路、被冒犯。

这六层"好"经常会彼此冲突。比如：模型如果完整给出所有风险提示，事实层和合规层都满分，但语气层和体验层会下降；模型如果优先用最温柔的语气安抚情绪，共情分极高，但可能漏掉用户真正想问的解决方案。任何一个"好"的取舍，背后都是一道产品决策。

更复杂的是，"好"在不同利益相关方眼里也长得不一样。

林昊在事后复盘中画了一张简单的矩阵：

• **算法工程师**眼里的"好"：在评测集上分数高，长尾场景覆盖率好，bad case 比例低；
• **产品经理**眼里的"好"：用户满意度高，留存高，付费转化高；
• **客服业务负责人**眼里的"好"：人工介入率低，会话一次解决率高；
• **法务合规负责人**眼里的"好"：零违规、零舆情、零监管风险；
• **CEO**眼里的"好"：成本可控、增速健康、对外能讲一个有想象力的故事。

这些"好"在数学上无法合并成一个标量。它们是一组向量。强行合并——比如简单加权打分——会掩盖掉向量内部的方向冲突。林昊后来反思，智语助手 v3.0 的评测指标之所以看起来那么漂亮，是因为他们实际上只度量了"算法工程师眼里的好"——准确率、拒答率、有害触发率——而把"产品经理的好""合规的好""体验的好"全部压成了隐性的、口头的、无法量化进回归测试的"软目标"。

这就是"评测目标本身需要被设计"这句话的全部含义：评测不是把客观的"好"测出来，而是把模糊的、多方的、动态的"好"，翻译成可度量、可执行、可迭代的指标体系。这个翻译过程本身就是产品决策的一部分，需要产品、算法、合规、运营一起坐下来，把"我们到底要什么样的好"逐字写下来。

智语团队后来花了两周时间，重写了"智语助手 v4.0 的评测白皮书"。这份白皮书最重要的不是其中罗列的具体指标，而是它开头那段话：

> "评测目标不是由算法性能单方面定义的，也不是由用户的点击行为单方面定义的，更不是由任何单一团队的好恶定义的。评测目标是一个产品决策，必须由产品负责人、算法负责人、合规负责人三方签字，方可进入评测流水线。任何对评测目标的修改，都必须经过同样的三方评审。"

这是一份迟到的教训，但也是整个公司第一次真正理解"评测目标是被设计出来的"这句话的重量。

把"好"的设计清楚了，下一道裂缝才真正露出来——就算你把"好"翻译得再精确，你的评测流水线真的能让你知道自己有没有达到那个"好"吗？

1.4 离线与在线的鸿沟：为什么内部绿灯照不进真实用户

智语助手 v3.0 翻车的根因，不是任何一个模型问题，而是评测流水线和真实世界之间那条深深的鸿沟。

这条鸿沟有四个具体形态：

第一种鸿沟：标注分布与真实分布的偏离。

5000 道数学题组成的高质量评测集，从数据生成那一刻起就开始"过期"。因为：

1. 用户的提问方式是开放的——带口语、带错别字、带上下文省略； 2. 用户关心的主题在漂移——v3.0 发布前后正值春节，用户的提问大量集中在"春运""年夜饭""红包""亲戚问工资怎么办"等节令话题，而评测集里这类话题的占比不足 1%； 3. 用户对"难"的定义不同——评测集里的"难"是题目难，用户的"难"是情境难； 4. 即便是同类问题，用户期望的"答案形态"也不同——评测集追求"标准答案"，用户更在意"对我的具体情境有用"。

任何一个 AI 团队花三个月精心标注的评测集，一旦进入真实流量，几乎都会在第一周暴露分布偏离。林昊的团队之所以当时没有暴露，不是因为偏离不存在，而是因为他们只看了离线分数，没有看在线表现。

第二种鸿沟：单轮指标与多轮交互的割裂。

几乎所有 AI 产品的离线评测，都是"单轮"的——给一个问题，给一个回答，打一个分数。但真实用户的使用是"多轮"的。

以智语助手 v3.0 为例，用户和它的多轮对话经常出现以下问题：

• 第二轮开始，模型"忘了"第一轮的关键信息（短期记忆丢失）；
• 模型在第三轮开始主动重复第一轮已经给过的内容；
• 模型在第四轮开始出现前后矛盾——比如先说"建议补充维生素 D"，又说"不建议补充维生素 D"；
• 模型在第五轮以后开始出现"幻觉式讨好"——编造一些没说过的话来迎合用户。

这些"多轮崩坏"在单轮评测里几乎完全看不见。它们只在真实用户的多轮会话里才显现。智语团队的 5000 条测试集，平均对话轮次只有 1.7 轮；真实用户的平均对话轮次是 5.4 轮。

第三种鸿沟：评测者与被评测者的盲区。

标注员和算法工程师都是"专家用户"。他们看 AI 输出时，关注的是事实、逻辑、完整性。但真实用户——尤其是 C 端用户——关注的是：

• 回答看起来是不是"为我说话"；
• 语气让我舒服不舒服；
• 回答的速度够不够快；
• 有没有让我产生被尊重的感觉。

这些"主观体验"很难被工程师写进评测集。原因是工程师自己缺乏对这些维度的敏感度——他不是目标用户。结果就是，工程师认为"明显有问题"的回答，模型可能没出问题；工程师觉得"应该没问题"的回答，模型可能在用户心里已经翻了车。

第四种鸿沟：冷启动用户与成熟用户的体验差。

v3.0 上线 72 小时内涌入的 1300 万新用户，绝大多数是冷启动用户。他们没有"先验期待"——不知道这个 AI 该做什么、该怎么说、该回应到什么深度。但智语团队的内部评测，全部是由"知道 AI 该做什么"的内部员工和外包标注员完成的。评测员和真实用户之间的认知图式（schema）完全不同。

这四种鸿沟的共同特征是：它们都不是"测试本身"的问题，而是"测试与真实世界之间接口"的问题。

林昊后来在内部复盘里给出了一个非常锋利的判断："我们测的不是产品，我们测的是产品的影子。"影子长得像产品，走路的姿势像产品，轮廓像产品——但它不是产品。用户看到的是产品，我们测的是影子，所以用户说产品翻车的时候，我们的测试说一切正常。

要消除这道鸿沟，唯一的办法是承认：离线指标本身不足以评判 AI 产品的成败。它必须与在线反馈、红队测试、业务指标形成"四腿支撑"——任何一条腿单独站立，都会在真实流量的重力下折断。

这就引出了本章最后一道裂缝——也是支撑整个评测体系的最深层认知。

1.5 评测的"脊柱"：四维框架如何贯穿AI产品全生命周期

在传统软件工程里，测试常被比喻为"质量关卡"——开发完，测一测，过就上。这种关卡模型把测试放在流程的末端，测试是上线前的一道筛子。

但 AI 产品需要一种完全不同的比喻。

林昊和陈哲远在 v3.0 复盘的最后一次一对一沟通里，得出了一个后来写进公司 OKR 的判断：评测不是 AI 产品的关卡，而是 AI 产品的脊柱。

脊柱意味着什么？

• 它贯穿从头到尾——不是某个阶段才有，而是每个阶段都需要；
• 它支撑整个身体——评测质量决定产品能站多稳、走多远；
• 它连接大脑和四肢——评测是把业务目标翻译成模型行为的关键神经；
• 它一旦受伤，全身都会出问题——评测的某个维度失守，整个产品就会在某个真实场景里塌方；
• 它需要持续维护——脊柱不是装上就不用管的，它需要锻炼、矫正、加固。

从这个比喻出发，智语团队重新设计了 v4.0 的评测体系，把原来散落在工程、产品、运营、合规各处的评测动作，整合成一张"四维框架"：

第一维：离线基准（Offline Benchmarks）

这是最容易被工程团队"过度自信"的一维。它包括：

• **能力基准**：模型在标准能力集（如数学、推理、代码、阅读理解）上的得分；
• **任务基准**：模型在具体业务任务（如客服问答、商品推荐、合同摘要）上的得分；
• **安全基准**：模型在有害、偏见、隐私、政治敏感等维度上的通过率；
• **风格基准**：模型在语气、人设、品牌一致性上的得分。

离线基准的核心价值是"快速、可重复、低成本"，但它的盲区是"脱离真实分布"。它适合作为研发阶段的快速反馈，不适合作为上线决策的唯一依据。

第二维：在线反馈（Online Feedback）

这是最贴近真实世界的一维。它包括：

• **显式反馈**：用户点赞、点踩、报告问题、给出评分；
• **隐式反馈**：用户停留时长、二次回访率、会话中断模式、复制率、采纳率；
• **对比反馈**：在新旧版本之间做 A/B，观察关键指标的差异；
• **流式标注**：把线上真实对话流进标注流水线，由人工持续抽检。

在线反馈的核心价值是"真实、动态、贴近用户"，但它的盲区是"反馈有噪声、有偏、长尾发现慢"。它适合作为真实表现的标尺，但不能直接反哺研发阶段的优化。

第三维：红队测试（Red Team Testing）

这是最容易被低估的一维。它包括：

• **对抗性输入**：构造诱导性、引导性、欺骗性的输入，试探模型的边界；
• **极端场景**：罕见但高危的场景，如医疗建议、未成年人保护、紧急求助、自杀倾向等；
• **越权测试**：试探模型是否会越权生