GitHub 发布 AI 代码审查开放基准 ReviewBench

Agentic 代码审查正成为开发流程中的关键一环。它可以帮助你检查拉取请求、发现问题，并在代码发布前判断哪些内容值得关注。

但现有 AI 审查器的质量可能很难衡量，而且在判断它是否能帮到你之前，你需要了解审查器的优势。有些审查器会发现更多问题，有些产生的噪音更少，还有些更擅长发现关键问题，而另一些也会指出较小的改进点。你可能需要代码审查在工作流中承担不同的任务。

因此，了解各类审查器的实际对比情况非常重要：不同系统能发现什么、会遗漏什么，以及它们做出了哪些取舍。一个好的代码审查基准应当反映真实拉取请求的多样性，涵盖广泛的审查发现，并支持按严重性、类别以及精确率-召回率偏好进行有意义的细分。对于构建代码审查代理的团队来说，该基准还应提供一种离线信号，能够可靠地反映变更是否可能改善生产环境中的体验。现有基准通常会在标签质量、覆盖范围以及对真实世界代码审查的代表性之间做出取舍，因此需要一种严谨且可复现的评估方法，将这些要素结合起来。

我们构建了 ReviewBench，一个新的代码审查离线基准，来填补这一空白，并且你今天就可以使用它。它遵循了拉取请求在语言、仓库规模和大小分布方面的特征，建模基础是 GitHub 上超过 100 million 个真实拉取请求。它使用多来源黄金集和一致的评估准则，并已由资深工程师独立验证。同样重要的是，在 ReviewBench 的帮助下，我们对 Copilot code review (CCR) 的离线评估已能更有效地预判生产实验的方向，让我们更有信心相信，测得的改进反映了对用户有意义的收益。

在本文中，我们将介绍 ReviewBench 的构建方式，它如何建立可靠的真实标注和评分体系，以及如何接入你自己的代码审查系统并提交结果。

本文中使用的术语定义

• 基准：一种标准化评估，使用相同的评分方法，在一组通用拉取请求上测试代码审查器。
• 发现：代码审查期间指出的某个具体问题。
• 黄金集：针对每个拉取请求的一组经过验证的已知发现，用作评估审查器发现或遗漏内容的参考。
• 精确率：在审查器指出的问题中，有效问题所占的比例。精确率越高，通常意味着噪音越少。
• 召回率：在已知有效问题中，审查器找到的比例。召回率越高，意味着覆盖范围越广。
• F1 分数：一个将精确率和召回率同等平衡的单一分数。
• Fβ 分数：F1 的一种变体，可根据你的审查偏好，对精确率或召回率赋予更高权重。

ReviewBench 概览

1

我们构建了什么

一个面向 AI 代码审查代理的真实、全面的基准

103.9M

GitHub 拉取请求

按语言、仓库规模和变更形态分析分布。

代表性基准语料库

219 个公开拉取请求，涵盖 19 种语言，在保留实质性审查案例的同时，与 GitHub 全站分布保持一致。

多来源黄金集

• 人工审查者
• 前沿 LLM
• 静态分析

结构化发现

每项发现都会标注严重程度和类别，从而支持按用户需求定制切片。

严重程度

• 严重
• 中等
• 低

类别

• 正确性
• 安全性
• 可靠性
• 可维护性
• 测试
• ......

评估指标

四项指标衡量已知问题和新发现的问题。

• 有依据的精确率
• 有依据的召回率
• 增强精确率
• 增强召回率

客观评估

客观地衡量改进并在不同智能体之间进行比较。帮助用户选择最符合其需求的审查者。

2

我们如何保持可信

从评判标准到专家验证和生产检查的可审计链条

公开的评判标准

为所有发现提供一个明确标准。

人工标注的开发集

资深工程师建立基准真值。

校准后的评分器

与人工判断保持一致。

统一标注

所有来源采用同一标准。

公开的一致性

对基准质量进行专家审计。

端到端可审计

96.6% 一致性

资深工程师在发布前独立标注了黄金真阳性。

可预示生产表现的离线信号

基准上的变化会对照线上实验进行检查。

• 改进往往会在线上体现出来
• 回归通常也会在线上体现出来

ReviewBench 的工作原理

我们的基准围绕五项原则构建：

1. 具有代表性的 pull request，而不是演示集

我们分析了 1.039 亿个 GitHub pull request，以刻画真实世界中代码审查工作负载的分布。ReviewBench 包含来自 187 个采用公共开源许可的仓库的 219 个 pull request，覆盖 19 种语言，其语言和仓库规模分布与 GitHub 整体高度匹配。完整的基准数据集已公开提供。

我们对这一分布做了一项有意的调整：语言和仓库规模直接反映 GitHub，而 pull request 大小则向可审查的中段和长尾加权。这减少了对微小的单文件变更的过度代表，同时保留了更实质性的多文件 pull request，因为在这些情况下审查质量最为重要。

语料库快速概览：

2. 广泛发现基准真值，并独立评判

无论是人工还是模型，任何单一审查者都无法识别出一个 pull request 中所有值得发现的问题。为了为基准真值发现构建更广泛、更可靠的黄金集，我们遵循三阶段流程：

• 从多样化来源收集候选发现。 我们收集来自真实人工审查者的发现、从作者后续提交中推断出的问题、确定性分析工具的结果，以及跨模型家族的多个前沿 LLM 的发现。
• 对重叠发现进行语义去重。 我们合并那些识别出同一底层问题的发现，扩大覆盖范围，同时避免不同生成者之间的一致性人为抬高黄金集，或使其依赖于任何单一来源的盲点。
• 在共享评估准则下验证发现。一项发现的来源并不决定它是否正确：只有当一项发现真实、相关且非平凡时，才算作真阳性。我们使用 Claude Sonnet 5 作为 LLM 评分器，对所有提交应用一致的评估准则。为提高透明度和可复现性，我们会发布评估准则以及用于应用该准则的评判器。

3. 同时衡量已知问题和新发现问题的指标

大多数基准测试都会针对固定的黄金集报告精确率和召回率。ReviewBench 报告两类共六项指标：

• 基于标注的精确率、召回率和 F1 分数仅使用现有黄金集标签。它们提供严格的同类对比：在我们已经知道的问题中，该 agent 找到了多少？它的发现中有多大比例匹配了已知问题？
• 增强精确率、召回率和 F1 分数还会评估那些与黄金集中任何内容都不匹配的发现。评判器会独立判断这些未匹配发现是真阳性还是假阳性，从而让审查器能够因发现黄金集中的任何生成方都未提出的有效问题而获得认可

随着代码审查 agent 变得更有能力，这一区分会变得更加重要。随着系统发现其创建者未曾预料到的问题，固定黄金集不可避免地会变得不完整。增强指标让 ReviewBench 能够识别这种行为，而不是自动对其进行惩罚。由于增强召回率会根据每个 agent 发现的内容扩展分母，我们使用基于标注的召回率作为跨系统比较的主要指标，并将增强指标作为额外的单系统诊断指标。

4. 面向不同审查偏好的可配置评估

不存在单一、普遍最优的审查体验。一些开发者可能只想关注严重问题，而另一些开发者也重视严重程度较低、不会导致破坏性变更的发现。有些人偏好更广的覆盖范围，而另一些人则优先考虑精确率和尽量减少噪声。还有一些人可能有专门需求，例如侧重安全或隐私的审查。

ReviewBench 允许按严重程度和类别切分结果，而精确率和召回率则捕捉不同的运行偏好。用户还可以调整 Fβ 分数中的 β，以便为更广覆盖范围赋予更高的召回率权重，或为更低噪声赋予更高的精确率权重。随着这些偏好的变化，排行榜也会相应重新排序，帮助用户识别最符合其审查优先事项的系统。

5. 内部审计并可复现评估

在发布之前，我们请未参与构建基准数据集的高级工程师从零开始独立地重新标注每一条真实值发现。他们对真/假阳性的判断有 96.6% 的时间与 ReviewBench 一致。我们会对每次评估中使用的基准数据集、评判器和匹配器进行版本管理，因此结果可以在相同的基准配置下进行比较，并在基准变化时重新验证。我们还发布验证方法、共识度量以及已知的有效性威胁，使读者能够了解如何评估基准质量，以及仍存在哪些不确定性。

探索 ReviewBench

ReviewBench 的研究预览版现已可通过 ReviewBench 网站访问，你可以在其中探索完整基准、比较代码审查 agent，并引入你自己的 agent 进行评估和迭代。

借助 ReviewBench，你可以：

• 探索完整的基准数据集。 完整的 ReviewBench 数据集已公开提供，包括拉取请求、发现的问题、标签、严重性和类别标注。这使你能够准确查看系统的评估内容，并复现基准测试结果。
• 在排行榜上比较各系统。 使用完整基准数据评估的代码审查代理的结果会发布在一个公共排行榜上，可按总体性能、严重性、类别以及不同的精确率–召回率偏好查看。
• 带上你自己的代理并持续改进。 完整的基准数据集、评估方法、LLM 评审提示词、评审模型配置以及自助运行器均已公开提供，因此你可以评估自己的代码审查代理，检查其优势与不足，并基于相同的基准配置进行迭代。

我们如何使用 ReviewBench

我们已使用 ReviewBench 在连续迭代中评估 Copilot 代码审查（CCR），为我们提供了一种一致的方式来衡量进展、发现回归并优先处理有前景的改动。随着时间推移，这帮助我们改进了产品。ReviewBench 最有价值的好处之一是，它能提供早期的离线信号，表明产品变更在生产环境中可能会有怎样的表现。在 A/B 测试之前用 ReviewBench 评估的各项实验中，离线变化始终与我们后来在生产环境中看到的方向一致。

最近的一次 lite-tier 实验为这一更广泛的模式提供了一个具体示例。我们引入了一种多模型集成审查，它将多个独立模型运行合并为一次审查，而不是依赖单次运行。ReviewBench 预测其精确率、召回率和评论量会更高，同时每次审查的成本会更低。

为了比较离线和生产结果，我们使用相应的在线信号。处理率（addressed rate）是我们在线环境中对应精确率的指标，指的是 CCR 评论中，由 LLM 根据 diff、讨论线程、反应、解决状态以及审查后的代码判断其促使开发者做出相应代码更改的百分比。对于召回率，我们衡量仍然需要多少额外的人工审查。

在线 A/B 测试的变化方向与 ReviewBench 的预测一致：处理率（精确率）上升 8.0%，召回率上升 13.6%，评论量上升 61%，而每次审查成本下降 8.0%，这些都是相对于生产对照组而言。

然而，仅评论量并不能反映评论质量。更多关键发现与低严重性的吹毛求疵有着截然不同的意义。ReviewBench 的严重性级别评估也捕捉到了这一点：它预测关键评论增加 227%，而在线结果为增加 262%，同时同样呈现出更广泛地转向更多中等严重性评论、更少细枝末节评论的变化。

这为我们在运行生产实验之前提供了快速且可重复的信号。在线实验仍然是衡量用户影响的最终标准，但 ReviewBench 让我们更有信心判断哪些变更值得推进到那里。

如何提交你自己的运行结果

1. 在 ReviewBench 网站上使用 GitHub 登录。
2. 注册你的代理。 提供容器镜像、你的配置以及你自己的模型密钥。我们提供评审器。
3. 在测试集上试用。 针对一个包含 25 个 PR 的测试集运行，并查看每个 PR 的详细信息；在调整配置时可反复运行。
4. 进行最后一次运行。准备好后，运行完整的 219 个拉取请求集（三轮），由与其他所有参赛作品相同的评审进行评分。
5. 发布到排行榜。在维护者审核并批准提交之前，你的分数会保持私密。只有当分数优于该智能体当前的排行榜分数，或者这是该智能体首次进入排行榜时，分数才会发布到排行榜。

我们邀请你探索 ReviewBench，评估你自己的系统，挑战我们的假设，并帮助我们改进该基准。我们很高兴能与研究人员和从业者合作，让代码评审评估更加开放、可靠且有用，并最终帮助推动 AI 代码评审向前发展。

致谢

ReviewBench 是 GitHub 和 Microsoft 跨团队协作的成果。我们感谢构建它的研究人员和工程师：他们设计了方法论，整理了拉取请求，构建了黄金集和评估流水线，并让这个基准成为任何人都可以运行的工具。

文章 ReviewBench：面向 AI 代码评审的开放基准 首发于 The GitHub Blog。