评测集漂移：为什么我们每周的模型排名会悄悄换位

上个月我们盯着一份跑了两周的评测结果，发现一个尴尬的事实：同一批模型，上周 A 排在 B 前面，这周 B 反超了。分数差 1.7 分，工程师们争论了一下午，谁也说服不了谁。

我们花了三天排查，最后确认：不是模型变了，是评测集变了。

问题出在哪

我们的评测流程是这样的：客户场景脱敏后整理成问答对，每周由一位工程师手动补充新案例。看起来挺合理——评测集应该跟着业务走。

但问题恰恰在这里。"跟着业务走"意味着每周的评测分布都在变：周一补的案例偏咨询类，周三补的偏操作类，周五补的偏长文生成。分数本身没变，变的是分数的"坐标系"。

最隐蔽的一个案例：我们连续三周观察到某模型"长文质量下滑"。排查后发现，每周补充的新案例里恰好都包含 2000 字以上的长文本任务，而这两周的旧案例里有大量短问答被归档了。短问答是那个模型的强项，它被移出评测集后，平均分自然往下走。模型什么都没变。

还有一个更隐蔽的漂移来源：脱敏。客户案例脱敏时，我们会把具体产品名、内部系统名替换成占位符。同一个业务场景，第一周脱敏成"某 CRM 系统"，第三周换了位工程师脱敏，写成了"客户关系管理系统"。案例表面变了，评测匹配逻辑也跟着变。我们后来把脱敏词表固定成一份受控文档，替换规则写死，不允许临时发挥。

我们改了什么

**第一，评测集分层，固定权重。** 把评测案例按任务类型分成五层：短问答、多轮对话、长文生成、代码辅助、结构化抽取。每层设定固定占比，比如短问答 30%、长文 25%。每周补充案例时，只往对应层里加，不改各层占比。这样即使案例总数在涨，分布是稳的。

**第二，新增案例必须标注"进入哪一层"。** 补充案例的工程师在提交时写清楚类型，不能丢进一个大池子。这条规则很轻，但堵住了大部分漂移入口。

**第三，保留一份额不变的"锚点集"。** 我们从评测集里抽 100 条案例冻结，只增不删、不改。每次跑评测时，锚点集分数和全量分数分开出。如果锚点集分数稳定但全量分数波动，基本可以判断是新案例引入的分布问题，而不是模型退化。

**第四，分数对比要带置信区间，不能只看均值。** 以前我们看的是"82.3 分 vs 84.0 分，提升 1.7 分"。现在改成分层出分，并要求每个分层的案例数不低于 30 条，不足的分层直接标注"样本不足，不做结论"。那条 1.7 分的争论，如果当时按层拆开看，会发现差异集中在长文层，而长文层案例只有 12 条——本来就不该下结论。

一个容易忽略的坑

分层的时候我们踩过一个坑：案例的"类型"不是按输入长度分的，是按任务意图分的。一条 50 字的提问如果要求输出完整 SQL，它属于结构化抽取层，不属于短问答层。最初我们按输入字数分层，结果 SQL 类案例散落在三层里，分层统计完全失真。后来改成按标注意图分层，问题才解决。

小结

评测集不是数据库，不能只增不审计。它的分布就是模型的坐标系，坐标系漂了，排名就失去了意义。分层 + 锚点集 + 最小样本量，这三个动作加在一起，投入大概一个人天，但让我们从"每周争论一次分数"变成了"分数异常时才介入"。

两周后再看，锚点集分数波动压到了 0.4 分以内，全量分数的周际波动也从平均 2 分降到了 0.8 分。之前那种"A 还是 B"的争论，现在只有当分层分数真的越界时才会出现——而且通常打开案例一看，答案十分钟内就能给出来。