CodeRAG-Bench：RAG遇到了Coder，哪个模型在RAG的加持下最会写代码？

1. CodeRAG-Bench是什么？

图片

CodeRAG-Bench是本文作者为检索增强代码生成（Retrieval Augment Code Generation，RACG）任务设计的一个测试评估基准。构建理念来自三个核心要素：

• 任务多样性：代码生成任务覆盖了从代码行到函数再到整个代码库的不同层面，以及封闭与开放的不同领域。

• 严谨且可复现的评估机制：提供了精确的文档标注，以支持检索评估。

• 统一的接口设计：尽管现有数据集采用了多样化的处理流程，代码库提供了一个统一的接口，用于实现检索、增强生成及评估。

接下来的内容里，作者从CodeRAG-Bench的构建角度来向大家展示了CodeRAG-Bench的全貌：在本节中，我们将详细介绍CodeRAG-Bench的构建流程：编程问题分类、检索资料收集、标注标准文档以及设置评估流程。

2. 如何将编程任务进行分类

本文作者专注于Python编程任务，将Python编程任务和数据集归为四大类：代码检索、基础编程、开放域问题、仓库级代码问题。

图片

2.1.1 基础编程问题

这一类问题通常以面试题目的形式出现，主要依赖Python的内置功能来解决算法挑战。

选取了两个广泛使用的数据集：HumanEval 和 MBPP ，它们要求模型根据自然语言描述来补全函数。

然而，由于模型训练数据的公共信息有限，HumanEval 和 MBPP 数据集是否被模型用于训练数据，从而带来数据污染？

所以，作者还引入了LiveCodeBench ，收集了在相关语言模型训练截止后，来自编程网站的题目，以降低潜在的数据污染风险。

2.1.2  开放领域问题

开放域问题是指一些超出了Python标准库的编程问题。

作者采用了DS-1000和ODEX测试数据集，DS-1000收集了Pandas、numpy等7个常用相关库的问题，ODEX包括了79个库的问题，比如requests、sqlalchemy等库的操作。

2.1.3  仓库级别编码问题

除了函数级别的编码任务外，有些问题需要在GitHub仓库的完整上下文中编辑文件。因此，采用了RepoEval 和 SWE-bench 进行仓库级别的代码生成和问题解决任务。

2.1.4 代码检索问题

除了用于增强生成的检索任务外，还采用了 CodeSearchNet（CSN）来测试代码检索任务。

3. 效果评估

3.1 检索方面评估

在检索方面，作者采用了NDCG、精确度、召回率来进行评估，并将NDCG@10的百分比作为主要衡量标准。

NDCG的全称是：Normalized Discounted Cumulative Gain(归一化折损累计增益）。NDCG的核心思想是，一个高质量的搜索结果应该在列表中排在更靠前的位置。因此，它不仅考虑了检索结果的相关性，还考虑了这些结果的排名顺序。NDCG值越高，表示搜索或推荐系统的性能越好。

选择了三大类别中的顶尖检索工具：

• 稀疏检索器：BM25
• 密集检索器：BGE-base/large、GIST-base/large和SFR-Embedding-Mistral
• API：voyage-code-2和openai-text-embedding-small-03

3.1.1 密集检索器和稀疏检索器哪个更好？

作者发现：密集嵌入模型在很多情况下能够超越BM25。这可能是因为许多竞争力强的检索模型经过了多领域、多样化任务的训练，包括代码数据的处理[1, 36]，从而在代码检索环境中展现出更强的鲁棒性。

3.1.2 更大尺寸的检索模型是否表现更佳？

在密集检索模型中，模型规模的扩大往往与检索性能的提升成正比，这与语言模型中观察到的趋势一致。

以GIST-large（0.34B）为例，它的表现始终超越了GIST-base（0.11B）。而SFR-Mistral（7B）在各项任务中均展现出了最好的性能，力压所有开放源代码的稀疏与密集模型，甚至在某些任务上超越了OpenAI的嵌入技术。

3.1.3 处理效率

虽然大尺寸的检索模型通常表现更优，但它们也常常带来显著的成本。作者对处理效率进行了分析，重点关注两个方面：

• 编码延迟：文档离线编码的延迟
• 搜索延迟：查询/文档编码及相似度计算的延迟
• 模型存储需求
• 索引存储需求

图片

3.2 代码生成评估

在代码生成方面，采纳pass@k指标[5]来评价程序执行的正确性。同时在规范检索和开放检索两种设置下对RAG的综合表现进行评估。

采用了StarCoder2、CodeGemma、CodeLlama和DeepSeekCoder等不同规模的模型作为测试基准进行对比。

对于通用文本语言模型，我们涵盖了三款表现最佳的模型：Llama3、专为RAG优化的Command-R，以及专有的GPT模型gpt-3.5-turbo-0125和gpt-4。

在代码生成方面，我们设定温度参数0.2，top_p采样比例为0.95。

通过两种方式来界定RACG性能的理论极值：

• 一种是完全不使用检索的生成
• 另一种是结合了标准答案文档的生成

图片

注：上图中，斜杠前的是完全不使用检索，斜杠后是使用标准文档后。绿色标注（ii）超过（i）的成果，颜色越深表示增加超过10次，否则用红色标示。

开放域： 大多数代码专属的语言模型得分激增，最高可达5.2分，这显示出它们能够高效地消化间接有益的文档资料。在众多通用语言模型中，Command-R独树一帜，它在两个数据集的上下文中均显示出增益，这与其卓越的RAG能力相吻合。然而，即便是最强的GPT模型，似乎也没有从上下文中获得额外优势，这可能归因于它对这些库的先前熟悉度，因为训练有素的模型倾向于记忆流行知识点，对于它们来说，检索的增益微乎其微。

代码库： 所有模型通过RepoEval的标准片段得分提升了7.5至17.2分。然而，SWE-bench Lite的难度显著增加，即便是顶尖的GPT模型，在标准测试中也仅达到了2.7%的准确率。这种难度的提升可能源于复杂的多文件编辑任务和冗长的上下文，这些都极大地考验了大多数模型的处理极限。将探索更高效的推理策略与RAG结合的可能性，作为未来研究的方向。

更大的模型与它们的小型对应版本一样，均能获得显著的性能提升，这表明RACG普遍有助于提升不同规模模型的能力。然而，要充分激发RACG的潜力，较弱的语言模型需要：

• 扩展它们的上下文长度，以纳入更多的文档资料
• 进一步提升它们处理上下文的能力。

3.4 检索辅助的代码生成实验

在全面的RACG场景中进行实验，这不仅需要检索相关文档，还需基于这些文档进行生成代码。精选了各类中的顶尖检索模型：BM25、GIST-large，以及OpenAI和Voyager的嵌入技术。

在生成方面，挑选了：

• StarCoder2-7B

• DeepSeekCoder-7B

• GPT-3.5-turbo。

图片

3.4.1 基础编程问题

大部分检索到的上下文对StarCoder2的生成过程大有裨益。在MBPP数据集上，RACG的表现甚至超越了仅使用标准文档设置的15.6至17.8个百分点。然而，对于DeepSeekCoder而言，RACG并未带来提升，当存在额外上下文时，其生成过程会变得过于复杂，且重复性高，缺乏规范性。这可能意味着DeepSeekCoder对额外上下文的处理不够稳健，因此在面对不同的输入时可能会产生不理想的行为。与此相反，GPT-3.5-turbo能够通过增加上下文有效提升性能，显示出其在利用增强上下文方面的卓越能力。

3.4.2 开放域问题

StarCoder2在两个数据集上通过检索到的库文档获得了显著的性能提升，而DeepSeekCoder仅在ODEX数据集上有所进步，GPT-3.5则在两个数据集上均未见提升。

我们推测，模型对某一领域的陌生程度越高，它从检索文档中获得的帮助就越大。同时，不佳的检索结果也可能削弱RACG的有效性。

DeepSeekCoder能够从真实文档中获益，但对于那些可能质量不高的、由模型检索出的文档则没有获益，这表明我们需要更高效的代码检索模型。

3.4.3  仓库级别问题

所有模型都能从RepoEval检索到的代码片段中获益，尤其是使用openai-embeddings的RACG经常能够超越仅使用标准文档设置的表现。尽管某些文件并未像标准文档那样直接包含问题的解决方案，但它们可能包含有益于最终生成过程的函数定义或使用示例，这表明openai-embeddings对仓库的理解相当深入，能够检索到隐含的支持性上下文。然而，SWE-bench-lite的复杂性极高，以至于没有任何RACG设置能够取得显著的成果。

3.5 究竟需增补多少文档？

各类模型在上下文长度限制和利用上下文的能力上存在差异。探究了在提供不同数量文档作为上下文时，模型表现如何变化。

针对每个任务类别精选了一个数据集进行试验：HumanEval因其广泛的应用；ODEX因其跨领域的广泛覆盖；RepoEval因其适中的难度。

图片

对比了在提供前1、2、5和10个文档时RACG的性能差异。大多数情况下，包含Top5能带来最优结果，尽管在RepoEval中StarCoder2更倾向于使用Top8。尽管StarCoder2和DeepseekCoder在上下文限制上存在巨大差异，但最佳选择始终是前5个文档。虽然适量增加文档能带来有益的上下文，但过多低相关性的文档可能会引入干扰，影响生成质量，这归咎于检索系统的不完善之处。

4. 开放检索下的RACG

4.1 RACG能否助力弱势模型？

我们使用三个顶尖检索器和StarCoder2生成模型，检验RACG是否能够助力较弱的代码语言模型。

基础编程： HumanEval 在所有来源中，StackOverflow（SO）的帖子能提升结果1.8至4.3个百分点，与选择的检索器无关。只有当使用GIST-large神经检索器时，教程才能提升结果2.1个百分点，这可能是因为其适应性。通过手动检查结果，发现许多检索到的帖子和教程与HumanEval示例是相同编程问题的变体，包含代码和详细的文本解释，因此可能暗示或直接给出答案。其他检索来源通常不包含相关上下文，因此对生成没有改进。混合文档生成的表现与使用最佳文档相当，表明模型能够从混合文本中识别并整合最有用的内容。

开放领域： ODEX 编程解决方案是最有益的资源，能带来3.8至4.3个百分点的增益；GitHub文件也提升了0.9至2.3个百分点。尽管检索到的解决方案/文件有时在功能上与ODEX示例相关，但它们展示了如regex和requests等库的正确用法，从而引导生成更加功能正确。

仓库级别： RepoEval 来自开放来源的文档不如从本地仓库检索的代码片段有用。

4.2 RACG对更强模型的助力如何？

开放检索的RACG能显著提升StarCoder2这一相对弱势模型的性能。为了探究RACG的这种提升效果是否同样适用于更为强大的模型，对一系列顶尖的专有模型进行了测试：GPT-4o、Claude-3的haiku/sonnet版本，以及Gemini-1.5的flash/pro版本。

基础编程： HumanEval 利用所有文档资源时，RACG能稳定提升GPT-4和Claude-3-sonnet的表现。然而，对于像Claude-3-haiku和Gemini-1.5-flash这样的较弱模型，RACG只有在整合多个资源时才有效，若仅依赖单一资源（哪怕它是标准解决方案资源）则效果不佳。值得注意的是，性能更强的Claude-3-sonnet在某些情况下表现不如较弱的Claude-3-haiku，但它能从所有检索资源中获益，并在标准编程资源文档的辅助下超越haiku，这暗示了它可能具有更出色的RAG能力。虽然更强大的Claude能从额外的上下文中获得实质性的好处，但更强大的Gemini-1.5-pro在非标准资源上的表现却与其较弱的对应版本相似，无法有效执行RACG。

开放领域： ODEX 所有模型通过利用库文档来增加ODEX任务的复杂度，所获得的提升有限，唯一的例外是GPT-4o，它通过将编程解决方案融入上下文，分数提升了4.6分。

由于大多数情况下性能会下降，我们进行了深入分析，以确定模型在何时失败。大多数模型倾向于复制上下文中的函数，有时甚至会覆盖正在查询的函数，导致所有针对该查询函数的测试用例均告失败。此外，由于上下文中程序众多，模型倾向于生成过于复杂的程序，这些程序往往无法通过测试用例。

总体而言，大多数模型容易受到额外上下文的干扰或分心，未能完成指定的代码生成任务，这表明RACG还有很大的提升空间。

仓库级别： RepoEval GPT-4o在解决RepoEval任务时，能够以合理的成功率完成，而所有Claude模型在这项任务上都遇到了挑战，大多数情况下pass@1的成功率不足10%。发现Claude模型通常以解释不完整的输入代码作为回应，而不是提供待完成的代码，即使给出了正确的指令，这可能是由于未知的训练数据特性所致。Gemini-1.5-flash在解决任务上也几乎无能为力，经常生成文本解释；然而，其更强大的pro版本在得分上提高了10至25分，显示出其在仓库级代码补全方面更强的能力。

本文转载自 ​​大语言模型论文跟踪​​，作者：HuggingAGI