为什么AI评测这么难？——被忽视的'测不准原理'

为什么AI评测这么难？——被忽视的"测不准原理"

如果你做过的AI项目超过三个，大概率经历过这样的场景：模型在离线评测集上一路过关斩将，准确率、F1、BLEU、Pass@k，所有数字都漂亮得不像话；CI流水线一路绿灯，PM拍着你的肩膀说"可以上线了"；结果上线第一天，客服群里就被用户骂声淹没，工单翻倍增长，老板在群里甩出那张著名的表情包："这就是你说的95%通过率？"

这不是段子，这是过去三年里大模型落地项目里最高频的翻车剧本。

问题出在哪？几乎所有团队在复盘时都会得出同一个结论——"模型不行"。但真相是：模型也许确实有改进空间，但真正失灵的，是评测体系本身。换句话说，你拿来给模型打分的尺子，从一开始就量错了东西。

本章的目的，是把这把"坏尺子"掰开揉碎，让你看清楚为什么大模型时代的评测，已经从一个"指标问题"升级成了一个"工程问题"。我们不会罗列评测指标清单（市面上这类内容已经够多了），而是直击一个更底层的问题：当我们说"这个模型不错"的时候，我们到底在说什么？

读完之后，你应该能拿到三样东西：

• 一套识别"评测幻觉"的诊断框架；
• 一份可以带回团队落地的"AI评测成熟度自检表"；
• 一个新的工作流范式——评测驱动开发（EDD）。

我们从经典软件测试讲起。

---

1.1 经典软件测试的"确定性假设"是怎么来的

要理解AI评测为什么这么拧巴，我们得先回到一个被绝大多数工程师视为理所当然的起点：经典软件测试的整套方法论，建立在一个极其优雅但极其脆弱的假设之上——系统行为是确定性的（deterministic）。

1.1.1 确定性假设的三层内涵

在传统软件工程里，这个假设通常被拆成三层来用：

第一层：给定相同输入，系统必然返回相同输出。

这是单元测试的根基。`sum(2, 3)` 在任何时刻、任何机器、任何线程下都应该等于 5。如果有一天它不等于 5，那一定是 bug，不是 feature。围绕这层假设，我们建立了 mock、stub、fixture、snapshot test 等一整套工具链。

第二层：系统的"正确行为"是可以被精确描述的。

函数有规约（specification），接口有契约（contract），业务有需求文档（PRD）。这些文档扮演着"绝对真理"的角色——测试用例本质上就是把需求文档里的"应该"翻译成可执行的断言。

第三层：系统的正确性是可枚举、可穷尽的。

至少在理论上，我们可以列出所有的等价类、边界值、路径组合，并通过有限（或经过精心设计的有限）的测试用例来获得足够高的覆盖率。即便做不到完全覆盖，覆盖率指标本身也被认为是有意义的——分支覆盖率越高，风险越低。

这三层假设合在一起，构成了经典软件测试的"确定性宇宙"。在这个宇宙里，评测 = 执行测试用例 + 对比预期输出。它是一个计算问题，不是一个工程问题，更不是一个哲学问题。

1.1.2 这个宇宙有多舒适

正是这套假设让现代软件工程得以规模化。我们可以写出上百万行代码，可以几十个团队并行开发，可以每天发布几千次，可以把"代码的可信度"外包给 CI/CD 流水线。背后的信念是：只要我测得足够多、足够细，系统的行为就是可预测的。

测试金字塔（Test Pyramid）就是这种信念的具象化：

• 底层是大量快速的单元测试（验证确定性的最小单元）；
• 中层是稍慢的集成测试（验证模块间契约）；
• 顶层是少量端到端测试（验证完整业务流程）。

每往上一层，速度变慢，成本变高，但确定性也在收敛。

1.1.3 AI 系统对这套假设的三连击

然后，深度学习来了，大语言模型来了，生成式 AI 来了。

确定性宇宙开始摇晃，并且不是地震，是海啸——三层假设被逐一击穿：

• **第一层崩塌**：你问同一个 LLM "北京今天天气怎么样？"，temperature=0.7 时它可能回答"晴转多云"，也可能回答"晴，气温 18-25 度"，还可能脑补一段"北京春天的风很大"——而且**三个答案在语义上都是合理的**。`sum(2, 3) = 5` 的安全感荡然无存。

• **第二层崩塌**：模型"应该"输出什么？没有 spec，没有契约，没有 PRD 写得清楚什么叫"好的摘要"、"得体的回复"、"有洞察的分析"。**价值本身变成了多维的、相对的、上下文相关的。**

• **第三层崩塌**：即便你愿意穷举输入空间，输出空间也是开放的、连续的、语义无穷的。**覆盖率指标失去了意义，因为"被覆盖"不再等价于"被验证"。**

当这三层同时崩塌，传统软件测试的工具箱几乎全部失灵。我们必须发明一套新的工具箱——这就是 AI 评测工程。

---

1.2 AI 评测的三大根本挑战

如果要用一句话概括 AI 评测和传统软件测试的本质差异，我会说：传统软件测试问的是"系统有没有做对"，AI 评测问的是"系统在大多数情况下是不是还可以"。

从"做对"到"还可以"，中间隔着三道鸿沟：输出随机性、价值多维性、分布漂移性。这三者构成了 AI 评测的"测不准原理"——你无法同时精确、稳定、可解释地测量一个 AI 系统的"好坏"。

1.2.1 输出随机性：当答案不再唯一

输出随机性指的是：对于同一个输入，模型可能产生多个语义上都合理但表面不同的输出。

这听起来像是个工程问题（"控制随机性"），但实际上是一个本体论问题——"正确答案"本身就不唯一。

举个例子。假设你让一个客服大模型回答用户的咨询："我买的鞋子还没到，能催一下吗？"

可能的好回答有至少三种风格：

• 简洁专业型："您好，已为您加急，预计 24 小时内发出。"
• 友好温暖型："别着急哈亲～我已经帮您催过了，仓库说最迟明天下班前就发出去啦！"
• 致歉补偿型："非常抱歉让您久等，已为您升级为顺丰，并附赠 10 元优惠券，请查收。"

三种回答都"正确"，但它们在语调、长度、附加动作上完全不同。如果你用 BLEU、ROUGE 这种基于 n-gram 重合度的指标去评测，模型 A 和 B 可能会因为一个没用上"您"字而被打低分。 但这有意义吗？没有。

更深层的问题在于：模型的"温度"（temperature）、采样策略、top-p、top-k 这些参数，会主动引入随机性以提升生成质量。换句话说，随机性不是 bug，是 feature。这意味着我们不可能通过"消除随机性"来解决问题，只能通过"理解并管理随机性"来应对。

工程上的应对通常有两条路径：

• **路径 A：把随机性固定下来**——评测时锁定所有采样参数，用期望值代替瞬时值，跑多次取平均。这条路能消除一部分噪声，但代价是抹掉了模型本身的生成多样性，而这种多样性恰恰是用户感知的核心。

• **路径 B：把随机性显式建模**——评测指标本身要能容忍合理的多样性。比如基于语义嵌入的 BERTScore、用 LLM-as-a-Judge 的偏好对比、人工评测中的 Likert 量表。这条路更贴近真实用户体验，但成本高、方差大、且评测本身也变得不确定。

1.2.2 价值多维性：什么算"好"，谁说了算？

价值多维性指的是：同一个输出，在不同维度上可能被评价为"好"或"坏"，且不同利益相关方对这些维度的权重完全不同。

我们用一个具体的例子。假设你的模型生成了一段营销文案："限时狂欢，全场五折，仅限今日，错过等一年！"

从营销转化角度看，这是教科书级别的文案——有紧迫感、有利益点、有行动号召。

从品牌调性角度看，这可能是一场灾难——过度促销、品牌廉价化、长期损害品牌资产。

从合规审查角度看，更要命的是，"仅限今日"如果实际不是"仅限今日"，可能涉嫌虚假宣传。

从用户体验角度看，对价格敏感型用户是福音，对品质敏感型用户可能是劝退。

这四个维度都对，但它们彼此冲突。 任何一个评测指标，如果只能反映其中一个维度，就必然在另外三个维度上失真。

更麻烦的是"谁说了算"的问题：

• PM 关心转化率；
• 老板关心舆情；
• 法务关心合规；
• 用户关心是否解决我的问题；
• 模型团队关心排行榜分数；
• 你，工程师，关心的是今晚能不能回家。

这些"关心"之间没有共同的标量刻度。试图用一个数字（比如 0.87 分）来概括这一切，本身就是一种过度简化。

工程上，这意味着我们必须从"单一指标"转向"指标体系"，并且这个体系必须包含：

• **多个独立维度的子指标**（避免相互抵消）；
• **每个维度的权重定义**（明确谁有最终拍板权）；
• **指标之间的冲突检测机制**（当一个维度的提升以另一个维度下降为代价时，自动告警）；
• **指标的可解释性**（每个数字都要能拆解回具体的样本和原因）。

但即使做到了这些，价值多维性还埋着一个更深的雷：这些权重本身会随时间变化。去年合规最重要，今年转化最重要，明年也许是用户体验。这是后面要讲的"分布漂移"的另一个侧面。

1.2.3 分布漂移性：你测的，真的就是用户用的吗？

分布漂移性（distribution drift）指的是：评测数据的分布和真实使用数据的分布之间存在系统性偏差，且这种偏差会随时间扩大。

这是三座大山里最阴险的一座，因为它是时间和空间的敌人。

时间维度的漂移：你三个月前构建的评测集，今天已经过时了。语言在演化（"yyds" 三个月前是火星文，现在是日常用语），用户行为在演化（疫情后大家开始习惯在线问诊，模型必须能处理新场景），世界知识在演化（昨天的"美国总统"和今天的不一定是同一个人）。评测集是一个静态快照，而世界是一个动态流。

空间维度的漂移：你的评测集通常是从内部场景构造的，但用户真实输入来自完全不同的人群、不同的设备、不同的意图分布。一个经典案例：内部测试时大家都规规矩矩问问题，线上用户会输入错别字、emoji、方言、甚至用反讽和陷阱题。

一个极端但真实的例子：某金融客服模型上线前测试集准确率 98%，上线后发现用户实际问的最多的问题是"你们贷款利息多少？""怎么投诉？""能不能给我返点？"——而这些问题在测试集中根本没出现，因为产品经理觉得"这些显而易见，不需要测"。测试集的盲区，恰好就是用户的高频区。

工程上的应对思路有三种：

• **思路 A：让评测集动起来**——构建"持续评测"（continuous evaluation）流水线，定期用线上真实流量（经脱敏和合规处理）回流，更新评测集。这条路最贴近真实，但成本高、合规风险大。

• **思路 B：让评测指标适应分布变化**——使用分布无关（distribution-free）的指标，比如基于排序的指标、基于样本对偏好的指标。这条路理论上优雅，但工程实现复杂。

• **思路 C：让评测本身成为产品的一部分**——把用户反馈、隐式信号（点赞/点踩、停留时长、二次询问率）整合进评测闭环。这条路最彻底，但要求跨职能协作。

无论选哪条路，都要接受一个事实：没有一劳永逸的评测集，只有持续运营的评测体系。

1.2.4 三座大山的叠加效应

这三座大山不是孤立存在的，它们会叠加放大：

• 输出随机性 + 价值多维性 = **指标噪声**：同一个答案在两个维度上得分的方差，可能比两个不同答案的方差还大。
• 输出随机性 + 分布漂移性 = **评测失稳**：今天的指标和明天的指标不可比，团队对"指标到底有没有变好"失去信心。
• 价值多维性 + 分布漂移性 = **目标漂移**：你以为你在优化用户体验，实际上你在优化一个过时的、对 PM 友好的代理指标。

当三者叠加，传统的"指标 + 测试集"评测范式就彻底失效了——你测出的数字，既不稳定（随机性）、不全面（多维性）、也不真实（漂移性）。

这就是为什么我们说，大模型时代的评测必须从"指标问题"升级为"工程问题"。下面我们用一个真实案例，把这三大挑战具体化。

---

1.3 "评测幻觉"案例：95% 通过率背后的故事

为了避免抽象讨论，我们来看一个虚构但基于多个真实项目改写的案例。我叫它"小 A 的客服大模型翻车事件"。

1.3.1 项目背景

2024 年初，某电商平台（姑且叫"买买买"）决定用大模型替换原有的人工客服系统。项目代号 "Atlas"，由小 A 担任技术负责人。项目周期三个月，目标是在双十一前上线。

小 A 是个非常靠谱的工程师。他在 GitHub 上有 2k stars，技术博客写得也不错。他之前做过搜索系统，对 Elasticsearch 和向量检索很熟。这次接到任务，他很快制定了一个"看起来无懈可击"的方案。

1.3.2 评测方案的设计

小 A 的评测方案分三层：

第一层：意图识别准确率。

他用 5000 条历史客服对话作为测试集，标注了 32 种意图（退款、催发货、投诉、咨询……），要求模型的意图分类准确率达到 95% 以上。

第二层：回复质量打分。

他用 LLM-as-a-Judge 的方式，让 GPT-4 给模型的回复打分（1-5 分），平均分不低于 4.0。

第三层：人工评测。

他找了 3 个实习生，对 100 条随机抽样的对话进行人工评估，要求"专业、友好、解决用户问题"。

小 A 还很贴心地准备了一个"金标答案库"——针对每个高频问题，写好"理想答案"，用 ROUGE-L 评分。

三管齐下，他对自己的评测体系非常自信。

1.3.3 模型训练的"完美"过程

训练过程非常顺利：

• 意图识别准确率：96.2%（超过 95% 目标）
• GPT-4 打分平均分：4.21（超过 4.0 目标）
• ROUGE-L：0.78（团队都说这个数字"相当不错"）
• 人工评测：3 个实习生全部给了"通过"

CI 流水线一路绿灯，PM 在周会上表扬了小 A，CTO 在群里点赞。一切看起来都像教科书。

1.3.4 上线后的灾难

上线第一天，投诉量翻倍。第二天，翻 3 倍。第三天，平台决定暂时下线 Atlas。

事后分析，小 A 复盘了整个事件。他发现自己的评测体系有三个致命缺陷——恰好对应着我们在 1.2 节讲的三座大山。

1.3.5 缺陷一：意图识别测试集严重过时（分布漂移性）

小 A 的 5000 条测试数据来自 2023 年上半年的历史对话。但 2024 年用户问得最多的问题，已经变成了：

• "我买的李佳琦直播间商品怎么没发货？"（直播带货相关新场景）
• "能不能用抖音支付？"（新增支付方式）
• "上次那个优惠券怎么找不到了？"（跨会话上下文问题）
• "你们和拼多多比哪个便宜？"（比价场景）
• "我要投诉你们 CEO！"（情绪发泄场景）

这些场景在测试集里几乎不存在。模型在这些场景下的表现完全是未知的，但通过率显示一切正常。评测集和真实分布的偏差，让 96.2% 这个数字变成了一个精心构建的谎言。

更深层的问题是：测试集的"过时"是悄无声息的。如果没人告诉你"用户问的问题变了"，你永远不会发现自己的测试集已经落伍。小 A 的 CI 流水线不会告诉他这件事——因为流水线只关心"今天的模型在今天的测试集上表现如何"，它完全不知道今天的测试集已经不代表真实世界。

1.3.6 缺陷二：LLM-as-a-Judge 的系统性偏差（价值多维性）

GPT-4 给的 4.21 平均分，听起来不错。但小 A 事后抽样了 200 条让真人复评，发现：

• GPT-4 给高分的回复里，有 38% 在真人眼里是"过度礼貌的空话"——比如用户问"运费多少"，模型回"亲，感谢您的咨询，关于运费问题我们一直致力于为您提供最优质的服务，运费是根据您的订单情况而定的哦亲～"。GPT-4 觉得"语气亲切、信息完整"，真人觉得"什么都没说"。

• GPT-4 给低分的回复里，有 22% 在真人眼里反而是"简洁专业的优秀回复"——比如用户问"运费多少"，模型回"10 元，包邮地区免运费"。GPT-4 因为没有"亲"字扣了分，真人觉得这就是标准答案。

• GPT-4 对"长回复"有显著偏好，平均长度比真人偏好长 47%。这导致模型学会了"用废话填充"来骗高分。

GPT-4 作为一个裁判，它有自己的一套价值观（某种"礼貌平均主义 + 信息堆砌"），而这套价值观和"买买买"平台想要的用户体验并不一致。 LLM-as-a-Judge 不是说不能用，而是说它本身就是一个有偏好的模型，需要校准（calibration），需要和真实用户反馈对齐（alignment）。

小 A 的问题是：他把 GPT-4 当成了"绝对裁判"，而不是把它当成一个"有偏好的、需要被监督的中间评估器"。

1.3.7 缺陷三：人工评测的样本偏差（输出随机性 + 分布漂移性）

3 个实习生的 100 条人工评测，看起来很认真。但小 A 事后发现：

• 100 条样本是从**测试集**里随机抽的，不是从**线上流量**里抽的。这意味着它们也不能代表真实场景。
• 实习生是计算机相关专业大三学生，他们的"友好"标准和真实用户不一致（用户觉得太"端"了，实习生觉得"专业"）。
• 3 个实习生之间的一致性（inter-annotator agreement）只有 0.41（Cohen's Kappa），远低于"可信"标准的 0.7。这意味着他们对"好"的定义本身就存在巨大分歧。
• 更糟糕的是，模型对同一个问题会生成不同回复（temperature > 0），实习生只看到了一条回复就下判断，根本没考虑到"也许换一种采样参数结果会完全不同"。

人工评测的最大谎言是：几个人看了一百条数据，就敢说"这个模型合格了"。 在随机性、多维性、漂移性同时存在的情况下，100 条样本能给你提供的信号极其有限——可能连 50% 的置信度都达不到。

1.3.8 复盘结论

小 A 在复盘文档里写了一段后来被无数团队引用的话：

> "我们以为我们在做评测，其实我们是在做'让评测看起来不错'。所有指标都在涨，但所有指标都在骗我们。95% 的通过率，是一个被精心保护的幻觉。"

这个案例不是要嘲笑小 A——小 A 的方案在传统软件测试的框架里是合理的。问题在于，他用错了工具。

传统软件测试的尺子（确定性 + 单维度 + 静态测试集）量不出 AI 系统的真实质量。要量出来，需要的不是一把更精确的尺子，而是一套多维、动态、可校准的测量系统。

---

1.4 从"指标"到"系统"：评测范式的范式转移

如果说 1.2 节讲了"为什么难"，1.3 节用一个案例具象化了"难到什么程度"，那么这一节我们要回答一个更建设性的问题：那我们到底应该怎么做？

答案可以用一句话概括：**把"评测"从一个名词变成一个动词，从一个结果变成一个过程，从一组指标