超越基础图检索：六种面向生产的架构，用于结合语义搜索、知识图谱和LLM推理。

检索增强生成（RAG（检索增强生成））是各组织中应用最广泛的LLM用例。通过在查询时对文档进行向量化并检索语义相似的片段，RAG可以缓解幻觉、为回答提供依据，并绕过模型预训练带来的静态知识截止限制。然而，在现实场景中，标准的基于向量的RAG在复杂查询上会遇到限制，例如那些需要全局上下文、多跳推理、跨文档数值聚合等的查询。

标准RAG非常擅长回答明确的、局部化的查询。但如果我们问：“供应商B延迟发货零件A会如何影响产品C的最终装配？”，它会基于语义重叠检索出彼此不连贯的片段，却完全遗漏了连接这些实体的明确、确定性的关系。类似地，对于诸如“截至2025年的5年间某一产品类别的收入趋势”这样的查询，它不太可能执行跨文档推理，从2021年至2025年的相关文档中获取正确片段并正确回答问题。这是因为标准向量RAG看到的只是一个由文档片段或块构成的扁平世界。

GraphRAG的转变

GraphRAG通过从检索扁平文档转向检索结构化知识来解决这个问题。它将知识图谱（KGs）集成到RAG流程中，其中数据以节点（实体）、边（关系）和属性的形式存储。通过这种方式，它将现代LLM的语义化、模糊匹配能力与KG的结构化、确定性推理结合起来。

本文不解释GraphRAG的基础知识，而是介绍GraphRAG的六种不同架构模式，以及它们的优缺点和用例。我们将探讨它们如何工作、数据流、可视化这些架构，以及在生产环境中究竟何时使用它们。

GraphRAG流程的核心组件

在深入这些架构之前，让我们先看看任何GraphRAG系统的基线组件。无论我们采用多么先进的路由或检索逻辑，系统都需要这些基础支柱：

• 信息抽取：原始非结构化文本会经过一个LLM，该LLM被指示执行命名实体识别（NER）和关系抽取。LLM识别节点（例如Company、Person）和边（例如WORKS_FOR、SUPPLIES）。这一步计算成本很高，并且需要定义良好的本体。
• 图存储：抽取出的节点和边会被加载到图数据库（如Neo4j、NebulaGraph、Memgraph等）中。这些数据库使用Cypher等专用查询语言来遍历节点和关系。此外，节点和关系可以被嵌入，以便在精确匹配无法产生结果时执行基于相似度的搜索和遍历。
• 检索：用户查询与图交互的机制。正如我们将看到的，不同架构模式在这方面差异显著。
• 生成：检索到的图数据会被注入LLM的上下文窗口中，以合成最终有依据的回答。

GraphRAG的6种架构模式

“GraphRAG”这个术语经常被宽泛地使用，但在实践中，它是若干根本不同架构模式的统称，其中一些模式里KG并不是唯一的知识存储。选择正确的模式取决于用户查询模式、系统成本、延迟和能力。

模式1：Text-to-Cypher / 图查询生成

GraphRAG 最直接且确定性的方法是 Text-to-Cypher 模式。在这种架构中，LLM（大语言模型） 严格充当查询翻译器，而非语义搜索引擎。

工作原理

用户输入自然语言查询。系统通过系统提示词向 LLM 提供图数据库的 schema（节点标签、边类型和属性）。LLM 的主要工作是将自然语言翻译为有效的图查询语言（例如 Neo4j 的 Cypher，或 Gremlin）。随后该查询直接在图数据库上执行。数据库返回的精确、事实性结果要么直接呈现给用户，要么传递给第二个 LLM 格式化为自然语言响应。

实现细节与数据流

要成功实现这一点，提示词工程必须严谨。我们不能简单地将查询传递给 LLM；我们必须传递精确的本体。

• Schema 注入：从我们的图数据库中提取 schema（例如 Neo4j 中的 CALL db.schema.visualization()），并将其格式化为提示词中的字符串。
• 少样本提示：向 LLM 提供 5-10 个复杂自然语言问题及其对应的最优 Cypher 查询示例。这有助于减少语法错误。
• 执行与回退：执行生成的 Cypher。如果数据库抛出语法错误，捕获该错误，将其追加到提示词中，并要求 LLM 修正其查询（自我纠正循环）。
• 格式化：将数据库输出的 JSON/表格结果提供给一个更便宜的 LLM（如 mini-gpt 或 Haiku），并提示：“鉴于用户询问了 X，且数据库返回了 Y，请撰写一个礼貌的回复。”

优缺点

• 零幻觉检索：检索是 100% 确定性的，就像使用 SQL 查询关系数据库一样。LLM 不会猜测关系；知识图谱已经拥有它们。
• 聚合：这是唯一原生支持计数、求平均和数学聚合的模式（例如，“向 VP John 汇报的工程师的平均薪资是多少？”）。

• 脆弱性（在没有节点和关系嵌入的情况下）：如果用户询问“software developer”，但本体使用的是“Engineer”，严格的 Cypher 查询将返回 null。这通常通过嵌入图节点和关系（向量图搜索）来缓解，允许我们在执行 Cypher 遍历之前通过语义相似性而非精确字符串匹配来找到起始节点。使用这种方法需要谨慎。与 Cypher 不同，语义相似性是非确定性的，并且总是会返回节点，即使它们与查询意图不同（因此是错误的）。
• 无 unstructured context：它只检索显式建模为节点和边的内容。它无法检索描述数据细微差别的文本段落。

何时使用

此模式最适合高度结构化、操作性的知识库，其中答案依赖于精确遍历、计数、聚合或查找最短路径。用户应了解本体，以便有效地查询知识图谱。这可能适用于查询内部 HR 数据库、供应链物流或金融交易网络，这些场景中语义歧义低、精确性重要且用户是领域专家。

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

这种架构反映了这样一个现实：向量数据库和图数据库各有所长，因此可以有效地互补。向量数据库擅长非结构化文本的语义匹配，而图数据库则用于遍历确定性的结构化关系。这种模式及后续模式探索了如何结合两者的能力，为各种查询提供有依据的响应。

在并行混合模式中，系统维护两个独立的数据库：原始非结构化文档块的向量索引，以及提取出的实体和关系的知识图谱。当用户查询到达时，系统同时查询两个数据库。这种方法承认，一个单一的复杂查询通常包含某些部分最适合由确定性图来回答（例如，“收入是多少？”），而另一些部分则更适合由向量数据库来回答（例如，“战略重点是什么？”）。向量数据库检索语义最相似的前K个文档块。同时，图数据库检索相关的子图。来自两个流的结果被合并并注入到LLM的上下文窗口中。

实现细节与数据流

• 双重摄取：当文档被摄取时，它被分块并嵌入到向量数据库中。同时，它通过提取管道来填充图数据库。此外，图节点必须维护一个source_document_id属性。（这种链接允许系统为图事实提供精确的文档引用，并在源文档被删除时安全地删除过时的图节点）。请注意，将source_chunk_ids存储为节点属性可能会导致非常大的数组，因为一个节点实体（例如零件号）可能存在于许多文档中的数百个块中。因此，不建议这样做。
• 查询处理：查询在两个数据库上并发处理。向量流：查询被嵌入，向量数据库检索语义最相似的前K个文档块。图流：从查询中提取实体和关系。系统尝试基于这些实体进行严格的Cypher遍历。如果严格匹配失败，则回退到语义图搜索（直接针对节点/关系嵌入进行搜索），以找到正确的入口节点并提取其1跳或2跳自我图。
• 上下文组装：我们现在有一个文本块列表和一个JSON格式的图关系列表。这些被连接到LLM提示中。对于像“上海港口延误的战略缓解计划是什么，哪些二级供应商受到影响？”这样的查询：

Context from Documents (Vector): [Internal memo detailing alternative routing and inventory buffering strategies for Asian ports]
Context from Knowledge Graph: Shanghai Port -> SHIPS_FOR -> Supplier A -> SUPPLIES_PART -> Microchip X.
Answer the query using the above context.

优缺点

• 高召回率：我们兼得两者之长。如果答案隐藏在段落的细微之处，向量搜索能捕捉到它。如果答案需要连接两个离散的事实，图能捕捉到它。
• 低延迟：由于向量搜索和图搜索并发运行，检索延迟取决于两者中较慢的那个，而不是两者之和。

• Token消耗大：我们向LLM注入了大量上下文。这增加了推理成本，有时可能导致合成器LLM忽略上下文中的细粒度事实或数字。
• 冗余：对于某些查询，从图或向量数据库收集的上下文可能已经足够。并行检索最终会注入冗余并浪费token。

这是通用企业搜索的安全选项。当无法预测用户查询是需要事实性关系数据还是广泛的非结构化上下文时，它很适用。如果查询是语义、关系或两者的混合，并行混合模式是首选。

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

与并行方法不同，顺序混合架构使用一种检索方法的结果来显式地告知和过滤另一种方法。这创建了一个高度聚焦、精确的上下文窗口，减少了并行方法的冗余和高token成本。其第一个变体是图优先RAG。

系统首先查询知识图谱以找到确切的实体关系。如前所述，图节点包含跟踪其source_document_ids的元数据。系统提取这些文档ID，并将它们用作后续向量搜索的硬过滤器。通过这样做，它保证检索到的非结构化文本仅属于那些提及满足查询关系逻辑的实体的文档。

实现细节与数据流

假设查询是“查找 XYZ Corp 供应的所有锂组件的安全警告”。

• 图遍历：系统从查询中找到入口节点（例如，'XYZ Corp'）。然后，使用严格的 Cypher 匹配或基于节点嵌入的回退语义图搜索，遍历关系以找到相关组件：MATCH (c:Company)-[:SUPPLIES]->(p:Component {type: 'Lithium'}) RETURN p.source_document_ids。
• 文档 ID 提取：图数据库返回提及这些特定组件的文档 ID 列表（例如，['DOC-12', 'DOC-45']）。
• 过滤向量搜索：系统现在对用户查询执行向量搜索。但此时对向量数据库应用元数据过滤器：WHERE chunk.document_id IN ['DOC-12', 'DOC-45']。这大幅缩小了搜索空间，聚焦检索并提高上下文的准确性。
• 合成：LLM 仅接收在确切文档中找到的安全警告文本块。就像并行混合模式一样，上下文也可以使用检索到的图关系进行增强，以获得更丰富的上下文。

优缺点

• 有依据的检索：标准向量搜索可能仅因为文本语义相似而返回其他公司供应的锂组件的安全警告。图优先高效地将搜索限制在相关文档上，从而使响应有依据。
• Token 效率：因为我们预先过滤了向量搜索，所以只将高度相关的块注入合成器 LLM。

• 延迟：步骤是顺序的。我们必须等待图查询完成才能开始向量搜索。
• 严格依赖：如果图中缺少 XYZ Corp 与组件之间的边，下游向量搜索将返回空结果，即使向量数据库中有完美的文档。在这种情况下，搜索可以回退到仅全局向量搜索，并提醒用户从引用的来源验证响应。

图优先 RAG 非常适合高度以实体为中心的查询，在这种情况下，您需要在解析文本之前明确地将搜索空间缩小到特定实体组。它不要求图包含每个精确、细微的关系，而是利用图的结构知识作为强大的粗过滤器。这确保下游向量搜索只查看与那些特定实体相关的文档。典型用例可能包括搜索法律文本（隔离与特定子公司相关的文档）和制造业（过滤与特定子组件相关的手册）。

推论：稀疏图架构（成本高效的图优先 RAG）

值得注意的是，采用任何形式的 GraphRAG 的一个主要障碍是使用 LLM 提取密集知识图谱的巨大成本。稀疏图架构是图优先模式的直接推论，旨在缓解这一成本问题。由于图优先 RAG 严重依赖下游向量搜索来处理细微差别，我们实际上不需要密集图来捕获所有关系。系统可以使用快速、确定性的 NLP 技术（如 SpaCy）或较小的 LLM 来构建仅包含最关键、高层实体的“稀疏”骨架图，而不是使用昂贵的 LLM。检索流程与模式 3 相同（遍历稀疏图 -> 过滤向量搜索 -> 合成）。我们完全依赖向量块来填补缺失的上下文，并准确回答基于关系的查询。

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

与前一个模式相反。这种架构承认，有时用户的查询过于宽泛或模糊，无法从严格的图遍历开始。相反，我们首先撒下广泛的语义网，然后使用图来锐化上下文。

系统首先执行标准语义向量搜索，以找到最相关的文档块。然后检查这些特定块，提取其中提到的关键实体，并使用这些实体作为入口点来遍历知识图谱。这引入了关于这些实体的更深层次、多跳上下文，而这些上下文在原始向量块中并不存在。

实现细节和数据流

考虑这样一个查询：“与 Project X 相关的系统性风险有哪些？”

• 语义搜索：系统对查询进行嵌入并在 Vector DB 中搜索，返回 5 个描述 Project X 即时延迟和预算问题的文本块。
• 实体锚定：系统对这 5 个检索到的文本块运行轻量级实体提取器（如快速 LLM 或 SpaCy），以识别其中提到的关键实体。（例如，“Project X”、“Vendor Z”、“Manager Smith”）。
• 图扩展：系统使用这些提取出的实体作为种子节点查询图。同时，通过对图的节点嵌入进行语义图搜索，系统可以优雅地处理轻微的名称不匹配（例如，将文本中的“Vendor Z”匹配到图中的“Vendor Z LLC”）。它检索这些节点的 1 跳和 2 跳邻居，从而发现例如该供应商还为另一个相关项目供应关键组件。
• 综合：将原始文本块加上扩展的关系上下文提供给 LLM，使其能够推断跨多个项目的系统性风险。

优缺点

• 发现未知模式：它擅长发现“未知的未知”。通过从模糊开始，然后通过图进行扩展，它揭示了用户最初认为不相关的联系。
• 对不良模式具有鲁棒性：与图优先方法不同，如果用户的查询与图模式不完全匹配，这种方法更为宽容。节点和关系是从检索到的文本块中提取的。

• 顺序延迟：同样，我们连续运行两个检索步骤。
• 上下文膨胀：从多个种子节点扩展图可能很快导致数千条不相关的边。我们需要将扩展范围限制在最重要的实体和关系上。

最适合广泛、开放式和语义化的查询，其中初始意图是模糊的，但需要后续的关系上下文来支撑最终答案。适用于取证分析、调查性新闻和深度研究应用。

模式 5：自适应路由代理

正如上述 4 种模式所示，每种模式都有其优势，为每个查询硬编码单一检索路径并非最优方法。自适应路由代理在管道的最前端引入了一个决策层。

一个智能路由代理（可以是快速 LLM 或微调的分类模型）分析用户传入的查询。它评估查询的意图、实体密度和关系复杂性，然后动态地将其路由到最优的架构路径（Text-to-Cypher、Vector-Only、Graph-First、Vector-First 或 Parallel Hybrid）。

实现细节和数据流

为了在不增加太多延迟的情况下实现路由代理，我们可以使用更小、更快的模型（如 gpt-mini、gemini-flash 等）。

• 路由提示：向 LLM 提供一个系统提示，概述可用的工具/管道及其具体用例。text 你是一个查询路由器。分析用户的查询并输出一个包含要使用的“pipeline”的 JSON 对象。- 如果查询要求计数、平均值或特定命名实体之间的精确关系，请使用“cypher”。- 如果查询要求简单解释、摘要或不需要精确事实关系的广泛概念理解，请使用“vector”。- 如果查询要求与满足特定关系标准的实体相关的文档，请使用“graph_first”。- 如果查询意图模糊但需要发现未知联系或文本中实体的多跳上下文，请使用“vector_first”。- 如果查询高度复杂、多面，或者不确定答案需要严格的事实数据还是广泛的语义上下文，请使用“parallel_hybrid”。
• 执行：路由器输出决策。编排层（例如 LangChain 或自定义 Python）捕获此 JSON 并仅执行选定的管道。

• 成本与延迟优化：通过将简单的语义查询或实体/关系查询路由到廉价、快速的仅向量或Text-to-Cypher流水线，我们节省了使用大上下文进行双重检索的成本和延迟。

• 路由器开销：我们在每个查询的开头添加了一次LLM调用。这为查询增加了一点延迟和成本。
• 误分类：路由器需要强大的提示词和充分的测试来避免误分类。如果路由器误解了查询，它会将查询发送到一个几乎肯定无法正确回答的流水线。

这种模式适用于面向用户的企业聊天机器人、通用搜索栏，或任何用户查询在结构和意图上差异很大的应用。如果我们无法预测用户会问什么，就必须使用路由器。

模式6：Agentic GraphRAG

第6个也是最后一个模式是Agentic GraphRAG。该模式不采用单一的、预先确定的检索过程，而是使用自主智能体与图动态交互。

给定一个复杂查询，自主智能体配备了与图数据库和向量数据库交互的工具。它可能首先在图谱中识别一个起始节点，执行查询以查看其邻居。它评估这个中间上下文并决定：“我需要沿着这条边进一步遍历，还是应该使用这个节点的source_document_id来读取向量数据库中的非结构化文本？”智能体在结构化关系和非结构化文本之间迭代导航，收集线索，如果遇到死胡同则回溯，直到形成完整的答案。

实现细节与数据流

这需要像LangGraph或AutoGen这样强大的智能体框架。

• 工具配置：智能体被赋予多个工具，例如query_graph(cypher_statement)和search_documents(semantic_query, document_id_filter)。
• ReAct循环：智能体在推理-行动-观察循环中运行。它推理需要找到什么，通过查询图或向量数据库来行动，观察结果，然后重复。
• 记忆：智能体维护一个“草稿本”，记录其在遍历路径中发现的事实。

优缺点

• 无界推理：它有可能回答需要不可预测遍历路径的极其复杂的问题，这是之前讨论的静态流水线无法做到的。
• 自我纠正：如果智能体查询了错误的节点，它可以意识到自己的错误并尝试不同的路径。

• 高延迟：智能体可能需要5、10或20次顺序LLM调用来回答单个问题。这意味着响应时间以分钟而非秒计。
• 成本：无界循环可能意味着无界的token使用量。一种潜在的优化是自适应模型路由，即每次LLM调用都被动态定向到适合该特定步骤复杂度的模型。

何时使用它

Agentic GraphRAG 严格保留用于离线、复杂、开放式的分析查询，这些查询需要深度的多步推理。它非常适合研究人员提出这样的问题：“调查产品 Y 在所有三级供应商中的供应链脆弱性，并总结地缘政治风险。”它通常不适合实时用户聊天机器人。

自定义架构 vs. Microsoft 的 GraphRAG

一个常见的比较点是 Microsoft 的 GraphRAG 框架。它代表了一种与我们上面讨论的基于遍历的架构不同的范式。

Microsoft 的方法重点在于构建语料库的结构化、分层表示。在摄取过程中，它从源文档中提取实体和关系，使用诸如 Leiden 之类的算法应用分层社区检测，并使用 LLM 生成总结这些社区的报告。

这种设计对于全局性问题尤其相关。Global Search 在 map-reduce 过程中使用这些预生成的社区报告来回答诸如“这个数据集中的主要主题是什么？”之类的问题。它不是尝试检索几个语义相似的块，而是可以跨整个语料库的摘要结构进行推理。

还有 Local Search，它专为更具体、以实体为中心的问题而设计。它结合了相关的图实体、关系、社区信息以及原始文档中的相关文本。DRIFT Search 进一步将全局社区信息与局部探索结合起来。

这是一种更广泛的分层架构，其中社区报告对于全局推理尤为重要。对于高度局部化的关系型问题，例如“John 向谁汇报？”，更简单的 Graph-First 或 Text-to-Cypher 方法可能更直接，并且根据数据和查询工作负载，可能成本更低。

总之，Microsoft 的实现尤其以其对全局语料库级推理和分层摘要的强调而与众不同，而不是作为适用于每种关系型 RAG 问题的通用解决方案。

实施中的挑战与最佳实践

与任何工具和架构一样，知识图谱和 GraphRAG 也存在一些众所周知的挑战。下面，我将指出关键挑战以及应对它们的最佳实践。

挑战 1：密集抽取的成本

正如稀疏图推论（模式 3）中所强调的，运行 LLM 从数 GB 文本中提取节点和边是相当昂贵的。

最佳实践：从稀疏图开始。使用传统 NLP（SpaCy、GLiNER）来映射数据的骨架结构。仅对最关键、高价值的文档部署密集的 LLM 提取。对于其余部分，依赖元数据连接，让 Vector RAG 处理繁重的工作。

挑战 2：本体漂移

如果我们今天使用 Company 和 Employee 模式提取数据，而下个月决定它应该是 Organization 和 Staff，图就会变成一个碎片化的烂摊子。未来，插入新文档会成为一项挑战，需要仔细评估实际存在哪些节点和关系以及它们的名称。

最佳实践：将本体视为生产数据库模式。它需要版本控制和严格的治理。从最小化、严格的本体开始。使用 LLM 进行提取时，在提示中严格提供模式并使用结构化输出（JSON 模式或函数调用）来强制合规会有所帮助。应限制 LLM 即时发明新的节点标签。

挑战 3：图维护与同步

在向量数据库中，更新文档很容易：删除旧块并嵌入新块。在图中，删除文档意味着找到仅由该文档生成的每个节点和边并删除它们，同时不破坏与其他有效文档共享的节点。

最佳实践：实现严格的血缘追踪。图数据库中的每个节点和边都必须包含一个 source_document_ids 数组属性。当文档被删除时，查询图中包含该 ID 的所有元素。从数组中移除该 ID。如果数组变为空，则删除该节点/边。

挑战 4：评估检索路径

标准 RAG 评估框架（如 Ragas）评估最终答案。但在 GraphRAG 中，如果答案错误，我们需要知道是向量搜索失败、图遍历失败，还是路由器代理做出了错误决策。

最佳实践：在管道中构建自定义遥测。记录每个中间步骤的输出。使用 LLM-as-a-judge 独立于最终答案生成，明确评估 Text-to-Cypher 管道生成的 Cypher。

结论

GraphRAG 代表了构建 AI 系统方式的范式转变。向量 RAG 使文本的语义含义能够被数值化编码为嵌入，从而使语义相似性搜索成为可能。知识图谱则将文本视为一个相互连接的知识网络。两者共同代表了同一知识存储的不同方面，在从文本中挖掘洞见时相互补充。

本文的目标是证明实现 GraphRAG 并非只有一种方式。选择不再是要不要使用图，而是哪种架构模式——无论是并行混合、自适应路由，还是顺序图优先——最适合用例的独特需求、延迟和预算约束。

这些架构模式可以帮助从业者构建不仅能找到相似文档，还能对企业数据的关联维度进行推理的检索系统。

延伸阅读

Agentic GraphRAG 可以决定下一步做什么。但谁来决定应该由哪个模型来做？

多智能体工作流中的每一步并不都需要相同级别的推理能力。将每次调用都路由到最强大的模型会迅速推高推理成本。

如果系统能够动态选择最适合每一步的模型呢？

我在《使用自适应模型路由优化多智能体系统中的 LLM 推理成本》一文中探讨了这种方法。

欢迎在 www.linkedin.com/in/partha-sarkar-lets-talk-AI 与我联系并分享您的评论。

本文使用的图片由 Google Gemini 生成。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Towards Data Science

原创地址：https://towardsdatascience.com/graphrag-a-practitioners-guide-to-6-advanced-architectural-patterns/