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 — 決定做
對應問題：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」，讓搜尋能匹配到具體的技術描述。
策略四：移除干擾性疑問詞。保留名詞和概念，移除「怎麼」「為什麼」「哪些」等對搜尋沒幫助的詞。
優化結果
六方比較表
| 方法 | 總分 | Type A 單一文件 | Type B 跨文件 | Type C 推理 | Type D 拒答 | 能處理規模 |
|---|---|---|---|---|---|---|
| R1：Context Stuffing 14 檔 | 88 | 4.80 | 3.80 | 4.00 | 5.00 | 14 檔 / ~25K tok |
| R2：Context Stuffing 64 檔 | 93 | 4.80 | 4.60 | 4.40 | 4.80 | 64 檔 / ~121K tok |
| B：關鍵字搜尋 64 檔 | 59 | 3.80 | 1.80 | 2.40 | 3.80 | 64 檔 / top-5 |
| RAG v1：Hybrid Top-5 | 77 | 4.60 | 3.20 | 3.20 | 4.40 | 200 檔 / ~462K tok |
| RAG v2：Rewrite + Top-10 | 88 | 5.00 | 4.20 | 3.80 | 4.60 | 200 檔 / ~462K tok |
關鍵數字
| 指標 | v1 | v2 | 改善 |
|---|---|---|---|
| 總分 | 77 | 88 | +14.3% |
| Type A 平均 | 4.60 | 5.00（滿分） | +0.40 |
| Type B 平均 | 3.20 | 4.20 | +1.00 |
| Retrieval Failure | 5 題 | 2 題 | -60% |
| 無失敗題目 | 6 題 | 11 題 | +83% |
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：差距在哪
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 的 ROI 最高
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 倍的資料量。