LightRAG: Dual-Level Retrieval over Entities and Relationships

Index entities and relationships

LightRAG extracts entities and relations from text, creates descriptive representations and connects them to source material. Vector matching helps locate relevant graph elements, while graph structure exposes associated entities and relationships.

This introduces more structure than a flat passage index without requiring the exact community-report workflow of GraphRAG. The papers share an external graph representation but organise retrieval differently.

Two levels of query information

The method distinguishes low-level information, such as particular entities and their attributes, from high-level information about relationships or broader themes. A query-processing step extracts information useful to these retrieval routes.

For “Which component connects R7 to charger E2?”, the entity route can focus on R7 and E2, while the relation route can focus on connection or compatibility. For “What caused recurring charging problems?”, higher-level relational information may be more central.

These levels are retrieval mechanisms, not a guarantee that the model correctly understands the user’s intent. An inaccurate keyword or entity extraction can exclude the needed part of the graph before the generator sees it.

Follow a small neighbourhood

Suppose the graph contains R7→uses→adapter A2 and A2→compatible-with→charger E2, with source references on both edges. A query about the connection can retrieve those entities, relationships and supporting text.

The two edges suggest an answer candidate, but their composition needs care. If the second edge applies only to an older revision of A2, the path may not establish current compatibility. Keep versions and conditions attached to the retrieved material.

Compare this with a flat passage hit containing the whole compatibility statement. Graph expansion is useful when the evidence is distributed, but it can add work and ambiguity when one precise passage is sufficient.

A retrieval union needs a budget

Let \(E_q\) be entity-route candidates and \(R_q\) relation-route candidates. A practical context builder must combine and deduplicate them, recover source passages and fit a token budget. The exact ranking and aggregation choices are implementation details that should be documented.

If entity retrieval finds 20 nodes and each expands to ten relationships, a naive neighbourhood can quickly become much larger than the reader’s budget. High-degree nodes such as a common supplier can dominate expansion. Prune by query relevance and retain the evidence needed for the specific relation being answered.

Incremental updates are a consistency problem

LightRAG includes an incremental-update design for incorporating new information. In an application, adding a document is only one update case. Corrections, deletions, entity merges and superseded claims also need explicit treatment.

If a document asserting compatibility is withdrawn, its derived edge and description must be removed or revised unless other sources still support them. A vector index that deletes only the source chunk can leave the same claim accessible through graph text.

Track which documents support each entity description and relation. Recompute affected derived material and test that removed facts no longer appear through an alternative retrieval route.

Evaluate the claimed tradeoff

Measure entity-specific questions, relation questions and broad synthesis questions separately. Compare low-level retrieval alone, high-level retrieval alone and their combination. Keep corpus, generator, prompt budget and evaluation questions fixed where possible.

Report graph-build tokens, index size, update cost, retrieval latency and answer support. A method described as simple or fast in a paper can behave differently with dense graphs, noisy extraction or highly dynamic documents.

Interpret results through evidence quality

A graph route can improve evidence coverage while lowering source precision. A faster update can preserve stale derived descriptions. These are measurable tradeoffs, not reasons to accept or reject graph retrieval in general.

Use provenance checks from citation evaluation and a document-change test suite. The strongest demonstration is a supported answer that changes correctly when the relevant source changes, without acquiring unrelated errors elsewhere.

References

1. Guo et al. LightRAG: Simple and Fast Retrieval-Augmented Generation. Preprint, 2024.
2. Edge et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Preprint, 2024.
3. Sarthi et al. RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval. ICLR, 2024.