在當今以閉源模型為主導、各大科技公司嚴格保護核心 AI 技術的環境下，一個開源專案能夠真正挑戰行業頂尖產品實屬罕見。
然而，DeepSeek 前段時間更新的最新版本 DeepSeek-R1（0528）不僅做到了這一點，甚至在某些關鍵領域超越了 Claude Opus 4 和 GPT-4.1 這樣的頂級商業模型。
真正引起開發者社群關注的是 R1（0528）在大模型公共基準測試平臺 LMArena 上的效能排名超越了多個頂尖封閉模型。
在 WebDev Arena 中，DeepSeek-R1（0528）的效能表現與 Gemini-2.5-Pro-Preview-06-05、Claude Opus 4 (20250514) 等閉源大模型並列第一，更讓人驚訝的是，R1（0528）得分為 1408.84 分，在分數上已經超過了得分為 1405.51 的 Claude Opus 4。
WebDev Arena 是由 LMArena 開發的即時 AI 程式設計競賽平臺，專注於 Web 開發挑戰，讓不同 AI 模型同臺競技、一較高下。
想想 Claude Opus 4 背後的資源。Anthropic 已經籌集了數億美元，聘請了全球最優秀的 AI 研究人員，並擁有海量的計算資源。然而，由一個規模相對較小的團隊開發的 DeepSeek 卻擁有與之完全匹配的效能。
這樣的成就的確令人驚歎。因為要想在 WebDev Arena 測試中取得高分並不是件容易事。
WebDev Arena 測試的不僅僅是基本的編碼能力。它向這些模型提出了複雜、多步驟的開發挑戰。例如構建互動式元件、除錯複雜的 JavaScript 問題、處理 CSS 邊緣情況。這些挑戰將實際的開發能力與簡單的程式碼生成區分開來。
除了編碼之外，DeepSeek-R1（0528）在文字競技場中排名第六。現在，文字競技場的挑戰性變得更高，因為它測試廣泛的語言理解、推理和複雜任務的處理能力。
Text Arena 的測試也相對複雜。Text Arena 測試旨在揭示模型的弱點。這類挑戰設定得細緻入微、層次豐富，模型有時候會在這些挑戰中暴露出“幻覺”，甚至出現一本正經胡說八道的現象。
Text Arena 測試結果顯示 DeepSeek 能在文字能力上與 GPT-4o、Claude Opus 以及其他由鉅額企業研究預算支援的模型展開直接競爭。
在其他細分領域的測試中，DeepSeek-R1（0528）表現怎樣？具體測試結果如下：
-
在硬提示詞（Hard Prompt）測試中排名第 4 -
在程式設計（Coding）測試中排名第 2 -
在數學（Math）測試中排名第 5 -
在創意性寫作（Creative Writing）測試中排名第 6 -
在指令遵循（Intruction Fellowing）測試中排名第 9 -
在更長查詢（Longer Query）測試中排名第 8 -
在多輪（Multi-Turn）測試中排名第 7
2025 年 5 月 28 日，DeepSeek 釋出了 R1（0528）（或稱 R1.2），這是其開源大語言模型 DeepSeek R1 系列的最新升級版本。儘管官方將其定位為“小版本更新”，但實際測試表明，DeepSeek-R1（0528） 在推理深度、程式碼能力及整體穩定性上都有很大的提升。
它還是沿用了初代 R1 的混合專家（MoE）架構，總引數量高達 6850 億，但每次推理僅啟用約 370 億引數，確保高效計算。同時，它支援 128K tokens 的長上下文視窗，使其在長文字理解、程式碼分析和複雜邏輯推理任務中同樣表現出色。
此次升級的關鍵在於訓練後最佳化，DeepSeek 團隊透過改進推理策略和計算資源分配，使模型在數學推導、程式碼生成和複雜問題解決方面的能力大幅提升。
LMArena 最新測試結果在社交平臺上引發了諸多討論。
在 X 上，有 ID 名為 Sughu 的使用者表示，DeepSeek 與 Claude Opus 4 匹敵。這些數字令人難以置信。
還有使用者已經摩拳擦掌，迫不及待想試試 R1（0528）實際使用效果怎麼樣了。
還有使用者拿 R1 的開源特性調侃 Opus 等封閉模型。
“區別在於：Opus 讓你變窮，但 R1 是免費的。”
也有使用者認為，DeepSeek R1 目前在測試中顯現出來的效能表現的確是讓人印象深刻，但它也有一些地方不及 Claude，比如在使用者體驗方面還有待提升。
“DeepSeek R1 目前在 WebDev Arena 效能上與 Claude Opus 匹敵，鑑於 Claude 長期以來作為程式碼型 AI 基準的地位，這是一個值得注意的里程碑。
這標誌著開源人工智慧的關鍵時刻。DeepSeek R1 在完全開放的 MIT 許可證下提供了前沿級別的能力，表明開放模型如今已能夠與最優秀的專有系統相媲美。雖然這一突破在 Web 開發領域最為顯著，但其影響可能會擴充套件到更廣泛的編碼領域。
然而，原始效能並不能定義其實際效用。DeepSeek R1 在技術能力上或許能與 Claude 匹敵，但它在使用者體驗方面仍遠不及 Claude，而正是這種體驗讓 Claude 在日常工作流程中如此高效。”
在 Reddit 平臺上，一些使用者同樣對 DeepSeek R1（0528）強大的編碼能力表示讚揚，甚至覺得使用 R1 輔助程式設計的開發者能碾壓用其他封閉模型的開發者。
“DeepSeek R1（0528）很火。我知道這是 LMAarena 的測試（可能會有點不那麼準確），但我絕對相信 R1 的實力有能力做到如此。我覺得它用在程式設計上，它的效能確實能與 Gemini/OpenAI 和 Anthropic 的模型匹敵。一個能用 DeepSeek 的程式設計師會碾壓使用封閉模型的普通程式。”
但也有使用者對 WebDev Arena 測試的結果表示了懷疑，認為 DeepSeek 的確很強大，但在 WebDev 中與 Opus 比肩，還是不太相信。
“他們（LMArena）有沒有修改評級流程或模型？DeepSeek 很棒，但在 WebDev 領域能和 Opus 比肩嗎？不可能的！”
其實也不怪網友質疑 LMArena 的測試結果，因為前不久，AI 實驗室 Cohere、斯坦福大學、麻省理工學院和 Ai2 也聯合發表了一篇新論文，指責 LMArena 在榜單分數上偏袒一些科技巨頭公司。
論文地址：https://arxiv.org/pdf/2504.20879
據作者稱，LMArena 允許一些行業領先的 AI 公司（例如 Meta、OpenAI、谷歌等）私下測試多種 AI 模型變體，並且不公佈表現最差的模型的得分。作者表示，這使得這些公司更容易在該平臺的排行榜上名列前茅。
作者稱，在科技巨頭 Meta 釋出 Llama 4 之前的 1 月至 3 月期間，一家名為 Meta 的 AI 公司在 Chatbot Arena 上私下測試了 27 種模型變體。在釋出時，Meta 只公開透露了一個模型的得分——而這個模型恰好在 Chatbot Arena 排行榜上名列前茅。
這項研究的圖表。（圖片來源：Singh 等人）
面對這些指控，LMArena 聯合創始人兼加州大學伯克利分校教授 Ion Stoica 在給媒體的一封電子郵件中表示，這篇論文充滿了“不準確之處”和“值得懷疑的分析”。
巧合的是，今天月之暗面釋出了針對軟體工程任務的全新開原始碼大模型 Kimi-Dev-72B。
Kimi-Dev-72B 專案地址：https://huggingface.co/moonshotai/Kimi-Dev-72B
該模型在 SWE-bench Verified 程式設計基準測試中取得了 全球最高開源模型水平，以僅 72B 的引數量，成績超過了 R1（0528），而 R1（0528）在中 LMArena 的編碼能力測試中與谷歌、Anthropic 模型並列第一。
Kimi-Dev-72B 在 AI 軟體工程能力基準測試 SWE-bench Verified 上取得了 60.4% 的高分，創下開源模型的 SOTA 成績。
Kimi-Dev-72B 透過大規模強化學習進行了最佳化。它能夠自主修補 Docker 中的真實儲存庫，並且只有當整個測試套件透過時才會獲得獎勵。這確保瞭解決方案的正確性和穩健性，並符合現實世界的開發標準。
在月之暗面官網上，研發團隊介紹離 Kimi-Dev-72B 的設計理念和技術細節，包括 BugFixer 和 TestWriter 的組合、中期訓練、強化學習和測試時自我博弈。
一個成功修復漏洞的補丁應透過能準確反映該漏洞的單元測試。同時，一個成功復現漏洞的測試應觸發斷言錯誤，而當向程式碼庫應用正確的漏洞修復補丁後，該測試應能透過。這體現了漏洞修復者（BugFixer）與測試編寫者（TestWriter）的互補作用，而能力足夠強的編碼大語言模型應能在這兩方面都表現出色。
漏洞修復者與測試編寫者遵循相似的工作流程：二者均需先找到需要編輯的正確檔案，再進行程式碼更新（無論是修正脆弱的實現邏輯，還是插入單元測試函式）。因此，針對這兩種角色，Kimi-Dev-72B 採用了相同的極簡框架，僅包含兩個階段：（1）檔案定位；（2）程式碼編輯。漏洞修復者與測試編寫者的雙重設計，構成了 Kimi-Dev-72B 的核心基礎。
為了增強 Kimi-Dev-72B 作為漏洞修復者（BugFixer）和測試編寫者（TestWriter）的先驗能力，研發團隊採用了約 1500 億高質量真實世界資料進行中期訓練。
它們以 Qwen 2.5-72B 基礎模型為起點，收集了數百萬條 GitHub 問題與 PR 提交記錄作為中期訓練資料集。該資料方案經過精心構建，旨在讓 Kimi-Dev-72B 學習人類開發者如何基於 GitHub 問題進行推理、編寫程式碼修復方案及單元測試。研發團隊還執行了嚴格的資料淨化處理，排除了 SWE-bench Verified 中的所有程式碼庫。中期訓練充分強化了基礎模型在實際漏洞修復和單元測試方面的知識，使其成為後續強化學習（RL）訓練更優的起點。
透過適當的中期訓練和 SFT，Kimi-Dev-72B 在檔案本地化方面表現出色。因此，強化學習階段專注於提升其程式碼編輯能力。
Kimi-Dev-72B 使用了 Kimi k1.5 中描述的策略最佳化方法，該方法在推理任務中表現出色。對於 SWE-bench Verified，有三個關鍵設計值得重點關注：
-
僅基於結果的獎勵。研發團隊僅使用 Docker 的最終執行結果（0 或 1）作為獎勵，訓練期間不採用任何基於格式或過程的獎勵。 -
高效的提示集。研發團隊過濾掉模型在多樣本評估下成功率為零的提示，從而更有效地利用大批次。此外，他們還採用課程學習法，引入新的提示，逐步提高任務難度。 -
正例強化。在訓練的最後階段，研發團隊將之前迭代中最近成功的樣本納入當前批次。這有助於模型增強成功模式並提升效能。
Kimi-Dev-72B 透過使用高度並行、強大且高效的內部代理基礎設施，從可擴充套件數量的問題解決任務的訓練中受益匪淺。
經過強化學習後，Kimi-Dev-72B 能夠同時掌握 BugFixer 和 TestWriter 的角色。在測試過程中，它會採用自我博弈機制，協調自身 Bug 修復和測試編寫的能力。
BugFixer 和 TestWriter 之間的測試時自我對弈。
每個問題最多可生成 40 個補丁候選和 40 個測試候選（按照標準無代理設定），可以觀察到測試時間自玩的擴充套件效應。
參考連結：
https://www.reddit.com/r/LocalLLaMA/comments/1lcy6fc/deepseek_r1_0528_ties_claude_opus_4_for_1_in/
https://x.com/lmarena_ai/status/1934650635657367671
https://techcrunch.com/2025/04/30/study-accuses-lm-arena-of-helping-top-ai-labs-game-its-benchmark/
https://moonshotai.github.io/Kimi-Dev/
