3rd evaluations¶
本文围绕 Codex 第三方评测，记录 Harness、资源预算、标准化比较和可信评测证据等关键问题。
阅读"A shared playbook for trustworthy third party evaluations"摘要: https://openai.com/index/trustworthy-third-party-evaluations-foundations/
codex这边定义了harness:
... performance depends not only on the model, but also on the environment in which the task takes place, and on the setup that facilitates its actions. This surrounding setup, which we call the “harness,” ...
所以说harness包括：(1) 模型之外的环境； (2)模型和环境交互的能力；基于外部的能力不同，相同的模型表现不同。在企业内部大量存在这种harness，这并不是个新鲜的概念。
这篇文章强调了agents不仅仅是 prompt-response这种结构，还包含着更多的结构，主要是control loop.
这给测试带来了新不同: (1): 测试环境是evaluation报告的重要因素，不能被忽略; (2) 更多关于evaluation报告是可靠的证据;
测试通常落入三个形式
- Capability elicitation: 模型是否能达到测试需要达到的能力
- Safeguard performance: 模型里的安全防护是否够
- Comparison: 如何在相同条件下横向比较模型间能力
harness在长轨迹的任务里对结果影响很大，所以在衡量模型（这是在讲衡量模型么，还是agent）的时候，harness是需要被显示定义的。
文中给出了几个测试场景，比如:
- capability under strong elicitation: 测量系统（模型+harness）在充分合理的harness帮助下可以展现的能力
- controlled comparison：相同 harness 下，A/B 哪个表现更好
- safeguard robustness：系统防护能否经受充分诱发的攻击
对于不同的场景是不同的测评目标，并给出了该如何控制harness系统的建议，可以查看具体文章去看细节。
测模型能力用好的但是可控的harness，这里需要选择最适合任务的harness系统， 比如openai发现当compact能力被引入后，模型表现更好了。比较模型能力用相同的harness，没什么特别的。
除了harness，resource budget也会影响eval的结果，resource budget的问题anthropic也提到过。
标准化harness¶
前面提到测试模型能力要选一个适合当前任务的harness，不同模型“最适合”的harness可能也不同，但这样就引入了同一套内容对不同模型测评是没有可比性的。
这个时候，统一标准化harness尽管无法充分代表模型上限能力，但它提供了公平可比的多agents比较。
这里提到了METR's time-horizon evaluation， 就提供了一种可靠公平的横向系统对比方案。
time horizon 说的是AI在x%能可靠完成的任务，其“人类专家完成时长”大约有多长。
例如 50% time horizon = 2 小时 的意思是：对 METR 任务集中，人类专家通常要花约 2 小时的任务，这个 agent 预计有 50% 概率做成功。
作者建议在三方evaluation的报告里，他应该写清楚他们的测试是为了支持哪种claim，同时描述清楚实际测到的东西，和你声称的更大结论之间有多接近。
evluation hazard and mitigate¶
有很多内容会影响evaluation，博客列出了一些内容，简而言之就是有个各种各样的问题，evaluation并不是一件简单的事情。
- Reward hacking
- Refusals
- Contamination
- Broken problems
- Sandbagging
openai给出了一些认为比较好的evaluator方法, 但也只是方法论的概括，谈不上具体细节。
-
给出尽量可以诱发模型能力的harness，也就是文中说的"specific maximum-elicitation guidance"， 前文提到模型能力在不同harness下差距比较多，就是这个意思。
-
使用codex作为openai模型的基准，这里比较特别的是测评不再意味着 prompt-response做测评这种场景， 而是伴随着更复杂的harness系统，例如codex就是个harness系统。
-
在必要时给评测者提供 reasoning traces 等中间过程。这是为了做 validity checks。例如模型失败了，究竟是不会、拒答，还是故意藏能力（sandbagging）？模型看似遵守安全规则，是否其实在计划欺骗？只看最终答案常无法分辨，需看中间推理/工具调用轨迹等证据。
-
研究 harness 的哪些选择会实质改变结果。例如上下文怎么压缩、是否给工具、失败后可否重试、如何评分、token/时间/计算资源预算。这是在把前文的“harness 很重要”从原则，变成可量化的实验研究。
看第三方评测报告时要看什么¶
不能只看最终分数。报告至少需要说清楚：
- 测试想支持什么 claim：比较系统、估计能力上限，还是测试安全防护；
- 测的具体是什么任务，以及这些任务实际在测什么能力/失败模式；
- 被测系统是什么：模型、推理设置、工具、harness 和安全防护；
- 给了多少预算：轮数、token、重试次数、时间和成本；
- 用什么 harness 来诱发能力，测试结果和它声称的更大结论之间有多接近；
- 是否检查了 reward hacking、数据污染、拒答、sandbagging、坏题等会扭曲结果的问题，以及这些问题是否影响最终解释。
否则结果可能低估模型在真实 harness 下的能力，或者把一个不可靠的安全结论说得太确定。