博客 / 詳情

返回

美團開源OIBench與CoreCodeBench:揭示大模型編程能力的真實水平

Meituan-M17 團隊聯合上海交大等機構,分別推出了 OIBench(聚焦高區分度算法題評測)與 CoreCodeBench(聚焦多場景工程級代碼基準)兩大數據集,旨在揭示大模型編程能力真實水平,這兩大數據集已分別在GitHub和Huggingface上進行開源。

當前,大語言模型(LLMs)在編程領域的能力宣稱引人矚目——DeepMind 的 AlphaCode 曾對標人類競技編程選手,OpenAI 頂尖模型屢被報道通過谷歌面試、挑戰 LeetCode 表現不俗。然而,當深入審視這些模型在真實、複雜場景下的表現時,現有評估體系的深層侷限性便暴露無遺,形成了顯著的“宣傳與現實的認知鴻溝”。

一方面,在算法能力評估上,儘管模型在傳統基準(如 HumanEval、MBPP)上通過率高達90%,但移植到更高難度的信息學奧賽或 Codeforces Div.2 C 級題目時,頂尖模型的通過率驟降至個位數或不足15%,遠遜於人類選手(如ACM校隊成員平均70%),動態規劃等題型錯誤率甚至超80%。傳統評測集已“飽和”且區分度不足,新引入的高難度題目又面臨數據“泄漏”風險和人機對比(Elo)的復現性差、效率指標粗略等問題。

另一方面,轉向真實工程能力評估,問題同樣嚴峻。現有工程基準(如 FullStackBench、SWEBench)雖在多樣性和語言覆蓋上有進展,但其任務類型主要集中於單段落代碼生成,難以覆蓋真實開發中跨文件協作、代碼修復(BugFix)、測試驅動開發、多函數協同等核心環節。數據構建方法也受限於隨機挖空(易忽略核心邏輯)或依賴稀缺的 GitHub PR 記錄(需大量人工清洗標註),導致評測“偏科”,無法科學、全面地評估模型在複雜工程中的準確性、健壯性和適用性。

為了系統性地解決這兩大評估困境——更真實地衡量頂尖模型的算法推理能力與更全面地評估其工程級代碼能力——Meituan-M17 團隊聯合上海交大等機構,分別推出了 OIBench(聚焦高區分度算法題評測)與 CoreCodeBench(聚焦多場景工程級代碼基準)兩大數據集,並託管於 AGI-Eval 評測社區。下文將詳細介紹它們的構建理念、評測方法及對主流大模型能力的深度剖析。

OIBench篇

背景:評測集侷限性的深層分析

儘管 GPT-4o 模型被冠以 "競賽級" 頭銜,甚至有聲音稱其算法水平接近 ACM 區域賽金牌選手,但實際在面對未經大量公開數據訓練的、更高難度的信息學奧賽級別問題時,其通過率卻往往低至個位數,與 985 級別高校 ACM 校隊成員的平均通過率存在顯著差距。

當部分評測宣稱 Claude 3.5 Sonnet 可替代中級開發人員時,它在動態規劃等高難度題型中錯誤率卻高達 80% 以上,且無法獨立完成需數學建模的複雜競賽題。

諸如文心一言、通義千問等模型在 MBPP 基礎題庫中通過率可達 90% 以上,但移植至 Codeforces Div.2 C 級題目時,通過率卻不足 15%,遠低於人類選手平均 70% 的水平。

這些鮮明的對比,共同指向一個核心問題:當前對 LLM 編程能力的評估,存在明顯的 "宣傳與現實的認知鴻溝"。這種差異不僅源於模型能力邊界的複雜性,也暴露出現有評估體系的諸多侷限性。具體表現為:

  • 評測集 “飽和” 與區分度不足:傳統評測集(如 HumanEval、MBPP)由於模型能力的快速提升,通過率普遍超過 90%,已無法有效區分最先進模型的細微優劣。
  • 數據 “泄漏” 風險: 儘管一些新評測集(如 Codeforces、USACO、LeetCode)引入了高難度題目,但由於大模型預訓練數據包含大量互聯網公開內容,這些題目可能已被模型 “見過”,導致評測結果虛高,無法真實反映其推理能力。
  • 人機對比的侷限性:現有基於 Elo 評分體系的模型與真人選手對比方法,存在週期長、選手水平波動大、復現性差等問題,難以提供精確且可靠的評估。

效率指標的粗略性: 部分評測雖引入運行時間、內存等效率指標,但通常僅為粗略的平均分,無法細緻反映模型在不同類型題目上的性能差異。

為了解決上述這些評估困境、評測出全球頂尖模型真實的編程能力, Meituan-M17 團隊推出了更真實、更具區分度的評估基準 OIBench 數據集,並託管於 AGI-Eval 評測社區,並在 Huggingface 和 GitHub 上開源。基於此數據集,我們對全球 18 個主流大模型的算法編程能力進行了系統評測並量化得分,詳細評分榜單如下所示,可以看到全球頂尖大模型距離以往所宣稱的編程能力還存在很大差距,哪怕是最高分的 o4-mini-high 也僅僅只有 36.35 分,距離人類競賽選手的水平還相差甚遠,甚至很多模型只有個位數的得分。

表1: OIBench AC Rate表

OIBench 的評測榜單未來將由 AGI-Eval 評測社區長期維護更新,歡迎持續關注。榜單地址如下:

  • 網頁端地址:https://agi-eval.cn/evaluation/detail?id=60
  • 微信公眾號文章:AGI-Eval大模型評測
  • 論文地址:https://arxiv.org/abs/2506.10481
  • Github地址:https://github.com/AGI-Eval-Official/OIBench

本文數據均引用自 OIBench v1.0 論文(arxiv:2506.10481v3),發佈日期 2025 年 6 月 13 日。

接下來為大家詳細介紹 OIBench 數據集是如何構建以及如何對大模型進行評測的。

1. OIBench 的構建與創新

OIBench 是一個高質量、私有且極具挑戰性的信息學奧賽級別算法題庫,旨在提供一個更真實、更具區分度的評估基準。該數據集的算法題主要來源於中國 ACM-ICPC 隊伍和信息學奧賽的高校教練團隊精心編纂,他們擁有豐富的高難度算法題設計經驗和獨到見解。

為了確保 OIBench 題目的高質量和高挑戰性,我們制定了三條嚴格的准入標準,OIBench 具備以下關鍵特性:

  • 原創性與私有性:OIBench 包含 250 道候選題目,經難度驗證後保留 212 道高難度、防泄漏的信息學奧賽題目(IOI Level)。所有題目在發佈前都經過嚴格檢索,確保未在任何公開平台出現,最大程度避免數據污染風險。
  • 難度分級與把控:每道題目都參照信息學競賽和 Codeforces 難度評級進行標註。同時,為避免主觀偏差,我們引入了自動化驗證機制 —— 只有當 GPT-4o、Qwen2.5-Coder-32B、Doubao-32k-pro、Llama3.1-405B 這幾個標杆大模型中 “最多隻有一個模型能解出” 時,該題才會被收錄,從而確保了題目的 “硬核” 難度。
  • 高標準測試用例與標準解答:每道題都配備覆蓋大數據量、邊界情況等多樣的測試用例,力求暴露代碼在時間和空間上的潛在瓶頸。同時,每道題都必須配備經過所有測試用例嚴格驗證的 C++ 標準解答,以確保題目本身的準確性及評測的公正性。
  • 中英文雙語支持: 數據集提供中英文雙語版本,方便全球大模型從業者使用。

我們還在論文中展示了 OIBench 與其他主流評測集的對比(見下表),可以看到 OIBench 在題目難度和測試用例規模上都相對更高。

表2: OIBench 與其他代碼評測集基礎統計信息表

OIBench 在題目難度和測試用例規模上顯著領先於其他主流評測集。例如,在其他榜單上表現較好的 GPT-4o 模型在 OIBench 上僅能答對 2.6% 的題目,同時 OIBench 的測試用例數量大幅超過了其他算法競賽基準,對標真實的競賽環境。

表3: GPT-4o 模型在 OIBench 與其他評測集通過率對比表

強抗數據污染能力:在評測集設計中,“同源污染” 是一個重要挑戰。由於大模型的預訓練和微調數據往往會爬取大量互聯網內容,容易出現模型在訓練階段就見過類似題目的情況,從而導致評測分數虛高,無法真實反映模型實際能力。雖然 OIBench 在數據構造時極力避免使用互聯網可公開檢索的題目,但一些相近的題目仍可能在大模型的預訓練或微調階段帶來數據污染。為此,我們專門設計了實驗來驗證 OIBench 的抗污染能力:

  • 具體做法:我們從 OIBench 中抽取部分題目,模擬它們在模型訓練數據中 “泄漏” 的場景,並與常規訓練數據混合,對比模型在 OIBench 上的表現提升。
  • 實驗證明:即使模擬少量題目 “泄漏” 到模型的訓練數據中,OIBench 的得分提升也極為有限,風險分數幾乎為零,表明其對數據污染具有很強的魯棒性。

2. OIBench 評測結果與發現

參評模型與評測方式

OIBench 對 18 個主流大模型(包括 14 個指令微調模型和 4 個基礎模型)進行了 zero-shot 評測,涵蓋 C++、Python、Java、JavaScript 四種語言。

表4:  OIBench 上基座模型、指令微調模型、推理模型的表現

主榜單結果

  • 推理模型表現突出:推理類模型(如 o4-mini-high)在 OIBench 上的平均得分高達 21.4%,遠高於普通指令微調模型(約 3.6%)。這表明 OIBench 能有效區分模型的推理和鏈式思考能力,且 o4-mini-high 在所有語言和任務上表現最優。
  • 閉源模型優勢明顯:閉源模型平均得分 14.5%,顯著高於開源模型(6.3%),這主要得益於閉源模型在算力和數據質量上的優勢。
  • 基礎模型決定上限:指令微調模型在 OIBench 上的表現高度依賴其基礎模型的能力,説明基礎模型的預訓練質量是決定代碼能力的關鍵。
  • DeepSeek-V3-0324 的亮點:作為非推理模型,DeepSeek-V3-0324 表現突出,得益於其採用了 DeepSeek-R1 的鏈式推理蒸餾方案,推理能力大幅提升。
  • 語言偏好與中英文差異: 模型在 JavaScript 和 Python 上的表現平均比 C++ 和 Java 低 10% 以上,可能與訓練數據分佈有關;中英文題目表現差異極小,甚至中文略優。

偽代碼(Pseudocode)提示的積極作用

OIBench 的高難度對普通模型來説挑戰巨大。為了更細緻地分析模型的能力,我們還引入了 “偽代碼提示” 評測:將標準解答轉為偽代碼並作為提示輸入,考查模型理解和復現解題思路的能力。

結果顯示,所有模型在有偽代碼提示時表現均有明顯提升,尤其是強推理模型(如 o3-mini-high 和 o4-mini-high)提升尤為顯著。這説明偽代碼極大降低了題目的推理難度,更能考查模型的代碼理解與生成能力。同時,推理模型在理解解題思路方面依然具備優勢。進一步分析發現,指令微調模型的表現與其基礎模型高度相關,説明代碼生成能力主要取決於預訓練水平。

在提供偽代碼提示後,所有模型表現均有明顯提升,尤其是強推理模型,這説明偽代碼能有效降低推理難度,更能考查模型的代碼理解與生成能力。

推理效率:隨着 “測試時推理” 成為提升大模型能力的重要手段, OpenAI-o1、DeepSeek-R1 等模型在解題時會生成大量推理內容。我們統計了各模型推理時的 Token 消耗與通過率的關係,發現 o4-mini-high 能以更少的 Token 解出更多題目,推理效率最高;DeepSeek-V3-0324 雖然表現不俗,但推理 Token 數量也最多,體現其長鏈推理的特點。

圖 1: OIBench 模型通過率與推理消耗 Token 量關係圖

3. 模型與人類選手的對比

許多技術人員都關心:現在的大語言模型在算法編程題上的表現,和真正的競賽選手相比到底如何?OpenAI、 DeepSeek 會用線上編程平台 Codeforces 的 Elo 評分體系來做模型與人類的對比,並報告自家模型最新的 Elo 分數,但這種方式存在一些問題:比如數據時間跨度長(一般需要半年以上的參賽記錄)、在線選手水平波動大,導致對比結果不夠精確,也不容易復現。

OIBench 創新性地採用了更可控的方法:邀請了中國 985 級別高校 ACM 校隊選手參與部分題目的作答,並將其成績與大模型直接對比,提供了更精準、可復現的人機對比數據;我們用小提琴圖展示了每個模型在所有人類選手中的排名分佈,能直觀反映模型與人類在不同題目上的表現差異。

排名規則參考了信息學奧賽(IOI)的標準:先比較通過的測試用例數量,數量相同則按運行時間排序(越快越高)。

提交標準:人類選手的答案以最後一次提交為準。

人類解答開源: 分析中所涉及的人類解答記錄也將匿名化並開源,便於後續研究和復現。

圖 2: 模型與人類選手的對比關係圖

在小提琴圖中,各模型在每道題中的人類排名位置會作為一個數據點,這些數據點形成的概率密度圖就是小提琴圖中的“琴身”。“琴身”的寬度顯示模型排名分佈的密度,越寬表示模型在對應的排名區間內出現的頻率越高,從而直觀地反映出模型排名表現的集中趨勢。中央的框線代表排名數據最集中的區域,以o4-mini-high舉例,它的排名大致超過了42%的人類選手。

三種類型的模型表現

  • 低谷型: 多數題目排名靠後,只能超越不到 20% 的人類選手,多為沒有長鏈推理能力的模型。
  • 雙峯型: 在部分題目上能超越一半人類選手,但在另一些題目上表現較差,多數支持長鏈推理的模型屬於此類型,顯示其在特定題型上的優勢和短板。
  • 橄欖型: 排名分佈更均勻,表現更接近人類整體能力分佈,目前只有 o4-mini-high 具備這種全面和穩定的推理特徵。

4. OIBench總結與展望

本文深入分析了當前大模型編程能力評估中存在的認知鴻溝,揭示了 "宣傳" 與 "現實" 之間的差距。Meituan-M17團隊 通過 OIBench 這一高質量、高區分度的私有數據集,清晰揭示了頂級 LLM 在面對複雜算法挑戰時,與人類頂尖水平之間的真實差距。不僅為大語言模型的算法推理能力評測樹立了一個全新標杆,也為整個行業帶來了更多思考。

它讓我們看到:即使在模型能力突飛猛進的今天,真正高質量、高難度的算法挑戰依然能夠 "難倒" 最先進的 AI。尤為重要的是,希望 OIBench 的開源和透明能夠為社區協作和持續創新做出一些貢獻。我們期待它能成為連接學術、產業和開發者的橋樑,推動大模型在算法智能領域邁向新高度。未來,隨着模型能力和評測需求的不斷演進,OIBench 也會持續迭代,與大家共同見證 AI 推理的進化之路。

與此同時,我們也觀察到,對於大多數人類開發者來説,即使他們接受過專業的算法設計訓練,面對高難度算法和複雜系統設計,同樣需要工具和智能助手的輔助才能更上一層樓。大模型的強大推理和代碼生成能力,正好能為人類開發者提供有力支持,幫助他們提升算法設計和代碼實現的效率。OIBench 促使我們深入思考:未來的代碼開發,已超越 "人" 或 "模型" 單打獨鬥的模式,轉變為人機協同、優勢互補的新範式

CoreCodeBench篇

背景:工程級代碼評估的挑戰

研究發現,現有的代碼基準數據集在面對複雜的工程場景時普遍存在缺乏多樣性和可控性的雙重問題:

  • 工程開發環節覆蓋有限:儘管現有基準(如 FullStackBench、SWEBench)在領域和語言多樣性上取得進展,但其任務類型仍主要集中於單段落代碼生成。而真實工程實踐通常涉及跨文件、跨模塊的協同,以及代碼修復、測試驅動開發、多函數協作等複雜任務,這些都應被工程級基準全面覆蓋。
  • 數據構建方法侷限:大多數數據集採用隨機挖空或從代碼倉庫的歷史 PR 記錄中提取修改點(如 GitHub 的 Pull Request)。前者容易忽略項目的核心邏輯代碼段,後者不僅數據量稀少,還需投入大量人工進行數據清洗和標註,難以規模化構建高質量的評測題目。

總之,我們發現現有的代碼基準測試大多“偏科”了。它們要麼只關注單個函數的補全,忽略了開發者修復 Bug 、根據單元測試反向開發的真實場景;要麼採用隨機挖空的方式,難以觸及代碼的核心邏輯。這導致我們無法科學、完整、全面地測評 LLM 在真實工程場景中的代碼能力,尤其是在可靠性和適用性方面,我們亟需一個能解決此難題的方案。

為了應對上述挑戰, Meituan-M17 團隊、上海交大聯合發佈了一個全新的大模型工程級別代碼基準測試 CoreCodeBench 數據集,託管到 AGI-Eval 社區

  • CoreCodeBench榜單地址:https://agi-eval.cn/evaluation/detail?id=64
  • 微信公眾號文章:AGI-Eval模型評測
  • 論文預印版:《CoreCodeBench: A Configurable Multi-Scenario Repository-Level Benchmark》。

  • 論文地址:http://arxiv.org/abs/2507.05281
  • GitHub地址:https://github.com/AGI-Eval-Official/CoreCodeBench

它專注於評估大語言模型在真實工程項目中的綜合代碼能力,覆蓋了從代碼開發到代碼修正的多個核心階段。

圖 3: CoreCodeBench 題型展示

圖 4: CoreCodeBench 模型能力榜單

通過在 CoreCodeBench 上對當前主流大語言模型的全面評測,我們得出了以下關鍵結論:

  • 大模型編程能力迭代進步顯著,但發展不均衡:較新的模型 {如 Claude 3.7 、o4 mini(high)} 相較於前代產品表現出明顯進步。然而,受測模型在代碼修正(BugFix)任務上表現欠佳,尤其是單函數任務場景下,修正任務的成功率全部低於開發任務,這揭示了當前 LLM 在理解和修復深層邏輯錯誤方面存在的普遍短板。
  • 多函數協作是當前大模型編程場景的主要瓶頸:幾乎所有模型在處理多函數任務時的表現都顯著劣於單函數任務。這表明,當需要同時處理多個函數間的依賴關係、調用邏輯和協同實現時,當前大模型的跨函數推理和規劃能力尚顯不足。
  • 大模型編程場景普遍缺乏靈活的規劃與分層推理能力:在多函數代碼生成任務中,我們觀察到大多數模型嚴格遵循輸入提示中的函數順序生成代碼,而非像人類工程師那樣,基於功能依賴(如先實現被調用的工具函數)進行優化。這一現象反映了當前模型在面對複雜任務時,傾向於採用默認的順序策略,缺乏主動規劃的意識。

1. 基準構建方法與實驗分析

數據集構建方法:CorePipe 流程

為了構建一個既關注多樣化工程問題,又聚焦於核心代碼的基準,CoreCodeBench 中設計了從工程代碼倉庫到多種函數題型的全自動化構建流程CorePipe。

圖 5: CorePipe 自動化生產數據流程示意圖

如上圖所示,CorePipe 基於函數調用樹,系統化地生成覆蓋三大核心場景的單函數與多函數題目,確保每一道題目都直擊“要害”:

精選真實項目:我們從 PyPI 對應的 GitHub 倉庫中篩選出高活躍度、高測試覆蓋率和高技術複雜度的頂級開源項目。

定位核心代碼:通過動態和靜態追蹤代碼的執行,我們首先構建函數調用圖,再利用抽象語法樹(AST)抽取出關鍵函數中的核心代碼,精準定位項目中那些“牽一髮而動全身”的核心代碼塊。我們能精準定位項目中那些“牽一髮而動全身”的核心函數。

模擬三大真實場景

  • 直接開發(Development): 不僅僅是填空,我們利用 GPT-4o 生成高質量的函數功能描述,並由 Claude 3.5 Sonnet 進行“挑刺”和審核,確保模型是在理解真正需求的前提下進行開發。
  • 代碼修正(BugFix):告別簡單的語法錯誤,轉而使用 LLM 生成更隱蔽、更復雜的邏輯錯誤,真實模擬了開發中那些令人頭疼的 Bug 。
  • 測試驅動開發(TDD):提供完整的單元測試,要求模型根據測試用例反向開發功能代碼,考察其遵循現代開發範式的能力。

引入多函數難題

我們將上述單函數問題按照真實的函數調用關係組合起來,創造出更復雜的多函數題目,全面考驗模型在宏觀層面的代碼組織和規劃能力。

2. 實驗結果與深度分析

為確保評測的科學性,我們採用了信息增益分數(IG Score)作為核心指標,並通過 IG Filter(信息增益過濾)和專業工程師人工審核(最終合格率78.55%) 對題目質量進行充分的監測,兼具可讀性、準確性和完整性

2.1 單函數與多函數任務分析

表 5: CoreCodeBench 單函數和多函數任務榜單

如上圖可以看出,實驗結果有力地支持了我們的核心結論, Claude 3.7 在所有任務中表現突出。

但所有模型在多函數任務上的普遍表現下滑差於單模型任務,這可能是因為多函數任務需同時處理多個函數間的依賴關係、調用邏輯和協同實現,對大語言模型的跨函數推理和規劃能力要求更高,以及在 BugFix 任務上的集體短板,清晰地勾勒出當前技術的能力邊界。

2.2 模型規劃能力洞察

多函數任務的實驗分析揭示,模型缺乏對實現順序的規劃能力

大多數模型嚴格遵循輸入提示中的函數順序生成代碼。當前模型在多函數代碼生成時缺乏靈活規劃能力與分層推理能力,往往採用默認的順序輸出策略,而非基於邏輯或功能依賴進行優化。

這種“順序執行”而非“邏輯執行”的策略,是其與人類工程師在解決複雜問題思路上的一大差異。

2.3 極限挑戰

圖 6: CoreCodeBench-Difficult 數據集的模型結果

我們通過放寬多函數問題的複雜度限制,構建了 CoreCodeBench-Difficult 數據集。

在該測試中,所有模型的通過率均低於30%,這不僅印證了該基準在揭示模型侷限性方面的有效性,也為未來技術的突破提供了嚴苛的測試平台。

2.4 LLM 代碼能力全景雷達圖

圖 7: 前沿 LLM 代碼能力雷達圖

我們將模型的六個核心場景表現繪製成雷達圖,可以直觀地看到:

  • 沒有一個模型能在所有場景中獨佔鰲頭,證明了 CoreCodeBench 評估維度的全面性
  • 開發(Development)和測試驅動開發(TDD)任務中,單/多函數表現並不完全相關,説明開發多關聯函數需要額外的規劃能力
  • 代碼修正(BugFix)任務中,單/多函數表現高度相關,這説明調試更依賴於一種通用的、局部的錯誤修正技能

為進一步分析各評測維度之間的關係,我們計算了所有模型在六個維度上的皮爾遜相關係數並繪製熱力圖。

圖 8: 代碼能力項相關度分析

如上圖所示可以觀察得到,相關係數的測算結果表明,CoreCodeBench 的六個核心場景之間既存在一定的相關性,也體現出各自的差異性

  • Single-function 任務之間相關性較高,表現出單函數任務在基礎編程、理解和實現能力上的共性
  • Multi-TDD 和 Multi-Development 存在一定的相關性,這是因為 Multi-function 任務通常考察模型在更復雜場景下的綜合能力,包括多步推理、實現規劃等,與單函數任務所需的基礎能力存在明顯區別。
  • Multi-BugFix 雖然屬於多函數任務,但它和單函數任務相關性高,反而和 Multi-TDD、Multi-Development 相關性低。這是因為 Multi-BugFix 任務的本質更接近於“單點排查”,它更側重於具體細節或某一局部的能力考察,而與需要全局綜合能力的多函數任務存在差異

3. CoreCodeBench總結與展望

CoreCodeBench 的構建與應用,旨在為大語言模型的代碼能力評估提供一把更科學、更全面、更貼近真實的“工程標尺”。回顧我們的研究,我們系統性地揭示了當前頂尖 LLM 在真實工程場景中的核心短板:無論是多麼先進的模型,都在邏輯錯誤修復方面步履維艱;在面對多函數協同任務時,其跨函數推理與規劃能力都顯得捉襟見肘;並且,它們普遍缺乏人類工程師所具備的靈活規劃與分層推理能力

然而,這些被揭示的侷限性並非技術的終點,而是為下一代大語言模型的發展指明瞭清晰的優化方向。我們相信,通過在 CoreCodeBench 這類更貼近真實工程需求的基準上進行訓練和迭代,大語言模型將能更快地從一個“代碼片段生成器”,進化成一個真正具備分析、規劃和解決複雜工程問題的“虛擬軟件工程師”,從而在軟件開發領域釋放出更深遠的變革力量。

總結

通過OIBench和CoreCodeBench兩大基準的構建和評測,Meituan-M17團隊系統性地揭示了當前大語言模型在編程領域的真實能力邊界。這兩個數據集不僅填補了現有評估體系的空白,更重要的是為整個行業提供了一面"照妖鏡",讓我們能夠更清晰地看到頂尖AI模型與人類專業水平之間的真實差距。

核心發現包括

  • 即使是最強的推理模型,在複雜算法挑戰面前仍顯不足,距離真正的競賽選手水平還有很大差距;
  • 在工程級代碼任務中,模型普遍在代碼修復和多函數協作方面存在明顯短板;
  • 現有模型缺乏人類工程師所具備的靈活規劃和分層推理能力。

展望未來

這些發現並非技術發展的終點,而是為下一代大語言模型的優化指明瞭明確方向。我們相信,通過在更貼近真實需求的基準上持續訓練和迭代,AI將逐步從"代碼生成工具"進化為真正的"智能開發夥伴",與人類開發者形成優勢互補的協作關係。

Meituan-M17團隊將持續致力於高質量評估研究,推動大語言模型技術向更廣闊的未來發展。

One More Thing - 從大模型到 Code Agent 的評測範式遷移

當前大量涌現的 Code Agent 類框架與產品,使得人機協作解決更加複雜的工程問題成為可能,這預示着對 Code Agent 在實際工程場景中與人類協作能力的評估,將變得日益關鍵。然而,現有的 Code Agent 評測基準(如 SWE-bench 系列)存在一個核心問題:它們將人類開發者完全排除在評估流程之外。這種 “端到端” 的自動化評測,雖然能比較容易的量化模型在封閉任務上的表現,卻無法回答一個更關鍵的問題:在真實、開放的開發環境中,Code Agent 能否與人類高效協作?當前多數 Code Agent 框架在交互設計上對人機交互的忽視,導致其評測結果與實際應用價值之間存在明顯脱節。

結合 OIBench 引發的關於人機協同、優勢互補的思考,Meituan-M17團隊也開始關注人機協作評測這一新的評測範式在 Code Agent 場景的應用,進而彌補當前範式引起的評測結果與實際應用價值間的鴻溝。基於此,我們與 AGI-Eval 評測社區合作,設計並計劃舉辦一項創新的人機協作編程競賽。

競賽核心設計如下

  • 評測目標:競賽旨在真實模擬人類開發者與搭載不同大模型的 Code Agent 協作解決複雜工程任務的全過程。我們關注的不再僅僅是任務的最終成敗,而是整個協作流程的質量與效率
  • 關鍵指標:我們將記錄並分析一系列過程性指標,包括:模型的意圖理解準確度、需求澄清的有效性、交互輪次、決策效率以及最終任務完成的質量與速度。

評測流程如下

圖 9: Code Agent評估流程圖

價值與產出

  • 首個人機協作榜單:我們將產出首個聚焦人機協作效能的 Code Agent 性能榜單,從模型硬實力(自主解決問題的能力)與協作流暢度(與人交互的體驗)兩大維度進行評估。
  • 深度洞察與改進:這些寶貴的數據和洞察,將揭示當前 Code Agent 在真實協作場景下的優勢與短板,為打造更智能、更實用的下一代開發工具提供堅實的實證依據,真正推動人機協同編程走向成熟。

這項競賽不僅填補了現有評測體系的空白,更為探索未來人機協作的無限可能提供了寶貴的數據和實踐參考。對這項比賽感興趣的小夥伴,歡迎前往 AGI-Eval 評測社區瞭解詳情。

網頁端地址:https://agi-eval.cn/competition/activity

招聘信息

崗位名稱:【北斗計劃】基座大模型算法研究員(評測與探索)

隨着AI下半場的到來,傳統的評測範式已經無法適配持續提升的模型能力,針對 ChatBot 模型的 Arena 評測的有效性也遭到質疑,如何面向現階段以及未來的模型能力進行科學有效的評估本身也是個極具挑戰和價值的研究方向。OpenAI 研究者也表示,AI 接下來比拼的不是訓練,而是“如何定義並評估真正有用的任務”。

在這樣的背景下,美團大模型評測團隊以指引通往 AGI 的道路為目標,深耕模型評測研究,系統性的理解大模型當前能力水平及未來技術發展方向,並以此為基礎完善模型評測能力矩陣。歡迎各路英才加入,聯繫方式:liuxingyu10@meituan.com。

閲讀更多

| 關注「美團技術團隊」微信公眾號,在公眾號菜單欄對話框回覆【2024年貨】、【2023年貨】、【2022年貨】、【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞,可查看美團技術團隊歷年技術文章合集。

| 本文系美團技術團隊出品,著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容,敬請註明 "內容轉載自美團技術團隊"。本文未經許可,不得進行商業性轉載或者使用。任何商用行為,請發送郵件至 tech@meituan.com 申請授權。

user avatar yaoyaolx_wiki 頭像
1 位用戶收藏了這個故事!

發佈 評論

Some HTML is okay.