你的 AI 到底做對沒有？用評估框架與 LLM 評審科學化衡量

一個 demo 很驚豔的客服機器人，上線三週後沒人說得清它好不好

很多團隊都遇過同一個畫面。AI 客服或 AI agent 的 demo 跑起來很漂亮，主管點頭、預算過了、系統上線。三週後有人問一句：「它現在到底答得好不好？」會議室就安靜了。

有人說客訴變少了，有人說同事覺得語氣怪怪的，有人翻出兩三筆答錯的截圖。沒有人能回答一個更基本的問題：這套系統的正確率是多少？跟上一版比是進步還是退步？昨天改的那個 prompt（提示詞，也就是給模型的指令）到底讓它變好還是變壞？

這個沉默，就是缺了 eval（evaluation 的縮寫，指對 AI 系統輸出做有系統的衡量）。Stanford 在談生產環境 agent 系統設計時，把 eval 稱為命脈：沒有 eval，你不知道系統有沒有用，也不知道每次改動是往前還是往後。這篇文章要把「怎麼科學化衡量一套 AI 系統」這件事，從表象拆到底層原理，讓不是這個領域的人也讀得懂。

開一個 open loop 在這裡：等你讀完，回頭看那個沉默的會議室，你會發現問題從來不是模型不夠強，而是沒有人替這套系統裝上量尺。

為什麼 91APP 團隊在意這題

91APP 團隊每天面對的是品牌客戶的真實會員資料、真實訂單、真實客服對話。當我們把 AI 放進客戶成功（customer success）流程，放進報表問答，放進受眾溝通，第一個被追問的永遠不是「模型選哪家」，而是「你怎麼證明它沒有亂答」。

我們把這題當成基本功，因為在零售場景裡答錯是有成本的。AI 把促銷規則講錯、把會員分群說反、把退貨政策編一個不存在的版本，傷的是品牌信任，而信任正是 AI 行銷會失敗的根因，往往不在模型而在數據品質與整合 這件事的延伸。下面用我們在實務上整理的觀念，把評估框架的底層原理拆給技術讀者看。

只盯一個準確率會留下盲區，三組維度要一起看

很多人以為「評估 AI」就是算一個準確率。實際上一套能用的 eval 體系，是三組維度交織在一起，每一組都得照顧到，漏掉任何一組都會有盲區。先用兩欄表把三組維度的對照講清楚。

第一組：整體 vs 逐步。

第二組：客觀 vs 主觀。

第三組：量化 vs 質化。

這三組不是三選一，而是同時成立的三個切面。同一筆 AI 對話，可以從端到端看它整段成不成立，也可以拆到元件層看是哪一步出錯；可以用客觀程式比對欄位，也可以用主觀判斷語氣；可以匯總成一個量化成功率，也可以留一份質化筆記記錄它怎麼出包。要提醒的是，這三組並非數學上完全獨立的座標軸：主觀評估也可以被量化成分數，客觀檢查也會留下質化的除錯紀錄，它們更像是設計 eval 時常用的三種切分角度。一套成熟的 eval，是在這三種切面裡選對組合，而不是只盯著一個準確率。

同樣答錯，端到端與逐元件會給你完全不同的線索

舉一個具體情境。一位會員問 AI 客服：「我正想買這件 2,000 元的外套，可以用生日禮金折抵嗎？」AI 回答：「可以，您有 200 元生日禮金，折抵後是 1,800 元。」結果這位會員其實沒有任何生日禮金可用。

如果你只做 end-to-end 評估，你會記下一筆：這次回答錯誤。量化上它讓成功率掉了一格，如此而已。你知道系統錯了，但不知道錯在哪。

如果你同時做 component-based 評估，把這次對話拆開看，故事就完整了。第一步檢索（retrieval，從資料庫撈出相關資訊的動作）有沒有撈到正確的禮金餘額？第二步模型有沒有正確讀懂折抵規則？第三步輸出時有沒有把數字算對？拆開後你可能發現：檢索其實撈對了「此會員禮金餘額為 0」，但模型在推理那一步無視了這筆事實，自己編了一個 200 元出來。

這兩種視角的差別，決定你接下來要修哪裡。只看端到端，你可能誤判成「換個更強的模型就好」；看了逐元件，你才知道問題出在推理階段對檢索結果的服從度，要修的是 prompt 設計或加一道事實核對，而不是換模型。Stanford 的觀點很直接：兩者都要做。端到端告訴你使用者體驗成不成立，逐元件告訴你壞在哪、該動哪裡。

再把這個情境往客觀與主觀的維度延伸一次，會更清楚為什麼三維要交織。同樣這筆對話，客觀評估可以寫程式自動檢查：系統算出的折抵後金額，跟用該會員真實禮金餘額重算的金額是否一致，這是一道有標準答案的是非題，不需要任何人來判斷。主觀評估則處理另一面：就算金額算對了，AI 那句「可以喔，幫您折抵」的語氣會不會太武斷、有沒有先確認資格再給承諾，這種沒有唯一正解的判斷，就得交給人或 LLM 評審。同一筆資料，客觀那一格抓的是事實錯誤，主觀那一格抓的是體驗問題，缺一個都會讓你以為系統「只是偶爾算錯」，而沒看見它在語氣上其實一直給過頭的承諾。

量化與質化的差別也藏在這裡。量化會告訴你這類折抵問題的整體成功率是 88%，這個數字適合追蹤趨勢、適合跟上一版比較。但 88% 不會告訴你那失敗的 12% 長什麼樣子，是金額算錯、還是資格判錯、還是語氣出包。要回答這個，你得回到質化，人工把那十幾筆失敗一筆筆讀過，才看得見模式。量化負責「有沒有變好」，質化負責「為什麼會壞」，兩者一起才構成完整的線索。

從表象到機制：讓 LLM 當評審，到底是怎麼運作的

前面說主觀評估可以讓「人或 LLM」來判斷。人工判斷大家都懂，這一段要把技術含量最高的部分講透：怎麼讓一個 LLM 去當另一個 AI 系統的評審，也就是業界說的 LLM as a judge（用大型語言模型當評審）。

先講為什麼需要它。客觀程式比對只能處理有標準答案的題目，例如金額、欄位、是非題。但 AI 客服大量的回答是開放式的，沒有唯一正解。一句安撫的話得不得體、一段說明清不清楚，寫不出一個 if-else 來判斷。這時候要嘛靠人工一筆一筆讀（準但慢又貴），要嘛找一個夠強的 LLM 來當評審，把人工判斷的標準教給它，讓它規模化地評分。

這也是 用 RAG x LLM 強化客戶成功服務 這類應用能不能上線的前提：你得先有能力衡量它答得對不對，才敢把它放到客戶面前。這不是憑空冒出來的做法。Zheng 等人在 2023 年的論文（Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, Zheng et al., 2023, arXiv:2306.05685）系統性驗證了這件事：在 MT-Bench 與 Chatbot Arena 這類開放式偏好評估裡，用 GPT-4 這種強模型當評審，它的判斷和人類偏好的一致程度可以達到八成以上，跟兩個人類標註者彼此之間的一致程度差不多。要留意的是，這裡量的是「偏好一致度」，不等於它在事實正確、零售規則、法務這類有明確正解的領域都同樣可靠，所以特定場景仍要用人工金標準另外校準。但這個結論的份量在於：它把人工只能抽樣讀幾十筆的限制，擴展成可以對大批量真實對話做重複、自動化的品質衡量，前提是保留人工校準與抽查。

LLM as judge 在實務上常見以下幾種判斷形式。其中前三種是 Zheng 論文明列的評分形式，第四種 rubric-based 嚴格說是一層可以套在前三種上的評分設計，這裡把它並列出來方便對照，各有適用場景而非單一的嚴謹度排序。

1. Pairwise（兩兩比較）：丟給評審 A 和 B 兩個回答，問它哪個比較好。這是最貼近人類直覺的方式，因為人判斷「哪個比較好」遠比「給這個打幾分」來得穩。知名的 Chatbot Arena 就是用這個邏輯，讓真人對兩個匿名模型的回答二選一，再用源自西洋棋的 Elo 評分把成千上萬筆兩兩對戰換算成排名（Chatbot Arena: Benchmarking LLMs in the Wild with Elo Ratings, LMSYS, 2023）。
2. Single answer grading（單筆直接評分）：給評審一個回答，請它依照標準給 1 到 5 分。比兩兩比較省事，可以對單筆做絕對評分，但分數的穩定度比兩兩比較差，今天的 4 分和明天的 4 分標準可能漂移。
3. Reference guided（給標準答案對比）：先準備好一份理想答案，讓評審拿 AI 的回答去跟標準答案比對。適合有公認正解的題目，能大幅降低評審亂給分的空間。
4. Rubric-based（依評分標準給分）：自己寫一套明確規則，讓評審照規則判。例如「回答控制在 100 字內且命中重點給 5 分，答非所問給 0 分，部分正確給 2 到 3 分」。這是最能控制品質、也最可重複的一種，因為評審不是憑感覺，是照你寫的尺在量。

四種玩法的底層共識是同一件事：把模糊的「好不好」變成可重複、可稽核的判斷。其中 rubric-based 是最值得投資的，因為它把標準寫死成文字，今天的你、明天的你、和那個 LLM 評審，量的是同一把尺。

值得多花一段把 rubric 的設計講清楚，因為它是整套主觀評估的關鍵零件。一份好的 rubric 不是寫「答得好給高分」這種空話，而是把每一個分數對應到可觀察的具體條件。以前面的折抵情境為例，一份能用的 rubric 會長這樣：先確認會員資格再給承諾、金額計算正確、語氣不武斷，三項全中給 5 分；金額對但語氣過頭給 3 分；金額算錯給 1 分；憑空編造不存在的禮金給 0 分。每一檔分數背後都是一個能被另一個人複核的條件，這樣不管是 LLM 評審還是人來打，量出來的分數才能對齊。Anthropic 在工程文件裡也建議，與其用一份包山包海的 rubric 一次評完所有面向，不如把「事實正確」「語氣得體」「格式合規」拆成各自獨立的 rubric 分開評，這樣每一項的訊號才不會被別項稀釋。rubric 寫得越具體，評審的判斷就越穩，A/B 測試時前後分數的比較才越可信。

機制再往下一層：LLM 評審會有偏誤，要先知道才防得住

把 LLM 當評審不是裝上去就信任它。它有幾個已被研究記錄的系統性偏誤，理解這些偏誤才知道為什麼前面那四種玩法要這樣設計。

Zheng 等人的論文點名了三種主要偏誤（arXiv:2306.05685）。第一是位置偏誤（position bias）：兩兩比較時，評審容易偏好排在前面的那個答案。對策是把 A、B 順序對調再評一次，兩次結論一致才算數；若對調後結論不一致，不要硬選一邊，標成平手或不確定，交給第三個評審或人工複核。第二是冗長偏誤（verbosity bias）：評審容易覺得長的答案比較好，即使長答案塞了廢話。對策是在 rubric 裡明確要求簡潔，把長度本身列入扣分項。第三是自我偏好（self-enhancement bias）：研究觀察到部分評審對自己或同風格模型的輸出可能給較高分數，不過原論文對這點態度保留，並未斷言所有模型都有此偏誤。實務上仍建議避免拿 A 模型去評 A 模型自己的輸出，或至少用人工、第三方評審交叉校準。

Anthropic 在工程部落格裡給了更實務的防身建議（Demystifying evals for AI agents, Anthropic, 2026）。他們強調 LLM 評審必須跟人類專家校準，確認模型給的分和人給的分差距夠小，你才能信任它。他們也提了一個防幻覺的小設計：給評審一個逃生出口，當資訊不足時允許它回答「未知」，而不是硬編一個答案。還有一個值得照做的原則：與其用一個評審一次評完所有面向，不如為每個面向寫獨立的 rubric，用各自隔離的評審分別評分，這樣每一項的標準才不會互相干擾。

業界另一個被反覆驗證的細節是：把評審模型的溫度（temperature，控制輸出隨機性的參數）設成 0，讓它的判斷盡量穩定可重複；同時把評審的原始判斷理由記錄下來，事後有爭議時可以回頭稽核它當初為什麼這樣判。

說到這裡，那個 open loop 可以收一半了：AI demo 驚豔但上線後沒人說得清好壞，根源就是團隊把心力全押在模型，卻沒有替系統建一把校準過的、可重複的量尺。LLM as judge 加上 rubric，就是那把量尺的核心零件。

但工具再好，沒有 error analysis 都是空中樓閣

這裡要講一個最常被跳過、卻最關鍵的基礎動作：error analysis（錯誤分析）。它的意思很樸素，就是人工抽樣去讀真實的對話紀錄，一筆一筆看系統到底錯在哪，把痛點找出來、歸類、計次。

為什麼它這麼重要？因為你不可能評估一個你還沒搞懂哪裡會壞的系統。Hamel Husain 與 Shreya Shankar 在他們廣為流傳的 eval 教材裡講得很重（LLM Evals FAQ, Hamel Husain, 2026）：大多數團隊一上來就急著寫 LLM 評審、做儀表板，這是本末倒置。你得先靠人工讀紀錄，搞清楚實際發生了哪些失敗模式，才有辦法去衡量它。錯誤分析不是可有可無的步驟，它是地基；跳過它，後面蓋的東西都建在沙上。

實務上的做法是先人工讀至少 100 筆對話，邊讀邊寫開放式筆記，讀到新的對話不再冒出新的錯誤類型（他們稱為理論飽和），就可以收手。接著把這些筆記歸類成幾種失敗模式，再計次，看哪一種錯誤發生得最頻繁。重點是務實：目標是優先處理最常發生的失敗，不是窮舉每一種可能的錯誤，因為評估本身也要花成本。

把這套接回主觀評估，Stanford 整理的四步流程就完整了。

1. Error analysis：人工抽樣讀對話，找出真實痛點並歸類。
2. 翻譯成 rubric：把找到的失敗模式寫成明確的評分標準，這份 rubric 就是給 LLM 評審用的尺。
3. A/B 測試模型：固定 prompt，只換模型，比較兩個模型在同一把尺下誰好。
4. A/B 測試 prompt：固定模型，只做一個明確可描述的 prompt 變更（例如新增一條約束、改一段規則、或替換一個範例），看分數變化。

這四步有一個次序上的講究：error analysis 一定排在最前面。先讀真實對話、確定系統實際會怎麼壞，rubric 才寫得出對的評分項；rubric 對了，後面兩道 A/B 測試量出來的分數才指向真正重要的問題。倒過來做，先憑想像寫一份 rubric 再去評，你很可能花力氣量了一堆其實不常發生的錯誤，卻漏掉系統真正每天在犯的那一種。

這裡也要補一個現實的邊界：上面假設你手上已經有一批上線後的真實對話可讀。如果系統還沒上線、還沒有真實流量，不必苦等。可以先用手動寫的測試任務、過去的客訴清單或合成案例湊出一版初步的 eval，先把流程跑起來，等系統上線、真實對話累積出來，再用 error analysis 回頭修正評分項。

這四步還有一條鐵律貫穿：一次只能動一個變數。

一次一變數：A/B 測試裡最容易違反、也最致命的原則

A/B 測試的精神是控制變因。你想知道「把 prompt 裡那句話改掉」有沒有效，唯一誠實的做法是固定其他所有東西，只改那一句，跑同一套題目，比前後分數。

最常見的錯誤是貪心：一次又換模型、又改 prompt、又調檢索參數，結果分數變好了，你卻不知道是哪個改動的功勞；分數變差了，你也不知道要回退哪一個。三個變數一起動，等於把三個實驗攪成一鍋，最後什麼結論都得不到。

所以紀律是：要比模型，就固定 prompt 只換模型；要比 prompt，就固定模型只做一個明確的 prompt 變更。OpenAI 的開源 eval 框架（OpenAI Evals, OpenAI, GitHub）代表的是另一個工程方向：把整套評估用程式跑、用固定資料集重複跑，讓比較能被機器自動化、能被重現。一次一變數是實驗設計的原則，程式化與資料集化是讓這個原則跑得起來的工程基礎，兩者合起來，每次改動才站得住。

把評估程式化並控制單一變數，是量尺站得住的關鍵

把前面的原理收斂成可執行的判斷清單，給準備替 AI 系統建量尺的團隊。

1. 先做 error analysis，再談指標。人工讀至少 100 筆真實對話，把失敗模式歸類計次，找出最常發生的前幾種錯誤。沒做這一步就先寫評審，等於蒙著眼睛裝量尺。
2. 三維都要照顧。端到端看體驗、逐元件找壞點、客觀程式比對該比對的、主觀評審判該判的、量化匯總成數字、質化留一份人工筆記。檢查自己是不是只做了其中一格。
3. 能用程式判的就別用 LLM 判。金額、欄位、格式這類有標準答案的，寫程式自動比對最快最穩，把寶貴的 LLM 評審額度留給開放式的主觀題。
4. 主觀題優先用 rubric-based。把標準寫成明確規則（幾分對應什麼條件），讓評審照尺評分，這樣分數可重複、可稽核。
5. 校準你的 LLM 評審。拿一份人工標好的金標準答案，比對評審打的分和人打的分差多少，差太多就回頭修 rubric。把評審溫度設 0，記錄它的判斷理由。
6. 防三種偏誤。兩兩比較時對調 A、B 順序各評一次；rubric 裡明確要求簡潔以防冗長偏誤；避免用某模型評它自己的輸出。
7. A/B 一次一變數。換模型就固定 prompt，改 prompt 就固定模型，跑同一套題目比前後分數。絕不一次動多個。
8. 把整套 eval 程式化、固定資料集重複跑。讓每次改動都能用同一批題目重現比較，而不是每次手動抽幾筆看感覺。
9. 定期更新題庫，留一份盲測集。固定資料集用久了會被優化到飽和，系統可能被調到只會討好那個 LLM 評審；真實客戶的問題分布也會隨時間漂移。定期補入新的真實案例，並保留一批不拿來調整的盲測題，避免只針對同一批題目和同一個評審過度優化。

落到實務上舉一個例子。91APP CDMP 團隊在替品牌客戶的 AI 服務做衡量時，就是照這個次序走：先人工讀真實的會員對話找出最常見的失敗模式（例如把促銷規則講錯、把會員分群說反），把這些模式寫成 rubric，再用校準過的 LLM 評審規模化評分，每次只改一個變數做 A/B。順序對了，數字才有意義。這只是一個應用面的例子，原理本身對任何 AI 系統都通用。

量尺裝上去，那個沉默的會議室就不會再出現

回到開頭那個畫面。三週後沒人說得清 AI 好不好，不是因為模型不夠強，是因為這套系統從頭到尾沒被裝上一把校準過的量尺。

把這篇講的東西做完，那個會議室的沉默就會被一句話取代：「這版正確率 92%，比上版高 4 個百分點，進步來自我們改掉了那句會誤導模型的 prompt，rubric 上每一項都有對應的分數。」這就是 eval 的價值，它讓「AI 到底做對沒有」從一個沒人敢答的問題，變成一個有數字、有依據、可以追蹤的答案。

衡量不會讓 AI 自動變好，但沒有衡量，你連它有沒有變好都不知道。對一套要進生產環境、要面對真實客戶的 AI 系統來說，先把量尺裝上，才有資格談優化。

常見問題

Q1：什麼是 AI 評估（eval）？為什麼生產環境的 AI 系統一定要做？ Eval 是 evaluation 的縮寫，指對 AI 系統的輸出做有系統的衡量。生產環境的 AI 系統一定要做 eval，因為沒有它你就無法回答最基本的問題：系統正確率多少、跟上一版比是進步還是退步、剛改的 prompt 是讓系統變好還是變壞。Stanford 把 eval 稱為生產環境 agent 系統的命脈，意思是沒有 eval 就不知道系統有沒有用。

Q2：LLM 評估有哪三組維度？ 三組交織的維度：一是 end-to-end 端到端與 component-based 逐元件，前者看最終體驗成不成立，後者看內部哪一步壞了；二是 objective 客觀與 subjective 主觀，客觀用程式自動比對，主觀靠人或 LLM 判斷；三是 quantitative 量化與 qualitative 質化，量化匯總成數字，質化人工一筆筆讀抓幻覺與語氣。三組要同時照顧，漏掉任何一組都會有盲區。

Q3：LLM as a judge 是什麼？有哪幾種玩法？ LLM as a judge 指用一個夠強的大型語言模型當評審，去判斷另一個 AI 系統的開放式回答好不好。四種玩法：Pairwise 兩兩比較、Single answer grading 單筆直接打 1 到 5 分、Reference guided 給標準答案對比、Rubric-based 依自寫的評分標準給分。其中 rubric-based 最可重複、最可稽核，最值得投資。

Q4：用 LLM 當評審可信嗎？有什麼偏誤要注意？ 研究顯示夠強的 LLM 評審和人類偏好的一致程度可達八成以上，接近一位人類標註者。但它有系統性偏誤要防：位置偏誤（偏好排前面的答案，對策是對調順序再評）、冗長偏誤（覺得長答案比較好，對策是 rubric 要求簡潔）、自我偏好（給自己風格的答案較高分數，避免用模型評自己的輸出）。同時要拿人工金標準校準，把溫度設 0，記錄判斷理由以供稽核。

Q5：什麼是 error analysis（錯誤分析）？為什麼這麼重要？ Error analysis 是人工抽樣讀真實對話紀錄，一筆一筆找出系統錯在哪、歸類、計次的過程。它重要是因為你不可能評估一個還沒搞懂哪裡會壞的系統。實務做法是人工讀至少 100 筆，讀到不再冒出新的錯誤類型就收手，再把失敗模式歸類計次，優先處理最常發生的錯誤。大多數團隊跳過它直接寫評審，等於把後面所有東西建在沙上。

Q6：A/B 測試 AI 系統時為什麼要一次只改一個變數？ 因為 A/B 測試的精神是控制變因。如果一次又換模型、又改 prompt、又調參數，分數變好你不知道是哪個改動的功勞，分數變差你也不知道該回退哪一個。所以紀律是要比模型就固定 prompt 只換模型，要比 prompt 就固定模型只改一個詞，跑同一套題目比前後分數。

Q7：如何用 AI 客服品質評估的結果改善系統？ 完整次序是：先做 error analysis 找出最常見的失敗模式，把這些模式翻譯成 rubric 評分標準，用校準過的 LLM 評審規模化評分得到基準分數，接著一次只改一個變數做 A/B 測試（先換模型或先改 prompt），跑同一套固定資料集比前後分數，採用有效的改動、回退無效的。把整套流程程式化重複跑，每次改動都能被重現比較。

評估是系統的命脈。回頭看 用經理人思維設計 AI 工作流 理解被評估的系統怎麼設計，往前看 先拆解任務，再決定要不要 multi-agent 把每一步的 eval 放進多 agent 架構。

延伸閱讀

1. 選 CDP AI Agent 前先問 4 個問題：把本文的評估精神套到挑選 AI agent 的實際決策上。
2. 破解 AI 神話：MCP 報表到 RAG 的陷阱、人機協作：理解 AI 系統常見的失敗模式，正是 error analysis 要抓的東西。
3. 如何挑選 CDP AI Agent：選型階段就把可衡量性納入考量，避免買到一個說不清好壞的系統。
4. 91APP AgentOne 的資安：Agent 為什麼需要資料獨立與數據 Sandbox