Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 需要的是地图，不是图钉
大分岔 — 属性图 vs RDF 三元组存储
图数据库 — 什么用在哪里
RDF 与本体栈 — 当你需要形式化语义
图 RAG 框架 — 自己搭，还是自带电池
向量 + 图 — 嵌入的位置
什么时候不该用图
决策流程
结语
参考资料

引言 — 需要的是地图，不是图钉

知识图谱工具的地形，在过去两年里爆发了。光是图数据库就有六个值得认真考虑，RDF 栈有二十年的历史，图 RAG 框架几乎每个月都有新的冒出来。这类文章常见的失败，是罗列三十个链接就完事。链接清单已经足够多了。

所以本文画一张地图。每个类别，都讲 拿它做什么、两三个代表性工具，以及什么时候该选什么。这是本系列实用意义上的最后一篇 — 走过为什么要用图 RAG、如何构建图、如何把领域建模为本体，如今终于来回答「那么，到底该用什么」。

先摆一个诚实的前提：工具是会变的。就在写这篇文章的过程中，一个知名的嵌入式图 DB 就被归档了。所以，比起工具的名字，我把 挑选的标准 写得更用心，好让它能留得更久。

大分岔 — 属性图 vs RDF 三元组存储

无论你最终选什么，第一个分岔口都是数据模型。这里有两大家族。

属性图给带标签的节点和边挂上任意的键值属性。形式化模式(schema)不是必需的，对开发者友好，用 Cypher(以及在 2024 年成为 ISO 标准的 GQL)、Gremlin、GSQL 来查询。

// 属性图 (Cypher): 实用，模式可选
CREATE (a:Person {name: 'Ada'})-[:WORKS_AT]->(c:Company {name: 'AE Ltd'})

RDF 三元组存储以(主语、谓语、宾语)三元组来保存，用全局 IRI 标识实体，用 RDFS/OWL 定义形式化本体(ontology)，并且能跑逻辑推理。你用 SPARQL 查询它；因为是 W3C 标准，跨组织的互操作性很强。

# RDF (SPARQL): 全局标识符、形式化词汇、可推理
SELECT ?person WHERE { ?person a :Person ; :worksAt ?org . }

诚实的判断标准是这样的。大多数 LLM 与图 RAG 应用，适合用属性图。 它的仪式(ceremony)更少，处理那些抽取出来、混着噪声的图时也更宽容。要动用 RDF，是在你需要形式化语义的时候 — 多个团队或组织共享的词汇、逻辑推理、合规与标准、数据集成。本体到底要形式化到什么程度，我在领域本体篇里另外讲过。

顺带一提，Amazon Neptune 两者都支持(属性图用 openCypher/Gremlin，RDF 用 SPARQL)。所以「已经在 AWS 上了」本身就是一个很强的理由。

图数据库 — 什么用在哪里

我按实用标准把六个分一分。

Neo4j — 事实上的标准。Cypher、最大的生态、最成熟的工具链。自托管或托管版 AuraDB、内置向量索引，还有后面会讲到的 1st-party neo4j-graphrag 包。它是服务器型属性图的 安全默认选项。
Memgraph — 内存型，兼容 Cypher。强在实时、低延迟的运营型工作负载与流式更新。2025 年的 AI 工具包(SQL2Graph、Unstructured2Graph)降低了上手的摩擦。需要 对频繁变动的数据做快速遍历，就选它。
Kùzu — 嵌入式(进程内)，「图版 SQLite」。列式、面向分析，Cypher，内置向量与全文检索。用在笔记本、原型、单节点分析上非常理想。一句诚实的提醒：Kùzu Inc. 已于 2025 年 10 月被 Apple 收购(acqui-hire)，GitHub 仓库随之归档。因为是 MIT 许可证，社区分叉会延续下去，但要把长期的生产依赖押在厂商的路线图上，请务必谨慎。技术很出色，只是你得把治理层面的不确定性算进价格里。
ArangoDB — 多模型(图 + 文档 + 键值)。想把 图和文档放进同一个存储 时选它。
Amazon Neptune — AWS 托管。属性图和 RDF 都支持，并能接上 Neptune Analytics 和 Bedrock Knowledge Bases 的 GraphRAG。想 待在 AWS 上、又想减轻运维负担 就选它。
TigerGraph — 原生并行(MPP)，GSQL。强在大规模图上的深链分析(欺诈检测、KYC/AML、推荐)。适合 规模极大、多跳分析很重 的场景。

嵌入式 vs 服务器，这样区分。原型、笔记本、单节点，就用嵌入式(Kùzu)。要并发、要生态、要上生产，就用服务器(Neo4j)。想要托管，就选 Neptune 或 AuraDB。

RDF 与本体栈 — 当你需要形式化语义

如果你踏上了 RDF 这条路，工具组合大体是这样的。

Protégé — 开源 OWL/RDF 本体编辑器的标准(斯坦福)。是你撰写本体的地方。
OWL / RDF / RDFS / SPARQL — W3C 标准本身。RDF 是数据模型，RDFS 和 OWL 是模式与逻辑，SPARQL 是查询语言。
RDFLib — Python 的 RDF 库。适合脚本、小图、ETL。
Apache Jena — Java 框架。是包含 Fuseki(SPARQL 服务器)、TDB(三元组存储)和推理器在内的开源主力。
Ontotext GraphDB — 企业级 RDF 三元组存储。SPARQL、RDF-star、推理，乃至向量相似度。
TopBraid (TopQuadrant EDG) — 构建在 RDF 知识图谱之上的企业数据治理。EDG 8.0(2025 年 2 月)内置了向量 DB，用来帮助实体解析与打标。商用，以治理为中心。

挑选标准：原型、Python 就用 RDFLib。开源的生产级 RDF 应用就用 Jena(+Fuseki)。需要推理和规模的企业级三元组存储就用 GraphDB(或 Stardog)。做数据管家(data stewardship)的组织就用 TopBraid EDG。撰写本体，随便在哪都用 Protégé。

图 RAG 框架 — 自己搭，还是自带电池

在这里，用两个维度来切分，选择就会变简单。(1) 是自带电池的流水线，还是组装部件；(2) 批量索引是重还是轻。

Microsoft GraphRAG — 自带电池，批量很重。它跑完整条流水线：LLM 抽取实体与关系 → 构建图 → Leiden 社区检测 → 社区摘要 → 局部与全局检索。对 「这整个语料库的主题是什么」 这类全局问题尤其强，但前置的 LLM 索引成本很大。LazyGraphRAG(2024 年末)把摘要往后推，将索引成本压到与向量 RAG 相当，同时守住全局问题的质量。需要对整个语料库做综合、又能承担这份成本(或用 Lazy 绕开它)的，就选它。
neo4j-graphrag (Python) — Neo4j 的官方(1st-party)库。端到端地提供 KG 构建器(SimpleKGPipeline)与检索器(Vector、VectorCypher、Hybrid、Text2Cypher)。想要一条 已押注 Neo4j、且有官方支持的路径 就选它。
LlamaIndex PropertyGraphIndex — 框架原生。对每个分块跑抽取器(kg_extractors)来附上实体与关系，可以随意替换图存储，并提供多种检索器。如果你 已经在 LlamaIndex 里 了，就用它。
LangChain LLMGraphTransformer — 组装部件。把允许的节点与关系类型作为模式传给它，它就会抽取出节点和关系。想 自己掌控整条流水线 时用它。
Cognee — 智能体的长期记忆。ECL(Extract, Cognify, Load)流水线，图 + 向量混合，多种后端(Kùzu、Neo4j、NetworkX 等)。如果你的目标不是文档 QA，而是 持续的智能体记忆，就用它。
txtai — 轻量的一体化嵌入框架。它的语义图(5.0, 2022~)用嵌入自动生成边，通过遍历图路径来做 RAG。如果你想 在本地轻量地做主题探索、又觉得专门的图 DB 是负担，就用它。
Haystack — 通用的 LLM 与 RAG 流水线框架(deepset)。可以把图作为组件接进来，但它并非专为图而生。把它当成 编排层 来看，别指望它是一个图优先(graph-first)的工具。

自己搭 vs 自带电池的诀窍：如果你只是想把实体和关系塞进自己的图里，那么 LangChain/LlamaIndex 的抽取器、或者一次普通的 LLM 调用就够了。Microsoft GraphRAG 只有在你真正需要它那套社区摘要、全局查询的机器时，才对得起它的成本。

向量 + 图 — 嵌入的位置

一个常见的误解，是把向量还是图看成二选一。现代的默认答案是混合。

向量检索负责模糊的语义回忆(「像这样的段落」)，图遍历负责精确的多跳关系(「X 与 Y 是怎么连上的」「Z 会影响到的一切」)。标准套路是这样的 — 把节点和分块做嵌入，用向量检索找到入口点，再从那里遍历图，把连带的上下文牵引进来。neo4j-graphrag 的 VectorCypherRetriever 正是这个形状。

而且如今大多数图 DB(Neo4j、Kùzu、Memgraph、Neptune Analytics、GraphDB、TopBraid)都内置了向量索引。所以很多时候，你并不非得再来一个单独的向量 DB。嵌入也用在构建图这件事上 — 把相似节点连起来的实体解析(entity resolution)就是一个例子，TopBraid EDG 8.0 的向量 DB、txtai 的语义图，做的就是这件事。

什么时候不该用图

放上诚实的另一头砝码。如果你的问题用单跳相似度就能解(「找关于 X 的文档」「帮我把这份政策总结一下」)，那么普通的向量 RAG 更简单、更便宜、更快，而且已经够用。图会加上抽取流水线、存储、模式、遍历逻辑 — 而其中的每一样都可能出错。

图能对得起成本，只在你需要下面这四样之一的时候：多跳推理、关系感知的检索、覆盖整个语料库的全局综合、可解释的来源追溯。如果你说不出这里面到底需要哪一样，那答案多半就是向量 RAG。怎样先把检索的基本功扎扎实实打好，我整理在生产级 RAG 模式里。

还有一点 — 建在糟糕抽取之上的图，比没有图更糟。 构建的质量决定了一切(参见图构建篇)。

决策流程

压缩成一页，就是这样。

1. 问题需要关系吗?
   (多跳、「X 与 Y 是怎么连上的」、整个语料库的主题)
   否   -> 普通的向量 RAG。到此为止。别去建图。
   是   -> 继续。

2. 需要形式化语义吗?
   (逻辑推理、跨组织共享的词汇、标准与规制)
   是   -> RDF 栈: 用 Protege(OWL)撰写、存进 Jena/GraphDB、用 SPARQL 查询。
   否   -> 属性图 (见下)。

3. 选图 DB:
   本地 / 笔记本 / 单节点  -> Kuzu (注: 2025 年仓库归档，社区分叉)
   生产服务器、最大生态    -> Neo4j
   实时 / 流式更新         -> Memgraph
   AWS 托管                -> Amazon Neptune
   图 + 文档放进一个存储   -> ArangoDB
   超大规模并行深链分析    -> TigerGraph

4. 选图 RAG 层:
   「整个语料库的主题」综合    -> Microsoft GraphRAG (成本用 LazyGraphRAG 解决)
   押注 Neo4j、想要 1st-party  -> neo4j-graphrag
   已经在某个框架里            -> LlamaIndex PropertyGraphIndex / LangChain
   持续的智能体记忆            -> Cognee
   轻量 / 本地 / 主题探索      -> txtai 语义图

结语

是地图，不是图钉。工具会摇摆 — Kùzu 就是今年的证据。不摇摆的是问题本身。属性图还是 RDF，不是赶时髦，而是语义的问题；图还是向量，不是炒作，而是关系的问题。先回答好这两个，再去挑工具。

至此，我们走到了这个系列实用意义上的终点。为什么要用图 RAG讲了理由，图构建讲了怎么建，领域本体讲了建模，而这一篇讲了工具。再把那篇为「图用得过头」时准备的生产级 RAG 模式也放在手边，这张地图就足够了。

最诚实的最后一句：最好的图项目，通常是能回答问题的那个最小的 — 而有时候，那意味着压根不用图。