PlanRAG: Planning-Centric Retrieval-Augmented Generation

• PlanRAG is a family of planning-centric retrieval-augmented generation techniques that insert an explicit planning stage prior to evidence retrieval to guide subsequent synthesis.
• Explicit planning in PlanRAG mitigates common retrieval flaws by reducing missed analyses and wrong candidate selections in decision QA and exploratory reasoning tasks.
• Variants like PlanRAG-Audio and logical query trees extend the paradigm to multimodal and complex query scenarios, balancing planning overhead with enhanced execution accuracy.

PlanRAG designates planning-centric forms of retrieval-augmented generation in which retrieval is conditioned not only on the raw user query but also on an explicit intermediate structure—such as an analysis plan, a retrieval contract, a logical query tree, or a workflow controller—that determines what evidence should be acquired, from which source, in what order, and for what downstream reasoning objective. In current arXiv usage, the term does not denote a single settled architecture. Instead, it spans several closely related formulations, including plan-then-retrieval for decision making over structured databases, modality-aware retrieval planning for long-form audio, and logical query planning for exploratory reasoning problems (Lee et al., 2024, Masao et al., 19 May 2026, Xu et al., 1 Jul 2026).

1. Terminology and conceptual scope

Taken together, the recent literature suggests that “PlanRAG” functions as a family-resemblance label rather than a single canonical method. The common commitment is that retrieval should be preceded or governed by an explicit planning layer, but the planning object varies substantially across papers. In some formulations, the plan is an analysis sequence over database queries; in others, it is a schema-constrained retrieval contract, a logical query tree, or a systems-level execution policy (Lee et al., 2024, Xu et al., 1 Jul 2026, Iannelli et al., 2024).

Formulation	Planning object	Primary setting
PlanRAG (Lee et al., 2024)	analysis plan and re-plan over database queries	Decision QA over RDB/GDB
PlanRAG-Audio (Masao et al., 19 May 2026)	structured retrieval plan over modalities and temporal spans	long-form audio understanding
PlanRAG (Xu et al., 1 Jul 2026)	logical query tree over atomic queries	exploratory reasoning problems

This variety matters because the literature uses “planning” at different layers. One layer concerns semantic decomposition of a question into subanalyses; another concerns retrieval planning over heterogeneous memories or modalities; a third concerns orchestration under cost, latency, or SLA constraints. A plausible implication is that PlanRAG is best understood as a research direction centered on explicit control over retrieval, rather than as a narrowly defined algorithmic family.

The strongest unifying claim across the core papers is that conventional retrieve-then-generate pipelines are brittle when the answer depends on multi-step analysis, ambiguous dependency structure, long multimodal evidence, or costly execution choices. PlanRAG methods therefore insert structure before retrieval: a plan constrains what to retrieve, and retrieved evidence is then used for grounded reasoning or answer synthesis (Lee et al., 2024, Masao et al., 19 May 2026, Xu et al., 1 Jul 2026).

2. Decision-oriented PlanRAG and the plan-then-retrieval formulation

The paper that names the paradigm most directly defines Decision QA as generating the best decision $d_{\text{best}}$ from a decision-making question $Q$, business rules $R$, and a structured database $D$ (Lee et al., 2024). The central claim is that ordinary RAG is oriented toward knowledge lookup, whereas decision making requires the model first to determine what analysis must be performed. PlanRAG therefore inserts an explicit planning stage before retrieval, followed by iterative query generation, observation, and optional re-planning.

Its prompting format extends ReAct with Plan, Current step, Thought, Action, Action input, Observation, Re-plan, and Final answer. The plan is not an after-the-fact explanation; it is a specification of the series of data analyses needed for the decision. Retrieval is then conditioned on the current plan step and executed through SQL for relational databases or Cypher for graph databases. Re-planning is triggered when the current retrieval trajectory is no longer helpful.

The benchmark introduced for this setting, DQA, contains two scenarios built from grand-strategy games: Locating from Europa Universalis IV and Building from Victoria 3. It includes 301 pairs of $(Q, D)$, with 200 for Locating and 101 for Building, and each database has both RDB and GDB versions, yielding 602 total databases (Lee et al., 2024). This construction is intended to approximate decision problems in which the best answer is not stored directly and must be inferred from business-rule-like formulas over large structured state.

Empirically, the method improved over the paper’s iterative RAG baseline by 15.8 percentage points in Locating and 7.4 percentage points in Building. The full reported accuracies were 64.3 versus 48.5 in Locating and 45.0 versus 37.6 in Building. Re-planning was materially important in Locating: removing it reduced accuracy from 64.3 to 53.5, while the drop in Building was smaller, from 45.0 to 44.1 (Lee et al., 2024).

The paper’s failure analysis is also central to the PlanRAG idea. It distinguishes improper candidate consideration, missed data analysis, improper use of retrieved data or equations, query generation error, and other errors. PlanRAG mainly reduces CAN and MIS failures, which indicates that explicit planning improves problem setup and coverage of critical variables. The remaining bottleneck is deeper reasoning over already retrieved values and rules. This suggests that plan-first retrieval improves analytical completeness, but does not by itself solve downstream symbolic or numerical reasoning.

3. Logical query trees and exploratory reasoning

A later paper redefines PlanRAG for exploratory reasoning problems (ERPs), which are characterized by high uncertainty, ambiguity, unclear reasoning paths, and coupled sub-tasks (Xu et al., 1 Jul 2026). Here the target is not primarily database QA but open-domain reasoning over complex natural-language queries. The key innovation is to model the query as a logical query tree (LQT), a directed acyclic graph $\mathcal{T} = (V, E)$ whose nodes are atomic queries and whose edges encode semantic dependency.

The pipeline has three stages. First, an LLM decomposes the ERP into atomic queries, each constrained to correspond to a single semantic triple. Second, the system constructs an optimized LQT using a Selinger-style dynamic program, supported by pairwise relation classification into parent-child, sibling, or unrelated. Third, execution proceeds bottom-up: leaf nodes retrieve and generate directly, while internal nodes aggregate child answers, rewrite their own query in context, retrieve again, and generate a refined answer (Xu et al., 1 Jul 2026).

The paper formalizes the execution semantics as: $$\mathrm{Ans}(v) = \mathrm{Generate}\bigl(\mathrm{Retrieve}(v)\bigr)$$ for leaf nodes, and for internal nodes: $$\mathrm{Ctx}(v) = \mathrm{Aggregate}\!\left( \{ (v, u, \mathrm{Ans}(u)) \mid u \in \mathrm{Children}(v) \} \right),$$

$$v' = \mathrm{Rewrite}\!\left(v, \mathrm{Ctx}(v)\right),$$

$$\mathrm{Ans}(v') = \mathrm{Generate}\!\left( \mathrm{Retrieve}(v') \right).$$

Optimization is guided by a heuristic cost model: $Q$0 with candidate selection by minimum cost. The structural terms favor compact, well-connected, shallow, and balanced trees, while the semantic term measures similarity between the original ERP and a natural-language rendering of the tree (Xu et al., 1 Jul 2026). The paper is explicit that this is heuristic optimization rather than classical cost-based optimization with formal guarantees.

The benchmark introduced for this formulation, WikiWeb-ERP, contains 3,536 queries and 53,682 documents, combining samples from existing benchmarks and generated ERP-style queries, with documents drawn from both Wikipedia and live webpages (Xu et al., 1 Jul 2026). On this dataset, PlanRAG w/ Ret achieved 26.43 Acc, 30.15 F1, 23.36 EM, and 30.68 Acc$Q$1, outperforming both iteration-based and graph-based baselines.

Efficiency results are integral to the method’s identity. Relation preprocessing reduced average planning time from 82.8s to 8.4s, token cost from 3454.4 to 1265.2, and LLM calls from 63.6 to 10.4. Parallel execution reduced average execution time from 18.7s to 7.3s, a $Q$2 speedup (Xu et al., 1 Jul 2026). The paper therefore frames PlanRAG not only as better reasoning structure but also as an execution model that exploits concurrency through balanced tree planning.

4. Modality-aware and interactive extensions

The most explicit multimodal extension is PlanRAG-Audio, which adapts the paradigm to long-form audio understanding (Masao et al., 19 May 2026). Its central claim is that the difficulty of long recordings is not only raw length but the need to reason over heterogeneous acoustic cues distributed across time, including speech content, speaker identity, emotion, and sound events. The system therefore preprocesses audio into a structured database $Q$3 with modality-specific streams, generates a schema-constrained retrieval plan $Q$4, compiles it into SQL $Q$5, and executes: $Q$6

The retrieval plan specifies which streams are needed, what filters to apply, how to fuse them temporally, which fields to return, and what answer schema the generator must obey. This plan-first design turns a query into an executable retrieval program over time-aligned structured memory rather than over raw waveform. The main experiments intentionally use keyword-based retrieval to isolate the effect of planning rather than retriever strength (Masao et al., 19 May 2026).

The paper’s scaling results are unusually concrete. For MCQA with 60-minute recordings, average input tokens were 115.2k for Gemini, 0.9k for Gemini + PlanRAG-Audio, and 1.2k for Qwen + PlanRAG-Audio. On advanced tasks, the gains were especially large where answers reduced to symbolic reasoning over retrieved records. In speaker count, Gemini improved from 14.20 to 69.40 with PlanRAG; in event ordering, Gemini improved from 0.30 to 0.68; and in speaker-constrained MCQA, Gemini + PlanRAG reached 70.96 constrained QA accuracy and 94.90 abstention accuracy (Masao et al., 19 May 2026). The paper characterizes the effect as performance stabilization rather than complete elimination of degradation as duration increases.

A closely related planning-oriented line is P-RAG, “Progressive Retrieval Augmented Generation,” for embodied everyday tasks (Xu et al., 2024). Although it is not named PlanRAG, it is explicitly framed as retrieval-augmented planning rather than factual QA. The system stores past trajectories consisting of goal instruction, scene graph, history, and done state, retrieves relevant experiences using both task similarity and situation similarity, and progressively updates its database after each interaction round. Its composite retrieval score is: $Q$7

This design makes planning state-aware: retrieval is conditioned on both the current task and the current situation. On ALFRED Valid Unseen, success rose from 7.05% for the GPT-4 baseline to 14.11% for P-RAG, then to 20.00% and 22.35% over later iterations, reaching 27.4% after 5 rounds in the saturation plot (Xu et al., 2024). The scene-graph ablation, 14.11% versus 13.10% without scene-graph retrieval, indicates that situation-level retrieval contributes additional value beyond task-name similarity alone.

5. Orchestration, modularity, and lifecycle interpretations

A broader literature treats PlanRAG less as a semantic decomposition method and more as an orchestration problem. Modular RAG argues that modern RAG has outgrown the classical “retrieve-then-generate” abstraction and should instead be modeled as a reconfigurable flow graph of modules and operators with explicit routing, scheduling, and fusion (Gao et al., 2024). In that framework, PlanRAG is discussed as a new flow created by orchestration rather than by wholly new primitives: an initial planning stage precedes retrieval, a judge module decides whether to adjust the plan, and subqueries are generated and executed under targeted retrieval.

This modular perspective is important because it identifies the flow patterns in which planning appears: linear, conditional, branching, and looping. Conditional flows correspond to plan-template selection; branching corresponds to subgoal execution; looping corresponds to iterative retrieval, recursive clarification, or adaptive retrieval triggers. A plausible implication is that many PlanRAG systems can be described as explicit control-flow graphs whose novelty lies in orchestration rather than in any single retriever or generator.

A second systems-level strand studies planning under service constraints. “SLA Management in Reconfigurable Multi-Agent RAG” presents a planning module that maps SLA and QoS targets to system-level parameters such as the number of agents, source selection, preprocessing strategies, arbitration mechanisms, and answer thresholds (Iannelli et al., 2024). Its planning is not semantic decomposition but runtime configuration under answer quality, cost, and latency objectives. The paper formalizes cost and latency models, and in its case study shows that increasing ensemble size improved quality: the best 5-agent settings achieved Recall 0.684, Precision 0.691, F1 0.688, Hallucination Rate 0.220, and Incongruent Response Rate 0.012 (Iannelli et al., 2024). This widens the meaning of planning in PlanRAG to include execution policy.

A third interpretation comes from RAG-Stack, which recasts RAG optimization as a database-style planning problem over a quality–performance Pareto frontier (Jiang, 23 Oct 2025). Its three pillars are RAG-IR, an intermediate representation of per-request dataflow graphs; RAG-CM, a cost model; and RAG-PE, a plan exploration algorithm. The framework is explicitly concerned with “RAG serving plans” and with finding near-Pareto-optimal configurations while minimizing the number of explored trials. This does not implement a finished PlanRAG system, but it provides a blueprint for treating retrieval strategy, chunking, reranking, hardware placement, index choices, KV-cache reuse, and speculative retrieval as plan variables (Jiang, 23 Oct 2025).

Operational and lifecycle papers further broaden the concept. A short position paper on local RAG for large computing systems argues that RAG should be developed “symbiotically” with the system itself, so that documentation, prompt design, and the retrieval stack co-evolve (Naikov et al., 23 Jan 2025). It is explicit that this is not a PlanRAG method in the narrow sense, but its iterative loop of asking test questions, identifying incorrect responses, and refining the description is planning-relevant at the systems-engineering level. RAGOps extends that operational view by treating production RAG as two intertwined lifecycles: the online query-processing pipeline and a separate data-management lifecycle for ingestion, verification, retrieval-source updates, offline testing, live testing, and coverage checking (Xu et al., 3 Jun 2025). In that perspective, a planning-oriented RAG system must also be observable, testable, and maintainable under continuous data change.

6. Limitations, ambiguities, and open problems

Across the literature, the most obvious limitation is terminological. “Planning” refers to different objects in different papers: the original PlanRAG plans data analyses over structured databases; PlanRAG-Audio plans retrieval over modalities and time spans; the LQT formulation plans a global dependency structure over atomic queries; systems papers plan execution graphs, agent ensembles, or lifecycle operations (Lee et al., 2024, Masao et al., 19 May 2026, Xu et al., 1 Jul 2026, Iannelli et al., 2024). This suggests that PlanRAG is an active but not yet standardized concept.

Algorithmically, planning quality remains a bottleneck. The LQT paper’s error analysis attributes 36% of failures to planning errors and 32% to retrieval errors, indicating that better generation alone is not the limiting factor (Xu et al., 1 Jul 2026). In the original Decision QA setting, PlanRAG reduces missed analyses and candidate omissions, yet still leaves substantial deep reasoning failures once the right evidence has been retrieved (Lee et al., 2024). In long-form audio, performance remains bounded by upstream ASR, diarization, emotion, and event-detection quality; the paper explicitly decomposes remaining errors into perception, retrieval, and planning/generation/formatting components (Masao et al., 19 May 2026).

Several papers also acknowledge that current planning machinery is heuristic rather than optimal. The LQT cost model has no formal guarantee that the selected tree is globally best for answer quality or runtime (Xu et al., 1 Jul 2026). The SLA-aware multi-agent framework defines the configuration surface and control knobs, but not a full optimizer or learned planner (Iannelli et al., 2024). RAG-Stack is even more explicit: it is a blueprint for IR, cost modeling, and plan exploration, not a fully instantiated optimizer with validated search behavior (Jiang, 23 Oct 2025).

A second recurring limitation is dependence on external structure. PlanRAG-Audio relies on structured multimodal memory built by preprocessing, P-RAG relies on scene-graph extraction and self-collected trajectories, and local enterprise or scientific systems rely on trustworthy documentation, retrieval sources, or tool interfaces (Masao et al., 19 May 2026, Xu et al., 2024, Naikov et al., 23 Jan 2025, Xu et al., 3 Jun 2025). When those substrates are incomplete, noisy, or stale, the planner can only optimize over flawed evidence.

A third issue is control versus cost. Explicit planning adds tokens, LLM calls, preprocessing, and orchestration overhead. Some papers show that the overhead is justified because it sharply reduces downstream retrieval noise or generator context length, but none claim planning is always beneficial. The LQT paper notes that its method may be overkill for simple queries or tasks with obvious stepwise reasoning, while the audio paper notes that preprocessing cost is amortized over queries but may limit real-time applicability (Xu et al., 1 Jul 2026, Masao et al., 19 May 2026).

The literature therefore points toward a common research agenda rather than a finished doctrine. A plausible synthesis is that future PlanRAG systems will need to combine three levels of planning that are currently studied separately: semantic planning over subgoals, retrieval planning over heterogeneous evidence stores, and systems planning over latency, cost, privacy, and lifecycle constraints. The existing papers establish that each layer can matter; they do not yet unify those layers into a single stable paradigm.