分享自:

EvocodeBench:一个具有领域特定评估能力的演化代码生成基准

期刊:38th conference on neural information processing systems (NeurIPS 2024) track on datasets and benchmarks

学术研究报告:EvocodeBench——一个具备领域特异性评估的演化代码生成基准测试

一、 研究作者、机构及发表信息

本研究由来自北京大学高可信软件技术教育部重点实验室、北京大学计算机学院的李佳、李戈(通讯作者)、张玄明、赵云飞、董一宏、金枝,以及阿里巴巴集团的李宾华、黄飞、李永斌(通讯作者)共同完成。该研究论文《evocodebench: an evolving code generation benchmark with domain-specific evaluations》已发表于第38届神经信息处理系统大会(NeurIPS 2024)的数据集与基准测试(Datasets and Benchmarks)轨道。

二、 研究背景与目标

本研究属于人工智能(AI)与软件工程(Software Engineering)的交叉领域,具体聚焦于大型语言模型(Large Language Models, LLMs)在代码生成任务上的评估

研究背景:随着代码生成LLMs(如GPT-4、DeepSeek Coder、StarCoder 2等)的快速发展,如何准确、公平地评估这些模型的真实能力成为一个关键问题。尽管已有多个基准测试(如HumanEval、MBPP、ClassEval、Deveval等)被提出,但它们普遍存在两大局限:1. 数据泄露(Data Leakage):由于LLMs的训练数据涵盖了海量开源代码库,许多现有基准测试的题目可能已包含在训练集中,导致评估结果虚高,损害了基准测试的公平性。2. 缺乏领域特异性评估(Lack of Domain-Specific Evaluation):实际软件开发高度专业化,开发者更关心模型在特定编程领域(如数据库、互联网、多媒体等)的表现。然而,现有基准要么缺乏领域标签,要么覆盖的领域过窄,无法指导用户为特定任务选择最合适的模型。

研究目标:为应对上述挑战,本研究旨在构建一个全新的代码生成基准测试——EvocodeBench。其核心目标是:1. 通过动态演化的机制避免数据泄露。2. 建立一个覆盖主流编程领域的领域分类体系,并对每个测试样本进行领域标注。3. 提供一套领域特异性评估指标,帮助揭示不同LLM在不同领域的优势和短板。

三、 研究详细流程与方法

本研究的工作流程主要包括四个阶段:基准测试构建、数据泄露检测、模型性能评估(包括整体与分领域评估)以及自动标注质量验证。

1. 基准测试构建流程 EvocodeBench的构建通过一个自动化的四阶段流水线完成,旨在从最新的开源仓库中收集高质量、贴近真实开发场景的测试样本。 * 第一阶段:仓库选择与函数爬取。研究团队从GitHub爬取高质量Python仓库,筛选标准包括:开源且许可证宽松、创建时间在最近6个月内、非Fork项目、非恶意项目、星标数超过50、拥有明确的单元测试。随后,从这些仓库中提取候选函数,并过滤掉空函数、初始化函数等简单函数。 * 第二阶段:基于执行的过滤。针对每个候选函数,从所在仓库中提取调用它的测试用例。使用pip安装执行环境,并利用pytest运行测试。任何没有可执行测试用例的候选函数都会被排除,确保了每个样本的可验证性。 * 第三阶段:自动标注。此阶段为每个样本生成丰富的元数据。 * 代码与依赖提取:使用基于静态分析的解析器(如Pyan)提取候选函数的签名、函数体(即参考代码)以及其调用的依赖项(参考依赖,包括类内、文件内和跨文件依赖)。 * 需求生成:由于手动编写需求描述费时费力,研究采用LLM(本文使用GPT-4)进行自动生成。研究者设计了一个单样本提示(One-Shot Prompt),教导模型按照特定格式(功能描述 + 输入输出参数说明)生成自然语言需求。 * 领域标签标注:首先,基于对流行开源社区PyPI的统计分析,人工设计了一个包含10个热门领域的编程领域分类体系(科学工程、软件开发、多媒体、数据库、系统、互联网、文本处理、通信、工具、安全)。然后,制作提示词,利用LLM根据候选函数的内容和该分类体系自动标注领域标签。不属于任何已定义领域的函数被排除。 * 第四阶段:基准测试构建。从通过上述筛选的候选函数中随机选取一部分,构建成EvocodeBench。构建过程遵循与500个真实世界仓库在代码分布、依赖分布等方面对齐的原则,以确保基准测试能反映真实开发场景。最终发布的第一版EvocodeBench-2403包含了来自25个仓库的275个样本,所有个人信息均已匿名化处理。

2. 数据泄露检测 为验证EvocodeBench在缓解数据泄露方面的有效性,研究采用了最新的数据泄露检测方法CDD。该方法可以检测LLMs是否在特定基准测试及其变体上进行过训练。实验结果显示,相较于主流基准测试HumanEval(GPT-3.5的泄露率达41.47%),EvocodeBench-2403上所有测试模型的泄露率均显著降低至3%以下(例如GPT-4为2.18%)。这证实了EvocodeBench-2403基本无数据泄露,能够提供更可信的评估。

3. 模型性能评估实验 研究选取了8个流行的LLMs进行评估,包括通用模型(GPT-4-Turbo-1106, GPT-3.5-Turbo-1106)和专用代码模型(DeepSeek Coder-33B/6.7B, StarCoder 2-15B/7B, CodeLlama-13B/7B)。 * 任务与指标:评估任务为仓库级代码生成(Repo-Level Code Generation),即给定需求描述和当前代码仓库上下文,让模型生成目标代码。这模拟了开发者在实际项目中的编码过程。评估指标包括: * pass@k:衡量生成代码的功能正确性。对每个需求生成n≥k个程序,计算其中能通过测试用例的正确程序比例。 * recall@k:衡量生成代码对参考依赖项的召回率,即生成的代码是否成功调用了上下文中定义的相关依赖。 * 实验设置:考虑到仓库代码通常很长,超出模型的上下文窗口,研究设计了三种实验设置来模拟不同开发场景: * 无上下文(Without Context):仅根据需求和函数签名生成代码。 * 本地文件(续写,Local File - Completion):模拟在文件末尾继续编码,模型可以看到目标函数所在文件中、位于目标位置之上的代码上下文。 * 本地文件(填充,Local File - Infilling):模拟在文件中间插入代码,模型可以看到目标位置之上和之下的代码上下文。 * 检索增强生成(RAG)实验:为进一步探索利用仓库信息,研究尝试了简单的RAG方法,即检索与目标函数名称最相似的Top-K个函数,并将其作为额外上下文提供给模型。

4. 自动标注质量的人为评估 为确保自动生成的需求和领域标签的质量,研究进行了人工评估。雇佣了5名有经验的Python开发者手动编写了EvocodeBench-2403所有样本的需求和领域标签,再由另外5名开发者对GPT-4生成的标注和人工标注进行盲评比较。评估结果显示,GPT-4生成的标注在绝大多数情况下(需求:96.7%的样本;领域标签:98.5%的样本)与人工标注质量相当,同时成本(时间和金钱)远低于人工标注,验证了自动标注流程的可行性。

四、 主要研究结果

1. 整体性能评估结果 在EvocodeBench-2403上的评估结果表明,与之前的基准测试相比,所有LLMs的表现均出现显著下降。例如,GPT-4在最新的仓库级基准测试Deveval上的最高pass@1为53.04%,而在EvocodeBench-2403的“本地文件(填充)”设置下仅为20.73%。这证实了EvocodeBench更具挑战性,且有效避免了因数据泄露导致的性能虚高。

2. 上下文对性能的影响 实验结果清晰地显示,提供更多代码上下文能显著提升LLMs的代码生成性能。例如,GPT-4在“本地文件(续写)”和“本地文件(填充)”设置下的pass@1,相比“无上下文”设置分别提升了104%和152%。这表明仓库上下文蕴含了关键的领域知识和API使用模式,对生成正确的、与项目风格一致的代码至关重要。一个典型案例显示,在没有上下文时,GPT-4错误地编造了一个不存在的属性;而在提供本地文件上下文后,它成功调用了文件中已定义的相关API,生成了正确代码。

3. RAG的初步效果 简单的RAG方法(基于函数名相似性检索)进一步提升了模型性能。例如,GPT-4在引入相似函数作为上下文后,pass@1从8.31%提升至12.29%。这说明即使是非目标位置的代码,只要语义相关,也能为生成过程提供有价值的信息,为未来探索更先进的RAG技术指明了方向。

4. 错误分析 通过对GPT-4在“本地文件(填充)”设置下的50个错误案例进行手动分析,发现失败的主要原因包括:实现逻辑错误(29例)必要上下文缺失(20例)(例如API定义在其他文件中)以及需求描述模糊(1例)。这表明现有LLMs的推理和编码能力仍需提升,同时如何更有效地利用广泛的仓库上下文(尤其是跨文件信息)是一个亟待探索的问题。

5. 领域特异性评估结果 这是本研究的核心贡献之一。根据领域标签将EvocodeBench划分为不同子集后,计算各模型在不同领域的pass@1。 * 领域性能差异:结果显示,不同LLMs在不同编程领域表现差异显著。例如,虽然StarCoder 2-7B的整体pass@1(13.82%)略高于DeepSeek Coder-6.7B(13.45%),但在互联网(Internet)领域,DeepSeek Coder-6.7B的表现(26.67%)却优于StarCoder 2-7B(20.00%)。这凸显了仅凭整体分数选择模型的局限性,以及领域特异性评估对实际开发者的重要性。 * 舒适领域与陌生领域:研究进一步提出了领域特异性改进(Domain-Specific Improvement, DSI) 指标,用以量化一个模型在特定领域相对于其他模型的平均相对改进程度。基于DSI,研究定义了模型的舒适领域(DSI > 10%)陌生领域(DSI < -10%)。 * 分析发现,GPT-4拥有最多的舒适领域(如科学工程、软件开发、多媒体、文本处理),尤其在文本处理领域表现突出,是唯一能解决部分任务的模型。然而,GPT-4在互联网领域表现不佳,成为其陌生领域。 * 一个有趣的发现是,StarCoder 2-15B在数据库领域表现出人意料地好,其性能甚至与GPT-4相当,超越了参数量更大的33B模型。 * 这些“舒适”与“陌生”领域的发现,可能与不同LLM预训练数据中各类领域代码的比例差异有关。例如,GPT-4的训练数据可能包含较少的互联网领域代码,导致其在该领域表现较弱。

五、 研究结论与价值

本研究成功构建并发布了EvocodeBench,这是一个旨在解决数据泄露和缺乏领域评估两大问题的演化式代码生成基准测试。其首个版本EvocodeBench-2403包含275个高质量样本,覆盖10个主流编程领域。

科学价值: 1. 提出了一个可持续、防污染的评估框架:通过定期更新(如每6个月)来自最新仓库的数据,EvocodeBench为代码生成LLMs的评估提供了一个长期可靠、公平的基准平台。 2. 推动了领域感知的模型评估:首次系统性地将领域分类和评估引入仓库级代码生成基准,使研究者能够深入分析模型在不同专业领域的性能剖面,而不仅仅是得到一个笼统的分数。 3. 揭示了LLMs在真实场景下的实际能力与局限:实验表明,即使在有上下文的情况下,当前最先进的LLMs在复杂仓库级任务上的通过率仍然较低(最高约20%),并明确了逻辑错误和上下文利用不足是主要瓶颈。

应用价值: 1. 为开发者选型提供指导:通过领域特异性评估和“舒适/陌生领域”分析,开发者可以根据自己专注的编程领域,选择表现更优的模型,而不是盲目追随整体排名。 2. 为模型训练者提供改进方向:模型开发者可以依据评估结果,识别模型在哪些领域表现薄弱,从而有针对性地扩充或调整训练数据,迭代出更强大的代码LLMs。 3. 提供了高质量、贴近实际的数据集:EvocodeBench的构建流程、丰富的标注(需求、代码、依赖、测试用例、仓库、领域标签)以及实验结果,为后续研究代码生成、代码补全、测试生成等任务提供了宝贵的资源。

六、 研究亮点

  1. 创新性基准设计:首创“演化”概念应对数据泄露,并系统性地整合了领域分类体系领域特异性评估指标(DSI、舒适/陌生领域),构成了本研究的核心理论贡献。
  2. 严谨的构建流程与高质量数据:采用四阶段自动化流水线,结合执行过滤和LLM辅助标注,确保了数据的功能正确性和标注质量。基准数据在代码/依赖分布上与真实仓库对齐,具有很高的生态效度。
  3. 深刻的评估洞察:不仅提供了全面的性能对比,还通过错误分析和领域细分,揭示了模型在仓库级代码生成任务中面临的核心挑战(逻辑错误、跨文件理解),以及不同模型在特定领域的能力分化,这些发现超越了简单的性能排名,具有更深的指导意义。
  4. 方法论的启发性:验证了利用LLM(如GPT-4)进行高质量需求自动生成的可行性,为大规模基准构建提供了高效、低成本的解决方案。同时,对RAG的初步探索也为提升仓库级代码生成性能提供了思路。

七、 其他有价值内容

  1. 未来工作展望:作者指出了EvocodeBench当前的两个主要局限:一是目前仅支持Python语言;二是首版数据规模相对较小。他们计划未来逐步支持Java、C++等其他编程语言,并通过持续收集最新仓库样本来扩大数据规模、平衡领域分布。
  2. 详细的附录与数据表(Datasheet):论文附录提供了丰富的细节,包括数据集的托管、许可与维护信息,符合伦理规范的作者责任声明,以及遵循Datasheets for Datasets范式的详细数据表,涵盖了数据集的动机、构成、收集过程、预处理、用途、分发和维护等各个方面,体现了研究的规范性和可复现性。
  3. 全面的对比:论文在表格中详细对比了EvocodeBench与众多现有基准(如HumanEval、MBPP、ClassEval、Deveval等)在仓库数量、样本数量、代码分布、依赖分布和标注信息等方面的差异,清晰展示了其独特性和优势。
上述解读依据用户上传的学术文献,如有不准确或可能侵权之处请联系本站站长:admin@fmread.com