博士论文 | 用代码结构感知方法推进代码大模型

导读

大语言模型已经成为代码生成、补全、修复和迁移中的核心工具，但一个长期被低估的问题是：代码并不只是自然语言式的 token 序列。程序有语法树、控制流、作用域、API 调用关系、模块边界和开发者编辑习惯；如果模型只从线性文本中学习，很容易在结构敏感的任务上出现“看起来合理、实际不可执行”的错误。 UC Berkeley 2025 博士论文《Advancing Large Language Models for Code Using Code-Structure-Aware Methods》围绕这一问题展开，作者 Linyuan Gong 系统研究了如何让代码大模型显式利用程序结构。论文不是单一方法论文，而是一条连续的研究线：先从深度学习框架间代码转译切入，提出 ADELT；再提出 SAFIM，用语法感知的中间填充任务检验模型是否真正理解代码结构；随后分别面向编码器-解码器和解码器-only 架构提出 AST-T5 与 AST-FIM 两类结构感知预训练策略。 这篇博士论文的核心观点可以概括为一句话：代码大模型要想更可靠地服务真实编程任务，不能只学“下一个 token”，还要学“程序结构中的合法位置、完整单元和语义约束”。这不仅影响代码补全，也影响跨框架转译、代码修复、长上下文代码生成以及未来的智能编程系统。

图1：论文封面。该博士论文由 Linyuan Gong 完成，技术报告编号为 UCB/EECS-2025-50，主题是通过代码结构感知方法推进代码大模型。

论文信息

论文标题：Advancing Large Language Models for Code Using Code-Structure-Aware Methods 作者：Linyuan Gong 单位：University of California, Berkeley 论文类型：博士论文，Computer Science 技术报告编号：UCB/EECS-2025-50 导师与委员会：Alvin Cheung、Dawn Song、Sida Wang 日期：2025 年 5 月 13 日 论文链接：https://www2.eecs.berkeley.edu/Pubs/TechRpts/2025/EECS-2025-50.html PDF：https://www2.eecs.berkeley.edu/Pubs/TechRpts/2025/Archive/EECS-2025-50.pdf

1 Introduction 引言

为什么代码不能只当作文本

现有代码大模型通常沿用自然语言建模范式：把源代码切成 token，通过海量语料学习局部共现、长程依赖和常见模式。这种范式非常强大，足以支撑代码补全、单元测试生成、自然语言到代码等任务。但代码与自然语言相比有一个决定性差异：代码必须满足严格的形式结构，并在运行时产生可验证行为。 论文指出，很多代码任务的失败并不是模型完全不知道语法，而是模型缺少对结构边界的稳定利用。例如，在补全一个 if 分支、函数体或 API 参数时，模型需要知道当前位置属于哪个语法单元；在代码转译中，模型需要保留控制结构、调用链和张量形状相关约束；在代码修复中，模型需要理解错误表达式与周围语句之间的结构依赖。只要这些结构被打散为普通 token 序列，模型就可能生成局部流畅但整体不合法的程序。

什么是代码结构

论文中的“代码结构”并不限于抽象语法树。作者将其理解为程序语言中能够约束或组织代码的多层信息，包括 AST、语句块、表达式、API 调用、控制流、数据流以及更高层的项目组织。本文重点研究的是 AST 及其相关语法结构，因为 AST 能自然表示代码中的完整表达式、语句和子树边界，适合用于构造训练目标、遮蔽策略和评估任务。 这种定义的意义在于，它把结构从“模型输入的一种额外特征”提升为“训练、评估和任务设计中的基本单位”。换句话说，结构感知不是简单把 AST 序列化后喂给模型，而是在任务本身就要求模型尊重结构：该遮蔽完整子树时不遮蔽半个表达式，该补全完整代码块时不只预测若干字符，该迁移 API 时不破坏原有计算图。

评估与训练结构感知能力

论文将结构感知研究拆成两个互补问题。第一，如何评估模型是否真的理解代码结构？传统 HumanEval 或 MBPP 主要关注函数级生成，无法细粒度观察模型在语法边界、控制流块或 API 调用补全中的能力。第二，如何训练模型利用结构？如果预训练阶段仍然随机切分代码，模型即使在下游任务中被要求补全完整语句，也没有足够强的训练信号去学习这种行为。 因此，论文的组织结构非常清晰：第 2 章用 ADELT 展示结构感知在代码转译中的价值；第 3 章用 SAFIM 建立语法感知中间填充基准；第 4 章提出适用于 T5 类模型的 AST-T5；第 5 章面向解码器-only 代码模型提出 AST-FIM；第 6 章总结结构感知代码大模型的未来方向。

2 ADELT: Transpilation Between Deep Learning Frameworks 深度学习框架间转译

问题设定

ADELT 关注的是深度学习框架之间的代码转译，例如 PyTorch、Keras、MXNet 之间的模型代码迁移。这类任务与普通代码翻译不同：深度学习代码常常高度模板化，层、激活函数、参数名和张量操作之间存在清晰结构；但不同框架的 API 名称、默认参数和调用方式又存在大量细节差异。 直接让大模型端到端转译，往往能保留大体骨架，却容易在 API 关键词上出错。例如把 in_features、out_features、bias 转成目标框架参数时，模型必须知道哪些参数应当删除、重命名或重排。论文认为，这说明代码转译可以被拆解为两个子问题：结构转换与 API 关键词翻译。 图2：ADELT 的代码转译流水线。方法先把源代码规范化并抽取骨架，再用语言模型完成骨架迁移，同时用学习到的 API 词典完成框架特定关键词映射。

方法设计

ADELT 的核心思想是“解耦”。对于代码骨架，方法利用语言模型 few-shot prompting 完成从源框架到目标框架的结构迁移；对于 API 关键词，则通过上下文嵌入与字典匹配完成映射。这样做的好处是，模型不必同时解决结构迁移和 API 细节对齐两个难题。 具体来说，ADELT 会先将源代码规范化，抽取出代码骨架和 API 关键词位置。代码骨架保留调用链、表达式和模块组织，而将具体 API 名称替换为占位符；语言模型负责把这种骨架转成目标框架。随后，系统根据 PyBERT 产生的上下文表示，为源框架和目标框架中的 API 关键词学习共享语义空间，再通过相似度或字典查找完成关键词替换。 图3：ADELT 的领域对抗训练机制。不同深度学习框架共享 PyBERT 与生成器，通过判别器推动 API 关键词表示进入更框架无关的空间。

关键结果与启示

ADELT 的重要性不只在于提升转译指标，更在于它说明：即使强大的语言模型已经具备一定代码迁移能力，结构与 API 语义仍然需要被分开处理。深度学习框架代码中的“结构相似性”可以由模型较好地迁移，而“框架特有 API 对齐”则更适合由结构化表示和词典学习来约束。 这为后文埋下了主线：代码模型的能力瓶颈不一定来自参数规模不足，也可能来自训练和推理过程没有显式对齐程序结构。ADELT 相当于论文中的第一个实证案例，证明结构感知可以把大模型从“泛化式猜测”拉回到更可控的程序变换过程。

3 SAFIM: Evaluation of LLMs on Syntax-Aware Code Fill-in-the-Middle Tasks 语法感知中间填充评估

为什么需要新的评测

代码补全是开发者最常接触的大模型能力之一，但常见评测往往过于简化。许多基准只要求模型从左到右补完整个函数，或者在单一位置生成一段代码。真实开发中，程序员更常在已有代码中间插入或修改完整结构，例如补一个循环体、一个分支、一个 API 调用或一段控制流逻辑。 SAFIM 正是为这种场景设计的语法感知 Fill-in-the-Middle 基准。它不是随便遮蔽若干 token，而是围绕代码结构构造补全任务，从而更精准地测试模型是否理解“被遮蔽部分在程序结构中扮演什么角色”。 图4：SAFIM 基准的三类任务划分，包括算法代码块补全、控制流补全和 API 函数调用补全。黄色区域表示模型需要根据上下文补全的结构化代码片段。

基准构造

SAFIM 包含三类代表性任务。第一类是算法块补全，要求模型在算法实现中补全一段连续代码，例如动态规划、循环更新或变量交换。第二类是控制流补全，关注 if、while、for 等控制结构中的条件和语句块。第三类是 API 函数调用补全，要求模型在上下文中填入正确 API 调用及参数。 这三类任务分别对应代码结构中的不同难点。算法块补全考验模型对局部变量、循环不变量和操作顺序的理解；控制流补全考验模型是否知道分支和循环边界；API 调用补全则考验模型对库语义、参数名称和上下文对象类型的掌握。与普通补全相比，SAFIM 更接近真实代码编辑。

评测发现

论文使用 SAFIM 评估了 15 个大语言模型，并得出一个很有价值的发现：模型越大并不一定越强。不同预训练范式、代码数据质量以及是否包含 FIM 目标，会显著影响语法感知补全能力。 图5：不同模型在 SAFIM 上的平均表现与模型规模对比。横轴为参数规模，纵轴为三类任务平均 Pass@1；颜色表示不同预训练范式。 从图中可以看到，某些中等规模但经过代码和 FIM 预训练优化的模型，在结构化补全上可以超过更大规模模型。这说明代码智能不能简单用参数量排序。对于代码任务，训练数据是否覆盖真实仓库上下文、预训练目标是否贴近编辑场景、模型是否见过中间填充格式，都会影响最终能力。 SAFIM 的贡献在于提供了一个更“结构化”的显微镜。它让研究者能够观察模型具体在哪类结构上失败，而不是只得到一个函数级生成分数。这对后续改进预训练目标非常关键。

4 AST-T5: Structure-Aware Pretraining for Code Generation and Understanding 结构感知预训练

方法动机

在 T5 类编码器-解码器模型中，常见预训练目标是随机 span corruption：从输入中随机遮蔽若干连续 token，让模型恢复被遮蔽部分。这种方法在自然语言中很有效，但用于代码时存在一个明显问题：随机 span 可能切断变量名、表达式、语句或代码块，使模型学习到的恢复任务与真实开发中的结构化编辑不一致。 AST-T5 试图把 AST 引入预训练过程，让遮蔽和切分都尽量尊重语法树结构。论文强调，这里的结构信息主要用于训练阶段，推理时不要求额外提供 AST，因此不会增加下游使用门槛。 图6：AST-T5 的子树感知遮蔽与普通 T5 随机遮蔽对比。AST-T5 倾向于遮蔽完整表达式或语句，使预训练任务更符合代码结构。

两个关键机制

AST-T5 包含两个核心机制。第一是 AST-Aware Subtree Corruption，即根据 AST 子树选择遮蔽片段。这样模型需要恢复的是有结构意义的代码单元，例如完整表达式、语句或分支，而不是任意字符片段。第二是 AST-Aware Segmentation，即在长代码切分时尽量沿着函数、类成员或主要分支边界切开，减少对代码结构的破坏。 这两个机制共同解决了代码预训练中的“结构错配”问题。传统预训练可能让模型习惯修复被随机破坏的文本，而真实代码生成更常要求补全结构完整的语法单元。AST-T5 通过改变训练样本构造方式，让模型更频繁地看到结构化缺口。

实验结果

论文在代码生成、代码转译、代码修复和代码理解任务上评估 AST-T5。结果显示，结构感知预训练能带来稳定收益，尤其是在代码到代码转换和修复场景中优势更明显。这与论文主张一致：当任务要求保留或恢复程序结构时，AST 信息会提供比纯文本更强的归纳偏置。 图7：AST-T5 在 HumanEval 与 MBPP 上的表现对比。图中展示了 AST-T5 与多种开源、闭源模型在不同参数规模下的 Pass@1 表现。 值得注意的是，AST-T5 的价值并不只是“分数更高”。它展示了一种训练范式：将程序结构用于构造更合理的自监督任务，而不是把结构当成推理时的额外负担。对于需要在真实工程中部署的代码模型，这种设计非常有吸引力，因为训练阶段引入结构，推理阶段仍然保持常规文本接口。

5 AST-FIM: Structure-Aware Fill-in-the-Middle Pretraining for Code 面向代码补全的结构感知中间填充预训练

随机中间填充的问题

随着代码补全和编辑场景变得重要，FIM 预训练被广泛采用。FIM 的基本思想是给模型前缀和后缀，让模型生成中间缺失部分。这比单纯从左到右生成更适合 IDE 中的真实补全。 但论文指出，许多 FIM 方法仍然以随机字符或随机 token 为单位选择中间片段。这会造成训练样本与真实编辑行为错位。开发者通常不是随机删除半个表达式，而是在函数中插入一个完整语句块、补一个分支、增加一个 API 调用或修改一个完整逻辑片段。随机 FIM 可能把代码切得支离破碎，让模型学习到噪声较大的补全目标。 图8：随机字符 FIM 与 AST-FIM 的遮蔽策略对比。AST-FIM 遮蔽完整 AST 子树，更贴近开发者在真实代码中插入或修改完整语法单元的方式。

方法与基准

AST-FIM 将 AST 子树作为 FIM 遮蔽单位。给定一段代码，方法会解析其语法树，从中选择完整子树作为中间部分，再把剩余代码组织成前缀、中间、后缀格式。这样，模型在训练中需要补全的是结构完整的代码片段，而不是任意字符串。 为了评估真实编辑场景，论文还提出 Real-FIM-Eval。该基准从真实 git commit 中构造样本，分为 Add 和 Edit 两类。Add 使用代码插入场景，把新增代码作为需要预测的中间部分；Edit 使用代码修改场景，通过类似冲突合并的格式呈现原始代码和更新代码，让模型预测修改内容。 图9：Real-FIM-Eval 的样本构造方式。左侧表示真实代码插入，右侧表示真实代码编辑；二者都将开发者实际变更转化为中间填充任务。

实验结果与局限

AST-FIM 在 SAFIM 与 Real-FIM-Eval 上均表现出优势，说明结构感知遮蔽确实能提升模型处理中间补全的能力。更重要的是，它在多个模型规模和多种编程语言上具有较好一致性，并且相较单纯 FIM 训练，能更好地保留从左到右生成能力。 这部分结果回应了一个现实问题：代码模型不能只优化一种交互模式。IDE 中既有从左到右补全，也有中间插入、局部重写、函数体扩展和 bug fix。AST-FIM 的优势在于，它让模型在预训练阶段就接触更接近真实编辑行为的缺口，从而减少训练任务与用户任务之间的差距。 论文也清楚指出了局限。Real-FIM-Eval 主要使用困惑度等指标，尚不能完全替代直接生成质量评估；AST-FIM 对从左到右生成的提升不一定超过纯 L2R 预训练；部分单行补全基准仍可能过于人工化，不能全面代表真实软件开发。换言之，结构感知不是万能解，但它提供了一条更贴近代码本质的训练路径。

6 Conclusion and Future Work 总结与未来工作

总结

这篇博士论文围绕代码结构感知建立了一条完整研究链路。ADELT 证明，在跨框架代码转译中，把结构迁移与 API 映射解耦可以显著提升可靠性；SAFIM 提供语法感知的中间填充评测，揭示模型规模并不是结构化代码能力的充分条件；AST-T5 展示了如何将 AST 用于编码器-解码器模型的结构化预训练；AST-FIM 则把结构感知推广到解码器-only 模型和真实代码编辑场景。 整篇论文最有价值的地方，是把“代码结构”从一个辅助特征变成了贯穿任务、评测和训练的核心对象。它提醒我们，代码大模型的发展不应只追求更大模型、更长上下文和更多数据，也要追求更合理的程序归纳偏置。

未来方向

论文提出的未来方向主要有两类。第一类是更丰富的结构建模。当前工作重点使用 AST，但真实软件系统还包含跨文件依赖、目录结构、构建配置、包管理信息、控制流图、数据流图以及运行时执行轨迹。未来的代码大模型如果要理解项目级软件，就需要从函数级 AST 扩展到仓库级结构和动态行为。 第二类是更真实的评估。现有代码评测仍然偏重函数级生成、单点补全或离线指标。未来需要更多贴近开发者工作流的基准，例如多文件补全、长周期代码修改、依赖升级、框架迁移、基于测试反馈的修复，以及对生成代码可维护性和安全性的评估。 从应用角度看，这篇论文对智能编程系统有直接启发。下一代代码助手不应只是一个会写代码的聊天模型，而应当理解代码库结构、编辑历史、测试反馈和运行行为；它需要知道“在哪里补”“补什么结构”“补完后会影响什么”。结构感知方法正是通向这一目标的重要基础。

参考资料

Linyuan Gong. Advancing Large Language Models for Code Using Code-Structure-Aware Methods. UC Berkeley EECS Technical Report No. UCB/EECS-2025-50, 2025.