Adaptive-RAG: Routing by Query Complexity

Adaptive-RAG (Jeong, Baek, Cho, Hwang and Park; NAACL 2024; arXiv:2403.14403) is a query-complexity router: a smaller language-model classifier picks no retrieval, single-step retrieval, or multi-step retrieval before the answer is generated. Official code is starsuzi/Adaptive-RAG. Among the named patterns under RAG architectures, Adaptive-RAG owns three-way complexity routing; binary retrieve-versus-skip lives on adaptive retrieval, and the multi-step branch usually follows IRCoT.

How is Adaptive-RAG different from generic adaptive RAG marketing?

Adaptive-RAG here means the Jeong et al. (2024) NAACL framework with an explicit A/B/C complexity classifier. Many explainers for adaptive RAG mean something broader: any system that changes retrieval behaviour based on feedback, confidence, or query shape. Meilisearch Adaptive RAG explained (2026) uses adaptive as a product-and-architecture umbrella for hybrid search, query rewriting, and self-correcting loops, which is a different sense from the Jeong classifier.

Eduinx Adaptive RAG 2026 and ragaboutit Query-Adaptive RAG posts sit closer to the Jeong framing: route complex questions to multi-hop retrieval while keeping simple queries on a fast single retrieve. Sotaaz Why Agentic RAG frames query routing as one agentic pattern among planners and tool loops. Those pages are useful for the routing idea; they are not substitutes for Jeong Table 1 Step and Time numbers.

When a vendor page says adaptive without naming Jeong, A/B/C labels, or a complexity classifier, treat it as the generic sense and ask which decision is being automated: skip versus retrieve, rewrite versus not, or three-way strategy choice. Only the last matches the Jeong Adaptive-RAG mechanism.

arXiv:2604.03455 Lightweight Query Routing for Adaptive RAG, which ranks on the same head query, studies cheaper routers as baselines around adaptive routing. Read it as adjacent research on router cost, not as a rename of Jeong NAACL Adaptive-RAG. Keep Jeong Table 1 as the reference numbers for A/B/C Step and Time unless you re-run the same single-hop and multi-hop mix yourself.

How does Adaptive-RAG choose between no retrieval, single-step, and multi-step?

Adaptive-RAG treats strategy choice as a three-way decision matched to how hard the question is (Jeong et al., 2024, Figure 2 and sections 3.1 to 3.2). Label A answers with LLM(q) only, for queries the model parametric knowledge can already handle. Label B retrieves once, then generates with LLM(q, d), the ordinary retrieve-then-read path. Label C iterates retrieve-and-reason with context carried across steps as LLM(q, d, c).

In the paper experiments the multi-step branch follows the Trivedi et al. IRCoT-style iterative approach (Jeong et al., 2024, section 4.2). One-size-fits-all multi-step wastes calls on easy questions; one-size-fits-all single-step fails questions that need several documents. The router exists to pick the cheapest strategy that is still adequate.

Depth on the C-branch loop itself lives at IRCoT; the single-step baseline cousin is Naive RAG. Ragaboutit Query-Adaptive RAG makes the same product claim in practitioner language: pay multi-hop cost only when the question needs it, and keep simple lookups on the fast path.

The A path is not a refusal path. It is an explicit bet that parametric knowledge already holds the answer, so skipping retrieval is correct rather than unsafe. If your domain forbids ungrounded answers, constrain A to a narrow FAQ set or remove A entirely and keep a two-way B/C router; Jeong three-way design assumes A is safe for some traffic.

The B path should match your production Naive RAG stack as closely as possible, including the same hybrid retrieve settings on Weaviate or another store, so the classifier is choosing strategy rather than accidentally choosing a weaker index. The C path should inherit the same corpus and only add iteration.

How does the Adaptive-RAG query-complexity classifier work?

The classifier is a smaller LM that maps the query string to one of {A, B, C} before any retrieval strategy runs: o = Classifier(q) (Jeong et al., 2024, section 3.2). The paper trains T5-Large with AdamW at learning rate 3e-5, picking the best validation epoch within 100 training iterations (section 4.4). The classifier sees only the query text, not retrieved documents, so the routing decision is cheap relative to a multi-step IRCoT trajectory.

Because no public A/B/C labels exist, the authors build silver training data automatically. Outcome-based labels run no-retrieval, single-step and multi-step solvers; if the simplest solver that gets the answer right succeeds, prefer that simpler label, with ties breaking toward simpler strategies. Dataset inductive bias fills remaining unlabeled queries: inherit B from single-hop datasets and C from multi-hop datasets.

Annotation used 400 sampled queries per dataset for bias labels plus predicted outcomes over 400 queries per dataset, with no overlap into the QA test set (section 4.4). The published confusion matrix still shows real error modes: Multi misclassified as One about 31%, One as Multi about 23%, No as One about 47%, and No as Multi about 22% (Jeong et al., 2024, section 5). Those rates matter operationally: sending a No query into Multi burns wall time, and sending a Multi query into No fails silently without a retrieve.

Related 2026 work on lightweight query routing for adaptive RAG (arXiv:2604.03455) studies cheaper routers as baselines around the same problem family. That line is complementary research, not a replacement for Jeong silver-label training or Table 1. Binary retrieve-or-skip gating without a multi-step tier remains the sibling at adaptive retrieval.

What results did Adaptive-RAG publish?

Table 1 averages single-hop (SQuAD, Natural Questions, TriviaQA) and multi-hop (MuSiQue, HotpotQA, 2WikiMultiHopQA) sets with 500 test samples per dataset. Step and Time are relative to the single-step approach (= 1.00) (Jeong et al., 2024, Table 1, section 4.3).

On FLAN-T5-XL (3B), Adaptive-RAG reaches EM 37.17, F1 46.94, Acc 42.10 at Step 2.17 / Time 3.60. Always multi-step scores EM 39.00, F1 48.85 at Step 4.69 / Time 8.81. Single-step sits at EM 34.83, F1 44.31. The accuracy gap to always multi-step is a few EM points; the Time gap is more than half.

On GPT-3.5 Turbo instruct, Adaptive-RAG EM 37.97, F1 50.91, Acc 48.97 at Step 1.03 / Time 1.46 versus multi-step EM 38.13, F1 50.87 at Step 2.81 / Time 3.33. With a perfect classifier, Adaptive-RAG on FLAN-T5-XL reaches EM 45.00, F1 56.28 at Step 1.28 / Time 2.11: the gap to the learned classifier is the headroom the Limitations section flags.

Self-RAG appears in the same table with an explicit caveat that it uses a different base LLM (LLaMA2), so those rows are not an apples-to-apples bake-off. See Self-RAG and RAG benchmarks. Eduinx Adaptive RAG 2026 restates the efficiency framing for practitioners: route, then measure Step and Time beside EM.

What does Adaptive-RAG cost compared with always multi-step?

Adaptive-RAG product claim is efficiency at near-multi-step accuracy: on FLAN-T5-XL it roughly halves relative Time versus always multi-step (3.60 versus 8.81) while staying within a few EM points (Jeong et al., 2024, Table 1). Table 3 shows why the mix matters in their experiment: predicted No (A) queries took 0.35 s (8.60% of samples), One (B) 3.08 s (53.33%), and Multi (C) 27.18 s (38.07%).

Routing a simple query into C pays that multi-step wall time for nothing; routing a hard query into A fails without a retrieve. The classifier itself adds one smaller-LM forward pass before the chosen solver. Dollars per query on a private corpus are not published; measure Step, Time and EM together.

Ragaboutit Query-Adaptive RAG emphasises the same cost curve for production traffic: keep simple queries fast, spend multi-hop only on complex ones. Pipeline spend framing is at pipeline cost. Stores behind the B and C solvers can still be hybrid indexes. Weaviate, Qdrant, and Pinecone can serve single-step or iterative retrieves with BM25F-plus-vector fusion; Weaviate hybrid search configuration as of September 2026 is documented on docs.weaviate.io.

Instrument the fraction of queries labeled C in production. If C dominates, the classifier is not saving money relative to always-IRCoT; if C is rare but Time is still high, inspect confusion that sends B queries into C.

Table 3 wall times also warn against averaging blindly. Multi at 27.18 s in the paper experiment is more than eight times One at 3.08 s, so a small rise in C share can dominate the mean. Report latency percentiles by predicted label, and set budgets per label rather than one global p95 target that only the B path can meet.

Classifier cost itself is usually small next to C, but it is not free on every query. If A and B already dominate and C is under 10% of traffic, a tiny classifier is still worth it; if every query needs a multi-hop solver, skip Adaptive-RAG and pay IRCoT directly without the extra forward pass.

When should you use Adaptive-RAG, and when should you avoid it?

Adaptive-RAG earns its classifier when query traffic really mixes easy parametric questions, single-hop corpus lookups and multi-hop compositions. It is usually the wrong default when almost every query needs the same strategy.

Use it on mixed-complexity traffic when always-on IRCoT is too expensive and always-on single-step is too weak, which is the paper motivating distribution (Jeong et al., 2024, Introduction). Meilisearch Adaptive RAG explained makes a related product claim for adaptive systems generally: change behaviour by query rather than paying one expensive path for all tickets. That advice applies only if you can measure complexity mix in logs.

Avoid Adaptive-RAG when complexity is uniform. If logs are almost all multi-hop, implement multi-hop RAG or IRCoT directly; if they are almost all single-hop, stay on Naive RAG. Budget for classifier error: silver labels can be wrong; only three discrete complexity levels are modeled; the oracle gap in Table 1 shows remaining headroom (Jeong et al., 2024, Limitations).

Also avoid treating Adaptive-RAG as a substitute for evaluation harnesses. A router that looks efficient on average Step can still fail the multi-hop subset that matters to users; score EM or task success by predicted label, not only in aggregate.

Security and tenancy constraints still apply on every branch. An A path that skips retrieval can still leak parametric memorisation; a C path that retrieves more documents expands the attack surface for prompt injection through retrieved text. Adaptive-RAG does not replace access control or redaction; it only chooses how many retrieves to run. Pair routing with the same security controls used on Naive RAG.

When product owners ask for adaptive because a competitor blog used the word, demand the decision table: A, B, or C, with measured share and latency. If the request is really for hybrid search, query rewriting, or self-RAG reflection, route that work to the owning sibling instead of forcing Jeong labels onto a different mechanism.

How does Adaptive-RAG differ from adaptive retrieval and Self-RAG?

Adaptive-RAG is a three-strategy router. Binary adaptive retrieval (Mallen et al. entity-frequency gates, Self-RAG Retrieve tokens, confidence gates) mainly decides whether to retrieve at all, covered on adaptive retrieval. Self-RAG additionally trains the generator to emit reflection tokens; Adaptive-RAG keeps a separate T5-Large classifier and swappable solvers, and compares to Self-RAG only with the different-base-LLM caveat in Table 1 (Jeong et al., 2024, section 4.2).

The multi-step branch is usually an IRCoT-style loop: mechanism depth at IRCoT rather than in the router description. FLARE mid-generation confidence retrieve is a different trigger timing again, covered on FLARE. ReAct Thought-Action-Observation can implement toolful multi-step behaviour, but it is an agent loop rather than a pre-answer A/B/C classifier, covered on ReAct RAG.

Sotaaz agentic routing posts place Adaptive-RAG-style decisions inside a larger agentic control story. That survey depth belongs on Agentic RAG; Adaptive-RAG stops at the Jeong three-way classifier and its measured Step/Time trade-off.

The naming collision with Meilisearch Adaptive RAG explained is the other boundary to keep sharp. Hybrid fusion, rewriting, and self-correcting loops can coexist with Adaptive-RAG, but they are not Adaptive-RAG. A stack can run Weaviate hybrid search inside B and C while the Jeong classifier still owns only the A/B/C choice.

FLARE mid-generation retrieve and ReAct tool loops can appear after Adaptive-RAG selects C, if the C solver is built that way, but Jeong default C is IRCoT-style interleaving. Do not claim FLARE or ReAct gains from Adaptive-RAG Table 1; those gains belong to the solver you actually wired into C.

How do you implement Adaptive-RAG?

Implementation is a handoff checklist: train the complexity classifier, wire three solvers, route, and evaluate accuracy with Step and Time. Build silver A/B/C labels by preferring outcome-based labels with simpler-wins tie-break, then fill gaps with single-hop to B and multi-hop to C bias (Jeong et al., 2024, section 3.2). Train a small classifier; the paper instantiation is T5-Large, and size ablations in the paper show smaller classifiers remain usable (section 5).

Implement three solvers: no-retrieval LLM; single-step BM25 plus LLM (paper retriever is BM25); multi-step IRCoT-style branch with a max-step ceiling. Route on classifier output before any solver runs. Start from the official starsuzi/Adaptive-RAG repository for paper fidelity; end-to-end wiring at building a RAG pipeline.

Hybrid retrieval behind B and C can sit on Weaviate without changing the router. Log predicted label, solver Step count, and answer correctness together so confusion modes are visible. Lightweight routing baselines such as arXiv:2604.03455 are optional comparisons once the Jeong pipeline is reproducing; they are not required to claim Adaptive-RAG behaviour.

Do not ship the router without a held-out mix that includes parametric-easy, single-hop, and multi-hop tickets. A classifier trained only on multi-hop demos will over-predict C and erase the efficiency gain Table 1 advertises.

A practical rollout order is: freeze B as the baseline Naive RAG path; add C with IRCoT stop rules and measure its lift on multi-hop only; add A only after you have a safe parametric subset; train the classifier last so silver labels reflect the solvers you will actually run. Skipping that order trains a router against solvers that later change, which recreates the oracle gap without the efficiency.

Lightweight routers from arXiv:2604.03455 can be compared against T5-Large once the three solvers are stable. Keep Jeong Table 1 metrics (EM, F1, Acc, Step, Time) as the scoreboard so a cheaper classifier is not declared better on latency alone while multi-hop EM falls.

How should you measure query-complexity mix before routing?

Adaptive-RAG only pays for itself when the live mix contains enough A and B queries to offset C. Before training a classifier, sample production questions and label them by hand into parametric-easy, single-hop corpus, and multi-hop composition buckets. If more than about two thirds already need multi-hop evidence, Jeong Table 1 efficiency story will not transfer, because the router will mostly select C and still pay IRCoT cost.

Eduinx Adaptive RAG 2026 and ragaboutit Query-Adaptive RAG both stress keeping simple queries on a fast path. That advice is measurable: track p50 and p95 latency separately for predicted A, B, and C, and track answer success in each bucket. A router that improves average Time while collapsing multi-hop success is a regression, not a win.

Silver labels from outcome-based solvers are a starting point, not ground truth. Re-label a held-out slice with humans when the confusion matrix shows No to One rates near the paper 47% figure, because that mode silently upgrades cheap parametric answers into unnecessary retrieves.

What operational failure modes show up after Adaptive-RAG ships?

Three failure modes dominate once Adaptive-RAG leaves the paper split. First, label drift: the mix of easy versus multi-hop tickets changes after a product launch, so a classifier trained on last quarter logs over-predicts C or under-predicts it. Retrain on a rolling window and watch the share of C predictions week over week.

Second, solver skew: the B solver and C solver may use different chunkers, indexes, or generators. Jeong experiments keep modules swappable, but a production stack that gives C a better index than B will make the classifier look worse than it is, because hard queries routed correctly still fail for index reasons. Keep B and C on the same corpus snapshot when you score the router.

Third, stop-budget mismatch on C: Adaptive-RAG selects IRCoT-style multi-step, but without a max-step ceiling the C path can still explode cost. Pair the router with the IRCoT stop rules (answer is: or max steps) documented on the IRCoT sibling so C cannot run unbounded after a correct Multi prediction.

Meilisearch-style adaptive marketing that bundles rewriting, hybrid fusion, and self-correction into one umbrella can hide which of those three modes you actually fixed. Name the decision Adaptive-RAG owns: A versus B versus C before solving starts.

Teams that already run IRCoT for every ticket can still adopt Adaptive-RAG later by freezing that IRCoT stack as C, adding a single-step B path that reuses the same Weaviate collection, then training the classifier on silver labels from both solvers. The efficiency win appears only after B absorbs the easy share; until then Adaptive-RAG is just IRCoT with an unused A/B option. The same caution applies if A is disabled for policy reasons: a two-way B/C router can still beat always-C on Time, but it will not match Jeong three-way Table 1 averages until A traffic exists and is labeled.

Adaptive-RAG is Jeong et al. (2024) three-way query-complexity routing: classify each query as no retrieval, single-step, or multi-step, then run only that solver. On FLAN-T5-XL, Adaptive-RAG approaches always-multi-step EM while cutting relative Time from 8.81 to 3.60, with an oracle upper bound showing remaining classifier headroom. Choose Adaptive-RAG when traffic truly mixes complexities; choose Naive RAG or IRCoT when the mix is uniform; choose binary adaptive retrieval when the only decision is retrieve versus skip.