昨天把驗證的機制建起來了：確定性信號優先，蓋不到的空間交給分層評估和 LLM-as-Judge。今天的問題是量什麼。這題我交過學費：第一次認真跑評估的時候，我直接全選。DeepEval（定位像 pytest for LLM 的開源評估框架）有 40 幾個指標，我覺得多多益善，全部開起來，跑完拿到一張有 40 幾個分數的報表。Faithfulness 0.81、Contextual Precision 0.74、Tool Correctness 0.90，每個數字看起來都還可以，組合起來什麼資訊也沒有：改了什麼會讓哪個分數動？要修哪裡？都不知道。

那次的教訓一句話：指標是工具，不是成績單。評估要回答的是「這個系統哪裡有問題」，分數自己不會告訴你。指標選太多，和完全不評估的下場一樣：沒有可行動的資訊。

先認架構，再選指標

選指標的起點是你的系統架構，因為不同架構的失敗模式不同，該量的東西也不同：

對號入座，只看你那一格。下面挑幾個架構展開，示範「按失敗點選指標」的思路。

RAG：先分清是檢索爛還是生成爛

兩個常被混用的指標先分開。Faithfulness 問「回答有沒有被召回的 context 支撐」，它是 RAG 的品質指標，就算世界上沒有這個知識，只要 context 支持它就高。Hallucination 問「回答有沒有跟 context 矛盾」，它是防腦補的安全檢查。兩個都在看事實性，量的東西不同，別當成同一件事。

檢索端如果只能選一個指標，選 Contextual Recall：「回答需要的資訊，有沒有被召回進 context？」它低，代表巧婦難為無米之炊，生成端再怎麼調都是白工。這剛好是昨天三層評估的中層落到 RAG 的樣子：輸出爛掉，先用檢索指標定位是哪一段爛。

Agent：工具對了不代表答案對了

Agent 的失敗常在中間某一步。Tool Correctness 量「選對工具了嗎」，Argument Correctness 量「參數填對了嗎」，兩個要分開量，因為實務上參數錯比選錯更常見，尤其 tool schema 描述模糊的時候，Day 17（Tool Design）的老問題在評估端再現一次。

Task Completion 這個指標藏著一個重要前提：它需要完整的執行軌跡（trace，系統每一步做了什麼的記錄）。agent 說「已幫您完成訂位」，中間的工具呼叫其實失敗了，只看最終輸出你永遠不會知道。Step Efficiency（有沒有繞遠路）則沒有絕對標準，什麼叫「不必要的步驟」是業務判斷，務實做法是拿現有系統跑 50 個 case 建 baseline，用 baseline 設閾值，別憑空定一個絕對值。

沒有標準答案的場景：用準則，或用對打

沒 retrieval 也沒 tools 的純 LLM 服務，主力是兩個工具。G-Eval 讓你用自然語言寫評估準則（「推理是否邏輯清晰、結論是否有根據支撐」），judge 回給你分數和 reason。reason 常常比分數有價值：「雖然通過，但步驟三跳過了關鍵假設」這種資訊才有地方動手，閾值附近的 case 尤其該讀。它的適用邊界也要標清楚：準則是模糊的語意標準才用它；明確的業務規則（「輸出必須包含 X 欄位」「遇到 Y 必須拒絕」）該用確定性的規則檢查，昨天的優先序在指標層一樣成立。

ArenaEval 換一個問法：與其煩惱「0.75 算不算好」，把新版和舊版的輸出配對，讓 judge 判誰贏，拿勝率當標準，例如「新版要贏過舊版六成以上」。prompt 迭代的場景特別好用，因為「有沒有進步」本來就是相對問題，相對比較不需要定義絕對門檻。

指標全過了，系統還是爛的三種情況

第一種：test set 不代表真實分佈。golden dataset 是你建的，你怎麼建就測什麼，全是標準問法的測資，擋不住真實使用者的怪問題。解法是讓線上資料餵回評估：對生產環境裡行為異常的 trace 打標籤，定期轉成 golden case 補進 test set，讓測資跟著真實行為一起進化。

第二種：只看分數，不看 reason。分數告訴你過沒過，reason 告訴你哪裡出問題，前面講過了，這裡算進坑清單再提醒一次。

第三種：評估做一次就收工。模型版本更新、tool API 悄悄改了 schema、使用者行為漂移，指標會無聲下滑。評估要接進 CI，每次變更都跑一遍，而不是靠人記得去測。

回頭數一下，今天撞了三次同一面牆：Task Completion 要 trace、test set 要靠線上行為餵、指標下滑要有人發現。三件事指向同一個缺口：系統在生產環境裡到底發生了什麼，你看得見嗎？明天講可觀測性。