使用GraphRAG讀小說《凡人修仙傳》
文檔簡要介紹了如何利用GraphRAG，實現(xiàn)對長篇小說等大規(guī)模文本的高效理解與問答。內容涵蓋GraphRAG的基本原理、核心優(yōu)勢及其在實際應用中的操作流程，幫助初學者快速上手并掌握其用法。
1. 什么是知識圖譜（knowledge graph ）
2. 傳統(tǒng)RAG與GraphRAG差異
3. GraphRAG知識模型的核心定義
4. GraphRAG工作的核心階段
5. 安裝GraphRAG
6. 使用方法
6.1 CLI 命令行
6.2 Python API
7. 初始化
8. 修改配置
9. 準備數(shù)據(jù)
10. 創(chuàng)建索引
10.1 索引階段的Token使用情況
11. 查詢
利用檢索增強生成（RAG）從外部知識源中獲取相關信息，使大型語言模型（LLMs）能夠回答涉及私有文檔或未見過文檔集合的問題。
基礎 RAG 系統(tǒng)僅依靠向量數(shù)據(jù)庫中的語義搜索來檢索和排序獨立的文本片段。
盡管這種方法能提供一些相關信息，但它無法捕捉這些片段之間的上下文聯(lián)系，基礎 RAG 系統(tǒng)難以回答復雜的多跳問題。
或者當問題指向整個語料庫時，RAG 往往也會失效，比如問題：“這個數(shù)據(jù)集的主題是什么？”，這類問題本質上屬于面向查詢的摘要任務，而不是單純的檢索任務。
GraphRAG，是利用知識圖譜（knowledge graph ）來表示和連接信息，不僅捕獲更多數(shù)據(jù)點，還捕獲它們之間的關系。因此，基于圖的檢索器能夠通過揭示那些不明顯但至關重要的關聯(lián)信息，提供更準確和相關的結果。
他既能適應用戶問題的泛化程度，也能應對龐大的文本規(guī)模。
GraphRAG利用 LLM 分兩個階段構建圖索引：先從源文檔中抽取實體知識圖，再為每一組緊密相關的實體預生成群體摘要。面對問題時，系統(tǒng)會先根據(jù)這些群體摘要生成局部回答，再將所有局部回答整合成最終答復。
對于百萬級別 token 數(shù)據(jù)集上的全局理解類問題， GraphRAG 相比傳統(tǒng) RAG 在答案的全面性和多樣性上都有顯著提升。
1. 什么是知識圖譜（knowledge graph ）
知識圖譜（knowledge graph ）是一種結構化的方式來表示現(xiàn)實世界中的人、事、物及其相互關系。
知識圖譜里的實體可以代表各種事物，比如具體對象、發(fā)生的事件、特定情境或抽象概念。實體之間的聯(lián)系則體現(xiàn)了它們相互關聯(lián)的背景和含義。
之前傳統(tǒng) RAG 方式實際上效果不佳，各個信息比較碎片化，所以我們希望將這些概念之間的復雜關系展現(xiàn)出來。在查詢時，不再是大海撈針去找「可能相關」的信息碎片，而是根據(jù)圖譜中已經掌握的關聯(lián)，提取一整串相連的信息，讓大語言模型來一并處理。
GraphRAG結合了知識圖譜結構和 RAG 方法，解決傳統(tǒng) RAG 方法的局限性。
2. 傳統(tǒng)RAG與GraphRAG差異
維度 | 傳統(tǒng)RAG | GraphRAG |
數(shù)據(jù)表示 | 向量數(shù)據(jù)庫中的孤立文本塊 | 結構化的知識圖譜（實體、關系、社區(qū)） |
檢索機制 | 基于向量相似性的語義搜索 | 圖譜遍歷、社區(qū)摘要和混合檢索 |
擅長問題類型 | 簡單的事實性檢索 | 復雜的、跨文檔的、需要全局理解和推斷的問題 |
上下文理解 | 僅基于局部、碎片化的文本 | 能夠理解實體間的關系和全局主題 |
可解釋性 | 檢索結果是一系列文本片段，可解釋性較低 | 能夠展示答案來源和推理路徑，可解釋性高 |
3. GraphRAG知識模型的核心定義
GraphRAG所構建的知識模型由多個相互關聯(lián)的核心定義構成，它們共同描繪了數(shù)據(jù)的深層結構 ：
- 實體（Entities）：這是知識圖譜中的基本節(jié)點，代表著文本中被識別出的關鍵對象，例如人、地點、組織、事件或概念。LLM會從原始文本中提取這些實體，并賦予其一個標題、類型和描述 。
- 關系（Relationships）：這是連接實體之間的邊，描述了實體之間的聯(lián)系。它將實體連接起來。關系也包含一個描述，詳細說明了連接的性質 。
- 文本單位（TextUnits）：它是原始輸入文檔被切分后得到的邏輯文本塊。這些文本單位是圖譜（如實體和關系）的來源，并在查詢階段作為證據(jù)來源被引用 。
- 社區(qū)（Communities）：這是GraphRAG實現(xiàn)高層次理解的關鍵。在圖譜構建完成后，系統(tǒng)會利用聚類算法（如Hierarchical Leiden算法）識別出由緊密相連的實體組成的群組，這些群組被稱為社區(qū) 。這種層次化的社區(qū)結構能夠幫助系統(tǒng)從不同的粒度審視數(shù)據(jù)。
- 社區(qū)報告（Community Reports）：這是LLM為每個社區(qū)生成的摘要。這些報告提供了對社區(qū)內關鍵實體、關系和主旨的高層次概述，并在全局搜索等查詢模式中發(fā)揮核心作用 。
4. GraphRAG工作的核心階段
GraphRAG的整個工作流程可以清晰地分為兩大核心階段：
索引階段（Indexing Phase）： 在這個階段，系統(tǒng)將原始的非結構化文本數(shù)據(jù)作為輸入，通過一系列復雜的LLM調用和數(shù)據(jù)轉換步驟，自動構建出結構化的知識圖譜及其相關的知識模型基本單元（如社區(qū)和摘要）。這個過程是一個自下而上的知識提煉過程 。
查詢階段（Querying Phase）： 在知識圖譜構建完成后，系統(tǒng)進入查詢階段。此時，用戶可以提出自然語言問題，查詢引擎會利用已構建的知識圖譜來為LLM提供更豐富、更具關聯(lián)性的上下文信息，從而生成準確、有洞察力的答案 。
GraphRAG所構建的知識圖譜不僅僅是一個簡單的信息存儲庫。它本質上是一個更豐富的、具有內在語義和拓撲結構的“記憶結構”。與傳統(tǒng)RAG將信息視作孤立的、無關聯(lián)的文本片段不同，GraphRAG通過LLM自動識別并編織這些片段之間的關系網絡。這意味著在查詢時，LLM不再是簡單地閱讀孤立的文本片段，而是可以基于這個結構化的“大腦”進行復雜的“推理”和“聯(lián)想”，沿著圖譜中的關系路徑進行知識遍歷，從而提供更具深度和廣度的答案。
5. 安裝GraphRAG
為了調試方便，我直接拉源碼下來
git clone https://github.com/microsoft/graphrag.git當前的版本是v2.5.0
新建虛擬環(huán)境（這里使用uv作為包管理工具）,使用Python3.11.9
uv venv -p 3.11.9切換到新建的虛擬環(huán)境：
.venv\Scripts\activate安裝依賴：
uv sync6. 使用方法
GraphRAG可以選擇通過 CLI 或 Python API 來運行
6.1 CLI 命令行
這是我們體驗的主要操作方式，如：??graphrag index --root ./ragtest ??
6.2 Python API
查看索引 API 的 Python 文件(???https://github.com/microsoft/graphrag/blob/main/graphrag/api/index.py??)，了解從 Python 代碼中直接調用的推薦方法。
7. 初始化
運行 ??graphrag init?? 命令
graphrag init --root ./ragtest這將在 ??./ragtest??? 目錄中創(chuàng)建兩個文件： ??.env??? 和 ??settings.yaml??? 和一個目錄 ??prompts??。
看一下結構：
> tree ragtest /f
G:\WORKSPACE\IDEA\PY\GITHUB\GRAPHRAG\RAGTEST
│ .env
│ settings.yaml
│
└─prompts
basic_search_system_prompt.txt
community_report_graph.txt
community_report_text.txt
drift_reduce_prompt.txt
drift_search_system_prompt.txt
extract_claims.txt
extract_graph.txt
global_search_knowledge_system_prompt.txt
global_search_map_system_prompt.txt
global_search_reduce_system_prompt.txt
local_search_system_prompt.txt
question_gen_system_prompt.txt
summarize_descriptions.txt8. 修改配置
??.env??
??.env??? 包含運行 GraphRAG 流程所需的環(huán)境變量。其中定義了一個環(huán)境變量， ??GRAPHRAG_API_KEY=<API_KEY>??? 。將 ??<API_KEY>?? 替換為您個人的模型密鑰。（我這里用的阿里百煉）
??settings.yaml??
??settings.yaml?? 通過修改此文件來更改所有的配置。
GraphRAG主要用到兩個模型：一個語言模型，一個嵌入模型，以下是我使用的配置
### This config file contains required core defaults that must be set, along with a handful of common optional settings.
### For a full list of available settings, see https://microsoft.github.io/graphrag/config/yaml/
### LLM settings ###
## There are a number of settings to tune the threading and token limits for LLM calls - check the docs.
models:
default_chat_model: # 定義語言模型
type:openai_chat# or azure_openai_chat
api_base:https://dashscope.aliyuncs.com/compatible-mode/v1 # 改為你的模型調用地址
# api_version: 2024-05-01-preview
auth_type:api_key# or azure_managed_identity
api_key:${GRAPHRAG_API_KEY}# set this in the generated .env file # 從.env讀取key
# audience: "https://cognitiveservices.azure.com/.default"
# organization: <organization_id>
model:qwen-flash # 你使用的語言模型
# deployment_name: <azure_model_deployment_name>
encoding_model:cl100k_base# automatically set by tiktoken if left undefined # 確定分詞編碼方式
model_supports_json:true# recommended if this is available for your model.
concurrent_requests:25# max number of simultaneous LLM requests allowed
async_mode:threaded# or asyncio
retry_strategy:native
max_retries:10
tokens_per_minute:1000000 # set to null to disable rate limiting # 確定TPM，可選
requests_per_minute:1000 # set to null to disable rate limiting # 確定RPM，可選
default_embedding_model:
type:openai_embedding# or azure_openai_embedding # 嵌入模型
api_base:https://dashscope.aliyuncs.com/compatible-mode/v1 # 改為你的模型調用地址
# api_version: 2024-05-01-preview
auth_type:api_key# or azure_managed_identity
api_key:${GRAPHRAG_API_KEY} # 從.env讀取key
# audience: "https://cognitiveservices.azure.com/.default"
# organization: <organization_id>
model:text-embedding-v4 # 你使用的嵌入模型
# deployment_name: <azure_model_deployment_name>
encoding_model:cl100k_base# automatically set by tiktoken if left undefined # 確定分詞編碼方式
model_supports_json:true# recommended if this is available for your model.
concurrent_requests:25# max number of simultaneous LLM requests allowed
async_mode:threaded# or asyncio
retry_strategy:native
max_retries:10
tokens_per_minute:1000000 # set to null to disable rate limiting or auto for dynamic 確定TPM，可選
requests_per_minute:1500 # set to null to disable rate limiting or auto for dynamic 確定RPM，可選
### Input settings ###
input:
storage:
type:file# or blob
base_dir:"input"
file_type:text# [csv, text, json]
chunks:
size:1200
overlap:100
group_by_columns:[id]
### Output/storage settings ###
## If blob storage is specified in the following four sections,
## connection_string and container_name must be provided
output:
type:file# [file, blob, cosmosdb]
base_dir:"output"
cache:
type:file# [file, blob, cosmosdb]
base_dir:"cache"
reporting:
type:file# [file, blob]
base_dir:"logs"
vector_store:
default_vector_store:
type:lancedb
db_uri:output\lancedb
container_name:default
overwrite:True
### Workflow settings ###
embed_text:
model_id:default_embedding_model
vector_store_id:default_vector_store
batch_size:10 # 嵌入的批量大小，要符合API限制
batch_max_tokens:8191
extract_graph:
model_id:default_chat_model
prompt:"prompts/extract_graph.txt"
entity_types:[organization,person,geo,event]
max_gleanings:1
summarize_descriptions:
model_id:default_chat_model
prompt:"prompts/summarize_descriptions.txt"
max_length:500
extract_graph_nlp:
text_analyzer:
extractor_type:regex_english# [regex_english, syntactic_parser, cfg]
cluster_graph:
max_cluster_size:10
extract_claims:
enabled:false
model_id:default_chat_model
prompt:"prompts/extract_claims.txt"
description:"Any claims or facts that could be relevant to information discovery."
max_gleanings:1
community_reports:
model_id:default_chat_model
graph_prompt:"prompts/community_report_graph.txt"
text_prompt:"prompts/community_report_text.txt"
max_length:2000
max_input_length:8000
embed_graph:
enabled:true# if true, will generate node2vec embeddings for nodes
umap:
enabled:true# if true, will generate UMAP embeddings for nodes (embed_graph must also be enabled)
snapshots:
graphml:true
embeddings:false
### Query settings ###
## The prompt locations are required here, but each search method has a number of optional knobs that can be tuned.
## See the config docs: https://microsoft.github.io/graphrag/config/yaml/#query
local_search:
chat_model_id:default_chat_model
embedding_model_id:default_embedding_model
prompt:"prompts/local_search_system_prompt.txt"
global_search:
chat_model_id:default_chat_model
map_prompt:"prompts/global_search_map_system_prompt.txt"
reduce_prompt:"prompts/global_search_reduce_system_prompt.txt"
knowledge_prompt:"prompts/global_search_knowledge_system_prompt.txt"
drift_search:
chat_model_id:default_chat_model
embedding_model_id:default_embedding_model
prompt:"prompts/drift_search_system_prompt.txt"
reduce_prompt:"prompts/drift_search_reduce_prompt.txt"
basic_search:
chat_model_id:default_chat_model
embedding_model_id:default_embedding_model
prompt:"prompts/basic_search_system_prompt.txt"??prompts??
??prompts?? 目錄中生成了將要使用到的所有提示詞。
我們需要把??extract_claims.txt???和??extract_graph.txt?? 中的“語言”修改為中文，避免生成英文內容。
??extract_claims.txt??
3. Return output in 中文 as a single list of all the claims identified in steps 1 and 2. Use **{record_delimiter}** as the list delimiter.??extract_graph.txt??
3. Return output in 中文 as a single list of all the entities and relationships identified in steps 1 and 2. Use **{record_delimiter}** as the list delimiter.9. 準備數(shù)據(jù)
新建數(shù)據(jù)目錄：
mkdir -p ./ragtest/input我準備了《凡人修仙傳》前125章，一共25萬字左右，放到input目錄中
10. 創(chuàng)建索引
在命令行執(zhí)行：
graphrag index --root ./ragtest這個時間會比較長，我這里用了20分鐘
GraphRAG的索引是其強大能力的來源，但同時也帶來了顯著的問題。
該過程被人們描述為“是一個昂貴的操作”，因為它涉及多次LLM調用，真的是“又貴又慢”。
這種高成本是其設計本身的直接結果。
系統(tǒng)不滿足于簡單的文本嵌入，而是通過LLM進行多輪次的文本解析、實體關系提取和社區(qū)摘要生成，每一步都是一次潛在的、昂貴的API調用。
因此，GraphRAG的“高成本”是其在復雜問題上實現(xiàn)“高精度”和提供“高洞察力”的直接代價。
對于希望在實踐中部署GraphRAG的人而言，這是必須要考慮的一個問題.
10.1 索引階段的Token使用情況
測試小說全文25萬字，
語言模型 qwen-flash 的使用情況：
調用總次數(shù)1690次，輸入Tokens總量3,890.1千Tokens，輸出Tokens總量1,319.6千Tokens
嵌入模型 text-embedding-v4 的使用情況：
調用總次數(shù)301次，全部Tokens總量780.5千Tokens
11. 查詢
這里的查詢方式有兩種：
局部查詢：
通過將 AI 提取到知識圖譜中的相關數(shù)據(jù)與原始文檔的文本塊相結合來生成答案，此方法適用于需要了解文檔中提到的特定實體的問題。
全局查詢：
全局查詢方法通過以 map-reduce 方式搜索所有 AI 生成的社區(qū)報告來生成答案。這是一種資源密集型方法，需要LLM支持的context window足夠大，但通常可以很好地回答需要了解整個數(shù)據(jù)集的問題。
那么我們現(xiàn)在就來用《凡人修仙傳》問一些問題吧。
使用全局搜索來提出一個概括性問題的例子：
graphrag query --root ./ragtest --method global --query "韓立和墨大夫是什么關系?"
(graphrag) PS G:\workspace\idea\py\github\graphrag> graphrag query --root ./ragtest --method global --query "韓立和墨大夫是什么關系?"
韓立與墨大夫的關系極為復雜，呈現(xiàn)出多重身份交織的深層張力，既包含師徒傳承、權力交接與醫(yī)術繼承的正面紐帶，又暗藏敵對、控制與奪舍的致命沖突。這一關系并非單一維度，而是貫穿于修仙世界中的權謀、生存與自我覺醒的核心敘事主線。
從傳承與身份的角度看，墨大夫是韓立的親傳師尊。他主持了韓立的入門考核，將其納入七玄門正式弟子序列，傳授《長春功》第一層法決與“引魂鐘”這一關鍵法器，標志著韓立正式進入修真體系 [Data: Reports (19, 82, 158, 119, 167, 260, +more)]。墨大夫還通過“紋龍戒”這一信物認證韓立的身份，其與嚴氏戒指的契合進一步確認了韓立作為真?zhèn)鞯茏拥暮戏ㄐ裕顾靡赃M入墨府、參與核心事務 [Data: Reports (80, 146, 157, 158, 146)]。此外，韓立在墨府期間承擔了謄錄《 醫(yī)道心得》的重任，這不僅是對醫(yī)術傳承的履行，也標志著其從外部觀察者向內部體系參與者的身份轉變 [Data: Reports (216, 19, 146)]。墨大夫去世后，韓立 接任其職位，成為七玄門新的首席醫(yī)師，完整繼承了其醫(yī)術權威與藥園資源，并利用神秘瓶子大規(guī)模催生藥材，展現(xiàn)出超越前任的掌控能力，完成了從弟子到領袖的權力交接 [Data: Reports (57, 65, 66, 3, 112, 185, 30, 36)]。
然而，這一表面的師徒關系之下，隱藏著深刻的敵對與控制本質。墨大夫對韓立的“教導”實為精心設計的奪舍計劃。他通過傳授《長春功》這一功法，實則植入了奪舍機制，意圖借韓立的肉身實現(xiàn)自身元神的轉移與長生 [Data: Reports (207, 115, 59, 60, 153)]。墨大夫更以“尸蟲丸”與“纏香絲”等毒藥進行雙重控制，使韓立長期處于生死依賴狀態(tài)——需服藥以避免骨骼異變與癱瘓，從而確保其絕對服從 [Data: Reports (153, 82, 0, 55, 69, 257, 140, 1278, 597, 681, 625)]。此外，墨大夫通過“定”字咒語與黃紙符咒構建的法術體系，實施意識入侵與靈魂操控，試圖在夢境中奪取韓立的神識 [Data: Reports (151, 28, 152, 45, 156)]。在“套
中套”情節(jié)中，墨大夫更主導了“七鬼噬魂大法”的奪舍儀式，其行為具有高度預謀性與攻擊性，直接威脅韓立的自我意識完整性 [Data: Reports (31, 21, 45, 22, 152, 2452, +more)]。使用局部搜索來詢問關于某個特定角色的更具體問題的例子：
graphrag query --root ./ragtest --method local --query "墨大夫是個什么樣的人"
(graphrag) PS G:\workspace\idea\py\github\graphrag> graphrag query --root ./ragtest --method local --query "墨大夫是個什么樣的人"
墨大夫是一位復雜而深藏不露的角色，其形象貫穿于整個故事的多個層面，既是醫(yī)術高超的象征，也是陰謀與權謀交織的核心人物。他是七玄門前任首席醫(yī)師，被稱
為“神醫(yī)墨大夫”，以醫(yī)術高明著稱，能夠救治內外傷及疑難雜癥，甚至在藥效上超越了前任醫(yī)師，盡管其醫(yī)術受限于藥材資源 [Data: Entities (819); Sources (1
50)]. 他不僅醫(yī)術精湛，還極富謀略與遠見，其居所內藏有暗格，存放著虛假身份文件、親筆證明、名單以及控制手段，顯現(xiàn)出其在生前便已布局長遠，為后人留下重重謎題 [Data: Entities (793); Relationships (1365)]。
墨大夫的個性極具矛盾性：他既是韓立的上司與前任，又是被韓立稱為“墨老鬼”的令人畏懼的存在，反映出韓立對其既敬且畏的心理 [Data: Entities (482, 819);
Relationships (822)]. 他行事沉穩(wěn)，善于隱藏真實意圖，例如在與韓立對峙時，其“虛實掌法”看似兇猛卻只用半成功力，實則是一種試探與保護 [Data: Entitie
s (620); Relationships (1070)]. 他在關鍵時刻出聲阻止鐵奴的攻擊，展現(xiàn)出對局勢的絕對掌控力，其聲音具有壓倒性的權威，足以讓鐵奴立即停手 [Data: Entities (655); Relationships (1140)]。
此外，墨大夫的死亡并非表面所見的簡單事件。他的尸體被發(fā)現(xiàn)于屋內，其身上藏有香囊，且在臨終前留下遺書，暗示其早已預料到未來變局，并為韓立安排了復雜
的任務與交易 [Data: Entities (776, 1348, 1350); Relationships (1340)]. 他甚至在臨死前察覺到自身傷口異樣，意識到中了“纏香絲”毒藥，心理防線開始動 搖，這表明他并非毫無防備，而是身陷險境 [Data: Entities (650, 631, 632); Relationships (1124, 1098, 1099)]。
更耐人尋味的是，墨大夫身后還有一位神秘人，始終緊隨其后，寸步不離，身份不明，可能為護衛(wèi)或隨從，暗示其生前并不孤單，背后或有更深的勢力支撐 [Data:
Entities (461); Relationships (782)]. 他最終的故鄉(xiāng)位于嵐州，是韓立必須前往的地理節(jié)點，也是整個事件推動的關鍵所在 [Data: Entities (1159, 2188); Relationships (2228)]。
綜上所述，墨大夫不僅是一位醫(yī)術超群的醫(yī)生，更是一位布局深遠、心思縝密的智者，其生前行為與死后遺局深刻影響了韓立的命運，其形象融合了醫(yī)者仁心、權謀深沉與神秘莫測的特質 [Data: Entities (1171, 819, 793, 1159); Relationships (1365, 1340, 1124, 1099, 2188, +more)].GraphRAG代表了RAG技術發(fā)展的一個重要方向，它通過將非結構化文本轉化為結構化知識圖譜，實現(xiàn)了從簡單的“信息檢索”到基于“知識結構”的“智能推理”的范式轉變。
問題是GraphRAG目前在成本、資源消耗和數(shù)據(jù)增量更新方面存在挑戰(zhàn)。
不過他有效地解決了傳統(tǒng)RAG在處理復雜、跨文檔和全局性問題時所面臨的核心局限。它提供了一種強大方式，使得LLM能夠基于可驗證的知識基礎生成答案，從而顯著減少了幻覺（hallucination）的風險。
對于希望為企業(yè)構建高精度、高可解釋性生成式AI應用的開發(fā)者和研究人員來說，GraphRAG是一個值得深入探索和關注的前沿技術。
本文轉載自??AI取經路??，作者：AI取經路
