每个人在构建GraphRAG时都从同一个Google搜索开始，最终都停留在微软的论文上。然后他们会花费三周时间构建社区检测管道，生成层次摘要，消耗API信用——结果却发现他们的实际查询根本不需要这些。

GraphRAG的复杂性存在层次结构。大多数人直接跳到最高级，因为那正是著名的论文描述的。他们在解决第一级的问题时却在构建第三级。

各个层次

将GraphRAG视为一个连续体，而不是二元对立。

第0级——向量RAG。 分块、嵌入、检索最相似的块，然后输入LLM。没有图。这正是Qdrant、Pinecone和Weaviate默认提供的。对于简单的事实性问题，它表现得非常好。“SOP-123关于温度监控的规定是什么？”——向量搜索找到块，LLM回答。完成。

当答案需要跨块连接信息时，它会失效。“哪些系统受引用Part 11的SOPs管辖？”需要遍历任何单一块中不存在的关系。

第1级——增强图RAG。 你保留向量搜索，同时添加图遍历。向量搜索找到入口点（“SOP-123”），然后图向外扩展——到要求、系统、验证、偏差。你获得结构化的上下文，而纯向量搜索会忽略这些。

这正是Neo4j的混合检索器所做的。这也是生产系统中最实用的级别，因为你可以在不重建一切的情况下将其附加到现有的向量管道上。

第2级——知识图谱RAG。 现在图本身成为主要的知识表示。你运行LLM从文档中提取实体和关系，构建一个真正的知识图谱，并用Cypher查询它。你不再搜索提到“LabVantage”的文本，而是有一个规范的:System节点，带有类型化的关系到要求、验证和偏差。

这正是LlamaIndex的PropertyGraphIndex和Neo4j的LLM图构建器所在的地方。它的构建成本比第1级更高，但图更丰富，查询也更精确。

第3级——微软风格的GraphRAG。 这是著名的级别。在知识图谱之上，你添加层次社区检测（Leiden算法）和LLM生成的多个抽象层次的社区摘要。局部社区可能会总结“约翰和简在微软构建GraphRAG团队。”更高层次的社区可能会总结“微软的人工智能研究部门包含从事GraphRAG、Copilot和Azure AI的团队。”

这使得一种查询类型成为低级别无法处理的：全局/语料库范围的问题。“所有500起偏差调查的主要主题是什么？”社区摘要让LLM看到整个森林，而不仅仅是个别树木。

第4级——代理式GraphRAG。 而不是硬编码一个检索策略，你让AI代理决定。代理看到问题，评估是否需要向量搜索、图遍历、社区摘要、SQL查询或它们的组合，然后相应地路由。Memgraph明确定位了这种架构——一个选择Text2Cypher、局部图扩展和查询导向的总结化基于问题的代理。

成本曲线

以下是各个级别的实际成本：

级别 索引成本（1000文档） 查询延迟 实施时间
0 — 向量RAG 分毫 <100ms 几小时
1 — 增强图 低（在现有向量上添加遍历） 100-500ms 几天
2 — 知识图谱 中等（LLM提取） 100ms-2s 几周
3 — 微软GraphRAG 高（$50-500+与GPT-4o） 2-10s（映射-减少） 几周
4 — 代理式 变化（取决于路由复杂性） 变化 几个月

第3级的成本数字是真实的。微软的参考实现对每个块进行LLM调用以提取实体，然后对每个社区进行LLM调用以生成摘要。对于一个中等大小的语料库，你在能够提出单个问题之前可能需要数千次API调用。

懒惰GraphRAG（微软自己的成本优化变体）通过将摘要推迟到查询时间来解决这个问题。它将索引成本削减到GraphRAG的0.1%左右，同时在本地查询中保持质量，在全局查询中实现700倍的成本降低。这是微软承认原始方法过于昂贵。

LightRAG更进一步——完全跳过社区检测，使用实体级和关系级的双重检索（无需Leiden聚类的重负荷）。它的质量大约是GraphRAG的70-90%，成本却少得多。对于大多数生产用例，这个质量差距并不重要。

没有人正确引用的基准测试

每个GraphRAG演示文稿都展示相同的数字。“72-83%的全面性改进！”“31点的MuSiQue增益！”这些数字是真实的——但它们衡量的是GraphRAG设计的查询类型：多跳推理和全局总结。

他们没有突出的是：

单一事实查找：普通RAG胜出。 2025年密歇根州立大学和Meta的一项受控头对头测试发现，对于简单的事实性问题，普通向量RAG的F1得分为64.8，而GraphRAG为63.0。图结构是查询不需要的额外开销。

GraphRAG-Bench（ICLR 2026）确认了这一模式。 简单的事实检索是平局（60.9 vs 60.1）。复杂的推理给图带来了10分的优势（53.4 vs 42.9）。上下文总结给图带来了13分的优势（64.4 vs 51.3）。

评估本身是有问题的。 LLM作为裁判的偏见可以导致胜率相差30多个百分点，这取决于答案的排序、长度和位置。一个报告的66.7%胜率在经过偏见校正后降至约39%。

真实的图景是：GraphRAG在复杂、多跳、全局到局部合成查询中胜出。对于单一事实查找，它对朴素RAG几乎没有优势。如果你的工作负载是80%简单的问答和20%复杂的推理，你为一个Level 0问题支付了Level 3的成本。

实际生态系统（实际存在什么）

GraphRAG的生态系统有四个层次，混淆它们是大多数困惑的来源。

第一层：框架

微软GraphRAG是参考实现——每个人首先阅读的东西。LightRAG（香港大学，GitHub星标约29000）是实用的替代品，它剥离了管道以保留基本要素。HippoRAG（俄亥俄州立大学）使用个性化PageRank而不是社区检测，灵感来自人类记忆如何工作。fast-graphrag（circlemind）是轻量级、可修改的基本基准。

2025-2026年的新进入者包括CatRAG（基于查询的遍历而不是固定的转移概率）、ParallaxRAG（优化4跳以上的推理）、Deep GraphRAG（基于强化学习的动态奖励加权，实现接近前沿模型性能的小模型）和TrustGraph的OntologyRAG（由领域本体引导的提取——适用于受监管的环境）。

第二层：图数据库

Neo4j是市场领导者，拥有最深的生态系统——GDS库包含65多种算法，官方neo4j-graphrag Python包，LangChain合作伙伴集成。它是安全的企业默认选择。

Memgraph是性能选择——内存C++，毫秒级遍历，原子图RAG，整个检索管道（搜索、扩展、排名、提示组装）作为单个Cypher查询运行。NASA在10年后从Neo4j切换到Memgraph。Memgraph的基准测试声称最高可达41倍的延迟降低。

FalkorDB（RedisGraph的继任者）使用GraphBLAS稀疏矩阵实现超低延迟。ArcadeDB是多模型选项，具有最宽松的许可证（Apache 2.0）。如果你是AWS原生用户，Amazon Neptune Analytics是托管选项。

第三层：编排

LlamaIndex是最快的原型路径——PropertyGraphIndex，支持10多种图存储后端，在不到50行代码中工作。LangChain提供GraphCypherQAChain用于文本到Cypher模式。它们都不是GraphRAG引擎——它们是围绕你选择的引擎的包装器。

第四层：内存层

Graphiti（Zep）是有趣的异类。它不是文档图RAG——它是代理记忆的临时知识图谱基础设施。每条边都携带一个有效区间，因此图可以正确处理被取代的事实。如果你正在构建代理记忆而不是文档检索，这是正确的工具。如果你正在索引SOP和CAPA，那不是。

每个人都会问的问题

“GraphRAG是否取代Neo4j？”

不。而且这种关系是相反的。

GraphRAG是一种检索模式。Neo4j是一个存储引擎。说“GraphRAG取代Neo4j”就像说“微服务取代PostgreSQL”。模式运行在基础设施之上。

微软的参考实现使用NetworkX和Parquet文件——在研究上下文中对几千份文档工作得很好。但如果你尝试在NetworkX中以内存方式运行一个包含100,000份文档的企业语料库，你的服务器会崩溃。生产GraphRAG需要持久存储、并发访问、实时更新和亚秒级遍历。这就是一个图数据库。

主流的企业模式是：通过LLM提取实体/关系，存储在Neo4j或Memgraph中，创建嵌入向量索引，查询时运行混合检索器。GraphRAG增加了对图数据库的需求，而不是取代它们。

没有人谈论的内容

GraphRAG最困难的部分不是架构或数据库。它发生在检索之前：

实体解析。 LLM提取表面形式，而不是规范实体。“LabVantage”、“Lab Vantage”、“LabVantage LIMS”、“LIMS系统”——四个节点，一个现实世界实体。2025年的一项研究发现，LLM提取产生了847个本应是312个的实体。简单应用实体解析——减少图的大小约40%——始终能提高性能。移除节点会改善图。

提取质量。 LLM遗漏实体，错误标注关系，并虚构连接。基于模式的提取有助于此。人工在环验证帮助更大。但大多数教程完全跳过了这一点，只展示了幸福路径。

维护。 向GraphRAG索引添加新文档不像向向量存储添加块那样简单。你必须提取新实体，将它们合并到现有图中，解决重复问题，并可能重新检测社区。DRIFT（微软的增量模式）和LightRAG的增量更新解决了这个问题，但仍然比向量存储更新难一个数量级。

变更控制。 在受监管的环境中，每个LLM生成的社区摘要实际上是一个新的“受控文档”。每次重新总结都会产生一个新版本。如果你在GxP环境中，这会成为大多数实现没有考虑的审计面。

我实际会构建的架构

鉴于以上所有内容，对于生产系统，这里是什么样的堆栈：

对于大多数企业问答（第1-2级）： 语义入口点的向量搜索。结构上下文的图遍历。Neo4j或Memgraph作为图存储。LlamaIndex或自定义编排。没有社区检测。没有层次摘要。图提供多跳上下文；向量搜索提供语义入口点。完成。

对于语料库范围的主题分析（第3级）： 添加微软风格的社区检测和摘要——但仅限于需要它的特定用例。将简单查询路由到向量或图的单独路径。使用懒惰GraphRAG的延迟摘要来避免为从未查询的摘要付费。将社区摘要视为受控文档并进行版本控制。

对于基于代理的系统（第4级）： 让代理决定。使用Memgraph的架构或构建自定义路由层。代理根据问题选择向量搜索、图遍历、社区摘要或SQL。这是未来，但也是最复杂且最难构建和评估的。

最后一句话

GraphRAG不是一件事。它是一个连续体。你的查询决定了正确的级别，而不是微软的论文描述的。

如果你的查询主要是简单的事实查找，第0级（向量RAG）就是答案。如果你需要多跳关系遍历，第1-2级可以以20%的成本获得80%的收益。如果你确实需要语料库范围的主题分析，第3级值得其复杂性。如果你正在构建一个需要动态跨越多个数据源进行推理的代理，第4级是你要去的地方——但你是在构建基础设施，而不仅仅是管道。

数据库选择（Neo4j vs. Memgraph vs. FalkorDB）是一个真正的工程决策。但它是在更重要的决策之后——你的问题实际上需要连续体中的哪一级？

大多数人正在构建第3级，因为那正是著名的论文描述的。他们的问题是第1级。