论文地址：arXiv:2509.01494
关键词：SWR-Bench, PR-Centric, Multi-Review Aggregation, False Positive
为什么又做一个 Benchmark？
作者指出目前的 ACR（自动化代码审查）基准主要是为 Deep Learning 时代设计的，存在三个致命伤：
- Context Poverty（上下文匮乏）：只给 Diff，不给整个仓库。
- Fine-grained Units（粒度太细）：只评测单个函数或 Diff 块，而真实的 Review 是针对整个 Pull Request (PR) 的。
- Metrics（指标烂）：BLEU 测不出逻辑错误；主观打分容易有偏差。
为了解决这些问题，他们构建了 SWR-Bench（Software Review Benchmark），包含 1000 个手动验证的 PR。
数据集构建
这篇论文在构建 Ground Truth 时非常讲究：
- SZZ 算法：
- 作者指出，通常我们把“Reviewer 提出的意见”当作真理。但人类 Reviewer 也会漏看 Bug。
- 作者利用 SZZ 算法（一种在软件工程中追踪 Bug 引入 Commit 的算法）去查该 PR 合并后，未来是否又因为修 Bug 改了这些代码。如果是，说明当初 Review 没看出来，这部分也算作 Ground Truth。这极大提高了数据的质量。
- 50:50 Clean-PR ：
- Change-PR (500个)：有问题的代码。
- Clean-PR (500个)：完全没问题的代码。
- 专门测试 LLM 的 False Positive Rate（误报率）。现在的模型太喜欢没事找事了，如果 Benchmark 里全是错代码，就测不出模型乱报错的毛病。
评估方法
Objective LLM-based Evaluation：
- 让 LLM 判断“模型生成的评论”是否覆盖（Hit）了“Ground Truth 中的修改点。
- 这是 Recall（召回率） + Precision（精确率） 计算，与之前的生成质量打分不同。
- 论文结论这种方法与人类专家判断的一致性高达 90% 左右。
Multi-Review Aggregation (多轮聚合)
这是论文提出的一个提升模型效果的简单策略。
原理：
一致，LLM 的输出有随机性，且容易产生幻觉。既然如此，就“三个臭皮匠顶个诸葛亮”。
操作步骤：
- Generate：让同一个 LLM 对同一个 PR 跑 N 次，或，用不同的 LLM 跑。
- Aggregate：把这 N 份报告扔给 LLM，让它做“合并同类项”。
- 过滤：如果一个问题只出现了一次，可能是幻觉，丢掉。
- 如果一个问题在多次 Review 中都出现了，说明是真问题的概率很大，保留。
论文结论：
简单的 Self-Aggregation (n=10) 就能让 Gemini-2.5-Flash 的表现大幅提升，甚至超过单次运行的更强模型。
实验中的有趣发现
- Agent 输给了 Prompt Engineering！！！
- 实验对比了复杂的 Agent（如 SWR-Agent，模仿 SWE-Agent）和简单的精心设计的 Prompt（PR-Review）。
- 结果 PR-Review (Prompt) 赢了。这说明目前的 Agent 架构在代码审查这种需要全局理解的任务上，可能还不如把 Prompt 写好（比如 PR-Review 工具会对 Diff 进行重组和排序）来得有效。
- Reasoning 模型更强：
- 带有推理能力的模型（如 Qwen-2.5-R1, Gemini Pro）比普通模型 F1 分数更高。
- 误报是最大瓶颈：
- 即使是最好的模型组合，Precision 也很低（低于 20%）。说明模型虽然能找出 Bug，但也会伴随大量的垃圾建议。
总结与启发……
- 做数据集，一定要放“负样本”，否则无法评估模型的抗干扰能力。SZZ 算法挖掘 Ground Truth 也是个很好的思路。
- 不要只跑一次 LLM。跑多次 + 聚合投票。
0 条评论