GitHub发布ReviewBench：基于 1.039 亿次拉取请求的AI代码审查开放基准
GitHub官方博客宣布推出ReviewBench，一个面向AI代码审查代理的离线基准，语料取自 219 个公开拉取请求、覆盖 19 种语言，并称其离线评估结果与Copilot代码审查（CCR）的生产A/B实验方向一致。
AI解读：ReviewBench要解决的具体问题是：团队在选用代码审查代理时，缺少一个能同时反映真实拉取请求多样性、覆盖多类审查发现、并可按严重级别和类别切片比较的离线评测方法。GitHub称现有基准在标签质量、覆盖面和真实代表性之间存在取舍。
基准语料基于 1.039 亿个GitHub拉取请求的分布设计，但正式评测集只有 219 个拉取请求，来自 187 个公开开源许可仓库、19 种语言。GitHub对分布做了一处调整：语言和仓库规模贴合GitHub整体，拉取请求规模权重向“可审查的中段和尾部”倾斜，以减少单文件小改动、保留多文件实质性改动。
真值发现采用多来源流程：收集人类审查者发现、作者后续提交中推断的问题、确定性分析工具以及多个前沿大模型的结果，做语义去重，再用统一评分标准判定。GitHub称使用Claude Sonnet 5作为LLM评分器，并公开评分标准和所用评审模型。
评分分两组共六项：Grounded的精确率、召回率和F1只用已有金标标签；Augmented的对应三项还会评估未匹配金标的结果，由评审模型独立判定其真伪。GitHub表示跨系统比较以grounded recall为主指标，augmented指标作为单系统诊断。
GitHub称发布前由未参与基准构建的资深工程师独立重新标注全部真值发现，与ReviewBench判定的一致率为 96.6%，并公开发布验证方法和已知有效性威胁。
GitHub称曾用ReviewBench评测Copilot代码审查的多轮迭代。文中举出一个lite层实验：多模型集成审查使被处理率（精确率的线上对应指标）上升 8.0%、召回率上升 13.6%、评论量上升 61%、每次审查成本下降 8.0%；严重级别方面，离线预测严重评论增加 227%，线上为 262%。GitHub称这些线上数据来自A/B测试，并强调线上实验仍是用户影响的最终衡量。
GitHub官方博客发布ReviewBench，一个用于评测AI代码审查代理的开放离线基准，研究预览版已在ReviewBench网站上线。文章作者为Michelle Zhou。
基准基于GitHub上 1.039 亿个拉取请求的分布设计，评测语料包含 219 个公开拉取请求，来自 187 个公开开源许可仓库，覆盖 19 种语言。GitHub表示语言和仓库规模分布贴合GitHub整体，但将拉取请求规模权重向“可审查的中段和尾部”倾斜，以减少单文件小改动的占比。
语料与真值如何构建
GitHub称，没有单一评审者（无论人或模型）能找出一份拉取请求中所有值得发现的问题，因此真值集合采用三阶段流程：先从真实人类审查者、作者后续提交中推断的问题、确定性分析工具和多个前沿大模型收集候选发现；再做语义去重，合并指向同一底层问题的发现，避免多来源一致抬高金标或依赖单一来源的盲区；最后由统一评分标准判定，一个发现只有同时满足真实、相关、非琐碎才算真阳性。
GitHub表示使用Claude Sonnet 5作为LLM评分器，对所有提交应用一致的评分标准，并公开评分标准和评审模型以支持复现。发布前，未参与数据集构建的资深工程师独立重新标注了全部真值发现，与ReviewBench的判定一致率为 96.6%。GitHub还称对数据集、评审模型和匹配器进行版本管理，并公开验证方法和已知有效性威胁。
- 评测集：219 个拉取请求，187 个仓库，19 种语言
- 设计参考：103.9 百万个GitHub拉取请求的分布
- 评分器：Claude Sonnet 5，评分标准公开
- 独立一致性：资深工程师重新标注，96.6% 一致
评分指标与适用条件
ReviewBench报告六项指标，分两组。Grounded精确率、召回率和F1只使用已有金标标签，用于严格同口径比较：在已知问题中代理找到了多少，其发现中又有多少匹配已知问题。Augmented精确率、召回率和F1还会评估未匹配金标的结果，由评审模型独立判断真伪，使代理可能因指出金标中无人提出的有效问题而获得认可。
GitHub称，随着审查代理能力增强，固定金标难免不完整，augmented指标用于识别这类行为而不是直接惩罚；但augmented recall的分母会随各代理发现的问题扩大，因此跨系统比较以grounded recall为主，augmented指标作为单系统诊断。
结果可按严重级别（Critical、Medium、Low）和类别（Correctness、Security、Reliability、Maintainability、Testing等）切片，用户还能调整Fβ 分数中的 β 以偏向召回或精确率。GitHub表示这些偏好变化会导致排行榜重新排序。
- Grounded precision / recall / F1：仅基于已有金标标签
- Augmented precision / recall / F1：额外评估未匹配金标的发现
- 可切片维度：严重级别、类别、精确率-召回率偏好
- 跨系统主指标：grounded recall
评测Copilot代码审查的一次对照
GitHub称已用ReviewBench评测Copilot代码审查（CCR）的连续迭代，并称在A/B测试前用ReviewBench评估的变更，其离线变化方向与之后在生产中观察到的一致。
文中给出一个lite层实验：引入多模型集成审查，将多个独立模型运行合并为一次审查，而非依赖单次运行。ReviewBench预测精确率、召回率和评论量上升，同时每次审查成本下降。GitHub称对应线上A/B测试同向移动：被处理率（精确率的线上对应指标）上升 8.0%，召回率上升 13.6%，评论量上升 61%，每次审查成本下降 8.0%。
严重级别方面，GitHub称ReviewBench预测严重评论增加 227%，线上为 262%，并同时出现向中等评论增加、轻微问题减少的转变。GitHub强调线上实验仍是用户影响的最终衡量，ReviewBench提供的是运行生产实验之前的快速可重复信号。
- 线上被处理率（IEEE）：+8.0%（相对生产对照）
- 线上召回率：+13.6%
- 线上评论量：+61%
- 线上每次审查成本：-8.0%
- 严重评论：离线预测 +227%，线上 +262%
如何提交自己的代理
GitHub说明提交步骤：用GitHub账号在ReviewBench网站登录，注册代理并提供容器镜像、配置和自己的模型密钥，评审模型由官方提供；先在 25 个拉取请求的测试集上运行并查看逐条详情，反复调整配置；准备好后对全部 219 个拉取请求运行三轮，由与其他条目相同的评审模型评分。
GitHub称分数在维护者审核批准前保持私有，只有超过该代理当前排行榜分数或为首次上榜时才会发布到排行榜。完整数据集、评测方法、LLM评审提示词、评审模型配置和自助运行器均公开。
- 测试集：25 个拉取请求，含逐条详情
- 正式运行：219 个拉取请求，三轮
- 排行榜发布条件：超过该代理当前分数，或首次上榜
- 公开内容：完整数据集、评测方法、评审提示词、评审模型配置、自助运行器