• 学术相关
  • LightRAG
    • 0. Execution Overview
    • 1. High-level Design (Indexing → Retrieval → Generation)
    • 2. Offline Construction: Indexing (Detailed Execution)
    • 3. Online Query: Retrieval (Detailed Execution)
    • 4. Online Generation: Generation (Detailed Execution)
    • 5. Key Design Decisions
    • 6. Evaluation
    • 7. Limitations and Applicability
    • 8. Quick Reference
  • GraphRAG
    • 0. Execution Overview
    • 1. Offline Construction: Knowledge Graph Indexing
    • 2. Online Query: Four Search Modes
    • 3. Online Generation: Map-Reduce Answer Aggregation (Global Search Example)
    • 4. Key Design Decisions
    • 5. Evaluation
    • 6. Limitations and Applicability
    • 7. Quick Reference
    • 相关项目

学术相关

LightRAG

One-sentence positioning: Integrates graph structure into the text indexing and retrieval process, achieving comprehensive answers to complex queries while maintaining retrieval efficiency through a dual-layer retrieval system (low-level entity retrieval + high-level relation retrieval) with graph-vector hybrid representation.

Key innovation: Replaces traditional chunk traversal and pure embedding matching with key-value structures, combining dual-layer query decomposition with one-hop neighbor expansion to support both concrete entity local retrieval and abstract concept global association.

0. Execution Overview

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Offline Phase (one-time construction)
  ├─ ① Text chunking (chunk size = 1200)
  ├─ ② Extract entities and relations (LLM-based)
  ├─ ③ Generate key-value pairs for each entity/relation
  │      - K: words or phrases convenient for retrieval
  │      - V: relevant segments from the original document
  ├─ ④ Deduplication (reduce graph scale)
  └─ ⑤ Build graph structure (nodes = entities, edges = relations)
         ↓
Online Phase (per query)
  ├─ ⑥ Query keyword extraction (intent identification: Low-Level vs High-Level)
  ├─ ⑦ Keyword matching (vector similarity retrieval)
  │      - Low-Level → match entity Nodes
  │      - High-Level → match relation Edges
  ├─ ⑧ Incorporate high-order relatedness (supplement one-hop neighbors)
  └─ ⑨ Concatenate context and generate answer
         ↓
Incremental Update (new data added)
  └─ ⑩ Execute ①~③ on new documents, union with original graph, no full rebuild needed

1. High-level Design (Indexing → Retrieval → Generation)

1.1 Indexing

1.2 Retrieval

1.3 Generation

2. Offline Construction: Indexing (Detailed Execution)

Step 2.1 Text Chunking

Step 2.2 Entity and Relation Extraction

Step 2.3 Key-Value Pair Generation (Core Design)

Why this design? Traditional RAG relies on embedding matching or chunk traversal — the former has low precision, the latter has low efficiency. The key-value structure separates retrieval keywords from original evidence, optimizing retrieval speed while preserving provenance capability.

Step 2.4 Deduplication

Step 2.5 Incremental Update

Comparison with GraphRAG: When new data is added, GraphRAG must decompose existing community structures, incorporate new entities/relations, and then fully rebuild; LightRAG’s union-based incremental update significantly reduces maintenance cost in dynamic environments.

3. Online Query: Retrieval (Detailed Execution)

3.1 Retrieval Mode Overview

LightRAG does not distinguish multiple search modes; instead, it adaptively splits the same retrieval procedure into two layers based on query intent:

3.2 Retrieval Procedure

Step 3.1 Query Keyword Extraction

• Intent identification: Decompose query content into Low-Level (Local) and High-Level (Global) keyword layers
• Key requirement: Extracted keywords must use the original expressions consistent with the query

Step 3.2 Keyword Matching

• Low-Level: Match entity nodes to query keywords via vector similarity retrieval
• High-Level: Match relation edges to query keywords via vector similarity retrieval
• Implementation: Uses nano vector database for vector data management and access

Step 3.3 Incorporating High-Order Relatedness

• Operation: Supplement retrieved nodes/edges with their one-hop neighbors
• Purpose: Complete context, capture implicit associations, improve answer coherence
• Characteristic: Compared to pure vector retrieval, graph-neighbor expansion provides cross-chunk association capability

Why is dual-layer retrieval effective? Traditional RAG only performs local retrieval and cannot answer global questions like “overall trends.” LightRAG maps queries to both entity and relation layers simultaneously, accommodating both concrete facts and abstract associations.

4. Online Generation: Generation (Detailed Execution)

LightRAG’s generation phase is standard:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
User query
    │
    ▼
┌─────────────────┐
│ Query           │  ← Extract Low-Level + High-Level keywords
│ Decomposition   │
│ (Keyword        │
│  Extraction)    │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Vector          │  ← Retrieve matching entity nodes and relation edges
│ Retrieval       │
│ (Keyword        │
│  Matching)      │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Neighbor        │  ← Supplement one-hop neighbors, build subgraph context
│ Expansion       │
│ (High-Order     │
│  Relatedness)   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Context         │  ← Combine entity descriptions, relation descriptions, original segments
│ Assembly        │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ LLM generates   │
│ answer          │
│ (Generation)    │
└─────────────────┘

5. Key Design Decisions

6. Evaluation

6.1 Evaluation Metrics

LLM-as-a-Judge four-dimensional scoring:

6.2 Comparative Experimental Setup

Dataset: UltraDomain benchmark (4 subsets, derived from 428 university textbooks, covering 18 domains including Agriculture, Mix, etc.)

Key findings:

• On large datasets and complex linguistic contexts, LightRAG consistently outperforms GraphRAG
• Graph-based RAG systems (LightRAG, GraphRAG) consistently outperform pure chunk-based methods
• LightRAG demonstrates significant advantages on the Diversity metric

6.3 Ablation Study

-Origin finding: The semantic graph in RAG is already sufficient to provide query-needed context; original text may actually introduce irrelevant noise.

7. Limitations and Applicability

Best Applicable Scenarios

• General-purpose RAG scenarios requiring both concrete facts and abstract associations
• Environments with frequent dynamic data updates (incremental update advantage)
• Requirements for retrieval efficiency where GraphRAG-style full rebuild cost is unacceptable
• Local + global hybrid queries on medium-scale document collections

Unsuitable Scenarios

• Complex queries requiring deep multi-hop reasoning (>1 hop) (neighbor expansion only one-hop)
• Scenarios with extremely high demands on entity alignment precision (simple deduplication may be insufficient)
• Pure global semantic understanding on very large document collections (GraphRAG’s community summaries are more advantageous here)

8. Quick Reference

GraphRAG

One-sentence positioning: Uses LLMs to construct a hierarchical knowledge graph from text corpora, then aggregates community summaries via Map-Reduce to answer global questions like “what does the entire dataset discuss.”

Key innovation: Transforms traditional RAG’s “retrieve then generate” into “pre-compute community summaries, then aggregate on demand,” solving the inability of vector RAG to perform global semantic understanding.

0. Execution Overview

1
2
3
4
5
6
7
8
9
10
11
Offline Phase (one-time construction)
  ├─ ① Text chunking
  ├─ ② Entity and relation extraction
  ├─ ③ Knowledge graph construction
  ├─ ④ Graph community detection (hierarchical)
  └─ ⑤ Community summary generation (bottom-up recursive aggregation)
         ↓
Online Phase (per query)
  ├─ ⑥ Load all community summaries at the target level
  ├─ ⑦ Map: Parallelly generate community answers + score
  └─ ⑧ Reduce: Sort by score and merge into global answer

1. Offline Construction: Knowledge Graph Indexing

Step 1.1 Text Chunking

Step 1.2 Entity and Relation Extraction

Self-Reflection (Gleaning loop)

① First extract entities → ② Feed extraction results back to LLM → ③ Force yes/no judgment on “anything missed” → ④ If missed, prompt “MANY entities were missed in the last extraction” to complete

Implementation evolution:

Source code references:

• Loop Prompt: prompts/index/extract_graph.py:129
• Gleaning loop: graph_extractor.py:115-121

Step 1.3 Entity Alignment → Knowledge Graph

Step 1.4 Community Detection (Hierarchical)

Step 1.5 Community Summary Generation (Core Pre-computation)

Why this approach? Traditional RAG retrieves relevant documents at query time; GraphRAG pre-computes “what each cluster of related entities is discussing” offline, making it directly available at query time.

2. Online Query: Four Search Modes

Select mode based on query type:

2.1 Global Search

• Core idea: Map-Reduce architecture, global summarization based on community reports
• Map phase: Independently question each community report, generating local answers (global_search/search.py, using MAP_SYSTEM_PROMPT)
• Reduce phase: Aggregate all local answers to generate the final answer (using REDUCE_SYSTEM_PROMPT)
• Characteristic: Does not rely on vector retrieval; uses the hierarchical community structure to answer top-down

2.2 Local Search

• Core idea: Build context based on entity-relation graph neighborhoods
• Procedure:
  1. Find entities most relevant to the query via vector retrieval (mixed_context.py:map_query_to_entities)
  2. Obtain neighbor relations, descriptions, community reports, text fragments of these entities from the graph
  3. Concatenate into mixed context and pass to LLM for answering
• Characteristic: Leverages graph structure for local diffusion, adding one layer of structured information beyond pure vector retrieval

2.3 DRIFT Search (Dynamic Reasoning Graph Search)

• Core idea: Adds iterative reasoning and exploration on top of Local Search
• Essence: Iteratively enhanced version of Local Search, similar to ReAct pattern, where the LLM autonomously decides the next exploration direction
• Introduced in: v0.4.0 (2024-11-05)

Complete procedure (4 phases):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
User query
    │
    ▼
┌─────────────────────────────────────────────┐
│ Phase 1: Primer (Initialization)            │
│   HyDE hypothesis → Vector retrieval of community reports |
│   LLM generates intermediate answer + score + follow-up query list |
└──────────────┬──────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────┐
│ Phase 2: Action exploration loop (n_depth rounds) |
│   Select top-k incomplete actions from follow-up queries |
│   Each action uses LocalSearch to search graph neighborhood |
│   Generate new follow-ups → add to graph   |
└──────────────┬──────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────┐
│ Phase 3: Serialization                      │
│   Serialize entire action graph as JSON      |
└──────────────┬──────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────┐
│ Phase 4: Reduce (Aggregation)               │
│   Aggregate all intermediate answers into one final answer |
└─────────────────────────────────────────────┘

Phase 1: Primer — Initialize exploration (drift_search/primer.py)

PrimerResponse structure:

Phase 2: Action exploration loop — Core (drift_search/search.py:188-263)

• Data structure: NetworkX directed graph (QueryState.graph = nx.MultiDiGraph())

  • Nodes = DriftAction (query + answer + score)
  • Edges = parent-child relations (which action generated the follow-up query)

• Loop logic:

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  while epochs < n_depth:  # n_depth rounds
      # 1. Find all incomplete actions, sort by score
      actions = query_state.rank_incomplete_actions()
      # 2. Take top-k (drift_k_followups)
      actions = actions[:drift_k_followups]
      # 3. Concurrently execute search for each action (LocalSearch)
      results = await search_step(actions)
      # 4. Add new results to graph
      for action in results:
          query_state.add_action(action)
          query_state.add_all_follow_ups(action, action.follow_ups)
  

• Single Action search: Calls LocalSearch, returns {"response", "score", "follow_up_queries"}

Key configuration parameters:

2.4 Basic Search

• Core idea: Pure vector retrieval, no graph structure utilization
• Procedure: Directly performs vector similarity retrieval on raw text chunks (text units), using the most relevant text chunks as context
• Applicable scenario: Simple QA, or scenarios where graph structure information is not important
• Characteristic: The simplest RAG, existing as a baseline (code comment: “generic RAG algorithm (vector search on raw text chunks)”)

3. Online Generation: Map-Reduce Answer Aggregation (Global Search Example)

Step 3.1 Prepare: Prepare Community Summaries

Step 3.2 Map: Parallelly Generate Intermediate Answers

Step 3.3 Reduce: Merge into Global Answer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Query: "What are the main themes in the dataset?"
         │
         ▼
  ┌─────────────────┐
  │ Load C2 level    │  ← Select community level (C0/C1/C2/C3)
  │ all community    │     Higher level = more macro = fewer summaries
  │ summaries        │     Lower level = more detailed = more summaries
  └────────┬────────┘
           │
           ▼
  ┌─────────────────┐
  │ Shuffle + Chunk  │
  └────────┬────────┘
           │
     ┌─────┼─────┐
     ▼     ▼     ▼
  [Chunk1] [Chunk2] [Chunk3]  ← Map: Process in parallel
     │     │     │
     ▼     ▼     ▼
  (Answer1, 85) (Answer2, 72) (Answer3, 90)  ← With scores
     │     │     │
     └─────┴─────┘
           │
           ▼
  ┌─────────────────┐
  │ Sort by score    │  ← Reduce
  │ and merge        │
  │ Generate final   │
  │ answer           │
  └─────────────────┘

4. Key Design Decisions

5. Evaluation

5.1 LLM-as-a-Judge (No Gold Standard)

5.2 Factuality Verification

• Tool: Claimify (LLM-based atomic fact decomposition)
• Method: Decompose answer sentences into simple, self-contained factual claims, verify each one individually

5.3 Comparative Experimental Setup

6. Limitations and Applicability

Best Applicable Scenarios

• Global semantic understanding of million-token-scale document collections
• Queries like “what are the main themes/trends/debates in the dataset” — questions with no clear retrieval target
• Scenarios requiring synthesis across multiple documents to generate comprehensive answers (literature review, dataset exploration)
• QA over private data (does not rely on pre-trained knowledge)

7. Quick Reference

相关项目

• LazyGraphRAG
• nano GraphRAG

• Previous
  【阅】本周阅读摘选2026-05-11 → 2026-05-17
• Next
  【阅】本周阅读摘选2026-05-18 → 2026-05-24