LLM Evaluation 實務：RAG 評估、Agent Trajectory、Golden Dataset 與 LLM-as-Judge 的限制¶

整理自評估框架官方文件與學術論文（見文末），2026-06-20。本頁是「怎麼評 LLM 系統」的實務地圖：分清楚你在評的是「最終答案」還是「過程」，挑對指標，並認清 LLM-as-judge 不是萬靈丹。

實證標記：〔論文〕= 出自學術論文；〔框架〕= 出自評估框架官方文件（RAGAS / LangSmith 等）；〔實務〕= 業界慣例或本人整理，未必是規範。預設 under-claim，拿不準的地方會明講。

先分清楚：你在評什麼¶

評 LLM 系統最常見的錯，是把「不同層次的東西」用同一把尺量。先把對象拆開：〔實務〕

評估對象	問的問題	典型方法
單次輸出品質	這個回答好不好？	人工評分、LLM-as-judge、規則指標
RAG 系統	檢索對不對？生成有沒有忠於來源？	RAGAS 類指標（拆檢索/生成）
Agent 軌跡	過程中的每一步工具呼叫對不對？	trajectory match、step-level judge
離線回歸	改了東西有沒有變差？	golden dataset + 自動指標

口訣：答案層看「結果」，agent 層看「過程」，回歸層看「有沒有退步」。 混在一起評，通常兩邊都評不準。〔實務〕

RAG 評估：把檢索與生成拆開量¶

RAG 出錯有兩種完全不同的來源——檢索沒撈到對的東西，或撈到了但生成亂講。好的評估要能分辨是哪一種。RAGAS 框架把這拆成四個核心指標：〔框架〕

指標	量什麼	對應環節
Faithfulness（忠實度）	回答是否只根據檢索到的內容、沒有捏造	生成
Answer Relevancy（答案相關性）	回答是否切題、有回應到問題	生成
Context Precision（脈絡精確率）	撈回來的內容裡，有多少是真的相關	檢索
Context Recall（脈絡召回率）	需要的相關資訊有多少被成功撈回	檢索

〔框架〕RAGAS 的設計賣點之一是多數指標不需大量人工標註的標準答案，可用 LLM 輔助計算——但這也意味著它繼承了 LLM-as-judge 的偏誤（見下節），數字要當「相對趨勢」看，不要當絕對真值。〔實務〕

〔實務〕實務上 faithfulness 偏低 → 多半是 prompt 沒約束模型「只根據脈絡回答」或生成模型太愛自由發揮；context recall 偏低 → 是 chunking / 檢索 / reranking 的問題。先看是哪一類指標掉，再決定改哪一段，比盲調有效。詳見 RAG 進階系列。

Agent Trajectory 評估：過程對不對，比結果對不對更難¶

Agent 會跨多步呼叫工具。只看最終結果會漏掉「結果對但過程亂」（瞎貓碰死耗子）與「過程合理但最後一步失誤」這兩種重要情況。所以 agent 要評軌跡（trajectory）——整串訊息與工具呼叫的序列。〔框架〕

常見做法分兩類：〔框架〕

Trajectory match（對標準軌跡比對）：把 agent 實際的工具呼叫序列，跟預期序列比對（嚴格逐步、或允許順序/超集）。適合有明確正解流程的任務。
LLM judge on trajectory：沒有單一標準流程時，用一個 LLM 評審判斷整串軌跡是否合理。靈活但繼承 judge 偏誤。

〔論文〕針對工具使用的評估還有更細的切法：BFCL（Berkeley Function-Calling Leaderboard）測「工具名稱與參數對不對」；τ-bench（Tool-Agent-User）則在模擬使用者互動的真實場景（如航空客服改票）測 agent，比單回合函式呼叫更接近實況。

〔論文〕一個值得記住的限制：LLM 模擬的使用者並不是真人的可靠替身——用 LLM 扮演 user 來跑 agentic 評估，結果可能與真人測試系統性偏離。模擬 user 適合大量回歸，不能完全取代真人驗收。

Golden Dataset：離線評估的地基¶

要能「改了東西、自動知道有沒有變差」，你需要一份golden dataset（黃金測試集）：一組固定的輸入 + 期望輸出/期望行為。〔實務〕

建一份能用的 golden dataset，實務上注意：〔實務〕

覆蓋真實分布：從真實 log 取樣，別只放工程師想得到的乾淨案例；要刻意納入難例、邊界、已知會出錯的 case。
標註成本是真成本：高品質標準答案要人標，貴。RAG 類指標部分可繞過標註，但 agent / 複雜任務多半繞不過。
會腐化：模型、prompt、資料來源一變，舊的期望輸出可能就過期；golden set 要當「會維護的資產」，不是寫一次就丟。
小而準 > 大而髒：幾十個被仔細審過的案例，常比幾千個自動生成、沒人看過的案例更能抓到退步。

LLM-as-Judge 的限制：好用，但別盡信¶

用一個強模型當「評審」去打分，是現在最普及的自動評估法——便宜、可擴展、和人類偏好有一定相關。但它有系統性偏誤，且這些偏誤無法靠提示完全消除：〔論文〕

偏誤	現象	量級（文獻觀察）
Position bias（位置偏誤）	偏好排在前面的答案	對「第一個」的偏好可高達 ~75%〔論文〕
Verbosity bias（冗長偏誤）	偏好較長、看起來豐富的回答	系統性偏向長答案〔論文〕
Self-enhancement / self-preference（自我偏好）	給「自己或同源模型的輸出」打更高分	約 10–25% 的自我偏好；強模型上更明顯〔論文〕

緩解（只能部分緩解，不能根除）：〔論文〕〔實務〕 - 隨機化答案順序、跑兩個方向再平均 → 壓 position bias。 - 在評分準則裡明確「不因長度加分」、必要時懲罰冗長 → 壓 verbosity bias。 - 用與受測模型不同來源的模型當評審 → 壓 self-preference bias（這條最重要，別讓模型評自己）。 - 給結構化評分準則（rubric）+ 要求逐項理由，比讓它直接吐一個分數穩。

〔實務〕底線心法：LLM-as-judge 是篩選與相對排序的好工具，不是絕對真值來源。高風險決策（上線與否、模型汰換）至少要有一層人工抽查；judge 的分數要定期拿真人標註做校準，否則你會在一個有偏的尺上持續最佳化。

一條最小可行的評估流水線〔實務〕¶

定義成功：先寫清楚「好」長什麼樣（rubric），再談指標。
建小而準的 golden set：從真實 log 取樣，含難例。
分層評：RAG 拆檢索/生成；agent 評軌跡；最終答案才上 judge。
judge 去偏：換源模型、隨機順序、rubric + 理由。
人工校準：定期用真人標註校 judge，抓漂移。
回歸把關：每次改動對 golden set 重跑，看有沒有退步。

延伸閱讀（本站）¶

RAG 完整指南：原理、架構與實作 — RAGAS 在整體 RAG 流程的位置
Agentic RAG（2026） — 自我修正檢索迴圈也需要評估
Agent Observability — 線上觀測與離線評估互補
Context Engineering：超越 Prompt Engineering