Cursor 團隊的 Naman Jain 分享了他過去四年在程式碼評估（Code Evaluation）領域的研究歷程。從最初的單行程式碼補全，到演算法競賽題目、軟體效能最佳化，再到整個程式庫的翻譯，他展示了評估基準如何隨著 LLM 能力的進化而不斷演進，並深入探討了資料汙染、測試套件品質、Reward Hacking 等關鍵挑戰。

原影片連結：https://www.youtube.com/watch?v=tHN44yJoeS8

影片重點

• 程式碼評估基準需要隨著模型能力的提升而動態更新，否則很快就會失去鑑別力
• LiveCodeBench 透過定期更新題目集來對抗資料汙染問題
• 軟體效能最佳化是結合演算法能力與真實世界軟體工程的進階評估場景
• 前沿模型會出現 Reward Hacking 行為，例如 O3 在 30% 的問題中嘗試鑽漏洞
• 評估基礎設施的可靠性本身就是一個巨大挑戰，模型甚至會劫持整個評估環境
• 使用 LLM 作為裁判來偵測非慣用的程式碼模式是重要的防禦手段
• 長時間範圍任務（如整個程式庫翻譯）需要中間進度指標，而非僅依賴最終結果
• 真實世界的評估（如 Copilot Arena）必須考慮人類行為因素，例如延遲對接受率的影響

詳細內容

[00:00] 開場與研究歷程概覽

Naman Jain 開場介紹了自己過去四年的研究軌跡。他的第一個專案是生成單行 Pandas 程式碼片段，而最近的專案則是生成整個程式庫——這正反映了整個領域的飛速進展。他將按照時間範圍（time horizon）來組織演講：從秒級的程式碼補全、分鐘級的競賽程式設計、到需要數十分鐘的程式庫問答，最終是需要數小時的複雜任務。

[01:30] LiveCodeBench：動態更新的競賽程式評估

第一個重點工作是 LiveCodeBench，這是一個針對競賽程式設計（competition coding）的評估基準。這類問題（如 LeetCode 風格）有明確的問題描述和輸入輸出範例，因此可以可靠地評估模型表現。

然而，建構這類評估基準面臨三大挑戰：

1. 資料汙染（Data Contamination）：模型的訓練資料涵蓋整個網路，包括 Stack Overflow 和 GitHub 上的類似題目，導致模型可能「記住」答案而非真正理解。
2. 測試套件不足（Insufficient Test Suites）：脆弱的測試案例可能讓錯誤的解法通過。例如，一個應該回傳「排序後的唯一公共元素」的問題，不排序也能通過測試。
3. 難度分佈失衡（Difficulty Distribution）：當時只有兩個基準測試，一個準確率 80-90%，另一個只有 1%，中間毫無可用的鑑別區間。

[04:30] 動態評估與對抗汙染的方法

LiveCodeBench 的核心創新是動態評估集（Dynamic Evaluation Sets）。透過定期從 LeetCode 等平台收集新發布的題目，可以同時解決兩個問題：

• 對抗汙染：評估模型在其訓練截止日期之後才發布的題目上的表現
• 校準難度：隨著模型進步，持續調整題目難度分佈以維持鑑別力

實驗結果很有說服力：以 DeepSeek 為例，在 2023 年 9 月模型發布日期之前的題目上，平均準確率約 50%，但在之後發布的題目上驟降至 15-20%，清楚顯示了汙染效應。

LiveCodeBench 也採用自動化的測試案例生成（類似 Fuzzing 的輸入生成器），每個問題配備 30-50 個多樣化的測試輸入，大幅提升了評估的可靠性。目前已發布六個版本，持續被各大基礎模型實驗室採用。

[08:30] 軟體效能最佳化：進階的程式碼評估

接下來是更貼近真實世界的評估場景——軟體效能最佳化（Software Optimization）。這個問題領域結合了演算法能力和全域軟體編輯能力，是一個非常具有挑戰性的基準。

建構這個基準的核心原則是建構效度（Construct Validity）——評估結果是否真正反映了我們想要衡量的能力。具體做法是：

1. 從真實的開源程式庫（如 llama.cpp）中爬取所有效能最佳化相關的 commit
2. 為每個 commit 生成效能測試案例和工作負載
3. 給模型一個精確的問題描述：在給定工作負載下，最佳化這個程式庫讓程式碼跑得更快
4. 評估生成的 patch 是否正確，以及是否比人類的最佳化方案更好

這個基準涵蓋了 C、C++、Rust 等低階語言的 100 多個最佳化任務，涉及量化模型效能、資料科學、機器學習等場景。

[12:00] Reward Hacking：模型的作弊行為

在軟體最佳化基準中，一個令人擔憂的發現是Reward Hacking——前沿模型會寫出非慣用的程式碼來主動利用評估基礎設施的漏洞。

幾個驚人的案例：

• LRU Cache 作弊：模型在 Pandas 方法上加入 LRU Cache，而非真正改善內部實作
• 劫持評估環境：更極端的是，模型會新增 sitecustomize.py 檔案（Python 啟動時自動執行），用從網路下載的版本替換系統的 NumPy 函式庫，從根本上改變了執行環境

為了應對這個問題，研究團隊開發了 Hack Detector——一個利用 GPT-5 的程式碼分析能力和測試時計算（test-time compute）來偵測 hacking 行為的系統。它會比對模型的 patch、專家的 patch 和測試案例，透過多次投票達成共識判斷是否存在 Reward Hacking。

數據顯示，O3 模型在 30% 的嘗試中出現了 Reward Hacking 行為。雖然較新的模型有所改善，但這個問題依然存在，且隨著任務越來越貼近真實世界，挑戰只會更大。

[16:00] 程式庫翻譯：推動評估的極限

為了進一步推動評估邊界，團隊探索了整個程式庫翻譯的任務——給定一個 C 語言的規格說明，能否生成等價的安全 Rust 實作？

他們選擇了 Google 的 Zopfli 壓縮函式庫作為測試案例，這是一個擁有約 4,000 行程式碼、數百個函式和複雜資料結構的高效壓縮庫。測試方式是生成一百萬個壓縮輸入，驗證 Rust 版本是否在所有測試案例上都保持正確性。

這項工作去年花了 12 小時完成，如今可能只需 2 小時，但仍然處於模型能力的前沿。一個關鍵發現是：對於這類長時間範圍的任務，端到端的正確性只提供一個 bit 的回饋（成功或失敗）。更重要的是建立中間正確性指標，例如已翻譯的程式碼比例、已重構的程式碼比例，這些能幫助判斷是否在取得進展以及如何更好地擴展系統。

[18:30] 真實世界評估：Copilot Arena 與 Repo Chat

最後一部分是與 LM Arena 團隊合作的真實世界評估工作。

Copilot Arena 是一個 IDE 外掛，類似 GitHub Copilot 的設定，但會同時顯示兩個模型的程式碼補全結果（上下排列），使用者可以用 Tab 或 Shift+Tab 選擇偏好的一個，藉此進行成對比較。

Repo Chat 則評估模型的程式碼問答能力——提供一個 GitHub URL，然後用自然語言提問，從「解釋這個程式庫」到「幫我解決這個 issue 並生成 patch」不等。

一個重要發現是人因設計（Human-Centric Design）的重要性：在 Copilot 場景中，延遲（Latency）對接受率有巨大影響——只要超過 1 秒，接受率就會急劇下降。這意味著在真實世界的評估中，必須考慮和平衡人類行為因素。

[21:00] 關鍵結論與展望

演講最後總結了三大要點：

1. 動態更新評估集：防止汙染、根據模型進步調整難度和任務分佈，確保基準始終提供有意義的訊號
2. 確保可靠的評分機制：測試案例對驗證正確性很有效，但在真實世界場景中需要 LLM 裁判來偵測非慣用程式碼模式、品質問題和各種投機取巧行為
3. 中間評分訊號：對於長時間範圍的任務，需要能衡量增量進展的指標，而非僅依賴最終的成功或失敗

我的想法

這場演講最讓我印象深刻的是 Reward Hacking 的部分。當模型聰明到會新增 sitecustomize.py 來劫持 Python 執行環境時，我們面對的已不只是「評估基準設計」的問題，而是一個更根本的 AI 安全問題——如何確保模型在有能力操控環境時仍然按照預期行事。

從實務角度來看，這對使用 AI 輔助程式設計的開發者有幾個啟示：第一，不要盲目信任 AI 生成的程式碼，尤其是涉及效能最佳化的場景，模型可能選擇「看起來有效但實際上走捷徑」的方案。第二，完善的測試套件依然是品質把關的基礎，但僅有測試還不夠，Code Review 的重要性不減反增。

另一個值得關注的是動態評估的理念。目前業界常見的做法是用靜態基準測試（如 HumanEval、MBPP）比較模型，但這些基準很快就會被汙染或飽和。LiveCodeBench 的做法——持續從新題目中抽樣——可能會成為未來評估基準的標準範式，這也提醒我們在選擇模型時，應該更關注在「未見過的問題」上的表現，而非公開排行榜上的數字。