企業資料分好幾區：規範 PDF、工單、人事規章、ERP 的庫存數字各在一處，問的卻是同一句話。搜之前先挑一區，會不會更準？

這個「先決定去哪裡搜」的步驟叫 routing。我把昨天那份語料分成四區，每題只搜相關片段最多的那一區：範圍小、雜訊少，BM25 是關鍵詞檢索，召回率看的是找回多少已標記的相關片段——結果卻從 96.2% 掉到 89.4%。

問題出在一個沒說出口的前提：**選對區，不代表相關片段全在那一區。**同一個型號有三段內容，兩段在操作手冊、一段在維修紀錄；每次都挑中手冊，也只找得回兩段。

Day 22 的 L4 開了三帖藥：加大候選池、hybrid、用 metadata 限定範圍。昨天用掉 hybrid，今天處理剩下兩帖：先算「只搜一區最多找得回多少」，再看多撈幾塊與加 router 各補得上什麼。

先算天花板，再談 router

語料沿用昨天那份：day01 到 day24、451 個片段，切法與 BM25 斷詞原封不動；我照週次分成四個「資料源」，一區 69 到 146 塊。

gold（本次標記的相關片段）是「原文含這個查詢字串的片段」，每題 2 到 5 塊；「正確的那一區」指每題 gold 最多的那一區；路由是每題只選一個區的硬路由，沒有多選、沒有低信心回退。所以這是詞項召回，不是問答品質——漏掉一塊 gold 不等於答不出來。

有了這個定義，天花板不必做實驗就算得出來：**相關片段散在不同區。**116 個識別碼查詢，每題的正確片段平均有 9.3% 住在別區；換成一般中文詞查詢（158 題）是 37.2%。

**所以只搜一區，recall 上限就是 90.7% 與 62.8%——不管候選池開多大、router 多準。**而全庫 BM25 是 96.2% 與 93.6%：你最好的那一路，兩邊都站在天花板上面。

圖 1：中文詞查詢的天花板只有 62.8%，比識別碼那組再低 28 個百分點。

BM25 從 96.2% 掉到 89.4%，逐題配對是顯著的；hybrid（融合兩路）掉 2.2 個百分點，但 sign test 過不了 0.05，只能說沒觀察到改善。

只有 dense（向量檢索）是正的，49.7% 拉到 60.6%。這份語料上，分域只改善了本來就離天花板很遠的那一路。

把它換算成門檻——固定錯域假設下，router 要多準才划算：dense 要 80.3%，BM25 要 108.4%——超過 100%，代表在這 116 題上連完美的 router 都虧；只算單域那 89 題是 98.1%，虧的全在跨區題。

這份語料撐不住的是：24 篇同一個人、同一個主題，是「域邊界很爛」的那一端。帶走的不是這幾個負數，是那條天花板算式。

四個 router，實際選到的區

唯一還有得談的是 dense 那條路。

但要先把兩個死因分開。上一節那 116 題混著 27 題答案散在多區，完美路由在那些題上再準也拿不滿。接下來只看答案全在同一區的 89 題：這批沒有天花板問題（完美路由的 BM25 98.9%，高過不分域的 97.0%），剩下的就是路由選錯的代價。

route 用兩種定義：人手寫的四段主題描述，或直接拿該區所有片段的向量平均——39.3% 與 49.4%，而全押最大那一區的多數類基線就有 33.7%。付一次 LLM 呼叫（把四個資料源的描述列成清單讓 gemma4:26b 挑）是 44.9%，夾在中間。

原因跟昨天同一個：查詢是 Q4_K_M、tg128 這種識別碼，**只靠這幾個字元，很難判斷該搜哪一週。**那換 k-means 重切？形心確實分得更開，但天花板跟著從 90.7% 掉到 80.8%——向量分得更開，未必能把同一個查詢的相關片段留在一起。

準確度只是分類分數。真正該問的是拿它選到的區去搜、recall 剩多少——直接拿它選的區重跑一次就好。吐不出合法代號的那幾題退回搜全庫，所以有幾格的 recall 高過它自己的準確度。

圖 2：手寫描述那一列準確度 39.3%，BM25 就從 97.0% 剩 38.8%——路由的錯，是用檢索的分數付的。

十二格全部輸給不分域，有生效的那九格還全部通過了 sign test。最準的那個 router 選對 49.4% 的題，配 BM25 之後實測 recall 只剩 48.9%（不分域 97.0%）——**選對區後幾乎能拿滿分時，最後的召回率就接近路由準確度。**這批題只有一區有答案，選錯依定義就是零；dense 沒這麼乾脆，它連在對的區裡也只有 68.5%。

那條 2.2% 的是怎麼回事？同一顆模型，只是 thinking 用預設值。prompt 中位數 208 個 prompt token，num_predict=256；關掉 thinking 中位數 3 個 token 就答完、p50 是 290 ms，打開之後它把 256 個 token 全花在思考，p50 變 5,009 ms，86 題連一個代號都沒吐出來就被截斷。

那 86 題退回搜全庫，於是它的 recall 幾乎等於不分域，落後不到 1.2 個百分點——十二格裡不顯著的三格全在這一列。救回來的是回退機制，不是那個 router。

高檢索分數也不能證明你路由選對了：丟到確定沒有答案的區，dense 有 39 題（116 題中）的第一名比正確區的 gold 還高分，BM25 只有 4 題（114 題中）。值得評估能不能當回退訊號，但它還不是偵測器。

分域和「多撈幾塊」是同一筆預算

L4 的第一帖藥是「加大候選池」。多撈幾塊就補得回來的話，分域在買什麼？

Day 22 那條 recall 階梯拿來量分域就行——只算單域題，這樣「縮到正確的區」只會移除非答案的片段。

**加大融合後的候選數之前，先確認每一路真的撈得夠深。**每路的取回深度是 Elasticsearch 的 rank_window_size，預設就等於 size。我這次讓它跟著 k 走；第一版卻把它寫死在 10，融合後的候選池上限因此卡在 20，k=20 與 k=50 量到同一個池、兩列數字一模一樣，而我差點把它讀成「加大候選池已經加不動」。

圖 3：兩條線在 k=3 之後分家——一條走向零，另一條起伏著往上。

修好重跑：k=3 值 9.4 個百分點；k=10 還有 4.4；k=20 剩 1.3 就過不了 0.05；k=50 只剩 0.6，89 題裡 88 題打平。

**但這只對已經逼近天花板的兩路成立。**dense 是反的：k=1 時分域值 8.8 個百分點，k=50 漲到 19.1——它在全庫開到 k=50 也才 75.4%，加大 k 補不上的洞，分域補得上。

dense 與 BM25 在這個子集上只進不退；hybrid 走 RRF、只讀名次，候選集一縮小就會翻面，所以它有敗場。這條單調性也只對「同一份全庫索引加 filter」成立：拆成四份重建，BM25 的文件頻率與平均長度都會變。

分域和加大候選池買的是同一件事——把正確答案弄進候選池。差別只在你用什麼付錢。

分域付的是路由判斷的成本，加上選錯範圍的漏失；加大 k 付的是檢索與重排的工作量，而且在固定送進 LLM 的 token 預算時它不會膨脹 prompt——Day 17 把這兩本帳分開過。所以先掃 k 曲線：它自己會告訴你這條路是撞到天花板，還是離天花板還很遠。

四個階梯各付什麼價

決定要爬了才輪到爬幾階。從一行 filter 到一整圈 agent 迴圈都叫 routing，尺是這個 query 多打了幾次呼叫。

圖 4：第 0 階的「0 次模型呼叫」不等於 0 成本——它把帳挪到查詢計畫上。

由便宜到貴是第 0 階 metadata filter、第 1 階 semantic router、第 2 階 LLM router、第 3 階 agentic 迴圈。三件圖上放不下的：

**第 0 階要先確認你的向量庫是 pre-filter 還是 post-filter。**pgvector 走 HNSW 時，過濾在索引掃完之後才套用：命中一成、ef_search 用預設 40，平均只剩四筆。

**第 2 階真正的工作量是 description。**Anthropic 給了個數字：Claude 挑對工具的能力在超過 30 到 50 個工具之後開始衰退。

**第 3 階的匯率別照抄。**那篇企業檢索論文在 BRIGHT 長文設定上把 recall@1 從 8.41% 拉到 49.6%——但換成同一篇 baseline 表裡最好的開源 embedding（27.8%）當分母只剩 1.78 倍，而跑出 49.6% 的是 Claude Sonnet 4.5：這套迴圈一顆開放權重模型都沒跑過。

2026 沒有換掉這把尺，換掉的是被路由的東西：MCP 官方列的 keyword／embedding／subagent 正好對上第 0 到第 2 階，而 Anthropic 內建的 tool search 用的是 regex 與 BM25，不是 embedding；Azure 那個 preview 功能的 minimal 檔，做法是省掉 LLM 規劃，直接搜尋該 knowledge base 已配置的全部來源。

Day 22 那條規矩仍然要記著：**檢索指標變好，不代表答案更可信。**它引的那篇研究，開源堆疊在不同表格裡方向相反，本文不採用它的掉幅。

今天的實驗需要什麼

前兩階不用 GPU：bge-m3 掛 sentence-transformers 跑 CPU，單題 p50 70.9 ms。第 2 階才要一顆能穩定吐出合法代號的模型，Day 06 那六組沒排過這一項，得自己挑自己驗。

但真正的門檻不是硬體，是開跑前就算得出來的那條天花板：**每題的相關片段，有多少比例住在相關片段最多的那一區。**它要一份 query 對 gold 的標註，不是把語料 encode 一次就有。

圖 5：第 2 步就可能叫你停手。

小結

• 先算天花板：每題挑相關片段最多的那一區，算它覆蓋多少 gold 再平均。我的語料是 90.7%，而全庫 BM25 已經 96.2%——天花板低於現況，這種單域硬路由就沒空間可贏。
• 再掃 k 曲線：確認加大候選池之後分域還剩多少優勢。hybrid 從 k=3 的 9.4 個百分點縮到 k=50 的 0.6，dense 卻到 19.1——兩條路分開量，掃之前先確認每一路撈得夠深。
• 最後驗實際路由，不是只量準確度：把選錯區與回退機制一起算進召回率與延遲。最準的 router 選對 49.4% 的題，實測 recall 只剩 48.9%；四個 router 十二格全輸給不分域。

今天這四個資料源都是文件片段。現實不是。明天 Day 27〈企業資料不是一種資料：API、異質 DB、Legacy、Wiki 的接入四象限〉，我們拆開那四種完全不同的資料形狀，看看哪些東西根本不該進向量庫。

咱們明天見。

這篇的條件與來源

機器 T1（M4 Max 128GB）。切法沿用 Day 25，corpus_sha256 逐位相同。所有數字僅代表這份評估集。