为什么AI基准测试漏掉了90%的真实工作

我有个朋友负责一家中型物流公司的运营。去年春天，她的团队花了三周评估能不能让LLM接手他们的异常处理流程，也就是那些没人愿意干的活：对账三个彼此不兼容的系统里对不上采购订单的发票。供应商的演示稿上全是漂亮的数字：MMLU、GSM8K、HumanEval，外加一堆智能体基准。模型在每个标准测试里都拿了高分。可等他们拿一周的真实异常数据去跑，模型却自信满满地把一张14000美元的发票匹配到了错误的采购订单上，原因只是某个供应商的简称写法不一样。这种问题，任何排行榜都测不出来。

这种差距现在已经可以量化了。最近有研究把公开的AI基准与美国劳工部的O*NET职业分类体系做了映射。这套体系涵盖美国全部923种职业和18797项构成美国就业的任务。结果发现，美国90%的工作时长都花在几乎没有或完全没有基准覆盖的任务上。923种职业中，只有208种至少有一项任务被五条以上的基准提示词覆盖。22个职业大类中有6个一条基准都没有。由此得出的结论并不让人舒服：问题不在于AI能力弱，而在于我们衡量AI能力的工具几乎全都对准了经济中的错误部分。

AI基准真正覆盖了什么

这项映射研究的方法值得仔细看看，因为它比标题听起来严谨得多。研究者选取了29个高质量、尚未饱和的智能体基准。这些测试要求模型真正完成工作，而不只是回答问题。然后他们用一个经过人类专家验证的LLM裁判，给每条基准提示词标注它所考察的O*NET任务。一项任务只有在至少五条提示词与之对应时，才算“已覆盖”。再结合每项任务大致占用的工作时间估算，就得到了一张全经济范围的图景，展示我们的评测体系到底能看见什么。

它能看见的东西窄而高，并不宽广。软件工程和金融分析几乎被基准测试填满了。卡车驾驶、燃气电厂运营、餐饮服务，以及大部分医疗日常工作，基本处于隐形状态。而且这种偏斜不只是因为哪些任务在技术上更容易自动化。被标记为“AI高暴露”的任务，被做成基准的概率大约是非暴露任务的六倍，这倒也合理。但即便控制了这个因素，那些职业工资总额很大的任务仍然明显被过度代表。律师的任务覆盖得很多，而面临类似AI暴露风险的法律秘书和法院书记员，几乎没怎么出现。

再读一遍：我们拿AI去对标的，是一份工作体面的那一版，却忽略了大多数人真正从事的那一版。中等收入的知识型工作长尾，比如协调员、文员、专员和排班人员，他们的工作时长加起来占了经济的很大一块，却几乎没有任何测量基础设施。每当有人宣称AI能完成某个百分比的“知识工作”，都应该追问：是哪种知识工作，怎么测的，对照的是哪份任务清单？诚实的回答通常是：一小片单薄、缺乏代表性的切片，用为研究论文设计的测试来衡量。

基准饱和是评估设计的失败

我做过好几年评估流水线，最难忘的教训是：基准本质上是对世界的一种建模，而大多数基准是很糟糕的模型。它们把一个杂乱、依赖语境、多步骤的人类任务压缩成一条带有可检查答案的干净提示词，因为这样最便宜、最好打分。接下来古德哈特定律就开始起作用了。一旦某个基准成为模型开发的目标，它就不再衡量它原本想代理的能力了。训练数据把测试分布吸收进去，团队针对排行榜调优，分数节节攀升，真实表现却原地打转。

饱和只是表面症状。当每个前沿模型在某项测试上都超过90%时，这项测试就已经失去区分度了。但更深层的问题在于，我们的应对方式是再造一个风格相同、覆盖同类任务的基准，因为这些任务是我们知道如何自动打分的。多选题问答催生了更难的多选题问答，编程挑战催生了更难的编程挑战。与此同时，却没人去做“发现这份合同的赔偿条款悄悄与3月的条款清单相矛盾”这类基准，因为给它打分需要律师、时间和需要判断力的决定，而这些恰恰抗拒自动化。

所以我不同意“基准饱和意味着AI已经攻克了某个领域”这种说法。饱和只说明测量工具已经顶到头了，就这么简单。一支温度计显示40°C并不能证明房间温度就是40度，它只证明你需要换一支温度计。如果你要为生产环境评估模型，尤其是在构建那些出错代价很高的基于LLM的决策系统，那么在饱和基准上的排行榜差距，在你的决策中几乎不该占任何权重。

我们非常清楚模型在我们决定衡量的那部分工作上有多好。而对于另外那90%，我们几乎一无所知。

AI评估中的路灯效应

有个老笑话说，一个醉汉在路灯下找钥匙。他不是在那里丢的，而是因为那里有光。基准的构建遵循的正是同样的逻辑，而数据也证实这并非偶然。映射研究发现，一项任务在其职业中的重要程度，会预测它被覆盖的概率：被O*NET评为对所属职业最重要的任务，被做成基准的可能性是最不重要任务的六到十倍。乍听之下，这像是合理的优先级排序。实际上，它意味着我们只测那些拿得出手的展示性任务，而略过了把工作串联起来的部分。

每份工作的主体其实都是那些串联性的部分。一名软件工程师被纳入基准的任务是“实现一个能通过这些测试的函数”。而他们一天的实际工作还包括：读懂同事写了一半的迁移脚本，弄清楚哪个干系人真正拍板这个决定，发现工单描述的其实是错误的问题。我之前写过智能体编程工具为何会在这一点上成败分明：循环机制、上下文和权限边界，比原始生成质量重要得多。这些在HumanEval式的分数里一点都看不出来。

覆盖率数字本身还存在一个微妙的定义问题。“已覆盖”的意思是有五条或更多提示词对应到某项任务，而不是说这五条提示词就捕捉到了这项任务。关于如何指导家长处理孩子教养问题的十三条提示词，并不能代表社工在一整个个案负荷、法庭和家访中实际要做的事。如果用普通人对“覆盖得好”的理解来衡量，那么经济中被测量的份额就不是10%，而是接近零。路灯不仅照得窄，它投下的光也很薄。

模型会生成，但没人测判断力

这是我觉得最致命的不对称。现存几乎所有基准测的都是产出：写代码、起草备忘录、解决问题。但大多数真实任务中，经济上最关键的那一半其实是检测：发现错误、标记不一致、识别出那个自信满满的答案其实是错的。初级会计的价值不在于做出一份对账表，而在于察觉某个数字“不对劲”。基准几乎从不测这一点，因为设计一个可打分的错误检测任务，比设计一个可打分的生成任务难得多。你需要逼真的有缺陷的材料，需要看似合理却暗藏问题的细微之处，还需要人类对“什么算被发现”达成一致。

这就是把门人谬误在评估设计上的翻版。用自动门替换门童，你会在为时已晚时才发现，门童还在迎接住户、代收包裹、留意街上的动静。把工作中可被基准测量的部分自动化，你会发现那些未被测量的部分其实是承重墙。我那位做物流的朋友，她的模型能写出很棒的对账说明，这是看得见的任务，却在匹配环节悄悄出错，而正是那个匹配判断让这些说明值得写。评测套件给了配菜打分，却忽略了正餐。

在错误检测得到一流的基准待遇之前，你应该预期演示表现与实际部署表现之间会持续存在差距。这和规格说明与实际实现之间的差距是同一类问题，而软件里的情况也一样，故障恰恰滋生在这道缝隙里。一个生成能力处于第90百分位、验证能力却只有第30百分位的模型，在生产环境里，其实就是一个打字快一些的第30百分位员工。

按真实任务分布为评测加权

在基准映射这项工作中，最实用的思路也是最简单的：如果基准过度代表了某些任务，那就别再对提示词取平均，而是对任务取平均，并按每项任务实际占用的工作时间加权。把所有被标记为“金融分析师”的提示词简单平均，结果会被那个恰好拥有最多基准提示词的任务主导，通常就是最容易构建数据集的那个。而按O*NET加权的平均，则让每项真实任务都有同等的份量。两者的差异可能非常惊人。

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

这段代码片段里有两点值得注意。第一，加权后分数下降，是因为模型最弱的任务在提示词池中本就代表性不足，这正是简单平均所掩盖的失真。第二，也是更重要的一点：“为客户提供建议”这项任务在计算中完全消失了，因为没有任何提示词对应它。任何加权方案都会悄无声息地丢掉零覆盖的任务，而零覆盖恰恰是经济中大多数领域的常态。加权能解决权重问题，却解决不了数据缺失的问题。这需要的是构建新的评测，而不是对旧评测重新求平均。

如何用AI评估你真正在做的工作

如果你正在选择或部署模型，这种全经济范围的覆盖缺口有一个很具体的含义：除非你的场景恰好落在那一小块明亮的角落里，否则公开基准对你的用例只是一个很弱的先验。所以，建立你自己的那块角落吧。这听起来没那么宏大，而且远比相信供应商的演示稿可靠得多。

• 从日志中抽取任务，而不是凭空想象。拉取一周的真实工单、邮件或异常记录，按频率抽样。你的评测集应该与你的工作负载直方图相吻合，包括那些枯燥的长尾，而枯燥的长尾恰恰是大部分工作。
• 按时间或成本加权，并同时报告两个数字。简单平均和加权平均共同界定了真相的范围。如果一个模型在简单平均中胜出，却在加权平均中落败，说明它擅长的是容易测试的任务，而这正是你需要筛查的失效模式。
• 加入验证类任务。拿真实的输出，包括已知有错的输出，考察模型能否发现预设的错误和自然出现的错误。在我的经验里，检测能力和生成能力几乎不相关，而检测能力才是你真正要购买的东西。
• 保留一个私有集，并定期更新。任何被你复用数月的评测，都会在有人开始针对它调整提示词的那一刻变成训练目标，即使这并非有意为之。建议每季度轮换一次案例。
• 尽可能以端到端结果评分。如果任务是“对账这张发票”，那就评判对账结果本身，而不是中间的文字说明。中间指标对模型的美化，就像缺乏集成测试覆盖的单元测试对代码的美化一样。

还有一个更隐蔽、值得点出的效应，每天使用AI编程工具的人应该都有体会：微观尺度上的鲍莫尔成本病。当生成速度快了二十倍，你并不会把一天都花在生成上，而是花在那些没有变快的部分上：审阅、协调、验证、决策。未被测量的剩余部分不会随着AI的进步而缩小，反而会填满腾出来的时间，并成为决定这次AI部署是否值得的更大因素。用越来越高的精度去测量可自动化的那一小块，同时无视剩下的部分，这不仅仅是不完整，它还把重要性整个颠倒了。

我并不是要说AI的进展是假的。能力的提升是真实的，我也把项目押在了这些进步上。我想说的是，我们的测量文化对准的是错误的分布。基准是在提示词容易编写和打分的地方被建立起来的：代码、数学、考试式的知识问答。而经济大体上并不是这个样子。在评估跟上之前，请把每一个能力宣称都当作对地图上那明亮十分之一的描述，然后去构建覆盖你自己那黑暗九成的评测。那些愿意做这种枯燥、不起眼的测量工作的组织，会比everyone刷排行榜的人做出更好的部署决策，而且差距不会小。