很多团队做 Evals 时停在“做一张分数表”，然后把它放进周报。
问题是：
- 分数好看，不代表线上稳定。
- 评测跑了，不代表发布可控。
Evals 的正确定位应该是：发布门禁系统的一部分。
架构图：质量/成本/时延三门禁
时序图：一次回归是如何阻断发布的
工程化 Evals 的三个层次
1. 离线正确性评测
验证模型是否在核心任务上达到最低可用线。
2. 线上性能评测
监控延迟、成本、失败率，确保系统可运营。
3. 发布门禁评测
与 CI/CD 挂钩，回归即阻断发布。
建议的门禁规则（示例）
- 质量分数下降超过阈值：阻断。
- 成本上涨超过预算比例：阻断。
- P95 延迟超阈值：阻断。
- 关键业务样本失败：强制人工审批。
评测集建设要点
- 代表性：覆盖真实高频和高风险请求。
- 可追溯：样本来源、标签标准、版本都要记录。
- 可迭代：每次线上事故都要反哺到评测集。
指标设计建议
| 维度 | 建议指标 |
|---|---|
| 质量 | 任务完成率、关键样本通过率 |
| 成本 | 单请求成本、千请求成本 |
| 性能 | P50/P95 延迟 |
| 稳定性 | 回归触发次数、误报率 |
误区复盘
- 只做一次性 benchmark，不做持续回归。
- 只关心质量，不关心成本和时延。
- 门禁规则没有分级，导致团队频繁“手动放行”。
结语
AI 产品进入规模化后，评测不是科研动作，而是发布治理动作。
把 Evals 接进门禁，才是从“模型可用”走向“业务可发布”的关键一步。