https://yennj12.js.org/yennj12_blog_V4/tags/hallucination/Recent content in Hallucination on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 04 Jun 2026 18:00:00 +0800https://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/fde-interview-guide-part25-self-reflection-loop-zh/Thu, 04 Jun 2026 18:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part25-self-reflection-loop-zh/LLM 的幻覺問題不會被「更好的 Prompt」完全消除。 更實際的工程思路是：允許 LLM 犯第一次錯， 但設計一個系統讓它能自己發現錯誤、自己修正。 問題是：你怎麼確保「自我修正」不會無限進行下去？ 面試情境 面試官： 「在法務合約問答中，Agent 呼叫外部工具，但工具返回的 JSON 數據包含矛盾的條款。LLM 第一次生成時沒有注意到，產生了嚴重幻覺。你如何設計一個 Self-Reflection 架構，讓 Agent 在輸出最終答案前能自己檢查並校正？如何防止反思機制陷入死循環？」 一、核心問題：為什麼需要 Self-Reflection 沒有 Self-Reflection 的問題： Tool 回傳矛盾資料： 第 3 頁：「違約金為 500 萬台幣」 第 7 頁：「違約金為 50 萬台幣（與前款衝突）」 LLM 第一次生成： 「根據合約，違約金為 50 萬台幣。」（只看了第 7 頁，忽略矛盾） 結果： └── 法務顧問基於錯誤資訊給建議 └── 客戶簽了有利於對方的合約 └── FDE 被客戶投訴 如果有 Self-Reflection： 第一次生成後，由「審查者」指出： 「你的答案說 50 萬，但第 3 頁寫的是 500 萬，兩者矛盾。請重新分析。」 第二次生成： 「合約中關於違約金存在矛盾條款：第 3 頁寫 500 萬，第 7 頁寫 50 萬。 建議客戶在簽約前要求對方澄清哪一條款有效。」 ← 這才是正確的專業回答 二、Reflexion Pattern：設計原理 Reflexion 的三個核心洞察： 洞察 1：同一個 LLM 作為生成者和評估者 同樣的 Gemini Pro，給它不同的角色（System Prompt）， 它能同時做好「生成答案」和「找出答案的問題」 洞察 2：評估者的視角和生成者不同 生成者的 System Prompt：「你是一個法務助理，根據合約回答問題」 評估者的 System Prompt：「你是一個嚴格的法務審查員，專門找答案的問題」 不同的視角 → 更容易發現問題 洞察 3：錯誤原因要結構化，不能只說「有問題」 ❌ 「這個答案有問題，請重試」 ✅ 「第 3 條和第 7 條數字矛盾（500 萬 vs 50 萬），答案沒有提及這個矛盾」 結構化的錯誤原因 → 生成者能有針對性地修正 三、Generator-Evaluator 架構設計 ┌──────────────────────────────────────────────────────────────┐ │ 輸入 │ │ User Query + Tool Results（可能含矛盾資料） │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Generator Node（生成節點） │ │ │ │ System Prompt：「你是一個專業的法務助理。 │ │ 根據提供的合約條款回答問題。 │ │ 如果有矛盾的條款，必須明確指出並說明不確定性。」 │ │ │ │ Input： │ │ ├── User Query │ │ ├── Contract Context（Tool 回傳的原始資料） │ │ └── [如果是重試] Evaluator 的錯誤原因（feedback） │ │ │ │ Output：Draft Answer（初稿） │ └──────────────────────────┬───────────────────────────────────┘ │ Draft Answer ▼ ┌──────────────────────────────────────────────────────────────┐ │ Evaluator Node（評估節點） │ │ │ │ System Prompt：「你是一個嚴格的法務品質審查員。 │ │ 你的任務是找出答案的問題，而不是給出正確答案。 │ │ 必須以結構化 JSON 格式輸出評估結果。」 │ │ │ │ Input： │ │ ├── User Query │ │ ├── Original Context（原始合約資料） │ │ └── Draft Answer（等待審查的答案） │ │ │ │ Output： │ │ { │ │ "has_error": true/false, │ │ "error_type": "contradiction/hallucination/incomplete", │ │ "error_detail": "第 3 頁寫 500 萬，第 7 頁寫 50 萬.