BM25 在大规模文档检索下的优势

当前的大语言模型在缺乏外部依据时，可能生成看似合理但事实不准确的内容。为缓解这一问题，主流方法之一是检索增强生成（Retrieval-Augmented Generation，简称 RAG）：模型在回答问题前，先从文档库中检索相关资料，再基于检索结果生成答案。这相当于让模型在回答时参考外部资料，而不是完全依赖参数中的记忆。

围绕“如何检索”这一问题，已经形成了几类不同路线：

词法检索（BM25）：一种经典检索方法，主要依赖关键词的精确匹配对文档进行排序，类似早期搜索引擎的工作方式，不需要大模型参与。
稠密检索（Dense Retrieval）：使用神经网络将文档和问题编码为向量，再根据语义相似度进行匹配，能够处理“同义不同词”的情况。
基于图的 RAG（Graph-based RAG）：在回答问题之前，先用大模型从文档中抽取实体和关系，构建知识图谱；查询时再沿图结构查找相关信息。
智能体搜索（Agentic Search）：不预先构建索引，而是让 AI 智能体像用户操作文件系统一样，反复调用“列目录”“搜索关键词”“读取文件”等工具来寻找答案。

这些路线各有适用场景，也有各自的基准测试。但论文指出，它们很少在统一条件下进行直接比较，更缺乏在不同语料库规模下的系统性评估。

实际企业知识库往往包含大量文档，并且会持续增长。因此，一个关键问题是：不同检索方法在什么规模下最有效？准确率和成本如何随规模变化？这正是论文试图回答的问题。

实验设计

研究团队设计了一组规模可控的实验。

固定问题，只改变语料库规模

论文使用 EnterpriseRAG-Bench 这一企业知识库基准，包含 511,959 份文档，约 6 亿 token，以及 500 个问题。

研究团队构建了 28 个严格嵌套的语料库子集：最小规模为 1,144 份文档，约 170 万 token；随后每一层按 1.25 倍增长，直到完整语料库的 511,959 份文档，整体跨度约 450 倍。

这一设计的关键在于：所有与问题相关的证据文档，以及故意设置的干扰文档，从最小规模的语料库开始就已经包含在内。 后续每一层规模扩大时，只新增无关背景文档。

因此，准确率的变化可以主要归因于一个因素：随着无关文档增加，检索方法在更大搜索空间中找到正确证据的难度上升。

控制变量，统一评估条件

实验中的七种方法均运行在相同条件下：

相同的阅读模型：Qwen3.6-27B，温度设为零。所有方法检索到文档后，都交由同一个模型生成答案。
相同的评判协议：使用官方准确率评分，并额外引入独立评审和简化协议进行交叉验证。
相同的 token 计量方式：精确记录每种方法在“构建阶段”和“查询阶段”分别消耗的 token 数。

这种设计使得不同方法的比较更具可比性，避免因模型、评分方式或计量方式不同而造成偏差。

实验结果

规模交叉点：BM25 的反超

实验结果显示，两类方法的表现曲线在约 1000 万 corpus token 附近出现交叉。

在最小规模下，即 1,144 份文档、约 170 万 token 时，File-System Agent 与 BM25 的表现接近：前者为 77.4 分，后者为 74.7 分，二者置信区间存在重叠。此时智能体方法略有领先。

但随着语料库规模继续增大，两条曲线开始分化。BM25 的准确率下降较为缓慢，而 File-System Agent 的下降幅度更大。到约 1000 万 token 时，BM25 反超；此后在更大规模下，BM25 始终保持领先。

在完整语料库规模下，即约 6 亿 token、51 万份文档时，两者差距扩大到近 20 分：BM25 得到 50.5 分，File-System Agent 为 30.7 分，稠密检索为 29.9 分。

成本：BM25 查询成本稳定，智能体成本随规模上升

除准确率外，成本也是论文关注的重点。

BM25 和稠密检索这类预先构建索引的方法，查询成本基本不随语料库规模变化。无论语料库多大，它们都先构建索引，查询时进行排序并返回最相关的文本片段。BM25 每个问题约消耗 5,800 个 token。

File-System Agent 的成本则明显更高。它在每次回答问题时，都需要让 AI 智能体在文件树中反复搜索和读取。即便在最小规模下，每个问题也需要约 226,000 个 token，是 BM25 的约 39 倍。到 2 万份文档时，其消耗上升到约 343,000 个 token，是 BM25 的约 60 倍。

此外，智能体方法设有 80 次调用预算。随着语料库规模扩大，它在预算内找到答案的难度增加，预算耗尽率从 7% 上升到完整规模下的 31%。论文同时指出，即便在预算未耗尽的问题上，智能体方法的准确率也会下降。这说明问题不仅在于调用次数不足，也与其搜索策略在大规模空间中的有效性有关。

图方法：构建成本限制了大规模应用

基于图的 RAG 方法在大规模语料库上的主要限制来自构建成本。此类方法需要在回答问题之前，用大模型从每份文档中抽取实体与关系，并构建知识图谱。随着语料库规模扩大，这一过程的计算与 token 成本迅速增加。

方法	最大可构建规模	全规模构建成本（推算）	全规模耗时（推算）
HippoRAG 2	约 13 万份文档	29 亿 token	约 3 天
MS-GraphRAG	约 8,750 份文档	79 亿 token	约 50 天
LightRAG	约 2,254 份文档	约 1,020 亿 token	约 4 年

其中，LightRAG 的构建成本呈超线性增长，指数为 1.36。这意味着语料库规模翻倍时，构建成本增长超过一倍。推算到完整规模时，需要约 1,020 亿 token，单实例运行时间约为 4 年。即便采用较乐观的估计，也需要约 42 亿 token。

从准确率看，即使 HippoRAG 2 成功构建到约 13 万份文档规模，其准确率也只有 41.0 分，比 BM25 在同一规模下低约 15 分。这表明，高昂的构建成本并未在该实验设置下转化为更好的整体表现。

机制分析

BM25 在大规模下表现更好的原因

论文给出的解释是：企业问题中通常存在明确的词法锚点。

企业知识库中的问题往往包含具体名称、日期、数字或项目代号，例如“2024 年 Q3 的营收是多少”“项目 X 的负责人是谁”。BM25 依赖关键词精确匹配，能够有效捕捉这些词法锚点。对于语义相近但事实错误的干扰文档，BM25 的精确匹配机制也有助于降低误召回概率。

相比之下，稠密检索依赖语义相似度排序。当干扰文档在语义上与问题高度接近、但事实内容不正确时，它们可能排在真正证据文档之前，从而影响最终答案质量。

File-System Agent 在大规模下表现下降的原因

其核心原因在于局部搜索与全局排序之间的差异。

BM25 和稠密检索在查询前已建立覆盖全部文档的索引。查询时，它们可以在完整搜索空间中进行一次性全局排序，返回最相关的文档片段。

File-System Agent 则采用顺序探索方式：从文件树根目录开始，逐步查看目录、搜索关键词、读取文件。随着语料库规模增大，相关文档可能位于更深或更分散的位置，智能体在有限调用预算内触达相关文档的概率会降低。

论文用数据进一步说明了这一机制：在完整规模下，File-System Agent 找到至少一份相关文档的概率只有 39%，而 BM25 为 71.6%。但在那些智能体确实找到相关文档的问题上，它的得分为 85.9，高于 BM25 的 73.8。这说明智能体在获得有效证据后的推理能力较强，主要瓶颈在于证据发现阶段。

控制实验：更换检索方式后的结果

论文还设计了一个控制实验：保持智能体的其他条件不变，包括模型、工具循环和 80 次调用预算，仅将“在原始文件树中搜索”替换为“使用 BM25 搜索”。

结果如下：

方法	全规模准确率	每问题 token	文档召回率
原始 File-System Agent	36.9	895,000	36.8%
Agent + BM25	69.4	101,000	72.4%
原始 BM25	54.8	5,800	65.6%

仅更换搜索方式后，准确率从 36.9 提升到 69.4，增加 32.5 分；token 消耗降至原来的约九分之一；文档召回率从 36.8% 提高到 72.4%。

这一实验表明：问题主要不在于智能体的推理能力，而在于其获取资料的方式。 智能体推理具有价值，Agent + BM25 的表现比原始 BM25 高 14.6 分；但这种价值更适合在全局排序得到候选文档之后发挥，而不是替代全局检索过程本身。

可以将 BM25 理解为一个高效的全局筛选器，能够先从整个文档库中快速找到候选资料；智能体则更适合在候选资料基础上进行阅读、交叉验证和推理。二者结合比单独依赖文件系统探索更有效。

不同问题类型上的表现

论文还按问题类型进行了细分分析。在 4.2 万份文档规模下：

File-System Agent 表现更好的类型：文档内推理、项目相关问题、完整性验证、冲突信息问题。例如在完整性验证题上，File-System Agent 得到 56 分，BM25 得到 27 分。这类问题通常需要跨多个文档进行检查和推理，智能体的迭代能力具有优势。
BM25 表现更好或相近的类型：其余五类问题，包括基础事实查找等。

这说明智能体方法并非没有价值。在某些需要多步推理和交叉验证的问题上，它在小规模条件下的优势是明确的。但在大规模语料库中，这种优势会受到证据发现能力下降的限制。

研究局限

论文也承认了若干局限，需要在理解结论时加以考虑：

1. 语料库类型单一。所有实验均基于 EnterpriseRAG-Bench 这一企业风格语料库完成。企业问题通常包含明确词法锚点，这一特征有利于 BM25。若换成更依赖语义理解、词法锚点较弱的问题集，结果可能不同。

2. 阅读模型单一。实验只使用了 Qwen3.6-27B 一个阅读模型。更强或不同类型的阅读模型可能影响各方法的相对表现。

3. 图方法的大规模失败部分涉及工程因素。图方法未能完整运行到大规模，部分原因在于构建工程尚未充分优化。不过论文也指出，即使硬件吞吐率提升，总构建工作量，即 token 数，并不会因此减少。

4. File-System Agent 只测试了一种实现形态。论文评估的是基于原始文件树探索的智能体方法，没有覆盖更复杂的搜索策略或更强的智能体系统设计。

启示

论文对企业 RAG 部署具有直接参考价值：

对于十万到百万级文档的企业知识库，BM25 可以作为一个稳健的默认检索选择。 它不需要大模型参与索引构建，查询成本低，且基本不随语料库规模增长；在该实验的大规模设置下，其准确率也优于其他方法。如果问题涉及复杂的多步推理，可以在 BM25 检索结果之上叠加智能体推理，即采用 Agent + BM25 的方式，而不是让智能体完全替代检索。

基于图的 RAG 在这一规模段面临较高的成本压力。 除非构建过程能够接近线性扩展，且应用场景中关系型问题占据主导，否则基于大模型的知识图谱构建在十万级文档以上较难证明其成本合理性。

更重要的方法论启示是：单一规模的评测可能掩盖方法之间的真实差异。 如果只观察最小规模，可能得出“智能体方法更优”的结论；如果只观察完整规模，则可能得出“BM25 更优”的结论。只有沿语料库规模变化观察完整曲线，才能识别方法表现的交叉点，并判断不同规模下的合适方案。

因此，RAG 方法评估不应只报告单一规模下的结果，而应系统呈现不同语料库规模下的准确率、成本和扩展趋势。

总体来看，这篇论文表明，在大规模企业知识库场景中，BM25 的优势并不来自更复杂的语义推理能力，而来自其在完整搜索空间中进行全局排序的机制。当搜索空间足够大时，全局检索能力往往比局部顺序探索更关键。这一结论不仅适用于文档检索，也为大规模信息获取系统的设计提供了参考。

paper: https://www.arxiv.org/abs/2607.26497