RAG 系列（十六）：Graph RAG——用知识图谱解决多跳关系问题

向量检索的关系盲点

前面几篇从各个角度优化了检索质量：更好的分块、Rerank 重排序、查询改写、CRAG 纠偏。但有一类问题，这些方法都帮不上多少忙：

需要横跨多个实体推理的问题。

举个例子：

“bge-large-zh-v1.5 和 bge-reranker-v2-m3 都来自哪个机构？各自在 RAG 中扮演什么角色？”

向量检索会找到提到 BAAI 或 bge 的文档片段——这没问题，两个模型都会出现。但检索的语义是"找相似"，不是"找关系"。LLM 拿到的是两段分散的文本，需要自己去理解"它们都来自 BAAI"这个关联。

再复杂一点：

“从 RAG 到 CRAG，检索质量评估经历了哪些演进步骤？”

这个问题要求按技术演进顺序把 RAG → Rerank → Self-RAG → CRAG 串联起来。向量检索找到的是语义最相似的 top-4 文档，不保证是这条演进链上的节点。

Graph RAG 的切入点：把文档中的实体和关系显式提取出来，构建成知识图谱。检索时不是"找最像的文档"，而是"从问题实体出发，沿关系边遍历图"——这天然适合多跳推理。

知识图谱的核心概念

知识图谱的基本单位是三元组：

（头实体，关系，尾实体）

例如：

BAAI --[开发]--> bge-large-zh-v1.5 BAAI --[开发]--> bge-reranker-v2-m3 bge-large-zh-v1.5 --[用于]--> 向量检索 bge-reranker-v2-m3 --[用于]--> 重排序

把这些三元组组织成有向图（NetworkX DiGraph），"BAAI 开发了哪些模型"这个问题就变成了：找到 BAAI 节点，列出所有出边。

Graph RAG 的完整流程

构建阶段（离线）： 文档 → LLM 提取三元组 → NetworkX 有向图 文档 → Embedding → ChromaDB 向量索引 查询阶段（在线）： 问题 ↓ LLM 提取问题实体（如 BAAI、bge-large-zh-v1.5） ↓ 模糊匹配图节点（子串匹配） ↓ BFS 2跳遍历：seed_nodes → 邻居 → 邻居的邻居 ↓ 组装三元组上下文（图遍历结果 + top-2 向量文档补充） ↓ LLM 生成答案

关键设计：Graph RAG 不是纯图检索，而是图遍历上下文 + 向量检索的混合。纯图遍历有"实体边界"——如果问题中的实体没被提取进图，就会漏检；向量检索兜底覆盖这类盲区。

实现：三元组提取

先踩了一个坑

LangChain 提供了LLMGraphTransformer，专门用于从文本提取图结构。我最初使用它：

fromlangchain_experimental.graph_transformersimportLLMGraphTransformer graph_transformer=LLMGraphTransformer(llm=llm)graph_docs=graph_transformer.convert_to_graph_documents([doc])

结果 12 篇文档全部报错：

Invalid JSON: invalid number at line 1 column 2 [type=json_invalid, input_value='- Node: RAG (Retrieval-A...']

原因：LLMGraphTransformer要求 LLM 返回严格的 JSON 格式，但 GLM-4-flash 返回的是文本列表（- Node: xxx），Pydantic 解析失败。

改用自定义 prompt

放弃 JSON，改用更宽松的分隔符格式——实体A | 关系 | 实体B，每行一个三元组，split("|")解析，不依赖 JSON，容错性强：

TRIPLE_EXTRACT_PROMPT=ChatPromptTemplate.from_messages([("system","从以下文本中提取实体和关系，输出三元组列表。\n""格式要求：每行一个三元组，格式严格为：实体A | 关系 | 实体B\n""规则：\n""- 实体用名词短语，不加括号或引号\n""- 关系用动词短语，如：使用、包含、由...提出、适用于、优于\n""- 每行只输出三元组，不要编号，不要解释，不要其他内容\n""- 每篇文档提取8-15个三元组\n\n""示例输出（格式参考）：\n""RAG | 使用 | 向量检索\n""RAGAS | 由...提出 | Es等人\n""Chroma | 适用于 | 本地开发"),("human","文本：\n{text}"),])defextract_triples