graph-rag-agent
融合 GraphRAG + DeepSearch 的多 Agent 知识图谱问答框架,支持 7 种检索模式
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
融合 GraphRAG + DeepSearch 的多 Agent 知识图谱问答框架,支持 7 种检索模式
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
当你向企业知识库助手提问"过去三年我们的毛利率趋势是什么",传统 RAG 很可能给出一段语焉不详的摘录,而 GraphRAG + DeepSearch 能沿着知识图谱一步步追溯到每一笔财务报表中的原始数据——这就是这个开源项目要解决的核心问题。
大型语言模型(LLM)的知识是死的、静态的,而企业的知识是活的、不断增长的。检索增强生成(RAG)通过从外部知识库中检索相关内容来弥补这一短板,成为企业私有知识问答的主流方案。然而,传统 RAG 在处理跨文档关联查询时存在明显短板——它只能找到语义相似的文本片段,却无法理解这些片段之间的逻辑关系。
GraphRAG 正是为解决这一痛点而生的技术方案。2023年,NebulaGraph 团队在 LlamaIndex 社区首次系统性地提出并开源了 GraphRAG 的实现思路:将非结构化文档中的知识抽取为实体-关系三元组,构建可推理的知识图谱,再结合社区检测算法发现跨文档的语义关联。这一方案在复杂问答任务上的表现远超传统 RAG。
本项目 graph-rag-agent 的作者投入了大量精力,将 GraphRAG 与 DeepSearch 深度融合,打造了一套从知识入库到问答推理的完整 Agent 框架。项目已被 DeepWiki 官方收录,在中文 AI 社区获得了不少关注,目前 GitHub Stars 超过 2200,Forks 超过 300,Issues 34 个。
项目采用 LangChain + LangGraph 作为 Agent 编排框架,以 Neo4j 作为知识图谱存储后端,支持以下 7 种 Agent 模式:
| Agent 模式 | 说明 |
|---|---|
| Naive RAG | 纯向量检索,最基础的对比基准 |
| Graph Agent | 基于图谱的语义检索 |
| Hybrid Agent | 向量 + 图谱混合检索 |
| Deep Research Agent | 深度研究模式,多轮探索与推理 |
| Chain of Exploration | 探索链,引导 AI 按步骤思考 |
| Fusion GraphRAG Agent | 融合模式,结合 IDP 技术 |
| LightRAG Agent | 轻量级图谱方案 |
各 Agent 模式通过 graphrag_agent/ 目录下的模块化代码实现,核心依赖包括 LangChain、LangGraph、LangChain-Neo4j、LangChain-OpenAI 等。其中 LangGraph 提供了状态机式的 Agent 编排能力,支持条件分支与循环,使得复杂的多轮对话推理流程得以可视化地组织。

图1:GraphRAG + DeepSearch 整体工作流(来源:项目 README)
知识图谱的构建是整个系统的核心环节。项目实现了从原始文档到 Neo4j 图数据库的自动化流水线,主要包含以下步骤:
1. 文档解析:支持 PDF、Word、Markdown、TXT 等多种格式,通过 textract + PyPDF2 提取文本内容。
2. 实体关系抽取:利用大模型(默认 OpenAI GPT-4o)进行 zero-shot 三元组抽取,将自然语言文本转化为 <实体A, 关系, 实体B> 的结构化表示。HanLP 作为中文 NLP 辅助工具,提升中文实体识别的准确性。
3. 图谱存储:抽取结果存入 Neo4j 图数据库。docker-compose.yaml 中预置了 Neo4j 5.22.0 镜像,并安装了 APOC 和 GDS(Graph Data Science)插件,分别用于图谱操作过程和图分析算法支持。
4. 增量更新:项目支持对已入库知识进行增量更新,自动去重并合并新增三元组,适合持续增长的企业知识库场景。
整个流程可通过 Streamlit 可视化界面操作,也支持纯 API 调用。README 中提供了从安装到运行的全流程指南,文档较为完整。
DeepSearch 是本项目的另一核心创新点。传统的 RAG 在检索到相关内容后直接送入 LLM 生成答案,整个过程是一次性的、无追溯的。DeepSearch 则引入了多轮探索-反思-验证的机制:
这一机制与 DeepSeek R1 的 Chain-of-Thought 思路一脉相承,但针对私有知识库的图谱结构做了专门优化。项目提供的 Chain of Exploration 模式完整展示了每一步的思考过程,用户可以清晰看到 AI 是如何沿着知识图谱一步步推理的——这不仅提升了答案质量,也大大增强了 AI 输出的可解释性。
RAG 系统好不好,往往靠"感觉"——这对于严谨的系统建设是远远不够的。本项目内置了一套针对 GraphRAG 的评估框架,覆盖 20+ 评估指标,包括:
评估框架基于 LangSmith 构建,支持自定义数据集和批量评测,方便对比不同 Agent 模式在不同场景下的表现。
项目提供了 docker-compose.yaml,可一键启动 Neo4j 数据库服务:
neo4j:
image: neo4j:5.22.0
ports:
- "7474:7474" # 浏览器管理界面
- "7687:7687" # Bolt 协议端口
environment:
NEO4J_AUTH: "neo4j/12345678"
NEO4J_PLUGINS: '[ "apoc", "graph-data-science" ]'
后端基于 FastAPI + Uvicorn,提供 RESTful API 接口;前端基于 Streamlit,提供交互式问答界面。部署步骤:
docker-compose up -d 启动 Neo4j.env 文件(参考 .env.example),填入 OpenAI API Keypip install -r requirements.txt 安装 Python 依赖streamlit run frontend/main.py 或 python server/main.py 启动服务需要注意的是,本项目依赖 OpenAI API(GPT-4o),不支持纯离线部署。如果需要完全私有化,需替换 langchain_openai 为本地部署的 LLM(如 Ollama + LlamaIndex)。另外,HanLP 2.1.1 的首次运行会下载模型权重,需要保证网络畅通。
尽管项目功能丰富,仍有几处值得关注的局限性:
1. 实体抽取质量依赖 LLM 能力:当前方案中,三元组抽取完全依赖 OpenAI API。虽然 GPT-4o 的抽取质量整体不错,但对于专业领域(医疗、法律、金融)的术语,仍可能出现实体边界模糊或关系误判的问题。作者已在 issues 中提到考虑引入本地模型作为备选。
2. 图数据库运维复杂度:Neo4j 虽然功能强大,但相比向量数据库(Milvus、Qdrant)运维门槛更高。项目没有提供 Neo4j 的备份、监控方案,企业级使用时需要额外关注数据安全。
3. 大规模文档处理性能:当前方案在文档数量超过千篇时,Neo4j 的图查询延迟会明显上升。项目 roadmap 中提到了分片和增量索引的计划,但尚未完全实现。
GraphRAG 正在成为企业知识管理的新范式。本项目将 GraphRAG 与 DeepSearch 融合,并提供了完整的 Agent 编排框架,为中文 AI 开发者提供了一个可参考、可落地的技术方案。随着 Agentic RAG 概念的持续火热,这类结合知识图谱与多 Agent 协作的项目将在私域知识库、智能客服、决策支持系统等场景发挥越来越重要的作用。
如果你是 AI 开发者,推荐从项目提供的示例数据集开始,依次体验 7 种 Agent 模式,直观感受不同方案在复杂问答上的效果差异。如果你是企业用户,建议先评估 Neo4j 的运维能力,再决定是否将本方案引入生产环境。