{"notes":[{"id":"retrieval-augmented-generation/bm25-wins-at-scale","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"BM25 Wins at Scale","subtitle":"讓 BM25 再次偉大","author":"Z. Yuan","paperDate":"2026-07-29","publishedOn":"2026-09-10","paperTitle":"BM25 Wins at Scale: A Scaling Study of Retrieval-Augmented Generation Paradigms","paperUrl":"https://arxiv.org/abs/2607.26497","bibliography":{"title":"BM25 Wins at Scale: A Scaling Study of Retrieval-Augmented Generation Paradigms","authors":["Pengyu Wang","Benfeng Xu","Shaohan Wang","Mingxuan Du","Xin Zeng","Huarui Wu","Lei Zhang","Licheng Zhang"],"url":"https://arxiv.org/abs/2607.26497","pdfUrl":"https://arxiv.org/pdf/2607.26497v3","codeUrl":null,"preprint":{"id":"2607.26497","submittedOn":"2026-07-29","url":"https://arxiv.org/abs/2607.26497"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationbm25winsatscale2026,\n  title = {{BM25 Wins at Scale: A Scaling Study of Retrieval-Augmented Generation Paradigms}},\n  author = {Pengyu Wang and Benfeng Xu and Shaohan Wang and Mingxuan Du and Xin Zeng and Huarui Wu and Lei Zhang and Licheng Zhang},\n  year = {2026},\n  eprint = {2607.26497},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2607.26497}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/bm25-wins-at-scale.faa6780c7835.bib"},"thumbnail":{"src":"/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png","width":700,"height":550},"locale":"zh-hant","path":"/content/papers/zh-hant/retrieval-augmented-generation/bm25-wins-at-scale.dbe8dd782fa1.md","headings":[{"id":"定義問題","text":"定義問題","depth":2},{"id":"解決問題","text":"解決問題","depth":2},{"id":"一家虛構公司的知識庫","text":"一家虛構公司的知識庫","depth":3},{"id":"地基1144-份固定文件","text":"地基：1,144 份固定文件","depth":3},{"id":"28-層巢狀資料庫","text":"28 層巢狀資料庫","depth":3},{"id":"七條管線四種門派","text":"七條管線、四種門派","depth":3},{"id":"討論","text":"討論","depth":2},{"id":"主要結果在-1000-萬-token-附近交叉","text":"主要結果：在 1,000 萬 token 附近交叉","depth":3},{"id":"成本agent-越找越貴","text":"成本：agent 越找越貴","depth":3},{"id":"圖式-rag-撞上建置的牆","text":"圖式 RAG 撞上建置的牆","depth":3},{"id":"為什麼-agent-會輸先找到才談得上推理","text":"為什麼 agent 會輸？先找到，才談得上推理","depth":3},{"id":"bm25-的優勢從哪裡來","text":"BM25 的優勢從哪裡來？","depth":3},{"id":"讀這篇時要知道的事","text":"讀這篇時要知道的事","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"RAG 發展到 2026 年，已經分出好幾個門派。\n\n**詞彙檢索**用 BM25 這類關鍵字排序；**稠密檢索**把文字轉成向量比相似度；**圖式 RAG** 在建索引時讓 LLM 把每段文字的實體和關係抽出來，建成知識圖；還有直接讓 **agent** 像 coding agent 那樣，在檔案樹裡 `ls`、`grep`、讀檔，一步步找答案。\n\n每個門派都有漂亮的論文成績。問題是，這些成績通常來自**不同的評測集**，而且只在**某一個資料量**下測。\n\n企業的知識庫卻不是固定大小的。今天幾萬份文件，明年可能幾十萬份。\n\n這篇來自中國科學技術大學、Metastone 與北京市農林科學院資訊技術研究中心的預印本，想回答一個很實際的問題：**資料量一直變大時，哪一種 RAG 還撐得住？**\n\n論文 2026 年 7 月 29 日首次上傳 arXiv，早期題名是《Which RAG Paradigm Wins at Scale?》，之後改成現在的標題。本文依 2026 年 7 月 31 日的 v3 閱讀。\n\n\n> [!TIP]\n> \n> **BM25 是什麼？**\n> \n> BM25 是 1990 年代就發展成熟的關鍵字排序方法，搜尋引擎和 Elasticsearch 這類工具至今仍以它為預設的排序方式之一。\n> \n> 它替每份文件打分數，大致看三件事：\n> \n> 1. **查詢詞出現幾次**。出現越多分數越高，但會逐漸飽和，同一個詞出現一百次不會比十次高十倍。\n> 2. **這個詞有多罕見**。「the」到處都有，幾乎不加分；「ticket-4821」只出現在少數文件，命中就很有分量。\n> 3. **文件有多長**。長文件本來就容易命中，所以會依長度做一點調整。\n> \n> 它不需要訓練，也不需要 GPU，建好倒排索引就能用。\n\n\n## 定義問題\n\n作者把「scaling」定義得很清楚：**題目固定不動，只讓資料庫變大，看每種方法的表現怎麼變。**\n\n要做到這件事，有三個難處：\n\n1. **題目和答案要固定**。換了題目，成績的變化就分不清是因為資料變多，還是題目變難。\n2. **干擾要固定**。專門設計來誤導的文件，最好從一開始就在，不要隨著資料量才逐步加入。\n3. **其他條件要固定**。回答的模型、評分的方式、成本的計算，都要每種方法一樣。\n\n## 解決問題\n\n### 一家虛構公司的知識庫\n\n作者使用 EnterpriseRAG-Bench，它模擬一家提供 LLM 推論服務的虛構公司，有 511,957 份文件、共 6.008 億 token，來自九種來源：wiki、聊天討論串、工單、電子郵件、會議逐字稿、CRM 紀錄、code review 等等。\n\n題目有 500 題，分成十種類型，從基本查詢到需要彙整完整資訊、處理互相矛盾的資訊、回答高層次問題都有。每題都標註了標準答案、對應的文件（共 722 份），以及答案應包含的原子事實。\n\n這份語料本身就有 7.7% 的雜訊文件：放錯來源或路徑，或者是內容過時的近似重複，就像真實公司裡會有的檔案。\n\n### 地基：1,144 份固定文件\n\n作者先建一個最小的資料庫，稱為**地基**（bedrock）：\n\n$$\n\\underbrace{722}_{\\text{標準文件}}+\\underbrace{326}_{\\text{陷阱}}+\\underbrace{99}_{\\text{誘餌}}+\\underbrace{2}_{\\text{公司總覽頁}}-\\underbrace{5}_{\\text{重複}}=1{,}144\n$$\n\n**陷阱**（trap）是最關鍵的部分：和標準文件講同一個主題，但版本、日期或決策是錯的。例如同一個專案的舊版規格。作者用 BM25 取全語料前 10 名，再用稠密檢索從 BM25 前 200 名裡重新排序取 10 名，最後由 LLM 篩出「主題相同、但事實錯誤」的文件。\n\n**誘餌**（lure）則是為「找不到答案」的題目準備的：和題目很像、但經確認無法回答它的文件。這樣模型就不能只因為「什麼都沒找到」而答對。\n\n這些干擾從最小的資料庫就全部放進去，之後不再變動。\n\n### 28 層巢狀資料庫\n\n接下來，作者把其餘的文件依固定順序排好，從地基開始，每一層多放一些，讓文件數每層乘上 1.25：\n\n$$\nn_{t+1}\\approx1.25\\,n_t\n$$\n\n從 1,144 份一路長到 511,959 份，一共 28 層，大約 450 倍；換算成 token，從 170 萬到 6.01 億。\n\n這裡的「巢狀」是嚴格的：每一層都完整包含前一層，作者用檔案校驗碼確認過。所以從第 1 層到第 28 層，唯一的差別就是多了更多無關的背景文件。\n\n新增的文件按來源和雜訊比例分層抽樣，讓每一層的組成接近整份語料。\n\n### 七條管線、四種門派\n\n| 門派 | 方法 | 怎麼做 |\n| --- | --- | --- |\n| 詞彙 | BM25 | 倒排索引，不需要 LLM |\n| 稠密 | DenseRAG | 每塊文字轉成 embedding 比相似度 |\n| 圖式 | HippoRAG 2 | 抽三元組建圖，用 Personalized PageRank 檢索 |\n| 圖式 | MS-GraphRAG | 建實體圖與階層式社群報告，用 local search |\n| 圖式 | LightRAG | 實體與關係的雙層索引，用 hybrid 模式 |\n| 圖式 | LinearRAG | 用輕量的命名實體辨識建共現圖，不呼叫生成式 LLM |\n| Agent | File-System Agent | 不建索引，在原始檔案樹裡列目錄、搜尋、讀檔 |\n\n*整理自原論文 §4.1。*\n\nFile-System Agent 用的就是 coding agent 的那套介面，每題最多呼叫 80 次 LLM。\n\n其他條件盡量統一：\n\n- **回答模型**：全部用 Qwen3.6-27B，溫度 0；File-System Agent 也用同一個模型決定下一步。\n- **embedding**：全部共用 Qwen3-Embedding-0.6B。\n- **檢索深度**：有檢索深度的方法都取前 5 塊。BM25、DenseRAG、HippoRAG 2 用同一套切塊方式。\n- **成本計量**：攔截每一次 LLM 呼叫，把 token 分別記在「建索引」或「回答問題」。\n- **評分**：用評測集的官方協定，主要指標是 **combined score**，看答案的事實完整度，但要先通過正確性的門檻。每題只跑一次，信賴區間用重抽題目的 bootstrap 估計。\n\n作者另外用一個獨立的評審模型重新評分，兩者的判斷有 96.2% 一致；改用更簡單的對錯二分評分，各方法在九個共同層級的排名也都不變。\n\n## 討論\n\n### 主要結果：在 1,000 萬 token 附近交叉\n\n[![各方法的官方 combined score 隨語料 token 數增加的變化，含 95% 信賴區間；BM25 與 File-System Agent 約在一千萬 token 處交叉](/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png)](/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png)\n\n*原論文 Figure 3，取自 [**v3 PDF 第 6 頁**](https://arxiv.org/pdf/2607.26497v3#page=6)。橫軸為語料 token 數（對數），縱軸為官方 combined score，色帶為 95% 信賴區間；圖式方法的線停在它們能建成的最大層級。*\n\n橫軸是語料的 token 數，用的是對數刻度；縱軸是分數。\n\n看最上面的兩條線。左端，青色的 File-System Agent 比咖啡色的 BM25 高一點：地基時分別是 77.4 和 74.7，但兩者的 95% 信賴區間（73.9–80.8 和 71.4–77.9）重疊，統計上分不出高下。\n\n往右走，兩條線在 $10^7$，也就是約 1,000 萬 token 附近交叉。之後 BM25 在每一個共同層級都領先，而且差距越拉越大。\n\n到了最右邊的完整語料：\n\n| 方法 | 1,144 份（地基） | 21,614 份 | 131,876 份 | 511,959 份（完整） |\n| --- | ---: | ---: | ---: | ---: |\n| BM25 | 74.7 | 64.9 | 55.2 | **50.5** |\n| File-System Agent | **77.4** | 62.6 | 50.9 | 30.7 |\n| DenseRAG | 58.1 | 44.2 | 36.0 | 29.9 |\n| HippoRAG 2 | 66.2 | 53.8 | 41.0 | — |\n| LinearRAG | 46.2 | 34.3 | 29.8 | — |\n| MS-GraphRAG | 45.9 | — | — | — |\n| LightRAG | 48.0 | — | — | — |\n\n*整理自原論文 Table 1，欄位為各層的文件數。「—」表示該層沒有建成或沒有評測。*\n\n完整語料下，BM25 是 50.5，File-System Agent 掉到 30.7，DenseRAG 是 29.9。差距接近 20 分。\n\n稠密檢索從頭到尾都在 BM25 下面。圖式方法則有一大半根本走不到完整語料。\n\n### 成本：agent 越找越貴\n\nBM25、DenseRAG、HippoRAG 2 這種「檢索一次就回答」的管線，每題的查詢成本幾乎不隨資料量改變，大約 5 千到 6 千 token，主要是回答模型的提示詞。\n\nFile-System Agent 則完全不同。地基時每題就要 226K token，是 BM25 的 39 倍；到了 21,614 份文件時漲到 343K，約 60 倍。\n\n它的 LLM 呼叫次數中位數，從 5 次增加到 8 次（42,587 份時）。80 次預算用完的比例，在 42,587 份以內都低於 7%，到 131,876 份時升到 15%，完整語料時是 31%。\n\n作者特別指出，就算只看沒用完預算的題目，準確率也一樣在下降，所以崩盤不能只怪預算太少。\n\n我們可以把 500 題的總成本算一下：BM25 每題 5.8K token，500 題是 290 萬 token，拿到 74.7 分；File-System Agent 每題 226K，500 題約 1.13 億 token，拿到 77.4 分。多花將近 40 倍的 token，換來 2.7 分，而且還在信賴區間的重疊範圍內。\n\n### 圖式 RAG 撞上建置的牆\n\n圖式方法的成本，主要花在建索引：每一段文字都要讓 LLM 讀一遍、抽出實體和關係。\n\n作者用 $C(x)=a\\,x^{b}$ 擬合建置 token 與語料大小的關係，再外推到完整語料：\n\n| 方法 | 指數 $b$ | 外推到完整語料 | 估計單機時間 |\n| --- | ---: | ---: | ---: |\n| HippoRAG 2 | 1.01 | 約 29 億 token | 約 3 天 |\n| MS-GraphRAG | 0.92 | 約 79 億 token | 約 50 天 |\n| LightRAG | 1.36 | 約 1,020 億 token | 約 4 年 |\n\n*整理自原論文 Table 2。*\n\nLightRAG 的指數大於 1，代表資料越多，每份文件的建置成本越高；作者認為原因是它會反覆改寫、合併實體。它在 2,826 份文件時就無法在作者的資源內完成。\n\n就算建得起來，分數也不理想。HippoRAG 2 在約 1.55 億 token 的語料上，用了 7.24 億 token 建索引，拿到 41.0 分，比同一層的 BM25 低約 15 分。\n\n作者分析，圖式方法在這份語料上吃虧有三個原因：抽取會帶進雜訊（地基的 3.2 萬個實體裡有不少殘缺片段）；圖的鄰近關係偏好「語意相關但事實錯誤」的內容，正好被陷阱文件懲罰；HippoRAG 2 還丟掉了抽出的謂詞文字，也就丟掉了關係的語意。\n\n### 為什麼 agent 會輸？先找到，才談得上推理\n\n這是整篇論文最關鍵的對照實驗。\n\nFile-System Agent 輸掉，到底是因為它「找不到」，還是「找到了也不會用」？\n\n作者在固定的 150 題上，比較地基與完整語料兩個層級。新加入的對照組叫 **Agent+BM25**：模型、harness、80 次預算、評審全部不變，只把原始的檔案樹工具換成「BM25 排序搜尋」加「讀取文字塊」，並強制第一次搜尋使用原始問題。\n\n| 方法 | 地基 | 完整 | 文件召回 | 呼叫次數 | token |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| Native BM25 | 81.3 | 54.8 | 65.6 | 1.00 | 5.8K |\n| File-System | 87.1 | 36.9 | 36.8 | 36.12 | 895K |\n| Agent+BM25 | **90.1** | **69.4** | **72.4** | 5.79 | 101K |\n\n*整理自原論文 Table 4，固定 150 題、同一次重新評分。前兩欄為兩個層級的 combined score；文件召回率、每題呼叫次數與每題 token 都是完整語料下的數值。*\n\n答案很清楚：**問題出在「找到」。**\n\n完整語料下，File-System Agent 至少命中一份標準文件的比例只有 39.0%，BM25 是 71.6%。\n\n作者也看了「命中至少一份標準文件」的那些題目：File-System Agent 在這些題目上拿到 85.9，BM25 是 73.8。換句話說，agent 一旦找到資料，推理與整合的能力其實比較好。不過這兩個數字來自各自命中的題目，題目集合不同，只能當成描述，不能直接比高下。\n\n只換掉檢索工具，Agent+BM25 在完整語料拿到 69.4，比原始的 File-System Agent 高 32.5 分，也比 Native BM25 高 14.6 分；命中率升到 78.0%，每題 token 從 895K 降到 101K，大約是原本的九分之一。\n\n作者的結論是：**agent 的推理，最適合放在全域排序之後，而不是取代它**。在小小的檔案樹裡一層層找，資料一多，相關的分支就越來越難走到。\n\n\n> [!NOTE]\n> \n> **Harness 也很重要**\n> \n> 作者另外在地基的 150 題上，比較三種讀原始檔案的 agent harness：作者自己的 86.3、Pi-Agent 的 82.3，Codex 只有 43.9；Native BM25 是 82.1（原論文 Table 5）。\n> \n> 同樣的模型、語料與評審，換一個 harness，分數就差了四十多分。前面 Agent+BM25 的對照，用的是三者中表現最好的作者版本。\n\n\n### BM25 的優勢從哪裡來？\n\n作者也承認，這份語料對 BM25 有利：企業的問題裡常有精確的字詞錨點（專案名稱、工單編號、人名），而陷阱文件是「語意很像、但事實錯誤」，精確比對比較不容易被騙。\n\n所以他們做了兩個控制實驗：\n\n- **改寫問題**：把題目換句話說，降低字面重疊。地基上 BM25 降到 63.9，File-System Agent 是 73.3，DenseRAG 是 51.8。改寫後，小型資料庫上 agent 的優勢變得更明顯，但 BM25 仍高於稠密與圖式檢索。\n- **取前 10 塊**：檢索深度加倍，BM25 是 83.0，DenseRAG 是 70.0，差距仍在。\n\n### 讀這篇時要知道的事\n\n1. **只有一個評測集**。EnterpriseRAG-Bench 是模擬的企業語料，題目的字詞錨點和陷阱設計，都會影響詞彙與語意檢索的相對表現。\n2. **稠密檢索用的是小模型**。所有 embedding 都來自 Qwen3-Embedding-0.6B。換成更大的 embedding 模型，DenseRAG 的成績會不會改變，論文沒有測。\n3. **沒有測混合檢索**。論文比較的是各門派的單一管線，沒有 BM25 與稠密檢索融合、或 BM25 後接 reranker 這類常見的混合做法。最接近的是 Agent+BM25。\n4. **單一回答模型、每題跑一次**。不確定性來自重抽題目，沒有重複執行的變異。\n5. **程式與資料**。附錄列了程式與資料補充材料的內容與對應關係，但 v3 正文沒有給出公開下載位置。\n\n## 結論\n\n這篇論文用 28 層、約 450 倍的巢狀資料庫，把題目、標準文件和陷阱都固定住，只讓背景文件變多。在這個設定下：\n\n1. **沒有永遠的贏家，只有交叉點**。資料小的時候，File-System Agent 略勝；約 1,000 萬 token 之後，BM25 在每一個共同層級都領先，完整語料時差距接近 20 分。\n2. **BM25 便宜又穩**。每題約 5.8K token，不需要用 LLM 建索引，穩穩占住成本與準確度取捨的低成本端。\n3. **Agent 的問題是找不到**。把檔案樹工具換成 BM25 排序搜尋，同一個 agent 在完整語料從 36.9 分升到 69.4 分，token 只剩九分之一。\n4. **圖式 RAG 卡在建置**。LightRAG 外推需要約四年的單機時間；建得起來的 HippoRAG 2，分數也低於 BM25。\n\n作者給企業語料的實務建議很直接：**BM25 當預設；需要彙整多份資料的問題，用 Agent+BM25**。LLM 建圖的索引，在十萬到百萬份文件的規模下很難說服人，除非建置成本接近線性，而且問題大多在問關係。\n\n資料一多，三十年前的老方法回來了。只是這次，它站在 agent 前面幫忙開路。\n","imageSizes":{"/content/papers/assets/d96c5fc056dc2c5c1af9de8338acd25396a1e0a15973938281502d305501c18e.png":{"width":700,"height":550}}}