BigCodeBench：複雜 Python 程式碼生成的新基準

Hugging Face 推出 BigCodeBench，這是一個新基準，旨在透過聚焦於複雜、真實世界的任務，評估大型語言模型（LLM）的實務程式設計能力。與以往如 HumanEval 等基準常依賴簡單的演算法片段不同，BigCodeBench 要求模型在 139 個不同的函式庫中組合多個函式呼叫，以解決以使用者為導向的問題。

解決現有基準的限制

BigCodeBench 的開發旨在解決現有程式碼評估框架中發現的三大主要問題：

任務簡單性：HumanEval 任務往往過於簡單，無法代表真實世界的軟體開發，後者通常需要整合多樣的函式庫。
污染與過擬合：越來越多人擔憂 LLM 已在 HumanEval 資料上進行訓練，使其成為衡量泛化能力的不可靠指標。
缺乏通用工具：現有的替代方案往往過於領域特定、決定性，或僅聚焦於代理（例如 DS-1000 或 SWE-bench），因此缺少易於使用且涵蓋廣泛程式設計的基準。

技術設計與任務結構

BigCodeBench 包含 1,140 個函式層級任務。為確保嚴謹的評估，每個任務平均包含 5.6 個測試案例，且平均分支覆蓋率達 99%。

任務變體

基準提供兩個版本，以測試模型的不同能力：

BigCodeBench-Complete：一種程式碼補全情境，LLM 需根據 docstring 中的詳細說明完成函式。
BigCodeBench-Instruct：較具挑戰性的變體，需求以對話式、較簡潔的方式呈現，以評估指令微調的 LLM。

任務創建流程

任務透過「Human-LLM 協作流程」產生：

Seeding：流程始於 ODEX 資料集（Stack Overflow Python 單行程式碼）。
Expansion：GPT-4 將這些單行程式碼擴展為完整的函式層級任務。
Refinement：20 位具備超過 5 年 Python 經驗的人類專家在沙盒中指導 GPT-4，精練任務並加入測試案例。
Verification：另外 7 位人類專家進行品質交叉檢查。人類專家在抽樣任務上達到平均 97% 的表現。

LLM 效能與評估指標

評估使用 Pass@1 with greedy decoding 進行，測量首次嘗試即正確解決任務的比例。為了對抗「模型懶惰」——指令微調模型在長提示中省略必要的 import 語句——研究人員採用 calibrated Pass@1，在評估時加入缺失的設定（import 與全域常數）。

主要發現

效能差距：LLM 的表現遠低於人類。目前表現最佳的模型為 GPT-4o，在 BigCodeBench-Complete 上取得 61.1% 的校準 Pass@1，在 BigCodeBench-Instruct 上取得 51.1%。
封閉與開源模型：封閉源碼與開源 LLM 之間存在顯著的效能差距。
難度：此基準相當具挑戰性；在 BigCodeBench-Complete 中，有 149 個任務未被任何測試模型解決，僅有 6 個任務被所有模型解決。

透過 Elo 評分的排名

為了提供比 Pass@1 更細緻的比較，團隊改編了 Elo 評分系統（常用於棋類）。在此系統中，每個任務視為一場比賽，每個模型視為一名玩家。GPT-4o 以大幅領先的優勢居首，第二梯次則是 DeepSeekCoder-V2。

評估框架與實作

BigCodeBench 提供一個使用者友善的評估框架，可透過 PyPI 取得（pip install bigcodebench）。此框架基於 EvalPlus，並針對 unittest 以及 BigCodeBench 多樣的函式庫相依性進行了調整。

工作流程

Generation：使用 bigcodebench.generate 產生程式碼樣本。
Sanitization：使用 bigcodebench.sanitize 移除自然語言，確保程式碼可編譯。
Evaluation：在 Docker 沙盒中使用 bigcodebench.evaluate 執行程式碼以對抗測試案例。

未來路線圖

BigCode 計畫旨在於以下幾個關鍵領域持續演進此基準：

多語言化：從 Python 擴展至其他程式語言。
嚴謹性：提升測試案例的增強，以確保所有 LLM 產生的解答皆能正確評估。
泛化能力：在新興函式庫（如 transformers、langchain）上測試模型。
演進：定期更新基準，以因應函式庫版本的棄用與訓練資料的演變。
互動性：朝「LLM 作為代理」的方向前進，允許模型與瀏覽器與終端互動，以自行除錯與反思。