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