评测集如何自动化集成CI?

把评测集接入 CI，真正改变的不是“多跑一次测试”，而是让模型、数据和检索流程的每次变化都留下可比较的痕迹。过去，团队常在发布后才发现回答变差；接入后，模型版本调整、数据批次更新或检索配置变化，都可以先经过同一批固定样本的检验。

关键是把评测集当作普通代码测试一样管理。核心场景、边界与异常输入、历史回归案例应一并保存；每个样本不仅要有输入，还要有预期输出或评分标准。否则 CI 即使跑完，也只能得到一堆结果，无法判断这次变更究竟是进步还是退化。

CI 流程不必复杂：当模型、数据或相关配置发生变更时，自动固定当前版本与生成设置，运行评测集，保存输出和评分，再与此前的基线结果对比。若核心样本明显变差，或历史问题重新出现，就应让变更停在检查阶段，等待人工确认，而不是直接进入后续流程。

这里最容易被忽略的是“记录条件”。同一份评测结果，若缺少模型版本、数据版本、检索参数和生成设置，几乎无法复现，也难以定位责任边界。评测报告不只是通过或失败的信号灯，更该告诉团队：变化集中在哪类样本，是数据更新带来的漂移，还是模型行为本身发生了波动。

也不必把所有差异都当成故障。有些变更会让个别输出措辞不同，却未必降低质量；真正需要拦截的，是偏离评分标准、影响核心任务，或让已修复问题再次出现的退化。CI 自动负责发现异常，人来判断异常是否值得阻断，这种分工往往比追求“完全自动判分”更稳妥。

当评测集持续随项目积累，CI 就不再只是发布前的一道门槛，而会成为团队共同维护的基线：每次改动都能回答一个简单却重要的问题——这次变化，到底让系统变好了，还是只是换了一种不容易察觉的坏法？