Real-World Evals：为什么 GDPval 比刷榜更值得看
flowchart LR
A["公开 Benchmark"] --> B["能力门槛"]
B --> C["真实任务样本"]
C --> D["专家/用户验收"]
D --> E["成本与风险"]
E --> F["上线决策"]公开 benchmark 像高考分数，能筛掉明显不行的人；但你要不要把一个 Agent 放进公司工作流，看的应该是它能不能交付你要的东西。GDPval 的意义就在这里：它把“AI 输出像不像真实工作产物”放到了评测中心。
出处与延伸阅读：
这篇文章会讲什么
078 Agent Benchmark 横评 已经梳理过 SWE-bench、OSWorld、WebArena、SWE-Lancer 等公开榜单。本文往前走一步：当公开榜单开始接近天花板，企业和产品团队该怎么评估“这个 Agent 到底有没有用”。
核心观点很简单：
2026 年的评估重点，正在从“模型会不会做题”转向“系统能不能交付真实工作”。
先说结论
- 公开 benchmark 仍然有用，但只能当门槛。SWE-bench、BrowseComp、OSWorld 适合做能力筛选，不适合直接做上线决策
- GDPval 的价值在于交付物。它评的是法律简报、工程蓝图、客户沟通、护理方案这类真实工作产物，而不是选择题
- 评测对象应该是系统，不只是模型。模型、prompt、工具、runtime、权限、检索、验证器都算进来
- 私有 eval 是必做项。没有一套自己的 30 到 100 个真实任务样本，选型基本是在猜
- 最重要的指标不是分数，而是失败类型。知道 Agent 为什么失败，比知道它多少分更有用
1. 公开榜单为什么不够了
公开榜单有三个天然问题。
1.1 它们会被刷到接近天花板
SWE-bench Verified 之所以重要，是因为它来自真实 GitHub issue，而且有人工验证子集。但当头部模型和 agent scaffolding 都围着它优化，分数差距会越来越小。
这不是 benchmark 的错。任何好 benchmark 一旦成为行业共识，都会逐渐被工程化吸收。
1.2 它们测的是“题”，不是“岗位”
BrowseComp 测浏览找信息，SWE-bench 测代码 patch，OSWorld 测 GUI 操作。这些都很重要，但真实工作通常还包括：
- 需求澄清
- 判断取舍
- 和人协作
- 对模糊目标负责
- 处理组织规则
- 承担错误后果
公开 benchmark 能测一部分能力，但不能代表完整工作。
1.3 它们和你的业务不一定相关
一个模型在 Python issue 上很强，不代表能改你的 Java monorepo。一个 GUI Agent 在 Ubuntu 办公软件上能跑，不代表能操作你的内部 ERP。
这就是为什么公开榜单只能帮你缩小候选，不应该替你做最终决策。
2. GDPval 真正新在哪里
GDPval 的思路值得单独写一篇，是因为它把评测对象从“答题”换成了“交付物”。
它覆盖的是美国 GDP 中较大行业里的 44 个职业，任务由有经验的行业人士撰写，输出也不是单行答案，而是更接近工作现场的材料，比如：
- 法律/合规简报
- 工程或业务分析
- 医疗护理计划
- 客户支持回复
- 市场研究
- 运营文档
评估方式也更接近现实：行业专家盲评 AI 产物和人类产物，比较哪一个更好。
这个设计很有启发，因为它没有问“模型会不会某个知识点”，而是问：
这个东西拿给专业人士看，像不像一份能交差的工作？
3. GDPval 也不能被误读
GDPval 很重要，但它不是“AI 替代岗位比例表”。
几个边界要说清楚。
3.1 它评的是任务，不是岗位
一个职业有大量工作不在单个 deliverable 里：
- 开会
- 说服
- 背锅
- 判断风险
- 和客户建立信任
- 在信息不完整时做决定
GDPval 测的是专业产物质量，不是完整岗位替代。
3.2 它不等于自动化 ROI
即使 AI 输出质量接近专家，也还要算：
- 人类 review 成本
- 集成成本
- 安全与合规成本
- 错误代价
- 用户是否愿意接受
企业里真正的 ROI 往往卡在这些地方。
3.3 它仍然会随模型和任务变化
GDPval 是一个更接近现实的方向，但不是永恒答案。随着模型提升、任务泄露、行业变动，它也需要更新。
正确用法是：把它当成“真实工作评测的范式”，而不是只盯一个数字。
4. 怎么自建 Real-World Eval
如果你做的是一个企业 Agent，我建议这样建私有 eval。
4.1 选 30 个真实任务
不要从脑子里编题。直接从过去一个月的真实工作里抽：
- 客服工单
- 销售邮件
- 代码 issue
- 数据分析请求
- 法务审查片段
- 运营报表
- 产品需求澄清
第一版 30 个就够。重点是样本真实。
4.2 给每个任务写验收标准
每个 case 至少写三项：
成功条件：
1. 必须输出哪些内容
2. 哪些错误不可接受
3. 什么情况下需要请求人类确认不要只写“回答要好”。这没法复现。
4.3 保留人类基线
让一个熟悉业务的人做同样任务，记录：
- 花了多久
- 交付物质量
- 是否需要多轮沟通
- 哪些地方靠经验判断
没有人类基线，AI 分数很容易失真。
4.4 记录失败类型
失败要分类，而不是只算错。
| 失败类型 | 说明 |
|---|---|
| 事实错误 | 编造、过时、引用错 |
| 工具错误 | 调错工具、参数错、没看结果 |
| 权限错误 | 做了不该做的动作 |
| 格式错误 | 交付物不符合工作流 |
| 任务理解错误 | 做偏了 |
| 验证失败 | 说完成但没有证据 |
| 成本过高 | 做对了但太贵太慢 |
这些分类会告诉你下一步该改什么。
5. 评测要测系统，不只测模型
同一个任务，下面这些变量都会影响结果：
- 模型
- prompt
- RAG 资料
- MCP 工具质量
- Agent Runtime
- 权限策略
- 检索召回
- verifier
- 是否允许重试
- token / 时间预算
所以评测报告里应该写清楚：
model: gpt-5.5-thinking / claude-sonnet-4.5 / ...
tools: web, file_search, internal_crm
max_steps: 20
human_confirmation: enabled for L3+
retrieval: internal docs v2026-05
verifier: unit tests / expert rubric / state check否则一个“80%”没有意义。
6. 和模型路由的关系
102 模型路由 会讲一件事：2026 年不太应该把所有任务都扔给同一个模型。
Real-World Eval 正好是路由的依据。你可以用私有 eval 得到这样的策略：
| 任务 | 默认模型 | 何时升级 |
|---|---|---|
| FAQ / 低风险摘要 | 便宜快模型 | 低置信度或用户追问 |
| 代码改动 | coding model | 测试失败 2 次 |
| 法务/合规 | 高推理模型 | 默认高等级 |
| 多工具长任务 | agentic model | 工具失败或权限冲突 |
| 敏感动作 | 模型无关 | 必须人工确认 |
换句话说，eval 不只是选模型用，它是 runtime 决策的一部分。
7. 一个现实的评测节奏
对一个小团队来说，不需要一开始就搞大型 benchmark 平台。
建议节奏：
- 第 1 周：收集 30 个真实任务，写验收标准
- 第 2 周：跑 2 到 3 个候选模型/Agent，人工评分
- 第 3 周：把失败最多的 10 个 case 固定成回归集
- 第 4 周：接入 CI 或 nightly run，追踪趋势
- 每月：新增 10 个真实失败样本，淘汰过时样本
这样做一个月，团队对 Agent 的判断会比看 20 篇榜单文章靠谱得多。
小结
GDPval 最值得记录的地方，不是某个模型赢了多少，而是它把 AI 评测带回了一个更朴素的问题：
这份东西，真实工作里能不能用？
公开 benchmark 仍然重要，但它们更像体检表。你要把 Agent 放进业务里，最终还是要看真实任务、真实交付物、真实成本、真实风险。
2026 年做 AI 产品，如果没有私有 eval，就像没有日志、没有测试、没有监控一样。能跑，但不该放心。