微软的GraphRAG是最强RAG？

GraphRAG到底是什么？为什么在2024年微软一发布相关论文和开源实现，就在技术圈引起这么大的关注？简单来说，传统的RAG虽然能把新知识塞给大模型，但面对那些信息之间关系松散、需要跨多个“跳”才能理清的复杂查询时，往往力不从心。而GraphRAG，就是在这种背景下诞生的新思路。

从非结构化数据到可查询图谱

把一堆散落的文本，变成一张可以按图索骥的知识图谱，这就是GraphRAG要做的核心工作。这件事听起来复杂，但通过Streamlit、LangChain、Neo4j和GPT-4o的组合，我们已经可以把它落地到实际应用中。下面这个示例，包含四个核心组件：

• 使用Docker托管的本地Neo4j图形数据库，作为存储基础。
• 一个能从非结构化文本中提取信息并构建知识图谱的工具。
• 一个混合检索器，能同时从图谱中提取结构化和非结构化信息。
• 一个Streamlit用户界面，让用户能直接与图谱化后的知识文档进行对话。

这里的GraphRAG，正是2024年4月微软研究团队发布的那项成果。它的设计初衷非常明确：解决大模型在接收新信息时产生的“幻觉”问题，尤其是在处理那些模糊、松散关联的信息时。而知识图谱的强项，恰恰在于通过多跳查询，清晰地表示和检索复杂关系。

整个工作机制可以分为两大阶段。

和传统RAG一样，首先需要将文本切分成适合模型上下文的块。但不一样的是，每个文本块会被进一步转换成“图文档”，从而逐步建立起整个图形。

这是关键。它同时利用图查询和向量相似度搜索。原始文档块既存储在图形中，又被用来构建向量索引。当用户提出问题时，检索器会先提取其中的实体，然后基于这些实体同时进行向量搜索和图查询。最终的结果和原始问题一起交给LLM，生成上下文感知的回答。

技术栈方面，LangChain简化了LLM应用的构建流程；Neo4j提供了高性能的图数据库能力；GPT-4o作为底层的语言模型；而Streamlit则让快速搭建交互界面成为可能。值得一提的是LangChain中的

，这是一个实验性功能，能直接将文档转换为图形格式，并允许开发者指定节点和关系类型，应用各种约束和筛选。

示例案例：Garmin手表推荐

我们用一个具体的例子——Garmin Forerunner 255来展开。这款手表功能多样、价格不一，本身就是一个很好的数据基础。

应用架构

示例应用由四个主要组件构成：本地Docker托管的Neo4j、从非结构化文本构建图谱的工具、混合检索器，以及Streamlit用户界面。

使用Docker配置Neo4j环境

首先，需要在本地运行一个Neo4j实例。为了简化配置，我们使用Docker。注意需要下载APOC JAR文件（Neo4j的一个辅助库）并放在特定目录下。确保已经安装了Docker Desktop，然后执行以下命令：

docker run -p 7474:7474 -p 7687:7687  -v ${PWD}/data:/data -v ${PWD}/plugins:/plugins  --name neo4j-v5-apoc  -e NEO4J_apoc_export_file_enabled=true  -e NEO4J_apoc_import_file_enabled=true  -e NEO4J_apoc_import_file_use_neo4j_config=true  -e NEO4J_PLUGINS='["apoc"]'  -e NEO4J_dbms_security_procedures_unrestricted="apoc.*"  neo4j:5.20.0

从非结构化数据构建图谱

为了演示如何整合多种数据源，可以创建三个文档提取器：一个对应YouTube，一个对应维基百科，还有一个处理纯文本文件。

def extract_youtube_transcript(self, url) -> List: return YoutubeLoader.from_youtube_url(url).load()
def extract_wikipedia_content(self, search_query): raw_docs = WikipediaLoader(query=search_query).load() self.chunk_and_graph(raw_docs)
def graph_text_content(self, path): text_docs = TextLoader(path).load() self.chunk_and_graph(text_docs)

提取内容后，需要进行文本分块。这里使用简单的

，将文本切分成适合RAG的块。

def chunk_document_text(self, raw_docs): text_splitter = TokenTextSplitter(chunk_size=512, chunk_overlap=24) docs = text_splitter.split_documents(raw_docs[:3])

接下来是关键一步：利用

，将每个文本块转换为图节点和边，并持久化到Neo4j中。

def graph_document_text(self, text_chunks): llm_transformer = LLMGraphTransformer(llm=self.llm) graph_docs = llm_transformer.convert_to_graph_documents(text_chunks) self.graph.add_graph_documents( baseEntityLabel=True, text_chunks=text_chunks, )

这个过程会循环进行，直到所有来源文档的所有块都被处理完毕。其中`include_source=True`这个参数很有用，它会在图中保留来源文档信息，对后续的非结构化语义搜索帮助很大。最后，在整个图谱上创建一个索引，保证高效检索。

构建图检索器

图检索器的构建需要多步配合。

第一步，提取用户问题中的实体。因为图是通过节点和边连接的，按实体搜索是最直接的策略。

def extract_entities_from_question(self, question): entities = self.entity_extractor.extract(question) return entities

第二步，构建结构化数据检索器，用于生成一个图查询，提取与识别出的实体相关的节点和关系。

第三步，创建非结构化部分。之前保留的源文档在这里派上用场了——直接从图中创建一个向量索引。

def create_vector_index_from_graph(self): vector_index = self.graph.create_vector_index(include_source=True) return vector_index

最后一步，将两种检索方法合并，构建一个组合查询并发给LLM。

def combine_retrieval_methods(self, entities, vector_index): combined_query = self.llm.create_combined_query(entities, vector_index) return combined_query

至此，一个完整的混合GraphRAG实现就搭建起来了。

为了让它更好用，还需要一个对话式交互界面。Streamlit可以快速实现原型，用户界面分为两个部分：侧边栏管理图形的控件，主窗口则是主要的聊天界面，用户可以在这里提问，与模型的知识及基于图谱的知识进行交互。

回顾整个过程，数据往往不是线性相关的，很多有价值的信息藏在多个“跳”之外。这正是知识图谱的价值所在——它能更真实地反映信息间相互关联的现实。手动构建这样的图谱曾经很困难，但随着LLM的出现，自动化这个过程已经成为可能。

GraphRAG的技术细节与优化方向

GraphRAG的核心优势在于，它利用知识图谱极大地丰富了LLM的上下文信息，有效解决了传统RAG在处理复杂查询时的局限性。工作原理可以总结为：构建一个融合向量相似度搜索与图查询的系统，综合检索结构化和非结构化数据。

这个过程主要分为两个阶段：

• RAG数据存储：
  文档分块、转换为图文档，建立用于背景检索的数据存储。

• 混合检索：
  结合图查询与向量搜索，获取最相关的上下文。

在检索层面，系统首先接受用户问题并提取实体，然后基于这些实体进行向量搜索和图查询构建。最终结果与原始问题一起交给LLM，生成基于上下文的回答。

GraphRAG的优势非常明显：它能利用知识图谱在多跳关系中的映射和查询能力，生成更复杂、更丰富的答案；能提供更多相关的数据点来支撑对用户查询的理解和响应；同时在减少生成幻觉、提高回答质量方面表现出色。

未来的发展方向，可能包括加强实体消歧、优化图嵌入、以及支持多模态数据。通过整合多种优化方法，GraphRAG有望在计算效率和知识传递的广度上进一步提升。

从应用前景来看，医疗、法律、金融等对复杂关系推理有高要求的领域，将是GraphRAG大展身手的舞台。相较于传统RAG方法，它在处理这类问题时展现出的优势是显而易见的。