把模型评测做成合并门禁：CI 里那个 eval 检查该怎么设阈值
模型评测最常见的失败不是「没测」，而是「测了没人看」。把它接进 CI、做成非零退出码的硬门禁，评测才会真正改变行为——但阈值设错，团队会立刻绕开它。
OpenRouter 发布教程：用固定的 eval 集在 CI 中对 Pull Request 做门禁，当通过率低于阈值时脚本以非零退出码阻止合并，做法与单元测试门禁一致。
为什么「门禁化」比「看报告」有效
- 反馈要出现在决策点。评测报告躺在文档里，改提示词的人不会翻；评测跑在 PR 上，他必须处理。
- 门禁把标准写成了代码。阈值、样本集、判定逻辑都在仓库里，评审就有据可依，而不是靠「感觉这次效果差不多」。
- 回归是可追责的。哪天效果掉了，能定位到是哪个提交改的——这一点在多人协作的提示词工程里尤其重要。
落地时最容易踩的三个坑
- 阈值不能拍脑袋。先让评测在最近二三十个已合并的 PR 上跑一遍，拿到真实分布，取略低于当前基线的值作为起点。凭直觉定一个高数字，结果通常是被反复跳过直至失效。
- 非确定性要单独处理。默认温度下同一输入的结果会漂移，直接逐字符比对会产生大量假阳性。要么固定随机种子与温度，要么用「通过率」而非「完全一致」做判定。
- 区分「阻断」与「提示」。把与本次改动无关的评测设成只提示不阻断，否则门禁会变成噪音源，最终被整体关掉。
一个可用的最小做法
# 伪代码：把 eval 当作测试套件
- name: eval-gate
run: |
python run_eval.py --suite fixed-regression --min-pass 0.85
# 通过率 < 0.85 时脚本 exit 1 -> CI 拦截合并关键在三个变量：固定的评测集（不能随 PR 变化）、明确的通过率阈值、非零退出码。三者齐备，门禁才成立。
对读者的实际影响
- AI 应用团队：优先给「提示词与检索逻辑」建一条最小回归集，二十到五十条就够用，重点是固定。
- 平台工程：把 eval 跑成独立 job，与单测并行，不要拖慢单测的快速反馈。
- 管理者：门禁的价值不在拦截率，而在于它把「效果」变成了每次提交都要面对的成本。
结论：评测进 CI 不是工程洁癖，而是把「模型效果」纳入版本管理的最低成本手段。门槛要低、阈值要准、噪音要隔离——后两点做不到，门禁一定会被绕过。