一、项目背景

模型迭代很快，但评测全靠人工攒题目，每次发版前测试同学手动整理几十道题，覆盖不全还慢，常常测了个寂寞就上线了。更麻烦的是没有基线，这次比上次好还是差，全凭感觉。我们进场时，模型已经迭代了十几版，却没有一份能反复跑的评测集，历史版本效果完全无法横向比，算法同学自己都说不清哪版更稳。有一次上线后质量肉眼可见地掉了，却没人能拿出证据，只能靠用户投诉才发现，等发现时已经影响了一波客户。

二、落地场景

我们搭了一套评测数据自动构建流水线：从线上真实对话、业务反馈、历史工单里抽取样本，经过清洗、去重、人工抽检后沉淀为评测集，按场景打标签（售前、售后、风控等）。每次模型发版，流水线自动跑全量评测，输出各维度得分并与上版本基线对比，差异超阈值就标红拦截。团队从此有了发版必过评测的硬规矩，没过基线的版本不许上生产，评测报告自动归档，任何版本都能随时复盘，新来的算法同学也能看懂每次迭代的来龙去脉。

三、关键技术挑战与解决思路

自动构建最怕引入脏数据。我们做了三道闸：抽取阶段用相似度去重，避免同题反复刷分；清洗阶段用规则滤掉过短、含隐私、无标准答案的样本；抽检阶段按比例人工复核，保证评测集可信。评测本身分两层，客观题用精确匹配和正则判分，主观题用大模型当评委并和人类打分做一致性校准，避免评委模型自己飘。基线用滑动窗口维护，只保留近五个稳定版本，防止历史噪声干扰判断，也避免评测集无限膨胀拖慢回归。评测集与训练集强制做去重隔离，杜绝题目泄露导致虚高。

四、效果数据

流水线跑起来约五个月，评测集规模从手工时期的约两百题增长到约三千题，覆盖场景从三个扩到十一个。单次全量回归耗时从人工的两天压到约四十分钟。版本间效果波动可量化，最近一次发版因售后场景准确率下降 4 个百分点被基线拦截，回滚后避免了一次线上质量事故。评测集人工抽检通过率稳定在 92% 以上，评委模型与人类打分一致率从初期的 0.78 提到 0.89，误拦误放都明显下降，团队对评测结果的信任度上来了。

五、可复用经验总结

评测集贵在能反复跑，不在于一次攒得多。我们吃过一次亏，手工集子里的题被模型训练时 inadvertently 见过，测出来虚高，后来强制评测集与训练集做去重隔离才准。评委模型要校准，不校准它给的分和自己人打分能对不上，反而误导。基线拦截要有弹性，死卡一个绝对值会误伤正常波动，我们用相对阈值加人工放行通道，既防劣化又不绑死团队，算法同学也服气。评测不是上线前的走过场，而是给每次迭代留一条可追溯的底线，这条底线保住，模型再怎么快跑也不至于翻车。

结语

评测这件事，我们一开始也走过弯路，以为攒个几百题人工看看就行，结果模型发了十几个版本都没人说得清好坏，直到一次线上质量肉眼可见地掉了才被用户投诉揪出来。那个坑让我们明白，评测集不是上线前的点缀，而是给每次迭代留的可追溯底线。现在集子大了、流水线稳了，算法同学发版前自己就会去跑一遍，质量问题在门内就挡住了。评委模型的校准我们也还在做，毕竟它自己也会飘，定期拿人类打分对齐不能省。这套机制跑顺之后，最明显的变化是团队敢发版了，因为心里有底，不再靠拍胸脯保证质量，回头看花在评测上的每一分时间都比事后救火便宜得多。

现在我们也在把线上真实 bad case 自动回流进评测集，让集子始终贴着生产环境长，而不是一成不变地躺在库里。评委模型的校准我们也还在做，毕竟它自己也会飘，定期拿人类打分对齐不能省。这套机制跑顺之后最明显的变化是团队敢发版了，因为心里有底，不再靠拍胸脯保证质量。

现在我们也在把线上真实 bad case 自动回流进评测集，让集子始终贴着生产环境长，而不是一成不变地躺在库里，这样评测才不会和线上脱节。我们也坚持评测集和训练集强制隔离，宁可多花人力抽检也不让题目偷偷泄露，测出来的分数才敢拿去拦发版。

案例片段（已脱敏）： 评测流水线一次运行输出摘要： 版本 v2.3.1 vs 基线 v2.3.0 售前场景准确率：91.2% → 87.1%（↓4.1，触发拦截） 售后场景准确率：88.5% → 89.0%（↑0.5） 风控场景 F1：0.82 → 0.83 总样本 2980，人工抽检 120 题，评委与人工一致率 0.89 处置：售前场景下降超阈值，自动阻断发布并通知算法组回查，回滚至 v2.3.0 后重新发版，二次评测售前回升至 91.5% 方才放行，整个过程无人肉干预发版。