GraphRAG: A Practitioner’s Guide to 6 Advanced Architectural Patterns

GraphRAG：6 种高级架构模式实践指南

Retrieval-Augmented Generation (RAG) is the most widely used LLM use case across organizations. By vectorizing documents and retrieving semantically similar chunks at query time, RAG mitigates hallucinations, grounds responses and bypasses static knowledge cutoffs imposed by model pretraining. 检索增强生成（RAG）是目前各组织中最广泛使用的 LLM 应用场景。通过对文档进行向量化并在查询时检索语义相似的片段，RAG 能够减轻幻觉、为回答提供事实依据，并绕过模型预训练所带来的静态知识截止限制。

However, in a real-life scenario, standard vector-based RAG runs into limitations for complex queries, such as those that require global context, multi-hop reasoning, cross-document aggregation of numerical figures etc. Standard RAG is great at answering explicit, localized queries. But if we ask, “How does a delay in shipping part A from supplier B affect the final assembly of product C?”, it retrieves disconnected chunks based on semantic overlap but completely misses the explicit, deterministic relationships connecting those entities. 然而，在现实场景中，标准的基于向量的 RAG 在处理复杂查询时会遇到局限性，例如需要全局上下文、多跳推理、跨文档数值聚合等查询。标准 RAG 非常擅长回答明确的、局部性的问题。但如果我们问：“供应商 B 延迟交付零件 A 如何影响产品 C 的最终组装？”，它只会根据语义重叠检索出互不关联的片段，却完全忽略了连接这些实体的明确且确定性的关系。

Similarly, for a query such as the trend in revenue across a certain product category for 5 years ending in 2025, it is unlikely to perform cross-document reasoning, fetch the right chunks from the relevant documents for 2021 to 2025 and answer the question correctly. This is because standard vector RAG sees a flat world of document snippets or chunks. 同样，对于“截至 2025 年的 5 年内某产品类别的收入趋势”这类查询，它很难进行跨文档推理，无法从 2021 年到 2025 年的相关文档中提取正确的片段并准确回答问题。这是因为标准向量 RAG 眼中的世界只是扁平的文档片段或块。

The GraphRAG Shift

GraphRAG 的转变

GraphRAG solves this by transitioning from retrieving flat documents to retrieving structured knowledge. It integrates Knowledge Graphs (KGs), where data is stored as Nodes (Entities), Edges (Relationships), and Properties into the RAG pipeline. By doing so, it combines the semantic, fuzzy-matching capabilities of modern LLMs with the structured, deterministic reasoning of KGs. GraphRAG 通过从检索扁平文档转向检索结构化知识解决了这一问题。它将知识图谱（KG）集成到 RAG 流水线中，数据以节点（实体）、边（关系）和属性的形式存储。通过这种方式，它结合了现代 LLM 的语义模糊匹配能力与知识图谱的结构化确定性推理能力。

Instead of explaining the basics of GraphRAG, in this article, let’s look at six distinct architectural patterns of GraphRAG, along with pros, cons and use cases. We will explore how they work, the data flow, visualize the architectures, and exactly when to use them in production. 本文不再赘述 GraphRAG 的基础知识，而是探讨 6 种不同的 GraphRAG 架构模式，以及它们的优缺点和应用场景。我们将深入研究它们的工作原理、数据流、架构可视化，以及在生产环境中何时使用它们。

Core Components of a GraphRAG Pipeline

GraphRAG 流水线的核心组件

Before diving into the architectures, let’s look at the baseline components of any GraphRAG system. Regardless of the advanced routing or retrieval logic we employ, the system will require these foundational pillars: 在深入架构之前，让我们先看看任何 GraphRAG 系统的基准组件。无论我们采用何种高级路由或检索逻辑，系统都需要以下基础支柱：

• Information Extraction: Raw unstructured text is passed through an LLM instructed to perform Named Entity Recognition (NER) and Relationship Extraction. The LLM identifies nodes (e.g., Company, Person) and edges (e.g., WORKS_FOR, SUPPLIES). This step is computationally expensive and requires a well-defined ontology. 信息提取： 原始非结构化文本通过 LLM 进行命名实体识别（NER）和关系提取。LLM 识别节点（如公司、个人）和边（如 WORKS_FOR、SUPPLIES）。这一步计算成本较高，且需要定义良好的本体（Ontology）。
• Graph Storage: The extracted nodes and edges are loaded into a Graph Database (like Neo4j, NebulaGraph, Memgraph etc). These databases use specialized query languages like Cypher to traverse nodes and relationships. In addition, nodes and relationships can be embedded to perform a similarity based search and traversal when exact matching fails to yield results. 图存储： 提取的节点和边被加载到图数据库中（如 Neo4j、NebulaGraph、Memgraph 等）。这些数据库使用 Cypher 等专用查询语言来遍历节点和关系。此外，节点和关系可以进行嵌入（Embedding），以便在精确匹配无法产生结果时进行基于相似性的搜索和遍历。
• Retrieval: The mechanism by which a user query interacts with the graph. As we will see, the architectural patterns diverge significantly in this aspect. 检索： 用户查询与图交互的机制。正如我们将看到的，各种架构模式在这一方面存在显著差异。
• Generation: The retrieved graph data is injected into the LLM’s context window to synthesize the final, grounded response. 生成： 将检索到的图数据注入 LLM 的上下文窗口，以合成最终的、有事实依据的回答。

6 Architectural Patterns of GraphRAG

6 种 GraphRAG 架构模式

The term “GraphRAG” is often used loosely, but in practice, it is an umbrella for several fundamentally different architectural patterns, in several of which a KG is not the only knowledge store. Choosing the right pattern is dependent on user query patterns, system’s cost, latency, and capability. “GraphRAG”一词常被泛用，但在实践中，它涵盖了多种本质上不同的架构模式，其中一些模式中知识图谱并非唯一的知识存储。选择正确的模式取决于用户查询模式、系统成本、延迟和能力需求。

Pattern 1: Text-to-Cypher / Graph Query Generation

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

The most direct and deterministic approach to GraphRAG is the Text-to-Cypher pattern. In this architecture, the LLM acts strictly as a query translator rather than a semantic search engine. GraphRAG 最直接且确定性的方法是 Text-to-Cypher 模式。在这种架构中，LLM 严格充当查询翻译器，而不是语义搜索引擎。

How it Works 工作原理

The user inputs a natural language query. The system provides a LLM with the graph database’s schema (node labels, edge types, and properties) via the system prompt. The LLM’s primary job is to translate the natural language into a valid graph query language (e.g., Cypher for Neo4j, or Gremlin). This query is then executed directly against the graph database. The exact, factual results returned by the database are either presented directly to the user or passed to a second LLM to be formatted into a natural language response. 用户输入自然语言查询。系统通过系统提示词向 LLM 提供图数据库的模式（节点标签、边类型和属性）。LLM 的主要工作是将自然语言翻译成有效的图查询语言（如 Neo4j 的 Cypher 或 Gremlin）。随后，该查询直接在图数据库上执行。数据库返回的精确事实结果要么直接呈现给用户，要么传递给第二个 LLM，格式化为自然语言回答。

Implementation Details and Data Flow 实现细节与数据流

To implement this successfully, the prompt engineering must be rigorous. We cannot simply pass the query to the LLM; we must pass the exact ontology. 为了成功实现这一点，提示词工程必须非常严谨。我们不能简单地将查询传递给 LLM；我们必须传递精确的本体。

• Schema Injection: Extract the schema from our graph DB (e.g., CALL db.schema.visualization() in Neo4j) and format it as a string in the prompt. 模式注入： 从图数据库中提取模式（例如 Neo4j 中的 CALL db.schema.visualization()）并将其格式化为提示词中的字符串。
• Few-Shot Prompting: Provide the LLM with 5-10 examples of complex natural language questions and their corresponding optimal Cypher queries. This helps in reducing syntax errors. 少样本提示（Few-Shot Prompting）： 为 LLM 提供 5-10 个复杂自然语言问题及其对应的最优 Cypher 查询示例。这有助于减少语法错误。
• Execution & Fallback: Execute the generated Cypher. If the database throws a syntax error, catch the error, append it to the prompt, and ask the LLM to fix its query (a self-correction loop). 执行与回退： 执行生成的 Cypher。如果数据库抛出语法错误，捕获该错误，将其附加到提示词中，并要求 LLM 修复其查询（自修正循环）。
• Formatting: Take the JSON/Tabular output from the database and feed it to a cheaper LLM (like a mini-gpt or Haiku) to say, “Given the user asked X, and the database returned Y, write a polite response.” 格式化： 获取数据库的 JSON/表格输出，并将其输入到一个成本更低的 LLM（如 mini-gpt 或 Haiku），要求其：“鉴于用户询问 X，数据库返回 Y，请写一个礼貌的回答。”

Pros and Cons 优缺点

• Pros:

  • Zero Hallucination Retrieval: The retrieval is 100% deterministic just like querying a relational database using SQL. The LLM does not guess the relationships; the KG already has them.
  • Aggregations: This is the only pattern that natively handles counting, averaging, and mathematical aggregations (e.g., “What is the average salary of engineers reporting to VP John?”). 优点：
  • 零幻觉检索： 检索是 100% 确定性的，就像使用 SQL 查询关系数据库一样。LLM 不会猜测关系；知识图谱中已经存在这些关系。
  • 聚合： 这是唯一能原生处理计数、平均值和数学聚合的模式（例如：“向 John 副总裁汇报的工程师的平均工资是多少？”）。

• Cons:

  • Brittleness (Without node and relation embeddings): If the user asks for a “software developer” but the ontology uses “Engineer”, a strict Cypher query will return null. This is often mitigated by embedding the graph nodes and relations (Vector Graph Search), allowing us to find the starting node via semantic similarity rather than an exact string match before executing the Cypher traversal. One needs to be careful with this approach. Unlike the Cypher, semantic similarity is non-deterministic, and will alw… 缺点：
  • 脆弱性（无节点和关系嵌入时）： 如果用户询问“软件开发人员”，但本体中使用的是“工程师”，严格的 Cypher 查询将返回空值。这通常可以通过对图节点和关系进行嵌入（向量图搜索）来缓解，使我们能够在执行 Cypher 遍历之前，通过语义相似性而非精确字符串匹配找到起始节点。这种方法需要谨慎使用。与 Cypher 不同，语义相似性是非确定性的，并且会……