当前位置：首页>排行榜>评测工程不进 CI,发布前 1 晚才救火

评测工程不进 CI,发布前 1 晚才救火

更新时间 2026-10-31 10:16:51

评测工程不进 CI,发布前 1 晚才救火

有个团队评测只在发布前手动跑，平时模型天天在调。到了发布前一夜，跑了全套才发现核心指标退化了8个点，rollback 来不及，上线后客诉炸了。复盘时他们说，要是那8个点在两周前就被拦住，早就修完了，不至于堆到发布夜爆发。

原因：评测是人工滞后的，退化在没人看的时候悄悄积累，等你想看已经晚了。

一、CI 门禁把退化拦在合并前

评测进 CI，本质是每次代码变更自动触发一次评测，分数退化就拦住合并。它把评测从发布前突击变成日常持续，退化在引入的那一刻就被抓住，修复成本最低。

二、CI 接入的四个环节

别以为接 CI 就是把脚本挂上去。完整接入是四个环节串起来的，缺一个就退化能溜过去：

环节	干什么	常见误用	正确做法
触发	什么变更跑评测	只在发布分支跑，日常跳过	每次 PR 合并前必跑
跑集	跑哪部分评测	全量长跑，PR 卡半小时	快速集卡门槛，全量集定时跑
阈值	退化多少算失败	只报不拦，看着退化合进去	设硬阈值，超了直接打回
报告	结果去哪看	打印在日志里没人翻	评测报告挂 PR 评论加看板

触发环节最容易被糊弄成「发布分支才跑」，可退化恰恰发生在日常 PR，等发布分支跑已经积重难返。跑集环节则是另一个极端，一上来全量长跑，PR 卡半小时，团队受不了就绕过它，门禁名存实亡。正确做法是快速集卡门槛、全量集定时跑，两层分工。

阈值环节是门禁的灵魂，只报不拦等于没闸，退化照常合进去。但阈值也不能太狠，误杀正常波动，团队会养成强制合并的习惯，门禁就废了。报告环节是收口，结果不挂出来没人看，等于白跑。

这四个环节里，跑集的分层最常被省。但恰恰是它，决定了门禁是真在用还是挂着好看，没有分层，门禁要么太慢被绕过，要么太粗漏掉退化。

三、门禁假红：非确定性抖动怎么治

门禁上线第一个月，团队嘴里最常蹦出来的一句是又红了，跟这次改动没关系。夸它拦得对的，反倒少见。同一个 PR 什么都没改，重跑一次就绿。到第三次，大家开始点强制合并，门禁从此形同废纸。这不是执行力问题，是 AI 评测的非确定性撞上了 CI 的确定性假设。

传统测试里 flaky 是少数派，AI 评测里它可能是常态。模型采样带温度，检索的 top-k 与重排版本会抖，裁判自己打分也有方差。同一个输入跑两遍，通过率能差好几个点。门禁按单次结果判红，假红率就高到没人受得住。

治理分三层，成本从低到高，顺序建议如下：

分层	做法	成本	解决什么
降方差	温度调 0、固定随机种子、固定 top-k 与重排版本	几乎为零	能消除的那部分抖动
重复判定	同一批样本跑 k 次取多数，或按通过率区间判	跑批时间乘 k	采样与裁判方差
隔离复跑	首次失败自动复跑失败样本，复跑通过记 flaky 不阻断	少量额外调用	偶发的样本级抖动

先降方差再重复判定，这个顺序省的是钱。温度调 0 听着太基础，可实际排查里相当一部分假红就是它。还有一个细节常被漏：有的链路检索侧也带随机，只把生成的 temperature 设 0，等于只治了一半。

重复判定要落到阈值上。快速集跑 3 次，3 次里 2 次过就算绿，比全量乘 k 便宜得多。全量集按单次跑，但把本次未过、上次过的样本单独标出来人工看，别直接判死，那批样本恰恰是链路最脆弱的地方。

隔离复跑是兜底，也最好量化。记一个 flaky 率，算法是复跑才通过的样本数除以失败样本数。这个数超过 10%，说明链路本身就不稳，压门禁阈值无用，得回头治采样和检索；低于 3% 属正常噪声，不值得追加投入。flaky 率本身也该挂上看板，它涨往往比主指标掉更早暴露问题。

四、成熟度细化

阶段	当前现状	改进	前序是否保留
阶段一	评测全靠手动跑	把脚本挂上 CI，先跑通不拦	起点，无前序
阶段二	能跑但不拦退化	设快速集加硬阈值打回	CI 跑通继续
阶段三	门禁拦得住但慢	跑集分层，全量集定时跑	以上全保留
阶段四	门禁频繁假红，被强制合并	降方差加快速集 k 次判定，flaky 率上看板	以上全部保留
阶段五	多仓库各自接 CI	统一门禁规范加报告看板	以上全部保留

常见错误是一上来就冲阶段五做统一平台，结果阶段二阈值都没设，门禁合进去照样退化。阶段二把硬阈值立起来，发布夜救火能直接消失。阶段四也常被跳过，可假红不治，红线就没人怕，前面修的多严都没用。

五、落地闭环实践

先把评测脚本挂上 CI 跑通（不拦），再设快速集加硬阈值打回，做跑集分层，接着降方差加复跑把假红压下去，最后把报告挂进 PR 和看板。

闭环这件事，前面已经画完：离线跑分、线上留 trace、失败样本回流成新用例，双轨上线和几道回归闸也点过名。问题在于这些动作都还停在流程图和检查单上，靠人记得去做，忙起来第一个被砍的就是它。需要把它们挪进流水线，从「建议回归」变成「不通过就不许合并」，差的往往不在工具，在执行力。

CI 门禁守的就是四件套里评测集跑出来的分数：评分卡的维度是门禁判据，裁判的通过率是门槛线，难负集是退化最敏感的那部分。字段映射关系汇总如下表。

四件套原有项	CI 怎么用
评测集	拆快速集与全量集两层
评分卡	维度阈值即门禁判据
裁判	通过率低于阈值打回
难负	进快速集，退化优先暴露

本文建议

PR 触发率 100%；快速集跑批小于等于 10 分钟；硬阈值超线打回率执行到位。

阈值设定依赖指标波动基线，本文未给统一公式，需按业务波动折算并先观察两周再定硬线。复跑次数 k 与 flaky 率的两条参考线来自通用工程经验，未做跨团队统计，需按自己链路的实测波动校准。

一句话收尾

你那套评测，现在是每次改动自动守门，还是发布前夜才手忙脚乱？

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。

随机文章