Skip to main content
GraphRAG SDK v2 follows a strategy-based pipeline architecture. Every algorithmic concern is an abstract base class (ABC) with swappable implementations. The system has two main flows: ingestion (document to knowledge graph) and retrieval (question to answer).

Design Principles

  • Strategy Modularity — Every pipeline step is an ABC. Swap any implementation without touching other code.
  • Zero-Loss Data — Full provenance chain from raw text to graph nodes (Document -> Chunk -> Entity).
  • Production Latency — Async-first, connection pooling, batched writes, parallel pipeline steps.
  • Simplicity — Single entry point (GraphRAG), flat package structure, no meta-programming.

Ingestion Pipeline

The ingestion pipeline transforms documents into a knowledge graph in 9 steps. Steps 1-7 run sequentially (each depends on the previous), steps 8-9 run in parallel.

Step-by-Step

Data Flow

Graph Schema

The knowledge graph contains these node types and edge types:

Node Labels

Edge Types

All LLM-extracted relationships use the single RELATES edge type. The original relationship type (e.g. WORKS_AT, LOCATED_IN) is preserved as the rel_type property on the edge. A fact property stores a human-readable fact string for embedding.

Post-ingestion: Entity Deduplication

Entity deduplication is handled post-ingestion via deduplicate_entities() rather than during the pipeline. This allows ingesting multiple documents independently, then deduplicating globally. The method groups entities by (normalized name, label) to prevent cross-type merging (e.g. Person “Paris” and Location “Paris” remain separate).

Retrieval Flow

The retrieval system answers questions by searching the knowledge graph through multiple paths, then generating an answer with the LLM.

MultiPathRetrieval Parameters

Storage Layer

GraphStore

All graph writes go through GraphStore, which provides:
  • Batched UNWIND upserts — 500 nodes/relationships per batch
  • Label hints — relationship MATCH queries use label hints (e.g., MENTIONED_IN matches __Entity__ -> Chunk) for faster lookups
  • Per-item fallback — if a batch fails, retries individual items
  • None-id guard — filters out entities with None/empty IDs (bad LLM extraction)

VectorStore

Vector operations go through VectorStore:
  • Index creationCREATE VECTOR INDEX for Chunk and Entity embeddings, plus RELATES edge embeddings
  • Fulltext index — for keyword search on chunk text and entity names
  • Batched embedding — embeds texts in bulk, stores via UNWIND
  • Searchdb.idx.vector.queryNodes for similarity search

Extending the SDK

To add a custom strategy, subclass the relevant ABC:
Then pass it to ingest():
The same pattern applies to all 6 strategy ABCs: LoaderStrategy, ChunkingStrategy, ExtractionStrategy, ResolutionStrategy, RetrievalStrategy, RerankingStrategy.

Deep Dives

Each subsystem has a dedicated document with step-by-step explanations:
  • Ingestion Pipeline — the 9-step pipeline from document to knowledge graph
  • Extraction — the 2-step hybrid extraction process (NER + LLM)
  • Graph Schema — how the knowledge graph is structured in FalkorDB
  • Storage — GraphStore, VectorStore, and EntityDeduplicator internals
  • Retrieval — the multi-path retrieval system that answers questions