背景介紹與研究團(tuán)隊

2025年5月26日，由Nebius公司的Ibragim Badertdinov和Alexander Golubev領(lǐng)銜的研究團(tuán)隊在arXiv上發(fā)布了一篇具有前瞻性的研究論文（arXiv:2505.20411v1）。這支團(tuán)隊還包括來自同一機(jī)構(gòu)的Maksim Nekrashevich、Anton Shevtsov、Simon Karasik、Andrei Andriushchenko、Maria Trofimova、Daria Litvintseva和Boris Yangel。這篇論文為軟件工程領(lǐng)域的大語言模型評估帶來了一個全新的自動化框架——SWE-rebench。

在當(dāng)今科技快速發(fā)展的時代，基于大語言模型（LLM）的智能代理在軟件工程領(lǐng)域展現(xiàn)出了令人印象深刻的能力。從代碼生成、調(diào)試到自動化開發(fā)工作流程，這些智能代理正在逐步改變軟件開發(fā)的方式。研究人員們開始創(chuàng)建由LLM驅(qū)動的代理，這些代理能與真實(shí)代碼庫和開發(fā)環(huán)境交互，執(zhí)行操作并根據(jù)反饋調(diào)整行為。雖然像OpenHands、Moatless Tools和Agentless等依托專有模型的代理在SWE-bench等基準(zhǔn)測試中表現(xiàn)出色，但開源模型在這方面仍有很大的提升空間。

研究面臨的兩大挑戰(zhàn)

想象一下，你是一位教練，想要訓(xùn)練一支優(yōu)秀的足球隊。你會面臨兩個關(guān)鍵問題：首先，你需要足夠多樣化的訓(xùn)練素材，讓隊員能應(yīng)對各種比賽情況；其次，你需要一個公平的評估體系，確保能準(zhǔn)確判斷隊員的真實(shí)水平，而不是僅僅看他們在熟悉的訓(xùn)練場上的表現(xiàn)。

Nebius團(tuán)隊在研究中發(fā)現(xiàn)，軟件工程智能代理的發(fā)展正面臨著類似的兩大挑戰(zhàn)：

首先是高質(zhì)量訓(xùn)練數(shù)據(jù)的稀缺。特別是那些能反映真實(shí)世界軟件工程場景的數(shù)據(jù)，在這些場景中，代理需要與開發(fā)環(huán)境交互，執(zhí)行代碼并根據(jù)結(jié)果調(diào)整行為?，F(xiàn)有的數(shù)據(jù)集要么局限于一次性代碼生成，要么是小規(guī)模、手動整理的交互式任務(wù)集合，缺乏規(guī)模和多樣性。

其次是缺少新鮮的交互式軟件工程任務(wù)來評估快速進(jìn)步的模型。靜態(tài)基準(zhǔn)測試很快就會因?yàn)槲廴締栴}而過時，當(dāng)新模型在訓(xùn)練過程中可能已經(jīng)接觸過這些測試用例，導(dǎo)致評估結(jié)果被人為抬高。

SWE-rebench：一個創(chuàng)新的解決方案

為了解決這些限制，研究團(tuán)隊提出了一個全新的、自動化且可擴(kuò)展的管道，用于從多樣化的GitHub倉庫中持續(xù)提取真實(shí)世界的交互式軟件工程任務(wù)。這就好比建立了一個自動化的足球訓(xùn)練系統(tǒng)，不斷從世界各地的比賽中捕捉各種精彩的戰(zhàn)術(shù)動作，并自動整理成訓(xùn)練素材。

利用這個管道，團(tuán)隊構(gòu)建了SWE-rebench，一個包含超過21,000個基于Python的交互式軟件工程任務(wù)的公共數(shù)據(jù)集，適用于軟件工程代理的大規(guī)模強(qiáng)化學(xué)習(xí)。此外，研究團(tuán)隊還利用SWE-rebench方法持續(xù)收集的新任務(wù)，構(gòu)建了一個無污染的軟件工程代理評估基準(zhǔn)。

通過在這個基準(zhǔn)上比較各種LLM的結(jié)果，并與SWE-bench Verified的結(jié)果進(jìn)行對比，研究團(tuán)隊發(fā)現(xiàn)一些語言模型的性能可能因?yàn)槲廴締栴}而被人為夸大。這就像發(fā)現(xiàn)一些隊員在熟悉的訓(xùn)練場上表現(xiàn)出色，但面對全新的比賽場地和戰(zhàn)術(shù)時卻力不從心。

自動化管道的工作原理

SWE-rebench的核心是一個自動化管道，能夠大規(guī)模地收集、處理和驗(yàn)證軟件工程任務(wù)。想象這個管道像一條智能生產(chǎn)線，從原料（GitHub數(shù)據(jù)）到成品（可驗(yàn)證的軟件工程任務(wù)）全程自動化。這個管道包括四個關(guān)鍵階段：

第一階段是初步任務(wù)收集。系統(tǒng)從GitHub Archive和GitHub上下載原始數(shù)據(jù)，包括問題描述、討論、關(guān)聯(lián)的拉取請求等信息。它會將問題與解決它們的拉取請求鏈接起來，并應(yīng)用一系列過濾器選擇符合條件的實(shí)例。例如，問題必須來自許可證寬松的Python倉庫、已標(biāo)記為已解決、相關(guān)PR必須合并到主分支等。這個階段就像是在世界各地的足球比賽中初步篩選出那些包含精彩戰(zhàn)術(shù)配合的片段。

第二階段是自動化安裝指令配置。傳統(tǒng)方法如SWE-bench或SWE-Gym依賴手動整理來配置每個倉庫的可執(zhí)行環(huán)境，這種方法固有地限制了可擴(kuò)展性。而SWE-rebench則采用了一種完全自動化的方法，使用大語言模型來生成候選環(huán)境設(shè)置指令。這就像有一個AI助手，能自動理解每個足球訓(xùn)練素材需要的場地設(shè)置和器材準(zhǔn)備。

第三階段是基于執(zhí)行的安裝驗(yàn)證。為了確認(rèn)任務(wù)的可解決性和提供的測試的完整性，系統(tǒng)會在容器中安裝每個任務(wù)的環(huán)境，并執(zhí)行拉取請求的測試補(bǔ)丁。它會解析測試運(yùn)行輸出，確保：1）應(yīng)用解決方案補(bǔ)丁前，至少有一個測試失??；2）應(yīng)用解決方案補(bǔ)丁后，所有最初失敗的測試都通過；3）最初通過的測試在應(yīng)用解決方案補(bǔ)丁后仍然通過。這就像在實(shí)際訓(xùn)練前驗(yàn)證每個訓(xùn)練素材的有效性和挑戰(zhàn)性。

第四階段是自動化實(shí)例質(zhì)量評估。為了有效用于強(qiáng)化學(xué)習(xí)，收集的任務(wù)應(yīng)該具備某些特性，否則RL代理可能會生成看似失敗但實(shí)際上是由于任務(wù)不完善導(dǎo)致的軌跡。團(tuán)隊微調(diào)了一個指令跟隨模型，使用來自SWE-bench Verified的人工注釋來預(yù)測：問題清晰度（GitHub問題描述是否足夠詳細(xì)）、任務(wù)復(fù)雜性（解決問題的預(yù)估工作量）、測試補(bǔ)丁正確性（拉取請求中的測試是否準(zhǔn)確驗(yàn)證了預(yù)期的修復(fù)）。這就像有一個專家教練團(tuán)隊，能夠評估每個訓(xùn)練素材的質(zhì)量、難度和教學(xué)價值。

SWE-rebench數(shù)據(jù)集的特點(diǎn)

通過這個四階段管道，研究團(tuán)隊自動收集和處理了交互式軟件工程任務(wù)，產(chǎn)生了SWE-rebench數(shù)據(jù)集，其中包含21,336個帶注釋的任務(wù)實(shí)例。這個數(shù)據(jù)集公開發(fā)布在Hugging Face Datasets上，任何人都可以訪問。配套代碼，包括任務(wù)評估腳本，也在GitHub上提供。

SWE-rebench數(shù)據(jù)集的一個任務(wù)實(shí)例包含了問題描述、代碼更改（補(bǔ)丁和測試補(bǔ)?。┮约跋嚓P(guān)元數(shù)據(jù)，包括LLM生成的質(zhì)量評分和安裝配置。這些豐富的信息使得研究人員和開發(fā)者能夠根據(jù)特定需求篩選和選擇任務(wù)實(shí)例。

SWE-rebench評估基準(zhǔn)

除了提供大規(guī)模數(shù)據(jù)集外，研究團(tuán)隊還利用自動化管道構(gòu)建了SWE-rebench評估基準(zhǔn)。這個基準(zhǔn)由294個來自169個不同倉庫的可執(zhí)行任務(wù)組成，是經(jīng)過篩選的SWE-rebench數(shù)據(jù)集的一部分。

研究團(tuán)隊發(fā)現(xiàn)，現(xiàn)有的軟件工程代理評估面臨幾個關(guān)鍵挑戰(zhàn)：潛在的數(shù)據(jù)污染、由于腳手架變異導(dǎo)致的結(jié)果不可比、缺乏標(biāo)準(zhǔn)化和可驗(yàn)證的評估、以及代理性能在多次運(yùn)行中的高變異性。

為了解決這些挑戰(zhàn)，SWE-rebench評估基準(zhǔn)設(shè)計基于幾個核心原則：

首先是集中化和標(biāo)準(zhǔn)化的評估框架。所有在SWE-rebench上的評估都由研究團(tuán)隊使用固定的腳手架進(jìn)行，即每個模型都使用相同的最小ReAct風(fēng)格代理框架、相同的提示和默認(rèn)生成超參數(shù)。這就像在完全相同的比賽條件下測試不同的足球隊，確保比較的公平性。

其次是持續(xù)數(shù)據(jù)集更新和去污染。SWE-rebench使用自動化管道持續(xù)提供新鮮任務(wù)。由于系統(tǒng)精確跟蹤問題及其對應(yīng)拉取請求的創(chuàng)建日期與模型發(fā)布日期，可以明確標(biāo)記潛在被污染的評估，這些評估包括在模型發(fā)布日期之前創(chuàng)建的問題。這些評估在排行榜上被明確標(biāo)記，以確保關(guān)于可能數(shù)據(jù)泄漏的透明度。

第三是考慮代理行為的隨機(jī)性。為了捕捉性能變異性，研究團(tuán)隊在完整基準(zhǔn)上運(yùn)行每個模型五次。他們額外報告平均值的標(biāo)準(zhǔn)誤差(SEM)和pass@5指標(biāo)，提供對每個模型性能的統(tǒng)計基礎(chǔ)和更可靠的評估。

研究結(jié)果分析

研究團(tuán)隊利用SWE-rebench的去污染特性，分析了不同時間窗口任務(wù)上的性能趨勢，并識別先前基準(zhǔn)中潛在的污染效應(yīng)。具體來說，他們評估了模型在兩個不同時間子集的任務(wù)上的表現(xiàn)：2025年1月創(chuàng)建的任務(wù)和2025年3月至4月創(chuàng)建的任務(wù)。

研究結(jié)果顯示了幾個值得注意的觀察：

GPT-4.1是唯一一個在3月至4月子集上性能明顯下降的模型，相比于1月子集。這可能表明這個模型對某些特定類型的任務(wù)更敏感，或者在處理更新、更復(fù)雜的軟件工程問題時面臨挑戰(zhàn)。

LLaMa-4-Maverick表現(xiàn)出相對于具有類似平均解決率的模型更高的pass@5分?jǐn)?shù)，但解決率相對適中。這表明該模型可以產(chǎn)生正確的解決方案來解決更復(fù)雜的問題，但在多次運(yùn)行中缺乏一致性，展示了高潛力但執(zhí)行不一致。

Qwen2.5-Coder-32B-Instruct表現(xiàn)不如預(yù)期，特別是考慮到其強(qiáng)大的代碼生成能力。分析其軌跡顯示了指令遵循問題；模型經(jīng)?；孟氕h(huán)境響應(yīng)或陷入格式錯誤循環(huán)，最終在沒有產(chǎn)生有意義的解決方案嘗試的情況下失敗。

Qwen3模型在啟用或不啟用思考模式的情況下表現(xiàn)相似——在某些情況下，非思考變體甚至略微超過思考版本。這表明基礎(chǔ)模型的能力足夠強(qiáng)，以至于刻意規(guī)劃并不能提供可測量的優(yōu)勢。幾乎相同的pass@5分?jǐn)?shù)進(jìn)一步表明，即使沒有明確的推理機(jī)制，模型的問題解決效率仍然保持一致。

DeepSeek模型在SWE-rebench兩個子集和SWE-bench Verified基準(zhǔn)上都展示了開源模型中最強(qiáng)的性能。值得注意的是，DeepSeek-V3的12月和3月版本在解決率和pass@5方面始終優(yōu)于其他開放模型，突顯了它們對任務(wù)分布變化的穩(wěn)健性。

研究局限性與未來工作

盡管SWE-rebench自動化管道和由此產(chǎn)生的數(shù)據(jù)集旨在解決大規(guī)模、真實(shí)世界任務(wù)缺乏和去污染基準(zhǔn)的需求，但研究團(tuán)隊也坦誠地指出了幾個局限性：

首先是自動化任務(wù)質(zhì)量評估的局限。雖然他們采用了自動化質(zhì)量評估，但完全自動化的管道可能導(dǎo)致一些任務(wù)描述不完善或僅憑問題無法解決。這可能導(dǎo)致與手動整理的基準(zhǔn)相比，絕對成功率較低。

其次是有限的語言多樣性。SWE-rebench的初始版本及其底層數(shù)據(jù)集專注于基于Python的任務(wù)。從根本上說，他們的管道是與語言無關(guān)的，可以擴(kuò)展到包含使用其他編程語言的項目的任務(wù)。

對于未來的工作，研究團(tuán)隊計劃集中在幾個關(guān)鍵領(lǐng)域：

擴(kuò)大數(shù)據(jù)覆蓋范圍和數(shù)量。他們的目標(biāo)是通過將收集方法從嚴(yán)格與GitHub問題相關(guān)的任務(wù)擴(kuò)展到更廣泛的代碼更改集，顯著增加數(shù)據(jù)集的數(shù)量。

改進(jìn)任務(wù)過濾管道。為了提高提取任務(wù)的整體質(zhì)量，他們計劃改進(jìn)在管道中使用的過濾啟發(fā)式方法。

支持新的編程語言。應(yīng)用相同的核心方法，他們計劃為其他流行語言（如JavaScript、Java、C++）收集數(shù)據(jù)集，從而擴(kuò)展SWE-rebench的語言和技術(shù)多樣性。

保持SWE-rebench基準(zhǔn)的最新性。維護(hù)對現(xiàn)有模型的評估過程，評估更廣泛的LLM，并與社區(qū)分享詳細(xì)的性能分析。

結(jié)論與影響

歸根結(jié)底，Nebius團(tuán)隊引入的這個自動化數(shù)據(jù)收集管道和SWE-rebench基準(zhǔn)為開發(fā)和評估下一代LLM基礎(chǔ)的代理提供了一個至關(guān)重要的基礎(chǔ)，這些代理能夠應(yīng)對真實(shí)世界的軟件工程挑戰(zhàn)。

想象一下，這就像是為足球教練們提供了一個自動化系統(tǒng)，不斷從世界各地的比賽中收集新的戰(zhàn)術(shù)動作和訓(xùn)練素材，同時確保在全新、未見過的比賽場景中公平評估球員的能力。這樣的系統(tǒng)不僅能加速球隊的進(jìn)步，還能確保我們對球員能力的評估是真實(shí)可靠的。

對于軟件開發(fā)領(lǐng)域，SWE-rebench的出現(xiàn)意味著我們能夠開發(fā)出更加強(qiáng)大、更加適應(yīng)實(shí)際開發(fā)環(huán)境的AI助手，它們能夠理解復(fù)雜的代碼庫，解決真實(shí)的軟件問題，并在開發(fā)過程中提供有價值的幫助。這不僅能提高開發(fā)效率，還能降低軟件bug的發(fā)生率，最終為用戶提供更加可靠、高質(zhì)量的軟件產(chǎn)品。

對于想深入了解這項研究的讀者，可以在Hugging Face Datasets上訪問SWE-rebench數(shù)據(jù)集，或者通過arXiv:2505.20411v1查閱完整的研究論文。這項創(chuàng)新工作無疑將推動軟件工程AI助手的快速發(fā)展，為編程世界帶來更多可能性。