LightRAG

• Graph-based RAG built around a dual-level retrieval scheme — combines specific-entity (“low-level”) and topic-level (“high-level”) keys in the same KG
• Paper: LightRAG: Simple and Fast Retrieval-Augmented Generation
  • EMNLP 2025 Findings
• Github: HKUDS/LightRAG
  • 36.2k stars

• LightRAG: Simple and Fast Alternative to GraphRAG for Legal Doc Analysis

• Two main complaints about earlier graph-RAGs (GraphRAG in particular)
  • Heavy community detection + hierarchical LLM summarization at index time → expensive
  • Single retrieval granularity — either fine entity lookup or coarse community summary, not both
• LightRAG’s answer
  • Build a flat entity-relation KG (no communities, no hierarchy)
  • Attach two index keys per node/edge — one fine, one thematic
  • At query time issue two retrievals over those keys and merge
• Result: GraphRAG-style multi-hop quality at a fraction of the indexing cost, plus incremental updates by graph union

The pipeline is formalized as $\hat{D} = (\hat{V}, \hat{E}) = \text{Dedupe} \circ \text{Prof}(V, E)$ — three composed steps.

• Chunk the corpus, then one LLM call per chunk asks the model to emit
  • A list of entities (nodes) with type and short description
  • A list of relationships (edges) between those entities with description
• Per-paper: total LLM calls for this stage ≈ total_tokens / chunk_size — i.e. linear, no overhead beyond plain dense RAG embedding
• Where this differs from HippoRAG 2: HippoRAG 2 splits NER and RE into two calls; LightRAG fuses them into one richer prompt that returns descriptions as well as triples

• LLM-empowered function $P(\cdot)$ produces a (key, value) pair for every node and every edge
  • Node key = entity name (used as fine-grained / low-level index key)
  • Edge keys = multiple LLM-generated index phrases that include “global themes from connected entities” → this is what makes high-level / topical retrieval possible
  • Value = a textual paragraph summarizing the entity or relation, including its description, the names of connected entities, and original passage snippets
• The keys are embedded and stored in a vector DB; the values live in a key-value store (typically JSON)
• This is the step that gives LightRAG its dual granularity — each edge carries both its concrete description and topic-level keys

• Identical entities and relations extracted from different chunks are merged
• Done by name match + LLM-assisted profile consolidation; far less aggressive than the community detection GraphRAG performs
• After this step the graph is much smaller than the raw extraction output and graph operations stay cheap

• New documents $D’$ run through the same φ pipeline → sub-graph $(\hat{V’}, \hat{E’})$
• Final graph = union of node sets and union of edge sets: $\hat{V} \cup \hat{V’}$, $\hat{E} \cup \hat{E’}$
• Deduplication handles overlapping entities; no re-indexing of the original graph required
• Contrasts sharply with GraphRAG (whose community summaries must be partially recomputed)

• An LLM call rewrites the query into two keyword sets
  • $k^{(l)}$ — local / low-level: specific entity mentions (“Pride and Prejudice”, “Jane Austen”)
  • $k^{(g)}$ — global / high-level: themes (“19th-century English literature”, “social class commentary”)

• $k^{(l)}$ → vector search against node keys → matched entities $N_v$
• $k^{(g)}$ → vector search against edge keys → matched relations $N_e$
• Two separate vector indexes, both populated during the Profiling step

• For every matched node/edge, pull in its one-hop neighborhood from the graph
• Formally: include every $v_i \in V$ such that $v_i \in N_v \lor v_i \in N_e$ plus its neighbors
• This is where structural information enters — the graph is used as a navigator over the retrieved seeds, not traversed from scratch

• Concatenate the values (descriptions + original snippets) of all retrieved entities, relations, and neighbor nodes
• Feed to the generator LLM with the original query
• No re-ranking step in vanilla LightRAG (some forks add cross-encoder reranking)

• vs HippoRAG 2 — both are flat KG approaches, but HippoRAG 2 ranks with Personalized PageRank over the whole graph at query time, while LightRAG just does vector lookup + 1-hop expansion. HippoRAG 2 wins on long multi-hop chains; LightRAG is simpler and faster at retrieval
• vs GraphRAG — LightRAG drops the community detection step entirely. Indexing cost ~order of magnitude lower, but you lose the explicit community-summary retrieval path
• vs RAPTOR — RAPTOR builds a summary tree; LightRAG builds an entity graph with topic-tagged edges. RAPTOR has fewer LLM calls but re-processes text up the tree; LightRAG has more calls but each is bounded to one chunk

• On benchmarks from the paper (UltraDomain, mix of agriculture/CS/legal/mix domains) LightRAG outperforms naive RAG, RQ-RAG, HyDE, and GraphRAG on both comprehensiveness and diversity of generated answers
• Incremental-update experiments show graceful integration of new corpora without quality regression on old queries
• Indexing cost is reported as roughly an order of magnitude below GraphRAG on the same corpora