FRONTIER · 工程实践
把「感觉变差了」变成可以测的东西
Demystifying Evals for AI Agents
Anthropic 工程团队
构建 Claude Code 与 MCP 的同一支工程团队
为什么选它做 AI 产品迟早会撞上的那堵墙:改了个提示词,用户说「感觉变差了」,而你无法证实也无法证伪。这篇讲怎么把「感觉」变成可以争论的数字,而且反复提醒你别把分数当真。
做 AI 产品的人迟早会撞上同一堵墙:改了个提示词,用户说「感觉变差了」,而你除了挨个手动试之外无法证实也无法证伪。这篇文章讲的就是怎么走出这个循环——评测不是上线前的例行检查,而是把「感觉」变成可以争论的数字的唯一手段。
最实用的一条建议是别把评测想得太重:从真实失败里挑 20–50 个任务就足以起步。早期每次改动的效果都很明显,小样本就够用;系统成熟了再扩。反过来,拖得越久越难做——早期产品需求可以直接翻译成测试用例,拖到线上再补,就变成从一个活系统里反推「什么算成功」。
具体设计上几条经验值得记。任务要写到两个懂行的人独立打分能得出同一个结论,含糊的任务只会变成指标里的噪声。打分优先用确定性的代码校验,用模型打分则要定期跟人工校准。别去检查它走了哪条路——规定工具调用顺序太脆,智能体经常找到设计者没想到的合法解法,该评的是产出而不是路径。题目还要正反都有:只测「该搜索时有没有搜」,你会训出一个逢事就搜的智能体。
最值得记的一段是提醒你别把分数当真。Opus 4.5 在 CORE-Bench 上一开始只拿到 42%,查下去发现问题全出在评测本身——期望答案写死成一个精确数值、任务描述有歧义、部分任务根本无法复现;修好之后分数变成 95%。METR 也发现自己的题目让模型「达到某个阈值」,判分却要求「超过阈值」,结果老实听话的模型反而被扣分。
怎么用它。这篇和第 14 篇是同一套价值观:先把可验证的东西定下来,再谈复杂度。它对非工程岗也有直接用处——写评测任务本身就是在逼产品需求变具体,一条含糊的需求根本写不成一道能判分的题。最该照做的是文章反复强调的那句「读记录」:分数只告诉你过没过,只有翻开完整的执行过程,你才知道是模型做错了,还是你的判分逻辑冤枉了一个正确解法。
去读原文
本文是原创导读,不是原文翻译——真正的细节、证据和微妙之处都在原文里。
原文Anthropic Engineering · Demystifying Evals for AI Agents →
本文为 AKL AI Club 原创撰写的导读,不是原文翻译;著作权归原文作者所有。 篇目由编辑独立选取,来源均经人工核实。