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 裡有幾個是 ✅。

Precision 越低，回答品質越差 — 數據佐證

Precision 跟回答品質高度相關。Type A 的 36% precision 對應 4.60 分，Type C 的 16% precision 對應 3.20 分。Precision 越低，回答品質越差。這不是巧合 — 它告訴你：改善檢索精準度，就能直接提升回答品質。

Type D 的數據也有意義。Precision 是 0%（知識庫裡本來就沒答案），但回答拿到 4.40 分（正確拒答）。這代表 LLM 在「判斷資訊不足」這件事上表現很好 — 即使拿到一堆不相關的 chunks，它還是能說「我不知道」。

60% 的品質問題來自檢索，Generation Failure 為零

排除 5 題 Type D（正確拒答是預期行為），剩下 15 題的失敗模式分類：

最重要的發現：Generation Failure = 0。

這代表 LLM 回答能力完全不是瓶頸。所有品質問題都來自檢索端 — 不是找到錯的東西（Retrieval Failure），就是找到的不夠完整（Coverage Failure）。60% 的品質問題都指向同一個方向：改善 Retrieval 是提升整體表現的唯一槓桿。

Hybrid Search 只在 40% 題目有互補效果

混合搜尋（Hybrid Search）結合向量搜尋和 BM25，預期是互補：向量搜尋處理語義、BM25 處理精確匹配。但實際數據顯示，互補不是每次都有效。

互補效果只在 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 的部署限制描述。

理論上限

我的觀點

這份診斷最有價值的不是具體的數字，而是診斷方法本身。

「逐題標記 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 相關性的初步判斷，再抽樣做人工覆核。但第一次一定要手動做，因為你需要親眼看到失敗案例才能建立對系統行為的直覺。