给 AI 应用做评测,最难的是不自欺

你给 AI 应用加了个新改动，离线评测涨了好几个点，上线后用户毫无感觉。问题大概率不在模型，而在评测本身。Anthropic 最近发了一篇文章，把「设计可信评测」和「对着评测优化而不自欺」这两件事的原则讲透了，还把它们做成了 Claude Code 里 claude-api skill 的两个命令。这篇帮你把要点拆出来。

好评测长什么样

文章给好评测列了四个判据，条条都能落地检查。

任务要镜像生产。 选案例的唯一标准是你在线上真正在乎的场景，而不是「容易生成」或「容易打分」。按后者选，测出来的是采集便利性，不是能力。

更强的模型应该得更高的分。 如果换了更强的模型、调高了 effort 档位，分数反而不动，多半是任务有歧义，或者评分器失准在拖累。

前沿要留余量。 最强模型加最高 effort 应该明显低于 100%，分数饱和了，任何改动的好坏都分辨不出来。但余量必须来自真难题，典型征兆是某个任务不管重复跑多少次都失败，那说明题目本身有问题。

跑与跑之间方差要低。 方差高的来源包括任务歧义、评分器对同一输出给不同判定、配置没生效，还有环境残留。文章特别点了一句，上一次试验留下的一个文件、一段 git 历史，都可能把答案直接递到 agent 手上。

A good task is one where two domain experts would reach the same verdict and everything the grader checks is stated in the task.

一个好任务是，两位领域专家会得出同样的判定，且评分器要检查的一切都在任务描述里写明了。

两个最隐蔽的自欺陷阱

第一个叫对抗式采样。模型能力是锯齿状的，如果你因为今天的模型做不对某道题就把它收进评测，实际是在采样这个模型能力面的谷底。评测最后度量的是这个模型的失败指纹，不是你应用真正的难点。正确做法是人类能说出这题为什么难才收录。另外别盲信用户流量，用户只尝试他们预期会奏效的东西，纯按用户流量取的任务分布会偏简单。

第二个叫 harness 过拟合。harness 指环绕模型的代码，包括 prompt、工具和调用循环。文章举了个例子，某评测任务受益于 OCR 而生产里几乎用不上，优化器就给你的应用加了个 OCR 工具，基准分涨了，生产没变化。防线有三条，把案例拆成优化器可读的 train 集和从不示人的 test 集，train 涨 test 平就是警报；绝不把失败转录的内容贴进 prompt；把评测答案在结构上隔离在模型够不到的地方。

两个命令，把原则变成流程

/claude-api build-eval 负责建评测。它先访谈你，再按优先级采样输入，顺序是生产转录、bug 报告与工单、你手写的 5 到 10 条案例、最后才是锚定在真实样例上的合成案例，生成确认页等你点头才继续。评分器选能胜任的最便宜款，输出空间受限用程序化校验，开放输出用 LLM-as-judge，评分规则要写成可逐条核查的论断而不是 1 到 5 的模糊打分，裁判模型不能是被测模型本身。选好后它会先对少量案例打分，再问你一句这些分你认不认，不看已评分的转录样本就相信评分器，是评测配错最常见的来源之一。跑完基线它还顺带做三类体检，评分器自洽性、管道健康（超时、报错、截断）、余量够不够，基线已经约 95% 以上它会提醒你把目标转向成本或延迟。

爬坡也不是哪儿都能爬。文章给优化面定了三条标准。改动要廉价，prompt、skill 这类文本改起来和回滚都便宜，对 harness 做开放式修改涉及大量代码变更，容易停滞。效果要可归因，分数变化要能对应到你在改的那个东西，skill 触发率优化就是正面例子，改什么测什么。目标要良界定，开放式地提升性能在评测接近饱和时最容易失败，而一个跨场景都强的目标是成本，哪怕评测饱和了，也能要求性能持平的前提下降成本。

/claude-api hillclimb 负责爬坡。先问你的优化目标，随机拆 train/test，首轮前先验证评测噪声小于你愿意行动的最小改进。每轮只提一个补丁，train 涨 test 平就怀疑过拟合并回滚，有回归就回滚，双双提升才保留。分数停滞两三轮，或者早到没有任何单点修复能超过噪声时，它进入一个只分类不编辑的反思轮，把剩余失败按根因分桶，能暴露歧义案例和 harness 错误。收尾时代码停在 test 集最优的版本，报告带置信区间，增益落在噪声内它会直说并建议不要合并。

实测效果怎么样

成本方向，一个 44 张客服工单的基准，其中 30 张参与搜索优化、14 张留出。起步是 Opus 4.8 高 effort，在 30 张搜索工单上决策准确率 74.4%、每张 4.6 美分。先清理 prompt 里强制工具调用仪式和自相矛盾的规则，再换 Opus 5.5 低 effort 到 87.8%、1.9 美分，接着降到 Sonnet 5 低 effort 的 88.9%、1 美分，最后补路由规则和退款上限交叉引用到 98.9%。在 14 张从没参与优化的留出工单上，最终配置 90.5% 对初始配置的 78.6%，成本约五分之一。

性能方向，claude-api skill 自己的评测从 66% 起步。补上 8 个缺失特性到 74%，修 C# 和 Java 类型表到 77%。停滞后反思轮发现内容其实在，只是模型在写训练先验里的旧 API 形状，于是在 skill 顶部加了一张新旧对照表，到 80%。又发现几道题其实是示例或评分器本身有缺陷，比如任务要求捕获一种错误类型而评分器要求至少三层，修完到约 88%。

看完最大的感受是，评测不是一次性搭好的基建，它和被测系统一样会被污染、会过拟合，得像对待生产代码一样对待它。你搭过自己的 eval 吗，踩过哪些坑，评论区聊聊。觉得有用的话点个关注，后面继续拆 agent 工程化的实操文章。

原文 Lance Martin《Automating eval design and hillclimbing with Claude》 https://claude.dev/blog/automating-eval-design-and-hillclimbing/

#AI评测 #EvalDesign #ClaudeCode #Agent开发 #LLM应用工程 #Hillclimbing