样本来源:线上真实 query 永远是主力
评测集的金标准来源是线上真实用户输入,没有之一,因为它天然带着真实分布——用户爱问什么、怎么问、错别字有多少、一句话里塞几个意图。其次是历史 bad case,这些是已知的雷区,每次发版必须保证不踩回去。第三类是产品设计的场景用例,覆盖还没上线但规划中的能力,防止版本升级时砍掉未来要用的功能。如果产品还没上线、没有真实数据,冷启动阶段可以用竞品 query 加上 LLM 造数:让强模型按你设计的场景模板批量生成,再由人工筛一遍。但要心里有数,LLM 造的数据偏「干净」和「规整」,真实用户的话要脏得多,上线后要尽快换成真数据。
分布对齐比总量更重要
最常见的错误是评测集按「知识均匀分布」建——每个领域 100 条,漂漂亮亮,但线上真实分布是 80% 的 query 集中在 3 个高频场景,长尾稀稀拉拉。这样的评测集测出来的 95 分,上线可能只有 70 分。正确做法是先做线上 query 聚类分析,按真实占比抽样建集:高频场景多放,长尾场景象征性放,但高危场景(医疗、金融建议、敏感话题)哪怕线上占比 0.1%,也要超配到 5%-10%,因为这些场景出错是事故不是误差。一句话:评测集是线上分布的有偏抽样,偏差方向往「风险」偏。
多少条够:看用途,不看虚荣心
经验数字,分三档。冒烟测试,每次改 prompt 或换模型后快速过一遍,50-100 条,只覆盖核心场景,几分钟出结果,发现明显退化就停下来;回归测试,每次发版前跑,300-1000 条,覆盖主要场景加历史 bad case 全集,这是大多数团队的日常主力;基准测试,季度级的大评估,换基座模型、做多方案对比时用,2000-5000 条,可以配合人工精评。再往上堆数量收益就递减了——从 1000 加到 5000,准确率置信区间也就收窄一两个点,不如把钱花在人工精评和场景覆盖度上。小团队起步,一套 500 条左右的回归集已经能跑赢大多数同行。
标注质量决定评测集的上限
每条样本不只是「问题」,还要有参考答案、评分要点、场景标签、难度标签。参考答案不用是唯一标准答案,写清楚「必须包含什么、不能出现什么」就行,这样人工评测和 LLM 裁判才有尺子可用。标注要做交叉校验,关键样本双人标注。还有一个脏数据问题:线上捞出来的 query 有大量重复、无意义输入和测试性输入(比如用户发「测试测试」),入库前要清洗去重,经验上要洗掉 20%-30%。
评测集是活的,三个月不动就过时
产品功能在变、用户问法在变、模型能力也在变,这条很多团队交了学费才信。评测集必须有新陈代谢机制。建议每季度做一次复盘,雷打不动。删掉已经稳定 100% 通过的简单题(它们不再提供信息量),补充新功能场景和新发现的 bad case。还要警惕模型「刷题」——公开评测集被模型训练数据吃进去,分数虚高,这就是大模型榜单总被质疑的原因。你的私有评测集如果给外部模型服务商做对比测试,最好留一套从未外流的保留集做最终裁决。
版本管理:评测集也是代码资产。
评测集要像代码一样管起来:进 git 或专门的数据版本工具,每次增删样本留 commit 记录,评测结果和评测集版本绑定存档。不然三个月后你想对比两个模型版本,发现评测集已经悄悄变了,对比毫无意义——这在团队协作里几乎必然发生,因为每个人都会「顺手加几道题」。另一个好习惯是给样本带「出生证明」:来源渠道、入库日期、标注人、关联的 bad case 单号,后面做复盘和清洗时省无数力气。听起来繁琐,但评测集是团队反复使用的公共资产,资产没有台账,迟早变成一笔糊涂账,谁也不敢信上面的分数。