当前位置：首页 > news >正文

GraphRAG 实战：从基础调用到稳定运行

news 2026/6/25 16:33:38

这篇我按“先跑起来、再讲取舍”的方式写《GraphRAG 实战：从基础调用到稳定运行》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

本文概述文章目标、核心观点和实践价值。

上周我在帮一家做金融合规的客户重构知识库系统时，遇到了一个典型的 RAG 痛点：传统向量检索在处理“跨文档实体关联”问题上彻底失效了。

客户问：“请列举所有涉及‘高风险’且与‘半导体供应链’有关联的供应商。”

如果用纯向量 RAG，Embedding 模型很难捕捉这种复杂的逻辑关系。A 文档说“半导体供应链紧张”，B 文档说“某供应商被列为高风险”，C 文档说“这两者有关联”。向量检索只能找到包含关键词的片段，却找不到它们之间的隐含链条。

这就是我决定引入 GraphRAG（基于知识图谱的 RAG）的原因。这不是一次为了赶时髦的技术升级，而是为了解决特定业务场景下的“逻辑断裂”问题。今天这篇文章，我不讲高大上的理论，直接复盘我从零搭建 GraphRAG 原型机的过程，重点聊聊其中的取舍、坑点和最终能跑通的代码路径。

传统 RAG 的瓶颈：为什么单纯靠向量不够？

在动手之前，我们必须明确一个判断标准：什么时候该用 GraphRAG？

如果你的业务场景是“语义相似度匹配”，比如用户问“怎么修复这个报错”，向量检索秒杀一切。但如果业务涉及“多跳推理”、“全局视野”或“结构化查询”，向量检索就会露馅。

我之前的项目经验表明，纯 RAG 有两个致命弱点：
1.缺乏全局观：向量数据库是按 Chunk（文本块）存储的，它不知道 Chunk A 和 Chunk B 其实是同一个实体的不同侧面。
2.幻觉放大：当 LLM 基于不完整的局部信息生成答案时，很容易产生看似合理但事实错误的推断。

GraphRAG 的核心价值在于引入了“结构”。通过知识图谱（KG），我们将非结构化文本转化为“实体-关系-实体”的网络，让检索从“找相似”变为“找路径”。

知识图谱建模：别一上来就搞复杂本体

很多初学者容易陷入的一个误区是：先设计完美的本体（Ontology），再填数据。在企业级实战中，这是死路一条。

我的建议是：最小化可用图谱（Minimal Viable Graph）。

对于大多数中文业务场景，我只定义三类节点和两类关系：

节点：Organization（机构）、Person（人物）、Concept（概念/事件）。
关系：BELONGS_TO（隶属）、RELATED_TO（关联）。

为什么要这么简化？因为高质量的三元组抽取极其依赖 LLM 的稳定性。如果本体太复杂，LLM 在提取关系时的准确率会断崖式下跌，导致图谱质量崩塌，进而污染后续的检索结果。

在建模阶段，我强烈建议使用 Neo4j 或 NebulaGraph 作为底层存储。Neo4j 的 Cypher 查询语言对开发者更友好，调试方便；NebulaGraph 适合超大规模分布式部署，但对于个人或小团队起步，Neo4j 的学习曲线更平缓。

实体关系抽取：LLM 是双刃剑

这是整个 Pipeline 中最容易踩坑的环节。我尝试过多种方案：

1.NER + 规则模板：成本低，但覆盖率低，无法处理隐含关系。
2.纯 LLM 抽取：效果好，但 Token 消耗巨大，延迟高，且存在格式不稳定问题。
3.混合模式（推荐）：先用轻量级 NER 模型（如 spaCy 或专门微调的 BERT）提取实体，再用 LLM 进行关系判断和属性丰富。

在实际代码实现中，我使用 LangChain 配合 OpenAI 的函数调用功能（Function Calling）来确保 JSON 格式的稳定性。

import json from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import JsonOutputParser # 定义抽取结果的 schema parser = JsonOutputParser(pydantic_object=EntityRelation) # 构建提示词，强调“只提取明确提到的关系” prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个专业的知识图谱构建助手。请从以下文本中提取实体及其关系。"), ("human", "Text: {text}\n\nReturn format: {format}") ]) llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) chain = prompt | llm | parser # 假设 chunk 是从 PDF 中提取的一段文本 result = chain.invoke({ "text": "张三担任李四公司的 CEO，该公司主要业务涉及人工智能芯片研发。", "format": parser.get_format_instructions() }) print(json.dumps(result, ensure_ascii=False, indent=2))

踩坑记录：
刚开始我直接用gpt-4，发现有些长文本会被截断，导致关系提取不完整。后来我改为预处理阶段，先按句子切分，再逐句提取，最后合并去重。虽然增加了复杂度，但准确率提升了 15% 以上。另外，务必设置temperature=0，保证抽取的确定性。

图检索增强：如何用 Cypher 查询答案？

图谱建好后，关键是怎么用它来增强 RAG。这里我有两种策略：

1.Hybrid Search（混合检索）：同时查询向量数据库和图数据库，最后融合结果。
2.Graph-Augmented Generation（图增强生成）：在 Prompt 中注入图谱检索到的子图结构。

我采用的是第二种，因为它更能体现 GraphRAG 的优势。具体流程是：

1. 用户提问后，先将问题向量化。
2. 在图谱中寻找与问题向量最相似的实体节点。
3. 以该节点为中心，向外扩展 1-2 跳（Hop），获取相关的邻居实体和关系。
4. 将这些结构化的“上下文”注入到 LLM 的 Prompt 中，要求 LLM 基于这些信息回答问题。

def get_graph_context(node_id, hops=2): """ 从 Neo4j 获取实体的多跳邻居信息 """ query = f""" MATCH path = (start:Node {{id: '{node_id}'}})-[r*1..{hops}]-() RETURN path """ # 实际调用 neo4j_driver.execute_query(query) # 这里省略具体的驱动代码，假设返回的是简化的文本描述 return "实体: 张三, 关系: 担任CEO, 目标: 李四公司; 关系: 涉及业务, 目标: 人工智能芯片" # 组装最终 Prompt final_prompt = f""" 基于以下知识图谱信息回答问题： Context: {get_graph_context(similar_entity_id)} Question: {user_question} 请严格依据 Context 提供的事实回答，如果 Context 中没有相关信息，请告知。 """

关键取舍：
扩展多少跳？我经过测试发现，1 跳准确率最高，但召回率低；2 跳召回率高，但噪声大。对于金融合规场景，宁可漏报不可错报，所以我通常限制在 1 跳，并在 Prompt 中增加“不确定性提示”，让 LLM 自行判断是否忽略弱关联信息。