GraphRAG太慢LightRAG延遲高？華東師大新方法一招破解雙重難題
GraphRAG的索引速度慢，LightRAG的查詢延遲高？
這些影響效率的難題，現在終于迎來改進——
由華東師范大學李翔老師帶領的的Planing Lab團隊推出高效解決方法E2GraphRAG。
該方法在大部分測試中接近了最優的GraphRAG方法。
并且值得關注的是，該方法在構建索引時間上是GraphRAG的1/10，在查詢時間上是LightRAG的1/100。
動機與背景
現有的RAG方法中，大部分都是依賴于文本知識庫，通過向量檢索的方式，從中檢索到與問題相關的一些文檔片段作為補充知識。
這種方法難以實現對整個文檔知識庫的全局理解，比如通過普通RAG的方法，模型仍然無法回答“這篇小說的主旨是什么”這類問題。
為了解決對知識庫的全局理解問題，RAPTOR提出了先對文檔塊進行聚類，然后遞歸構建文檔總結樹，然后在這個文檔總結樹上進行向量查詢的方法，來引入不同粒度的信息；
GraphRAG則利用了大模型強大的信息抽取能力，由大模型從逐個文檔塊中抽取出三元組，然后構成一張圖，之后再通過圖分割算法分割成多個社區，再由大模型對社區進行總結，從而得到了不同粒度的信息。
然而，GraphRAG在圖構建以及查詢的過程中需要調用太多次大模型，導致其開銷過重，難以實用。
為了解決這一問題，LightRAG讓大模型一次性抽取出所有粒度的三元組，從而減少了總結不同社區帶來的大模型調用開銷；
FastGraphRAG則是在查詢的過程中利用了PageRank算法來聚合全局信息，從而避免了查詢時的大模型開銷。
但是這些方法仍然面臨一些問題：
每一個文檔塊需要調用一次大模型，帶來的開銷仍然相對較高；
嚴重依賴于大模型自身的能力，當模型參數量較小或者不支持Json格式輸出的時候，這些方法難以實現；
需要手動設置查詢模式，限制了其面對不同類型問題時的靈活性。
因此，本文中提出通過使用SpaCy來進行文檔中的實體識別，利用實體之間的句中共現關系構成一張圖，然后利用大模型對文檔塊按順序遞歸總結，將其構建成不同粒度的文檔總結樹，之后結合利用圖和樹來進行查詢，實現高效率、高性能。
方法
構建階段
首先和普通RAG一樣，先將長文檔進行分塊，本文中選取1200tokens一塊，相鄰塊間有100tokens的重疊，follow了LightRAG的實驗設置。然后構建階段主要有兩個任務：
利用LLM遞歸總結文檔樹：將文檔塊按照順序排列，每g個文檔塊一組，交給大模型來進行內容總結，由于文檔塊是連續的，這里的相鄰文檔塊之間的重疊可以合并，節約token消耗；
然后對于大模型生成的總結，繼續每g個一組，進一步總結，構成一個文檔樹。
通過這種方式，團隊得到了不同層次、不同粒度的信息，越接近根節點，信息越全局；
越接近葉子節點，信息越具體。
利用SpaCy抽取實體圖：對于每一個文檔塊，團隊利用SpaCy抽取其中的實體以及名詞（他們可能是潛在的實體的代稱），然后在同一句子內出現的實體以及名詞之間構建連邊，體現二者之間存在一定關系。
然后將所有的文檔塊對應的子圖合并到一起，構成一個針對整個文檔中的實體關系的實體圖。
同時，團隊構建兩個index，來描繪文檔和實體之間的關系，即文檔塊中抽取出哪些實體，一個實體能從哪些文檔塊中抽取出來。
通過這兩個任務，團隊得到了上圖中的四種數據結構以及兩個索引，即總結節點、文檔節點、實體、邊；以及實體到文檔塊的一對多索引，文檔塊到實體的一對多索引。
檢索階段
團隊的檢索方式可以根據問題的內容來自動選擇local or global的檢索方式，為了區分這兩種檢索方式，在下文中用斜體來表示global檢索，以示區分。
同時團隊提供了偽代碼，其中標
的是全局檢索的部分。
假設要檢索最多k個文檔塊，具體步驟如下：
- 利用SpaCy從問題中抽取出來實體，然后將這些實體兩兩組合（無序），假設有n個實體，團隊會得到*個候選實體對（即圖中Entity Extraction步驟）。
- 如果步驟1中不存在實體，那么認為這是一個全局的問題，同時無法利用實體信息來輔助檢索，直接通過向量檢索的方式，從文檔樹上檢索到相關的文檔塊。
- 候選實體對中肯定存在噪聲，因此拿它到團隊構建好的圖中去過濾，即兩個實體如果在圖中的距離超過h跳，那么就認為他們是無關的，將其排除（即圖中Graph Filtering步驟）。
- 根據上一步剩余的實體對數量，團隊如果有剩余的實體，進行5的local檢索，如果沒有，則執行步驟6的全局檢索：
- 如果有剩余的實體對，團隊利用實體到文檔塊的索引將每個實體對中的兩個實體映射到各自對應的文檔塊上，然后對這兩個文檔塊集合取交集，即得到了和這兩個實體均相關的文檔塊（即圖中的Index Mapping步驟）。
- 如果沒有剩余的實體對，那么也就意味實體并非緊密相關，那么這也更可能是一個全局查詢，因此團隊首先通過向量檢索檢索到樹上的top- 2k個相關的文檔塊作為候選；然后由于問題中也有實體，因此實體可以輔助進行查詢，即計算每一個候選文檔塊中實體的出現次數作為權重，如果這個候選文檔塊是總結塊，那么其對應的權重即為其子節點的權重之和，向下一直遞歸。這樣的設計自然會給總結塊更高的權重，自然符合了這是一個全局查詢的假設（即圖中的Occurrence Ranking步驟）。
- 如果步驟5返回了超過k個文檔， 那說明團隊的約束太松，因此團隊令h =h-1，然后重新執行步驟5，循環至只剩下不超過k個文檔。
- 如果步驟7返回了0個文檔，那么取縮緊約束之前的一個查詢結果，從其中進行篩選，具體篩選指標為：
- 看這個文檔包含了多少個不同的問題相關的實體；
- 看這個文檔中問題相關的實體出現了多少次。
團隊首先比較指標1，當指標1打平時，比較指標2，取最高的k個文檔作為結果。
最后團隊將其整理為實體1，實體2：文檔內容的形式，輸入給模型。
實驗結果
團隊在7-8B的相對易部署的模型上進行實驗，確保了該方法在資源受限的情況下仍然能夠有良好表現。
團隊發現，該方法達到了最短的索引構建時間，同時沒有帶來查詢的延遲。
在性能上，在大部分實驗設置下超過或者接近了最優的GraphRAG方法，實現了效率與性能的均衡。
值得關注的是，該方法在構建索引時間上是GraphRAG的1/10，在查詢時間上是LightRAG的1/100。
同時，團隊繪制了文檔token數量和構建索引時間的散點圖，并且擬合成直線。
團隊發現該方法構建索引時間隨著文檔token數量以最低的斜率線性增長，體現該方法可以擴展到更大的文檔上。
團隊進一步進行了消融實驗，三欄分別是：
- 針對團隊整體方法必要性的消融：只用向量檢索，確保團隊的local-global檢索系統是有效的；
- 針對local檢索的消融：分別以及同時消去Graph Filter以及Entity-aware Ranking，確保團隊的local檢索的部件是有效的；
- 針對global檢索的消融：分別以及同時消去Dense Retrieval以及Occurrence Ranking，發現在NovelQA上出現了一個異常的升高，可能是由于模型的幻覺導致的。
通過結合樹與圖，該團隊達成了GraphRAG效率與效果的平衡，在該方法中，圖主要用于信息點的關系發現以及過濾噪聲，而樹則主要用于提供具體不同粒度的信息內容，二者各有所長，相互依賴。
