评估：如何判断系统是否真正有效

“模型有能力”、“演示看起来不错”和“用户似乎很满意”是不同的主张。单独来看，任何一个都不足以证明某个特定的 AI 原生（AI-native）系统能在其预期任务上可靠运行。

部署后的行为不只来自一个模型。指令、上下文、检索、工具、权限、控制流程、应用代码与执行环境都会影响结果。因此，评估必须面向整个系统及其预期工作，而不能只看一个模型分数。

论点

评估把预期的系统行为转化为可以检查的证据。它首先为有代表性的工作定义成功、可接受的变化和不可接受的失败，然后从输出、执行过程与最终结果三个层面评估模型及其周边系统。

评估不是一项单独的基准测试，也不只是发布前的一道门槛。它是一个持续的工程反馈过程：

预期结果 → 明确标准 → 代表性任务 → 观察到的行为
   ↑                              ↓
   └──── 诊断、修正与新增用例 ────┘

这条回路并不替代产品判断。它让当前判断足够明确，以便测试、质疑与修订。

从主张开始

在选择指标之前，先说明系统应该为谁做什么。

“产出好答案”过于含糊。对比三个更有用的主张：

“对于受支持的退货请求，助理能识别适用政策并给出正确的下一步。”
“对于一组明确指定的代码仓库，编程智能体能产出通过必要测试、且不修改受保护路径的补丁。”
“对于范围内的研究问题，系统能区分有出处的结论与无支撑或相互冲突的证据。”

每个主张都对应不同的任务、证据与后果。评估对象可能是一条回复、一项完成的工作产物、一次工具操作、环境中的实际变化，或后续的业务结果。

因此，评估很接近一份可检验的系统规格。它能及早暴露尚未明确的需求：何谓“受支持”、哪些测试是必需的、哪些来源有效、允许哪些变化，以及系统无法完成任务时应当如何处理。

基准、模型与系统评估

这些层次回答不同的问题。

层次	问题	能支持什么	单独无法建立什么
公共基准	在标准化流程下，模型或系统如何比较？	能力筛查与广泛比较	我们的上下文、工具、用户与风险边界内的表现
模型或提示评估	模型在已定义的输入–输出任务上如何表现？	针对受限能力的模型与提示选择	检索、工具、权限或副作用的正确性
组件评估	某个检索器、路由器、工具或规则检查能否履行预期职责？	诊断与局部回归检测	端到端任务成功
系统评估	组装后的产品能否在约束内完成代表性工作？	发布证据与架构比较	每一种未来的生产环境条件
生产环境结果评估	真实使用是否产生了预期效果且没有不可接受的伤害？	检验真实环境中的适用性并发现新失效	如果缺少严谨设计，就很难判断具体原因

HELM 说明，即使只评估模型，也需要观察多种场景和指标：不同系统往往各有权衡，并不存在一个模型在所有关注点上全面占优（Bommasani 等, 2023）。对于完整应用，多角度评估更为重要，因为模型只是其中一个依赖项。

评估的基本单位

使用不同术语，避免让一个百分比掩盖了实际测量的内容。

一个任务是具有已定义输入、相关环境与成功标准的单个测试用例。
一次试验是指在已记录配置下对一个任务进行的一次尝试。
一个评估器是用于判断某次试验某一方面表现的规则、程序、人员或模型。许多工具把它称为 grader。
一条**追踪记录（trace）**会记录试验中的关键交互：模型响应、工具调用、返回结果、状态变化与审批。
一个**结果（outcome）**是最终与任务相关的状态或效果。
一个评估套件是为测量已命名的能力、风险与回归而维护的任务集合。

Anthropic 的智能体评估文章使用了类似区分，并强调评估对象是模型与智能体运行框架（harness）共同组成的系统（Anthropic, 2026）。这些定义很有用，但并非通用标准；接入具体工具时，仍应尊重该工具采用的术语。

评估输出、过程与结果

一个多步骤系统可能在若干层面上成功或失败。

输出

产出的答案或工作成果是否满足要求？

检查可能涵盖正确性、相关性、完整性、溯源、政策、结构与表达。对于已知标识符或分类任务，精确匹配是合适的；对于具有多种有效形式的解释或设计提案，它通常过于狭窄。

过程

系统是否采用了可接受的路径？

重要的过程准则可能包括：许可的数据访问、正确的工具参数、所需的审批、预算限制、来源溯源、不修改受保护资源、以及不产生重复副作用。当多种策略都有效时，不要强求一种唯一的推理轨迹。仅在路径本身承载风险、义务或诊断价值时评估过程。

结果

预期的改变是否真的发生了？

智能体可能会说“预订已完成”，但实际并没有生成预订记录。补丁可能读起来不错，但测试没有通过。客服回复可能内容准确，但客户的问题仍未解决。检查结果需要查看环境中的真实状态或后续信号，而不能只相信系统对自身是否成功的表述。

这些层面可能出现矛盾。通过未授权数据访问得到的正确结果并不可接受。遵循合规流程却得到错误结果也不算成功。一个表达流畅的输出，如果执行过程和最终结果都没有得到验证，最多只能证明它在表达上看起来不错。

构建具代表性的任务

一个评估套件是对预期工作的建模。其效用取决于它包含与排除了什么。

从四类开始：

典型案例：系统被明确设计用来支持的高频工作。
边界案例：罕见但合理的输入、含糊的请求、缺失数据、非常规格式、长上下文与工具错误。
对抗案例：试图绕过政策、重定向工具、暴露数据或利用信任边界的尝试。
后果严重的案例：一旦出现看似合理的错误，就可能带来高成本、难以逆转的影响，或法律与伦理问题。

对重要的数据子集分别统计，而不是只看总体平均值，例如语言、用户群、任务类型、数据来源、工具路径、后果等级与环境条件。很高的总分也可能掩盖系统在规模较小但非常重要的群体中的失败。

任务来源可以包括产品需求、领域专家提供的用例、历史事件、在符合法律与安全要求的前提下保留的生产记录、用户更正，以及有意构造的压力测试。合成用例可以扩大覆盖范围，但不能假定它们能够还原真实使用情况。

把用于日常迭代的开发集，与用于判断系统能否适应未见案例的留出测试集分开。围绕固定套件反复优化，会逐渐削弱它检验新行为的能力。可以用新发现的案例更新套件，同时保留一组稳定的回归测试用例。

让评估器匹配主张

没有任何一种评估器适合所有标准。

评估器	适用场景	重要局限
确定性规则或数据结构	格式、数值范围、授权、精确字段、不变量	无法判断编码规则之外的语义质量
可执行检查	代码、查询、模拟、环境状态、外部副作用	测试环境可能遗漏真实条件，或仅编码了不完整的需求
参考对比	分类、抽取、有已知答案的受限问题	参考集可能不完整，且可能惩罚有效的替代答案
人工评审	细微差别、领域正确性、后果、演变中的要求	成本高、速度慢、不一致，且受偏见或疲劳影响
基于模型的评估	可大规模运行的、按评分标准进行的比较或分类	继承模型偏差、可能被操纵，而且不能充当事实依据
用户或业务结果	真实有用性与外部效应	往往延迟、受混杂因素影响、稀疏，且受选择使用者所影响

当一个主张包含多个方面时，可以组合使用不同评估器。例如，研究型回答可能需要确定性的引文格式检查、来源核验、针对综合质量的领域评分标准，以及判断系统是否在证据不足时正确拒绝作答的单独测试。

OpenAI 的评估 API 文档建议进行任务特定的评估、使用具代表性的生产与专家数据、持续评估，并用人工反馈对自动评分进行校准。它还指出了模型裁判的“位置偏置”和“冗长偏置”（OpenAI, “Evaluation best practices”）。由于这是 OpenAI 产品文档中的建议，而非独立标准，请在本地任务上验证这些建议及任何评估器。

将模型评估器视为测量仪器

基于模型的评估器能以可承受的成本开展大规模语义评估，但其得分是由另一个可变模型生成的测量值。在将其用于发布决策之前：

编写具体评分细则，并附带对重要区分的示例；
建立一个经人工审阅的校准集；
衡量一致性并检查分歧，而非只看平均分；
测试对顺序、长度、风格、身份与提示注入（prompt injection）的敏感性；
当更契合问题时，采用盲评或成对比较；
对评估器的模型、提示、细则与参考材料进行版本管理；以及
在评估器不确定或后果较高时，保留人工复审通道。

当任务分布、系统输出风格或评估器模型发生变化后，原先在某个数据集上得到的高一致性不一定还能保持。评估工具一旦变化，就需要重新校准。

可变行为需要多次试验，而不是个别案例

一次任务运行只是一个样本，不能代表系统的可靠性。当行为可能变化时，应运行足够多次试验来回答实际产品问题，并记录模型、提示、上下文、工具、规则与环境的版本。

前一章关于不确定性的内容解释了 pass@k、pass^k，以及为何候选生成不同于重复的有副作用执行。此处的评估原则更简单：

当重复使用或抽样是产品的一部分时，进行多次试验；
按与该使用方式相匹配的方式聚合结果；
将运行间波动与配置或环境的有意更改区分开来；以及
报告各类成功与失败的次数和失效模式，而不只是一个好看的平均数。

十个抽样草稿配合一个可靠的验证器可以构成有效的设计。若任一尝试都可能“下单生效”，那么十次购买尝试并不是一种可靠性方法。评估配置必须能代表实际的控制流。

评估在发布之后仍将继续

离线任务必然不完整。生产环境会带来新用户、新输入、不断变化的数据、工具中断、策略变化，以及评估套件未预料到的行为。

使用生产证据来发现——而非自动定义——新的评估用例：

明确的用户更正与申诉；
失败或被放弃的任务；
人工接管、改判与升级处理；
意外的工具序列或重复重试；
规则拦截与安全事件；
结果反转或后续对账失败；以及
输入、来源、成本或延迟的分布变化。

生产遥测必须遵循隐私、同意、访问与保留要求。追踪记录具有诊断价值，并不意味着可以无限期存储每条提示、每份文档或模型的内部推理内容。

早期生产机器学习研究提出了一个更普遍的观点：模型质量存在于由数据、代码、基础设施与监控共同构成的系统之中。因此，ML Test Score 不只关注离线模型指标，也评估系统的上线准备程度（Breck 等, 2017）。生成式系统同样需要这种系统视角，并将其扩展到开放式输出与多步操作。

权衡

选择	益处	成本或风险
范围明确且可执行的标准	快速且可重复的回归检查	可能优化容易测量的部分，而不是最重要的部分
综合性的人工评分标准	捕捉细微差别与不断变化的判断	成本高、不一致，而且难以持续运行
大型套件	更广覆盖与更好地发现稀有案例	维护成本、迭代更慢，且若用例薄弱则更易产生虚假信心
稳定套件	便于比较不同时期的结果	可能被过度针对，并逐渐偏离生产环境
频繁更新的套件	更好地覆盖新出现的失效	更难进行长期比较，而且标注可能受到污染
过程追踪评估	发现不安全路径并支持诊断	可能拒绝有效的替代路径，且提升数据敏感性
结果评估	衡量真正重要的效果	结果可能延迟、噪声大，或受系统之外因素影响

目标不是让评估用例越多越好，而是获得足以负责任地做出下一项决策的证据。

失效模式

基于直觉的评估

少量令人印象深刻的演示取代了明确标准与有代表性的用例。系统究竟改进还是退步，只能依靠主观争论。

基准替代

一个公共模型分数被当作应用有效的证明，尽管其上下文、工具、策略与用户从未被测试。

单一分数掩盖多重失败

正确性、安全性、成本、延迟、用户投入与恢复能力被平均成一个不再回答清晰问题的数字。

把标准答案用错地方

一个参考响应被当作开放式任务的唯一可接受答案。有效的多样性被惩罚，而用词相似但无支撑的响应却可能通过。

评估器缺乏独立性

同一家族的模型在类似证据缺失下既产出又裁判答案，于是“吻合”被误当作独立验证。

只奖励固定执行路径

套件奖励一种预期的工具序列，即使另一条安全路径也能达成要求的结果。系统学会“像测试一样”，而非解决任务本身。

满足于测试套件分数

在静态套件上的分数提升，但生产失败在变化。没有机制把事件、纠正或分布漂移纳入评估。

只有可观测性而无评估

系统存储了大量追踪记录，但没有用于解读它们的标准。数据体量增长，却无法产出发布决策或工程启示。

本手册的判断

在扩大模型的自主决策空间或系统可影响的外部范围之前，先写一份最小评估简报：

能力及目标用户：
任务结果：
支持与不支持的情况：
允许的变化：
不可接受的输出、过程与结果：
典型、边界、对抗和后果严重的任务：
每次试验记录的配置：
试验次数及汇总规则：
确定性评估器：
人工评估人员与评分标准：
模型评估器及其校准证据：
结果证据：
需要单独观察的重要类别：
评估支持的发布或升级处理决策：
可以补充新用例的生产信号：

如果团队暂时无法完成这份记录，仍然可以开展实验；但还不能据此断言系统能够可靠运行。

清单

参考文献与使用方式

Anthropic, “Demystifying evals for AI agents” (2026) — Anthropic 工程文章，支持区分任务、试验、评估器、追踪记录、结果、运行框架与评估套件，并将模型与智能体运行框架作为一个整体进行评估。它并非统计学标准。
OpenAI, “Evaluation best practices” — OpenAI 维护的 API 文档，面向 OpenAI 评估工作流；本章用它支持任务特定与持续评估、具代表性数据集、人工校准，以及对已知模型裁判偏差的注意。其示例与产品性建议需在本地验证，不能视为独立评估标准。
Bommasani et al., “Holistic Evaluation of Language Models” (2023) — 经同行评审的模型评估研究，支持使用多个场景和指标、呈现权衡，并公开评估材料。其评估对象是模型，而非完整部署的产品。
Breck et al., “The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction” (2017) — 生产机器学习研究，支持对更广泛的系统进行测试与监控。它早于当前的生成式模型和智能体多步执行过程。
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 (2024) — 自愿性全生命周期风险管理资料，支持与用例相称的验证、多种评估方法、文档化、反馈与监督。
Google, “Production ML systems: Monitoring pipelines” 与 “Dividing the original dataset” — Google 教育材料，用于支持分别观察重要数据子集、采用真实世界指标和留出数据，也提醒团队反复使用同一测试集会降低其检验价值。