AI 应用上线前怎么评测？评测集怎么建、多少条起步？
谁在问：二面必问；有 AI 产品上过线的团队一定会问
口语化问法
- 你们那个功能上线前是怎么验证效果的？
- 评测集是怎么建的？大概多少条？谁标的？
- 你们怎么知道改完 prompt 是变好了还是变差了？
考察意图
这道题几乎是所有 AI 应用岗二面的开场刀。面试官在判断三件事：
- 你有没有真的建过评测集——建过的人第一反应是「先说清楚我们的失败长什么样」，没建过的人第一反应是「我们用 GPT 打分，准确率 92%」。
- 你把评测当验收还是当回归——当验收的人上线前跑一次；当回归的人每次改动都跑，并且能说出门禁集和全量集的区别。
- 你有没有数量级的直觉——「多少条起步」这一问没有唯一答案，但它能立刻区分「背过一个数字」和「知道这个数字取决于什么」。
参考答案
60 分答案（及格线）
我们建了一个评测集，大概 100 多条，来自产品和研发一起整理的典型问题，每条配了标准答案。判分一部分用规则（比如必须包含某个字段），一部分用大模型判「是否命中要点」。每次改 prompt 或换模型都跑一遍，分数不掉才发。上线前我们跑到了 90 分以上。
这个答案能过，因为它包含了三个正确的动作：有固定集合、有自动判分、每次改动都重跑。
它止步于 60 分是因为：说不出这 100 多条的分布是怎么定的，也没提数据来源、分层、泄漏和统计显著性。面试官只要问一句「这 100 条和线上真实 query 的分布像吗」，就会卡住。
90 分答案（有生产经验的回答）
我分四步说：怎么起步、怎么分层、怎么判分、怎么知道分数可信。
一、起步不是先建集合，是先做错误分析。 我们最早也是坐在会议室里写题，写了 120 条，上线后发现和线上分布差很远——线上 61% 是残句和关键词，44% 发生在第二轮以后带指代，还有 12% 问的是知识库里根本没有的东西，而这三类在我们的评测集里出现次数是零。指标为零的维度在看板上是不可见的，我们看到的不是「多轮场景 30 分」，是「多轮场景不存在」。 所以后来的做法是反过来：先从线上（或灰度、或内测）捞 100 条真实 trace，人工逐条看，给每条失败写一句话，再归并成失败类别。大概看到 20 条不再出现新类别就可以停，这时候你才知道该测什么。
二、评测集是三层，不是一个。 冒烟集 5–20 条，每次提交跑，秒级；门禁集几十到两百条，每次发布跑，它是唯一有权拦住发布的；全量集几百到上千条含长尾，每周或大改动跑，只报告不拦。判据是：能进门禁的必须是「错了就该拦住发布」的用例，把锦上添花的题放进门禁，结果一定是门禁天天红、大家学会无视它。
三、来源按含金量排序，合成数据只能扩写不能打底。 线上真实失败 > 线上成功流量的分层抽样（保分布）> 专家写的边界样例（保覆盖）> 模型批量扩写。最后一类最便宜，但用模型生成的题去测模型，测到的是两个模型共同盲区之外的部分——真正会翻车的地方在合成数据里是空白的。另外评测集必须和调 prompt 用的开发集分开，也必须和微调训练集异源，还要留一份从不参与迭代的保留集。
四、「多少条」取决于你拿分数干什么。
- 还在做错误分析：看 100 条 trace，20 条不出新类别就停，此时谈样本量没意义；
- 建门禁：每个失败类别 20–50 条，总量几十到两百，这是判据集不是统计集，作用是钉死行为；
- 要拿分数做 A/B 决策：回到统计，95% 置信、±5% 误差、基线 80% 需要 约 250 条。
还有一条容易漏的：判分越便宜越可靠，评测集就越该大；判分越贵越主观，评测集就越该小而准。 代码判分的边际成本接近零，多多益善；靠人或靠 judge 判分的，每条都有标注成本和噪声，小而精反而更好。
追问链
这些题具体是谁写的？有多少来自线上？
期望报得出来源构成的比例，而不是「产品和研发一起整理的」；线上真实失败最值钱，每条都是花真实代价换来的；早期没流量只能自己写不丢分，但要说得出什么时候用灰度/内测/种子用户把它换掉信号答「都是我们自己写的」且没有替换计划 → 评测集停在开发期想象；说「线上回流现在占 60%」→ 飞轮真的在转你怎么确认评测集的分布和线上是一致的？
期望把评测集与线上采样的query各自统计长度、轮次、意图分布，摆进一张表对比，一个下午能做完；再用embedding聚类找线上有、评测集没有的簇。要害是分布不一致不报错 —— 没有异常日志，只有一个看起来正当的高分信号只说「我们尽量覆盖了各种情况」→ 没做过；说「意图为零的那一类最危险，它在看板上不可见」→ 很强的信号主观的东西怎么判？比如文案好不好、语气对不对
期望先分层：能用代码判的先用代码判（长度、必含要素、禁用词、结构、schema），剩下的才交给人或judge；主观维度拆成多个二元判据，不打一个 1–5 的总分；用 judge 的前提是先有人工校准集和一致性指标信号「用大模型打 1–5 分取平均」→ 形态错误，本章最常见的失分点；「人都对不齐的判据 judge 学不会」→ 很强的信号评测集怎么维护？会不会越来越大？
期望每次线上事故必须以「评测集新增一条用例」结束；而且它不是只增不减 —— 最近所有版本都 100% 通过的题已经没有区分度，降级进冒烟集；评测集要有版本号并与跑分结果绑定，改了集合不改号，历史曲线就废了信号只说「一直往里加」→ 还没到要控成本的规模；主动提「删题」和「版本号」→ 维护过一年以上评测集才有的直觉只给你两天、一个人力，从零建评测集，这两天怎么分配？
期望第一天上午捞 100 条真实输入写失败类别，不写题 → 下午定判据、优先能代码判的，判据错了题再多也没用 → 第二天只建门禁集（每类 20–30 条），放弃全量集和 judge 校准 → 说清放弃的什么时候补回来（第一次线上事故就开始回流）→ 留一小时把评测跑进 CI，跑不起来的评测集等于不存在信号上来就说「先写 200 道题」→ 把产出量当成果；说出「判据优先于题目、门禁优先于全量、先跑起来再谈准」→ 做过而且被资源卡过
评分要点
- 能说清评测集是回归测试套件（防复发），不是期末考试（证明好）
- 起步动作是错误分析，不是直接写题；给得出「看 100 条、20 条不出新类别就停」这类可执行经验值
- 说得出三层结构（冒烟 / 门禁 / 全量）以及门禁的准入判据
- 说得出来源含金量排序，并明确合成数据只能扩写不能打底
- 说得出防泄漏三条：评测集≠开发集、与训练集异源、留保留集
- 「多少条」的回答分阶段，且给得出统计口径（±5% / 基线 80% → 约 250 条）
- 提到判分成本与集合规模的反向关系（代码判分越多可以越大）
- 提到维护：事故回流、删饱和题、版本号