JetBrains Research证明：项目级代码补全训练并不需要海量数据和复杂方法

这项由JetBrains Research的Maksim Sapronov和Evgeniy Glukhov开展的研究发表于2025年ICLR会议（国际学习表征会议），论文编号为arXiv:2510.13697v1。对于那些想要深入了解技术细节的读者，可以通过这个编号查询完整论文。

在现代软件开发中，程序员们越来越依赖AI来帮助编写代码。这就像是有一个非常聪明的助手，能够理解你正在写的程序，并在合适的时候提出建议，告诉你下一行应该写什么。然而，让AI真正理解一个完整的软件项目就像让一个人理解一部复杂的小说一样——不仅要看懂当前这一页的内容，还要记住前面所有章节的情节发展。

在编程世界里，大部分AI模型就像只看了小说其中一页的读者，它们只能理解单个文件的代码，却无法把握整个项目的全貌。这种局限性就好比一个厨师只看到了食谱的一部分，虽然知道如何切菜，却不清楚最终要做成什么菜。为了解决这个问题，研究人员开始训练AI模型来理解整个代码仓库（repository），让它们能够像经验丰富的项目经理一样，对整个软件项目的结构和逻辑了如指掌。

然而，这种"仓库级训练"面临着巨大的挑战。首先，它需要海量的数据——一些最先进的模型需要3000亿个文本单元（token）的训练数据，这相当于几百万本书的文字量。其次，处理这么多信息需要巨大的计算资源，就像试图同时记住一整个图书馆的内容一样困难。这让许多研究团队和公司望而却步，因为不是每个人都有Google或微软那样的资源。

JetBrains Research的这项研究带来了一个令人振奋的发现：要让AI理解项目级代码，其实并不需要那么多数据和复杂的方法。研究团队以OpenCoder这个15亿参数的模型为起点，通过巧妙的训练策略，仅用10亿个token的精心筛选数据，就让模型的项目级代码补全能力达到了与那些使用数千亿token训练的顶级模型相当的水平。

更有趣的是，研究团队发现了一个颠覆常识的结论：在训练过程中如何组织和排列代码文件，对最终效果的影响微乎其微。这就像发现烹饪一道美味佳肴时，食材的摆放顺序远没有火候控制重要。真正的关键在于一个看似技术性的调整——修改模型的位置编码参数（RoPE scaling parameter），这个调整让模型能够处理更长的上下文信息。

一、研究背景：为什么项目级代码理解如此重要

在软件开发的世界里，代码就像建筑图纸一样复杂。一个现代软件项目可能包含成千上万个文件，每个文件都像拼图的一片，只有放在正确的位置才能构成完整的图案。传统的AI代码助手就像只看到一片拼图就要猜测整幅图案的人，虽然能做出一些有用的建议，但往往缺乏对全局的把握。

当程序员在写代码时，他们经常需要调用其他文件中定义的函数或变量。这种跨文件的依赖关系就像一张复杂的人际关系网，每个人都与其他人有着千丝万缕的联系。如果AI助手不理解这些关系，就像一个不了解公司组织架构的新员工，虽然能完成一些简单任务，但在需要协调配合的复杂工作上就会力不从心。

为了解决这个问题，研究人员开始探索"仓库级预训练"的方法。这种方法让AI模型在学习过程中接触到完整的代码项目，而不仅仅是零散的代码片段。这就像让一个学徒不仅学习如何使用单个工具，还要了解整个工作坊的运作方式。通过这种训练，模型可以学会理解代码文件之间的关系，掌握项目的整体架构。

然而，这种训练方法带来了新的挑战。最大的问题是数据需求量的急剧增加。一些最先进的模型，如Qwen2.5 Coder，需要大约3000亿个token的仓库级数据进行训练。这个数字听起来可能比较抽象，但可以这样理解：如果把这些数据打印出来，需要的纸张可能比一座摩天大楼还要高。

除了数据量的挑战，计算资源的需求也呈指数级增长。处理长序列的计算复杂度随着序列长度的平方增长，这意味着处理两倍长的序列需要四倍的计算资源。这就像试图同时记住越来越多的信息，大脑的负担会急剧增加。

面对这些挑战，许多研究团队开始探索更高效的方法。有些团队开发了新的注意力机制，如Flash Attention和Ring Attention，这些技术就像更高效的记忆方法，能够帮助模型更好地处理长序列。但即使有了这些改进，如何有效利用仓库级信息仍然是一个悬而未决的问题。

在这个背景下，JetBrains Research的团队决定深入研究一个具体但重要的问题：在项目级代码补全任务中，不同的数据处理策略会产生怎样的影响。他们选择了Long Code Arena基准测试中的单行代码补全任务，这个任务要求模型根据当前文件的内容和整个项目的上下文，预测程序员接下来要写的那一行代码。

二、研究方法：巧妙的实验设计

研究团队采用了一种类似对比实验的方法来探索这个问题。他们选择了OpenCoder 1.5B作为基础模型，这个模型最初设计用来处理4096个token的上下文长度。可以把这个长度想象成一本中等厚度书籍的篇幅——对于理解单个文件来说足够了，但要理解整个项目就显得有些局促。

为了让模型能够处理更长的上下文，研究团队将其上下文窗口扩展到16384个token，这相当于把模型的"记忆容量"增加了四倍。这种扩展就像给一个人增加更大的工作台面，让他能够同时摊开更多的资料进行工作。

在数据准备方面，研究团队采用了与Long Code Arena基准测试相同的方法。他们从GitHub上收集了开源的Python项目，然后遍历这些项目的Git提交历史来提取训练数据。这个过程就像考古学家挖掘遗址一样，通过分析每次代码变更来理解项目的演化过程。

最终的数据集包含了1640个仓库、160801次提交和361052个待补全的文件。这些数字看起来可能很抽象，但可以这样理解：这相当于分析了数千个不同规模的软件项目，涵盖了各种编程风格和应用场景。

研究的核心创新在于对"上下文组合器"（context composer）的系统性研究。上下文组合器就像一个智能的文件管理员，它的任务是从项目的所有文件中选择最相关的内容，然后按照某种逻辑顺序排列，为模型提供最有用的上下文信息。

研究团队设计了多种不同的上下文组合器策略。最简单的是"文件级"策略，它根本不提供任何项目上下文，就像让一个人在完全不了解背景的情况下续写故事。另一个重要的策略是"路径距离"策略，它根据文件之间的路径相似性来排序，优先选择与当前文件在目录结构上最接近的文件。

这种方法的逻辑很直观：通常情况下，位于相同目录或相近目录的文件在功能上更相关。这就像在图书馆里，同一书架上的书通常属于相同的主题分类。除了路径距离，这个策略还使用了"交并比"（IoU）作为辅助排序标准，通过计算文件之间共同代码行的比例来评估相关性。

为了确保训练过程的有效性，研究团队采用了特殊的截断策略。他们确保上下文与待补全内容的token比例至少为3:1，这样模型就能获得足够丰富的上下文信息来进行准确的预测。这种比例设计就像在做菜时保证配菜与主菜的合理搭配，既不能让配菜抢夺主菜的风头，也不能让主菜显得过于单调。

在模型训练方面，研究团队做了一个关键的技术调整：将RoPE（旋转位置编码）的基础频率从10000调整到500000。这个调整听起来很技术性，但可以这样理解：这就像调整收音机的频率来接收更远距离的电台信号。通过这种调整，模型能够更好地理解长序列中不同位置的信息。

整个训练过程使用了大约10亿个token的数据，这个数量虽然看起来很大，但相比那些使用数千亿token的模型来说，已经相当节约了。研究团队在第512个优化步骤保存模型权重作为检查点，这相当于在训练过程中设立一个里程碑来评估进展。

三、关键发现：颠覆传统认知的结果

当研究团队分析实验结果时，他们发现了一些令人惊讶的模式。首先，在与现有最先进模型的对比中，他们的方法展现出了令人印象深刻的性能。尽管只使用了相对较少的训练数据，他们的模型在Long Code Arena基准测试上达到了与DeepSeek Coder 1.3B和Qwen2.5-Coder等模型相当的性能水平。

这个结果就像发现了一个神奇的烹饪秘诀：不需要昂贵的食材和复杂的工艺，也能做出米其林星级的美味。在具体的性能指标上，他们的模型在"inproject"类别（需要使用项目内其他文件信息的代码补全）上获得了48.8分（满分100分），在"infile"类别（只需要当前文件信息的代码补全）上获得了47.6分。

更令人惊讶的是第二个发现：不同上下文组合器策略对最终性能的影响远比预期的要小。研究团队测试了多种不同的组织策略，包括基于路径距离的排序、基于内容相似性的排序、随机排序等等。结果显示，这些策略的性能差异只有3.6分（45.2分到48.8分之间），这个差异在统计学上并不显著。

这个发现就像发现在烹饪某道菜时，香料的添加顺序对最终味道的影响远没有火候控制重要。无论是精心设计的智能排序策略，还是简单的随机排列，最终的效果竟然相差无几。这个结果挑战了许多研究人员的直觉，也让人重新思考什么才是仓库级代码理解的核心要素。

通过进一步的分析，研究团队发现了真正的关键因素：RoPE参数的调整。当他们比较使用原始RoPE参数（基础频率10000）和调整后参数（基础频率500000）的模型时，发现后者在长上下文任务上的性能有了质的飞跃。原始模型在处理16K token长度的上下文时完全失效（得分接近0），而调整后的模型即使只进行文件级训练，也能获得45.2分的成绩。

这个发现揭示了一个重要的洞察：让模型学会处理长上下文的关键不在于复杂的数据组织策略，而在于调整模型的基础架构使其能够理解位置信息。这就像发现要让一个人记住更多信息，关键不在于记忆内容的排列方式，而在于提升大脑的记忆容量。

研究团队还发现了另一个有趣的现象：即使使用最简单的文件级训练（不提供任何项目上下文），模型在评估时仍然能够有效利用项目级上下文信息。这种现象被称为"仓库上下文提升"（repository-context boost），文件级训练的模型获得了19.3分的提升，而最佳策略只能额外提供3.5分的改进。

这个结果表明，模型的上下文理解能力很大程度上是一种泛化能力，而不是通过特定训练策略获得的专门技能。这就像一个受过良好教育的人，即使在陌生的环境中也能快速理解和适应，因为关键能力在于学习能力本身，而不是对特定环境的熟悉程度。

四、深入分析：为什么简单的方法如此有效

为了更深入地理解这些发现，研究团队进行了广泛的补充实验。他们测试了总共11种不同的上下文组合器策略，涵盖了从完全随机到高度优化的各种方法。这些策略包括基于代码相似性的排序、只保留函数声明的过滤、移除注释和文档的精简等等。

令人惊讶的是，即使是一些看似不合理的策略也取得了不错的效果。例如，"反向排序"策略（故意将最不相关的文件放在前面）仍然能够提供显著的性能提升。这个现象就像发现即使用错误的地图，只要有足够的导航能力，仍然能找到目的地。

这些结果指向了一个重要的结论：模型的长上下文理解能力主要来自于其架构调整，而不是训练数据的精心组织。具体来说，RoPE参数的调整使模型能够正确理解长序列中不同位置的信息，这是利用长上下文的必要条件。一旦具备了这种能力，模型就能从各种形式的上下文信息中学习，无论这些信息是如何组织的。

研究团队还探索了模型在不同上下文长度下的表现。他们发现，经过16K token训练的模型能够很好地扩展到更长的序列，甚至在32K token的上下文下仍然表现良好。这种扩展能力类似于一个人学会了骑自行车后，很快就能适应不同类型的自行车。

另一个有趣的发现涉及损失函数的选择。在某些训练策略中，研究团队只对待补全的代码部分计算损失（masked loss），而忽略上下文部分的预测误差。但实验表明，这种精细的调整对最终性能的影响很小，大多数情况下使用完整损失函数（full loss）的效果相当。

这个结果进一步强化了"简单方法同样有效"的主题。就像发现在某些烹饪过程中，过度精细的温度控制并不会带来显著的味道改善，有时候最直接的方法就是最好的方法。

五、实际意义：为代码AI研究开辟新道路

这项研究的意义远远超出了技术细节本身。首先，它为资源有限的研究团队和公司提供了希望。在AI领域，特别是大规模语言模型的研究中，往往需要庞大的计算资源和数据集。这种高门槛让许多有潜力的研究者望而却步，就像只有富人才能参与的游戏。

然而，这项研究证明了在代码理解这个特定领域，巧妙的方法可以弥补资源的不足。使用仅仅10亿token的精心筛选数据，就能达到与使用数千亿token训练模型相当的性能，这为更多研究团队参与这个领域提供了可能性。

其次，研究结果挑战了该领域的一些基本假设。长期以来，研究人员认为复杂的数据预处理和精心设计的训练策略是提升模型性能的关键。但这项研究表明，在某些情况下，简单的方法可能同样有效，甚至更加实用。这种发现促使研究社区重新审视现有的方法论。

从工程实践的角度来看，这些发现具有重要的指导意义。软件公司在开发代码AI助手时，可以专注于架构层面的优化，而不必过度投入在复杂的数据工程上。这就像发现建造坚固房屋的关键在于地基的稳固，而不是装饰的精美。

研究还显示了迁移学习的强大威力。OpenCoder模型原本只能处理4K token的上下文，但通过相对简单的调整和适量的额外训练，就能有效处理16K token的长上下文。这种能力的快速获得表明，许多现有的模型可能都具有被开发的潜力，只是需要正确的方法来释放这种潜力。

对于实际的软件开发来说，这项研究预示着更好的代码AI助手的到来。当前的代码补全工具虽然有用，但往往缺乏对项目全局的理解。有了项目级的上下文理解能力，未来的AI助手将能够提供更智能、更相关的建议，就像一个真正理解项目架构的资深开发者。

六、局限性与未来方向

尽管这项研究取得了令人鼓舞的结果，研究团队也诚实地指出了其局限性。最主要的限制是研究只在OpenCoder模型上进行了验证，尚不清楚这些发现是否适用于其他架构的模型。这就像一个医学发现可能在特定人群中有效，但需要更广泛的验证才能确认其普适性。

另一个局限是研究专注于Python编程语言和特定类型的代码补全任务。不同编程语言有着不同的语法特点和编程范式，项目结构也可能差异很大。因此，这些发现在其他编程语言或任务上的有效性还需要进一步验证。

研究团队也指出，他们使用的基准测试虽然具有代表性，但仍然只是真实编程场景的一个子集。实际的软件开发涉及更复杂的上下文理解需求，包括跨语言依赖、动态生成的代码、第三方库的使用等等。

尽管存在这些局限，研究为未来的发展指明了几个有前景的方向。首先，可以将类似的方法应用到其他代码相关任务上，如代码修复、重构建议、安全漏洞检测等。如果简单的上下文扩展策略在这些任务上也同样有效，那将进一步证实研究发现的价值。

其次，可以探索更高效的检索策略来进一步提升性能。虽然当前研究显示不同组织策略的差异不大，但这并不意味着不存在更好的方法。未来的研究可能会发现真正能够显著提升性能的上下文组织策略。

另一个有趣的方向是研究模型在更长上下文下的行为。当前研究主要关注16K token的上下文，但现代AI模型的上下文处理能力正在快速发展。理解模型在处理整个大型代码库时的行为模式，将为开发更强大的代码AI提供指导。

最后，这项研究为"小而美"的AI模型发展提供了启示。在追求更大、更强模型的同时，探索如何让较小的模型在特定任务上达到优异性能，可能是一个更具可持续性的发展方向。

说到底，这项来自JetBrains Research的研究为我们展示了一个重要的道理：在AI研究中，有时候最简单的方法可能就是最有效的方法。与其花费巨大资源追求复杂的解决方案，不如深入理解问题的本质，找到真正的关键因素。对于整个AI代码助手领域来说，这个发现不仅节约了研发成本，也为更多研究者和开发者参与这个激动人心的领域降低了门槛。

当我们回顾这项研究时，最令人印象深刻的可能不是具体的技术细节，而是它所体现的研究哲学：保持开放的心态，质疑既有假设，用实证的方法寻找真相。在AI技术快速发展的今天，这种严谨而务实的研究态度显得尤为珍贵。对于那些希望深入了解这项研究技术细节的读者，可以通过论文编号arXiv:2510.13697v1查找完整的研究报告。

Q&A

Q1：OpenCoder模型如何在只用10亿token数据的情况下达到顶级性能？

A：关键在于RoPE位置编码参数的调整，将基础频率从10000改为500000，这让模型能够理解更长的上下文。研究发现，模型架构的调整比复杂的数据组织策略更重要，即使用简单的文件级训练也能获得显著的性能提升。

Q2：为什么不同的上下文组合策略效果差不多？

A：研究团队测试了11种不同策略，发现性能差异只有3.6分。这表明模型的长上下文理解能力主要来自架构调整，而非训练数据的精心组织。一旦模型具备了处理长序列的基础能力，就能从各种形式的上下文中学习。

Q3：这项研究对普通程序员有什么实际意义？

A：这意味着未来的AI代码助手将能更好地理解整个项目结构，提供更智能的代码建议。同时，这种"用更少资源达到更好效果"的方法将让更多公司能够开发高质量的代码AI工具，最终让程序员们受益于更强大、更便宜的AI助手。