GraphRAG 实战：用知识图谱给 Agent 装上关联理解能力

传统 RAG 将文档切块后做向量化检索，找到语义相似的文本片段。这种方式在面对"多跳推理"、"跨文档关联"和"全局总结"时力不从心。GraphRAG 通过从文本中提取实体和关系构建知识图谱，让 Agent 获得真正的关联理解能力。

传统 RAG 的瓶颈

基于向量相似度的 RAG 存在三个结构性局限：

扁平块检索：文档被切成独立块，每个块只包含局部信息。Agent 提问"这个项目的核心团队分布在哪几个国家？"，需要跨多个块甚至跨文档聚合信息时，向量搜索无法保证覆盖全部相关片段。

无法跨文档关联：块与块之间没有关系链接。"A 公司收购了 B 公司"和"B 公司的产品是 X"两个事实分布在不同的块中，向量搜索能把它们找出来，但无法建立"收购 → 产品"的因果链路。

多跳推理困难：需要连续推理的问题（"哪些开源项目受到了 Apache 2.0 许可证的约束，并且它们的 GitHub Stars 超过 10K？"）在向量空间中没有直接的路径可走。

GraphRAG 核心理念

GraphRAG 的工作流程分为三步：

1. 实体与关系提取——用 LLM 从文本中抽取出实体（人、组织、产品、概念）和它们之间的关系（"收购"、"合作"、"依赖"）
2. 知识图谱构建——以三元组 (实体, 关系, 实体) 的形式存入图数据库或图结构索引
3. 检索增强——Agent 提问时，不仅做向量相似度匹配，还沿着图结构做遍历，找到关联路径上的相关信息

两种检索方式互补：

方式	覆盖范围	典型用例
向量相似度	语义相近的文本块	记住具体事实
图谱遍历	关系路径上的相关实体	推理间接关联

当 Agent 需要回答"为什么 X 和 Y 有关系？"时，图谱遍历是必经之路。

Microsoft GraphRAG

Microsoft 在 2024 年发表论文 "From Local to Global: A Graph RAG Approach to Query-Focused Summarization"，并在 GitHub 开源了实现。

Pipeline 架构

1. 文档分块——输入文档按 token 切块，保证每块不超过 LLM 上下文窗口
2. 实体与关系提取——对每个块调用 LLM 提取实体和关系，然后用实体名做去重合并
3. Leiden 社区检测——在实体图上运行 Leiden 算法，将紧密连接的实体归入同一社区
4. 层次化总结——对每个社区生成摘要，再对社区组生成全局摘要，形成"局部 → 全局"的层次索引
5. 双模检索——局部搜索（Local Search）：在实体级别查询，适合具体事实；全局搜索（Global Search）：在社区摘要上查询，适合概括和趋势分析

优点

• 全局性问题回答强——社区摘要层次结构天然适合"What are the main themes?"类问题
• 学术基准领先——在论文的 Head-to-Head 测试中，全局总结质量全面超过传统 RAG + Prompt 压缩方案
• 成熟的开源生态——官方 Python 包 + Neo4j 集成 + Visual Studio Code 扩展

缺点

• 索引成本高——每个文档块都需要多次 LLM 调用（提取 + 去重 + 总结），处理 100 万 token 语料需约 $100-200 的 LLM 费用
• 构建速度慢——Leiden 社区检测和层次总结是串行的，大语料索引时间可达数小时
• 不支持增量更新——增删文档需要完全重建索引
• 本地执行困难——对 LLM 的 API 依赖较重，本地模型效果下降明显

# Microsoft GraphRAG 初始化
pip install graphrag

# 准备索引配置文件
graphrag init --root ./my_project

# 运行索引（需要 OpenAI API Key）
graphrag index --root ./my_project

# 查询
graphrag query --root ./my_project --method local --query "项目使用了哪些技术栈？"
graphrag query --root ./my_project --method global --query "项目的整体架构设计思路是什么？"

LightRAG

LightRAG 由香港大学研究团队发布（MIT License），从设计上对标 Microsoft GraphRAG 的痛点。

核心设计

LightRAG 放弃了社区检测和层次总结，采用更轻量化的方案：

• 双级检索——实体级别（low-level entities）+ 概念级别（high-level concepts），在索引时额外提取对实体所属概念的描述
• 增量更新——支持通过 insert 方法逐步添加新文档，无需重建索引
• 图结构索引——用纯文本表示知识图谱，不依赖图数据库，初始化极其简单
• LLM 调用量显著减少——每个文档块只需 1-2 次 LLM 调用

安装与使用

pip install lightrag-hku

初始化并插入数据：

import asyncio
from lightrag import LightRAG
from lightrag.llm import gpt_4o_mini_complete

rag = LightRAG(
    working_dir="./lightrag_data",
    llm_model_func=gpt_4o_mini_complete,  # 支持 OpenAI / Ollama / Anthropic
)

# 插入文档
rag.insert("AgentList 是一个开源 AI Agent 目录网站，收录了超过 200 个开源项目。")
rag.insert("Microsoft GraphRAG 是微软开源的图增强检索框架，基于知识图谱技术。")
rag.insert("LightRAG 由香港大学团队开发，提供轻量级的知识图谱检索方案。")

# 三种查询模式
print(rag.query("AgentList 收录了哪些项目？", mode="local"))
# 局部检索：聚焦相关实体 → "AgentList 收录了超过 200 个开源项目"

print(rag.query("GraphRAG 技术有哪些主流实现？", mode="global"))
# 全局检索：引入概念级别信息 → "Microsoft GraphRAG 和 LightRAG 是主流实现"

print(rag.query("比较 Microsoft GraphRAG 和 LightRAG 的差异", mode="hybrid"))
# 混合检索：实体 + 概念综合

优点

• 成本仅为 Microsoft GraphRAG 的 1/10 到 1/3，处理同等语料约 $10-30
• 支持增量插入，适合持续增长的文档库
• 初始化极简，几行 Python 代码即可运行
• 多 LLM 后端——内置 OpenAI / Ollama / Anthropic / Google 适配器
• 速度快，无需社区检测和层次总结，索引时间大幅缩短

缺点

• 全局总结质量略逊于 Microsoft GraphRAG——缺少社区摘要的层次化结构，在"分析整个文档库的趋势"这类任务上表现稍弱
• 去重能力有限——同义词实体合并的准确度不如 Microsoft 的层次化去重
• 社区较小——文档和最佳实践相对较少

使用场景对比

场景	推荐方案	理由
全局总结 / 主题分析 — "整个文档库讨论了哪些主要话题？"	Microsoft GraphRAG	社区摘要层次结构天然适合宏观概括
单文档问答 — "这篇论文的实验结论是什么？"	LightRAG	性价比高，不用为单文档跑全局摘要
增量的多文档库 — "每天新增 100 篇文档，持续查询"	LightRAG	支持增量插入，无需全量重建
Agent 长期记忆 — "记住用户的偏好并随时间更新"	Graphiti / Zep	时态知识图谱，支持遗忘和优先级
对话上下文补充 — "用户之前提到了什么项目？"	LightRAG	对话本身就是增量文本，快速插入查询

GraphRAG + Agent 集成模式

LangChain 和 LlamaIndex 都已内置 GraphRAG 集成：

from langchain_community.graphs import Neo4jGraph
from langchain.chains import GraphCypherQAChain

graph = Neo4jGraph(url="bolt://localhost:7687", username="neo4j", password="password")
chain = GraphCypherQAChain.from_llm(llm=llm, graph=graph)
chain.run("AgentList 中收录了哪些与知识图谱相关的项目？")

LlamaIndex 提供了 GraphRAGQueryEngine，可以直接对接 Microsoft GraphRAG 的索引输出。Dify 和 Open WebUI 也在最近的版本中加入了知识图谱检索的支持。

时态知识图谱：Agent 长期记忆

传统的 GraphRAG 关注"文档中的静态知识"，但 Agent 的长期记忆需要处理"知识随时间变化"的问题。Graphiti 和 Zep 引入了时态知识图谱的概念——每个实体和关系都带有时间戳，支持查询"某时间点的状态"和"某个时间段的变化"。

from graphiti import Graphiti

g = Graphiti()
g.add_episode("用户说：我喜欢 Python 和 Rust")
g.add_episode("一个月后用户说：我现在主要用 Go")

g.search("用户最喜欢的编程语言", time_context="三个月前")
# → "Python, Rust"

g.search("用户最喜欢的编程语言", time_context="现在")
# → "Go"

这对于构建 Agent 的"记忆层"至关重要——Agent 需要知道用户兴趣的变化，而不是永远记住过时的信息。

选型建议

根据不同的预算、语料规模和查询类型，选择方案：

• 大语料全局分析——选 Microsoft GraphRAG。预算充足（$100+ LLM 费用）、语料量大（百万 token 级别）、主要查询类型是宏观总结和趋势分析。
• 预算有限 / 快速迭代——选 LightRAG。个人项目、小团队、预算控制在 $30 以内、需要快速上线并支持增量更新。
• Agent 长期记忆——选 Graphiti / Zep。需要记录用户偏好随时间的变化，支持遗忘机制和时态查询。
• 已有 Postgres 基础设施——选 TypeGraph（TypeScript）。基于 Postgres + pgvector 实现，与现有数据栈无缝集成。
• 需要图形界面查询——在 Microsoft GraphRAG 或 LightRAG 之上叠加 Neo4j Browser 或 GraphQL API。

使用场景矩阵：

查询类型 →  全局总结   具体事实   长期记忆
语料量 ↓
小（<10K tokens）    LightRAG    LightRAG    Graphiti
中（10K-1M tokens）  MS GraphRAG LightRAG    Graphiti
大（>1M tokens）     MS GraphRAG MS GraphRAG  Graphiti

小结

GraphRAG 不是向量 RAG 的替代，而是补充。向量检索找到"相似的块"，图谱检索找到"关联的路径"。两者结合，Agent 才能真正理解文本中的关系网络：

• Microsoft GraphRAG 适合全局分析和学术研究场景，索引成本高但质量领先
• LightRAG 适合快速原型和中小规模项目，成本低、迭代快
• Graphiti / Zep 解决 Agent 长期记忆中的时态推理需求
• 主流框架（LangChain、LlamaIndex、Dify、Open WebUI）均已内置 GraphRAG 支持

选择方案的第一步不是对比功能，而是明确你的查询类型——你需要 Agent 做的是"检索事实"，还是"理解关系"？

---

本文由 AgentList 团队整理，更多 RAG 与知识图谱相关项目请浏览本站项目列表。