分层评测体系

从业务任务成功反推评测层

先写任务成功契约，再选择指标。以“创建合规采购单”为例，最终业务状态必须正确；权限、审批与副作用符合约束；交付物有依据且用户能理解和控制；整个过程还要在延迟、成本与资源预算内完成。四类条件共同决定 Session 成功，不能只检查最终文本。

把成功契约映射到可观察证据：业务数据库确认采购单状态，Trace 证明审批和 Tool 轨迹，引用与检索证据支持结论，Usage 和时序提供效率。评测 Runner 负责收集与评分，业务 Owner 对成功定义负责，平台 Owner 对测量可重复性负责。

各层指标回答不同问题

层级不是组织架构，而是诊断视角。同一次失败可以在模型层表现为错误 Tool 选择，在 Tool 层表现为契约拒绝，在 Session 层表现为未完成。报告应保留层级关联和同一 case_id/run_id，避免把相关信号当作独立样本。

模型层

模型层隔离输入后测“在给定上下文和能力下，模型是否产生合规决定”。它不能证明检索内容正确，也不能证明外部 Tool 执行成功。

指令与输出

结构合法、指令遵循、拒绝边界、事实正确与表达质量分别评分。Schema 校验通过只证明形式，事实主张还需参考证据、业务查询或人工/Judge 复核。

Tool 决策

分别测该不该调用、调用哪个 Tool、参数是否正确、并行或串行选择是否安全。只统计 Tool 名准确率会漏掉“不该调用却调用”和正确 Tool 的危险参数。

检索层

在固定查询与权限上下文下，分别测候选召回、排序、Grounding、时效与权限过滤。Recall 上升却引入越权文档是硬失败；检索到了证据但生成未使用，则应归因到生成或上下文组织，而不是检索。

规划执行层

检查分解是否覆盖成功条件、依赖是否合法、关键步骤是否执行、失败能否恢复、何时停止。步骤更少不是天然更好：跳过核验会降低步骤数，却增加未知结果与副作用风险。

Tool 层

契约测试覆盖 Schema、鉴权、错误分类、超时、重试、幂等与副作用回执。测试环境应能注入限流、部分失败和未知结果，验证 Runtime 是否正确恢复，而不是只测 happy path。

端到端 Session

Session 是用户目标的验收单位，要允许多轮、人工介入和不同有效路径，同时验证最终业务事实。

结果

由业务系统或独立验证器检查最终状态、交付物、约束和必要证据。模型自报“完成”不计成功，部分完成也应有独立终态。

过程

过程指标覆盖完成所需轮数、人工介入、失败恢复、高风险审批和副作用。开放任务不要求轨迹逐步匹配参考答案，但硬安全控制必须满足。

系统效率

记录 TTFT、任务时长、Token、费用、吞吐和可用性，并优先换算为“每成功任务”的资源消耗。失败请求成本很低并不是效率提升，成功率下降也可能让平均延迟看起来更好。

匹配问题选择评分器

确定性事实优先确定性评分器：JSON Schema、编译、单测、集合与数值比较、权限查询和业务状态。参考答案适合封闭问题，但文本相似度不能可靠代表语义正确。Trace 评分器检查必须或禁止的动作，开放质量再交给人工或经校准的 LLM Judge。

OpenAI Graders API展示了字符串、文本相似、模型评分等不同 Grader 类型，这也说明评分器应匹配可判定对象。多个信号组合时应保留原始维度与失败原因；加权总分只用于排序辅助，不能让一个高分维度抵消越权或数据泄露。

结果对了不代表过程安全，过程不同也不一定错

高风险 Tool、权限、审批和外部副作用属于硬过程约束，即使结果正确也不能放行。开放研究、总结和规划任务则可能有多条有效路径，强制逐步匹配会惩罚更优方案。应把约束分成必须满足、禁止发生和允许变化三类。

最终状态必须由权威业务系统验证。过程指标用于解释结果与风险，不是结果的替代品；步骤数、Token 和调用次数只在成功与安全条件相当时比较。一个少两步却省略复核的版本，应被判为风险退化。

离线与在线互补

可重复回归、快速定位、无真实副作用

离线评测固定数据、系统版本和工具环境，适合 CI 回归与组件诊断。它的边界是无法完整重现真实分布、外部漂移、长周期价值和用户适应。

真实输入下不影响用户的影子评估

Shadow 复制真实输入给候选版本，但禁止真实副作用，输出也不展示给用户。需要处理生产数据授权、并发成本和不可重放依赖；“没有影响用户”不代表没有数据风险。

业务成功、用户行为、事故和长周期价值

线上指标覆盖业务结果、用户纠正、投诉、人工处置和事故，能发现离线集外的失败。实验必须预先定义分流单元、护栏、观察窗口和停止条件，并由发布门禁控制暴露范围。

总平均值会掩盖关键退化

按风险、任务、租户、语言、模型、Tool 与上下文长度切片，并为核心切片设置不可退化底线。报告同时给出分子、分母、效应量和不确定区间，小样本不得用多位小数制造精确感。

阈值应绑定业务损失和人工容量。例如人工接管率上升两个百分点，若超出运营团队容量，即使总体成功率略升也不可放行。多重切片探索用于发现问题，正式门禁则应预注册关键切片，避免事后挑选支持预期的结果。

评测输出要能推动修复

失败报告包含错误分类、代表性 Trace、受影响切片、根因假设和验证计划。根因候选分到数据、模型、Prompt、Tool、Runtime 或 UX，但不凭最后一个报错直接定责。修复后先跑目标切片证明机制成立，再跑全量防止跨层回归。

一份可发布的 Scorecard 还要记录未修复风险、上线限制、Owner 与复审条件。实践验收应故意注入检索漏召回、Tool 超时和审批拒绝，检查指标能否落到正确层、Trace 能否还原因果链。