考察点
评测集是整个评测体系的地基，这道题看候选人有没有真正把评测集当工程资产做过的经验。面试官关心样本来源是否真实、量级有没有依据、调 prompt 的人天天盯着评测集刷分怎么办。追问常往「合成数据能不能用」「多少条才能看出两个版本的差异」「评测集多久更新一次」走。
参考答案
样本从哪来
评测集的第一原则是贴近真实分布，最好的来源是线上日志。从生产流量里分层采样，按意图、场景、难度分桶，保证每个重要桶都有覆盖。没有线上流量的冷启动阶段，可以用三类补充：一是产品和运营手工构造的典型问题，二是用强模型批量生成再人工筛选的合成数据，三是从公开数据集里改造的同领域样本。合成数据能用但要小心——它往往偏「规整」，缺少真实用户输入里的错别字、多意图混杂、上下文省略这些脏特征，比例建议不超过三到四成，并且必须过人工校验。
除了正常样本，还要专门留一块对抗子集：边界输入、注入攻击、敏感话题、超长超短输入，这部分样本量不用大，但必须每次回归都跑。
多少条够
量级不是拍脑袋，是由统计功效决定的。假设你要看一个通过率指标，p 在 80% 附近，样本量 n 时标准误是 sqrt(p(1-p)/n)。100 条样本，标准误约 4 个百分点，两个版本差 3 个点根本分不清是真提升还是噪声；要分辨 2 个点的差异，得七八百条以上。所以经验做法是：核心场景每类至少 50-100 条，总量 300-1000 条起步，指望靠它做发布决策的指标，先算一下这个量级下的置信区间再下结论。
另一个实操约束是评测成本。LLM-as-Judge 打分、多次采样降方差，都要花钱花时间，评测集大到跑一轮要几小时，迭代节奏就被拖垮了。常见折中是两层结构：一个几百条的核心集每次提交都跑，一个几千条的全量集发版前跑。
怎么防过拟合
评测集被盯着刷分是必然发生的，防御手段有三个。
一是拆分。学机器学习的做法，把评测集分成 dev 和 test 两份：dev 集开放给日常调优，随便看随便迭代；test 集严格 holdout，只有发版前才跑，访问权限收紧，结果只做决策参考不做调参依据。
二是轮换。即使 holdout，同一份 test 用半年，团队对它的「隐性记忆」也会造成过拟合。定期从线上新流量里采样补充、替换一部分旧样本，让评测集跟着业务分布走。
三是看 case 不看分。评审版本效果时多看 case 级 diff——如果提升全部来自对某几条已知 case 的针对性修补，而不是一类问题的整体改善，那大概率是过拟合而不是真进步。
评测集需要更新吗
必须更新，它是活资产。三个更新触发器：线上 badcase 回流，用户点踩和转人工的会话是最高价值的新样本；业务变化，新产品、新政策上线后旧样本可能失效；定期轮换，按季度从线上重新采样校准分布。评测集要像代码一样版本化管理，每次更新有记录，这样能回答「这个版本是在哪份评测集上测出来的」，历史结论才可追溯、可复现。
可能的追问
- 冷启动没有线上数据怎么办？ 用「种子样本 + 强模型扩写 + 人工校验」快速搭几百条，同时尽早上线最小功能收集真实流量，第一批真实数据进来后立刻校准评测集，合成数据占比逐步压低。
- 评测集里标注答案怎么定？ 开放题不强求唯一标准答案，标参考要点和评分 rubric 更实用；有标准答案的（如政策问答）标参考答案加可接受的等价表述，交给 judge 时一并给出。
- 怎么发现评测集已经和线上分布漂了？ 定期在线上流量上重跑评测集的难度分布和意图分布统计，和评测集自身分布对比；另一个信号是离线分数持续上涨但线上指标不动，八成是集子老了。