這項由中國科學技術大學、北京元石科技和北京市農林科學院資訊技術研究中心聯合開展的研究,以預印本形式發布於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更好"。在中等規模上,兩者接近,如果在這裡停下,結論將是"兩者差不多"。只有跑完全程,才能看到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萬詞彙單元。因此除非業務場景明確以實體關係推理為主,單純因為數據量小就選擇圖譜方法,從成本收益角度來看並不合算。






