https://yennj12.js.org/yennj12_blog_V4/tags/evaluation/Recent content in Evaluation on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part1-zh/Mon, 18 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part1-zh/前言：「準確率 90%」到底代表什麼？ 當有人告訴你「我們的 AI 模型準確率達到 90%」，你的第一個反應應該是問：「在什麼任務上？用什麼指標衡量的？」 因為一個疾病篩查模型，如果只是把所有病人都判斷為「健康」，在某些罕見疾病的數據集上，準確率照樣可以高達 99%。這樣的數字毫無意義，甚至危險。 準確率（Accuracy） 只是眾多評估指標中最基礎的一個，而且它往往不是最重要的那個。 本系列文章分三篇，帶你系統性地了解如何客觀衡量 AI 的準確度： 第一篇（本文）：分類與回歸任務的基礎評估指標 第二篇：大型語言模型（LLM）的評估方法 第三篇：RAG 檢索增強生成系統的可靠性評估 一、分類任務指標（Classification Metrics） 分類任務就是讓模型把輸入歸到某個類別，例如： 這封郵件是不是垃圾郵件？ 這張 X 光片是否顯示腫瘤？ 這則評論是正面還是負面的？ 混淆矩陣（Confusion Matrix） 一切的起點是混淆矩陣。它把模型的預測結果與真實標籤交叉對照，分成四個格子： 預測為正 預測為負 實際為正 TP（真陽性） FN（假陰性） 實際為負 FP（假陽性） TN（真陰性） TP（True Positive）：模型說「是」，實際也是「是」。✅ TN（True Negative）：模型說「否」，實際也是「否」。✅ FP（False Positive）：模型說「是」，但實際是「否」。❌（誤報） FN（False Negative）：模型說「否」，但實際是「是」。❌（漏報） 最基礎的準確率定義就是： $$\text{Accuracy} = \frac{TP + TN}{TP + TN + FP + FN}$$ 但當數據嚴重不平衡時（例如只有 1% 的郵件是垃圾郵件），全部預測為「非垃圾」就能拿到 99% 的準確率，模型根本沒在做事。 精確率（Precision）：我說的「是」有多可信？ $$\text{Precision} = \frac{TP}{TP + FP}$$ 精確率衡量的是：模型預測為正類的結果中，有多少是真的正類。 適用場景：當誤報（FP）代價很高時。 例如垃圾郵件過濾——如果系統把重要的客戶合約誤判為垃圾郵件，損失就很大。此時我們希望「被標記為垃圾的郵件」要盡量都是真的垃圾。https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part2-zh/Mon, 18 May 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part2-zh/前言：文字回答沒有「標準答案」 在第一篇文章中，我們討論了分類與回歸任務的評估——這些任務都有明確的真值（ground truth）可以比對。 但大型語言模型（LLM）面對的是一個根本不同的問題： 「請幫我摘要這篇報告。」 這個問題沒有唯一的正確答案。一個好的摘要可以有很多種寫法，每種都合理。那我們怎麼知道模型給出的摘要是「好」還是「差」的？ 這正是 LLM 評估最困難的地方，也是這個領域近幾年最活躍的研究方向之一。 本文將介紹四種主要的評估方法： 字面重疊指標：BLEU、ROUGE 困惑度：Perplexity 語意相似度：BERTScore 以 AI 評估 AI：LLM-as-a-Judge 一、字面重疊指標：BLEU 與 ROUGE 這是最早用於評估文字生成品質的方法，核心思路是：把 AI 的輸出與人類寫的「參考答案」做字詞重疊比較。 BLEU（Bilingual Evaluation Understudy） BLEU 最早設計用於機器翻譯評估，衡量模型輸出的 n-gram（連續 n 個字的片段）有多大比例出現在參考答案中。 計算邏輯（簡化版）： 模型輸出：The cat is sitting on the mat. 參考答案：The cat sat on the mat. 1-gram 重疊：The, cat, on, the, mat → 5/7 ≈ 71% 2-gram 重疊：The cat, on the, the mat → 3/6 = 50% BLEU 分數是多個 n-gram precision 的幾何平均，加上一個「簡短懲罰」（防止模型生成很短但精確率高的回答）。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part3-ml-fundamentals-zh/Sat, 30 May 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part3-ml-fundamentals-zh/有人覺得 FDE 只需要會包 API。 這個判斷在面試中會死得很難看。 基礎不紮實，一旦系統出問題，你沒有能力診斷。 閱讀建議： 這篇是 ML 基礎概要。想要更完整的深度版本，參考 第八篇（ML 完整版） 和 第九篇（LLM 核心）。 面試情境 面試官：「解釋一下 Transformer 的 Self-Attention 機制。然後告訴我：Fine-tuning 和 RAG 在你的客戶場景下你怎麼選？如果 Fine-tuning 出現 Overfitting，你怎麼偵測？」 ML 基礎題通常是「過濾用的」——答不出來直接扣分，答得好不會讓你脫穎而出。但這些概念在實際工作中真的有用。 一、Transformer 架構：面試要說清楚的程度 Self-Attention 的核心機制 傳統 RNN 的問題：句子越長，開頭的資訊到句尾就已經被稀釋了，遠距離依賴很難學。 Self-Attention 的解法：每個 token 直接和所有其他 token 計算相關性，不管距離。 句子：「這家公司的 CEO 昨天宣布了一項重大決策」 Self-Attention 讓「決策」直接「看到」「CEO」， 不需要一步步從前面傳遞資訊。 數學直觀（面試可能問到 Q/K/V 的意思）： Q（Query）：這個 token 在「問」什麼資訊？ K（Key）： 其他 token「能提供」什麼資訊？ V（Value）：實際要「傳遞」的內容是什麼？ 計算流程： Q × Kᵀ（相關性分數）→ Softmax（變成機率分布）→ × V（加權求和） 不需要手推公式，但要知道： └── √d_k 是縮放因子，避免點積值過大導致梯度消失 Positional Encoding：為什麼要加位置資訊 Self-Attention 本身沒有位置概念。https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part3-zh/Mon, 18 May 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part3-zh/前言：RAG 帶來了新的評估挑戰 在第一篇和第二篇中，我們分別探討了傳統機器學習任務與 LLM 的評估方法。 現在，許多企業級 AI 應用走向了 RAG（Retrieval-Augmented Generation）架構： 用戶問題 ↓ [檢索器] → 從知識庫取出相關文件段落（Context） ↓ [LLM] → 根據 Context 生成回答 ↓ 最終答案 RAG 的評估比純 LLM 更複雜，因為它有兩個可能出錯的環節： 檢索器：有沒有找到正確的資料？ 生成器（LLM）：有沒有忠實地根據資料回答，而不是憑空幻想？ 本文將系統性地介紹 RAG 的評估框架，包括核心指標、評估工具（RAGAS），以及企業實際落地時的最佳實踐。 一、RAG 評估的三個核心維度 評估一個 RAG 系統，需要從三個維度同時切入： ┌─────────────────┐ │ 用戶問題 (Q) │ └────────┬────────┘ │ ┌──────────────▼──────────────┐ │ 檢索器 │ └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ 檢索到的 Context (C) │ ← 評估維度 1：檢索品質 └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ LLM 生成 │ └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ 最終答案 (A) │ ← 評估維度 2：生成品質 └─────────────────────────────┘ │ ← 評估維度 3：端到端品質（Q→A） 二、核心指標詳解 2.https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/Wed, 20 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/前言 你的 RAG 系統「感覺」不錯，但你能量化它有多好嗎？ 這是生產環境中最常見的盲區：工程師花大量時間優化 Chunking、調整 Reranker，卻沒有客觀的指標來驗證改動是否真的有效。 這篇是系列的最後一篇，涵蓋三個主題： RAG 評估（RAGAS）：如何量化 RAG 品質 GraphRAG：當向量搜尋不夠用時的替代方案 Agentic RAG：RAG + Agent，讓 AI 自己決定如何搜尋 Part 1：RAG 評估——RAGAS 框架 為什麼評估很難？ RAG 的輸出是自然語言，沒有標準答案可以直接比對。 「這個答案好不好」，需要從多個維度判斷。 RAGAS 的四個核心指標 RAGAS（RAG Assessment） 是目前最流行的 RAG 評估框架，定義了四個指標： 1. Faithfulness（忠實度） 答案是否只根據 context，沒有幻覺？ 計算方式： Step 1: 把答案分解成一組陳述句（claims） Step 2: 對每個陳述，判斷 context 是否支持它 Step 3: Faithfulness = 有 context 支持的陳述數 / 總陳述數 理想值：接近 1.0 2. Answer Relevancy（答案相關性） 答案是否真的回答了問題？ 計算方式： Step 1: 讓 LLM 根據答案生成 N 個「可能的問題」 Step 2: 計算這些問題與原始問題的向量相似度 Step 3: Answer Relevancy = 平均相似度 理想值：接近 1.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part6-rag-eval-zh/Sun, 31 May 2026 09:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part6-rag-eval-zh/RAG 跑起來很容易。 讓它在生產環境穩定運行、能量化效果、還要控制成本——這才是難的。 面試官想知道你有沒有這層意識。 面試情境 面試官：「你的 RAG 系統上線後，客戶反映回答品質下降了。你怎麼診斷問題在 Retrieval 還是 Generation？你用什麼指標量化 RAG 的品質？如果成本超出預算，你怎麼優化？」 這是 FDE 最貼近生產現實的考題——不是設計新系統，而是診斷一個已上線系統的問題。 一、檢索失敗：你的 RAG 為什麼沒找到正確答案 這是 RAG 系統最常見的實際問題，也是面試官最愛問的： 「你的 RAG 系統回答品質不好，你怎麼 debug？」 檢索失敗的五大原因 1. Query 和 Document 的語意空間不對齊 用戶問的方式和文件寫的方式不同。 用戶問：「這個功能怎麼用？」 文件寫的是：「操作說明 3.2.1 節」 向量搜尋找不到，因為語意距離太遠。 修復方式： HyDE（Hypothetical Document Embeddings）：先讓 LLM 根據 query 生成一個假設答案，用假設答案的 embedding 去搜尋，而不是 query 本身 Query Rewriting：讓 LLM 把用戶的問題改寫成更像文件的表述 Query Expansion：生成多個 query 變體，分別搜尋後合併結果 2. Chunk 切壞了 答案跨越了 chunk 邊界。 修復：調整 chunk overlap，或改用 Parent-Child chunking。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part12-agent-evaluation-zh/Wed, 03 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part12-agent-evaluation-zh/你怎麼知道 Agent 可以上線？ 直覺不算，「感覺還不錯」不算。 FDE 的工作是把感覺轉成數字，把數字轉成信心——讓客戶的工程團隊能基於證據做決定。 一、核心問題：「夠好」的標準是什麼 Agent 評估的難點不是「怎麼算分」，而是「對誰問什麼問題，要達到什麼分才算夠好」。 三個不同維度的「夠好」： 評估的三個維度（缺一不可） ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │ 效能（Performance）│ │ 品質（Quality） │ │ 業務（Business） │ │ │ │ │ │ │ │ 快不快？ │ │ 對不對？ │ │ 有沒有用？ │ │ 貴不貴？ │ │ 準不準？ │ │ 用戶滿不滿意？ │ │ │ │ │ │ │ │ tokens/sec │ │ Faithfulness │ │ Task completion │ │ p95 latency │ │ Relevance │ │ User retention │ │ cost/request │ │ Groundedness │ │ Escalation rate │ └───────────────────┘ └───────────────────┘ └───────────────────┘ ↑ ↑ ↑ 系統層關心 工程師關心 客戶關心 只看品質、不看效能：上線後延遲爆炸。https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-19-llm-judge-bias-mitigation-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-19-llm-judge-bias-mitigation-zh/核心定義：LLM-as-Judge 是用一個強大的語言模型對另一個語言模型的輸出進行自動評分，透過結構化 Prompt、分層抽樣與偏見消除技術，以 1% 的人力成本達到 80% 的人工評估一致性，是大規模 AI 產品品質監控的基礎設施。 一、為什麼面試官問這個 面試官真正在測試的不是「你知道 LLM-as-Judge 這個詞」，而是三件事： 你是否理解評估的統計性質：知道抽樣比例、信賴區間、漂移偵測背後的數學，而不只是說「隨機抽樣評估一下」。能說出「50K 樣本、95% CI、±14% 誤差範圍」的候選人，遠比說「我們抽 5%」的候選人有說服力。 你是否能辨識並主動消除偏見：弱候選人只說「讓 LLM 評分」；強候選人說出自增強偏見、位置偏見、冗長偏見、奉承偏見四類具體問題以及各自的 mitigation 技術，並知道每種技術的代價和侷限。 你是否懂成本工程：能給出具體數字—1M 日查詢、5% 抽樣、每次 $0.002，得出 $100/day vs $2,000/day 的差距，並說明如何用分層設計讓高風險租戶獲得更高覆蓋率。 弱答案：「我們讓 GPT-4 評分，看分數有沒有下降。」這個答案暴露了三個問題：沒有偏見意識、沒有成本意識、沒有統計有效性意識。 強答案：「我們對 5% 的流量做按 intent_class × tenant 的分層抽樣，用與被評估模型不同家族的模型作為裁判，強制 CoT 先推理再評分，pairwise 比較做雙向排列取一致結果，設 7 日滾動均值 ±2σ 漂移告警接 PagerDuty。1M 日查詢成本 $100/日，裁判與人工的 Spearman ρ = 0.84。」 二、核心原理與技術深度 2.1 為什麼人工評估無法規模化 人工評估的隱藏成本遠超表面工資。一個典型的企業 AI 產品日查詢量達 1M： 評估方式 1M 查詢/日 成本 結果延遲 實際覆蓋率 全量人工標注（$0.05/條） ~$50,000/日 24–72 小時 理論 100%，實際 <0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part19-multiagent-eval-tracing-zh/Thu, 04 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part19-multiagent-eval-tracing-zh/評估 RAG 系統：一個問題進去，一個答案出來，量化兩者的關係。 評估 Multi-Agent 系統：一個問題進去，4 個 Agent 跑了 10 次工具，最後出來一個答案。 中間任何一個環節出了問題，你都看不到——除非你事先設計好追蹤架構。 面試情境 面試官： 「這是一個由 4 個 Agent 組成、包含 10 次 Tool-calling 的複雜工作流。客戶說最終答案正確率很低。你如何建立統計評估管線？如何進行 Granular Tracing 抓出是哪個 Agent 或哪次 Tool-calling 出問題？」 一、核心問題：Multi-Agent 的評估為什麼比 RAG 難一個量級 RAG 評估的輸入/輸出模型： Input: Query ↓ [Single Pipeline] ↓ Output: Answer 評估點：3 個指標（Context Relevance, Faithfulness, Answer Relevance） 定位問題：要麼是 Retrieval，要麼是 Generation Multi-Agent 評估的現實： Input: User Request ↓ Router Agent → 分派 ├── Agent A → Tool 1 → Tool 2 → Output A ├── Agent B → Tool 3 → Tool 4 → Tool 5 → Output B └── Agent C → Tool 6 → Output C ↓ Synthesis Agent → 整合 A + B + C → Final Answer 評估點： ├── Router 的分派決策對不對？（Routing Accuracy） ├── Agent A 的工具呼叫成功率？（Tool Success Rate） ├── Agent B 是不是最慢的瓶頸？（Latency by Agent） ├── Agent C 的輸出品質？（Output Quality by Agent） └── Synthesis Agent 整合時有沒有幻覺？（Faithfulness） 問題可能在 10 個地方的任何一個 二、可觀測性架構：三層追蹤設計 ┌──────────────────────────────────────────────────────────────┐ │ User Request 進入 │ │ 分配唯一的 trace_id（e.https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-20-rag-triad-metrics-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-20-rag-triad-metrics-zh/RAG 系統沒有「準確率」這個單一指標——你需要三把尺同時量：檢索對了嗎？答案有根據嗎？答案回答了問題嗎？少量其中任何一把，幻覺或廢話就悄悄進入生產。 一、為什麼面試官問這個 面試官問 RAG 評估指標，真正在測試的是以下三件事： 你能否把「LLM 答得好不好」拆解成可量化的子問題。 弱答案：「我們用 ROUGE 或 BLEU 評估。」——這是序列生成指標，對 RAG 完全不適用，暴露了對 RAG 工作流程的根本誤解。 你是否理解幻覺的成因與偵測手段。 弱答案：「幻覺是 LLM 的問題，換模型就好。」——強答案會指出 Groundedness（忠實度）是反幻覺的核心指標，並說明如何用 NLI 模型逐句驗證。 你能否把評估指標接進可觀測性管道（OTel → Prometheus → Grafana），讓它在生產中持續追蹤而非一次性評測。 弱答案只談離線評測；強答案談 span attributes、rolling average dashboard、以及 alert threshold。 二、核心原理與技術深度 RAG 三角指標的數學基礎 RAG Triad 由 TruEra（現為 Snowflake 旗下）提出，對應 RAG pipeline 的三個環節： 使用者查詢 (Query) │ ▼ ┌──────────────────────┐ │ Retriever │ ← 指標 1：Context Relevance │ 向量搜尋 / BM25 │ retrieved chunks 與 query 的相似度 └──────────┬───────────┘ │ retrieved context ▼ ┌──────────────────────┐ │ LLM Generator │ ← 指標 2：Groundedness（忠實度） │ Gemini / GPT-4o │ answer 中每個宣稱是否有 context 支撐 └──────────┬───────────┘ │ generated answer ▼ ┌──────────────────────┐ │ Answer Evaluation │ ← 指標 3：Answer Relevance │ Embed / LLM Judge │ answer 是否真正回答了 query └──────────────────────┘ 指標 1：Context Relevance（上下文相關度） 定義：檢索到的 chunks 中，真正與查詢相關的比例。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part2-rag-evals-zh/Sun, 21 Jun 2026 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part2-rag-evals-zh/大多數工程師遇到 LLM 幻覺，第一反應是把 Prompt 寫得更長、更詳細。 正確答案是：建立 RAG 管線讓模型說「我不知道」，而非瞎猜。 大多數團隊上線後才發現回答品質不穩，因為沒有評估管線。 正確答案是：在 CI/CD 中門控 Faithfulness ≥ 0.80，讓壞版本無法部署。 面試情境 你們公司的法律文件問答系統上線三個月，客服每週回報大約 15% 的回答「聽起來合理但內容有誤」。CTO 要你在四週內把幻覺率降到 5% 以下，且 P95 延遲不能超過 2 秒。請說明你會怎麼診斷現況、選擇改進方向，以及如何證明改善確實發生了。 一、核心問題：LLM 幻覺與知識截止日期的工程解法 LLM 有兩個先天限制，工程師必須正視： 幻覺（Hallucination） — 模型會以高信心度生成看起來合理但事實上錯誤的內容。根源在於訓練目標是「預測下一個 Token」，而非「陳述事實」。當問題超出訓練分布，模型不會說「我不確定」，而是繼續生成流暢但錯誤的文字。 知識截止日期（Knowledge Cutoff） — 模型訓練資料有時間邊界。2024 年底截止的模型不知道 2025 年的法規修訂、產品更新、或內部文件。無論 Prompt 寫得多好，模型都無法回答它從未見過的資訊。 RAG（Retrieval-Augmented Generation） 是主流工程解法：把外部知識庫的相關片段即時檢索出來，附加在 Prompt 中，讓模型「有所依據地回答」而非憑空捏造。 但 RAG 帶來新問題：檢索品質如何保證？回答是否忠實於檢索內容？這需要評估管線來量化和監控。 二、三個演進階段（POC / MVP / Scale） ╔══ Phase 1：POC / < 1K 文件 ══╗ 目標：兩週內驗證 RAG 在這個領域是否可行。 ┌─────────────────────────────────────────────────────┐ │ Phase 1 RAG 架構（POC） │ │ │ │ PDF / Markdown ──▶ 固定 512 Token Chunking │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Chroma / SQLite │ (本機) │ │ │ Dense Vector │ │ │ └────────┬─────────┘ │ │ │ Top-K ANN │ │ ▼ │ │ ┌──────────────────┐ │ │ │ LLM（API） │ │ │ │ GPT-4o / Claude │ │ │ └──────────────────┘ │ └─────────────────────────────────────────────────────┘ 項目 數值 文件量 < 1K docs 向量 DB Chroma（本機，免費） Embedding text-embedding-3-small（$0.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part36-eval-pipeline-zh/Fri, 05 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part36-eval-pipeline-zh/Eval Pipeline 和 Eval 的差別： Eval 是你跑一次、拿到一個分數。 Eval Pipeline 是每次系統改變，自動跑、自動比較、自動擋住退化。 法律合約系統漏掉一個風險條款的損失可能是千萬。 靠人記得去跑評估，不夠。 面試情境 面試官：「客戶是一家法律事務所，剛上線了一個合約審查 AI 系統。他們問：每次你們更新 Prompt 或換模型版本，我怎麼知道品質沒有退化？法務長說，如果 AI 漏掉一個風險條款，損失可能是千萬。請設計一個讓客戶可以信任的 Eval Pipeline。」 一、核心問題：為什麼需要 Pipeline Eval（一次性）的問題： 現在的品質：Faithfulness = 0.87 ← 你知道 下週改了 Prompt 之後：? ← 你不知道 三個月後換了模型版本之後：? ← 你更不知道 沒有 Pipeline： 需要有人記得每次改動後去跑評估 → 沒人記得 → 品質退化不被發現 → 客戶先發現 有 Pipeline： 每次 Prompt / 模型 / 資料 變更 → 自動觸發評估 → 分數低於閾值 → 自動擋住部署 → 品質退化在影響用戶之前被系統發現 Eval Pipeline 是把「品質管控」從人工流程變成自動化系統。 這是 POC 到生產的核心差距之一。 二、Eval Pipeline 的四層架構 ┌───────────────────────────────────────────────────────────────────┐ │ Layer 1：黃金資料集（Ground Truth） │ │ 「正確答案是什麼」的標準，由領域專家建立 │ └──────────────────────────────┬────────────────────────────────────┘ │ 每次評估都用同一份資料集 ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 2：離線評估（Offline Eval） │ │ 每次部署前，對黃金資料集跑 RAGAS + Safety，產出指標報告 │ └──────────────────────────────┬────────────────────────────────────┘ │ 評估結果 vs 上一版 baseline ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 3：CI/CD 品質閘門（Quality Gate） │ │ 分數低於閾值 → 自動阻止部署；通過 → 繼續 Canary 部署 │ └──────────────────────────────┬────────────────────────────────────┘ │ 部署到生產後持續監控 ▼ ┌───────────────────────────────────────────────────────────────────┐ │ Layer 4：線上評估（Online Eval） │ │ 生產流量的持續品質監控，偵測 Data Drift 和 Performance Drift │ └───────────────────────────────────────────────────────────────────┘ 三、Layer 1：黃金資料集的設計原則 黃金資料集的每一筆記錄： { "id": "Q042", "query": "這份合約的違約金條款是否符合台灣民法第 250 條？", "context": ["第 3 頁段落.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part50-llm-judge-evaluation-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part50-llm-judge-evaluation-zh/多數工程師的做法：每次模型更新後，手動抽幾十筆對話，憑感覺評估品質有沒有退步。 問題是，樣本量不足無法代表真實用戶分佈，而且人工評估無法在 CI/CD 流程中自動執行。 正確的做法：建立三層自動化評估管線，用統計學方法精準抽樣 5% 送 LLM 裁判， 其餘 95% 走免費傳統指標，並在 Sigma 2 漂移時自動觸發 PagerDuty 警報。 面試情境 你的團隊正在維護一個 B2B SaaS 平台上的 RAG Agent，每天處理約 50 萬筆客戶支援對話。 上週你們將底層模型從 Gemini 1.5 Pro 升級至 Gemini 2.0 Flash，同時調整了 System Prompt。 產品團隊要求你在 48 小時內確認新系統的回答品質沒有惡化，並建立一套長期可用的 自動化觀測機制。你有 Vertex AI 的使用權限，預算受限，你會怎麼設計這套系統？ 一、核心問題：為什麼 GenAI 的品質監控比傳統服務更難？ 傳統後端服務的品質監控相對直觀：HTTP 4xx/5xx 錯誤率、P99 延遲、資料庫查詢失敗數。 這些指標全都是客觀的、可計算的、接近零成本的。 GenAI 系統的品質卻天生是主觀的：一個回答是否「夠好」，取決於事實準確度、 語氣適切性、上下文相關性、甚至法律合規性。這帶來三個根本性挑戰： 挑戰一：評估本身就需要智慧 你無法用 if response == expected_answer 來評分自由文本。傳統 BLEU / ROUGE 指標 只能衡量字面重疊，無法判斷語意正確性。唯一可靠的裁判是另一個 LLM——但這就是 評估成本 ≥ 生產成本的陷阱：https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part3-evaluation-zh/Tue, 30 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part3-evaluation-zh/寫傳統程式,你有單元測試:斷言 add(2,3) == 5,綠燈就是對。 寫 LLM 應用,「正確答案」往往沒有唯一解——同一個問題有一百種好的回答方式。 那你怎麼測?怎麼知道改了 prompt 之後是變好還是變壞?這就是 LLM 評估要解的問題,也是 Langfuse 最核心的價值。 一、為什麼 LLM 評估這麼難 Part 1 說過,LLM 的「錯」是品質退化而非當機。這帶來一個根本困難:品質很難測。 傳統測試 LLM 評估 ─────────────── ─────────────── assert f(x) == 預期值 「這個回答好不好?」 ✅ 確定、二元、自動 ❓ 主觀、連續、難自動 困難來自三點: 沒有唯一正解:「解釋一下這份財報」可以有無數種好答案。 品質是多維的:正確性、忠實度(有沒有編造)、完整性、語氣、格式……每個維度都要分開看。 改一處動全身:調了 prompt 修好了 A 問題,可能默默弄壞了 B 問題——你需要回歸測試。 Langfuse 的評估體系,就是把這三個困難逐一拆解。核心是一個概念:Score(評分)。 二、Score:把「好不好」變成一個數字 Part 1 提過,Score 是 Langfuse 評估的基石。它把主觀品質,變成可記錄、可追蹤、可比較的值,附加在 trace 或 observation 上。 最直接的用法是用 SDK 寫入。比如收到使用者按了「👍 / 👎」: 1from langfuse import get_client 2langfuse = get_client() 3 4# 把使用者回饋寫成一個 score 5langfuse.https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part1-concepts-zh/Tue, 30 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part1-concepts-zh/傳統後端壞掉:噴 500、log 一條 stack trace、監控告警響——你馬上知道。 LLM 應用壞掉:回了一段「看起來很合理但其實是編的」答案,HTTP 200,沒有任何錯誤。 你的使用者知道它錯了,但你的系統不知道。這就是為什麼 LLM 需要一種全新的可觀測性。 一、傳統監控為什麼救不了 LLM 應用 先想一個問題:一個傳統 API 壞掉,你怎麼發現? 傳統後端 ───────────────────────────── 輸入 → 確定性邏輯 → 輸出 │ ├─ 壞了 → throw Exception → 500 → 告警響 └─ 對了 → 200 錯誤是二元的、確定的:不是對就是錯,壞了會噴例外。你的 APM(Datadog、Sentry)抓得到。 但 LLM 應用不是這樣: LLM 應用 ───────────────────────────── 輸入 → Prompt → LLM(機率性) → 輸出 │ ├─ 幻覺(編造事實) → HTTP 200 ✅ ├─ 答非所問 → HTTP 200 ✅ ├─ 語氣不對/拒答 → HTTP 200 ✅ └─ 完美回答 → HTTP 200 ✅ 所有情況都是 HTTP 200。 沒有例外、沒有 stack trace、沒有錯誤碼。LLM 的「錯」不是當機,而是輸出品質的退化——而品質是連續的、主觀的、機率性的。傳統監控的整套工具(看 error rate、看 5xx)在這裡完全失效。https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part3-observability-eval-zh/Tue, 30 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part3-observability-eval-zh/多數 RAG 專案上線後,優化全憑「感覺答案變好了」。 但你說不出 faithfulness 是 0.6 還是 0.9,也不知道上次調 alpha 是讓 nDCG 上升還是下降。 這篇講的就是把「感覺」換成「數字」:追蹤每一次 LLM 呼叫、持久化每一次評估、即時評每一個答案——讓優化變成可被驗證的循環。 一、為什麼可觀測性是 RAG 的最後一哩 第一篇解決切塊與檢索品質,第二篇補上 production 防線。但還缺一塊:你怎麼知道這些優化真的有效? RAG 的恐怖之處在於它「永遠會給出一個看起來合理的答案」。沒有量測,你根本分不清: 調了 hybrid_alpha,到底是變好還是變壞? 某個答案是基於檢索內容,還是 LLM 自己編的(hallucination)? 這次改動,整體 nDCG@k 的趨勢是上升還是下降? PR #4 補上三層可觀測性: ┌──────────────────────────────────────────────────────┐ │ 三層可觀測性 │ ├──────────────────────────────────────────────────────┤ │ 1. 即時聊天 每個回答附信心分數(faithfulness 等) │ │ 2. 評估工具 每次評估的彙總指標持久化,追蹤趨勢 │ │ 3. Langfuse 所有 LLM 呼叫被追蹤(延遲/token/成本) │ │ ── 設定才開,不設定零開銷 │ └──────────────────────────────────────────────────────┘ 二、Langfuse 追蹤:opt-in 且零開銷 設計原則:不設定 = 完全無感 可觀測性工具最怕的就是「為了觀測而拖慢主流程」。chatPDF 的 Langfuse 整合是完全 opt-in:沒設定環境變數時,它是一個 no-op,零開銷、零風險。