2403.07974_LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code¶
引用: 464(2025-07-22)
组织: UC Berkeley, MIT, Cornell
HuggingFace: https://huggingface.co/livecodebench
总结¶
LiveCodeBench 的评估框架
评估大型语言模型（LLM）在编程任务中的表现
从LeetCode、AtCoder和CodeForces三大竞赛平台收集2023年5月至2024年5月期间发布的新题目
构建了一个污染较少、内容更新及时、覆盖更广的评测集
核心设计原则
动态更新，防止数据污染
从竞赛平台（如LeetCode、AtCoder、CodeForces）收集每周更新的问题，并标注发布时间
对于新模型，仅评估其在发布时间晚于其训练截止日期的问题上的表现，避免训练数据中已包含该问题
全面评估多个代码能力
除了传统的“自然语言到代码生成”外，LiveCodeBench还评估以下三种能力：
Self-Repair：根据执行反馈修复错误程序，评估调试能力
Code Execution：给定程序和输入，输出执行结果，评估代码理解能力
Test Output Prediction：根据自然语言任务和输入，预测输出，评估测试输出生成能力
实证结果与发现
数据污染现象明显：LLM在训练阶段可能接触过早期问题，存在污染风险
LLM总结¶
主要介绍了一个名为 LiveCodeBench 的评估框架，用于全面且无污染地评估大型语言模型（LLM）在编程任务中的表现。
总结：
LiveCodeBench 是一个为代码领域设计的新型评估基准，旨在全面评估大型语言模型在编程任务中的能力，同时避免因模型训练数据中包含测试数据而导致的“污染”问题。该基准通过真实、多样、高质量的编程任务组合，测试模型在代码生成、调试、理解、优化等多个方面的综合能力。作者强调，该框架不依赖于任何模型训练中可能包含的数据，从而确保评估结果的公正性和有效性。这一方法为未来研究提供了一个更可靠、更公平的模型评估方式。
Abstract¶
该论文章节主要介绍了LiveCodeBench，这是一个用于评估大型语言模型（LLMs）在代码相关任务中的表现的新型基准测试平台。文章指出，随着LLMs的快速发展，传统评估基准（如HumanEval、MBPP）已无法全面衡量模型的能力。LiveCodeBench通过从LeetCode、AtCoder和CodeForces三大竞赛平台收集2023年5月至2024年5月期间发布的新题目，构建了一个污染较少、内容更新及时、覆盖更广的评测集。
除了基本的代码生成能力，LiveCodeBench还评估了LLMs在自我修复、代码执行、测试输出预测等方面的表现。文章中还展示了对大量基础模型和指令微调模型的评估结果，并探讨了数据污染问题、现有基准可能存在的过拟合现象，以及不同模型之间的性能比较。最后，作者承诺公开所有提示和模型生成结果，提供工具包供社区扩展和研究使用。
1 Introduction¶
该论文的引言部分主要探讨了当前大语言模型（LLMs）在代码相关任务中的广泛应用以及评估方法的不足，并提出了一个名为 LiveCodeBench 的新型代码能力评估基准。以下是该章节的核心内容总结：
一、背景与问题¶
代码领域的LLM发展迅速
多个代码专用模型（如Codestral、DeepSeek、GPT-4-O等）被提出，并广泛应用于程序修复、优化、测试生成、文档生成、SQL生成等领域。评估方法存在局限
尽管模型发展迅速，但评估手段相对滞后。现有基准（如HumanEval、MBPP、APPS）存在两个主要问题：评估范围局限：仅关注自然语言到代码生成任务，忽视了编程中的多种能力。
数据污染和过拟合风险：基准问题可能已被模型在训练中接触，导致评估结果失真。
二、LiveCodeBench的提出¶
为解决上述问题，作者提出了 LiveCodeBench，一个动态更新且无数据污染的代码能力评估框架。其核心设计原则包括：
动态更新，防止数据污染
通过从竞赛平台（如LeetCode、AtCoder、CodeForces）收集每周更新的问题，并标注发布时间。
对于新模型，仅评估其在发布时间晚于其训练截止日期的问题上的表现，避免训练数据中已包含该问题。
全面评估多个代码能力
除了传统的“自然语言到代码生成”外，LiveCodeBench还评估以下三种能力：Self-Repair：根据执行反馈修复错误程序，评估调试能力。
Code Execution：给定程序和输入，输出执行结果，评估代码理解能力。
Test Output Prediction：根据自然语言任务和输入，预测输出，评估测试输出生成能力。
高质量问题与测试用例
问题来源自经过验证的竞赛平台，确保题面清晰、测试充分。
平均每个问题提供约17个测试用例，保证评估的鲁棒性和可靠性。
平衡问题难度分布
通过平台提供的难度评分，筛选并分类问题，确保评估覆盖不同难度层级，避免模型表现趋同。
三、实证结果与发现¶
作者在LiveCodeBench上评估了18个基础模型和34个指令调优模型，得出以下关键结论：
数据污染现象明显
DeepSeek、GPT-4-O和Codestral等模型在训练截止日期后发布的LeetCode问题上表现显著下降，说明其在训练阶段可能接触过早期问题，存在污染风险。
模型能力在不同任务中表现差异大
不同模型在代码生成、自修、执行、测试预测等任务中的表现差异显著，强调了综合评估的重要性。
例如，Claude-3-Opus在测试预测任务上甚至优于GPT-4。
HumanEval存在过拟合风险
某些模型在HumanEval上表现良好，但在LiveCodeBench上表现较差，表明它们可能过拟合了HumanEval数据。
模型对比揭示能力差距
封闭API模型（如GPT、Claude、Gemini）普遍优于开放模型。
在LiveCodeBench中，GPT-4和GPT-4-Turbo在所有场景中表现最佳（除Claude-3-Opus外）。
四、相关工作对比¶
LiveCodeBench与已有方法相比具有以下优势：
时间分割评估：与Huang et al. (2023)类似，但覆盖了多个竞赛平台。
多任务评估：与Li et al. (2023c)和Singhal et al. (2024)不同，不仅关注生成任务，还引入了代码理解、调试和测试预测等能力。
污染检测机制：与Guo et al. (2024)相比，更系统地检测并避免了数据污染问题。
五、总结¶
LiveCodeBench 是一个动态更新、无污染、综合评估代码能力的基准平台，解决了传统评估方法在覆盖范围和公平性上的不足。通过实证分析，作者揭示了当前主流模型在真实代码任务上的表现差异，并提供了更准确、更公平的模型比较依据。
2 Holistic Evaluation¶
本章提出了一种对代码相关能力进行综合性评估（Holistic Evaluation）的方法，旨在更全面地衡量大语言模型（LLMs）在软件工程中的实际能力。
传统上，代码生成任务是评估模型代码能力的主要方式，但实际软件开发需要更多维度的技能，如测试用例生成、调试、代码理解、文档编写等。这些能力不仅对代码质量、可维护性和可靠性至关重要，也能帮助模型在代码生成任务中表现更好。文章以 AlphaCodium 为例，展示了在编程竞赛中结合自然语言推理、测试生成、代码生成和自修复的流程可以显著提升模型性能。
基于此，作者提出了 LiveCodeBench 评估框架，涵盖四种评估场景，每种场景都有清晰的自动化评估指标：
代码生成（Code Generation）
模型根据自然语言描述和示例输入输出生成代码，评估其是否能通过未见测试用例。使用 Pass@1 指标衡量生成代码的正确性。
自修复（Self-Repair）
模型在初始生成错误代码后，根据错误反馈（如异常信息或失败测试用例）进行修正。评估最终代码的正确性，仍使用 Pass@1 指标。
代码执行预测（Code Execution）
模型根据给定的代码片段和测试输入，预测代码执行的输出。评估方式是验证预测输出是否与实际执行结果一致。
测试用例输出预测（Test Case Output Prediction）
模型根据问题陈述和测试输入预测预期输出，不涉及测试输入的生成。该任务有助于评估模型对问题的理解能力和测试生成能力。
此外，作者提到 LiveCodeBench 是一个可扩展的框架，未来可以集成更多任务，如输入生成、程序总结、优化等。
总结：本章强调了对代码生成任务以外的多维度能力进行评估的重要性，并通过 LiveCodeBench 框架系统性地提出了四种评估场景，以更全面地衡量模型在实际软件开发中的潜力。
Figure 3: Overview of the different scenarios present in LiveCodeBench. Coding is multi-faceted and we propose evaluating LLMs on a suite of evaluation setups that capture various coding-related capabilities. Specifically, beyond the standard code generation setting, we consider three additional scenarios, namely self-repair, code execution, and a newly introduced test output prediction task.
3 Benchmark Curation¶
本节介绍了 LiveCodeBench 基准数据集的构建过程，主要涵盖问题的收集、筛选和分类，以及针对不同评估场景（如代码生成、测试输出预测等）的专门构建方法。作者从 LeetCode、AtCoder 和 CodeForces 三大编程竞赛平台收集问题，确保问题具有挑战性、清晰度及正确性。
3.1 数据收集（Data Collection）¶
使用 HTML 抓取工具从各平台收集问题及其元数据。
筛选出适合通过输入输出样例进行评估的问题，排除含图像、答案不唯一或需构造数据结构的问题。
收集每个问题的 自然语言描述（P）、测试用例（T）和 标准答案（S），并记录其 发布日期（D）。
通过时间窗口筛选问题，可以评估模型在不同时间点的表现，用于对比模型的演化能力。
测试用例优先使用平台提供的，若不可用则使用 LLM（如 GPT-4-Turbo）并结合上下文学习生成输入生成器。
对部分新问题，收集平台提供的失败测试，用于对抗性测试。
3.2 平台特定的处理（Platform Specific Curation）¶
LeetCode：收集 2023 年 4 月后所有周赛与双周赛的问题，包含问题描述、公共测试用例和用户提交代码。由于隐藏测试不可用，使用生成器生成测试，并收集部分失败测试。
AtCoder：仅收集 abc（初学者）比赛的问题，避免难度更高 arc 和 agc 比赛。根据平台难度评分（最高 500）将问题分为 Easy、Medium、Hard。
CodeForces：收集 Division 3 和 4 的问题，尽管经过筛选，仍比其他平台更难。根据评分将问题划分为不同难度等级，并因测试不完整需手动生成部分测试用例。
3.3 针对不同场景的基准构建（Scenario-specific benchmark construction）¶
代码生成与自我修复（Code Generation and Self-Repair）：
使用自然语言问题描述构建问题。
LeetCode 提供初始代码，AtCoder 和 CodeForces 使用标准输入格式。
使用收集或生成的测试用例评估生成代码的正确性。
最终共构建 511 个问题实例。
代码执行（Code Execution）：
参考 Gu 等人的方法，从 LeetCode 收集约 2000 个用户提交的正确代码。
通过编译时和运行时过滤，剔除结构复杂、执行步骤多的代码，并进行人工核查。
最终构建 479 个代码执行样本，来自 85 个问题。
测试输出预测（Test Case Output Prediction）：
使用 LeetCode 的自然语言问题描述和示例测试输入，构建测试输出预测任务。
示例输入对人类和 LLM 都有良好的测试代表性。
最终构建 442 个问题实例，来自 181 个 LeetCode 问题。
总结¶
本节详细介绍了 LiveCodeBench 基准的构建过程，包括问题的收集、筛选、测试生成以及针对不同评估场景的专门构建方法。通过结合多个编程竞赛平台的问题，并利用 LLM 辅助测试生成与筛选，构建了一个全面、无污染、适合评估大语言模型代码能力的高质量基准数据集。
4 Experiment Setup¶
本章节主要介绍了实验的设置，包括通用设置和针对不同场景的特定设置，内容总结如下：
实验模型设置¶
模型范围：评估了 52个模型，模型参数规模从 1.3B 到 70B 不等，涵盖基础模型、指令调优模型、开源模型和闭源模型。
模型类别：包括 GPT 系列（GPT-3.5-turbo、GPT-4 等）、Claude、Gemini、Mistral、LLaMa-3、DeepSeek、CodeLLaMA、StarCoder2、CodeQwen 等。
调优模型：还包括从基础模型微调得到的模型，如 Phind-34B、MagiCoders。
完整列表：详见附录 C.1。
评估指标¶
主要指标：使用 Pass@1 指标（Kulal et al., 2019；Chen et al., 2021），计算生成的代码中能通过测试的比例。
生成方式：为每个问题生成 10个候选答案，使用 API 或 vLLM（Kwon et al., 2023）生成。
采样策略：采用 nucleus sampling，温度设为 0.2，top_p 设为 0.95。
正确性判断：
代码生成与自修复场景：程序必须通过所有测试才算正确。
代码执行场景：通过与真实输出对比判断正确性。
测试输出预测场景：从生成的回答中提取答案，并通过等价性检查评分。
不同场景的实验设置¶
代码生成（Code Generation）¶
指令调优模型：采用 zero-shot prompt，并添加适当的指令生成解决方案（函数式或 stdin 格式）。
基础模型：使用 one-shot 示例，并为两种输入类型（stdin 和函数输出）提供不同示例。
提示模板：详见附录 C.2。
自修复（Self Repair）¶
零样本提示：基于代码生成阶段的输出和错误反馈构建。
错误类型：包括语法错误、运行时错误、答案错误、超时错误。
方法细节：伪代码和提示结构详见附录 C.3。
代码执行（Code Execution）¶
提示方式：
使用 few-shot prompt，包括有和无 chain-of-thought（COT） 两种方式。
具体为：2-shot 不带 COT，1-shot 带详细步骤的 COT。
提示内容：详见附录 C.4。
测试输出预测（Test Output Prediction）¶
零样本提示：给定问题、函数签名和测试输入，要求模型补全断言。
提示结构：详见附录 C.5。
总结¶
本节详细描述了实验的整体设置，包括评估的模型类别和参数规模、评估指标 Pass@1 的使用方式，以及针对代码生成、自修复、代码执行和测试输出预测四种场景的具体提示构造和评估机制。这些设置旨在全面、无污染地评估代码生成类大模型的性能。
5 Results¶
这篇论文的第五章“结果”部分主要围绕 LiveCodeBench 这个用于评估大型语言模型（LLMs）代码能力的基准，探讨了其如何避免污染问题（contamination），并展示了模型在该基准上的性能表现和模型比较。
5.1 避免污染问题（Avoiding Contamination）¶
LiveCodeBench 的时间窗口能力
该基准通过时间窗口划分问题（从 2023 年 5 月至今），可以检测模型对未见问题的泛化能力，从而避免训练数据中的污染问题。DeepSeek 与 GPT-4-O 的污染问题
DeepSeek 模型的发布时间（2023 年 9 月）与 LiveCodeBench 的问题发布时间重叠，可能存在训练数据污染。
GPT-4-O 的训练截止日期为 2023 年 11 月，在之后的问题上性能下降，进一步表明污染的存在。
性能下降的实验观察
DeepSeek 模型在 2023 年 8 月之后的问题（即其发布前）表现较好，但在之后下降明显（如 DS-Ins-33B 的 Pass@1 从 ~60% 降至 ~0%）。
GPT-4-O 在 2023 年 11 月之后的性能也有下降。
非 LeetCode 平台的问题（如 AtCoder）性能下降不明显，说明污染主要发生在 LeetCode 数据中。
其他模型的表现
GPT-4-Turbo、Gemini-Pro、Mistral-L 和 Claude-3 等模型在时间窗口内没有明显性能波动，污染影响较小。
DeepSeek 的基础模型（DS-Base-33B）也表现出类似污染问题，说明其预训练数据可能包含 LeetCode 竞赛题。
5.2 性能与模型比较（Performance and Model Comparisons）¶
模型评估与数据集选择
评估了 34 个指令调优模型和 18 个基础模型。
为了防止污染，所有模型仅在 2023 年 9 月后的问题上进行评估。
多场景的综合评估
LiveCodeBench 包括四种任务场景：代码生成（Code Generation）、自修复（Self-Repair）、测试输出预测（Test Output Prediction）和代码执行（Code Execution）。
模型在这些任务上的性能相对一致，相关性高于 0.88，尤其在相关任务（如生成与自修复、测试预测与执行）之间相关性更高（0.98 和 0.96）。
但不同任务之间仍存在性能差异，例如 GPT-4-Turbo 在自修复任务中表现优于 GPT-4，Claude-3-Opus 和 Mistral-L 在执行和测试预测任务中表现突出。
与 HumanEval 的对比
HumanEval+ 是目前主流的代码生成评估基准，但 LiveCodeBench 的问题更具挑战性和多样性。
模型在两个基准上的性能差异明显，一些模型（如 DS-Ins-1.3B）在 HumanEval+ 上表现优异（Pass@1 为 60%），但在 LCB 上性能骤降至 26%，表明它们可能在 HumanEval 上过拟合。
基础模型和闭源模型在两个基准上的表现更一致，而一些开源模型因数据集单一导致泛化能力差。
SOTA 与开源模型的差距
在 LiveCodeBench 上，SOTA 模型（如 GPT-4-Turbo、Gemini-Pro-1.5、Claude-3-Opus）性能远高于开源模型。
例如，GPT-4-Turbo 在代码生成任务上比 DS-Ins-33B 高出 16.2 个百分点，在测试输出预测和代码执行任务中分别领先 96% 和 134%。
GPT-4-Turbo 生成的代码更易读，使用更多自然语言注释进行推理，注释量是 GPT-4 的 19.5 倍。
基础模型与指令调优模型的比较
基础模型中，L3-Base 和 DeepSeek 表现最佳，优于 CodeLLaMa 和 StarCoder2。
指令调优可以显著提升模型性能，例如 L3-Ins-70B、DS-Ins-33B 和 Phind-34B 相比其基础模型提升了 7-9 个 Pass@1 百分点。
闭源模型的指令调优数据可能更具多样性，而开源模型在不同任务上表现差异较大。
不同开源模型的比较
L3-Base 和 DeepSeek 指令调优模型表现最佳，其次是 Phind-34B 和 CodeLLaMa。
模型性能与规模相关，更大模型通常表现更好（如 Phind-34B 优于 6.7B 模型）。
闭源与开源模型的对比
闭源模型（如 GPT-4-Turbo、Claude-3-Opus）整体表现优于开源模型。
仅有 L3-Ins-70B、Mixtral 和 DS-Ins-33B 能够接近甚至超过闭源模型。
闭源模型在代码执行和测试输出预测任务上优势更明显，说明其在复杂推理任务上更强大。
总结¶
LiveCodeBench 作为一个污染少、覆盖全面的代码评估基准，揭示了当前大型语言模型在代码生成、自修复、测试预测和代码执行等方面的真实能力。研究发现：
污染问题在某些模型（如 DeepSeek 和 GPT-4-O）中明显存在，需通过时间窗口评估规避。
性能表现与模型类型和数据分布密切相关，SOTA 闭源模型表现显著优于开源模型。
HumanEval 的过拟合问题在多个开源模型中被验证，强调了 LiveCodeBench 的多样性和挑战性。
基础模型的性能提升依赖于高质量的指令调优数据，而闭源模型的泛化能力更强。
该研究有助于推动更公平、更准确的模型评估，为未来代码生成模型的开发和优化提供方向。
7 Limitations¶
本章节总结了 LiveCodeBench 的主要局限性及其应对策略，具体包括以下几个方面：
基准规模有限
当前基准包含 400 个代码生成任务实例，但为避免训练数据污染，仅使用 349 个在模型截止日期之后发布的问题进行评估。
由于样本大小有限，性能波动可能在 1% 至 1.5% 范围内，其他任务场景（如代码修复、执行与测试预测）也面临类似问题。
为减少此类影响，建议谨慎对待模型间的微小性能差异，并提出未来将引入更多竞赛平台问题和私有测试集，提升评估鲁棒性。
仅支持 Python
当前仅支持 Python 语言，限制了对多语言模型能力的评估。
由于已收集题目和测试用例，只要配备合适的评估引擎，扩展其他语言相对容易。
提示词鲁棒性不足
提示词设计对模型表现影响较大，但当前研究未做系统性优化，可能导致性能差异。
尤其在代码执行任务中，开源模型在使用思维链（COT）提示时表现不如封闭模型，说明提示优化仍有改进空间。
问题领域局限
当前基准主要基于竞赛编程问题，缺乏对实际软件开发等更广泛编程场景的覆盖。
建议将其作为模型评估的起点，并结合特定领域任务进行更全面的评估。
总结：LiveCodeBench 在数据规模、语言支持、提示策略和问题领域上存在局限，但已提出多个改进方案，例如引入更多问题源、扩展语言支持和优化提示策略，以提升评估的代表性与稳定性。
8 Conclusion¶
本章总结了文章的主要贡献和意义。作者提出了一个新的代码大模型评估基准 LiveCodeBench，通过引入实时评估机制来缓解现有基准中数据污染的问题，并扩展了评估场景，以更全面地反映大语言模型的代码能力。该基准具有可扩展性，将持续更新问题、场景和模型。评估结果揭示了一些新发现，例如数据污染现象和模型在 HumanEval 上的潜在过拟合问题。作者希望 LiveCodeBench 能够促进对当前代码大模型的理解，并为未来的研究提供指导。
Appendix A Dataset¶
本附录详细介绍了LiveCodeBench数据集的构建方法、数据来源、生成器的使用以及代码执行的筛选标准。
A.1 License（授权）¶
数据主要从LeetCode、AtCoder和CodeForces等编程竞赛平台抓取，仅限公开可见的内容，避免涉及付费墙或需要登录的内容。
引用了Hendrycks等人的Fair Use原则，强调数据使用的目的为学术研究，不涉及商业用途，并遵守版权法规。
所有抓取的数据仅用于学术研究，并未用于模型训练。
A.2 Generator Based Test Generation（基于生成器的测试生成）¶
使用GPT-4-Turbo模型生成输入生成器，用于测试编程竞赛问题。
随机输入生成器和对抗输入生成器分别构建，以覆盖程序的常见输入和边界情况。
构建了2222个随机输入生成器和4个对抗输入生成器，最终采样输入数控制在 100 以内以提高评估效率。
对于CodeForces平台，由于只使用了 9 个问题，因此生成器采用了半自动方式构建。
提供了用于生成随机输入和对抗输入的提示模板（Prompt Examples），并展示了示例生成器代码。
A.3 Code Execution（代码执行）¶
LiveCodeBench代码执行部分包含来自85个不同问题的479个样本，每个问题最多选取6个样本以保证多样性。
对代码进行了严格的筛选标准，包括代码长度、语法正确性、运行时间、运算复杂性等。
禁用了浮点运算、复杂字符串和列表操作，并限制执行步骤在1000个Python字节码操作以内，以确保代码的可执行性和安全性。
给出了两个被筛选掉的代码示例，一个因包含乘法运算，另一个因控制流复杂。
提供了数据集的统计信息，包括代码长度和执行步骤的分布情况（图8）。
总结： 本附录详细说明了LiveCodeBench数据集的构建流程、授权依据、输入生成方法和代码筛选标准，确保了数据集的合法性、多样性和可执行性，为LLM的代码评估提供了一个高质量、无污染的基准。
Appendix B UI¶
本附录介绍了LiveCodeBench的用户界面（UI），展示了两个视图：May-Jan和Sep-Jan。界面中受污染的模型被模糊显示，两个视图之间的性能差异一目了然。顶部的滚动条允许用户选择不同的时间段，突出显示了该基准测试的实时特性。
Appendix C Experimental Setup¶
本节详细介绍了实验中使用的模型、代码生成、自修复、代码执行及测试输出预测的设置方法。
C.1 模型¶
本节列出了实验中使用的语言模型的详细信息，包括模型 ID、简称、大致的截止日期和模型链接。模型涵盖了多个主流的代码生成模型和大语言模型，包括：
DeepSeek Coder 系列（如 DSCoder-33b-Ins、DSCoder-6.7b-Ins 等）
CodeLlama 系列（如 CodeLlama-70b-Ins、CodeLlama-34b-Ins 等）
LLaMA 系列（如 LLama3-8b-Ins、LLama3-70b-Ins 等）
Anthropic 系列（如 Claude-2、Claude-3 系列）
Google 系列（如 CodeGemma、Gemini-Pro 等）
Meta 系列（如 Mixtral-8x22b、Mixtral-8x7b 等）
Qwen、MagiCoder、StarCoder、OpenCodeInterpreter、Codestral、Command-R 等
这些模型的截止日期从 2021 年到 2024 年不等，涵盖了多个不同版本和大小，以全面评估其性能。
C.2 代码生成¶
本节提供了用于代码生成场景的提示格式。提示模板为用户生成符合要求的 Python 代码，包括两种情况：
有启动代码时：提示中包含用户提供的启动代码。
无启动代码时：提示中引导用户直接编写完整代码。
提示明确了用户要返回的是完整且正确的 Python 程序，不包含额外信息。
C.3 自修复（Self Repair）¶
此部分描述了用于代码自修复的提示格式。当模型生成的代码出错时，系统会返回错误信息（如错误输出、运行时错误、超时等），并引导模型进行自修复。
提示要求模型：
先简要说明错误原因（最多 2-3 句话）。
再提供修正后的完整代码，并确保代码被正确包裹在代码块中。
C.4 代码执行¶
本节提供了用于代码执行任务的提示内容，分为两种方式：
基础提示：要求模型根据给定的 Python 函数和输入，生成对应的 assert 输出。
链式思考（CoT）提示：要求模型先逐步执行代码，再生成最终的 assert 语句。
例如，给定 def performOperation(s): 和 assert performOperation("hi") == ??，模型需要计算执行结果并填写正确输出。
C.5 测试输出预测¶
本节描述了用于测试输出预测的提示模板。用户会提供函数签名和输入，模型需计算输出并生成完整的 assert 语句。提示强调：
用户是高级 Python 编程助手。
需根据问题描述、函数定义和测试输入推导出正确的输出。
最终结果应完整地写入代码块中。
总结¶
本章节详细说明了实验中使用的模型配置以及各项任务（代码生成、自修复、代码执行和测试输出预测）的提示格式，确保模型在统一的标准下进行测试，为后续实验的对比分析提供了明确的基础。
Appendix D Results¶
D.1 污染（Contamination）¶
本节展示了一些模型在代码生成和执行任务中出现的“污染”现象，尤其是 DeepSeek（DS）模型。通过图 10 和图 11，可见 DS 模型在自修复（self-repair）和代码执行（code execution）任务中，随着时间推移性能有所下降，这可能与模型训练数据中的污染有关。此外，图 12 显示了在 LeetCode 和 AtCoder 平台上，代码生成任务随时间的变化，其中 DS 模型的性能波动较大，而其他模型的性能相对稳定。图 13 展示了不同任务场景之间的相关性。
D.2 所有结果（All Results）¶
GPT-4O-2024-05-13 和 GPT-4 Turbo 在多个任务中表现最为突出。
Gemini-Pro-1.5 系列和 Claude-3 系列也有较强的综合能力。
DS 模型在某些任务中表现出性能波动，可能与数据污染相关。
COT 模式显著提升了部分模型在代码执行任务中的表现。
这些结果反映了不同大语言模型在代码生成、自修复、测试输出预测和代码执行任务中的综合能力，同时也揭示了污染问题和模型更新对性能的影响。
Appendix E Qualitative Examples¶
GPT-4在代码执行任务中，即便使用了Chain-of-Thought（CoT）提示方法，仍存在执行错误的5个示例。每个示例都包含任务描述、正确代码及其测试断言，以及GPT-4输出的错误结果，具体总结如下：
E.1 代码执行错误示例总结¶
这些示例反映了GPT-4在代码任务中的一些局限性，尤其是在逻辑判断、递归状态管理、数据结构操作等方面。即便使用了推理链提示（CoT），GPT-4仍可能产生错误答案。这表明对于需要精确逻辑推理或对算法理解较深的编程问题，大型语言模型仍存在一定的执行误差。