Planing Lab團隊 投稿
量子位 | 公眾號 QbitAI

GraphRAG的索引速度慢，LightRAG的查詢延遲高？

這些影響效率的難題，現(xiàn)在終于迎來改進——

由華東師范大學(xué)李翔老師帶領(lǐng)的的Planing Lab團隊推出高效解決方法E2GraphRAG

該方法在大部分測試中接近了最優(yōu)的GraphRAG方法。

并且值得關(guān)注的是，該方法在構(gòu)建索引時間上是GraphRAG的1/10，在查詢時間上是LightRAG的1/100

動機與背景

現(xiàn)有的RAG方法中，大部分都是依賴于文本知識庫，通過向量檢索的方式，從中檢索到與問題相關(guān)的一些文檔片段作為補充知識。

這種方法難以實現(xiàn)對整個文檔知識庫的全局理解，比如通過普通RAG的方法，模型仍然無法回答“這篇小說的主旨是什么”這類問題。

為了解決對知識庫的全局理解問題，RAPTOR提出了先對文檔塊進行聚類，然后遞歸構(gòu)建文檔總結(jié)樹，然后在這個文檔總結(jié)樹上進行向量查詢的方法，來引入不同粒度的信息；

GraphRAG則利用了大模型強大的信息抽取能力，由大模型從逐個文檔塊中抽取出三元組，然后構(gòu)成一張圖，之后再通過圖分割算法分割成多個社區(qū)，再由大模型對社區(qū)進行總結(jié)，從而得到了不同粒度的信息。

然而，GraphRAG在圖構(gòu)建以及查詢的過程中需要調(diào)用太多次大模型，導(dǎo)致其開銷過重，難以實用。

為了解決這一問題，LightRAG讓大模型一次性抽取出所有粒度的三元組，從而減少了總結(jié)不同社區(qū)帶來的大模型調(diào)用開銷；

FastGraphRAG則是在查詢的過程中利用了PageRank算法來聚合全局信息，從而避免了查詢時的大模型開銷。

但是這些方法仍然面臨一些問題：

每一個文檔塊需要調(diào)用一次大模型，帶來的開銷仍然相對較高；

嚴(yán)重依賴于大模型自身的能力，當(dāng)模型參數(shù)量較小或者不支持Json格式輸出的時候，這些方法難以實現(xiàn)；

需要手動設(shè)置查詢模式，限制了其面對不同類型問題時的靈活性。

因此，本文中提出通過使用SpaCy來進行文檔中的實體識別，利用實體之間的句中共現(xiàn)關(guān)系構(gòu)成一張圖，然后利用大模型對文檔塊按順序遞歸總結(jié)，將其構(gòu)建成不同粒度的文檔總結(jié)樹，之后結(jié)合利用圖和樹來進行查詢，實現(xiàn)高效率、高性能。

方法

構(gòu)建階段

首先和普通RAG一樣，先將長文檔進行分塊，本文中選取1200tokens一塊，相鄰塊間有100tokens的重疊，follow了LightRAG的實驗設(shè)置。然后構(gòu)建階段主要有兩個任務(wù)：

利用LLM遞歸總結(jié)文檔樹：將文檔塊按照順序排列，每g個文檔塊一組，交給大模型來進行內(nèi)容總結(jié)，由于文檔塊是連續(xù)的，這里的相鄰文檔塊之間的重疊可以合并，節(jié)約token消耗；

然后對于大模型生成的總結(jié)，繼續(xù)每g個一組，進一步總結(jié)，構(gòu)成一個文檔樹。

通過這種方式，團隊得到了不同層次、不同粒度的信息，越接近根節(jié)點，信息越全局；

越接近葉子節(jié)點，信息越具體。

利用SpaCy抽取實體圖：對于每一個文檔塊，團隊利用SpaCy抽取其中的實體以及名詞（他們可能是潛在的實體的代稱），然后在同一句子內(nèi)出現(xiàn)的實體以及名詞之間構(gòu)建連邊，體現(xiàn)二者之間存在一定關(guān)系。

然后將所有的文檔塊對應(yīng)的子圖合并到一起，構(gòu)成一個針對整個文檔中的實體關(guān)系的實體圖。

同時，團隊構(gòu)建兩個index，來描繪文檔和實體之間的關(guān)系，即文檔塊中抽取出哪些實體，一個實體能從哪些文檔塊中抽取出來。

通過這兩個任務(wù)，團隊得到了上圖中的四種數(shù)據(jù)結(jié)構(gòu)以及兩個索引，即總結(jié)節(jié)點、文檔節(jié)點、實體、邊；以及實體到文檔塊的一對多索引，文檔塊到實體的一對多索引。

檢索階段

團隊的檢索方式可以根據(jù)問題的內(nèi)容來自動選擇local or global的檢索方式，為了區(qū)分這兩種檢索方式，在下文中用斜體來表示global檢索，以示區(qū)分。

同時團隊提供了偽代碼，其中標(biāo)??的是全局檢索的部分。

假設(shè)要檢索最多k個文檔塊，具體步驟如下：

1. 利用SpaCy從問題中抽取出來實體，然后將這些實體兩兩組合（無序），假設(shè)有n個實體，團隊會得到*個候選實體對（即圖中Entity Extraction步驟）。
2. 如果步驟1中不存在實體，那么認(rèn)為這是一個全局的問題，同時無法利用實體信息來輔助檢索，直接通過向量檢索的方式，從文檔樹上檢索到相關(guān)的文檔塊。
3. 候選實體對中肯定存在噪聲，因此拿它到團隊構(gòu)建好的圖中去過濾，即兩個實體如果在圖中的距離超過h跳，那么就認(rèn)為他們是無關(guān)的，將其排除（即圖中Graph Filtering步驟）。
4. 根據(jù)上一步剩余的實體對數(shù)量，團隊如果有剩余的實體，進行5的local檢索，如果沒有，則執(zhí)行步驟6的全局檢索：
5. 如果有剩余的實體對，團隊利用實體到文檔塊的索引將每個實體對中的兩個實體映射到各自對應(yīng)的文檔塊上，然后對這兩個文檔塊集合取交集，即得到了和這兩個實體均相關(guān)的文檔塊（即圖中的Index Mapping步驟）。
6. 如果沒有剩余的實體對，那么也就意味實體并非緊密相關(guān)，那么這也更可能是一個全局查詢，因此團隊首先通過向量檢索檢索到樹上的top- 2k個相關(guān)的文檔塊作為候選；
   然后由于問題中也有實體，因此實體可以輔助進行查詢，即計算每一個候選文檔塊中實體的出現(xiàn)次數(shù)作為權(quán)重，如果這個候選文檔塊是總結(jié)塊，那么其對應(yīng)的權(quán)重即為其子節(jié)點的權(quán)重之和，向下一直遞歸。
   這樣的設(shè)計自然會給總結(jié)塊更高的權(quán)重，自然符合了這是一個全局查詢的假設(shè)（即圖中的Occurrence Ranking步驟）。
7. 如果步驟5返回了超過k個文檔， 那說明團隊的約束太松，因此團隊令h =h-1，然后重新執(zhí)行步驟5，循環(huán)至只剩下不超過k個文檔。
8. 如果步驟7返回了0個文檔，那么取縮緊約束之前的一個查詢結(jié)果，從其中進行篩選，具體篩選指標(biāo)為：

• 看這個文檔包含了多少個不同的問題相關(guān)的實體；
• 看這個文檔中問題相關(guān)的實體出現(xiàn)了多少次。

團隊首先比較指標(biāo)1，當(dāng)指標(biāo)1打平時，比較指標(biāo)2，取最高的k個文檔作為結(jié)果。

最后團隊將其整理為實體1，實體2：文檔內(nèi)容的形式，輸入給模型。

實驗結(jié)果

團隊在7-8B的相對易部署的模型上進行實驗，確保了該方法在資源受限的情況下仍然能夠有良好表現(xiàn)。

團隊發(fā)現(xiàn)，該方法達到了最短的索引構(gòu)建時間，同時沒有帶來查詢的延遲。

在性能上，在大部分實驗設(shè)置下超過或者接近了最優(yōu)的GraphRAG方法，實現(xiàn)了效率與性能的均衡。

值得關(guān)注的是，該方法在構(gòu)建索引時間上是GraphRAG的1/10，在查詢時間上是LightRAG的1/100。

同時，團隊繪制了文檔token數(shù)量和構(gòu)建索引時間的散點圖，并且擬合成直線。

團隊發(fā)現(xiàn)該方法構(gòu)建索引時間隨著文檔token數(shù)量以最低的斜率線性增長，體現(xiàn)該方法可以擴展到更大的文檔上。

團隊進一步進行了消融實驗，三欄分別是：

• 針對團隊整體方法必要性的消融：只用向量檢索，確保團隊的local-global檢索系統(tǒng)是有效的；
• 針對local檢索的消融：分別以及同時消去Graph Filter以及Entity-aware Ranking，確保團隊的local檢索的部件是有效的；
• 針對global檢索的消融：分別以及同時消去Dense Retrieval以及Occurrence Ranking，發(fā)現(xiàn)在NovelQA上出現(xiàn)了一個異常的升高，可能是由于模型的幻覺導(dǎo)致的。

通過結(jié)合樹與圖，該團隊達成了GraphRAG效率與效果的平衡，在該方法中，圖主要用于信息點的關(guān)系發(fā)現(xiàn)以及過濾噪聲，而樹則主要用于提供具體不同粒度的信息內(nèi)容，二者各有所長，相互依賴。

論文地址：https://arxiv.org/abs/2505.24226
代碼倉庫：https://github.com/YiboZhao624/E-2GraphRAG

— 完 —