评估系统与质量门槛

“基础”部分将评估定义为把预期行为转化为证据的工程实践。“生产工程”需要回答一个更难的问题：当模型、提示词、上下文、工具、策略、数据、评估器和环境都在变化时，组织能否持续产出可比较的证据？

一份曾经得到 84% 准确率的实验笔记并不构成评估系统。如果缺少对应的任务、系统配置、评估运行框架、环境、评估器版本、试验记录和决策规则，这个数字就无法可靠说明某项待定变更究竟更好、更差，还是仅仅表现不同。

论点

只有把待验证的主张、任务、环境、评估运行框架、系统配置、评估器、试验和决策规则作为同一个版本化测量系统来维护，评估才能成为生产控制手段。

质量门槛依据这些证据，决定阻止某项变更、交由更高权限的负责人判断，还是允许它进入下一阶段。通过质量门槛，只能支持它原本针对的具体决策和系统运行主张；这并不能证明系统在所有未来条件下都正确、安全或已经准备就绪。

评估系统比评估套件更大

评估套件只是生产系统的一部分。完整的测量路径包括：

产品主张与风险边界
  -> 覆盖关系与任务
  -> 测试环境配置与评估运行框架
  -> 待测系统配置
  -> 试验与捕获的证据
  -> 评估器与复核
  -> 估计值、不确定性与有效性审查
  -> 质量门槛决策
  -> 诊断、变更与套件维护

只要其中任何一部分发生变化，结果的可比性就可能改变。OpenAI 当前关于第三方智能体评估的文章强调，只记录模型名称远远不够：提示词、工具、控制逻辑、防护措施、重试、预算和环境共同定义了被测系统，以及评估能够展现出的行为（OpenAI, 2026）。即使内部产品评估只用于发现回归而不是公开比较，也应满足同样的记录要求。

对测量系统进行版本管理

将以下内容视为生产资产，而不是一次性测试输入：

资产	必须可恢复的内容
主张与覆盖关系	预期行为、排除行为、风险类别、用户与任务切片
任务	输入、初始状态、允许资源、成功标准、来源、审查状态
数据集或案例集合	成员关系、抽样规则、标签、划分、保留与访问约束
测试环境配置	服务、数据快照、时间、权限、随机种子、故障注入、清理行为
评估运行框架	指令、上下文组装、接口、控制流、预算、重试、停止规则
系统配置	模型、提供方、参数、提示词、检索、策略、代码、依赖、功能开关
评估器	程序、模型、提示词、评分标准、参考集、校准集、回退与复核规则
运行记录	资产版本、试验标识符、时间戳、成本、延迟、追踪记录、结果、错误
报告与决策	估计值、不确定性、切片、有效性问题、门槛判定、负责人、例外与到期时间

内容哈希或不可变的产物标识符，比“最新提示词”或“生产模型”之类的模糊标签更可靠。密钥和私有数据不应复制到报告中，但记录必须能够指向所使用的受保护版本或快照。

可复现并不意味着每个有波动的输出都必须完全重复。它意味着团队能够重建条件、重新运行等效实验、区分预期随机性与失控变化，并解释实质差异。

英国 AI Security Institute 开源的 Inspect 框架提供了一个具体示例：任务、求解流程、工具、评分、日志和扩展都可以表示为可组合、可共同进行版本管理的代码（Inspect AI，固定到 2025-11-28 标签）。这一架构结论并不要求团队采用 Inspect 或任何其他特定平台。只要保留同样的信息，小团队也可以从代码仓库、结构化结果文件和可复现脚本起步。

围绕决策组织套件

单一的“智能体总分”很少能够回答实际的生产问题。应建立覆盖关系表，把每项系统运行主张与对应任务、重要切片、评估器和决策联系起来。

有用的套件维度包括：

产品能力，例如研究综合、退款处理或补丁生成；
后果、可逆性和所需权限；
典型、边缘、对抗性、高后果以及曾经失败的案例；
用户群体、语言、地域、数据源、租户和可访问性需求；
组件或执行路径，例如检索、路由、审批、执行和恢复；
环境条件，包括陈旧数据、依赖失败、长上下文和中断工作。

ISO/IEC 25059:2023 提供了一套用于规定和评估多项 AI 系统质量特性的国际质量模型（ISO/IEC 25059:2023）。它可以帮助检查质量要求是否过于狭窄，但并没有定义本手册的评估套件结构或智能体发布门槛。该标准正在修订，因此引用时必须记录实际采用的版本。

保留稳定的回归锚点，以便结果能随时间保持可比，但同时要维护受治理的路径，用于添加生产失败、专家案例、新威胁以及变化后的产品需求。至少应区分：

开发集，工程师在迭代时可以检查；
留出案例，用于偏差相对较小的决策估计；
受限的对抗性或高后果案例，其泄露会削弱测试；
已退役或被隔离的案例，并保留其不再适用于该主张的原因。

不要因为系统无法通过某个困难案例就悄悄删除它。只有经过对需求、参考结果、环境或有效性的审查，才应修改或退役一个案例。

让环境成为测试的一部分

智能体行为取决于其能够观察和改变的世界。评估环境应定义：

初始权威状态和重置行为；
身份、权限、凭据和审批规则；
可用接口及其版本；
网络、时钟、区域设置和依赖条件；
token、轮次、时间、重试、并发和费用预算；
浏览或检索是否会暴露答案；
已经生效的外部影响如何隔离与验证；以及
保留哪些日志和运行产物。

当真实操作会造成不可接受的影响时，应使用隔离租户、合成账户、沙箱、模拟服务或可回放快照。模拟环境必须保留与待验证主张有关的关键语义。一个总是返回成功的模拟支付 API 无法测试对账；代码仓库历史中已经包含答案的编程任务也无法测试真正的问题解决能力。

标准化与充分展现能力之间存在张力。固定的评估运行框架有助于判断不同配置之间的差异来自哪里；更贴合模型特性或能力更强的运行框架，则可能揭示通用接口所掩盖的能力或失效。每次运行都应明确说明它准备回答什么问题：

回归比较：让任务、评估运行框架、预算和评估器保持足够稳定，以比较候选配置与基线；
能力探索：使用足以发挥系统能力的可信评估运行框架和预算，了解系统能够做到什么；
安全或滥用测试：模拟具有现实能力的对手并记录其攻击资源，而不是只测试一条便于执行的提示词。

不要在没有说明的情况下，把这些目的的结果混在一张表里。

将评估器视为测量仪器

即使被测系统本身没有退化，评估器也可能发生变化。代码可能含有缺陷，参考答案可能过期，人工评审标准可能逐渐偏移，负责评分的模型更新后也可能改变分数含义。

对每个重要评估器：

明确它负责判断的主张，以及需要区分的失效类型；
使用经过人工审阅或其他可靠方式验证的案例来测试它；
包含正例、负例、边界例、对抗例和无效输入；
测量分歧并检查其模式；
在存在可靠参照时，记录误判为通过和误判为不通过的情况；
在相关场景下，测试它是否会受到输出顺序、篇幅、风格、身份信息和提示注入的影响；
对代码、模型、提示词、评分标准、参考集和阈值进行版本管理；以及
定义需要重新校准或交由人工复核的触发条件。

判断一致不代表评估有效。两个评估者可能因为具有相同盲点而得出一致结论。如果评审者缺乏所需的领域知识，或只能看到不完整的证据，即使形成共识也未必可靠。系统应明确由哪些人负责复核哪些标准。

Anthropic 建议组合不同类型的评估器，使用专家判断校准基于模型的评分标准，直接阅读追踪记录，并在自动化评估之外配合生产监控和人工审查（Anthropic, 2026）。这是由提供方发布、具有实践价值的生产经验，但不能证明某一种评估器组合适用于所有应用。

报告波动与不确定性

当系统行为会发生变化时，仅报告 91% passed 这样的点估计并不完整。至少还应报告：

分子、分母、任务数和每个任务的试验数；
聚合统计所采用的单位：试验、任务、用户、对话或其他分组；
抽样与聚合规则；
估计值及合适的不确定性区间；
使用同一批任务比较两个配置时的配对差异；
重要切片结果和缺失数据；
无效、超时、被拒绝或结果无法确定的试验；以及
与该决策相关的实际效应量。

对于相互独立试验中的简单二元比例，Wilson 区间等二项比例区间通常比一个没有说明精度的百分比更有信息，尤其是在比例接近 0 或 1、或者样本量较小时（Wilson, 1927）。但智能体评估经常不满足试验相互独立的假设：同一任务的多次尝试彼此相关，多个案例共享同一环境，评估器本身带有噪声，自适应重试也会改变实际试验过程。只有在方法假设与评估设计相符、且这些假设已经记录时，才能使用配对分析、分层模型、Bootstrap 或其他统计方法。

不要规定统一的试验次数，也不要机械套用 p < 0.05。在运行成本较高的质量门槛评估之前，应先确定：

哪种退化或改进对产品有意义；
对该后果级别可以容忍多大的不确定性；
这项质量门槛是在检查绝对要求、比较候选与基线，还是两者兼有；
哪些切片需要各自的最低证据；以及
当套件无法判定该决策时会发生什么。

统计显著性并不会让一个差异变得重要，缺乏显著性也不能证明两个系统等价。即使整体通过率很高，一次已经确认的未授权转账也足以阻止发布；而一个统计结果非常明确、实际幅度却很小的风格变化，可能对产品没有重要影响。

将质量门槛设计成决策记录

一项有效的质量门槛包含若干相互独立的部分：

受控的变更阶段
系统变更与候选配置
基线与比较方法
绝对要求
非退化限制
目标改进
所需切片与最低证据
有效性与评估器状态检查
成本与延迟边界
决策负责人和升级处理路径
例外授权、补偿措施和到期时间
结果、证据链接、理由和时间戳

将三种规则分开：

硬性要求：已经确认的策略、安全、隐私、授权、数据完整性或其他不可接受的失效，不能通过计算平均分来抵消。
非退化规则：考虑统计不确定性后，重要指标和切片的退化不得超过事先定义且具有实际意义的幅度。
改进目标：期望的改进可以指导优化，但不一定阻止每一次变更。

避免把它们折叠成一个加权分数。显著的延迟改善不能抵消未授权的数据披露。更高的平均答案质量分数不能掩盖关键语言的回归。如果权衡是正当的，就让具有相关产品或风险权限的人明确决定。

质量门槛的结果不应只有 pass 和 fail。更完整的结果包括：

通过（pass）：所需证据支持该变更进入下一阶段；
不通过（fail）：已经触发事先定义的阻断条件；
证据不足（inconclusive）：证据波动过大、不完整、无效或互相矛盾；
升级决策（escalate）：这项权衡或潜在后果需要由指定负责人判断；
批准例外（exception granted）：获授权的负责人接受一个有时限的偏离，并记录理由、补偿措施和后续工作。

在看到不符合预期的结果后才修改阈值，属于策略变更，而不是测试修复。系统应保留原有决策，说明修改理由，并重新评估受影响的证据。

使用分层评估节奏

并非所有评估套件都需要进入每一轮开发循环。可以采用如下分层节奏：

阶段	目的	典型证据
本地或 PR 冒烟测试	快速发现明显的接口约定和行为回归	小型确定性子集、评估器测试、必要时使用固定随机种子
合并前或持续集成	保护常见能力和硬性不变量	稳定回归套件、配对的候选–基线运行
定期完整运行	发现不同切片、行为波动和依赖问题	更大的套件、多次试验、对抗条件和故障条件
发布前资格审查	支持一次明确的配置推广或能力扩展决策	留出和受限案例、完整配置记录、有效性审查、门槛负责人签署
影子或金丝雀证据	在广泛暴露前检查类生产流量和基础设施	受控流量、结果对账、回滚信号、用户影响限制
生产反馈	发现漂移和未预料到的失效	结果指标、生产事件、更正、申诉、抽样审查

Anthropic 指出，自动化评估适合开发和 CI 阶段，而生产监控、用户反馈、追踪记录审查、A/B 测试和系统化人工评估则分别弥补不同缺口（Anthropic, 2026）。更早的生产机器学习研究也提出，生产就绪程度取决于对数据、模型、基础设施和服务行为的共同测试与监控，而不能只看离线模型质量（Breck et al., 2017）。

《测试、变更与发布》一章负责 CI、分阶段发布、功能开关、兼容性和回滚机制；本章只负责这些机制需要使用的行为证据与决策语义。

审计有效性，而不仅是分数

评估系统本身也需要质量保证。应审查成功、失败和边界案例的样本。调查：

本身有缺陷、含义模糊、无法完成、重复或标注错误的任务；
环境信息泄露、不稳定的依赖、过期快照和清理失败；
通过训练数据、公开答案、浏览、仓库历史或记忆产生的污染；
钻评分器或评估运行框架的漏洞，以及其他未预期的捷径；
改变分数含义的拒绝或防护措施；
系统意识到自己正在接受评估，或者表现出与正常部署不同的行为；
评估器漂移、提示注入，或对风格而非实质的系统性偏好；
由于开发者反复接触而导致的套件过拟合；以及
报告的总体结果与重要生产切片之间的不匹配。

OpenAI 在 2026 年对代码能力评估进行审计时发现，一个知名基准中有相当一部分任务存在问题，足以改变人们对分数的解释。这说明即使执行过程可以复现，基准本身仍可能失去有效性（OpenAI, 2026）。该报告中的缺陷比例只适用于被审计的数据集；可以推广的结论是，评估任务和评估方法本身也必须接受测试。

应单独记录无效试验，而不是把每一次基础设施失败都计为模型失败，或悄悄将其丢弃。如果排除规则实质性地改变了结果，应同时报告该规则及其影响。

运行反馈回路

评估系统需要负责人和维护工作：

能力负责人定义系统运行主张和受支持的任务分布；
领域专家负责可靠的参考结果和语义评分标准；
风险或策略负责人定义硬性要求；
评估维护者负责评估运行框架、环境、校准和报告；
服务负责人把生产结果和生产事件转化为新的案例；以及
一位明确指定的决策负责人允许或拒绝变更进入下一阶段。

单独跟踪套件健康状况与系统性能：任务年龄、无效案例率、不稳定运行率、评估器分歧、未审查的生产失败、运行时长、成本、覆盖缺口、例外数量以及距上次校准的时间。

把所有生产追踪记录都纳入评估，既不安全也没有必要。应执行隐私、用户同意、访问控制、留存和去标识化规则；只选择能够代表某项主张、失效或分布变化的案例；由具备资格的评审者确定预期行为；并保留案例与对应生产事件或反馈来源之间的关系。

权衡

选择	好处	成本或风险
固定套件与评估运行框架	便于进行可靠的长期比较	可能过拟合，且与生产环境的相关性逐渐下降
经常刷新案例	捕捉新行为与新失败	削弱直接比较并增加标签维护
大规模重复运行	缩小不确定性，并更清楚地看到不同切片的表现	成本、延迟、能源消耗和更慢的迭代
严格的阻断门槛	防止已知不可接受的变化	误阻断、针对指标投机，以及标准不合理时学习速度下降
灵活的专家决策	处理具体情境和合理权衡	缺少记录时容易不一致，也难以追责
基于模型的评分	可扩展的语义判断	偏差、漂移、操纵和循环论证
生产实验	更强的真实性	用户暴露、混杂、延迟结果和运营风险
一个共享平台	统一记录并降低治理难度	形成中心化瓶颈，且未必适合特殊领域

目标不是最大化自动化，而是建立一个其不确定性、成本和失效模式都适合其所治理后果的测量与决策过程。

失效模式

分数没有说明被测系统

报告只写了模型名称和百分比，却没有记录提示词、工具、评估运行框架、防护措施、预算、环境和评估器，因此结果无法支持比较或复现。

用一个总分决定一切

质量、策略、安全、延迟和成本被加权成一个数字。小类或不可补偿类别中的严重失败消失在平均值之中。

用点估计制造精确假象

两个配置得分为 82% 和 84%，然后在没有样本数、配对分析、不确定性或实际重要性的情况下宣称第二个更好。

评估全绿，任务本身却有问题

系统不断适应错误的参考结果、已经泄露的答案、不稳定环境或可以被钻漏洞的评分方法。团队只关注候选系统为什么失败，却从不审查评估资产本身。

评估器升级却未重新校准

评分模型、评分标准或参考集发生变化，历史分数却仍被直接比较，仿佛分数含义从未改变。

在结果之后编辑阈值

候选配置未通过后，团队悄悄降低了门槛。真正的决策被隐藏在测试配置中，没有作为风险例外或策略变更交由相应负责人判断。

无差别囤积生产反馈

所有提示词和追踪记录都以“用于评估”为由长期保留，造成额外的隐私和安全风险，但真正得到审查或转化为有效评估任务的案例却很少。

永久例外

临时绕过没有负责人、到期时间、补偿措施或必须完成的后续工作，最终导致质量门槛对部分团队变成可选项。

本手册建议

对于每项重要的质量门槛，都应保留如下记录：

决策与受控变更阶段：
系统运行主张：
候选与基线配置 ID：
套件、环境、评估运行框架和评估器版本：
任务、试验、切片和抽样规则：
绝对阻断要求：
非退化限制与实际幅度：
改进目标：
统计方法与假设：
无效或被排除的试验：
有效性审查发现：
质量、风险、成本和延迟结果：
质量门槛结果：
决策负责人和时间戳：
例外、补偿措施和到期时间：
证据链接和后续案例：

如果团队无法重建这份记录，它拥有的就只是一个分数，而不是可靠的质量门槛。

检查清单

参考文献及其用途

Anthropic, “Demystifying evals for AI agents” — Anthropic 工程文章，支持真实任务、组合评估器、追踪记录审查、CI 使用、生产监控和持续套件维护。其建议来自 Anthropic 和选定客户经验，而非独立标准。
OpenAI, “A shared playbook for trustworthy third party evaluations” — OpenAI 研究与工程文章，支持完整记录被测系统、说明评估运行框架与预算、检查有效性以及明确主张边界。它主要讨论前沿模型和第三方评估，本章只借鉴其中适用于生产系统的原则。
OpenAI, “Separating signal from noise in coding evaluations” — OpenAI 审计文章，作为任务和评分都可能使基准失效的具体证据。其缺陷估计不应推广到所研究的编码数据集之外。
ISO/IEC 25059:2023, “Quality model for AI systems” — 已发布的国际标准，用于支持从多项质量特性定义 AI 系统要求，并检查这些要求是否完整。公开摘要没有提供智能体质量门槛的设计方法，而且该标准正在修订。
ETSI TR 103 910 V1.1.1, “AI Testing” — 已发布的欧洲技术报告，支持明确规定 AI 测试方法与测试规范。它是一份技术报告，并非欧盟协调标准，而且范围比生成式智能体更广。
Breck et al., “The ML Test Score” — 生产机器学习研究，用于支持跨系统组件进行测试和监控、采用小范围验证，以及不能只凭离线模型分数判断生产就绪程度。其具体检查方法早于生成式智能体，需要按当前系统调整。
UK AI Security Institute, Inspect AI — UK AI Security Institute 维护的 Inspect AI 开源仓库，引用固定在标签 release/2025-11-28 对应的提交 b547763，用作版本化、可组合评估资产的实现示例。本章并不把它推荐为默认平台。
Wilson, “Probable Inference, the Law of Succession, and Statistical Inference” — 支持简单二项比例区间估计的基础统计来源。智能体试验通常需要更丰富的设计，因此本章并不普遍规定使用 Wilson 区间。