構建高效的GraphRAG系統:簡化架構與工具選擇的藝術
摘要
本文探討了GraphRAG(檢索增強生成)技術的實現方法,指出開發者在構建GraphRAG系統時往往過度依賴復雜的圖數據庫、查詢語言和分析工具。作者強調,生成式AI的用例與傳統圖分析場景根本不同,大多數GraphRAG應用只需要進行局部鄰域探索,而不需要復雜的全圖分析。文章建議采用以向量存儲為核心、按需添加圖功能的簡化架構,避免不必要的技術復雜性。
當RAG開發者決定嘗試GraphRAG時——即構建知識圖譜并將其集成到他們的RAG(檢索增強生成)系統中——根據互聯網上的信息,他們有很多選擇和決策要做。有大量的文章、指南和教程介紹了用于GraphRAG和一般圖形處理的不同工具。因此,一些開發者直接投入其中,認為他們需要集成和配置一長串圖工具和技術才能正確地實現GraphRAG 。
在搜索如何開始時,你通常會發現文章建議你需要以下部分或全部工具:
- 知識圖譜——連接語義搜索無法捕獲的關鍵術語和概念
- 關鍵詞和實體提取工具——用于構建知識圖譜
- 圖遍歷算法——用于探索圖中的連接
- 屬性圖實現——用于豐富圖結構和遍歷方法
- 圖數據庫(DBs)——用于存儲和與圖交互,以及高級圖分析
- 圖查詢語言(QLs)——用于對圖節點和邊進行復雜查詢
- 圖節點嵌入算法——用于將圖對象嵌入到可搜索的向量空間中
- 向量存儲——用于存儲和搜索嵌入在語義向量空間中的文檔
當然,可以說這些工具和實現中的每一個都可以對特定的圖用例非常有幫助。但對于開始典型GraphRAG用例的任何開發者來說,一個簡單的事實仍然存在:大多數"圖"工具都是在生成式AI革命之前很久就設計和構建的。生成式AI用例與傳統圖用例根本不同,需要不同的方法,即使某些工具可以在兩者之間共享 。
生成式AI用例與傳統圖應用的根本差異
在生成式AI出現之前,就有了知識圖譜和圖數據庫。這些圖工具比生成式AI早了很多年,一些相關技術是為非常不同的用例設計的。這些技術主要針對結構化數據探索,而不是生成式AI擅長的非結構化文本處理和語義理解 。
從傳統圖用例到生成式AI的轉變是數據處理技術的重大變化。傳統圖表在處理清晰、定義明確的關系方面表現出色,但它們往往缺乏生成式AI細致需求所需的靈活性 。
傳統圖工具是為龐大復雜的圖而構建的
知識圖譜通常是來自各種來源的大量數據的聚合,鏈接了廣泛數據點范圍內復雜且相互依賴的關系。大量的節點和邊,加上它們連接的復雜性,可能使數據處理和分析任務在計算上密集且耗時 。
這就是為什么最初創建圖數據庫(圖DBs)的原因。它們提供了優化的存儲解決方案和處理能力,旨在高效管理節點和邊的廣泛網絡。與圖數據庫一起,圖查詢語言(圖QLs)被設計用來促進對這些大型圖及其子圖的復雜查詢操作 。
傳統圖數據庫和查詢語言的一些典型用例包括:
- 中心性分析——識別社交網絡中最有影響力的人員。涉及諸如度中心性、介數中心性和特征向量中心性等中心性度量
- 社區檢測——將網絡分割成社區或集群,其中成員內部連接比與網絡其余部分連接更密集。涉及圖聚類算法和邊介數社區檢測
- 路徑查找——找到兩個節點之間的最短路徑,以了解個體之間的分離度。涉及Dijkstra或A*(A星)等最短路徑計算算法
當然,傳統圖工具設計并擅長的復雜圖查詢和圖分析還有許多其他用例。但是,這里給出的例子以及許多其他例子,與我們今天在生成式AI應用中看到的圖用例非常不同 。
GraphRAG和向量搜索都是局部操作
之前我將"鄰域探索"列為圖在生成式AI用例中的一個應用,但從概念上講,它可以被視為一個廣泛的總體術語,在其下你可以找到生成式AI中幾乎所有的圖用例。換句話說,當我們在生成式AI中使用圖時,我們幾乎可以肯定只探索鄰域——很少探索整個圖或圖的大部分。最多,我們探索相對于整個圖來說相當小的子圖 。
在圖論中,"鄰域"指的是圖中與給定節點相鄰的節點集合,由直接鏈接或邊定義。因此,在知識圖譜中檢索節點的鄰居應該產生一組與起始節點直接相關的項目或概念。類似地,在向量搜索中,標準實現返回語義向量空間中的"近似最近鄰"(ANN),這意味著結果集中的文檔是那些在語義意義上與查詢最密切相關的文檔 。
因此,向量搜索和從起始節點開始的幾步圖遍歷都在尋找"最近鄰",其中"最近"在這兩種情況下有不同的含義。向量搜索找到最近的語義鄰居,圖遍歷找到圖鄰居——如果集成得好,可以將在語義方式和各種非語義方式中相關的文檔匯集在一起,這些方式僅受你如何構建知識圖譜的限制 。
這里的重點是要注意,GraphRAG完全關注探索局部鄰域,無論是圖還是向量——就像RAG在純向量方面一直如此。其含義是,我們的GraphRAG軟件堆棧應該建立在擅長局部鄰域搜索和檢索的基礎上,因為我們在生成式AI應用中的所有查詢都專注于特定的知識領域,不需要對整個知識圖譜進行全面探索或分析 。
按需選擇圖工具:只采用你需要的
回到本文開頭的圖工具"清單",讓我們仔細看看什么時候你可能想要將它們作為GraphRAG堆棧的一部分采用,或者不采用:
知識圖譜
- 何時采用——始終,以某種形式。知識圖譜是GraphRAG的核心部分
- 何時避免——永遠不要,除非放棄GraphRAG轉而使用純RAG
實體和關鍵詞提取工具
- 何時采用——當直接從文本內容構建知識圖譜時,自動提取可以高效地用相關實體和關鍵詞填充你的圖
- 何時避免——如果你的數據不適合自動提取,或者當文檔鏈接、手動策劃或專門解析器等替代方法更適合你的數據和用例時
圖遍歷算法
- 何時采用——始終。GraphRAG需要簡單的圖遍歷算法,例如通常從起始節點進行深度1-3的簡單遍歷
- 何時避免——雖然基本遍歷是必要的,但除非你的用例特別需要高級圖導航能力,否則要避免過于復雜的算法
屬性圖實現
- 何時采用——當你的項目需要在邊內對復雜關系和屬性進行復雜建模,遠超基本鏈接時
- 何時避免——對于大多數標準GraphRAG實現,不需要關系建模中的這種復雜性。更簡單的圖模型通常就足夠了
圖數據庫
- 何時采用——當處理廣泛、復雜的查詢并需要執行超越標準系統能力的高級圖分析和遍歷時
- 何時避免——如果你的GraphRAG系統不進行復雜、廣泛的圖特定操作。在這種情況下采用圖數據庫可能導致不必要的系統復雜性和資源分配
圖查詢語言(圖QLs)
- 何時采用——如果采用圖數據庫。當圖數據的復雜查詢對你的應用至關重要時,允許對相互連接的數據進行復雜的操作和檢索
- 何時避免——對于基本檢索方法足夠的較簡單GraphRAG設置,結合圖QL可能會使架構過于復雜
圖節點嵌入算法
- 何時采用——當你有圖,并想將圖節點轉換為向量時。這是一個專門的用例,有優點和缺點
- 何時避免——如果你的系統不需要將圖節點作為向量搜索
向量存儲
- 何時采用——始終。必要的,因為它們作為存儲和搜索對RAG系統至關重要的高維向量表示的基礎
- 何時避免——永遠不要
最小GraphRAG系統的要求
考慮到上述關于圖工具和技術的說明,這些是任何GraphRAG系統所需的核心組件:
1. 向量存儲
對于任何RAG框架都是必需的,向量存儲在GraphRAG中對于維護文檔檢索的可擴展性和效率更加重要。向量存儲提供了在語義向量空間中存儲和搜索嵌入文檔的基礎設施,這是RAG系統中檢索過程的基礎 。
2. 知識圖譜
GraphRAG與純RAG的定義概念,知識圖譜鏈接語義向量搜索可能錯過的關鍵術語和概念。該圖對于擴展上下文和增強RAG系統可用的關系數據至關重要,因此證明了其在GraphRAG中的核心作用 。
3. 圖遍歷
需要簡單的圖遍歷算法來導航知識圖譜。這個組件不需要過于復雜,因為GraphRAG主要需要探索與查詢直接相關的局部鄰域或小子圖,而不是深度或廣泛的圖導航 。
對于特殊用例,或者如果最小實現性能不夠好,可以添加更多圖工具和功能——下一節概述了一些重要考慮因素。
從向量開始,按需添加"圖"——而不是相反
在處理生成式AI用例時,知識的基礎在向量空間中。我們使用向量優化的工具如向量存儲,因為它們直接使用LLM和其他生成式AI模型的語言——向量。我們的生成式AI應用實現應該以向量為先,因為最重要的向量操作(例如近似最近鄰搜索)在時間和金錢上都很昂貴,所以我們應該為性能和效率優化這些操作 。
向生成式AI應用添加圖應該就是這樣:向你現有的向量優化基礎設施添加圖功能。從向量優化移動到圖原生基礎設施可能在某些特定用例中需要,但在絕大多數情況下,它會使技術堆棧復雜化并使部署更具挑戰性 。
開始實現GraphRAG的簡單方法
對于如何在不使用任何專門圖工具的情況下進行GraphRAG的直接且說明性的示例,超越LangChain中的開源圖向量存儲實現,可以參考作者之前在《走向數據科學》上的文章。或者,要獲得更廣泛的入門視圖,可以參考GraphRAG指南 。
總結
GraphRAG并不需要復雜的圖數據庫、查詢語言或分析工具。生成式AI用例與傳統圖分析根本不同,主要關注局部鄰域探索而非全圖分析。最有效的方法是以向量存儲為基礎,按需添加簡單的圖功能。這種方法既保持了系統的簡潔性,又充分利用了GraphRAG的優勢,避免了不必要的復雜性和維護開銷。
記住:簡單往往更好,尤其在快速發展的AI領域中。選擇合適的工具而不是最復雜的工具,是成功構建GraphRAG系統的關鍵。
本文轉載自????知識圖譜科技????,作者:KGGPT

















