SQLConductor: Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

SQLConductor: Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

machine learning, deep learning, neural networks

SQLConductor: Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration Yizhang Zhu

Zhangyang Peng

Boyan Li

Yuyu Luo*

HKUST(GZ) Guangzhou, China [email protected]

arXiv:2606.23537v1 [cs.DB] 22 Jun 2026

ABSTRACT Text-to-SQL enables users to access relational databases through natural language questions, but real-world Text-to-SQL remains challenging due to the need for coordinated reasoning over complex database environments. Existing systems often rely on carefully designed multi-stage Text-to-SQL pipelines, sometimes further enhanced with trained reasoning models specialized for individual stages. However, such fixed pipelines rely on predefined stage orders, limiting their adaptivity to different query demands and intermediate evidence. Recent orchestration-based methods provide a more flexible alternative by composing specialized modules for each query, but typical plan-then-execute orchestration still commits to a complete workflow before execution and cannot sufficiently adapt to intermediate artifacts and feedback. In this paper, we propose SQLConductor, a step-wise orchestration learning framework for Text-to-SQL. SQLConductor formulates typical Text-to-SQL subtasks as specialized actions in an action space for flexible workflow composition, and trains a policy model to decide the next action based on intermediate artifacts and feedback. To learn such an adaptive policy, SQLConductor introduces Search-to-Policy Learning, which uses Monte Carlo Tree Search to explore candidate workflows and stability estimation to identify robust workflow supervision. The policy model is trained with Stability-weighted Supervised Fine-tuning to prioritize high-quality orchestration patterns, and further enhanced through Curriculum Reinforcement Learning. In this way, broad offline workflow search is transformed into a deployable policy for efficient step-wise orchestration at inference time. Extensive experiments on BIRD-Dev and out-of-distribution datasets show that SQLConductor achieves superior execution accuracy and strong generalization, reaching 73.2% EX on BIRD-Dev by training a compact orchestration policy to coordinate frozen larger action models, outperforming prior methods directly training comparable or larger Text-to-SQL backbones. Further analyses show that the learned policy adapts workflow orchestration to diverse query demands.

INTRODUCTION

Text-to-SQL aims to enable non-technical users to access relational databases through natural language (NL) questions [11, 26] and has become an important interface for data analytics and business intelligence in the era of large language models (LLMs) [29, 32, 62, 64]. Despite recent progress, real-world Text-to-SQL remains challenging. A practical Text-to-SQL system needs to locate relevant tables and columns in large and heterogeneous schemas, align query conditions with database contents, and construct complex query

NL Ques(on Database NLNL Ques(on Ques(onDatabase Database

Final SQL

(a) Fixed Pipeline NL Ques(on Database NLNL Ques(on Ques(onDatabase Database

Orchestrate

aa11 a1

Execute Orchestrated Workflow in Order

aa22 a2

aa33 a3

Orchestrated Workﬂow

Final SQL

(b) Plan-then-Execute Orchestration NL Ques(on Database NLNL Ques(on Ques(onDatabase Database

Want to take previous ac9on (a2) again? ok 2

State

a3 … a4

5 State

a2 … a5

Final SQL

Figure 1: Comparison of fixed workflow, plan-then-execute orchestration, and step-wise orchestration for Text-to-SQL. logic [17, 30]. Correct SQL generation therefore requires coordinating these reasoning steps into an effective solving procedure. From Fixed Pipelines to Orchestration. To handle these difficulties, some Text-to-SQL systems introduce meticulously designed pipelines to decompose Text-to-SQL into more manageable subtasks, such as schema linking, value retrieval, SQL generation, revision, and selection [3, 5, 48, 52]. Some methods further strengthen such pipelines by incorporating stage-specific reasoning models trained with large-scale supervision [12, 44, 49]. These designs have achieved strong performance by introducing structured reasoning procedures and task-specific adaptation. However, as shown in Figure 1(a), this paradigm relies on a predefined stage order. This rigidity limits adaptivity to different query demands and intermediate evidence. For straightforward questions, the fixed procedure may also introduce unnecessary steps, extra noise, and a higher risk of hallucination [4, 63]. For complex cases, once an early stage misses key schemas or values, later stages may proceed under a flawed premise, leading to error propagation. Although intermediate artifacts such as filtered schemas and execution feedback can provide useful signals, a fixed pipeline can only utilize them for later stages rather than reconsider earlier decisions. A more flexible direction is to coordinate Text-to-SQL through workflow orchestration. Rather than applying the same workflow to every question, orchestration selectively composes specialized modules into a query-specific workflow [8, 42, 58]. This separates

Yizhang Zhu, Zhangyang Peng, Boyan Li, and Yuyu Luo*

subtask reasoning from process organization: specialized modules handle concrete Text-to-SQL subtasks, while an orchestration policy decides which to invoke and how to combine them [18, 36, 57]. Attempts at Text-to-SQL Orchestration. Some recent methods have started to explore orchestration for Text-to-SQL. A typical strategy is plan-then-execute orchestration [51] as illustrated by Figure 1(b): the system first plans a complete workflow for the input query, and then invokes action modules in the order specified by the planned workflow. Compared with fixed pipelines, planthen-execute orchestration provides better flexibility by producing a query-specific workflow. However, as shown in Figure 1(b), once the workflow execution begins, its procedure becomes fixed again. As a result, the system is still limited in adjusting later decisions based on intermediate artifacts or execution feedback. These limitations suggest that planning a complete workflow before execution is not sufficient. A more desirable approach is to leverage intermediate results for step-wise orchestration as illustrated in Figure 1(c): instead of committing to the entire workflow upfront, the system can use intermediate artifacts and execution feedback to decide the next action accordingly. This can enable the workflow to better adapt to the solving demand and evolving reasoning process of each query. Challenges. However, learning such a step-wise orchestration policy is non-trivial, mainly due to the following challenges. (C1) Heterogeneous Workflow Demands Across Queries. Different queries can require diverse workflow compositions. Some queries may be resolved through direct SQL generation, whereas others may require additional evidence-gathering, refinement, or iterative generation as intermediate feedback emerges. Therefore, effective orchestration requires both a composable decision space and a policy that adapts its orchestration decisions to each query’s evolving reasoning process. (C2) Scarce Workflow Data for Orchestration Learning. Learning such adaptive orchestration requires large-scale, highquality, and diverse Text-to-SQL workflow data that covers different queries and databases, workflow compositions, or decision patterns and reasoning trajectories. However, such data is rarely available and impractical to obtain through manual annotation. This raises the challenge of deriving workflow-level supervision without relying on human-crafted workflows. (C3) Large, Non-Unique, and Noisy Workflow Space. The workflow space is combinatorial and inherently diverse. A question may admit multiple valid workflows, and no single canonical workflow can generally serve as the ground truth. Moreover, a workflow that reaches the correct answer is not necessarily reliable, since its success may be accidental or unstable. Effective orchestration learning therefore requires identifying high-quality workflows while preserving useful workflow diversity. Our Proposal. To systematically address these challenges, we propose SQLConductor, a step-wise orchestration learning framework for Text-to-SQL. To address C1, SQLConductor formulates typical Text-to-SQL subtasks as specialized action modules in an action space, and trains a policy model to make step-wise orchestration decisions based on the current solving context. This allows the system to compose workflows with flexible action combinations for various

query demands. To address C2, SQLConductor introduces Searchto-Policy Learning, where MCTS-based Workflow Exploration treats workflow construction as a tree-structured search over the action space. By balancing broad exploration with execution-guided selection, it automatically discovers diverse promising workflows, avoiding the need for human-crafting. To address C3, SQLConductor further estimates the stability of explored workflows and curates reliable yet diverse trajectories for policy learning. The policy model is first trained with Stability-weighted Supervised Fine-tuning to absorb robust orchestration patterns, and is then enhanced through Curriculum Reinforcement Learning. In this way, broad offline search is converted into a deployable policy that can make efficient step-wise orchestration decisions at inference time to adapt to the different demands and evolving reasoning processes for diverse queries. Contributions. We make the following contributions: (S1) A Step-wise Orchestration Learning Framework. We propose SQLConductor, a step-wise orchestration learning framework for Text-to-SQL that separates process organization from subtask execution. Instead of planning and fixing a complete workflow upfront, SQLConductor learns to dynamically orchestrate next action based on intermediate artifacts and feedback, enabling queryspecific workflows with adaptive depths and module compositions. (S2) Search-to-Policy Learning for Adaptive Orchestration. We introduce a Search-to-Policy Learning mechanism to train the orchestration policy. We first perform MCTS-based Workflow Exploration to discover high-quality and diverse candidate trajectories, then curate reliable workflows through stability estimation, training the policy model with Stability-weighted Supervised Finetuning to prioritize robust orchestration patterns while preserving diversity, followed by Curriculum Reinforcement Learning for further enhancement. This transforms offline workflow search into an inference-time policy for adaptive orchestration. (S3) Extensive Experiments and Empirical Insights. SQLConductor achieves superior execution accuracy, reaching 73.2% EX on BIRD-Dev by training only a much smaller orchestration policy to coordinate frozen larger action models, outperforming prior methods that directly train comparable or larger Text-to-SQL backbones. Additionally, SQLConductor demonstrates strong generalization across out-of-distribution datasets without specific training. Further analyses also reveal how SQLConductor adapts workflow orchestration to diverse queries.

2 PRELIMINARIES 2.1 Text-to-SQL The Text-to-SQL task aims to translate a natural language question into an executable SQL query over a relational database. Formally, given a natural language question 𝑞 and a database D, a Text-toSQL system generates an SQL query 𝑦. Executing 𝑦 on D produces the query result used to answer 𝑞, denoted as Exec D (𝑦). Text-to-SQL is primarily evaluated with execution accuracy (EX), which measures whether the predicted SQL query produces the same execution result as the ground-truth query [22]. Let 𝑦 ∗ denote the ground-truth SQL. A predicted query 𝑦 is considered correct if: Exec D (𝑦) = Exec D (𝑦 ∗ ).

(1)

SQLConductor : Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

2.2

Workflow Orchestration for Text-to-SQL

To handle the coordinated reasoning required by real-world Textto-SQL, workflow orchestration provides a flexible formulation that organizes specialized action modules into a workflow. Formally, let A = {𝑎 (1) , 𝑎 (2) , . . . , 𝑎 (𝐾 ) } denote an action space. A workflow is a finite action sequence: 𝜏 = (𝑎 1, 𝑎 2, . . . , 𝑎𝑇 ),

𝑎𝑡 ∈ A.

(2)

Executing a workflow on (𝑞, D) further induces a trajectory that records the orchestration states and intermediate action outputs: 𝜉 = (𝑠 0, 𝑎 1, 𝑜 1, 𝑠 1, . . . , 𝑎𝑇 , 𝑜𝑇 , 𝑠𝑇 ),

𝑜𝑡 = 𝑎𝑡 (𝑠𝑡 −1, D),

(3)

where 𝑠 0 is the initial orchestration state induced by (𝑞, D), 𝑜𝑡 is the output of action 𝑎𝑡 , and 𝑠𝑡 is the updated state after incorporating 𝑜𝑡 . The workflow can therefore be viewed as the action-level abstraction extracted from a trajectory. In Text-to-SQL, the final prediction 𝑦 is obtained from the terminal state. Plan-then-Execute Orchestration. One orchestration strategy is to first use an orchestration policy 𝜋 to generate a complete workflow, as shown in Figure 1(b): 𝜏 = 𝜋 (𝑞, D).

(4)

The actions in 𝜏 are then invoked in order. Compared with a universal fixed pipeline, plan-then-execute orchestration provides a query-specific workflow. However, since the entire workflow is determined before execution, the action sequence is not revisable according to intermediate evidence produced during execution. Step-wise Orchestration. In contrast, step-wise orchestration applies the orchestration policy during execution, as shown in Figure 1(c). At each step 𝑡, the policy selects the next action according to the current orchestration state, i.e., 𝑎𝑡 = 𝜋 (𝑠𝑡 −1 ),

𝜏𝜋 = (𝑎 1, 𝑎 2, . . . , 𝑎𝑇 ).

(5)

After the selected action is invoked, its output is incorporated into the orchestration state, which forms the context for the next decision. Since each state incorporates previous actions and their outputs, the next decision can condition on updated evidence, making the workflow adaptive to the evolving solving context of each query. In this paper, we focus on learning such a step-wise workflow orchestration policy for Text-to-SQL.

SQLCONDUCTOR OVERVIEW

Figure 2 illustrates the overall framework of SQLConductor, which consists of two phases: offline Search-to-Policy Training and online Deployment. In the offline phase, SQLConductor uses MCTS to explore Text-to-SQL workflows, curates workflow supervision, and trains a policy model with stability-weighted supervision and reinforcement learning. In the online phase, the learned policy model coordinates action modules step by step to solve each input query. This design separates process organization from subtask reasoning: the trainable policy learns how to orchestrate effective Text-to-SQL workflow, while frozen LLM-driven specialized action modules carry out concrete subtasks in the workflow. Offline: Search-to-Policy Training. As illustrated in Figure 2-A, the goal of the offline phase is to learn a step-wise orchestration policy from automatically constructed workflow supervision.

(1) MCTS-based Workflow Exploration. SQLConductor first performs Monte Carlo Tree Search over the action space. Each node represents an orchestration state, and each edge corresponds to an action selection. The search process broadly explores different action compositions and workflow depths, while using execution outcomes to guide the discovery of promising workflows. This produces a diverse set of candidate workflows for each training instance, covering a wide range of potential solving paths. (2) Workflow Supervision Curation. The searched workflows are diverse but may contain unstable or accidental successes. Therefore, SQLConductor further processes and curates workflow supervision before training. Specifically, it extracts workflow skeletons, i.e., action sequences, from candidate trajectories, groups with the same skeleton, and estimates the stability of each workflow according to its success and failure statistics. Then, SQLConductor selects top-ranked workflow skeletons and converts their representative trajectories into step-level instruction-tuning formatted data, which contains the current orchestration context, its next action, and the corresponding stability score. This step filters unreliable workflows while preserving diverse orchestration patterns. (3) Stability-weighted Supervised Fine-tuning. Based on the curated training samples, SQLConductor introduces Stabilityweighted Supervised Fine-tuning to train the policy model in step 3. Different from treating all selected samples equally, this training objective assigns larger weights to samples with higher stability scores. In this way, the policy is encouraged to learn more robust orchestration patterns from explored workflows, while still retaining alternative valid solving strategies. (4) Curriculum Reinforcement Learning. In step 4, SQLConductor further enhances the policy through curriculum reinforcement learning. The curriculum emphasizes challenging queries that are less effectively solved during MCTS-based exploration. For these instances, the policy rolls out to orchestrate workflows and receives rewards based on execution-oriented feedback. This further calibrates the policy for complex cases, especially in deciding when to collect additional evidence or regenerate a new query iteratively. Online: System Deployment. After training, SQLConductor is deployed as a step-wise Text-to-SQL workflow orchestration system. Given an unseen question 𝑞 and database D, the learned policy model iteratively selects an action based on the current orchestration state; the system then automatically parses to invoke the corresponding action module and updates the state with its output. This process continues until the termination is determined, after which SQLConductor outputs the current SQL query as the final prediction. Thus, the workflow is constructed during execution and adapted to the evolving solving context of each query.

4 THE DESIGN DETAILS OF SQLCONDUCTOR 4.1 Action Space SQLConductor separates workflow orchestration from subtask reasoning. To support flexible workflow composition, we expose typical Text-to-SQL capabilities as callable action modules. Following prior practice [19, 50], we implement seven actions for typical subtasks in Text-to-SQL to instantiate the action space. Formally, A = {𝑎 dec, 𝑎 val, 𝑎 op, 𝑎 sch, 𝑎 gen, 𝑎 ref , 𝑎 term },

(6)

Yizhang Zhu, Zhangyang Peng, Boyan Li, and Yuyu Luo*

NL Ques>ons

[Training Set]

What is the salaries of What theaverage average salaries of Tell meisthe total number of dept. employees in Software Dept.? What isisthe salaries of employees in Software Dept.? What theaverage average salaries of How many employees in the Sales employees in Software Dept.? employees in Software Dept.? department earn more than 80K?

Databases

[Training Set]

Employees Employees Departments Departments Employees - dept_id Departments --emp_id emp_id(PK) (PK) - dept_id(PK) (PK) emp_id (PK) --name -name dept_id (PK) --name name -dept_id name (FK) name --dept_id loca5on (FK) - loca5on -Telephone dept_id (FK) --duty -duty loca5on --Telephone - duty - Telephone

1. Monte Carlo Tree Search-based Text-to-SQL Workﬂow Explora>on

3. Stability-weighted SFT

Candidate Traj.

Repeat

(1)Selection

(2)Expansion

(3)Simulation

(4)Backpropagation

a1 S1

System Prompt… <reasoning>…</reasoning> <call> … </call> <results>MASK …… </results> <reasoning>…</reasoning> <call> … </call> <results>MASK …… </results>

……

Stability-Weighted Workflow SFT

…… …

Ques5on Decomposi5on

Opera5on Iden5ﬁca5on

Relevant Value Extrac5on

(1) Workﬂow Skeleton Extrac6on

……

SQL Query Reﬁnement

More Actions can be integrated …

Terminate and Output

NL Ques>on

2. Text-to-SQL Workﬂow Supervision Cura>on

Schema Pruning

SQL Query Genera5on

[Test Set]

…

Ac>on Space

+ reasoning

4. Curriculum RL

(

: 3,

Top-k : 0) p = 0.80 1st

(

: 4,

: 1) p = 0.71 2nd

…

+ reasoning + reasoning + reasoning

(2) Reasoning Augmenta6on for Orch. Decision

Randomly choose one correct traj. candidate as represen5ve

…

Query

Rollout

? … SQL

Update

System Prompt (Instruction, DB schema, question, … ) (3) <reasoning>…</reasoning><call>Operator Identification</call> <results>… Identified SQL operation needed for this Tag( ) question, i.e. output of this worker …</results> <reasoning>…</reasoning><call>Schema Pruning</call> …

Student_info - sid (PK) - name

SQL

Rewards - Outcome Reward - Executability Reward

…

[A] Offline Phase: Search-to-Policy Learning System Prompt & Task Instruction… Previous Context & Reasoning… <reasoning>………</reasoning> <reasoning>………</reasoning> <call>Operator Identification</call> <call>Schema Pruning</call>

Previous Context & Reasoning… <reasoning>………</reasoning> <call>SQL Query Generation</call>

Previous Context & Reasoning… <reasoning>………</reasoning> <call>Terminate and Output</call>

List all students with A+ in math.

Database

Gold

SQL

Output

[Test Set] Math_grades - sid (FK) - grade

…

Sn-2

Sn-1

[B] Online Phase: System Deployment

Figure 2: The framework overview of SQLConductor. where the first six actions invoke frozen LLM-driven subtask modules, and 𝑎 term terminates the workflow and returns predicted SQL. Given an orchestration state 𝑠𝑡 −1 , invoking an action 𝑎𝑡 ∈ A produces an action-specific output 𝑜𝑡 , which is incorporated into the subsequent state 𝑠𝑡 following Eq. (3). Importantly, Eq. (6) defines available capabilities rather than a predefined execution order. Conditioned on the current intermediate artifacts and feedback, the policy may skip unnecessary actions, gather additional evidence, revisit an earlier action, regenerate a candidate query, refine an existing query, or terminate when obtaining a sufficient SQL candidate. Figure 2 summarizes the action space, and we describe each action below. Question Decomposition (𝑎 dec ). NL questions may compactly express multiple constraints or dependencies [35]. This action rewrites the original question into fine-grained requirements while preserving semantics, making the underlying sub-intents easier to consume in later reasoning. For example, “How many employees in the Sales department earn more than 80K?” can be decomposed into identifying Sales employees, filtering salaries above 80K, and counting the remaining employees. Relevant Value Extraction (𝑎 val ). NL questions often contain values that should be grounded into SQL predicates. Given the question and database information, this action infers condition values likely needed for SQL construction and provides predicatelevel hints. For example, for the Sales-department question above, it may identify “Sales” and “80K” as relevant condition values.

Operation Identification (𝑎 op ). Questions may imply SQL operations such as aggregation, grouping, ordering, comparison, deduplication, temporal transformation, scalar functions, or nested queries. This action records operation-level requirements as intermediate evidence to reduce the burden on later analysis. For example, it may identify AVG(salary) for an average-salary question, or a ranking pattern like ORDER BY salary DESC LIMIT 1. Schema Pruning (𝑎 sch ). Large databases often contain many irrelevant tables and columns. Based on the question and accumulated evidence, this action selects a compact schema subset that preserves the tables, columns, and relational paths needed for the current query. Because it remains callable throughout the workflow, the policy may invoke it again when later feedback suggests that essential schema elements may be omitted. SQL Query Generation (𝑎 gen ). This action synthesizes a complete SQL candidate from the current orchestration state. Following DAILSQL [7], SQLConductor adopts few-shot in-context learning, and the LLM is prompted with the question, schema, few-shot examples, and accumulated evidence. The generated query is executed on the database, and the feedback is incorporated into the updated state, allowing generation to be invoked again after new values, schema elements, or operation cues are obtained. SQL Query Refinement (𝑎 ref ). When an existing SQL candidate requires targeted correction, SQLConductor can apply this action following the strategy of DeepEye-SQL [15]. The candidate is checked by a fail-fast toolchain covering syntax and execution validation,

SQLConductor : Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

Algorithm 1 MCTS-based Workflow Exploration Input: Question 𝑞, database D, action space A, rollout budget 𝑁 rollout , expansion samples 𝑁 exp , reward samples 𝐾, maximum depth 𝑇max Output: Candidate trajectory set X (𝑞, D ) 1: 𝑠 0 ← InitState(𝑞, D ) 2: Initialize Ψ = (𝑉 , 𝐸 ) with root 𝑣0 where 𝑠 (𝑣0 ) = 𝑠 0 ; X (𝑞, D ) ← ∅ 3: for 𝑖 = 1, . . . , 𝑁 rollout do 4: 𝑣 ← 𝑣0 5: while 𝑣 is non-terminal and fully expanded do 6: 𝑎 ← UCTSelect(𝑣), 𝑣 ← Child(𝑣, 𝑎) ⊲ Selection, Eq. (7) 7: end while 8: if 𝑣 is non-terminal and Depth(𝑣) < 𝑇max then 9: C ← Expand(𝑣, A, 𝑁 exp , D ), 𝑣 ← Sample( C) ⊲ Expansion 10: end if 11: while 𝑣 is non-terminal and Depth(𝑣) < 𝑇max do 12: C ← Expand(𝑣, A, 𝑁 exp , D ), 𝑣 ← Sample( C) ⊲ Simulation 13: end while 14: if 𝑣 is non-terminal then 𝑣 ← ForceTerminate(𝑣) 15: 𝜉 ← Trace(𝑣0 , 𝑣), 𝑦 ← ExtractSQL(𝑠 (𝑣) ) 16: 𝑟 ← 𝑅 (𝑦; D, 𝐾 ) ⊲ Eq. (8) 17: Backpropagate(𝜉, 𝑟 ) ⊲ Backpropagation 18: X (𝑞, D ) ← X (𝑞, D ) ∪ {𝜉 } 19: end for 20: return X (𝑞, D )

logical verification, and query-quality checking. If a defect is detected, the diagnostic signal is converted into an explicit revision instruction for the LLM to produce a corrected candidate. Terminate and Output (𝑎 term ). This terminal action ends the workflow and returns the latest SQL candidate as the prediction. Allowing the policy to select 𝑎 term adaptively avoids redundant modules for straightforward questions while preserving the option to invest more reasoning steps when evidence remains insufficient. The action space is intentionally modular. Additional Text-toSQL capabilities can be incorporated as new actions without changing the overall orchestration formulation. In the next subsection, we describe how SQLConductor explores compositions of these actions through Monte Carlo Tree Search to construct diverse candidate workflows for policy learning.

4.2

MCTS-based Workflow Exploration

The action space introduced in Section 4.1 enables flexible workflow composition, but also induces a large combinatorial search space. Manually specifying high-quality workflows for different questions is therefore impractical, while directly sampling trajectories from an LLM may cover only a limited set of orchestration patterns. To automatically discover diverse orchestration patterns, SQLConductor performs Monte Carlo Tree Search (MCTS) [2, 13] over the action space for each training instance (𝑞, D). Tree-structured Workflow Search. We construct a search tree Ψ = (𝑉 , 𝐸) rooted at the initial orchestration state 𝑠 0 . Each node 𝑣 ∈ 𝑉 stores an orchestration state 𝑠 (𝑣) reached after a sequence of action invocations, and each edge corresponds to an action-induced state transition. Specifically, invoking action 𝑎𝑡 at state 𝑠𝑡 −1 produces an intermediate output 𝑜𝑡 and an updated state 𝑠𝑡 . A root-to-terminal path therefore induces a trajectory 𝜉 = (𝑠 0, 𝑎 1, 𝑜 1, 𝑠 1, . . . , 𝑎𝑇 , 𝑜𝑇 , 𝑠𝑇 ), whose action-only projection

𝜏 (𝜉) = (𝑎 1, . . . , 𝑎𝑇 ) is the corresponding workflow. Trajectories retain concrete intermediate artifacts, while workflows abstract action-composition patterns. Algorithm 1 summarizes the exploration procedure. As illustrated in Figure 2-A(1), each rollout consists of selection, expansion, simulation, and backpropagation. Selection. Starting from the root, MCTS traverses the current tree until it reaches a terminal state or a node with unexplored children. At each visited node 𝑣, the next action is selected by the Upper Confidence Bound for Trees (UCT) criterion [13]: √︄ " # 𝑄 (𝑣, 𝑎) ln 𝑁 (𝑣) ∗ 𝑎 = arg max +𝑐 , (7) 𝑁 (𝑣, 𝑎) 𝑁 (𝑣, 𝑎) 𝑎∈ A (𝑣) where A (𝑣) is applicable action set at node 𝑣; 𝑄 (𝑣, 𝑎) and 𝑁 (𝑣, 𝑎) denote accumulated reward and visit count of edge (𝑣, 𝑎); 𝑁 (𝑣) is the visit count of 𝑣; and 𝑐 controls the exploration–exploitation trade-off. Unvisited actions are prioritized before applying Eq (7). Expansion. When traversal reaches a non-terminal frontier node, SQLConductor expands the tree by invoking applicable action modules. To preserve exploration diversity, the same action may be sampled multiple times with a non-zero temperature, producing alternative child states under the same preceding context. Each child stores the updated orchestration state and the newly generated intermediate artifact. Simulation. Starting from an expanded child, SQLConductor continues sampling and invoking actions until Terminate and Output is selected. Because each state incorporates accumulated artifacts and feedback, later actions operate on an evolving solving context. When a rollout reaches a terminal state, SQLConductor extracts its SQL candidate 𝑦 and evaluates it with an executionconsistency reward. Following existing research [19, 44], we sample additional SQL candidates Y𝐾 = {𝑦 (1) , . . . , 𝑦 (𝐾 ) } from the current SQL-generation context and compute 𝑅(𝑦) = b E𝑦 ( 𝑗 ) ∈ Y𝐾 I Exec D (𝑦) = Exec D (𝑦 ( 𝑗 ) ) . (8) If 𝑦 is non-executable, we set 𝑅(𝑦) = 0. This reward assigns higher scores to candidates whose execution results are reproduced consistently across multiple generations, providing a lightweight execution-oriented signal for guiding exploration. Backpropagation. The reward is propagated from the terminal node back to root, updating visit counts and accumulated rewards of the edges along the explored path. Repeating this procedure allocates more rollouts to promising regions while still exploring alternative action compositions. Meanwhile, SQLConductor records completed trajectories as candidates for subsequent supervision curation. After 𝑁 rollout iterations, the collected trajectory set is X(𝑞, D) = 𝜉 (1) , 𝜉 (2) , . . . , 𝜉 (𝑀 ) . (9)

4.3

Workflow Supervision Curation

MCTS-based exploration produces diverse candidate trajectories for each training instance. However, these trajectories cannot be directly used as policy supervision. The explored trajectories only record action calls and action outputs, without explicit reasoning for

Yizhang Zhu, Zhangyang Peng, Boyan Li, and Yuyu Luo*

(10)

where X(𝑞, D) denotes the set of candidate trajectories explored for the training instance. For each workflow 𝜏, we count the number of successful trajectories 𝑠𝜏 and the total number of trajectories 𝑛𝜏 = |X𝜏 |, where success is determined by execution correctness. Figure 3(a) shows that MCTS explores a broad set of trajectories with diverse workflow skeletons for each question. Workflow Stability Estimation. Since the combinatorial space is large, most workflows are observed only once or a limited number of times. To account for sparse observations, SQLConductor defines each workflow’s stability score as the posterior predictive probability of success under a Bernoulli model with a uniform Beta(1, 1) prior, as given by Laplace’s rule of succession [56]:

Reasoning Augmentation for Orchestration Decisions. The representative trajectory 𝜉 + contains the selected actions and their outputs, but the policy model should also learn why an action is selected under the current orchestration context. Thus, we augment each representative trajectory with step-level orchestration reasoning. For each step 𝑡, we prompt a deployed LLM to generate the orchestration reasoning 𝑒𝑡 = LLM(𝑞, D, 𝜉¯<𝑡 , 𝑎𝑡 , 𝑜𝑡 ) for invoking 𝑎𝑡 , where 𝜉¯<𝑡 is the augmented trajectory prefix before step 𝑡, and 𝑎𝑡 , 𝑜𝑡 are the selected current action and its observed output. The reasoning is inserted before the corresponding action call, yielding: (12)

This step-wise augmentation is more controllable than generating reasoning for the whole trajectory at once, because the LLM only needs to justify a fixed action under a fixed context and observed result. Since the trajectory has already been selected from stable successful candidates, the generated reasoning is grounded in highquality orchestration behavior.

=25.3

The resulting 𝑝ˆ𝜏 serves as a Laplace-smoothed workflow stability score. It assigns higher scores to workflows that repeatedly lead to successful executions, while avoiding extreme estimates for rarely observed workflows. For each training instance, SQLConductor ranks all workflows with 𝑠𝜏 > 0 by 𝑝ˆ𝜏 to select the top-𝑘 workflows, and randomly samples one successful trajectory from each selected group as the representative trajectory 𝜉 + . Since grouped trajectories share the same high-level orchestration decisions, retaining one representative per workflow reduces redundant supervision and exploration-frequency bias. This keeps multiple valid workflow patterns for the same question, rather than forcing a single canonical workflow. Figure 3(b) shows that the selected top-3 workflows have clearly higher stability scores among all explored workflows.

𝜉¯ = (𝑠 0, 𝑒 1, 𝑎 1, 𝑜 1, 𝑠 1, . . . , 𝑒𝑇 , 𝑎𝑇 , 𝑜𝑇 , 𝑠𝑇 ).

Explored Trajectories Unique Workflow Skeletons

(11)

𝑠𝜏 + 1 , 𝑛𝜏 + 2

Number of Questions 1

𝑝ˆ𝜏 =

X𝜏 = {𝜉 ∈ X(𝑞, D) | 𝜏 (𝜉) = 𝜏 },

Input: Training set I, MCTS explored trajectories X (𝑞, D ), top-𝑘 Output: Curated supervision set C 1: C ← ∅ 2: for all (𝑞, D, 𝑦 ∗ ) ∈ I do 3: Extract 𝜏 (𝜉 ) = (𝑎 1 , . . . , 𝑎𝑇 ) for each 𝜉 ∈ X (𝑞, D ) 4: X𝜏 ← {𝜉 ∈ X (𝑞, D ) | 𝜏 (𝜉 ) = 𝜏 } for each distinct 𝜏 ⊲ Eq. (10) 5: for all workflow group X𝜏 do 6: 𝑠𝜏 ← | {𝜉 ∈ X𝜏 : 𝜉 is successful} |, 𝑛𝜏 ← | X𝜏 | 𝑠𝜏 + 1 7: 𝑝ˆ𝜏 ← // Laplace-smoothed stability score ⊲ Eq. (11) 𝑛𝜏 + 2 8: end for 9: T ← top-𝑘 ( {𝜏 | 𝑠𝜏 > 0}; 𝑝ˆ𝜏 ) // Select top-𝑘 workflows 10: for all 𝜏 ∈ T do // Randomly select a successful representative trajectory 11: 𝜉 + = (𝑠 0 , 𝑎 1 , 𝑜 1 , . . . , 𝑎𝑇 , 𝑜𝑇 , 𝑠𝑇 ) ∈ X𝜏 12: Initialize 𝜉¯ ← (𝑠 0 ) 13: for 𝑡 = 1, . . . ,𝑇 do 14: 𝑒𝑡 ← LLM(𝑞, D, 𝜉¯<𝑡 , 𝑎𝑡 , 𝑜𝑡 ), 𝜉¯ ← 𝜉¯ ⊕ (𝑒𝑡 , 𝑎𝑡 , 𝑜𝑡 , 𝑠𝑡 ) 15: end for 16: C ← C ∪ { (Tag( 𝜉¯), 𝑝ˆ𝜏 ) } 17: end for 18: end for 19: return C MCTS All Explored Selected Top-3

=34.7

10 15 20 25 30 35 40 45

Count per Question

=0.548

=0.766

MCTS All Explored

Selected Top-3

Laplace-Smoothed

Workflow Skeleton Extraction. Given a MCTS explored trajectory 𝜉, we first extract its workflow skeleton (i.e., workflow 𝜏) by keeping only its action sequence: 𝜏 (𝜉) = (𝑎 1, 𝑎 2, . . . , 𝑎𝑇 ). Different trajectories with the same workflow are grouped together:

Algorithm 2 Workflow Supervision Curation

0.0 0.2 Stability 0.4 0.6 Score 0.8 1.0

orchestration decisions, and some successful trajectories may be accidental. Therefore, SQLConductor curates the explored trajectories into reliable, reasoning-augmented, and instruction-tuning-ready supervision, as shown in Figure 2-A(2) and detailed in Algorithm 2.

(a) MCTS Exploration Distribution

(b) Stability Score Distribution

Figure 3: Statistics of workflow exploration and curation. Finally, as shown in Figure 4, we serialize each augmented trajectory into a tagged instruction-tuning format, where <reasoning> and <call> are supervised as policy-generated content, and <results> is the output of the corresponding action. System Prompt: 𝑞, D, A, instruction, . . . <reasoning>𝑒 1 </reasoning><call>𝑎 1 </call><results>𝑜 1 </results> ··· <reasoning>𝑒𝑇 </reasoning><call>𝑎𝑇 </call><results>𝑜𝑇 </results>

Figure 4: Instruction-tuning format for subsequent training.

4.4

Stability-weighted Supervised Fine-tuning

After workflow supervision curation, each selected sample consists ¯ and its workflow stabilof a tagged augmented trajectory Tag(𝜉) ity score 𝑝ˆ𝜏 . This stage introduces a Stability-weighted Supervised Fine-tuning to train the policy to learn from robust orchestration patterns from selected workflows, while still preserving diversity from alternative valid solving strategies. Action Result Masking. In SQLConductor, the training objective focuses on learning orchestration for Text-to-SQL workflow. Thus, different from fine-tuning Text-to-SQL generators, SQLConductor only updates the compact policy model.

SQLConductor : Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

As mentioned in Section 4.3, the tagged instruction-tuning formatted data contains both policy-generated content and actiongenerated observations. Since <results> is not produced by the policy, forcing the policy to predict it would introduce irrelevant supervision and bias the model from learning workflow orchestration [34]. Therefore, SQLConductor keeps <results> in the context for subsequent decisions, but masks it out from the training ¯ be the serialized token sequence. loss [6, 34, 61]. Formally, let Tag(𝜉) We define a tag-aware binary mask 𝑚𝑖 as: ¯ = (𝑧 1, 𝑧 2, . . . , 𝑧 𝑁 ), Tag(𝜉) (13) ( 0, 𝑧𝑖 ∈ <results> · · · </results>, (14) 𝑚𝑖 = 1, otherwise. In practice, the system prompt and other non-response tokens are also excluded following the standard instruction-tuning setting. The result-masked loss is: 𝑁 ∑︁ ¯ = −Í 1 ℓmask (𝜃 ; 𝜉) 𝑚𝑖 log 𝑃𝜃 (𝑧𝑖 | 𝑧 <𝑖 ). (15) 𝑁 𝑖=1 𝑚𝑖 𝑖=1 This normalization prevents longer trajectories or longer action outputs from dominating the optimization. Meanwhile, the masked results remain visible in the context, allowing the policy to learn state-conditioned decisions from evolving intermediate evidence. Stability-weighted Objective. Although the curated trajectories are selected from successful candidates, they are not equally reliable. A workflow that succeeds repeatedly during MCTS-based exploration provides stronger evidence of robust orchestration behavior than one that succeeds only occasionally. Therefore, SQLConductor uses the Laplace-smoothed workflow stability score 𝑝ˆ𝜏 from Eq. (11) to weight the supervised learning objective. For the selected trajectories of the same question, SQLConductor converts stability scores into normalized training weights. This avoids treating 𝑝ˆ𝜏 as an absolute loss scale and instead uses it to define the relative importance of different valid workflows for the same question. Specifically, we adopt power normalization: 𝑝ˆ𝛼 𝑤𝜏 = Í 𝜏 𝛼 , (16) 𝜏 ′ ∈ T 𝑝𝜏 ′ where T denotes the selected top-𝑘 workflows for a certain question. The exponent 𝛼 controls the strength of stability preference. Following prior work on distribution sharpening [1], we set 𝛼 = 2. The final Stability-weighted Supervised Fine-tuning objective is: " # ∑︁ LSFT (𝜃 ) = E (𝑞,D,𝑦 ∗ )∼I 𝑤𝜏 ℓmask (𝜃 ; 𝜉¯𝜏 ) , (17) 𝜏∈T

where 𝜉¯𝜏 is the representative augmented trajectory of workflow 𝜏. This objective prioritizes stable orchestration patterns while still preserving multiple valid workflows for the same question. As a result, the policy obtains a reliability-aware initialization for tagged interaction formatting and step-wise action decision, which is further enhanced by curriculum reinforcement learning.

4.5

Curriculum Reinforcement Learning

Stability-weighted Supervised Fine-tuning trains the policy model to learn reliable orchestration patterns selected from MCTS exploration. However, its supervision still comes from curated successful

trajectories. For difficult instances, successful trajectories can be sparse during exploration, making supervised signals less sufficient for learning how to recover from imperfect intermediate decisions. Therefore, SQLConductor further applies Curriculum Reinforcement Learning to enhance the orchestration policy on challenging queries through self-rollouts and execution-oriented rewards. Curriculum Construction. We construct the reinforcement learning (RL) set according to the difficulty observed during MCTS-based exploration. For each training instance (𝑞, D, 𝑦 ∗ ), let X(𝑞, D) denote the explored trajectory set, and let X + (𝑞, D) denote the subset of successful ones obtaining correct predicted SQL. We define the MCTS success ratio as: 𝜌 (𝑞, D) =

|X + (𝑞, D)| . |X(𝑞, D)|

(18)

A lower 𝜌 (𝑞, D) indicates that successful trajectories are more sparsely yielded in the exploration, suggesting a more challenging query. Given a threshold 𝛾, we construct the curriculum set as: IRL = {(𝑞, D, 𝑦 ∗ ) ∈ I | 𝜌 (𝑞, D) < 𝛾 }.

(19)

This curriculum directs the RL stage toward challenging instances that are less effectively solved during exploration, complementing curated supervision with further policy optimization. Policy Rollout with GRPO. We adapt GRPO [25, 36, 43, 57] to workflow orchestration by optimizing the policy over grouped stepwise rollouts with execution-oriented rewards. For each instance in IRL , the current policy performs step-wise rollout by interacting with the frozen action modules. As shown in Figure 5, starting from the initial state 𝑠 0 , the policy repeatedly generates orchestration reasoning and selects an action. The corresponding action module is then invoked, with its output result appended to the context for the next decision. The rollout stops when the policy decides to terminate and output or reaches the maximum step limit 𝑇max , yielding a final predicted SQL query 𝑦𝑖 . Each rollout is scored by an execution-oriented reward 𝑟𝑖 , which will be elaborated next. Following GRPO, we sample a group of 𝐺 rollouts for the same training instance: {𝜉𝑖 , 𝑦𝑖 , 𝑟𝑖 }𝐺 𝑖=1 , where 𝜉𝑖 is the rollout trajectory, 𝑦𝑖 is its final predicted SQL, and 𝑟𝑖 is the scalar reward computed from execution feedback. GRPO estimates the advantage of each rollout by comparing it with other rollouts in the same group: 𝐺 𝑟 𝑖 − 𝜇𝑟 1 ∑︁ 𝐴ˆ𝑖 = , 𝜇𝑟 = 𝑟𝑗, 𝜎𝑟 + 𝛿 𝐺 𝑗=1

(20)

where 𝜎𝑟 is the standard deviation of group rewards and 𝛿 is a small constant for numerical stability. This relative advantage avoids training an additional value model and encourages the policy to prefer workflows that perform better than other sampled workflows for the same question. As in Eq. (13), we serialize each rollout 𝜉𝑖 into a token sequence 𝑧𝑖,1:𝑁𝑖 . Let Ω𝑖 ⊆ {1, . . . , 𝑁𝑖 } denote the index set of policy-generated tokens, including tokens in <reasoning> and <call>. Let 𝑃𝜃 denote the autoregressive token distribution induced by the policy model 𝜋𝜃 . For each 𝑡 ∈ Ω𝑖 , we define the probability ratio: 𝜂𝑖,𝑡 =

𝑃𝜃 (𝑧𝑖,𝑡 | 𝑧𝑖,<𝑡 ) . 𝑃𝜃 old (𝑧𝑖,𝑡 | 𝑧𝑖,<𝑡 )

(21)

Yizhang Zhu, Zhangyang Peng, Boyan Li, and Yuyu Luo*

NLQ

Algorithm 3 Online Deployment of SQLConductor S1

(1)

…

SQL1

(2) 1

…

SQL2

(n)

…

SQLn

…

… S1

(a) Executability Reward SQL1

SQL2

2 Executable SQL

… An

(b) Outcome Reward Gold SQL

SQL2

+0.5

1 Non-executable

…

Group Computa/on

? ?

city

cnt

Boston Denver

3 2

SQL3

+2.0

city

cnt

Boston Austin

3 1

ExecF1 = 0.5 city

cnt

Boston Denver

3 2

ExecF1 = 1.0

Figure 5: Rollout and reward computation in curriculum reinforcement learning for SQLConductor. Therefore, our GRPO objective for SQLConductor is: 𝐺 1 ∑︁ 1 ∑︁ min 𝜂𝑖,𝑡 𝐴ˆ𝑖 , JGRPO (𝜃 ) = 𝐺 𝑖=1 |Ω𝑖 | 𝑡 ∈Ω 𝑖 clip(𝜂𝑖,𝑡 , 1 − 𝜖𝑐 , 1 + 𝜖𝑐 )𝐴ˆ𝑖 − 𝛽𝐷 KL (𝑃𝜃 ∥ 𝑃ref )

(22)

where 𝑃𝜃 old is the policy used to generate the rollouts, 𝑃ref is the SFT-trained reference policy, and 𝜖𝑐 and 𝛽 control clipping and KL regularization. As in SFT, only policy-generated tokens are optimized, while action results are treated as observations. Execution-oriented Reward. The reward is designed to encourage both executable SQL generation and semantically correct execution results. Given a predicted SQL 𝑦𝑖 , SQLConductor executes it on D and compares its result with the execution result of the ground-truth SQL query 𝑦 ∗ . (1) Executability Reward encourages the policy to produce workflows that lead to valid SQL: 𝑟 exe (𝑦𝑖 ) = I [𝑦𝑖 executes on D without error/timeout] .

(23)

(2) Outcome Reward measures the quality of the final execution result. Exact execution correctness remains the primary target, while partial result overlap can also be used to provide a more fine-grained signal for distinguishing near-correct predictions [9]. For this purpose, we employ ExecF1 over the execution result table of predicted and gold SQL. Specifically, for executable 𝑦𝑖 , let V𝑖 and V ∗ denote the multisets of normalized cell values in Exec D (𝑦𝑖 ) and Exec D (𝑦 ∗ ), respectively. The numbers of matched, prediction-only, and gold-only values are: TP = |V𝑖 ∩ V ∗ |, FP = |V𝑖 \ V ∗ |, FN = |V ∗ \ V𝑖 |,

(24)

where repeated values are counted according to their multiplicities. As Prec = TP/(TP+FP), Rec = TP/(TP + FN), ExecF1 then denotes: 2 · Prec · Rec ExecF1(𝑦𝑖 , 𝑦 ∗ ) = . (25) Prec + Rec For non-executable 𝑦𝑖 , the outcome reward is also 0. Otherwise, the outcome reward is: ( 1 + ExecF1(𝑦𝑖 , 𝑦 ∗ ), Exec D (𝑦𝑖 ) = Exec D (𝑦 ∗ ), 𝑟 out (𝑦𝑖 ) = (26) ExecF1(𝑦𝑖 , 𝑦 ∗ ), otherwise. Here, exactly correct executions receive an additional reward, while partially correct results are still rewarded according to ExecF1. The final reward combines outcome quality and executability: 𝑟𝑖 = 𝜆𝑟 out (𝑦𝑖 ) + (1 − 𝜆)𝑟 exe (𝑦𝑖 ),

Input: Test question 𝑞 test , test database Dtest , action space A, learned policy model 𝜋𝜃 , maximum steps 𝑇max Output: Predicted SQL query 𝑦 1: 𝑠 0 ← InitState(𝑞 test , Dtest ) 2: for 𝑡 = 1, . . . ,𝑇max do 3: 𝑢𝑡 ← 𝜋𝜃 (𝑞 test , Dtest , A, 𝑠𝑡 −1 ) // Generate orchestration reasoning 4: 𝑒𝑡 ← Extract(𝑢𝑡 , <reasoning>, </reasoning>) 5: 𝑎𝑡 ← Extract(𝑢𝑡 , <call>, </call>) 6: if 𝑎𝑡 = 𝑎 term then 7: 𝑦 ← ExtractSQL(𝑠𝑡 −1 ) 8: return 𝑦 9: end if 10: 𝑜𝑡 ← 𝑎𝑡 (𝑠𝑡 −1 , Dtest ) // Invoke and perform the corresponding action 11: 𝑠𝑡 ← UpdateState(𝑠𝑡 −1 , 𝑒𝑡 , 𝑎𝑡 , 𝑜𝑡 ) 12: end for 13: 𝑦 ← ExtractSQL(𝑠𝑇max ) 14: return 𝑦

(27)

where 𝜆 ∈ [0, 1] balances outcome correctness and executability. Through curriculum reinforcement learning, the orchestration policy is further optimized from its own rollout behaviors on challenging instances. This completes the offline Search-to-Policy Training phase, after which the learned policy is deployed for online step-wise orchestration for Text-to-SQL workflow.

4.6

Online Deployment

After offline Search-to-Policy Training, SQLConductor is deployed as a step-wise workflow orchestration system for unseen Text-toSQL queries. Given a test question 𝑞 test and database Dtest , the learned policy model 𝜋𝜃 iteratively selects actions conditioned on the current orchestration state until termination or the maximum step limit is reached. Algorithm 3 outlines the online procedure. Step-wise Orchestration. At each step 𝑡, SQLConductor serializes the current orchestration state 𝑠𝑡 −1 into the same tagged interaction format used in training. The policy model then generates a decision segment containing orchestration reasoning and an action call: 𝑢𝑡 = <reasoning>𝑒𝑡 </reasoning><call>𝑎𝑡 </call>. The system parses 𝑒𝑡 from <reasoning> and 𝑎𝑡 from <call>, and maps the parsed action name to an action module in A. If 𝑎𝑡 is a non-terminating action, the corresponding action module is invoked to produce its results and output 𝑜𝑡 , as in Eq. (3). The 𝑜𝑡 is appended to the context and incorporated into the orchestration state for the next decision. Therefore, although the action result is not generated by the policy, it remains visible as intermediate evidence for subsequent policy decisions. Termination and SQL Output. The action space includes a termination action 𝑎 term , corresponding to Terminate and Output. When the parsed <call> is 𝑎 term , the process terminates and extracts the current SQL candidate from the terminal orchestration state as the final prediction. If the maximum step limit is reached, the termination is automatically triggered. The induced workflow for the test instance is therefore: 𝜏𝜃 = (𝑎 1, 𝑎 2, . . . , 𝑎𝑇 ), where 𝑇 ≤ 𝑇max is determined online by the learned policy. This procedure enables SQLConductor to produce query-specific workflows with adaptive action organization, conditioned on evolving orchestration state.

SQLConductor : Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

5 EXPERIMENTS 5.1 Experimental Setup Datasets. We use the following datasets for training and evaluation: • BIRD-Train [22] is used to construct workflow supervision and train the orchestration policy through Search-to-Policy Learning. • BIRD-Dev [22] is used for the main evaluation, containing 1,534 challenging cross-domain questions over 11 databases. • Out-of-distribution (OOD) datasets include Spider-Test [54], KaggleDBQA [14], and ScienceBenchmark [59]. Spider-Test is a cross-domain benchmark; KaggleDBQA contains real web databases with less standardized schemas; ScienceBenchmark focuses on complex scientific databases with highly specialized queries on policy, astrophysics, and cancer research. They are used only for OOD evaluation without dataset-specific training. Metrics. We use execution accuracy (EX) as the primary metric, which evaluates whether the predicted SQL returns the same execution result as the reference gold SQL on the database. Baselines. We compare our SQLConductor with the following state-of-the-art Text-to-SQL baselines: • Model-level training baselines directly employ task-specific training with large-scale data to improve LLMs’ Text-toSQL translation capabilities, including CodeS [21], ReasoningSQL [40], SQL-R1 [37], and OmniSQL [20]. • Fixed-pipeline systems follow human-designed multi-stage procedures for Text-to-SQL, including (i) prompting-based systems such as CHESS [47] and DeepEye-SQL [15]; as well as (ii) trained-model-enhanced systems: XiYan-SQL [28], CSCSQL [44], CHASE-SQL [38], and OpenSQL [12]. • Dynamic-workflow systems try to go beyond fixed pipelines, including search-based methods such as Alpha-SQL [19], and the recent plan-then-execute orchestration method of SquRL [51]. Implementation. All experiments are conducted on 8 Nvidia A100 GPUs. Implementations are summarized as follows: • Model configuration. SQLConductor trains Qwen3-8B/4B policies to coordinate frozen action modules; unless otherwise specified, we use trained Qwen3-8B as default policy and Qwen2.5Coder-32B-Instruct as default action LLM. We also evaluate Qwen2.5-Coder-14B-Instruct and more recent Gemma4-31B-It to study the effect of action-model capacity and model family. • Policy training. MCTS exploration uses 𝑁 rollout = 24. The policy is first trained for two epochs with Stability-weighted Supervised Fine-tuning, using learning rate 1 × 10−5 with a cosine scheduler, LoRA rank 𝑟 = 64, 𝛼 LoRA = 128. It is then further optimized for two epochs with Curriculum Reinforcement Learning, using learning rate 1 × 10−6 , 𝜆 = 0.8, 𝐺 = 4. • Inference. All LLMs are deployed with their official recommended configurations; 𝑇max is set to 10.

5.2

Overall Performance

RQ1: How does SQLConductor compare against existing stateof-the-art Text-to-SQL systems? Table 1 reports the main comparison on BIRD-Dev. With the 8B policy paired with Gemma4-31B-It as the action LLM, SQLConductor achieves 73.2% EX, the highest result among all compared systems, outperforming the strongest baselines across

model-level training, fixed-pipeline, and dynamic-workflow categories, including systems that rely on much larger proprietary models. Notably, this result is obtained by training only the orchestration policy while keeping the action LLM frozen, rather than fine-tuning a dedicated Text-to-SQL backbone. To control for the same underlying models, we further compare methods built on Qwen2.5-Coder-32B-Instruct. Under this comparable setting, SQLConductor reaches 71.2% EX, outperforming fixed-pipeline systems such as DeepEye-SQL (70.6%), CSC-SQL (70.7%), and OpenSQL (70.0%), the model-level training baseline OmniSQL-32B (67.0%), and the search-based Alpha-SQL (69.7%), all reasoning with the same backbone. This controlled comparison thus highlights the performance advantage of SQLConductor under the same backbone setting. The subset results show the same trend: SQLConductor achieves the best performance across all difficulty levels with reported subset scores. SQLConductor reaches 78.5%, 66.1%, and 61.8% on Simple, Moderate, and Challenging subsets, respectively, outperforming the strongest baseline on each subset by 2.0%, 2.1%, and 4.6%. Notably, with the 8B policy, SQLConductor obtains the same competitive performance in Challenging set when paired with Qwen2.5-Coder14B-Instruct and Qwen2.5-Coder-32B-Instruct (57.6%), and reducing the policy from 8B to 4B lowers overall EX by only marginal points. These results suggest that the learned orchestration policy can robustly coordinate action LLMs with different capacities, and that SQLConductor’s advantage comes from effective workflow orchestration rather than simply scaling model size. Figure 6 compares BIRD-Dev EX with the size of trained parameters across methods that adapt model weights. SQLConductor lies in the favorable accuracy-per-trained-parameter region: it trains only a 4B/8B orchestration policy while keeping the action LLM frozen, yet achieves superior EX. Compared with model-level training baselines and trained-model-enhanced fixed-pipeline systems, SQLConductor shifts learning from the Text-to-SQL backbone to the orchestration policy, supporting the central premise that learned orchestration can be more parameter-efficient than further training a monolithic Text-to-SQL model. RQ2: Does SQLConductor learn a generalizable policy for Textto-SQL orchestration? We then evaluate whether our trained policy to unseen database domains and query styles. Specifically, we test SQLConductor on Spider-Test, KaggleDBQA, and ScienceBenchmark without datasetspecific re-training, and pair the 8B policy with Qwen2.5-Coder32B-Instruct for comparison with open-source baselines. As shown in Table 2, SQLConductor achieves the best OOD average of 72.4%, outperforming the strongest fixed-pipeline baseline OpenSQL (71.0%), the dynamic-workflow baseline Alpha-SQL (69.6%), and the model-level training baseline OmniSQL-32B (69.1%). The gains are more pronounced on complex OOD cases involving noisy schemas or domain-specialized queries. In particular, SQLConductor achieves the best results on KaggleDBQA and ScienceBenchmark, reaching 66.0% and 62.3%, respectively. These results indicate that the learned orchestration policy generalizes beyond the training distribution, suggesting that SQLConductor does not simply fit and memorize dataset-specific patterns, but learns orchestration behavior that remains effective across diverse Text-to-SQL settings.

Yizhang Zhu, Zhangyang Peng, Boyan Li, and Yuyu Luo*

Table 1: Main comparison on BIRD-Dev. We report execution accuracy (EX, %) on three difficulty subsets and the full set; \ / denote trained/frozen models, and – denotes unavailable results. Method

Base LLM

CHESS [47] DeepEye-SQL [15] XiYan-32B [28] CSC-SQL [44] CHASE-SQL [38] OpenSQL [12] Alpha-SQL [19] SquRL [51] SQLConductor (Ours) SQLConductor (Ours) SQLConductor (Ours) SQLConductor (Ours)

BIRD-Dev EX (%)

73 72 71 70 69 68 67 66 65

Ours (Gemma) Ours (Qwen) Ours (Qwen) SquRL

#Params Avail. Dyn. Workflow Simple Moderate Challenge Total EX

\ StarCoder-15B

CodeS [21] Reasoning-SQL [40] SQL-R1 [37] OmniSQL-32B [20]

\ Qwen2.5-Coder-14B-Instruct \ Qwen2.5-Coder-14B-Instruct \ Qwen2.5-Coder-32B-Instruct

15B 14B 14B 32B

✓ ✗ ✓ ✓

✗ ✗ ✗ ✗

65.8 – 72.4 73.3

48.8 – 59.7 59.3

42.4 – 56.5 51.7

58.5 65.3 67.1 67.0

Qwen2.5-Coder-32B-Instruct Qwen2.5-Coder-32B-Instruct \ Qwen2.5-Coder-32B-Instruct \ Qwen2.5-Coder-32B-Instruct \ Gemini-1.5-Flash Gemini-1.5-Pro \ Qwen2.5-Coder-32B

32B 32B 32B 32B UNK >200B 32B

✓ ✓ ✓ ✗

✗ ✗ ✗ ✗

73.5 76.5 72.2 –

60.9 63.5 59.5 –

53.5 55.6 55.2 –

67.8 70.6 66.8 70.7

✗

–

73.0

✗

–

70.0

Qwen2.5-Coder-32B-Instruct \ Qwen2.5-7B-It Qwen-Plus

32B 7B >100B

✓

74.5

64.0

57.2

69.7

✓

–

67.6

\ Qwen3-4B Qwen2.5-Coder-32B-Instruct \ Qwen3-8B Qwen2.5-Coder-32B-Instruct \ Qwen3-8B Qwen2.5-Coder-14B-Instruct \ Qwen3-8B Gemma4-31B-It

4B 32B 8B 32B 8B 14B 8B 31B

✓

76.5

62.2

56.3

70.3

✓

77.3

63.1

57.6

71.2

✓

75.8

62.6

57.6

70.1

✓

78.5

66.1

61.8

73.2

Table 2: OOD evaluation. Note that SQLConductor is deployed without additional dataset-specific training.

CHASE-SQL CSC-SQL OpenSQL

BASE-SQL (Qwen) SQL-R1 OmniSQL-32B OmniSQL-14B XiYan-32B

Distillery

Reasoning-SQL XiYan-22B BASE-SQL (DS) 4 8 16 Trained Model Size (B) 32 >200 Figure 6: BIRD-Dev EX vs. trained parameter size for trainingbased methods. Marker size indicates inference model size.

5.3

Efficiency and Resource Cost

RQ3: Can SQLConductor achieve a favorable inference-time accuracy–cost profile? We focus on per-query workflow cost under a shared Qwen2.5Coder-32B-Instruct action LLM backbone. For a consistent comparison, we measure the token usage and API cost of action-LLM calls, which are available from the execution traces of representative fixed-pipeline and dynamic-workflow systems. Costs are computed according to official Qwen API pricing. Table 3 reports the average tokens and the corresponding cost per query. SQLConductor achieves the highest EX with the lowest measured per-query cost. As shown in Table 3, under the shared Qwen2.5Coder-32B-Instruct backbone, SQLConductor achieves 71.2% EX with only 7.1k input tokens and 12.2k output tokens per query. This corresponds to roughly 16×, 10×, and 2× lower token usage than CHESS, Alpha-SQL, and DeepEye-SQL, respectively. The reduced token consumption leads to an average cost of only $0.012 per query, with the orchestration policy adding just $0.001, making SQLConductor about 8×, 7×, and 2× cheaper than these baselines while achieving higher EX. In wall-clock time, SQLConductor is

Method

Spider. Kaggle. Science. OOD Avg.

CodeS + \ StarCoder-15B SQL-R1 + \ Qwen2.5-Coder-14B-Instruct OmniSQL-32B + \ Qwen2.5-Coder-32B-Instruct

85.1

42.2

51.2

59.5

88.1

54.6

57.6

66.8

89.8

56.8

60.6

69.1

87.1

54.6

56.9

66.2

88.7

61.6

60.6

70.3

88.4

53.0

53.2

64.9

88.3

63.2

61.5

71.0

Alpha-SQL + Qwen2.5-Coder-32B-Instruct

87.8

62.7

58.2

69.6

SQLConductor + \ Qwen3-8B + Qwen2.5-Coder-32B-Instruct

88.9

66.0

62.3

72.4

CHESS + Qwen2.5-Coder-32B-Instruct DeepEye-SQL + Qwen2.5-Coder-32B-Instruct XiYan-32B + \ Qwen2.5-Coder-32B-Instruct OpenSQL + \ Qwen2.5-Coder-32B

Table 3: Per-query cost measured by action-LLM token usage under shared Qwen2.5-Coder-32B-Instruct. Parentheses denote the extra orchestration policy cost (custom Qwen3-8B). Method

EX ↑ Total Time (h) ↓ Input (k) ↓ Output (k) ↓ Avg. Cost ($) ↓

CHESS DeepEye-SQL Alpha-SQL

67.8 70.6 69.7

21.8 4.9 29.1

268.0 20.3 124.4

37.5 21.5 68.7

0.109 0.024 0.094

SQLConductor 71.2

5.6

7.1

12.2

0.012 (+0.001)

substantially faster than CHESS and Alpha-SQL and remains close to DeepEye-SQL. Overall, this shows that SQLConductor offers a more favorable inference-time trade-off among workflow-based Text-to-SQL methods, making efficiency an integral outcome of orchestration rather than a separate engineering optimization.

SQLConductor : Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

Single-round

SFT+RL Non-trained

Proportion (%)

100

Simple

Moderate

Challenging

Figure 7: Workflow-length distributions across BIRD-Dev difficulty-levels. Trained vs. Non-trained policy. Table 4: Ablation of SFT and RL stages on BIRD-Dev. Orchestration Backbone

Simple

Moderate

Challenge

Total EX

SFT + RL (full) SFT only, w/o RL RL only, w/o SFT Non-trained policy

77.3 77.5 76.3 73.8

63.1 62.9 62.4 62.5

57.6 52.1 55.6 51.0

71.2 70.7 70.2 68.3

5.4

Adaptive Orchestration Analysis

RQ4: Does SQLConductor improve accuracy by allocating orchestration effort according to query demands, rather than simply increasing workflow length? A higher EX alone does not establish adaptivity: a policy may improve performance simply by spending more inference steps, analogous to test-time scaling. To rule out this explanation, we compare the trained policy with the same 8B backbone before Searchto-Policy training, with both coordinating the same Qwen2.5Coder-32B-Instruct action LLM on BIRD-Dev. Figure 7 shows the workflow-length distributions across difficulty subsets, and Table 4 reports the corresponding EX. The trained policy improves EX on every difficulty subset, raising overall accuracy from 68.3% to 71.2%, with the largest gain on Challenging queries (51.0% to 57.6%). This improvement does not come from uniformly longer workflows: in the aggregate All panel, the non-trained policy issues more action calls on average but obtains lower EX. In contrast, our trained policy changes how effort is distributed across queries. Its workflow-length distribution shifts upward from Simple to Challenging queries, while the non-trained policy shows much weaker difficulty-aware adaptation. These results suggest that Search-to-Policy learning improves not only EX but also the allocation of orchestration effort. The trained policy achieves higher EX with fewer average action calls, while assigning additional steps more selectively to harder queries. This behavior distinguishes adaptive orchestration from brute-force workflow expansion: the gain comes from where computation is spent, rather than simply from spending more computation overall.

5.5

Ablation Study

RQ5: What roles do Stability-weighted SFT and Curriculum RL play in learning orchestration policies? Table 4 ablates these two stages while keeping the same 8B policy backbone and Qwen2.5-Coder-32B-Instruct action LLM. Stability-weighted SFT establishes orchestration abilities, while Curriculum RL further improves difficult-query handling. Stabilityweighted SFT raises EX from 68.3% to 70.7%, showing the value of curated workflow supervision. Curriculum RL also improves over the untrained policy, suggesting that execution rewards provide

12.4%

(a) Simple

86.6%

Gen+Refine

12.0%

12.3%

15.1%

85.4%

83.4%

81.7%

100

Non-train. SFT SFT+RL (c) Challenging 13.1% 11.7%

17.9% 22.1%

24.8%

60.0%

53.8%

Non-train. SFT

SFT+RL

75 50

75.2%

25 0

Multi-round

(b) Moderate

25 0

All Proportion (%)

Workflow Length

6+ 5 4 3 2 1

12.3% 15.1%

13.6% 16.2%

72.6%

70.3%

Non-train. SFT SFT+RL (d) BIRD-Dev All 13.2%

13.9%

7.0%

9.1% 14.3%

84.0%

79.1%

76.6%

Non-train. SFT

SFT+RL

21.4%

Figure 8: SQL-stage orchestration patterns by training stage and query difficulty in BIRD-Dev. Table 5: Ablation of training, policy scale, and adaptive execution on BIRD-Dev. Orch. Policy SFT + RL Non-trained Fixed workflow

#Params

Simple

Moderate

Challenge

Total EX

8B 4B 8B 32B –

77.3 76.5 73.8 75.2 74.4

63.1 62.2 62.5 63.4 64.2

57.6 56.3 51.0 54.5 52.1

71.2 70.3 68.3 69.7 69.2

useful learning signals even without supervised trajectories. Combining both achieves the best overall EX, especially on Challenging queries: 57.6% versus 52.1% for SFT-only and 55.6% for RL-only. Figure 8 explains the gain at the behavior level. From untrained → SFT → SFT+RL, the policy shifts from single-round SQL generation toward refinement and multi-round SQL construction, especially increasing multi-round SQL generation on Challenging queries. This suggests complementary roles: Stability-weighted SFT helps SQLConductor absorb robust and diverse workflow patterns, while Curriculum RL further calibrates on challenging cases. RQ6: Are the gains of SQLConductor attributable to policy learning, policy scale, adaptive workflow orchestration, or their combination? Table 5 isolates the effects of policy training, policy scale, and adaptive execution, while keeping the action LLM fixed. Policy capacity helps but is insufficient. Within the same training condition, larger policies achieve higher EX: the non-trained 32B policy outperforms the non-trained 8B policy (69.7% vs. 68.3%), and the trained 8B policy outperforms the trained 4B policy (71.2% vs. 70.3%). However, the non-trained 8B policy still underperforms the fixed workflow baseline (68.3% vs. 69.2%), indicating that policy scale alone does not guarantee reliable orchestration. Adaptivity requires a reliable orchestration policy. Dynamic action selection is not automatically beneficial. When the policy is weak, adaptivity may lead to misallocated actions and fall behind a fixed workflow. As the policy becomes stronger or well-trained, adaptivity becomes beneficial: the non-trained 32B policy reaches 69.7%, while the trained 4B and 8B policies further improve to 70.3% and 71.2%, respectively. This suggests that adaptive orchestration

Yizhang Zhu, Zhangyang Peng, Boyan Li, and Yuyu Luo*

Table 6: Ablation of SFT supervision curation on BIRD-Dev. All variants use the Qwen3-8B policy backbone w/o. RL. SFT-only Policy

Simple

Moderate

Challenge

Total EX

Stability-weighted (Top-3) Top-1 only Shortest correct workflow only Non-trained policy

77.5 77.0 75.4 73.8

62.9 63.3 59.0 62.5

52.1 51.4 48.6 51.0

70.7 70.4 67.9 68.3

SQL Query Genera0on

SELECT COUNT (set_translations.setCode) FROM sets INNER JOIN …… WHERE sets.block = 'Commander' AND set_translations.language = 'Portuguese (Brasil)'

SELECT COUNT …… FROM … INNER JOIN… WHERE sets.block = 'Commander' AND set_translations.language = 'Portuguese (Brasil)'

SQL Query Reﬁnement SELECT COUNT(DISTINCT t1.code) FROM sets AS t1 INNER JOIN …… WHERE t1.block = 'Commander' AND t2.language = 'Portuguese (Brasil)'

(a) Orch. by Non-trained Policy

Relevant Value Extrac0on The previous SQL is almost correct… In database content, it’s not 'Brasil' but 'Portuguese (Brazil)' ……

SQL Query Genera0on SELECT COUNT …… FROM … INNER JOIN …… WHERE t1.block = 'Commander' AND t2.language = 'Portuguese (Brazil)'

(b) Orch. by Trained Policy

Figure 9: Case study. should be viewed as a policy-controlled capability rather than an inherent advantage of dynamic workflows. Policy learning is more effective than raw scaling. The trained 4B policy surpasses the non-trained 32B policy (70.3% vs. 69.7%), despite being roughly 8× smaller. This indicates that Search-toPolicy learning contributes orchestration behavior that cannot be explained by policy capacity alone. Overall, the gains of SQLConductor arise from the combination of adaptive execution and learned orchestration, with policy learning playing the central role. Adaptive execution can underperform a fixed workflow under an unreliable policy, but becomes notably more effective when guided by a sufficiently capable learned policy. RQ7: How does supervision curation approach affect policy learning in Stability-weighted Supervised Fine-tuning? To study the effect of supervision curation, Table 6 compares three strategies under the same Qwen3-8B policy backbone with RL disabled: using the explored shortest correct workflow for each query, using the top-1 workflow with the highest stability score, and using our stability-weighted top-3. Correct workflows are not equally effective supervision. Training on the shortest correct workflow reduces total EX to 67.9%, even below the non-trained policy (68.3%), with larger drops on Moderate and Challenging queries. This suggests that shortest-path supervision may bias the policy toward under-orchestration, as a workflow reaching the correct answer is not necessarily a robust orchestration pattern. Using the top-1 workflow improves EX to 70.4%, while the stability-weighted top-3 strategy achieves the best overall EX (70.7%) and the best Challenging performance. These results show that SFT benefits not from imitating arbitrary correct trajectories, but from curated supervision that captures stable and diverse orchestration patterns across search rollouts.

5.6

Case Study

Figure 9 presents a representative example from BIRD-Dev (QID: 405) to demonstrate how SQLConductor adapts its workflow. The

question requires precise value grounding: several similar surface forms exist (e.g., Brasil and Brazil), but only the database-stored form can be executed correctly. Both policies initially use the plausible but mismatched condition Portuguese (Brasil), which fails to match the stored value. After this failure, the non-trained policy naturally calls SQL refinement. However, without new value evidence, it preserves the wrong condition and leaves the error unresolved. In contrast, the trained policy recognizes the failure as a potential value-grounding issue. It first invokes relevant-value extraction to identify Portuguese (Brazil), then regenerates the query with the corrected condition. This case shows that learned step-wise orchestration can respond to execution failure by gathering missing evidence before regeneration, rather than repeatedly refining an under-grounded query, which is consistent with the aggregate analysis in Section 5.4.

RELATED WORK

LLM-based Text-to-SQL. Earlier LLM-based methods mainly prompt general-purpose LLMs for Text-to-SQL reasoning [5, 17, 39, 46]. For example, DAIL-SQL [7] studies in-context learning through demonstration selection. Some other works also focus on task-specific training, including fine-tuning [20, 24], reinforcement learning [40, 53, 60], and incremental pre-training [21], to enhance the Text-to-SQL translation capabilities of open-source LLMs. Workflow Organization in Text-to-SQL. Since real-world Textto-SQL often involves multi-stage reasoning, many systems organize the solving process as a workflow [26, 30, 31]. CHESS [47] and DeepEye-SQL [15] introduce carefully designed multi-stage pipelines for schema linking, SQL generation, revision, and selection to improve Text-to-SQL performance with prompting-based LLMs [16, 27]. Some systems further integrate trained reasoning models into such pipelines [28, 38, 45] or use specially trained LLMs for every individual stage [10, 12, 41, 44, 49]. However, these pipelines usually follow predefined stage orders, limiting their adaptivity to different query demands and intermediate feedback. Some methods thus explore dynamic workflow organization for Text-toSQL, including complexity-based routing [63] and inference-time MCTS search over reasoning paths [19, 23, 33, 55]. More recently, SquRL [51] attempts to plan a complete query-specific workflow before execution. While these methods improve system flexibility, they either incur substantial online search costs or still fix the workflow once execution begins. In contrast, SQLConductor introduces Search-to-Policy Learning to train a step-wise orchestration policy, enabling adaptive action selection and workflow revision during inference without extensive online search.

CONCLUSION

We propose SQLConductor, a step-wise orchestration learning framework for Text-to-SQL that adapts Text-to-SQL workflow composition.SQLConductor introduces Search-to-Policy Learning, which combines MCTS-based workflow exploration and curation, Stability-weighted Supervised Fine-tuning, and Curriculum Reinforcement Learning to transform broad offline search into a deployable orchestration policy. Extensive experiments demonstrate that SQLConductor achieves strong performance and generalization, with adaptive Text-to-SQL orchestration.

SQLConductor : Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

REFERENCES [1] David Berthelot, Nicholas Carlini, Ian Goodfellow, Nicolas Papernot, Avital Oliver, and Colin Raffel. 2019. Mixmatch: A holistic approach to semi-supervised learning. Advances in neural information processing systems 32 (2019). [2] Cameron B Browne, Edward Powley, Daniel Whitehouse, Simon M Lucas, Peter I Cowling, Philipp Rohlfshagen, Stephen Tavener, Diego Perez, Spyridon Samothrakis, and Simon Colton. 2012. A survey of monte carlo tree search methods. IEEE Transactions on Computational Intelligence and AI in games 4, 1 (2012), 1–43. [3] Zhenbiao Cao, Yuanlei Zheng, Zhihao Fan, Xiaojin Zhang, Wei Chen, and Xiang Bai. 2024. RSL-SQL: Robust Schema Linking in Text-to-SQL Generation. CoRR abs/2411.00073 (2024). [4] Alejandro Cuadron, Dacheng Li, Wenjie Ma, Xingyao Wang, Yichuan Wang, Siyuan Zhuang, Shu Liu, Luis Gaspar Schroeder, Tian Xia, Huanzhi Mao, et al. 2025. The danger of overthinking: Examining the reasoning-action dilemma in agentic tasks. arXiv preprint arXiv:2502.08235 (2025). [5] Xuemei Dong, Chao Zhang, Yuhang Ge, Yuren Mao, Yunjun Gao, Jinshu Lin, Dongfang Lou, et al. 2023. C3: Zero-shot text-to-sql with chatgpt. arXiv preprint arXiv:2307.07306 (2023). [6] Jiazhan Feng, Shijue Huang, Xingwei Qu, Ge Zhang, Yujia Qin, Baoquan Zhong, Chengquan Jiang, Jinxin Chi, and Wanjun Zhong. 2026. ReTool: Reinforcement Learning for Strategic Tool Use in LLMs. In The Fourteenth International Conference on Learning Representations. https://openreview.net/forum?id=tRk1nofSmz [7] Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, and Jingren Zhou. 2024. Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation. Proc. VLDB Endow. 17, 5 (2024), 1132–1145. [8] Hongcheng Gao, Yue Liu, Yufei He, Longxu Dou, Chao Du, Zhijie Deng, Bryan Hooi, Min Lin, and Tianyu Pang. 2025. Flowreasoner: Reinforcing query-level meta-agents. arXiv preprint arXiv:2504.15257 (2025). [9] Yuxiang Guo, Zhuoran Du, Nan Tang, Kezheng Tang, Congcong Ge, and Yunjun Gao. 2026. DTBench: A Synthetic Benchmark for Document-to-Table Extraction. In Proceedings of the 32nd ACM SIGKDD Conference on Knowledge Discovery and Data Mining. [10] Mingqian He, Yongliang Shen, Wenqi Zhang, Qiuying Peng, Jun Wang, and Weiming Lu. 2025. Star-sql: Self-taught reasoner for text-to-sql. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 24365–24375. [11] Zijin Hong, Zheng Yuan, Qinggang Zhang, Hao Chen, Junnan Dong, Feiran Huang, and Xiao Huang. 2025. Next-generation database interfaces: A survey of llm-based text-to-sql. IEEE Transactions on Knowledge and Data Engineering (2025). [12] Ruilin Hu, Yuyu Luo, Guoliang Li, Shuangqiao Wu, and Yun Luo. 2026. OpenSQL: Data-Efficient Text-to-SQL for Open-Source LLMs via Synthesized Intermediate Supervision. Proc. VLDB Endow. (2026). [13] Levente Kocsis and Csaba Szepesvári. 2006. Bandit based monte-carlo planning. In European conference on machine learning. Springer, 282–293. [14] Chia-Hsuan Lee, Oleksandr Polozov, and Matthew Richardson. 2021. KaggleDBQA: Realistic Evaluation of Text-to-SQL Parsers. In ACL/IJCNLP (1). Association for Computational Linguistics, 2261–2273. [15] Boyan Li, Chong Chen, Zhujun Xue, Yinan Mei, and Yuyu Luo. 2026. DeepEyeSQL: A Software-Engineering-Inspired Text-to-SQL Framework. Proc. ACM Manag. Data 4, 3 (2026). https://doi.org/10.1145/3802035 [16] Boyan Li, Ou Ocean Kun Hei, Yue Yu, and Yuyu Luo. 2026. DPC: TrainingFree Text-to-SQL Candidate Selection via Dual-Paradigm Consistency. https: //doi.org/10.48550/arXiv.2604.15163 arXiv:2604.15163 [cs.DB] Accepted to ACL 2026 Main Track. [17] Boyan Li, Yuyu Luo, Chengliang Chai, Guoliang Li, and Nan Tang. 2024. The Dawn of Natural Language to SQL: Are We Fully Ready? [Experiment, Analysis & Benchmark]. Proc. VLDB Endow. 17, 11 (2024), 3318–3331. [18] Boyan Li, Yiran Peng, Yupeng Xie, Sirong Lu, Yizhang Zhu, Xing Mu, Xinyu Liu, and Yuyu Luo. 2026. DeepEye: A Steerable Self-driving Data Agent System. In Companion of the International Conference on Management of Data (India) (SIGMOD Companion ’26). Association for Computing Machinery, New York, NY, USA, 74–77. https://doi.org/10.1145/3788853.3801612 [19] Boyan Li, Jiayi Zhang, Ju Fan, Yanwei Xu, Chong Chen, Nan Tang, and Yuyu Luo. 2025. Alpha-SQL: Zero-Shot Text-to-SQL using Monte Carlo Tree Search. In Forty-second International Conference on Machine Learning. [20] Haoyang Li, Shang Wu, Xiaokang Zhang, Xinmei Huang, Jing Zhang, Fuxin Jiang, Shuai Wang, Tieying Zhang, Jianjun Chen, Rui Shi, Hong Chen, and Cuiping Li. 2025. OmniSQL: Synthesizing High-quality Text-to-SQL Data at Scale. Proc. VLDB Endow. 18, 11 (2025), 4695–4709. [21] Haoyang Li, Jing Zhang, Hanbing Liu, Ju Fan, Xiaokang Zhang, Jun Zhu, Renjie Wei, Hongyan Pan, Cuiping Li, and Hong Chen. 2024. CodeS: Towards Building Open-source Language Models for Text-to-SQL. Proc. ACM Manag. Data 2, 3 (2024), 127. [22] Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, Binhua Li, Bowen Li, Bailin Wang, Bowen Qin, Ruiying Geng, Nan Huo, Xuanhe Zhou, Chenhao Ma, Guoliang Li, Kevin Chen-Chuan Chang, Fei Huang, Reynold Cheng, and Yongbin Li. 2023.

Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs. In NeurIPS. [23] Weibin Liao, Xin Gao, Tianyu Jia, Rihong Qiu, Yifan Zhu, Yang Lin, Xinyu Ma, Junfeng Zhao, and Yasha Wang. 2026. LearNAT: Learning NL2SQL with AST-guided Task Decomposition for Large Language Models. In The Fourteenth International Conference on Learning Representations. https://openreview.net/ forum?id=q6kXd8Gpfj [24] Xiaotian Lin, Yanlin Qi, Yizhang Zhu, Themis Palpanas, Chengliang Chai, Nan Tang, and Yuyu Luo. 2025. LEAD: iterative data selection for efficient LLM instruction tuning. Proceedings of the VLDB Endowment 19, 3 (2025), 426–439. [25] Shih-Yang Liu, Xin Dong, Ximing Lu, Shizhe Diao, Peter Belcak, Mingjie Liu, Min-Hung Chen, Hongxu Yin, Yu-Chiang Frank Wang, Kwang-Ting Cheng, Yejin Choi, Jan Kautz, and Pavlo Molchanov. 2026. GDPO: Group reward-Decoupled Normalization Policy Optimization for Multi-reward RL Optimization. In Fortythird International Conference on Machine Learning. [26] Xinyu Liu, Shuyu Shen, Boyan Li, Peixian Ma, Runzhi Jiang, Yuxin Zhang, Ju Fan, Guoliang Li, Nan Tang, and Yuyu Luo. 2025. A Survey of Text-to-SQL in the Era of LLMs: Where are we, and where are we going? IEEE Transactions on Knowledge and Data Engineering (2025). [27] Xinyu Liu, Shuyu Shen, Boyan Li, Nan Tang, and Yuyu Luo. 2025. NL2SQLBUGs: A Benchmark for Detecting Semantic Errors in NL2SQL Translation. In Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V.2 (Toronto ON, Canada) (KDD ’25). Association for Computing Machinery, New York, NY, USA, 5662–5673. https://doi.org/10.1145/3711896. 3737427 [28] Yifu Liu, Yin Zhu, Yingqi Gao, Zhiling Luo, Xiaoxia Li, Xiaorong Shi, Yuntao Hong, Jinyang Gao, Yu Li, Bolin Ding, and Jingren Zhou. 2026. XiYan-SQL: A Novel Multi-Generator Framework for Text-to-SQL. IEEE Trans. Knowl. Data Eng. 38, 4 (2026), 2474–2487. [29] Tianqi Luo, Chuhan Huang, Leixian Shen, Boyan Li, Shuyu Shen, Wei Zeng, Nan Tang, and Yuyu Luo. 2026. nvBench 2.0: Resolving Ambiguity in Text-toVisualization through Stepwise Reasoning. In The Thirty-ninth Annual Conference on Neural Information Processing Systems Datasets and Benchmarks Track. https: //openreview.net/forum?id=PuzbYHf1GR [30] Yuyu Luo, Guoliang Li, Ju Fan, Chengliang Chai, and Nan Tang. 2025. Natural language to sql: State of the art and open problems. Proceedings of the VLDB Endowment 18, 12 (2025), 5466–5471. [31] Yuyu Luo, Guoliang Li, Ju Fan, and Nan Tang. 2026. Data Agents: Levels, State of the Art, and Open Problems. arXiv preprint arXiv:2602.04261 (2026). [32] Yuyu Luo, Xuedi Qin, Nan Tang, and Guoliang Li. 2018. DeepEye: Towards Automatic Data Visualization. In 34th IEEE International Conference on Data Engineering, ICDE 2018, Paris, France, April 16-19, 2018. IEEE Computer Society, 101–112. https://doi.org/10.1109/ICDE.2018.00019 [33] Shuai Lyu, Haoran Luo, Ripeng Li, Zhonghong Ou, Jiangfeng Sun, Yang Qin, Xiaoran Shang, Meina Song, and Yifan Zhu. 2025. Sql-o1: A self-reward heuristic dynamic search method for text-to-sql. arXiv preprint arXiv:2502.11741 (2025). [34] Da Ma, Ziyue Yang, Hongshen Xu, Haotian Fang, Kai Yu, and Lu Chen. 2026. Empowering LLM Tool Invocation with Tool-call Reward Model. In The Fourteenth International Conference on Learning Representations. https://openreview. net/forum?id=LnBEASInVr [35] Peixian Ma, Boyan Li, Runzhi Jiang, Ju Fan, Nan Tang, and Yuyu Luo. 2024. A Plug-and-Play Natural Language Rewriter for Natural Language to SQL. arXiv preprint arXiv:2412.17068 (2024). [36] Stefan Nielsen, Edoardo Cetin, Peter Schwendeman, Qi Sun, Jinglue Xu, and Yujin Tang. 2026. Learning to Orchestrate Agents in Natural Language with the Conductor. In The Fourteenth International Conference on Learning Representations. https://openreview.net/forum?id=U23A2BUKYt [37] Ma Peixian, Xialie Zhuang, Chengjin Xu, Xuhui Jiang, Ran Chen, and Jian Guo. 2025. SQL-R1: Training natural language to sql reasoning model by reinforcement learning. In The Thirty-ninth Annual Conference on Neural Information Processing Systems. [38] Mohammadreza Pourreza, Hailong Li, Ruoxi Sun, Yeounoh Chung, Shayan Talaei, Gaurav Tarlok Kakkar, Yu Gan, Amin Saberi, Fatma Ozcan, and Sercan Ö. Arik. 2025. CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL. In ICLR. OpenReview.net. [39] Mohammadreza Pourreza and Davood Rafiei. 2023. DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction. In Thirty-seventh Conference on Neural Information Processing Systems. [40] Mohammadreza Pourreza, Shayan Talaei, Ruoxi Sun, Xingchen Wan, Hailong Li, Azalia Mirhoseini, Amin Saberi, and Sercan O Arik. 2025. Reasoning-SQL: Reinforcement Learning with SQL Tailored Partial Rewards for Reasoning-Enhanced Text-to-SQL. In Second Conference on Language Modeling. [41] Yang Qin, Chao Chen, Zhihang Fu, Ze Chen, Dezhong Peng, Peng Hu, and Jieping Ye. 2025. ROUTE: Robust Multitask Tuning and Collaboration for Text-to-SQL. In The Thirteenth International Conference on Learning Representations. [42] Jianhao Ruan, Zhihao Xu, Yiran Peng, Fashen Ren, Zhaoyang Yu, Xinbing Liang, Jinyu Xiang, Yongru Chen, Bang Liu, Chenglin Wu, Yuyu Luo, and Jiayi Zhang. 2026. AOrchestra: Automating Sub-Agent Creation for Agentic Orchestration.

Yizhang Zhu, Zhangyang Peng, Boyan Li, and Yuyu Luo*

arXiv:2602.03786 [cs.AI] https://arxiv.org/abs/2602.03786 [43] Zhihong Shao, Peiyi Wang, Qihao Zhu, Runxin Xu, Junxiao Song, Xiao Bi, Haowei Zhang, Mingchuan Zhang, YK Li, Yang Wu, et al. 2024. Deepseekmath: Pushing the limits of mathematical reasoning in open language models. arXiv preprint arXiv:2402.03300 (2024). [44] Lei Sheng and Xu Shuai Shuai. 2025. CSC-SQL: Corrective Self-Consistency in Text-to-SQL via Reinforcement Learning. In IJCNLP-AACL (Findings). The Asian Federation of Natural Language Processing and The Association for Computational Linguistics, 1473–1496. [45] Lei Sheng, Shuai-Shuai Xu, and Wei Xie. 2025. BASE-SQL: A powerful open source Text-To-SQL baseline approach. arXiv preprint arXiv:2502.10739 (2025). [46] Chang-Yu Tai, Ziru Chen, Tianshu Zhang, Xiang Deng, and Huan Sun. 2023. Exploring chain of thought style prompting for text-to-sql. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing. 5376–5393. [47] Shayan Talaei, Mohammadreza Pourreza, Yu-Chen Chang, Azalia Mirhoseini, and Amin Saberi. 2024. CHESS: Contextual Harnessing for Efficient SQL Synthesis. CoRR abs/2405.16755 (2024). [48] Bing Wang, Changyu Ren, Jian Yang, Xinnian Liang, Jiaqi Bai, LinZheng Chai, Zhao Yan, Qian-Wen Zhang, Di Yin, Xing Sun, and Zhoujun Li. 2025. MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL. In Proceedings of the 31st International Conference on Computational Linguistics. [49] Pengfei Wang, Baolin Sun, Xuemei Dong, Yaxun Dai, Hongwei Yuan, Mengdie Chu, Yingqi Gao, Xiang Qi, Peng Zhang, and Ying Yan. 2025. AgentarScale-SQL: Advancing Text-to-SQL through Orchestrated Test-Time Scaling. arXiv:2509.24403 [cs.CL] https://arxiv.org/abs/2509.24403 [50] Yihan Wang, Peiyu Liu, Runyu Chen, Jiaxing Pu, and Wei Xu. 2025. Squrve: A Unified and Modular Framework for Complex Real-World Text-to-SQL Tasks. arXiv preprint arXiv:2510.24102 (2025). [51] Yihan Wang, Peiyu Liu, Runyu Chen, and Wei Xu. 2026. Beyond Static Pipelines: Learning Dynamic Workflows for Text-to-SQL. arXiv preprint arXiv:2602.15564 (2026). [52] Xiangjin Xie, Guangwei Xu, Lingyan Zhao, and Ruijie Guo. 2025. OpenSearchSQL: Enhancing Text-to-SQL with Dynamic Few-shot and Consistency Alignment. Proc. ACM Manag. Data 3, 3 (2025), 194:1–194:24. [53] Zhewei Yao, Guoheng Sun, Lukasz Borchmann, Gaurav Nuti, Zheyu Shen, Minghang Deng, Bohan Zhai, Hao Zhang, Ang Li, and Yuxiong He. 2025. Arctictext2sql-r1: Simple rewards, strong reasoning in text-to-sql. arXiv preprint arXiv:2505.20315 (2025). [54] Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, Dongxu Wang, Zifan Li, James Ma, Irene Li, Qingning Yao, Shanelle Roman, Zilin Zhang, and Dragomir R.

Radev. 2018. Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task. In EMNLP. Association for Computational Linguistics, 3911–3921. [55] Shuozhi Yuan, Liming Chen, Miaomiao Yuan, and Zhao Jin. 2026. MCTS-SQL: Light-Weight LLMs Can Master the Text-to-SQL Through Monte Carlo Tree Search. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 40. 34521–34529. [56] Sandy L Zabell. 1989. The rule of succession. Erkenntnis 31, 2 (1989), 283–321. [57] Fan Zhang, Vireo Zhang, Shengju Qian, Haoxuan Li, Hao Wu, Jinyang Wu, Donghao Zhou, Zhihong Zhu, Zheng Lian, Xin Wang, and Pheng-Ann Heng. 2026. Orchestra-o1: Omnimodal Agent Orchestration. arXiv:2606.13707 [cs.AI] https://arxiv.org/abs/2606.13707 [58] Jiayi Zhang, Jinyu Xiang, Zhaoyang Yu, Fengwei Teng, Xiong-Hui Chen, Jiaqi Chen, Mingchen Zhuge, Xin Cheng, Sirui Hong, Jinlin Wang, Bingnan Zheng, Bang Liu, Yuyu Luo, and Chenglin Wu. 2025. AFlow: Automating Agentic Workflow Generation. In The Thirteenth International Conference on Learning Representations. https://openreview.net/forum?id=z5uVAKwmjf [59] Yi Zhang, Jan Deriu, George Katsogiannis-Meimarakis, Catherine Kosten, Georgia Koutrika, and Kurt Stockinger. 2023. ScienceBenchmark: A Complex RealWorld Benchmark for Evaluating Natural Language to SQL Systems. Proc. VLDB Endow. 17, 4 (2023), 685–698. [60] Yuxin Zhang, Meihao Fan, Ju Fan, Mingyang Yi, Yuyu Luo, Guoliang Li, Bin Wu, and Wenchao Zhou. 2026. Reward-SQL: Boosting Text-to-SQL via Stepwise Execution-Aware Reasoning and Process-Supervised Rewards. Proceedings of the ACM on Management of Data 4, 3 (SIGMOD (2026), 1–27. [61] Yabo Zhang, Yihan Zeng, Qingyun Li, Zhen Hu, Kavin Han, and Wangmeng Zuo. 2025. Tool-R1: Sample-Efficient Reinforcement Learning for Agentic Tool Use. arXiv preprint arXiv:2509.12867 (2025). [62] Yizhang Zhu, Shiyin Du, Boyan Li, Yuyu Luo, and Nan Tang. 2024. Are large language models good statisticians? Advances in Neural Information Processing Systems 37 (2024), 62697–62731. [63] Yizhang Zhu, Runzhi Jiang, Boyan Li, Nan Tang, and Yuyu Luo. 2025. EllieSQL: Cost-Efficient Text-to-SQL with Complexity-Aware Routing. In Second Conference on Language Modeling. [64] Yizhang Zhu, Liangwei Wang, Chenyu Yang, Xiaotian Lin, Boyan Li, Wei Zhou, Xinyu Liu, Zhangyang Peng, Tianqi Luo, Yu Li, et al. 2025. A Survey of Data Agents: Emerging Paradigm or Overstated Hype? arXiv preprint arXiv:2510.23587 (2025).

Record · ID 299946 · SHA-256 6ce60886b22b623b
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.