前面了解了RAG的開山之作，今天來看下微軟提出的GraphRAG是如何提升RAG性能的。

首先了解下研究動機：

傳統(tǒng)的RAG方法在處理局部信息檢索方面表現(xiàn)出色，但對于涉及整個文本語料庫的全局性問題，如“數(shù)據(jù)集中有哪些主要主題？”這樣的問題，它們的表現(xiàn)不佳。

更合適的任務(wù)框架應(yīng)當是查詢聚焦型摘要（Query-Focused Summarization，QFS），特別是抽象式摘要，它可以生成自然語言的總結(jié)而不僅僅是摘錄片段。隨著LLM的發(fā)展，GPT、Llama 和 Gemini 系列等模型可以通過上下文學習來總結(jié)任何在其上下文窗口內(nèi)提供的內(nèi)容，但是，對于需要對整個語料庫進行查詢聚焦型抽象摘要的情況，尤其是當文本量遠超出了LLM上下文窗口的限制時，仍然存在挑戰(zhàn)。

研究人員希望結(jié)合兩種方法的優(yōu)點，即RAG的精確性和QFS的大規(guī)模文本處理能力，以更有效地回答全局性質(zhì)的問題。

因此，來自微軟的研究團隊提出GraphRAG，利用LLM構(gòu)建了一個基于圖的文本索引。此索引不僅包括節(jié)點（例如實體），還包括邊（例如關(guān)系）和協(xié)變量（例如聲明）。通過這種方法，Graph RAG能夠更好地捕捉文本之間的關(guān)聯(lián)，并支持對大規(guī)模文本集合的全局理解和摘要。

項目地址：https://aka.ms/graphrag

下面詳細介紹下方法實現(xiàn)：

1、方法介紹

圖1為GraphRAG的pipeline和實現(xiàn)細節(jié)，主要分為以下幾個部分：

源文檔（Source Documents） → 文本塊（Text Chunks）

拿到一個文檔，無論是構(gòu)建一個圖譜還是傳統(tǒng)的RAG方法，第一步都是從原始文檔中提取文本，并將其分割成適合后續(xù)處理的文本塊。

這里就涉及到文本塊的分割粒度問題：較長文本塊，減少對LLM的調(diào)用次數(shù)，但可能由于LLM上下文窗口長度的限制而導(dǎo)致召回率下降。較短文本塊，雖然增加了調(diào)用次數(shù)，但有助于保持較高的召回率，因為每個塊的信息量較小，更容易完整地捕捉到其中的關(guān)鍵信息。

如圖2，在 HotPotQA 數(shù)據(jù)集上，單輪提取的情況下，使用600 token大小的文本塊幾乎可以提取兩倍于2400 token大小文本塊的實體引用數(shù)量。這是因為較長的文本塊可能會導(dǎo)致某些重要信息“丟失在中間”，特別是在LLM上下文窗口長度固定的情況下。

這里作者沒有給出實際的分塊方法，實際上，根據(jù)具體應(yīng)用場景的需求來選擇合適的文本塊大小。通常來說，較小的文本塊更適合保證高召回率，而較大的文本塊則可能更經(jīng)濟高效，尤其是在處理非常大的文檔集合時。為了確保連續(xù)文本塊之間不會遺漏重要的上下文信息，可以在相鄰文本塊之間設(shè)置一定的重疊。例如，在論文中提到的數(shù)據(jù)集處理中，文本塊大小為600 tokens，且相鄰塊之間有100 tokens的重疊。

文本塊 → 元素實例（Element Instances）

在劃分好文本塊之后，一個基本要求是從每個文本塊中識別并抽取圖節(jié)點和邊的實例。

具體來說，通過一個多部分的LLM提示來完成，首先識別所有實體（包括名稱、類型和描述），然后識別清楚相關(guān)的實體之間的關(guān)系（包括源實體、目標實體及其關(guān)系描述）。最后，所有類型的元素實例（實體和關(guān)系）都被組織成一個統(tǒng)一的、由分隔符分隔的元組列表輸出。

為了使提示適應(yīng)特定領(lǐng)域的文檔語料庫，可以為LLM提供用于上下文學習的少量示例。例如，默認提示可能適用于廣泛類別的“命名實體”（如人名、地名、組織名），但對于具有專業(yè)知識的領(lǐng)域（如科學、醫(yī)學、法律等），則可以通過提供專門化的示例來優(yōu)化提取效果。另外，還支持對與提取的節(jié)點實例關(guān)聯(lián)的任何附加協(xié)變量進行二次提取。默認協(xié)變量提示旨在提取與檢測到的實體相關(guān)聯(lián)的聲明，包括主題、對象、類型、描述、源文本跨度以及開始和結(jié)束日期。

為了平衡效率和質(zhì)量，使用多個“gleaning”輪次來鼓勵LLM捕捉任何之前可能遺漏的實體。這是一個多階段的過程：

• 評估完整性：首先詢問LLM是否所有實體都已被提取，使用logit偏置強制模型做出二選一的回答（是/否）。
• 繼續(xù)挖掘：如果LLM回答有實體被遺漏，則通過提示告知“上次提取中遺漏了許多實體”，促使LLM補充這些遺漏的實體。
• 實驗驗證：這種方法允許使用較大的文本塊而不降低質(zhì)量或引入噪音，如圖2所示，在HotPotQA數(shù)據(jù)集上，600 token大小的文本塊幾乎能提取兩倍于2400 token大小文本塊的實體引用數(shù)量，但通過增加遍歷次數(shù)（gleanings），可以顯著提升較大文本塊上的實體檢測數(shù)量和質(zhì)量。

元素實例 → 元素摘要（Element Summaries）

使用LLM“提取”源文本中的實體、關(guān)系和聲明描述實際上已經(jīng)是一種抽象摘要生成的形式。這意味著LLM不僅僅是在簡單地識別這些元素，而是在創(chuàng)造獨立有意義的概念摘要。這些概念可能是隱含的，而不是由文本本身明確陳述的（例如，隱含關(guān)系的存在）。

為了將所有此類實例級摘要轉(zhuǎn)換為每個圖元素（即實體節(jié)點、關(guān)系邊和聲明協(xié)變量）的單個描述性文本塊，需要對匹配的實例組進行進一步的LLM摘要生成。這個過程確保了每個圖元素都有一個單一、連貫且描述性的文本塊，從而提高了信息的清晰度和組織性。

這里存在的一個潛在的問題是，LLM可能不會始終以相同的文本格式提取對同一實體的引用，這可能導(dǎo)致重復(fù)的實體元素，進而產(chǎn)生圖中的重復(fù)節(jié)點。

但是對于LLM來說，這又是很容易解決的一個問題：由于緊密相關(guān)的“社區(qū)”將在接下來的步驟中被檢測并總結(jié)，而且LLM能夠理解多個名稱變化背后共同的實體，因此整個方法對于這些變化具有魯棒性。只要所有變化都通過足夠的連接指向一組緊密相關(guān)的實體，整體方法就可以保持一致性和準確性。換句話說，即使存在不同的命名方式或拼寫變化，LLM依然能夠識別它們代表的是同一個實體，從而避免了不必要的重復(fù)。

總體而言，在潛在噪聲圖結(jié)構(gòu)中對同質(zhì)節(jié)點使用豐富的描述性文本，這與LLM的能力和全局查詢聚焦摘要生成的需求相一致。通過這種方式，不僅捕捉到了文檔中的顯式信息，也涵蓋了那些隱含但重要的概念。這些特性也將圖索引與典型的知識圖區(qū)分開。傳統(tǒng)的知識圖依賴于簡潔且一致的知識三元組（主體、謂詞、客體）進行下游推理任務(wù)，而圖索引則更注重描述性和靈活性，旨在支持更廣泛的認知活動和復(fù)雜的查詢?nèi)蝿?wù)。

最終輸出的是經(jīng)過LLM總結(jié)后的描述性文本塊，這些文本塊代表了圖中的各個元素（實體、關(guān)系和聲明）。每個元素現(xiàn)在都有一個簡明而全面的描述，這不僅有助于理解該元素本身，還便于在后續(xù)步驟中對其進行處理和分析。

元素摘要 → 圖社區(qū)（Graph Communities）

基于提取出的實體、關(guān)系和聲明，創(chuàng)建一個圖結(jié)構(gòu)，其中實體作為節(jié)點，關(guān)系作為邊，邊權(quán)重代表關(guān)系實例的歸一化計數(shù)。給定這樣的圖，使用社區(qū)檢測算法將圖劃分為多個節(jié)點社區(qū)，每個社區(qū)由一組緊密相連的節(jié)點組成，這些節(jié)點之間的連接比與其他節(jié)點的連接更為緊密。

GraphRAG中的社區(qū)算法采用Leiden算法，因為它能夠高效地恢復(fù)大規(guī)模圖的層次社區(qū)結(jié)構(gòu)。此層次結(jié)構(gòu)的每個級別都提供了一個社區(qū)劃分，以互斥且集體窮盡的方式覆蓋圖的節(jié)點，從而實現(xiàn)分治的全局摘要生成。

最終輸出的是一個經(jīng)過社區(qū)檢測算法處理后的圖結(jié)構(gòu)，其中原始節(jié)點被劃分為若干個社區(qū)。每個社區(qū)包含了一組緊密相關(guān)的節(jié)點，這些節(jié)點之間的連接強度高于與外部節(jié)點的連接。這樣的社區(qū)劃分不僅有助于理解數(shù)據(jù)的整體結(jié)構(gòu)，也為后續(xù)的查詢聚焦型摘要生成提供了基礎(chǔ)。

圖社區(qū) → 社區(qū)摘要（Community Summaries）

接下來就是為每個社區(qū)生成獨立有用的、類似報告的摘要，以幫助用戶理解數(shù)據(jù)集的全局結(jié)構(gòu)和語義。這些社區(qū)摘要可以用于后續(xù)的查詢聚焦型摘要生成，特別是在處理需要對整個語料庫進行綜合理解的復(fù)雜查詢。

對于大型數(shù)據(jù)集，單個社區(qū)可能包含大量信息，如何有效地將這些信息濃縮成有意義的摘要是一個挑戰(zhàn)。GraphRAG分為葉級社區(qū)和高級社區(qū)生成：

• 葉級社區(qū)摘要生成：葉級社區(qū)（即最底層社區(qū)）的元素摘要（節(jié)點、邊、協(xié)變量）被優(yōu)先考慮，即對于葉級社區(qū)，首先按源節(jié)點和目標節(jié)點的度（邊的權(quán)重）的降序排列，然后，依次將源節(jié)點、目標節(jié)點、相關(guān)協(xié)變量以及邊本身的信息添加到LLM的上下文窗口中，直到達到token限制。這確保了最重要和最具代表性的信息被優(yōu)先考慮。
• 更高級別社區(qū)摘要生成：如果所有元素摘要都能適應(yīng)上下文窗口的token限制，則直接生成該社區(qū)的摘要。如果無法全部適應(yīng)，則按元素摘要tokens數(shù)量遞減的順序?qū)ψ由鐓^(qū)進行排名，并迭代的用較短的子社區(qū)摘要替換其關(guān)聯(lián)的較長元素摘要，直到適應(yīng)上下文窗口。這種方法允許在保持信息完整性的同時，減少token使用量。

社區(qū)摘要 → 社區(qū)答案 （Community Answer）→ 全局答案（Global Answer）

給定用戶查詢，上一步生成的社區(qū)摘要可用于生成最終答案，這是一個多階段過程。社區(qū)結(jié)構(gòu)的層次性質(zhì)也意味著可以使用不同級別的社區(qū)摘要來回答問題。

這里存在一個問題：層次社區(qū)結(jié)構(gòu)中的特定級別是否提供了摘要細節(jié)和范圍的最佳平衡，以應(yīng)對一般理解問題。

對于給定的社區(qū)級別，任何用戶查詢的全局答案生成如下：

• 準備社區(qū)摘要：為了確保相關(guān)信息均勻分布，而不是集中在單個上下文窗口中，首先將社區(qū)摘要隨機打亂，并分成預(yù)定義token大小的塊。這樣可以避免某些重要信息因超出上下文窗口限制而被忽略，保證了信息的完整性和多樣性。
• 映射社區(qū)答案：對于每個分塊，使用LLM并行生成中間答案。這意味著每個文本塊都會產(chǎn)生一個獨立的初步回答。LM還被要求為每個生成的答案提供一個0-100的評分，指示該答案對于回答目標問題的幫助程度。這有助于后續(xù)篩選最有用的信息。
• 歸約為全局答案：中間社區(qū)答案按幫助性分數(shù)的降序排序，并迭代地添加到新的上下文窗口中，直到達到 token 限制。此最終上下文用于生成返回給用戶的全局答案。

2、實驗設(shè)置

數(shù)據(jù)集

為了評估Graph RAG的有效性，作者選擇了兩個具有代表性的數(shù)據(jù)集，每個數(shù)據(jù)集大約包含一百萬token，相當于約10本小說的文字量。這些數(shù)據(jù)集反映了用戶在現(xiàn)實世界活動中可能遇到的文檔集合類型。

• 播客轉(zhuǎn)錄文本（Podcast Transcripts）：由微軟CTO Kevin Scott主持的技術(shù)播客《Behind the Tech》的編譯轉(zhuǎn)錄文本。包含1669個600-token文本塊，塊間有100-token重疊（約100萬tokens）。
• 新聞文章（News Articles）：從2013年9月到2023年12月期間發(fā)布的涵蓋娛樂、商業(yè)、體育、技術(shù)、健康和科學等多個類別的新聞文章。包含3197個600-token文本塊，塊間有100-token重疊（約170萬tokens）。

測試問題生成

為了生成適用于全局認知任務(wù)的問題，作者采用了一種以活動為中心的方法自動化生成問題。這種方法確保了問題只傳達對數(shù)據(jù)集內(nèi)容的高層次理解，而不是具體細節(jié)，從而更適合評估RAG系統(tǒng)在更廣泛的認知任務(wù)中的表現(xiàn)。

• 活動中心法：給定一個數(shù)據(jù)集的簡短描述，要求LLM識別N個潛在用戶和每個用戶的N個任務(wù)，然后為每個（用戶，任務(wù)）組合生成N個需要理解整個語料庫的問題。
• 示例問題：例如，對于播客轉(zhuǎn)錄文本，問題可能涉及“哪些劇集主要討論科技政策和政府監(jiān)管？”；對于新聞文章，則可能是“當前哪些健康話題可以整合到健康教育課程中？”。
  
• 數(shù)量：對于每個數(shù)據(jù)集，N=5，共生成125個測試問題。

為了全面評估Graph RAG的性能，作者比較了六種不同的條件，包括使用不同層級社區(qū)摘要的Graph RAG方法、直接對源文本進行映射-歸約摘要的方法（TS），以及樸素的語義搜索RAG方法（SS）。具體描述如下：

• C0：使用根級社區(qū)摘要（數(shù)量最少）來回答用戶查詢。
• C1：使用高級社區(qū)摘要來回答查詢。這些是C0的子社區(qū)（如果存在），否則是C0社區(qū)的向下投影。
• C2：使用中級社區(qū)摘要來回答查詢。這些是C1的子社區(qū)（如果存在），否則是C1社區(qū)的向下投影。
• C3：使用低級社區(qū)摘要（數(shù)量最多）來回答查詢。這些是C2的子社區(qū)（如果存在），否則是C2社區(qū)的向下投影。
• TS：直接對源文本進行映射-歸約摘要的方法，類似于Graph RAG的最后步驟，但直接作用于原始文本而非社區(qū)摘要。
• SS：一種樸素的RAG實現(xiàn)，通過檢索文本塊并將其添加到上下文窗口中直到達到指定的token限制。

評價指標（Metrics）

為了評估不同條件下生成的答案質(zhì)量，作者選擇了一個基于LLM的頭對頭比較方法，定義了四個目標度量標準，旨在捕捉對認知活動有益的質(zhì)量特征：

• 全面性（Comprehensiveness）：答案提供的細節(jié)覆蓋了多少方面和細節(jié)？
• 多樣性（Diversity）：答案在提供不同視角和見解上有多豐富？
• 賦能性（Empowerment）：答案在幫助讀者理解和做出明智判斷上有何效果？
• 直接性（Directness）：答案如何具體且明確地解決提問？

表2顯示了LLM生成的評估示例：

3、實驗結(jié)果

索引過程生成了一個由8564個節(jié)點和20691條邊組成的播客數(shù)據(jù)集圖，以及一個由15754個節(jié)點和19520條邊組成的更大的新聞數(shù)據(jù)集圖。表3顯示了不同級別的圖社區(qū)層次結(jié)構(gòu)中社區(qū)摘要的數(shù)量。

Graph RAG vs Na?ve RAG

1. 全面性（Comprehensiveness）：
   Graph RAG vs Na?ve RAG：所有全局方法（C0, C1, C2, C3, TS）在全面性方面均優(yōu)于樸素RAG（SS）。這是因為全局方法能夠更好地捕捉和整合來自多個社區(qū)摘要的信息，提供更廣泛的內(nèi)容覆蓋。
   層級選擇的影響：使用中間層和低層社區(qū)摘要的Graph RAG（C2, C3）表現(xiàn)尤為突出，在全面性上超過了直接總結(jié)源文本的方法（TS），并且在相同指標下具有更低的token成本。
2. 多樣性（Diversity）：
   Graph RAG的優(yōu)勢：Graph RAG方法在多樣性方面同樣表現(xiàn)出色，特別是當使用較低層次的社區(qū)摘要（C2, C3）。這些方法能夠提供更加豐富多樣的視角和見解，涵蓋了更多的子話題和細節(jié)。
   原因分析：由于較低層次的社區(qū)摘要包含更詳細的子社區(qū)信息，因此它們可以提供更廣泛且深入的回答，避免了高層次摘要可能遺漏的具體內(nèi)容。
3. 賦能性（Empowerment）：
   全局方法與樸素RAG（SS）以及Graph RAG方法與源文本摘要生成（TS）的結(jié)果參差不齊。臨時使用LLM分析LLM推理表明，提供具體示例、引用和引文的能力被認為是幫助用戶達成明智理解的關(guān)鍵。調(diào)整元素提取提示可能有助于在Graph RAG索引中保留更多這些細節(jié)。
4. 直接性（Directness）：
   平衡考量：雖然直接性是衡量答案是否具體且明確地解決提問的一個重要標準，但它通常與全面性和多樣性呈反比關(guān)系。因此，作者并未期望任何一種方法能在所有四個度量標準上都占據(jù)優(yōu)勢。
   Graph RAG的表現(xiàn)：盡管如此，Graph RAG在保持高全面性和多樣性的前提下，依然能夠在直接性方面提供清晰且有針對性的回答。

社區(qū)摘要 vs. 源文本

社區(qū)摘要通常在答案的全面性和多樣性方面提供了小幅但一致的改進，除了根級摘要。

表3還說明了Graph RAG與源文本摘要生成相比的可擴展性優(yōu)勢：對于低級社區(qū)摘要（C3），Graph RAG需要少26-33%的上下文token，而對于根級社區(qū)摘要（C0），它需要少97%以上的token。與其他全局方法相比，性能略有下降，根級Graph RAG提供了一種高度高效的方法，用于迭代式問答，這是理解活動的特征，同時在全面性（72%勝率）和多樣性（62%勝率）方面保留了優(yōu)于樸素RAG的優(yōu)勢。

4、總結(jié)

在大模型時代，都不看好知識圖譜的發(fā)展，其實將知識圖譜和LLM結(jié)合，能夠更好的將開放域知識引入LLM，GraphRAG就是一個LLM和圖譜結(jié)合非常好的例子。

GraphRAG對于需要全文理解，摘要生成等任務(wù)，是一個非常好的解決方案，但是這里存在一個巨大的隱患，圖譜構(gòu)建的過程，可能需要大量的資源和時間。

對于GraphRAG和RAG的使用，更多的還是根據(jù)任務(wù)需求來決定。