昨天談 RAG,結尾那句鐵律是「答案品質的上限由檢索品質決定」,而且評估要從第一天就做。但那句話其實藏了一個更根本的問題:你憑什麼說一套系統「好」或「不好」?你怎麼「知道」換了嵌入模型、加了重排之後,系統真的變強了,而不是你的錯覺?答案就是今天的主角——評估(Evaluation,業界簡稱 evals)。沒有評估,你手上那套 RAG、那個 agent、那顆微調過的模型,全都是薛丁格的貓:在你量測之前,它既好也不好。
📖 學
為什麼評估是整個 AI 工程的地基
傳統軟體有明確的對錯:輸入 2 + 2,輸出必須是 4,不是就是 bug,一條測試斷言搞定。大型語言模型不是這樣——同一個問題,它可以用一百種措辭都答對,也可以流暢地講一段聽起來很對、實際全錯的話。輸出是開放式的自然語言,沒有一個唯一正確字串可以比對。這讓「這個模型/這套系統到底好不好」變成一個出奇困難的量測問題,而它偏偏又是所有決策的地基:要不要換模型、prompt 改了有沒有變好、上線後有沒有退步,全都得靠評估回答。
先分清兩個層次。**基準測試(benchmark)**是拿公開、標準化的題庫,量一顆「模型」的通用能力,方便跨模型橫向比較——這是你在新聞上看到「某模型 GPQA 拿 94 分」的來源。**評估(eval)**則更廣,通常指你為「自己的應用」量身打造的量測:你的客服 RAG 答得準不準、你的 agent 完成任務的成功率多少。基準測試回答「這顆模型聰不聰明」,評估回答「這套系統在我的場景堪不堪用」。兩者都要,但對做產品的人來說,後者遠比前者重要——這點文末會再回頭強調。
承接 RAG:光有檢索不夠,得分兩段量
昨天說 RAG 要「分開量檢索與生成」,今天把它講透。一套 RAG 答錯,可能錯在兩個地方:檢索段沒撈到對的料,或料對了但生成段亂編。混在一起量,你永遠不知道該修哪裡,所以要拆開。
檢索段借用資訊檢索領域的老工具:context precision(撈回來的 chunk 有多少是真的相關)、context recall(該撈到的相關內容撈全了沒),以及看排序品質的 NDCG、MRR。這段有明確的相關/不相關標籤,相對好量。
生成段才是難點,也是這幾年冒出一整套 RAG 專用框架(如 RAGAS)的原因。它拆出幾個 LLM 才有的維度:faithfulness(忠實度)——答案裡的每一個陳述,是否都能從檢索到的內容裡找到依據,還是模型超出資料自己加戲?這正是量測幻覺的核心手段。answer relevance(答案相關性)——答案有沒有切題,還是答非所問、東拉西扯。context relevance——撈回的上下文夠不夠聚焦,有沒有塞一堆雜訊。RAGAS 這類框架厲害在於它多數指標是 **reference-free(免參考答案)**的:不需要人工先寫好標準答案,而是用一顆 LLM 去拆解、比對陳述與上下文,自動打分。這讓大規模、持續的評估成為可能——這也自然引出下一個主題:用模型當評審。
基準測試家族:每個 benchmark 各測什麼
要看懂排行榜,得先知道每個 benchmark 在量什麼能力,別把它們當成同一種「聰明分數」。
- MMLU / MMLU-Pro:通識知識與推理。原版 MMLU 涵蓋 57 個學科的選擇題,曾是 2023 年的王牌;但前沿模型紛紛破 90% 後它就飽和了,於是有了 MMLU-Pro——一萬兩千題研究所等級難題、選項從 4~5 個增為 10 個,壓低瞎猜命中率、更吃推理。
- GPQA(Diamond):研究所等級的物理、化學、生物,號稱「Google 不到答案」——就算給非專家無限上網,也只能考約 34%。它專門用來量「真正的專家級科學推理」。注意:2023 年底前沿模型還只有約 39%,到 2026 年 Claude Opus 4.7、Gemini 3.1 Pro 都已衝到 94% 上下,GPQA 對頂級模型也開始飽和。
- SWE-bench(Verified):真實世界的軟體工程能力。題目來自 GitHub 上真正的 Python issue,模型要讀懂整個 repo、產出能通過測試的修補 patch。這是最貼近「AI 能不能真的幫你寫程式」的硬核基準。
- HumanEval:更基礎的程式生成,給函式簽章與說明,寫出能通過單元測試的實作,用 pass@k 計分。它老、也早就飽和,但仍是入門級的程式能力座標。
- GSM8K / MATH:數學推理。GSM8K 是小學應用題(考多步驟算術推理),MATH 則是競賽等級的難題。
- MMMU:多模態的研究所級推理,同時考圖(圖表、示意圖、化學結構)加文字,量的是「看得懂圖並據此推理」。
看排行榜的正確姿勢:不要看一個總分,要看「哪個 benchmark 對應你的用途」。要它寫程式就看 SWE-bench,要它做科學問答就看 GPQA,要它讀圖表就看 MMMU。一個在數學屠榜的模型,不保證客服對話討喜。
三個要命的陷阱:汙染、飽和、Goodhart
基準測試看起來客觀,實則遍地陷阱,不懂這三個,你會被排行榜騙。
**基準汙染(benchmark contamination / data leakage)**是最嚴重的。當 benchmark 的題目和答案(或高度改寫的版本)混進了模型的訓練語料,模型考高分就不是「推理出來」,而是「背過答案」——就像考卷提前外洩。這在網路爬蟲式的預訓練幾乎難以避免,連 OpenAI 都公開示警 SWE-bench Verified 在各家前沿模型上都有汙染疑慮,於是有了更難洩題的後繼者(如 SWE-bench Pro)。判斷汙染的訊號:模型在公開題庫上分數奇高,換成同難度但全新、私有的題目就大幅掉分。
飽和(saturation):當所有頂級模型都擠在 90~94% 這種窄帶裡,這個 benchmark 就失去鑑別力了——分數差 1% 可能只是雜訊,分不出誰真的比較強。MMLU、HumanEval、乃至逼近飽和的 GPQA 都是例子。這就是為什麼 benchmark 需要不斷推陳出新、加難度(Pro 版、Diamond 版),永遠是一場評估者與模型的軍備競賽。
Goodhart’s law:「當一個指標變成目標,它就不再是好指標。」一旦某個 benchmark 成了全業界追逐的目標,大家就會有意無意地「對著考試優化」——刷榜、針對題型微調、甚至汙染——分數漂亮了,但那個分數原本想代表的「真實能力」反而被掏空。這是所有評估工作的頭號心魔:你量的東西一旦變成 KPI,它就開始說謊。
LLM-as-a-judge:用模型當評審,以及它的偏見
生成任務沒有標準答案,人工評分又貴又慢,於是主流做法是用一顆強模型當評審(LLM-as-a-judge):給它評分準則(rubric)、待評的答案(或兩個答案比高下),讓它打分或選優。它便宜、快、可規模化,跟頂尖人類評審的一致性也相當高,是 RAGAS 這類自動評估的引擎。
但評審模型帶著系統性偏誤,不校正就會被它騙:
- 位置偏誤(position bias):兩個答案並排比較時,它傾向偏好排在前面的那個。校正法很直接——把兩個答案的順序對調再各評一次,取平均。
- 冗長偏好(verbosity bias):它傾向給比較長的答案較高分,哪怕內容沒更好。得在準則裡明確要求「別因為長就給高分」,或做長度懲罰。
- 自我偏好(self-preference bias):它偏愛「長得像自己會產出」的答案,替自家模型的輸出打較高分。所以評審模型最好跟受測模型不同家,或匿名化來源、隱藏是誰寫的。
實務準則:給評審清楚具體的 rubric、隱藏答案來源、交換位置取平均、必要時多顆評審投票。把 LLM 評審當成「一個有已知偏見、但很勤勞的實習生」——用得好,不用它自己說了算。
人類偏好與 Chatbot Arena:讓真人盲測投票
benchmark 量得了知識與推理,卻量不出一個更玄的東西:人「用起來喜不喜歡」——回答的語氣、格式、貼不貼心。這要靠人類偏好評估,最出名的就是 LMArena(前身 LMSYS Chatbot Arena)。
它的機制優雅:使用者丟一個 prompt,系統回傳兩個匿名模型的答案,使用者選哪個比較好(或平手、都爛)。這是盲測——投票當下你不知道誰是誰,消除品牌光環。累積的成對比較用 Elo / Bradley-Terry 模型(就是西洋棋排名那套)換算成分數:A 贏 B 就加分、B 扣分。自 2023 年上線至今已累積數千萬張票,是目前規模最大的公開人類偏好資料集。截至 2026 年 7 月,Claude Opus 4.8 以約 1580 Elo 領先總榜,而 Moonshot 的開源 Kimi K3 在前端程式競技場衝上第一。
Arena 的價值是補了 benchmark 的盲點——它量的是真實互動中的偏好,難以直接汙染。但它也有自己的偏誤:投票的是特定社群、口味偏好會漂移、也容易被「討喜但空洞」的長答案帶風向(又見冗長偏好)。所以正解永遠是:benchmark、自動評估、人類偏好三者交叉看,別獨押任何一個榜。
開放式輸出與幻覺:最難量的那一塊
摘要、翻譯、創意寫作、開放問答這類任務最難評,因為好答案有無數種、沒有唯一標準。早年用 BLEU、ROUGE 這種比對字面重疊的指標,但它們量的是「跟參考答案用字有多像」,跟「答得好不好」常常兩回事——換個同義的好說法,分數反而掉。現在主流轉向兩條路:一是 LLM-as-a-judge 配一份細緻的 rubric(把「好」拆成正確性、完整性、語氣、格式等維度逐項打分);二是針對事實性(factuality)與幻覺專門量測——把答案拆成一條條原子事實陳述,逐條查證是否有可靠來源支撐(這跟 RAG 的 faithfulness 是同一套思路)。準備一批黃金答案(golden set)——由專家寫好、審過的標準答案——仍是評估開放任務最扎實的地基,雖然貴,但它是你判斷自動評估準不準的那把尺。
落到產品:私有 eval set、離線 vs 線上、迴歸測試
最後這段最實用,做產品的人請記牢。公開 benchmark 幫你選模型,但真正決定你產品好壞的,是你自己的私有評估集(private eval set)——用你真實場景的題目、你在乎的標準,建一套只有你有、絕不外流的測試集。它有三個公開榜給不了的好處:貼合你的實際用途、天然免疫汙染(模型沒看過)、而且指標由你定義。這是 AI 產品團隊最該投資、也最容易被忽略的資產。
再分清兩種評估時機。離線評估(offline):上線前,拿固定的評估集跑,快速便宜地比較「改動前 vs 改動後」,適合開發迭代。線上評估(online):上線後,用真實流量量測——A/B 測試、使用者按讚倒讚、真實成功率——它最真實,但慢、有風險、且受各種外部變因干擾。兩者互補:離線把關別讓爛東西上線,線上驗證離線的判斷在真實世界站不站得住。
把這一切綁起來的,是**迴歸測試(regression testing)**的紀律:每次改 prompt、換模型、動 RAG 參數,都對同一套私有評估集重跑,確認「這次改動有沒有讓某些原本會的案例反而變爛」。LLM 系統牽一髮動全身——為了修好 A 類問題調的 prompt,很可能悄悄弄壞了 B 類。沒有迴歸測試,你就是在拆東牆補西牆而不自知。這正是把昨天那句「從第一天就做評估」真正落地的方法。
🧠 記
- 兩個層次別混:benchmark 用公開標準題庫量「模型」的通用能力(方便跨模型比),eval 用你自己場景的題目量「系統」在你用途上堪不堪用;做產品時後者更重要。
- 承接 RAG:評估要分兩段。檢索段量 context precision / recall、NDCG;生成段用 RAGAS 這類框架量 faithfulness(忠不忠於來源=幻覺指標)、answer relevance、context relevance,且多為免參考答案。
- Benchmark 各有專長:MMLU(通識)、GPQA(專家科學推理)、SWE-bench(真實程式修 bug)、HumanEval(基礎程式)、GSM8K/MATH(數學)、MMMU(多模態看圖推理)——看榜要對應你的用途,別看單一總分。
- 三大陷阱:汙染(題目洩進訓練資料=背答案不是推理)、飽和(頂級模型擠在窄帶失去鑑別力)、Goodhart’s law(指標一旦成為目標就被刷榜掏空)。
- LLM-as-a-judge 便宜可規模化,但有位置偏誤(偏前者→換序取平均)、冗長偏好(偏長答→長度懲罰)、自我偏好(偏自家輸出→換評審家、匿名化);人類偏好靠 LMArena 盲測+Elo。
- 產品鐵律:建自己的私有 eval set(貼合場景、免疫汙染)、分離線(上線前迭代)與線上(真實流量)評估、每次改動都跑迴歸測試,防止修 A 弄壞 B。
✍️ 實踐
接續昨天你搭的那套最小 RAG,今天別再靠「眼睛看感覺對不對」——動手建一套屬於它的私有評估集。挑 20~30 個你場景裡真實會被問的問題,親自寫好每題的黃金答案與「應該撈到哪些來源」,存成一個 CSV 或 JSON。這份東西看起來土,卻是你之後所有判斷的那把尺;它會逼你把「好答案長什麼樣」講清楚,而這件事本身就價值連城。
接著跑一次真正的量測。用 RAGAS(或自己寫個簡單的 LLM-as-a-judge 腳本)對這 20~30 題算出 faithfulness、answer relevance、context precision 三個分數,記下基準線。然後刻意做一次改動——換個嵌入模型、或把切塊策略從固定長度改成語意切塊——重跑同一套題,比較分數變化。你會第一次「看見數字」告訴你改動到底有沒有用,而不是憑感覺。順手體驗 LLM 評審的偏誤:同一題,把你的答案硬拉長一倍(廢話不加資訊)再讓評審打分,看它是不是給了更高分——那就是冗長偏好在你眼前現形。
🔗 延伸學習
- LMArena Leaderboard(前 LMSYS Chatbot Arena) — 最大規模的公開人類盲測偏好榜,親眼看 Elo 排名怎麼運作、當前各模型高下。
- Stanford CRFM — HELM(Holistic Evaluation of Language Models) — 史丹佛的整體式評估框架與排行榜,示範怎麼「不只看準確率」地全面量測模型。
- RAGAS:Available Metrics 官方文件 — RAG 評估框架 RAGAS 的完整指標清單(faithfulness、context precision/recall 等),照著就能上手量你的 RAG。
- SWE-bench 官方網站 — 真實 GitHub issue 的程式修補基準,了解「AI 能不能真的寫程式」是怎麼被量測的。
💬 問 AI
想把今天的概念變成能保護你產品的工具,可以請 AI 幫你為自己的 AI 應用設計一套評估方案。把下面這段貼給它,換成你的情境:
我想為我的 AI 應用建立一套系統化的評估(eval)機制,請扮演資深 AI 評估工程師幫我規劃:
【我的應用】(在此描述:例如「一套查詢公司產品手冊的客服 RAG 問答系統」)
【我最在乎的品質】(例如「不能亂編、答案要有來源、語氣要專業友善」)
請針對這個情境,給我:
1. 我該建一套怎樣的私有評估集(eval set):要收哪幾類題目、每題要準備哪些欄位(問題、黃金答案、應命中的來源等)、大概要幾題才夠。
2. 我該量哪些指標,以及各自對應我在乎的哪個品質(例如 faithfulness 對應「不能亂編」);哪些適合用 RAGAS 這類自動框架、哪些需要人工或 LLM-as-a-judge。
3. 如果用 LLM-as-a-judge,我要注意哪些偏誤、怎麼在 rubric 與流程上校正(位置、冗長、自我偏好)。
4. 離線評估與線上評估我分別該怎麼做,以及迴歸測試的具體流程(每次改 prompt/模型/RAG 參數時該跑什麼)。
請具體、務實,直接給我可以照做的清單與範例,不要空泛原則。