所有大型语言模型都能写出出色的代码，但有些模型犯的错误（明显）更少

一个假设场景

如果你是一位经验丰富的软件工程师，经历过多次编码面试，你一定遇到过这样的候选人。他们当场理解问题并立即投入行动。他们编码速度很快。阅读他们最终的代码简直是一种享受。优秀的结构，适当的缩进，易于理解的命名等等。除了一个非致命的`BUG`，这应该是一个疏忽。你多次提醒候选人，但他们仍然没有发现。因此，你在评审意见中带着一些遗憾，推荐将他聘为一名具有巨大潜力的初级工程师。到目前为止一切顺利，……`直到`你遇到下一位候选人。

除了速度、可读性、注释等，代码完美无瑕，`没有BUG`。你的第一反应是“我自己都做不到”。你的下一个想法是“我们必须让这个人加入我们的团队”，前提是你并不担心自己的工作安全。

动机

以上是我在读完论文《基准测试前沿语言模型在Web应用代码生成方面的洞察》后脑海中浮现的画面。我设计了WebApp1K基准测试，使其易于运行且对所有竞争模型公平。规则很简单：让你的代码通过给定的单元测试。我还重用了HumanEval提出的pass@k指标。

结果令人惊讶：模型之间的性能差距比我预期的要大得多。问题并不是非常困难（平均代码行数<=50），而且所有代码目测都很棒。用编码面试场景的比喻来说，GPT和Claude是完美的候选人，而顶级的开源模型是具有巨大潜力的候选人。

另一方面，小段代码输出带来了机会：我们现在有了一个在受控环境中的案例研究，复杂性也更易于管理。所以我决定深入研究日志，希望能学到一些东西，于是就有了这篇论文。

它们犯着相同的错误

总共有七种类型的bug（详细信息请参阅论文）。即使是性能最佳的GPT-4o模型也会犯所有这些bug。这里的区别在于，顶级模型犯的bug数量要少10倍。

提示工程有多大帮助

现在我们知道模型会犯哪些错误，我们能否通过提示来避免这些错误？我进行了大量实验，唯一成功的是提醒模型不要调用React框架中已弃用的`useHistory`函数。所有其他尝试都失败了。

事实上，所有错误都是由于未能满足单元测试的期望，而这些期望已经包含在提示中。例如，B型错误是文本不匹配。测试期望渲染的HTML包含某些显示“Submit”、“Share”等文本的UI元素。成功的代码当然满足所有期望。失败的代码也满足期望，只是文本略有不同，例如“submit”或“share”。

正确代码与错误代码的区别

这在正确性方面显然是正确的。但是两个数据集之间存在统计差异。下面是一个应用程序的成功与失败代码行数 (LOC) 分布。一个是双峰分布（成功），另一个是单峰分布（失败）。论文中还有更多类似的图表。

下一步是什么

首先是使用更多的任务和编程框架来增强基准测试。如果我们将代码行数提高到200或500，同样的观察结果是否仍然成立？还将发现新的观察结果。

其次是继续深入研究日志以探寻真相。还有许多悬而未决的问题。模型之间的差异肯定不是知识差距造成的。你可以说所有其他因素（后期训练、对齐、指令遵循等）都有影响力，但我相信可以获得洞察力，从而找到提升模型性能的公式。

非常感谢🤗HuggingFace🤗

当我决定分享这个基准测试（数据集和排行榜）时，选择HuggingFace是显而易见的。上手非常容易，自解释性强。工具也恰到好处。

但他们的执行速度让我大吃一惊。我的论文一出现在Arxiv上，他们就推荐了它，甚至在我宣传之前！

因此，我衷心感谢HF。他们真正理解社区和其中的每一个人，无论是宏大的计划还是日常的琐事。