{"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-hans","path":"/content/papers/zh-hans/retrieval-augmented-generation/bm25-wins-at-scale.174c1c32fb15.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}}}