ReviewBench: An open benchmark for AI code review

智能代理代码审查正成为开发流程中不可或缺的一部分。它可以帮助您检查拉取请求，发现潜在问题，并在代码发布前确定需要重点关注的内容。

但现有AI审查工具的质量难以衡量，您需要了解审查工具的优势后才能判断其是否对您有帮助。一些审查工具能发现更多问题，一些产生的噪音更少，有些擅长发现关键性问题，而另一些则更关注小的改进。在工作流中，您可能需要代码审查承担不同的功能。

这使得理解不同审查工具的实际表现变得尤为重要：它们能发现什么问题，会遗漏什么，以及它们在性能上的权衡取舍。一个优秀的代码审查基准应能反映真实拉取请求的多样性，涵盖广泛的审查发现，并支持按严重性、类别和精确率-召回率偏好进行有意义的分析。对于构建代码审查代理的团队而言，该基准还应提供可靠的离线信号，准确追踪变更是否可能提升生产环境中的体验。现有基准通常在标签质量、覆盖范围和对真实世界代码审查的代表性之间做出权衡，缺乏一个严格且可复现的评估方法论来整合这些要素。

我们构建了**ReviewBench**，一个新的代码审查离线基准，以弥补这一空白，现在即可供您使用。它遵循GitHub上超过1亿个真实拉取请求的语言分布、仓库规模和规模分布特征。该基准采用多源黄金数据集和一致的评估标准，已由资深工程师独立验证。同样重要的是，借助ReviewBench，我们对Copilot代码审查（CCR）的离线评估在预测生产实验方向方面变得更加有效，使我们更有信心确保所测量的改进确实为用户带来实质性的提升。

在本文中，我们将逐步介绍ReviewBench的构建方式，它如何建立可靠的基准真相和评分体系，以及如何将您的代码审查系统接入并提交结果。

ReviewBench 一览

我们构建了什么

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

103.9M

GitHub 拉取请求

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

代表性基准语料库

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

多源黄金数据集

• 人类审查者
• 前沿大语言模型
• 静态分析

结构化发现

每个发现均标注严重性和类别，支持用户自定义筛选。

#### 严重性

• 关键性
• 中等
• 低级

#### 类别

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

评估指标

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

• 基准精确率
• 基准召回率
• 增强精确率
• 增强召回率

客观评估

客观衡量改进效果并跨代理进行比较。帮助用户选择最符合其需求的审查工具。

我们如何确保其可信性

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

已发布评分标准

所有发现均遵循一个明确的统一标准。

人工标注开发集

高级工程师确定事实真相。

校准评分器

与人类判断保持一致。

统一标注

所有来源均采用相同标准。

已发布一致性

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

端到端可审计

96.6% 一致性

发布前高级工程师独立标注了黄金标准的真正阳性案例。

预测生产的离线信号

基准指标变化会与在线实验进行比对。

• 改进通常会在线上体现
• 回归问题也通常会在线上体现

ReviewBench 的工作原理

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

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

我们分析了 1.039 亿个 GitHub 拉取请求，以表征真实世界代码审查工作量的分布情况。ReviewBench 包含来自 187 个公开开源许可仓库的 219 个拉取请求，涵盖 19 种编程语言，其语言和仓库规模分布与 GitHub 整体高度吻合。完整基准数据集已公开。

我们对这一分布进行了一项有意调整：虽然语言和仓库规模直接反映 GitHub 的分布，但拉取请求数量则向可审查的中位数和长尾部分倾斜。这减少了微小单文件变更的过度代表，同时保留了对审查质量影响最大的实质性多文件拉取请求。

快速语料库概览：

ReviewBench 数据集概览

主要语言

按拉取请求数统计；其他语言总计 51 个

TypeScript

68

Python

41

C#

25

Go

19

JavaScript

15

其他

51

拉取请求变更规模

新增 + 删除行数

≤ 50 行

17

51–200

40

201–500

44

501–1,000

40

1,000

78

主要拉取请求类型

基于标题和描述推断（用于覆盖率分析）；非正式人工标注

功能

79

错误修复

59

文档

15

性能优化

14

重构

12

其他

40

仓库集中度

最大仓库仅占 4.6%；集中度并非主要风险

独立仓库数量 187

单一仓库最多 PR 数 10

每仓库平均 PR 数 1.17

最大仓库占比 4.6%

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代码审查（CCR）进行多轮迭代评估，这为我们提供了一种持续衡量进展、发现回归并优先处理有前景改进的统一方式。随着时间推移，这帮助我们不断改进产品。ReviewBench最宝贵的特性之一是其能提供产品变更在生产环境中可能表现的早期离线信号。在A/B测试前通过ReviewBench评估的实验中，离线变更结果始终与后续生产环境观察到的趋势保持一致。

最近的轻量级实验为这种总体模式提供了具体例证。我们引入了一种多模型集成评审方法，通过将多个独立模型运行结果合并为单一评审（而非依赖单一运行），而非依赖单一运行。ReviewBench预测这种改进将带来更高的精确率、召回率和评论量，同时降低每条评审的成本。

为对比离线结果与生产结果，我们使用对应的在线指标进行验证。解决率（我们对精确率的在线对应指标）是指LLM根据diff、线程、反应、解决状态和审查后代码判断CCR评论促使开发者做出相应代码修改的百分比。对于召回率，我们测量仍需多少额外人工审查。

在线A/B测试结果与ReviewBench预测方向一致：解决率（精确率）提升8.0%，召回率提升13.6%，评论量增加61%，而每条评审成本下降8.0%，所有数据均相对于生产环境对照组。

ReviewBench 的离线收益转化为在线影响

轻量级集成评审与生产单人评审对照

ReviewBench 离线 在线 A/B

+4.45%

+8.00%

+12.88%

+13.58%

+40.0%

+25.0%

-23.7%

-8.00%

-20%0+20%+40%+60%

评论数量本身无法反映评论质量。关键性发现与低严重性细节意味着完全不同的影响。ReviewBench 的严重程度评估也准确反映了这一点：它预测关键性评论将增加 227%，而在线实际增长 262%，同时呈现出相同的趋势——更多中性评论和更少细节性评论。

最大收益来自高严重性发现

按严重程度显示的评论变化与生产对照组对比

ReviewBench 离线 在线 A/B

+227.4%

+262.0%

+121.0%

+18.00%

-15.69%

-45.0%

-50%0+50%+100%+150%+200%+250%

这使我们能在进行生产实验前获得快速且可重复的信号。在线实验仍然是衡量用户影响的最终标准，但 ReviewBench 让我们更有信心判断哪些改进值得推进。

如何提交你的运行结果

1. 使用 GitHub 登录 ReviewBench 网站。
2. 注册你的代理程序。 提供容器镜像、你的配置和专属模型密钥。我们提供评审系统。
3. 在测试集上尝试。 使用包含 25 个 PR 的测试集进行运行，可查看每个 PR 的详细信息，并根据配置调整重复测试。
4. 进行最终运行。 准备就绪后，运行完整的 219 个 Pull Request（三轮测试），由与所有其他参赛者相同的评审系统进行评分。
5. 发布到排行榜。 提交结果在维护者审核批准前将保持私密。只有当成绩优于当前排行榜记录，或这是该代理程序的首次排行榜记录时，成绩才会发布到排行榜。

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

致谢

ReviewBench 是 GitHub 和微软团队合作的成果。我们感谢参与构建它的研究人员和工程师：那些设计方法论、整理 Pull Request、构建黄金数据集和评估流程，并使基准测试成为任何人都能运行的系统的贡献者。

作者

Michelle 专注于开发和评估用于代码评审的智能体 AI 系统，研究方向包括仓库级上下文检索、评审和修复质量，以及对 AI 代码评审器的严格基准测试。

Alejandro 的研究重点包括评估编码智能体、改进其对代码变更和仓库上下文的推理能力，以及优化模型质量、覆盖率、延迟和 token 成本。