聞樂 發(fā)自 凹非寺
量子位 | 公眾號 QbitAI

大模型也會玩信息差了。

Qwen3在基準(zhǔn)測試中居然學(xué)會了鉆空子。

FAIR研究員發(fā)現(xiàn)Qwen3在SWE-Bench Verified測試中，不按常理修bug，反而玩起了信息檢索大法。

不分析代碼邏輯，不定位漏洞根源，而是直接跑到GitHub上搜任務(wù)里的issue編號，精準(zhǔn)扒出了前人留下的修復(fù)方案。

能說嗎，會搜代碼才是真正的程序員行為吧。而Qwen3，你是真正的程序員。

Qwen3是如何鉆空子的

要知道，SWE-Bench Verified本來是檢驗(yàn)?zāi)Ｐ驼娴墩鏄屝薮a的基準(zhǔn)，相當(dāng)于編程屆的資格考試。

它的測試邏輯是這樣的：在代碼修復(fù)類任務(wù)中，它給模型的任務(wù)全是真實(shí)開源項(xiàng)目里的bug，比如修復(fù)某個(gè)功能異常、補(bǔ)全缺失的代碼模塊，核心要求是模型能讀懂現(xiàn)有的代碼、定位到問題在哪，最后生成能夠直接運(yùn)行的解決方案。

這原本考驗(yàn)的是模型從0到1解決問題的能力，但我們的Qwen3，可沒按這個(gè)劇本走。

FAIR研究團(tuán)隊(duì)追蹤它的操作軌跡發(fā)現(xiàn)，Qwen3拿到任務(wù)后，第一步不是分析代碼文件，而是調(diào)用工具檢索GitHub的提交日志。

具體操作是：

• 先切換（cd）到/workspace/django_django_4.1這個(gè)目錄；
• 然后執(zhí)行g(shù)it log —oneline —grep=“33628” —all這個(gè)命令。

git log是查看Git版本控制提交歷史的命令，—oneline讓提交歷史以簡潔的一行的形式展示。

—grep用于篩選提交指定內(nèi)容（在這個(gè)例子中是issue編號33628），—all則表示所有分支的提交。

最后以退出碼0表示命令成功執(zhí)行。

一番操作之后，Qwen3不用動腦子寫代碼就輕松“借鑒”了以前的成功答案。（怎么不算動腦子了呢）

其實(shí)不止Qwen3，研究者發(fā)現(xiàn)Claude 4 Sonnet也有類似的行為。

不過，模型能成功鉆空子，當(dāng)然也不全是自身的原因。

說回SWE-Bench Verified，它自身的設(shè)計(jì)就有漏洞——沒過濾未來倉庫狀態(tài)。

簡單說就是，這個(gè)測試用的是開源項(xiàng)目數(shù)據(jù)，所以它連帶著項(xiàng)目后續(xù)已經(jīng)解決bug的提交記錄一起放進(jìn)去了，相當(dāng)于把考題和參考答案混在一起，還沒設(shè)權(quán)限。

正常來說，測試應(yīng)該只給模型bug未修復(fù)時(shí)的項(xiàng)目狀態(tài)，讓它只看著題目解題。

但SWE-Bench Verified沒做這個(gè)篩選，導(dǎo)致模型能夠拿到bug已經(jīng)被修復(fù)后的數(shù)據(jù)

于是，只要用任務(wù)里的issue編號當(dāng)關(guān)鍵詞，就能在已解決的數(shù)據(jù)里找到現(xiàn)成的修復(fù)方案。

看來啊，不是只有人類知道搜答案比解問題簡單，現(xiàn)在大模型也知道了。（Doge）

雖然說，按正常規(guī)則，這些模型確實(shí)是在作弊，但也有網(wǎng)友覺得：只要能完成任務(wù)，利用規(guī)則漏洞也沒什么不行的。

所以，你覺得這種行為算作弊還是算Qwen3聰明呢？

[1]https://x.com/giffmana/status/1963327672827687316
[2]https://x.com/bwasti/status/1963288443452051582
[3]https://github.com/SWE-bench/SWE-bench/issues/465

— 完 —