智能体评测中的人类基线

这个词要先意味着什么，才能意味着任何东西。

「人类水平」被使用时，好像人类有一个水平似的。人类没有——人类有的是一张关于条件的性能曲面，而一条基线是这张曲面上的某一个点。四个坐标固定这个点；一条没有把四项都说清楚的基线，无法与任何东西比较，包括它自己日后的一次重跑。

# A human baseline is this tuple, or it is a rumour

who       expertise, domain familiarity, familiarity with THIS codebase
budget    wall-clock allowed per task, and whether it was enforced
tools     search? a debugger? the internet? an LLM?
grader    the identical scorer, applied to human and agent output

# Report format that survives a year

  human   41/60 @ 2h cap, n=6 annotators, same rubric
  agent   37/60 @ 2h cap, same rubric, pass^3
  ratio   0.90  (CI overlaps; see paired test)

第四个坐标是几乎所有人都会丢掉的那个，也是会把结论整个翻过来的那个。如果智能体由一个自动检查器来评，而人由一位读 diff 的评审来评，那你比较的并不是「两个工人在一件任务上」；你比较的是「两套打分制度在两个工人身上」。轨迹与过程评测的那个问题——我们究竟在给什么打分——必须回答一次，然后不加调整地套在双方身上。

判断你到底有没有一条基线的实操检验：一个陌生人只凭你的记述，能不能把你的人类数字复现到几个点以内？如果记述写的是「人类专家大致能到 90%」，并引用一篇在不同时间预算下测了不同的人的论文，那你导入的是一个常数，不是一条基线。

坐标压过模型，而时间预算压过坐标。

人们很容易以为这个四元组是对「能力」这个一阶事实的二阶修正。在现实的智能体任务上恰好相反，因为被测量的那个量——一件多步工作有没有到达一个可核验的终态——对「工人有多少时间」和「工人已经知道什么」极度敏感。

• 时间预算。人在一件数小时的软件任务上的成功率，在很宽的区间内大致随允许时间单调上升，而这个区间恰恰覆盖了有意思的任务所在的地方。一条不设上限的人类基线与一个受步数限制的智能体不在同一根轴上，而这个比较会偏向你忘了设限的那一侧。智能体几乎总是被设了限的——受上下文、步数上限和成本所限——这些限制如何相互作用见重试放大。
• 熟悉度。在以仓库为基础的任务上，一位熟悉这个代码库的贡献者，和一位同等技术水平但从未见过它的工程师，不是同一条基线，而且差距很大。你为基线雇的是哪一位，决定了你的智能体看起来是接近专家，还是接近超人。
• 工具可得性。一条在 2023 年、不许联网的条件下采集的人类基线，测的是一个你的智能体并不在与之竞争的工人。而一条 2026 年、允许标注者使用助手的基线，测的是一个「人加智能体」的系统——对部署决策来说这通常是对的比较，对能力主张来说则是错的比较。请刻意选择，并标注清楚。
• 标注者之间的方差。同一件任务上的个人完成时间相差的是倍数，不是百分点。METR 之所以用几何平均来聚合多次成功的基线，正是这个原因——一个重尾时长分布的算术平均会被它最慢的那个样本主导。

打分器不是中立的，而且它同时朝两个方向偏。

假设你把前三个坐标都固定好了。打分器仍然会把这场比较掰歪，而有意思的地方在于：两种常见的打分器把它掰向相反的方向——这就是为什么文献可以支持你想要的任何结论。

# Same work, two graders, two directions of bias

automated checker (tests, exact match, SQL result diff)
  favours  the worker optimising for the check
  costs    the human, who solves the task as stated
           and loses points on an unstated convention

LLM judge (rubric, pairwise, reference-free)
  favours  structured, verbose, confident prose
  costs    the human, whose terse correct answer
           reads as low-effort against the rubric

# The only stable fix
  one grader, blind to authorship, applied to both,
  with the human transcripts in the SAME format

这条「盲评」要求比听起来更强。人的提交通常以一个带提交信息的 pull request 形式到来；智能体的提交以一份 diff 加一份轨迹的形式到来。一个评判器仅凭格式就能分辨哪个是哪个，而评判器偏好「智能体形状的输出」是一种已被记录的失效方式，不是一种猜测——这与评判器校准与元评测是同一个校准问题，只是多了一层麻烦：这里的两个群体在系统性上是可分辨的。

自动检查器有互补的毛病。一套测试编码了任务陈述里没写的约定，而智能体是从仓库里学到这些约定的，人类标注者读的却是工单。那在被部署的任务上是一处真实的性能差异，所以它不自动就是一种应当被移除的偏差——但它必须被报出来，因为「智能体更常通过隐藏测试」与「智能体把问题解得更好」是两个不同的主张，而只有前者被测过。相关内容：评测完整性与打分器博弈。

这个领域真正建起来的那一条基线，以及它说了什么、没说什么。

公开的智能体评测里，最扎实的人类基线工作是 METR 的时间跨度研究，而它值得理解，恰恰因为它的方法与通常那套是反的。它不问「模型通过了任务里的多大比例」，而是为每一件任务估出人类专家的完成时间，把模型的成功率对这个人类时间的对数拟合成一条逻辑斯蒂曲线，然后报出曲线穿过 50% 的那个点——即 50% 任务完成时间跨度，以「等效人类工时」为单位。

• 它买来了什么。人类测量成了 x 轴而不是一个单一的比较点，于是结果是一句关于任务难度、以人类小时为刻度校准过的话，而不是一个取决于你任务集里难易配比的百分比。两个配比不同的基准能产出可比的时间跨度；两个配比不同的基准产不出可比的通过率。
• 它的代价。真实的基线采集：每件任务多位标注者，并对成功尝试做几何平均聚合。2026 年 1 月的 Time Horizon 1.1 更新把长跨度套件从 14 件扩到 31 件，每件估计需要人类八小时以上——这就告诉了你，把一条校准过的基线延伸进所有人最想被测量的那个区域，价钱是多少。
• 它没有说什么。METR 自己发过一份关于这个指标局限的说明，而诚实的读法是窄的：一个 50% 跨度是一句关于「一族有清晰成功判据的软件任务」的话，不是「模型在你的工作上能被信任那么久」这个主张。按构造，在跨度处的可靠性就是 50%——参见任务跨度，看看为什么人们真正想要的那个数字是 80% 或 95% 跨度，而它要短得多。

拿这个去对照，就会注意到智能体采购里最常被引用的那个基准缺了什么。SWE-bench Verified 有一个经人工校验的任务集——标注者确认了这些问题可解、测试公允——这和「在同一批任务上、设了时限的人类性能基线」是两件不同的事。所以那句被反复复述的框架——「模型 X 现在能解决 70% 的真实 GitHub issue，正在接近专家水平」——里面含着一个从未被跑过的比较。2026 年基准全景里的饱和论证还要叠加在上面：一旦五个模型彼此相差一个点以内，那个缺失的分母就是唯一还有可能让这个数字与决策相关的东西了。

用大约两个人日建起你自己的基线。

团队跳过这一步，是因为相信做基线是一个研究项目。在你自己的任务集上它不是，因为你不需要一个可发表的估计——你需要的是一个稳到能一年除两次的分母。二十件任务、两位标注者，就足以把你从「没有基线」推到「有一条站得住的基线」。

# Minimum viable baseline, ~2 person-days

1  sample 20 tasks from the same pool the agent runs on
     stratify by your own difficulty proxy, not by outcome
2  fix the budget BEFORE anyone starts
     e.g. 45 min/task, hard stop, partial credit allowed
3  two annotators, disjoint halves, 4 tasks overlapping
     the overlap is your inter-annotator agreement
4  submissions normalised to the agent's output format
     strip commit messages, author names, styling
5  grade blind, with the agent's grader, in one sitting
6  publish: n, budget, tool policy, agreement, CI

# Refresh cadence
  re-baseline when the task pool changes, not when
  the model changes. The baseline is a property of
  the tasks.

• 在看到结果之前分层。在你已经知道智能体在哪些任务上失败之后再抽样，产出的基线回答的是一个你早就知道答案的问题。分层变量应该是你能从任务本身算出来的东西，而不是从一次运行里算出来的。
• 要么两边都给部分分，要么两边都不给。混着来的制度是最常见的那种安静错误：智能体从检查器那里拿到通过或不通过，而人被一位「看得出他其实差一点就成了」的同事宽容地评判。
• 把重叠预算花掉。四件共享任务几乎不花什么钱，却能给你那唯一一个数字：它告诉你你的评分标准到底是一份标准，还是一种心情。如果两位标注者在共享任务上意见不一致，那你的智能体分数具有同样的不稳定性，而你一直在读噪声——处理它的机械装置在评测方差与统计功效里。
• 花一次钱，摊销一年。一条二十件任务的基线，对你之后跑的每一次模型评测都是一笔固定成本，这按评测的成本的标准来说很便宜——而且远比另一种选择便宜，那就是拿一个没有分母的比值去做采购决策。

汇报比值，不要汇报分数。

一旦有了基线，就改掉你对内发布的东西。一个裸百分比会招来与别的团队的裸百分比做比较，而那些是不可比的；一个对着明示基线的比值，会强迫那四个坐标进入句子里，并让主张变得可审计。

• 把四元组放在最前面。「为我们内部基线的 0.90（2 小时时限、对本仓库非熟手的标注者、同一打分器、n=6）」比「37/60」长，而它是这句话唯一能让读者据以行动的形式。
• 永远不要跨时限比较。拿一个不设限的模型分数去对一条设了限的人类基线，是制造比值最常见的那一种方式。如果你没法用同样方式给智能体设限，那就把两个数都报出来，并拒绝做除法。
• 把人的轨迹留着。它们是这项练习产出的最有价值的制品：一套在你自己任务上标好的正确轨迹，它会喂给评测集维护，也给你的评判器提供了可校准的对象。
• 预期这个比值是锯齿状的。一个跨越混杂任务池的单一比值，会把真正要紧的形状藏起来——在某些任务族上高于基线，在另一些上远低于基线，而原因并不沿着人会去排的难度顺序走。那就是锯齿前沿，而按任务族拆开来看的那份细目，才是部署决策真正落定的地方。