只在发布前跑评测，等于把发现问题推到最后一刻。
评测集放在仓库里，不如接进流水线
评测集建好之后最大的风险是没人跑：改动上线了，指标退化了，几天后才发现。
把它接进 CI（持续集成）意味着：每次改动自动跑一遍，退化当场拦下。
三条流水线
1. 快速冒烟（每次提交，1~2 分钟）：抽 20~30 条样本，看有没有崩溃级退化（格式错、拒绝回答、超时）；
2. 完整评测（合并主干，5~15 分钟）：跑完整评测集（100~300 条），比较正确率与失败类型分布；
3. 夜间回归（每天）：加跑成本/延迟统计与更贵的评估（人工抽检或强模型打分）。
判定规则要写死在配置里
· 主指标允许的波动范围（例如正确率下降不超过 2 个百分点）；
· 失败类型的硬约束（例如"编造事实"类不得增加）；
· 成本与延迟的上限（防止为了指标把成本翻倍）。
超限时阻断合并，而不是只在评论里提示——人的注意力会被别的事吸走。
三个工程细节
· 缓存与并发：同样的样本结果可复用，别每次都真调模型；并发跑，但限速避免打爆配额；
· 基线要固定：与"上一次主干"比，而不是与某个历史最好成绩比；
· 失败也要留档：把失败样本与原始输出存下来（脱敏后），这是最有价值的素材。
常见坑
· 评测集与提示词在同一仓库但版本不一致（改了提示词却没重跑基线）；
· 只在发布前跑：等于把发现问题的时机推到最后一刻；
· 评测环境与线上不一致（不同模型版本、不同参数）→ 结论不可迁移；
· 把评测做成"打分游戏"：只盯总分，忽略失败类型的变化（平均不变但极差回答变多，是恶化）。
落地顺序
1. 先把冒烟跑起来（20 条、1 分钟、阻断合并）；
2. 再加完整评测与基线对比；
3. 最后加夜间回归与成本看板；
4. 每次改动都在 PR 描述里附本次的评测结论（含没变好的地方）。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：检索结果怎么排序：相似度不是唯一信号
下一篇：数据脱敏与最小必要：把用户数据喂给模型前该做什么 →
第 23 / 171 篇