一、GraphRAG基本介紹
GraphRAG 是一種基於圖的檢索增強方法，由微軟開發並在2024年7月初開源，最為新鮮熱乎的知識圖譜與大模型融合的前沿開源技術。它透過結合LLM和圖機器學習的技術，從非結構化的文字中提取結構化的資料，構建知識圖譜，以支援問答、摘要等多種應用場景。GraphRAG的特色在於利用圖機器學習演算法進行語義聚合和層次化分析，從而能夠回答一些高層次的抽象或總結性問題，這是常規RAG系統的短板。
二、GraphRAG的核心流程
GraphRAG的核心在於其處理流程，包含2個階段：Indexing和Querying。
- 在Indexing階段：GraphRAG將輸入文字分割為多個可分析單元（稱為TextUnits）。使用LLM提取實體、關係和關鍵宣告。然後透過層次聚類技術（例如Leiden演算法）對圖譜進行社群劃分，並生成每個社群的摘要
- 在Querying階段：這些結構被用來提供材料，以作為LLM的context來回答問題。查詢模式包括全域性搜尋和區域性搜尋
全域性搜尋：透過利用社群的總結來推理關於語料庫整體問題的答案
區域性搜尋：透過擴充套件到特定實體的鄰居和相關概念來推理關於特定實體的問題
它透過構建知識圖譜和社群分層，以及利用圖機器學習技術，增強了對複雜資訊的問答效能，尤其是在需要全面理解大型資料集或單一大型文件的語義概念時。
三、GraphRAG的安裝與測試
- graphrag安裝
pip install graphrag
環境依賴 pytorch2.3.0-tensorflow2.16.1-gpu-py310-cu121-ubuntu22.04
推理GPU配置
- 建立檔案並初始化索引
mkdir -p ./ragtest/input
將待構建圖譜的文件（《紅樓夢》第18回-元春省親，見附錄），存放在input目錄下（對pdf檔案進行格式轉換，目前graphrag僅支援三種格式，csv txt和markdown）
文字格式encoding為utf-8
初始化環境變數
python -m graphrag.index --init --root ./ragtest
配置settings.yaml檔案中的llm和embedding（將llm和embeddding中應用的大模型切換為deepseek和智譜AI的embedding-2，這兩個都提供百萬級的免費試用token）
對檔案建立索引
python -m graphrag.index --root ./ragtest
(耗時20多分鐘，消耗token50萬左右，要是用openai的api那可太貴了
查詢階段
資料查詢分為高階查詢和具體問題查詢，高階查詢比如問主題，使用global模式。具體問題查詢比如問細節，使用local模式資料查詢
高階問題,method引數使用global
區域性查詢，method引數用local
部分回答示例，可以看到在紅樓夢這一回的人物關係理解和檢索上，效果滿足需求。
python -m graphrag.query --root ./ragtest --method global '是誰讓寶玉來園中玩耍的'
SUCCESS: Global Search Response: 寶玉來園中玩耍的原因涉及家族內部的親情和支援，以及家族領導者的管理和教育。
首先，賈母對寶玉的關愛體現在日常的互動和特殊時刻的經濟援助，這包括允許他在園中自由玩耍，體現了家族內部的親情和支援 [Data: Reports (15)]。
其次，賈政作為家族的領導者和文學討論的推動者，對寶玉進行管理和教育，包括安排他在園中的活動 [Data: Reports (20)]。
綜合來看，寶玉來園中玩耍是賈母的關愛和賈政的管理共同作用的結果。
python -m graphrag.query --root ./ragtest --method local '是誰讓寶玉來園中玩耍的'
SUCCESS: Local Search Response: 寶玉來園中玩耍是由賈母安排的。根據提供的資料，寶玉因思念秦鍾而憂戚，賈母常命人帶他到園中來戲耍 [Data: Sources (4)]. 這表明賈母關心寶玉的情緒狀態，並採取行動幫助他緩解憂愁。
python -m graphrag.query --root ./ragtest --method global '總結下園中的景觀'
SUCCESS: Global Search Response: ### 翠嶂園林社群的景觀設計
翠嶂園林社群以翠嶂為核心，圍繞其展開一系列的園林設計和文化活動。翠嶂作為園林中的一座山，其設計目的是為了遮擋視線並增加園林的趣味性 [Data: Reports (11)]。此外，亭子及其周邊景觀以‘亭子’為中心，周圍環繞著‘清溪瀉雪’和‘石磴穿雲’的自然景觀。亭子不僅是討論命名的地點，也是連線這些自然景觀的核心 [Data: Reports (1)]。
自然與人工的融合
寶玉對自然和人工的差異有深刻理解，並質疑人工造作的美學價值。他對杏花村和田莊的命名和佈局提出了自己的見解，顯示出他對自然美的獨特追求和審美品味 [Data: Reports (15)]。寶玉還能夠識別和討論各種植物，如杜若蘅蕪、金す草等，顯示出他的知識淵博和對自然界的深刻理解。這些討論不僅豐富了社群的文化內涵，也反映了寶玉對自然美的追求 [Data: Reports (15)]。
院落與植物景觀
院落及其植物景觀以‘院落’為中心，是一個集休息與觀賞植物於一體的空間。院落與‘碧桃花’和‘西府海棠’等植物有著緊密的地理和功能關係 [Data: Reports (13)]。青溪和花園水系統社群以青溪為中心，青溪是一個複雜的花園水系統，其源頭來自東北山坳，流經村莊，最後返回花園 [Data: Reports (17)]。
建築與自然環境的結合
清涼瓦舍和大主山社群以清涼瓦舍為中心，清涼瓦舍是一個獨特的建築結構，位於大主山的分支點，周圍環繞著各種異草 [Data: Reports (5)]。這些設計不僅增強了社群的自然美感，也體現了人與自然和諧共存的理念。
python -m graphrag.query --root ./ragtest --method local '對園中出現的景觀進行美感排序'
SUCCESS: Local Search Response: 在探討園林中的景觀美感時，我們可以從多個角度進行分析，包括自然元素、建築特色以及文化內涵等。以下是對園中出現的景觀進行美感排序的幾個關鍵點：
自然元素的美感
自然元素如山水、植物等，往往給人以寧靜和和諧的感覺。例如，“翠嶂”作為園林中的一座山，不僅增加了園林的趣味性，還因其自然形成的美麗而受到讚賞[Data: Entities (17); Relationships (55, 107)]。此外，“清涼瓦舍”周圍的異草和自然環境融為一體，增添了獨特的美麗和香氣[Data: Entities (69); Relationships (118, 119)]。
建築特色的美感
建築特色如橋樑、亭臺樓閣等，展現了人類與自然和諧共存的藝術。例如，“柳陰中的橋”透過這座橋可以到達不同的路徑，連線到一所清涼瓦舍，展現了路徑選擇的決策能力和對園林佈局的熟悉[Data: Entities (68); Relationships (43)]。
文化內涵的美感
文化內涵如詩詞、歷史故事等，為園林增添了深厚的文化底蘊。例如，“遊幸”這一活動不僅決定了園林的命名和裝飾，還體現了貴妃的權威和影響力[Data: Entities (9); Relationships (103)]。
綜合美感排序
綜合考慮自然元素、建築特色和文化內涵，我們可以對園中景觀進行如下美感排序：
- 翠嶂：因其自然形成的美麗和增加園林趣味性的功能[Data: Entities (17); Relationships (55, 107)]。
- 清涼瓦舍：周圍異草和自然環境融為一體，增添了獨特的美麗和香氣[Data: Entities (69); Relationships (118, 119)]。
- 柳陰中的橋：展現了路徑選擇的決策能力和對園林佈局的熟悉[Data: Entities (68); Relationships (43)]。
- 遊幸：體現了貴妃的權威和影響力，決定了園林的命名和裝飾[Data: Entities (9); Relationships (103)]。
透過這種排序，我們可以更深入地理解園林中各個景觀的美感價值，並欣賞其背後的自然、建築和文化元素。
四、GraphRAG流程解析
Indexing階段——
Source Documents → Text Chunks：將源文件分割成文字塊；
Text Chunks → Element Instances：使用大模型從每個文字塊中提取圖節點和邊的例項；
Element Instances → Element Summaries：使用大模型為每個圖元素生成摘要；
Element Summaries → Graph Communities：使用社群檢測（leiden演算法）將圖劃分為社群；
Graph Communities → Community Summaries：使用大模型為每個社群生成摘要報告（reports），這些摘要包含一個概述，以及引用社群子結構中的關鍵實體、關係和宣告；
Community Summaries → Community Answers → Global Answer：使用社群摘要生成區域性答案，然後彙總這些區域性答案以生成全域性答案。
最終生成的圖資料是以graphml語法的字串形式，儲存在.parquet檔案中
Global search階段——
Global Search是基於整個資料集的推理。常規RAG在處理需要跨資料集聚合資訊後進行組合回答的場景時很難有很好的表現。例如，“資料中的top 5主題是什麼？”這種問題查詢效果會很差，因為常規RAG的處理方式是：依賴於資料集中存在語意相似的文字內容的向量檢索。如果知識庫中沒有文字內容包含這個問題的答案，則無法給出高質量的回答。
然而，使用 GraphRAG 可以回答此類問題，因為 LLM 生成的知識圖譜的結構可以告訴我們整個資料集的結構（以及主題）。這使得私有資料集能夠組織成有意義的語義clusters，並且這些clusters已被預先總結。透過使用我們的全域性搜尋方法，LLM 在響應使用者查詢時可以使用這些cluster來總結這些主題，並回答使用者對整個資料集的問題。
在global查詢模式下的資料來源是create_final_nodes.parquet、create_final_entities.parquet 和create_final_community_reports.parquet 。
查詢流程為：
1.從create_final_community_reports.parquet檔案中獲取選中的community_report資料；
2.基於選中的community_reports列表批次請求大模型（這裡由於community_reports內容較多，會耗費較多的大模型Token），讓大模型基於每個community_report回答使用者的問題；（map過程）
3.把上述獲取的大模型返回結果列表整合成一個完整的答案並返回給使用者，這個整合過程也是透過大模型完成的。（reduce過程）
Local search階段——
給定使用者查詢（或加上對話歷史記錄），Local Search會從知識圖譜中識別出一組與使用者輸入在語義上相關的實體。這些實體作為進入知識圖譜的入口點，能夠提取進一步相關的細節,如相連實體、關係、實體協變數（與實體相關的變數）和社群報告。此外，它還從原始輸入文件中提取與已識別實體相關的相關文字chunk。然後對這些候選資料來源進行優先順序排序和過濾，以適應預定義大小的單個上下文視窗，該視窗用於生成對使用者查詢的響應。
local查詢模式下，與global模式相比，多了幾個資料來源create_final_text_units.parquet和create_final_relationships.parquet
1.基於使用者的問題透過語義相似度計算相似度高的實體Entity；
2.基於選中的Entity獲取對應的Community內容；
基於聊天上下文和community_content構建prompt內容，呼叫大模型並將結果返回給使用者。
五、GraphRAG的官方測評和最佳化方法
微軟開源部落格上對於官方測試文件的評價
基於微軟官方釋出的部落格來看，微軟採用了一個LLM評分器來給GraphRAG和Baseline RAG的表現進行評估。
基於一系列的指標，包括全面性（提取的上下文內容的完整性，包括隱含的資訊）、人類賦權（提供來源的材料或其他上下文資訊）和多樣性（提供不同的視角或問題的角度）。從初步評測結果來看，GraphRAG在這些指標上都優於Baseline RAG。
除此之外，微軟還實用了SelfCheckGPT來進行忠實度的絕對測量，來確保基於原材料的事實性和連貫性結果。結果也顯示出GraphRAG在忠誠度上達到了與Baseline RAG類似的水平。目前微軟也在開發一個評估框架，用來進一步衡量上述問題型別的效能。
從使用GraphRAG對《紅樓夢》中出場人物最多章節《元春省親》的indexing和querying過程來看，可以看到GraphRAG的優缺點都非常明顯。
優點——
1.知識全面：得益於在Indexing過程中構建的實體關係圖、社群、原始文件切片等資訊，在內容檢索時（包含向量檢索與結構化資料檢索），它能夠獲取到更豐富、更多層的資訊，提供更全面的回答；
2.有據可查：在生成各個索引的過程中，都引入了源文件chunk，保持對源資料的忠誠，使得回答可靠。
缺點——
1.耗時長、成本高：在Indexing的過程中，需要頻繁呼叫LLM（例如抽取實體、實體和關係的總結、社群總結等）並呼叫外部演算法（例如社群檢測），會使得索引時間拉長，並且LLM呼叫消耗的tokens過高；
2.擴充套件性：在資料集膨脹到更高數量級時，除了耗時與成本更長外，其構建Indexing過程的穩定性也需要進一步測試；
3.延遲高：由於在檢索時需要進行多路召回、過濾和排序，所以在回答問題延遲上也會相應增加；
4.準確性不夠：在查詢和時間日期等相關的實體時，準確性下降較大；
總的來說，GraphRAG還是一個非常強大的工具，提供了一整套完成的pipeline來完成非結構化文字進行知識抽取、索引構建和知識問答的流程，提高了從非結構化資料中提取Insight的能力，彌補現有RAG模式的不足。但它在耗時、成本、擴充套件性等方面仍會是在應用到生產環境中的幾大挑戰點。
針對其他場景的非結構化文字進行GraphRAG圖譜構建和知識抽取，考慮的最佳化方法：
1.採用本地部署的ollama大模型進行文件解析和抽取，更好地對照問答結果；
2.圖譜構建時的實體抽取和指代消解等流程，考慮採用neo4j的graph builder元件，或者螞蟻開源的圖譜抽取大模型oneke（預計下一版本有一個基於llama3-8b微調的，支援（半）開放抽取，目前是schema約束的抽取）
3.寫prompt最佳化輸出。