RAG 系統的 77 分怎麼來的？一次完整的 Retrieval 品質診斷
RAG 系統拿了 77 分，比 Context Stuffing 的 93 分低。但「低 16 分」不是結論，而是診斷的起點。逐題拆解 100 個 chunks 的檢索品質後發現：60% 的品質問題來自檢索端，LLM 回答能力完全不是瓶頸。這篇展示完整的診斷方法論和優化推導。
為什麼要做品質診斷？
RAG 系統上線後，大部分人的第一反應是看總分。77 分，比 Context Stuffing 低，結論似乎是「RAG 不夠好」。但這個結論毫無行動價值 — 你不知道該改什麼。
是 LLM 回答能力不行？是搜尋找到了錯的東西？還是找到了對的東西但不夠完整？每種原因對應完全不同的優化方向。看總分是管理者的本能，拆總分才是管理者該做的事。
診斷方法：逐題標記每個 Chunk 的相關性
20 題 × 每題 5 個 chunks = 100 個 chunks。逐一判斷每個 chunk 跟問題的相關性：
- ✅ 完全相關：這個 chunk 包含回答問題所需的核心資訊
- ⚠️ 部分相關：有一些有用的上下文，但不是核心答案
- ❌ 不相關：跟問題完全無關，是噪音
標記完之後，算 Retrieval Precision（精準度）：每題 5 個 chunks 裡有幾個是 ✅。
Retrieval Precision 數據
| 問題類型 | 嚴格 Precision（✅） | 寬鬆 Precision（✅+⚠️） | 平均回答分數 |
|---|---|---|---|
| Type A — 單一文件 | 36% | 76% | 4.60 |
| Type B — 跨文件 | 24% | 48% | 3.20 |
| Type C — 推理 | 16% | 28% | 3.20 |
| Type D — 知識庫外 | 0% | 16% | 4.40 |
關鍵發現：Precision 跟回答品質高度相關。Type A 的 36% precision 對應 4.60 分，Type C 的 16% precision 對應 3.20 分。Precision 越低，回答品質越差。這不是巧合 — 它告訴你：改善檢索精準度，就能直接提升回答品質。
另一個值得注意的是 Type D。Precision 是 0%（知識庫裡本來就沒答案），但回答拿到 4.40 分（正確拒答）。這代表 LLM 在「判斷資訊不足」這件事上表現很好 — 即使拿到一堆不相關的 chunks，它還是能說「我不知道」。
失敗模式分類：問題出在哪？
排除 5 題 Type D（正確拒答是預期行為），剩下 15 題的失敗模式分類：
| 失敗模式 | 題數 | 佔比 | 說明 |
|---|---|---|---|
| 無失敗 | 6 | 40% | 檢索和回答都良好 |
| Retrieval Failure | 5 | 33% | 檢索到的 chunks 完全不相關，LLM 無法回答 |
| Coverage Failure | 4 | 27% | 找到部分相關段落，但資訊不完整 |
| Generation Failure | 0 | 0% | 沒有。只要給對資料，LLM 回答品質都好 |
最重要的發現：Generation Failure = 0。
這代表 LLM 回答能力完全不是瓶頸。所有品質問題都來自檢索端 — 不是找到錯的東西（Retrieval Failure），就是找到的不夠完整（Coverage Failure）。60% 的品質問題都指向同一個方向：改善 Retrieval 是提升整體表現的唯一槓桿。
Hybrid Search 的真相
Hybrid Search（向量 + BM25）的預期是互補：向量搜尋處理語義、BM25 處理精確匹配。但實際數據告訴你，互補不是每次都有效。
| 情境 | 題數 | 說明 |
|---|---|---|
| 兩者互補（1+1 > 2） | 3 | 各自找到不同的正確段落，合併後更完整 |
| 向量更好，BM25 無貢獻 | 3 | BM25 找不到東西或找到噪音 |
| BM25 更好，但被向量稀釋 | 2 | BM25 有正確結果，但被向量的噪音在 RRF 合併時擠掉 |
| 兩者都差 | 4 | 都找不到正確段落，合併也救不回來 |
| 兩者都好 | 3 | 都找到有用段落 |
互補效果只在 40% 的題目（6/15）有效。另外有 2 題，BM25 明明找到了正確結果，卻在 RRF 合併時被向量搜尋的大量噪音稀釋到 Rank 4-5，影響了最終品質。Hybrid Search 不是萬靈丹 — 當兩邊都找不到正確段落時，合併只是把兩組錯誤結果混在一起。
BM25 的同形異義詞弱點
最典型的失敗案例：問題問的是「Act 1 專案對齊了目標職缺的哪些能力」，BM25 把「Act」匹配到了一篇關於美國晶片法案（CHIPS and Science Act）的文章。BM25 是 bag-of-words 模型，它無法區分「Act 1 = 專案第一階段」和「Act = 法案」。這種同形異義詞干擾是 BM25 最經典的失敗模式。
失敗案例深度診斷
Case 1：Q8 — 1 分（BM25 被「Act」誤導 + 向量被「目標」吸引）
問題問的是「Act 1 專案對齊了目標職缺的哪些能力」。向量搜尋把「對齊目標職缺的能力」匹配到了「AI 曼哈頓計畫的戰略目標」和「保持技術領導地位的能力」。BM25 把「Act」匹配到了「CHIPS and Science Act」。5 個 chunks 裡 4 個完全無關。
根因有三層：BM25 的同形異義詞干擾、向量搜尋被通用語義（「目標」「能力」）誤導、知識庫中可能根本不存在 Act 1 和職缺對齊的直接描述。即使把 Top-K 增加到 20，正確段落也不在任何排名中 — 因為問題本身包含的語義信號把搜尋方向帶偏了。
Case 2：Q6 — 2 分（正確段落存在但排在 10-15 名）
問題問的是「技術選型決策和理由」。知識庫裡有完全對應的段落（HANDOFF.md 的「完全 Headless CMS 架構」），但向量搜尋把它排到了 Rank 10-15。因為「技術選型決策」的語義被匹配到了「產業競爭格局的重大決策」（一篇半導體文章）和「選擇適合的專案管理工具」（一篇工具評比文章）— embedding model 捕捉到了「決策」「選擇」的通用語義，但忽略了「gwarket 的技術架構」這個限定條件。
這題的解法很明確：增加 Top-K 到 15 就能把正確段落撈進來。或者用 Query Rewriting 把「技術選型決策」改寫為「gwarket 網站用了什麼技術架構」，直接避開通用語義的干擾。
Case 3：Q13 — 3 分（語義污染）
問題是「如果要把內容策略從 AI 科技產業分析擴展到企業數位轉型，工具和流程需要做哪些調整？」。問題的核心是「工具和流程調整」，但問題裡 70% 的詞彙在描述「從什麼主題擴展到什麼主題」。結果就是搜尋引擎被「AI 科技產業分析」「企業數位轉型」這些描述性詞彙主導，去匹配了「包含這些主題的文章」（半導體分析、智慧製造、AI 週報），而不是「描述工具和流程的架構文件」。
向量 distance 的數據很有說服力：一篇高通英特爾收購分析文章的 distance 只有 0.2892（非常近），而真正需要的「來源清單和篩選規則」段落根本不在 top-20 裡。語義上「很像」，邏輯上完全不相關。
從失敗模式推導優化方向
每個優化方向都對應一個具體的失敗模式：
優化一：Query Rewriting（預期 +5-8 分）
對應問題：5 題 Retrieval Failure 中的 3 題。
方法：在搜尋前，先讓 LLM 把使用者問題改寫為更具體的搜尋查詢 — 把抽象問題拆成具體子問題、把專案內部術語展開（「Act 1」改寫成「第一階段專案」）、移除干擾性的描述詞彙。Q6 改寫為「gwarket 網站的技術架構是什麼」幾乎確定能找到正確段落。Q13 改寫為「網路資訊專家的來源清單和篩選規則」也是同理。
優化二：增加 Top-K 到 10 + Reranker（預期 +5-8 分）
對應問題：4 題 Coverage Failure。
方法：初始檢索已經取 top-20，但最終只送 top-5 進 LLM。把最終送入的數量增加到 10，讓更多段落有機會被包含。再加上 cross-encoder reranker 對 top-20 做精排 — reranker 看的是 query-document pair 而非獨立的 embedding，精度更高，能把「語義相似但邏輯無關」的段落降權。
優化三：Metadata Filtering（預期 +2-3 分）
對應問題：Type C 推理題的檢索偏離。
方法：先對問題做意圖分類 — 如果是「架構問題」，限定搜尋範圍為 CLAUDE.md、HANDOFF.md、SKILL.md 等架構文件。這樣就不會被知識庫裡的文章內容干擾。Q11 問 Newsletter 訂閱功能，限定搜架構文件就能直接找到 code-conventions SKILL 的部署限制描述。
理論上限
| 狀態 | 分數 | 說明 |
|---|---|---|
| 當前 RAG | 77 | v1 baseline |
| + Query Rewriting | 82-85 | 解決 Retrieval Failure |
| + Top-K 10 + Reranker | 87-93 | 解決 Coverage Failure |
| + Metadata Filtering | 90-97 | 接近或超越 Context Stuffing 的 93 分 |
我的觀點
這份診斷最有價值的不是具體的數字，而是診斷方法本身。
「逐題標記 chunk 相關性 → 算 precision → 分類失敗模式 → 從失敗模式推導優化方向」— 這套流程可以用在任何 RAG 系統上。你不需要猜「是不是 LLM 不夠好」或「是不是 embedding model 要換」，數據會告訴你問題出在哪。
這次的數據非常清楚：Generation Failure = 0。所有品質問題都來自 Retrieval。這意味著換更強的 LLM 不會有幫助，但改善搜尋策略會直接轉化為回答品質的提升。對管理者來說，這就是資源配置的依據 — 把預算花在 Retrieval 優化上，不是 LLM 升級上。
最後一個洞察：Hybrid Search 不是「加了就變好」。它在 40% 的題目上有互補效果，但在另外 13% 的題目上反而讓 BM25 的好結果被向量噪音稀釋。技術方案的價值不是看最佳情況，而是看平均情況和最差情況。
常見問題 FAQ
為什麼 Generation Failure 是 0？是不是 LLM 太強了？
不完全是。Claude Opus 4.6 的確是很強的模型，但更重要的原因是：這次的測試題目沒有設計專門測試 Generation 能力的場景（例如需要複雜邏輯推理或數學計算的問題）。在知識庫問答的場景下，LLM 的主要任務是「根據給定的段落組織回答」，這對大型語言模型來說是相對簡單的任務。如果換成更弱的模型，Generation Failure 可能會出現。
Retrieval Precision 20% 是不是太低了？
嚴格 Precision 20% 看起來很低，但要考慮兩個因素。第一，Type D 的 5 題本來就不該有正確 chunk，拉低了整體平均。第二，寬鬆 Precision（包含部分相關的 ⚠️ chunks）是 52%，代表一半以上的 chunks 至少有一些幫助。真正需要改善的是 Type B 和 Type C 的嚴格 Precision（24% 和 16%），這是優化的重點方向。
診斷方法需要人工標記每個 chunk 嗎？不是很花時間？
20 題 × 5 chunks = 100 個標記，實際做大約需要 1-2 小時。對於一個系統上線後的第一次品質診斷，這個投入是值得的。之後可以建立自動化的評估機制 — 用 LLM 做 chunk 相關性的初步判斷，再抽樣做人工覆核。但第一次一定要手動做，因為你需要親眼看到失敗案例才能建立對系統行為的直覺。