圖形 RAG 是一個突破性的系統,它結合了知識圖譜與檢索增強生成(RAG)來解決傳統 RAG 方法的局限性。通過利用知識圖譜,圖形 RAG 提供了更全面的理解底層語料庫,從而實現更準確和更具上下文相關性的回應。

圖形 RAG 的關鍵方面包括:

1. 索引階段: 在這個階段,源文件被處理,實體被提取並用於創建知識圖譜。知識圖譜表示不同實體之間的關係,然後用於創建不同粒度的摘要。

2. 查詢階段: 當用戶查詢被提供時,圖形 RAG 根據查詢選擇適當的社區(摘要)級別,並檢索相關信息。來自多個社區的回應隨後被組合以生成最終答案。

這種方法解決了傳統 RAG 的局限性,如有限的上下文理解和可擴展性問題。通過結合知識圖譜,圖形 RAG 可以提供對底層數據更全面的理解,從而產生更準確和連貫的回應。

圖形 RAG 的一個關鍵優勢是它能夠處理需要更深入理解實體關係的複雜查詢。這使它特別適用於涉及問答、摘要或知識密集型任務的應用程序。

然而,值得注意的是,運行圖形 RAG 的成本可能高於傳統 RAG 系統,因為它涉及額外的處理步驟,如實體提取和知識圖譜創建。這個成本因素在決定是否在您的應用程序中實施圖形 RAG 時應該仔細考慮。

總的來說,圖形 RAG 代表了檢索增強生成領域的重大進步,它在各種應用中增強語言模型性能的潛力值得探索。

傳統的檢索增強生成(RAG)是一種方法,其中語言模型從大型語料庫中檢索相關文檔,以生成更準確和上下文相關的回應。這種方法涉及三個主要步驟:

1. 文檔處理和嵌入: 原始文檔使用分塊策略分成較小的塊。然後為每個塊計算嵌入,並將其存儲在向量存儲中,這成為知識庫。

2. 查詢階段: 當用戶提出問題時,會計算查詢的嵌入,並在向量存儲上執行相似性搜索,以檢索最相關的塊或子文檔。

3. 回應生成: 檢索到的上下文與原始查詢結合,輸入到大型語言模型中以生成最終回應。

然而,這種傳統的 RAG 方法存在一些局限性:

1. 有限的上下文理解: RAG 有時會由於過度依賴檢索的文檔而錯過數據中的細微差異。它沒有對整個文檔的全面概覽,因此無法完全理解整體情況。

2. 可擴展性問題: 隨著語料庫的增長,檢索過程可能變得效率較低。

3. 整合外部知識源的複雜性: 以有意義的方式整合外部知識源可能很複雜和麻煩。

為了解決這些局限性,微軟推出了 GraphRAG,這是一個結合知識圖譜與檢索增強生成的系統。在下一節中,我們將深入探討 GraphRAG 的工作原理。

圖形 RAG 是一種新穎的方法,它結合了知識圖譜與檢索增強生成(RAG),以解決傳統 RAG 系統的局限性。圖形 RAG 過程涉及以下關鍵步驟:

1. 索引階段:

   • 將源文檔分塊成較小的子文檔。
   • 在每個塊中,識別實體(如人物、地點、公司),並提取這些實體之間的關係。
   • 使用這些信息創建一個知識圖譜,其中實體表示為節點,它們之間的關係表示為邊。
   • 然後使用知識圖譜檢測社區,即緊密相關實體的群組。
   • 為每個社區創建不同粒度的摘要,從全局(高層次)到局部(更細粒度)。

2. 查詢階段:

   • 當收到用戶查詢時,根據所需的詳細程度選擇適當的社區級別(全局、中間或局部)。
   • 檢索相關社區的摘要,並將這些部分回應組合以生成最終答案。

這種方法相比傳統的 RAG 系統提供了以下優勢:

• 改善上下文理解: 通過利用知識圖譜和社區級摘要,圖形 RAG 可以更好地捕捉源文檔的整體背景和細微差異,而不是僅依賴於檢索的文檔。
• 增強可擴展性: 隨著語料庫的增長,社區級摘要可以幫助維持有效的檢索和回應生成,從而緩解傳統 RAG 的可擴展性問題。
• 簡化整合: 基於知識圖譜的方法提供了一種更結構化和有意義的方式來整合外部知識源,使整個過程更加簡單和不那麼繁瑣。

然而,圖形 RAG 方法也存在一個潛在的缺點:運行系統的成本。索引階段涉及實體提取、關係識別和社區摘要,這可能是計算密集型的,尤其是在使用像 GPT-4 這樣的大型語言模型時,會產生重大成本。

在提供的示例中,在單本書(《聖誕頌歌》)上運行圖形 RAG 的成本約為 7 美元,這對於更大的語料庫可能過於昂貴。這個成本因素是在決定是否在您的應用程序中使用圖形 RAG 或傳統 RAG 系統時需要仔細考慮的。

總的來說,圖形 RAG 代表了解決傳統 RAG 系統局限性的創新方法,但成本影響需要根據您的具體需求和項目規模進行仔細評估。

要在您的本地機器上設置圖形 RAG,請按照以下步驟操作:

1. 創建一個 Conda 虛擬環境:

   conda create -n graphrag python=3.9
   conda activate graphrag
   

2. 安裝圖形 RAG 套件:

   pip install graphrag
   

3. 為您的測試數據創建一個目錄:

   mkdir -p rag_test/input
   

4. 下載一個示例數據集,如查爾斯·狄更斯的《聖誕頌歌》文本:

   python -m graphrag.index --root_dir rag_test/input --download_sample_data
   

5. 設置您的工作區變量和配置:

   python -m graphrag.index --root_dir rag_test/input --init_config
   

   這將創建一個 settings.yml 文件,您可以在其中配置 API 密鑰、模型和其他設置。

6. 運行索引過程以創建知識圖譜:

   python -m graphrag.index --root_dir rag_test/input
   

   這一步可能需要一些時間,因為它涉及實體提取、關係識別和社區摘要。

7. 運行示例查詢:

   python -m graphrag.query --root_dir rag_test --method global --prompt "這個故事的主要主題是什麼?"
   python -m graphrag.query --root_dir rag_test --method local --prompt "Scrooge 和 Bob Cratchit 之間的關係是什麼?"
   

   global 方法檢索最高級別的信息,而 local 方法關注特定實體及其關係。

8. 分析成本影響: 索引過程可能很昂貴,尤其是在使用像 GPT-4 這樣的大型語言模型時。提供的示例顯示,處理單本書的成本約為 7 美元。在將圖形 RAG 應用於更大的數據集時,請考慮成本影響。

這就是在本地機器上運行圖形 RAG 的基本設置過程。請記得根據您的具體用例自定義配置和提示。

在提供的示例中,使用圖形 RAG 的成本影響是重大的。處理該書並創建圖形 RAG 的總成本約為 7 美元,這對於大型數據語料庫可能過於昂貴。

導致高成本的關鍵因素有:

1. API 請求: 圖形 RAG 方法總共發出了 570 個 API 請求,主要用於 GPT-4 模型。相比之下,傳統的 RAG 方法可能有較少的 API 請求。

2. 令牌處理: 圖形 RAG 過程涉及處理超過 100 萬個令牌,這也貢獻了整體成本。

相比之下,傳統的 RAG 系統可能成本較低,因為它不需要圖形 RAG 方法中的額外步驟,如實體提取、關係識別和社區摘要。

必須權衡圖形 RAG 提供的改善上下文理解和全面概覽,以及其實施的更高成本。根據具體的用例和可用預算,一種方法可能比另一種更合適。

如果處理大型數據語料庫,應該仔細評估圖形 RAG 的成本影響。在這種情況下,如果改善的上下文理解不是關鍵要求,傳統的 RAG 系統可能是更具成本效益的解決方案。

最終,在圖形 RAG 和傳統 RAG 之間的選擇將取決於項目的具體需求、可用資源以及性能和成本之間的平衡。

雖然微軟的 GraphRAG 是一個突破性的系統,但它並不是圖形 RAG 方法的唯一實現。還有其他值得探索的顯著解決方案:

Lama Index 的知識圖譜 RAG 查詢引擎

Lama Index 是一個流行的開源知識管理平台,它開發了自己的知識圖譜 RAG 查詢引擎實現。這個解決方案利用知識圖譜的力量來增強大型語言模型的檢索和生成能力。

Lama Index 的方法重點是從各種數據源(包括結構化和非結構化數據)構建一個全面的知識圖譜。然後使用這個知識圖譜來驅動 RAG 系統,提供對底層信息更全面的理解。

Neo4j 的圖形 RAG 套件

Neo4j 是一個領先的圖形數據庫提供商,它也推出了一個圖形 RAG 套件。這個解決方案將 Neo4j 的圖形數據庫功能與檢索增強生成(RAG)技術相結合。

通過利用 Neo4j 高效的圖形遍歷和查詢功能,圖形 RAG 套件旨在解決傳統 RAG 系統的可擴展性和上下文理解限制。這種方法允許更有效地從知識圖譜中檢索相關信息,從而產生更準確和連貫的回應。

比較這些實現

雖然圖形 RAG 的核心原則在這些解決方案中是共享的,但每個實現可能都有自己的獨特特徵、優勢和權衡。如性能、集成容易程度、對不同語言模型的支持以及成本影響等因素可能因不同的圖形 RAG 解決方案而有所不同。

如果有興趣,我可以深入比較這些圖形 RAG 實現,突出它們的關鍵差異,並幫助您確定最適合您特定用例的解決方案。

圖形 RAG 工作得很好,但有一個主要問題就是成本。在提供的示例中,總共發出了 570 個 API 請求,使用了 GPT-4,並處理了超過 100 萬個令牌,導致成本約為 7 美元。這對於大型數據語料庫來說可能