Bigger Isn't Always Better: A Comparative Evaluation of LLMs for Automated Code Review
本文表明，规模更小、更具成本效益的 Claude Haiku 4.5 在自动化代码审查方面优于规模更大的 Claude Sonnet 4.6，同时也揭示了合成基准测试显著高估了模型能力，且性能会随着差异（diff）尺寸的增大以及性能相关缺陷的出现而急剧下降。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你是某家规模巨大、混乱不堪的报社的总编辑。每天，数百名记者（开发人员）都会提交修改后的稿件（代码）。你的职责是在报纸付印之前，发现其中的错别字、逻辑错误和安全漏洞。
过去，你认为完成这项工作的唯一方法是雇佣最昂贵、受教育程度最高且“大脑最大”的编辑。你假设更大的大脑意味着能发现更多的错误。
这份报告书告诉我们：“事实并非如此。而且我们一直用来招聘编辑的测试方法完全是错误的。”
以下是研究人员发现的内容，使用了简单的类比进行说明：
1. “大容量大脑”的迷思
研究人员测试了五种不同的“AI 编辑”（大语言模型）。其中两个来自同一家公司：
- Claude Sonnet 4.6： “大容量大脑”。昂贵、强大且评价极高。
- Claude Haiku 4.5： “小容量大脑”。便宜得多、速度更快且体积更小。
令人惊讶的是： “小容量大脑”（Haiku）发现 Bug 的数量和编写评论的质量始终优于“大容量大脑”（Sonnet）。
- 类比： 这就像雇佣了一名初级侦探，他发现线索的数量比高级侦探多出 18%，但成本却只有后者的 3 倍。那位高级侦探因为过于谨慎和过度思考，反而漏掉了初级侦探一眼就能看出的东西。
2. “虚假考试”陷阱
这是最关键的发现。多年来，公司一直使用**合成缺陷（Synthetic Bugs）**来测试这些 AI 编辑。
- 类比： 想象一下通过让一名消防员在安静的房间里扑灭一根小小的蜡烛来测试他。这些 AI 编辑表现得非常出色！他们拿到了 90% 的高分。
- 现实情况： 研究人员随后让同样的 AI 编辑去处理真实的拉取请求（Real Pull Requests）。这就像要求消防员去扑灭一栋伴随着浓烟、强风和复杂布局的着火摩天大楼。
- 结果： 当 AI 编辑面对“着火的摩天大楼”（真实代码）时，它们的表现不仅是下降，而是崩溃了。
- 在“蜡烛”（合成缺陷）测试中，它们得到了 85% 的分数。
- 在“摩天大楼”（真实缺陷）测试中，表现最好的模型仅得到了 6.6% 的分数。
- 教训： 用完美的、虚假的例子来测试 AI，就像是在空旷的赛道上测试驾驶员，然后就假设他们能应对高峰期的交通拥堵一样。这会给人一种极其危险的虚假安全感。
3. “信息过载”问题
研究人员发现，AI 在处理真实代码时失败的主要原因并不是因为 AI “笨”，而是因为“任务”太乱了。
- 类比： 如果你要求校对员检查一个句子，他们会做得完美无缺。但如果你同时把一部 500 页的小说交给他们，而小说里还夹杂着 500 页的随机笔记、咖啡渍和涂改过的段落，他们就会感到不知所措并漏掉所有内容。
- 发现： 代码变更的大小（即 "diff"）是预测失败的最主要指标。
- 小规模变更（少于 10 行）：AI 表现良好。
- 大规模变更（超过 150 行）：AI 的表现下降了 15 倍。
- 解决方案： 不要一次性把整部小说喂给 AI。先将代码拆分成易于处理的小章节。
4. “盲区”
有一种类型的 Bug 是 AI 完全会漏掉的：性能问题（例如运行缓慢的代码）。
- 类比： 想象一下要求一名机械师寻找一个损坏的汽车零件。他能看到那个坏掉的零件。但如果你问他能否找到一个会在 5 年后导致引擎过热的零件，他是看不出来的，因为车现在还没开始跑。
- 现实情况： AI 观察的是屏幕上的代码。它无法“运行”代码来观察其运行速度或内存占用情况。对于这些特定的问题，AI 实际上是盲目的。
5. “团队协作”的迷思
研究人员想知道：“如果我们雇佣两名编辑并将他们的笔记结合起来呢？效果会更好吗？”
- 结果： 不会。
- 类比： 如果两个人都在找草堆里的针，而他们都漏掉了同一个位置，那么增加人数并不能解决问题。AI 模型都在观察相同的盲点。增加更多的模型只会增加更多的“噪音”（误报），而无法发现新的 Bug。
总结
如果你正在构建一个自动化的代码审查系统：
- 不要购买最昂贵的模型。 在这项研究中，较小的、更便宜的模型（如 Haiku）实际上做得更好。
- 不要相信“虚假”的测试结果。 如果一个 AI 在包含简单、人为制造的 Bug 的测试中表现完美，那么在面对真实代码时它很可能会失败。
- 将大问题拆解为小问题。 如果代码变更很大，请在展示给 AI 之前先将其切碎。
- 针对速度问题使用人类（或不同的工具）。 AI 无法预测代码运行的速度快慢。
研究结论指出，在自动化代码审查的世界里，大并不代表更好；它往往只是更贵，而且有时会让 AI 更加困惑。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。