GraphRAG 六种架构模式实战指南：从 Text-to-Cypher 到混合检索

标准向量检索增强生成（RAG）把文档切块、向量化，在查询时召回语义相近的片段。这套做法在回答局部、明确的问题时表现稳定，能缓解幻觉、让回答有据可依，也绕开了模型预训练知识的时间截断。但真实业务里的问题往往更复杂：需要全局上下文、需要多跳推理、需要跨文档聚合数值。比如「供应商 B 延迟发货零件 A，会如何影响产品 C 的最终装配」，向量检索只能按语义重叠召回彼此孤立的片段，抓不到实体之间那条确定的关系链；再比如「某产品类别截至 2025 年的五年营收趋势」，它也很难跨文档把 2021 到 2025 年的正确片段都找齐并做推理。根子在于，标准向量 RAG 看到的是一堆扁平的文本片段。

GraphRAG 的思路是把检索对象从扁平文档换成结构化知识。它把知识图谱（KG）接入 RAG 管线，数据以节点（实体）、边（关系）和属性三种形态存储，从而把大模型的语义模糊匹配能力与知识图谱的确定性推理能力结合起来。下面不铺陈 GraphRAG 的基础概念，而是直接拆解六种彼此不同的架构模式，说明它们各自怎么工作、数据怎么流动、优缺点是什么、生产环境里什么时候该用哪一种。

准备工作

在动手搭任何一种模式之前，需要先确认几项前置条件。这些条件不因架构模式而变，是所有 GraphRAG 系统的共同底座。

知识储备与角色分工

GraphRAG 横跨三个领域：大模型应用开发、图数据建模、检索系统调优。团队里至少要有人能定义本体（ontology）——也就是这个业务里有哪些实体类型、哪些关系类型、各自带什么属性。本体定义得含糊，后面的抽取和查询都会跟着含糊。

技术组件清单

• 大模型接口：用于信息抽取、查询翻译、结果格式化。抽取环节对模型能力要求较高，格式化环节可以用更便宜的模型。
• 图数据库：用于存储节点与边，并提供图查询语言。常见选择包括 Neo4j、NebulaGraph、Memgraph 等，它们使用 Cypher 一类的查询语言来遍历节点和关系。
• 向量数据库或向量索引：用于存储原始文档块的嵌入，以及（可选的）节点与关系的嵌入。
• 嵌入模型：用于把文本块、节点、关系转成向量。
• 编排层：负责并发调用、结果合并、上下文拼装、错误重试。

数据准备

需要准备一批非结构化文本作为输入源。同时要明确一件事：抽取步骤是计算密集型的，成本不低，因此最好先用一小批文档跑通全流程，确认本体设计和抽取质量，再全量铺开。

关于版本与配额

图数据库、向量库、模型接口的版本号、定价、调用配额、区域可用性都会随时间变化，动手前请以各产品官网的当前信息为准，不要依赖任何二手资料里的数字。

GraphRAG 管线的四个基础组件

无论后面采用多复杂的路由或检索逻辑，任何 GraphRAG 系统都需要下面四根支柱。理解它们，才能理解六种模式到底在哪些环节上产生了分歧。

信息抽取

把原始非结构化文本送进大模型，指示它执行命名实体识别（NER）和关系抽取。模型需要识别出节点（例如「公司」「人物」）和边（例如「就职于」「供应」）。这一步计算开销大，并且依赖一份定义清晰的本体。抽取质量直接决定图谱的可用性：漏抽的实体在后续查询里就是查不到的，抽错的边会污染推理链。

图存储

把抽取出的节点和边写入图数据库。这类数据库使用专门的查询语言（如 Cypher）来遍历节点与关系。此外，节点和关系也可以做嵌入，这样在精确匹配查不到结果时，还能退回到基于相似度的搜索与遍历。这一点在后面几种模式里反复出现，是缓解「本体用词与用户用词不一致」的关键手段。

检索

用户查询与图谱交互的机制。六种架构模式的分歧主要就发生在这里：有的让模型直接生成图查询，有的让向量检索和图检索并行跑，有的让其中一路的结果去过滤另一路。

生成

把检索到的图数据注入大模型的上下文窗口，合成最终有依据的回答。这一步的输入形态可能是表格、JSON 关系列表，也可能是纯文本片段，取决于上游检索方式。

操作步骤

下面按模式逐一展开。每种模式都给出工作方式、实现要点与数据流、优缺点和适用场景。可以把它当作一份选型清单：先读完六种，再回到自己的查询分布上做判断。

模式一：Text-to-Cypher（图查询生成）

这是最直接、最确定的一种做法。在这个架构里，大模型严格扮演查询翻译器的角色，而不是语义搜索引擎。

工作方式

1. 用户输入自然语言查询。
2. 系统通过系统提示词把图数据库的 schema（节点标签、边类型、属性）提供给大模型。
3. 大模型的主要任务是把自然语言翻译成合法的图查询语句，例如 Neo4j 的 Cypher 或 Gremlin。
4. 该查询直接在图数据库上执行。
5. 数据库返回的精确事实结果，要么直接呈现给用户，要么交给第二个大模型格式化成自然语言回答。

实现要点与数据流

要跑通这条路径，提示词工程必须足够严谨。不能把用户查询直接丢给模型，必须把准确的本体一并传入。

• Schema 注入：从图数据库中提取 schema，格式化成字符串放进提示词。在 Neo4j 中可以用 CALL db.schema.visualization() 之类的语句获取结构信息。
• 少样本提示：给模型提供 5 到 10 个复杂自然语言问题及其对应的最优 Cypher 查询示例。这能显著减少语法错误。
• 执行与回退：执行生成的 Cypher。如果数据库抛出语法错误，捕获该错误，把它追加到提示词里，让模型修正自己的查询，形成一个自我纠错循环。
• 格式化：把数据库返回的 JSON 或表格输出交给一个更便宜的模型，提示它「用户问的是 X，数据库返回的是 Y，请写一段礼貌的回答」。

优点

• 检索零幻觉：检索过程 100% 确定，就像用 SQL 查关系型数据库一样。模型不猜测关系，关系本来就在图谱里。
• 聚合能力：这是唯一能原生处理计数、求平均、数学聚合的模式。例如「向 VP John 汇报的工程师平均薪资是多少」这类问题，只有它能直接算出来。

缺点

• 脆弱性：如果用户问的是「软件开发人员」，而本体里用的是「工程师」，严格的 Cypher 查询会返回空。常见的缓解办法是给图节点和关系做嵌入（向量图搜索），先通过语义相似度找到起始节点，再执行 Cypher 遍历。但要小心：与确定性的 Cypher 不同，语义相似度是非确定性的，它总会返回节点，哪怕这些节点与查询意图并不一致、甚至是错的。
• 拿不到非结构化上下文：它只能检索被显式建模成节点和边的内容，无法取回描述数据细微差别的整段文字。

适用场景

适合高度结构化、操作型的知识库，答案依赖精确遍历、计数、聚合或最短路径查找。使用者最好了解本体结构，才能有效查询图谱。典型场景包括内部 HR 数据库、供应链物流、金融交易网络——这些领域语义歧义低、精度要求高，且使用者本身就是领域专家。

模式二：并行混合 RAG（向量 + 图）

这个架构承认一个现实：向量数据库和图数据库各有所长，可以互补。向量库擅长非结构化文本的语义匹配，图数据库擅长遍历确定的结构化关系。本模式及后续模式，都是在探索如何把两者的能力组合起来，为各类查询提供有依据的回答。

工作方式

系统同时维护两个数据库：一个是原始非结构化文档块的向量索引，另一个是抽取出的实体与关系的知识图谱。用户查询到达时，系统同时查询两个库。这个思路的前提是：一个复杂的查询往往同时包含几部分——有些部分适合由图谱确定回答（例如「营收是多少」），有些部分适合由向量库回答（例如「战略重点是什么」）。向量库召回语义最相近的 top-K 片段，图数据库并发地取出相关子图，两路结果合并后注入大模型的上下文窗口。

实现要点与数据流

• 双路摄入：文档摄入时，先切块并嵌入到向量库；同时把它送进抽取管线填充图数据库。此外，图节点必须维护一个 source_document_id 属性。这个关联让系统能为图事实提供精确的文档引用，也能在源文档被删除时安全地清理过期的图节点。注意，不建议把 source_chunk_ids 存成节点属性——一个实体（比如某个零件编号）可能出现在成百上千个片段里，这个数组会变得极其庞大。
• 查询处理：查询在两个数据库上并发处理。向量这一路，把查询嵌入后召回 top-K 语义相近的片段。图这一路，先从查询中抽取实体和关系，尝试基于这些实体做严格的 Cypher 遍历；如果严格匹配失败，就回退到语义图搜索（直接对节点或关系的嵌入做检索），找到正确的入口节点，再取出它们的一跳或两跳自我图。
• 上下文拼装：此时手上有一组文本片段和一组 JSON 格式的图关系。把它们拼接进大模型提示词。以「上海港延误的战略缓解方案是什么，哪些二级供应商受影响」为例，提示词里会同时出现：来自文档的文本上下文（一份内部备忘录，详述亚洲港口的替代路线和库存缓冲策略），以及来自知识图谱的上下文（上海港 → 为谁发货 → 供应商 A → 供应零件 → 芯片 X）。然后指示模型用上述上下文回答问题。

优点

• 高召回：两头的好处都拿到了。答案藏在段落细节里，向量搜索能抓到；答案需要连接两个离散事实，图谱能抓到。
• 低延迟：向量搜索和图搜索并发执行，检索延迟取决于两者中较慢的那个，而不是两者之和。

缺点

• Token 开销大：注入的上下文量很大，推高推理成本，有时还会导致合成模型忽略上下文里的细粒度事实或数字。
• 冗余：某些查询下，图或向量库任一路的上下文其实就够了。并行检索会注入冗余内容，浪费 token。

适用场景

这是通用型企业搜索的稳妥选择。当你无法预判用户查询到底需要事实性关系数据，还是宽泛的非结构化上下文时，它比较合适。如果查询本身就是语义型、关系型或两者混合，并行混合是可行路径。

模式三：顺序混合（图优先）

与并行方案不同，顺序混合架构用一路检索的结果去显式地指导并过滤另一路。这样能构造出高度聚焦、精确的上下文窗口，减少并行方案带来的冗余和高 token 成本。第一个变体是图优先 RAG。

工作方式

系统先查询知识图谱，找到精确的实体关系。如前所述，图节点带有追踪其来源的 source_document_ids 元数据。系统提取这些文档 ID，把它们作为硬过滤条件，用于后续的向量搜索。这样一来，就能保证取回的非结构化文本只来自那些提及了满足查询关系逻辑的实体的文档。

实现要点与数据流

假设查询是「找出 XYZ 公司供应的所有锂电池元件的安全警告」。

1. 图遍历：系统从查询中定位入口节点（例如「XYZ 公司」）。然后通过严格的 Cypher 匹配，或回退到节点嵌入上的语义图搜索，找到该节点。
2. 沿关系扩展：顺着供应关系找到该公司供应的锂电池元件节点。
3. 提取文档 ID：从这些节点上读取 source_document_ids。
4. 过滤向量搜索：把文档 ID 集合作为过滤条件，在向量库中只对这些文档的片段做语义检索，召回与「安全警告」语义最接近的内容。
5. 上下文拼装：把图关系与过滤后的文本片段一起注入模型。

优点

• 上下文精准：向量检索被限制在关系逻辑已经确认过的文档范围内，噪声显著降低。
• Token 更省：相比并行方案，注入的无关内容更少。
• 可解释：检索路径可以沿着图关系回溯，便于排查为什么召回了这些文档。

缺点

• 依赖图抽取的完整性：如果某个关键实体在抽取阶段被漏掉，图这一路就找不到它，后续的向量过滤也就无从谈起，整条链路会漏召回。
• 串行带来延迟叠加：两路检索是先后执行的，总延迟是两者之和，而不是取较大值。

适用场景

适合关系逻辑明确、且希望把文本检索范围收窄到特定文档集合的查询。当业务问题天然带有「先确定实体、再找相关描述」的结构时，图优先的顺序混合比并行方案更经济。

模式四：顺序混合（向量优先）

这是顺序混合的另一个方向：先用向量检索定位相关文本，再从这些文本中抽取实体，最后用这些实体去查询图谱。

工作方式

1. 用户查询先进入向量库，召回 top-K 语义相近的文档片段。
2. 从这些片段中抽取实体和关系，或者直接复用摄入阶段已经抽取好的实体。
3. 用这些实体作为入口，在图谱上做遍历，取出它们之间的关系子图。
4. 把文本片段与图关系一起注入模型生成回答。

优点

• 入口更宽容：向量检索对用词差异不敏感，用户不必知道本体里的确切术语，也能找到相关文档，再由文档里的实体接入图谱。
• 适合探索型查询：当用户自己也说不清要找什么、只知道大致主题时，这种顺序更自然。

缺点

• 图的价值被削弱：如果向量检索没召回包含关键实体的片段，图谱这一路就接不上，等于退化成普通向量 RAG。
• 同样有串行延迟：两路先后执行，延迟叠加。

适用场景

适合查询意图模糊、需要先靠语义检索「探路」的场景，例如面向非专家用户的问答入口。

模式五：图增强的迭代检索

复杂问题往往一次检索答不上来。迭代模式让系统在多轮之间逐步扩展上下文：每一轮根据已有信息判断还缺什么，再决定下一步往图谱的哪个方向走。

工作方式

1. 第一轮检索得到初始的实体集合与文本片段。
2. 由模型判断当前上下文是否足以回答问题。若不足，则指出缺失的信息类型。
3. 根据缺失信息，在图谱上沿特定关系扩展一跳或两跳，或发起新的向量检索。
4. 把新增内容并入上下文，重复判断，直到信息足够或达到轮次上限。
5. 用累积的上下文生成最终回答。

优点

• 能处理多跳问题：像「供应商 B 延迟发货如何影响产品 C 的装配」这类问题，需要沿关系链逐跳展开，迭代方式天然契合。
• 上下文按需增长：不必一次性注入大量无关内容。

缺点

• 延迟不可控：轮次越多，响应越慢，且难以预估上界。
• 成本随轮次上升：每一轮都可能触发模型调用与图查询。
• 需要终止条件：必须设置最大轮次或置信度阈值，否则可能陷入无意义的循环。

适用场景

适合多跳推理、根因分析、影响链路追踪这类问题。对响应时间要求苛刻的在线场景要谨慎使用。

模式六：社区摘要与全局检索

前面几种模式都偏向「定位到具体实体再展开」。但有一类问题问的是整体：某个语料库的主题分布是什么、有哪些主要议题、整体趋势如何。这类问题没有明确的入口实体，逐点检索很难覆盖。

工作方式

1. 在摄入阶段，除了抽取实体和关系，还对图谱做社区划分，把关系紧密的节点聚成若干社区。
2. 为每个社区生成一份摘要，描述这个社区里有哪些实体、它们之间是什么关系、涉及什么主题。
3. 查询时，先在社区摘要层面做检索，定位与问题相关的若干社区。
4. 把相关社区的摘要（必要时再下钻到社区内的具体节点和边）注入模型，生成回答。

优点

• 能回答全局性问题：这是逐点检索做不到的。
• 摘要可复用：社区摘要在摄入阶段生成一次，之后多次查询都能用。

缺点

• 摄入成本高：社区划分和摘要生成都要额外调用模型，文档量大时开销明显。
• 摘要会丢细节：需要精确数字或具体事实的问题，仍然要回到节点级检索。
• 社区结构会随数据变化：新增文档后，社区划分可能需要重算。

适用场景

适合语料综述、主题发现、趋势概览类查询，常与实体级检索配合使用，形成「先看全局、再钻细节」的两段式流程。

一个完整示例

下面用一个供应链场景，把并行混合模式串起来，展示从摄入到回答的最小可跑通流程。示例只描述结构与步骤，具体语法请以所用图数据库和向量库的当前文档为准。

第一步：定义本体

先确定实体类型和关系类型。例如实体类型包括：供应商、零件、产品、港口。关系类型包括：供应商供应零件、零件装配成产品、港口为供应商发货。

第二步：摄入与抽取

把原始文档切块，嵌入后写入向量库。同时把每个文档块送进抽取流程，让模型按本体输出节点和边。抽取结果写入图数据库，并在每个节点上记录 source_document_id。

节点：供应商 A
节点：芯片 X
节点：上海港
边：供应商 A --供应零件--> 芯片 X
边：上海港 --为谁发货--> 供应商 A
属性：供应商 A.source_document_id = doc_017

第三步：并发检索

用户提问：「上海港延误会影响哪些二级供应商，缓解方案是什么？」

向量这一路召回与「港口延误」「缓解方案」「库存缓冲」语义相近的文档片段。图这一路从查询中抽取出「上海港」这个实体，做严格匹配；若匹配失败则回退到节点嵌入的语义搜索，找到入口节点后取出一到两跳的自我图。

第四步：拼装上下文

来自文档的上下文：
[内部备忘录：亚洲港口的替代路线与库存缓冲策略]

来自知识图谱的上下文：
上海港 -> 为谁发货 -> 供应商 A -> 供应零件 -> 芯片 X

请依据以上上下文回答问题。

第五步：生成回答

把拼装好的提示词交给模型，输出带依据的回答。如果回答里引用了图事实，可以顺着 source_document_id 回溯到原始文档，供人工核对。

第六步：验证与调优

用一批真实查询跑一遍，观察三类指标：召回是否覆盖了关键实体、注入的上下文里有多少是冗余的、回答里的数字和关系是否与图谱一致。根据结果调整 top-K、跳数上限和提示词结构。

注意事项

• 抽取是成本大头：信息抽取计算密集，且依赖定义清晰的本体。本体含糊会导致抽取结果不可用，返工代价高。
• 语义相似度是非确定性的：在 Text-to-Cypher 模式里用节点嵌入做回退匹配时要注意，语义搜索总会返回节点，哪怕它们与查询意图并不一致。严格匹配失败后的回退结果需要额外校验。
• 不要存 source_chunk_ids：把片段 ID 数组存成节点属性会膨胀得非常大，因为一个实体可能出现在成百上千个片段中。存 source_document_id 即可。
• 并行方案会注入冗余：某些查询下任一路的上下文就足够，并行检索会浪费 token，还可能让合成模型忽略细粒度事实。
• 顺序方案延迟叠加：两路先后执行时，总延迟是两者之和，而不是取较大值。
• 迭代方案需要终止条件：必须设置最大轮次或置信度阈值，否则可能陷入循环，延迟和成本都不可控。
• 社区摘要会丢细节：需要精确数字或具体事实的问题，仍要回到节点级检索。
• 版本、定价与配额以官网为准：图数据库、向量库、模型接口的版本号、价格、调用配额、区域可用性都会变化，动手前请查阅各产品官网的当前信息。