Source-linked AI summary

One Size Does Not Fit All! Dynamic Retriever and Generator Selection for RAG

Neeraj Anand, Payel Santra, Partha Basuchowdhuri, Debasis Ganguly, Sumit Bhatia

arXiv:2609.17709v1cs.IRcs.AI

TL;DR

RAG commonly uses fixed retriever and generator settings even though queries differ in complexity, and joint adaptation of these components remains underexplored. This paper analyzes their interaction and introduces DRAG, which routes queries to retriever–generator configurations. Across benchmarks, DRAGQPP reduces latency while matching strong static baselines, and DRAGSFT improves the effectiveness–efficiency trade-off.

  • Problem

    Fixed retriever–generator settings are used despite query complexity differences, and their joint effect on end-to-end RAG performance remains underexplored.

    Source: §1 · pp. 1–2
  • Method

    DRAG selects query-specific retriever–generator configurations through training-free DRAGQPP and supervised DRAGSFT approaches.

    Source: §1 · p. 2
  • Results

    Across multiple QA benchmarks, DRAGQPP matches strong static baselines while reducing latency, and DRAGSFT improves the effectiveness–efficiency trade-off, approaching oracle routing.

    Source: §1 · p. 2, §7 · p. 11
  • Takeaways & Limitations

    The results support per-query joint retrieval and generation selection as a way to better balance effectiveness and efficiency than fixed configurations.

    Source: §7 · p. 11

    Future work is needed on more expressive routing policies that better capture non-separable interactions between retrieval and generation.

    Source: §7 · p. 11

Abstract

from arXiv · show

Retrieval-Augmented Generation (RAG) systems typically employ fixed retriever and generator configurations across queries, despite substantial differences in query complexity and information needs, leading to inefficient allocation of computational resources. While retrieval and generation adaptivity have been studied independently, their joint effect on end-to-end RAG performance remains underexplored. We systematically analyze how retriever and generator complexity interacts across factoid and multi-hop question answering (QA), including bridge and composition reasoning tasks. Our analysis shows that stronger retrieval generally yields larger gains than increased generation effort, but both exhibit diminishing and non-monotonic returns, indicating that higher-complexity configurations are not uniformly better across queries. Motivated by these findings, we introduce DRAG, a query-adaptive framework for selecting retriever-generator configurations. We first propose DRAG$_\text{QPP}$, a training-free routing approach that uses Query Performance Prediction (QPP) signals to guide retriever selection and perplexity-based measures over retrieved context to guide generator selection. We further introduce DRAG$_\text{SFT}$, a supervised routing approach that fine-tunes an LLM to jointly predict retriever-generator configurations. Across three LLM families and four QA benchmarks, \qpprag~achieves performance comparable to strong static RAG baselines while substantially reducing inference latency, whereas DRAG$_\text{SFT}$ consistently improves effectiveness over static and training-free adaptive baselines. Overall, DRAG demonstrates that jointly adapting retrieval and generation achieves a more favorable effectiveness-efficiency trade-off than static RAG pipelines.

1 Introduction

Fixed RAG pipelines apply the same retrieval and generation effort despite queries differing in complexity, while stronger pipelines add latency. DRAG jointly adapts retriever and generator selection, with training-free and supervised approaches evaluated across benchmarks and model families.

1 Introduction

  • Query needs range from single-document factoids to multi-hop, temporal, numerical, and multi-constraint tasks, while stronger retrieval and reasoning can increase latency.Fixed retriever–generator settings can therefore be computationally inefficient and suboptimal in effectiveness.Source: §1 · pp. 1–2
  • DRAG jointly selects query-specific retriever–generator configurations through training-free DRAGQPP and supervised DRAGSFT approaches.DRAGQPP uses unsupervised retrieval and generator performance prediction to balance the effectiveness–efficiency trade-off; DRAGSFT learns configuration prediction from query signals.Source: §1 · p. 2
  • The paper presents a comprehensive empirical study of how retriever–generator pair selection jointly affects end-to-end RAG performance.The study examines when additional computational capacity benefits queries and motivates adaptive selection.Source: §1 · p. 2
  • Across three LLM families and four benchmarks, the adaptive approaches are evaluated for robustness, including out-of-domain testing on FRAMES without dataset-specific tuning.The authors report that adaptive selection generalizes beyond the training distribution.Source: §1 · p. 2
  • The authors release their dataset and code to support reproducible research.The introduction provides the release location.Source: §1 · p. 2

2 Related Works

Prior RAG work spans retrieval, reranking, reasoning, and fine-tuning, while adaptive retrieval and reasoning studies often vary only one part of the pipeline. This paper distinguishes its focus as jointly analyzing retriever and generator choices.

2 Related Works

  • RAG research covers query-based retrieval, retrieval integration, reranking, iterative retrieval, multi-document reasoning, and fine-tuning of retrievers or generators.These strands include methods for incorporating retrieved evidence and improving reasoning over it.Source: §2 · p. 2
  • Adaptive retrieval work includes retrieve-or-not decisions, iterative retrieval, and SELF-RAG, while the paper distinguishes DRAG by selecting among multiple retriever–generator configurations.The cited discussion says binary retrieval decisions generally fail on difficult multi-hop queries.Source: §2 · p. 2
  • Some adaptive reasoning methods vary reasoning steps or select among reasoning paths while assuming a fixed retrieval pipeline; this paper jointly analyzes retrieval and generation choices.The contrast is the joint treatment of retriever and generator capabilities within RAG.Source: §2 · pp. 2–3
  • Query performance prediction includes pre-retrieval and post-retrieval approaches, and this work uses pre-retrieval predictors to guide retriever selection.The passage describes predictors based on query difficulty and collection statistics, retrieval scores, ranking features, or rank-list perturbations.Source: §2 · p. 3

3 RAG Configuration Analysis and Problem Formulation

The section formulates adaptive RAG as selecting a query-specific retriever–generator pair to balance answer quality and computational cost. Its oracle analysis and query examples motivate routing across configurations rather than using one fixed level of complexity.

3 RAG Configuration Analysis and Problem Formulation

  • Adaptive RAG selects a query-specific retriever–generator configuration to balance downstream answer quality and computational cost.Because ground-truth answers are unavailable at inference time, the formulation uses an estimator of answer correctness to choose an efficient configuration.Source: §3 · p. 3
  • The configuration space orders retrievers and generators by increasing capability and computational cost, from lexical to retrieve-and-rerank retrieval and from lightweight to multi-step reasoning.The GPT-OSS setup uses four retrieval levels and three generator levels; Qwen and Gemma use four retrieval levels and two generator modes.Source: §3 · p. 3
  • The efficiency-aware oracle assigns each query the least expensive retriever–generator configuration that correctly answers it, using ground-truth effectiveness.When multiple configurations meet the effectiveness threshold, the oracle selects the least expensive one.Source: §3 · p. 3
  • A substantial fraction of HotpotQA queries are correctly answered with low- and medium-complexity configurations, so uniformly using the most expensive pipeline is often unnecessary.The oracle distribution also shows that some simple queries are answered across all configurations, while other queries need particular retrieval and reasoning combinations.Source: §3 · pp. 3–4
  • Figure 2 presents DRAG as per-query configuration selection, with DRAGQPP using retrieval and generator performance prediction and DRAGSFT learning selection from supervision.The chosen configuration is then run to produce the answer; the illustration describes GPT-OSS and notes configurations for Qwen and Gemma.Source: Figure 2 · p. 4
  • The query examples show that configurations are not strict supersets: a semantic entity-relation query succeeds with dense retrieval when other retrievers miss or retrieve noisy evidence.A simple factoid is answered across configurations, for which more expensive retrieval and reasoning add cost without performance gain.Source: §3 · p. 4

4 Dynamic RAG Workflow (DRAG)

DRAG approximates query-specific oracle routing by selecting retriever–generator configurations. It offers a training-free, sequential predictor and a supervised approach that predicts both components jointly.

4 Dynamic RAG Workflow (DRAG)

  • DRAG approximates oracle routing when ground-truth answers are unavailable, with separate training-free and supervised approaches for selecting retriever–generator configurations.DRAGQPP uses sequential unsupervised performance signals; DRAGSFT directly learns query-specific configurations.Source: §4 · p. 4

4.1 DRAGQPP

  • DRAGQPP uses pre-retrieval query performance prediction to route queries to retrievers, avoiding the cost of evaluating every retriever for each query.Its threshold intervals map lower QPP scores to more complex retrievers and higher scores to simpler, cheaper ones.Source: §4.1.1 · p. 5
  • DRAGQPP selects a generator based on perplexity of the retrieved context, escalating to more complex generators when context perplexity fails the tier’s threshold.The method conditions generator selection on the retriever chosen in the preceding stage.Source: §4.1.2 · p. 5

4.2 DRAGSFT

  • DRAGSFT fine-tunes Qwen on queries paired with oracle configuration labels to jointly predict a retriever–generator configuration in one decoding step.This avoids DRAGQPP’s sequential routing and threshold calibration while adding negligible upfront inference overhead.Source: §4.2 · p. 5

5 Experimental Setup

The experimental setup evaluates adaptive RAG against static and other baselines across four QA benchmarks, using retriever and generator configurations of varying complexity. It specifies the research questions, evaluation metrics, and benchmark scope.

5 Experimental Setup

  • The experiments ask how retriever and generator complexity affect RAG quality, whether dynamic selection improves the effectiveness–efficiency trade-off, and how routing generalizes out of domain.Source: §5 · p. 6

5.1 Datasets

  • TriviaQA represents factoid QA, while HotpotQA, MuSiQue, and FRAMES cover multi-hop reasoning; FRAMES is the out-of-domain benchmark.The datasets span bridge, compositional, numerical, temporal, and multi-constraint reasoning needs.Source: §5.1 · p. 6

5.2 Retrievers Investigated

  • Retriever configurations range from BM25 lexical retrieval and E5 dense retrieval to cross-encoder reranking and query-decomposition reranking.The query-decomposition pipeline retrieves for subqueries and the original query before reranking the candidate pool.Source: §5.2 · p. 6

5.3 Generators Investigated

  • The evaluated LLM families expose reasoning-effort settings that trade increased token use and inference latency for generally improved multi-hop and compositional performance.GPT-OSS has three effort levels; Qwen-3 and Gemma-4 use binary thinking controls.Source: §5.3 · p. 6

5.4 Baselines

  • Baselines include answer-only 0-shot, the best static RAG configuration, an oracle adaptive setup, and DRAGQPP routing with ground-truth retrieval effectiveness replacing QPP.DRAGPPT prompts an LLM to select a configuration from its parametric knowledge.Source: §5.4 · pp. 6–7

5.5 Experimental Details

  • Evaluation reports Exact Match, F1, Accuracy, and retrieval AP@10, with query-level significance tests; DRAGSFT training uses Qwen3-4B-Instruct and five epochs.McNemar’s test is used for Exact Match and Accuracy, and a paired t-test for F1.Source: §5.5 · p. 7

6 Results and Discussion

Across the experiments, stronger retrieval generally improves QA more than increased reasoning effort, though both show diminishing or non-monotonic returns. Adaptive routing beats static high-complexity RAG, with supervised DRAGSFT typically more effective but slower than training-free DRAGQPP.

6.1 Effect of Retriever and Generator Complexity

  • Retrieval scaling generally improves performance, especially on multi-hop QA, but saturates at the highest level outside FRAMES; reasoning gains are smaller and depend on retrieval quality.On MuSiQue, increased reasoning effort yields 7% EM improvement under θL versus 16.9% under θH.Source: §6.1 · p. 8

6.2 Dynamic vs. Static RAG Performance

  • DRAGSFT and DRAGAP outperform static RAGmax, while DRAGSFT typically improves performance 2-12% over DRAGQPP at 5-40% higher latency.The oracle RAGOrac remains stronger than all adaptive methods and baselines.Source: §6.2 · p. 9
  • DRAGSFT gains over static configurations are consistently significant in-domain, but its FRAMES improvements are not always significant, leaving cross-dataset routing challenging.DRAGQPP often remains statistically comparable to static RAG with medium- or high-complexity generators.Source: §6.2 · p. 10
  • Routing overhead is relatively small; most latency differences arise from retrieval and generation, with DRAGSFT choosing costlier settings while DRAGQPP favors cheaper ones.Table 5 reports per-query latency on HotpotQA using GPT-OSS and separates decision time from downstream RAG time.Source: Table 5 · p. 9, §6.2 · p. 10

6.3 Model Generalization

  • On FRAMES, both adaptive methods outperform baselines including DRAGAP and cost less than RAGmax, although GPT-OSS’s best static setting uses low or medium reasoning effort.The OOD evaluation trains on MuSiQue and evaluates directly on FRAMES.Source: §6.3 · p. 10

6.4 Ablation Studies

  • As retrieved-document count increases, low-complexity retrieval continues improving, whereas stronger retrievers plateau early across generator reasoning levels; k=5 balances coverage and cost.Figure 3 compares F1 across document counts and retrieval and generator complexities.Source: Figure 3 · p. 9, §6.4 · p. 10
  • Across HotpotQA and MuSiQue, retrieval effectiveness (MAP@10) and downstream QA performance (F1) rise together as retrieval complexity increases.Figure 4 encodes retrieval modes as bars and reports MAP@10 and F1 for GPT-OSS.Source: Figure 4 · p. 9, §6.4 · p. 10

6.5 Per-Query Analysis

  • DRAGSFT’s errors fall into overestimation, underestimation, and wrong-entity patterns, linking routing mistakes to query-complexity estimation and evidence selection.The examples are qualitative failure cases on MuSiQue relative to oracle RAGOrac.Source: §6.5 · p. 10, Table 6 · p. 10

7 Conclusions and Future Work

The study examines joint retrieval and generation complexity and concludes that higher-complexity RAG is not uniformly better; adaptive routing improves the effectiveness–efficiency trade-off.

7 Conclusions and Future Work

  • The study examines how retrieval complexity and generation effort jointly affect end-to-end RAG performance.Source: §7 · p. 10
  • Across multiple QA benchmarks, DRAGQPP matches strong static baselines while reducing latency, and DRAGSFT improves the effectiveness–efficiency trade-off, approaching oracle routing.Source: §7 · p. 11
  • Increasing complexity does not consistently improve accuracy, and high-complexity configurations are not strict supersets of simpler ones.Source: §7 · p. 11
  • Future work will develop more expressive routing policies, richer supervision, and reinforcement learning to better model retrieval–generation interactions and optimize cost–quality trade-offs.Source: §7 · p. 11

GenAI Usage Disclosure

Loading 2609.17709v1…