JetBrains-Research/lca-codegen-large

该数据集主要包含代码补全相关的信息，涉及GitHub上的Python项目。每个数据点包括仓库名称、提交哈希、补全文件内容、补全行分类、仓库快照等信息。数据集通过克隆GitHub上的Python项目收集，补全文件是提交到仓库中的.py文件。数据集包含270个数据点，来自75个仓库和219个提交。

原始信息汇总

LCA Project Level Code Completion 数据集概述

数据集信息

特征结构

• repo: 仓库名称，格式为 {GitHub_用户名}__{仓库名称}，数据类型为 string。
• commit_hash: 提交哈希，数据类型为 string。
• completion_file: 包含完成文件内容的字典，结构如下：
  • filename: 完成文件的路径，数据类型为 string。
  • content: 完成文件的内容，数据类型为 string。
• completion_lines: 字典，键为行类别，值为整数列表（待完成的行号），类别包括：
  • committed: 包含至少一个在提交文件中声明的函数或类的行。
  • inproject: 包含至少一个在项目中声明的函数或类的行（不包括之前的）。
  • infile: 包含至少一个在完成文件中声明的函数或类的行（不包括之前的）。
  • common: 包含至少一个被分类为通用的函数或类的行（不包括之前的）。
  • non_informative: 被分类为非信息性的行，例如太短、包含注释等。
  • random: 从剩余行中随机抽取的行。
• repo_snapshot: 提交前仓库的快照，结构与 completion_file 相同，但文件名和内容组织为列表。
• completion_lines_raw: 与 completion_lines 相同，但抽样前。

数据分割

• test: 测试集，字节数为 2972013125，示例数为 270。

数据集大小

• 下载大小: 1242136049 字节
• 数据集大小: 2972013125 字节

配置

• default: 默认配置，数据文件路径为 data/test-*。

数据点结构

• repo: 仓库名称，格式为 {GitHub_用户名}__{仓库名称}。
• commit_hash: 提交哈希。
• completion_file: 包含完成文件内容的字典，结构如下：
  • filename: 完成文件的路径。
  • content: 完成文件的内容。
• completion_lines: 字典，键为行类别，值为整数列表（待完成的行号），类别包括：
  • committed: 包含至少一个在提交文件中声明的函数或类的行。
  • inproject: 包含至少一个在项目中声明的函数或类的行（不包括之前的）。
  • infile: 包含至少一个在完成文件中声明的函数或类的行（不包括之前的）。
  • common: 包含至少一个被分类为通用的函数或类的行（不包括之前的）。
  • non_informative: 被分类为非信息性的行，例如太短、包含注释等。
  • random: 从剩余行中随机抽取的行。
• repo_snapshot: 提交前仓库的快照，结构与 completion_file 相同，但文件名和内容组织为列表。
• completion_lines_raw: 与 completion_lines 相同，但抽样前。

数据收集方法

数据收集自 GitHub 上主要语言为 Python 的仓库。每个数据点的完成文件是在提交中添加到仓库的 .py 文件。提交前的仓库状态为仓库快照。

数据集统计

• 数据点数量: 270
• 仓库数量: 75
• 提交数量: 219

完成文件

• 行数中位数: 278
• 行数最小值: 200
• 行数最大值: 1694

仓库快照

• .py 文件数中位数: 84，范围从 3 到 255
• 非 .py 文件数中位数: 155，范围从 8 到 2174
• .py 行数中位数: 15466.5
• 非 .py 行数中位数: 18759

行计数

• infile: 2691
• inproject: 2595
• common: 693
• committed: 1322
• non-informative: 1019
• random: 1311
• 总计: 9631

搜集汇总

数据集介绍

构建方式

在代码智能与软件工程领域，代码补全作为提升开发效率的关键技术，其性能高度依赖于训练数据的质量与多样性。本数据集由JetBrains Research团队精心构建，旨在为项目级代码补全任务提供大规模、细粒度的评估基准。其构建过程始于对GitHub上以Python为主语言的仓库进行系统克隆，随后提取每个数据点中在特定提交中被新增的`.py`文件作为补全文件，并将提交前的仓库状态作为快照。数据集规模的界定基于仓库快照中`.py`文件的总字符数，范围限定在192K至768K之间，从而形成了包含270个数据点、横跨75个仓库与219个提交的高质量集合。

特点

该数据集的核心特色在于其多维度的标签体系与精细化的行级标注。每个补全文件中的代码行被划分为六类：`committed`（包含提交中声明的函数或类）、`inproject`（项目内声明）、`infile`（文件内声明）、`common`（常见标识符）、`non_informative`（无信息行）、以及`random`（随机采样行），这种分类方式深刻反映了代码补全任务中不同上下文依赖的层次。此外，数据集提供了原始标签（`completion_lines_raw`）与采样后标签（`completion_lines`）两种版本，便于研究者灵活设计实验。统计数据显示，补全文件行数中位数为278，仓库快照中`.py`文件数中位数为84，总标注行数达9631行，确保了评估的统计稳定性。

使用方法

使用本数据集进行模型评估极为便捷，研究者可通过HuggingFace的`datasets`库直接加载：`load_dataset('JetBrains-Research/lca-codegen-large', split='test')`。每个数据点包含仓库名、提交哈希、补全文件内容与路径、仓库快照、以及行级分类标签。在应用时，可将`repo_snapshot`作为上下文输入给代码补全模型，以`completion_file`中的`content`作为目标输出，并利用`completion_lines`中的标签对模型生成结果按不同类别进行分层评估。例如，可分别计算模型在`committed`类行上的准确率，以衡量其利用提交级上下文的能力。该数据集已集成至Long Code Arena评测平台，支持在线对比与结果提交。

背景与挑战

背景概述

在代码智能领域，代码补全作为提升开发者效率的核心工具，长期受限于对项目级上下文的理解能力。传统方法多聚焦于单文件或局部上下文的预测，难以捕捉跨文件、跨模块的语义依赖关系。为突破这一瓶颈，JetBrains Research于近年推出了LCA（Long Code Arena）系列数据集，其中lca-codegen-large版本由该机构主导构建，旨在系统评估大语言模型在项目级代码补全任务上的表现。该数据集通过分析GitHub上Python仓库的提交历史，精心筛选出270个数据点，每个数据点包含一个待补全文件及其提交前的完整仓库快照，覆盖75个仓库与219次提交。其核心研究问题在于：模型能否利用仓库范围内的全局依赖（如跨文件函数调用或类继承）生成准确补全？这一数据集的发布为代码生成模型从“行级”向“项目级”能力的跃迁提供了标准化评测基准，显著推动了该领域研究范式的演进。

当前挑战

该数据集所应对的领域挑战集中于代码补全的上下文扩展难题：传统模型仅依赖局部上下文（如当前文件或邻近行），而LCA要求模型从数十至数百个文件中提取有效信号，这考验其对长程语义依赖的建模能力，例如识别跨文件的函数定义或推断未显式导入的类。在构建过程中，团队面临多重技术挑战：首先，需从海量GitHub仓库中精准定位那些包含完整项目结构且补全文件具有明确语义标签的提交，避免噪声数据干扰评估；其次，设计了一套细粒度行级分类体系（如committed、inproject等），以区分不同依赖类型的补全难度，但如何确保分类规则在跨仓库场景下的一致性与客观性成为难题；此外，仓库快照规模差异悬殊（.py文件行数中位数达15466行），如何在计算资源有限条件下高效处理并平衡数据代表性，亦是构建流程中的关键瓶颈。

常用场景

经典使用场景

该数据集专为项目级代码补全任务而设计，聚焦于在大型代码仓库中预测跨文件的代码片段。数据点包含完整的仓库快照与待补全文件，并标注了补全行与仓库中函数或类定义的关联类别（如提交内、项目内、文件内等）。经典使用场景是训练和评估模型在复杂依赖关系下生成代码的能力，尤其适用于需要理解项目全局上下文的补全任务。

实际应用

在实际开发中，该数据集可支撑智能代码补全工具的研发，例如集成开发环境（IDE）中的实时补全建议。通过训练模型理解仓库快照中的全局依赖，工具能更精准地预测新代码中应引用的函数或类，减少开发者的手动搜索与记忆负担。尤其适用于大型Python项目，可显著提升编码效率与代码一致性。

衍生相关工作

该数据集衍生了Long Code Arena等评测基准工作，用于系统评估代码模型在长上下文场景下的表现。此外，基于其行级分类标签，研究者开发了上下文感知的代码补全模型，通过区分不同类型依赖的权重来优化预测。这些工作共同推动了代码生成模型从独立片段向项目级协作的演进，成为代码智能领域的重要基准资源。