Gbrain、GraphRAG、LLM Wiki、Graphify：4 种知识图谱方案怎么选

发布日期：2026-07-01 08:23:41 浏览次数： 1536

作者：AI工程化实战派

微信搜一搜，关注“AI工程化实战派”

gbrain、GraphRAG、LLM Wiki、Graphify：4 种知识图谱方案怎么选

「怎么给 Agent 喂知识」是团队落地 AI 时的核心问题。gbrain、GraphRAG、LLM Wiki、Graphify 四个方案各自解决不同的需求。

向量检索的短板

传统 RAG 的做法：文档切块，向量化，塞进向量库，问问题取 top-k。

这方法对简单问答够用，但有个硬伤：只能找到语义相近的内容，理解不了文档之间的关系。

你问「这个需求跟之前哪个模块有关联」，向量检索答不了。知识图谱把实体和关系存成图结构，Agent 能顺着关系推理。

方案	核心思路	数据来源	官方链接
gbrain	Git + Postgres 做持久化知识图谱	人工录入 + Agent 自动更新	github.com/garrytan/gbrain
GraphRAG	知识图谱 + RAG 检索增强	文档自动提取图谱	microsoft.github.io/graphrag
LLM Wiki	LLM 维护的 Markdown 知识库	人工维护 + LLM 增量更新	github.com/nashsu/llm_wiki
Graphify	从代码库自动生成知识图谱	代码静态分析 + 语义提取	graphify.net

gbrain 是 Garry Tan 开源的方案，最初为 OpenClaw 设计的 Agent 记忆层。

用 Postgres 存图结构，Git 做版本控制。Agent 学到新知识就写入图谱，Git 提交记录变更。

1Agent 对话 → 提取实体和关系 → 写入 Postgres → Git commit 记录变更

特点：

成本：

适合多 Agent 协作需要共享记忆的团队。

GraphRAG 是微软的方案。先用 LLM 从文档里提取实体和关系建图谱，检索时顺着图谱找关联上下文，再让 LLM 生成回答。

1
2
3
文档集合 → LLM 提取实体/关系 → 构建知识图谱
         ↓
用户提问 → 图谱检索关联上下文 → LLM 生成回答

文档量大的时候优势最明显。普通 RAG 只能做局部匹配，GraphRAG 能回答「总结整个语料库的主题」这类全局问题。

代价：

适合有固定文档集合需要做全局分析的场景，比如企业知识库、法律文档。文档经常更新的场景不太适合。

Karpathy 提出的思路：用 LLM 当编译器，维护一个 Markdown 知识库。每次对话先检索相关内容，结果增量更新回去。

1
2
3
用户提问 → 检索 Wiki 相关页面 → LLM 结合上下文回答
         ↓
新信息 → LLM 决定更新哪个页面 → 写入 Markdown 文件

这个方案最轻。纯 Markdown 文件，任何编辑器都能打开，没有数据库依赖。知识沉淀过程透明，人随时能直接编辑。

局限：

个人用或者小团队够用，追求轻量和可控的场景是首选。

Graphify 从代码仓库自动生成知识图谱。静态分析提取函数调用和类继承关系，再结合语义分析理解代码意图。

1代码仓库 → 静态分析 → 提取函数/类/模块关系 → 生成知识图谱

只做代码相关的图谱，不处理业务文档。AI 编程助手顺着图谱理解项目结构，回答准确度明显提升。

局限：

适合大项目需要 AI 辅助开发和代码导航的场景。

维度	gbrain	GraphRAG	LLM Wiki	Graphify
部署难度	中（需要 Postgres）	高（需要 LLM 索引）	低（纯 Markdown）	中（需要代码分析）
图谱构建	手动 + Agent	自动从文档提取	LLM 增量维护	自动从代码提取
检索能力	Agent 记忆查询	全局图谱检索	语义检索	结构导航
更新频率	实时	低（需重建索引）	实时	按需
可观测性	Git 版本历史	图谱可视化	文件 diff	图谱可视化
适用规模	中小	大	小	中大