Source-linked AI summary
LiteRAG: Cost-Efficient Graph-Based Retrieval-Augmented Generation
Daniel Alejandro Coll Tejeda, Pedro García López, Daniel Barcelona-Pons
TL;DR
Graph-based retrieval supports multi-hop question answering but can be costly and produce diffuse contexts. LiteRAG replaces retrieval-time LLM control with query-conditioned algorithmic exploration and reasoning-chain context construction, achieving strong quality-efficiency results across DistComp and UltraDomain. Its reported limitations concern domain generality, indexing scope, cross-model robustness, and empirical scalability assessment.
Problem
Graph-based retrieval can incur high query-time costs and produce oversized, diffuse contexts that reduce generation efficiency for multi-hop question answering.
Method
LiteRAG uses query-conditioned algorithmic exploration and compact reasoning-chain construction instead of retrieval-time LLM navigation.
Results
LiteRAG achieves the highest reported quality on DistComp while using the fewest tokens and lowest latency and cost, and remains competitive on UltraDomain with a substantially smaller context and lower execution cost.
Takeaways & Limitations
Separating graph exploration from LLM inference and constructing compact, information-dense contexts yields a favorable quality-efficiency trade-off under tight token budgets.
Takeaways & Limitations
DistComp is specialized, indexing cost is outside the method’s scope, cross-model robustness remains untested, and scalability analysis is empirical rather than formal.
Abstract
from arXiv · showhide
Graph-based retrieval can improve multi-hop question answering, but existing approaches often incur high query-time costs and produce diffuse, oversized contexts that reduce generation efficiency. We present LiteRAG, a graph-based retrieval method that replaces expensive retrieval-time LLM control with query-conditioned algorithmic exploration and reasoning-chain context construction. On DistComp, a benchmark for multi-hop retrieval over distributed-systems papers, LiteRAG attains the highest overall quality among the evaluated methods (0.798) while reducing per-query latency by over 100$\times$ and cost by over 99% relative to GraphRAG Global and DRIFT. On UltraDomain, it matches LinearRAG on overall quality while using about 14$\times$ fewer tokens. An ablation study indicates that LiteRAG's query-adaptive thresholding and community-aware hub penalization are the main drivers of its token-efficiency gains.
1 Introduction
LiteRAG addresses the cost and context-density limits of graph-based retrieval by replacing retrieval-time LLM control with query-conditioned algorithmic exploration and compact reasoning-chain context construction. On DistComp, it achieves the strongest reported quality-efficiency results among evaluated methods.
- Graph-based retrieval can incur high latency and cost while producing broad contexts containing irrelevant or weakly relevant information.These problems make the generator sift through diffuse evidence, especially for multi-hop questions under realistic token budgets.
- The method optimizes both evidence selection and preparation for the generator rather than treating retrieval as selection alone.
- LiteRAG replaces retrieval-time LLM navigation with query-conditioned algorithmic graph exploration using dynamic thresholding and community-aware hub penalization.It selects semantic and lexical anchors before expanding a bounded subgraph.
- LiteRAG converts retrieved subgraphs into compact reasoning chains that make retained relations explicit for generation.The resulting context is designed to preserve query-relevant structure within a budget of about 2,000 tokens.
- LiteRAG attains the highest overall quality and lowest latency and cost among evaluated methods on DistComp.Relative to the most expensive LLM-intensive GraphRAG configurations, it reduces per-query cost by over 99% and latency by over 100×.
2 Related Work
Related graph-based RAG methods use relational structure to support multi-hop reasoning, but they differ in how much retrieval-time control they assign to LLMs and how directly they optimize efficiency. LiteRAG combines query-conditioned evidence collection with explicit construction of a dense final context.
- Graph-based RAG methods organize entities and relations so retrieval can operate over relational structure rather than isolated text chunks.
- One line of work relies heavily on LLMs to construct graph representations and orchestrate traversal, community summarization, and evidence retrieval at query time.Graph structure improves retrieval quality in these systems, but retrieval-time control remains coupled to the LLM.
- Efficiency-oriented systems improve graph organization, hierarchy, scoring, indexing, or filtering to reduce LLM dependence.Examples include LightRAG, HiRAG, RAPTOR, HippoRAG, LinearRAG, KET-RAG, and ROGRAG.
- LiteRAG differs by combining query-conditioned subgraph construction with compact reasoning-chain context construction.This couples adaptive evidence collection with a more information-dense final context rather than relying primarily on fixed neighborhoods or static graph statistics.
3 LiteRAG Method
LiteRAG builds a query-conditioned subgraph through algorithmic anchor selection and adaptive expansion, then converts retained relations into compact reasoning chains. Its three-phase design combines semantic, lexical, community, structural, and traversal signals to preserve explicit relational evidence under strict token budgets.
- Overview: LiteRAG has three stages: query-conditioned anchor selection, query-conditioned subgraph expansion, and reasoning-chain context construction.The method replaces retrieval-time LLM control with algorithmic exploration before final answer generation.
- Phase 1: Query-Conditioned Anchor Selection: Anchor selection scores candidate entities using semantic similarity, lexical matching, and community-level relevance before thresholding them into the initial frontier.The semantic term captures conceptual alignment, the lexical term protects exact terminology, and the community term favors coherent topical neighborhoods.
- Phase 2: Query-Conditioned Subgraph Expansion: Subgraph expansion grows adaptively from all anchors by retaining query-relevant neighbors until relevance, hop-depth, or per-anchor expansion limits stop exploration.Traversal is treated as an algorithmic search rather than delegated to an LLM.
- Phase 2: Query-Conditioned Subgraph Expansion: Dynamic thresholding links traversal selectivity to anchor quality: stronger anchors impose stricter criteria, while weaker anchors permit broader exploration.The threshold uses a minimum relevance floor, anchor evidence, and a cap at 1.0.
- Phase 2: Query-Conditioned Subgraph Expansion: Community-aware hub penalization reduces drift by penalizing high-degree connectors less when transitions remain within the same topical community.The penalty distinguishes generic connectivity from query-relevant structure while protecting within-community transitions.
- Phase 3: Reasoning-Chain Context Construction: Phase 3 ranks explored entities with consensus signals, retains incident relations, and linearizes them into compact reasoning chains with minimal interpretive support.This curated relational context is more compact than raw text or community summaries while preserving explicit connections for multi-hop reasoning.
4 Experimental Methodology
LiteRAG is evaluated on DistComp, a custom distributed-computing benchmark designed for multi-hop synthesis, drift-style comparison, and corpus scaling, and on UltraDomain’s Mix split. The study compares it with graph-based and dense-retrieval baselines using quality, latency, token consumption, and cost metrics under a shared model setup.
- Benchmarks: DistComp contains distributed-computing papers from 2020–2022, five corpus sizes from D40 to D1280, and 160 expert-written queries across four categories.The largest split contains approximately 500,000 tokens.
- Benchmarks: UltraDomain’s Mix split provides a public multi-domain evaluation spanning agriculture, law, and healthcare.
- Baselines: The comparison includes GraphRAG Basic, Microsoft GraphRAG, LightRAG, HiRAG, and LinearRAG across their reported retrieval modes and configurations.
- Experimental setup: All methods use gemini-2.5-flash-lite for generation and gemini-embedding-001 for embeddings, while LiteRAG reuses Microsoft GraphRAG indexing.LiteRAG hyperparameters were selected by grid search on a validation split.
- Metrics: The evaluation reports composite quality Qtotal alongside end-to-end latency, total token consumption, and cost per query.Qtotal combines Qjudge, Qsem, and Qlex; efficiency uses shared API pricing.
5 Results and Empirical Analysis
LiteRAG achieves the strongest reported quality-efficiency trade-off across DistComp and UltraDomain, maintaining competitive quality with lower latency, token use, and cost. Its advantage persists as corpus size grows, under a roughly 2,000-token budget, and in component ablations.
- Main results: 0.798 Qtotal is LiteRAG’s highest score on DistComp D1280, alongside 1.42s latency, 2,291 tokens, and $0.0003 cost per query.GraphRAG Global requires 162.66s and 643k tokens, while GraphRAG DRIFT exceeds 142s and 6.4M tokens.
- Main results: 0.801 overall quality is shared by LiteRAG and LinearRAG on UltraDomain, while LiteRAG records the lowest latency, token consumption, and cost.LiteRAG uses 4,862 tokens, 1.24s, and $0.0006 per query.
- Main results: 14× fewer tokens, about 92% lower cost, and 74% lower latency distinguish LiteRAG from LinearRAG on UltraDomain at matched aggregate quality.LinearRAG uses 68,774 tokens, 4.79 seconds, and $0.0071 per query.
- Latency and cost across corpus scale: 1.33–1.74 seconds per query is LiteRAG’s latency range across DistComp corpus sizes, remaining below the selected baselines at every size.LiteRAG ends at 1.42 seconds on D1280; GraphRAG Global grows from 8.57s to 162.66s.
- Latency and cost across corpus scale: $0.00028–$0.00030 per query is LiteRAG’s cost range across corpus sizes, below the selected baselines and their larger increases in LLM-intensive modes.GraphRAG Global rises from $0.0031 to $0.0679 across the same settings.
- Quality under a fixed token budget: −16.1% is the largest reported budget-induced quality drop, while LiteRAG remains unchanged under the approximately 2,000-token constraint.GraphRAG DRIFT drops 13.3%, and HiRAG is the most resilient baseline family but remains below LiteRAG’s budgeted score.
- Quality under a fixed token budget: 570,440 tokens is GraphRAG DRIFT’s most restrictive available configuration, which still loses 13.3% in quality; GraphRAG Global lacks a comparable hard token cap.
- Ablation study: Nearly 250% more tokens, from 2,291 to 7,979, result when query-adaptive thresholding is replaced by fixed-hop expansion, while Qtotal remains 0.787.Removing hub penalization raises token consumption to 4,522 with similar quality at 0.789; raw subgraph context uses 3,622 tokens and lowers quality to 0.780.
6 Conclusion
LiteRAG combines query-conditioned graph exploration with compact reasoning-chain construction to deliver relevant evidence in a structurally explicit form. Across experiments, it achieves a favorable quality-efficiency trade-off, with adaptive thresholding and hub penalization driving token efficiency.
- LiteRAG replaces LLM-mediated navigation with query-conditioned algorithmic exploration and reasoning-chain context construction.Its design combines lexical and community-aware anchor selection, query-adaptive thresholding, community-aware hub penalization, and compact reasoning-chain construction before generation.
- On DistComp D1280, LiteRAG achieves the highest reported Qtotal while using the fewest tokens, lowest latency, and lowest per-query cost.The broader scaling results also show a comparatively flat latency-cost profile across the evaluated corpus range.
- Fixed-budget and ablation results show that reasoning-chain construction preserves overall quality under tight token budgets.The ablation study further identifies query-adaptive thresholding and community-aware hub penalization as the main drivers of token-efficiency gains.
- On UltraDomain, LiteRAG remains competitive in aggregate quality while using a substantially smaller retrieved context and markedly lower execution cost than the strongest comparator.
Limitations
The study’s conclusions are bounded by domain coverage, system scope, evaluation setup, and the empirical nature of its scalability analysis. These limitations primarily affect scope and generality rather than the central quality-efficiency claim.
- DistComp is specialized to distributed-systems literature, so its absolute performance levels may not transfer unchanged across domains.UltraDomain is used to check whether the main quality-efficiency pattern is confined to DistComp.
- LiteRAG addresses retrieval and context construction but not graph indexing, leaving full end-to-end optimization outside the paper’s scope.
- All systems share the same generation and embedding setup, improving comparability but leaving cross-model robustness for future work.
- The scalability analysis is empirical rather than formal, and some baselines lack controls for perfectly matched hard token budgets.
A Complete Scalability Results
Table 4 reports complete scalability results for all evaluated query engines across DistComp dataset sizes. It details latency, token consumption, cost per query, and overall quality.
- Table 4 covers all evaluated query engines across every DistComp dataset size D.
- The table reports average end-to-end latency, total token consumption, cost per query, and Qtotal.
B Disaggregated Quality Metrics
The appendix reports disaggregated quality components for top-performing configurations on the 1280-document corpus. It also documents the composite metric’s weighting and the judge prompt used to evaluate correctness, completeness, and relevance.
- The disaggregated analysis covers Qjudge, Qsem, Qlex, and Qtotal for top-performing configurations on the D1280 benchmark.
- Qtotal weights judge-based, semantic, and lexical components at 0.6, 0.25, and 0.15, respectively.The weights were fixed on a held-out validation split, with Qjudge receiving the largest weight because it evaluates multi-hop reasoning quality, factual correctness, and relevance.
- Qsem measures semantic alignment, while Qlex uses ROUGE-L to penalize severe wording-level drift or unsupported terminology.
- LiteRAG performs consistently highly across the three independent evaluators without semantic or factual degradation according to the reported comparison.
- The final-generation prompt uses graph reasoning chains to make relationships explicit and reduce inference from dispersed passages.This construction lowers token consumption and the generator’s inferential burden.
- The judge evaluates generated answers against ground truth on correctness, completeness, and relevance using scores from 0.0 to 1.0.
D LiteRAG Hyperparameter Configuration
LiteRAG’s reported experiments used configurations selected by validation and bounded, query-conditioned exploration. The settings preserve lexical anchors, limit traversal, and prioritize repeated support over generic graph centrality.
- Hyperparameters were selected by grid search on a held-out validation split under the reported model and graph-construction setup.
- LiteRAG configuration: LiteRAG decomposes lexical anchoring into exact and fuzzy matching, while Phase 2 uses kmax = 3 and Nmax = 50.The expansion budget is governed by dynamic thresholding under bounded traversal.
- Retrieval bias: The method preserves exact lexical anchors, expands conservatively from strong evidence, and ranks entities by repeated traversal support rather than generic graph centrality.
- Budgeting: LiteRAG requires no separate budgeted configuration because its algorithmic design naturally produces context within the 2,000-token target budget.
F Exploratory Multi-Entity Efficiency Comparison
A focused 20-query DistComp subset examined whether LiteRAG’s efficiency advantage persists as queries mention more entities. Across all bins, LiteRAG remained faster, less expensive, and more token-efficient, while quality differences varied.
- Subset design: The subset contains 20 queries grouped into four bins by the number of distinct entities or concepts explicitly mentioned in each question.The analysis tests whether the efficiency gap remains visible as query entity count increases.
- Efficiency comparison: Across all four bins, LiteRAG remained faster, less expensive, and more token-efficient than LinearRAG.
- Efficiency comparison: 1.00–1.11 seconds and 1,881–2,120 tokens characterized LiteRAG, compared with 2.12–3.77 seconds and 2,365–3,077 tokens for LinearRAG.Latency is reported per query, and the cited ranges span all four entity-count bins.
- Quality comparison: On the 4-entity bin, LiteRAG scored 0.81 versus 0.74 for LinearRAG, while quality differences were mixed in lower-entity bins.