graphrag

Extracts named entities, relationships, and attributes from documents using LLM-based prompting with configurable extraction schemas. The system uses a workflow-based pipeline architecture that chains LLM calls through a task execution engine, supporting multiple LLM providers (OpenAI, Azure OpenAI, Anthropic, Ollama) with built-in rate limiting, retry strategies, and token-aware batching. Extracted entities and relationships are structured into a knowledge graph schema with configurable entity types, relationship types, and attributes.

Detects communities (clusters of densely-connected entities) within the extracted knowledge graph using graph algorithms, then organizes them hierarchically into levels for multi-scale analysis. The system applies community detection algorithms to partition the graph, generates summaries for each community at each hierarchy level, and stores these as 'community reports' that serve as intermediate representations for query-time reasoning. This enables both local (entity-neighborhood) and global (community-level) search strategies.

Constructs LLM prompts by combining retrieved context (entities, relationships, community reports) with query information and response instructions. The system extracts entities from queries, retrieves relevant context from the knowledge graph, ranks context by relevance, and assembles prompts that include both structured context (entity descriptions, relationships) and unstructured context (text chunks). Context building strategies differ between Global Search (community-level context), Local Search (entity-neighborhood context), and DRIFT Search (combined context).

Implements provider-agnostic rate limiting, exponential backoff retry logic, and fault tolerance mechanisms for LLM API calls. The system tracks token usage and API call rates, enforces per-provider rate limits, retries failed calls with exponential backoff, and handles transient failures gracefully. This enables reliable indexing and querying even with unreliable network conditions or rate-limited APIs. Rate limiting is configurable per provider and per operation type.

Provides a command-line interface for all major GraphRAG operations: initializing new indexes, running indexing pipelines, executing queries, tuning prompts, and updating existing indexes. The CLI supports both interactive and batch modes, with progress reporting, error handling, and result formatting. Commands are organized hierarchically (e.g., 'graphrag index', 'graphrag query', 'graphrag prompt-tune') and support configuration file overrides through command-line arguments.

Implements multi-level caching to reduce redundant LLM API calls and embedding computations. The system caches LLM responses by prompt hash, caches embeddings by text hash, and supports both in-memory and persistent (file-based or database) caching. Cache hits avoid expensive API calls, significantly reducing indexing time and cost for repeated operations. Cache invalidation is based on content hashing, enabling safe cache reuse across runs.

Implements three distinct search strategies that can be selected or combined at query time: (1) Global Search uses community reports and hierarchical summaries for high-level reasoning over the entire dataset, (2) Local Search retrieves entity neighborhoods and relationships for detailed reasoning about specific entities, and (3) DRIFT Search (Dynamic Retrieval In-context Fusion Technique) combines both strategies with adaptive context selection. Each strategy uses vector embeddings for semantic matching, entity extraction from queries, and context building to construct LLM prompts with relevant information.

Provides a modular, configuration-driven indexing pipeline that orchestrates document loading, chunking, entity/relationship extraction, community detection, embedding generation, and graph finalization. The system uses a factory pattern for LLM providers (OpenAI, Azure OpenAI, Anthropic, Ollama), vector stores (LanceDB, Azure AI Search, Cosmos DB), and storage backends (local file system, Azure Blob Storage, in-memory). Configuration is managed through YAML files with environment variable overrides, enabling environment-specific setup without code changes.

Supports updating existing knowledge graphs with new or modified documents without full re-indexing. The system detects which documents have changed, re-extracts entities and relationships for changed documents, updates the knowledge graph with new entities/relationships, and regenerates affected community reports. This avoids redundant processing of unchanged documents while maintaining graph consistency. Incremental updates preserve existing entity IDs and relationships, enabling stable references across index versions.

Generates dense vector embeddings for all text units (documents, entities, relationships, community reports) using configurable embedding models, then stores and indexes these embeddings in a pluggable vector store backend. Supported backends include LanceDB (local/cloud), Azure AI Search (managed), and Cosmos DB (multi-model). The system handles embedding batching, caching, and retrieval with semantic similarity search capabilities. Embeddings enable both entity-level and text-level semantic matching for query-time retrieval.

Provides a system for customizing and versioning prompts used during both indexing (entity extraction, relationship extraction, community report generation) and query stages (context building, response generation). Prompts are stored as template files with variable placeholders, enabling domain-specific customization without code changes. The system supports prompt versioning, A/B testing of different prompts, and prompt tuning workflows to optimize extraction and response quality.

Handles loading documents from various formats (PDF, DOCX, TXT, MD, HTML) and preprocessing them through configurable chunking strategies. The system extracts text from documents, applies language-specific text cleaning, splits documents into overlapping chunks with configurable size and overlap, and preserves document structure metadata (sections, headings, page numbers). Chunking strategies can be token-based, character-based, or semantic, enabling optimization for different document types and LLM context windows.

Defines and enforces a schema for the knowledge graph that specifies allowed entity types, relationship types, and their attributes. The schema is defined through configuration files and used to validate extracted entities and relationships during indexing. The system supports custom entity and relationship types, attribute definitions with type constraints, and relationship cardinality rules. Schema validation ensures consistency and enables downstream applications to rely on predictable graph structure.

Supports querying across multiple GraphRAG indexes simultaneously, enabling federated search over multiple knowledge graphs or document collections. The system routes queries to appropriate indexes based on query characteristics, aggregates results from multiple indexes, and deduplicates/ranks results across indexes. This enables scenarios like searching across multiple departments' knowledge bases, multiple versions of a dataset, or multiple document collections with different schemas.