LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code

文章标题: LiveCodeBench: 对代码大型语言模型的全面无污染评估 (LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code)
作者/机构: Naman Jain†, King Han†, Alex Gu*$, Wen-Ding Li*‡, Fanjia Yan*†, Tianjun Zhang*†, Sida I. Wang, Armando Solar-Lezama$, Koushik Sen†, Ion Stoica† († 加州大学伯克利分校 $ 麻省理工学院 ‡ 康奈尔大学)

A1 主要贡献

应用于代码相关应用的大型语言模型（LLM）已成为一个突出领域，吸引了学术界和工业界的极大兴趣。然而，随着新的、更强大的LLM的开发，现有的评估基准（如HumanEval, MBPP）已不足以评估其能力。本文针对这些不足，提出了LiveCodeBench，一个全面且无数据污染的代码LLM评估基准。

核心问题与研究目标:
现有代码评估基准存在三大问题：
1. 评估维度单一: 现有基准如HumanEval, MBPP, APPS主要关注自然语言到代码的生成任务，忽略了编程所涉及的更广泛能力，如代码修复、理解和测试。
2. 数据污染风险: LLM在海量、不透明的语料库上训练，现有基准测试样本很可能已包含在训练数据中，导致评估结果虚高。尽管有去污染的尝试，但任务艰巨且容易被简单策略（如改写）规避。
3. 问题质量与难度不均: 现有基准存在测试用例不足、问题描述模糊等问题。同时，竞赛级编程问题对当前SOTA模型来说也极具挑战性，低分数的扎堆使得模型间难以进行有意义的比较。

创新点与核心原则:
为解决上述问题，LiveCodeBench基于以下四大原则构建：
1. 实时更新以防止污染: LiveCodeBench通过从LeetCode, AtCoder, CodeForces等竞赛平台每周的比赛中收集新问题，并为每个问题标记发布日期。在评估新模型时，只使用其知识截止日期之后发布的问题，从而确保模型未在训练中见过这些问题。例如，图1显示DeepSeek和GPT-4-O模型在各自截止日期之后发布的LeetCode问题上性能显著下降，证明了这种时间分段评估方法的有效性。

1. 全面的整体评估: 编程是一项多方面的任务。LiveCodeBench除了代码生成外，还评估了另外三个关键场景：

   • 自我修复 (Self-Repair): 根据执行反馈（如错误信息或失败的测试用例）修复错误代码，评估模型的调试能力。
   • 代码执行 (Code Execution): 给定一段代码和一个输入，预测其输出，评估模型的代码理解能力。
   • 测试输出预测 (Test Output Prediction): 给定问题描述和一个输入，预测其对应的输出，评估模型生成测试用例的能力。
     图2（左）的雷达图展示了不同模型在这四个场景中的性能差异，凸显了整体评估的重要性。

   

2. 高质量的问题与测试: LiveCodeBench从知名竞赛平台获取问题，其质量已由大量用户验证。每个问题平均提供约17个测试用例，确保评估的鲁棒性和意义，同时又能快速完成。

3. 均衡的问题难度: 为了避免模型在难题上得分普遍为零而无法区分性能，LiveCodeBench利用竞赛网站提供的问题难度评级来筛选过难的问题，并将问题分为“简单”、“中等”和“困难”三个等级，以实现更细粒度的模型比较。

主要实证发现:
通过对18个基础模型和34个指令调优模型的评估，得出了以下关键发现：
1. 污染: DeepSeek、GPT-4-O和Codestral模型在各自截止日期之后发布的LeetCode问题上性能急剧下降，证实了旧问题中可能存在数据污染，时间分段评估是有效的。
2. 整体评估: 模型在不同任务上的性能相关，但相对差距各异。例如，在自我修复或测试输出预测任务上，开放模型与封闭模型的差距进一步拉大。Claude-3-Opus在测试输出预测上甚至超过了GPT-4。
3. HumanEval过拟合: 与HumanEval对比发现，一些模型（主要是微调的开源模型）在HumanEval上表现优异，但在LiveCodeBench上表现不佳（见图5），表明可能存在对HumanEval的过拟合。
4. 模型比较:
* 开源基础模型中，L3-Base和DeepSeek-Base表现最强。
* 封闭API模型（如GPT系列、Claude、Gemini）普遍优于开源模型。只有大型（>30B）指令调优模型如L3-Ins-70B、Mixtral和DS-Ins-33B能缩小差距。
* LiveCodeBench突显了GPT-4与其他模型之间的巨大性能差距，这在现有基准中并不明显。

A3 背景知识与设计原则

第2节 整体评估

对代码能力的评估不应局限于代码生成。LLM的代码能力通常通过自然语言到代码的生成任务来评估和比较。然而，这只捕捉了与代码相关能力的单一维度。现实世界的软件工程需要的专业知识远不止代码生成，还包括合成有信息的测试用例、调试错误代码、理解现有代码和编写文档等。这些任务不仅是额外的辅助工作，它们是软件开发过程中至关重要的部分，有助于提高代码的质量、可维护性和可靠性（引用自【8，A view of 20th and 21st century software engineering，2006，ICSE】）。这也适用于LLM，采用类似的工作流程可以使模型实现更好的代码生成。例如，AlphaCodium（【60，Code generation with alphacodium: From prompt engineering to flow engineering，2024】）是一个用于解决竞赛编程问题的复杂LLM流程。通过结合自然语言推理、测试用例生成、代码生成和自我修复，他们相比于简单的直接代码生成基线取得了显著的改进，展示了这些更广泛能力的重要性。受此启发，本文提出了一种更全面的LLM评估方法，使用一套评估设置来捕捉更广泛的与代码相关的能力。

评估场景的选择标准与概述。具体来说，我们在四个场景中评估代码LLM，即代码生成、自我修复、代码执行和测试输出预测。我们的选择标准是挑选那些在代码LLM工作流中是有用组件，并且具有清晰和自动化评估指标的设置。

代码生成场景。代码生成场景遵循从自然语言生成代码的标准设置。模型被给予一个问题陈述，包括自然语言描述和示例测试（输入-输出对），任务是生成一个正确的解决方案。评估基于功能正确性，使用一组未见过的测试用例。我们使用Pass@1指标，即模型能够生成通过所有测试的程序的问题所占的比例来衡量。图3（左）提供了此场景的一个示例。

自我修复场景。自我修复场景基于先前测试LLM自我修复能力的工作（【52，Demystifying gpt self-repair for code generation，2023】；【71，Reflexion: Language agents with verbal reinforcement learning，2023】；【12，Teaching large language models to self-debug，2023】）。在这里，模型被给予一个问题陈述，从中生成一个候选程序（类似于单步代码生成场景）。然而，如果出现错误，模型还会收到错误反馈（对于不正确的代码生成，是异常消息或失败的测试用
例），任务是生成修复后的解决方案。与代码生成场景类似，评估是通过对最终程序的功能正确性进行的，即单步正确生成或尝试修复后的程序。我们使用Pass@1指标来衡量修复步骤后的综合性能。图3（中左）提供了此场景的一个示例。

代码执行场景。代码执行场景基于CRUXEval（【17，Cruxeval: A benchmark for code reasoning, understanding and execution，2024】）中使用的输出预测设置。模型被提供一个由函数（f）组成的代码片段以及程序的测试输入，任务是预测程序在输入测试用例上的输出。评估通过基于执行的正确性指标进行，如果assert f(input) == generated_output通过，则认为模型生成是正确的。图3（右）提供了代码执行场景的一个示例。

测试用例输出预测场景。最后，我们引入了一个新任务，旨在研究自然语言推理和测试生成。在这个任务中，模型被给予问题陈述以及一个测试用例输入，任务是为该输入生成预期的输出。这个任务遵循了与CodeT（【10，Codet: Code generation with generated tests，2022】）中使用的类似设置，其中测试仅从问题陈述生成，无需函数的实现。一个关键区别是，我们在数据集中为每个问题提供了一组固定的测试输入，然后提示模型仅预测那些特定输入的预期输出。这种方法避免了测试输入预测这个难以评估的任务，从而可以直接评估测试生成能力。图3（中右）提供了此场景的一个示例。

框架的可扩展性。最后，我们想指出LiveCodeBench也提供了一个可扩展的框架，以便未来添加新的场景。因此，其他相关设置如输入生成、程序摘要、优化等都可以与我们的设置集成。

A2 方法细节

第3节 基准测试的构建

问题来源与质量保证。我们从三个编程竞赛网站策划问题：LeetCode、AtCoder和CodeForces。这些网站定期举办比赛，包含评估参与者编码和解决问题能力的题目。这些问题包括一个自然语言问题陈述和示例输入-输出，目标是编写一个能通过一组隐藏测试的程序。此外，成千上万的参与者参与解决这些问题，从而确保了问题的清晰度和正确性。

3.1 数据收集

数据抓取与初步处理。我们为上述每个网站编写了HTML爬虫，以收集问题和相应的元数据。为确保质量和一致性，我们解析了数学公式，并排除了带有图片的问题。我们还排除了不适合通过输入-输出示例进行评分的问题，例如那些接受多个正确答案或需要构建数据结构的问题。除了解析问题描述，我们还收集了相关的基准解决方案和测试用例（如果直接可用）。因此，对于每个问题，我们收集了由自然语言问题陈述P、测试用例T和基准解决方案S组成的元组。最后，我们将比赛日期D关联起来，以标记每个问题的发布日期，并使用收集到的属性为我们的四个场景构建问题（详见3.3节）。

时间滚动评估机制。如前所述，我们为每个问题关联了比赛日期D。发布日期使我们能够通过筛选问题发布日期是否在某个时间窗口内，来衡量LLM在不同时间窗口的性能（称之为“时间滚动”）。这对于评估和比较在不同时间训练的模型至关重要。具体来说，对于一个新模型及其相应的截止日期（如果未公布训练截止日期，则规范化为发布日期），我们可以衡量该模型在截止日期之后发布的基准问题上的性能。我们开发了一个用户界面，允许在不同时间窗口发布的问题上比较模型（如图9所示）。

测试用例的收集与生成。测试用例对于评估生成输出的正确性至关重要，并在所有四个场景中都使用。我们尽可能收集平台上可用的测试用例，并将其用于基准测试。否则，我们遵循Liu等人（【39，Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation，2023】）的方法，使用一个LLM（这里是GPT-4-Turbo）为问题生成测试。我们的测试生成方法与他们的一个关键区别在于，我们不是直接使用LLM生成输入，而是构建生成器，使用上下文学习根据问题规范采样输入。这类输入生成器的详细信息和示例可以在A.2节找到。最后，我们从平台上为较新的问题收集了一小部分失败的测试用例，从而实现了更有针对性的对抗性测试收集。

问题难度的平衡与筛选。竞赛编程对LLM来说一直是一个挑战，GPT-4的平均CodeForces评级（ELO）为392，处于垫底的5%（【53，Gpt-4 technical report，2023】）。这使得比较LLM变得困难，因为模型之间的性能差异很小。在LiveCodeBench中，我们收集了竞赛平台上标记的各种难度的问题，排除了那些评级超过某个阈值，可能对最好的模型来说也太难的问题。此外，我们使用这些评级将问题分为简单、中等和困难，以便进行更细致的模型比较。

3.2 特定平台的构建细节

各平台数据构建流程。我们描述了每个平台的构建过程。

LeetCode数据构建。我们收集了自23年4月后在LeetCode上举行的所有周赛和双周赛的问题。对于每个问题，我们收集了问题描述、公开测试用例和用户提交的解决方案。该平台还为每个问题提供了一个难度标签，我们用它来将问题标记为简单、中等和困难。由于LeetCode为每个问题提供了一个起始代码模板，我们也收集了它，并以函数式输入格式提供给LLM。由于隐藏的测试用D例不直接可用，我们使用了基于生成器的测试输入生成方法（A.2节），并且还为一些近期问题收集了自动评分器失败的测试用例。

AtCoder数据构建。我们收集了自23年4月后在AtCoder上举行的abc（初学者场）比赛的问题。我们特意避开了更具挑战性的arc和agc比赛，这些比赛是为更高级的奥林匹克竞赛参与者设计的。这些问题被赋予了数字难度评级，我们排除了评级超过500的abc问题。我们还使用这些数字评级将问题标记为简单、中等和困难。具体来说，我们使用评级区间[0−200)、[200−400)和[400−500]来进行分类。AtCoder为每个问题提供了公开和隐藏的测试用例，我们直接在基准测试中使用它们。

CodeForces数据构建。我们收集了CodeForces上Division 3和Division 4比赛的问题。值得注意的是，我们发现即使有这个筛选，这些问题也比其他两个平台的问题更难。CodeForces也为问题提供了难度评级，我们分别使用评级区间{800}、(800−1000]和(1000−1300]将问题标记为简单、中等和困难。由于难度较高，我们只考虑了CodeForces的一小部分问题，并半自动地构建了测试用例生成器，因为它们在平台上不提供完整的测试用例（长的测试用例会被截断）。

LiveCodeBench数据统计。表1提供了我们为LiveCodeBench收集的问题的各种统计数据。

3.3 针对不同场景的基准构建

代码生成与自我修复场景的数据构建。我们使用自然语言问题陈述作为这些场景的问题说明。对于LeetCode，如上所述，为函数式输入格式提供了额外的起始代码。对于AtCoder和CodeForces的问题，我们使用标准输入格式（类似于Hendrycks等人【20，Measuring mathematical problem solving with the math dataset，2021】的做法）。收集或生成的测试用例随后用于评估生成程序的正确性。我们的最终数据集在三个平台上共包含511个问题实例。

代码执行场景的数据构建。我们的灵感来自于Gu等人（【17，Cruxeval: A benchmark for code reasoning, understanding and execution，2024】）使用的基准创建程序。首先，我们从LeetCode子集中收集了大约2000个正确的人类提交的解决方案。然而，这些程序中有许多具有多个嵌套循环、复杂的数值计算和大量的执行步骤。因此，我们应用编译时和运行时过滤器来确保样本是合理的，并通过人工检查来复核。有关过滤标准和数据集统计的更多细节可以在附录A.3中找到。我们的最终数据集包含来自85个问题的479个样本。

测试用例输出预测场景的数据构建。我们使用LeetCode平台的自然语言问题陈述和示例测试输入来构建我们的测试用例输出预测数据集。由于问题中的示例测试输入是人类推理和理解问题的合理测试用例，它们也成为LLM处理的理想测试输入。我们的最终数据集包含来自总共181个LeetCode问题的442个问题实例。

A4 实验环境

本节描述实验设置，首先是跨场景的通用设置，然后在4.1节介绍特定场景的设置。

模型: 我们评估了52个模型，涵盖了从1.3B到70B的不同规模，包括基础模型、指令模型，以及开源和闭源模型。实验包括了不同系列的模型，例如GPTs（GPT-3.5-turbo, GPT-4, GPT-4-Turbo, GPT-4-O），Claudes（Claude-Ins-1, Claude-2, Claude-3s），Geminis（Gemini-Pro, Gemini-Flash），Mistral等闭源模型，以及LLaMa-3s（L3-Base-{7, 70}B, L3-Ins-{7, 70}B），DeepSeeks（DS-Base-{1.3, 6.7, 33}B, DS-Ins-{1.3, 6.7, 33}B），CodeLLaMas（CL-Ins-{7, 13, 34}B, CL-Base-{7, 13, 34}B），StarCoder2（SC2-Base-{3,7,15}B），CodeQwen等开源模型。此外，我们还包括了从CL-Base-34B微调的Phind-34B模型，以及从CL-Base-7B和DS-Base-6.7B微调的MagiCoders（MC-{6.7, 7}B）模型。完整的模型列表和估计的截止日期见附录C.1。

评估指标: 我们使用Pass@1（【27，Spoc: Search-based pseudocode to code，2019】；【11，Evaluating large language models trained on code，2021】）作为评估指标。具体来说，我们使用API或vLLM（【28，Efficient memory management for large language model serving with pagedattention，2023】）为每个问题生成10个候选答案。我们使用核采样，温度为0.2，top_p为0.95，并计算正确的程序或答案的比例。对于代码生成和自我修复场景，我们使用测试用例来验证程序的正确性，程序必须通过所有测试才被认为是正确的。对于代码执行场景，我们使用生成输出和真实输出之间的基于执行的正确性度量。对于测试输出预测场景，我们解析生成的响应以提取答案，并使用第2节中指定的等效性检查进行评分。

4.1 特定场景的设置

各场景的提示设置。每个场景的设置如下。请注意，基础模型仅在代码生成场景中使用，因为它们不容易遵循其他场景的格式。

代码生成。对于指令调优的模型，我们使用零样本提示，并遵循Hendrycks等人（【20，Measuring mathematical problem solving with the math dataset，2021】）的方法，添加适当的指令以生成函数式或标准输入格式的解决方案。对于基础模型，我们使用一个固定的一样本示例，为接受标准输入的问题和接受函数式输出的问题分别提供不同的示例。C.2节显示了所使用的高级零样本提示。

自我修复。与先前的工作Olausson等人（【52，Demystifying gpt self-repair for code generation，2023】）类似，我们使用在代码生成场景中生成的程序以及相应的错误反馈来构建自我修复场景的零样本提示。错误反馈的类型包括语法错误、运行时错误、错误答案和超时错误（如适用）。C.3节提供了计算错误反馈和相应提示的伪代码。

代码执行。我们在代码执行场景中使用少样本提示，包括有和没有思维链（COT）提示的两种情况。具体来说，我们使用一个不带COT的2样本提示和一个带COT的1样本提示，并手动详细说明步骤。这些提示在C.4节中有详细说明。

测试输出预测。我们使用一个零样本提示，查询模型在给定问题、函数签名和测试输入的情况下完成断言。我们在C.5节中提供了该提示。

A4 实验结果

5.1 避免污染

时间窗口评估机制的有效性。我们的基准测试一个显著的特点是能够在不同时间窗口发布的问题上评估模型。这使我们能够衡量模型在截止日期之后发布的问题上的性能，从而得到对未见问题的性能估计。

DeepSeek和GPT-4-O的污染检测。LiveCodeBench包含自2023年5月以来发布的问题。然而，DeepSeek模型于2023年9月发布，可能已经在我们基准测试中的一些问题上进行了训练。同样，OpenAI指出GPT-4-O的截止日期是11月。我们可以使用在截止日期之后发布的问题来衡量模型在基准测试上的性能，从而估计模型在先前未见问题上的性能。图1显示了这些模型在2023年5月至2024年2月不同月份发布的LeetCode问题上的LiveCodeBench代码生成和测试输出预测场景的性能。我们注意到DS-Ins-33B模型在2023年8月（其发布日期之前）之后性能急剧下降，这表明早期的问题确实可能被污染。这一趋势在其他LiveCodeBench场景中也是一致的，如修复和代码执行，如图10所示。与此同时，Guo等人（【18，Deepseek-coder: When the large language model meets programming–the rise of code intelligence，2024】）（第4.1节，最后一段）也承认了LeetCode污染的可能性，指出“模型在7月和8月举行的LeetCode竞赛中取得了更高的分数”。同样，GPT-4-O模型的性能在11月（其官方截止日期）之后发布的问题上有所下降。

不同平台上的污染情况。有趣的是，我们发现这种性能下降主要只发生在LeetCode问题上，而对于来自其他平台的问题，模型的性能在各个月份之间相对平稳。图11显示，所有模型在不同时期发布的AtCoder问题上表现相对稳定，可能除了5月和6月。

其他模型的性能表现。我们研究了最近发布
的其他模型的性能变化。特别是，GPT-4-Turbo、Gemini-Pro、Mistral-L和Claude-3s模型分别于2023年11月、2023年12月、2024年2月和2024年3月发布。请注意，GPT-4-Turbo（1106-preview版本）和Claude-3s的截止日期分别为2023年4月和2023年8月。无论发布或截止日期如何，我们没有发现各月份之间有任何剧烈的性能变化，如图12所示，特别是与DeepSeek模型相比。有趣的是，我们发现即使是DS-Base-33B模型也存在污染问题，其Pass@1从5月问题的约60分下降到9月LeetCode问题的约0分。这也表明DeepSeek模型的预训练中可能包含了竞赛问题，从而影响了所有由其训练的指令模型。最后，Codestral在23年5月至24年1月之间发布的问题上实现了Pass@1 36.5，而在24年2月之后的问题上实现了Pass@1 28.3。

5.2 性能与模型比较

评估设置。我们在LiveCodeBench上评估了34个指令调优模型（以及在代码生成场景中使用的18个基础模型）。这些模型涵盖了从闭源到开源及其各种微调变体。为了克服DeepSeek模型的污染问题，我们在下面的所有评估中只考虑自2023年9月以来发布的问题。图4显示了一部分模型在四个场景中的性能。我们在此强调我们的主要发现。

整体评估结果。我们在LiveCodeBench当前可用的四个场景中对模型进行了评估。图2的极坐标图沿轴线显示了模型在所有场景中的性能。首先，我们观察到模型的相对顺序在各个场景中基本保持一致。这一点也得到了场景间Pass@1指标高度相关的支持——如图13所示，所有配对的相关性均超过0.88。有趣的是，相关任务的相关性更大，生成和自我修复为0.98，测试输出预测和代码执行为0.96。生成和执行场景的相关性降至0.89。

不同场景下的性能差异。然而，尽管相关性很强，但性能的相对差异在不同场景中确实存在变化。例如，GPT-4-Turbo在代码生成场景中已经领先于GPT-4，在自我修复场景中进一步拉大了性能差距。同样，Claude-3-Opus和Mistral-L在涉及COT的任务中表现出色，特别是在代码执行和测试输出预测场景中。例如，Claude-3-Opus在测试输出预测场景中甚至超过了GPT-4-Turbo。同样，Mistral-L在代码生成和修复场景中落后于Claude-3-Sonnet，但在这两个场景中都超过了它。这些差异凸显了除了衡量代码生成能力之外，进行全面评估的必要性。

与HumanEval的比较。接下来，我们比较了代码生成性能指标在LiveCodeBench和HumanEval（评估编码能力的主要基准）之间的转换情况。请注意，我们使用的是HumanEval+版本的问题，因为它有更详尽的测试用例，更加可靠。图5显示了HumanEval+上的Pass@1与LCB-Easy代码生成场景上的Pass@1的散点图。我们发现相关性仅为中等，为0.72，而在LCB-Easy上的性能差异要大得多。

HumanEval的过拟合现象。此外，我们观察到模型聚集成两个群体，分别用红色和绿色阴影表示。绿色阴影区域的模型位于x=y线附近，表明它们在两个基准测试上的表现相似。另一方面，红色阴影区域的模型位于图表的左上区域，表明它们只在HumanEval+上表现良好，但在LiveCodeBench上表现不佳。有趣的是，绿色阴影的集群包含基础模型或闭源模型，而红色阴影的集群主要包含开源模型的微调变体。这两个分离良好的集群表明，许多在HumanEval上表现良好的模型可能在该基准上过拟合，其性能无法很好地迁移到LiveCodeBench中存在的其他领域或难度级别的问题上。

过拟合原因分析与实例。事实上，HumanEval是一个较简单的基准，包含小型且独立的编程问题，因此更容易过拟合。相比之下，LiveCodeBench的问题来源于信誉良好的编码平台，提供更具挑战性、多样性和难度更高的问题。这种潜在的过拟合尤其体现在DS-Ins-1.3B上，它在HumanEval+上实现了59.8%的Pass@1，但在LCB-Easy上仅为26.3%。因此，尽管它在HumanEval+上的性能优于Gemini-Pro和Claude-Ins-1，但在LCB-Easy上表现却差得多。同样，CodeQwen、DS-Ins-6.7B和MC-6.7B在HumanEval+上表现优于Mistral-L、Claude-2和Claude-3-Sonnet，但在LCB-Easy上却差得多。

凸显顶尖模型与开源模型的差距。我们评估的一个显著发现是，在所有场景中，顶尖（SoTA）模型与开源模型之间存在巨大差距。特别是，GPT-4-Turbo、GPT-4、Gemini-Pro-1.5和Claude-3-Opus在各项基准测试中均领先，与其他模型有很大的性能差距。这使得LiveCodeBench与之前的基准测试（如HumanEval）有所不同，在那些基准测试中，各种开源模型已经取得了相似或更好的性能。例如，DS-Ins-33B在HumanEval+上仅比GPT-4-Turbo落后4.3个点，但在LCB代码生成场景中落后16.2个点（69%）。这种差距在其他场景中要么保持，要么有时甚至会放大。例如，考虑测试输出预测和代码执行（带COT），GPT-4-Turbo分别领先DS-Ins-33B模型96%和134%！

顶尖模型代码质量分析。我们定性分析了领先模型GPT-4-Turbo生成的代码样本，发现它生成的代码更具可读性。具体来说，代码包含了更多的内联自然语言注释，在生成代码之前进行推理或规划。我们通过定量验证了这一点，发现GPT-4-Turbo生成的代码比GPT-4多使用了19.5倍的注释标记。

基础模型比较。我们使用了四个系列的基础模型——L3-Base、DeepSeek、CodeLLaMa和StarCoder2，并在代码生成场景中对它们进行了比较。所有模型都使用了一样本提示，以避免任何格式化和答案提取问题。我们发现L3-Base和DS模型明显优于CodeLLaMa和StarCoder2基础模型，DS-Base-6.7B模型甚至超过了CL-Base-34B和SC2-Base-15B模型。接下来，我们观察到SC2-Base-15B也优于CL-Base-34B模型（与Lozhkov等人（【40，Starcoder 2 and the stack v2: The next generation，2024】）的发现相似）。请注意，一些LiveCodeBench特有的差异可能归因于数据整理方法。例如，StarCoder2模型（以及可能如5.1节所讨论的DeepSeek模型）在预训练语料库中使用了竞赛问题。

后训练的作用。我们发现，对于代码生成场景，后训练提高了在HumanEval+和LiveCodeBench上的性能。特别是，L3-Ins-70B、DS-Ins-33B和Phind-34B在LCB上分别取得了28.3、23.6和21的Pass@1，相比其基础模型分别提高了8.2、7.3和9.5个点。在之前的基准测试（如HumanEval+）中也观察到了类似的增益。这凸显了良好的后训练数据集对于构建强大的LLM的重要性。

后训练数据与泛化能力。同时，我们注意到基础模型在LCB代码生成和HumanEval+基准上的性能是一致的，并且位于图5中绿色阴影区域内或附近。然而，微调的开源模型表现出更大的性能差距，在HumanEval+上的性能要好得多。另一方面，闭源模型在两个基准上的表现仍然一致。这表明开源模型的微调数据可能不如闭源模型的数据多样化，导致对不同类型问题的泛化能力不足。

开源指令调优模型比较。在这里，我们比较了L3-Base、DeepSeek和CodeLLaMa基础模型的各种不同模型大小的微调变体。我们发现，在大多数场景中，微调的L3-Base和DeepSeek模型在性能上领先，其次是Phind-34B和CodeLLaMa模型。总的来说，我们发现模型性能与模型大小相关。例如，Phind-34B模型在所有场景中都优于6.7B模型。

闭源模型比较。我们评估了一系列闭源（API访问）模型，涵盖了GPT、Claude、Gemini和Mistral等不同模型系列。我们发现GPT-4-Turbo和Claude-3-Opus在所有场景中排名最高，其次是Mistral-L和Claude-3-Sonnet模型。最后，Gemini-Pro和GPT-3.5-turbo处于模型的较低端。模型之间的相对差异因场景而异。例如，GPT-4-Turbo在自修复方面表现出显著的改进（在LCB-Medium问题上从24.5%提高到36.9%），而Gemini-Pro仅从8.5%提高到9.4%。同样，如上所述，Claude-3-Opus和Mistral-L在测试输出预测和代码执行场景中表现得更好。

开源模型与闭源模型的对比。总的来说，闭源（API）访问模型系列通常优于开源模型。只有三个模型缩小了这一差距，即L3-Ins-70B、Mixtral和DS-Ins-33B，它们达到了闭源模型的性能水平。例如，在代码生成场景中（图2右），这些模型接近甚至超过了像Gemini-Pro、GPT-3.5-turbo和Claude-3-Sonnet这样的闭源模型。性能因场景而异，闭源模型在测试输出预测和代码执行场景中表现更好。总的来说，我们的发现证实了强大的基础模型和高质量的后训练数据集是构建优秀代码LLM的可行方案。

A7 补充细节

第6节 相关工作

6.1 代码生成

代码生成的语言模型。从Codex（【11，Evaluating large language models trained on code，2021】）开始，出现了十几种代码LLM。其中包括CodeT5（【84，Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation，2021】；【83，Codet5+: Open code large language models for code understanding and generation，2023】）、CodeGen（【50，Codegen: An open large language model for code with multi-turn program synthesis，2022】）、SantaCoder（【2，Santacoder: don’t reach for the stars!，2023】）、StarCoder（【32，Starcoder: may the source be with you!，2023】）、AlphaCode（【35，Competition-level code generation with alphacode，2022】）、InCoder（【14，Incoder: A generative model for code infilling and synthesis，2022】）和CodeGeeX（【92，Codegeex: A pre-trained model for code generation with multilingual evaluations on humaneval-x，2023】）。截至2024年5月，L3-Base和DeepSeek（【7，Deepseek llm: Scaling open-source language models with longtermism，2024】）、StarCoder（【40，Starcoder 2 and the stack v2: The next generation，2024】；【32，Starcoder: may the source be with you!，2023】）和CodeLLaMa（【64，Code llama: Open foundation models for code，2023】）是最受欢迎的开源模型。许多下游模型是通过在合成生成的数据上微调它们而产生的，例如WizardCoder（【42，Wizardcoder: Empowering code large language models with evol-instruct，2023】）、MagiCoders（【86，Magicoder: Source code is all you need，2023】）和Phind-34B。

代码生成基准测试。已经提出了许多基准来比较和评估这些模型。这些基准主要关注从自然语言生成Python代码：HumanEval（【11，Evaluating large language models trained on code，2021】）、HumanEval+（【39，Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation，2023】）、APPS（【20，Measuring mathematical problem solving with the math dataset，2021】）、CodeContests（【35，Competition-level code generation with alphacode，2022】）、MBPP（【5，Program synthesis with large language models，2021】）、L2CEval（【49，L2ceval: Evaluating language-to-code generation capabilities of large language models，2023】）。它们的变体已被提出以覆盖更多语言（【4，Multi-lingual evaluation of code generation models，2022】；【92，Codegeex: A pre-trained model for code generation with multilingual evaluations on humaneval-x，2023】；【9，Multipl-e: A scalable and extensible approach to benchmarking neural code generation，2022】；【82，Recode: Robustness evaluation of code generation models，2022】）。许多基准测试专注于API中的代码生成。像DS-1000（【29，Ds-1000: A natural and reliable benchmark for data science code generation，2023】）、ARCADE（【90，Natural language to code generation in interactive data science notebooks，2022】）、NumpyEval（【94，Toolcoder: Teach code generation models to use apis with search tools，2023】）和PandasEval（【23，Jigsaw: Large language models meet program synthesis，2022】）等基准专注于数据科学API。其他基准则衡量使用更广泛的API或通用软件工程任务，例如JuICe（【1，Juice: A large scale distantly supervised dataset for open domain context-based code generation，2019】）、APIBench（【54，Gorilla: Large language model connected with massive apis，2023】）、RepoBench（【39，Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation，2023】）、ODEX（【85，Execution-based evaluation for open-domain code generation，2022】）、SWE-Bench（【25，Swe-bench: Can language models resolve real-world github issues?，2023】）、GoogleCodeRepo（【72，Repository-level prompt generation for large language models of code，2023】）、RepoEval（【93，Repocoder: Repository-level code completion through iterative retrieval and generation，2023】）和Cocomic-Data（【13，Cocomic: Code completion by jointly modeling in-file and cross-file context，2022】）。

竞赛编程基准与方法。一些基准专门衡量竞赛编程能力，例如APPS（【20，Measuring mathematical problem solving with the math dataset，2021】）、CodeContests（【35，Competition-level code generation with alphacode，2022】）、CodeScope（【88，Codescope: An execution-based multilingual multitask multidimensional benchmark for evaluating llms on code understanding and generation，2023】）、xCodeEval（【26，xcodeeval: A large scale multilingual multitask benchmark for code understanding, generation, translation and retrieval，2023】）和LeetCode-Hard（【71，Reflexion: Language agents with verbal reinforcement learning，2023】）以及TACO（【33，Taco: Topics in algorithmic code generation dataset，2023】）。诸如AlphaCode（【35，Competition-level code generation with alphacode，2022】）、AlphaCode 2（【15，Gemini: a family of highly capable multimodal models，2023】）、ALGO（【96，Algo: Synthesizing algorithmic programs with generated oracle verifiers，2023】）、Parsel（【97，Parsel: A unified natural language framework for algorithmic reasoning，2022】）、代码清理（【24，Llm-assisted code cleaning for training accurate code generators，2023】）、代码解释（【31，Explaining competitive-level programming solutions using llms，2023】）、类比推理（【91，Large language models as analogical reasoners，2023】）和AlphaCodium（【60，Code generation with alphacodium: From prompt engineering to flow engineering，2024】）等方法一直在推动LLM在该领域可能性的边界。LiveCodeBench与这些基准最大的区别在于，我们的基准是持续更新的，问题策划具有均衡的难度，更高的测试和问题质量，并包含更多场景，如代码修复、代码执行和测试输出预测，为构建代理式编码系统捕捉了更多方面。

6.2 整体性任务

其他场景的相关工作。LiveCodeBench将自我修复、测试输出预测和代码执行作为额外的场景。下面我们注意到这些领域的相关工作。

代码修复。（【12，Teaching large language models to self-debug，2023】；【52，Demystifying gpt self-repair for code generation，2023】；【44，Self-refine: Iterative refinement with self-feedback，2023】；【56，Check your facts and try again: Improving large language models with external knowledge and automated feedback，2023】；【95，Self-edit: Fault-aware code editor for code generation，2023】）已经研究了现有代码LLM基准的自我修复。特别是，这些方法使用错误反馈来让模型改进，启发了我们的代码修复场景。

代码执行。代码执行首次在Austin等人（【5，Program synthesis with large language models，2021】）和Nye等人（【51，Show your work: Scratchpads for intermediate computation with language models，2021】）的研究中被探讨。LiveCodeBench的执行场景尤其受到CRUXEval（【17，Cruxeval: A benchmark for code reasoning, understanding and execution，2024】）的启发，这是一个最近的基准，用于衡量代码LLM的推理和执行能力。我们与CRUXEval的不同之处在于，我们的基准是实时的，而且我们的函数更复杂且是人类编写的（不像CRUXEval中由Code Llama生成）。

测试生成。使用LLM进行测试生成已在（【98，No more manual tests? evaluating and improving chatgpt for unit test generation，2023】；【67，An empirical evaluation of using large language models for automated unit test generation，2024】；【80，Methods2test: A dataset of focal methods mapped to test cases，2022】；【81，On learning meaningful assert statements for unit test cases，2020】）中进行了探索。此外，Chen等人（【10，Codet: Code generation with generated tests，2022】）证明了LLM可以辅助生成竞赛编程问题的测试用例输入/输出，从而提高生成代码的准确性，这启发了我们的测试生成场景。然而，LiveCodeBench的测试生成场景的独特之处在于它将测试输入和输出解耦，从而允许更恰当的评估。

其他相关任务。最后，一些工作还研究了其他任务和场景，如类型预测（【47，Type4py: Practical deep similarity learning-based type inference for python，2022】；【87，Typet5: Seq2seq type inference using static analysis，2023】；【45，Nl2type: inferring javascript function types from natural language information，2019】）、代码摘要（【30，A neural model for generating natural language summaries of program subroutines，2019】；【22，Summarizing source code using a neural attention model，2016】；【6，A parallel corpus of python functions and documentation strings for automated code documentation and code generation，2017】；【19，Codesc: A large code-description parallel dataset，2021】；【3，code2seq: Generating sequences from structured representations of code，2018】）、代码安全（【36，Can we generate shellcodes via natural language? an empirical study，2022】；【55，Asleep at the keyboard? assessing the security of github copilot’s code contributions，2022】；【79，Llmseceval: A dataset of natural language prompts for security evaluations，2023】）等。

6.3 污染

数据污染问题的研究现状。数据污染和测试用例泄露问题已受到相当大的关注（【53，Gpt-4 technical report，2024】；【16，Time travel in llms: Tracing data contamination in large language models，2023】；【87，Typet5: Seq2seq type inference using static analysis，2023】；【61，To the cutoff... and beyond? a longitudinal perspective on LLM data contamination，2024】），因为LLM可能在基准测试上进行了训练。Sainz等人（【66，Did chatgpt cheat on your test?，2023】）通过简单地提示模型来突出其污染，从而证明了污染的存在。一些检测方法也被建立起来以避免这些情况（【70，Detecting pretraining data from large language models，2023】；【99，Don’t make your llm an evaluation benchmark cheater，2023】）。对于代码，Riddell等人（【59，Quantifying contamination in evaluating code generation capabilities of language models，2024】）使用编辑距离和基于AST的语义相似性来检测污染。

第7节 局限性

基准测试规模。LiveCodeBench代码生成场景目前包含从5月到2月发布的400多个问题实例。为了考虑DeepSeek中的污染，我们只对模型截止日期之后发布的问题进行评估。这导致我们的最终评估中只使用了349个问题，这可能会因为问题集样本而增加噪音。我们目前估计LiveCodeBench代码生成因此问题导致的性能变化为1-1.5%（通过从511个问题的数据集中进行349个问题的自助采样测量）。其他场景，即自我修复、代码执行和测试输出预测，分别包含349、188和254个问题，也会有类似的性能变化。因此，我们建议在比较性能差异较小的模型时进行适当的判断。请注意，HumanEval有164个问题，也会遇到类似的问题。

新模型的评估挑战与解决方案。对于截止日期较近的新模型，这个问题会更加严重，因为它们可能只能访问一个更小的评估集。随着LiveCodeBench的发展，我们提出了两种解决方案来解决这个问题。首先，我们将使用其他竞赛平台来收集问题，从而允许将更多最近的问题添加到基准测试中。此外，我们还希望通过一个专门为模型评估构建的未发布的私有测试集来补充这一点。这些问题将采用与当前问题类似的形式，并在模型提交到LiveCodeBench平台进行评估时使用。这将减少对公开可访问问题的依赖，并为模型提供更稳健的评估，同时为社区提供类似问题的公开访问，类似于Kaggle等流行平台采用的策略。

专注于Python。LiveCodeBench目前只关注Python，这可能无法提供足够的信息来了解模型在其他语言中的能力。然而，由于我们收集了问题陈述和序列化的测试用例，一旦使用了适当的评估引擎，添加新的编程语言将是直接的。

对提示的鲁棒性。最近的研究发现，不充分的提示可能导致巨大的性能差异。在这里，我们要么不对模型进行提示调整，要么根据系统提示和分隔符标记进行微调。这可能导致我们的结果出现性能差异。我们的发现和模型比较顺序在LiveCodeD Bench场景中具有普适性，并且与HumanEval上观察到的性能趋势基本一致，使得这个问题不那么突出。

特定场景下的鲁棒性问题。这个问题在开源模型的代码执行场景中使用COT提示时尤其明显。有趣的是，开源模型在与直接代码执行基线相比时，性能甚至更差。请注意，我们对闭源模型使用了相同的提示，所有这些模型都从COT中显示出显著的改进。虽然使用的提示可能不是最优的，但这凸显了开源模型在执行思维链方面与闭源模型相比表现更差。

问题领域。编程是一个广阔的领域，以各种形式出现，如编程谜题、竞赛编程和现实世界的软件开发。不同的领域可能有各自的要求、约束、挑战和难度级别。LiveCodeBench目前专注于从三个平台获取的竞赛问题。这可能不代表LLM编程能力的“最通用”概念。特别是，LLM在现实世界中的使用是基于用户提出的开放式和无约束的问题。因此，我们建议将LiveCodeBench作为评估LLM的起点，并进一步使用领域特定的评估来根据需要衡量和比较特定设置中的LLM。

A5 结论

本文提出了LiveCodeBench，一个用于评估代码LLM的新基准。我们的基准通过引入实时评估来缓解现有基准中的污染问题，并强调代码生成之外的场景，以考虑LLM更广泛的编码能力。LiveCodeBench是一个可扩展的框架，将不断更新新的问题、场景和模型。我们的评估揭示了新的发现，例如污染检测和在HumanEval上可能的过拟合。我们希望LiveCodeBench能够促进对当前代码LLM的理解，并通过我们的发现指导该领域的未来研究。

A6 附录

A 数据集

A.1 许可证

数据使用声明。与Hendrycks等人（【20，Measuring mathematical problem solving with the math dataset，2021】）类似，我们只从竞赛网站——LeetCode、AtCoder和CodeForces——抓取问题陈述、真实解决方案和测试用例。此外，我们只抓取网站的公开可见部分，避免任何可能需要付费、登录或与网站互动的数据收集。遵循Hendrycks等人（【20，Measuring mathematical problem solving with the math dataset，2021】），我们遵守合理使用条款§107：“对受版权保护作品的合理使用，包括……学术或研究等用途，不构成版权侵犯”，其中合理使用由“使用的目的和性质，包括该使用是否具有商业性质或用于非营利教育目的”、“所使用部分相对于整个受版权保护作品的数量和实质性”以及“使用对受版权保护作品的潜在市场或价值的影响”来确定。最后，我们仅将收集的问题用于学术目的，并且不用于训练模型。

A.2 基于生成器的测试生成

测试生成器提示。我们使用GPT-4-Turbo来构建输入生成器。以下提示（图6和图7）提供了一次性提示模板，用于合成随机和对抗性输入生成器。这些生成器定义了一个函数，返回按某种分布采样的参数。然后执行这些生成器以构建输入，这些输入在收集到的正确程序上进行验证。我们对随机和对抗性设置使用不同的生成器，因为编程问题通常有随机采样输入可能无法捕捉到的边界情况。我们构建了2个随机输入生成器，4个对抗性输入生成器，并检查采样的输入是否适用于正确的程序。最后，收集的输入数量被限制在100个以内，以便进行高效评分（使用随机选择）。我们发现我们的生成器已经能很好地工作，但未来的工作可以研究构建此类生成器的设计空间。

CodeForces的特殊处理。请注意，对于CodeForces，由于只使用了9个问题，我们以半自主的方式构建生成器。

A.3 代码执行

数据集构成。LiveCodeBench的代码执行部分由来自85个不同问题的479个样本组成。为了在保持基准测试小巧易用的同时鼓励其多样性，我们为每个给定问题设置了六个样本的限制。这些样本程序和相应的测试用例是从所有通过筛选的样本中均匀随机选择的。

过滤标准。具体的过滤标准如下：

• 编译时：代码长度在100到500个字符之间，无语法错误，包含所有必要的导入。
• 运行时：无浮点运算，真除法，指数运算，其他整数运算必须至少有一个参数≤3，字符串和列表操作必须至少有一个参数长度≤3，在2秒内完成运行，执行步骤“合理”（大约在1000个Python字节码操作以下）。

被过滤的程序示例。下面我们在列表中给出了两个被过滤掉的程序的例子。我们最终的基准测试由来自85个问题的479个样本组成，但由于其动态性，规模将不断增加。

# 示例1：因递归深度和计算复杂性被过滤
def check(x, t):
    if x == '':
        return t == 0
    if t < 0:
        return False
    for i in range(len(x)):
        if check(x[:i], t - int(x[i:])):
            return True
    return False

@cache
def punishmentNumber(n: int) -> int:
    if n == 0:
        return 0
    ans = punishmentNumber(n-1)
    if check(str(n * n), n):
        ans += n * n
    return ans

assert punishmentNumber(n = 37) == 1478

# 示例2：因预计算量大和循环次数过多被过滤
dp = [True for _ in range(int(1e6 + 5))]
MAXN = int(1e6 + 5)
p = []
dp[0] = False
dp[1] = False
for i in range(2, MAXN):
    if not dp[i]:
        continue
    p.append(i)
    for j in range(2 * i, MAXN, i):
        dp[j] = False

def findPrimePairs(n: int) -> List[List[int]]:
    res = []
    for i in range(1, n):
        if n % 2 == 1 and i > n//2:
            break
        if n % 2 == 0 and i > n//2:
            break
        if dp[i] and dp[n - i]:
            res.append([i, n - i])
    return res

assert findPrimePairs(n = 2) == []

数据集统计。如前所述，我们筛选代码长度在100到500个字符之间，以及执行步骤少于1000步的代码。我们数据集中的程序统计数据如图8所示。

LiveCodeBench UI

C 实验设置

C.1 模型

我们在表2中描述了研究中考虑的模型的详细信息。

C.2 代码生成

代码生成提示。下面我们提供了用于此场景的提示格式（为适应每个指令调优模型，添加了特殊标记的相应变体）。

你是一位专业的Python程序员。你将收到一个问题（问题规范），并需要生成一个符合规范且能通过所有测试的正确Python程序。除了程序本身，你不能返回任何其他内容。

### 问题：
{question.question_content}
{ if question.starter_code } ### 格式：{PromptConstants.FORMATTING_MESSAGE}
'''python
{question.starter_code}

{ else }
### 格式：{PromptConstants.FORMATTING_WITHOUT_STARTER_MESSAGE}
'''python
# YOUR CODE HERE
'''
{ endif }
### 回答：（使用提供的带有反引号的格式）

C.3 自我修复

自我修复提示。下面我们提供了用于此场景的提示格式（为适应每个指令调优模型，添加了特殊标记的相应变体）。

{if check_result.result_status is "Wrong Answer"}
上面的代码不正确，并且没有通过测试用例。
输入：{wrong_testcase_input}
输出：{wrong_testcase_output}
预期：{wrong_testcase_expected}

{elif check_result.result_status is "Time Limit Exceeded"}
上面的代码不正确，并且超出了时间限制。
输入：{wrong_testcase_input}

{elif check_result.result_status is "Runtime Error"}
上面的代码不正确，并且有一个运行时错误。
输入：{wrong_testcase_input}
错误信息：{wrong_testcase_error_message}

{endif}

帮助用户编写一个解决问题的程序。用户写了一些代码，但有一些错误，没有通过测试。你将通过首先给出一个简明（最多2-3句话）的文本解释，说明代码有什么问题，来帮助用户。在你指出代码的问题之后，你将生成一个修复后的程序版本。你必须将整个修复后的程序放在代码分隔符内，并且只放一次。

### 问题：
{question.question_content}
### 回答：'''python
{code.code_to_be_corrected}

### 格式：{PromptConstants.FORMATTING_CHECK_ERROR_MESSAGE}
### 回答：（使用提供的带有反引号的格式）

C.4 代码执行

代码执行提示。下面我们提供了带和不带CoT的代码执行提示。这些提示是根据（【17，Cruxeval: A benchmark for code reasoning, understanding and execution，2024】）中的提示修改而来的，以适应我们基准测试中样本的格式。

不带CoT的提示

你将得到一个Python函数和一个包含函数输入的断言。请用一个字面值（无未简化的表达式，无函数调用）来完成这个断言，该字面值是执行所提供代码在给定输入上的输出，即使函数不正确或不完整。不要输出任何额外信息。请在[ANSWER]和[/ANSWER]标签中提供带有正确输出的完整断言，遵循示例。

# [PYTHON]
def repeatNumber(number : int) -> int:
    return number
assert repeatNumber(number = 17) == ??
[/PYTHON]
[ANSWER]
assert repeatNumber(number = 17) == 17
[/ANSWER]

[PYTHON]
def addCharacterA(string : str) -> str:
    return string + "a"
assert addCharacterA(string = "x9j") == ??
[/PYTHON]
[ANSWER]
assert addCharacterA(string = "x9j") == "x9ja"
[/ANSWER]

[PYTHON]
{code}
assert {input} == ??
[/PYTHON]
[ANSWER]

带CoT的提示

你将得到一个Python函数和一个包含函数输入的断言。请用一个字面值（无未简化的表达式，无函数调用）来完成这个断言，该字面值是执行所提供代码在给定输入上的输出，即使函数不正确或不完整。不要输出任何额外信息。在得出答案之前，请逐步执行程序，并在[ANSWER]和[/ANSWER]标签中提供带有正确输出的完整断言，遵循示例。

[PYTHON]
def performOperation(s):
    s = s + s
    return "b" + s + "a"
assert performOperation(s = "hi") == ??
[/PYTHON]
[THOUGHT]
让我们一步步执行代码：
1. 定义了函数performOperation，它接受一个参数s。
2. 函数以参数"hi"被调用，所以在函数内部，s的初始值是"hi"。
3. 在函数内部，s与自身连接，所以s变成了"hihi"。
4. 然后函数返回一个新字符串，以"b"开头，后跟s的值（现在是"hihi"），并以"a"结尾。
5. 因此，函数的返回值是"bhihia"。
[/THOUGHT]
[ANSWER]
assert performOperation(s = "hi") == "bhihia"
[/ANSWER]

[PYTHON]
{code}
assert {input} == ??
[/PYTHON]
[THOUGHT]

C.5 测试输出预测

测试输出预测提示。下面我们提供了用于此场景的提示格式（为适应每个指令调优模型，添加了特殊标记的相应变体）。

指令：你是一个有用的编程助手和专业的Python程序员。你正在帮助一个用户编写一个测试用例，以帮助检查函数的正确性。用户已经为测试用例编写了一个输入。你将计算测试用例的输出，并在markdown代码块中用正确的输出写出整个断言语句。

问题：{problem_statement}

函数：

{function_signature}

请完成以下测试用例：
'''
assert {function_name}({testcase_input}) == # TODO

### 回应：

D 更多结果

D.1 污染

更多污染证据。图10展示了DeepSeek在自我修复和测试输出预测场景中的污染情况。

D.2 所有结果

详细结果图表。下面我们提供了包含LiveCodeBench不同场景结果的表格。

代码生成性能表

自我修复性能表

测试输出预测性能表

代码执行性能表

E 定性示例

E.1 代码执行

GPT-4失败案例。我们展示了5个来自代码执行任务的例子，即使使用了CoT，GPT-4（gpt-4-1106-preview）仍然难以正确执行。

# 错误 1
def countWays(nums: List[int]) -> int:
    nums.sort()
    n = len(nums)
    ans = 0
    for i in range(n + 1):
        if i and nums[i-1] >= i:
            continue
        if i < n and nums[i] <= i:
            continue
        ans += 1
    return ans
assert countWays(nums = [6, 0, 3, 3, 6, 7, 2, 7]) == 3
# GPT-4 + CoT 输出: 1, 2, 4, 5

# 错误 2
def minimumCoins(prices: List[int]) -> int:
    @cache
    def dfs(i, free_until):
        if i >= len(prices):
            return 0
        res = prices[i] + dfs(i + 1, min(len(prices) - 1, i + i + 1))
        if free_until >= i:
            res = min(res, dfs(i + 1, free_until))
        return res
    dfs.cache_clear()
    return dfs(0, -1)
assert minimumCoins(prices = [3, 1, 2]) == 4
# GPT-4 + CoT 输出: 1, 3, 5, 6

# 错误 3
def sortVowels(s: str) -> str:
    q = deque(sorted((ch for ch in s if vowel(ch))))
    res = []
    for ch in s:
        if vowel(ch):
            res.append(q.popleft())
        else:
            res.append(ch)
    return ''.join(res)
assert sortVowels(s = 'lEetcOde') == 'lEOtcede'
# GPT-4 + CoT 输出: "leetecode", "lEetecOde", "leetcede", "leetcEde", "leetcOde"

# 错误 4
def relocateMarbles(nums: List[int], moveFrom: List[int], moveTo: List[int]) -> List[int]:
    nums = sorted(list(set(nums)))
    dd = {}
    for item in nums:
        dd[item] = 1
    for a,b in zip(moveFrom, moveTo):
        del dd[a]
        dd[b] = 1
    ll = dd.keys()
    return sorted(ll)
assert relocateMarbles(nums = [1, 6, 7, 8], moveFrom = [1, 7, 2], moveTo = [2, 9, 5]) == [5, 6, 8, 9]
# GPT-4 + CoT 输出: [2, 6, 8, 9], [2, 5, 6, 8, 9], KeyError

# 错误 5
def minimumSum(nums: List[int]) -> int:
    left, right, ans = [inf], [inf], inf
    for num in nums:
        left.append(min(left[-1], num))
    for num in nums[::-1]:
        right.append(min(right[-1], num))
    right.reverse()
    for i, num in enumerate(nums):
        if left[i] < num and right[i + 1] < num:
            ans = min(ans, num + left[i] + right[i + 1])
    return ans if ans < inf else -1
assert minimumSum(nums = [6, 5, 4, 3, 4, 5]) == -1
# GPT-4 + CoT 输出: 10, 11, 12

方法细节中的引用汇总

以下是论文方法论部分（第2节、第3节）所引用的参考文献及其在文中的描述：

1. 引用: 【8】 Boehm, B. (2006). A view of 20th and 21st century software engineering. In Proceedings of the 28th International Conference on Software Engineering.

   • 引用位置: 第2节 整体评估，第1段。
   • 原文描述: 引用此文献以支持“现实世界的软件工程需要的专业知识远不止代码生成，还包括合成有信息的测试用例、调试错误代码、理解现有代码和编写文档等...是软件开发过程中至关重要的部分，有助于提高代码的质量、可维护性和可靠性”这一论点。

2. 引用: 【60】 Ridnik, T., Kredo, D., & Friedman, I. (2024). Code generation with alphacodium: From prompt engineering to flow engineering. arXiv preprint arXiv:2401.08500.

   • 引用位置: 第2节 整体评估，第1段。
   • 原文描述: 以AlphaCodium为例，说明通过结合自然语言推理、测试用例生成、代码生成和自我修复的复杂工作流，可以显著提升LLM在编程问题上的表现，从而论证更广泛编程能力的重要性。

3. 引用:

   • 【52】 Olausson, T. X., Inala, J. P., Wang, C., Gao, J., & Solar-Lezama, A. (2023). Demystifying gpt self-repair for code generation. arXiv preprint arXiv:2306.09896.
   • 【71】 Shinn, N., Cassano, F., Gopinath, A., Narasimhan, K. R., & Yao, S. (2023). Reflexion: Language agents with verbal reinforcement learning. In Thirty-seventh Conference on Neural Information Processing Systems.
   • 【12】 Chen, X., Lin, M., Schärli, N., & Zhou, D. (2023). Teaching large language models to self-debug. arXiv preprint arXiv:2304.05128.
   • 引用位置: 第2节 整体评估，自我修复场景段落。
   • 原文描述: 表明“自我修复”场景的设计是基于这些先前测试LLM自我修复能力的工作。

4. 引用: 【17】 Gu, A., Rozière, B., Leather, H., Solar-Lezama, A., Synnaeve, G., & Wang, S. I. (2024). Cruxeval: A benchmark for code reasoning, understanding and execution. arXiv preprint arXiv:2401.03065.

   • 引用位置: 第2节 整体评估，代码执行场景段落；第3.3节 场景特定基准构建，代码执行段落。
   • 原文描述: 表明“代码执行”场景的设置是基于CRUXEval中使用的输出预测设置，并且基准构建过程也受到了CRUXEval的启发。

5. 引用: 【10】 Chen, B., Zhang, F., Nguyen, A., Zan, D., Lin, Z., Lou, J.-G., & Chen, W. (2022). Codet: Code generation with generated tests. arXiv preprint arXiv:2207.10397.

   • 引用位置: 第2节 整体评估，测试用例输出预测场景段落。
   • 原文描述: 表明“测试用例输出预测”任务遵循了与CodeT相似的设置，即仅从问题陈述生成测试，但LiveCodeBench的不同之处在于提供了固定的测试输入，让模型只预测输出。

6. 引用: 【39】 Liu, J., Xia, C. S., Wang, Y., & Zhang, L. (2023b). Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation. arXiv preprint arXiv:2305.01210.

   • 引用位置: 第3.1节 数据收集，测试收集段落。
   • 原文描述: 在无法直接获取平台测试用例时，遵循此文献的方法，使用LLM（GPT-4-Turbo）为问题生成测试。

7. 引用: 【53】 OpenAI. (2023). Gpt-4 technical report. arxiv 2303.08774.

   • 引用位置: 第3.1节 数据收集，问题难度段落。
   • 原文描述: 引用GPT-4在CodeForces上的低ELO评级（392），来说明竞赛编程对于当前LLM的挑战性，并论证进行难度分级和筛选的必要性。

8. 引用: 【20】 Hendrycks, D., Burns, C., Kadavath, S., Arora, A., Basart, S., Tang, E., Song, D., & Steinhardt, J. (2021). Measuring mathematical problem solving with the math dataset. arXiv preprint arXiv:2103.03874.

   • 引用位置: 第3.3节 场景特定基准构建，代码生成与自我修复段落；附录A.1 许可证。
   • 原文描述: 描述在处理AtCoder和CodeForces问题时，采用了与此文献类似的标准输入格式。在许可证部分，引用此文献作为类似数据抓取和合理使用声明的先例。