
这项由中国科学技术大学、北京元石科技和北京市农林科学院信息技术研究中心联合开展的研究,以预印本形式发布于2026年7月,论文编号为arXiv:2607.26497,有兴趣深入了解的读者可通过该编号查询完整论文。
**一个你可能没想过的问题**
假设你是一家大公司的IT主管,公司内部积累了几十万份文件——员工聊天记录、项目工单、邮件、会议纪要、代码审查记录……你想搭建一个"智能助手",让员工能用自然语言提问,系统自动从这些文件里找到答案。现在市面上有一堆方案:有用传统关键词搜索的,有用AI向量搜索的,有用"知识图谱"构建复杂关系网络的,还有让AI像侦探一样自己翻文件夹的。哪个最好?
大多数人会本能地觉得:越先进越好,用图谱、用Agent,总比老古董关键词搜索强吧?
这支研究团队决定认真测一测这个问题——而且他们的测试方式,和以往所有评测都不一样。
**一、问题的根源:大家都在"单场比赛"里评判选手**
以往的AI检索评测,通常是这样的:在一个固定大小的文档库上,跑一跑各种方法,看谁的准确率高。这就像只看运动员在100米短跑里的表现,就判断谁适合当马拉松冠军。
问题在于,现实中的企业文档库不是固定的。它们会不断增长,从几千份文件变成几万份、几十万份。不同检索方法在文档量小的时候可能差距不大,但随着文档量增长,各自的优劣会发生根本性的变化——有的方法越跑越强,有的方法越跑越喘不过气。
研究团队称这种现象为"规模相关的拐点"。他们想知道:当文档量从小变大,各种方法的准确率曲线会怎么走?什么时候会发生你追我赶的超越?
为了回答这个问题,他们设计了一个极其严格的实验——就像在同一条赛道上,让所有选手在不同天气条件下反复比赛,而不是换不同的赛道、换不同的裁判、换不同的规则。
**二、实验的搭建:一条28级的"文档楼梯"**
实验的基础是一个叫做"EnterpriseRAG-Bench"的企业知识库测试集,里面有511,959份文档,总计约6亿个词汇单元(token),内容涵盖维基百科页面、员工即时通讯记录、项目工单、电子邮件、会议录音转写、客户关系管理记录和代码审查——这模拟了一家真实公司的完整知识积累。测试集还提供了500道题,题型从简单的信息查找到"公司里有没有相互矛盾的政策"这样的复杂判断,覆盖十种不同难度。
研究团队构建的"文档楼梯"是这样运作的:最底层只有1,144份文档(这是"基岩层"),每往上一级,文档量乘以约1.25倍,一共28级,最顶层就是全部511,959份文档。这1,144份基岩层文档绝对不会变——500道题的"标准答案文档"全在里面,此外还有精心设计的"陷阱文档"和"诱饵文档",专门用来迷惑检索系统。随着楼梯往上爬,增加的只是背景噪音文档,让问题越来越难找。
基岩层里的陷阱文档(326份)尤其精妙。研究团队通过两种搜索方式分别提名候选文档,再用语言模型筛选出那些"主题相关但事实错误"的文档——比如针对某项决策的查询,陷阱文档里写的是错误的日期、版本号或最终结论。这样一来,一个系统如果靠"语义相近就行"的逻辑,很容易被陷阱文档欺骗。另有99份"诱饵文档"专门对应那些本来就没有答案的问题,确保AI无法靠"没搜到相关内容就等于问题无解"来蒙混过关。
整个实验的严格控制体现在:所有方法用同一个阅读模型(Qwen3.6-27B,一种270亿参数的大语言模型)生成答案,用同一套打分规则评估准确率,用同一个计量层记录每个步骤消耗的计算资源。这消除了"张三用了更聪明的AI所以分数高"这种干扰因素。
**三、四种选手,各怀绝技**
研究团队在这条文档楼梯上测试了七个具体系统,代表四种主要的检索增强生成(RAG)路线。
第一种是BM25——这是一个诞生于上世纪80年代的经典关键词搜索算法,工作原理类似于图书馆的卡片目录:你搜"季度财报",它就找包含这些词最多的文档,按相关性排序,不需要任何AI参与,建立索引几乎不花钱。
第二种是DenseRAG(密集检索)——它把每份文档和每个问题都变成一个数学向量,向量之间的距离代表语义相似度。建立索引需要用嵌入模型(embedding model)处理每份文档,成本比BM25高一些,但理论上能理解语义上相近但用词不同的查询。
第三种是图谱系RAG——这一类方法会在建库阶段用AI把文档里的所有实体(人名、项目名、术语)和它们之间的关系抽取出来,构建一张"知识网络",查询时沿着这张网络找答案。实验测试了四种图谱方法:MS-GraphRAG用层级社区报告来组织知识;LightRAG维护双层实体关系索引;HippoRAG 2通过个性化PageRank(一种类似Google网页排名的算法)在图上游走找到相关事实;LinearRAG则跳过生成式AI,改用轻量级命名实体识别工具加嵌入模型来建图,省去了大部分AI计算成本。
第四种是文件系统Agent——这位选手完全不建任何索引,而是像一个人类助手拿到一个硬盘之后,靠自己的判断逐步翻文件夹、用关键词搜索、打开文件阅读来找答案。每个问题最多允许调用80次AI工具操作,具体操作包括列出目录内容、关键词搜索和读取文件。
**四、比赛结果:一个出人意料的交叉点**
在最底层的1,144份文档(基岩层)上,文件系统Agent和BM25并列领先,分别得了77.4分和74.7分(满分100分)。这两个分数的统计误差范围有重叠,可以认为基本平手。图谱系方法里表现最好的HippoRAG 2拿了66.2分,MS-GraphRAG和LightRAG在45至48分区间,DenseRAG得58.1分。
随着文档楼梯往上爬,局势发生了变化。文件系统Agent的得分随文档量增加而加速下滑,而BM25则相对稳健。在大约1,000万个词汇单元的规模附近(对应约8,750到10,970份文档),BM25的分数曲线和Agent的曲线发生了交叉,此后BM25一路领先。到达顶层的全部511,959份文档时,BM25还保持在50.5分,而文件系统Agent只剩30.7分,DenseRAG29.9分——BM25的领先优势接近20分。
这个拐点是实验的核心发现。它不是某个理论预测,而是在28个严格嵌套的文档规模上实际测量出来的曲线交叉。
**五、为什么文件系统Agent会"崩"?**
要理解这件事,可以把文件系统Agent比作一个侦探,在一个存满文件盒的仓库里寻找特定案件的线索。当仓库只有两三排货架时,侦探可以系统地翻一翻,甚至凭借灵感直觉找到角落里的关键文件,效率不低。但当仓库扩展到整整一栋大楼的几十万个文件盒时,同样是一个人、同样的时间限制,能翻到的比例就变得微乎其微,而且越找越容易找偏。
数据上的体现是:在基岩层,文件系统Agent平均消耗226,000个词汇单元来完成每道题的查找和回答;到21,614份文档这一层,这个数字增长到343,000——已经是BM25每题5,800个词汇单元的59倍。工具调用次数从中位数5次增长到8次,预算耗尽(80次调用不够用)的比例在131,876份文档时达到15%,在全量文档时达到31%。更严峻的是,即使没有耗尽预算、顺利作答的那些问题,准确率也在下滑——说明问题不仅仅是"没找完",而是"找的方向本来就越来越难对"。
原因在于Agent的搜索方式是局部的、串行的:每一步的决策依赖前一步的结果,而前一步的结果又受到当前文档规模下"哪些路径更显眼"的影响。文档库越大,相关文件在整个目录结构里的占比越低,Agent越难导航到正确的分支。
BM25则完全不同——它把整个文档库的词频信息一次性建成倒排索引,每次查询都相当于同时扫描所有文档,任何包含相关词汇的文档都有机会被排到前列。文档库从1万份扩展到50万份,BM25的单次查询成本几乎不变,因为它的工作原理本来就是全局排序而非局部探索。
**六、图谱方法的"建设工期"问题**
图谱系方法的处境则是另一种困境——它们甚至没能跑完所有28级楼梯。
MS-GraphRAG在8,750份文档时就遭遇了资源上限,后续规模的数据无法完成建库。研究团队测量了它的建库成本增长规律,发现它近似线性增长(指数约为0.92),按这个趋势推算到全量60亿词汇单元的文档库,需要消耗约79亿词汇单元的AI生成调用,折合约50个实例天——哪怕用多台服务器并行也只能缩短日历时间,无法减少总计算量,而且并行建库通常还会引入更多不一致性问题。
LightRAG的情况更糟。它在2,826份文档时就已无法在合理资源内完成建库,而且它的建库成本增长是超线性的(指数为1.36),推算到全量数据需要约102,000亿词汇单元,相当于一台服务器跑四年。即使用三倍算力,也要超过一年。LightRAG之所以超线性增长,是因为它在每加入新文档时需要反复更新全局实体合并表,文档越多、合并次数越多、每次合并涉及的历史数据越多,形成了雪球效应。
HippoRAG 2的增长更接近线性(指数为1.01),能撑到131,876份文档才遭遇瓶颈,推算到全量大约需要三天。但即便如此,在它能完成的最大规模(154.7M词汇单元)上,它的得分是41.0分,比同规模下的BM25低约15分。
LinearRAG走了一条"平价路线"——完全不用生成式AI来建库,只用轻量命名实体识别工具加嵌入模型,建库成本低到接近DenseRAG,但最终准确率也只有46.2分(基岩层),与其他图谱方法相差无几。这暗示了一个有趣的结论:在这个测试场景里,花高价用AI抽取实体关系,并不比便宜的替代方案带来显著的准确率提升。
**七、分开来看:Agent的能力是真实的,只是用错了地方**
一个关键问题是:文件系统Agent的失败,是因为"AI推理能力弱",还是因为"搜索方式不对"?
研究团队设计了一个精巧的对照实验来分离这两个因素。他们创建了一个叫"Agent+BM25"的混合方案:保持与文件系统Agent完全相同的AI模型、相同的推理框架、相同的80次调用预算,但把"自己翻文件夹"的工具替换成"BM25关键词搜索"工具。第一次搜索被强制使用原始问题,确保返回的前5个结果和直接用BM25完全一致,之后的搜索才允许Agent自由发挥。
结果非常显著。在基岩层,文件系统Agent得87.1分,直接BM25得81.3分,Agent+BM25得90.1分,三者接近。但到全量文档时,文件系统Agent跌到36.9分,BM25保持54.8分,Agent+BM25则达到69.4分——比纯Agent高出32.5分,也比纯BM25高出14.6分。
从资源消耗看,Agent+BM25每题只用101,000词汇单元,是文件系统Agent(895,000词汇单元)的九分之一,平均工具调用次数也从36次降到5.79次。换句话说,给Agent配上全局搜索能力之后,它反而变得更高效、更准确,因为它不再需要在巨大的文件迷宫里盲目摸索,而是先得到一张"全局候选地图",再在地图上做针对性的深入探索。
这个发现的意义在于:Agent的推理能力本身是有价值的,特别是在需要综合多个文档信息、解决矛盾、完成多步骤任务的场景里。但这种能力需要建立在"先把候选文档找对"的基础上,不能期待它在海量文档里凭空定位到正确信息。
**八、不同题型,各有强弱**
研究团队还在42,587份文档的规模上,按问题类型拆分了各方法的得分。这一层数据揭示了BM25和Agent各自的优势领域。
在基础信息查找、语义理解和与上下文无关的事实确认类题目上,BM25占优或持平。这类题目通常有清晰的关键词线索,BM25的精确词汇匹配恰好对症下药。
文件系统Agent则在四类题目上领先:单文档内的细节提取(56分对BM25的27分,差距悬殊)、项目相关问题、需要确认某份文档是否"完整覆盖某个话题"的完整性判断题,以及需要识别文档间相互矛盾的冲突信息题。这些题型的共同特点是:需要在拿到候选文档后做更深入的推理和综合,而不仅仅是把搜到的片段拼凑在一起。
这与"Agent+BM25"的设计理念完全契合:用BM25完成全局候选文档发现,再用Agent的推理能力处理需要深度理解的问题类型。
在"信息不存在"类问题(即正确答案是"这个问题在文档库里找不到答案")上,BM25和Agent的得分都很高,但原因不同。BM25因为没找到相关证据就不作答,符合预期。Agent有时候会在没有证据的情况下仍然编造答案,不过总体上随着规模增大这个问题反而因为Agent整体准确率下滑而不再突出。
**九、词汇优势:BM25为什么特别适合企业文档**
研究团队还做了一系列控制实验来检验BM25的领先是否来自"刷题优势"——毕竟测试问题里的用词可能和文档里的用词高度重叠,对关键词搜索天然有利。
他们专门用改写后的同义表达版本重新提问("换个说法问同一个问题"),再次比较各方法的表现。结果BM25在改写版问题下确实有所下滑,但仍然优于DenseRAG和图谱方法。此外,他们还把检索深度从前5个文档扩展到前10个文档,在这个条件下BM25得分进一步提升到81至83分,DenseRAG提升到66至70分,HippoRAG 2在有数据的规模下提升到73分。
这说明BM25的优势并非纯粹来自问题措辞与文档词汇的机械匹配,而是它确实更擅长在企业类文档场景里定位到正确文档。研究团队给出的解释是:企业文档里充满了精确的专有名词——项目代码、产品版本号、人名、日期、决策编号——这些信息在语义空间里和"相关但事实错误"的内容非常接近(DenseRAG很难把"v2.3正式版"和"v2.3测试版"区分开),但在词汇层面一眼即辨。陷阱文档专门针对的就是语义相近但事实有误的内容,BM25的精确匹配机制天然地抵御了这类干扰。
图谱方法在陷阱文档面前则格外脆弱:知识图谱搜索的是语义邻近的实体和关系,而陷阱文档在知识图谱的拓扑结构里往往和正确文档毗邻,几乎无法区分。
**十、成本全貌:谁更"经济实惠"**
把准确率和成本放在一起看,可以得到一个直观的效率地图。
BM25的建库成本是零AI计算(只有CPU时间,不调用任何AI模型),每道题的查询消耗约5,800词汇单元。DenseRAG建库需要6.594亿词汇单元的嵌入计算,每题查询约4,900词汇单元,略低于BM25(因为文档截断更积极),但准确率显著低于BM25。文件系统Agent不需要建库,但每题查询成本随规模急剧增长,在全量文档时达到每题近90万词汇单元。HippoRAG 2建库需要约7.5百万词汇单元(基岩层),每题查询6,500词汇单元,准确率在能建出来的规模上介于BM25和DenseRAG之间。MS-GraphRAG和LightRAG的建库成本分别达到3.51亿和3.46亿词汇单元(基岩层已如此),之后随规模快速膨胀。
把500道题的查询开销和建库开销合并计算,BM25在覆盖范围从10到10,000道题的所有场景下,都处于"准确率-总成本"的帕累托前沿——即在相同成本下没有其他方法能做到更高的准确率,在相同准确率下也没有更便宜的方法。
**十一、图谱方法失败的三重原因**
研究团队对图谱方法的失败给出了系统性的解释,这三重原因相互叠加,让图谱路线在当前测试场景下难以发挥优势。
第一重是抽取噪音。在基岩层1,144份文档的建库中,图谱方法抽取出了3.2万个实体,其中包含大量格式错误的碎片——截断的句子片段、混入了文档格式标记的伪实体、同一实体的多种拼写变体。这些噪音实体在图谱里形成了虚假的连接,查询时容易被误导到无关节点。
第二重是语义陷阱的放大效应。图谱检索的核心逻辑是"找到和查询实体相邻的知识节点",而陷阱文档里的错误信息(同一实体,但属性值不同)在图谱拓扑上和正确文档几乎无法区分,导致图谱检索经常返回内容相关但事实错误的片段。
第三重是信息蒸发。HippoRAG 2在构建三元组时丢弃了谓词的完整文本,只保留实体本身——这意味着精确的关系语义(比如"批准了"还是"否决了"、"升级到"还是"降级到")在建库过程中就已经消失,查询时无法恢复。
LinearRAG绕过了前两重问题(轻量NER噪音较少,不依赖生成式AI的语义理解),但由于图谱本身缺乏精确的关系语义,最终效果与花费数十倍成本的LLM图谱方法相差无几,这本身就是一个说明"LLM建图未必值得"的间接证据。
**十二、对评测方法论本身的启示**
这项研究顺带揭示了一个评测层面的系统性盲点:如果只在一个固定文档规模上比较各种方法,很可能得到完全错误的结论。
在最小规模(基岩层)上,文件系统Agent是领先的,如果评测就在这里停下,结论将是"Agent比BM25更好"。在中等规模(约1,000万词汇单元)上,两者接近,如果在这里停下,结论将是"两者差不多"。只有跑完全程,才能看到BM25在大规模下的持续领先。
同理,图谱方法通常在自己的发布论文里使用精心挑选的小规模数据集评测,这些数据集往往没有针对性的陷阱文档,也不会测试几十万份文档的场景——这自然会让图谱方法在论文里显得很好看,但不能反映它们在真实部署场景下的表现。
研究团队因此建议:跨范式的检索评测应当同时报告多个规模下的准确率、建库和查询成本,以及各方法实际能完成的文档覆盖范围。"在能建出索引的规模下,准确率是多少"和"在企业实际部署规模下,有没有能建出的索引"是两个不同的问题,必须分开回答。
**说到底,这告诉了我们什么?**
归根结底,这项研究用扎实的数据回答了一个很多人不敢直接面对的问题:在大规模企业文档检索场景里,一个40多年前发明的关键词搜索算法,在综合准确率和成本的维度上,仍然是目前最强的默认选择。
这并不意味着新技术没有价值。Agent的多步推理能力在某些需要深度理解的题型上确实更出色,但这种能力在配合全局搜索(比如BM25)之后才能充分发挥,单独使用反而因为搜索方式的局限而大幅受损。图谱方法的知识结构化理念在某些特定场景(比如关系推理密集、实体连接清晰的领域)有其价值,但在构建成本、噪音抵御和语义精确性方面还存在明显的工程挑战,特别是在文档量达到企业实际部署规模时。
对于正在考虑搭建企业内部知识检索系统的团队,这项研究给出了一个相当明确的工程建议:从BM25开始,它几乎不花钱建库,查询成本可预期,准确率在大规模下优于其他方案;如果业务里有大量需要综合多文档信息、解决矛盾或判断完整性的问题,可以在BM25检索的基础上叠加Agent的深度推理能力;在文档量还未达到百万量级之前,LLM图谱建库的高成本很难通过准确率收益来弥补。
当然,这项研究基于特定的企业文档类型(模拟公司的混合文档库)、特定的问题集和特定的底层模型,在其他领域(比如需要复杂关系推理的科学文献库)结论可能有所不同。研究团队也坦诚地指出了这一点。对于这个问题有更多好奇心的读者,可以通过arXiv:2607.26497查阅完整论文,数据和代码也作为实验补充材料随论文一同发布。
---
Q&A
Q1:BM25是什么,为什么说它是"已过时的算法"?
A:BM25是一种发明于上世纪80年代的关键词搜索算法,原理类似图书馆卡片目录——你搜某个词,它就找包含这些词频率最高的文档并排序。之所以有人认为它"过时",是因为它不能理解语义,比如不知道"汽车"和"轿车"是相关的,只能靠精确词汇匹配工作。但这项研究发现,在企业文档场景里,精确匹配反而是优势,因为专业术语、版本号、项目代码这类关键信息用语义搜索很难精确区分,BM25反而能一眼辨别。
Q2:Agent+BM25比单独使用BM25准确率更高,那应该直接用Agent+BM25替代BM25吗?
A:不一定。Agent+BM25确实在全量文档下得了69.4分,比纯BM25的54.8分高出约15分,但代价是每道题的计算消耗从5,800词汇单元增长到101,000词汇单元,大约是18倍。如果问题类型以简单信息查找为主,增加的成本难以通过准确率提升来弥补;如果问题需要综合多文档信息、识别矛盾或判断文档完整性,Agent+BM25的额外推理能力才更有价值。实际使用中可以根据问题类型动态决定是否调用Agent。
Q3:图谱RAG在小规模文档上表现如何,是不是数据量少就该用图谱方法?
A:图谱方法在小规模上确实比大规模上表现更接近BM25,但即便在最小的1,144份文档基岩层上,HippoRAG 2只得了66.2分,仍比BM25的74.7分低约8分,而MS-GraphRAG和LightRAG只有45至48分。此外,即使在小规模上建库成本也并不低,基岩层的MS-GraphRAG建库就消耗了3,510万词汇单元。因此除非业务场景明确以实体关系推理为主,单纯因为数据量小就选择图谱方法,从成本收益角度来看并不合算。