GitHub 推出了开放的 ReviewBench 基准，用于评估代码审查代理，试图解决 AI 驱动的审查工具面临的一项核心问题：难以比较它们发现了哪些错误、遗漏了哪些错误，以及产生了多少噪声。该基准面向研究人员和开发代码审查系统的团队开放，也支持提交自定义系统并将其与其他系统进行比较。
基于真实拉取请求的基准
GitHub 通过分析平台上超过 1.039 亿个拉取请求的分布，设计了 ReviewBench 数据集。该数据集包含来自 187 个获得开源许可的公共仓库的 219 个拉取请求，覆盖 19 种编程语言，并使语言和仓库规模的分布与 GitHub 的总体模式保持一致。不过，数据集对变更规模进行了重新加权，倾向于中型和大型且适合审查的请求，而不是过度集中于单文件的小规模变更。
GitHub 所称的“真值集”并不依赖单一来源。潜在结果来自人工审查者、请求作者随后进行的修改、静态分析工具以及多个先进语言模型。在删除语义上重叠的结果后，研究人员依据统一标准对其进行评估：正确结果必须准确、相关且非无关紧要。GitHub 使用 Claude Sonnet 5 作为语言评估器，并发布评估 rubric 和设置，以提升可审计性和可复现性。
不会惩罚新错误发现的指标
ReviewBench 区分两组指标。grounded precision、grounded recall 和 grounded F1 衡量系统发现真值集中既有问题的能力，从而为系统之间提供直接比较。augmented precision、augmented recall 和 augmented F1 则还会检查与任何已知问题都不匹配的结果；如果评估器证明该结果确实是一个问题，系统也会获得相应分数。
这种区分很重要，因为固定的错误集合不一定完整；新的代理可能发现基准制定者未发现的问题。GitHub 使用 grounded recall 作为系统间比较的主要指标，同时提供扩展指标作为每个系统的补充诊断信息。
可调节且可审计的评估
结果可以按照问题严重程度和类别进行细分，例如正确性、安全性、可靠性、可维护性和测试。Fβ 指标还允许调整召回率与精确率之间的权重，使用户能够选择更广泛的覆盖范围，或更少但更准确的评论。在发布前，未参与数据构建的高级工程师对所有结果重新进行了标注，ReviewBench 与其判断的一致率达到 96.6%。GitHub 表示，它会固定每次评估所使用的数据、评估器和匹配工具的版本。
实际证明了什么？
GitHub 使用 ReviewBench 评估 Copilot Code Review 的连续版本，并表示离线测试中出现的改进或退步趋势与生产环境测试一致。在一次针对结合多个不同模型运行结果的审查系统的实验中，该基准预测精确率、召回率和评论数量会上升，同时审查成本会下降。生产环境中的 A/B 测试也呈现出相同方向：与对照组相比，促使代码发生修改的评论比例上升了 8.0%，召回率上升了 13.6%，评论量上升了 61%，而每次审查的成本下降了 8.0%。此外，该基准预测关键评论数量将增加 227%，生产环境中的实际增幅则为 262%。
certi.news 的编辑解读是：ReviewBench 最重要的价值并不是推出一个新工具，而是试图将代码审查代理的评估转变为可比较、可审计的流程，同时承认“更多评论”并不一定意味着更好的审查。不过，该来源本身也承认，生产环境测试仍然是衡量用户影响的最终标准；此外，评估的一部分依赖语言评估器，也留下了关于自动化判断一致性边界的开放问题。
GitHub 提供了该基准的初步研究版本，包括数据、方法、评估器设置以及自托管运行工具。用户可以先在 25 个拉取请求组成的集合上测试代理，然后在请求将结果发布到排行榜之前，通过三轮运行对 219 个拉取请求执行完整评估。