1. ConnectionConfig
ConnectionConfig is a dataclass that defines how the SDK connects to a FalkorDB instance. It is passed to GraphRAG or used to create a FalkorDBConnection directly.
Fields
Creating from a URL
ConnectionConfig.from_url() parses a redis:// URL and returns a ConnectionConfig:
redis://[user:pass@]host[:port][/db]. Any keyword argument overrides the value parsed from the URL.
Passing to GraphRAG
You can pass either aConnectionConfig or a pre-built FalkorDBConnection:
Retry Behavior
Queries are retried up toretry_count times with linear backoff (retry_delay * attempt_number). Non-transient errors — those containing "already indexed", "already exists", or "unknown index" — are raised immediately without retrying.
2. LLM Providers
The SDK defines an abstractLLMInterface base class. All LLM providers must implement invoke() for synchronous calls. Async calls (ainvoke) default to running invoke in a thread pool but can be overridden for true async support.
Common Parameters
TheLLMInterface base class accepts:
LiteLLM (Recommended)
LiteLLM supports 100+ LLM providers through a unified interface. Install withpip install graphrag-sdk[litellm].
OpenRouter
OpenRouter provides access to many models through a single API. Install withpip install graphrag-sdk[openrouter].
Azure OpenAI via Environment Variables
When using LiteLLM with Azure, the following environment variables are recognized:Custom LLM Provider
Implement theLLMInterface abstract class:
3. Embedder Providers
The SDK defines an abstractEmbedder base class with embed_query() (single text) and embed_documents() (batch). Batch embedding is critical for performance.
Performance Note: Batch Embedding
Individual embedding calls to Azure OpenAI take approximately 0.22 seconds each. A batch of 500 texts takes approximately 8 seconds. Always use batch embedding (embed_documents / aembed_documents) rather than looping over embed_query.
LiteLLMEmbedder
Supports OpenAI, Azure, Cohere, and other embedding models via LiteLLM.
For Azure OpenAI, set
batch_size=500 to stay within the API rate limits. The default of 2048 works well for OpenAI’s direct API.
OpenRouterEmbedder
Custom Embedder
Implement theEmbedder abstract class:
aembed_query and aembed_documents if your provider supports true async. The defaults run the sync methods in a thread pool via asyncio.to_thread.
Binary-Split Error Recovery
BothLiteLLMEmbedder and OpenRouterEmbedder implement binary-split error recovery for batch embedding. If a batch fails with a transient error, the batch is split in half and each half is retried recursively. Non-transient errors (401, 403, authentication failures) are raised immediately.
4. GraphSchema
GraphSchema defines the structure of your knowledge graph. It constrains LLM extraction and powers the pruning step that filters non-conforming data.
Components
EntityType — defines a node type:
RelationType — defines a relationship type:
PropertyType — defines a property on a node or relationship:
Example Schema Definition
RelationType.patterns entry is a (source_label, target_label) tuple.
An empty patterns list means the relation is allowed between any entity types.
Open Schema Mode
If no entity types or relation types are defined (emptyGraphSchema()), the extraction operates in open-schema mode and the pruning step is skipped. This lets the LLM extract any entities and relationships it finds.
5. Pipeline Tuning
Chunking Parameters
FixedSizeChunking splits text into fixed-size character windows with overlap.
Extraction Strategy Parameters
GraphExtraction — composable 2-step extraction (GLiNER NER + LLM relationship extraction):
Built-in entity extractors:
Custom Entity Types
Override the default 11 entity types with your own domain-specific ontology:schema.entities > entity_types param > defaults (Person, Organization, Technology, Product, Location, Date, Event, Concept, Law, Dataset, Method).
LLM Concurrency
TheLLMInterface.max_concurrency parameter (default: 12) controls how many LLM calls run in parallel during abatch_invoke(). Set it lower to avoid rate limits:
GraphExtraction, you can also pass max_concurrency directly:
6. Retrieval Tuning
MultiPathRetrieval
MultiPathRetrieval is the default retrieval strategy. It combines multiple search paths with cosine reranking.
Retrieval Pipeline (9 Steps)
The retrieval pipeline proceeds as follows:- Keyword extraction — stopword filtering + LLM proper-noun extraction.
- Embed question — single embedding API call for the query.
- RELATES edge vector search — finds fact strings and entity entry points via edge embeddings.
- Entity discovery (2 paths) — Cypher
CONTAINSon entity names + fulltext search on the__Entity__index. Merged with entities from step 3. - Relationship expansion — 1-hop (top 15 entities, limit 150) + 2-hop (top 5 entities, limit 25) traversal of RELATES edges.
- Chunk retrieval (4 paths) — fulltext search, vector search, MENTIONED_IN traversal, and 2-hop entity-to-neighbor-to-chunk traversal.
- Source document names — batch-fetch document paths via PART_OF edges.
- Cosine reranking — batch-embed candidate chunks and sort by cosine similarity to the query vector.
- Context assembly — structured sections: hint, entities, relationships, facts, passages.
Overriding the Default Strategy
Pass a custom strategy to individual queries or set it as the default:7. Post-Ingestion
After all documents have been ingested, run post-ingestion steps to deduplicate entities, backfill embeddings, and ensure all indexes exist.finalize() — All-In-One
The recommended approach is to call finalize() after all ingestion is complete. It bundles four steps in order:
deduplicate_entities()— global exact-name deduplication.backfill_entity_embeddings()— embed entity names for vector search.embed_relationships()— embed fact text on RELATES edges.ensure_indices()— create all 5 standard indexes (idempotent).
deduplicate_entities() — Entity Deduplication
Call this when you need fine-grained control over deduplication.
Phase 1 (always runs): Exact name match. Groups entities by normalized name (lowercase, stripped) and label to prevent cross-type merging. Keeps the entity with the longest description as the survivor. Remaps all RELATES and MENTIONED_IN edges from duplicates to the survivor, then deletes the duplicate nodes.
Phase 2 (optional,
fuzzy=True): Embedding-based match. Re-fetches all surviving entities, batch-embeds their names, computes pairwise cosine similarity in memory-efficient blocks (1000 entities per block), and merges near-duplicates above the threshold.
backfill_entity_embeddings() — Entity Vector Backfill
Embeds __Entity__ nodes that are missing embeddings. Queries entities where embedding IS NULL, batch-embeds the entity name, and stores vectors. Safe for incremental runs.
embed_relationships() — RELATES Edge Embeddings
Batch-embeds all RELATES edges that have a fact property but are missing embeddings. These edge embeddings power the RELATES vector search path in retrieval.
ensure_indices() — Index Creation
Creates all standard indexes (idempotent — safe to call repeatedly):
ensure_indices() is called automatically after each ingest() call. The finalize() method resets the internal _indices_ensured flag and re-runs it to catch any newly needed indexes.
When to Call Each
Do not call
backfill_entity_embeddings() inside an ingestion loop (i.e., after each document). It re-scans all entities and is slow when called repeatedly. Instead, ingest all documents first, then call finalize() once.