评测自动化是怎么搭的？内部门道在这

团队里的大模型一更新，评测就要重来一遍，手工跑分既慢又容易走样，评测自动化解决的就是这个问题：把跑题、判分、汇总变成机器流水线，人只看报告。本文讲清搭法与门道。

一句话定位：自动化接管的是执行层，题目质量与判分标准仍由人定，机器保证的是每次都按同一套规矩跑。

整体结构：三层流水线

典型结构分三层：触发层监听模型更新或定时信号；执行层按配置拉起题集、调用模型、收集输出；汇总层判分、算分、生成报告并归档。三层解耦，换模型只改执行层配置，换题集只动题库。不想从零搭，开源框架已经把执行层做好了，见开源评测框架是怎么用的。

触发与执行：别让人插手

触发方式有定时触发和事件触发两种，版本更新后自动跑回归评测是常见用法。执行环节有几个易错处：接口重试策略要固定，避免网络抖动被算进分数；并发数别压满，防止限流导致超时被判零分。另外题库若是固定集，被针对优化的风险会随时间累积，见固定集和动态集有什么区别。执行日志逐题留存，出问题能回放。

判分与汇总：自动里留人工

规则题全自动判，开放题先机判再按比例抽人工复核，抽检结果反过来修正机判模板；机判接口可选智谱清言或 DeepSeek，模板与参数锁定后不再改动。全自动与抽检的分工边界，人评和机评有什么区别讲得更细。

报警与门槛：让分数会说话

给关键维度设分数门槛，跌破就在群里报警，比如新版写作分下滑超过阈值即阻断发布；门槛与规则要在跑分前公开，透明度要求见评测自身的伦理问题。还要留意分数涨了体验却没跟上的落差，边界见跑分和体验有什么区别。

失败重试与幂等

批量跑评测，失败是常态而不是意外：接口超时、限流、返回格式异常都会出现。流水线要能区分「模型答错」和「根本没答成」，前者计入分数，后者必须重试而不是记零分，否则分数会被系统性拉低。重试要带退避，连续失败超过阈值就暂停该通道并告警，避免把限流打成雪崩。任务本身要幂等，同一道题重跑覆盖旧结果而不是追加新记录，否则统计口径会悄悄失真。跑完还要出一份执行报告：成功率、重试次数、平均耗时，这些数字比总分更能说明流水线是否健康。有条件的话把执行报告接进日常看板，异常在当天就能被发现。

另外，跑批配置要能一键复现：模型版本、参数、提示词、题集快照都写进配置文件，出了问题能原样重跑。配置和结果一起归档，隔几个月回头查，也能说清当时的分数是在什么条件下得出的。

评测自动化自查清单

• 触发、执行、汇总三层解耦
• 重试策略与并发数写进配置
• 逐题日志留存，可回放
• 关键维度设门槛，跌破即报警

留一个提醒：流水线上线后别急着撤人，头两周每天人工抽看一批明细，确认判分没有系统性跑偏，再逐步放手。

聊聊评测自动化的常见疑问

• 小团队有必要上自动化吗？：哪怕每周只跑一次，脚本化也能省下重复劳动，规模小可以只搭执行层。
• 全自动判分可信吗？：规则题可信，开放题必须留人工抽检，发现系统性偏差立刻修模板。
• 自动化会掩盖题目老化吗？：会，分数长期稳定可能只是题目被刷熟，定期换题不能省。