先说我们为什么被迫干这件事。

2026 年 4 月，一家模型厂商的客户经理通知我们：项目用的那个模型版本，第三季度下线。要么升到他们的新版，要么换供应商。上次换模型我们吃过亏——prompt 一字没改，抽取准确率从 96.4% 掉到 87%，排查花了一周。这次我们学乖了，动手升级之前先建了一套评测集。

这篇讲评测集怎么建、怎么跑、以及几个我们踩过的坑。适合手里有智能体项目、马上要面临模型下线或升级的人。

评测集不是随机抽题

最直觉的做法是从历史请求里随机抽几百条。我们一开始就是这么干的，300 条，跑出来的分数很漂亮：新版模型 89.6 分，旧版 88.1。差点就照这个结论升级了。

后来发现问题：随机抽样里 87% 都是"好答的常规题"。真正会让模型翻车的——时间歧义、两张表口径不一致、客户说了不该答的话——在随机样本里占比很低。平均分掩盖了回归。

推倒重来，按错误类型分层抽：

最终 328 题。坑题 65 条，全是真实事故：比如"上季度的销售额"没定含不含退货、比如客户上传的 Excel 表头在第 3 行（前两行是合并单元格的标题）、比如一句"帮我把上个月张经理那几个店的数拉一下"——"张经理那几个店"在主数据里对应 4 家门店但系统里查不到"张经理"这个字段。

坑题层是整个评测集最值钱的部分。随机抽题测的是模型会不会，坑题测的是它死不死。而且坑题是活的——每线上纠错一次，就往里加一条，这个集子越用越毒。

评分怎么自动化

抽取类好办：结果和标准答案做字段级比对，全对得 1 分，错一个关键字段得 0.5，编造字段得 0。

麻烦的是问答和生成类，没有唯一标准答案。我们用 LLM 打分（拿一个强模型当裁判，1-5 分），但这里有两个坑必须说：

第一，裁判模型自己也有偏向。 我们拿 20% 的题目做了人工复核对账：裁判给"格式更工整"的答案打分偏高，哪怕内容有漏。后来裁判的评分提示词里明确加了"格式不计分，漏项扣分优先"，对账才基本拉平。所以规则是：LLM 打分必须抽 20% 人工复核，不复核等于没打。

第二，裁判模型不能用被测模型的同家族。 同家族模型互相打分有系统性偏高，我们对比过两家的裁判结果，自家模型给自家答案平均高 0.4 分。裁判用固定的第三方，别图省事。

跑一次多少钱，怎么跑进流程

328 题，全量并发跑，26 分钟，API 花费 37 块钱。这个成本意味着它可以当日常工具用，而不是"大版本才舍得跑一次"的仪式。

我们的节奏：

• 每次改 prompt、调检索参数：跑全量。CI 里挂了个脚本，prompt 文件一提交自动触发，分数变动超过 1 分报警
• 每周固定跑一次：防上游模型偷偷热更新——这事真遇到过，同样的问题一周后答案变了，啥都没改
• 模型升级评估：全量跑 + 坑题层单独看

坑题单独看很关键。上次那个新版模型，总分 +2.1，看着是进步，但坑题层从 62 分掉到 49 分——升级修好了 20 道常规题，弄坏了 9 道曾经翻过车的题。就凭这个我们跟厂商拉扯了六周，要求他们确认那 9 类问题在新版的行为，或者给个降级开关。

评测集自己的坑

它不是一劳永逸的，有两个维护成本必须提前知道。

答案会过时。 6 月里业务把"销售额"的口径改了（从含税改成不含税），评测集里十几道题的标准答案一夜之间全错了，CI 突然全员报警，吓得我以为是 prompt 出了问题。现在每月第一天花半小时人工过一遍题目清单，口径相关的题标了"依赖口径表 v2026.06"这种版本号。这活儿枯燥，没人愿意干，但跳过就会出上面那种狼来了。

坑题会失效。 曾经的坑，比如表头不在第一行，在 prompt 里加了两行处理规则之后，这道题就变成送分题了，测不出新东西。我们的做法是不删（防回归还是有用的），但每隔一阵把"已经连续 8 次全对"的坑题移进常规层，再从新事故里补坑题进来。

最后

那次模型下线的事，最后是升级了，但不是按厂商给的时间表——是我们拿着评测报告里那 9 类问题，等厂商修复到 6 类之后才切的全量。上线当天一切照旧，没有再出现上次那种一周的排查。

要说这套东西的成本：建集子 5 个人日，加上每月半天维护。换来的是每次改动心里有底。智能体项目最难受的不是模型不行，是你不知道它什么时候悄悄变不行了。评测集就是干这个的。

另外说句实话：这套东西做出来之前，我们内部也有争论，有同事觉得 328 题太少没有统计显著性。真做下来我的体会是——评测集的价值不在精确，在于每次改动前后有个同一把尺子。尺子不必完美，但必须固定。