🤖 machine learning

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

The paper introduces SQLConductor, a step-wise orchestration framework that employs Search-to-Policy Learning to train a policy model for dynamically selecting SQL subtasks based on intermediate feedback, thereby achieving superior execution accuracy and generalization on complex Text-to-SQL benchmarks compared to fixed pipelines and direct backbone training.

Original authors: Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

Published 2026-06-23

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to get a very specific answer from a massive, messy library of information (a database) by asking a question in plain English. This is the "Text-to-SQL" problem: turning a human question into a computer command (SQL) that the library can understand.

For a long time, computers tried to solve this by following a strict, pre-written recipe. No matter what you asked, the computer had to follow the same steps: Step 1, Step 2, Step 3, Step 4. If you asked a simple question like "What is the capital of France?", the computer still had to go through all four steps, wasting time and sometimes getting confused. If you asked a hard question and the computer made a mistake in Step 2, it would keep marching forward with that mistake, leading to a wrong answer.

SQLConductor is a new system that changes the game. Instead of following a rigid recipe, it acts like a smart project manager or a conductor who decides the next move based on what is happening right now.

Here is how it works, using simple analogies:

1. The Toolbox (The Action Space)

Imagine the computer has a toolbox with different specialized tools:

The Breaker: Breaks a big question into smaller parts.
The Finder: Looks for specific numbers or names in the database.
The Filter: Cuts out irrelevant information.
The Writer: Writes the actual computer command.
The Editor: Fixes mistakes in the command.
The Finisher: Says, "We are done, here is the answer."

Old systems forced the computer to pick tools in a specific order (e.g., Breaker $\to$ Finder $\to$ Writer $\to$ Finisher). SQLConductor lets the "Conductor" pick whichever tool is needed right now. If the Finder realizes it needs more info, the Conductor can call the Breaker again. If the Writer makes a mistake, the Conductor can call the Editor immediately.

2. The Training Camp (Search-to-Policy Learning)

How does the Conductor learn to make these smart decisions? It doesn't just read a manual; it goes through a rigorous training camp called Search-to-Policy Learning.

The Simulation (MCTS): Imagine a chess player practicing against a computer. The computer tries thousands of different game paths (workflows) to see which ones win. SQLConductor does this too: it simulates millions of different ways to solve a question, trying different combinations of tools.
The Stability Check: Just because a path worked once doesn't mean it's a good strategy; it might have been luck. The system looks at which paths work consistently. It's like a coach saying, "Don't just copy the one time you won by luck; copy the strategy that wins 9 out of 10 times."
The "Curriculum" (Harder Problems): Once the Conductor gets good at easy problems, the training camp throws harder, trickier questions at it. The system learns specifically how to handle the difficult cases where it usually fails.

3. The Result: A Flexible, Efficient Worker

Once trained, the SQLConductor is deployed to solve real questions.

Adaptability: If you ask a simple question, the Conductor might say, "I don't need the Editor or the Breaker; I'll just use the Writer and Finisher." It saves time. If you ask a complex question, it knows to loop back, gather more evidence, and refine the answer.
Efficiency: Because it only uses the tools it actually needs, it uses less computing power and costs less money than systems that force every question through a long, fixed pipeline.
Accuracy: In tests, this system got the right answer more often than previous methods, even when the questions were very difficult or the databases were messy.

The Big Picture

Think of old Text-to-SQL systems as a conveyor belt in a factory: every item goes through the same machines, whether it needs them or not. If a part breaks on the belt, the whole line keeps moving, producing bad products.

SQLConductor is like a skilled craftsman in a workshop. They look at the item (the question), decide which tools to grab, try a step, check the result, and then decide what to do next. If they make a mistake, they fix it immediately. If the job is simple, they finish it quickly. If it's complex, they take the time to get it right.

The paper claims that by teaching a computer to act like this skilled craftsman—rather than a rigid machine—it can solve database questions more accurately, more efficiently, and with better adaptability to different types of problems.

Technical Summary: SQLConductor

1. Problem Statement

Real-world Text-to-SQL remains challenging due to the need for coordinated reasoning over complex, heterogeneous database environments. Existing systems generally fall into two categories, both of which exhibit limitations in adaptivity:

Fixed Pipelines: These rely on predefined, rigid stage orders (e.g., schema linking $\to$ value retrieval $\to$ generation $\to$ revision). While structured, they cannot reconsider earlier decisions based on intermediate feedback or execution errors, leading to error propagation.
Plan-then-Execute Orchestration: These methods generate a complete workflow plan before execution. While more flexible than fixed pipelines, they still commit to a static sequence once execution begins, preventing the system from adapting to intermediate artifacts or execution feedback during the solving process.

The core challenge is learning a step-wise orchestration policy that can dynamically select the next action based on the current solving context and intermediate evidence, without relying on human-crafted workflow data or incurring prohibitive online search costs at inference time.

2. Methodology: SQLConductor

SQLConductor is a step-wise orchestration learning framework that separates process organization (orchestration) from subtask execution (reasoning). It employs a Search-to-Policy Learning paradigm, transforming broad offline workflow search into a deployable policy for efficient inference.

2.1 Action Space

The system defines a modular action space $\mathcal{A}$ comprising seven specialized modules, invoked by frozen Large Language Models (LLMs):

Question Decomposition ( $a_{dec}$ ): Rewrites complex questions into fine-grained requirements.
Relevant Value Extraction ( $a_{val}$ ): Identifies condition values for SQL predicates.
Operation Identification ( $a_{op}$ ): Records required SQL operations (e.g., aggregation, ordering).
Schema Pruning ( $a_{sch}$ ): Selects relevant tables and columns.
SQL Query Generation ( $a_{gen}$ ): Synthesizes a SQL candidate.
SQL Query Refinement ( $a_{ref}$ ): Corrects syntax or execution errors.
Terminate and Output ( $a_{term}$ ): Ends the workflow and returns the final SQL.

2.2 Search-to-Policy Learning

The training process consists of an offline phase and an online deployment phase.

Phase 1: Offline Search-to-Policy Training

MCTS-based Workflow Exploration:
- For each training instance, SQLConductor performs Monte Carlo Tree Search (MCTS) over the action space.
- Nodes represent orchestration states; edges represent action selections.
- The search explores diverse action compositions and depths, guided by execution-consistency rewards (measuring if generated SQL produces consistent results across multiple samples).
- This generates a diverse set of candidate trajectories $\mathcal{X}(q, D)$ .
Workflow Supervision Curation:
- Skeleton Extraction: Trajectories are grouped by their action sequences (workflow skeletons).
- Stability Estimation: Since the search space is combinatorial and noisy, SQLConductor estimates the stability of each workflow using Laplace's rule of succession: $\hat{p}_\tau = \frac{s_\tau + 1}{n_\tau + 2}$ , where $s_\tau$ is the count of successful executions and $n_\tau$ is the total count.
- Selection: The top- $k$ workflows with the highest stability scores are selected. One successful trajectory is sampled from each group as a representative.
- Reasoning Augmentation: A deployed LLM generates step-level reasoning ( $e_t$ ) explaining why a specific action was chosen given the current context, creating an augmented trajectory $\bar{\xi}$ .
Stability-weighted Supervised Fine-tuning (SFT):
- The policy model is trained on the curated augmented trajectories.
- Masking: The loss function masks out <results> tokens (action outputs) to prevent the policy from learning to predict action outputs, focusing instead on orchestration decisions.
- Weighting: Trajectories are weighted by their stability scores ( $\hat{p}_\tau$ ) to prioritize robust orchestration patterns while preserving diversity.
Curriculum Reinforcement Learning (RL):
- To handle difficult queries where successful trajectories are sparse, the system constructs a curriculum set of challenging instances (low MCTS success ratio).
- Using Group Relative Policy Optimization (GRPO), the policy performs self-rollouts on these hard cases.
- Rewards: The reward function combines Executability (valid SQL) and Outcome Quality (Execution F1 score against the ground truth), encouraging the policy to learn recovery strategies for complex cases.

Phase 2: Online Deployment

The trained policy model coordinates the frozen action modules step-by-step.
At each step, the policy generates reasoning and selects the next action based on the current state (accumulated evidence and feedback).
The workflow is constructed dynamically during execution, adapting to the specific demands of the query.

3. Key Contributions

Step-wise Orchestration Framework: SQLConductor introduces a framework that decouples process organization from subtask execution, enabling query-specific workflows with adaptive depths and module compositions, unlike fixed pipelines or plan-then-execute approaches.
Search-to-Policy Learning: The paper proposes a mechanism to train an adaptive orchestration policy without human-crafted workflow data. It utilizes MCTS for exploration, stability estimation for curation, and a combination of Stability-weighted SFT and Curriculum RL for training.
Empirical Performance and Generalization:
- BIRD-Dev: SQLConductor achieves 73.2% Execution Accuracy (EX) on the BIRD-Dev benchmark, outperforming prior methods that directly train comparable or larger Text-to-SQL backbones.
- Parameter Efficiency: It achieves these results by training only a compact orchestration policy (e.g., 8B parameters) to coordinate frozen larger action models (e.g., 32B), demonstrating superior accuracy-per-trained-parameter efficiency.
- Generalization: The model shows strong generalization on out-of-distribution (OOD) datasets (Spider-Test, KaggleDBQA, ScienceBenchmark) without dataset-specific re-training.
- Efficiency: It reduces inference-time token usage and API costs significantly (approx. 8x cheaper than baselines like CHESS) while maintaining higher accuracy.

4. Significance and Claims

The paper claims that learned orchestration is more parameter-efficient and effective than further training a monolithic Text-to-SQL model.

Adaptivity vs. Brute Force: The results demonstrate that the performance gains come not from simply increasing workflow length or model size, but from the policy's ability to allocate orchestration effort adaptively. The trained policy assigns more steps to challenging queries while keeping simple queries efficient.
Robustness: The stability-weighted curation ensures the policy learns robust patterns rather than accidental successes, allowing it to handle complex, noisy, and domain-specialized queries effectively.
Scalability: By separating the orchestration policy from the action modules, the framework allows for the integration of larger or specialized action models without retraining the entire system, offering a scalable path for complex Text-to-SQL tasks.

In summary, SQLConductor addresses the rigidity of existing Text-to-SQL systems by learning a dynamic, step-wise orchestration policy that adapts to intermediate evidence, achieving state-of-the-art performance with significantly lower computational costs.