Cao Zihang - Blog

【阅】本周阅读摘选2026-05-25 → 2026-05-31

Mon, 01 Jun 2026 00:00:00 +0000

本周阅读摘选 2026-05-25 → 2026-05-31 目录

学术相关
- Intern-Atlas
- Search-R1

学术相关

Intern-Atlas

One-sentence positioning: Extracts “method entities + typed causal edges + bottleneck/mechanism evidence” from 1M+ AI papers to construct a queryable methodological evolution graph, serving as the underlying knowledge infrastructure for AI research agents.

Key innovation: Upgrades flat citation networks into a “method-method causal graph” where each causal edge is accompanied by verbatim citations and structured bottleneck/mechanism annotations; proposes the SGT-MCTS algorithm to reconstruct method evolution lineages on this graph, enabling idea evaluation and generation based on explicit structural evidence rather than LLM parametric memory.

0. Execution Overview

Offline Phase (graph construction)
  ├─ ① Paper corpus processing (1,030,314 papers)
  ├─ ② Method entity extraction + alias resolution
  │     ├─ Seed method curation
  │     ├─ LLM Proposer scanning expansion
  │     └─ Alias registry A: 8,155 canonical / 9,545 aliases
  ├─ ③ Citation edge semantic classification (7 types)
  │     ├─ strong-causal: extends / improves / replaces / adapts
  │     ├─ non-strong: uses_component / compares
  │     └─ non-causal: background
  └─ ④ Causal edge evidence filling
        ├─ 14-category bottleneck taxonomy b_e
        ├─ Mechanism m_e / trade-off t_e
        ├─ LLM confidence c_e ∈ [0,1]
        └─ Verbatim citation grounding
              ↓
Online Phase (retrieval + generation)
  ├─ ⑤ Node matching (keywords + BM25)
  ├─ ⑥ Lineage Reconstruction: SGT-MCTS
  │     ├─ Forward/backward dual trees
  │     ├─ SGT-UCT selection = standard UCT + λ·graph-aware prior
  │     ├─ Temporal coherence TC + edge confidence conf joint prior
  │     └─ Branch discovery + Jaccard deduplication
  ├─ ⑦ Lineage Rerank (length + evidence strength + search consensus)
  └─ ⑧ Generation layer
        ├─ Graph-Grounded Idea Evaluator (5-dimension scoring)
        └─ Graph-Grounded Idea Generator (4 strategy types + evidence certificate)

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

1.1 Indexing

Dimension	Approach
Chunking strategy	Method-level entity extraction, replacing traditional paper/paragraph-level extraction
Index structure	Method evolution graph: method nodes + typed causal edges + structured evidence attributes
Knowledge representation	Directed causal network: nodes = methods/papers/stubs, edges = 7 semantic types (extends/improves/replaces/adapts/uses_component/compares/background), each edge carrying bottleneck/mechanism/trade-off/confidence/verbatim citation
Construction cost	High: 1M+ paper corpus processing, LLM extraction (Qwen3.6-35B-A3B), alias resolution, edge classification, evidence filling
Core characteristic	Method-level atomic units replace paper-level; each causal edge mandatorily carries verbatim citations and structured evidence

1.2 Retrieval

Dimension	Approach
Retrieval method	Graph traversal (SGT-MCTS searches evolution paths on the strong-causal subgraph)
Retrieval granularity	Method nodes + Evolution paths (evolution chains)
Iteration strategy	Multi-hop (forward/backward exploration along strong-causal edges) + Branch discovery restart
Query processing	Keyword matching (canonical/alias) + BM25 semantic matching
Core characteristic	SGT-MCTS dual-tree search with graph-aware and time-aware priors; branch discovery prevents greedy collapse

1.3 Generation

Dimension	Approach
Context injection	Lineage paths injected into Idea Evaluator / Generator
Citation tracing	Verbatim citation grounding + evidence certificate (specific causal edge, bottleneck original text, unresolved explanation)
Quality control	Graph statistics replace LLM free-text judgment; evidence certificate prevents hallucination; verification failure triggers fallback
Core characteristic	Graph-grounded idea evaluation/generation; structural evidence replaces parametric memory

2. Offline Construction: Indexing (Detailed Execution)

Step 2.1 Corpus Preparation

Item	Description
Input	1,030,314 AI papers (covering AI conferences, journals, arXiv preprints)
Operation	Collect and preprocess paper corpus, construct raw document repository
Output	Structured paper corpus

Step 2.2 Method Entity Extraction and Alias Resolution

Step 2.2.1 Seed Method Construction

Item	Description
Input	Human-curated list of well-known methods
Operation	Manually establish initial method seed set
Output	Seed method set

Step 2.2.2 Method Expansion

Item	Description
Input	Seed method set + paper corpus
Operation	LLM Proposer scans entire corpus, identifies and supplements additional candidate method entities
Output	Expanded candidate method set

Step 2.2.3 Alias Registry Construction

Item	Description
Input	Expanded method entity set
Operation	Build alias registry A: V_M → 2^Σ*, mapping each canonical method to a set of surface forms
Matching rules	Substring matching + case/punctuation normalization + word boundary enforcement (prevents “GPT” matching inside “lgpto”) + longest match priority (“GPT-4 Turbo” > “GPT-4” > “GPT”)
Version merging	“-v2”, “-Large” etc. appended to parent unless an independent canonical node already exists
Ambiguity handling	Manually maintained negative-surface list (e.g., state space model “Mamba” vs. Python linter “Mamba”)
Scale	8,155 canonical methods / 9,545 aliases
Output	Alias registry A

Step 2.3 Citation Edge Semantic Classification (Two-Phase LLM Extraction)

Step 2.3.1 Phase 1: Edge Type Classification

Item	Description
Input	Citation relationships between papers
Operation	Use Qwen3.6-35B-A3B to classify each citation edge into semantic types
Classification system	7 types: strong-causal (extends / improves / replaces / adapts), non-strong (uses_component / compares), non-causal (background)
Accuracy	Production model 70.4%; audit model (Claude-Sonnet-4.6) 93.0%
Output	Semantically typed edges

Step 2.3.2 Phase 2: Structured Record Completion

Item	Description
Input	Non-background causal edges
Operation	Complete structured evidence records for each edge
Output	Causal edges carrying structured attributes

Step 2.4 Causal Edge Evidence Filling

Step 2.4.1 14-Category Bottleneck Taxonomy

Bottleneck Dimension	Operational Definition
computational complexity	asymptotic or wall-clock compute at fixed scale
memory efficiency	peak activation / parameter memory footprint
parallelization	degree of across-device or across-token parallelism
accuracy	task-level correctness or quality metric
generalization	out-of-distribution / cross-domain transfer
scalability	behavior as model / data / context size grows
data efficiency	sample complexity at fixed quality target
training stability	variance / divergence risk during optimization
inference speed	runtime latency or throughput
expressiveness	function class or representational capacity
simplicity	implementation, conceptual, or interface simplicity
robustness	behavior under perturbation or adversarial input
hyperparameter sensitivity	outcome variance w.r.t. hyperparameter choice
training complexity	engineering difficulty of the training recipe

Step 2.4.2 Structured Evidence Quadruple

Each causal edge e carries quadruple ρ(e) = (b_e, m_e, t_e, c_e):

Attribute	Meaning	Key Design
b_e	Bottleneck addressed	14-axis bottleneck taxonomy (fixed at publication time)
m_e	Mechanism employed	LLM-extracted structured field
t_e	Trade-off	Cost/limitation of the mechanism
c_e	LLM-reported confidence	∈ [0,1], used later by SGT-MCTS
Citation grounding	Verbatim excerpt	All non-background edges mandatorily paired with verbatim quote

Step 2.4.3 Verbatim Citation Verification

Item	Description
Input	LLM-extracted citations + original papers
Operation	Search Match + Symmetry Check
Purpose	Ensure citations actually exist in the original text, preventing hallucination
Output	Verified verbatim citations

Step 2.4.4 Graph Scale

Metric	Value
Papers	1,030,314
Method nodes	8,155 canonical
Aliases	9,545
Semantically typed edges	9,430,201

3. Online Query: Retrieval (Detailed Execution)

3.1 Retrieval Mode Overview

Intern-Atlas employs a single lineage reconstruction retrieval mode, with SGT-MCTS searching on the method evolution graph:

Mode	Applicable Scenario	Core Mechanism	Characteristic
Lineage Reconstruction	Query method’s evolution history	SGT-MCTS forward/backward dual-tree search on strong-causal subgraph	Graph-aware + time-aware; branch discovery prevents greedy collapse

3.2 Retrieval Procedure

Step 3.1: Node Matching

Item	Description
Input	User query q
Operation	Parse query, construct seed method set S(q)
Matching method 1	Vocabulary keyword matching (exact hit on canonical / alias)
Matching method 2	BM25 semantic matching (handles semantically ambiguous queries)
Output	Seed method set S(q) ⊆ C_q

Step 3.2: SGT-MCTS Lineage Reconstruction

Item	Description
Input	Seed method set S(q)
Operation	On strong-causal subgraph (V_M, ε_sc), construct directed evolution path set Π_q along publication chronology
Why not standard MCTS?	Central nodes have extremely high branching → standard UCT easily gets trapped in high-visit branches; standard UCT does not perceive graph structure and temporal direction, producing implausible paths where “ancestors come from descendants”

Step 3.2.1: Dual-tree Construction

Item	Description
Operation	Each seed simultaneously constructs forward + backward trees
Forward tree	Searches for predecessor methods
Backward tree	Searches for successor developments
Key constraint	Operates only on the strong-causal edge subgraph

Step 3.2.2: SGT-UCT Selection

\[\text{SGT-UCT}(v) = \underbrace{\text{UCT}(u, v)}_{\text{standard exploration-exploitation}} + \lambda \cdot \underbrace{\alpha_G(u, v)}_{\text{graph-aware prior}}\] \[\alpha_G(u, v) = \underbrace{\text{conf}(e_{u \to v})}_{\text{edge confidence}} \cdot \underbrace{\text{TC}(\Delta\tau_{uv})}_{\text{temporal coherence}}\]

Component	Source
conf(e)	Edge confidence c_e reported by LLM during graph construction
TC(Δτ)	Manually segmented function scoring publication year difference

\[\text{TC}(\Delta\tau) = \begin{cases} 0.40 & -1 \leq \Delta\tau < 0 \quad \text{(slight temporal overlap, e.g., preprints)} \\ 0.85 & \Delta\tau = 0 \quad \text{(same year)} \\ 1.00 & 1 \leq \Delta\tau \leq 3 \quad \text{(optimal: 1-3 year natural evolution)} \\ 0.80 & 4 \leq \Delta\tau \leq 6 \quad \text{(slightly distant but still reasonable)} \\ \max(0.30,\ 1.00 - 0.08(\Delta\tau - 6)) & \Delta\tau > 6 \\ 0.70 & \tau \text{ missing} \end{cases}\]

Calibration range limitation: TC is only calibrated on post-2015 AI literature; domains with different research paces require recalibration.

Step 3.2.3: Expansion (Confidence-prioritized)

Item	Description
Loop exclusion	Discard nodes that would create cycles in the path
Hard temporal filtering	Discard nodes with reversed temporal direction (prevents “descendants producing ancestors” paradox)
Expansion strategy	Select the unexplored child node with highest confidence (no random expansion)

Step 3.2.4: Rollout (Greedy)

Item	Description
Strategy	Greedy rollout, no MC random sampling
Selection	Directly select child node with highest confidence, avoiding noise introduction
Termination conditions	Leaf node with no outgoing edges / cycle detected / maximum depth reached
Scoring	R(π): paper does not provide specific form

Step 3.2.5: Backpropagation

Item	Description
Operation	Backpropagate to update cumulative reward and visit count
Special penalty	Additional score deduction for ancestors of non-expandable leaf nodes → reduces dead ends

Step 3.2.6: Path Stitching and Deduplication

Item	Description
Operation	Take top-5 cumulative reward paths from forward/backward each → stitch through seed node
Deduplication	Jaccard similarity threshold 0.8 to determine path homogeneity; keep only the higher-ranked path for homogeneous ones

Step 3.2.7: Branch Discovery

Item	Description
Problem	Addresses greedy collapse preventing discovery of branch paths
Branch node definition	Node has at least 2 strong-causal child nodes in the search direction, but the current lineage final path includes only 1
Restart search	Restart algorithm from the branch node
Constraint	Edges already in the main lineage are forcibly blocked; search budget halved
Output merge	Aggregate main path + branch paths

Step 3.3: Lineage Rerank

Item	Description
Input	Candidate evolution path π
Ranking formula	rank(π) = w_ℓ ·	π	/L_max + w_c · conf̄(π) + w_m · N̄(π)
First term	Rewards long paths (sufficient evolution)
Second term	Path average evidence strength
Third term	Path node average visit count (search consensus)
Output	Re-ranked evolution paths

3.3 Retrieval Algorithm Comparison

Method	NR	ER	CAS
Beam@1	41.0	18.6	41.0
Beam@5	43.4	21.6	43.4
Beam@10	44.9	23.2	44.9
RW@5	28.1	0.7	28.1
SGT-MCTS	84.8	79.0	84.8

4. Online Generation: Generation (Detailed Execution)

4.1 Generation Procedure

Input: query q, retrieved evolution paths Π_q
    │
    ▼
┌─────────────────────────────┐
│ Parse methods mentioned     │
│ in idea d, map to nodes M_d │
│ via lookup table A          │
└─────────────┬───────────────┘
              │
         ┌────┴────┐
         ▼         ▼
   Evaluator   Generator
   (Evaluate)   (Generate)
      │           │
      ▼           ▼
  5-dim scoring  4 strategy types
  +cross penalty +evidence certificate

Step 4.1: Graph-Grounded Idea Evaluator

Step 4.1.1: Motivation

Free-text LLM judges prefer stacking popular methods; novelty scores are negatively correlated with actual scientific impact; graph statistics can directly provide structural evidence.

Step 4.1.2: Per-dimension Scoring

Item	Description
Input	Methods mentioned in idea d → resolved to nodes M_d ⊆ V_M via lookup table A
Operation	Independently evaluate 5 dimensions based on graph statistics
Dimensions	Novelty (N), Feasibility (F), Significance (S), Validity (V), Clarity (C)
Calculation	Each dimension score directly based on graph statistics of M_d’s position/connectivity structure in retrieval context C_d

Formula:

\[s_k(d, G) = \text{clip}_{[1,10]}\left(b_k + \sum_j w_j^{(k)} \cdot \phi_j^{(k)}(M_d, C_d)\right), \quad k \in \{N, F, S, V, C\}\]

Step 4.1.3: Cross-dimensional Aggregation

Item	Description
Operation	Fixed weight vector w + 4 hand-crafted conjunctive penalties Ω_cross
Representative penalty	Strong deduction when high Novelty + low Feasibility — “novel but infeasible” typically indicates a flawed core proposal

Formula:

\[s^*(d, G) = \text{clip}_{[1,10]}\left(\mathbf{w}^\top \mathbf{s} + \Omega_{\text{cross}}(\mathbf{s})\right), \quad \mathbf{s} = (s_N, s_F, s_S, s_V, s_C)\]

Step 4.1.4: Idea Evaluation Results

Publication tier	Overall Score
Top-tier	8.48 ± 1 s.d.
Core	7.83 ± 1 s.d.
Workshop	6.85 ± 1 s.d.
Rejected	5.84 ± 1 s.d.

Step 4.2: Graph-Grounded Idea Generator

Step 4.2.1: Structural Gap Pattern → Generation Strategy Mapping

Gap Pattern	Corresponding Generation Strategy	Description
Open axes	Bottleneck Resolution	Address identified but unresolved bottlenecks in the graph
Recent improvement direction	Trend Extrapolation	Extrapolate along recent improvement directions
Sacrifice axes	Cross-pollination	Cross-domain/cross-method combination, leveraging trade-offs between different methods
Disconnected pairs	Paradigm Challenge	Challenge existing paradigms, connecting disconnected method pairs in the graph

Step 4.2.2: Evidence Certificate (Core Anti-hallucination Mechanism)

Field	Content
Certificate tuple	(specific causal edge, bottleneck original text in the graph, explanation of why this bottleneck remains unresolved)
Verification	Exact match of bottleneck original text in the certificate against actual graph content
Failure handling	Discard result, fallback
Design goal	Ensure ideas are traceable without over-constraining generation

5. Key Design Decisions

Decision Point	Intern-Atlas’s Choice	Alternative	Rationale
Graph atomic unit	Method entities (method-level)	Papers (paper-level)	Notes explicitly document: paper-level citations cannot distinguish extends/improves/replaces/compares/background
Causal edge evidence	Mandatory verbatim citations + structured bottleneck/mechanism	Edge type labels only	Provides grounded evidence, supports certificate verification for idea generation
Lineage search algorithm	SGT-MCTS (graph-aware + time-aware)	Beam search / standard MCTS / Random Walk	Notes explicitly document: high branching at central nodes causes beam collapse; standard MCTS does not perceive publication year direction; Random Walk performs extremely poorly (ER only 0.7)
Rollout strategy	Greedy (highest confidence)	MC random sampling	Random sampling introduces LLM extraction noise
Dead-end handling	Backpropagation additional penalty + branch discovery restart	Pure reliance on UCT exploration term	Explicitly suppresses greedy collapse, proactively recalls ignored branches
Idea evaluation	Per-dimension graph statistics + hand-crafted conjunctive penalties	Free-text LLM judge	The latter’s novelty score is negatively correlated with actual impact
Idea generation	Structural gap patterns + evidence certificate	Direct LLM free generation	Forces grounding to specific causal edges and bottlenecks, avoids method name stacking

6. Evaluation

6.1 Graph Construction Quality

Benchmark: 30 high-impact surveys → 30 method evolution graphs, containing 2,268 nodes / 1,462 edges / 133 evolution chains.

Metric	Meaning	Result
NMR (Node Match Ratio)	Node match rate	91.0%
ERR (Edge Reachable Ratio)	Edge reachability rate	89.7%
PSC (Path Semantic Correctness)	Path semantic correctness	92.0%
NR (Node Recall)	Node recall	84.8% (SGT-MCTS)
ER (Edge Recall)	Edge recall	79.0% (SGT-MCTS)
CAS (Chain Alignment Score)	Lineage chain alignment score	84.8% (SGT-MCTS)

6.2 Idea Evaluator (Strata Dataset)

Category	Paper Count	Overall Score
Top-tier (ICLR 2026, ICML 2025, NeurIPS 2025)	300	8.48
Core (AAAI 2026, IJCAI 2025)	300	7.83
Workshop (ICLR 2026)	300	6.85
Rejected (ICLR 2026)	300	5.84

Evaluation method: Publication tier verification (across publication strata) + human evaluation.

6.3 Idea Generator Comparative Experiments

Baseline	Retrieval/Knowledge Source
Direct LLM generation	No external retrieval
External search	OpenAlex / Semantic Scholar
Local RAG	BM25
Intern-Atlas	Method evolution graph + evidence certificate

6.4 SGT-MCTS Retrieval Algorithm Comparison

Method	NR	ER	CAS
Beam@1	41.0	18.6	41.0
Beam@5	43.4	21.6	43.4
Beam@10	44.9	23.2	44.9
RW@5	28.1	0.7	28.1
SGT-MCTS	84.8	79.0	84.8

7. Limitations and Applicability

Limitation	Specific Manifestation	Mitigation
Edge type classification accuracy	Phase-1 production model 70.4% / audit model 93.0%	Key decisions can undergo secondary audit; improve production model
Bottleneck taxonomy rigidity	14-axis taxonomy D fixed at publication time; new dimensions mapped to nearest existing axis	Await future taxonomy revision
Alias resolution coverage	Substring matching favors precision over recall; ambiguity handled via manual negative list	Biased toward high-quality nodes
Temporal coherence calibration range	TC calibrated on post-2015 AI literature	Cross-pace domains require recalibration
Rollout scoring opacity	R(π) paper does not provide specific form	Reproduction requires custom design

Best Applicable Scenarios

AI agents performing idea generation/evaluation that require structured method evolution priors
Traceable scientific idea generation (evidence certificate prevents hallucination)
Method lineage research / survey automation within AI subfields
Evaluating ideas while avoiding the “popular method stacking” bias of LLM free-text judges

Unsuitable Scenarios

Disciplines with research paces significantly different from AI (TC calibration fails)
Extremely niche subfields without human survey references (limited graph coverage)
Research focused on paper-level citation network properties (e.g., PageRank, influence propagation)

8. Quick Reference

What You Want to Know	See Which Section
What is the complete pipeline?	0. Execution Overview
High-level design comparison?	1. High-level Design
How is the graph constructed?	2. Offline Construction
How to retrieve evolution paths from the graph?	3. Online Query
How to use the graph to evaluate/generate ideas?	4. Online Generation
How does it differ from existing approaches?	5. Key Design Decisions
How does it perform?	6. Evaluation
When should it NOT be used?	7. Limitations and Applicability

Search-R1

One-sentence positioning: A framework that trains LLMs via reinforcement learning to autonomously generate multi-turn search queries during step-by-step reasoning and perform real-time retrieval, addressing the suboptimal performance of prompt-engineering-driven search through retrieval result loss masking and outcome-oriented rewards.

Key innovation: Unlike prompt-driven search methods, Search-R1 models the search engine as part of the environment and trains the LLM via RL to autonomously learn the optimal search interaction strategy; simultaneously introduces retrieval token masking to prevent gradient updates on retrieved content, ensuring training stability.

0. Execution Overview

Training Phase
  ├─ ① Preparation: search engine as environment, policy model π_θ, reference model π_ref
  ├─ ② Rollout: model generates reasoning sequences, interleaving token generation with search engine retrieval
  │   ├─ Encountering uncertain knowledge → generate <search>... </search> query
  │   ├─ Search engine returns documents → wrap as <information>... </information>
  │   ├─ Reasoning process → wrap as <think>... </think>
  │   └─ Final answer → wrap as <answer>... </answer>
  ├─ ③ Reward computation: outcome-oriented reward r_φ(x, y) = EM(a_pred, a_gold)
  ├─ ④ Loss Masking: policy gradient computed only on LLM-generated tokens; retrieved content excluded from optimization
  └─ ⑤ Policy update: PPO or GRPO updates the policy model

Inference Phase (per query)
  ├─ ① Input question q
  ├─ ② Iterative generation: text generation ↔ search query alternation
  │   ├─ Generate response tokens
  │   ├─ Detect <search> / </answer> / <eos> → determine next action
  │   ├─ Search query → retrieve documents → inject into reasoning chain
  │   └─ Continue generation
  ├─ ③ Termination condition: maximum action count B reached or <answer> generated
  └─ ④ Output final answer

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

1.1 Indexing

Dimension	Approach
Chunking strategy	—
Index structure	— (relies on external search engine; offline index construction not explicitly recorded in notes)
Knowledge representation	—
Construction cost	—
Core characteristic	Notes do not explicitly record index construction; the offline phase focuses on model training rather than knowledge base construction

1.2 Retrieval

Dimension	Approach
Retrieval method	Dynamic search triggering (model learns via RL to autonomously decide when to retrieve)
Retrieval granularity	Documents (external documents returned by the search engine)
Iteration strategy	Multi-turn iteration (search may be triggered multiple times during reasoning until termination conditions are met)
Query processing	Model autonomously generates search queries based on current reasoning state
Core characteristic	RL-driven agentic search: model learns the optimal search interaction strategy rather than relying on manual prompt engineering

1.3 Generation

Dimension	Approach
Context injection	Retrieved documents injected into the reasoning chain via tags
Citation tracing	—
Quality control	Outcome-oriented reward (EM matching) drives generation quality; retrieval token masking ensures training stability
Core characteristic	Structured token system ( / / / ); reasoning and retrieval proceed in an interleaved manner

2. Offline Construction: RL Training (Detailed Execution)

The core of Search-R1’s offline phase is RL training rather than traditional knowledge base index construction. The system relies on external search engines (e.g., Bing) for document retrieval, and the notes do not explicitly record traditional index construction steps.

Step 2.1 Search Engine Environment Modeling

Item	Description
Input	Policy LLM π_θ, search engine R
Operation	Model the search engine as part of the environment; sampled trajectory sequences interleave LLM token generation with search engine retrieval
Key decision	Unlike previous methods that rely solely on the policy LLM for rollout generation, explicitly introduces retrieval-interleaved reasoning: π_θ(· \| x; R)
Output	Rollout environment with interleaved retrieval and reasoning

Step 2.2 Structured Token System Definition

Item	Description
Operation	Define four types of special tokens to structure the interaction
Key decision	Uses special tokens rather than free text, facilitating rule-based parsing and training control
Output	Token system: / , / , / , /

Step 2.3 Rollout Sequence Generation

Item	Description
Input	Query q, policy model π_θ, search engine R
Operation	Model generates response tokens y_t ~ πθ(· \| x, y*<t; R), appended to the rollout sequence
Key decision	The sequence contains two types of tokens: LLM-generated tokens and retrieved tokens
Output	Complete rollout sequence y

Step 2.4 Retrieval Token Masking (Loss Masking)

Item	Description
Problem	Optimizing retrieved tokens equally leads to unexpected learning dynamics
Operation	Introduce a loss mask ensuring the policy gradient objective is computed only on LLM-generated tokens
Key decision	Indicator function I(y_t): model-generated token = 1, retrieved content (within ) = 0
Output	Masked policy gradient computation

Step 2.5 Reward Computation

Item	Description
Input	Model’s final answer a_pred, ground-truth answer a_gold
Operation	Apply a rule-based outcome-oriented reward: r_φ(x, y) = EM(a_pred, a_gold)
Key decision	Does not use format reward (model already demonstrates strong structural compliance); does not train a neural reward model (avoids sensitivity and additional cost)
Output	Reward value

Step 2.6 Policy Update (PPO / GRPO)

Item	Description
PPO	Actor-critic method; Actor generates answers, Critic value network estimates advantage, advantage function uses GAE
GRPO	Group-relative advantage estimation, no Critic network needed; samples G outputs per group to compute group baseline
Key decision	Both are compatible; GRPO converges faster, PPO trains more stably, final rewards are comparable
Output	Updated policy model parameters

3. Online Query: Retrieval (Detailed Execution)

3.1 Retrieval Mode Overview

Search-R1 employs a single RL-driven search mode, autonomously triggered by the trained model during inference:

Mode	Applicable Scenario	Core Mechanism	Characteristic
RL-driven Search	Knowledge uncertainty encountered during reasoning	Model autonomously generates queries → retrieves → injects	Learned, not manually predefined strategy

3.2 Retrieval Procedure

Step 3.1: Reasoning and Search Alternation

Item	Description
Input	Query q, current reasoning chain state
Operation	LLM alternates between text generation and external search engine queries
Key decision	Iterative framework: generates at each step until , </answer>, or is detected
Output	Response token sequence

Step 3.2: Search Query Detection and Execution

Item	Description
Input	Query wrapped in tags
Operation	Extract search query from rollout sequence, invoke search engine to retrieve documents D
Output	Retrieved documents, wrapped as ... and injected into the sequence

Step 3.3: Iterative Termination Judgment

Item	Description
Termination condition 1	Maximum action count B reached
Termination condition 2	Model generates final response wrapped in tags
Fallback strategy	If content is empty (model outputs "My action is not correct. Let me rethink."), continue iteration

4. Online Generation: Generation (Detailed Execution)

4.1 Reasoning Procedure

Input question q
    │
    ▼
┌─────────────────────────┐
│ Initialize: action count b ← 0 │
│ Initialize: response y ← ∅      │
└───────────┬─────────────┘
            │
            ▼
    ┌───────┴───────┐
    │  while b < B  │
    └───────┬───────┘
            │
            ▼
    ┌───────────────────┐
    │ Generate response tokens │
    │ until termination signal │
    └─────────┬─────────┘
              │
         ┌────┴────┐
         ▼         ▼
      <search>   <answer>
         │         │
         ▼         ▼
      Retrieve    Return y
      documents
      inject
         │
         ▼
      b ← b + 1
         │
         └──────→ Continue generating

Step 4.1: Online Reasoning Sequence Generation

Item	Description
Input	Query q, trained policy model π_θ, search engine R
Operation	Model autoregressively generates response tokens; pauses upon encountering to trigger retrieval, then continues generation after injecting results
Key decision	Reasoning process is structurally consistent with the training Rollout, but no longer computes gradient updates
Output	Final response sequence y, containing the answer wrapped in tags

5. Key Design Decisions

Decision Point	Search-R1’s Choice	Alternative	Rationale
Training paradigm	Reinforcement learning (PPO / GRPO)	Prompt engineering / SFT / Rejection sampling	Explicitly stated in notes: prompting advanced LLMs to use search engines is often suboptimal; LLMs may not fully possess the ability to optimally interact with search engines
Retrieval triggering	Model learns autonomously ( token)	Fixed retrieval strategy / manually predefined trigger conditions	Explicitly stated in notes: RL training enables the model to autonomously learn when search is needed
Reward design	Outcome-oriented reward (EM matching)	Process reward / neural reward model / format reward	Explicitly stated in notes: uses simple outcome reward to avoid complexity; does not train a neural reward model to avoid sensitivity and cost
Training stability	Retrieval token masking	No special handling of retrieved content	Explicitly stated in notes: optimizing on retrieved tokens equally leads to unexpected learning dynamics
Inference algorithm	Supports both PPO and GRPO	Single RL algorithm	Explicitly stated in notes: both algorithms are compatible, providing empirical comparison

6. Evaluation

6.1 Evaluation Metrics

Metric	Meaning	This System vs. Baseline
EM	Exact Match	Qwen2.5-7B +41% over RAG baselines; Qwen2.5-3B +20% over RAG baselines

6.2 RL Training Comparison

Condition	Description
PPO	Actor-critic RL; higher training stability
GRPO	Group Relative Policy Optimization; faster convergence
Conclusion	GRPO converges faster, PPO is more stable, final training rewards are comparable

6.3 Experimental Setup

Condition	Description
Search-R1	Full system (RL training + retrieval masking + outcome reward)
CoT	Chain-of-thought baseline
vanilla RAG	Standard retrieval-augmented generation baseline
IRCoT	Iterative retrieval chain-of-thought baseline
Search-o1	Inference-time search augmentation baseline
R1	DeepSeek-R1 baseline
SFT	Supervised fine-tuning baseline
Rejection Sampling	Rejection sampling baseline

6.4 Datasets

Dataset	Description
Natural Questions (NQ)	Open-domain QA benchmark
TriviaQA	Open-domain QA benchmark
PopQA	Knowledge-intensive QA benchmark
HotpotQA	Multi-hop QA benchmark
2WikiMultiHopQA	Multi-hop QA benchmark
MuSiQue	Multi-hop QA benchmark
Bamboogle	Open-domain QA benchmark

7. Limitations and Applicability

The notes do not explicitly record Search-R1’s limitations.

Best Applicable Scenarios

Reasoning tasks requiring efficient acquisition of external knowledge and up-to-date information
Open-domain QA (NQ, TriviaQA, etc.)
Multi-hop QA (HotpotQA, 2WikiMultiHopQA, MuSiQue, etc.)
Knowledge-intensive reasoning tasks

Unsuitable Scenarios

8. Quick Reference

What You Want to Know	See Which Section
What is the complete pipeline?	0. Execution Overview
High-level design comparison?	1. High-level Design
How is the model trained?	2. Offline Construction
How is retrieval triggered?	3. Online Query
RL training details?	2. Offline Construction
Why this design?	5. Key Design Decisions
How does it perform?	6. Evaluation
When should it NOT be used?	7. Limitations and Applicability

【阅】本周阅读摘选2026-05-18 → 2026-05-24

Mon, 25 May 2026 00:00:00 +0000

本周阅读摘选 2026-05-18 → 2026-05-24 目录

学术相关
- HippoRAG
- HippoRAG2

学术相关

HippoRAG

One-sentence positioning: A retrieval framework inspired by the hippocampal indexing theory that extracts an open knowledge graph via LLM and combines it with the Personalized PageRank algorithm to achieve cross-passage multi-hop knowledge integration in a single retrieval step.

Key innovation: Uses Personalized PageRank to perform pattern completion on the knowledge graph, compressing traditional iterative multi-hop retrieval into a single-step graph traversal, achieving performance comparable to or better than iterative retrieval while reducing cost by 10-30x and improving speed by 6-13x.

0. Execution Overview

Offline Phase (one-time construction)
  ├─ ① Named entity recognition (extract named entities from each passage)
  ├─ ② OpenIE extraction of KG triples (two-stage: NER → OpenIE extracts noun phrase nodes N and relation edges E)
  ├─ ③ Retrieval encoder supplements synonym edges (add E' between entities with cosine similarity > τ)
  └─ ④ Construct Passage-Node co-occurrence matrix P (|N| × |P|, recording each noun phrase's occurrence count in each passage)
         ↓
Online Phase (per query)
  ├─ ⑤ Query entity extraction (LLM extracts salient named entities from query)
  ├─ ⑥ Query node mapping (entity vectorized encoding, mapped to most similar KG node via cosine similarity)
  ├─ ⑦ Run Personalized PageRank (query nodes as seeds, PPR distributes probability on graph)
  │      - Initialization: query nodes equal probability, rest are 0
  │      - Node-specific weighting: si = |Pi|^{-1} (similar to TF-IDF)
  │      - Transition probability constructed via adjacency matrix
  └─ ⑧ Aggregate PPR node probabilities with co-occurrence matrix P to obtain passage ranking scores
         ↓
  ⑨ Retrieved passages input to LLM for final answer generation

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

1.1 Indexing

Dimension	Approach
Chunking strategy	Processed by passage (notes do not document chunking parameters)
Index structure	Graph index (open KG + synonym edges + Passage-Node co-occurrence matrix)
Knowledge representation	Entity-relation graph (schemaless OpenIE triples) + synonym relations + co-occurrence statistics
Construction cost	Medium (LLM two-stage extraction + encoder similarity computation)
Core characteristic	Artificial neocortex (LLM) handles extraction, artificial hippocampus (open KG) handles indexing, parahippocampal region (retrieval encoder) handles connection

1.2 Retrieval

Dimension	Approach
Retrieval method	Graph traversal (Personalized PageRank)
Retrieval granularity	Passage
Iteration strategy	Single retrieval (PPR achieves multi-hop effect in a single step)
Query processing	Entity extraction → Query node mapping (cosine similarity)
Core characteristic	PPR uses query nodes as seeds to diffuse probability on the graph, achieving in one step what traditional methods require iteration for

1.3 Generation

Dimension	Approach
Context injection	Retrieved and ranked passages as context input to LLM
Citation tracing	Based on Passage-Node co-occurrence matrix associating nodes with original passages
Quality control	Notes do not explicitly document special mechanisms in the generation phase
Core characteristic	Retrieval framework positioning; generation phase relies on standard LLM generation

2. Offline Construction: Indexing (Detailed Execution)

Step 2.1 Named Entity Recognition

Item	Description
Input	Raw passage collection P
Operation	Extract named entities from each passage
Key decision	First step of two-stage extraction: extract named entities first, then add them to the OpenIE prompt, balancing generality and named entity bias
Output	Named entity set for each passage

Step 2.2 OpenIE Extraction of KG Triples

Item	Description
Input	Passages + named entities
Operation	LLM performs open information extraction (OpenIE) via 1-shot prompting, extracting noun phrase nodes N and relation edges E
Key decision	Add named entities to the OpenIE prompt to extract final triples containing concepts beyond named entities (noun phrases)
Output	Nodes N and edges E of schemaless open KG

Step 2.3 Supplement Synonym Edges

Item	Description
Input	Node set N + retrieval encoder M
Operation	Compute cosine similarity between node representations; add synonym relation edges E’ when similarity exceeds threshold τ
Key decision	Uses off-the-shelf dense retrieval encoders to establish additional edges between similar but non-identical noun phrases, aiding downstream pattern completion
Output	Extended edge set (E + E’)

Step 2.4 Construct Passage-Node Co-occurrence Matrix

Item	Description
Input	Final node set N + original passages P
Operation	Count the occurrence of each noun phrase in each original passage
Output	\|N\| × \|P\| co-occurrence matrix P (recording each noun phrase’s occurrence count in each passage)

3. Online Query: Retrieval (Detailed Execution)

3.1 Retrieval Procedure

Step 3.1 Query Entity Extraction

Operation: LLM extracts salient named entities (query named entities) from the query
Purpose: Transform natural language query into seed nodes on the graph

Step 3.2 Query Node Mapping

Operation: Vectorize query named entities using the retrieval encoder, map to most similar nodes in the KG based on cosine similarity
Output: Query nodes

Step 3.3 Personalized PageRank Execution

Initialize personalized probability distribution: All query nodes have equal probability, other nodes probability is 0
Node-specific weighting: si = Pi ^{-1}, similar to TF-IDF’s inverse document frequency idea
Transition probability: Constructed via adjacency matrix
Core mechanism: PPR distributes probability on the graph only through user-defined source nodes (query nodes), simulating pattern completion in hippocampal neural pathways

Step 3.4 Passage Ranking

Operation: Multiply the updated PPR node probability distribution with the co-occurrence matrix P
Output: Final ranking score for each passage

4. Online Generation: Generation (Detailed Execution)

HippoRAG is positioned as a retrieval framework; the notes do not explicitly document special design in the generation phase. Retrieved and ranked passages serve as context input to the downstream LLM for answer generation.

User query
    │
    ▼
┌─────────────────┐
│ Query entity    │  ← LLM extracts named entities
│ extraction      │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Query node      │  ← Cosine similarity matches KG nodes
│ mapping         │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ PPR probability │  ← Execute Personalized PageRank on graph
│ diffusion       │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Passage ranking │  ← PPR probability × co-occurrence matrix P
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ LLM generates   │  ← Retrieved passages as context
│ answer          │
└─────────────────┘

5. Key Design Decisions

Decision Point	HippoRAG’s Choice	Alternative	Rationale
Index structure	Open KG + synonym edges + co-occurrence matrix	Pure vector index / structured KG / text chunk index	Schemaless OpenIE flexibly adapts to any corpus; co-occurrence matrix associates nodes with original passages
Retrieval algorithm	Personalized PageRank single-step graph traversal	Iterative multi-hop retrieval (e.g., IRCoT)	PPR achieves multi-hop effect in one step, reducing cost by 10-30x and improving speed by 6-13x
Entity extraction	Two-stage: NER → OpenIE	Single-stage OpenIE	Balances generality and named entity bias
Synonym edge construction	Retrieval encoder cosine similarity	Exact string matching / semantic models	Establishes connections between similar but non-identical phrases, aiding pattern completion
Node-specific weighting	si = \|Pi\|^{-1} (similar to TF-IDF)	Uniform weighting / other weighting strategies	Reduces weight of high-frequency nodes, improving retrieval precision

6. Evaluation

6.1 Evaluation Metrics

Metric	Meaning	System vs. Baseline
recall@2 / recall@5	Retrieval recall	Superior to traditional RAG methods
EM	Exact match	Single-step retrieval comparable to or better than IRCoT
F1	F1 score	Up to 20% improvement over SOTA

6.2 Comparative Experimental Setup

Condition	Description
HippoRAG	Full system (OpenIE KG + PPR retrieval)
BM25	Sparse retrieval baseline
Contriever / GTR / ColBERTv2	Dense retrieval baselines
Propositionizer	Proposition-level retrieval baseline
RAPTOR	Hierarchical summary retrieval baseline
IRCoT	Iterative retrieval baseline

Benchmark datasets: MuSiQue, 2WikiMultiHopQA, HotpotQA

Key findings:

Single-step retrieval achieves performance comparable to or better than iterative retrieval IRCoT
Cost is 1/10 to 1/30 of IRCoT, speed is 6-13x faster than IRCoT
Integration into IRCoT yields further improvements

7. Limitations and Applicability

Limitation	Specific Manifestation	Mitigation
NER design limitation	Cannot extract sufficient information from queries for retrieval, accounting for approximately half of all errors	Improve NER module design; consider richer query understanding mechanisms
Entity-centric bias	Strong bias toward concepts, many contextual signals not utilized	Introduce context-aware retrieval mechanisms
Missing contextual cues	Ignoring contextual cues accounts for approximately 48% of errors	Incorporate more contextual information in indexing and retrieval

Best Applicable Scenarios

Multi-hop QA tasks requiring cross-passage knowledge integration
Scenarios sensitive to retrieval latency (single-step PPR is 6-13x faster than iterative retrieval)
Cost-constrained environments (10-30x cheaper than iterative retrieval)
Scenarios where query information can primarily be expressed through entity relations

Unsuitable Scenarios

Scenarios where key information in queries cannot be extracted via NER
Queries requiring extensive contextual cues rather than entity relations
Scenarios with extremely high demands on fine-grained semantic differences between concepts

8. Quick Reference

What You Want to Know	See Which Section
What is the complete pipeline?	0. Execution Overview
High-level design comparison?	1. High-level Design
How is the index constructed?	2. Offline Construction
How are queries answered?	3. Online Query + 4. Online Generation
Why is it better than iterative retrieval?	5. Key Design Decisions
How does it perform?	6. Evaluation
When should it NOT be used?	7. Limitations and Applicability

HippoRAG2

One-sentence positioning: An improved version of HippoRAG that introduces passage nodes into the knowledge graph to achieve dense-sparse fusion of concepts and context, combining Query-to-Triple retrieval with LLM filtering to comprehensively outperform standard RAG on factual memory, sense-making, and associative memory tasks.

Key innovation: Introduces passage nodes on top of PPR to achieve dense-sparse fusion of concepts and context, and through the Query-to-Triple + LLM filtering retrieval strategy, addresses the performance degradation of knowledge graph RAG on factual memory tasks.

0. Execution Overview

Offline Phase (one-time construction)
  ├─ ① Entity extraction
  ├─ ② Extract KG triples (OpenIE)
  ├─ ③ Synonym edge completion (cosine similarity > τ)
  └─ ④ Dense-Sparse fusion (core design)
         - Sparse layer: phrase nodes
         - Dense layer: complete vector representation of each passage abstracted as passage node
         - Bridging: passage nodes connected to corresponding entities via contains edges
         ↓
Online Phase (per query)
  ├─ ⑤ Query embedding
  ├─ ⑥ Vector recall
  │      - top-k passages (embedding similarity)
  │      - top-k KG triples (Query to Triple)
  ├─ ⑦ LLM filters triples (produces T' ⊆ T)
  ├─ ⑧ Seed node selection
  │      - If filtered set is empty → directly return top-k passages
  │      - Otherwise
  │        · Phrase nodes: identified from T', top-k selected by average ranking score, probabilities assigned by normalized ranking scores
  │        · Passage nodes: all recalled passages serve as seeds, probability = embedding similarity × weight factor
  ├─ ⑨ Merge & global normalization
  ├─ ⑩ Execute Personalized PageRank
  └─ ⑪ Sort and output retrieval results
         ↓
  ⑫ Retrieved passages input to LLM for final answer generation

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

1.1 Indexing

Dimension	Approach
Chunking strategy	Processed by passage
Index structure	Graph index (open KG + passage nodes + synonym edges + contains edges)
Knowledge representation	Entity-relation graph + passage nodes + dense-sparse fusion
Construction cost	Medium (LLM extraction + encoder similarity computation + passage vector encoding)
Core characteristic	Dense-Sparse fusion — phrase nodes as sparse encoding, passage nodes as dense encoding, contains edges bridge the two

1.2 Retrieval

Dimension	Approach
Retrieval method	Hybrid (graph traversal PPR + vector recall of triples/passages)
Retrieval granularity	Passage
Iteration strategy	Single retrieval (PPR single-step achieves multi-hop effect)
Query processing	Query to Triple (embedding recall of top-k triples + LLM filtering)
Core characteristic	Query-to-Triple incorporates richer contextual information from KG; phrase + passage nodes jointly serve as PPR seeds

1.3 Generation

Dimension	Approach
Context injection	Retrieved and ranked passages as context input to LLM
Citation tracing	Based on passage-node associations
Quality control	Notes do not explicitly document special mechanisms in the generation phase
Core characteristic	Retrieval framework positioning; generation phase relies on standard LLM generation

2. Offline Construction: Indexing (Detailed Execution)

Step 2.1 Entity Extraction

Item	Description
Input	Raw passages
Operation	Extract named entities
Output	Named entity set

Step 2.2 Extract KG Triples

Item	Description
Input	Passages + named entities
Operation	Extract noun phrase nodes and relation edges via OpenIE
Output	Nodes and edges of schemaless open KG

Step 2.3 Synonym Edge Completion

Item	Description
Input	Node set + retrieval encoder
Operation	Add synonym edges between entities with cosine similarity above threshold τ
Output	Extended edge set

Step 2.4 Dense-Sparse Fusion (Core Design)

Item	Description
Input	KG nodes + passages
Operation	Abstract the complete vector representation of each passage as a passage node; passage nodes connected to corresponding entities via contains edges
Key decision	Inspired by brain’s dense-sparse integration — phrase nodes as sparse encoding of extracted concepts, passage nodes as dense encoding of the context from which concepts originate
Output	Enhanced KG (containing phrase nodes, passage nodes, contains edges)

Why this approach? Concepts are concise and generalizable but lose information; context is semantically rich but adds complexity. Dense-sparse fusion retains the advantages of both, resolving the concept-context trade-off.

3. Online Query: Retrieval (Detailed Execution)

3.1 Retrieval Mode Overview

HippoRAG 2 supports three query mapping methods, with Query to Triple as the default:

Method	Mechanism	Description
NER to Node	Extract query entities → embedding matches KG nodes	HippoRAG’s original method
Query to Node	Entire query embedding directly matches KG nodes	Does not extract individual entities
Query to Triple	Entire query embedding matches triples in the graph	Default, incorporates richer contextual information

3.2 Retrieval Procedure

Step 3.1 Query Embedding

Operation: Encode the query as a vector representation

Step 3.2 Vector Recall

top-k passages: Recalled via embedding similarity
top-k triples: Query to Triple, recall triples in the graph via embedding similarity

Step 3.3 LLM Filters Triples

Operation: Use LLM to filter retrieved triples T, producing T’ ⊆ T
Purpose: Improve retrieval quality, remove irrelevant triples

Step 3.4 Seed Node Selection

If filtered set is empty: Directly return embedding-recalled top-k passages
Otherwise:
- Phrase nodes: Identify phrase nodes from filtered triples T’, select top-k by average ranking score, assign probabilities based on normalized ranking scores
- Passage nodes: All recalled passage nodes also serve as seed nodes, with initial probability being embedding similarity multiplied by a weight factor (§6.2), balancing the influence of phrase nodes and passage nodes

Step 3.5 Merge and Global Normalization

Merge probability distributions of phrase nodes and passage nodes
Global normalization

Step 3.6 Personalized PageRank

Execute PPR using the merged seed node probability distribution as the personalized vector

Step 3.7 Sort and Output

PPR output node probabilities multiplied by the co-occurrence matrix to obtain final passage ranking scores

4. Online Generation: Generation (Detailed Execution)

HippoRAG 2 is positioned as a retrieval framework; the notes do not explicitly document special design in the generation phase. Retrieved and ranked passages serve as context input to the downstream LLM for answer generation.

User query
    │
    ▼
┌─────────────────┐
│ Query embedding │
└────────┬────────┘
         │
    ┌────┴────┐
    ▼         ▼
┌────────┐ ┌─────────────┐
│ top-k  │ │ top-k       │
│passages│ │ triples     │
└───┬────┘ └──────┬──────┘
    │             │
    │             ▼
    │      ┌─────────────┐
    │      │ LLM filters │
    │      └──────┬──────┘
    │             │
    │      ┌──────┴──────┐
    │      ▼             ▼
    │  ┌────────┐   ┌──────────┐
    │  │ T' is  │   │ T' is    │
    │  │ empty  │   │ non-empty│
    │  └───┬────┘   └────┬─────┘
    │      │             │
    ▼      ▼             ▼
┌─────────────────────────────────┐
│ Directly return passages        │   ← T' is empty
│ or                              │
│ Phrase nodes + Passage nodes    │   ← T' is non-empty
│ → merge & normalize → PPR       │
└─────────────────────────────────┘
         │
         ▼
┌─────────────────┐
│ Passage ranking │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ LLM generates   │
│ answer          │
└─────────────────┘

5. Key Design Decisions

Decision Point	HippoRAG2’s Choice	Alternative	Rationale
Concept-context fusion	Dense-Sparse fusion (passage nodes + contains edges)	Pure concepts (phrase nodes) / pure context	Resolves concept-context trade-off, retaining conceptual conciseness while incorporating contextual richness
Retrieval strategy	Query to Triple + LLM filtering	NER to Node / Query to Node	Incorporates richer contextual information from KG
Seed nodes	Phrase nodes + Passage nodes jointly as PPR seeds	Phrase nodes only (HippoRAG)	Broader activation improves multi-hop reasoning capability
Passage node probability	Embedding similarity × weight factor	Ranking scores / uniform distribution	Balances the influence between phrase nodes and passage nodes

6. Evaluation

6.1 Evaluation Metrics

Metric	Meaning	System vs. Baseline
recall@5	Retrieval recall	Superior to standard RAG and HippoRAG
F1	F1 score	Comprehensively superior to standard RAG on factual, sense-making, and associative memory tasks

6.2 Comparative Experimental Setup

Condition	Description
HippoRAG 2	Full system (Dense-Sparse fusion + Query to Triple + LLM filtering)
BM25	Sparse retrieval baseline
Contriever / GTR	Dense retrieval baseline
RAPTOR	Hierarchical summary retrieval baseline
GraphRAG / LightRAG	Graph RAG baselines
HippoRAG	Predecessor method baseline

Datasets:

Task Type	Datasets
Simple QA	NaturalQuestions, PopQA
Multi-hop QA	MuSiQue, 2WikiMultihopQA, HotpotQA, LV-Eval
Discourse Understanding	NarrativeQA

Key findings:

Comprehensively superior to standard RAG on factual memory, sense-making, and associative memory tasks
7% improvement over SOTA embedding models on associative memory tasks
Resolves HippoRAG’s performance degradation on factual memory tasks

7. Limitations and Applicability

Notes do not explicitly document specific limitations. From a design perspective, while the concept-context trade-off is mitigated through fusion, the dense-sparse weight balancing still relies on hyperparameter tuning.

Best Applicable Scenarios

RAG scenarios requiring simultaneous consideration of factual memory and associative reasoning
Environments requiring multi-hop QA without bearing the high cost of iterative retrieval
Scenarios where query information can be expressed through both entity relations and contextual context

Unsuitable Scenarios

Notes do not explicitly document unsuitable scenarios

8. Quick Reference

What You Want to Know	See Which Section
What is the complete pipeline?	0. Execution Overview
High-level design comparison?	1. High-level Design
How is the index constructed?	2. Offline Construction
How does the retrieval strategy work?	3. Online Query
How does it differ from HippoRAG?	5. Key Design Decisions
How does it perform?	6. Evaluation

【阅】本周阅读摘选2026-05-11 → 2026-05-17

Mon, 18 May 2026 00:00:00 +0000

本周阅读摘选 2026-05-11 → 2026-05-17 目录

学术相关
- LightRAG
- GraphRAG

学术相关

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

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

Dimension	Approach
Chunking strategy	Fixed token size chunking (default 1200)
Index structure	Graph index + vector index (hybrid)
Knowledge representation	Entity-relation graph + key-value pairs (K=retrieval keywords, V=original document segments)
Construction cost	Medium (LLM extracts entities/relations + generates K-V pairs, but lighter than GraphRAG’s recursive community summarization)
Core characteristic	Graph-based text index with incremental updates requiring no full database reprocessing

1.2 Retrieval

Dimension	Approach
Retrieval method	Hybrid (vector similarity + graph traversal expansion)
Retrieval granularity	Entity / Relation / One-hop neighbor subgraph
Iteration strategy	Single retrieval + neighbor expansion (not iterative multi-hop)
Query processing	Query decomposed into Low-Level (concrete/local) and High-Level (abstract/global) keywords
Core characteristic	Dual-layer retrieval system: matches entity nodes for concrete queries, matches relation edges for abstract queries

1.3 Generation

Dimension	Approach
Context injection	Direct concatenation of retrieved entities, relation descriptions, and neighbor information
Citation tracing	Based on V in key-value pairs (original document segments)
Quality control	Standard LLM generation (no special post-processing)
Core characteristic	Graph structure provides cross-chunk multi-hop associations, solving vector RAG’s context fragmentation problem

2. Offline Construction: Indexing (Detailed Execution)

Step 2.1 Text Chunking

Item	Description
Input	Raw document collection
Operation	Segment text by fixed token size (default chunk size = 1200)
Key decision	Chunk size fixed at 1200, consistent with GraphRAG and other baselines for fair comparison
Output	Text Chunks

Step 2.2 Entity and Relation Extraction

Item	Description
Input	Text Chunks
Operation	LLM extracts entities and relations from each chunk
Key decision	Uses LLM (default GPT-4o-mini) for extraction; gleaning parameter fixed at 1
Output	Entity set + relation set

Step 2.3 Key-Value Pair Generation (Core Design)

Item	Description
Input	Extracted entities and relations
Operation	For each entity and relation, LLM generates (K, V) pairs
Key decision	K uses retrieval-friendly words or phrases (not full descriptions); V uses relevant segments from the original document
Output	Entity nodes and relation edges with K-V attributes

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

Item	Description
Input	Entities/relations extracted from each chunk
Operation	Merge duplicate entities and relations, reducing graph scale
Output	Deduplicated knowledge graph

Step 2.5 Incremental Update

Item	Description
Input	New document D’
Operation	Execute the same indexing steps on new documents, generate new graph data, then take the union of node sets and edge sets with the original graph
Key decision	No full rebuild required; union-based merging; stands in stark contrast to GraphRAG’s community structure decomposition and rebuild
Output	Updated knowledge graph

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:

Layer	Applicable Queries	Matching Target	Core Mechanism
Low-Level (Local)	Concrete entity queries (“What is the attribute of X?”)	Entity Nodes	Vector similarity matches entity nodes → expand neighbors
High-Level (Global)	Abstract concept queries (“What are the overall trends of X?”)	Relation Edges	Vector similarity matches relation edges → expand neighbors

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:

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

Decision Point	LightRAG’s Choice	Alternative	Rationale
Index structure	Graph + key-value pairs	Pure vector index / text chunk index / community summaries	K-V balances retrieval efficiency and provenance capability, outperforming pure embedding matching and chunk traversal
Dual-layer retrieval	Low-Level(entity) + High-Level(relation)	Single-layer unified retrieval	Simultaneously covers concrete fact queries and abstract association queries
Neighbor expansion	One-hop neighbors only	Multi-hop traversal / no expansion	One-hop neighbors balance quality and efficiency, avoiding over-expansion that introduces noise
Incremental update	Union merging (node set + edge set)	Full rebuild (e.g., GraphRAG)	No need to decompose existing structure, significantly reducing update cost in dynamic environments
Deduplication strategy	Simple deduplication to reduce graph scale	Semantic similarity merging / entity alignment	Keeps things simple and efficient; lightweight deduplication is sufficient for optimization

6. Evaluation

6.1 Evaluation Metrics

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

Metric	Meaning	LightRAG vs Baseline
Comprehensiveness	Topical coverage of answers	Superior to chunk-based methods, comparable to or better than GraphRAG
Diversity	Diversity of viewpoints/angles in answers	Significant advantage (against all baselines)
Empowerment	Degree to which answers help users	Superior to chunk-based methods
Overall	Composite score	Superior to GraphRAG and all chunk-based baselines

6.2 Comparative Experimental Setup

Condition	Description
LightRAG	Full system (graph + vector + dual-layer retrieval)
GraphRAG	Graph RAG baseline (community summaries + Map-Reduce)
NaiveRAG	Traditional vector RAG baseline
HyDE	Hypothetical document embedding baseline
RQ-RAG	Query rewriting RAG baseline

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

Variant	Modification	Result
-Low-Level	Remove low-level retrieval module	Performance drops
-High-Level	Remove high-level retrieval module	Performance drops
-Origin	Do not use original text in retrieval, rely only on graph structure	No significant drop on most datasets; some even improve (Agriculture, Mix)

-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

Limitation	Specific Manifestation	Mitigation
Extraction quality depends on LLM	Entity and relation extraction quality directly determines graph quality, affecting retrieval performance	Use stronger LLMs; increase gleaning iterations
Incremental update simple merging	Union-based update does not handle entity conflicts, relation contradictions, or stale data	Periodic full rebuilds; introduce conflict detection mechanisms
Neighbor expansion depth fixed	Only one-hop neighbor expansion, may be insufficient for complex queries requiring multi-hop reasoning	Configurable expansion depth; combine with iterative retrieval
Limited evaluation scope	Mainly validated on UltraDomain benchmark; domain coverage is broad but not comprehensive	Validate on more real-world scenarios and vertical domains

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

What You Want to Know	See Which Section
What is the complete pipeline?	0. Execution Overview
How is the index constructed?	2. Offline Construction
How does dual-layer retrieval work?	3. Online Query
Incremental update mechanism?	2.5 Incremental Update
Difference from GraphRAG?	5. Key Design Decisions + 2.5 Incremental Update
How does it perform?	6. Evaluation
When should it NOT be used?	7. Limitations and Applicability

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

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

Item	Description
Input	Raw document collection
Operation	Split text into fixed token-size chunks
Key decision	Larger chunks → fewer LLM calls (cost savings), but recall of early information within chunks decreases
Output	Text Chunks

Step 1.2 Entity and Relation Extraction

Item	Description
Input	Text Chunks
Operation	LLM extracts entities, relations, and claims from each chunk
Output	Entities & Relationships

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:

Version	Implementation	Principle
Before v2.2.0	`logit_bias=100`	Adds +100 bias to logits of “Y”/”N” tokens, forcing output of only Y or N at probability level
After v2.2.0	Pure Prompt	Uses instruction “Please answer with a single letter Y or N” (because o-series reasoning models do not support logit_bias)

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

Item	Description
Input	Entities/relations extracted from each chunk
Operation	Exact string matching for entity alignment (merge different expressions of the same entity)
Error tolerance	Duplicate entities are typically clustered into the same community in subsequent steps, with limited impact on results
Output	Knowledge Graph (nodes = entities, edges = relations)

Step 1.4 Community Detection (Hierarchical)

Item	Description
Input	Knowledge Graph
Operation	Leiden algorithm recursively detects communities: large graph → sub-communities → sub-sub-communities… until no further division (leaf communities)
Output	Hierarchical Graph Communities (C0 = top-level full graph, C1, C2, C3… increasingly fine-grained)

Step 1.5 Community Summary Generation (Core Pre-computation)

Item	Description
Input	Hierarchical community structure
Operation	Bottom-up recursive generation: leaf community summaries → use leaf summaries to generate parent summaries → layer by layer upward
Summary content	Comprehensive description of entities, relations, and claims within the community
Output	Community Summaries (one report-style summary per community)

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:

Mode	Applicable Query	Context Source	Core Mechanism	Cost
Global Search	“What are the main themes in the dataset?”	Community reports (full load)	Map-Reduce + LLM scoring and filtering	Medium
Local Search	“What are the attributes of entity X?”	Entity neighborhood + graph structure	Vector retrieval of entities → graph traversal to expand neighbors → mixed context	Medium
DRIFT Search	Complex multi-hop reasoning questions	Iterative graph exploration	HyDE → Action loop (LocalSearch) → Reduce	High
Basic Search	Simple QA	Raw text chunks	Pure vector retrieval (no graph structure utilization)	Low

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):

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)

Step	Operation	Description
1a. HyDE query expansion	Randomly select a community report as template, have LLM generate hypothetical answer	HyDE (Hypothetical Document Embeddings) strategy
1b. Vector retrieval of community reports	Use embedding of hypothetical answer for cosine similarity, take top-k	`drift_context.py:168-229`
1c. LLM query decomposition	Use structured output to force JSON return	`DRIFT_PRIMER_PROMPT`

PrimerResponse structure:

Field	Meaning
`intermediate_answer`	Intermediate answer based on community reports (2000 characters)
`score`	0-100, match degree between answer and query
`follow_up_queries`	At least 5 follow-up exploration queries

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:

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:

Parameter	Function
`n_depth`	Number of exploration loop rounds (depth)
`drift_k_followups`	Number of actions executed in parallel per round (width)
`primer_folds`	Number of groups to parallelize community report processing in the Primer phase
`local_search_*`	Various parameters for LocalSearch (inherited)
`reduce_*`	Temperature and token limits for the Reduce phase

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

Item	Description
Input	User query + all community summaries at the target level
Operation	① Take all community summaries at that level ② Randomly shuffle order ③ Chunk by preset token size
Purpose	Eliminate order bias + adapt to LLM context window
Output	Shuffled community summary chunks

Step 3.2 Map: Parallelly Generate Intermediate Answers

Item	Description
Input	Each community summary chunk + user query
Operation	Independently call LLM for each chunk: “Based on these community summaries, answer the query”
Key output	① Partial answer (Answer Fragment) ② Helpfulness score (0-100, indicating how helpful this chunk is for answering the target question)
Parallelism	All chunks processed simultaneously
Output	A set of (partial answer, score) pairs

Step 3.3 Reduce: Merge into Global Answer

Item	Description
Input	All (partial answer, score) pairs
Operation	① Sort by helpfulness score ② Concatenate partial answers from high to low ③ Call LLM to synthesize the final answer
Output	Global Answer

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

Decision Point	GraphRAG’s Choice	Alternative	Rationale
Index structure	Graph index + community summaries	Pure vector index / text index	Global questions require understanding entity relations, which pure vector cannot achieve
Community detection	Leiden hierarchical	Single-level communities	Hierarchical supports multi-granularity queries (macro → micro)
Summary generation	Bottom-up recursive	Independent generation per community	Recursive ensures higher-level summaries include lower-level information, avoiding omission
Answer aggregation	Map-Reduce + scoring	Direct concatenation of all summaries	Scoring mechanism filters highly relevant information, controls context length
Entity alignment	Exact string matching	Semantic similarity matching	Simple and efficient; duplicate entities naturally cluster during community detection

5. Evaluation

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

Dimension	Meaning	GraphRAG vs. Vector RAG
Comprehensiveness	Thematic coverage of the answer	Superior
Diversity	Diversity of viewpoints/angles in the answer	Superior
Empowerment	Degree of helpfulness to the user	Superior
Directness	Whether the answer is concise and direct	Inferior (trade-off)

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

Condition	Description
GraphRAG C0/C1/C2/C3	Four different community levels (C0 = top-level, C3 = bottom-level)
TS (Text Summarization)	Direct Map-Reduce summarization on source text (no graph structure)
SS (Semantic Search)	Traditional vector RAG baseline

6. Limitations and Applicability

Limitation	Specific Manifestation	Mitigation
Hierarchical rigidity	Enumerative classification; new categories require index reconstruction	Periodically rebuild index; or use more flexible dynamic community detection
High construction cost	Multiple LLM calls (entity extraction × N + summary generation × M)	Batch processing; caching; select appropriate community level to balance quality/cost
Global query focus	Not optimal for “finding a specific piece of information”	Combine with Local Search or DRIFT Search
Lower Directness	Global summarization may be verbose	Adjust Map-Reduce scoring thresholds; post-processing refinement

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

What You Want to Know	See Which Section
What is the complete pipeline?	0. Execution Overview
How is the index constructed?	1. Offline Construction
How are queries answered?	2. Four Search Modes + 3. Map-Reduce Aggregation
Why is it better than vector RAG?	4. Key Design Decisions + 5. Evaluation
When should it NOT be used?	6. Limitations

【阅】本周阅读摘选2026-05-11 → 2026-05-17

Mon, 11 May 2026 00:00:00 +0000

本周阅读摘选 2026-05-11 → 2026-05-17 目录

学术相关
- PaSa

学术相关

PaSa

One-sentence positioning: An LLM-powered academic literature search agent that autonomously completes search tool invocations, paper reading, and citation expansion through a Crawler-Selector dual-component architecture, optimized via reinforcement learning for complex academic queries.

Key innovation: Models academic search as an agentic decision process, where the Crawler maximizes recall in citation networks and the Selector precisely determines relevance; both components are jointly optimized via the AGILE RL framework, with dedicated synthetic dataset AutoScholarQuery and real-world benchmark RealScholarQuery constructed for training and evaluation.

0. Execution Overview

Offline Phase (one-time training)
  ├─ ① Dataset preparation
  │   ├─ AutoScholarQuery: synthetic academic query-paper pairs (35k), generated by GPT-4o from Related Work
  │   └─ RealScholarQuery: real-world academic query benchmark
  ├─ ② Selector training (SFT)
  │   ├─ Input: academic query + paper
  │   ├─ Output: decision token (True/False) + supporting rationale
  │   └─ Decision token placed before rationale, enabling it to serve as a single-token auxiliary reward model for the Crawler
  └─ ③ Crawler training (SFT → RL)
      ├─ SFT: generate trajectories session by session (Search session / Expand session)
      └─ RL (PPO): token-level MDP, each session independently optimized
         ├─ Action space: [Search] generate query and retrieve / [Expand] extract citations / [Stop] switch to next paper
         ├─ Reward function: α × Σ I(q, p_i, t) − c(a_t)
         └─ Auxiliary reward: Selector as reward model to mitigate sparse rewards

Online Phase (per query)
  ├─ ① Input academic query q
  ├─ ② Crawler iterative execution
  │   ├─ [Search] → generate search query → invoke retrieval tool → add results to paper queue
  │   ├─ [Expand] → extract sub-section citations from current paper → add to paper queue
  │   ├─ [Stop] → switch to next paper in queue
  │   └─ Navigate through citation network, continuously discovering more relevant papers
  ├─ ③ Selector per-paper judgment
  │   ├─ Input: query q + each paper in paper queue
  │   ├─ Output: True/False judgment + rationale
  │   └─ Decision token probability used for ranking search results
  └─ ④ Return final retrieval result set

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

1.1 Indexing

Dimension	Approach
Chunking strategy	—
Index structure	— (relies on external search engine; notes do not explicitly document offline index construction)
Knowledge representation	—
Construction cost	—
Core characteristic	Notes do not document index construction; offline phase focuses on model training and dataset construction

1.2 Retrieval

Dimension	Approach
Retrieval method	Agentic dynamic search (Crawler autonomously decides Search / Expand / Stop)
Retrieval granularity	Paper level (collects entire papers through citation networks)
Iteration strategy	Multi-round iteration (Crawler continuously navigates citation network, expanding paper queue)
Query processing	Model automatically generates search queries based on current context and query
Core characteristic	Crawler-Selector dual-component: Crawler maximizes recall, Selector maximizes precision; RL optimization teaches the agent optimal search strategies

1.3 Generation

Dimension	Approach
Context injection	Selector matches retrieved papers with query, generating True/False judgments and rationales
Citation tracing	Selector outputs rationale supporting its judgment for each paper
Quality control	Dual-component division: Crawler recall + Selector filtering; Selector decision token probability used for result ranking
Core characteristic	Selector serves as single-token reward model, used both for online judgment and as auxiliary reward for Crawler RL training

2. Offline Construction: Training (Detailed Execution)

Step 2.1 Dataset Construction

AutoScholarQuery

Item	Description
Input	Related Work section of each paper
Operation	Use GPT-4o to generate academic queries; answers correspond to references cited in Related Work
Key decision	Synthetic but high-quality dataset, curated for the AI domain
Output	35k query-paper pairs
Quality verification	Sample 100 query-paper pairs to assess reasonableness and relevance

RealScholarQuery

Item	Description
Input	Real-world academic queries
Operation	Collect real academic queries to construct benchmark
Output	Real academic query benchmark for evaluating more realistic scenarios

Step 2.2 Selector Training

Item	Description
Input	Academic query and a paper
Operation	Fine-tune model to generate two outputs: (1) decision token d (True/False); (2) supporting rationale r
Key decision	Decision token placed before rationale, enabling Selector to serve as single-token reward model for Crawler training; token probability can be used for ranking search results
Training config	SFT, 1 epoch, learning rate 1e-5, batch size 4
Output	Trained Selector model

Step 2.3 Crawler Training: Imitation Learning

Item	Description
Input	AutoScholarQuery training data subset
Operation	Generate trajectories session by session for imitation learning
Key decision	Two session types: Search session (starting from state S_q) and Expand session (starting from state S_{q+p})
Search Session	GPT-4o generates search query trajectories based on user query
Expand Session	Given query and retrieved papers, use Google retrieval sampling; check paper sub-sections; citations to training data papers must be included, otherwise 10% probability of random selection to augment diversity
Output	SFT-initialized Crawler policy model

Step 2.4 Crawler Training: Reinforcement Learning

Item	Description
Input	Query q, SFT-initialized policy model π_θ
Operation	Model Crawler as token-level MDP, optimize with PPO
State	Current LLM context + paper queue
Action space	LLM vocabulary; each token represents an action; when action matches function name, execute corresponding function ([Search]/[Expand]/[Stop])
Reward function	r(s_t, a_t) = α × Σ_i=1^n_t I(q, p_i, t) − c(a_t), where I is indicator function for new papers matching query and not in queue
Auxiliary reward	Selector as auxiliary reward model, mitigating sparse reward problem from AutoScholarQuery matching only
Key decision	Independent PPO per session; session defined as sub-trajectory ending with [Stop]; Monte Carlo sampling estimates returns
Total objective	L_RL(θ, φ) = L_policy(θ) + η · L_value(φ)
Output	Trained Crawler policy model

Step 2.5 Model Assembly

Item	Description
Input	Trained Selector and Crawler
Operation	Sequentially train both components; both based on Qwen2.5-7b
Output	Final agent PaSa-7b

3. Online Query: Retrieval (Detailed Execution)

3.1 Retrieval Mode Overview

PaSa uses a single agentic search mode, with the Crawler autonomously navigating through citation networks:

Mode	Applicable Scenario	Core Mechanism	Characteristic
Agentic Search	Complex academic queries	Crawler autonomously Search/Expand/Stop; Selector judges per paper	Learned optimal search strategy, not manually predefined

3.2 Retrieval Procedure

Step 3.1: Crawler Initialization and Execution

Item	Description
Input	User academic query q
Operation	Crawler executes token-level MDP, autonomously deciding the next action
Action [Search]	Generate search query, invoke retrieval tool, add all results to paper queue
Action [Expand]	Extract sub-sections from current paper context, parse all citations and add to paper queue
Action [Stop]	Stop current paper processing, reset context, begin processing next paper in queue
Key decision	Crawler aims to maximize recall of relevant papers, exploring increasingly relevant papers through citation networks
Output	Continuously growing paper queue (potentially containing hundreds or even thousands of papers)

Step 3.2: Selector Judgment and Ranking

Item	Description
Input	Query q + each paper in paper queue
Operation	Selector carefully reads each paper, determining whether it meets query requirements
Output	(1) True/False judgment; (2) supporting rationale; (3) decision token probability for ranking
Key decision	Selector emphasizes precise identification of papers meeting user needs, complementing Crawler’s recall objective

4. Online Generation: Generation (Detailed Execution)

PaSa’s “generation” phase is not traditional RAG answer generation, but rather relevance judgment and ranking of retrieval results through the Selector, ultimately outputting the set of papers satisfying the query.

4.1 Judgment and Ranking Procedure

Input: query q, paper queue Q = {p_1, p_2, ..., p_n} collected by Crawler
    │
    ▼
┌─────────────────────────────┐
│ For each paper p_i in Q     │
│ Call Selector(q, p_i)       │
└─────────────┬───────────────┘
              │
         ┌────┴────┐
         ▼         ▼
      True       False
         │         │
         ▼         ▼
    Retain and   Filter
    rank
    (by decision probability)
         │
         ▼
    Output final paper set

Step 4.1: Relevance Judgment

Item	Description
Input	Query q, paper p_i
Operation	Selector generates decision token d (True/False) and supporting rationale r
Key decision	Decision token probability can be used for ranking search results, enabling fine-grained sorting
Output	Relevance judgment + rationale + ranking score

5. Key Design Decisions

Decision Point	PaSa’s Choice	Alternative	Rationale
System architecture	Crawler-Selector dual-component	Single-component end-to-end	Crawler maximizes recall, Selector maximizes precision; clear division of labor
Training paradigm	RL (AGILE framework, PPO)	SFT / prompt engineering	Optimize PaSa in the AGILE RL framework, teaching the agent optimal search strategies
Crawler training	Imitation Learning + RL two-stage	SFT only / RL only	First generate trajectories for imitation learning, then apply RL
Reward design	Outcome-oriented + Selector auxiliary reward	Sparse matching reward only	AutoScholarQuery matching alone causes sparse rewards; Selector as auxiliary reward model mitigates this
RL optimization granularity	Independent PPO per session	Unified optimization over entire trajectory	Session defined as sub-trajectory ending with [Stop]; each session independently optimized
Selector output	Decision token before rationale + rationale	Rationale before decision token	Decision token placement enables Selector to serve as single-token reward model; probability usable for ranking
Data generation	GPT-4o synthesizes from Related Work	Manual annotation	Generates queries from Related Work sections; answers correspond to cited references

6. Evaluation

6.1 Evaluation Metrics

Metric	Meaning	PaSa vs Baseline
Recall@20	Relevant paper recall in top 20 results	PaSa-7B vs Google with GPT-4o: +37.78%
Recall@50	Relevant paper recall in top 50 results	PaSa-7B vs Google with GPT-4o: +39.90%
Recall	Overall recall	PaSa-7B vs PaSa-GPT-4o: +30.36%
Precision	Precision	PaSa-7B vs PaSa-GPT-4o: +4.25%
F1	Composite F1 score	—

6.2 Comparative Experimental Setup

Condition	Description
PaSa-7B	Full system (Qwen2.5-7b base, SFT + RL training)
Google	Traditional search engine baseline
Google Scholar	Academic search engine baseline
Google with GPT-4o	Google + GPT-4o query rewriting baseline
ChatGPT (search-enabled GPT-4o)	Search-augmented ChatGPT baseline
GPT-o1	OpenAI o1 reasoning model baseline
PaSa-GPT-4o	PaSa baseline implemented by prompting GPT-4o
PaSa w/o RL	No-RL version baseline

6.3 Datasets

Dataset	Description
AutoScholarQuery	Synthetic academic query dataset (35k), for training
RealScholarQuery	Real-world academic query benchmark, for evaluation

7. Limitations and Applicability

Notes do not explicitly document PaSa’s limitations.

Best Applicable Scenarios

Complex academic queries requiring long-tail expertise, comprehensive survey-level coverage, fine-grained queries
Literature retrieval tasks requiring deep exploration within citation networks
Academic search scenarios with high demands on both recall and precision

Unsuitable Scenarios

8. Quick Reference

What You Want to Know	See Which Section
What is the complete pipeline?	0. Execution Overview
High-level design comparison?	1. High-level Design
How is the model trained?	2. Offline Construction
How is retrieval executed?	3. Online Query
How is relevance judged?	4. Online Generation
Why is it designed this way?	5. Key Design Decisions
How does it perform?	6. Evaluation
When should it NOT be used?	7. Limitations and Applicability

【阅】本周阅读摘选2026-04-27 → 2026-05-03

Mon, 04 May 2026 00:00:00 +0000

本周阅读摘选 2026-04-27 → 2026-05-03 目录

学术相关

学术相关

近期梳理的一些RAG相关的综述笔记，具体内容由claude code基于笔记内容生成 Information Retrieval, RAG, and Intelligent Literature Systems: A Technical Survey

1. A Brief Review of Traditional Information Retrieval

Modern large-scale information retrieval (IR) systems almost universally adopt a retrieval + ranking two-stage pipeline (retrieve-then-rerank architecture), achieving a fundamental balance between efficiency and effectiveness [Hambarde et al., 2023; Xu et al., 2025].

1.1 The Evolution of Retrieval Methods

Retrieval methods have evolved from term-based matching to semantic vector-based approaches, which can be summarized into four categories:

Category	Core Idea	Representative Methods
Traditional	Term matching, query expansion, topic models	TF-IDF, BM25, Query Expansion, Topic Model
Sparse	Represent documents/queries as sparse vectors, activating few dimensions	Neural weight prediction, document expansion, BM25 variants
Dense	Encode queries and documents as dense vectors, retrieve via vector similarity	Word2Vec, Sentence-BERT, DPR, ColBERT
Hybrid	Combine the strengths of sparse and dense representations	SPLADE, ColBERT, and other late-fusion schemes

To enhance retrieval effectiveness, researchers have proposed two augmentation strategies. Query Augmentation enriches the query representation on the query side through expansion, reformulation, and feedback, but is subject to query drift and overfitting risks [Hambarde et al., 2023]. Document Augmentation augments or semantically rewrites indexed content on the document side to narrow the semantic gap between queries and documents.

1.2 The Evolution of Ranking Methods

The ranking stage is responsible for fine-grained relevance scoring of candidate documents returned by retrieval, and has similarly undergone a transformation from traditional methods to deep learning approaches:

Category	Description	Representative Methods
Learning-to-Rank	Classified by loss function into pointwise / pairwise / listwise	LambdaRank, LambdaMART
Representation-based	Encode query and document separately, compute global similarity	DSSM, Siamese Network
Interaction-based	Model query-document term-level interactions before scoring	DRMM, BERT-based Re-ranker
Hybrid	Combine the efficiency of representation-based with the accuracy of interaction-based, dual-network parallel	DUET

The introduction of continuous vector representations enabled text ranking to transcend the ceiling of exact term matching, while neural networks eliminated the need for manual feature engineering [Hambarde et al., 2023]. In practical systems, representation-based models typically pre-encode documents into vectors during offline stages, making them suitable for efficient initial retrieval; interaction-based models jointly process queries and documents during the online stage, achieving deeper and more precise relevance matching but at higher computational cost, making them better suited for re-ranking a smaller set of candidate results [Xu et al., 2025]. Recognizing the complementary strengths of these two architectures, researchers further proposed hybrid models that combine the efficiency of representation-based methods with the effectiveness of interaction-based methods [Xu et al., 2025].

1.3 Pre-trained Transformers and the Representation Learning Revolution in IR

The advent of pre-trained Transformers has further reshaped IR model architectures. By network structure, they can be broadly categorized into three types:

Architecture	Representative Models	Characteristics
Encoder-only	BERT (Cross-Encoder)	Deep interaction, high ranking quality, but computationally expensive
Encoder-decoder	T5, BART	Balances understanding and generation capabilities
Decoder-only	GPT series	Strong generation capability

To bridge the effectiveness gap between efficient Bi-Encoders and powerful Cross-Encoders, Knowledge Distillation (KD) has been widely adopted in the IR domain. However, regardless of architectural evolution, retrieval systems always face a fundamental trade-off between effectiveness (recall, MRR, nDCG) and resource efficiency (latency, throughput, memory footprint, indexing and update costs). While neural retrievers can significantly improve effectiveness, they require additional computational and indexing engineering investment. Furthermore, Calibration mechanisms aim to align model output scores with true relevance probabilities, ensuring that confidence scores faithfully reflect correctness.

At this point, information retrieval has fully entered the representation learning era of deep learning. Pre-trained models have endowed retrieval systems with powerful semantic understanding capabilities, yet the fundamental paradigm remains user issues a query → system returns a ranked list of relevant documents. The emergence of large language models is poised to fundamentally alter this paradigm.

2. IR Systems in the LLM Era: The Technical Evolution Path of RAG

The fundamental paradigm of traditional information retrieval systems is to return a ranked list of relevant documents in response to user queries; the system itself is not responsible for understanding document content and generating coherent answers. Large Language Models (LLMs), while possessing powerful language understanding and generation capabilities, exhibit significant limitations when relying solely on their internal parametric knowledge. This complementarity gave rise to Retrieval-Augmented Generation (RAG), which combines the external knowledge acquisition capability of IR with the text generation capability of LLMs, forming an entirely new information processing paradigm.

2.1 Why RAG Is Needed

Before RAG, the field of information access went through two major phases, each with fundamental shortcomings.

Limitations of Pure LLMs (Chatbot Mode). When LLMs rely solely on parametric knowledge learned during pre-training to answer user queries, they face three core challenges: first, hallucination, where the model may generate plausible but inaccurate content; second, lack of timeliness, as the model has no knowledge of events beyond its training data cutoff and cannot provide up-to-date information; and third, context window limitations, where even with massive parameter counts, the context length the model can process in a single pass remains limited (typically 2K–32K tokens), making it difficult to comprehensively understand complex queries requiring integration of extensive background knowledge [Zhang et al., 2025b].

Limitations of Traditional IR Systems. While traditional search engines or retrieval systems can return large volumes of relevant documents based on indexing, their responsibility ends there — they are designed to “find” information, not to “understand” and “answer.” After obtaining a document list, users must still read, screen, and synthesize on their own to form a complete answer. For complex questions requiring cross-document correlation analysis or synthetic reasoning, the cognitive burden of this process is extremely high.

The Core Motivation of RAG. The central idea of RAG is Retrieve-then-Read: first use a retrieval system to retrieve relevant document fragments from an external knowledge base, then concatenate these retrieved texts as context into the LLM’s input prompt, guiding the model to generate responses based on these external factual inputs. This approach leverages the powerful language understanding and generation capabilities of LLMs while harnessing the retrieval system to ensure the factuality and timeliness of responses, simultaneously alleviating hallucination to some extent [Zhang et al., 2025b; Gao et al., 2024].

2.2 Naive RAG: The Simplest Form

The most rudimentary implementation of RAG is exceedingly straightforward: a user query enters the system, relevant fragments are retrieved from the document collection via keyword matching (such as TF-IDF or BM25), these fragments are concatenated with the original query to form a prompt, which is then passed to the LLM to generate a final answer. This design is conceptually clear and easy to implement, and can achieve reasonable results for simple factual question answering.

However, this naive “one-shot retrieval + direct generation” architecture quickly reveals its fragility in complex scenarios: the retrieval stage may return insufficiently relevant fragments due to inherent limitations in similarity computation; the generation stage struggles to deeply integrate retrieved content with the query, as multi-source similar information tends to produce redundancy or incoherent content; and the entire pipeline is static and linear, lacking the ability to adjust based on intermediate results [Gao et al., 2024]. These limitations prompted researchers to explore more advanced RAG variants.

2.3 The Technical Evolution Path of RAG

From the historical perspective of information retrieval, the way humans access information has evolved from Web Search (static keyword-based search) to LLM as Chatbot (pure parametric knowledge generation) to LLM with RAG (retrieval-augmented generation), and is now advancing toward Multi-hop Retrieval (iterative multi-hop retrieval) and Deep Research [Zhang et al., 2025b]. Deep Research emphasizes a dynamic feedback loop between reasoning and search: the reasoning process actively influences search strategies (e.g., refining queries based on intermediate deductions), while retrieved information in turn recursively refines the reasoning process.

From a technical perspective, the evolution of RAG can be summarized as a clear five-stage progression [Gao et al., 2024]:

Naive RAG → Advanced RAG → Modular RAG → Graph RAG → Agentic RAG

Stage	Key Characteristics	Core Improvements	Limitations
Naive RAG	Keyword retrieval (TF-IDF, BM25), results directly concatenated to prompt	Simple architecture, easy to implement	Lacks context awareness, fragmented output, limited scalability
Advanced RAG	Introduces dense vector retrieval models, vector search, context re-ranking, multi-hop iterative retrieval	Significantly improves retrieval quality and context relevance	Increased computational overhead, scalability still limited
Modular RAG	Decouples retrieval, ranking, and generation into independent reusable modules, supports hybrid retrieval strategies and external tool integration	Substantially improved system flexibility and scalability	Inter-module collaborative optimization still requires manual design
Graph RAG	Leverages graph node connectivity and edge relations to organize knowledge, enabling hierarchical knowledge management and structured navigation	Supports cross-document correlation, multi-hop reasoning, and global context understanding	High graph construction cost, scalability limited by graph scale, reliance on high-quality data
Agentic RAG	Introduces autonomous agents for iterative query refinement, adaptive retrieval strategy selection, and dynamic workflow orchestration	Possesses multi-step reasoning and autonomous decision-making capabilities	High coordination complexity, significant computational overhead, increased latency

Meanwhile, Li et al. (2025), from the perspective of the interplay between RAG and Reasoning, proposed a higher-level framework that categorizes their integration into three paradigms:

Paradigm	Core Idea	Direction
Reasoning-Enhanced RAG	Leverages reasoning capabilities to optimize RAG’s retrieval, integration, and generation stages	Reasoning → RAG
RAG-Enhanced Reasoning	Leverages external knowledge from retrieval to enhance LLM reasoning capabilities	RAG → Reasoning
Synergized RAG-Reasoning	Deep coupling of retrieval and reasoning, iterative alternating execution, forming a dynamic feedback loop	RAG ↔ Reasoning

These three paradigms reveal that RAG is not merely about “attaching an external retriever to an LLM,” but rather a process of continuous integration and mutual enhancement between retrieval and reasoning capabilities. Early RAG systems primarily belonged to the first two unidirectional enhancement modes, while current frontier trends are advancing toward the third mode of deep synergization.

2.4 Core Limitations of RAG

Despite continuous advances in RAG technology, traditional RAG systems (primarily Naive and Advanced RAG) face fundamental challenges across multiple dimensions. Synthesizing findings from multiple surveys, these limitations can be summarized along three dimensions:

Retrieval Dimension. A single retrieval pass cannot guarantee acquisition of all relevant information needed to resolve a query, and assessing the relevance of retrieval results is itself challenging. When queries involve complex knowledge requiring synthesis across multiple data sources, simultaneously satisfying the sufficiency and accuracy of retrieval becomes difficult [Li et al., 2025; Gao et al., 2024]. Furthermore, deep-seated limitations at the embedding level — including biases in training data leading to high-frequency task/language/domain preferences, poor performance of general-purpose corpus models in specialized domains (e.g., biomedicine, scientific literature), and insufficient capture of long-range structural information — further constrain the upper bound of retrieval quality [Zhang et al., 2025c].

Reasoning Dimension. Traditional RAG lacks genuine multi-step reasoning capabilities. The system cannot dynamically refine retrieval strategies based on intermediate insights or user feedback, making it difficult to handle tasks requiring complex logical chains and deep contextual understanding [Singh et al., 2026; Li et al., 2025]. Errors in early reasoning paths may propagate through subsequent steps, affecting the completeness of the final output [Zhang et al., 2025b]. Additionally, models struggle to maintain fidelity to retrieved evidence when conflicts arise between external retrieved evidence and internal parametric knowledge.

System Dimension. RAG pipelines are typically static and linear, lacking adaptive adjustment mechanisms, making it difficult to accommodate queries of varying complexity and dynamically updating knowledge bases [Li et al., 2025; Singh et al., 2026]. The entire workflow — from preprocessing and index construction to real-time retrieval and generation — faces efficiency bottlenecks in large-scale deployment [Zhang et al., 2025b]. Moreover, effectively integrating similar information retrieved from multiple sources, avoiding redundant output while ensuring stylistic and tonal consistency of generated content, remains a persistent practical challenge [Gao et al., 2024].

The Emergence of Enhanced Retrieval Modes. To overcome the limitations of single-pass retrieval, researchers proposed three enhanced retrieval modes [Gao et al., 2024]: Iterative Retrieval gradually enriches context through multiple retrieval-generation cycles; Recursive Retrieval progressively decomposes complex problems for deeper retrieval; and Adaptive Retrieval dynamically controls retrieval and generation behavior on demand. While these ideas had preliminary exploration in the first two generations of RAG, their potential was far from fully realized due to the static nature of system architecture. True breakthroughs came from two directions: first, using graph structures to explicitly model knowledge associations (Chapter 3, Graph-based RAG); and second, using autonomous agents to dynamically orchestrate retrieval and reasoning processes (Chapter 4, Agentic Search).

3. Graph-based RAG

When RAG needs to handle cross-document correlation, multi-hop reasoning, and global knowledge integration, traditional text-fragment-based indexing and retrieval methods face structural limitations. Graph-based RAG elevates RAG from “retrieving text fragments” to “navigating and reasoning within structured knowledge networks” by introducing graph structures to explicitly model inter-knowledge associations.

3.1 Definitions and Taxonomy of Graph-based RAG

3.1.1 Text-Attributed Graphs and Formal Definition

Graph-based RAG uniformly represents graph data as Text-Attributed Graphs (TAGs) [Peng et al., 2024]:

\[G = (V, E,\{x_v\}_{v\in V}, \{e_{i,j}\}_{i,j \in E})\]

where $V$ is the node set, $E \subseteq V \times V$ is the edge set, $A$ is the adjacency matrix, and ${x_v}$ and ${e_{i,j}}$ are the text attributes of nodes and edges, respectively. The objective of Graph-based RAG is to find the optimal answer $a^*$ given a query $q$ and a TAG $G$:

\[a^* = \arg\max p(a|q, G)\]

Through joint modeling, the generation probability of the answer can be decomposed as the product of the probability of retrieving a subgraph and the probability of generating an answer based on that subgraph:

\[p(a|q, G) \approx p_\phi(a|q, G^*)p_\theta(G^*|q, G)\]

3.1.2 Three-Category Taxonomy

Based on the role the graph plays in the RAG system, Graph-based RAG can be classified into three types [Zhang et al., 2025a]:

Type	Core Idea	Characteristics
Knowledge-based	Graph as knowledge carrier	Explicitly models domain knowledge and semantic relations; understands complex relations through graph transformations
Index-based	Graph as indexing tool	Organizes raw text through graphs; optimizes retrieval and global navigation
Hybrid	Combines strengths of both	Provides more advanced solutions for complex reasoning tasks

Graph-based RAG systems can reduce token usage by 26% to 97% compared to conventional methods when generating answers, with significant improvements in both speed and resource utilization [Zhang et al., 2025a].

3.2 The Three-Stage Workflow of Graph-based RAG

The workflow of Graph-based RAG can be summarized as three core stages: G-Indexing (graph-based index construction), G-Retrieval (graph-guided retrieval), and G-Generation (graph-enhanced generation) [Peng et al., 2024; Zhang et al., 2025a; Huang et al., 2026]. Rich optimization methods exist before and after each stage, enabling systematic improvement of retrieval and generation quality.

3.2.1 G-Indexing: Graph-based Index Construction

Pre-indexing: Data Preprocessing and Index Optimization

Index quality is directly determined by the effectiveness of raw data processing. Before constructing the graph index, systematic preprocessing and optimization of the data are required [Huang et al., 2026; Gao et al., 2024]:

Optimization Direction	Specific Methods	Description
Data Cleaning	Remove irrelevant/redundant information, supplement additional information	Improves index purity, reduces noise interference
Document Segmentation	Sliding Window, Fine-grained Segmentation	Balances context completeness with index granularity
Metadata Augmentation	Metadata Incorporation	Enriches index information with metadata, supporting subsequent filtering and routing

These preprocessing techniques establish the data foundation for subsequent graph index construction.

Index Method Taxonomy

Based on the degree of graph structure preservation, indexing methods can be classified into four categories [Peng et al., 2024; Zhang et al., 2025a]:

Method	Characteristics	Algorithms
Graph Indexing	Preserves complete graph structure	BFS, Shortest Path
Text Indexing	Converts graph data into text descriptions	Sparse Retrieval, Dense Retrieval
Vector Indexing	Converts to vector representations for efficiency	LSH (Locality Sensitive Hashing)
Hybrid Indexing	Combines all three approaches	—

Beyond graph indexing, Graph-based RAG can additionally leverage hierarchical index structures to establish multi-granularity retrieval support for documents, as well as knowledge graph indexing that uses knowledge graphs to organize document relations and enable structured navigation [Gao et al., 2024].

Knowledge Graphs as Structural Indices

In Graph-based RAG, knowledge graphs serve not merely as a knowledge representation form but as a powerful structural indexing mechanism for organizing inter-document relations and supporting structured navigation [Peng et al., 2024; Zhang et al., 2025a].

KG Construction Challenges. At the knowledge graph construction level, different scenarios face distinct challenges. Domain-specific corpora face a triple challenge: complex knowledge dependencies (domain knowledge progresses from foundational to advanced concepts layer by layer, requiring cross-reference analysis), domain specificity (dense technical terminology and abbreviations), and limited reference knowledge (private technical documents are difficult to obtain externally) [Sun et al., 2025]. For general-purpose knowledge graphs, Li et al. (2026) note that while LLM pipelines can extract entities and relations at scale, the resulting graphs often lack a shared schema, with entity types and relation vocabularies being ad hoc. To address this, ontology-oriented construction methods emphasize building schema as a first-class resource for downstream tasks from the outset, rather than as a byproduct of graph construction.

Two-View KG: The Ontological Dual-Layer Architecture

The Two-View KG concept proposed by Hao et al. (2019) reveals the ontological dual-layer architecture of knowledge graphs, simultaneously representing two complementary views:

Ontology View: The abstract concept layer, defining types, relation schemas, and other meta-knowledge
Instance View: The concrete entity layer, containing actual fact triples

Between the two views exist cross-view links that connect ontological concepts with their instantiated entities, while satisfying mutual disjointness constraints (the entity vocabulary set and concept vocabulary set are disjoint, as are the relation set and meta-relation set). This dual-layer structure provides Graph-based RAG systems with navigation paths from abstract concepts to concrete instances, enabling the system to both understand high-level semantic patterns and locate specific knowledge details.

Yeom et al. (2024) further note that a large number of knowledge graphs are essentially Two-View KGs: abstract classes in the ontology view form tree-like hierarchical structures through class inheritance, while concrete entities in the instance view are instantiated from ontological classes. This structured dual-layer representation holds significant value for Graph-based RAG tasks that must simultaneously leverage abstract concept reasoning and concrete fact verification.

3.2.2 G-Retrieval: Graph-Guided Retrieval

Pre-retrieval: Query Optimization

Before formal retrieval, the system can optimize queries through various means to improve retrieval effectiveness [Gao et al., 2024; Huang et al., 2026]:

Category	Sub-category	Description
Query Expansion	Multi-Query	Generates multiple related queries to expand retrieval coverage
	Sub-Query	Decomposes complex queries into sub-queries
	CoVe (Chain-of-Verification)	Verification chain expansion, progressively confirms query completeness
Query Transformation	Query Rewrite	Rewrites queries to improve retrieval effectiveness
	Query Routing	Routes queries to different processing paths based on query characteristics (via metadata filtering or semantic similarity)

Additionally, RRR (Rewrite-Retrieve-Read) uses dedicated small language models for query rewriting, with some methods further introducing external adapters to assist retriever-generator alignment [Gao et al., 2024]. Query optimization essentially clarifies and expands information needs before retrieval, reducing the semantic gap between queries and the index.

Retriever Types

By degree of parameterization, retrievers can be classified into three categories [Peng et al., 2024]:

Non-parametric Retriever: High retrieval efficiency, no training required
LM-based Retriever: E.g., fine-tuned RoBERTa models, balancing semantic understanding with efficiency
GNN-based Retriever: Leverages graph neural networks to capture structural information, but with higher computational cost

Retrieval Techniques

By the mode of interaction between queries and graph data, retrieval techniques can be classified into three categories [Zhang et al., 2025a]:

Type	Core Idea	Representative Methods
Semantics Similarity-based	Models similarity in discrete space (substring matching, regex) or embedding space (TF-IDF, Word2Vec)	Substring matching, TF-IDF, Word2Vec
Logical Reasoning-based	Uses rule mining, inductive logic programming, constraint satisfaction to reveal implicit insights	Rule Mining, ILP, Constraint Satisfaction
GNN-based	Uses graph neural networks for graph modeling and mining	GCN, GAT

While semantic similarity methods are simple to implement, they cannot fully exploit graph structure information, resulting in significant underestimation of the inherent advantages of graph databases [Zhang et al., 2025a].

Retrieval Paradigms and Granularity

Retrieval paradigms include Once Retrieval, Iterative Retrieval (with non-adaptive and adaptive variants), and Multi-Stage Retrieval [Huang et al., 2026]. Retrieval granularity spans four levels: Nodes, Triplets, Paths, and Subgraphs. The goal of granularity optimization is to balance relevance with efficiency: coarse-grained units provide richer context but may introduce redundancy and noise; fine-grained units are more semantically focused but may lack completeness and increase retrieval burden [Zhang et al., 2025a].

Retrieval Augmentation

To enhance retrieval, the system can perform Query Enhancement (query expansion, query decomposition) before retrieval or Knowledge Enhancement (knowledge merging, knowledge pruning) after retrieval.

Post-retrieval: Re-ranking and Context Compression

After retrieval and before generation, the retrieval results typically require processing to improve final generation quality [Gao et al., 2024]:

Reranking: Fine-grained relevance scoring of retrieved candidate results
Context Compression: Removing redundant information and compressing retrieval results to a context length suitable for LLM processing

Redundant information disrupts LLM generation quality, while excessively long contexts may cause the LLM to exhibit the “Lost in the Middle” problem — difficulty effectively utilizing information in the middle portions of long contexts [Gao et al., 2024].

3.2.3 G-Generation: Graph-enhanced Generation and Knowledge Integration

Knowledge Integration

Retrieved graph data must be transformed into natural language responses through appropriate generation strategies. G-Integration (knowledge integration) is the process of effectively fusing retrieval results with LLM generation capabilities. Zhang et al. (2025a) summarize the conventional RAG pipeline as comprising three core components: knowledge organization, knowledge retrieval, and knowledge integration. Knowledge integration occupies the pre-generation stage, and its quality directly impacts the accuracy and coherence of the final answer.

Generation Paradigms

Graph-enhanced generation can be categorized into three types [Peng et al., 2024]:

Type	Paradigm	Description
GNNs	—	First processes graph data with GNNs, encapsulating structural and relational information for LM comprehension
LMs	—	Language models generate the final text response
Hybrid	Cascaded Paradigm	Models sequentially process different aspects of the data
Hybrid	Parallel Paradigm	Models simultaneously receive inputs, process collaboratively; outputs merged via rules or another model

Generation Control: Context-Aware and Grounded Constraints

During generation, the system can actively control output quality through reasoning capabilities [Li et al., 2025]:

Control Direction	Description	Representative Methods
Context-Aware Generation	Selectively utilizes context, avoids interference from irrelevant information	Open-RAG, RARE, Self-Reasoning
Grounded Generation Control	Fact verification, citation generation, ensures output fidelity to retrieval evidence	RARR, TRACE, AlignRAG

Post-generation: Iterative Refinement and Verification

Generation is not the endpoint. Through Test-Time Scaling, the system can further refine output quality after generation [Zhang et al., 2025a]:

Iterative Self-Refinement: Multiple rounds of self-improvement, progressively correcting errors in generated content [Madaan et al., 2023]
Self-Consistency Decoding: Consistency verification across multiple decoding paths to select the most reliable answer [Hao et al., 2023]

These methods transform generation from a one-shot output into an iteratively optimizable process, which is particularly important in complex reasoning tasks.

3.3 Applicability of Graph-based RAG: When Are Graph Structures Needed?

Not all tasks require introducing graph structures. Xiang et al. (2026) systematically compared vanilla RAG and Graph-based RAG across different task complexity levels through GraphRAG-Bench, proposing a series of key observations.

3.3.1 Task Complexity and the Graph-based RAG Advantage Threshold

Observation	Core Conclusion	Task Type
Obs.1	Basic RAG and Graph-based RAG perform comparably on simple factual retrieval tasks	Simple factual retrieval
Obs.2	Graph-based RAG excels in complex tasks	Complex reasoning
Obs.3	Graph-based RAG ensures higher factual reliability in creative tasks	Creative generation
Obs.4	RAG is adept at extracting discrete facts from simple questions not requiring complex logic	Simple QA
Obs.5	As questions grow increasingly complex, the advantage of Graph-based RAG becomes evident	Increasing complexity

RAG performs excellently in scenarios requiring rapid access to discrete information, while Graph-based RAG excels at tasks requiring nuanced understanding of interconnected data [Xiang et al., 2026].

In terms of retrieval performance, a trade-off exists: Global Graph-based RAG achieves superior Evidence Recall (83.1%), accessing more relevant information; whereas RAG achieves superior Context Relevance (78.8%), with more focused retrieval results and less redundancy. This indicates that while Graph-based RAG retrieves broader information, its retrieval method inevitably introduces some redundancy [Xiang et al., 2026].

Additionally, different Graph-based RAG implementations produce index graphs with significant structural differences; compared to vanilla RAG, Graph-based RAG substantially increases prompt length, with prompt length exhibiting a clear upward trend as task complexity increases.

3.3.2 Practical Implications

Based on the above empirical findings, four scenario-specific recommendations can be summarized:

Simple Factual Retrieval: Vanilla RAG is sufficient; there is no need to incur the additional overhead of Graph-based RAG.
Complex Reasoning / Multi-hop Queries: Graph-based RAG offers clear advantages; graph structures can explicitly model cross-document associations.
Creative Generation: Graph-based RAG provides higher factual reliability, but attention must be paid to the trade-off between retrieval redundancy and context relevance.
Efficiency-Sensitive Scenarios: Prompt inflation in Graph-based RAG is a significant constraint, particularly in long-context or token-constrained environments.

4. Agentic Search

Core Paradigm Shift: From Fixed Pipelines to Autonomous Multi-turn RAG

	Traditional RAG	Agentic Search
Retrieval Turns	Single turn	Multi-turn
Retrieval Timing	Fixed (one retrieval before generation)	Dynamic (triggered on-demand during reasoning)
Query Construction	Raw query used directly	Agent dynamically constructs based on intermediate reasoning
Decision-Making Entity	Predefined workflow	LLM autonomous decision-making
Typical Paradigm	Retrieve → Generate	Reason ⟷ Retrieve ⟷ Reason ⟷ … → Generate

4.1 Definition and Core Components

The core characteristics of Agentic Search include: autonomous reasoning — the agent dynamically plans and adjusts its approach based on intermediate results rather than following preset patterns; on-demand retrieval — dynamically triggered based on uncertainty or information needs during the reasoning process; and iterative synthesis — retrieved information recursively refines reasoning, forming a feedback loop where reasoning and retrieval mutually reinforce each other.

The system comprises four core components:

Component	Function
LLM	Core reasoning engine, providing role definition and task understanding capabilities
Memory	Short-term memory maintains current reasoning context; long-term memory stores cross-session knowledge and preferences
Planning	Dynamically plans task step sequences through Reflection and Self-Critique
Tools	Retrieval backends (Dense RAG, GraphRAG, web search, etc.) form core infrastructure; additionally includes external capabilities such as API calls

Planning is the core differentiating component of Agentic Search. While traditional RAG follows a fixed “retrieve-then-generate” pattern, agents through Planning capability can autonomously decompose complex problems, prioritize information needs, and adjust strategies based on feedback during execution, transforming retrieval from passive data supply into an active reasoning resource.

4.2 Workflow Patterns: From Linear Reasoning to Graph-structured Exploration

The workflow design of Agentic Search determines how the system handles complex queries. From the macro control logic perspective, Singh et al. (2026) summarize five general patterns: Prompt Chaining (improving accuracy through sequential processing), Routing (routing to different processing strategies based on input characteristics), Parallelization (processing independent sub-tasks in parallel), Orchestrator-Workers (dynamically assigning tasks to worker threads), and Evaluator-Optimizer (iteratively evaluating and optimizing outputs).

Li et al. (2025), from the reasoning structure perspective, categorize workflows into theoretically more significant classes:

Workflow Type	Structural Characteristics	Representative Methods	Advantages	Limitations	Applicable Scenarios
Chain-based	Linear sequence, one retrieval per reasoning step	IRCoT, Rat, CoV-RAG, RAFT	Low latency, low token cost, easy caching	Error propagation, rapid context growth	Single-hop or short multi-hop QA
Tree-based (ToT)	Parallel exploration of multiple branches to hedge early errors	RATT, Tree of Clarifications, AirRAG	High recall, transparent hypothesis analysis	Quadratic cost, multiple retrieval calls	Ambiguous or multi-path tasks
Tree-based (MCTS)	Budget-aware exploration, focusing on promising branches	MCTS-RAG, SeRTS	Graceful anytime stopping	Parameter-dependent, may converge to suboptima	Deep search under strict budgets
Graph-based (Walk-on-Graph)	Efficient walks on explicit KG/document graphs	QA-GNN, LightRAG	Efficient on KGs, short paths	Requires high-quality KG, limited flexibility	Domain QA with existing KGs
Graph-based (Think-on-Graph)	LLM dynamically updates evidence graph, adaptive and verifiable	ToG, ToG-2.0, Graph-CoT	Node-level citation checking, high accuracy	High latency, search space explosion risk	Open-domain deep research

Chain-based methods, exemplified by Chain-of-Thought (CoT), structure reasoning into linear sequences of intermediate steps. However, relying solely on LLM parametric knowledge readily leads to error propagation, where small deviations at each step are amplified in subsequent steps. Tree-based methods hedge early errors through parallel exploration of multiple branches; Tree-of-Thought (ToT) allows multiple hypotheses to coexist and be evaluated simultaneously, while Monte Carlo Tree Search (MCTS) focuses exploration on the most promising branches through budget-aware strategies.

Graph-based methods represent deeper reasoning-retrieval coupling. Walk-on-Graph methods primarily rely on graph learning techniques for retrieval and reasoning, including GNNs (leveraging graph neural networks for graph modeling and retrieval reasoning) and lightweight graph techniques (vector indexing, PageRank, and other link-structure-based ranking methods). Think-on-Graph methods embed graph structures directly into the LLM reasoning loop, enabling the LLM to serve as a “reasoning field” on the graph, dynamically deciding which connected entity or relation to explore next, progressively constructing paths to the answer. The significant advantage of this approach lies in node-level citation checking and higher accuracy, at the cost of higher latency and potentially exploding search spaces.

4.3 Agent Orchestration and Training Paradigms

4.3.1 System Architecture Taxonomy

Based on the comprehensive classification of Singh et al. (2026) and Li et al. (2025), Agentic Search systems can be categorized by architectural complexity into multiple levels:

Type	Core Characteristics	Representative Methods	Applicable Scenarios
Single-Agent (Prompt-only)	ReAct loop, simple implementation	ReAct, Search-O1	Prototype demonstrations, simple queries
Single-Agent (SFT/RL)	Fine-tuning or reinforcement learning enhances retrieval and reasoning capabilities	Toolformer, Search-R1	Production systems, open-domain research
Multi-Agent (Decentralized)	Parallel expert collaboration, high recall	M-RAG, MDocAgent	Large-scale evidence aggregation across heterogeneous sources
Multi-Agent (Centralized)	Hierarchical manager coordinates sub-tasks	Chain of Agents	Complex tasks under strict budgets
Hierarchical	Strategic decision-making → delegation → aggregation	—	Scenarios requiring multi-level task decomposition
Adaptive	Dynamically selects strategies based on query complexity	—	Systems with diverse query types

Corrective and Adaptive are two behavioral enhancement modes: Corrective introduces self-correction mechanisms to improve document utilization; Adaptive uses a classifier to assess query complexity and dynamically switches between single-step, multi-step, or skip-retrieval modes.

4.3.2 Evolution of Training Paradigms

Agent capability acquisition has undergone a three-stage evolution:

Paradigm	Core Mechanism	Advantages	Limitations
Prompt-based	Prompt engineering defines retrieval and reasoning behavior	Simple, no training required	Constrained by fixed instruction patterns
SFT	Fine-tuning on reasoning-retrieval joint data	Higher precision than prompting	Requires large amounts of synthetic data, prone to overfitting
RL	Reward functions incentivize strategy discovery and adaptive optimization	Genuine agentic behavior	Difficult to define reward signals, expensive training

The fundamental distinction: Prompt-based and SFT rely on offline supervision and fixed patterns; RL-trained agents are incentivized to autonomously discover search strategies rather than being told how to search.

4.4 Are Graph Structures Necessary for Agentic Search? — RAGSearch Empirical Evidence

The core question posed by Fan et al. (2026) addresses a key debate in Agentic Search: Do we still need GraphRAG? — that is, can Agentic Search compensate for the absence of explicit graph structures through dynamic multi-turn retrieval and reasoning, thereby reducing dependence on high-cost GraphRAG?

Core Conclusion: Agentic search can partially compensate for missing structural information in dense RAG through iterative retrieval, but explicit graph retrieval remains essential for robust multi-hop reasoning. GraphRAG consistently provides stronger performance and greater stability in complex settings, while dense RAG, with its lower construction cost, remains a practical choice for general-purpose QA.

The following analysis supports this conclusion across three dimensions: the formal framework, eight empirical findings, and system case studies.

4.4.1 Formal Framework

RAGSearch formalizes Agentic Search as follows: given a query $q$, an LLM-equipped agent interacts with a retrieval backend $B$ (dense RAG or GraphRAG) over multiple turns. At each step, the agent decides whether to trigger retrieval or generate an answer based on reasoning history, with retrieved information appended to the reasoning sequence. Its core characteristics are: retrieval is executed dynamically rather than as one-time preprocessing; the same control logic can operate across different backends.

Two Implementation Paths:

Path	Mechanism	Representative Methods
Training-Free	Reasoning-driven on-demand search or Orchestrated multi-agent workflows	Search-o1, GraphSearch
RL-Based	GRPO training, Outcome-based + Format-based reward design	Search-R1, Graph-R1

4.4.2 Eight Core Findings

RAGSearch revealed the relationship between Agentic Search and retrieval backends through systematic experiments:

Finding	Conclusion	Practical Implication
Obs.1	Under single inference, dense RAG is effective for general QA; GraphRAG primarily provides decisive improvements in multi-hop QA	Task complexity determines GraphRAG necessity
Obs.2	Agentic search can enhance dense RAG and partially close the gap with GraphRAG, but effectiveness depends on agent design	Structured agentic design is key, not simply increasing interaction turns
Obs.3	RL-based training generally improves performance, but well-designed training-free pipelines remain competitive	Training cost and performance require trade-off
Obs.4	In training-free workflows, explicit graph structures provide consistent and significant benefits for multi-hop QA	The robust advantage of graph structures in zero-training settings cannot be overlooked
Obs.5	RL-based agentic performance is highly backend-dependent: graph retrievers gain larger improvements on multi-hop QA	RL + GraphRAG exhibits synergistic effects
Obs.6	GraphRAG is more robust and stable than dense RAG in agentic search	Explicit structures reduce agentic control uncertainty
Obs.7	GRPO is a favorable training paradigm for RL-based agentic systems	Validates GRPO’s effectiveness in retrieval augmentation
Obs.8	Larger backbones not only improve reasoning performance but also narrow the performance gap between GraphRAG and dense RAG	Larger models may reduce the marginal benefit of graph structures

4.4.3 System Case Studies

This conclusion is corroborated in concrete system designs. Agent-G dynamically assigns retrieval tasks to specialized agents, simultaneously leveraging both graph knowledge bases and text documents. GeAR enhances conventional retrievers through graph expansion and introduces an agent framework for managing graph-structured data retrieval tasks. These systems demonstrate the deep synergy between graph structures and Agentic Search: explicit graph structures not only provide higher-quality retrieval results but also offer interpretable knowledge relation paths for agent decision-making, reducing the uncertainty of agentic control.

4.5 Open Challenges and Future Directions

4.5.1 Core Challenges

Agentic Search should not be viewed as a universal replacement for traditional RAG. While it provides superior adaptability and multi-step reasoning capabilities, it also introduces coordination complexity, latency, and computational costs. Core challenges include:

Evaluation Difficulty — Output-level metrics are insufficient to measure Agentic system quality; multi-dimensional evaluation of reasoning trajectories, planning depth, adaptability, robustness, and cost-effectiveness is needed.
Long-term Memory Design — Knowledge drift, bias reinforcement, and frequent updates may amplify hallucination risks.
Coordination Complexity — Multi-agent collaboration introduces communication and consensus overhead.
Computational Overhead — Additional latency from agent reasoning is non-negligible in practical deployment.

Furthermore, a fundamental constraint is that agentic reasoning cannot compensate for persistently poor retrieval. Failures often stem from insufficient retrieval coverage, poorly constructed indices, or inadequate integration of structured and unstructured knowledge.

Optimal Application Domains: Agentic Search gains the strongest benefits in domains with structured knowledge and explicit constraints. Healthcare, finance, and legal analysis particularly benefit from combining retrieval with rule-based reasoning and graph-structured knowledge.

4.5.2 Efficiency and Latency Optimization

While Synergized RAG-Reasoning systems excel in complex reasoning, their iterative retrieval and multi-step reasoning loops may cause significant latency. Optimization directions include: budget-aware query planning — optimizing query strategies under strict API call or token budgets; memory-aware mechanisms — caching prior evidence or belief states to reduce redundant access.

4.5.3 Trustworthiness and Adversarial Robustness

Agentic Search systems remain vulnerable to adversarial attacks through poisoned or misleading external knowledge sources. Ensuring the trustworthiness of retrieved content is critical for maintaining fully reliable downstream reasoning. Systems need to establish credibility verification mechanisms for retrieved content, particularly in high-stakes scientific research and legal analysis scenarios.

4.5.4 Structured Data and Multi-agent Deep Research

Key future development directions include: iterative data organization — structuring intermediate search and reasoning content from agentic retrieval and reasoning processes to help agents maintain coherence and relevance in long-term contexts; and multi-agent deep research — leveraging graph structures to understand task requirements and role relationships, enabling effective task assignment and coordination. Graph structures help agents understand task requirements based on roles and relationships, support complex task decomposition, and make multi-agent collaboration more efficient.

5. Literature Retrieval Systems in Scientific Research

The volume of scientific literature is growing at an exponential rate — according to statistics, the number of scientific papers doubles every 17 years. This trend has rendered traditional literature retrieval methods increasingly inadequate, giving rise to a new generation of AI-driven academic search platforms and research intelligence frameworks.

5.1 Academic Search Platforms and Tools

The current academic search ecosystem can be categorized by function into two types: search and synthesis platforms (focused on literature discovery and content comprehension) and recommendation systems (focused on personalized delivery and trend tracking).

Platform	Core Functionality	Technical Characteristics
Elicit	Semantic search, paper summary extraction	AI-enhanced academic search
Consensus	Evidence synthesis, trend analysis	LLM-based scientific question answering
OpenScholar	Large-scale academic literature retrieval	Semantic search + open access
SciSpace	Paper summarization, multi-document information synthesis	Cross-document understanding and synthesis
Connected Papers	Visual literature graph exploration	Visualization based on bibliographic coupling and co-citation
ORKG ASK	Structured knowledge access	KG-organized structured retrieval, more interpretable than conventional LLM QA
Arxiv Sanity	Paper recommendation	Personalized delivery based on ML and IR techniques
Scholar Inbox	Personalized academic information subscription	Interest-customized literature streams
ResearchTrend.ai	Research trend discovery	Trend analysis and emerging direction identification
Research Rabbit	Visual literature exploration	Similarity-based literature network mapping

Mainstream technical approaches for recommendation systems include content-based filtering, collaborative filtering, and hybrid approaches. Notably, graph-structured systems such as ORKG ASK organize research contributions as structured data rather than unstructured text, offering unique advantages in interpretability.

5.2 Four Core Limitations of Academic Search

Despite the important role these platforms play in literature discovery, academic search still faces systemic challenges:

Limitation	Description
Data Quality and Coverage Gaps	Incomplete, non-standard, or outdated data sources lead to inaccurate and inconsistent retrieval information
Model Bias	Search and ranking algorithms inherit biases from training data, affecting the visibility of certain research domains
Scalability and Real-time Processing	Efficiently processing large-scale datasets while maintaining low latency and high retrieval accuracy is challenging
Matthew Effect Reinforcement	Established researchers receive disproportionate attention; algorithms may exacerbate academic inequality

Additionally, existing systems generally lack rigorous filtering options and advanced relevance ranking mechanisms. Many AI-assisted research tools rely on proprietary data, closed APIs, or evolving LLM backends, making strict reproducibility and long-term comparability difficult to ensure.

5.3 Research AI Frameworks and Evaluation Benchmarks

To address the above challenges, researchers have proposed a series of AI frameworks targeting the full research pipeline, covering literature retrieval, survey generation, hypothesis generation, and experimental automation:

Framework	Core Functionality	Technical Characteristics
LitSearch	Literature retrieval evaluation benchmark	Evaluates complex literature retrieval queries in ML and NLP domains
ResearchArena	Academic survey LLM Agent evaluation	Three-stage: Information Discovery → Selection → Organization
SciLitLLM	Scientific literature understanding enhancement	CPT + SFT hybrid strategy, domain knowledge injection
CiteME	Citation management	Automated citation discovery and management
ResearchAgent	Research hypothesis generation	Multi-hop reasoning-assisted research ideation
Agent Laboratory	End-to-end research automation	High success rates in data preparation, experimentation, and report writing; weak in literature review

The central tension facing current research AI frameworks is the trade-off between end-to-end automation capability and domain depth. Systems such as Agent Laboratory perform excellently in data preparation, experiment execution, and report writing, but exhibit significant performance degradation during the literature review stage — precisely the phase requiring the most structured evaluation and domain expertise. While SciLitLLM and ResearchArena demonstrate promising results, they remain insufficient for tasks demanding deep domain knowledge and nuanced understanding. These limitations indicate that automated literature review remains a far-from-solved challenge, requiring better balance between structured evaluation, domain expertise, and reproducibility.

6. References

[1] Abou Ali, et al. (2025). Agentic AI: a comprehensive survey of architectures, applications, and future directions.

[2] Bai, et al. (2023). Advancing abductive reasoning in knowledge graphs through complex logical hypothesis generation.

[3] Borrego, et al. (2025). Research hypothesis generation over scientific knowledge graphs.

[4] Eger, et al. (2025). Transforming science with large language models: a survey on AI-assisted scientific discovery, experimentation, content generation, and evaluation.

[5] Fan, et al. (2026). Do we still need GraphRAG? Benchmarking RAG and GraphRAG for agentic search systems.

[6] Gao, et al. (2024). Retrieval-augmented generation for large language models: a survey.

[7] Gridach, et al. (2025). Agentic AI for scientific discovery: a survey of progress, challenges, and future directions.

[8] Hambarde, et al. (2023). Information retrieval: recent advances and beyond.

[9] Hao, et al. (2019). Universal representation learning of knowledge bases by jointly embedding instances and ontological concepts.

[10] Huang, et al. (2026). A survey on retrieval-augmented text generation for large language models.

[11] Li, et al. (2025). Towards agentic RAG with deep reasoning: a survey of RAG-reasoning systems in LLMs.

[12] Li, et al. (2026). OntoKG: ontology-oriented knowledge graph construction with intrinsic-relational routing.

[13] Niu, et al. (2026). A comprehensive survey of knowledge graph reasoning: approaches and applications.

[14] Peng, et al. (2024). Graph retrieval-augmented generation: a survey.

[15] Singh, et al. (2026). Agentic retrieval-augmented generation: a survey on agentic RAG.

[16] Sun, et al. (2025). LKD-KGC: Domain-Specific KG Construction via LLM-driven Knowledge Dependency Parsing.

[17] Thakur, et al. (2021). BEIR: a heterogenous benchmark for zero-shot evaluation of information retrieval models.

[18] Xiang, et al. (2026). When to use graphs in RAG: a comprehensive analysis for graph retrieval-augmented generation.

[19] Xu, et al. (2025). A Survey of Model Architectures in Information Retrieval.

[20] Yeom, et al. (2024). Embedding two-view knowledge graphs with class inheritance and structural similarity.

[21] Zhang, et al. (2025a). A survey of graph retrieval-augmented generation for customized large language models.

[22] Zhang, et al. (2025b). From web search towards agentic deep research: incentivizing search with reasoning agents.

[23] Zhang, et al. (2025c). On the role of pretrained language models in general-purpose text embeddings: a survey.

【阅】本周阅读摘选2026-04-20 → 2026-04-26

Mon, 27 Apr 2026 00:00:00 +0000

本周阅读摘选 2026-04-20 → 2026-04-26 目录

学术相关
- Is AI an algorithm by any other name? Behavioral reactions to AI- and model-based demand planning algorithms
- Unraveling multifaceted user preferences on digital platforms: a bayesian deep-learning approach [^2]

学术相关

Is AI an algorithm by any other name? Behavioral reactions to AI- and model-based demand planning algorithms ¹

Unraveling multifaceted user preferences on digital platforms: a bayesian deep-learning approach [^2]

McKinley, F., Brau, R., Aloysius, J., & Hofer, A. R. (n.d.). Is AI an algorithm by any other name? Behavioral reactions to AI- and model-based demand planning algorithms. https://doi.org/10.1002/joom.70045 ↩

【阅】本周阅读摘选2026-04-13 → 2026-04-19

Mon, 20 Apr 2026 00:00:00 +0000

本周阅读摘选 2026-04-13 → 2026-04-19 目录

学术相关
- Towards real-world human behavior simulation: benchmarking large language models on long-horizon, cross-scenario, heterogeneous behavior traces
- An introduction to double/debiased machine learning
娱乐
- 集智俱乐部丨物理学报告：复杂系统的可预测性

学术相关

Towards real-world human behavior simulation: benchmarking large language models on long-horizon, cross-scenario, heterogeneous behavior traces ¹

An introduction to double/debiased machine learning ²

娱乐

集智俱乐部丨物理学报告：复杂系统的可预测性

Chen, J., Xu, R., Cao, B., Pan, R., Zhang, Y., Hu, Y., Du, Y., Gao, T., Lu, Y., Sun, Y., Han, X., Sun, L., Wu, X., & Lin, H. (2026). Towards real-world human behavior simulation: Benchmarking large language models on long-horizon, cross-scenario, heterogeneous behavior traces (arXiv:2604.08362). arXiv. https://doi.org/10.48550/arXiv.2604.08362 ↩
Ahrens, A., Chernozhukov, V., Hansen, C., Kozbur, D., Schaffer, M., & Wiemann, T. (2025). An introduction to double/debiased machine learning (Version 2). arXiv. https://doi.org/10.48550/ARXIV.2504.08324 ↩

【阅】本周阅读摘选2026-04-06 → 2026-04-12

Mon, 13 Apr 2026 00:00:00 +0000

本周阅读摘选 2026-04-06 → 2026-04-12 目录

学术相关
技术技巧
娱乐
- DeepScientist & PaperOrchestra

学术相关

技术技巧

腾讯技术工程丨技术教科书：顶级开发团队设计的Harness工程项目源码什么样

运行时：Bun启动速度快
语言：TypeScript确保类型安全
UI：React+Ink
CLI解析：Commander.js
Schema校验：Zod v4
代码搜索：ripgrep
协议：MCP SDK + LSP
遥测：OpenTelemetry + gRPC
特征标记：GrowthBook 支持A/B测试和渐进式发布

快速启动

分层启动架构

入口分发 & lazy import
- 重量级模块懒加载
Paralle Prefetch
全局初始化
- 保证memorize即便多次import也只执行一次
会话级初始化

工具系统

接口：Tool<Input, Output, Progress>
- inputSchema Pydantic模型定义，Zod v4 shchema验证
- checkPermissions 权限校验
- isConcurrencySafe 并发安全控制流标记
- isDestructive 标记危险操作
- isAutoClassifierInput 为auto模式的安全分类器提供紧凑表示
buildTool工厂函数
- 所有tool必须通过工厂函数创建，提供安全默认值（默认假设不安全）
统一工具注册
通过assembleToolPool()将内建工具与MCP工具集成，构建通过工具池出口
StreamingToolExecutor流式并行执行

查询系统

Agent Loop的核心

异步生成器驱动主循环
- 流式UI更新
- 中途中断
- 背压控制
- 消息独立持久化
循环状态管理
- State对象
  - transition字段记录上次迭代的持续原因
四级上下文压缩管道 —— 渐进降级
- Snip Compact 基于标记的历史剪裁（无需API调用）
- Micro Compact 缓存编辑压缩（不破坏整体缓存的情况下删除特定工具调用结果）
- Context Collapse 上下文折叠（多轮工具调用结果折叠为摘要，保留结构）
- Auto Compact 全量摘要压缩（上下文接近窗口限制时使用生成摘要替换历史消息）
输出截断恢复机制
- stop_reason === 'max_output_tokens'输出截断有三层恢复机制
  - Token升级：尝试提高token预算上限
  - 多轮恢复（最终3次）：注入恢复消息，要求模型从中断处继续
  - 放弃：surface错误
模型降级容错
QueryEngine封装完整的查询生命周期
查询配置快照QueryConfig
- 实时读取不能保证一个查询内部每次迭代行为一致
task_budget Token预算

Multi-Agent编排与任务系统

七种任务类型，独立生命周期管理；每种任务ID具有独立前缀字母和8个字符随机后缀

local_bash Shell命令 -> 后台进程
local_agent 本地subagent -> 独立进程
remote_agent 远程subagent -> WebSocket连接
in_process_teammate 进程内teammate -> 共享内存
local_workflow 本地工作流脚本
monitor_mcp MCP监控任务
dream “梦境”任务 -> 后台分析

Agent Tool —— Subagent生成

subagent具有独立的对话历史和工具池

关键约束：

工具白名单
- 禁止使用agent生成相关管理工具
权限继承
独立的AbortController

Coordinator模式

当AGENT_COORDINATOR_MODE=1时，主线程变成协调器，仅负责分配任务

此时，协调器线程仅有AgentTool+TaskStopTool+SendMessageTool，而Bash，File Read/Edit/Write，Grep，Glob等工具由Worker线程拥有

工具分离保证协调器不参与任务执行

Agent Swarms

进程内Teammate通过Unix Domain Socket进行通信

本地快速通信

DreamTask —— 后台分析

TUI

内置Ink渲染引擎

Harness Engineering

上下文价格
架构约束
- 代码和工具的硬约束
- Deny Rules -> Tool-level Permissions -> Generic Rules -> Permission Mode -> Auto Classifier
- 默认配置最严格的限制避免遗忘造成漏洞
自验证循环
上下文隔离
- 进程级隔离：subagent具有独立的进程
- 通信接口化
- Coordinator模式控制&数据分离
熵治理：对抗系统自然熵增（上下文、记忆、文档混乱）
- 上下文蒸镏 /compact + Auto Compact
- 知识沉淀 memdir/持久化写入
- 状态清理 Session记忆自动失效
- 后台整理 AutoDream
- 碎片整理 Dream Phase 4: Prune & Index
模块化：防止与特定模型深度偶合

cloc丨Count Lines of Code

file & directory & archive & git repo: cloc [path]
Iterative for d in ./*/ ; do (cd "$d" && echo "$d" && cloc --vcs git); done
help cloc --help

有输入输出控制options，支持diff对比

prompt> cloc perl-5.22.0.tar.gz
    5605 text files.
    5386 unique files.
    2176 files ignored.

https://github.com/AlDanial/cloc v 1.65  T=25.49 s (134.7 files/s, 51980.3 lines/s)
-----------------------------------------------------------------------------------
Language                         files          blank        comment           code
-----------------------------------------------------------------------------------
Perl                              2892         136396         184362         536445
C                                  130          24676          33684         155648
C/C++ Header                       148           9766          16569         147858
Bourne Shell                       112           4044           6796          42668
Pascal                               8            458           1603           8592
XML                                 33            142              0           2410
YAML                                49             20             15           2078
C++                                 10            313            277           2033
make                                 4            426            488           1986
Prolog                              12            438              2           1146
JSON                                14              1              0           1037
yacc                                 1             85             76            998
Windows Message File                 1            102             11            489
DOS Batch                           14             92             41            389
Windows Resource File                3             10              0             85
D                                    1              5              7              8
Lisp                                 2              0              3              4
-----------------------------------------------------------------------------------
SUM:                              3434         176974         243934         903874
-----------------------------------------------------------------------------------

Tree-Sitter

增量式代码解析器生成器，将源代码转换为抽象语法树AST，并提供Tree Query Language (TQL)进行查询

VS Code、Neovim等均使用Tree-Sitter进行语法高亮

娱乐

DeepScientist & PaperOrchestra

主要关注Harness

【阅】本周阅读摘选2026-03-30 → 2026-04-05

Tue, 07 Apr 2026 00:00:00 +0000

本周阅读摘选 2026-03-30 → 2026-04-05 目录

学术相关
- Beyond Means: A Dynamic Framework for Predicting Customer Satisfaction
- Search games with predictions
娱乐
- Leveraging LLM-based agents for social science research: insights from citation network simulations

学术相关

Beyond Means: A Dynamic Framework for Predicting Customer Satisfaction ¹

Search games with predictions ²

娱乐

Naumzik C., Maarouf A., Feuerriegel S., & Weinmann M. (2026). Beyond Means: A Dynamic Framework for Predicting Customer Satisfaction. International Journal of Research in Marketing. https://doi.org/10.1016/j.ijresmar.2026.03.006 ↩
Angelopoulos, S., Lidbetter, T., & Panagiotou, K. (2026). Search games with predictions. Operations Research, opre.2024.1498. https://doi.org/10.1287/opre.2024.1498 ↩
Ji, J., Lei, R., Pan, X., Wei, Z., Sun, H., Lin, Y., Chen, X., Yang, Y., Li, Y., Ding, B., & Wen, J.-R. (2025). Leveraging LLM-based agents for social science research: Insights from citation network simulations (arXiv:2511.03758). arXiv. https://doi.org/10.48550/arXiv.2511.03758 ↩

【阅】本周阅读摘选2026-03-23 → 2026-03-29

Mon, 30 Mar 2026 00:00:00 +0000

本周阅读摘选 2026-03-23 → 2026-03-29 目录

学术相关
- Diversity of interactions within connectivist learning context: insights from flow of collective attention
- 计量经济圈丨全网最全的社科计量方法手册(含实操), 社会科学计量模型一网打尽(收藏级)

学术相关

Diversity of interactions within connectivist learning context: insights from flow of collective attention ¹

计量经济圈丨全网最全的社科计量方法手册(含实操), 社会科学计量模型一网打尽(收藏级)

一些经典方法

Research Scenario	Recommended Method
Continuous dependent variable, no endogeneity	OLS / Multiple regression
Binary dependent variable	Logit / Probit
Unordered multicategorical dependent variable	Multinomial Logit
Ordered multicategorical dependent variable	Ordered Logit
Count data (no overdispersion)	Poisson
Count data (overdispersed)	Negative binomial
Count data with excess zeros	ZIP / ZINB
Censored dependent variable	Tobit
Nested data (student—school)	HLM / Mixed-effects model
Panel data, time-invariant variables matter	Random effects (RE)
Panel data, control for individual heterogeneity	Fixed effects (FE)
Causal effect of policy intervention	DID / Synthetic control
Endogeneity problem	Instrumental variables (IV / 2SLS)
Threshold-based policy eligibility	Regression discontinuity (RDD)
Selection bias (observable)	PSM / IPW
Complex theoretical model + latent variables	SEM / CFA
Time-to-event data	Cox / Discrete-time event history
Multiple/competing events	Competing risks model
Discovering types in data	LCA / k-means
Longitudinal developmental trajectories	Latent growth model (LGM)
Large-scale text data	LDA / BERT
Heterogeneous treatment effects	Causal forest / Double ML

Gao, M., Zhang, J., & Zhang, J. (2025). Diversity of interactions within connectivist learning context: Insights from flow of collective attention. International Journal of Educational Technology in Higher Education, 22(1), 76. https://doi.org/10.1186/s41239-025-00575-5 ↩