评测体系¶
没有评测集，就没有可控的模型、提示词、RAG 或 Agent 调优。
三层评测¶
| 层 | 问题 | 示例指标 |
|---|---|---|
| 组件 | 单个组件是否工作 | Recall@K、JSON 解析率、工具参数正确率 |
| 任务 | 端到端是否完成用户目标 | 任务通过率、严重错误、人工接管率 |
| 业务 | 是否产生真实价值 | 采用率、节省时间、处理量、投诉或风险 |
组件指标好不保证业务指标好，但组件评测能快速定位根因。
建立黄金集¶
- 从真实流量抽取正常、边界、高风险和失败案例。
- 由领域人员定义通过条件，不只给一段参考答案。
- 对开放问答拆成事实点、必须引用、禁止结论和信息不足条件。
- 按用户、来源和时间去重，隔离测试集。
- 每次生产事故或重要失败都考虑加入回归集。
评测集是版本化产品资产。每条样本记录来源、审核人、风险级别、适用版本和修改原因。
Grader 组合¶
- 确定性检查：schema、字段、正则、数值、代码测试、工具结果。
- 检索指标：关键证据是否被召回与进入最终上下文。
- 模型评分：按清晰 rubric 判断开放结果。
- 人工审核：高风险、主观质量和模型评分校准。
模型评分器需要用人工标注集校准。报告一致率、分歧样本和偏差，不能因为 grader 给出小数就把它当客观真值。
指标设计¶
质量¶
- 任务通过率和严重错误率。
- 完整性、事实性、引用正确性和指令遵循。
- 工具选择、参数、结果使用和停止条件。
性能与成本¶
- TTFT、TPOT、端到端 P50/P95/P99。
- input/output/cache tokens。
- 每请求成本与每成功任务成本。
- 重试、降级、人工接管和无效 Agent 步数。
稳定性¶
- 同一输入多次运行的通过率分布。
- 不同语言、长度、文档版本和用户权限表现。
- 模型或提示词升级前后的成对胜负。
评测门禁示例¶
必须满足：
- 严重错误数不增加
- 高风险集合 100% 通过确定性规则
- 总任务通过率提升至少 2 个百分点，或成本下降至少 20% 且质量不退化
- P95 时延不超过 SLO
- 每成功任务成本不超过预算
阈值由业务风险决定。不要把示例数字直接复制到医疗、金融或安全场景。
线上闭环¶
线上 A/B 测试只在安全门槛通过后进行。严重错误不能靠平均指标抵消。
OpenAI Evals API展示了把数据源、评分标准和多次运行分离的基本结构。即使不使用该平台，也应保留相同的可重复性。
报告模板¶
| 项目 | 基线 | 候选 | 差异 | 门槛 | 结论 |
|---|---|---|---|---|---|
| 任务通过率 | |||||
| 严重错误数 | 0 增长 | ||||
| P95 E2E | |||||
| 每成功任务成本 | |||||
| 人工接管率 |
报告同时附上版本、样本数、置信区间或不确定性、失败样本链接和复现命令。
样本结构¶
参考答案不是唯一评测方式。每条样本更适合保存可判定的 rubric：
{
"id": "ticket-0042",
"input": {"question": "...", "user_role": "support_l2"},
"required_facts": ["版本范围", "回滚命令"],
"required_citations": ["doc-18#p47"],
"forbidden_claims": ["未经资料支持的根因"],
"expected_tools": ["search_manual"],
"risk": "high",
"metadata": {"source": "production_failure", "reviewer": "..."}
}
这样既允许措辞变化，又能对必须事实、引用、工具和危险结论做确定性或半确定性检查。
评分 Rubric¶
| 分数 | 定义 | 处理 |
|---|---|---|
| 3 | 完成任务，事实、引用、格式和权限全部正确 | 通过 |
| 2 | 主要目标完成，仅有不影响使用的轻微缺陷 | 按场景决定是否通过 |
| 1 | 部分有用，但遗漏关键条件或需要明显人工修正 | 不通过 |
| 0 | 错误、无关、越权、危险或无法使用 | 严重错误候选 |
Rubric 必须给边界例子。若两位领域标注者经常对 1/2 或 2/3 分产生分歧，先修订规则，不要立即训练 grader 模仿不一致标签。
成对发布评测¶
对同一条样本保存基线和候选输出，随机隐藏模型身份后判断：candidate_win、baseline_win、tie、both_fail。同时保留绝对门禁，因为两个版本都失败时“相对更好”仍不能上线。
发布报告至少分层：
- 高频正常任务：确认总体收益。
- 历史失败与回归：确认已修复问题不反弹。
- 高风险任务：严重错误不能被平均分稀释。
- 长输入、不同语言、不同权限：检查分布切片。
- 多次重复运行：测量概率输出的方差。
不确定性与样本量¶
小样本从 80% 提升到 84% 可能只是波动。至少同时报告分子/分母，例如 42/50，而不只写 84%。对关键比例给出置信区间或 bootstrap 区间；模型评分器还应报告与人工标注的一致率。
失败审阅板¶
| 样本 | 风险 | 失败层 | 基线 | 候选 | 是否新回归 | 负责人 | 下一步 |
|---|---|---|---|---|---|---|---|
| 数据/检索/生成/工具/权限 |
先按失败层聚类，再决定修改数据、检索、提示、工具还是模型。随机阅读几条“感觉变好”不能代替系统性审阅。
本章实践¶
建立 30 条最小黄金集：15 条正常、5 条信息不足、5 条高风险、5 条历史失败。为每条写 required/forbidden 条件，运行两个候选并做盲评。报告必须包含原始输出和全部失败，而不只展示平均分。
从“平均分”升级到可决策的实验¶
先分层，再汇总¶
把样本按风险、输入长度、语言、工具数量、用户权限和知识库版本分层。总平均值只能回答“整体有没有变化”，不能回答“哪个群体变差”。发布单至少展示：
overall / high-risk / historical-failure / long-context
tool-use / retrieval-required / permission-boundary
每个切片同时报告分子/分母，例如 42/50，并保留失败样本 ID。小样本不要写成精确趋势；对关键比例使用 Wilson 区间或 bootstrap 区间，并在多模型比较时预先写出主要终点。
选择性自动化¶
如果系统只对高置信度样本自动执行，必须绘制覆盖率与风险曲线：
阈值不是越高越好。阈值提高会降低覆盖率，换来较低风险；正确选择取决于漏放、误报、人工处理和业务时延的成本。Jev 或普通 judge 返回的 confidence 都要用 holdout 集校准，不能把原始概率直接当业务概率。
Agent 轨迹评测¶
最终答案正确，不代表 Agent 过程安全。轨迹评测至少拆出：
| 轨迹层 | 检查项 |
|---|---|
| 规划 | 是否遗漏硬约束，是否无谓拆分任务 |
| 工具 | 工具选择、参数、权限、幂等和超时 |
| 上下文 | 是否把不可信网页或工具输出当成系统指令 |
| 恢复 | 失败后是否重试、换工具、回滚或升级人工 |
| 交付 | diff、引用、工件和审计日志是否完整 |
建议给每次 run 生成一个不可变 trace：run_id、模型 revision、harness commit、工具事件、输入快照、输出、judge 结果和人工改判。没有 trace，就无法解释为什么同一输入这次通过、下次失败。
最小统计报告模板¶
experiment: model-router-2026-09-26
baseline: provider/model-a@revision
candidate: provider/model-b@revision
dataset: golden-2026-09-20
n: 240
primary_metric: task_success
secondary_metrics: [severe_error, ttft_p95, cost_per_success]
slice_metrics:
high_risk: 48/48
long_context: 31/40
paired_test: bootstrap_10000
decision: ship / hold / rollback
failure_ids: [ticket-0042, ticket-0118]
适用条件：模型、提示、RAG、工具或 harness 任何一层将要改变。 代价：需要维护数据集版本、脱敏、人工标注和重放基础设施。 验证方式：另一位工程师只拿到实验 YAML、工件目录和命令，也能复算结论。