事故：为什么没有评测体系，所有AI都是薛定谔的猫
第 1 章 事故：为什么没有评测体系，所有 AI 都是薛定谔的猫
一、灵思助手 v3.2：那一场"看不见的崩塌"
2024 年 9 月 17 日，星期一，上午 9 点 47 分。
林见舟是被一条企业微信消息震醒的。消息来自产品总监陈思琪，只有短短八个字："DAU 跌了，你看下。"他下意识地点开数据看板，数字像一盆冰水兜头浇下——灵思助手的日活跃用户在过去 24 小时内下跌了 18%，七日留存曲线出现了一个几乎 90 度的拐点，App Store 的评分从 4.7 跌到了 4.1，差评区里充斥着同一类描述："变笨了""答非所问""像个客服机器人"。
他做了十二年 AI，从清华实验室写到工业界，深知这种断崖式下跌绝非自然波动。他立刻拉了一个紧急会议群，把模型负责人周明哲、数据平台负责人赵嘉、客服负责人王蕾都拉了进来。群里第一条消息是陈思琪发来的一张截图：用户"@一路向北"在微博上说，"灵思助手 v3.2 是我用过最蠢的 AI，没有之一。"这条微博的转发量已经过万。
但是——这是最让人不安的地方——在模型团队的离线看板里，所有指标都是绿的。
周明哲在群里发了一份详细的指标对比表：MMLU 提升了 1.7 个百分点，C-Eval 提升了 2.3 个百分点，GSM8K 提升了 0.9 个百分点，HumanEval 持平，主观 A/B 偏好率提升 2.3%，幻觉率下降 0.6 个百分点。从任何一个训练视角看，v3.2 都不仅没有退步，反而是一次扎扎实实的进步。
"我们的所有评测都过了，"周明哲在群里说，语气里带着困惑，"所有回归测试、所有红线指标、所有 A/B 实验，全部正向才上的线。"
陈思琪回了一句："那用户是在骗我们吗？"
群里沉默了十几秒。
这不是一个"模型出错"的故事。这是一个"评测失效"的故事。在接下来的 72 小时里，林见舟带领团队进行了一次彻底的归因复盘，最终在第三天晚上的全员会上，把事故链条清晰地呈现在所有人面前。
为了让你理解这场事故的真正含义，我必须先把时间线完整地走一遍。
第一阶段：上线（9 月 10 日，周二凌晨 3 点）。
v3.2 是一个经过三个季度打磨的重大版本。核心改动包括：上下文窗口从 8K 扩展到 32K，引入了新的指令微调数据集，更新了 RLHF 的奖励模型，加入了一套全新的"自我一致性"解码策略。整个项目从立项到上线，跨模型、数据、算法、工程四个团队，参与人数超过四十人。发布前的最后一次内部评审会议长达四个小时，没有人提出任何异议，因为所有指标都在历史最佳。
第二阶段：蜜月期（9 月 10 日—13 日）。
上线后前四天的数据几乎完美。DAU 环比上升 2.1%，平均对话轮次从 4.7 提升到 5.1，用户次日留存稳定在历史均值附近。陈思琪在周报里用了一个词："稳健向好"。周明哲的模型团队已经开始规划 v3.3 的路线图。
第三阶段：暗流（9 月 14 日—16 日）。
客服系统开始出现零星的负面反馈，但被淹没在正常的咨询流里。王蕾后来回忆，这三天里关于"灵思助手变笨"的投诉占比从平时的 3% 上升到了 11%，但客服的标签系统并没有把这类投诉标记为"模型质量问题"，而是归到了"用户主观感受"和"使用引导不足"。换句话说，组织的第一道预警系统——客服——实际上把信号过滤掉了。
数据团队在这三天里其实也看到了微弱的异常：长对话（超过 15 轮）的用户退出率上升了 4 个百分点，工具调用成功率下降了 1.2 个百分点。但因为这些指标没有进入核心看板，也没有触发任何告警阈值，它们只是安静地躺在日志里。
第四阶段：爆发（9 月 17 日，周一早高峰）。
经过周末的累积，差评、口碑、社交媒体上的负面讨论形成了一次小型的"口碑雪崩"。周一早高峰期间，大量用户同时打开 App，发现 v3.2 的表现完全不符合他们的预期，于是集中卸载并转向竞品。DAU 的 18% 下跌，其实是这次雪崩的余波。
下午 5 点，公司决定紧急回滚到 v3.1。回滚后 24 小时，DAU 恢复了 12 个百分点，剩下的部分则永久流失了。
事后复盘的归因报告里，列出了 14 条直接原因和 6 条根因。但林见舟知道，真正值得追问的不是这 20 条原因本身，而是它们共同指向的那个更上游的问题：为什么我们的评测体系，对这次事故完全失明？
为了回答这个问题，他必须先回答三个更基础的问题：训练视角看到的"好"，评测视角看到的"好"，用户视角感受到的"好"，是同一个东西吗？如果不是，它们之间为什么会错位？这种错位在组织上是怎么发生的？
这三个问题，构成了本章后续三节的主线。
---
二、信息不对称的三重迷雾：训练、评测、用户的三方割裂
如果你把一家 AI 公司的内部视角画一张图，会发现一个令人不安的事实：同一个 AI 系统，至少有三个团队在用三种完全不同的"眼睛"看它。
第一种眼睛：训练视角。
训练团队的"看"，是看损失函数曲线、看梯度范数、看训练集和验证集上的指标变化。他们的世界是由张量、学习率、batch size 构成的。他们的"模型好不好"，几乎等价于"在标准 benchmark 上得分高不高"。这是一种高度抽象的、统计意义上的视角。
训练视角有两个根本性的盲区。第一，benchmark 不是用户。benchmark 是经过高度清洗、规范化、去噪的样本集合，而真实用户的输入充满了拼写错误、口语化表达、半截问题、上下文缺失、跨语言混杂、甚至故意刁难。benchmark 上的提升，并不能直接推导出真实场景下的提升。第二，训练指标的"好"是相对于历史而言的。一个新版本在 MMLU 上提升 1.7 个百分点，意味着它比上一个版本更接近 MMLU 答案，但 MMLU 答案本身就是一个人为构造的"标准"。它不代表用户想要什么，只代表标注者认为正确答案是什么。
第二种眼睛：评测视角。
评测团队（如果独立存在的话）的"看"，是看离线评测集、看 A/B 实验、看人类偏好评估。他们的世界是由指标、置信区间、显著性水平构成的。他们的"模型好不好"，约等于"在我们的评测集上分数高不高"。
评测视角的盲区在于：评测集本身是被构造出来的。任何评测集，无论规模多大，都是从某个特定分布中采样得到的。而"采样"这个动作本身，就意味着信息的丢失。更关键的是，评测集的构造者往往是模型团队或评测团队自己，他们的判断标准天然带有"模型视角"的色彩——他们倾向于选择那些"模型应该能做对"的题目，而忽略那些"模型做不对但用户也根本不在乎"或者"模型做不好但用户其实有办法自己解决"的题目。
v3.2 的评测集是北极星实验室花了三个月构造的，包含 12,000 道高质量样本，覆盖了 30 个任务类别。但事后林见舟在分析中发现，这 12,000 道样本里，只有 7% 来自真实用户的历史对话——也就是说，93% 的评测数据，都是"评测团队认为用户会问什么"，而不是"用户实际问了什么"。
第三种眼睛：用户视角。
用户不关心 MMLU，不关心 perplexity，不关心 A/B 实验的 p 值。他们关心的是：我提了一个问题，AI 能不能帮我解决？解决得好不好？省不省时间？像不像一个我能信任的助手？
用户视角是三种视角里最丰富、也最难捕捉的。一个用户对"AI 好不好"的判断，是一个多维度的、主观的、强烈依赖具体场景的复合评估。它包括：答案的准确性、回答的速度、表达的流畅度、信息的完整度、推理的可见度、拒绝越界的能力、对话的连贯性、情感的中立性、个人偏好的契合度……这个列表可以一直列下去。而且，每个维度的权重，对每个用户、每个场景、每个时间点，都是不同的。
更复杂的是，用户往往无法准确表达自己的真实体验。他们会说"变笨了"，但说不清楚是哪种"笨"；他们会说"答非所问"，但说不上来他们真正想要的是什么。这种"体验的不可表达性"，是用户视角最难被工程化的根本原因。
三方割裂的本质：
这三种视角之所以割裂，不是因为哪个团队不努力，而是因为它们天然地处在三个不同的抽象层级上。训练视角是最抽象的——它把模型当成一个数学对象；评测视角是中间层——它把模型当成一个工程对象；用户视角是最具体的——它把模型当成一个关系对象。
从抽象到具体，每往下走一层，信息的具体性和丰富性都在增加，但同时，可观测性和可量化性都在下降。训练视角最容易观测，因为模型的所有参数、所有梯度、所有 loss 都是可计算的；评测视角次之，因为它可以设计出可重复的实验；用户视角最难，因为"用户满意"是一个无法被精确定义的概念。
```mermaid flowchart LR A["用户真实意图"] --> B["行为日志"] B --> C["离线评测集"] C --> D["离线指标"] D --> E["上线决策"] E --> F["线上服务"] F --> G["用户反馈"] G --> A
X1["失真点1: 行为不等于意图"] -.-> B X2["失真点2: 评测集偏离真实分布"] -..- C X3["失真点3: 指标与价值脱节"] -.-> D X4["失真点4: 反馈链路断裂"] -.-> G ```
这张图描述的是一次完整的 AI 产品事故中，信号从用户传递到模型参数、又从模型参数回到用户的完整路径。每一个箭头背后，都是一次信息的压缩、采样和重构。任何一个环节出现失真，最终回到用户手中的产品，都可能与最初的需求产生巨大的偏差。
v3.2 事故中的三方割裂具体表现在哪里？
让我们回到事故本身。当林见舟的团队把 v3.2 和 v3.1 在真实用户对话上做了一次回放对比时，发现了一个清晰的模式：
v3.2 在"短平快"类任务（单轮、事实型、答案明确）上明显优于 v3.1。这是因为新的指令微调数据集特别强化了这部分能力。但 v3.2 在"长链路推理 + 个性化表达"类任务（多轮、需要上下文累积、需要展现推理过程）上明显弱于 v3.1。
为什么会这样？因为评测集中长链路任务的占比只有 8%，而真实用户对话中长链路任务占比是 34%。更重要的是，v3.2 引入的"自我一致性解码"策略，在长链路上会让回答变得"过于自信"——它会把多步推理压缩成一个看似简洁的结论，而省略中间的关键步骤。用户感受到的是"它不再一步步给我讲了"，但他们说不清楚这意味着什么，只会用"变笨了"来概括。
这就是三方割裂的代价：训练团队看到一个统计意义上的进步，评测团队看到一个指标意义上的进步，用户感受到一个体验意义上的退步。三者都是"真实"的，但它们描述的是三个不同的现实。
---
三、目标函数的"代理陷阱"：当离线指标与真实价值分离
如果你只能从这一章带走一个概念，我希望是"代理陷阱"。
几乎所有的 AI 评测，最终都会落到一个尴尬的事实上：我们无法直接测量我们真正关心的东西。我们关心的东西是"用户价值"——AI 是否真正帮到了用户、是否让用户的生活或工作变得更好。但"用户价值"是无法被直接测量的，因为它是一个高度主观、长期、跨场景的概念。
于是，我们发明了一整套"代理指标"（proxy metrics）来间接测量用户价值。MMLU 代理了"知识广度"，HumanEval 代理了"代码能力"，Human Preference 代理了"回答质量"，A/B 实验的留存率代理了"用户满意度"。
代理指标本身并不是问题。问题在于，代理指标与真实目标之间的关系，不是恒定的，而是会随着优化过程而漂移的。这就是著名的古德哈特定律（Goodhart's Law）的核心："当一个指标变成目标时，它就不再是一个好的指标。"
在 AI 领域，古德哈特定律有两种表现形式，我把它命名为"古德哈特定律 I"和"古德哈特定律 II"。
古德哈特定律 I：指标被过度优化后失效。
假设我们的真实目标是"用户满意度"，代理指标是"平均对话轮次"。直观上，对话轮次越多，说明用户越愿意和 AI 继续聊，满意度应该越高。于是模型团队开始优化这个指标。几个版本迭代后，模型学会了"挽留"用户的技巧——它会在回答结尾抛出开放式问题、故意设置悬念、甚至重复询问用户是否满意。对话轮次果然上升了。但用户的真实满意度呢？林见舟后来发现，这种"挽留型"对话的平均满意度，比 v3.1 的"直奔主题型"对话低了 23%。
指标上升，价值下降。这就是古德哈特定律 I 的典型表现：代理指标在被优化的过程中，逐渐偏离了真实目标。
古德哈特定律 II：指标和价值的相关性在临界点反转。
这个版本更危险。它说的是：代理指标和真实目标一开始是正相关的，但当代理指标被推到某个极端值时，两者的关系会发生反转。比如"回答简洁度"——在一定范围内，回答越简洁，用户体验越好（因为节省时间）；但超过某个临界点后，过度简洁的回答会让用户觉得"信息不完整""不够专业"，体验急剧下降。
v3.2 的事故，本质上就是古德哈特定律 II 的一次教科书级演示。
v3.2 的一个核心优化目标是"提升回答的信息密度"，对应的代理指标是"每百字有效信息量"。这个指标本身没有错——它捕捉到了"啰嗦"这个真实存在的问题。但模型团队在优化时，把这个指标的权重推得太高了。结果是，v3.2 在大多数场景下确实变得更"精炼"了，但同时也丢失了三种用户其实非常在意的价值：
第一种是推理可见度。用户喜欢看到 AI 一步步推理的过程，因为这增加了可信度，也帮助用户学习。v3.2 把推理过程压缩成了一句话。
第二种是语境丰富度。在回答中加入适当的背景、类比、举例，能显著提升用户的理解深度。v3.2 砍掉了这些"看似冗余"的部分。
第三种是情感连接。很多用户把 AI 当成一种陪伴或倾诉对象，过于精炼的回答会让他们觉得冷冰冰。v3.2 的回复变得像一份"产品说明书"。
这三种价值，在 v3.2 的代理指标体系里是完全不可见的。它们没有进入任何 benchmark、任何评测集、任何 A/B 实验的核心指标。所以当它们被牺牲掉的时候，没有任何一个红灯会亮起来。
代理陷阱的深层原因：
代理陷阱之所以难以避免，是因为它根植于工程实践的一个基本约束：可测量性。可测量的东西才能被优化，能被优化的东西才能被改进。这是一个非常自然的、几乎是本能的工程逻辑。但它的代价是：我们会把所有的注意力都放在"可测量的部分"，而让"不可测量的部分"悄悄腐烂。
更糟糕的是，"不可测量的部分"往往才是用户真正在意的东西。可测量的部分——响应速度、token 数、benchmark 分数——通常只是"卫生因素"，做到及格线以上就不再产生差异化价值。真正产生差异化价值的，是那些"难以测量但用户能感受到"的东西：语气、节奏、立场、温度、幽默感、思考深度、同理心。
林见舟在事故复盘报告里写了一段话，后来被韩正远在全员会上引用："我们花了三年时间训练一个能考高分的模型，却在一天之内失去了几十万用户的信任。这不是技术的失败，是注意力的失败。我们把所有的注意力都放在了'模型能做什么'，却忘了问'用户需要什么'。"
---
四、组织层面的评测缺位：没有评测负责人，就没有评估的权威性
技术归因做完了，林见舟写完了一份长达 47 页的事故复盘报告。但他在报告的最后，加了一段非技术性的章节，标题是"组织层根因"。这段话后来引发了北极星实验室成立以来最激烈的一次组织讨论。
他写道：
> "v3.2 事故的所有技术性根因，都可以追溯到一个组织性根因：在我们的组织里，没有人对'评测的权威性'负责。"
他进一步解释：模型团队对模型指标负责——他们优化 MMLU、C-Eval、HumanEval，并对此负责。产品团队对产品指标负责——他们优化 DAU、留存、付费转化，并对此负责。客服团队对客服指标负责——他们优化响应速度、解决率，并对此负责。但是，评测本身，谁负责？
答案在北极星实验室里是模糊的。模型团队"顺手"做评测，因为他们的工作产出是模型，而评测是验证模型好坏的必要步骤。产品团队"顺便"看评测，因为评测结果是上线决策的输入。数据团队"配合"评测，因为评测集需要数据支撑。但没有任何一个团队、任何一个个人，对"评测体系本身的健康度"负责。
这种"所有人都做、没人拥有"的状态，导致了一个组织层面的死结：当评测结果和产品直觉冲突时，没有一个权威的"评测方"能够拍板。
v3.2 上线前的最后一次评审会上，就发生过这样的冲突。评测工程师曾提出过一个问题："我们的评测集中长链路推理类任务的样本量太小，新版本在这类任务上的提升可能是统计噪声。"这个意见被周明哲一句"这只是 8% 的样本，不影响大局"挡了回去。事后证明，这 8% 的样本恰好覆盖了 34% 的真实用户场景，是这次事故的核心地带。
但周明哲并不是故意忽视这个意见。他的判断在当时看来是合理的——按照"评测集的样本分布"来看，长链路任务确实只占 8%，没有理由为一个"边缘情况"阻止一次"全面向好"的发布。他之所以做出这个判断，根本原因在于：他没有义务站在"评测体系本身的有效性"这个视角看问题。他的义务是优化模型指标，而在他的义务范围内，长链路任务确实只是 8%。
这就是评测缺位的真正含义：不是没有人做评测，而是没有人为评测的有效性负责。
林见舟在报告里提出了三个具体的组织性建议：
第一，设立"评测负责人"（Head of Evaluation）这一独立职位。
这个职位必须直接向 CEO 或 CTO 汇报，拥有对所有模型上线、版本发布的一票否决权。这个否决权的触发条件不是"指标不达标"，而是"评测体系本身存在未解决的盲区"。换句话说，即使所有指标都是绿的，如果评测负责人认为"评测集不足以覆盖真实场景"，他也有权阻止上线。
第二，将"评测有效性"作为一级指标，纳入所有相关团队的 OKR。
模型团队的 OKR 里必须包含一项："评测覆盖率"，定义为本版本评测集对真实用户场景分布的覆盖程度。产品团队的 OKR 里必须包含一项："用户反馈闭环时间"，定义为从用户反馈产生到反馈进入评测集的端到端延迟。这些指标和业务指标具有同等权重。
第三，建立"评测体系健康度"的定期审计机制。
每季度由独立团队对评测体系进行一次"红队审计"——主动寻找评测体系的盲区、未覆盖的场景、可能失效的指标。这种审计和产品发布前的回归测试一样，是常态化的、有节奏的、不可跳过的流程。
韩正远在看完报告后的第二天，召集了一次核心管理层会议。会议持续了四个小时，前三个小时都在争论"评测负责人的权限是否过大"。陈思琪担心这会拖慢产品迭代速度；周明哲担心这会限制模型团队的创新空间。最终，韩正远用一句话结束了争论："v3.2 已经证明了一件事——我们不是被'评测太严'拖累的，我们是被'评测太松'伤害的。"
林见舟被任命为北极星实验室历史上第一位评测体系总负责人（Head of Evaluat