跳转到主要内容

作为发现工具的 Agent 集群:Patch the Planet 背后的评估问题

Agent 集群把评估问题从单个 agent 的精确率,转变为在给定误报预算下每计算小时的产出。大多数 agent 基准并不衡量这一点。

工业设计中锈蚀金属梁抽象图案的特写

在集群规模下失效的指标

单个 agent 报告一个误报,审阅者只需花几分钟。一万个 agent 各自报告一个误报,审阅者就要花掉一个工作周,而且审阅进行时队列还在不断增长。这个算术并不微妙,却常被跳过:精确率被当作模型的属性来报告,而误报的成本是消费它的流水线的属性。

这就是两个看似无关的项目之间的结构性相似之处。OpenAI 在发现和修补漏洞方面的安全工作,以及它的生物数据 agent 项目,都是把一群 agent 放在一个语料库前面,然后让人类来裁决返回的结果。两种情况下,瓶颈都不是模型在留出集上的召回率,而是一小批合格审阅者确认或拒绝候选的速度。一份漏洞报告需要一个能复现它的人;一条生物学线索需要一个能判断它是否值得做湿实验的人。这两个队列都不随 GPU 小时扩展。

于是有用的问题变了。不要问一个 agent 有多精确,而要问:在给定的误报预算下,一个集群每单位审阅者注意力能产出多少已确认的发现。这是一个不同的量,在不同的轴上衡量,而大多数 agent 基准并不报告它。它们报告的是在精心策划的任务上的通过率,这些任务的每个输出都已知是可核查的,这恰恰去掉了主导真实集群部署的分诊成本。

这一转变也改变了“发现”是什么。在集群规模下,发现不是独立的抽样,它们会聚集。

去重就是产品

让一千个 agent 跑同一个代码库或同一个蛋白质相互作用语料库,它们会趋同。许多会浮出同一个缺失的边界检查、同一个可疑的结合基序、同一个畸形的解析器分支。原始输出看起来像大量的发现;去重后的输出往往只是其中一小部分。

Row of AA batteries lined up against a black and blue background

这使得聚类和去重成为承重组件,而不是后处理的点缀。流水线必须判断两个候选发现何时是同一个发现,并且要足够一致,让审阅者能信任这种分组。两种失败模式很重要。过度合并,真正不同的发现消失在一个簇里,这是无声的召回损失。过度拆分,审阅者看到同一个问题以十一种描述出现十一次,这就是分诊队列问题换了副面孔。

一致性风格的追踪——记录一组 agent 在相同或近乎相同的输入上何处产生分歧的做法——在这里变得有用,而且这一点容易被忽视。在单 agent 调试中,它只是好奇心的对象。在集群中,它是一个分诊信号:许多 agent 独立趋同的簇是强候选,而 agent 沿一致边界分裂的簇则告诉审阅者判断的抉择究竟在哪里。追踪不是发现正确的证据,但它是关于审阅者注意力最好花在哪里的廉价先验。

诚实的权衡是:去重本身就是一个模型形态的决策,有自己的错误率,而且它通常被评估得远不如它所服务的 agent 严格。一个为缩短队列长度而调优的去重层会激进合并并隐藏发现;一个为召回而调优的去重层会交回一个与完全不去重无法区分的队列。因此流水线应该把聚类决策暴露给审阅者,而不是隐式地解决它,并且应该评估排序列表是否把已确认的发现放在靠近顶部的位置,而不是评估簇看起来是否整齐。

集群基准应该报告什么

我们想要的发现集群基准不是排行榜上的一行,而是一条曲线,并且需要附上三样东西。

产出对审阅小时。 纵轴画已确认的发现,横轴画花费的审阅小时,并在每个操作点说明误报率,而不是一个平均值。曲线重要,是因为随着队列被处理,边际发现会变得更贵:第一个小时的审阅抓住明显的簇,第十个小时则磨过模糊的长尾。单个精确率数字完全掩盖了这种形状。

Blue Yaskawa industrial robot arm on display at a technology showcase

每个已确认发现的成本,包括分诊。 每次 agent 运行的计算成本容易测量,但单独看会误导。决定一个集群是否值得运行的数字包括去重环节、排序环节和审阅者时间,因为一个把计算减半却把审阅负载翻倍的配置是退步。报告整条链,否则什么都别报告。

同一语料库上的可复现性。 用相同的集群配置对同一语料库重跑,报告已确认集合中有多少复现。集群的随机性会以复合的方式叠加:采样、工具调用顺序和聚类阈值都会相互作用。一个已确认发现不复现的配置不是发现工具,而是一个带良好界面的随机数生成器。

一个让它被测量到的具体机制:给流水线加埋点,让每个候选都携带一条溯源记录,从产生它的 agent,经过它落入的簇,到解决它的审阅者决策。这条记录让团队能在事后计算产出曲线,而不是凭记忆重建,也让重跑能与原始运行可比。

这些都不是免费的。埋点增加延迟和存储,排序列表需要一个本身需要评估的排序模型,而审阅小时轴需要一个诚实到记录自己审阅时间的组织。替代方案是一个输出量增长快于已确认发现的集群,而这正是基准目前看不见的失败模式。

先预算审阅者注意力

由此得出的设计规则对以计算为思考单位的团队来说并不舒服:先设定审阅者预算,再据此确定集群规模。如果分诊能力是每周固定的若干小时,这个数字就决定了流水线能负担发出多少候选,集群规模则由每个候选的预期产出推导出来。把 agent 扩展到超过分诊能力不会产生更多发现,只会产生更长的队列、士气低落的审阅团队,以及不断增长、没人能将其与噪声区分开的未裁决候选积压。

这颠倒了通常的扩展对话。更多 agent 只有在去重和排序层把它们的输出转换成更短、排序更好的列表时才有用。当这种转换很弱时,额外的 agent 只会增加成本和队列深度,却拿不出已确认的发现。做对这件事的组织往往把分诊流水线当作产品,把集群当作它的供应商,并且按每审阅小时的产出来评估供应商,而不是按它能生成多少候选。

对于漏洞发现和生物学线索生成这类裁决步骤昂贵、合格审阅者供给固定的项目,这种框架不是一种改进,而是能发现东西的集群与只会制造工作的集群之间的区别。

分享XLinkedIn永久链接6 分钟阅读

相关阅读

这能回答的问题

Why is precision per agent the wrong metric for a fleet?

Because the cost of a false positive is paid by a reviewer, not by the model. At fleet scale the aggregate false-positive volume becomes a triage queue, so the useful measure is confirmed findings per unit of reviewer attention at a stated false-positive budget.

Why does deduplication matter so much in multi-agent discovery?

Many agents converge on the same finding. Without clustering, the output overstates discovery and buries distinct findings in repetition. The dedup and ranking layer decides whether the fleet's output is usable at all.

What should a fleet benchmark report?

A yield curve of confirmed findings against reviewer hours with the false-positive rate at each operating point, cost per confirmed finding including triage, and reproducibility when the same configuration is re-run on the same corpus.

How should fleet size be chosen?

Start from the reviewer budget. Triage capacity sets how many candidates the pipeline can afford to emit, and fleet size follows from expected yield per candidate. Scaling past that capacity adds queue, not discovery.