一项评测得到的分数，并不只属于模型——它属于 模型 + agent harness + 工具与环境 + 预算 + 任务集 + grader + 运行协议 的完整组合。改变其中任何一项，分数都会变化。这不是 agent 出现以后才成立的道理；但 agent 任务把这个事实从"可忽略的实现细节"变成了"一阶变量"。

本文综合了两份关键资料：OpenAI 发布的第三方评测 playbook（侧重"如何做出可信的能力声明"）和 Anthropic 的 agent eval 工程指南（侧重 task / trial / grader / transcript / outcome 的实操分类体系）。两份文档指向同一个工程事实：评测结果应当绑定到一个有版本号的被测系统，而不仅仅是一个模型名字。在此基础上，本文还补充了两块内容：LLM-as-Judge 的实操落地指南，以及一个知识增强型开发工作流的评测案例。

本文结构：先建立术语共识（§词汇表），再拆解评测体系的三个层次（§全景），然后分别梳理 OpenAI 和 Anthropic 的方法论，合并为共识（§共识），深入 LLM-as-Judge 的实操细节（§实操），最后通过一个 SDD 知识循环的实战案例（§案例）把理论落地。

信息时效声明：本文引用的 OpenAI 与 Anthropic 文档截至 2026 年 7 月验证有效。评测领域迭代极快，读者在引用具体数字或工具版本时，请以原文最新版本为准。

核心术语词汇表

本文涉及大量评测领域术语。下表集中定义，后文首次使用时以粗体标记。

英文术语 中文释义 在本文中的含义
Rubric 评分标准 / 评分准则 一份结构化的评分指南，定义每个评分维度上不同质量等级的具体标准。类似教育中的"评分量表"。例：correctness: 5=完全正确且有依据, 3=部分正确但有遗漏, 1=事实错误
Evaluation / Eval 评测 一次评测活动或评测体系的总称，包含任务集、被测系统和评测基础设施
Benchmark 基准测试 标准化的任务集 + 运行协议 + 指标，用于系统间可复现比较。如 MMLU、HumanEval、SWE-bench
Evaluation Suite / Task Set 评测套件 / 任务集 一组用于评测的任务。没有固定比较协议时用此称呼，不应称为 benchmark
Agent Harness / Scaffold Agent 脚手架 / 被测侧系统 把裸模型变成 Agent 的全部工程：工具循环、上下文管理、记忆、重试策略和 token 预算
Evaluation Harness 评测基础设施 负责执行评测的系统：调度、环境隔离、日志记录、评分和结果聚合
Elicitation 能力激发 通过优化 prompt、工具、scaffold 等手段，尽量充分地发挥模型在特定任务上的能力上限
Grader 评分器 检查 trial 某个维度的评分逻辑。可以是确定性规则（单元测试）、模型（LLM judge）或人类评审
Ground Truth 基准真值 已知正确的参考答案或预期状态，是确定性 grader 的评判依据
Contamination 数据污染 评测数据泄露到模型训练数据中，导致分数不反映真实能力而只反映记忆
Reward Hacking 奖励劫持 被测系统找到满足评分器字面标准但不满足真实意图的捷径
Pass@k k 次至少成功一次 k 次独立 trial 中至少有一次成功。衡量"给多次机会能否做到"
Pass^k k 次全部成功 k 次独立 trial 全部成功。衡量"连续执行是否可靠"。若单次成功率 75%，pass^3 = 0.75³ ≈ 42%
Transcript 交互记录 可审计的完整交互过程，包含消息、工具调用、环境观察和输出
Outcome 最终结果 trial 结束后环境中的实际状态——区别于 agent 口头声称的结果
Trial 试次 一个 task 的一次独立执行。同一 task 重复运行产生多个 trial
Inter-rater Reliability 评分者间一致性 不同评分者（人类之间、人类与模型之间）对同一样本给出一致评分的程度
NLI 自然语言推理 Natural Language Inference，判断前提是否蕴含/矛盾/无关假设。在评测中用于检查回答是否被上下文支持

本文后续首次使用这些术语时会加粗标记。如需快速查阅，可随时回到本节。

全景：一次 Eval 的三个层次

所谓"模型评测"和"系统评测"，差别主要在被测系统是否把 harness、工具和环境纳入控制范围。两者都属于 eval，不是两种互斥的方法。

graph TB
    subgraph "一次完整评测 Evaluation"
        direction TB
        subgraph TS["任务集 Task Set / Suite"]
            T1["固定任务 + 成功标准"]
            T2["公开 benchmark 或内部回归集"]
        end
        subgraph SYS["被测系统 Tested System"]
            M["模型 Model"]
            AH["Agent Harness"]
            P["Prompt"]
            Tools["工具集"]
            Env["环境"]
            Budget["预算 & 重试策略"]
        end
        subgraph EH["评测基础设施 Evaluation Harness"]
            Run["调度 & 隔离"]
            Record["记录 Transcript"]
            Grade["评分 Grader"]
            Agg["聚合 & 统计"]
        end
    end
    TS --> SYS
    SYS --> EH
    Run --> Record --> Grade --> Agg

    style TS fill:#e1f5fe
    style SYS fill:#fff3e0
    style EH fill:#e8f5e9

从外到内拆开来看，一次 eval 可以分成三个层次：

层次 回答的问题 典型内容
Task set / suite 用哪些任务测量 题目、输入、环境、成功标准、数据切分
Tested system 谁在完成任务 模型、agent harness、prompt、工具、记忆、重试与预算
Evaluation harness 如何执行和判分 调度、隔离环境、日志、grader、聚合与统计

这三层的边界决定了评测分数的归属。对于传统的单轮 QA 评测，变量相对有限：

1
score = f(model, prompt, decoding, answer_extraction, dataset, grader)

一旦进入 agent 场景，公式膨胀为：

1
score = f(model, agent_harness, tools, environment, context_policy, budget, retries, task_set, graders, aggregation)

变量从 6 个跳到 10 个以上。每个变量的改变都可能导致分数显著波动——同一个模型换一套 scaffold，SWE-bench 上的分数可以差出 20 个百分点。这就是为什么 agent 评测必须把被测系统作为一个整体来版本化和报告。

关于"harness"一词的歧义。Anthropic 明确区分了被测侧的 agent harness / scaffold（把模型变成 agent 的工程）和评测侧的 evaluation harness（执行评测的基础设施）。OpenAI 在 playbook 中使用"harness"时更偏向后者——围绕被测系统的运行环境。两家的术语并不冲突，只是切分粒度不同。在阅读第三方评测报告时，需要注意作者的"harness"到底指哪一侧。

为进一步消除歧义，下表整理了本文中几个容易混淆的术语的指向：

术语 指向 本文中的用法
evaluation / eval 一次评测活动或评测体系 task、trial、grader、结果和统计
evaluation suite / task set 一组用于评测的任务 可以是公开任务集，也可以是内部回归集
benchmark 用于可复现比较的标准化任务、协议和指标 MMLU、HumanEval、SWE-bench
agent harness / scaffold 把模型变成 Agent 的被测侧系统 工具循环、上下文管理、记忆、重试和预算
evaluation harness 执行评测的基础设施 调度、隔离、日志、grader、聚合和统计

一个常见的误用是把内部任务集称为"benchmark"。严格来讲，benchmark 需要具备标准化的运行协议和公开的比较基准，否则只是 evaluation suite / task set。混用这两个词会给读者造成可复现性的错误预期。

OpenAI：先说明分数要支持什么声明

OpenAI 在 “A shared playbook for trustworthy third-party evaluations” 中提出的核心主张不是"怎么跑评测"，而是"评测分数要支持哪一类声明"。声明类型不同，评测设计的约束条件就不同。

三种声明需要不同设置

flowchart LR
    Q["你的评测要回答什么问题？"]
    Q --> C["横向比较<br/>谁更好？"]
    Q --> E["能力激发<br/>能做到什么？"]
    Q --> S["安全防护<br/>防线是否有效？"]
    C --> C1["标准化 harness<br/>相同预算<br/>配对任务"]
    E --> E1["强工具支持<br/>足够预算<br/>迭代优化"]
    S --> S1["明确威胁模型<br/>攻击 harness<br/>匹配威胁能力"]

    style C fill:#bbdefb
    style E fill:#c8e6c9
    style S fill:#ffcdd2
目的 要回答的问题 设计重点
横向比较 两个系统在同等条件下谁更好 标准化 harness、相同预算、配对任务
能力激发 一个系统在充分支持下能做到什么 较强工具、足够预算、合理 scaffold、迭代优化
安全防护 防线能否抵挡特定能力的攻击者 明确威胁模型，并让攻击 harness 匹配该威胁

这里有一个容易被忽略的张力：标准化和最大化激发是两个不同的目标。统一设置能让横向比较公平，但可能低估某个系统的上限。能力激发评测允许为每个系统做针对性优化，但得到的分数不能直接拿来做横向排名。安全评测则需要站在攻击者视角——攻击 harness 的能力应当匹配你所担心的威胁等级，否则"通过测试"只意味着"通过了一个弱攻击者的测试"。

选错声明类型不会让评测结果"不精确"，而是让它回答了一个你没有问的问题。

一份可复核报告至少披露六项信息

OpenAI 给出的清单直截了当。一份第三方评测报告要做到可复核，至少需要披露：

  1. 要支持的声明——这份评测要回答什么问题，属于上述三种目的中的哪一种。
  2. 评测覆盖了什么内容——任务集合的范围、来源和选择标准。
  3. Tested system 的完整描述——不是模型名，而是模型加上 scaffold、工具、系统提示词和任何中间件的完整配置。
  4. Token、turn、retry、wall-clock 等预算——资源约束决定了分数的天花板。
  5. Prompt、scaffold、工具和调参等 elicitation 方法——同一模型在不同 elicitation 下表现可以差距悬殊。
  6. 对 grader、污染、拒答、reward hacking、评测感知等有效性风险做过哪些检查——没有做过的检查本身就是应当披露的信息。

这六项中，前三项定义"测的是什么"，后三项定义"测得是否可信"。缺少任何一项，读者都无法独立判断分数的含义。

三个案例说明 Harness 何时成为一阶变量

OpenAI 在 playbook 中给出了三个案例，说明 harness 层面的变化如何直接影响评测结论：

  • Context compaction 的影响：GPT-5.5 在 cyber range 任务上，使用 context compaction 的设置优于不使用 compaction 的设置。同一个模型，scaffold 层面的一个功能开关就改变了成绩排序。

  • Token 预算的影响：UK AISI 将某项评测的 token 预算从 1000 万提高到 1 亿，观察到最高 59% 的性能提升。这是十倍 token 预算带来的变化。预算不是"够用就行"的后勤参数，它直接塑造了分数的上界。

  • Reward hacking 的影响：METR 对 GPT-5.4 的长任务能力做初步估计时得到约 13 小时；修正 reward hacking 后降到约 6 小时。变化的不是模型，而是对评测有效性的判断。一个未被发现的 reward hacking 路径可以让能力估计膨胀一倍。

需要注意的是：这三个案例都来自长轨迹、高资源消耗的任务场景。它们说明了 harness 变量在这类任务上的影响量级，但不足以推出"换 harness 普遍会相差 30%"之类的跨任务常数。在短轨迹、低歧义的任务上，harness 变化的影响可能小得多。案例的价值在于建立警觉，而不是提供可外推的系数。

Codex 作为 common floor

OpenAI 建议能力评测者在评测 OpenAI 模型时把 Codex 作为 common floor——即一个可以作为起点的、OpenAI 提供的标准化 agent scaffold。这个建议的适用范围是有限的：它针对的是评测 OpenAI 模型的场景，目的是让不同评测者之间有一个可比较的基线。它不是"所有评测都必须使用 Codex"，也不排斥评测者在 common floor 之上叠加自己的 scaffold 来做能力激发。

不要混淆 OpenAI 的三个同名项目

OpenAI 生态中有三个容易混淆的评测相关项目，它们的状态各不相同：

  • openai/simple-evals：GitHub 仓库。README 说明仓库自 2025 年 7 月起不再为新模型更新。
  • OpenAI hosted Evals platform：线上托管平台。现有 eval 将在 2026 年 10 月 31 日变为只读，11 月 30 日关闭。官方迁移说明链接到 Promptfoo。
  • openai/evals：另一个 GitHub 仓库。hosted platform 的退役不代表此仓库停止维护。

在引用 OpenAI 评测相关内容时，需要区分你引用的到底是哪一个。

Anthropic：把 Agent Eval 拆成可操作对象

如果说 OpenAI 的 playbook 回答的是"评测报告应该怎么写"，Anthropic 的 “Demystifying evals for AI agents” 回答的则是"评测系统应该怎么建"。这是一份面向工程团队的实操指南，把 agent 评测拆解成了一组有明确定义的对象和操作。

术语表：先对齐词汇

术语 含义
Task 一项测试，包含输入、环境和成功标准
Trial 一个 task 的一次执行
Grader 检查 trial 某个维度的评分逻辑
Transcript 可审计的交互记录
Outcome trial 结束后环境中的实际结果
Evaluation harness 评测基础设施——负责调度 task、收集 transcript、运行 grader
Agent harness / scaffold 被测侧系统——模型加上工具、提示词和编排逻辑的完整组合

这套术语中最关键的区分是 transcript 与 outcome。Transcript 记录的是 agent 说了什么、调用了什么工具、中间推理了什么；outcome 记录的是 trial 结束后环境中实际发生了什么。Agent 声称"已经订票"不代表数据库里真的出现了订单。一个只看 transcript 的 grader 会被 agent 的自信措辞误导，一个只看 outcome 的 grader 可能会漏掉过程中的安全违规。两者需要分别评估，不能互相替代。

Grader 没有单一最佳实现

flowchart TD
    Start["需要评分某个维度"]
    Start --> Q1{"能写成确定性规则？<br/>（单元测试/文件状态/SQL 查询）"}
    Q1 -->|是| Det["确定性 Grader<br/>✅ 稳定、便宜、可复现<br/>⚠️ 规则写错会稳定给错分"]
    Q1 -->|否| Q2{"维度是否主观？<br/>（相关性/风格/完整性）"}
    Q2 -->|是| Mod["模型 Grader (LLM Judge)<br/>✅ 可处理开放式质量<br/>⚠️ 偏差、漂移、成本"]
    Q2 -->|高歧义/高风险| Hum["人类 Grader<br/>✅ 领域判断<br/>⚠️ 慢、贵、标注者间不一致"]
    
    Det --> Note["工程顺序：先确定性 → 再模型 → 最后人类"]
    Mod --> Note
    Hum --> Note

    style Det fill:#c8e6c9
    style Mod fill:#fff9c4
    style Hum fill:#ffcdd2
类型 适合什么 主要风险
确定性 grader 单元测试、文件状态、数据库记录 规格或断言写错时会稳定地给错分
模型 grader 相关性、风格、完整性 偏差、漂移、提示词敏感和成本
人类 grader 高歧义、高风险 慢、贵、标注者间不一致

工程上的优先级顺序是：能用确定性规则覆盖的维度先用确定性 grader，剩下的考虑模型 grader，最后才引入人类 grader。这不是因为确定性 grader"更好"，而是因为它的失败模式最容易发现和修复——一个写错的断言至少会稳定地给错分，而不是时对时错。

对于模型 grader，Anthropic 给出的具体建议是：一次只判断一个清楚定义的维度，并保留 Unknown 出口。让 LLM judge 同时判断多个维度会导致维度间互相干扰；没有 Unknown 出口会迫使模型在无法判断时猜一个答案，而猜测的方向往往是系统性的偏差。

Pass@k 和 Pass^k 回答不同问题

Agent 的非确定性意味着同一个 task 跑多次可能得到不同结果。Anthropic 区分了两个聚合指标：

  • pass@k：k 次 trial 中至少成功一次的概率。它回答的问题是"这个 agent 有没有能力完成这个任务"。
  • pass^k：k 次 trial 全部成功的概率。它回答的问题是"这个 agent 能否可靠地完成这个任务"。

两者的差距随 k 增大而急剧扩大。假设单次成功率为 75%，pass@3 = 1 - (1-0.75)^3 ≈ 98.4%，看起来很好；但 pass^3 = 0.75^3 ≈ 42.2%，意味着不到一半的情况下三次都能成功。

选择哪个指标取决于你的使用场景。如果用户可以重试且成本很低，pass@k 更相关；如果系统需要无人值守地稳定运行，pass^k 才是你需要关注的数字。报告中只写 pass@k 而不提 pass^k，会让一个可靠性不足的系统看起来能力很强。

Transcript 审计不是附加步骤

Anthropic 引用了 CORE-Bench 的案例来说明 transcript 审计的必要性：Claude Opus 4.5 在该基准上的成绩从 42% 变为 95%。这个巨大的变化不是某一个因素造成的，而是评分问题、任务规格歧义、随机性和 scaffold 约束共同作用的结果。

这个案例的意义不在于具体数字，而在于它揭示的模式：当你看到一个异常的分数——无论是异常高还是异常低——第一反应不应该是"这个模型真厉害/真差"，而应该是"评测链路的哪个环节可能出了问题"。Transcript 提供了回答这个问题所需要的证据。没有 transcript，你只能看到一个数字；有了 transcript，你可以追溯到这个数字是怎么产生的。

任务定义先于框架选型

Anthropic 建议的工作顺序是：

  1. 收集 20-50 个真实失败案例作为起点
  2. 为每个案例编写参考解法
  3. 定义可验证的 outcome（不是"回答是否合理"，而是"数据库中是否出现了正确的记录"）
  4. 构建平衡的任务集——覆盖不同难度、不同失败模式
  5. 在隔离环境中运行——每个 trial 独立，不共享状态
  6. 校准 grader——用已知结果验证 grader 的准确性
  7. 建立基线——在改动之前先记录当前表现
  8. 阅读 transcript——不只是看分数，而是理解 agent 的行为模式
  9. 将 capability eval 转化为 regression eval——一旦某项能力通过验证，将其纳入回归测试

这个顺序的关键在于：任务定义（步骤 1-4）发生在框架选型和基础设施搭建之前。先选框架再找任务，容易被框架的内置假设限制任务的多样性。先从真实失败出发，任务集合会更贴近你实际需要解决的问题。

两家的共识与边界

OpenAI 和 Anthropic 的文档面向不同的读者——前者面向第三方评测机构和政策制定者，后者面向产品工程团队。但把两份文档放在一起看，可以找到交叉验证的共识，也可以看到各自侧重点的边界。

维度 OpenAI 侧重点 Anthropic 侧重点 可以共同推出的结论
评测对象 tested system 与 surrounding setup model + agent harness 报告不能只写模型名
资源 token、turn、retry、时间与工具支持 多 trial、隔离执行与 agent scaffold 预算和执行协议需要版本化
评分有效性 reward hacking、污染、拒答、broken eval、评测感知 outcome、grader 校准、Unknown、transcript 审计 分数异常时先审计评测链路
使用场景 第三方能力声明和安全声明 产品研发中的 capability / regression eval 对外声明和内部回归不是同一种契约

可以推出的结论

从两份文档的交集中，可以合理推出以下结论：

  1. "模型名 + 分数"不构成完整信息。 两家都要求报告 tested system 的完整配置。一个分数如果不附带 harness、预算和 elicitation 方法的描述，就不具备可解释性。

  2. 分数异常时，评测链路是第一嫌疑人。 OpenAI 列举了 reward hacking、污染、评测感知等有效性风险；Anthropic 通过 CORE-Bench 案例展示了评分问题和任务规格歧义的影响。两者指向同一个工程实践：看到意外分数时，先检查评测本身，再下关于模型能力的结论。

  3. 预算和执行协议需要版本化。 Token 预算从 1000 万到 1 亿可以带来最高 59% 的性能变化；scaffold 的一个功能开关可以改变成绩排序。这些参数不是"跑完就丢"的运行时配置，而是影响结论的核心变量，需要像代码一样做版本管理。

  4. 对外声明和内部回归是不同的契约。 OpenAI 区分横向比较、能力激发和安全防护三种声明类型；Anthropic 区分 capability eval 和 regression eval。混用不同目的的评测设计，得到的分数在任何一个目的下都不可靠。

不能推出的结论

同样重要的是，以下结论不能从这两份文档中推出：

  1. 不能推出"存在一种通用的最佳评测方法"。 两家都强调评测设计取决于你要回答的问题。没有一种 harness 配置同时适用于横向比较和能力激发，没有一种 grader 类型同时适用于所有维度。

  2. 不能推出具体的跨任务影响系数。 OpenAI 给出的案例（59% 性能提升、13 小时降至 6 小时）来自特定的长轨迹任务场景。这些数字说明了 harness 变量可以造成的影响量级，但不能外推为"换 harness 普遍会相差 X%"。

  3. 不能推出"两家的方法论可以直接合并"。 OpenAI 的 playbook 面向第三方评测的可信度，Anthropic 的指南面向产品团队的工程实践。它们的共识是在各自的适用范围内独立成立的，强行合并成一套统一框架会丢失各自的上下文约束。

  4. 不能推出"遵循这两份文档就能做好评测"。 两份文档都是方法论层面的指导，不包含具体的任务集、grader 实现或基准数据。从方法论到可运行的评测系统之间，还有大量的工程决策需要根据具体场景做出。

LLM-as-Judge 深度实操指南

LLM-as-Judge 适合处理无法完整写成规则的质量维度——相关性、风格、完整性、开放式回答质量。问题不在于"能不能用"，而在于是否有证据表明它在当前任务、rubric 和候选分布上足够可靠。

本节将从"什么是 rubric"讲起，逐步展开到完整的实操流程。

什么是 Rubric，为什么它是 LLM Judge 的核心

Rubric（评分标准/评分准则）是一份结构化的评分指南，为每个评分维度定义不同质量等级的具体标准。这个概念来自教育评估——教师用 rubric 告诉学生"优秀的论文长什么样，合格的论文长什么样"。

在 LLM 评测中，rubric 的作用完全相同：它告诉 judge 模型"5 分意味着什么，3 分意味着什么，1 分意味着什么"。没有 rubric 的 LLM judge 只能靠"整体印象"打分——这种打分不稳定、不可审计、不可复现。

一个好的 rubric 包含三个要素：

  1. 清晰的维度名：一次只评一个维度（如"事实正确性"），不要把正确性、风格、安全混在一起
  2. 具体的等级锚点：每个分数等级都有可操作的描述，最好附带示例
  3. 显式的边界条件：无法判断时输出 Unknown，而不是强行猜测

下面是一个用于代码评审质量评测的 rubric 示例：

1
2
3
4
5
6
7
8
9
维度：代码评审完整性（Code Review Completeness）

| 分数 | 等级 | 标准                                                       |
|------|------|------------------------------------------------------------|
| 5    | 优秀 | 覆盖正确性、边界条件、安全风险、性能影响和可维护性；指出具体代码行 |
| 4    | 良好 | 覆盖正确性和至少两个其他维度；有具体建议                       |
| 3    | 合格 | 覆盖正确性；提到但未深入分析其他维度                           |
| 2    | 不足 | 仅表面评论（"看起来不错"）；遗漏明显问题                       |
| 1    | 无效 | 未实际审阅代码；或评论与变更无关                               |

[PATTERN] Rubric 设计的核心原则：一次一个维度、每级有锚点、预留 Unknown 出口。Rubric 越具体，judge 的评分越稳定，校准越容易。

什么时候该用 LLM Judge

flowchart TD
    Start["需要评分某个维度"]
    Start --> Q1{"能写成确定性规则？"}
    Q1 -->|"是：测试通过/文件存在/SQL 匹配"| Det["用确定性 Grader"]
    Q1 -->|"否"| Q2{"维度是否需要<br/>语义理解？"}
    Q2 -->|"是：相关性/风格/完整性"| LLM["用 LLM Judge + Rubric"]
    Q2 -->|"高歧义 + 高风险"| Hum["用人类 Grader"]
    LLM --> Cal{"已在人类标注集<br/>上校准？"}
    Cal -->|"否"| CalDo["先校准再上线"]
    Cal -->|"是"| Auto["自动评分 + 定期抽查"]

    style Det fill:#c8e6c9
    style LLM fill:#fff9c4
    style Hum fill:#ffcdd2

判断规则很简单：能用规则的用规则，规则覆盖不了的才用 LLM judge，LLM judge 上线前必须校准。

逐点评分 vs 配对比较

LLM-as-Judge 有两种主要范式。选错范式比选错模型影响更大。

逐点评分（Pointwise Grading）

Judge 对单个回答独立评分。适合需要绝对质量分数或候选数量多的场景。

实际 prompt 模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[System]
你是一个公正的评审员。请根据下方的评分标准（rubric），
对给定回答的 {dimension} 进行评分。

评分标准：
{rubric}

注意事项：
- 严格按照 rubric 中的具体标准评分，不要凭印象
- 如果证据不足以判断，输出 "Unknown" 而非猜测
- 先给出分析（2-3 句话），再给出最终分数

[User]
用户问题：{question}
待评回答：{response}

请评分（1-5）：

配对比较（Pairwise Comparison）

Judge 比较两个回答的相对优劣。适合需要排序而非绝对分数的场景。

实际 prompt 模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[System]
你是一个公正的评审员。请比较以下两个回答在 {dimension} 
维度上的表现。

评分标准：
{rubric}

注意事项：
- 回答的呈现顺序是随机的，不要因为顺序产生偏好
- 如果两个回答质量相当，判定为平局
- 先逐一分析每个回答的优劣（各 2-3 句），再给出判定

[User]
用户问题：{question}

【回答 A】
{response_a}

【回答 B】
{response_b}

请判定（A 胜 / B 胜 / 平局）：

两种范式的对比：

方面 逐点评分 (Pointwise) 配对比较 (Pairwise)
适用场景 需要绝对分数；候选多 需要相对排序；候选少
评分稳定性 中等；受锚定效应影响 较高；同维度内比较更一致
成本 O(n)，每个候选一次调用 O(n²)，每对候选一次调用
常见偏差 分数膨胀（倾向给高分） 位置偏差（偏好先出现的回答）
缓解方法 校准集 + rubric 锚定 随机交换顺序 + 取众数

MT-Bench 论文（Zheng et al., 2023）的实验表明，GPT-4 作为 pairwise judge 时与人类专家的一致率超过 80%，接近人类评审者之间的一致率。但这个数字绑定的是 MT-Bench 的特定任务分布和 rubric，不能直接迁移到其他任务。

五种常见偏差与缓解策略

偏差类型 表现 检测方法 缓解策略
位置偏差 配对比较中偏好先（或后）出现的回答 交换顺序后检查判定是否翻转 每次评估交换顺序各做一次；不一致时标记为 Unknown
冗长偏差 偏好更长的回答，即使内容质量相同 构造仅长度不同的对照样本 rubric 中明确"简洁准确优于冗长"
自偏好 偏好由同系列模型生成的文本 Panickssery et al. (2024) 的因果实验方法 使用不同系列模型做 judge；校准集上测量偏好差异
锚定效应 分数向某个默认值聚集（如都给 4 分） 检查分数分布是否异常集中 rubric 为每个等级提供具体示例
光环效应 某维度好印象影响其他维度评分 拆开维度分别评分，检查相关性 每次 judge 调用只评一个维度

Self-preference 论文的来源与适用范围

论文 LLM Evaluators Recognize and Favor Their Own Generations（Panickssery, Bowman & Feng, 2024）发现模型可能识别并偏好由同类模型生成的文本。这提示了同源 judge 的风险，但不能推出"同一模型做裁判时一定系统性高估"的普遍定律。任务、候选生成方式、judge prompt 和模型版本都会改变偏差方向和幅度。

OpenAI 的 Prover-Verifier Games 研究提醒了另一件事：回答对不对和回答是否容易被验证，不是同一维度。用 LLM judge 评价复杂答案时，rubric 应要求可核查证据，不能只奖励"看起来像正确答案"的表达。

校准闭环：从人类标签到自动化

flowchart TD
    A["1. 从真实候选分布<br/>中抽取样本"] --> B["2. 领域专家按<br/>同一 rubric 标注"]
    B --> C["3. 隐去候选模型身份<br/>和呈现顺序"]
    C --> D["4. 运行 LLM judge<br/>分维度对比一致性"]
    D --> E{"judge-human 一致性<br/>≥ human-human × 0.9？"}
    E -->|"否"| F["5. 审阅分歧样本<br/>修改 rubric 或 prompt"]
    F --> C
    E -->|"是"| G["6. 上线自动评分"]
    G --> H["7. 定期抽查漂移"]
    H --> I{"模型/prompt/任务<br/>分布变化？"}
    I -->|"是"| A
    I -->|"否"| H

    style A fill:#e3f2fd
    style G fill:#c8e6c9
    style F fill:#fff9c4

校准闭环的每一步：

  1. 抽样：从真实候选分布中抽取样本——不是精心挑选的好例子，而是代表生产环境的分布
  2. 人类标注：由有领域能力的人类按同一 rubric 标注。至少两人独立标注，计算 inter-rater reliability（如 Cohen’s Kappa）
  3. 盲测：隐去候选模型身份、顺序和无关风格信号（如 markdown 格式差异）
  4. 分维度对比：不只看一个总相关系数，要看每个维度上 judge 与人类的混淆矩阵
  5. 修 rubric：单独审阅分歧样本和 Unknown，定位到 rubric 描述不清的位置
  6. 上线：judge-human 一致性接近 human-human 一致性时，可以上线自动评分
  7. 抽查漂移：模型升级、prompt 变化或任务分布漂移时，重新抽查

样本量不存在脱离任务风险的固定答案。低风险文案润色可以接受 30-50 个校准样本；涉及资金、权限、安全处置的 grader 需要更大的校准集和更保守的自动化边界。

完整示例：评测客服 Agent 退款处理质量

用一个端到端案例串联上面的所有概念。

场景：评测客服 agent 处理退款请求的质量。

Step 1：定义评分维度和 rubric

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
dimensions:
  - name: policy_compliance      # 政策合规
    type: deterministic           # 可用规则检查
    check: "退款金额 ≤ 政策表允许上限 AND 退款原因在允许列表中"
    
  - name: resolution_accuracy    # 解决准确性  
    type: deterministic
    check: "后端订单状态 = 预期状态（已退款/已拒绝/转人工）"
    
  - name: communication_quality  # 沟通质量
    type: model_judge
    rubric: |
      5: 语气专业友善；主动解释原因和后续步骤；无冗余信息
      4: 语气专业；解释了原因；轻微冗余但不影响理解
      3: 语气中性；基本解释了处理结果但缺少后续步骤
      2: 语气生硬或过度道歉；解释不清晰
      1: 语气不当（敷衍/指责）或完全未解释
      
  - name: information_gathering  # 信息收集效率
    type: model_judge
    rubric: |
      5: 一次性收集所有必要信息；未重复要求已知信息
      4: 高效收集；最多一次不必要的追问
      3: 收集了必要信息但过程低效（多余的确认步骤）
      2: 遗漏关键信息导致需要二次联系，或重复询问
      1: 严重遗漏导致无法处理请求

Step 2：组合评分器

1
2
3
4
5
6
7
8
9
10
11
12
评分流水线：

policy_compliance   → 确定性 grader（查退款政策表）
resolution_accuracy → 确定性 grader（检查后端订单状态）
communication_quality → LLM judge（使用 rubric + 校准后的 prompt）
information_gathering → LLM judge（使用 rubric + 校准后的 prompt）

执行顺序：
  先跑确定性 grader。
  如果 policy_compliance = FAIL，整个 trial 标记为"政策违规"，
  不需要再评主观维度——节省 judge 调用成本，也避免
  "政策违规但沟通质量很好"这种误导性高分。

Step 3：校准 LLM judge

  1. 从生产日志中抽取 50 个 trial（覆盖成功/失败/边界情况）
  2. 两名客服主管分别标注 communication_quality 和 information_gathering
  3. 计算 human-human Cohen’s Kappa（假设得到 κ = 0.72）
  4. 在同一集合上运行 LLM judge
  5. 计算 judge-human Cohen’s Kappa
  6. 若 judge-human κ ≥ 0.72 × 0.9 = 0.65，认为 judge 在此维度上可用
  7. 审阅所有分歧样本，修改 rubric 中描述不清的锚点
  8. 设置月度抽查：每月随机抽取 20 个 trial 由人类复核

Step 4：聚合与报告

1
2
3
4
5
6
7
8
9
10
报告内容：
- task 数：200（来自最近 30 天的生产退款请求）
- 每 task trial 数：3（因 agent 有随机性）
- pass^3 (全维度)：68%（连续三次全部通过的比例）
- 按维度分解：
    policy_compliance:     95% pass rate
    resolution_accuracy:   88% pass rate  
    communication_quality: 82% pass rate（≥ 3 分为通过）
    information_gathering: 76% pass rate（≥ 3 分为通过）
- 主要失败模式：信息收集效率低（反复确认订单号）

这个例子展示了一个核心模式：确定性 grader 兜底事实，LLM judge 覆盖主观维度，人类校准确保 judge 可信。每个维度都有独立的 rubric、独立的 grader、独立的校准——不把所有维度揉进一个总分。

实战案例：SDD 知识循环的评测体系设计

前面几节建立了评测方法论。本节用一个真实场景把方法论落地——评测一个知识增强型软件开发工作流（SDD 知识循环）。

问题定义：知识循环中到底要评测什么

很多团队在 SDD（Software Design Document）流程中引入了知识循环：

flowchart LR
    subgraph "知识循环 Knowledge Loop"
        KB["知识库<br/>Knowledge Base"]
        Recall["知识召回<br/>Recall"]
        SDD["SDD 设计 & 编码"]
        Reflect["反思 & 沉淀<br/>Reflection"]
        Sink["知识入库<br/>Sink"]
    end
    KB -->|"检索相关知识"| Recall
    Recall -->|"注入上下文"| SDD
    SDD -->|"需求完成后"| Reflect
    Reflect -->|"新知识"| Sink
    Sink -->|"更新"| KB

    style KB fill:#e1f5fe
    style SDD fill:#fff3e0
    style Reflect fill:#e8f5e9
  1. 知识召回：在 SDD 开头，从知识库检索与当前需求相关的设计经验、代码模式、踩坑记录
  2. 设计与编码：在召回知识的辅助下完成设计和开发
  3. 反思与沉淀：需求完成后，提炼新的经验知识
  4. 知识入库：将新知识写回远端知识库，形成闭环

大多数团队目前只能度量两个指标：

  • 有果率：知识召回是否返回了结果（非空率）
  • 召回知识量：每次 SDD 召回了多少条知识

这两个指标的问题在于——它们只衡量了输入侧。这就像评测一个 RAG 系统只看检索召回率，而不看生成的回答是否因为检索结果而变好了。有果率 = 100% 可能只意味着检索阈值设得太低，什么都召回了；召回 10 条知识可能其中 8 条完全无关。

真正需要回答的问题沿着一条因果链展开：

1
2
召回了什么？ → 用了多少？用在哪？ → 产出变好了吗？ → 新知识有价值吗？ → 系统在学习吗？
 (输入质量)     (使用深度)        (结果影响)      (反思质量)      (循环效能)

五层评测模型

把上面的因果链拆成五层，每层有独立的指标和评分方式：

graph TB
    subgraph "五层评测模型"
        L1["Layer 1: 检索质量<br/>Retrieval Quality<br/>──────────<br/>召回了什么"]
        L2["Layer 2: 使用深度<br/>Utilization Depth<br/>──────────<br/>用了多少，用在哪"]
        L3["Layer 3: 结果影响<br/>Outcome Impact<br/>──────────<br/>产出变好了吗"]
        L4["Layer 4: 反思质量<br/>Reflection Quality<br/>──────────<br/>新知识有价值吗"]
        L5["Layer 5: 循环效能<br/>Loop Effectiveness<br/>──────────<br/>系统在学习吗"]
    end
    L1 --> L2 --> L3
    L3 --> L4 --> L5
    L5 -.->|"反馈优化检索策略"| L1

    style L1 fill:#e3f2fd
    style L2 fill:#bbdefb
    style L3 fill:#fff9c4
    style L4 fill:#c8e6c9
    style L5 fill:#a5d6a7

Layer 1：检索质量（Retrieval Quality）——“召回了什么”

这一层是现有"有果率"和"召回知识量"的升级版。核心改变是从"有没有召回"转向"召回的是否相关"。

指标 定义 评测方法 Grader 类型
Context Precision 召回的知识条目中，与当前任务相关的比例 LLM judge 逐条判断相关性 模型 grader（rubric：相关/部分相关/不相关）
Context Recall 任务实际需要的知识中，被召回的比例 事后由领域专家标注"理想知识集"，计算覆盖率 人类 grader + 确定性计算
Retrieval MRR 最相关的知识排在第几位 人工标注 top-1 相关性，计算 Mean Reciprocal Rank 确定性计算

这三个指标改编自 RAGAS（Retrieval Augmented Generation Assessment）框架。RAGAS 定义了四个核心维度：faithfulness、answer relevance、context precision、context recall。在 SDD 场景中，context precision 和 context recall 可以直接复用，faithfulness 需要适配为"设计/代码是否忠实地使用了召回知识"。

Layer 2：使用深度（Utilization Depth）——“用了多少，用在哪”

这是五层中最关键也最难度量的一层。它回答的核心问题是：知识是用在了架构决策上，还是只用在了注释里？

指标 定义 评测方法 Grader 类型
Citation Rate 召回知识被实际引用或参考的比例 对设计文档/代码做 NLI 追溯，检查哪些段落可追溯到召回知识 NLI 模型 + 人工校准
Position Criticality 知识被用在了设计/代码的哪个关键层级 按位置分级加权 规则 grader（按代码结构分类）
Integration Depth 知识是被照搬还是被理解消化后融合 LLM judge 四级评分 模型 grader

Position Criticality（位置关键性） 是衡量知识价值的关键权重。同一条知识，用在不同位置的价值截然不同：

1
2
3
4
5
位置关键性权重：
  架构决策层（选型、模式、边界划分）     → 权重 4
  接口设计层（API 契约、协议、数据模型）  → 权重 3
  实现细节层（算法、工具用法、配置）      → 权重 2
  文档注释层（README、注释、说明）        → 权重 1

Integration Depth（融合深度） 衡量知识被吸收的程度：

1
2
3
4
5
融合深度评分：
  1 = 照搬：直接复制粘贴，未做任何改动
  2 = 改写：根据当前场景做了表面调整
  3 = 融合：与其他知识/经验结合，产生了新的设计决策
  4 = 创新扩展：在原有知识基础上推导出了新的模式或方案

三个指标可以组合成一个综合分数：

1
Knowledge Impact Score = Σ (citation_i × position_weight_i × integration_depth_i)

举例：一条关于"分布式事务最终一致性模式"的知识——

  • 被用在架构选型文档中（权重 4），深度融合（深度 3）→ 贡献 = 1 × 4 × 3 = 12
  • 同一条知识如果只是被复制到代码注释里（权重 1，深度 1）→ 贡献 = 1 × 1 × 1 = 1

这个分数不需要精确到个位数——它的价值在于把"知识被用了"这个模糊的判断，拆分成了可以独立度量和优化的维度。

Layer 3：结果影响（Outcome Impact）——“产出变好了吗”

指标 定义 评测方法 Grader 类型
Quality Delta 知识辅助 vs 无辅助的代码质量差异 A/B 实验或准实验：对比两组 SDD 任务 统计检验
Defect Rate 需求上线后缺陷数 统计同期 bug 数，按是否使用知识召回分组 确定性计算
Review Feedback 代码评审中的改进建议数量 统计 CR 中"需要修改"类反馈 确定性计算
Cycle Time 从需求开始到完成的周期 时间戳差值，分组对比 确定性计算

这一层面临一个根本性难题：因果推断。你不能简单地比较"用了知识召回的 SDD"和"没用的 SDD"，因为这两组任务本身可能不同——复杂的任务更可能触发知识召回，也更可能产生 bug。

推荐的方法按可信度排序：

  1. 随机对照实验（金标准但昂贵）：随机分配一部分 SDD 任务使用知识召回，另一部分不使用
  2. 配对比较：找到复杂度、技术域和开发者经验相近的任务对，一个用了知识召回一个没用
  3. 回归控制：用统计模型控制任务复杂度、开发者经验、团队规模等混淆变量

对于大多数团队，方法 2（配对比较）是最实际的起点。

Layer 4：反思质量（Reflection Quality）——“新知识有价值吗”

指标 定义 评测方法 Grader 类型
Generalizability 是否从具体案例提炼了通用模式 LLM judge 评分 模型 grader（rubric：1=仅描述具体案例 / 3=提炼了可复用规则 / 5=抽象为通用模式并给出适用边界）
Novelty 是否包含新信息 vs 重复已有知识 与知识库现有条目做语义相似度比较 embedding 相似度 + 阈值
Actionability 是否可被后续任务直接使用 跟踪该条目在未来 N 天内的被召回次数和 citation rate 确定性跟踪

Actionability 是一个延迟指标——你只有等到后续任务实际使用这条知识时才能度量。但它也是最有说服力的指标：如果一条知识被反复召回并且有高 citation rate，它就是有价值的；如果它沉入知识库后再也没被使用，那么无论它的 generalizability 评分多高，实际价值都是零。

Layer 5：循环效能（Loop Effectiveness）——“系统在学习吗”

指标 定义 评测方法
Knowledge Reuse Rate 产出的知识在后续任务中被召回和使用的比率 跟踪每条知识从 sink 到首次被 cite 的时间和频率
Loop Acceleration 随着知识积累，同类任务的完成效率是否提升 对同类型任务按时间排序，检查 cycle time 趋势
Coverage Growth 知识库对业务领域的覆盖度变化 定期评估覆盖的技术域占全部技术域的比例

Loop Acceleration 是最终的"北极星"指标。如果知识循环真的在起作用，你应该能观察到：同类型的任务随着知识积累，开发周期在缩短，或者缺陷率在下降。如果这个趋势不存在，说明知识循环的某个环节断了——可能是检索不够精准（Layer 1），可能是知识没被真正使用（Layer 2），也可能是反思产出的知识质量不高（Layer 4）。

评测契约模板

将上述五层整合到一份版本化的评测契约中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
claim:
  type: capability
  question: "知识循环是否在不增加开发成本的前提下提升了设计和编码质量？"

suite:
  id: sdd-knowledge-loop-eval
  version: 2026-09-01.1
  task_source: recent_sdd_tasks
  split: stratified_by_complexity

tested_system:
  knowledge_base_version: kb-2026-09-01
  recall_model: embedding-model-v3
  recall_top_k: 10
  sdd_agent: agent-harness-v2.1
  reflection_prompt_version: v4

protocol:
  tasks: 50
  control_group: matched_historical
  
graders:
  layer1_retrieval:
    context_precision: {type: model_judge, rubric: v2}
    context_recall: {type: expert_labeled}
  layer2_utilization:
    citation_rate: {type: nli_based}
    position_criticality: {type: rule_based}
    integration_depth: {type: model_judge, rubric: v3}
  layer3_outcome:
    quality_delta: {type: statistical_test, method: mann_whitney_u}
    defect_rate: {type: deterministic}
  layer4_reflection:
    generalizability: {type: model_judge, rubric: v1}
    novelty: {type: embedding_similarity, threshold: 0.85}
  layer5_loop:
    reuse_rate: {type: deterministic, window: 90d}
    loop_acceleration: {type: trend_test, method: mann_kendall}

validity_checks:
  - confound_analysis
  - sample_size_power_analysis
  - grader_calibration_on_layer2

从现有指标到完整体系的迁移路径

一次性搭建五层评测不现实。下面是一条渐进式迁移路径：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
阶段 1（1-2 周）：升级 Layer 1
  ├── 在"有果率"基础上增加 Context Precision
  │   （用 LLM judge 逐条判断召回知识的相关性）
  ├── 从"召回知识量"升级为"召回相关知识量"
  └── 成本：每次 SDD 增加 ~10 次 LLM 调用

阶段 2（2-4 周）：建立 Layer 2 的 Citation Rate
  ├── 在 SDD 完成后，用 NLI 检查设计文档/代码中
  │   哪些段落可追溯到召回知识
  ├── 这是从"召回了多少"到"用了多少"的关键跳跃
  └── 成本：需要开发 NLI 追溯管道

阶段 3（1-2 月）：增加 Layer 3 的对照实验
  ├── 设计准实验，配对比较使用 vs 不使用知识召回的 SDD
  ├── 统计 quality delta 和 cycle time
  └── 成本：需要数据基础设施支持分组对比

阶段 4（持续迭代）：补齐 Layer 4 和 Layer 5
  ├── 接入反思质量评分
  ├── 建立知识复用追踪
  ├── 形成自动化评测报告
  └── 定期校准所有 LLM judge

每个阶段都应该产出可度量的改进，而不是等到五层全部搭完才开始看数据。阶段 1 的 Context Precision 就能立刻告诉你"召回的知识有多少是垃圾"；阶段 2 的 Citation Rate 能告诉你"有用的知识有多少被真正使用了"。这些中间指标本身就有优化价值。

本节的核心启示：评测的层次应当匹配因果链的层次。只测输入（召回了什么）不测使用（用在哪里）和结果（产出变好了吗），就像只测 RAG 的检索召回率而不测生成质量。从 RAGAS 的四维指标到本案例的五层模型，底层逻辑相同：沿着因果链逐层设置 grader，每层用最合适的评分方式。

公开 Benchmark 的分数为什么会失效

OpenAI 在 “Why we no longer evaluate SWE-bench Verified” 中说明，已停止把 SWE-bench Verified 作为前沿 coding 能力的报告指标。审计发现一些测试会拒绝正确补丁；公开题目进入训练数据也削弱了分数的解释力。

重点不是"benchmark 已经无用"，而是公开、静态任务集很难长期同时保持有效测试和低污染。

flowchart TD
    B["公开 Benchmark 发布"] --> U["被广泛使用和引用"]
    U --> T["题目进入训练数据<br/>（Contamination）"]
    U --> O["题目/测试被发现有缺陷"]
    T --> D["分数不再反映<br/>真实能力"]
    O --> D
    D --> R["需要刷新或退役"]
    R --> N["新 Benchmark 发布"]
    N --> U

    style T fill:#ffcdd2
    style O fill:#ffcdd2
    style D fill:#fff9c4

Contamination 的边界在不同角色之间不同：

  • 模型厂商可以审计预训练、微调、后训练数据与评测集的重合，从源头控制污染。
  • 使用闭源模型的应用团队通常无法检查预训练数据，只能避免在 prompt、日志、知识库中泄露评测题。
  • 产品门禁更适合保留未公开任务、周期性刷新、记录每个任务被开发团队接触的历史，把污染风险控制在可追溯的范围内。

一套最小可落地的 Eval Contract

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
claim:
  type: comparison          # comparison | capability | safeguard | regression
  question: "候选系统是否在不增加严重错误的前提下改善订单处理？"

suite:
  id: order-agent-regression
  version: 2026-07-26.1
  split: hidden
  task_source: production_failures

tested_system:
  model: provider/model-snapshot
  agent_harness_commit: abc1234
  prompt_digest: sha256:...
  tools: [order-api@v3, search@v2]
  environment_image: sha256:...

protocol:
  trials_per_task: 3
  token_limit: 200000
  turn_limit: 80
  retry_policy: none
  context_policy: compact-at-threshold

graders:
  - id: final-order-state
    type: deterministic
  - id: response-quality
    type: model
    rubric_version: v4
    calibration_set: human-labeled-2026-07

validity_checks:
  - transcript_sample_review
  - reward_hacking_review
  - task_and_test_audit
  - eval_leakage_review

artifacts:
  retain: [task_result, transcript, grader_evidence, environment_diff]

这份契约有三个功能：让结果可复现，让失败可归因，让版本之间可比较。

claim 声明评测要回答的问题和比较类型。tested_system 固定被测系统的完整快照——模型、harness 代码、工具版本、环境镜像、预算上限。graders 列出每个评分器的类型和校准依据。validity_checks 是人工审计清单，防止评测链路本身引入错误。

从零到回归门禁的顺序

  1. 明确 claim——写下评测要回答的一句话问题和比较类型。没有 claim 就没有成功标准。
  2. 收集真实失败——从生产 case、用户反馈、线上日志中提取任务，而不是凭想象编造题目。
  3. 为每个 task 写成功标准与 reference solution——成功标准是 grader 的输入，reference solution 用于验证 grader 自身的正确性。
  4. 固定模型快照、agent harness、工具、镜像、预算——版本化所有组件，确保结果可复现。
  5. 优先实现 outcome grader——能用确定性检查回答的问题不交给 LLM 猜。
  6. 运行 baseline 与 candidate——在相同条件下对比，记录完整 artifact。
  7. 阅读 transcript，修复评测链路——检查 grader 是否正确评分、任务定义是否有歧义、环境是否稳定。
  8. grader 稳定后才接入 CI——确认评分器在人工审计下表现一致，再自动化。

第 8 步容易被提前。一个未经审计的 grader 接入 CI，只会把评分错误自动化。

不同任务需要不同主证据

任务类型 首选主证据 补充证据
Coding / 运维 agent 测试、文件或资源状态、环境 diff transcript、代码质量 rubric、成本与时延
客服 / 业务流程 agent 后端业务状态、约束是否满足 回复质量、安全和一致性 grader
RAG / 研究 agent 引用是否支持主张、来源质量、关键事实覆盖 人类审阅、检索轨迹、时效性
Computer use 页面或应用最终状态 屏幕与 action trace
安全评测 明确威胁模型、攻击是否成功 攻击预算、拒答原因

常见失效方式速查表

反模式 症状 修复方向
把模型升级当唯一变量 分数变化无法归因 版本化所有组件，分阶段实验
用回答自述替代环境结果 Agent 说"完成"但实际没完成 检查 outcome 而非 transcript
先做仪表盘后补任务定义 图表整齐但成功标准模糊 先定义 task 和 grader
Capability eval 直接当 CI 门禁 难题多导致 CI 频繁失败 Capability 和 regression 分开运行
厂商材料当对称证据 利益位置未披露 保留来源身份，用独立复核约束
Rubric 缺失的 LLM judge 评分不稳定、不可审计 先写 rubric，再写 prompt
只看平均分 长尾失败被掩盖 报告 task 数、失败类型、pass@k/pass^k

这套方法不能替代什么

基于 harness 的系统 eval 适合回答版本化系统在控制条件下的能力、可靠性和失败模式。它不能单独替代：

  • 生产监控和事故复盘——线上行为与离线评测之间始终存在分布偏移。
  • 用户反馈、可用性研究与人工质检——用户满意度和体验质量无法完全通过自动评分捕获。
  • 在线 A/B 实验——真实流量下的统计显著性检验是离线 eval 无法模拟的。
  • 安全红队和威胁建模——对抗性测试需要持续更新攻击策略，静态 eval 覆盖不了动态威胁。
  • 成本、延迟、吞吐和运维稳定性测试——这些是系统工程指标，需要在真实负载下度量。

评测体系的复杂度应由任务链路和失败代价决定，不是每个项目都需要容器隔离和多模型裁判。

结论：分数属于一份配置，而不只属于模型

一项能力分数属于 模型 + agent harness + 工具与环境 + 预算 + 任务集 + grader + 运行协议 的组合。

把上述组合中的任何一项换掉，分数就不再是同一个分数。这是系统评测与模型评测的根本区别。

回顾全文的核心方法：

  • 先写清 claim、tested system 和成功标准，再选平台——评测的价值来自问题定义的精确性，而不是工具链的复杂度。
  • 确定性 outcome 能回答的问题不交给 LLM 猜——文件状态、API 返回值、数据库记录是比任何 judge 都可靠的证据。
  • 需要 LLM judge 的维度先用人类标签校准——没有校准集的 judge 是不可审计的黑盒。
  • 随机系统既看 pass@k 也看 pass^k——前者衡量能力上界，后者衡量可靠性下界。
  • 聚合分数异常时回到 task、transcript 和 grader evidence 做归因——数字只是入口，诊断在细节里。

这套方法不会给出永远正确的排行榜。它的价值在于让每个数字都能追溯到一份契约、一次执行和一组证据。

参考资料

OpenAI

Anthropic

论文与 Benchmark

评测框架与工具