RAG 優化實戰：Query Rewriting 怎麼把分數從 77 拉到 88

上一篇診斷出 RAG 系統 60% 的品質問題來自檢索端，Generation Failure = 0。這篇記錄接下來怎麼做：評估三個優化方向、決定只做其中兩個、執行後分數從 77 拉到 88（+14.3%），Retrieval Failure 減少 60%。完整的「診斷 → 決策 → 執行 → 驗證」迴圈。

上一輪診斷結論：所有品質問題指向檢索端

上一輪品質診斷的結論很明確：

• Generation Failure = 0：LLM 回答能力不是瓶頸，只要給對資料就能答好
• Retrieval Failure = 5 題（33%）：搜尋到完全不相關的段落
• Coverage Failure = 4 題（27%）：找到部分相關段落但資訊不完整
• 所有品質問題都指向檢索端，改善 Retrieval 是唯一槓桿

問題清楚了，接下來是決定怎麼改。

三個優化方向：做 Query Rewriting 和 Top-K，不做 Reranker 和 Metadata Filtering

根據失敗模式，有三個明確的優化方向。但不是每個都該做。

Query Rewriting（查詢改寫）— 決定做

對應問題：5 題 Retrieval Failure 中，有 3 題的根因是「使用者問題的語言跟知識庫的語言有落差」。

使用者問「技術選型決策」，但知識庫裡寫的是「完全 Headless CMS 架構」— 語義相關但用詞完全不同。使用者問「Act 1 專案對齊目標職缺」，但 BM25 把「Act」匹配到了「CHIPS and Science Act」。

解法：在搜尋前加一層「翻譯」— 讓 LLM 把使用者問題改寫成 2-3 個版本，每個版本從不同角度描述同一個資訊需求。改寫後的版本分別搜尋，結果合併去重。等於用多個搜尋查詢去覆蓋同一個問題，大幅提升找到正確段落的機率。

預期效果高、實作成本低、風險小。做。

Top-K 從 5 增到 10 — 決定做；Reranker — 決定不做

對應問題：4 題 Coverage Failure 中，正確段落存在於知識庫但排名在 6-15 名之間。Top-K=5 把它們排除在外了。

增加 Top-K 到 10 是最直接的解法 — 讓更多段落有機會被納入。做。

Reranker（用 cross-encoder 對 top-20 做精排）理論上能進一步提升精準度，但我決定不做。原因是我只有 20 題測試集。如果同時調 Query Rewriting + Top-K + Reranker 三個變數，分數提升了我分不清是哪個的貢獻。20 題的樣本量太小，同時改太多東西容易 overfitting（過度擬合）— 你以為在優化系統，其實只是在 fitting 這 20 題。

控制變數比追求最高分更重要。

Metadata Filtering — 決定不做

對應問題：推理題的搜尋被文章內容干擾，如果能先限定搜尋範圍（只搜架構文件、不搜文章），精準度會提升。

不做的原因同上：20 題太少，加上 Metadata Filtering 需要先做意圖分類（判斷這題是「架構問題」還是「一般問題」），這本身就是另一個需要調試的子系統。在 PoC 階段，先把最大槓桿的優化做好，確認有效再加層。

Query Rewriting 的四種改寫策略，各針對不同的檢索失敗模式

每一題使用者問題，系統會產生三個改寫版本。加上原始問題，一共四個 queries 分別做混合搜尋（Hybrid Search），結果合併去重後取 top-10。

改寫策略有四種，針對不同的檢索失敗模式：

策略一：加入架構文件關鍵字。在改寫中加入「CLAUDE.md HANDOFF.md SKILL」。這等於告訴 BM25「去看架構文件」，解決了向量搜尋被文章內容吸引的問題。這是最有效的單一策略，直接貢獻了 +5 分。

策略二：展開專案內部術語。把「Act 1」改寫成「gwarket 專案初期」，避免 BM25 被同形異義詞干擾。

策略三：加入技術術語。把「自動上架流程」改寫時加入「Deploy Hook rebuild」，讓搜尋能匹配到具體的技術描述。

策略四：移除干擾性疑問詞。保留名詞和概念，移除「怎麼」「為什麼」「哪些」等對搜尋沒幫助的詞。

優化結果：8 題提升、0 題退步，Retrieval Failure 減少 60%

六方比較表

關鍵數字

8 題分數提升，0 題退步。最大改善是 Q6（技術選型），從 2 分拉到 4 分。Query Rewriting 加入「CLAUDE.md HANDOFF.md SKILL」關鍵字後，搜尋成功找到了 gwarket 的架構描述，而不是半導體收購分析。

Retrieval Precision 變化

Type B（跨文件問題）的嚴格 Precision 從 24% 提升到 36%（+12%），對應的回答品質從 3.20 分提升到 4.20 分（+1.00）。Precision 跟回答品質的正相關在 v2 中再次得到驗證。

RAG v2 vs Context Stuffing：剩下 5 分差距來自資料品質，不是演算法

RAG v2 拿 88 分，追平了 R1 Context Stuffing（14 檔的 88 分），距離 R2（64 檔的 93 分）只差 5 分。但 RAG v2 能處理 200 檔 / 462K tokens，是 R2 的 3.8 倍資料量。

剩下的 5 分差距集中在兩題：

Q8（2 分 vs R2 的 3 分）：「Act 1 對齊職缺能力」。BM25 仍然被「Act」干擾到晶片法案。而且知識庫裡可能根本沒有 PRD 文件 — 這不是演算法問題，是資料覆蓋問題。加入 PRD 文件就能解決。

Q13（3 分 vs R2 的 4 分）：「擴展內容策略的調整」。問題裡的「AI 科技產業分析」「企業數位轉型」語義太強，即使改寫後仍然把搜尋拉向產業分析文章。這需要更進階的技術（HyDE 或 intent-based routing）才能解決。

結論：剩下的差距主要是資料品質問題（缺 PRD）和極端的語義污染，不是 RAG pipeline 本身的能力問題。

我的觀點

優化 Retrieval 的投資報酬率最高

Generation Failure = 0 這個發現的實際意義是：不要花時間換更強的 LLM。RAG 系統的品質瓶頸在檢索端，把預算和精力花在 Query Rewriting、搜尋策略調優、知識庫品質上，效果遠比升級 LLM 好。

這次的數據直接證明了這點：只改了 Query Rewriting + Top-K，不動 LLM、不動 Embedding Model、不動向量資料庫，分數就從 77 拉到 88。

「決定不做什麼」跟「決定做什麼」一樣重要

Reranker 理論上有用，Metadata Filtering 理論上也有用。但在 20 題的測試集上同時做三個優化，你分不清效果來自哪裡。更糟的是，你可能 overfitting 這 20 題 — 系統在這 20 題上表現很好，但換一批問題就不行了。

在 PoC 階段，每次只改一到兩個變數，用數據驗證效果，再決定下一步改什麼。這比一口氣全上然後不知道為什麼有效（或為什麼沒效）要好得多。

20 題樣本的局限性

必須誠實說：20 題的測試集太小。+11 分的改善是顯著的，但如果換一批 20 題，改善幅度可能不同。如果是生產環境，至少需要 100-200 題的測試集，涵蓋更多樣的問題類型和邊界情況。

但 20 題夠用來做 PoC 階段的方向驗證 — 它告訴你 Query Rewriting 值得投資、Retrieval 是對的優化方向、Generation 不需要動。這些方向性的結論，在更大的測試集上大概率不會翻轉。

常見問題 FAQ

Query Rewriting 增加了多少延遲和成本？

每題從 1 次搜尋變成 4 次（原始 + 3 個改寫版本），搜尋量增加 4 倍。但在 1,880 chunks 的規模下，單次搜尋本身只需要毫秒級，4 倍也感覺不到。改寫本身用的是規則式（不是呼叫 LLM），所以不增加 API 成本。如果改用 LLM 改寫，每題會多一次 LLM 呼叫的延遲和費用，需要評估 ROI。

為什麼 Type A 能拿滿分但 Type C 只有 3.80？

Type A 是「答案在某一份文件裡」，搜尋只需要找到那一個段落就夠了。Type C 是推理題，需要理解系統全貌後做推理，但搜尋只能給你 10 個片段 — 等於叫你只看 10 張拼圖碎片就猜出整幅畫。這是 chunk-level retrieval 的本質限制，不是 Query Rewriting 能解決的。需要 document-level retrieval 或更大的 context window。

如果繼續優化，理論上限是多少？

加入 PRD 文件（解決 Q8）預期 +2 分，加上 HyDE 或 intent-based routing（解決 Q13）預期 +1-2 分，再加 Reranker 預期 +1-2 分。理論上限大約 92-95 分，有機會超越 Context Stuffing 的 93 分 — 而且能處理 3.8 倍的資料量。