读论文 - BM25 Wins at Scale
内容提要
该论文评估了不同检索增强生成范式在企业级语料规模扩展下的性能。实验发现，当语料超过约1000万token时，BM25检索器优于密集向量检索和文件系统代理。文件代理在小规模下表现略好，但随着规模增大，因候选发现能力不足而失效。结合BM25候选发现的Agent方法效果最佳。图RAG方法因建库成本过高或准确率低而失败。结论是BM25负责全局候选排序，Agent负责在缩小后的范围内推理。
延伸解读
规模拐点：BM25 为何在千万 token 后反超
论文的核心发现是，当语料规模超过约 1000 万 token 时，BM25 的准确率反超密集向量检索和文件系统代理。这并非因为 BM25 语义能力更强，而是因为随着候选空间增大，全局词法排序比局部串行探索更稳定。文件系统代理在小规模下略优，但满规模时 any-gold hit rate 仅 39.0%，而 BM25 为 71.6%，说明其失败在于候选发现能力不足，而非阅读或推理能力。
Agent 的正确位置：在 BM25 候选上推理
实验表明，Agent+BM25 组合效果最佳，满规模时比文件系统代理高 32.52 分，比原生 BM25 高 14.56 分，且 token 成本约为文件系统代理的九分之一。这支持了工程结论：Agent 适合在 BM25 或混合检索的候选集合上进行改写、核验与综合，而非替代全局候选排序。但论文未做 Agent+Dense 对照，因此不能断言 BM25 天然优于 embedding 作为 Agent 的搜索工具。
图 RAG 的失败：建库成本与准确率双重瓶颈
图 RAG 方法（如 HippoRAG 2、MS-GraphRAG、LightRAG）在扩展实验中未能形成可部署方案。HippoRAG 2 在 131,876 文档时建图成本已高达 724M token，得分 41.0 低于 BM25 的 55.2；MS-GraphRAG 仅完成到 8,750 文档；LightRAG 在 2,826 文档时已无法完成。LinearRAG 成本可控但准确率低至约 29.8。因此，图 RAG 需同时满足准确率和部署成本，否则难以实用。
Q&A
BM25 Wins at Scale 这篇论文主要研究了什么？
该论文评估了七种检索增强生成范式在企业级语料规模扩展下的性能，发现当语料超过约1000万token时，BM25检索器优于密集向量检索和文件系统代理。
为什么文件系统代理在大规模语料下性能下降？
文件系统代理在小规模下表现略好，但随着规模增大，因候选发现能力不足而失效。满规模时其any-gold hit rate仅为39.0%，而BM25为71.6%，说明它难以在巨大的原始文件树中找到证据。
Agent+BM25 方法相比其他方法有什么优势？
Agent+BM25 方法效果最佳，满规模时比文件系统代理高32.52分，比原生BM25高14.56分，且token成本约为文件系统代理的九分之一。它结合了BM25的全局候选发现和Agent的推理能力。
论文中提到的图RAG方法（如HippoRAG 2、MS-GraphRAG）为什么失败？
图RAG方法因建库成本过高或准确率低而失败。例如，HippoRAG 2在131,876文档时需724M生成token建图，得分低于BM25；MS-GraphRAG完整语料估计需7.9B生成token；LightRAG建图增长超线性，完整语料估计需102B token。它们未能形成可部署的竞争方案。
论文对实际RAG系统建设有什么建议？
建议先建立BM25基线，再评估dense检索是否必要，并让Agent在候选集合上工作。图索引只在关系结构确实能提高目标任务且离线构建成本可接受时引入。
论文中的official combined score是如何计算的？
official combined score先判断答案是否与gold answer对齐，若不对齐则得0分；若对齐，则计算被覆盖且一致的原子事实比例。此外还记录alignment、completeness和document recall等指标。
