GitHub ReviewBench：面向 AI 代码评审的开放基准

智能体代码审查正成为开发过程中不可或缺的一环。它帮助你检查拉取请求、发现问题，并在代码发布前决定哪些内容值得关注。

但现有 AI 审查器的质量可能难以衡量，你需要先了解一个审查器的长处，才能判断它是否对你有帮助。有些审查器会发现更多问题，有些产生的噪声更少，有些更擅长捕捉关键问题，而另一些也会指出较小的改进。你可能需要代码审查在工作流中承担不同的任务。

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

我们构建了 ReviewBench，一个新的代码审查离线基准，以弥补这一空白，并且你今天就可以使用它。它遵循拉取请求的语言、仓库规模和规模分布，以 GitHub 上超过 1 亿个真实拉取请求为蓝本。它采用多来源黄金集和一致的评估标准，并已由资深工程师独立验证。同样重要的是，借助 ReviewBench，我们对 Copilot 代码审查（CCR）的离线评估更能预判生产实验的方向，使我们更有信心：测得的改进反映的是对用户有意义的收益。

在本文中，我们将介绍 ReviewBench 是如何构建的、它如何确立可靠的基准真相与评分，以及如何接入你自己的代码审查系统并提交结果。

本博文中所用术语的定义

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

ReviewBench 一览

1

我们构建的内容

面向 AI 代码审查智能体的真实、全面的基准

103.9M

GitHub 拉取请求

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

具有代表性的基准语料

219 个公开拉取请求，涵盖 19 种语言，与 GitHub 整体分布对齐，同时保留有实质内容的审查案例。

多源黄金集

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

结构化发现

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

严重程度

• 严重
• 中等
• 低

类别

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

评估指标

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

• 锚定精确率
• 锚定召回率
• 增强精确率
• 增强召回率

客观评估

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

2

我们如何确保其可信

从评分标准到专家验证再到生产检查的可审计链路

已发布的评分标准

适用于所有发现的一套明确标准。

人工标注的开发集

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

已校准的评分器

与人工判断保持一致。

统一标注

所有来源采用同一标准。

已发布的一致性

专家对基准质量的审计。

端到端可审计

96.6% 一致性

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

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

基准变动会对照在线实验加以检验。

• 改进往往会在线上体现
• 回归往往也会在线上体现

ReviewBench 如何运作

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

1. 具有代表性的拉取请求，而非演示集

我们分析了 103.9 million 个 GitHub 拉取请求，以刻画代码评审工作负载的真实分布。ReviewBench 包含来自 187 个公开的开源许可仓库、涵盖 19 种语言的 219 个拉取请求，其语言与仓库规模分布与 GitHub 整体高度吻合。完整的基准数据集已公开发布。

我们对这一分布做了一处有意调整：语言和仓库规模直接镜像 GitHub，而拉取请求规模则向可评审的中段和尾部加权。这降低了微小的单文件改动占比过高的问题，同时保留更多实质性的多文件拉取请求，因为评审质量在这些请求上最为重要。

语料快照一览：

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

无论是人工还是模型，没有任何单一评审者能找出拉取请求中所有值得发现的问题。为了构建更广泛、更可靠的基准真值发现黄金集，我们采用三阶段流程：

• 从多样化来源收集候选发现。 我们收集来自真实人工评审者的发现、从作者后续提交推断出的问题、确定性分析工具的结果，以及跨模型家族的多个前沿 LLM 的发现。
• 对重叠发现进行语义去重。 我们将识别同一底层问题的发现合并，从而扩大覆盖范围，同时避免不同产出方之间的一致意见人为膨胀黄金集，或使其受制于任一来源的盲点。
• 在统一评分标准下验证发现。 一项发现的来源并不能决定它是否正确：只有当该发现为真、相关且非平凡时，才计为真阳性。我们使用 Claude Sonnet 5 作为 LLM 评分器，对所有提交应用一致的评估标准。为了透明性与可复现性，我们同时公布评估标准以及用于执行该标准的评判器。

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

大多数基准会针对固定的黄金集报告精确率和召回率。ReviewBench 报告分属两个系列的六项指标：

• 锚定精确率、召回率和 F1 分数仅使用现有的黄金集标签。它们提供严格的同类比较：在我们已经知晓的问题中，智能体发现了多少，以及其发现中有多大比例与已知问题相匹配？
• 增强精确率、召回率和 F1 分数还会评估那些与黄金集中任何内容都不匹配的发现。评判器会独立判定这些未匹配的发现是真阳性还是假阳性，从而使评审者能够因黄金集中没有任何产出者提出过的有效问题而获得认可

随着评审智能体能力增强，这一区分变得更加重要。当系统发现其创建者未曾预料的问题时，固定的黄金集不可避免地会变得不完整。增强指标让 ReviewBench 能够认可这种行为，而不是自动对其施加惩罚。由于增强召回率会根据每个智能体所发现的内容扩大分母，我们以锚定召回率作为跨系统对比的主要指标，并将增强指标作为针对各系统的额外诊断。

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

并不存在一种普遍最优的评审体验。有些开发者可能只想关注关键问题，而另一些人也看重严重程度较低、不会导致故障的发现。有些人偏好更广的覆盖范围，而另一些人则优先考虑精确率并尽量减少噪声。还有一些人可能有专门需求，例如以安全或隐私为重点的评审。

ReviewBench 支持按严重程度和类别对结果进行切分，而精确率和召回率则体现不同的运行偏好。用户还可以调整 Fβ 分数中的 β，从而在追求更广覆盖时更侧重召回率，或在追求更低噪声时更侧重精确率。随着这些偏好发生变化，排行榜会相应重新排序，帮助用户识别最符合其评审优先级的系统。

5. 经内部审计且可复现评估

发布之前，我们请未曾参与构建该基准数据集的资深工程师，从头独立重新标注每一项真实标签发现。他们的真/假阳性判断与 ReviewBench 的一致率为 96.6%。我们对每次评估所用的基准数据集、评判器和匹配器进行版本管理，以便在相同的基准配置下比较结果，并在基准发生变化时重新验证。我们还公布验证方法、一致性测量结果以及已知的效度威胁，以便读者了解基准质量是如何评估的，以及不确定性仍然存在于何处。

探索 ReviewBench

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

借助 ReviewBench，你可以：

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

我们如何使用 ReviewBench

我们已使用 ReviewBench，在历次迭代中评估 Copilot code review (CCR)，从而以一致的方式衡量进展、发现回归并优先处理有前景的改动。随着时间推移，这帮助我们改进了产品。ReviewBench 最有价值的益处之一是，它能提前提供离线信号，表明产品改动在生产环境中可能的表现。在 A/B 测试之前使用 ReviewBench 评估的各项实验中，离线变化的方向始终与我们后来在生产环境中看到的一致。

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

为比较离线结果与生产结果，我们使用相应的在线信号。已处理率是精确率的在线对应指标，即 LLM 根据 diff、讨论线程、反应、解决状态和审查后代码，判定为促使开发者做出相应代码更改的 CCR 评论所占百分比。对于召回率，我们衡量仍需要多少额外的人工审查。

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

然而，仅凭评论量并不能体现评论质量。更多关键发现与低严重程度的琐碎意见含义截然不同。ReviewBench 的严重程度级别评估同样捕捉到了这一点：它预测关键评论增加 227%，在线结果为 262%，并且同样出现了中等评论增多、琐碎意见减少的整体转变。

这使我们在运行生产实验之前获得快速且可重复的信号。在线实验仍是衡量用户影响的最终标准，但 ReviewBench 让我们更有把握判断哪些改动值得拿到那里验证。

如何提交你自己的运行

1. 使用 GitHub 登录于 ReviewBench 网站。
2. 注册你的代理。 提供容器镜像、你的配置以及你自己的模型密钥。评判由我们提供。
3. 在测试集上试用。 对一个带有逐 PR 详情的 25-PR 测试集运行，并在调整配置时重复进行。
4. 进行最终运行。 准备就绪后，运行全部 219 个拉取请求（三轮），并由与其他所有条目相同的评判者评分。
5. 发布到排行榜。 在维护者审核并批准提交之前，你的分数保持私密。只有当分数超过该智能体当前的排行榜分数，或这是该智能体的首个排行榜条目时，分数才会发布到排行榜。

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

致谢

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

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