传统测试问“同样输入是否得到同样输出”，生成式系统却可能在语义正确时换一种措辞，也可能在格式完美时答错事实。于是团队很容易退回“看几个例子感觉不错”。这个方法无法比较模型快照、prompt、工具 Schema、检索索引和编排变化，更无法证明一次升级没有破坏长尾任务。

AI eval 的目标不是制造一个总分，而是把产品规格翻译成可重复的实验：哪些输入必须成功，哪些必须拒绝，哪些控制流不能发生，变化与基线相比改善了什么、牺牲了什么。OpenAI 的评测最佳实践将 eval 定义为结构化测试，并建议早评、常评、任务化、记录日志、自动化，同时用人工判断校准指标。

本文面向已经有模型功能、准备建立 CI 或发布门禁的开发者。你需要熟悉测试夹具、版本控制和基本统计。重点是平台无关的评测工程，而不是某个 dashboard 的操作教程。

规格、冻结数据集、运行、评分、门禁与失败回流组成持续评测闭环

图 1（1600 × 900）：WEB/SUN 原创 SVG。评测不是上线前的一次考试；失败完成归因后回流为带来源的新案例，下一次变更必须重新通过。

多条候选路径反复穿过固定门禁并把失败样本送回评测循环

图 2（1600 × 900）：持续回归的编辑式视觉隐喻，不表达未经测试的指标。OpenAI Image Gen × WEB/SUN，2026-07-16；项目内原创生成资产。

0. 先写“行为规格”，再收集样本

“回答要好”无法评分。把功能拆成可观察行为：意图分类正确；工具选择与参数合法；没有权限时拒绝；答案引用支持论断；证据不足时承认不足；总轮次在预算内；敏感数据不进入输出。每条规格说明适用范围、风险等级和判定方式。

评测对象也要固定。不要只写“测试 prompt v3”，而要记录完整 system version：模型与参数、developer prompt hash、工具 Schema、路由与退出策略、检索 corpus/index revision、后处理代码和安全策略。一次 run 的输出必须能关联这份不可变配置，才能重放差异。

先定义非目标。创意写作不该用事实 exact match；严格抽取不该只评文风；工具 Agent 的最终文案正确也不能掩盖越权调用。规格决定 grader，grader 不能反过来把容易测的指标变成产品目标。

1. 数据集是一份版本化产品资产

一个案例至少包含输入、可信上下文、期望行为、禁止行为、grader 所需参考和切片标签：

type EvalCase = {
  id: string;
  source: 'spec' | 'expert' | 'incident' | 'synthetic';
  input: unknown;
  expected: { claims?: string[]; toolPath?: string[]; outcome: string };
  forbidden: string[];
  slices: string[];
  risk: 'low' | 'medium' | 'high';
  reviewedBy?: string;
  corpusRevision?: string;
};

来源字段防止合成案例被误当成真实分布；reviewedBy 表示领域事实由谁确认；corpusRevision 对 RAG 尤其重要。案例正文若来自用户日志，必须先获得允许、删除身份信息并限制访问。不要为了评测方便永久保存生产原文。

数据集至少有三层：快速 smoke set 在每次提交运行；冻结 regression set 保护已知行为；挑战集覆盖长尾、对抗和高风险路径。线上新失败不是直接追加一句问答，而要还原上下文、标注期望和失败层，经审核后成为不可变案例。

随机抽样不能代表所有风险。按语言、输入长度、主题、工具、可回答性、权限、设备、失败类型和用户群体建立 slices。每次报告切片样本量与变化，避免常见样本的进步淹没关键少数的回退。

OpenAI 的Datasets 指南强调数据集应持续扩展，并说明专家注释对特定领域行为最有价值。dashboard 可以帮助探索，但数据定义、版本和导出必须由项目自己管理，不能只存在某个外部界面。

2. 选择最窄、最确定的 grader

优先顺序是：程序不变量、结构/规则、参考对比、模型 grader、人工评审。能用 JSON Schema 判断就不要让另一个模型猜；能检查工具白名单和参数就不要只读最终文案；能验证引用原文就不要评“看起来可信”。

确定性 grader 包括 exact match、正则、Schema、集合包含、数值容差、权限和状态机断言。语义任务可拆成原子 claim，再做蕴含、分类或成对比较。OpenAI 的Graders 指南列出字符串检查、文本相似、分数/标签模型和代码执行等类型；关键不是类型多，而是每个 grader 对应一条明确规格。

模型 grader 的 rubric 要写可观察证据，避免“综合质量 1–10”。例如引用正确性逐 claim 返回 supported / contradicted / insufficient，并要求指出 source span；工具规划判断允许路径、冗余步骤和越权调用。评分输出结构化，温度和 grader 版本固定，原始判断保留用于抽查。

自动 grader 必须和人工校准。抽一组覆盖各切片的案例由两名合格审核者独立标注，先看人际一致性，再看 grader 与共识的混淆矩阵。若人都无法一致，先改规格；若 grader 在否定、跨语言或长文本上偏差，按切片补规则或保留人工门禁。不要把模型 judge 称为客观真值。

3. 运行器负责公平比较

基线与候选必须使用同一案例、相同可控外部依赖和等价预算。工具调用用快照、mock 或隔离测试环境；RAG 绑定同一 corpus revision；时间、随机 ID 和网络结果固定。否则“模型升级”可能只是搜索结果或数据变化。

每次 run 保存：system version、dataset version、case ID、随机/采样参数、请求与 trace ID、输出状态、用量、各 grader 结果和错误。对非确定输出按风险进行多次采样，报告通过率或分布，而不是挑最好的一次。具体重复次数和阈值由成本、方差与风险决定，不能从别人的 benchmark 照抄。

差异报告至少分四类：候选修复了基线失败；候选新引入失败；两者都失败但类型变化；两者都通过但成本或路径恶化。逐案例 diff 比一个平均分更可行动。高风险不变量按“任何一次失败即阻断”，开放式质量可以设置统计门禁，但要同时报告切片。

缓存不能污染公平性。可以缓存确定性的检索快照与工具 fixture，却要记录命中；模型 prompt cache 只优化计算，不改变逻辑，但基线和候选仍应分别记录延迟分布，避免不同缓存热度被误读成模型差异。

用配对比较减少噪声

基线和候选对同一个 case 运行，比较的是成对差异，不是两组无关平均值。对确定性 grader，直接列出 pass→fail 和 fail→pass；对连续分数，保存每个 case 的 delta，并报告中位数、分位和切片分布。若输出有采样波动，在相同条件下重复两边，预先写清聚合方式，不能运行后选择最有利统计量。

样本量很小时，不要用“提升 3%”制造确定感。给出实际计数和不确定区间，列出发生变化的 case。高风险行为适合硬门禁，不依赖总体显著性；低风险开放式指标可以作为方向信号，再由人工确认。统计方法服务决策，不替代风险判断。

建立 AI 测试金字塔

底层是普通软件测试：Schema、权限、状态迁移、幂等、解析器、缓存键和回退。它们便宜、稳定，应覆盖最多。中层是组件 eval：分类、抽取、query rewrite、retrieval、工具选择、引用与单 Agent step。顶层才是昂贵的端到端多轮任务、对抗测试和人工评审。

若所有质量都靠端到端模型 grader，失败既慢又难定位；若只测组件，组合后的权限和上下文问题又会漏掉。每个线上事故先补最靠近根因的低层测试，再保留一个端到端案例证明用户路径恢复。

工具与 RAG 使用 fixture 之外，还要定期做隔离环境契约测试，验证真实 API Schema、错误码、索引构建和权限。Fixture 保护回归，契约测试发现依赖漂移；两者不能互相替代。

4. 输出评测与 trace 评测分工

黑盒输出回答“用户最终得到什么”，trace 回答“系统为何得到它”。Agent 可能给出正确答案，却调用了不必要工具、重复读取私人数据或绕过审批；也可能最终失败，但前几步路由正确。OpenAI 的Trace grading将决策、工具调用和运行轨迹赋予结构化标签，用于定位编排回归。

trace grader 可以检查：选了哪个 Agent；工具及参数顺序；审批是否先于副作用；相同调用是否重复；检索证据是否被使用；退出原因；总轮次与预算。不要评分隐藏的 chain-of-thought；使用系统实际暴露的 item、工具、handoff、guardrail 和状态迁移。

输出与 trace 门禁需要同时满足。一个客服答案语气正确但读取了错误租户，应判失败；一次安全拒绝路径很正确但给用户空白页，也应判失败。分层得分让修复落到模型、prompt、工具、检索还是产品体验。

故障注入让 trace 评测更接近生产：在模型请求、流式中断、工具提交前后、审批恢复、检索超时和状态持久化处分别失败。断言任务进入正确终态、写操作不重复、用户能恢复且日志没有泄露。只用成功依赖跑 eval，会把恢复逻辑留到真实事故才首次执行。

5. 从离线回归到上线证据

持续回归可以按四个频率运行：提交时执行小型确定性集；合并前执行完整冻结集；候选版本执行多次抽样和人工抽查；上线后对获许可、脱敏的流量做影子或抽样评估。线上监控关注分布漂移、拒绝率、工具错误、成本和用户恢复，不把生产用户自动变成训练数据。

发布门禁写成配置而不是口头判断：零越权、零未审批副作用、结构成功率、关键切片不得低于基线、开放式质量差异区间、成本和延迟上限。本文不提供通用数字，因为正确阈值取决于任务风险、样本量和现有基线；门禁文件应记录每个阈值的业务理由和负责人。

部署采用可回滚的 system version 和稳定分桶。先小比例观察真实 trace；触发硬门禁立即回滚整个配置组合，而不只换模型名。回滚后把事件变成新案例，记录根因与修复证据。

线上指标与离线 eval 需要映射。用户重试、人工接管、工具撤销、引用展开和任务放弃能提供产品信号，却不能直接解释为模型对错；将它们用于发现需要标注的样本，再由领域审核形成 ground truth。不要让点击率成为唯一优化目标，否则模型可能靠更自信、更冗长的回答提高互动，同时降低事实质量。

数据漂移监控关注输入切片比例和未知类别，而不仅是分数下降。新产品版本、语言或文件类型大量出现时，离线集可能已经失真；先补代表性案例并重新审查门禁，而不是只调 grader 阈值让 dashboard 变绿。

6. 处理 2026 年 Evals 平台变更

截至本文核验日 2026-07-16，OpenAI 文档已宣布现有 Evals 平台将在 2026-10-31 变为只读，并计划于 2026-11-30 关闭，时间表见官方 Deprecations。因此新系统不应把“持续回归”绑定到即将关闭的平台对象。

保留平台无关的 dataset JSONL/Parquet、runner 接口、grader 定义、原始结果和差异报告；外部平台只是一个执行适配器。若现有项目仍使用该平台，立即导出数据、grader 配置、run 结果和版本映射，并验证本地或替代执行器能复现关键门禁。不要因为产品弃用而丢掉评测方法，也不要在文章中继续推荐一条已知将关闭的长期路径。

7. 一次变更的标准闭环

  1. 写变更假设：它应改善哪个切片，可能伤害什么。
  2. 固定候选 system version 和数据集版本。
  3. 先跑 smoke，阻止格式、权限和工具契约错误。
  4. 跑完整回归并生成逐案例、逐切片 diff。
  5. 对新失败与高风险样本人工复核；校准 grader 分歧。
  6. trace 归因到模型、检索、工具、编排或界面。
  7. 达到门禁后小流量发布；否则修复或放弃假设。
  8. 将真实失败变成经审核的新案例，再冻结数据集版本。

闭环不允许“调 prompt 直到测试集全部通过”而没有 holdout。反复针对同一集优化会过拟合 grader；保留未参与迭代的挑战集，并周期性更新真实分布。

评测资产要有负责人。领域 owner 批准 ground truth，安全 owner 维护硬边界，工程 owner 维护 runner 与 fixture，产品 owner 决定发布取舍。任何人修改 grader、删除失败案例或调整门禁都走代码评审并说明原因。否则团队会在压力下不断降低阈值，最终只剩下形式上的“持续评测”。

定期做反向审计：随机抽取自动通过案例，看 grader 是否漏掉新型错误；随机抽取自动失败案例，看规则是否误杀；检查切片是否还有样本、数据来源是否过期、人工审核是否积压。一个从不被质疑的 grader 会随产品演进变成旧规格的守门人。

失败模式与取舍

常见错误包括：只评最终自然语言；数据集没有版本和来源；把合成数据当生产分布；模型 judge 无人工校准；多个配置同时变化无法归因；只报平均分；重试直到通过；工具使用真实生产环境；把用户日志默认纳入评测；门禁依赖将弃用的平台且无法导出。

高质量 eval 需要领域标注、运行成本和维护。最小可行方案不是省略证据，而是聚焦最高风险行为：先建立几十个经过专家确认的典型、边界和对抗案例，使用确定性 grader 保护硬边界，再逐步扩展语义和 trace 评测。小而可信优于大而含糊。

结论

AI Evals 是变化管理系统。行为规格定义什么值得保护，版本化数据集保存真实分布与失败，分层 grader 把确定性规则、语义判断和人工校准组合起来，trace 解释控制流，发布门禁把证据连接到部署和回滚。

当团队能在每次模型、prompt、工具或检索变化前写出假设，运行同一基线，列出新增回归并把线上失败沉淀为案例，AI 功能才拥有和普通软件同等级别的持续工程纪律。

Sources