AREXOpen in interactive Feed

AREX Feed Article

GitHub 发布开放基准 ReviewBench:219 个真实 PR、19 种语言,给 AI 代码审查打分

October 5, 2026

GitHub 于 10 月 5 日在宣布,用于评估 AI 代码审查智能体(AI code-review agents)的开放基准 ReviewBench 上线,研究预览版当天即可通过 使用。这套基准的“考卷”取自真实开发场景:219 个公开 pull request(PR,代码合并请求),来自 187 个带开源许可证的仓库、覆盖 19 种语言,语言与仓库规模分布与 GitHub 全站分布对齐。

为了让“标准答案”不止出自单一来源,ReviewBench 的 golden set(金标准问题集)由人类审查者、多个前沿 LLM(大语言模型)与静态分析工具共同产出,每条发现(finding,审查中报出的一个具体问题)按严重程度和类别标注;发布前,未参与构建数据集的资深工程师逐条独立复标,与基准判断的一致率为 96.6%。以上均为 GitHub 博客的自述口径。

考卷按全站 PR 分布抽取,而不是演示集

GitHub 团队先分析了 1.039 亿个 GitHub pull request,用来刻画真实代码审查工作负载的分布,再据此选出 219 个 PR,其语言与仓库规模分布与 GitHub 全站总体接近。完整基准数据集公开,参与者可以逐条查看各系统到底在哪些题上被评测,并复现结果。

分布上只做了一处刻意调整:语言和仓库规模照搬 GitHub 全站,PR 体量则向“可审查的中段和尾部”加权,减少单文件小改动的占比,保留多文件、更有实质内容的 PR。博客称,这正是审查质量最要紧的地方。

人、模型、静态分析一起出题,一把尺子判卷

Golden set 的构建分三步。第一步广纳候选:发现来自真实人类审查者、从作者后续提交(follow-up commits)推断出的问题、确定性分析工具(即静态分析),以及跨模型家族的多个前沿 LLM。第二步语义去重:把指向同一底层问题的发现合并,避免多个来源“撞车”虚增答案数量,也不让答案集依赖任何单一来源的盲区。第三步统一判卷:一条发现算不算真阳性,只取决于它是否真实、相关且非平凡,与它出自谁无关。GitHub 用 Claude Sonnet 5 担任 LLM 判分模型,并公开评测量表(rubric)和判分模型配置。

每条 golden 发现都标注严重程度(critical、medium、low 三档)和类别(correctness、security、reliability、maintainability、testing 等),评测结果可以按这两个维度切片查看。

两族指标:已知的问题要找到,没见过的问题也给记分

多数基准只对着固定答案算 precision(查准率:报出的问题里多少是真问题)和 recall(查全率:已知问题里找到了多少)。ReviewBench 的成绩分两族共六项:grounded 一族只使用 golden set 内的标签,给出严格的同卷同尺比较;augmented 一族把没有匹配到任何已知问题的发现也交给判分模型独立判定真假,让审查者能因为“找到了答案集里没有的真问题”而得分,两族各自配套 F1 分数(平衡查准率与查全率的单一分数)。

博客解释,随着审查智能体变强,固定答案集不可避免会落后于系统能发现的问题,augmented 指标就是为了承认这类行为而不是惩罚它。但由于 augmented recall 的分母随每个系统自己的发现扩张,跨系统排名以 grounded recall 为准,augmented 只作单系统诊断。用户还可以调整 Fβ 中的 β,在查准(少噪音)与查全(广覆盖)之间表达偏好,榜单随之重新排序。

发布前的独立复标与版本化

博客将这套流程归入“内部审计”:发布前,GitHub 请来未参与构建数据集的资深工程师,把每条 ground-truth 发现从零重新标注一遍,其真/假阳性判断与 ReviewBench 的既有标注一致率达到 96.6%。基准数据集、判分模型和匹配器都做了版本化,同一配置下的成绩可以互比,基准变更后可重新验证;验证方法、一致性测量和已知的效度威胁(known threats to validity)均已公开。

GitHub 先拿自家产品跑了一遍:离线分数对上线上实验

据博客自述,GitHub 用 ReviewBench 在多轮迭代中评测自家的 。文中给出的例子是一个 lite 档实验:把多个独立模型运行合并成一份多模型集成审查。ReviewBench 离线预测其查准率、查全率、评论量上升,单次审查成本下降;随后的线上 A/B 测试方向一致——相对于生产对照组,addressed rate(CCR 评论促使开发者实际改码的比例,按 diff、讨论线程、表情回应、解决状态和审查后代码由 LLM 判定,作为线上查准率的对应物)上升 8.0%,recall 上升 13.6%,评论量上升 61%,单次审查成本下降 8.0%。严重程度维度上,ReviewBench 预测 critical 级评论增长 227%,线上实测为 262%。

博客同时写明边界:线上实验仍然是用户影响的最终衡量标准,ReviewBench 提供的是进入生产实验之前快速、可重复的方向性信号。

上榜规则写明:分数私密,审核通过才公开

想提交自己的系统,需要用 GitHub 账号登录 review-bench.ai,注册智能体并提供容器镜像、配置和自己的模型密钥,判分模型由 GitHub 提供。提交者可以先在一个 25 个 PR 的测试集上反复调试,拿到逐 PR 的细节;正式跑分要完整跑完 219 个 PR、共 3 轮,用与其他条目相同的判分模型。成绩在维护者审核批准前保持私密,只有优于该智能体现有榜单成绩或属其首次上榜时才会发布。

截至 2026 年 10 月 6 日查询其,榜单共有 28 个条目,快照日期从 2026 年 6 月 16 日延续到 10 月 1 日。排在第一的是 GitHub 自己的 Copilot Code Review(Balanced 配置),grounded precision 87.8%、grounded recall 26.0%;Devin AI、Qodo 分列第二、第三,其后是多档配置的 Codex、Cubic、Greptile、Cursor,以及排名第 7 的 Copilot Code Review Lite。博客致谢部分说明,ReviewBench 由 GitHub 与 Microsoft 的团队协作建成;博客在结尾邀请研究者与从业者“挑战我们的假设,帮助我们改进基准”。

参考链接