[AI Generated Post] LLM 代码能力的基准、主流 LLM 的评分和排名

注：本文由 Gemini Deep Research 生成，是我在调研后续训练的 base model 选型所用

  1. 引言

大型语言模型（LLM）在包括代码生成在内的多个领域展现出变革性的潜力，有望提高开发人员的生产力并自动化软件开发生命周期的各个方面。随着越来越多的 LLM 具备生成代码的能力，客观且严谨的评估这些模型变得至关重要。标准化的基准测试在比较不同 LLM 的性能、跟踪技术进步以及识别需要改进的领域方面发挥着关键作用。本报告旨在深入探讨用于评估 LLM 代码生成能力的主要基准测试，分析主流 LLM 在这些基准测试上的表现，并探讨当前评估方法的局限性以及未来的发展方向。

  1. 评估 LLM 代码能力的常见基准

评估 LLM 代码生成能力涌现出了一系列基准测试，每个基准测试都旨在从不同的角度评估模型的性能 (1)。这些基准测试涵盖了从基本的函数级代码生成到复杂的现实世界软件工程任务的各种场景。以下是其中一些主要的基准测试：

  • HumanEval (1): 由 OpenAI 开发，是评估 LLM 从文档字符串生成功能正确代码能力的最广泛认可的研究基准之一 (1)。它包含 164 个手写编程问题，每个问题都带有函数签名、文档字符串、函数体以及若干单元测试 (2)。HumanEval 侧重于评估模型在理解语言、进行推理以及解决与算法和简单数学相关的问题的能力 (3)。

  • MBPP (Mostly Basic Python Programming) (1): 由 Google 发布，包含约 1000 个众包的 Python 编程问题，旨在由入门级程序员解决 (5)。每个问题都包含任务描述、代码解决方案和 3 个自动化测试用例，用于检查功能正确性 (8)。MBPP 的目标是衡量模型从自然语言描述中合成短 Python 程序的能力 (8)。

  • BigCodeBench (1): 由 BigCode 项目创建，旨在评估 LLM 在解决实际且具有挑战性的编程任务方面的能力，这些任务涉及对来自 139 个不同库的多个函数调用进行组合 (7)。它包含 1140 个函数级任务，每个任务都包含详细的指令和平均 5.6 个测试用例 (32)。BigCodeBench 包括两个主要部分：BigCodeBench-Complete（基于详细文档字符串的代码补全）和 BigCodeBench-Instruct（基于自然语言指令的代码生成）(32)。

  • SWE-bench (7): 由普林斯顿大学开发，是一个旨在评估 LLM 在现实世界软件工程场景中解决问题的能力的基准 (7)。它包含来自 GitHub 上流行的开源 Python 存储库的 2294 个软件工程问题，这些问题通常是错误报告或功能请求 (7)。LLM 的任务是生成一个补丁来解决问题，并通过存储库自身的测试框架进行评估 (7)。

除了这些主要的基准测试外，还有其他一些值得关注的基准，它们侧重于代码生成的不同方面或特定的编程语言：

  • CodeEval (67): 一个更广泛的术语，可以指代各种评估代码生成能力的基准测试。其中一些变体包括：

    • ComplexCodeEval (67): 旨在评估 LLM 在更复杂的开发场景中的表现，使用来自高星级 GitHub 存储库的 Java 和 Python 样本，侧重于库 API 的使用。

    • CoderEval (69): 评估生成式预训练模型在实用代码生成方面的性能，超越了仅生成独立函数的情况，考虑了上下文依赖性。

    • CrossCodeEval (73): 一个多语言基准测试，专注于需要跨文件上下文理解的代码补全任务。

    • SwiftEval (74): 专门针对 Swift 编程语言的基准测试，包含手工制作的问题，考虑了 Swift 特有的语言特性。

  • APPS (Automated Programming Progress Standard) (7): 一个包含 10000 个来自 Codewars、AtCoder、Kattis 和 Codeforces 等平台的编程问题的综合基准测试，涵盖了从初级到高级的各种难度级别。

  • MultiPL-E (2): 一个用于将单元测试驱动的代码生成基准测试翻译成多种编程语言的系统，支持 22 种编程语言。

  • StackEval (1): 评估 LLM 作为编码助手的实用性，通过测试其对 StackOverflow 上真实编码问题的响应。

  • CanAiCode (1): 一个包含人类创建并由 AI 测试的各种难度级别的面试风格编码问题的基准测试。

  1. 主要基准的深入分析

3.1 HumanEval

HumanEval 的评估方法侧重于功能正确性，即生成的代码在给定的单元测试中是否能按预期工作 (1)。对于每个问题，模型会生成 k 个代码样本，如果其中至少一个样本通过了所有相关的单元测试，则认为该问题已解决 (3)。性能通常使用 pass@k 指标来衡量，该指标表示模型在前 k 个生成的样本中至少生成一个正确解决方案的概率 (3)。常用的指标包括 pass@1、pass@10 和 pass@100 (3)。

HumanEval 的主要关注领域是评估 LLM 在理解自然语言描述、运用算法思维以及解决简单的数学问题方面的能力 (2)。它通过一组精心设计的 Python 编程问题来实现这一点，这些问题涵盖了各种编程概念和技巧。

HumanEval 的优势在于它提供了一种标准化且可重复的方式来评估代码生成 (1)，并且其 pass@k 指标与开发人员测试代码的方式相似 (3)。然而，HumanEval 也有其局限性。它主要关注相对简单的函数级任务，可能无法充分代表现实世界的编程场景 (1)。此外，它仅限于 Python (8)，并且不评估代码风格、可维护性或效率 (13)。由于其广泛使用，HumanEval 也更容易受到数据污染的影响 (7)。

3.2 CodeEval（及相关基准）

CodeEval 是一个更广泛的类别，包含了一系列旨在评估代码生成能力的不同方面的基准测试。

ComplexCodeEval 旨在评估 LLM 在更复杂的开发场景中的表现，使用了来自高星级 GitHub 存储库的 Java 和 Python 代码 (67)。每个样本都包含多个注释，以适应代码生成、代码补全、API 推荐和测试用例生成等任务 (67)。该基准测试强调使用库 API，并旨在通过使用时间戳来避免数据泄露 (67)。评估通常使用 pass@1 指标。

CoderEval 专注于评估生成式预训练模型在实用代码生成方面的能力，超越了仅生成独立函数的情况 (69)。它包含来自真实世界开源项目的 Python 和 Java 代码生成任务，并考虑了上下文依赖性和可运行级别 (69)。CoderEval 使用一个执行平台来自动评估生成代码的功能正确性 (70)。

CrossCodeEval 是一个多语言基准测试，支持 Python、Java、TypeScript 和 C# (73)。它专注于代码补全任务，这些任务严格要求跨文件的上下文理解 (73)。该基准测试使用基于静态分析的方法来确保跨文件依赖性，并根据标识符匹配和在不同上下文级别上的精确匹配准确率来评估模型 (73)。

SwiftEval 是第一个面向 Swift 的基准测试，包含手工制作的问题，旨在评估 LLM 在 Swift 编程方面的编码能力 (74)。它考虑了 Python 中心基准测试未涵盖的 Swift 特有语言特性，并使用 pass@k 指标进行评估，同时与 HumanEval 的结果进行比较 (74)。

CodeEval 系列基准测试的评估方法和重点各不相同，但通常涉及评估功能正确性、上下文理解以及对特定编程范例或语言特性的遵守情况。评估指标包括 pass@k、准确率和标识符匹配。这些基准测试的优势在于它们解决了 HumanEval 的局限性，评估了更复杂的场景、多种语言、跨文件依赖性和实用的代码生成。然而，一些基准测试的任务数量较少（例如 SwiftEval），并且可能仍然容易受到数据污染的影响。此外，评估可能很复杂，需要特定的设置和指标。

3.3 MBPP (Mostly Basic Python Programming)

MBPP 的评估方法旨在衡量 LLM 从自然语言描述中合成短 Python 程序的能力 (8)。该基准测试包含 974 个编程任务，每个任务都附带一个自然语言描述、一个参考代码解决方案以及通常三个自动化测试用例，用于验证生成代码的功能正确性 (5)。模型的性能通常通过准确率来衡量，即模型生成的任何样本通过其相应任务的所有测试用例的百分比 (20)。评估通常在少量样本学习和微调设置中进行 (81)。

MBPP 的主要关注领域是评估模型生成适合入门级程序员解决的短 Python 程序的能力，涵盖编程基础和标准库功能 (5)。

与 HumanEval 相比，MBPP 的优势在于数据集更大 (8)，并且在提示中包含输入/输出示例 (8)。它侧重于许多应用都相关的基本编程问题 (5)。然而，MBPP 主要仍然侧重于单函数生成 (84)，与现实世界的任务相比，复杂性有限 (25)，并且也可能受到数据污染的影响 (7)。

3.4 BigCodeBench

BigCodeBench 的评估方法使用带有贪婪解码的 Pass@1 指标来评估 LLM 的性能 (32)。该指标衡量模型通过精心设计的测试用例，在第一次尝试时正确解决的任务百分比 (32)。为了解决 LLM 跳过长代码提示的倾向，评估过程中会添加缺失的设置（例如导入语句、全局常量），这被称为校准的 Pass@1 (32)。此外，BigCodeBench 还使用 Elo 评分系统对模型进行排名 (32)。

BigCodeBench 的主要关注领域是评估 LLM 处理实际且具有挑战性的编程任务的能力 (7)，这些任务需要利用来自各种库的不同函数调用 (7)。它包含两个主要组成部分：BigCodeBench-Complete 侧重于基于详细文档字符串的代码补全，而 BigCodeBench-Instruct 则旨在评估遵循自然语言指令的指令调整 LLM 的能力 (32)。

BigCodeBench 的优势在于它通过关注涉及多个函数调用和库使用的更复杂的任务，解决了更简单基准测试的局限性 (7)。它包含大量具有高分支覆盖率的任务 (7)，并旨在实现现实世界的相关性并避免污染 (32)。然而，它仍然是函数级别的任务，而不是完整的程序或项目 (7)。LLM 的性能仍然远低于人类的水平 (22)。指令调整模型有时会在长提示中省略必要的导入语句等信息（模型惰性）(32)。

3.5 SWE-bench

SWE-bench 的评估方法旨在衡量 LLM 解决现实世界软件问题的能力 (7)。给定一个代码库和一个问题描述，模型需要生成一个补丁来解决该问题 (7)。通过将生成的补丁应用到代码库并执行相关的单元测试来评估解决方案 (7)。主要的评估指标是解决的问题百分比 (21)。SWE-bench 包含 Full、Lite 和 Verified 等变体 (41)。

SWE-bench 的主要关注领域是评估 LLM 在理解复杂系统、进行超越简单代码生成的高级推理、协调跨多个文件的更改以及执行代码审查和解决问题等方面的能力 (7)。

SWE-bench 的优势在于它基于真实的 GitHub 问题和拉取请求 (7)，提供了最现实的 LLM 软件工程能力评估 (7)。它使用基于执行的评估框架 (7)，并且可以持续更新新的实例 (21)。然而，这是一个非常具有挑战性的基准，即使对于最先进的模型，解决率也很低 (21)。评估需要大量的计算资源 (45)，并且可能受到数据污染的影响 (45)。

  1. 主流 LLM 在主要基准上的表现

4.1 HumanEval 的分数和排名

下表总结了主流 LLM 在 HumanEval 基准测试上的 Pass@1 分数和排名。值得注意的是，一些模型的性能会受到所使用的提示技术的影响，例如分层提示 (HPT)。

表 1：主流 LLM 的 HumanEval Pass@1 分数

模型 Pass@1 (%) 来源 年份
Claude 3.5 Sonnet (HPT) 100 93 2024
Llama-3 8B (HPT) 100 93 2024
LLMDebugger (OpenAI o1) 99.4 93 2025
QualityFlow (Sonnet-3.5) 98.8 93 2025
LPW (GPT-4o) 98.2 93 2024
GPT-4o (0-shot) 90.2 17 2024
Llama 3.1 405B 89 17 2024
Grok-2 88.4 17 2024
Qwen2.5-Coder-7B-instruct 88.4 19 2024
Claude3 Opus 84.9 17 2024
Qwen2.5-Coder-32B-instruct 92.7 19 2024
GPT-4 (0-shot) 67 96 2023
Gemini Ultra 74.4 77 2023
Gemini 1.5 Turbo 71.9 98 2024
Gemini Pro 53.7 97 2023
Code Llama 34B 53.7 99 2023
Gemma 3 PT 27B (0-shot) 48.8 15 2025
Llama 2 7B 21 97 2023

这些结果表明，最近的模型，如 Claude 3.5 Sonnet 和 Llama-3 8B，在使用分层提示技术时，在 HumanEval 上取得了完美的成绩，这可能表明该基准测试已接近饱和。然而，标准的零样本评估仍然显示出模型之间的性能层次，GPT-4 和 Claude 3 Opus 处于领先地位。

4.2 CodeEval 的分数和排名

由于研究材料中缺乏在 CodeEval 的各种变体（ComplexCodeEval、CoderEval、CrossCodeEval、SwiftEval）上对主流 LLM 进行全面且直接可比的评分，因此无法在此处提供具体的表格。然而，值得注意的是，这些基准测试旨在评估代码生成的不同方面，例如处理复杂场景、多种语言、跨文件依赖性和实用代码生成。模型的性能将取决于基准测试的具体任务和评估指标。

4.3 MBPP 的分数和排名

下表总结了主流 LLM 在 MBPP 基准测试上的准确率和排名。

表 2：主流 LLM 的 MBPP 准确率

模型 准确率 (%) 来源 年份
QualityFlow (Sonnet-3.5) 94.2 28 2025
o1-mini + MapCoder 93.2 28 2024
GPT-4 + AgentCoder 91.8 28 2023
CodeSim (GPT4o) 90.7 28 2025
Qwen2.5-Coder-32B-instruct 90.2 19 2024
Claude 3 Opus 86.4 28 2024
LPW (GPT-4o) 84.8 28 2024
Qwen2.5-Coder-7B-instruct 83.5 19 2024
GPT-4 (ChatGPT Plus) 87.5 28 2023
Claude 3 Haiku 80.4 28 2024
Claude 3 Sonnet 79.4 28 2024
Llama 3.1 405B 78.8 94 2024
Llama 3.1 70B 75.4 94 2024
Gemini 1.5 Turbo 77.7 98 2024
Gemini Ultra 86.4 28 2024
Gemini Pro - 28 2023
Code Llama 70B 65.5 28 2023
Gemma 3 PT 27B (3-shot) 65.6 15 2025

与 HumanEval 类似，MBPP 上表现最好的模型在合成短 Python 程序方面表现出了很高的准确率。QualityFlow（基于 Claude 3.5 Sonnet）取得了最高的准确率，表明其在这些入门级编程任务上表现出色。

4.4 BigCodeBench 的分数和排名

下表总结了主流 LLM 在 BigCodeBench 上的校准 Pass@1 分数和 Elo 评分。

表 3：主流 LLM 的 BigCodeBench 校准 Pass@1 分数和 Elo 评分（截至 2024 年 6 月）

模型 Complete (%) Instruct (%) Elo MLE 来源
GPT-4o-2024-05-13 61.1 51.1 1269 32
DeepSeek-Coder-V2-Instruct 59.7 48.2 1251 32
Claude-3.5-Sonnet-20240620 58.6 46.8 1214 32
GPT-4-Turbo-2024-04-09 58.2 48.2 1216 32
Gemini-1.5-Pro-API-0514 57.5 43.8 1218 32
Claude-3-Opus-20240229 57.4 45.5 1209 32
GPT-4-0613 57.2 46 1213 32
Llama-3-70B-Instruct 54.5 43.6 1170 32
Gemini-1.5-Flash-API-0514 55.1 43.5 1187 32
Qwen2.5-Coder-32B-Instruct 30.8 - 1168 12
Gemma-3-27B-Instruct 26 - - 12
Qwen2.5-Coder-7B-Instruct 20.3 - - 12

GPT-4o 在 BigCodeBench 上处于领先地位，表明其在处理复杂指令和利用来自不同库的函数调用方面具有卓越的能力。Complete 和 Instruct 任务之间显着的性能差异表明，遵循自然语言指令仍然比基于结构化文档字符串完成代码更具挑战性。

4.5 SWE-bench 的分数和排名

下表总结了主流 LLM 在 SWE-bench（Full、Lite、Verified）上解决的问题百分比。值得注意的是，一些结果是通过使用代理框架或特定技术实现的，这可能会影响直接比较。

表 4：主流 LLM 的 SWE-bench 问题解决百分比（截至 2025 年 3 月）

模型 SWE-bench Full (%) SWE-bench Lite (%) SWE-bench Verified (%) 来源
Augment Agent v0 - - 65.4 50
W&B Programmer O1 crosscheck5 - - 64.6 50
AgentScope - - 63.4 50
Tools + Claude 3.7 Sonnet (2025-02-24) - - 63.2 50
EPAM AI/Run Developer Agent + Claude 3.5 Sonnet - - 62.8 50
CodeStory Midwit Agent + swe-search - - 62.2 50
OpenHands + 4x Scaled (2025-02-03) - - 60.8 50
CodeStory Midwit Agent + swe-search - - 62.2 41
OpenAI o3 (unverified) - - 72 41
Claude 3.5 Sonnet 3.79 4.33 49 41
Claude 2 1.97 3 - 46
ChatGPT-3.5 0.17 0.33 - 46
GPT-4-turbo 1.31 2.67 - 46
SWE-Llama 13b 0.7 1 - 46
Devin - - 13.86 48
GPT-4o - - 33.2 51
Claude 3.7 Sonnet - - 62.3 (70.3 with scaffold) 102
Gemini 2.5 Pro - - 63.8 105

所有模型在 SWE-bench 上的解决率都非常低，这表明现实世界的软件工程任务对 LLM 来说是一个巨大的挑战。一些模型，如 Augment Agent v0、W&B Programmer O1 crosscheck5 和 AgentScope，在 SWE-bench Verified 上表现出相对更好的性能，这可能归因于使用了更复杂的代理框架和技术。

  1. 代码生成基准的局限性和偏差

当前的 LLM 代码生成基准测试虽然很有价值，但也存在一些固有的局限性和偏差 (7)。

常见限制包括：

  • 数据污染 (7): LLM 可能在其训练数据中已经遇到过基准测试中的问题或非常相似的问题，从而导致人为夸大的性能。

  • 范围狭窄 (7): 许多基准测试侧重于特定的编程语言（主要是 Python）和相对简单的任务，可能无法代表现实世界软件开发的广泛需求和复杂性。

  • 缺乏现实世界的复杂性 (25): 像 HumanEval 和 MBPP 这样的基准测试通常包含孤立的、单函数的任务，而现实世界的软件工程通常涉及大型代码库、多文件交互和复杂的依赖关系。

  • 评估指标的局限性 (3): 许多基准测试主要关注功能正确性，而忽略了代码质量的其他重要方面，例如可读性、可维护性、效率和安全性。像 pass@k 这样的指标虽然很有用，但可能无法完全捕捉到代码的细微差别。

  • 测试充分性 (7): 基准测试中使用的单元测试的质量和全面性可能存在差异，有时可能无法充分验证生成代码的正确性或覆盖所有边缘情况。

此外，代码生成基准测试和 LLM 本身也可能存在偏差 (25)。这可能包括社会偏见，例如与年龄、性别和种族相关的偏见 (79)，这些偏见可能会在 LLM 生成的代码中无意中体现出来，从而导致不公平或不道德的行为 (79)。研究人员正在积极探索识别和减轻这些偏差的方法，例如通过提示工程或开发专门的基准测试来评估公平性 (79)。

  1. LLM 代码生成评估的进展和未来方向

LLM 代码生成评估领域正在迅速发展，研究人员不断努力克服现有基准测试的局限性并开发更全面和现实的评估方法 (1)。

一些值得注意的进展和未来方向包括：

  • 多语言支持 (7): 越来越多的基准测试开始包含对多种编程语言的支持，以更全面地评估 LLM 在不同语言环境下的代码生成能力。例如，MultiPL-E 和 HumanEval-X 旨在评估模型在多种编程语言上的性能。

  • 关注现实世界场景 (21): 新的基准测试，如 SWE-bench 和 BigCodeBench，越来越侧重于评估 LLM 在更实际的软件开发任务中的表现，例如修复错误、实现新功能以及与现有代码库集成。

  • 持续演进的基准测试 (21): 为了应对数据污染的问题，一些基准测试正在开发持续更新的机制，以确保评估任务不会出现在模型的训练数据中。EvoCodeBench 就是一个例子，它计划每六个月更新一次。

  • 更全面的评估指标 (21): 除了功能正确性之外，未来的评估可能会更多地关注代码质量的其他方面，例如可读性、可维护性、效率、安全性和风格。RACE 基准测试是朝着这个方向迈出的重要一步。

  • 多模态评估方法 (12): 随着 LLM 变得越来越擅长处理多种类型的数据，将视觉信息（例如图表和流程图）融入代码生成任务的基准测试（如 HumanEval-V）正在出现。

  • 上下文感知评估 (37): 未来的基准测试可能会更加强调评估 LLM 在理解和利用上下文信息（例如代码库、项目结构和依赖关系）来生成更准确和相关的代码方面的能力。

  • 伦理和负责任的代码评估 (79): 评估 LLM 生成代码中的偏见和公平性将变得越来越重要。FairCode 基准测试旨在评估代码生成中的社会偏见。

  • 持续和自动化的评估流程 (133): 开发能够持续监控和评估 LLM 代码生成性能的自动化管道将有助于更快地识别问题和跟踪进展。

  • 人机协作评估 (12): 结合人类专业知识和 LLM 的能力来创建更强大和细致的评估方法可能会成为未来的趋势。RealHumanEval 就是一个例子，它通过用户研究来衡量 LLM 在辅助程序员方面的能力。

  1. 基准测试与现实世界编码的相关性

虽然基准测试为评估 LLM 的代码生成能力提供了有价值的指标，但重要的是要考虑这些评估与 LLM 在实际编码场景中的实用性和性能的相关性 (16)。

一些观察结果表明，基准测试结果与现实世界性能之间可能存在差距：

  • HumanEval 和 MBPP 的局限性 (8): 这些基准测试主要侧重于短的、独立的 Python 函数，可能无法充分代表实际软件开发中遇到的更广泛和更复杂的任务。模型在这些基准测试上取得高分并不一定意味着它们在处理大型代码库或具有复杂依赖关系的项目时也能表现良好。

  • BigCodeBench 的进步 (22): 通过评估 LLM 在利用来自各种库的函数调用方面的能力，BigCodeBench 比 HumanEval 和 MBPP 更接近现实世界的场景。然而，它仍然侧重于函数级别的任务。

  • SWE-bench 的现实性 (21): SWE-bench 通过使用来自真实 GitHub 问题的任务来模拟现实世界的软件工程挑战，提供了 LLM 在实际编码环境中能力的更真实的评估。然而，即使是最先进的模型在这个基准测试上的表现仍然相对较低，这表明了现实世界编码任务的难度。

  • 基准测试与实际生产力的不匹配 (80): 研究表明，基准测试性能的提高并不总是能直接转化为程序员生产力的相应提高。程序员的偏好也不一定与他们的实际表现相关，这突显了需要更好、以人为中心的评估指标。

  • 数据污染的潜在影响 (16): 由于许多 LLM 都是在大量代码数据上训练的，因此基准测试中的问题或类似问题可能已经包含在它们的训练集中，从而可能导致性能被高估。

总的来说，虽然当前的基准测试为评估 LLM 的代码生成能力提供了宝贵的见解，但它们应该被视为评估 LLM 在实际编码场景中全部潜力的一个方面。未来的评估工作需要继续开发更全面、更现实的基准测试，这些基准测试能够捕捉到软件开发的复杂性和细微差别。

  1. 结论

评估大型语言模型的代码生成能力是一个复杂且不断发展的领域。HumanEval、MBPP、BigCodeBench 和 SWE-bench 等基准测试为衡量 LLM 在不同方面的性能提供了有价值的框架，从基本的函数正确性到复杂的现实世界问题解决。主流 LLM 在这些基准测试上取得了显着的进步，但结果也突显了当前评估方法的局限性以及 LLM 在处理实际软件工程任务时仍然面临的挑战。未来的研究必须继续开发更全面、更现实、更能代表软件开发复杂性的基准测试，并解决数据污染和偏见等问题，以确保对 LLM 的代码生成能力进行准确和有意义的评估。

posted @ 2025-04-09 16:47  zion03  阅读(1381)  评论(0)    收藏  举报