排行榜上的第一名，不一定適合你的 workflow
前陣子為一個內部項目挑選語言模型，我打開幾個 LLM Leaderboard，看到排名頂端的模型，直覺以為「選第一名就對了」。結果落地測試才發現，它在處理我手頭的長文件與結構化輸出時，表現遠沒有分數那麼漂亮。那種落差，就像看到一雙鞋在評測裡拿滿分，穿在自己腳上卻完全不合腳。
這篇文章想分享的，是我後來整理出的一套實際做法：如何看待網上那些 AI 排名與 benchmark 分數，以及更重要的——如何為自己的真實用例建立測試，選出真正適合的模型。
為什麼排行榜只能信一半
我並非全盤否定 leaderboard。它們在「特定條件下的相對比較」仍有參考價值，但對於「哪個模型最好」這種絕對宣稱，則往往過度簡化。
排名網站通常混合了以下數據來源：學術 benchmark（MMLU、GSM8K、HumanEval 等）、匿名投票式對決（Arena）、自動化評分（另一個 LLM 當評委）、廠商自行公布的數字、以及私有測試集。每一種都測量了某些真實的東西，但也都有明顯的天花板。
分數背後的陷阱
數據污染（Contamination）是最常見的問題。許多熱門 benchmark 是公開的，模型在訓練時可能已經「看過」考題。高分可能反映的是記憶力，而非推理能力。就像學生拿到已經在網上流傳的標準答案後去考試，成績會失真。
考試技巧不等於實用能力。一個模型在選擇題 benchmark 上拿高分，不代表它能處理雜亂的真實指令、維持長對話的一致性、或生成符合你內部格式的報告。真實用戶很少會用乾淨的 benchmark 句式來提問。
提示與設定會大幅改變結果。同一個模型，換一個 system prompt、加幾個 few-shot 例子、調高 temperature，分數可以完全不同。所以 leaderboard 上的數字，測的不只是模型本身，而是「模型 + prompt + 參數 + 評分方式」的整組合。
人類偏好排名反映的是「討喜」，而非「正確」。Chatbot Arena 的機制是用戶盲選較喜歡的回答。這固然有價值，但用戶偏好可能獎勵有禮貌、語氣自信、格式漂亮的答案，而不是法律或醫療上準確的答案。一個模型可以「感覺比較好」，同時卻比較容易出錯。
Benchmark 到底在代表什麼？
與其把 benchmark 看成「智商排名」，不如理解它是一個「採樣代理」——測的是某種能力在特定條件下的表現，而非那項能力在真實世界中的全部樣貌。
| Benchmark 類型 | 它大致代表什麼 | 它不代表什麼 |
|---|---|---|
| MMLU 類學術測驗 | 廣泛的學科知識與應試能力 | 真實世界推理、領域工作流、知識更新速度 |
| GSM8K / 數學 | 小學程度數學文字題 | 高等數學、證明能力、符號運算的穩定性 |
| HumanEval | 短篇 Python 函式編寫 | 大型軟體工程、架構設計、除錯體驗 |
| SWE-bench | 在真實程式碼庫中修 bug | 完整開發者生產力、上下游協作 |
| Chatbot Arena | 人類對話偏好的盲測結果 | 客觀正確性、企業級專業表現 |
| 長文本測試 | 長文件中的資訊檢索 | 對雜亂長文獻的深度綜合分析 |
| 安全性測試 | 對已知風險提示的反應 | 真實世界對抗式部署中的完全安全 |
簡單來說，一個漂亮的數字只說明了：「這個模型在這份考卷、這種評分方法、這組設定下，表現不錯。」至於這件事跟你的需求有沒有關聯，需要你自己判斷。
我的實戰做法：自建「用例測試集」
與其花時間爭論哪個公開排名最權威，我傾向把精力投入建立一套屬於自己的輕量評估流程。做法不複雜，重點是貼近真實工作。
第一步：先定義「好」的標準
不要先問「哪個模型最聰明」，而是先問「我們需要它完成什麼任務，以及什麼算失敗」。我會先列出實際應用場景，例如：整理文件、抽取欄位生成 JSON、起草回覆、分類工單、或輔助寫 code。針對每個場景，定義輸入是什麼、輸出應該長什麼樣子、哪些錯誤絕對不能發生（例如幻覺公司政策、洩漏敏感資料、格式錯誤導致下游系統當機）。
第二步：從真實工作提取測試案例
我會從過去一、兩週的真實紀錄中，挑出 20 到 50 個代表性例子。這些案例要分開幾類：
- 正常案例：最常見的日常問題。
- 邊界案例：資訊不完整、語意模糊、或指令有矛盾的輸入。
- 對抗案例：試圖讓模型出錯的輸入，例如「Ignore previous instructions」或文件內藏有惡意提示。
- 高價值案例：一旦出錯後果嚴重的情境，這類應該在評分時佔更高權重。
第三步：固定條件，公平對比
要比較不同模型，必須控制變因。我會固定以下所有條件：同一份 system prompt、同一份 user prompt、同樣的上下文、相同的 temperature（通常用 0 或 0.2）、相同的 max tokens、同樣的工具權限。這樣才能確保差異來自模型本身，而不是某個模型拿到更好的「考試攻略」。
第四步：設計評分維度與權重
不要只做一個總分。我會按任務類別分開評分，例如「文件摘要」、「欄位抽取」、「程式碼生成」各自計算。每個類別再設計幾個維度，例如正確性、完整性、是否基於提供的上下文、語氣、格式合規、安全性。然後按業務重要性給予不同權重——對客服場景，「政策正確性」可能佔 40%；對法律文件抽取，「欄位準確度」佔 50%。
評分方式可以根據任務性質選擇：
- 精確匹配：適合分類、路由、選擇題。
- 格式驗證：適合 JSON、schema 輸出，檢查是否 valid、欄位是否正確。
- 人類評分：適合寫作品質、語氣、推理過程，用 1 到 5 分或 Pass / Partial / Fail 制。
- LLM 評委：可作為初步篩選，但重要決策仍需人工抽樣覆核。
第五步：加入負面測試，並多次運行
LLM 是機率性的，即使 temperature 設為零，輸出仍可能波動。我會對重要案例跑 3 到 5 次，觀察平均表現與最壞情況。有時候，一個模型平均分略低，但極少出現災難性錯誤；另一個模型平均高，卻偶爾產生完全無法使用的輸出。在生產環境中，穩定性往往比天花板更重要。
此外，我必定加入負面測試（negative tests）：給予上下文不包含答案的問題，看模型會老實承認不知道，還是硬掰一個答案；或是測試它在收到 prompt injection 時，是否仍遵守 system instruction。這些往往是公開 benchmark 不會揭露的差異。
一個輕量起步版本
如果你沒時間建立完整流程，這是最小可行做法：
- 收集 5 到 10 個你最近真實處理過的問題或任務。
- 為每個案例寫下你期望的輸出，以及「絕對不能出現」的錯誤。
- 選 2 到 3 個候選模型，用同一組 prompt、同樣的 temperature 設定。
- 用一張試算表記錄每個輸出，從 1 到 5 分評估：正確性、聽懂指示、格式合規、安全性、實用度。
- 如果找人幫忙評分，記得隱藏模型名稱（用 Answer 1、Answer 2 代替），並隨機調換順序，避免品牌偏見。
- 記錄延遲與估算成本，綜合評分後選出最適合的。
這樣的做法看似土法煉鋼，但它直接對應你的真實 workflow，不需要依賴任何外部排名的解釋權。
把選擇權拿回自己手中
公開的 benchmark 和 leaderboard 並非全無意義，它們可以幫你快速收窄候選範圍。但最終，沒有任何第三方測試能完全替代「你的資料、你的用戶、你的成功標準」。模型版本更新頻繁，廠商也可能悄悄調整行為，所以自建測試不該是一次性工作，而應該在每次更換 prompt、升級模型、或引入新工具時重新跑一次。
如果你這星期就想動手，我的建議是：打開你過去一週的訊息紀錄或文件，找出五個你真正需要 AI 幫忙處理的真實問題。用同一組 prompt、同樣的 temperature，把它們分別餵給兩個你正在考慮的模型。不需要寫程式，一張試算表就夠了——給每個輸出在「正確性」、「聽懂指示」、「格式穩定度」上打個分數。這五個來自你真實工作的例子，比任何公開排行榜都更能告訴你該選誰。