Ian Chou's Blog

Ensemble 不只在機器學習：把 RAG 做穩的多路徑檢索策略（BM25/FTS + Vector + GraphRAG）

Ensemble 不只在機器學習：把 RAG 做穩的多路徑檢索策略（BM25/FTS + Vector + GraphRAG）

在機器學習或統計裡，Ensemble（集成學習）指的是：用多個模型一起做同一件預測任務，再把結果整合成最終輸出。這通常會比單一模型更穩、更準，因為你在做的是「分散風險」：只要各子模型的錯誤不是完全同向，融合後就能降低整體失誤。

這個直覺其實很值得拿來做 RAG（Retrieval-Augmented Generation）。

現在很多人談「RAG 回歸 BM25/SQLite」，看起來像返璞歸真，但它背後反映的其實是工程現實：大多數需求不需要推理，只需要把答案翻出來。而 GraphRAG 之所以相對少人談，往往不是因為它不強，而是因為它更像「重工業」，你得先付出建圖與治理成本，才看得到效益。

本文把兩件事連起來：

如果你只想記住一句話：

在 RAG 裡，Ensemble 不是「多用一個模型」，而是「讓不同失誤模式互補，並把它們變成可控的決策」。

1) Ensemble 的核心概念：不是「問更多人」，而是「讓錯誤彼此抵消」

你可以把 Ensemble 想成：不是只問一位專家，而是問一群專家，最後用投票、平均、加權平均來決定答案。

幾個常見類型：

如果你想補完整體背景，可以參考這幾篇整理（入門導向）：

把這套概念搬到 RAG，你會得到一個很重要的結論：

檢索系統的 Ensemble，不是「多用幾個模型」，而是「把不同失誤模式的檢索器疊在一起，讓它們互補」。

你也可以用一個對照表快速建立映射：

ML Ensemble 概念 檢索/GraphRAG 對應直覺
Bagging：降低 variance 多條便宜的召回路徑（FTS + Vector）互補，穩定召回
Boosting：修正前一個錯誤 用「Hard Match」修正語意路徑漏抓的專有名詞
Stacking：第二層學融合 用 reranker / LLM / RRF 做融合，學會怎麼組合候選

2) RAG 的 Ensemble：Recruiter vs Hiring Manager

在檢索系統裡，你可以把流程拆成兩個角色：

很多系統做到一半會卡住，是因為它把「有一點訊號」的路徑降級成 Recruiter 的輔助材料，卻沒有把它變成可控的決策依據。典型症狀是：

在這個 repo 的做法是：把檢索拆成多條路徑，並把「字面指名」升級成獨立通道參與融合，避免只當輔助素材。

3) 為什麼很多人回歸 BM25/FTS？因為 80% 的問題不需要推理

BM25/FTS 的甜蜜點是：

因此，當需求是「查條文」「找某段定義」「確認某 API 用法」，很多場景確實只要 BM25/FTS 就足夠。

從 Ensemble 的角度看，這不是倒退，而是回到一個合理的基線：

先把最便宜、最可控的專家（BM25/FTS）做好，讓它處理大量單點查詢，再用更貴的專家補強難題。

在本 repo，chunk 層的字面命中除了 FTS，也會做額外 boost，確保「字面命中」能在排序上被看見（可參考 [server.py](file:///home/ianc/GitHub/2511-Eleventy-blog/search/server.py) 內的 keyword boost 邏輯）。

4) 為什麼講 GraphRAG 的人少？因為它是重工業，而且解的是進階題

GraphRAG 的成本通常在「問問題之前」就先付掉了：

如果你的任務只是「翻書找一段文字」，GraphRAG 的投入很容易變成過度設計。

但只要你開始問這類問題，GraphRAG 的價值就會出現：

5) 關鍵澄清：GraphRAG 不會取代 BM25，它通常「包含」BM25

成熟的 GraphRAG 很少是「只走圖」。

比較合理的流程是：

  1. Seed retrieval：先用便宜的方法拿種子（BM25/FTS/Vector）
  2. Graph expansion：沿著圖補上下文（1-hop/2-hop）
  3. Rerank / evidence selection：把成本集中在候選集合上

這其實就是一種檢索層的 Ensemble：不同路徑各自擅長的錯誤模式不同，融合後更穩。

你可以把它想成「兩層系統」：

flowchart TD
  Q[Query] --> SR[Seed Retrieval: FTS/BM25 + Vector]
  SR --> F[Fusion: RRF / Rerank / Rules]
  F --> SE[Seed Entities/Chunks]
  SE --> GX[Graph Expansion: 1-2 hops]
  GX --> ES[Evidence Selection / Rerank]
  ES --> A[Answer]

6) 一套可落地的「多路徑檢索」配方（由便宜到昂貴）

下面這套順序的重點是：先把 CP 值最高的專家做穩，再往上加能力。

Path A：BM25/FTS（字面保底）

用途：處理大量單點查詢、專有名詞、精確用語。

Path A’：Vector（語意召回）

用途：處理同義改寫、語境相近但字面不同的段落。

Path B：LLM 選擇（概念對齊）

用途：把「候選集合」裡的概念做對齊與取捨。

關鍵護欄是：LLM 不要面對全局節點列表，而是只從候選池選，避免幻覺節點。

Path C：Hard Match（指名保證）

用途：只要使用者字面點名了某個 Entity，就要能穩定進入 seeds，避免「向量沒搜到 + LLM 沒選到」的漏抓。

本 repo 將 query token/片語命中升級成獨立通道參與融合，可參考：

Graph expansion：走圖補脈絡（Local）

用途：把種子 chunk 周邊關聯的 chunk 拉進來，補「上下文」而不是補「更多相似段落」。

Community summaries：全局檢索（Global）

用途：先回答「整體有哪些主題群？」再回到該群找證據，特別適合宏觀問題。

6.1) 常見踩坑與護欄（避免「多路徑」變成「多路徑一起爆炸」）

7) 用一個判斷題收尾：你的需求是在「翻書」還是在「整理知識」？

真正穩健的落地方式通常不是押寶單一路徑，而是把它們變成一個可控的 Ensemble：每條路徑都有清楚的職責、護欄、與融合策略。

參考連結