评测目标与基本单元
本节目标
从产品决策反推可检验的声明，并用统一术语描述一次评测。
直觉解释
评测像验收合同：先写“准备据此决定什么”，再决定测哪些 case、检查什么结果。若先跑一个流行分数再补故事，分数很可能与产品决策错位。
先写“评测为了决定什么”
“评测聊天机器人”过于宽泛。一个可操作声明应写成：
在中文订单查询的目标用户与给定工具权限下，候选版本相对当前版本不降低正确订单查询率，且不得越权执行退款；证据来自冻结离线集、独立重复试验和灰度在线监控。
这句话限定了任务、用户/条件、候选与基线、关键收益、不可接受风险和证据来源。分数只是支持声明的证据，不是声明本身。
基本单元
flowchart LR S["suite：围绕发布声明"] --> T["task：输入 + 初始环境 + 成功条件"] T --> R1["trial 1"] T --> R2["trial 2…n"] H["harness：模型 / prompt / tools / 预算 / 沙箱"] --> R1 H --> R2 R1 --> X1["trace：动作与中间证据"] R1 --> O1["outcome：最终环境状态"] X1 --> G["grader：assertions / rubric"] O1 --> G R2 --> G G --> D["聚合 + 切片 + 区间 + gate"] D --> P["发布、暂停或拒绝"]
图 1 Agent 评测对象关系。文字替代：suite 包含 tasks，每个 task 在固定 harness 下运行多次 trial；trial 同时产生 trace 和真实 outcome，grader 对其断言，聚合后按切片、区间和风险 gate 支持发布决策。图依据本节术语、NIST AI RMF 的 Map/Measure 边界和课程所引第一方评测资料整理；Mermaid 源码即再生成方式。
| 单元 | 含义 | 订单 Agent 示例 |
|---|---|---|
| task / case | 输入、环境和成功条件 | 用户询问订单状态 |
| trial | 对一个 task 的一次独立尝试 | 同一配置第 2 次运行 |
| assertion | 可判断的单个条件 | 查询工具参数等于订单号 |
| grader | 执行一组评分逻辑 | Python 状态检查器 |
| trace / transcript | 中间调用与消息记录 | 工具选择、参数、结果 |
| outcome | 任务结束后的真实状态 | 无退款、返回正确物流 |
| harness | 提示、工具、预算和运行环境 | Agent 循环及沙箱 |
| suite | 围绕目标组织的一组 tasks | 查询、取消、退款、升级 |
Agent 说“退款成功”不等于 outcome 中真的产生了退款记录。对有副作用的任务，优先检查环境状态。
成功标准的三层
- 任务质量：正确、相关、完整、格式合规。
- 风险门槛：泄露、越权、危险动作等关键失败常用“一票否决”。
- 运行约束：时延、调用次数、成本、失败恢复和资源使用。
不要把三层简单平均。例如 99 分回答质量不能抵消一次真实越权。先定义关键 gate，再汇总可权衡指标。
系统边界与 harness
评测“模型”与评测“应用”不是同一件事。提示、检索、工具、记忆、重试次数、超时和上下文整理都会影响结果。报告中应记录被测系统完整配置与预算；若候选使用更多工具或尝试次数，比较也要说明。
把声明写成评测契约
一个可执行契约至少冻结：
claim：要支持的声明与发布决策；system_under_test：模型、Prompt、检索、工具、策略和harness版本；population：用户、任务、环境、语言与排除条件；dataset：split、版本、来源、覆盖和样本单位；graders：断言、rubric、人工/模型校准与未知值处理；gates：关键风险优先级、总体/切片门、成本与延迟边界；reporting：样本量、区间、失败证据、批准人和有效期。
契约在查看候选结果前冻结，变更时产生新版本并说明为什么。否则为了让候选通过而临时改阈值，会把测量变成追分。
本库的评测契约面向具体产品决策；Benchmark设计进一步固定跨系统长期比较协议；运行监控观察部署后的真实遥测和SLO。三者可以共享用例和信号，但回答的问题不同。
常见错误与排查
- 目标只有“回答更好”：补充用户、环境、基线、成功与风险条件。
- 把回答文本当 outcome：对有副作用任务检查数据库、文件或沙箱最终状态。
- 不记录 harness：模型不变但工具、重试和上下文变化也会改变结果。
练习
- 把“RAG 回答得好”改写成带用户、数据范围、正确性、引用和风险门槛的声明。
- 对“创建日历事件”分别写一个 trace assertion 和 outcome assertion。
自测
为什么一次 trial 不能代表随机系统的稳定表现？同一输入可能因采样、工具或环境波动产生不同结果。
小结与下一步
进入 用例数据集与分层。
参考资料
- NIST AI RMF Core: Map and Measure（核对于2026-07-14）
- Anthropic: The structure of an evaluation（发布于2026-01-09；核对于2026-07-14）
- OpenAI: A shared playbook for trustworthy third-party evaluations（发布于2026-05-29；核对于2026-07-14）