智能体输出的验收抽样:制造业质量保证领先于代码审查的秘诀
你的智能体集群(agent fleet)本周开启了 40 个拉取请求(pull requests)。你审查了其中涉及支付代码的 6 个请求,浏览了几个正好在你打开标签页时提交的请求,然后只要通过了 CI 测试,就将其余的全部合并了。如果有人问你的审查政策是什么,你大概会描述成类似上面的做法——但这根本不是政策。这只是一种“心情”(mood)。
数据表明大多数团队都处于同样的境地。最近一项针对流行开源仓库中智能体生成的拉取请求的大规模研究发现,61% 的请求完全没有任何审查记录;而在确实经过审查的请求中,大多数也仅由其他智能体进行审查。与此同时,产量仍在攀升:智能体现在生成 PR、文档、支持响应和工单的速度,已经超出了任何人类审查流程的设计初衷。审查所有内容是不可能的,而完全不审查则是玩忽职守。因此,团队在两者之间即兴发挥,既没有明确的规则,也没有衡量的覆盖率,更无法判断当前的审查力度是过于偏执还是草率鲁莽。
制造业在一个世纪前就解决了这个问 题。20 世纪 20 年代,当西部电气(Western Electric)大量生产电话设备时,对每一个单元进行检查在经济上是不可能的,而运送未检查的批次又是不可接受的——于是贝尔实验室的统计学家们建立了“验收抽样”(acceptance sampling):这是一门具有数学依据的学科,用于决定一批产品中需要检查多少、何时拒绝整批产品,以及供应商何时赢得了放宽检查的信任。它在二战期间演变为 MIL-STD-105 标准,随后成为 ANSI/ASQ Z1.4 和 ISO 2859-1,至今仍规范着港口如何验收一整箱货物。这与智能体集群的对应关系几乎是直截了当的,但在 AI 工程领域几乎没有人采用它。
“审查看起来重要的内容”不是政策
首先来看看为什么这种即兴的折中方案会失败。典型的潜规则是基于“显著性”(salience)的:审查那些看起来有风险、涉及你关心的文件或刚好出现在你屏幕上的更改。这听起来很合理,但会在三个特定方面失效。
首先,显著性与错误的东西相关。你审查的是“可见”的内容——大的 diffs、熟悉的子系统、在工作时间提交的更改。而逃逸的缺陷通常集中在“不可见”的地方:细微的配置更改、生成的迁移脚本、无人认领的文档。对智能体生成的 PR 的研究表明,审查精力集中在结构足迹(涉及的文件、更改的行数)上,这在任何人类查看更改之前就是可预测的——但结构足迹是审查“成本”的指标,而不是缺陷“风险”的指标。
其次,基于显著性的审查没有可衡量的覆盖率。如果下个月你的缺陷率翻倍,你的流程中没有任何环节会察觉到,因为你从未知道自己检查了多少比例的输出,或者你在样本中观察到的缺陷率是多少。你无法检测到你未测量的指标的漂移。
第三——这也是在组织层面上最重要的一点——非正式的政策无法被辩护或列入预算。当领导层询问“我们对智能体工作的审查是否足够?”时,在基于“感觉”的审查下,诚实的回答是“我们不知道,而且我们对‘足够’没有定义”。相比之下:“我们按照 AQL 1.0 进行正常检验,样本中观察到的缺陷率为 0.4%,由此推导出的缺陷逃逸概率如下。”只有后者经得起审计。
“随机审查 10%”——这是团队有时会升级到的政策——确实更好一些,因为它至少是一个具有可衡量覆盖率的明确规则。但它是一种粗放的手段:无论风险、批次大小或过往记录如何,它都检查相同比例的内容,而且它没有回答当样本中出现缺陷时该怎么办。验收抽样就是“随机 10%”模式的成熟版。
运作机制:批次、AQL 和 OC 曲线
验收抽样依赖于几个可以迁移的机制。
批次(Lot)是作为一个整体进行判断的一组同质输出——在制造业中,这是一次生产运行;在智能体集群中,类似于“本周来自升级工作流的依赖项更新 PR”或“今天生成的 500 个支持工单摘要”。批次的定义至关重要:将来自不同工作流的输出混合到一个批次中会破坏统计结果,因为缺陷率是“流程”的一种属性,而不同的工作流 就是不同的流程。
AQL——可接受质量水平(acceptance quality limit)——是你在流程被视为受控的情况下愿意常规容忍的最差缺陷率。这是一个协商出的业务数字,而不是统计数字。生成的文档中的排版问题可能有 4% 的 AQL;而错误的退款决策可能只有 0.1%。声明 AQL 会迫使团队进行大多数团队从未有过的对话:针对每种输出类型,我们实际上愿意忍受多高的缺陷率?
给定批次大小和 AQL,标准表(如 Z1.4 的样本量代号字母)会给出样本量(sample size)和合格判定数(acceptance number):从批次中随机检查 n 个单位;如果发现的缺陷多于 c 个,则拒绝整个批次。关键特性在于,样本量的增长速度远慢于批次大小——500 个单位的批次可能需要 50 个样本,而 3200 个单位的批次需要 125 个,而不是 320 个。统计置信度更多是绝对样本量的函数,而非抽样比例的函数,这正是为什么扁平的“审查 X%”规则会对小批次过度审查,而对大批次审查不足的原因。
每个方案背后都有一条抽检特性曲线(operating characteristic curve,简称 OC 曲线),它描绘了接受批次的概率与其真实缺陷率之间的关系。OC 曲线使两种失效模式变得明确:生产方风险(α)——拒绝了一个实际上合格的批次的概率,即浪费了升级成本;以及使用方风险(β)——接受了一个实际上不合格的批次的概率,即缺陷逃逸。历史上存在的每一种审查政策都有一条 OC 曲线;验收抽样只是让你清楚地知道你的曲线是什么。“我们审查任何看起来重要的内容”也有 OC 曲线——只是你画不出来,这意味着你无法为其辩护。
而且,拒绝批次意味着比修复你发现的缺陷更严厉的措施。在制 造业中,被拒绝的批次要退回进行 100% 的全检。对于智能体集群:如果升级工作流抽样的 50 个 PR 中有 3 个有缺陷,那么应对措施不是“修复那三个”,而是“由人类审查该批次中剩余的所有 40 个 PR,并对该工作流最近合并的输出进行审计”。样本的存在不是为了捕捉缺陷,而是为了判断产生该批次的流程。
- https://asq.org/quality-resources/z14-z19
- https://www.aqlinspectorsrule.com/manual/switch.html
- https://www.6sigma.us/six-sigma-in-focus/operating-characteristic-curve/
- https://arxiv.org/html/2605.02273v1
- https://arxiv.org/html/2601.00753v1
- https://www.braintrust.dev/articles/human-in-the-loop-evals-for-llm-apps
- https://www.datadoghq.com/blog/llm-evaluation-framework-best-practices/
