AI Agent Engineer

AI Agent Engineer

评测报告、审计与治理

13 min read

评测报告、审计与治理

本节目标

把一次评测从“终端里有个分数”提升为可复核、可批准、可追责且能过期重审的发布证据，并正确处理质量、安全、公平、成本与延迟之间不能简单平均的约束。

评测报告要支持什么决策

报告开头先写决策问题，例如“是否允许candidate-2026-07-14进入5%灰度”，而不是先放漂亮图表。最小报告应回答：

  1. 被测对象是什么：模型、Prompt、检索、工具、策略、harness和预算的完整版本；
  2. 使用什么数据：数据集版本、来源、split、覆盖、去重与冻结时间；
  3. 如何评分：grader/rubric版本、人工校准、未知值和失败优先级；
  4. 得到什么证据：总体、切片、样本数、区间、失败类型和代表案例；
  5. 能做什么结论：PASS、REVIEW或BLOCK，以及结论的适用范围；
  6. 谁批准、例外到何时、上线后怎样停止和回滚。

单一平均分不能独立回答这些问题。原始逐case结果、配置和变更差异必须可追溯，但涉及个人或敏感内容时，应保留经过授权、最小化和脱敏的证据，而不是把完整生产Prompt塞进报告。

多维门控与优先级

维度典型证据常见门控方式不能证明什么
任务质量成功率、precision/recall/F1、人工rubric最低总体和关键切片门槛不自动证明安全
安全/隐私禁止动作、泄露、越权与覆盖率严重单例或关键切片硬BLOCK“0次”不等于检测完整
公平与群体影响有业务/权益意义的群体切片、错误差异风险评审、差距调查、法规流程小样本差距不是歧视因果证明
成本每请求、每成功任务、最坏路径估算REVIEW或预算上限估算不等于账单
延迟/可靠性均值、p95、超时、重复试验SLO相容门槛或灰度guardrail离线时延不等于生产时延

先声明优先级，再看结果。例如：关键安全失败 > 关键切片失败 > 总体质量 > 成本/延迟优化。否则一个质量均值提升可能在汇总时“抵消”越权动作。硬门槛用于不可交换的风险；软门槛进入人工REVIEW，并要求明确所有者、补充证据和截止日期。

“公平”不是给每个切片算差值后自动下结论。切片选择、潜在伤害、样本代表性、统计不确定性和合法处理敏感属性都需要领域、受影响方、隐私/合规与工程共同定义。本课程项目只演示切片差距作为调查信号。

失败分类与根因证据

先把症状归类，再验证根因：

  • 数据问题：错误答案、split泄漏、过期文档、标签冲突；
  • grader问题：rubric含糊、程序bug、judge偏差、奖励漏洞；
  • harness问题：工具缺失、预算不同、沙箱残留、依赖故障；
  • 系统问题：检索、生成、工具选择/参数、策略或最终状态失败；
  • 统计问题：样本过少、选择偏差、相关trial、多重比较；
  • 报告问题：口径变更未标注、只报均值、隐藏未知和失败样本。

Trace能说明“在哪里发生”，环境状态能证明“最后发生了什么”，配置diff能说明“改变了什么”；三者结合才能形成根因假设。相关时间顺序不是因果证明，修复后应新增最小回归case并在相同契约下复测。

结论有效性检查

高分只有在“声明—harness—有效性检查”三层同时成立时才支持结论。报告应在汇总前审计：任务或grader是否损坏，系统是否利用奖励漏洞，安全拒绝是否被误算失败，测试内容是否被训练、提示、检索或浏览发现，提交者是否反复适配隐藏测试，以及系统是否因识别到评测环境而改变行为（evaluation awareness/sandbagging风险）。这些风险不一定都能被黑盒运行证实，未知必须保留为未知。

对确认、疑似和无法判断的case分别计数，公开检测方法、覆盖与误差边界；若排除或重评分，同时保留原始结果和调整后结果及理由。不能静默删掉“坏题”来抬高分数，也不能把“未检测到污染”写成“没有污染”。

可复现与审计清单

每次有发布意义的运行至少冻结或记录：

  • suite、dataset、rubric、grader和人工标注指南的版本或内容摘要；
  • baseline/candidate的模型快照、Prompt、代码、工具、检索索引和策略版本；
  • harness、超时、重试、turn/token预算、并发、随机种子和环境依赖；
  • 逐case结果、失败证据、样本排除、未知值、运行时间、完整SHA-256证据摘要、摘要算法/字节表示/版本，以及仅用于终端/看板对照的短指纹；
  • 运行者、评审者、批准者、利益冲突、例外理由与到期时间；
  • 数据授权、访问控制、保留期、删除流程及是否含合成/生产样本。

完整SHA-256摘要只有在接收端复用同一算法、版本和输入字节表示时，才可检测所绑定输入是否变化；短指纹仅方便人读，不能作为跨发布、线上窗口或审批系统的唯一绑定键。若JSON要跨语言哈希/签名，显式传递原始字节或采用并测试规范化方案，不能把某个语言的“键排序”误称为通用canonical JSON。两者都不能代替签名、访问控制或来源真实性。若grader、dataset或harness版本改变，应建立新比较边界；不要把新旧曲线直接拼接成“持续提升”。

离线、持续评测与运行监控的治理边界

  • 本库的离线/持续评测在版本化case和契约上反复运行，用于开发、回归和发布门禁；
  • 运行监控持续观察真实流量、遥测、SLO与事故，输出需要人工分诊的候选而非直接写入评测集；
  • Benchmark设计固定更长期的比较协议、任务分布、报告规范和维护规则，使多系统结果可比。

同一评分器可以跨离线与线上使用，但线上数据有采样、标签延迟、隐私和分布漂移，不能把监控曲线直接当冻结测试集结果。生产失败必须先保留受控证据引用，经人工分诊、脱敏、去重、许可和最小复现，再由评测负责人接纳为新版本回归case；过程详见 离线到线上证据交接与回归闭环。全过程还要防止测试答案进入开发提示或训练数据。

工具事实与版本边界

截至2026-07-22，OpenAI官方弃用页记录：Evals平台于2026-06-03宣布弃用；既有eval在2026-10-31变为只读；Evals dashboard和API计划于2026-11-30关闭。其Graders页面也明确说明grader随eval/fine-tuning工作流进入弃用过渡。因此本课程只把其evaluation best practices与trace grading作为方法参考，不教授新建Evals API资源或复制即将失效的grader配置。

MLflow官方latest文档在本次核对时明确区分经典ML的mlflow.models.evaluate()/EvaluationMetric与GenAI的mlflow.genai.evaluate()/Scorer，两套接口不可互操作；旧mlflow.evaluate已在MLflow 3中弃用。基于Trace的自动评测是另一条能力，当前只支持LLM judges、不能直接使用code-based scorers：创建或启用judge时最多只回看一小时前的Trace/会话，仅更新judge配置不会重评已经评估的Trace。这是产品现状而不是通用评测理论；采用时应固定实际MLflow包版本、阅读相应版本文档并做迁移测试。本课程离线项目不依赖MLflow。

练习

  1. 为“客服Agent候选版本进入5%灰度”写一页决策报告：列出硬门槛、软门槛、批准人、例外到期和上线停止条件。
  2. 情景：总体F1从0.82升到0.87，但中文高风险切片Recall从0.76降到0.52，且只有20个样本。分别写出已证实、未证实、决策和补充证据。
  3. 给一份只有总分的旧报告补齐数据、grader、harness、区间、失败分类、隐私和版本字段。

自测与掌握检查

  • 能解释为什么安全/隐私硬失败不能被质量均值抵消；
  • 能区分切片差距、统计证据与公平因果结论；
  • 能从case、Trace、outcome和配置diff组织根因证据；
  • 能列出复现一次评测所需的版本、环境和审批记录；
  • 能准确说明评测体系、Benchmark设计与运行监控的边界；
  • 能识别已弃用平台入口，保留方法而不照抄即将失效的API。

小结与下一步

评测只有进入版本、审批、例外、回滚和持续维护流程，才成为可靠的工程门。先阅读 离线到线上证据交接与回归闭环，再完成 离线分层评测流水线，亲自验证关键安全case为何优先于总体均值。

参考资料

Backlinks