Agent Evaluation / Agent 评测

答:单轮 QA 是「输入→一次输出→与参考答案比对」,一次性、近确定性;agent 评测要测一条多步轨迹,成功判据是终态满足目标(execution-based,跑单测 / 校验环境状态),不是字符串匹配。只看 accuracy 会漏掉三件 agent 特有的事:多次跑的可靠性(pass^k)、轨迹质量(有没有 reward hacking / 蒙对)、分数随时间贬值(污染 + 饱和)。

追问： 为什么 agent benchmark 偏好 execution-based 判据而非答案匹配? → 因为 agent 的「正确」往往不是唯一字符串(改代码有多种写法、网页操作有多条路径),只能用「最终是否达成可执行的目标状态」来判;execution-based 还更难作弊(若判据隐藏)。

答:污染 = 测试样本(题目甚至官方解)进了训练语料,模型「记住」而非「解出」,分数测的是记忆。对 agent benchmark 尤其严重,因为很多任务源自公开 GitHub(SWE-bench 的 issue + 修复 PR 都是公开且会被爬的),题目和标准解天然在训练集里;加上前沿模型反复在这些榜上刷分,过拟合 + 记忆叠加。

追问： 怎么检测一个模型在某 benchmark 上被污染了? → ① n-gram 重叠扫训练语料;② 只给题面不给环境,看能否凭记忆复现官方 fix;③ 比较训练 cutoff 前后结构相同题目的分数断崖。

答:pass@k = k 次尝试至少 1 次成功(能力上界,乐观);pass^k = k 次全部成功(可靠性,见 foundations §9)。两者都不是真值而是估计量:实际用每题采 $n$ 个样本来估,$n$ 小则方差大。pass@k 有无偏估计量 $1-\binom{n-c}{k}/\binom{n}{k}$($c$ = $n$ 中成功数),比「直接数一次中没中」方差更小。

追问： 为什么报 pass@k 必须同时报 $k$、温度和 $n$? → pass@k 的取值随 $k$ 和采样分布(温度) 变化——温度改变每样本成功率与多样性;而 $n$(估计用的采样数)只决定方差 / 置信区间,并不改变 pass@k 的期望值(除非你真改了 $k$ 或在做 best-of-$n$)。所以不报 $k$ / 温度 → 数字不可比,不报 $n$ / seed → 不可复现。

答:两条线叠加。污染线:OpenAI 的诱发实验显示前沿模型在部分任务上只给题面即可凭记忆复现官方 fix → 分数反映「见过多少 benchmark」而非真实能力。饱和/缺陷线:OpenAI 审计了 o3 在 64 次运行中未能稳定解出的 138 题(占 500 的 27.6%),发现 59.4% 的题在测试 / 描述上有实质缺陷——35.5%(约 49 题)太窄(拒绝功能正确解)、18.8%(约 26 题)太宽(要求题面没提的功能),其余约 5% 描述缺陷;即部分「失败」是 benchmark 错判。结论:Verified 上的提升不再反映真实开发能力。OpenAI 改推抗污染的 SWE-bench Pro(同批模型 ~70–80%→~23–58% 量级)。

追问： 引用「SWE-bench Pro 上掉到 ~23–58%」时要注意什么? → 那是 2025–26 单一来源(Scale leaderboard)、会变的具体分数;只能用它说明「饱和/污染导致的量级落差」这个方法学现象,不能当稳定排名或固定能力值。

答:说明 benchmark 比较的是 model × harness,不是纯 model——prompt 模板、工具集、解析器、步数预算、检索策略都显著影响分数(SWE-bench 早期大量提升来自 scaffold 工程)。负责任的报法必须带:harness 版本 + 工具集 + 最大步数 + 温度 + seed + 采样数 $n$ + 日期。缺这些的单个数字不可比、不可复现。

追问： 这对「读别家技报」意味着什么? → 看到「我们达到 X%」而不交代 harness 与日期,要对可比性打折;尤其跨技报比分数前,先确认是否同一 harness、同一 benchmark 版本、是否防污染。

答:只用模型训练 cutoff 之后新发布的竞赛题来评测——既然题目在模型训练后才出现,就不可能被训练时见过,从机制上断掉污染;"living" = 持续滚动加新题、退旧题,长期保鲜。局限:① 题型偏算法竞赛,覆盖面窄于真实软件工程(不测仓库级 issue);② 需要持续运营投入;③ 不同模型 cutoff 不同,严格可比要按各自 cutoff 切窗。

追问： 时间窗防污染和「私有保留集 / 专家命题」(GDPval、SWE-bench Pro private)各自适合什么? → 时间窗适合有稳定新题流的领域(竞赛);私有 / 专家命题适合没有自然新题流、或需要贴近真实专业任务的场景,代价是命题 + 评分的人力成本。

答:按三个匹配度依次过滤——① 动作空间匹配:agent 操作粒度是什么？修代码 → SWE-bench Pro / LiveCodeBench;操作网页 → WebArena;操控 OS GUI → OSWorld;多轮工具+用户交互 → τ-bench;ML 工程 → MLE-bench;通用问答+工具调用 → GAIA。② 评判方式可靠性:能否接受 LLM-judge 的偏置？高危场景(代码部署、金融交易)优先选 execution-based + 隐藏判据的榜;低危探索场景可用 LLM-judge 做初筛。③ 维护状态:是否仍在 actively maintained / living？饱和榜(SWE-bench Verified 已退役)不可作唯一依据;living benchmark(LiveCodeBench)或刚发布且社区活跃的新榜更可信。

具体映射:

追问： 一个场景没有现成 benchmark 怎么办? → ① 判断是否能用通用榜(GAIA / τ-bench)先做初筛;② 不行就自己构建 domain-specific eval:关键是把成功判据做成可执行的(脚本/单测/终态校验),并且保持判据对 agent 不可见;③ 评估构建成本:一般需几十到上百题(取决于 baseline 成功率 + 效应量 + 期望 CI 宽度,建议做 power analysis 定题量;作为粗略经验值往往 ≥100),且需要长期维护(换题防过拟合)。

答:LLM-judge 评 agent 轨迹时有已多次在文献中复现的三类偏置风险:

1. 位置偏置(position/order bias):答案在 prompt 中出现的顺序、是否靠近 prompt 末尾显著影响 judge 评分。轨迹越长越严重——agent 多步轨迹天然比单轮 QA 长,末尾步对 judge 影响远大于开头步。
2. 自我偏置(self-preference):同模型族的 judge 倾向给同族的 agent 更高分;多个研究在 GPT/Gemini/Claude 家族上都观测到此现象,虽强度因 model/task 而异而非定值,但方向一致。
3. 风格/解释偏置:agent 轨迹中若包含自信、详细或权威风格的解释文本,LLM-judge 更倾向判它对,即使底层动作是错的——judge 被 rhetoric 而非事实影响(有时被称为 verbosity / authority / rationale bias)。

可以用 LLM-judge 的场景:

• 相对排序(A vs B 哪个轨迹更好)——比给绝对分数可靠,偏置在成对比较中部分抵消。
• 粗粒度过滤——筛掉明显坏轨迹(没调工具 / 死循环 / 空响应),规则判据做主、LLM 兜底。
• 辅助诊断——在 human review 前预标注,加速人工复核。

不能用 / 要极其谨慎的场景:

• 作为 RL 训练的 reward 来源——偏置会被策略搜索并放大,变成「讨好 judge」而非「完成任务」。
• 作为绝对 pass/fail 判据——可靠性不足以做高风险单次决策。
• 跨模型族能力排名——自我偏置会让排名系统性不可比。

追问： 有没有比 LLM-judge 更可靠、又比 execution-based 更灵活的折中? → 程序化规则 + LLM 组合:对可规则化维度(步数上限、是否调了禁用工具、动作格式是否合法)走确定性规则;对需「语义判断」的维度(这一步方向是否合理)走 LLM,但只在统计意义上用(多 judge 均值 + 方差),不在单次决策层面依赖任何一个 judge。

答:综合 §3–§5:① 抗污染——题目用训练 cutoff 之后的新题(时间窗)或私有保留集,并做污染审计(凭记忆复现测试);② 抗 reward-hacking——成功判据用隐藏的额外单测 + 环境终态校验(agent 不可见),防改测试 / 空实现过 CI;审计单测质量本身(避免太弱→假阳、太严→假阴);③ 可复现——固定 seed、公开 harness、报 $n$ 次采样的 pass@k 无偏估计 + 区间 + 版本日期;④ 可靠性——报 pass^k 而非只报 pass@1,暴露多次跑的稳定性;⑤ living——定期换题防长期过拟合。

追问： 为什么「隐藏判据」是抗 hack 的关键? → 一旦 agent 能看到判据(断言 / 单测),它会去满足判据而非真解题(改测试文件、硬编码期望输出);把判据藏在 agent 不可见处,才逼它真正达成目标状态。

答:outcome-only 盲区——漏掉「蒙对 / lucky path」与 reward hacking,且不诊断哪步错、不给 partial credit;trajectory 盲区——「谁来评每步」难,规则覆盖不全、LLM-judge 自带位置/自我偏好。execution-based verifier 的假阴/假阳:单测太弱→错解蒙过(假阳),太严→功能正确解被拒(假阴,即 SWE-bench Verified 的缺陷题)。缓解:① 审计 + 加强测试集(多样输入、隐藏额外断言);② 多判据交叉(单测 + 终态校验 + 必要时人工核验子集);③ 对高风险题保留 human-in-the-loop 复核;④ 在 RL 里对 verifier 噪声做鲁棒处理(别把单一弱信号当真值放大)。

追问： 弱 verifier 在 RL 训练里为什么比在静态评测里更危险? → 静态评测里弱 verifier 只是测不准;在 RL 里它是奖励来源,reward hacking 会被策略主动搜索并放大——agent 会朝「骗过弱测试」而非「真解题」的方向优化,越训越坏。

答:必带精确 scope。那个「多 agent 编排器执行任意恶意代码」的数字(某研究报 58–90%、个别配置 100%)是「在特定 web 注入攻击下的攻击成功率」,是控制流劫持的攻击成功率,不是「一般部署中就会按这个比例作恶」。sabotage 类同理:Anthropic 的 sabotage evaluations 是个评测框架,引用要说清是框架 / 特定设定,流传的具体百分比若不能溯源到原文设定就弃用。原则:安全数字几乎都绑定一个威胁模型 + 实验设定,脱离设定的引用即失真。

追问： 为什么安全评测的数字比能力评测的更容易被误引? → 安全数字往往是「最坏情况 / 特定攻击」下的上界,天然吸睛且易被掐头去尾;而它对威胁模型极度敏感(换攻击面结论就变),所以脱离设定单独引用几乎必然夸大。

答:标准链路是 benchmark 评测 → 奖励设计 → RL 训练 → 再评测。每一步都可能出错:

1. 同一 benchmark 既当评测又当 reward 源:如果用同一套验证器/单测既给 RL 当 reward、又当最终评测——agent 学到的是「骗过这个验证器」而非真正解题。必须 eval/train verifier 分离,训练用的判据与最终评测用的判据是两套独立集合。
2. 弱 verifier 在 RL 里被放大(呼应 Q10):静态评测里弱 verifier 只是「测不准」;在 RL 里它是奖励来源,reward hacking 被策略主动搜索并放大——agent 朝「骗过弱测试」(改测试文件、空实现过 CI)的方向优化,越训越坏。
3. 分布偏移(distribution shift):RL 改变策略 → 轨迹分布改变 → 训练初期校准的 verifier 到后期可能不再有效——agent 进入了 verifier 从未见过的行为区域,判据的假阳/假阴率未知。
4. proxy reward gap:benchmark 测「任务成功」,但 RL 用的 reward 是任务成功的代理(单测通过 / 终态校验通过 / LLM-judge 评分)。这个「成功 ↔ proxy」的差距就是 reward hacking 的温床——agent 优化 proxy 而非真目标。
5. RL 运行污染 benchmark:如果 RL 训练轮次中用了 benchmark 题目做环境交互(不只是最终评测),那些题目后续不能再用——agent 已在这些题上训练过,再测即污染。

缓解:① eval 题集与训练题集物理隔离(各自独立采样,不是随机切分——agent 评测题天然少,随机切分不够安全);② RL reward 用独立于最终评测的隐藏训练判据(训练专用 verifier,与最终 eval 判据不重叠);最终评测判据须至少同等强度且完全 held-out;③ 定期人工抽查 agent 轨迹,看是否有 reward hacking 信号;④ 用多个异构 reward 源交叉验证,而非依赖单一 signal。

追问： eval/train verifier 分离和 eval/train problem split 是一回事吗? → 不是。problem split 是「哪些题用于训练、哪些用于评测」;verifier split 是同一道题用不同判据——训练时只暴露训练专用弱判据(少量可见单测),评测时用 held-out 的完整强判据集(不与训练判据重叠)。两层都要做,只做一层不够。

答:学术 benchmark 分数衡量的是理想条件下的能力上界,生产 agent 还要看五个维度:

追问： shadow deployment 具体怎么做、看什么? → 把 agent 部署在与生产同分布但隔离的环境(生产流量镜像 / 生产快照回放 / dry-run 模式),写操作走 no-op / sandbox adapter 不做真实副作用(不触发支付、不发送外部消息、不对真实用户可见);暗中运行数天到数周,统计:

• shadow 指标(离线可测):真实分布任务成功率 vs 学术榜差距、单任务成本分布、安全红线触发率、延迟/步数分布
• live 指标(需 canary / A-B / 辅助人工部署才能测):用户放弃率、人工接手率、满意度——这些 shadow 模式下测不到,要拆开说

这套数字和学术榜分数的 gap,就是 agent 从「能做题」到「能干活」的鸿沟。做 shadow 前须确认:隐私/PII 合规(镜像流量是否含敏感数据)、写操作隔离是否彻底、有 approval 流程。