GraphRAG通過引入文檔結構信息和知識抽取流程優化，提升了知識圖譜的構建和檢索性能，特別是在金融、醫療等對數據完整度要求高的領域，實現了更準確的知識表示和高效的多維檢索。

作者：陳梓康

眾所周知，GraphRAG將文檔內容抽取為知識圖譜三元組后，實際上僅保留了關聯性知識信息，因此不可避免地會丟失原文的一些內容細節。在對數據完整度要求嚴格的業務場景，如金融、醫療、保險等行業，這是不希望看到的結果。為了解決此類業務訴求，我們將文檔結構信息引入GraphRAG鏈路，以解決知識抽取后原文信息損失的問題。同時，我們也從端到端優化了GraphRAG鏈路，大幅提升了知識圖譜的構建和檢索性能。

1. 摘要

GraphRAG 是一個創新的知識檢索與問答增強框架，它巧妙地結合了圖數據庫技術與檢索增強生成（RAG）方法。GraphRAG 往往在處理復雜數據關系任務上取得比傳統 RAG 更好地效果，是當下 LLM 領域熱門的工程方向之一。

作為 DB-GPT 萬星開源項目的重要組件之一，螞蟻自研的 GraphRAG 近期獲得了顯著的性能提升——改進的 GraphRAG 在原有的社區摘要增強和混合檢索支持的基礎上，新增了文檔結構（Document Structure）索引，進一步提升了知識圖譜的豐富度和知識召回的完備性。同時，繼續兼容基于 AntV G6 引擎和 TuGraph 引擎的知識圖譜的酷炫渲染，GraphRAG 讓文檔中的復雜數據關系一目了然。

本文將詳細介紹 DB-GPT GraphRAG 系統的最新技術改進，重點包括文檔結構索引的創新實現、知識圖譜構建的效率優化，以及多維檢索機制帶來的效果提升。通過與業界標桿的對比測試，驗證了優化方案在降低資源消耗的同時，保持了知識表示的完整性和準確性。文章同時展示了實際應用案例，為讀者提供了直觀的技術參考。

2. 知識圖譜構建

2.1 文檔結構圖譜

2.1.1 文檔解析

為提升文檔解析的精確度，我們對 Markdown 格式文件實現了增強支持。系統通過識別標準格式文檔中的標題層級符號（如"#"、"##"等），將文檔智能切分為多個獨立的文本塊（content block, 簡稱 chunk）。這種結構化解析方法不僅保留了原始內容的完整性，更重要的是準確捕獲了內容之間的層級關系。

基于這些層級關系，我們構建了一個有向圖結構：

• 每個節點代表一個文本塊（chunk）。
• 邊的類型分為兩種（有向邊）：
  • next：連接同一層級的相鄰文本塊，表示內容的順序關系。
  • include：連接不同層級的文本塊，表示上下級包含關系。

為了直觀展示文檔結構解析的過程，讓我們通過一個具體的示例來理解這個機制，考慮以下 Markdown 文檔片段：

# 機器學習基礎
## 監督學習
### 分類算法
### 回歸算法
## 無監督學習
### 聚類算法

這個文檔會被切分成以下文本塊（用[...]表示具體內容）：

• chunk1: "# 機器學習基礎 [...]"
• chunk2: "## 監督學習 [...]"
• chunk3: "### 分類算法 [...]"
• chunk4: "### 回歸算法 [...]"
• chunk5: "## 無監督學習 [...]"
• chunk6: "### 聚類算法 [...]"

同時，這些文本塊（chunk）之間存在著兩種有向關系（包含 include、連接 next）：

• include 邊：chunk1 包含 chunk2 和 chunk5；chunk2 包含 chunk3 和 chunk4；chunk5 包含 chunk6。
• next 邊：chunk2 連接 chunk5；chunk3 連接 chunk4。

2.1.2 文檔結構圖譜構建

自然地，得益于文本塊（chunk）之間的有向關系，可以將文件結構組織為有向圖。順便，將其寫入到知識圖譜（基于 TuGraph 底座）。如圖所示，在圖的上半部分，其中的節點可以是文件的一個內容分片/文本塊（chunk，紫色節點），邊則代表了文本塊（chunk）之間在原文檔中的結構關系。

通俗地說，Document 1 就像一本教程的主目錄，它通過包含（include）關系連接到不同的章節（Chunk 1、2、3）。每個章節又可以包含（include）更具體的知識點（Entity）。同時，通過 next 關系，我們能清晰地看到學習的推薦順序。

2.2 三元組圖譜

完成文檔結構圖構建后，下一個關鍵步驟是通過語義理解提取文檔中的知識實體與關系，構建結構化知識圖譜。我們采用了創新的"上下文增強"方法，通過多維度信息融合提升知識抽取的準確性。

2.2.1 相似文本塊檢索

• 對于每個待處理的文本塊（chunk），我們首先通過向量相似度檢索找到語義相近的其他 top k 個文本塊（chunk）。
• 這些相似的文本塊將作為補充上下文，幫助 LLM 更好地理解當前內容。

2.2.2 三元組知識抽取

• 將當前文本塊和相關上下文一起作為一個請求，并發送到 LLM 服務端。
• 基于更豐富的上下文，LLM 能夠更準確地識別和抽取出知識三元組。
• 抽取的結果遵循 【entity】--（relation）->【entity】的標準格式。

2.2.3 并發抽取優化

1. 文本塊的三元組抽取是相對獨立的進程，因此，我們采用并發的形式來批次執行進程。
2. 考慮到三元組知識抽取任務的特點：
   • 各文本塊之間的處理相互獨立。
   • 計算過程無共享狀態。
   • 任務粒度適中。
3. 我們實現了基于文本塊的并發處理機制：
   • 通過批處理方式，平衡并發數量和 LLM 調用資源。
   • 從而，實現了處理速度和資源利用的最優平衡。
4. 該提出的并發優化方案取得了顯著的性能提升：任務處理時間降低至原有耗時的 20%。這種五倍的性能提升充分證明了并發策略在大規模知識抽取場景下的效果。在實際運行中，我們也觀察到了兩個主要的性能瓶頸：
   • LLM 并發請求限制
     • 大語言模型的 API 通常對并發請求數有嚴格限制。
     • 即使系統能夠并行處理更多任務，也會受限于 API 的調用配額。
   • Token 生成速率限制
     • LLM 服務對每分鐘生成的 token 總量有明確上限。
     • 這種限制直接影響了系統的最大處理吞吐量。

這些限制是由 LLM 服務的基礎架構決定的，超出了我們的 GraphRAG 框架的優化范圍。不過，這也為我們指明了未來的優化方向：

- 探索模型部署的彈性伸縮方案。
- 研究請求批處理的智能調度策略。
- 優化 token 使用效率（比如，精簡系統提示詞等等）。

“上下文增強”方法的優勢在于：

• LLM 能夠獲得更全局的知識視角，不會被單個文本塊的局部信息所限制。
• 通過上下文的補充，能夠建立起更準確的實體關系。
• 最終形成的知識圖譜質量更高，關系更加準確和完整。

例如，當處理一個關于“深度學習”的文本塊（chunk）時，通過檢索相似內容，LLM 可以（通過系統支持的相似度算法）同時看到“神經網絡結構”、“反向傳播算法”等在意義上相似的文本塊（chunk），從而幫助 LLM 更準確地抽取出三元組/實體之間的關系，如： 【深度學習】--（使用）->【反向傳播算法】； 【神經網絡】--（是）->【深度學習模型】。

至此，加上前文提到的文檔結構，我們拓展了 GraphRAG 對于 Graph 的定義范疇：

其中，

• 三元組有向圖（Triplets Graph）：捕獲實體間語義關系。
• 文檔結構圖（Document Structure Graph）：保持知識層級結構。

這種圖結構不僅僅繪制了一張“知識地圖”，還為 LLM 順藤摸瓜式地依據 entity 回溯到原始文本塊（chunk）提供了可能性。在未來，我們或許構建一個更加復雜、覆蓋更加全面的信息的圖，支持更加復雜的檢索算法。

2.3 社區摘要總結

為了更好地宏觀地、全局地理解和組織圖譜中的知識，我們引入了社區層面的知識總結和歸納機制。這個過程分為三個關鍵步驟：

2.3.1 社區發現

GraphRAG 默認采用 Leiden 算法進行社區檢測。它以其高效和準確的特點著稱，該算法能夠：

• 自動發現知識實體間的緊密關聯群組。
• 在保持社區內部聯系緊密的同時，確保社區間邊界清晰。
• 適應性地確定合適的社區規模。

2.3.2 社區文本化

對于每個識別出的社區，我們進行了系統的信息提?。矗瑘D的展開過程）：

• 收集社區內所有實體的屬性信息、提取實體間的關系描述。
• 將圖結構信息轉換為結構化文本表示。

2.3.3 社區總結

基于文本化的社區信息，我們通過以下步驟生成社區摘要：

• 調用 LLM 分析社區的核心主題和關鍵概念，生成凝練的社區主題描述（使用并發處理社區摘要總結功能）。
• 將摘要信息持久化存儲，便于后續檢索和分析。

因此，得益于文檔結構+三元組結構，以及社區摘要總結，新版的 GraphRAG 不僅提供了知識圖譜的局部視角，幫助人們發現知識間的緊密聯系，還為知識圖譜的應用提供了更高層次的語義理解基礎。

2.4 圖數據建模

在設計 GraphRAG 數據持久化的階段，我們選擇了 TuGraph 作為底層存儲引擎。同時，在原來的圖模型（Graph Schema）的基礎上，新設計了一套完整的圖模型，使得圖譜表達、存儲和索引文檔結構的部分。因此，新的圖模型具備如下特點：

1. 完整保留文檔的層級結構。
2. 清晰表達文本塊之間的關系。
3. 支持三元組知識實體的關聯表示。

2.4.1 點類型

GraphRAG 定義了三種基本的節點類型：

1. document：表示文檔對象
   • 核心屬性：id、name。
   • 可選屬性：community_id（用于社區劃分）。
2. chunk：表示文檔的文本塊
   • 核心屬性：id、name。
   • 可選屬性：community_id（用于社區劃分）、content（塊的具體內容）。
3. entity：表示知識實體
   • 核心屬性：id、name
   • 可選屬性：community_id（用于社區劃分）、description（實體描述）。

2.4.2 邊類型

為了準確表達節點之間的關系，GraphRAG 定義了五種特定的邊類型：

1. 包含關系邊：
   • document_include_chunk：文檔包含文本塊。
   • chunk_include_chunk：文本塊間的層級包含。
   • chunk_include_entity：文本塊包含知識實體。
2. 順序關系邊：
   • chunk_next_chunk：文本塊之間的順序關系。
3. 語義關系邊：
   • relation：三元組實體之間的語義關系。

每種邊類型都包含基本屬性（id、name）和可選的描述信息（description）。對于實體間的關系邊，GraphRAG 還額外記錄了 chunk_id，用于追蹤關系的來源上下文。

基于這種建模方式，我們不僅實現了文檔的結構化存儲，還為后續的知識圖譜構建和語義分析打下了基礎。

3. 知識圖譜檢索

知識圖譜的構建為智能檢索奠定了基礎，但如何高效地檢索和利用這些結構化知識仍面臨諸多挑戰。我們設計了一套多層次的檢索框架，通過融合不同維度的知識表示，實現精準且全面的信息獲取。

3.1 關鍵詞抽取

首先，GraphRAG 需要準確理解用戶的查詢意圖。通過調用 LLM 實現查詢解析：用戶輸入 Query -> 關鍵詞。比如，提取出關鍵的搜索詞：“機器學習”、“入門”、“基礎”、“教程”等。

3.2 局部檢索：三元組圖譜檢索

基于提取的關鍵詞，我們首先通過簡單的圖查詢語句，定位到相關的知識實體（entity）和文本塊（chunk）。次后，GraphRAG 憑借圖的多跳遍歷，探索實體之間的關聯關系，獲取更多的關聯信息。

為了更好地理解多跳遍歷，我們舉一個例子。在知識圖譜中，多跳遍歷這就像是：

• 首先發現一個 AI 相關的知識點，發現它與"深度學習"有關（一跳）。
• 順著這條線索，又找到了"深度學習"與"神經網絡"的關聯（二跳）。
• 繼續探索，發現"神經網絡"又與"反向傳播"有密切關系（多跳）。
• 通過這種方式，GraphRAG 不僅可以找到最直接相關的答案，還能借助多跳探索，得到一張子圖，從而提供更加全面和豐富的信息。

3.3 全局檢索：社區摘要檢索

通過社區檢測算法 Leiden，GraphRAG 能夠獲取與查詢相關的知識社區概覽，提供了更宏觀的知識視角。

3.4 原文檢索：文檔結構檢索

對于檢索到的文本塊，系統通過文檔結構中的“包含”關系（include）“向上”回溯，直到回溯至文檔節點（document）。這種溯源機制保證了知識的可追溯性，還作為原始語境，以幫助用戶理解上下文信息。筆者暫且稱之為“知識溯源”。

• 以 TuGraph 查詢為例，解釋知識溯源的過程：

假設用戶詢問："TuGraph 在金融風控方面的應用效果如何？"

第一步：定位相關文本塊 系統首先找到了這個關鍵信息（chunk）：

在金融風控方面，TuGraph已幫助金融機構提升反欺詐和反洗錢的效率，例如，某銀行的反洗錢風險事件分析效率提升了790%，并在信貸平臺中提高了713%的風控覆蓋區分率。

第二步：向上溯源 系統通過 include 關系，逐層回溯：

1. 發現這個文本塊屬于"應用案例"部分。
2. “應用案例”進一步屬于 TuGraph 的整體介紹文檔。
3. 最終定位到完整的文檔結構： 

TuGraph簡介
├── 主要特性
│   ├── 高效性
│   ├── 分布式架構
│   └── 多樣功能
└── 應用案例
    └── 金融風控應用  <- 當前內容位置

從“當前內容位置”到 TuGraph 簡介的過程，筆者稱之為“向上溯源”。

3.5 生成回答

最后 GraphRAG 將來自三個鏈路的檢索結果整合起來，形成一個完整的知識集合：

• 局部檢索提供具體的知識點和關聯關系。
• 全局檢索提供領域概覽和知識聚類。
• 原文檢索提供可溯源的文檔依據。

這些多維度的知識被輸入到 LLM 中，模型會結合用戶的查詢意圖，生成一個全面、準確且連貫的回答，最后返回給用戶。GraphRAG 所做的一切，均是為了確保了答案的準確性，為用戶提供深入的知識洞察。

4. 效果演示

4.1 可視化

目前，用戶可以快速地在 DB-GPT v0.6.2 版本的前端應用中體驗到該功能，并且該前端提供了清晰直觀的知識圖譜可視化圖。生成的知識圖譜由 AntV G6 引擎驅動渲染。

4.2 問答示例

用戶詢問的是 “TuGraph” 的基本信息。系統通過關鍵詞提取，準確定位到了相關的知識節點。這驗證了筆者前面討論的查詢理解機制的有效性。

特別值得注意的是答案底部的引用部分（藍色引用框），這正是之前討論的“知識溯源”機制的體現：

• 借助文檔結構的實現，GraphRAG 不僅可以回答用戶問題，還可以標明信息的具體來源。
• 通過引用原文的方式，GraphRAG 確保了信息的可信度，方便用戶進一步探索。

5. 性能測試

5.1 測試結果

為了方便對比，我們選用 graphrag-test.md 測試文本，來分別測試我們版本的 GraphRAG 和微軟版本的 GraphRAG 的性能。通過實測發現，我們的方案在保持相近的文檔輸入規模(42,631 tokens)的情況下，取得了一下成果（相比微軟版本的 GraphRAG方案，9 月份版本）：

1. 總 Token 消耗是微軟 GraphRAG 的 42.9%（**417,565 **vs 972,220）。
2. 特別是，生成 Tokens 量是微軟 GraphRAG 的 18.4%（41,797 vs 227,230）。
3. 構建知識圖譜的時間是微軟 GraphRAG 的 80.1% （170s vs 210s）。
4. 我們支持文檔結構圖譜， 微軟 GraphRAG 不支持。
5. 同時，我們的圖譜結構保持了相當的復雜度（734節點/1164 邊 vs 779節點/967邊），確保了知識表示的完整性和覆蓋率大約保持同一水平。

	GraphRAG (DB-GPT)	GraphRAG (Microsoft)
Doc Tokens	42631	42631
Triplets Graph	734 nodes, 1064 edges	779 nodes, 967 edges
Doc Structure Graph	76 nodes, 1090 edges	N/A
Prompt Tokens	375768	744990
Completion Tokens	41797	227230
Total Tokens	417565	972220
Indexing Time	170s	210s

• 全局檢索：性能有明顯提升。

	GraphRAG (DB-GPT)	GraphRAG (Microsoft)
Time	8s	40s
Tokens	7432	63317

• 局部搜索：性能基本相當。

	GraphRAG (DB-GPT)	GraphRAG (Microsoft)
Time	15s	15s
Tokens	9230	11619

5.2 結果分析

微軟 GraphRAG 方案在 Map 步驟中，將社區報告分割成預定義大小的文本塊。每個文本塊用于生成包含點列表的中間回答，每個點都有相應的數值評分，表示該點的有用度（評分標準：有用度 0-100，LLM 作為“評委”）。然后，在 Reduce 步驟中，從中間響應中篩選出最有用的一些點，并將它們聚合起來，作為生成最終回答的上下文。為了獲得 map-reduce 中每個點的“有用度”評分，需要多次調用 LLM，因此微軟 GraphRAG 消耗了更多的 tokens 和時間。實際上，這種中間回答缺少了全局視野/全局信息，導致 LLM 在評估中間回答的有用度時，存在偏差。

• 為了更好理解偏差產生的原因，以三國演義為例。用戶問題： “曹操為什么會失去荊州的統治權？”
• 社區摘要塊和中間回答：
  • 片段1： "荊州原本由劉表治理。建安十三年（208年），劉表病逝，其子劉琮投降曹操。曹操派兵南下，占領荊州。"
    • 中間回答：荊州最初是通過劉琮投降而落入曹操之手。
    • LLM 評分：85（高分，因為直接回答了曹操如何獲得荊州）。
  • 片段2： "周瑜和諸葛亮在赤壁之戰中，以火攻大敗曹操軍隊。曹操被迫退往北方。"
    • 中間回答：曹操在赤壁之戰中戰敗，不得不撤離。
    • LLM 評分：70（中分，因為描述了曹操退往北方，而荊州在南方，說明曹操基本不可能獲得統治權）。
  • 片段3： "劉備派關羽鎮守荊州。關羽善用水軍，又因當地百姓擁護，使得荊州基業穩固。"
    • 中間回答：關羽接管了荊州的防務。
    • LLM 評分：30（低分，因為看似只是一個人事安排，和曹操無關）。
• 偏差分析：
  • LLM 對片段3的評分較低，因為單獨看這段內容，似乎只是一個簡單的人事調動。但實際上，關羽鎮守荊州是極其關鍵的信息，因為：不僅展示了劉備勢力的實際控制，表明了荊州易主的完整過程，還反映了民心向背的重要性。片段 3 將會被微軟 GraphRAG 按照算法篩選掉。如此，偏差產生。

進一步地，當圖的規模增大時，即節點數量和邊數量增多，建議選擇直接通過相關的社區檢測（community detection）算法來計算社區的聚集程度，以此定義某些被發現的子圖對于用戶問題的重要程度，而并不使用有用度評分機制。筆者認為，這才是在全局索引維度下，GraphRAG 的職責之一——提供“全局信息”。在大規模圖的情況下，微軟 GraphRAG 的 map-reduce 方法的真實效果如何，索引性能是否依舊優秀？后續或許可以通過進行更多的實驗來檢驗這些觀點是否正確。

微軟 GraphRAG 采用并行處理策略，對社區摘要塊進行批量處理以生成中間答案，這種方法雖提高了處理速度，但帶來了額外的 tokens 和時間開銷。在生成中間態回答的同時，一定程度上引入了信息損耗和偏差：

（1）信息完整性損失：缺乏跨塊信息關聯。

（2）語義理解偏差：局部處理影響全局判斷"。

無論如何，我們的版本考慮到了這些隱患和偏差。當然，微軟 GraphRAG 在開源社區取得了巨大的成功，也是筆者學習和借鑒的對象。

總得來說，我們取得了不錯的效果：在構建同樣規模的知識圖譜的情況下，我們在構建圖譜這個任務上，花費了更少的時間（約80%），**消耗了更少的 tokens **（約40%）。同時，在回答需要全局檢索的用戶問題時，根據測試結果，我們版本的 GraphRAG 在時間和 tokens 的消耗上更具優勢。此外，我們的 GraphRAG 得益于文檔結構的支持，我們可以搜索原文，并將原文作為參考文本的一個部分返回給用戶，讓用戶可以獲得更可靠的原文信息。