67 — Graph RAG / Knowledge Graphs

Concept overview

Graph RAG uses an explicit relationship representation to guide retrieval or synthesis. A knowledge graph can represent suppliers, facilities, products, incidents, and their connections; linked source passages provide the evidence behind each node or edge. Some GraphRAG approaches additionally build community summaries for corpus-wide questions. These are design choices, not a single interchangeable algorithm.

The graph is a derived evidence structure, not unquestionable truth. Entity resolution, relation extraction, temporal validity, and provenance determine its usefulness. A graph traversal can expose a possible path, but the answer must distinguish asserted relationships from inferred connections and must respect permissions on every contributing source.

Why it matters in production

Proof of concept

A prototype models one narrow relationship question and manually checks extracted entities and edges.

Production

Production attaches provenance, confidence, validity intervals, and access metadata while evaluating both extraction and retrieval.

Enterprise scale

Enterprise scale requires incremental graph updates, entity merge governance, traversal limits, and recomputation rules for summaries affected by source changes.

Architecture components

Entity resolver

Maps mentions to stable identities while preserving ambiguous matches.

Relation extractor

Produces typed edges with source evidence and temporal attributes.

Graph store

Supports bounded traversal and relationship filtering.

Passage index

Retrieves original text supporting graph nodes and edges.

Graph-guided retriever

Combines traversal results, source passages, and optional community summaries.

The architecture, mapped

flowchart LR
 D["Supplier reports"] --> X["Entity and relation extraction"]
 X --> G["Temporal knowledge graph"]
 D --> P["Source passage index"]
 Q["Dependency question"] --> T["Bounded graph traversal"]
 G --> T
 T --> E["Evidence fetch"]
 P --> E
 E --> A["Cited relationship answer"]

sequenceDiagram
 participant S as Source registry
 participant X as Extraction pipeline
 participant G as Graph store
 participant R as Retriever
 S->>X: Source revision or deletion
 X->>G: Invalidate dependent edges
 X->>G: Write validated replacement relations
 R->>G: Query at requested validity time
 G-->>R: Paths with current provenance
 R->>S: Fetch authorized supporting passages

Runtime flow

1. 1

   Ingest evidence

   Parse documents and retain immutable source identifiers and access metadata.

2. 2

   Resolve entities

   Link mentions conservatively and quarantine uncertain merges.

3. 3

   Build supported relations

   Store typed edges with evidence, validity, and extraction version.

4. 4

   Plan traversal

   Choose allowed relation types, depth, and temporal scope for the question.

5. 5

   Retrieve supporting passages

   Fetch authorized source text for the selected path or community.

6. 6

   Synthesize with qualifications

   Cite relationships and identify uncertainty instead of presenting inferred edges as established facts.

Tracing a shared upstream dependency

Supply chain · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A manufacturer investigates whether several delayed parts depend on the same upstream processing facility.

The problem

Part-level document search finds separate supplier notes but does not connect their facility references.

Agent requirement

Expose the dependency path with dated evidence and uncertainty.

Architecture

A graph connects suppliers, facilities, and parts; each edge links to an approved source passage.

Runtime

• The question resolves affected part IDs and traverses supplier-to-facility edges.
• The agent fetches supporting notes and reports a shared facility only where the evidence supports it.

Failure scenario

An ambiguous facility name remains two possible entities until reviewed, preventing a false shared-dependency conclusion.

Operational impact

Measure supported-path precision, entity-resolution errors, and evidence freshness; graph density alone is not a quality metric.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Treating extracted edges as facts

Retain source evidence and uncertainty.

Allowing unbounded traversal

Limit depth, relation types, and result cardinality.

Ignoring permissions on summaries

Authorize every contributing source or build scope-specific summaries.

When to choose this pattern

Choose it when

• Use for dependency, ownership, and relationship questions.
• Use when repeated entity connections matter across documents.
• Use for corpus-level synthesis with maintained provenance.

Avoid it when

• Avoid graphs for simple isolated fact lookup.
• Avoid automatic entity merging without quality controls.
• Do not deploy when source relationships cannot be kept current.

Architecture checklist

• Define a narrow graph schema.
• Preserve edge-level provenance.
• Represent ambiguous identities.
• Version temporal relationships.
• Enforce traversal and access limits.
• Evaluate supported paths against expert labels.

Related concepts

• 21 — Authorization-Aware RAG
• 38 — Data Lineage Tracking
• 62 — Hybrid Search (Dense + Sparse)
• 66 — Query Deconstruction / Expansion
• 68 — Time-Weighted Vector Retrieval
• 76 — Multi-Aspect Indexing

Primary references

• Microsoft GraphRAG: Indexing overview