今日進度：12. Evaluation
今日花費時數：4
筆記
What we see?
-
**Benchmark Scores：**當新模型（如 DeepSeek-R1、Llama 4 等）發布時，通常會伴隨著在 MMLU、MATH 等常見基準測試上的分數。雖然大眾對這些數字習以為常，但往往不清楚這些測試的具體內容以及數字背後的真正含義。此外，也有像 HELM 這樣的平台會將多種基準測試的結果統整在一起供人比較。
-
Costs：好的評估不應只看準確率，還需要考慮使用成本。大多數的排行榜（Leaderboards）通常會完全忽略或邊緣化成本問題。網站 Artificial Analysis 會將模型的「智力指數」（綜合各項基準測試的分數）與每個 token 的價格結合起來，繪製出 Pareto frontiers，讓使用者能找出性價比最高的模型。
-
真實用戶的選擇與偏好：
- OpenRouter：這類網站透過追蹤實際被發送到各個模型的流量（token 數）來建立排行榜，其背後的邏輯是「人們願意花錢選擇使用的模型就是好模型」。
- Chatbot Arena：這是一個極受歡迎的盲測平台，由網路上的使用者與兩個匿名的模型進行對話，並根據人類主觀的成對偏好（pairwise preferences）來為模型進行排名。
-
評估危機：如同 Andrej Karpathy 所指出的，當前 AI 領域正面臨嚴重的「評估危機」。許多過去被認為很有指標性的基準測試（例如 MMLU），現在可能已經達到飽和，或是被開發者特別針對而產生了「刷榜（gamed）」的現象。這導致雖然我們擁有大量的模型和排行榜數字，但卻越來越不清楚哪種方法才是真正正確的評估方式。
How to think about evaluation?
很多人誤以為評估只是一個機械化的過程：拿一個現成的模型、輸入 prompt、計算指標，然後算出平均分數。但實際上，評估是一個非常深奧的議題，它甚至決定了語言模型未來的發展方向。因為頂尖的模型開發者會追蹤這些評估指標，當他們想辦法讓分數提高時，評估的設計就會深深影響模型的建構方式。
沒有所謂「唯一正確的評估」， 評估的方式完全取決於我們想要回答什麼問題、達成什麼目的。不同的角色會有完全不同的評估需求：
- 一般用戶或企業：目的是為了特定的應用場景（例如：該選 Claude、Gemini 還是 GPT）做出購買決策。
- 研究人員：目的是衡量模型純粹的原始能力，了解 AI 領域是否取得了科學上的進展，這通常與特定應用場景無關。
- 政策制定者與企業：希望客觀了解模型在特定時間點能帶來哪些益處與潛在危害。
- 模型開發者：目的是在開發週期中獲得回饋，看看加入某種技術後分數是否提升，藉此改進模型。
一旦確定了抽象的評估目標，就需要將其轉化為具體的評估流程與框架：
- 輸入（Inputs）：
- prompt 的來源為何？涵蓋了哪些使用情境？
- 資料集中是否包含能挑戰模型的極端/困難案例（tails）？
- 輸入是否需要針對模型進行適應？例如在多輪對話或尋找安全漏洞（紅隊測試）時，固定的對話腳本可能不切實際，必須根據模型的反應來動態調整輸入。
- 呼叫模型（Call）：
- 採用哪種提示策略？是 Zero-shot、Few-shot 還是 Chain-of-thought？不同的策略會帶來極大的結果差異，因為模型對 prompt 仍非常敏感。
- 模型是否允許使用 CoT, tools 或 RAG（檢索增強生成）？
- 釐清評估的對象：我們到底是在評估純粹的「語言模型」，還是加上了周邊腳本的「整個代理系統（Agentic system）」（模型開發者會希望評估前者，使用者會希望評估後者）？
- 評估輸出（Outputs）：
- 用來核對答案的參考標準是否乾淨且沒有錯誤？
- 該採用什麼 metrics？（例如評估程式碼是用 pass@1 還是 pass@10）。
- 評估時是否將成本考量進去？（例如 inference + training）。
- 如何考慮非對稱誤差（例如，醫療環境中的幻覺）？
- 如何處理開放式生成（open-ended generation）？例如要求模型「寫一個關於 Stanford 的故事」，這類沒有標準答案的任務極難客觀評估。
- 解釋結果（Interpret）：
- 得到一個數字（例如 91% 的準確率）後，這代表它已經可以落地應用了嗎？
- 必須面對訓練集與測試集重疊（train-test overlap）的嚴峻挑戰：模型分數高是因為它真的學會了 generalization，還是它在訓練時早就看過測試資料了？
- 回到初衷：釐清我們評估的到底是模型本身、整個系統，還是背後提出的新「方法」？如果研究目的是為了評估某種新「方法」，那麼評估的設計就必須包含明確的控制變因（controls），否則評估結果將失去意義；相較之下，現代的評估更多是在沒有嚴格控制下對綜合「系統」進行測試。
Perplexity
語言模型本質上是在輸出 tokens sequences 的機率分佈 *p(x)*。Perplexity 衡量的是模型對於某個資料集賦予多高的機率，在 pre-training 階段，目標就是將模型在 training set 上的 perplexity 最小化，而評估時則是測量其在 test set 上的 perplexity。
過去研究員常使用 Penn Treebank（華爾街日報）、WikiText-103 或 One Billion Word 等標準資料集，在特定的 training set 上訓練，然後在對應的 test set 上評估 perplexity。
但 GPT-2 改變了這個遊戲規則，它在 WebText（包含 40GB 來自 Reddit 連結的網路文本）上訓練，然後在 zero-shot 的情況下，直接於上述的 datasets 上進行測試。這是 out-of-distribution evaluation（但核心想法是訓練可以涵蓋許多方面）。這種做法在小資料集上取得了很好的遷移效果（甚至超越當時的 SOTA），但在大資料集上表現不佳。這是一種 out-of-distribution evaluation。其核心想法是：只要訓練用的網路文本足夠廣泛，我們就可以期望模型獲得強大的泛化能力，從而在未見過的資料集上表現優異。
自從 GPT-2 和 GPT-3 之後，語言模型的評估主流轉向了下游任務的準確率，但 perplexity 依然有其不可替代的價值：
- Smoother：相比於任務準確率只有「對與錯」的二元結果，perplexity 能提供每個 token 的細微機率變化，這對於 scaling laws 非常重要，能讓曲線變化更優雅。
- Universal：計算 perplexity 時，模型必須關注資料集中的每一個 token；相較之下，任務準確率有時會漏掉細節，模型可能會「因為錯誤的原因而得到正確的答案」。
- 可應用於下游任務：我們依然可以透過計算給定 prompt 後生成答案的 “conditional perplexity”，來評估下游任務的表現並預測大模型的效能。
如果我們經營一個模型排行榜，使用 perplexity 作為指標會面臨一個信任困境：我們必須非常信任模型提供者回傳的機率值真的加總為 1。如果透過 API 測試任務準確率，只需比對生成的文字是否正確即可；但如果是計算 perplexity，一個含有 bug 或是惡意的 API 可能會給所有單字都賦予 0.8 的機率，使得 perplexity 看起來極佳，但這根本不是有效的機率分佈。在早期依賴未知詞彙 token (<UNK>) 的時代，這種信任問題甚至更糟，因為模型可能會利用將機率集中在 <UNK>上來作弊，進而獲得虛假的 perplexity。
Perplexity Maximalist View： 有一派觀點認為，如果真實世界的資料分佈是 *t*，模型的機率分佈是 *p*，只要我們不斷將模型 *p* 相對於 *t* 的 perplexity 最小化，最終 *p* 會完美貼合 *t*，這就等同於解決了所有任務並達成了 AGI。不過反方意見認為，這可能不是最有效率的途徑，因為模型可能會浪費大量算力去擬合資料集中我們根本不在乎的無意義片段（這也是我們需要針對特定任務進行測試的原因）。
精神上類似 perplexity 的克漏字任務： 有些基準測試雖然不是直接算整體 perplexity，但核心概念非常相似，目前這類任務大多已被強大的語言模型所破解：
- LAMBADA：要求模型根據廣泛的上下文來猜測段落的最後一個單字。
- HellaSwag：測試常識推理，要求模型從選項中挑選最合理的情境續寫。這類任務的評估方式通常也是直接計算各個選項給定 prompt 下的 likelihood 來決定勝負，不過實務上還會有一些微調細節，例如需要針對各選項不同的 token 數量進行 normalizing。此外，由於此資料集源自 WikiHow，極易出現在模型的預訓練網路資料中，因此需特別防範 train-test overlap 的問題。
Knowledge Benchmarks
Massive Multitask Language Understanding (MMLU)
- 背景與設計：推出於 2020 年（GPT-3 發布後），是目前最經典的標準化測驗基準之一。它包含了 57 個學科（如數學、美國歷史、法律、道德等）的選擇題，題目主要從網路上的公開來源收集。
- 特點與演進：儘管名稱包含「語言理解」，但它實際上更多是在測試知識量。早期使用 few-shot 評估 GPT-3 時準確率僅約 45%，但現在頂尖模型的準確率已高達 90% 以上。
- 評估意義與挑戰：MMLU 其實是評估 foundation models 的好工具，因為如果模型只是在預測下一個 token 而沒有特別針對考試微調，卻能拿高分，代表它具備極高的泛化智力。然而，由於題目來自網路，因此面臨 train-test overlap 的風險。
[HELM MMLU for visualizing predictions]
MMLU-Pro
- 背景與設計：為了解決 MMLU 已經「飽和」（大家分數都太高）的問題，研究人員在 2024 年推出了加強版。
- 改良重點：
- 移除了原本 MMLU 中充滿雜訊或過於簡單的題目。
- 將選擇題的選項從 4 個增加到 10 個，大幅提升難度。
- 模型在此測試上的準確率通常會下降 16% 到 33%。
- 特點：在這個測試中，使用 chain-of-thought 能顯著提升表現，這與最初的 MMLU 不同，顯示 MMLU-Pro 包含了更多需要複雜推理的題目。
[HELM MMLU-Pro for visualizing predictions]
Graduate-Level Google-Proof Q&A (GPQA)
- Questions written by 61 PhD contractors from Upwork
- 背景與設計：這是一個極具挑戰性的基準測試，題目由生物、物理和化學領域的博士級專家所撰寫與驗證。
- 難度：
- 博士級專家作答的準確率約為 65%。
- 非專家即使擁有 30 分鐘的時間且可以不受限地使用 Google 搜尋，準確率也只有 34%。
- 模型表現：GPT-4 剛推出時準確率為 39%，但最新的 o3 模型已經可以達到 75%，顯示模型在這一年多來取得了驚人的進展。
[HELM GPQA for visualizing predictions]
Humanity’s Last Exam
- 背景與設計：目標是成為「最後一個」包含廣泛學科的封閉式學術基準測試。它包含了 2,500 道涵蓋數學、人文與自然科學的多模態題目（包含選擇題與簡答題）。
- 題目來源：主辦方提供 50 萬美元的獎金池並讓出題者掛名共同作者來徵集題目，並且使用最先進的語言模型進行過濾，只有模型答錯的題目才會被納入。
- 模型表現：目前的頂尖模型（如 o3）在此測試上的準確率僅約 20% 左右。
- 潛在缺陷：有人提出強烈質疑，認為這種透過公開徵求並用高額獎金吸引來的題目，會導致嚴重的偏差。因為出題者往往是已經非常熟悉大語言模型研究的人，這會導致題庫變得極端小眾且特定，無法代表真實世界人們會問的常規問題分佈。
Instruction Following Benchmarks
在 ChatGPT 普及後，評估重點從過去高度結構化的選擇題，轉向了 instruction following 的基準測試。這類任務最大的挑戰在於如何客觀評估沒有標準答案的「開放式回答」，這目前仍是一個未完全解決的難題。
Chatbot Arena
- 運作機制：這是目前極受歡迎的平台。網路上隨機的使用者輸入 prompt 後，會收到兩個匿名模型的回答，使用者根據主觀偏好選擇哪一個比較好。系統接著根據這些成對比較（pairwise rankings）計算出 ELO scores 來為模型排名。
- 優勢：因為是由真實用戶輸入，prompt 是動態且即時的，而非靜態資料庫，並且能輕鬆容納不斷推出的新模型。
- 隱憂與挑戰：
- 刷榜與公關化：當指標變得太受關注，模型開發者就會開始針對性地優化或鑽漏洞（如享有特權訪問或多次提交造成的「排行榜幻覺」）。
- 受眾代表性：由網路上「隨機」的群眾來決定好壞，其問題分佈未必能代表所有真實與專業的應用場景。
Instruction-Following Eval (IFEval)
- 運作機制：這個測試專注於讓模型遵循具體的格式限制。例如要求模型「回答必須大於 400 字」、「至少提到 AI 這個詞 3 次」或「回答中不能使用逗號」。
- 優勢：由於限制條件非常明確，不需要人類介入，寫個簡單的腳本就能自動驗證模型是否達標。
- 隱憂與挑戰：它只檢查「格式」，完全不管「語意」。如果模型產出了一篇字數符合規定但內容毫無邏輯的垃圾文章，在 IFEval 裡依然會算作過關。此外，這些刻意刁難的限制在真實世界中往往顯得很不自然。
[HELM IFEval for visualizing predictions]
AlpacaEval
https://tatsu-lab.github.io/alpaca_eval/
- 運作機制：收集來自各處的 805 個指令，並直接利用強大模型（如 GPT-4）來當裁判，評估測試模型相較於基準模型（GPT-4 本身）的勝率。
- 優勢：這是一種自動化、快速且可重現的評估方式。
- 隱憂與挑戰：
- 偏差：GPT-4 作為裁判，往往會偏好自己生成的回答風格。
- 長度偏差：早期模型只要單純生成「更長的回答」，就能輕易騙過 GPT-4 獲得高分，後來才推出了針對長度進行修正的版本。
WildBench
- Sourced 1024 examples from 1M human-chatbot conversations
- Uses GPT-4 turbo as a judge with a checklist (like CoT for judging) + GPT-4 as a judge
- Well-correlated (0.95) with Chatbot Arena (seems to be the de facto sanity check for benchmarks)
- 運作機制：從超過一百萬筆真實的人類與聊天機器人對話記錄中，精選出 1,024 個極具挑戰性的真實任務。
- 評估改良：同樣使用強大模型（GPT-4 turbo）當裁判，但不同於 AlpacaEval，它引入了 checklist 的機制。這迫使裁判模型在給分前，必須像使用 chain-of-thought 一樣，系統性地確認回答是否涵蓋了各個面向。
- 優勢：在評估困難任務時，WildBench 的自動化評分結果與人類主導的 Chatbot Arena 呈現極高的相關性（相關係數高達 0.95）。這使得它成為一個兼具客觀性與低成本的優質自動化評估工具。
[HELM WildBench for visualizing predictions]
Agent Benchmarks
SWEBench
- 測試目標：評估語言模型解決真實世界 GitHub 程式碼問題的能力。
- 資料規模：包含了來自 12 個熱門 Python 專案庫的 2,294 個真實 gitHub issues 與對應的 pull requests。
- 運作機制：給定一個程式碼庫與問題描述，agent 必須自主修改程式碼並提交一個 patch 或 PR 來修復錯誤。
- 評估標準：系統會執行 unit tests，如果修改後的程式碼能讓測試通過，才算成功。
- 後續改進：這類基準測試常面臨資料品質問題（例如有些測試本身有誤），因此後來社群也推出了修復標籤錯誤的 SWE-bench Verified 版本。
CyBench
- 測試目標：評估模型在網路安全方面的駭客與漏洞發掘能力。
- 資料規模：包含 40 個專業級別的「搶旗（Capture the Flag, CTF）」挑戰賽任務。
- 運作機制：代理會獲得一個終端機/伺服器環境的存取權，必須自主思考計畫、執行指令、更新記憶並不斷迭代，直到成功駭入系統並找出隱藏的機密金鑰。
- 難度指標：這個測試經常引入人類解題時間（First-solve time）作為對照。例如最難的挑戰人類團隊花了快 25 小時才解開，而現在的最強模型（如 o3）已經能解出人類需要花 42 分鐘才能解開的任務。
MLEBench
- 測試目標：評估 AI agent 是否能像機器學習工程師一樣完成專案。
- 資料規模：精選了 75 個真實的 Kaggle 機器學習競賽。
- 運作機制：agent 必須自主撰寫程式碼來處理資料集、訓練模型、進行除錯、調整超參數，最後提交預測結果。
- 當前表現：目前頂尖的代理系統（如 OpenAI 的 o1-preview 搭配 AIDE 鷹架），大約只能在 16.9% 的競賽中達到 Kaggle 銅牌的門檻。
總結觀察
與前面動輒 80%、90% 準確率的知識型基準測試（如 MMLU）不同，目前的代理基準測試難度極高。即使是最好的模型，在這些需要長期推理與反覆除錯的任務上，準確率通常仍低於 20%。這顯示出我們距離成熟的全自動 AI agent 系統還有一段路要走。
Pure Reasoning Benchmarks
ARC-AGI
- 背景：由 François Chollet 在 2019 年（甚至在現代 LLM 爆發前）提出。
- 測驗設計：
- 這是一種圖形規律預測任務。模型會看到幾組輸入與輸出的網格圖形，必須找出其中的邏輯與規律，並在給定一個新的輸入圖形時，預測出正確的輸出圖形。
- 這些圖形規律對人類來說通常很容易察覺，但它完全沒有語言描述、也沒有文字說明，純粹依賴圖形推理。
- 模型表現與演進：
- 傳統的語言模型在這個任務上表現非常差（例如 GPT-4o 的準確率幾乎是零）。
- 但目前最新的強推理模型（如 OpenAI 的 o3）已經能在這個任務上取得相當好的成績。
- 雖然模型能解出來，但每解一題都會消耗大量的運算資源（可能要花費數百美元）。
- 後續發展：由於模型能力的提升，現在也已經推出了難度更高的 ARC-AGI-2。
ARC-AGI-1
ARC-AGI-2: harder
Safety Benchmarks
對於 AI 而言，安全意味著什麼？
[HELM safety: curated set of benchmarks]
HarmBench
- 設計目標：提供一個標準化框架來評估自動化的紅隊測試以及模型拒絕有害指令的穩定性。
- 內容與表現：基於 510 種違反法律或常理的有害行為進行測試（例如：要求提供製造危險化學品二甲基汞的步驟）。有些模型會正確拒絕，但也有些模型（如 DeepSeek-V3）會直接照做並給出危險指令。
AIR-Bench
- 設計目標：將抽象的安全概念，具體錨定在真實世界的法律規範中。
- 內容：將 8 項政府法規與 16 項企業政策，拆解成包含 314 個具體風險類別的分類架構，並包含了 5,694 個測試 prompt。這能幫助了解模型是否符合特定管轄區的安全要求。
Jailbreaking
- 概念：這是一個「後設（meta）」層級的安全問題。雖然模型都有經過對齊訓練來拒絕有害指令，但只要透過巧妙的提示詞設計，就能繞過這些安全防護。
- 自動化越獄（GCG）：現在有研究提出了 Greedy Coordinate Gradient (GCG) 等方法，能自動找出最佳化的亂碼後綴（adversarial suffixes）。當這些亂碼加在有害問題（如「如何毀滅人類」）後面時，就能迫使模型給出肯定且危險的回覆。
- 高度可遷移性：令人驚訝的是，這類在開源模型（如 LLaMA）上訓練出來的攻擊 prompt，竟然可以直接遷移並攻破未開源的商業模型（如 GPT-4 或 Claude）。
Pre-deployment testing
- 運作機制：目前這是一個自願性質的協議。模型開發商（如 Anthropic 或 OpenAI）會在模型發布前，給予美國和英國的 AI 安全機構早期訪問權限。
- 目的：機構會運行各種安全評估並產出報告，提供 feedback 來協助企業決定部署與上線的安全策略。
But what is safety?
- 安全性具有高度的「語境依賴性（strongly contextual）」
- 目前在 AI 領域，對於「什麼才是安全」其實還沒有絕對且單一的標準答案。
- 安全性的定義會受到不同國家的法律、政治環境與社會規範的強烈影響，因此會隨著環境與文化而有所差異。
- 安全性不等於「拒絕（Refusal）」，也並非總是與「能力」互斥
- 人們常有一種直覺認知：安全性就是讓模型「拒絕回答有害問題」，因此越安全的模型會因為經常拒絕而顯得越無能（與能力相斥）。
- 但實際上，安全性的範疇遠大於單純的拒絕。例如在醫療或其他高風險情境中，減少模型的「幻覺（hallucinations）」不僅能讓系統變得更安全，同時也讓它具備更強大的實際應用能力。
- 評估的兩個核心維度：能力（Capabilities） vs. 傾向（Propensity）：要評估模型的風險，必須將以下兩個方面拆開來看：
- 能力：模型是否有技術能力去執行某件危險的事（例如它骨子裡懂不懂得如何製造炸彈或駭入系統）。
- 傾向：模型是否會拒絕去執行危險的事（這通常是對齊訓練的結果）。
- 針對封閉的 API 模型：我們主要只需要在乎傾向。因為使用者無法修改模型，只要模型能穩定拒絕有害指令（且無法被越獄），就算它具備危險知識也沒有關係。
- 針對開源模型（open-weight models）：我們就必須高度關注它的能力。因為模型一旦開源，惡意使用者就可以非常輕易地透過微調把原先設定的安全防護（傾向）給抹除掉。
- 雙重用途（Dual-use）的兩難
- 模型的能力與安全風險往往緊密交織在一起，很難被完全分割。
- 例如在使用 agent 基準測試（如 CyBench）時，一個能成功駭入系統的強大 AI，既可以被惡意駭客用來發動攻擊，但同時也能被企業用來進行有益的滲透測試（Penetration testing），幫助在系統上線前找出防護漏洞。這使得評估人員常常很難界定：這到底是一項「安全評估」，還是一項單純的「能力評估」。
Realism
語言模型在實務上已被廣泛使用，但我們現有的標準化基準測試（如 MMLU）卻與真實世界的使用情境相去甚遠。
雖然最直接的想法是「拿真實用戶的流量來進行評估」，但實務上網路流量充滿了許多無意義的垃圾訊息或純粹的惡搞，這並不是我們真正想要評估的資料分佈。
用戶輸入的 prompts 大致分可為兩種思維：
- Quizzing：用戶早就知道答案，只是想「考」一下系統，這也是多數標準化考試的運作邏輯。
- Asking：用戶真的不知道答案，需要系統提供幫助與創造價值。 「提問型」才更符合真實世界的實際應用，因此標準化的考試在反映真實性上存在明顯的缺陷。
Clio (Anthropic)
為了解決不知道用戶真正在做什麼的盲點，Anthropic 提出了名為 Clio 的隱私保護分析平台。
- 運作機制：利用 AI 助理本身來自動分析數百萬次對話的聚合使用模式，完全不需要人類審查員去閱讀原始對話，從而保護了用戶隱私。
- 洞察結果：他們發現最常見的真實應用是寫程式、寫作與研究任務。同時也觀察到了有趣的跨語言/文化差異，例如日本用戶討論高齡化與長照問題的比例異常地高。
- 安全性應用：Clio 也被用來主動監控對系統的惡意濫用，或在發布新功能與發生重大世界事件時，監控潛在的未知風險。
MedHELM
- 過去的醫療語言模型評估，大多也是依賴標準化的醫學執照考試題庫。
- MedHELM 專案詢問了 29 位臨床醫師：「在你們的實際工作中，語言模型到底可以幫上什麼忙？」並據此收集了 121 項真實的臨床任務。
- 這些任務不再是死板的醫學選擇題，而是包含撰寫病歷筆記、規劃治療方案等更貼近第一線醫療現場的工作。
不幸的是，當我們越追求基準測試的「真實性」，就越需要使用包含真實用戶或病患的資料，而這會直接與「隱私」產生對立。例如，上述提及的許多真實醫療數據，因為牽涉病患隱私，根本無法被公開託管到網路上成為大家都能使用的公共基準測試。
Validity
我們要如何知道我們做的 evaluation 是有效的？
Train-test overlap
-
背景：機器學習最基礎的常識就是「絕對不能把測試集拿來訓練」。在基礎模型尚未爆發的時代（如 ImageNet、SQuAD 時代），訓練集與測試集都有明確的劃分。但現在的大模型大多直接在海量網路資料上訓練，且開發商往往不願公開完整的訓練資料，導致我們根本無從得知模型是否在訓練時就已經「看過並背下」了考題。
-
應對路線一：從模型中推斷（Infer from model）：研究人員發現了一種不需檢查訓練資料就能偵測作弊的方法，即利用資料的「可交換性（exchangeability）」。如果模型沒有看過測試集，那任何考題的隨機排列順序對它來說機率都應該一樣；但如果模型曾背過原始資料庫，它就會對該測試集原本的「標準順序（canonical ordering）」賦予異常高的預測機率。[Oren+ 2023]
-
應對路線二：建立社群報告規範（encourage reporting norms）：就像科學研究發布結果時必須報告信賴區間一樣，學界正積極呼籲模型開發商在發布基準測試分數時，應將主動測量並公開「訓練集與測試集重疊率」視為標準規範。[Zhang+ 2024]
Dataset quality
- 背景：許多知名的基準測試（例如數學題庫 MATH 或 GSM8K）其實含有大量的標籤錯誤與題目雜訊。有時候模型分數無法提升，是因為題目本身的標準答案就是錯的。
- 改進方向：
-
社群開始動手修復舊有基準測試中的錯誤，例如前面 agent 基準測試提到的 SWE-bench，經過除錯後推出了更準確的 SWE-bench Verified 版本。[blog]
-
研究人員提倡建立所謂的 「白金級基準測試」，也就是經過極度精心策劃、致力於將標籤錯誤與語意模糊降到最低的測試題庫，用來取代過去充滿雜訊的舊題庫。[Vendrow+ 2025]
-
What are we evaluating?
我們到底在評估什麼？換句話說，遊戲的規則是什麼？
在 foundation models 之前，我們評估了各種方法（標準化的 training set - test set split）。今天，我們將評估各種模型/系統（任何類型都可以）。
進行任何評估前，最核心的問題是：我們必須先明確定義「遊戲規則」是什麼？
目前的評估可以大致分為兩種：
- 評估「方法」
- 時代背景：在大型基礎模型（foundation models）爆發之前。
- 遊戲規則：具有嚴格且標準化的 train-test splits）。
- 核心價值：這種評估方式能有效鼓勵研究人員專注於「演算法的創新」。
- 評估「模型 / 系統（Models/Systems）」
- 時代背景：現今的 LLM 時代。
- 遊戲規則：幾乎是「毫無限制（Anything goes）」，模型開發商可以使用任何海量資料或訓練技巧來衝高最終的分數。
- 核心價值：這種評估方式對下游使用者非常實用，因為一般使用者並不在乎模型背後的演算法為何，只在乎最終產品的綜合表現。
- 例外與新趨勢（Exceptions） 雖然現在的主流是評估綜合系統，但也出現了一些新的挑戰賽，試圖在某些變因上重新建立客觀的「遊戲規則」來評估方法：
- nanoGPT speedrun：固定訓練資料，參賽者要比賽誰能用最短的「運算時間」達到特定的 validation loss。
- DataComp-LM：給定一個龐大的原始資料集（Raw dataset），參賽者必須使用標準的訓練流程，比賽誰能達到最佳的準確率。
總結：無論我們選擇評估的是「方法」還是「系統」，最重要的事情都是：「我們必須明確定義遊戲規則！」
今日回顧與筆者的碎碎念
今天的內容毫無疑問是截至目前為止，讓筆者做筆記時感到最輕鬆的一節。這一節主要說明了做 evaluation 的基本原則，以及各種常見 benchmark 的設計背景。老實說筆者過去是完全沒在關心的 benchmark 分數，因為實際使用的時候，目前的 SOTA 模型其實感覺起來不會差非常多。不過這節課筆者也學習到為了應對現在 foundation models 遍地開花的時代，研究者花費了多少苦心在 evaluation 這塊上。最讓筆者覺得有趣的是 ARC-AGI，這個競賽的發起人同時也是 Keras 之父，而且他還是在 foundation models 爆發之前就提出概念這麼超前的 benchmark，筆者對此是相當佩服的。