写这个应该会写成一个系列，发现自己在复现优秀论文时总是会遇到问题，但是在毕业之前这大概是个常态。失败的项目其实更容易带给自己更多思考，所以记录一下。

一、论文摘要

仓库级代码补全会基于整个代码仓库中的更广泛信息，自动预测尚未完成的代码。
近年来，代码大语言模型（code LLM）的快速发展推动了仓库级代码补全方法的研究，并取得了令人鼓舞的成果。
然而，这些方法仍然存在一些问题，例如不恰当的查询构建、单路径代码检索，以及代码检索器与代码 LLM 之间的不对齐。

为了解决这些问题，我们提出了 CodeRAG，这是一个专门为检索增强的仓库级代码补全设计的框架，用于识别检索所需的相关且必要的知识。它的核心组成包括：

• 由对数概率引导的查询构建，

• 多路径代码检索，

• 以及基于偏好对齐的 BESTFIT 重排序。

在 ReccEval 和 CCEval 基准上的大量实验表明，CodeRAG 在性能上显著且持续地优于当前最先进的方法。
CodeRAG 的实现已在以下地址开源：
https://github.com/KDEGroup/CodeRAG

二、数据集

CCEval数据集：总结来说，多语言，考察项目的跨文件调用api的能力，具体来说，他会在build_query阶段不去查询最近的几个片段，而是查询大模型意义上最有用的片段，在数据检索阶段，会从整个仓库里检索有用的片段。

数据集分两部分，一部分是待补全代码，一部分是他们的原始仓库，待补全代码是从原始仓库中抽出来的，专门用于补全的build_query阶段。（build_query是指将文件划分为文本块chunks,拼接这个chunks和target_chunks，丢给llm，llm如果能从这个chunks中获取更丰富信息，则是有效chunks）。原始仓库主要是检索阶段使用，retrieve(主要是三种检索并行使用，dense,sparse,dataflow三种，第一种寻找语义上最相似的，sparse寻找形式上最相似，dataflow则顺着变量和函数之间的依赖关系，去寻找代码仓库里依赖最强的）。这样我们就获取了一些基于仓库的最有效的检索信息。

CCEval 具有以下特点：

1. 多语言（multilingual）

   • 覆盖 4 种主流编程语言：Python、Java、TypeScript、C#。

   • 因此不仅能测一个语言里的表现，也能比较模型在不同语言上的泛化能力。

2. 跨文件依赖（cross-file context）是强制需求

   • 数据集中每个测试用例里的“待补全位置”，都至少涉及一次跨文件 API 的调用或依赖。

   • 换句话说：如果模型只看当前文件，很难或根本不能正确补全，需要去“看”仓库其他文件。

3. 来源真实、开源且许可证友好

   • 从 GitHub 上选取了一批**真实的、开源且许可友好（permissive license）**的仓库构建数据。

   • 构建时特别避免和 The Stack 这类常用预训练语料重叠，以减少数据泄漏的风险。NeurIPS 论文集

4. 严格的自动构造流程

   • 作者使用基于静态分析（static analysis）的方式，在当前文件中定位哪些位置的补全必须依赖跨文件信息，再把这些位置做成测试样本。

三、评估指标

EM：验证代码完全补全的正确程度，只有0和1这两个指标。（困难指标）

ES：评估补全代码和真实代码的相似度。(这个指标相对好完成）

identifier EM:标识符完全匹配度

identifier ES:标识符相似度（看一些关键字，函数和变量命名是否相似）

四、复现过程

uv 还是 conda?我的答案是，如果你是Linux,和原环境一模一样，推荐uv。但是一旦有一个包版本不一样，就会导致uv lock无用，还是用conda比较好。

复现过程波折很多，首先是环境问题，vllm在windows上不能用，所以租了远程服务器。但是到后期又发现缺少哥大的原始数据，于是发邮件又找作者要，这个过程也是几经波折。github上其实有作者邮件，但是只有打开outlook会显示。
 

后期环境都配平了，开始实验。一共六个流程，4个可以本地跑，还有两个阶段：rerank和inference阶段都需要调用7B和8B这种参数量比较大的模型。

经过了build_query和retrieve阶段，获取了大量检索信息后，我们还得过滤，rerank（重新排序这些检索信息，并把最有效的筛选出来，筛选的方式也是给大模型，三种检索方式得到的数据合并去重过滤，然后给大模型，由于数据比较多，所以采用了划分windows，逐个窗口冒泡排序的进程）(这个阶段和Inference阶段是整个项目里最费算力的部分，因为这个第一次接触api调用，然后发现这玩意是真费算力，8B模型跑三千条数据大概得几百块，遂找了一家淘宝网站)。

找出最高质量的检索数据后，下一步就是build_prompt,使用检索信息和提示词一起拼接成prompt。

inference阶段把prompt送进llm,选择的是代码专用大模型，Qwen2.5-coder-7B模型，之前还在另一个网站上选过A30B模型，效果有差距但不多。

evaluation评估生成的数据。

到此，我的复现就结束了。这是我关于coderag领域的第一次复现。

五、复现结果

不是很好，两个ES都和原文差20个点，但是EM差的更多，只有不到10%。复现模型几乎和原文一模一样，我监控了rerank和inference阶段，是完全执行了。

但是原作者很好，回了我邮件告诉我数据地址，然后源代码仓库路径真的非常清晰，中间有个inference阶段用的东西是错的，很快可以检查出来，因为他们命名也很专业，但是我确实没有找到我复现失败的原因。

中间我尝试过30B(3B)激活的同源阿里模型替代Inference阶段的Qwen2.5-coder-7B模型，发现的确会效果更好一点。

复现持续了三周，体感还是很不错的，起码跑通了，但是那种效果始终跑不好的失败感还是会一直持续下去。

写这篇文章也是想纪念这段复现，不写的话两个月之后就真的什么也不记得了~