← 最新论文
🤖 AI

Towards Comprehensive Benchmarking Infrastructure for LLMs In Software Engineering

本文识别了当前大语言模型在软件工程评估方面的关键空白,并引入了 BEHELM,这是一个旨在将软件场景规范与多指标评估相统一的全面基准测试基础设施,以实现公平、真实且可复现的评估。

原作者: Daniel Rodriguez-Cardenas, Xiaochang Li, Marcos Macedo, Antonio Mastropaolo, Dipin Khati, Yuan Tian, Huajie Shao, Denys Poshyvanyk

发布于 2026-01-30
📖 1 分钟阅读☕ 轻松阅读

原作者: Daniel Rodriguez-Cardenas, Xiaochang Li, Marcos Macedo, Antonio Mastropaolo, Dipin Khati, Yuan Tian, Huajie Shao, Denys Poshyvanyk

原始论文采用 CC BY 4.0 许可(http://creativecommons.org/licenses/by/4.0/)。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性,请参阅原始论文。 阅读完整免责声明

想象一下,你正在试图评判新一代“机器人厨师”(用于编写代码的大型语言模型)的厨艺水平。目前,我们测试它们的方式有点像是在看它们切一个洋葱的速度快不快。如果它们切好了洋葱,我们就给它们一颗金星。

但在现实世界中,一名厨师不仅仅是切洋葱;他们要管理整个厨房,遵循复杂的食谱,处理辛辣的食材而不至于烧掉房子,还要与团队协作。这篇论文指出,我们目前的“切洋葱”测试过于简单了。它们忽略了大局,因此我们其实并不真正了解这些机器人厨师是否能应付一场真正的晚餐服务。

以下是使用简单类比对该论文主要观点的拆解:

1. 问题所在: “驾驶测试”太简单了

目前,我们用一些孤立的小任务(比如编写一段简短的代码片段)来测试这些 AI 模型。

  • 类比: 这就像给一名驾驶员做测试,要求他们只在时速 5 英里的空旷停车场里开车。他们表现得非常出色。但这并不能告诉我们他们是否能应对高峰时段的交通、恶劣的天气或高速公路上的突然刹车故障。
  • 现实情况: 论文指出,目前的测试已经“饱和”了。这些机器人已经背下了这些简单的停车场测试题的答案。当你给它们一个现实世界的问题(比如修复一个庞大且混乱的软件项目中的漏洞)时,它们往往会失败,因为它们只是在记忆模式,而不是在学习如何像软件工程师一样“思考”。

2. 我们测试中的三个大洞

作者发现我们的现有测试基础设施存在三个主要缺陷:

  • 洞口 #1:缺失“上下文”(食谱书)
    • 问题: 现在的测试只关注代码本身,忽略了软件项目的其余部分。
    • 类比: 想象一下,你要求一名厨师做汤,但你只给了他们一份食材清单。你没有给他们锅、炉灶、食谱书,或者关于这道汤如何融入整顿饭的说明。真正的软件工程是混乱的;它涉及历史记录、团队注释和特定的规则。我们的测试忽略了所有这些“厨房杂物”,所以机器人并没有在处理真实混乱的情况下接受测试。
  • 洞口 #2:错误的评分标准(“通过/失败”陷阱)
    • 问题: 我们大多使用“准确率”(它是否奏效?是/否)或“文本相似度”(它看起来是否像答案?)。
    • 类比: 想象你在给学生的作文评分。如果学生写了一段语法完美但内容完全错误的段落,或者他们写出了一个精妙的解决方案但看起来与老师的答案不一致,我们目前的测试可能会判定他们错误。我们需要根据他们编写内容的原因(可解释性)、完成速度(效率)以及是否对每个人都公平(偏见)来评分,而不仅仅是看最终的字数是否匹配。
  • 洞口 #3:每个人都在建造自己的测试赛道(“缺乏标准”问题)
    • 问题: 每个研究团队都在从头开始构建自己的测试。一个团队使用泥泞的赛道,另一个使用铺设好的公路,第三个使用跑步机。
    • 类比: 这就像在比较赛车手,有的在土路上开,有的在冰面上开,有的在高速公路上开。你无法判断谁是最好的驾驶员,因为条件完全不同。论文指出,我们浪费了大量的时间和金钱在重复构建这些赛道上,而不是使用一个标准化的、高质量的赛道。

3. 解决方案:BEHELM(“全能型”测试中心)

为了解决这个问题,作者提出了一个名为 BEHELM 的新基础设施。可以把它想象成建立一座规模宏大的、最先进的驾驶学院,同时测试驾驶员各个方面的技能。

BEHELM 不仅仅是一个测试,它创建了一个检查网格,涵盖:

  • 场景: 我们是在测试代码生成、漏洞修复还是代码翻译?
  • 语言: 是 Python、Java 还是 C++?
  • 细节程度: 我们是在看一个单词、一个完整的文件,还是一整个项目?
  • 指标: 除了“通过/失败”,它还会根据以下维度对模型进行评分:
    • 准确性: 它奏效了吗?
    • 效率: 它是否消耗了过多的计算资源?
    • 可解释性: 我们能否理解它为什么做出那个选择?
    • 公平性与偏见: 它是否平等地对待了所有用户?
    • 鲁棒性: 当遇到奇怪的输入时,它会崩溃吗?

核心结论

论文得出结论,我们不能再把 AI 代码模型仅仅视为需要简单测验的“自动补全”工具。我们需要把它们当作专业的软件工程师来对待。

BEHELM 是一个提议,旨在建立一个标准化的、全面的测试设施,用以检查这些模型是否真的能在混乱、复杂的现实世界软件厨房中生存下来,而不仅仅是靠通过一个停车场测试。其目标是确保当我们信任这些机器人承担实际工作时,它们是真的准备好投入工作的。

您所在领域的论文太多了?

获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。

试用 Digest →