LightRAG: Simple and Fast Retrieval-Augmented Generation

LightRAG provides flexible deployment options by supporting a variety of vector database backends. Developers can choose a database based on their specific requirements for scale, performance, and infrastructure complexity.

Supported databases include:

• ChromaDB: Ideal for simple deployment in development environments.
• Neo4j: A graph database that enables graph-based knowledge representation combined with vector search.
• Milvus: Designed for high-performance vector search at scale for large collections.
• Qdrant: Provides fast similarity search with filtering capabilities for production-ready infrastructure.
• MongoDB Atlas Vector Search: Combines document storage with vector search for unified data management.
• Redis: Offers low-latency, in-memory vector search suitable for real-time applications.
• Built-in Nano-VectorDB: A lightweight, built-in option that eliminates external dependencies, making it perfect for small projects and simple deployments.

The LightRAG documentation is organized into several functional areas:

Deployment and Setup

• InteractiveSetup.md: Using the make env-* wizard for .env and Docker Compose generation.
• DockerDeployment.md: Docker/Docker Compose deployment and GHCR image verification.
• AppleContainerSetup.md: Running the storage stack (Postgres/Neo4j/Milvus) on Apple Silicon without Docker Desktop.
• OfflineDeployment.md: Air-gapped installation instructions.
• MultiSiteDeployment.md: Running isolated instances behind a single reverse proxy.
• FrontendBuildGuide.md: Building the WebUI using Bun/Node.

Server and API

• LightRAG-API-Server.md: Complete guide to startup, configuration, authentication, and REST endpoints.

Document Processing

• FileProcessingPipeline.md: Routing rules, engine parameters, and document lifecycle.
• ParserServiceDeployment.md: Hosting MinerU and docling-serve parsing services.
• ParagraphSemanticChunking.md: Using the Paragraph semantic (P) chunking strategy.
• LightRAGSidecarFormat.md: The *.parsed/ interchange format for multimodal parsers.
• ThirdPartyParser.md: Developing and registering custom parser engines.
• ParserDebugCLI.md: Using python -m lightrag.parser.cli to parse files offline.

Models and Storage

• RoleSpecificLLMConfiguration.md: Configuring LLM/VLM per role (EXTRACT, QUERY, KEYWORD, VLM).
• AsymmetricEmbedding.md: Configuring EMBEDDING_ASYMMETRIC and model prefixes.
• MilvusConfigurationGuide.md: Tuning Milvus via vector_db_storage_cls_kwargs.

LightRAG uses different engines to extract content from files. Choosing the right engine depends on your file formats and whether you want to run extraction locally or via external services.

Important Notes:

• External Engines: For mineru and docling, you must have the service running and configure the corresponding endpoint and token in your environment.
• Custom Formats: If your deployment supports formats outside the baseline (e.g., old Office .doc), you must declare them using MINERU_ADDITIONAL_SUFFIXES or DOCLING_ADDITIONAL_SUFFIXES and then route them via LIGHTRAG_PARSER or filename hints.

LightRAG is a lightweight knowledge graph (KG) RAG framework designed as an efficient alternative to Microsoft GraphRAG. It uses a dual-layer architecture that manages both Knowledge Graphs and vector embeddings simultaneously, bridging the gap between traditional vector-based RAG and graph-based RAG.

Key advantages include:

• Deep Contextual Understanding: Captures complex semantic dependencies between entities via graph structures, making it ideal for vertical domains like law or finance.
• High Efficiency & Low Cost: Avoids inefficient community reports or multi-hop reasoning, significantly reducing LLM calls and latency during indexing and querying.
• Incremental Updates & Partial Deletion: Supports dynamic data environments by allowing efficient updates and deletions of entities and relationships.
• Multimodal Support: Since v1.5, it integrates images, formulas, and tables into the document processing pipeline and query flow via the knowledge graph.
• Flexible Chunking & Parsing: Supports multiple parsing engines (MinerU, Docling, Native) and four chunking strategies: Fixed-length (F), Recursive character (R), Vector semantic (V), and Paragraph semantic (P).

LightRAG utilizes four distinct storage types to manage different aspects of the RAG lifecycle. When configuring LightRAG, you can specify different backend implementations for each type.

Supported Implementations

KV_STORAGE

• JsonKVStorage (default)
• PGKVStorage (Postgres)
• RedisKVStorage (Redis)
• MongoKVStorage (MongoDB)
• OpenSearchKVStorage (OpenSearch)

GRAPH_STORAGE

• NetworkXStorage (default)
• Neo4JStorage (Neo4J)
• PGGraphStorage (PostgreSQL with AGE plugin)
• PGTableGraphStorage (PostgreSQL, plain tables - no AGE/extensions required)
• MemgraphStorage (Memgraph)
• OpenSearchGraphStorage (OpenSearch)

VECTOR_STORAGE

• NanoVectorDBStorage (default)
• PGVectorStorage (Postgres)
• MilvusVectorDBStorage (Milvus)
• FaissVectorDBStorage (Faiss)
• QdrantVectorDBStorage (Qdrant)
• MongoVectorDBStorage (MongoDB)
• OpenSearchVectorDBStorage (OpenSearch)

DOC_STATUS_STORAGE

• JsonDocStatusStorage (default)
• PGDocStatusStorage (Postgres)
• MongoDocStatusStorage (MongoDB)
• OpenSearchDocStatusStorage (OpenSearch)

Note: LightRAG creates tables within an existing database instance, but it does not create the database instance itself. Connection strings should be configured via environment variables as shown in env.example.

LightRAG manages parsing workloads using queue_groups. For every batch, the pipeline creates one queue and one worker group for every unique queue_group identified in the registry.

• Built-in Groups: native, mineru, and docling have worker counts determined by LightRAG instance fields (e.g., max_parallel_parse_native).
• Third-party Dedicated Groups: If you use a unique queue_group name, the worker count is determined by the concurrency value in the ParserSpec that owns that group. Only one spec per group may declare a concurrency value; otherwise, batch startup fails.
• Sharing the Native Pool: If you set queue_group="native", your engine shares the built-in pool. In this mode, your spec-level concurrency value is ignored (and a warning is logged), as the pool size is controlled by the LightRAG instance's max_parallel_parse_native setting.
• Best Practice: External-service engines should use a dedicated queue_group so that slow network requests do not block local, lightweight parsing tasks.

LightRAG uses two orthogonal configuration layers to manage document chunking:

1. process_options: A selector that determines which chunking strategy to use. It uses single-character identifiers:

   • F: Fixed token chunking
   • R: Recursive character chunking
   • V: Semantic vector chunking
   • P: Paragraph semantic chunking

2. chunk_options: A structured dictionary that determines which parameters are used by the selected strategy.

Data Flow & Lifecycle:

• Initialization: LightRAG.__init__ reads environment variables into addon_params["chunker"].
• Enqueuing: When documents are enqueued via apipeline_enqueue_documents, a chunk_options snapshot is frozen for each document. If the caller provides specific chunk_options (via SDK), those are persisted; otherwise, they are assembled from the instance's addon_params.
• Processing: The chunker retrieves the corresponding sub-dictionary from the frozen chunk_options based on the process_options selector and applies the parameters.

/* Mapping of selector to sub-dictionary */
F -> fixed_token
R -> recursive_character
V -> semantic_vector
P -> paragraph_semantic