Yash DabhadeAI Engineer

← Writing

LightRAG: Graph RAG Without the Graph-Sized Bill

GraphRAG is powerful but slow and expensive to build and update. LightRAG keeps the knowledge graph, drops the community summaries, and retrieves at two levels — specific entities and broad themes — at a fraction of the cost.

14 Mar 2026 · 3 min read · RAG · Knowledge graphs

After my GraphRAG post, the most common reply was some version of: "Love the idea. Tried it. The indexing bill made my manager cry." Fair. GraphRAG pays for global understanding with an LLM call for every community report, and pays again every time the corpus changes.

LightRAG (Guo et al., HKU, 2024) asks a pragmatic question: how much of the graph benefit can we keep if we throw away the expensive parts? Quite a lot, it turns out.

GraphRAG is a printed encyclopedia: beautiful, comprehensive, reprinted for every correction. LightRAG is a well-kept wiki: good enough structure, edited in place.

The Core Idea in One Diagram

documents → LLM extracts entities + relationships → key-value profiles for each node and edge → vector index over entities / vector index over relationships / vector index over chunks → knowledge graph + indexes
LightRAG indexing. No community detection, no community reports.

Like GraphRAG, it extracts entities and relationships with an LLM. Unlike GraphRAG, it stops there. Each entity and relationship gets a short key-value profile (a searchable key and a description), and those profiles are embedded so they can be found with vector search.

Dual-Level Retrieval: The Clever Part

Questions come in two flavours. "Who maintains the payments service?" is about a specific thing. "How does our team handle reliability?" is about a theme. LightRAG extracts two kinds of keywords from every question and searches for each differently.

question → LLM extracts keywords → low-level keywords → match entities / high-level keywords → match relationships / themes → expand to one-hop neighbours → gather entity + relation descriptions + source chunks → LLM answer
Low-level retrieval is precise; high-level retrieval is broad. Combining both covers most question types.
  • Low-level (local): specific names, systems, terms → find matching entity nodes, pull their neighbours and source text.
  • High-level (global): abstract concepts → find matching relationships, which carry thematic descriptions across many entities.
  • Neighbour expansion: include one-hop neighbours so multi-hop context comes along for free.

Analogy: you walk into a bookshop and say, "Something by Murakami, but also I'm in the mood for magical realism in general." A good bookseller takes you to the M shelf and to the genre table. That is dual-level retrieval.

Incremental Updates: Why Teams Actually Adopt It

This is LightRAG's real selling point in production. When new documents arrive, it extracts a small graph from them and merges it into the existing one — union the nodes and edges, update descriptions. No re-clustering, no regenerating hundreds of community reports.

new document → extract mini-graph → merge nodes + edges into existing graph → embed only the new / changed profiles → ready to query
Incremental update: cost proportional to the new data, not the whole corpus.

Query Modes

  • naive — plain vector RAG over chunks. The baseline, useful for comparison.
  • local — low-level retrieval centred on entities.
  • global — high-level retrieval centred on relationships.
  • hybrid — local + global combined.
  • mix — graph retrieval plus vector chunk retrieval together. In my experience the most robust default.

GraphRAG vs LightRAG, Honestly

LightRAG Wins On

  • Indexing cost and speed — no community reports.
  • Query cost — one keyword-extraction call plus retrieval, instead of map-reduce over many reports.
  • Updates — incremental merge instead of rebuild.
  • Simplicity — easier to run, easier to reason about.

GraphRAG Still Wins On

  • True corpus-wide summarisation. If the question is literally "summarise every theme in 10,000 documents", pre-written community reports are hard to beat.
  • Hierarchy — explicit levels from broad to narrow, useful for exploration UIs.

What I Learned Running It

  1. Entity extraction quality is everything. Spend time on the extraction prompt and entity types for your domain.
  2. Deduplicate aggressively: "K8s", "Kubernetes" and "kubernetes cluster" should be one node.
  3. Use mix mode as default, and log which mode would have answered best — that data tells you whether the graph earns its keep.
  4. Keep a plain hybrid RAG baseline running. On simple factual questions it is often just as good and cheaper.
  5. Evaluate on multi-hop and theme questions specifically; that is where the graph should win. If it does not, you do not need it.
Graphs are not magic. They are an index. Pick them when your questions are about relationships.

LightRAG is the version of graph RAG I would actually recommend a small team try first. Cheap to build, cheap to update, and it covers the questions vector RAG quietly fails on.