[论文阅读] 人工智能 + 软件工程 | C3Gen：用检索增强让代码提交消息更“懂事“——附ApacheCM数据集详解

论文：Contextual Code Retrieval for Commit Message Generation: A Preliminary Study

arXiv:2507.17690
Contextual Code Retrieval for Commit Message Generation: A Preliminary Study
Bo Xiong, Linghao Zhang, Chong Wang, Peng Liang
Comments: The 19th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)
Subjects: Software Engineering (cs.SE)

C3Gen：用检索增强让代码提交消息更"懂事"——附ApacheCM数据集详解

研究背景：代码提交消息的"痛点"与现有方案的局限

如果你是程序员，一定遇到过这样的场景：改了一堆代码后，对着"提交消息"输入框发呆——到底该怎么写才能让同事（或者三个月后的自己）一眼看懂这次改了啥、为啥改？

在软件开发中，Git提交消息就像代码变更的"说明书"，记录着修改的性质、动机和影响。但现实是，写好这条"说明书"太费劲了。研究显示，约44%的提交消息都不达标，要么信息不全，要么说不清楚修改逻辑。

为啥会这样？现有自动生成提交消息（CMG）的工具也不太给力。它们大多只盯着"代码diff"（即修改前后的代码差异）来生成消息，但代码diff就像"局部快照"，没法反映修改在整个项目中的上下文——比如这个函数被哪些模块调用了、改了它会影响什么功能。打个比方，这就像只看拼图的一小块就想描述整幅画，肯定说不明白。

于是，研究者们开始思考：能不能让生成工具"多看点"？比如，把项目里和这次修改相关的其他代码也找来当参考，让消息更全面？这就是本文要解决的核心问题。

主要作者及单位信息

本文作者团队来自武汉大学计算机学院，包括Bo Xiong、Linghao Zhang、Chong Wang（通讯作者）、Peng Liang（通讯作者）

创新点：两大亮点打破现有局限

这篇论文的创新之处主要体现在两个方面：

1. C3Gen框架：给模型"喂"更多项目级上下文
   现有方法要么只看代码diff，要么只找相似的历史提交，但没人想到去挖掘"当前修改在整个项目中的关联代码"。C3Gen就做了这件事：它能从代码仓库里"搜"出和本次修改相关的代码片段（比如被修改函数的调用处、相关类的定义等），让模型在生成消息时不仅知道"改了什么"，还知道"改的东西在项目里扮演啥角色"。

2. ApacheCM数据集：给研究搭个"靠谱的舞台"
   以前的CMG数据集要么质量差（比如包含机器人自动提交的无意义消息），要么信息不全（缺仓库地址、提交时间等元数据）。而ApacheCM是从50个Apache顶级开源项目中精挑细选的，包含23万+提交，不仅经过严格过滤（比如剔除太长/太短的消息、排除机器人提交），还附带完整的元数据，堪称"高质量标杆"。

研究方法：C3Gen框架如何让消息"更懂代码"？

C3Gen的核心思路是"检索相关代码→增强输入→生成消息"，具体分三步，像搭积木一样简单：

第一步：建个"代码结构地图"（CSG）

先用工具解析项目里的所有代码，把类、函数这些"零件"的位置、名称记下来，再用一个"图"（CSG）把它们的关系画出来——比如哪个函数属于哪个文件、哪个类调用了哪个函数。这就像给项目代码画了张"导航图"，方便后续找关联。

第二步：给"地图"标注"修改点"

拿到本次代码diff后，先拆分成不同文件的修改，然后标记出被改的函数或类（比如"UserProcessor类被改了"）。接着，在第一步的CSG里找到这些被改实体的"关联者"（比如谁调用了UserProcessor），并把这些关联信息（如调用位置、文件名）加到图里。相当于在"导航图"上用荧光笔标出了"施工区域"和"周边道路"。

第三步：提取"有用的周边代码"

根据标记的"修改点"和关联信息，抽取出真正相关的代码片段：如果被改的函数在另一个函数里被调用了，就把那个调用它的函数完整代码抽出来；如果是在全局范围内被调用，就抽调用处前后25行代码。这些片段会和代码diff一起，作为模型的输入。

实验方法：拿四大模型"练手"，从客观到主观全面评估

研究者选了4个有代表性的大语言模型（GPT-4o、GPT-4.1、DeepSeek V3、DeepSeek R1），对比两种输入方式的效果：一种只给代码diff（叫"Naive"方法），另一种给代码diff+C3Gen检索到的代码片段。

评估指标分两类：

• 客观指标：用BLEU、ROUGE等计算生成消息与人工消息的相似度；
• 主观指标：请两位有3年+编程经验的工程师从"清晰度"（好不好懂）、“完整性”（信息全不全）、“正确性”（准不准）三个维度打分（1-5分）。

主要贡献：给代码提交消息生成领域的三大"礼物"

1. ApacheCM数据集：让研究有"好料"可用
   这个包含234,799个提交的数据集，不仅规模大，还解决了老数据集的"质量病"——有严格过滤步骤、去重、元数据完整，能作为CMG研究的标准化基准。

2. C3Gen框架：证明了"上下文"的价值
   实验显示，虽然C3Gen在BLEU等客观指标上提升有限，但在人工评估的"完整性"上平均提升了5%，说明加入关联代码后，生成的消息能涵盖更多关键信息。比如改了一个工具函数，C3Gen能让消息不仅说"改了工具函数A"，还能加上"这个函数被登录模块和支付模块调用，修改后修复了支付时的格式错误"。

3. 揭示了现有评估指标的"不靠谱"
   一个意外发现：程序员自己写的提交消息，在人工打分中得分远低于模型生成的。这说明靠"和人工消息相似度"来评判生成质量的客观指标，可能严重低估了模型的真实能力。

一段话总结：

本文提出C3Gen，一种基于检索增强生成的提交消息生成（CMG）框架，通过从代码仓库检索相关代码片段为模型提供仓库级上下文，以提升生成质量；同时构建了包含234,799个提交的高质量数据集ApacheCM。实验显示，在4个代表性大语言模型上，C3Gen在主观指标（尤其是完整性，提升约5%） 上表现优异，但客观指标改进有限；人工评估发现，开发者编写的提交消息质量显著低于模型生成的，凸显了基于相似度的客观指标的局限性。

思维导图：

详细总结：

1. 研究背景与目标

   • 在软件开发中，提交消息是记录代码变更的关键，但44%的提交消息质量不达标，存在信息不足等问题。
   • 现有提交消息生成（CMG）方法多仅依赖代码diff，缺乏仓库级上下文，导致生成质量有限。
   • 研究目标：提出检索增强框架C3Gen，结合相关代码片段提升CMG质量；构建高质量数据集ApacheCM。

2. 相关工作

   • CMG方法分为三类：
     • 规则-based：基于预定义规则/模板生成消息；
     • 检索-based：如NNGen，通过相似度检索相似diff的消息；
     • 学习-based：如CommitGen，将CMG视为神经机器翻译任务。
   • 现有RAG方法未整合仓库级代码上下文，存在局限。

3. 方法：C3Gen框架

   • 核心：通过检索相关代码片段为模型提供上下文，包含三个阶段：
     • 阶段1：构建代码结构图谱（CSGs）：利用tree-sitter解析代码，提取类、函数等信息，构建以源文件为根节点的CSG；
     • 阶段2：基于diff增强CSGs：解析diff识别修改实体，二次解析定位调用/实例化位置，用D节点存储相关信息增强CSG；
     • 阶段3：提取相关代码片段：基于修改实体和增强CSG，提取包含调用/实例化的函数体或前后25行代码，作为上下文。

4. 数据集：ApacheCM

   • 构建：基于GitHub上50个Apache顶级仓库，2015年以来的提交，经6项过滤标准处理；
   • 规模：234,799个提交（训练集249,830、验证集10,000、测试集10,000）；
   • 优势：包含完整字段（如commit SHA、时间戳）、经去重和过滤、可复现，覆盖10种语言；
   • 与现有数据集对比：

5. 实验设置

   • 研究问题：整合检索代码片段是否提升CMG模型在客观和主观指标上的性能；
   • 模型：GPT-4o、GPT-4.1、DeepSeek V3、DeepSeek R1（覆盖开源/闭源、通用/推理型）；
   • 指标：
     • 客观：BLEU、ROUGE-L、METEOR、CIDEr；
     • 主观：清晰度、完整性、正确性（1-5分评分）。

6. 实验结果

   • 客观指标：C3Ge

总结：解决了什么问题？有哪些成果？

这篇论文聚焦"如何让代码提交消息更全面"，做了三件事：

• 建了个高质量数据集ApacheCM，填补了现有数据的不足；
• 提出C3Gen框架，通过检索项目级关联代码，给模型补充关键上下文；
• 用实验证明，C3Gen能显著提升消息的完整性，同时暴露了现有评估指标的局限性。

简单说，它让自动生成的提交消息更"懂事"了——不仅能说清"改了啥"，还能讲明白"改的东西在项目里有啥用"。