GraphRAG：从向量检索到知识图谱增强的进化之路

引言：当向量检索触及天花板

2026年，一个令业界警醒的数据浮出水面：超过68%的企业传统RAG项目因"复杂推理失败"和"全局认知缺失"而未能跨越生产环境的鸿沟。与此同时，以微软GraphRAG为代表的图增强检索技术正式跨越技术触发期，进入生产成熟期，成为金融风控、医疗科研、政务智库等复杂知识密集型场景的"新标配"。

平面向量检索正在触及天花板。2026年，大模型外挂知识库的范式已从"语义相似度匹配"全面跃迁至"图谱结构化推理"。这不是渐进式改进，而是一次根本性的范式转换。

本文将深入剖析传统RAG的致命缺陷、GraphRAG的核心原理、以及从零构建GraphRAG系统的完整工程实践。

一、传统RAG的三大致命缺陷

1.1 "管中窥豹"效应：局部性盲区

用户提问：“总结这份100页财报中，A业务线和B业务线在亚太区的战略差异。”

传统RAG表现：由于A和B的信息分散在不同页面，向量检索只能召回语义最接近的Top-K个片段，无法跨文档建立关联，导致回答片面甚至产生幻觉。

这个问题的本质是：向量检索是"局部相似性"驱动的，它只能找到与问题最相似的片段，但无法理解片段之间的逻辑关系。就像你只能通过关键词找到书中的某些段落，但无法理解整本书的论证结构。

1.2 多跳推理失败

用户提问：“公司X的现任CEO的母校，在2025年QS排名中位列第几？”

传统RAG表现：这是一个典型的三跳问题（公司X → CEO → 母校 → QS排名）。向量库中可能根本没有直接包含"公司X"和"QS排名"的共现文本，检索直接失效。

多跳推理需要系统能够追踪实体之间的关系链。传统RAG将知识存储为孤立的文本片段，丢失了实体之间的连接信息，自然无法支持链式推理。

1.3 全局性问题崩溃

用户提问：“这批数据集中最核心的三个主题是什么？”

传统RAG表现：向量检索是Query-driven（查询驱动）的，它只能寻找与问题"相似"的片段。面对需要"俯瞰全局"的总结性问题，传统RAG完全无能为力——因为它从未"看到"过全局。

二、GraphRAG的核心原理

2.1 从文档到图谱

GraphRAG的核心思想是：在索引阶段，不仅将文档切分为文本块，还从中抽取实体和关系，构建知识图谱。这样，知识不再以孤立的文本片段存储，而是以相互连接的图结构存储。

GraphRAG的处理流程分为两个阶段：

索引阶段（离线）：

1. 将文档切分为文本块（Text Units）
2. 从每个文本块中抽取实体和关系
3. 构建实体-关系知识图谱
4. 使用社区发现算法（如Leiden）识别实体社区
5. 为每个社区生成描述性摘要

查询阶段（在线）：

1. 根据用户问题定位相关社区
2. 从相关社区中提取结构化上下文
3. 结合向量检索补充细节信息
4. 将图谱上下文和文本上下文融合，生成回答

2.2 实体与关系抽取

实体抽取是GraphRAG的第一步，也是最关键的一步。抽取的质量直接决定了图谱的质量。

fromtypingimportList,Dict,Tuplefromdataclassesimportdataclassimportjson@dataclassclassEntity:"""知识图谱实体"""name:strtype:str# PERSON, ORGANIZATION, LOCATION, CONCEPT, EVENT等description:strsource_chunks:List[str]# 来源文本块ID@dataclassclassRelation:"""实体关系"""source:str# 源实体名称target:str# 目标实体名称type:str# 关系类型description:strevidence:str# 关系证据（原文片段）classEntityExtractor:"""实体与关系抽取器"""def__init__(self,llm_client):self.llm=llm_clientasyncdefextract_from_chunk(self,chunk_id:str,text:str)->Tuple[List[Entity],List[Relation]]:"""从文本块中抽取实体和关系"""prompt=f"""你是一个知识图谱构建专家。请从以下文本中抽取实体和关系。 文本：{text}请以JSON格式输出，包含两个列表： 1. entities：实体列表，每个实体包含： - name: 实体名称（唯一标识） - type: 实体类型（PERSON/ORGANIZATION/LOCATION/CONCEPT/EVENT/DATE/PRODUCT） - description: 简短描述（一句话） 2. relations：关系列表，每个关系包含： - source: 源实体名称 - target: 目标实体名称 - type: 关系类型（WORKS_FOR/LOCATED_IN/FOUNDED_BY/PART_OF/RELATED_TO等） - description: 关系描述 - evidence: 支持该关系的原文片段 注意： - 只抽取明确提到的实体和关系，不要推测 - 实体名称要保持一致（如"苹果公司"和"Apple"统一使用一个） - 关系必须能在原文中找到证据 """response=awaitself.llm.chat(prompt)data=json.loads(response)entities=[Entity(name=e["name"],type=e["type"],description=e["description"],source_chunks=[chunk_id])foreindata.get("entities",[])]relations=[Relation(source=r["source"],target=r["target"],type=r["type"],description=r["description"],evidence=r["evidence"])forrindata.get("relations",[])]returnentities,relations

2.3 实体消歧与合并

从不同文本块中抽取的实体可能存在重复或歧义。例如，"Apple"可能指苹果公司，也可能指水果。需要实体消歧和合并：

classEntityResolver:"""实体消歧与合并"""def__init__(self,llm_client,embedding_model):self.llm=llm_client self.embedding=embedding_modelasyncdefresolve(self,entities:List[Entity])->List[Entity]:"""消歧并合并实体"""# 1. 按名称分组name_groups=self._group_by_name_similarity(entities)# 2. 对每组进行消歧resolved=[]forgroupinname_groups:iflen(group)==1:resolved.append(group[0])else:# 使用LLM判断是否为同一实体merged=awaitself._merge_or_split(group)resolved.extend(merged)returnresolveddef_group_by_name_similarity(self,entities:List[Entity])->List[List[Entity]]:"""按名称相似度分组"""fromcollectionsimportdefaultdict groups=defaultdict(list)processed=set()fori,e1inenumerate(entities):ifiinprocessed:continuegroup=[e1]processed.add(i)forj,e2inenumerate(entities):ifjinprocessed:continue# 计算名称相似度sim=self._name_similarity(e1.name,e2.name)ifsim>0.8:# 高相似度，归为一组group.append(e2)processed.add(j)groups[e1.name].extend(group)returnlist(groups.values())def_name_similarity(self,name1:str,name2:str)->float:"""计算名称相似度"""# 使用嵌入向量计算余弦相似度emb1=self.embedding.encode(name1)emb2=self.embedding.encode(name2)returnnp.dot(emb1,emb2)/(np.linalg.norm(emb1)*np.linalg.norm(emb2))asyncdef_merge_or_split(self,group:List[Entity])->List[Entity]:"""判断是合并还是拆分"""iflen(group)<=1:returngroup# 构建判断提示词entities_desc="\n".join([f"-{e.name}({e.type}):{e.description}"foreingroup])prompt=f"""判断以下实体是否指向同一个真实世界实体：{entities_desc}请以JSON格式输出： {{ "groups": [ {{ "canonical_name": "规范名称", "entity_indices": [0, 1], // 属于同一实体的索引 "reasoning": "判断理由" }} ] }} """response=awaitself.llm.chat(prompt)result=json.loads(response)# 按分组结果合并merged=[]forginresult["groups"]:indices=g["entity_indices"]base=group[indices[0]]base.name=g["canonical_name"]# 合并来源foridxinindices[1:]:base.source_chunks.extend(group[idx].source_chunks)merged.append(base)returnmerged

2.4 社区发现与摘要

构建完知识图谱后，使用社区发现算法识别紧密关联的实体群组，并为每个社区生成摘要：

importnetworkxasnximportigraphasigimportleidenalgclassCommunityDetector:"""社区发现与摘要生成"""def__init__(self,llm_client):self.llm=llm_clientdefdetect_communities(self,entities:List[Entity],relations:List[Relation])->Dict[int,List[str]]:"""使用Leiden算法检测社区"""# 构建图G=nx.Graph()forentityinentities:G.add_node(entity.name,type=entity.type,description=entity.description)forrelinrelations:G.add_edge(rel.source,rel.target,type=rel.type,description=rel.description)# 转换为igraph格式ig_graph=ig.Graph.from_networkx(G)# Leiden社区发现partition=leidenalg.find_partition(ig_graph,leidenalg.ModularityVertexPartition,n_iterations=10)# 组织结果communities={}fori,community_idinenumerate(partition.membership):ifcommunity_idnotincommunities:communities[community_id]=[]node_name=ig_graph.vs[i]["_nx_name"]communities[community_id].append(node_name)returncommunitiesasyncdefgenerate_community_summary(self,community_id:int,entities:List[str],entity_details:Dict[str,Entity],relations:List[Relation])->str:"""为社区生成摘要"""# 收集社区内的关系community_relations=[rforrinrelationsifr.sourceinentitiesandr.targetinentities]# 构建摘要提示词entities_desc="\n".join([f"-{name}:{entity_details[name].description}"fornameinentities])relations_desc="\n".join([f"-{r.source}--[{r.type}]-->{r.target}:{r.description}"forrincommunity_relations[:20]# 限制数量])prompt=f"""你是一个知识图谱分析专家。请为以下实体社区生成摘要。 ## 社区实体{entities_desc}## 社区关系{relations_desc}请生成一个全面的社区摘要，包含： 1. 社区主题：这个社区主要讨论什么？ 2. 核心实体：哪些是最重要的实体？ 3. 关键关系：最重要的关系是什么？ 4. 整体描述：用2-3句话总结这个社区的知识内容。 输出格式：纯文本段落。 """summary=awaitself.llm.chat(prompt)returnsummary

三、GraphRAG查询引擎

3.1 全局搜索（Global Search）

全局搜索用于回答需要"俯瞰全局"的问题，如"这批文档的核心主题是什么"。

classGlobalSearch:"""全局搜索：基于社区摘要回答全局性问题"""def__init__(self,llm_client,community_summaries:Dict[int,str]):self.llm=llm_client self.summaries=community_summariesasyncdefsearch(self,query:str)->str:"""全局搜索"""# 将所有社区摘要作为上下文all_summaries="\n\n---\n\n".join([f"## 社区{cid}\n{summary}"forcid,summaryinself.summaries.items()])prompt=f"""你是一个知识分析专家。请基于以下社区摘要回答用户问题。 ## 知识库社区摘要{all_summaries}## 用户问题{query}请基于社区摘要提供全面的回答。如果信息不足，请说明。 """returnawaitself.llm.chat(prompt)

3.2 局部搜索（Local Search）

局部搜索用于回答需要具体细节的问题，结合图谱遍历和向量检索：

classLocalSearch:"""局部搜索：结合图谱遍历和向量检索"""def__init__(self,llm_client,graph:nx.Graph,vector_store,entity_index:Dict):self.llm=llm_client self.graph=graph self.vector_store=vector_store self.entity_index=entity_indexasyncdefsearch(self,query:str,top_k:int=10)->str:"""局部搜索"""# 1. 向量检索找到相关实体query_embedding=self._embed(query)relevant_entities=awaitself.vector_store.search(query_embedding,top_k=top_k)# 2. 图谱扩展：获取相关实体的邻居expanded_context=self._expand_context(relevant_entities,depth=2)# 3. 构建上下文context=self._build_context(expanded_context)# 4. 生成回答prompt=f"""基于以下知识图谱上下文回答问题。 ## 知识图谱上下文{context}## 用户问题{query}请基于上下文提供准确回答。如果信息不足，请说明。 """returnawaitself.llm.chat(prompt)def_expand_context(self,entities:List[str],depth:int=2)->Dict:"""从实体出发扩展上下文"""context={"entities":set(),"relations":[]}visited=set()current_layer=set(entities)fordinrange(depth):next_layer=set()forentityincurrent_layer:ifentityinvisited:continuevisited.add(entity)context["entities"].add(entity)# 获取邻居ifentityinself.graph:forneighborinself.graph.neighbors(entity):edge_data=self.graph[entity][neighbor]context["relations"].append({"source":entity,"target":neighbor,**edge_data})ifneighbornotinvisited:next_layer.add(neighbor)current_layer=next_layerreturncontext

四、GraphRAG vs 传统RAG：对比分析

五、生产部署考量

5.1 成本控制

GraphRAG的索引阶段需要大量LLM调用（实体抽取、关系抽取、社区摘要），成本远高于传统RAG。优化策略包括：

• 批量处理：将多个文本块合并处理，减少LLM调用次数
• 模型降级：实体抽取使用GPT-4o-mini等低成本模型
• 增量更新：只对新文档执行完整索引流程

5.2 混合架构

实际项目中，GraphRAG和传统RAG往往配合使用：

• 全局性问题 → GraphRAG全局搜索
• 多跳推理问题 → GraphRAG局部搜索
• 简单事实查询 → 传统RAG向量检索

通过问题分类器自动路由到最合适的检索方式。

结语

GraphRAG代表了知识增强技术从"平面"到"立体"的进化。它通过显式建模实体和关系，让AI真正"理解"知识之间的关联，而不仅仅是"匹配"相似的文本。

但GraphRAG不是银弹。它的索引成本高、工程复杂度大，适合知识密集、关系复杂的场景。对于简单的FAQ问答，传统RAG仍然是更经济的选择。

选择GraphRAG还是传统RAG，取决于你的业务需求：如果你需要回答"为什么"和"有什么关系"，GraphRAG是你的答案；如果你只需要回答"是什么"，传统RAG就足够了。