代理式代码审查已成为开发过程中不可或缺的一部分。它有助于你检查拉取请求、发现问题，并在代码发布前确定哪些需要关注。
但现有 AI 审查员的质量很难衡量，在确认它们是否能提供帮助之前，你需要了解审查员的优势。有些审查员会暴露更多问题，有些则产生的干扰较少，还有一些在发现关键问题方面更出色，而另一些则能提出较小的改进。在你的工作流程中，你可能需要代码审查来完成不同的任务。
这使得理解评审人员实际的比较方式非常重要：不同的系统能发现什么，遗漏了什么，以及他们做出的权衡。一个好的代码审查基准应该能够反映真实 pull requests的多样性，涵盖广泛的评审发现，并支持按严重程度、类别和精确性-召回率偏好进行的有意义的分析。 对于构建代码审查代理的团队来说，基准测试还应提供离线信号，以可靠地判断修改是否可能提升生产环境中的体验。现有的基准测试通常会在标签质量、覆盖率以及它们对实际代码审查的反映程度之间做出权衡，从而留下一个空白，需要一种严格且可复现的评估方法来整合这些要素。
我们构建了 ReviewBench，一个新的离线代码审查基准测试，以填补这一空白，现在你可以直接使用它。该工具依据了 GitHub 上超过1亿个真实 pull requests的语言、仓库规模及数据分布模式进行设计。它采用多源黄金数据集以及统一的评估标准，并得到了高级工程师的独立验证。同样重要的是，借助 ReviewBench，我们对 Copilot代码审查的离线评估能力更加有效，能够更精准地预测生产实验的方向，从而让我们更有信心认为所测量的改进确实对用户有实际意义。
在本文中，我们将介绍 ReviewBench 的构建方式、其如何建立可靠的真实数据和评分机制，以及如何将您自己的代码审查系统接入并提交结果。
我们构建了什么
一个真实、全面的 AI 代码审查代理基准测试
103.9MGitHub 拉取请求
按语言、存储库大小和变更形态分析分布情况。
代表性基准语料库
219个跨19种语言的公共pull请求，与GitHub全局分发计划保持一致，同时保留了重要的审查案例。
多来源黄金套装
- 人类审核员
- 边境 LLM 模型
- 静态分析
结构化发现
每个发现都标有严重性和类别标签，从而支持用户自定义的视图。
严重度
- 关键
- 中等
- 低
类别
- 正确性
- 安全
- 可靠性
- 可维护性
- 测试
- ......
评估指标
四个指标用于衡量已知和新发现的问题。
- 基于基础的精确性
- 基于记忆的回忆
- 增强精度
- 增强式回忆
客观评估
客观地衡量改进情况，并对比不同代理。帮助用户选择最符合其需求的评审员。
我们如何确保其可信性
可审计的链条：从评分标准到专家验证以及生产检查
发布评分标准
所有发现都需遵循一个明确的标准。
人类标注的开发数据集
高级工程师确定基准事实。
校准过的评分器
与人类的判断一致。
统一标签标注
所有来源都遵循相同的标准。
发布协议
基准质量专业审计。
可审计的端到端
96.6% 的同意率
高级工程师在发布前独立标注了金色真阳性结果。
离线信号预示着生产即将开始
基准测试移动性通过在线实验进行验证。
- 改进效果通常会在网上显现出来
- 回归现象也常出现在网上
ReviewBench 如何工作
我们的基准测试基于五项原则：
1. 代表性 Pull Request，而非演示样本
我们分析了 1.039 亿个 GitHub pull request，以了解代码审查工作量的实际分布情况。ReviewBench 包含来自 187 个公开开源许可仓库的 219 个 pull request，这些仓库使用 19 种语言，其语言与仓库规模的分布与 GitHub 整体情况非常相似。完整的基准测试数据集可公开获取。
我们对这种分配方式进行了一次有意的调整：虽然语言类型和仓库大小与 GitHub 完全对应，但拉取请求的大小则更侧重那些需要审查的中等及长文件。这样就能减少小型、单文件更改的过度出现，同时保留那些涉及多文件且审查质量至关重要的实质性拉取请求。
快速语料库快照：
2. 广泛的真实情况探索，独立判断
没有一位评审员，无论是人类还是模型，能够指出所有值得在 Pull Request 中查找的内容。为了构建更广泛且更可靠的“黄金集合”以作为真实数据的基础，我们采用三阶段流程：
- 从多种来源收集候选者的发现结果。我们收集了来自真实人类评审员的发现、从作者后续提交中推断出的问题、确定性分析工具，以及不同模型家族中的多种前沿 LLM 的成果。
- 语义上消除重叠的研究结果。 我们将识别相同根本问题的研究结果合并在一起，从而扩大研究范围，避免不同研究者之间的共识导致“黄金集合”被人为放大，也避免该集合依赖于某一来源的缺陷。
- 在统一的评估标准下验证结果。 一个结果的来源并不能决定其是否正确：只有当该结果真实、相关且非简单时，才视为真正的阳性结果。我们使用 Claude Sonnet 5 作为 LLM 评分器，对所有提交内容应用统一的评估标准。为了增强透明度和可重复性，我们会同时发布评估标准以及用于评估的评分员信息。
3. 能够衡量已知及新发现问题的指标
大多数基准测试都针对固定的黄金数据集来报告精确度和召回率。ReviewBench则报告了两个类别中的六种指标：
- 基于的精确性、召回率和 F1 分数仅使用现有的黄金标签。它们能够进行严格的、类似比较：对于我们已知的问题，智能体发现了多少，其发现中有多少与已知问题相符？
- 增强的精确度、召回率和 F1 分数也用于评估那些与黄金集合中的任何内容都不匹配的结果。评委独立判断这些不匹配结果属于真阳性还是假阳性，从而让审核人员能够因有效的问题获得认可，而黄金集合中的制作人并未提及这些问题。
随着评估代理的能力提升，这种区分变得更加重要。由于系统发现了创建者没有预料到的问题，固定的黄金标准必然变得不完整。增强型指标使 ReviewBench 能够识别这种行为，而不是自动对其进行惩罚。因为增强型回忆根据每个代理发现的内容扩大了分母，我们采用基于真实回忆的跨系统对比作为主要指标，并将增强型指标作为额外的系统级诊断工具。
4. 可配置的评估功能，满足不同的审核偏好
没有一种能够适用于所有人的最佳审查体验。有些开发者可能只希望关注关键问题，而另一些开发者则重视较轻微且不影响功能的发现。有些人更希望获得更广泛的覆盖，而另一些人则注重精确性并减少噪音。还有一些人可能有特定的需求，比如以安全或隐私为重点的审查。
ReviewBench 允许根据严重性和类别来划分结果，而精确度和召回率则反映了不同的使用偏好。用户还可以调整 Fβ 分数中的 β 值，以在更广泛的覆盖度方面重视召回率，或在较低的噪声水平方面重视精确度。随着这些偏好的变化，排行榜也会相应重新排序，从而帮助用户找到最符合其评审优先级的系统。
5. 内部审计且可复现评估
在发布之前，我们请那些没有参与构建基准数据集的高级工程师自行重新标记每一个真实结果，从零开始。他们的真/假阳性判断有 96.6% 的时间与 ReviewBench 的结果一致。我们为基准数据集、评估方法和匹配器建立版本号，这样在相同的基准配置下即可比较结果，并在基准发生变化时再次验证。 我们还发布了验证方法、一致性测量指标以及对有效性有影响的已知威胁，以便读者能够了解基准质量是如何评估的，以及存在哪些不确定性。
探索 ReviewBench
ReviewBench 的研究预览版本现已通过 ReviewBench 网站 提供，你可以在该网站上查看完整的基准测试、比较代码审查代理，并使用自己的代理进行评估与迭代。
使用 ReviewBench，您可以：
- 探索完整的基准测试数据集。 完整的 ReviewBench 数据集可公开获取，包含拉取请求、发现结果、标签、严重程度及类别注释等内容。这样你可以准确了解哪些系统被评估，并复现基准测试结果。
- 在排行榜上对比系统。使用完整基准数据对代码审查工具进行评估的结果会发布在统一的排行榜上，该排行榜显示整体性能、严重程度、类别以及不同的精确率-召回率偏好情况。
- 携带您自己的代理工具进行挑战。 完整的基准测试数据集、评估方法、LLM评判提示、评判模型配置以及自助运行工具均公开可用，因此您可以评估自己的代码审查代理，分析其优缺点，并针对相同的基准配置进行优化。
我们是如何使用 ReviewBench 的
我们使用 ReviewBench 对连续迭代中的 Copilot 代码审查 (CCR) 进行评估，从而提供了一种统一的方式来衡量进展、发现问题，并确定有潜力的改进措施。随着时间的推移，这帮助我们提升了产品质量。ReviewBench 最宝贵的优势之一是，它能够提前提供关于产品变更在生产环境中表现情况的信号。在通过 ReviewBench 进行的 A/B 测试实验中，离线测试的结果始终与生产环境中的实际结果一致。
最近的一项简化级别实验为这一普遍模式提供了具体示例。我们采用了一种多模型集成评估方法，将多个独立模型运行结果整合为一次评估，而非依赖单一模型运行。ReviewBench 显示，该方法的精确率、召回率和评论数量更高，且每次评估的成本更低。
为了比较离线和生产环境中的结果，我们使用相应的在线信号。解决率作为精确度的在线对应指标，是指基于差异、讨论线程、反馈、解决状态以及审核后的代码，LLM 判断出开发者需要做出相应代码更改的 CCR 评论所占比例。至于回顾程度，则衡量还需要多少额外的人工审核。
在线 A/B 测试的结果与 ReviewBench 的预测一致：处理率（精确性）提升了 8.0%，召回率提升了 13.6%，评论量提升了 61%，而每条评论的成本则降低了 8.0%，所有数据均相对于生产控制部分而言。
然而，评论数量本身并不能反映评论的质量。更重要的发现与低严重性问题相比有着截然不同的意义。ReviewBench的严重性等级评估也揭示了这一点：与在线数据中262%的较高严重性情况相比，关键评论的比例增加了227%，同时更多的中等严重性评论和更少的低严重性问题也出现了类似的趋势。
这让我们在开展生产性实验之前获得一个快速且可重复的信号。在线实验仍是衡量用户影响的关键指标，但 ReviewBench 让我们对哪些修改值得进行这些实验更有信心。
如何提交您自己的运行
- 使用 GitHub 登录 上 ReviewBench 网站。
- 注册您的代理。 提供容器图像、配置以及您的模型密钥。我们负责处理评判工作。
- 在测试集上尝试它。 使用包含每 P-R 细节的 25-PR 测试集进行运行，并在调整配置过程中重复此过程。
- 进行最后一次运行。 当您准备好后，请运行全部 219 个 Pull Request，共进行三轮，这些请求由与其它项目相同的评审员评分。
- 发布到排行榜上。 您的分数在维护人员审核并批准之前均为私密状态。只有当分数高于智能体当前的排行榜分数，或者这是该智能体的首次参与排行榜时，分数才会被发布到排行榜上。
我们邀请您探索 ReviewBench，评估您自己的系统，挑战我们的假设，并帮助我们改进基准测试。我们很高兴与研究人员和从业者合作，让代码审查评估更加开放、可靠且有用——最终有助于推动 AI 代码审查的发展。
致谢
ReviewBench 是 GitHub 和 Microsoft 共同协作的成果。我们感谢那些构建该工具的研究人员和工程师：他们设计了方法论，审核了 Pull Request，建立了基准测试集与评估流程，使得任何人都能运行该基准测试。
该文章 ReviewBench：一个用于 AI 代码审查的开放基准测试 首先出现在 GitHub 博客 上。