AI软件工程领域从不缺少基准测试。想知道一个智能体能否解决真实的GitHub问题?有SWE-bench。想看看它在终端环境中的操作能力如何?Terminal-Bench可以满足需求。

现在,GitHub决定为AI代码评审再添一个标尺。周一,该公司发布了ReviewBench,这是一个与微软合作开发的开放基准测试,用于衡量AI代码评审智能体在拉取请求中发现有用问题的能力水平。而在首批排行榜榜首的——或许并不令人意外——正是GitHub Copilot代码评审。

对代码评审工具的测试

GitHub于2024年10月推出Copilot代码评审功能,次年4月向所有付费Copilot订阅用户全面开放。在随后的几个月里,GitHub将该评审工具迁移至智能体架构,使其能够从代码仓库中获取更广泛的上下文信息,开始按照GitHub Actions分钟数对私有仓库计费,赋予其批准拉取请求的权限,并于9月28日将更为全面的"均衡"评审模式设为默认选项。

代码评审一直是软件开发中至关重要的环节,GitHub在尝试自动化这一流程方面并不孤单。Qodo、Greptile、Cubic、Devin和Cursor都是目前提供AI辅助评审的产品,而CodeRabbit也在其他代码评审排行榜上占据突出位置。

现在,GitHub希望提供另一个通用测试,以比较这些系统的实际表现。

ReviewBench从19种编程语言、187个公开代码仓库中选取了219个公开拉取请求,要求参与竞争的评审工具检查相同的代码变更。GitHub表示,其在分析了1.039亿个拉取请求后选定了这一语料库:该语料库的语言分布和仓库规模分布与GitHub整体情况高度吻合,同时拉取请求的规模分布也刻意避开了仅涉及单一文件的微小变更。

为确定评审工具应当发现的问题,该基准测试从多个来源构建了参考集,包括人工评审意见、作者后续所做的变更、静态分析工具以及大语言模型评审结果。Claude Sonnet 5负责对发现的问题进行分类,而另一个独立的大语言模型匹配器则判断候选发现结果是否对应参考集中同一潜在问题。方法论说明中提到,最初被归类为真阳性的47项发现结果经过人工修正,而在判断发现结果为真阳性还是假阳性方面,人工判断与分类器判断的一致率达到96.6%。

在"均衡"配置下进行测试的Copilot代码评审,以40.1%的"有依据F1分数"(综合衡量精确率和召回率与基准已知发现结果的匹配程度)登上排行榜榜首。

不过,这一结果也附带了一些值得注意的重要说明。GitHub表示,其团队通过运行各产品公开可用版本自行生成了初始测试结果——相关厂商既未参与测试执行,也未对结果进行验证。而且由于各产品的测试日期不同,部分结果与其他结果相比明显滞后:Copilot的测试时间为10月1日,而Cubic和Greptile的测试则早在6月进行。ReviewBench特别提醒,这些产品自测试以来可能已发生变化,且在该语料库上的表现未必能够反映在企业自身代码上的实际效果。

一个由厂商自行发布、且该厂商自身产品又名列榜首的基准测试,这些说明尤其值得关注。不过,GitHub确实公开了数据集、方法论和评判设置,并允许厂商提交自己的测试结果。

"我们一直在使用ReviewBench来改进GitHub Copilot代码评审功能,其离线测试结果一直与后续生产环境实验的方向保持一致。"

GitHub还以自身的产品开发实践为证据,证明ReviewBench的价值不仅限于排行榜指标。GitHub高级应用工程师亚历杭德罗·卡尔德雷拉·德迭戈周一在LinkedIn上发文表示,该基准测试已证明其作为早期信号的价值,有助于预判Copilot代码评审功能的改动在生产环境测试中的表现。

他写道:"我们一直在使用ReviewBench来改进GitHub Copilot代码评审功能,其离线测试结果一直与后续生产环境实验的方向保持一致。"

换一个基准测试,结果大不相同

卡尔德雷拉·德迭戈与微软应用科学家米歇尔·周在周一发布的一篇博文中指出,现有方法往往需要在衡量内容和结果与真实评审场景的贴近程度之间作出妥协。

他们写道:"现有基准测试常常需要在标签质量、覆盖范围以及对真实代码评审场景的代表性之间做出权衡取舍,这就留下了一个空白——需要一种严谨且可复现的评估方法,将这些要素整合在一起。"

"现有基准测试常常需要在标签质量、覆盖范围以及对真实代码评审场景的代表性之间做出权衡取舍。"

此前已有类似尝试,来自AI研究公司Martian,该公司于2月推出了其代码评审基准测试(Code Review Bench)。该测试将离线测试与基于开发者对真实开源代码库中评审意见反馈情况的在线追踪相结合。该测试发布之初,Martian表示其离线测试结果与实际使用中观察到的情况存在差异,因此将在线基准测试作为其核心指标。

截至10月6日,Martian的在线排行榜显示Cubic以64.9%的F1分数位居第一,Greptile和CodeRabbit紧随其后,而GitHub Copilot以60.9%的分数排名第四。F1是一种标准指标,将精确率和召回率综合为单一分数,且对两者赋予同等权重。

而在Martian的离线排行榜上,情况则有所不同。Qodo Deep排名第一,Cubic和Augment紧随其后,而GitHub Copilot以58%的F2分数排名第五。F2是同一指标的变体,更强调召回率而非精确率——换言之,该指标更注重奖励那些能够发现更大比例相关问题的系统。

这些分数仍无法与ReviewBench直接比较。尽管ReviewBench在默认排名中也采用了类似F1的衡量方式,但它基于不同的数据集和评分方法,而Martian的在线和离线测试则衡量的是不同类型的证据。

不过,这些不同结果恰好说明了基准测试设计对于判定哪些工具表现最佳具有多大的影响力。

Martian还将独立性作为其代码评审基准测试的核心卖点之一。该公司在2月的发布文章中指出,维持一个具有可信度的基准测试需要投入大量资金和精力,尤其是在被测试工具和用于评判的证据都在不断变化的情况下。该公司表示,这种情况历来促使基准测试的开发倾向于由学术界或厂商自身主导。

该公司作者当时写道:"我们正在尝试第三种选择:由一个不训练模型、不销售编码工具、且在哪款工具胜出上没有利益关系的、资金充足的研究实验室来主导。"

"我们正在尝试第三种选择:由一个不训练模型、不销售编码工具、且在哪款工具胜出上没有利益关系的、资金充足的研究实验室来主导。"

该基准测试及其方法论以MIT许可证开源,Martian还邀请工具开发者、模型制造商和研究人员审阅并为该项目做出贡献。

另外值得一提的是,早在7月,LangChain就发布了自己的AI代码评审基准测试,同样命名为ReviewBench。该版本规模较小,更侧重于模型评估,基于从LangChain的LangSmith代码库中提取的59个任务构建而成,与GitHub或Martian的版本不同,它并未附带公开的厂商排行榜。LangChain在相同的Deep Agents配置下测试了不同的模型,因此它实际上测试的是模型在统一智能体配置下的表现,而非对商业代码评审产品进行排名。

综上所述,GitHub的ReviewBench随着时间推移,仍有空间变得更具代表性。厂商可以通过自助服务系统提交自己的测试结果,新结果经评分后将被添加到排行榜中——当然,厂商也会自行选择提交哪些配置的结果。是否会有足够多的厂商这样做,从而将当前这份由GitHub自行生成的"快照"转变为一个更广泛的、经厂商测试验证的排行榜,这将是更值得关注的后续考验。

The New Stack