# 如何閱讀 AI 程式設計基準測試，避免選出論文中的冠軍 > HumanEval 和 SWE-bench 衡量的內容，以及閱讀 AI 程式設計排名時，如何考量代理程式包裝層、測試條件、任務新舊、結果變異和成本。 Source: https://ailoot.ai/blog/zh-hant-tw/read-ai-coding-benchmarks/ Canonical: https://ailoot.ai/blog/zh-hant-tw/read-ai-coding-benchmarks/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-125 Revision: sha256-0984f80ec42257f5c6940240a4a05a1e45d8deb005133cf904794f20aeb7f076 簡單來說，「解決了 76% 的任務」這個數字本身幾乎說明不了任何事情。重要的是產生這個數字的任務集、一起計算的模型與代理程式包裝層、任務是新是舊，以及花了多少錢。沒有這些條件，這個百分比適合放在廣告橫幅上，卻不適合用來選工具。 接下來，我會用淺白的方式說明兩個主要程式設計基準測試衡量什麼、表格裡藏著哪些陷阱，以及如何在依據任何排名採取行動前，用一分鐘檢查它。下文討論歷史基準定義，未重現即時配對排行榜快照；目前分數或成本比較，需要自己的連結表格、日期與設定。 閱讀更多模型使用相關內容，請參閱 [Ailoot 文件](https://ailoot.ai/docs/)。 ## 基準測試的百分比實際代表什麼？
重點摘要 基準測試的百分比，是工具在特定條件下，從特定任務集中完成並產生可用結果的任務比例。任務會透過自動化測試檢查：程式碼要嘛通過測試，要嘛不通過；評估結果很明確，沒有「差不多」這回事。不過，任務集的範圍一定有限，而且事先已經公開；每項測量的條件也因工具而異。因此，這個數字回答的是：「這個工具用這種方式解決了這些任務中的幾個？」它回答不了：「它能處理我的工作嗎？」
基準測試的運作方式很簡單。先準備好一份程式設計任務清單，把每個任務交給工具，工具回傳程式碼後，系統便執行自動化測試，確認解決方案是否可行。通過測試的任務比例，就是表格中顯示的百分比。 這種做法的優點是評估客觀。測試不是通過就是不通過，沒有人會用「看起來還行」來打分。就這一點而言，基準測試比任何評論或使用心得都更坦率。 缺點也正是同一回事。任務集有限，而且所有人都事先知道，包括訓練模型的人。每次測量的條件也不盡相同。再者，任務集中的任務幾乎肯定和你的工作不同。這就造成了下文會談到的各種陷阱。這個百分比描述的是工具在別人所選定的封閉任務清單上的表現，不能直接套用到你的專案上。 ## HumanEval 衡量什麼？為什麼現在不能再用它來選工具？
重點摘要 HumanEval 是一組過時的測試集，包含 164 個小型 Python 任務：模型會收到函式說明、撰寫程式碼，再由自動化測試檢查任務。它在 2021 年發布時，第一代 Codex 一次嘗試就解決了 28.8% 的任務。如今，強大的模型幾乎都能完成其中所有任務，因此它已無法區分這些模型。此外，這些任務只是玩具問題：根據說明撰寫單一函式，和在大型、正在運作的專案中工作相去甚遠。2026 年的 HumanEval 高分幾乎毫無意義。
HumanEval 由 OpenAI 建立，並於 2021 年隨 Codex 模型一同發布。它包含 164 個小型 Python 任務：模型會收到以文字描述的函式需求，撰寫函式本體，再由一組自動化測試檢查函式是否正確運作。 當時，它確實能區分模型。作者在論文中列出這項數據：第一代 Codex 一次嘗試就解決了 28.8% 的任務，而一般的 GPT-3 一題也沒解決。

在 HumanEval 上，我們的模型解決了 28.8% 的問題，而 GPT-3 解決了 0%，GPT-J 則解決了 11.4%。

— OpenAI，文章〈Evaluating Large Language Models Trained on Code〉，
此後模型持續進步，如今強大的模型幾乎都能完成 HumanEval 中的所有任務。當大家的分數都接近 100% 時，表格便無法區分任何東西，工具之間的差異也消失了。這種情況稱為基準測試飽和，HumanEval 長期以來都處於這個狀態。 第二個缺點更嚴重。這些任務非常簡單：根據說明撰寫一個函式。你的實際工作則不同——你得處理有歷史脈絡的大型專案、理解別人寫的程式碼、找出缺陷，還要避免破壞相鄰程式碼。「從頭撰寫一個函式」與「修復運作中專案的錯誤」之間有一道鴻溝。因此，如今 HumanEval 的高分已不再是選擇工具的理由；它頂多表示「基本能力已經具備」。 ## SWE-bench 衡量什麼？它如何更貼近實際工作？
重點摘要 SWE-bench 取材自熱門 GitHub 專案中的真實缺陷：涵蓋 12 個 Python 儲存庫的 2,294 個任務。工具會收到問題說明並修改程式碼，接著由系統執行修正前會失敗、修正後應能通過的測試。這比 HumanEval 更貼近實際工作，因此常用來比較成熟的工具。它的難度從歷史紀錄中可見一斑：最初的簡單基準方法解決的任務不到 2%。
SWE-bench 完全不同，因此也更值得關注。它取材自熱門 GitHub 專案中的真實問題和合併請求。根據作者的說法，它包含來自 12 個大型 Python 儲存庫的 2,294 個任務，並於 2023 年 10 月發布。 評估方式很直接。他們選取專案中曾經出現真實缺陷的版本，以及當時會失敗的一組測試。工具收到問題說明後修改程式碼。接著執行同一組測試：如果測試轉為通過，任務才算真正解決；這裡沒有人會相信口頭承諾。

我們透過檢視 12 個熱門 Python 儲存庫中的合併請求與問題，收集了 2,294 個任務。每個任務都以一個合併請求為基礎；該合併請求與某個問題相關，且至少變更一個測試相關檔案。

— SWE-bench，官方基準測試網站，
最初的數據顯示，這比玩具型任務難得多。第一種基準方法在 SWE-bench 上的分數只有 1.96%，而第一個代理程式的分數是 12.47%。換句話說，即使只是接近真實的程式設計工作都不容易；後來百分比雖然提高了，但起點接近零。 因此，如今在 AI 程式設計代理程式排名中看到的高分，通常來自 SWE-bench，或其經人工驗證、包含 500 個任務的子集 SWE-bench Verified。這是合理的基準測試，但它也有一些條件；若不看這些條件，百分比就會誤導人，接下來我會說明。 表格裡最誠實的基準測試，也不代表工具已在你的專案上取得成果。結果取決於你如何使用工具，而排名最上方的數字說明不了多少。若要可靠地完成工作，重要的是 AI 分身、Second Brain 和脈絡工程三者的組合。乾淨的脈絡比從表格中選模型，更能明顯提高個人的成功率。 ## 為什麼同一個模型會顯示不同的百分比？
重點摘要 因為結果不只取決於模型。每次測量至少涉及三個要素：模型本身、包在模型外的代理程式包裝層，以及啟用的推理層級。變更推理設定可能讓同模型與包裝層產生不同資料列；沒有測試工具名稱、修訂、設定及附日期來源，就不能作數值比較。因此，你需要比較完整的組合；光看模型品牌並不能決定太多。
最常見的基準測試解讀錯誤，就藏在這裡。人們把表格當作模型排名來看，認為這個模型比那個模型聰明 2%。但有三個因素會影響百分比，而模型只是其中之一。 第一是模型本身。第二是包在模型外的代理程式包裝層：這是一種程式，讓模型能瀏覽檔案、執行命令、讀取錯誤並重寫程式碼。同一個模型搭配聰明或簡單的包裝層，結果會不同，因為包裝層決定了模型如何與專案互動。第三是推理層級，也就是模型會把每個步驟想得多深入。思考時間越長，百分比通常越高，成本也越高。 可重現比較應保留完整設定。以下是報告範本，並非實測排行榜： | 欄位 | 執行 A | 執行 B | |----|----|----| | 模型與確切版本 | 記錄測試版本 | 控制比較用相同版本 | | 代理測試工具與修訂 | 記錄儲存庫及提交 | 相同工具與提交 | | 任務集與計分 | 記錄子集與評估修訂 | 相同任務與計分 | | 推理設定 | 記錄設定 A | 記錄設定 B | | 結果與證據 | 解決數、分母、日誌與日期 | 解決數、分母、日誌與日期 | 這能看出哪些因素改變，是否真正隔離了推理設定。先前沒有連結的數字，不當成實測結果。 規則很簡單：好的排名一定會標明使用的模型、包裝層和推理層級。如果表格只列出模型名稱和百分比，卻沒有標明包裝層，就很難相信這份排名，因為你不知道實際測量的是什麼。關於「模型加包裝層」組合的構成，請參閱[AI 程式設計代理程式排名](https://ailoot.ai/blog/zh-hant-tw/ai-coding-agent-rankings/)一文。 這也解釋了為什麼排名第一的工具有時在你手上表現不佳。基準測試衡量的是模型在別人精心調整的包裝層中，處理別人選定的任務。你的包裝層、專案，以及提供給模型的脈絡都不同。在你的專案中，結果取決於脈絡；表格中的排名是次要因素。 ## 為什麼任務會「過期」？訓練資料外洩是什麼？
重點摘要 模型使用網路上的大量文字和程式碼進行訓練，而熱門基準測試都已公開。如果任務及解答進入了訓練資料，模型就可能記住它們，並在評估時直接重現記憶內容，而不是解決問題。這稱為任務洩漏到訓練資料中。測試集越舊、知名度越高，風險就越大：舊基準測試更可能反映模型的記憶，而非推理能力。與舊且公開的任務集相比，新且封閉的任務集更可靠。
有個陷阱無法從數字本身看出，卻比其他任何因素都更能削弱數字的可信度。模型使用從網路蒐集的大量文字和程式碼進行訓練。而幾乎所有程式設計基準測試都是公開的：包括任務、測試和參考解答。 運作原理很簡單。如果任務和正確解答進入了訓練資料，模型就可能記住它們。評估時，模型做的與其說是在解題，不如說是從記憶中取出熟悉的答案。看起來像是解決了問題，其實只是憑記憶作答。這稱為訓練資料洩漏或資料污染。 任務集越舊、越熱門，風險就越高。HumanEval 自 2021 年起便已上網公開；它被重寫、分析，並多次納入無數資料集。期待現代模型從未「看過它」，並不合理。因此，任務新舊是基準測試的一項獨立品質指標。好的任務集會定期更新，或將部分任務保密，避免模型事先學到。 閱讀排名時該怎麼做？檢查任務日期，以及任務集是否更新。如果基準測試取材自近幾個月才出現的新缺陷，就更值得信賴。如果任務集已有五年歷史，那麼高分更能說明模型記憶力好，而非它有能力解決你的新任務。[全新 FrontierCode 基準測試](https://ailoot.ai/blog/zh-hant-tw/frontiercode-benchmark-mergeable-ai-code/)一文以具體範例展示了這種效果，其中的任務刻意採用新題目。 ## 為什麼幾個百分點的差距往往毫無意義？
重點摘要 基準測試存在變異：同一個工具在相同任務上的不同執行結果會略有差異，因為模型不會每次都做出相同回應。因此，排名相鄰兩列相差 1 或 2 個百分點，往往會被雜訊掩蓋，不能代表真正的優勢。也要另外檢查價格：相近的百分比可能相差好幾倍的成本。只有完整設定、成功率、計費假設與成本分母都明確時，才比較成本。
表格頂端的名次會誤導人的另一個原因是，模型不會每次都給出相同的回應。面對同一個提示詞，它可能採取略有不同的推理路徑。因此，如果你用同一組任務多次執行某個工具，百分比會因每次執行而略有浮動，這種浮動稱為變異。 實際結論很簡單。排名中兩列只差 1 或 2 個百分點時，差距很可能只是雜訊。追逐「高 2%」的工具並不明智：下次執行時，它們的名次很容易互換。只有在大量任務中，差距明顯且持續存在時，才值得視為顯著差異；幾個百分點達不到這個標準。 最後還有一點，而且幾乎總是比百分比本身更重要：價格。相近的結果可能需要截然不同的費用。成本比較需要兩組模型與測試工具設定，以及評估任務集的全部支出，包含失敗嘗試。除以嘗試數得到每次嘗試成本，除以解決數則是每項完成成本，請標明使用哪種。本文未提供有來源的配對成本測量。因此，閱讀排名時務必同時看價格，因為單獨看百分比幾乎沒有意義。[解決一個任務的成本](https://ailoot.ai/blog/zh-hant-tw/ai-agent-cost-per-solved-task/)一文說明了如何公平比較工具的成本。 ## 如何在一分鐘內讀懂任何基準測試表格？
重點摘要 依據排名採取行動前，先問它七個問題：使用的是哪個任務集？任務是新是舊？使用的是哪個模型？哪個代理程式包裝層？哪個推理層級？每個任務的成本是多少？結果變異有多大？如果表格連一半的問題都答不上來，就不值得信賴：它很可能只是廣告。此外，還要另外確認任務集是否與你的實際工作相似，因為即使是別人任務上的誠實百分比，也不能直接套用到你的專案。
讓我把所有內容濃縮成一份簡短清單。打開任何排名表格，依序檢查以下七點。 1. **使用哪個任務集？** HumanEval 現在的參考價值不高；SWE-bench 更貼近實際工作。如果完全沒寫任務集名稱，就不必繼續看。 2. **任務是新是舊？** 新的或部分封閉的任務集，比模型可能已經學過的舊公開任務集更可靠。 3. **測試的是哪個模型？** 確認精確名稱和版本，不要只看含糊的「AI」或模型家族名稱。 4. **使用哪個代理程式包裝層？** 這個百分比屬於「模型加包裝層」的組合。如果沒有標明包裝層，你就不知道測量的是什麼。 5. **使用哪個推理層級？** 同一個模型在不同層級下會得到不同百分比，成本也不同。 6. **每個任務的成本是多少？** 相近的結果可能有數倍的價格差異。閱讀百分比時也要看成本。 7. **結果變異有多大？** 不同列相差 1 或 2 個百分點，往往只是雜訊。 第八個問題與你有關：**任務集中的任務和你的工作相似嗎？** 由 Python 任務組成的基準測試，對於使用不同工具製作網站或機器人的人幫助有限。即使是在別人的任務上取得誠實的數字，也不能保證你的專案會有相同成果。唯一可靠的檢查方法，是讓工具處理幾個你常做的任務，再親自查看結果。[如何檢查 AI 生成的程式碼](https://ailoot.ai/blog/zh-hant-tw/check-ai-generated-code/)一文說明了即使你不會寫程式，也能如何判斷程式碼是否可用。 ## 最後應該看什麼？
重點摘要 看排名首位背後的條件，而不只是首位本身：任務集及其新舊、「模型加包裝層」的組合、推理層級、每個任務的成本，以及結果變異的程度。缺少這些條件的單一數字無法證明任何事。也要記得，即使是在別人任務上取得誠實的百分比，也不能直接套用到你的專案。最終仍要用自己的真實任務來測試；而測試結果更取決於你如何使用工具，而不是工具在排名中的位置。
整篇文章的重點可以簡短概括：排名的位置是進一步了解工具的理由，但接下來還得由你自己深入查證。高分只表示工具在特定條件下，妥善完成了一份特定的封閉任務清單。百分比無法說明這些條件是否符合你的情況。 因此，要看排名那一列背後的資訊：使用了哪些任務、任務有多新、採用哪種模型與包裝層組合、推理層級為何、費用多少，以及差距是否只是雜訊。無法回答這些問題的表格，適合放在廣告橫幅上。[2026 年該用哪個工具寫程式](https://ailoot.ai/blog/zh-hant-tw/ai-coding-tools/)一文會說明該如何為自己的任務挑選工具。 還有一點比任何基準測試都重要。即使是排名最高的工具，面對混亂的脈絡也會難以發揮；脈絡整理乾淨時則能運作良好。個人的成功率取決於你提供給模型的內容，以及你如何描述任務；表格上的排名只是次要因素。排名有助於排除明顯較弱的選項，但成果要靠你自己打造。
### 來源 - [HumanEval - dataset openai/openai_humaneval (huggingface.co)](https://huggingface.co/datasets/openai/openai_humaneval) - 包含 164 個 Python 任務的測試集，使用自動化測試檢查
排名可以排除弱的選項，但在你的專案中能取得什麼成果，取決於方法：AI 分身加上 Second Brain，再加上脈絡工程。 進一步使用 [Ailoot](https://ailoot.ai/)。 ## 常見問題：如何閱讀 AI 程式設計基準測試，避免選出論文中的冠軍 ### 比較兩筆基準結果前，必須記錄什麼？ 記錄確切模型、代理測試工具與修訂、推理設定、任務子集、計分方式、日期及直接結果來源。缺少這些資料，就不能把分數差距歸因於某一設定改變。 ### 每次嘗試成本等於每項解決任務成本嗎？ 不同。前者把全部評估支出除以嘗試任務數，後者除以成功解決任務數。兩者都應包含失敗嘗試支出，且比較前標清楚分母。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。