type
status
date
slug
summary
tags
category
icon
password
comment
Paper 1: ProjectEval: A Benchmark on Project-Level Code GenerationPaper 2: Toward a Theory of Causation for Interpreting Neural Code Models
Paper 1: ProjectEval: A Benchmark on Project-Level Code Generation
论文原文:
1. Motivation
- 现有评测不足:随着大型语言模型(LLM)在编程任务上取得显著进展,现有的评测基准(如 HumanEval、MBPP 等)主要聚焦于函数级或算法级任务,无法全面反映模型在生成完整、可运行项目时的实际表现。而现有的项目级基准往往依赖人工评审或者测试方法不够真实,难以模拟用户的实际交互体验。
- 用户视角的需求:在真实应用场景中,用户更关心整个项目的功能完整性、交互体验以及系统的鲁棒性。因此,急需一种能够从用户角度出发、自动化评估项目级代码生成质量的基准。这样的评测不仅要验证代码是否能运行,还要解释生成过程中各个环节的优劣,为模型改进提供明确方向。
- 提高解释性和实用性:除了仅仅统计通过率,现有基准对生成过程的各个环节缺乏详细解释。作者希望通过设计新的评测方法,不仅能够衡量最终项目能否正确运行,还能拆解评估各步骤(如功能清单生成、代码骨架构建、参数推理等)的效果,从而为进一步优化模型提供更具针对性的反馈。
2. Methods
- 多层输入设计
- 层级1 – 自然语言描述(NL Prompt):以简洁的自然语言描述给出项目目标,例如“创建一个 Todo 应用的网站”。这种描述要求模型从零开始构建整个项目。
- 层级2 – 自然语言清单(NL Checklist):在层级1基础上,利用 LLM 自动生成详细的功能清单,并经过人工审核修正。清单中明确列出项目所需的各项功能,比如“创建新列表”、“查看任务”等。
- 层级3 – 代码骨架(Skeleton):从标准答案中提取出部分代码框架,保留项目的基本结构,同时用注释标明各部分功能,指导模型填充具体实现细节。
为了模拟真实的软件开发过程,ProjectEval 定义了三个层次的输入:

- 自动化评测流程
- 任务下发与代码生成:将不同层次的输入(NL Prompt、NL Checklist 或 Skeleton)以 JSON 格式传递给 LLM,让模型生成完整的解决方案代码。
- 参数推理与回答:由于代码中涉及的变量名、函数名等不确定性,系统设计了参数描述(PD)环节。生成的代码与 PD 一同再次输入模型,让模型输出具体的参数值(PV),这些参数用于后续测试。
- 项目构建与交互测试:将生成的代码和参数值嵌入自动化测试脚本中,构建出可执行项目。针对不同任务类型:
- 对于网站项目,利用 Selenium 模拟用户在浏览器中的操作(如访问页面、点击按钮、检查页面标题)。
- 对于命令行或批处理项目,使用 Python 的 subprocess 模块模拟命令输入和响应。
- 多维度指标评估:除了最终的通过率(Pass@K),还引入多种客观指标来评估生成结果:
- NL Checklist:采用句子嵌入技术与匹配算法(如 Sentence Transformers 加 Jonker-Volgenant 算法)来计算功能描述的相似度;
- 代码骨架与生成代码:使用 CodeBLEU 评估代码结构和细节的匹配程度;
- 参数值匹配:通过字符串相似度(如 Levenshtein 距离)评价模型对参数描述的准确回答。

评测流程旨在模拟真实用户对项目的使用和测试过程,包括以下关键步骤:
- 标准答案与构建流程
- 初始任务描述经由 LLM 生成详细清单,再由人工审核形成层级2输入;
- 利用清单生成项目骨架,并进一步由 LLM 推断生成完整标准答案代码(Canonical Code),该代码经过人工校验以确保可运行;
- 最终,标准答案还包括标准参数值,作为后续自动测试的基准。
ProjectEval 的构建过程是半自动化的:
此外,通过 Masker 模块将标准答案中的关键部分替换为描述性注释,生成适用于评测的骨架,从而更好地衡量模型在补全代码时的表现。
3. Results
- 整体性能评估
实验结果显示,在项目级代码生成任务中,各大语言模型的整体表现均较低。以 Pass@5 指标为例,即使是闭源模型中表现最优的 GPT-4o,其得分也仅在 10%~15% 左右,反映出项目生成任务的高难度和当前模型在构建完整、可执行项目方面的不足。
- 模型类型间的差异
- 闭源模型优于开源模型:实验数据表明,闭源 LLM(如 GPT-4o、Gemini 系列)在代码骨架生成和项目可运行性测试上远优于开源模型(如 Llama 系列、Mistral 等)。闭源模型能较好地将功能清单转化为合理的代码结构,而开源模型在此环节普遍存在编译和运行失败的问题。
- 代码生成专用模型表现欠佳:专注于代码生成的 LLM(例如 CodeLlama 和 StarCoder-2)在本基准测试中表现不佳,原因可能在于这些模型缺乏处理自然语言描述和自动推理参数的能力。
- 生成策略的影响
- 在客观指标(例如 NL Checklist 与 Skeleton 部分的相似度评估)上,逐步生成方式表现略优,表明这种分步骤生成策略有助于提升代码结构和部分细节的质量。
- 然而,在最终的 Pass@K 核心指标上,两种生成策略之间的差距不明显,有时直接生成甚至更优,反映出生成策略对关键参数(Parameter Values)的填充和项目整体执行结果具有较大影响。
实验比较了逐步生成(cascade generation)与直接生成(direct generation)的两种策略:
- 分步评估揭示性能瓶颈
- 大多数模型在生成自然语言清单方面具有一定能力,说明它们能够理解项目要求;
- 但在生成代码骨架和细节实现上,尤其是参数值的正确推导和填充方面,模型普遍表现不足,这成为整个项目生成流程中的主要瓶颈。
通过对任务各个阶段(功能清单生成、代码骨架填充、参数值推导)的分步客观指标进行分析,结果显示:
4. Contribution
- 提出了项目级自动化评测基准
本文构建了 ProjectEval 基准,首次针对项目级代码生成任务设计了一套从用户视角出发的自动化评测体系,填补了现有评测方法在项目整体可执行性、用户交互模拟以及详细过程解释性方面的空白。
- 多层输入设计创新
通过引入三层输入(自然语言提示、详细功能清单、代码骨架),项目评测能够细粒度地分解任务,从而分别评估模型在理解项目需求、生成代码框架和填充具体实现上的表现,这为分析大模型各阶段能力提供了新的思路。
- 用户交互模拟与自动化测试结合
采用 Selenium、subprocess 等工具模拟真实用户操作,自动化执行项目测试,同时设计了参数描述与推导环节,实现了从代码生成到项目构建再到运行效果的全流程自动评测,为实际应用场景下的模型评估提供了更为贴近实际需求的方法。
- 多维度客观指标构建
除了传统的 Pass@K 指标外,文章引入了 CodeBLEU、句子相似度、字符串相似度等多种客观评价指标,分别对应功能清单、代码骨架与参数值的比对,增强了评测结果的解释性,为后续模型改进提供了细致反馈。
- 为编程代理的发展提供指导
实验结果揭示了大模型在项目级代码生成中的关键瓶颈(如参数推理与代码细节完善),并指出了闭源模型在此领域的优势,为未来设计更高效的编程代理和改进自动评测方法提供了有力的理论和实践依据。
Paper 2: Toward a Theory of Causation for Interpreting Neural Code Models
论文原文:
- 摘要
神经代码模型(NCMs)正在快速发展为商业开发工具,但对其能力和局限性了解有限。本文提出了docode,一种基于因果推理的解释性方法,用于解释NCMs的模型决策,尤其是编程语言相关的行为。通过对多个深度学习架构和NCMs的研究,发现这些模型对代码语法变化敏感,且在预测代码块标记时表现出较少的混淆偏差。docode展示了帮助检测和消除NCMs偏差的潜力
- 文章内容
- 文章基本内容概述
- 研究现状
代码生成任务在软件工程中扮演着至关重要的角色,NCMs 能够通过从大量的代码语料库中学习,来帮助开发者编写代码,提升开发效率。因此,NCMs 不仅在研究中表现出色,还逐渐进入了商业工具领域。像微软的 IntelliCode、OpenAI 的 Codex、GitHub 的 Copilot 都是 NCMs 的应用示例。这些模型已经在工业界受到广泛关注,并有望在生产环境中得到越来越多的实际应用。问题:如何从因果关系的角度来解释模型对代码生成的预测?问题:如何设计一个通用的解释框架,使其能够适用于不同的深度学习模型和不同类型的代码数据?
尽管 NCMs 的应用前景广阔,但目前对于这些模型的理解还远不够全面。尤其是现有的大部分研究都集中在评估模型的准确性上,通常使用一些自动化指标(如 BLEU、ROUGE、METEOR 等)来衡量模型性能。然而,这些指标只能揭示模型在特定测试集上的表现,无法深入解释模型是如何做出决策的。目前在神经代码模型的研究中,普遍依赖于准确性等自动化评价指标,但这些指标往往高估了模型的实际性能,忽略了许多模型存在的偏差、对抗性脆弱性、语法误解等问题。此外,很多用于代码生成的模型都是从自然语言处理(NLP)模型中直接迁移而来的,这些模型可能继承了 NLP 领域的诸多局限性,比如数据的低效性、过拟合和记忆化等问题。BLEU、ROUGE 和 METEOR 是用于评估自然语言处理任务中生成文本质量的指标。
1. BLEU(Bilingual Evaluation Understudy):主要用于机器翻译评估,通过计算生成文本与参考文本之间的n-gram重叠度来评估质量,值越高表示翻译越好
2. ROUGE(Recall-Oriented Understudy for Gisting Evaluation):通常用于文本摘要评估,关注生成文本与参考文本的召回率,常见的有ROUGE-N(n-gram重叠)和ROUGE-L(最长公共子序列)
3. METEOR(Metric for Evaluation of Translation with Explicit ORdering):综合考虑了词汇重叠、同义词和词序,通过计算匹配度来评估生成文本质量,旨在更好地捕捉文本的语义相似性
black-box:除此之外,由于现有的模型架构往往表现为黑箱模型,它们的推断过程缺乏透明性。这种不透明性让研究者和开发者难以理解模型的实际工作原理,进而质疑这些模型在实际部署中的稳定性和可靠性。特别是在面对带有语法错误的代码输入时,模型如何得出其预测结果往往不明确,现有的评估方法也无法充分揭示模型的内部行为。
- 研究问题
面对以上的研究现状,该论文提出的主要问题是:如何解释神经代码模型的预测行为?即,在现有的黑箱模型中,模型的预测决策过程缺乏透明性,使得我们无法确切了解模型为什么得出了某个特定的结果。因此,研究者提出需要一种新的解释方法,能够在模型预测代码时提供更为细致的因果解释,揭示模型的内部机制,帮助开发者识别并减少模型中的偏差。
问题:如何从因果关系的角度来解释模型对代码生成的预测?
问题:如何设计一个通用的解释框架,使其能够适用于不同的深度学习模型和不同类型的代码数据?
- 研究思路(技术路线)
- 构建结构因果模型(SCM):
- 研究者首先基于因果推理理论,构建了用于解释神经代码模型预测行为的结构因果模型(SCM)。SCM 通过有向无环图(DAG)表示输入变量(例如代码中的特定语法元素、错误、注释等)与输出变量(如模型的预测准确率、损失值)之间的因果关系。
- 在模型中,研究者设定了多种输入变量(如代码错误、代码注释等),并假设这些变量可能影响模型的预测性能。为了验证这种假设,研究者构建了相应的因果图。
- 识别因果效应:
- 在构建因果图后,研究者使用了因果推理的后门准则(Back-Door Criterion)来识别潜在的干扰因素(例如代码行数、代码复杂度等),并在估算因果效应时对这些干扰因素进行调整。
- 该方法帮助研究者控制那些与模型预测结果可能相关但不直接导致因果效应的因素,从而确保所识别的因果效应是准确且可信的。
- 因果效应估算:
- 为了量化因果效应,研究者使用了多种统计和机器学习方法,包括倾向得分匹配(Propensity Score Matching) 和 线性回归(Linear Regression) 等。这些方法用于计算输入变量(如代码错误、注释等)对输出结果(如模型的预测准确率、交叉熵损失等)的影响程度。
- 对于二元处理(如是否存在代码错误),研究者通过倾向得分匹配的方法来估算因果效应;而对于离散或连续变量(如模型层数、神经元数等),则使用线性回归来估算因果效应。
- 验证因果效应的稳健性:
- 添加随机干扰因素:通过引入一个与输入变量无关的随机变量来检验模型的因果效应是否受到了不相关因素的影响。
- 替换处理变量:使用一个随机变量替代真实的输入变量,来验证模型是否在没有实际输入的情况下仍然能得到合理的预测结果(即“安慰剂测试”)。
- 数据子集验证:通过使用不同的数据子集重新计算因果效应,来测试模型是否对数据的变化具有鲁棒性。
最后,研究者通过敏感性分析和假设检验方法来验证因果效应的稳健性。具体方法包括:
- 建模因果推断问题
- 图中的内容: 在这个阶段,通过已有的领域知识和数据,构建一个结构因果模型(SCM)。这个模型用一个图来表示变量之间的因果关系,像图中的例子,存在外生变量(L1, L2, L3, L4)、处理变量T、中介变量Z和结果变量Y。箭头表示因果关系的方向,比如从L1到Z说明L1影响Z,而Z影响Y。
- 通俗解释: 在这个步骤,我们要根据我们对领域的了解,画一个图,把可能导致某个结果的各种因素标出来。这个图可以帮我们理解各种因素是如何互相影响的。比如,L1可能是年龄,L2是收入,T是某种药物,中间变量Z是健康状态,最终我们想知道这些东西对结果Y(比如寿命)的影响。
- 相关名词解释:
- 结构因果模型(SCM):用图表表示变量之间因果关系的模型,帮助我们识别和量化这些关系。
- 外生变量:是指那些没有被系统内其他变量影响的变量,它们可能对其他变量产生影响。
- 处理变量:是我们施加某种干预或处理的变量,比如给病人服药。
- 结果变量:是我们关心的最终结果,比如病人的健康改善情况。
- 识别因果估计量
- 图中的内容: 在这一阶段,选择一个适合的因果估计量(Causal Estimand),即明确我们想要计算的因果效应是什么。为此,我们需要使用不同的因果识别准则,比如:
- 后门准则:排除潜在的混淆因素。
- 工具变量:利用外生变量来消除混淆。
- 前门准则和中介效应:通过中介变量来识别因果效应。
- 通俗解释: 在这里,我们要弄清楚如何计算因果效应,也就是明确我们到底要研究哪些因素的关系。例如,我们要研究一种药物对健康的影响,首先要确保排除其他影响健康的因素(比如年龄、性别等),这样才能更准确地得出药物的效果。
- 相关名词解释:
- 后门准则:确保我们排除了那些可能同时影响处理变量和结果的混淆因素。
- 工具变量:一种特殊变量,它和结果没有直接关系,但与处理变量有关,用它来帮助区分因果效应。
- 中介效应:处理变量通过某个中介变量(如Z)对结果变量产生影响的机制。
- 估计因果效应
- 图中的内容: 使用不同的统计方法计算因果效应。常见的方法包括:
- 基于处理分配的估计方法,如倾向得分匹配或倾向得分分层,用于调整组间差异。
- 基于结果模型的估计方法,如线性回归或机器学习估计器,计算处理变量对结果的影响。
- 通俗解释: 这个步骤就是选择一种方法,来计算因果关系到底有多大。比如,药物对健康的影响到底是好是坏,影响有多大。我们可以用一些统计方法来计算,比如倾向得分匹配,确保我们在比较药物有效性的同时,已经考虑了其他可能影响结果的因素。
- 相关名词解释:
- 倾向得分匹配:通过找到具有相似特征的个体来比较不同处理组的效果。
- 机器学习估计器:利用机器学习算法来估计因果效应,比如决策树或神经网络等。
- 验证因果过程
- 图中的内容:评估因果效应估计的稳健性和敏感性,确保其结果可信。例如,通过添加随机因素或使用未观察到的共因子来检验估计值的稳健性。
- 通俗解释: 我们计算出因果效应后,需要验证结果是否可靠。这个步骤通过各种测试,确保估计的因果效应不会因为某些未考虑的因素而发生重大变化。比如,我们可以假设一些数据是随机的,看看结果是否还一致。
- 相关名词解释:
- 稳健性:估计结果是否对假设的变化不敏感,能否在不同条件下保持一致。
- 随机因素:人为加入的随机变量,用来测试模型的稳健性。
- 因果效应输出
- 图中的内容: 最终输出因果效应的结果,通常包括:
- 平均处理效应(ATE):总体上某个处理的平均效果。
- 条件平均处理效应(CATE):在不同条件下(如不同人群)处理的效果。
- 通俗解释: 最后一步是把结果总结出来,看看干预措施总体上对所有人效果如何(ATE),以及在不同群体中的表现(CATE)。比如,药物在所有病人中平均效果是正面的,但在某些特定病人中效果可能更好。
- 相关名词解释:
- 平均处理效应(ATE):整体来看,一个处理(干预)的平均效果。
- 条件平均处理效应(CATE):在不同条件下,一个处理的平均效果,比如对于不同年龄段的人。
- Interpretablity Scenario(可解释性场景或案例)
- 这里列出了不同的场景,从A到G,分别代表不同类型的代码问题:
- A:Buggy Code(有bug的代码)
- B:Code Documentation(代码文档)
- C、D:Static Clone类型I和II(静态代码克隆)
- E:Hyperparameter Layers(超参数层数)
- F:Hyperparameter Units(超参数单元数)
- G:Missing AST Node Types(缺失的抽象语法树节点类型)
- do_code Goal(目标)
- 该部分的目标是生成对不同神经网络模型(如RNN、GPT、GRU、BERT等)的解释和可解释性验证。它通过各种模型和数据集的设置来实现。
- Setup(设置)
- DL Architecture(深度学习架构):包括RNN、GPT、GRU、BERT等神经网络模型。
- Evaluation Dataset(评估数据集):使用了CodeXGlue、CodeSearchNet、Galeras等数据集来评估模型性能。
- 这些数据集各自侧重不同的任务,推动了代码相关的自然语言处理研究,帮助开发更智能的代码理解和生成工具。
- Intervention Modality(干预模式):分为Binary和Linear两类干预方式。
- Hyperparameter Interventions(超参数干预):干预方式包括不干预、层数变化和单元数变化。
- Structural Causal Model Definition(结构因果模型定义)
- Data Interventions(数据干预):通过对数据的干预(如取消注释、节点类型掩码等)来研究代码修复、语法差异、下一个词预测、交叉熵损失等不同的任务和评估标准(如Jaccard、Levenshtein等)。
- Potential Outcomes(潜在结果):包括语法差异、程序修复、交叉熵损失等不同的测量结果。
- Syntax Clustering(语法聚类)
- Keyword-Based Categories [Java]:使用关键字对Java代码进行语法聚类。
- AST/Grammar-Based Categories [Python]:使用抽象语法树或语法结构对Python代码进行分类。
- Causal Inference Measure(因果推断衡量)
- 使用关联(Association)和干预(Intervention)来衡量因果效应。关联度量方法包括Pearson、Jensen-Shannon等。干预效应的度量方法包括ATE(平均处理效应)和CATE(条件平均处理效应)。
- Causal Validity(因果效应的有效性验证)
- Refutation Testing(反驳测试):通过删除子集、引入随机共因子和未观测共因子等方法来测试模型的稳健性。
- Vetting Causal Graph(因果图验证):包括因果图创建、探索性分析、因果图正确性验证(例如通过d-separation来检查图的正确性)。


这个图展示了基于神经网络模型的因果推断与可解释性分析的工作流程。它涉及多个场景、模型、评估数据集、因果推断的具体定义、因果验证及聚类分析等。
CodeXGlue介绍:CodeXGlue 是一个综合性的基准数据集,涵盖了多种编程语言(如 Python、Java、JavaScript 等)的任务,旨在评估代码理解和生成模型的性能。它包含多个子任务,如代码补全、翻译、摘要和生成等,促进了在代码相关任务中的研究。
示例:
代码翻译:将 Python 代码翻译成 Java 代码
例如,将以下 Python 函数:
翻译为 Java:
CodeSearchNet 介绍:CodeSearchNet 是一个针对代码搜索任务的数据集,包含了大量的代码片段和对应的自然语言描述,支持多种编程语言。它的设计目的是让研究者能够开发和测试代码搜索模型,改善开发人员在代码查找方面的效率。
示例:
自然语言查询:用户可以输入“查找实现冒泡排序的函数”,模型应能返回相关代码片段:
Galeras介绍:Galeras 数据集结合了代码、注释和文档,旨在支持多模态编程语言理解,促进对代码的上下文理解。这使得模型能够在生成代码时考虑更多的上下文信息,增强其理解能力。
示例:
代码生成:根据给定的注释生成代码。例如,给定注释“计算列表中所有元素的平方和”,模型应生成如下代码:
- 作者:Samuel Hu
- 链接:http://www.hjw-aihub.cn/research/paper-reading
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。