LLM 基準別對職能，不再看單一分數

這篇把 2026 年常見 LLM benchmark 翻成工作適配度，最後附一份可直接複製的自訂評測模板。

我用 benchmark 分數挑模型有一陣子了，但老實說，這套路常常很雷。簡報上丟一個漂亮數字，大家點頭，彷彿模型只要贏了 2 分，就能同時會研究、會寫 code、會守格式、會跑客服流程。沒有這種事。我看過團隊因為公共榜單小贏就選了模型，結果一上線，prompt 變髒、context 變長、輸出要對 schema，整個就散掉。這不是模型壞掉，這是我們拿錯尺在量。

我這次被點醒，是讀到 Datavlab 這篇 LLM Benchmarks 2026: Which Model for Which Job。它不是在跟你報成績單，而是在拆解 MMLU、GPQA、SWE-Bench、Arena Elo 到底各自回答什麼問題，還有為什麼它們都不能當成萬用結論。這篇也很老實，直接講 saturation、contamination、scaffold 依賴，以及為什麼自訂評測還是最重要。

別把一個分數當成錄取通知

“A cholesterol test does not predict blood pressure. An ECG does not measure lung function. Each test answers a specific question. LLM benchmarks follow the same logic.”

翻譯一下就是：benchmark 是診斷工具，不是終局答案。我一直看到有人把 MMLU 或 Arena Elo 拿來當模型績效考核，這很偷懶，而且通常最後都要多花錢補洞。模型可以很會聊天、很會講幹話，也可以在公開榜單上很漂亮，但如果你的工作要的是精準格式、長上下文推理、工具呼叫，那它一樣可能翻車。

Datavlab 這篇講得對：benchmark 不是沒用，而是每個 benchmark 只測一小塊能力。MMLU 看廣泛知識，GPQA 看困難推理，SWE-Bench 看真實軟體工程，Arena Elo 看人類偏好。沒有一個可以單獨代表 production 行為。這點我自己踩過雷。

我之前幫一個客服助理做模型選型，A 模型在對話流暢度上比較討喜，B 模型沒那麼會演，但它比較會照格式輸出 JSON。Demo 時 A 贏，進 production 後是 B 贏。這種落差，就是單一 benchmark 會害人的地方。

實操寫法很簡單：有人丟你一個分數時，先問一句很煩但很必要的話，「這個 benchmark 到底在模擬什麼工作？」如果答案很空，先當雜訊。只有答案夠具體，才拿來跟你的實際工作比。

MMLU 只能當底線，不是王冠

“By 2026, MMLU has saturated for frontier models... Top performers cluster above 90%, making the benchmark ineffective for differentiating between current frontier models.”

MMLU 以前很有用，因為它是大家都能拿來講的通用知識測試。現在這個時代差不多過了。Datavlab 很直接：前沿模型已經擠在 90% 以上，分數差個 1、2 分，通常不再有決策價值。你如果還拿它當主選型依據，基本上是在拿一個已經鈍掉的尺量東西。

也就是說，MMLU 還有工作，但不是大家以為的那個工作。它可以幫你抓出明顯知識缺口；如果一個模型還卡在 80% 以下，我會開始皺眉。但如果兩個前沿模型都在低 90%，我不會假裝那個差距很重要。那時候比的多半是噪音、格式細節，或訓練差異的邊角料。

Datavlab 也提到 MMLU-Pro，比原版更難，但也在往飽和走。換句話說，如果你 2026 年還把 MMLU 當主要門檻，你大概是在用一個已經不太會分人的考卷做選才。

我看過採購流程很愛 MMLU，因為它看起來客觀、好放表格、好交差。但表格漂亮，不代表模型真的適合你的內部文件、領域語言、輸出限制。真正該做的是把這個分數當底線，不是終點。

實操寫法：MMLU 只拿來做粗略 sanity check。夠不夠格先看它有沒有明顯知識洞；一旦你在比較前沿模型，就別再為了 1-2 分糾結，直接進 task-specific evaluation。

• MMLU 適合做廣泛知識的底線檢查。
• 不要拿 MMLU 決定前沿模型的最終勝負。
• 如果你的領域知識很重要，自己補一組 domain set。

GPQA 和 HLE 才像真的在考推理

“GPQA Diamond tests expert-level reasoning on PhD-level science questions... HLE (Humanity's Last Exam) is a newer benchmark designed to remain non-saturated longer.”

GPQA 是少數我還會認真看的公開 benchmark 之一，因為它真的比較像在測推理，不是測背誦。Datavlab 提到它用的是 PhD 等級的科學題，而且非專家 PhD 的分數大概在 34% 左右，這代表它還保有足夠難度。這很重要，因為你要的是一個還能把模型分開的測試，而不是大家都考差不多的安慰獎。

翻譯一下就是：GPQA 比較像推理壓力測試，不是一般知識小考。如果你的產品是研究助理、科學分析工具，或任何需要模型把多層證據串起來的場景，GPQA 比 MMLU 更像一個像樣的訊號。它不保證 production 會贏，但至少沒那麼容易被唬住。

Datavlab 也提到 HLE，也就是 Humanity's Last Exam，目的是讓 benchmark 不要太快被前沿模型打爆。這件事很實際，因為當一個 benchmark 太容易時，它就不再能分出真正有差距的模型。HLE 就是在試著往前補這個洞。

我自己很有感。很多模型在廣泛 benchmark 上看起來差不多，但一碰到多步推理、沒有捷徑的任務，就開始分裂。有的模型能把思路維持住，有的模型前面講得很像一回事，後面直接往懸崖走。如果你的工作包含 synthesis、科學 triage、內部分析，這種差異比榜單名次重要太多。

實操寫法：只要你的 use case 是推理導向，就先測 GPQA 類型的題，再做一組貼近你工作內容的內部題庫。如果你真的是在挑前沿模型，HLE 類型的任務也要補進來，避免只對舊題型過擬合。

• GPQA 適合看深度推理，不適合拿來看泛知識。
• HLE 適合當更難、較不飽和的訊號。
• 數學產品別只看 GSM8K，至少把 MATH 一起放進來。

HumanEval 過時了，SWE-Bench 才像真實寫 code

“HumanEval is no longer differentiating... SWE-Bench Verified replaces HumanEval as the meaningful coding benchmark in 2026.”

這段我點頭點得最用力。HumanEval 以前有它的價值，因為我們需要一個乾淨的 coding benchmark，而且生態還很早期。但 Datavlab 說得很對：它現在飽和了，而且 contamination 不是小事。當前沿模型都跑到 90% 以上時，這個 benchmark 對 production 選型的資訊量其實很有限。

也就是說，寫函式跟做軟體工程不是同一件事。HumanEval 問的是模型能不能寫一個通過 unit test 的函式；SWE-Bench 問的是模型能不能在真實 GitHub issue、真實 codebase 裡把事情做完。這兩個工作差很多，真的差很多。

Datavlab 還提醒一個很要命的點：SWE-Bench 分數會因為 scaffolding 不同差到 25 個百分點。這不是小誤差，這是警報燈。意思是 benchmark 不只在測模型，也在測你旁邊那套 harness、工具串接、評測設定。如果你的 stack 很髒，你的分數也會很髒。

我自己做 agentic coding 的時候就常看到這種事。Notebook demo 看起來很神，一進 repo，要找檔案、抓 context、做最小 patch，不要大改亂炸，模型就開始不穩。函式題根本抓不到這種差異，真實 issue 題才抓得到。

實操寫法：coding 模型選型時，HumanEval 只當 sanity check。要看真實工程能力，就用 SWE-Bench Verified。若你怕 contamination，就加 LiveCodeBench。若你的產品比較像 LeetCode 而不是 GitHub issue，MBPP 還能看，但別把它跟 production coding 混為一談。相關資源可以看 SWE-Bench Verified 與 LiveCodeBench。

指令遵從才是你 pipeline 會不會炸的地方

“IFEval measures how reliably a model follows complex, multi-part instructions in prompts.”

這類 benchmark 很多人會跳過，然後很快就發現自己的 app 不聽話。IFEval 不性感，但它很實用。只要你的模型要聽 system prompt、守 schema、照格式輸出、同時滿足多個限制，instruction following 其實比漂亮的 chat score 更重要。

翻譯一下就是：模型可以很聰明，還是很煩。它可能有回答到問題，但沒照你要的格式；可能遵守第一條指令，忽略第三條；可能解釋得很漂亮，最後 JSON 爆掉。這不是小 bug，這是產品本體。

Datavlab 也提到 MT-Bench，這個比較像多輪對話的測試。如果你的產品重視來回互動，它有參考價值；但如果你的痛點是 prompt 遵從，IFEval 更尖銳。對 RAG、structured output、multi-agent orchestration 這類系統，IFEval 常常比一般 chat 分數更能預測你會不會半夜接到告警。

我修過不少系統，最後都不是因為模型不夠強，而是因為它不夠乖。修法也不是「讓它更聰明」，而是「換一個比較會照指令做事的模型」。這聽起來很無聊，但比你花一週追 schema failure 實際多了。

實操寫法：只要你的產品依賴嚴格格式或多層指令，就早點測 IFEval 類案例。加上 adversarial prompt、巢狀限制、schema 驗證。某些模型在一般 benchmark 輸一點，但在 instruction following 贏很多，那種反而更適合上線。

Arena Elo 很有用，但它只告訴你一半

“Arena Elo captures human preference but cannot tell you whether a model will pass your specific evaluation.”

Chatbot Arena 很有價值，因為它抓的是人類直接比較輸出時的偏好。Datavlab 把它當成一般使用者滿意度訊號，我覺得很合理。如果你在做 consumer chatbot、客服助理、或任何對話本身就是產品的東西，Arena Elo 值得看。

但也要講白一點：偏好不等於正確。人類常常會喜歡更自信、更順、更像樣的回答，可是那不代表它對法律工作、醫療分流、研究助理就是對的。在專業場景裡，最受歡迎的模型不一定最適合任務。

Datavlab 這裡講得很克制，我反而更信。它說 Arena 排名在專業領域可能會誤導，因為它反映的是平均使用者偏好，不是 domain-specific accuracy。這個差別很大，但很多人故意裝作沒看見。

我通常把 Arena 當成 tie-breaker。當兩個模型在真正重要的 benchmark 上差不多時，我才會在意哪個比較討喜。但如果你的工作有硬正確性要求，我絕不會讓 Arena 一票定生死。

實操寫法：如果你做的是面向一般大眾的聊天、語氣敏感的 UX、或一般助理體驗，就把 Arena 類偏好資料納進來。若是技術、法律、醫療、研究產品，就別讓它蓋過任務導向評測。

自己做 100 到 200 筆 eval，不然你永遠在猜

這段最像真的 operator advice。Datavlab 的核心意思是：公共 benchmark 必要，但不夠；你還需要 100-200 筆自訂評測，最好能預測 production performance。這才是正解。不是因為自訂 eval 很潮，而是因為它真的只是在告訴你，你的模型能不能做你的工作。

翻譯一下就是：你需要一個小、乾淨、代表性夠高的測試集，從你自己的工作裡長出來。不是學術大全集，也不是 Slack 裡隨手撈的一坨 prompt。要的是能反映你產品每天會遇到的輸入、失敗模式、邊界案例和輸出限制。

我自己做過幾輪之後，模式都差不多。第一版一定比你想像中樸素，然後它會很誠實地戳破一堆團隊原本默默假設的事。這很好，真的很好。評測不是拿來證明你最愛的模型很神，是拿來在使用者罵你之前先知道它會壞在哪。

Datavlab 也把這件事跟 routing architecture 連起來，說有機會把成本砍 50-80%。這個數字不是拿來喊爽的，是提醒你：有了真 eval，你才能把簡單任務丟給便宜模型，把難題留給強模型。沒有 eval，routing 就只是帶著帳單的猜拳。

實操寫法：從真實 tickets、真實 docs、真實 code issues、真實 research prompts 抽 100-200 筆。每筆都標註你在意的 failure mode，然後用同一套標準比模型。最後再拿這些資料做難度分流，而不是全部都丟最貴的模型。

• 例子要貼近 production，不要太乾淨。
• 評分別只看 pass/fail，要記失敗模式。
• prompt、工具、模型版本變了就重跑。

可抄的模板

# LLM evaluation template for 2026 model selection

## 1) Define the job
- User type:
- Primary task:
- Secondary task:
- Output format:
- Hard constraints:
- Failure modes that matter:

## 2) Map the job to public benchmarks
- Knowledge-heavy: MMLU / MMLU-Pro
- Reasoning-heavy: GPQA Diamond / HLE / MATH
- Coding: SWE-Bench Verified / LiveCodeBench / HumanEval only as a sanity check
- Instruction following: IFEval / MT-Bench
- General chat preference: Chatbot Arena Elo
- Multimodal: MMMU
- Computer use: OSWorld

## 3) Build the custom eval set
Create 100-200 examples from real work.
For each example, store:
- Input
- Expected behavior
- Required format
- Known edge case
- Pass/fail rule
- Severity if it fails

## 4) Score model outputs
Use a 0-2 scale:
- 0 = fails the task or breaks constraints
- 1 = partially works but needs human cleanup
- 2 = passes with acceptable quality

Track separately:
- Accuracy
- Format compliance
- Tool use correctness
- Hallucination rate
- Latency
- Cost per successful task

## 5) Compare models
For each candidate model, record:
- Public benchmark signal
- Custom eval score
- Worst failure mode
- Best use case
- Cost tier

## 6) Route by difficulty
- Easy tasks -> cheaper model
- Medium tasks -> mid-tier model
- Hard tasks -> strongest model

## 7) Review cadence
Re-evaluate when:
- Prompt changes
- Tooling changes
- New model release lands
- User complaints rise
- Cost profile shifts

## 8) Procurement note
If you need documentation for internal review or EU AI Act work, keep:
- Model name and version
- Eval date
- Benchmarks reviewed
- Custom eval results
- Known limitations
- Decision rationale

## 9) Decision rule
Pick the model that wins on your custom eval for the job,
not the model that wins one public benchmark by a tiny margin.

原始來源是 Datavlab 的 LLM Benchmarks 2026: Which Model for Which Job。我前面拆的是它的觀點和框架，這份可抄模板是我把它改成能直接拿去做選型的版本。

我另外參考了 Chatbot Arena、SWE-Bench Verified 和 LiveCodeBench。原文是來源，我這篇是把它變成台灣開發者比較好直接上手的工作版。