Advanced Architectural Patterns in GraphRAG

The six patterns and the challenges below follow Partha Sarkar's practitioner guide on Towards Data Science, dated 20 September 2026. Each pattern is summarized in new wording with its trade-offs, and the cards link to documentation, papers and projects for going deeper.

Vector RAG sees a flat world of text chunks. It struggles with questions that need relationships across entities (how a delayed part from one supplier affects a final product), global context, multi-hop reasoning, or numbers aggregated across documents. GraphRAG adds a knowledge graph of entities and relationships so retrieval can follow explicit links as well as semantic similarity.

Every pattern shares four parts: information extraction, where an LLM pulls entities and relationships out of text against a defined ontology (costly); graph storage in a graph database queried with a language such as Cypher, optionally with node and relationship embeddings; a retrieval step, which is where the patterns differ; and generation, where retrieved facts go into the LLM prompt.

The LLM acts as a query translator: given the graph schema and a few example questions, it writes a graph query that runs directly on the database, with a self-correction loop if the query errors. Retrieval is deterministic, and it is the pattern that handles counts and other aggregations natively. It is brittle when user wording does not match the ontology (a vector step to find starting nodes helps but is non-deterministic), and it returns nothing from unstructured text. Best for structured, operational data where users know the domain, such as HR, supply chain or transactions.

The system keeps a vector index of document chunks and a knowledge graph, queries both at the same time and merges the results into one prompt. Graph nodes keep a source document identifier so facts can be cited and stale ones removed. Recall is high and latency is set by the slower branch, but the combined context is token-heavy and often redundant. Best for general enterprise search where you cannot predict whether a question needs relational facts or broad text.

The graph is queried first to find entities that satisfy the question's relational logic; their document identifiers then become hard filters for a vector search, so only relevant documents are read. Context is focused and cheaper, but the steps are sequential and a missing edge in the graph can return nothing (a fallback to unfiltered vector search with a caution helps). Best for entity-centric questions such as legal documents for one subsidiary or manuals for one sub-assembly. A sparse-graph variant cuts extraction cost by building only a skeletal graph of key entities with classic NLP or small models, leaving detail to the vector chunks.

The inverse: a semantic search runs first, entities are extracted from the retrieved chunks and used as seed nodes, and the graph is expanded one or two hops to add relational context. It is tolerant of a poorly matched schema and can surface unexpected connections, but it adds latency and can flood the prompt with edges unless expansion is limited. Best for broad, fuzzy questions in forensic analysis, investigations and deep research.

A small fast model classifies each query by intent, entity density and relational complexity, then sends it down the best path: text-to-Cypher, vector-only, graph-first, vector-first or parallel hybrid. It saves cost and latency on simple questions, but adds a call to every query and a wrong route usually fails, so it needs a strong prompt and testing. Use it when user questions vary widely.

Autonomous agents get tools for both the graph and the vector store, and loop through reason, act and observe: pick a start node, inspect neighbours, read source text, backtrack from dead ends and keep a scratchpad of findings. It can answer questions with unpredictable paths and correct its own mistakes, but may take many sequential model calls (minutes) and unbounded token cost. Reserve it for offline, complex analysis, not real-time chat.

Microsoft's approach is different from the traversal patterns above: it extracts a graph, applies hierarchical community detection (the Leiden algorithm) and has an LLM write summary reports for each community. Global search answers corpus-wide questions such as main themes by running a map-reduce over those reports, local search combines entities, relationships and source text for entity-specific questions, and DRIFT search mixes the two. For simple local questions like who reports to whom, graph-first or text-to-Cypher can be more direct and cheaper.

Dense extraction is expensive: start with a sparse graph using classic NLP and use LLM extraction only on high-value documents. Ontology drift fragments the graph: version and govern the schema like a database schema, give the LLM the schema in the prompt and use structured output. Graph maintenance is hard: record source document identifiers on every node and edge and remove an ID on delete, deleting the element only when none remain. Evaluation must look at the path, not just the answer: log each step and judge the generated Cypher separately.

Open-source starting points. Check each project's activity.

Surveys and methods for going deeper.

Neighbouring pages on this site.