1 Introduction↩︎

Text-to-SQL converts natural language questions into executable SQL queries [1], [2]. Recent LLM-based systems have improved SQL generation through prompting [3]–[5], supervised fine-tuning [6], [7], and reinforcement learning [8]. As modern databases often contain large and complex schemas, selecting relevant tables and columns becomes a necessary intermediate step for accurate SQL generation, making schema linking a critical challenge [9]. Existing systems typically handle this step in two ways. One approach performs full-schema generation, where schema selection is implicitly learned within end-to-end SQL generation over the entire database [4], [5], [10]. Another approach introduces a separate retriever trained with static gold-column supervision to explicitly select relevant schema components before SQL generation [7], [11], [12].

A central issue in both designs is a generator-conditioned supervision mismatch. In full-schema generation, schema selection is implicitly coupled with SQL generation and updated only through the final SQL loss. As Figure 1 (a) shows, replacing full schemas with gold-column inputs improves execution accuracy by up to +15.4 points. Even a model trained on only 4k gold-column samples can surpass a 2.5M-sample model under gold-column inputs, confirming the value of explicit schema linking. In retriever-generator pipelines, schema linking is explicit, but the retriever is trained against static gold-column annotations. Yet Figure 1 (b) shows that from 19.1% to 42.3% of execution-correct full-schema predictions rely on non-gold column sets, particularly on harder queries. Since SQL generation often admits multiple executable routes, the current generator policy may prefer relational paths and query patterns it has already learned to use. Appendix 12.4 provides examples of execution-correct non-gold routes. A retriever anchored to fixed gold targets thus penalizes executable schema configurations preferred by the current generator. These observations suggest that schema linking should be explicitly optimized, and that execution-aligned signals can better track on-policy executable routes.

At the same time, moving retrieval supervision on-policy introduces a coupled optimization challenge: retrieved schemas define the generator’s input distribution, while execution-correct generator rollouts determine which column sets become positive retrieval targets. Updating either role can therefore shift the other’s training environment or supervision target, creating a circular dependency whose shared backbone further risks gradient interference. However, this same coupling enables bidirectional adaptation: the retriever updates toward column sets that the generator can execute correctly, while the generator adapts to the retriever’s evolving selections, with execution accuracy grounding both directions. The challenge is therefore not to eliminate the coupling, but to stabilize it.

We propose Adaptive Co-optimization via Empirical Credit Assignment for Text-to-SQL (ACE-SQL), a reinforcement learning framework that jointly optimizes schema retrieval and SQL generation over a shared policy. ACE-SQL maintains a per-question pool of execution-correct column sets, uses the most frequent set as an adaptive on-policy retrieval target, and trains the generator with execution rewards under a majority-voted schema. PCGrad [13] and a generator-weight schedule stabilize this coupled optimization.

Our contributions are:

• We formulate schema retrieval in retriever-generator Text-to-SQL as an on-policy credit assignment problem. Instead of relying on static gold-column supervision, ACE-SQL derives adaptive retrieval targets from execution-correct generator rollouts under the current policy, leading to stronger and more stable training.

• We propose ACE-SQL, a bidirectionally adaptive joint reinforcement learning framework that uses execution accuracy to align the two directions of the co-adaptation loop. PCGrad and a generator-weight schedule stabilize this coupled optimization.

• With only 2,913 RL examples, ACE-SQL achieves 65.3% greedy execution accuracy on BIRD Dev while using 0.93k output tokens per query, outperforming SQL-R1-7B and MTIR-SQL-8B while using 3.3\(\times\) and 2.2\(\times\) fewer output tokens, and remains competitive on Spider.

2 Related Work↩︎

2.0.0.1 LLM-Based Text-to-SQL.

Recent Text-to-SQL systems rely on large language models through prompting [3], [5], [10], [14], supervised fine-tuning [6], [7], [15], [16], and reinforcement learning [8]. These methods substantially advance SQL generation, but treat schema linking as either implicit within full-schema generation or frozen within a fixed retriever-generator pipeline. Neither design allows retrieval decisions to receive execution-grounded credit during generator optimization.

2.0.0.2 Schema Linking in Text-to-SQL.

Schema linking selects relevant tables and columns to reduce context noise, especially for large databases. Existing approaches include prompt-based schema refinement [10], [17], generative pruning [7], extractive or discriminative linking [11], [12], and pipeline-based linking with SQL revision [18]. Among these, JOLT-SQL [12] is the most closely related, as it jointly trains schema linking and SQL generation under a unified objective. However, its retriever target remains the static gold column set throughout training. When the generator’s executable preferences diverge from the gold route, as observed in 19% to 42% of correct predictions (Figure 1 (b)), retriever updates anchored to a fixed label cannot track this divergence. ACE-SQL instead derives retriever targets from online execution-correct rollouts, allowing the retrieval objective to co-evolve with the generator policy.

2.0.0.3 Reinforcement Learning for Text-to-SQL.

Reinforcement learning has been applied to Text-to-SQL through execution rewards for structured query generation [19], group-relative policy optimization [20], [21], task-specific SQL reasoning rewards [8], [22], and multi-turn execution feedback [23], [24]. These systems optimize SQL generation under a fixed or implicit schema context, leaving the retriever outside the RL loop. ACE-SQL instead performs joint RL over both roles: retrieved schemas define the generator’s input space, while execution-correct generator rollouts define positive retrieval targets. This bidirectional coupling introduces non-stationarity and gradient conflicts reminiscent of challenges studied in multi-agent RL [25] and multi-task optimization [13]. ACE-SQL addresses both with empirical target smoothing, majority voting, a generator-weight schedule, and PCGrad.

3 ACE-SQL↩︎

3.1 Overview↩︎

Given a natural language question \(q\), a database schema \(\mathcal{S} = \{(t_i, \{c_{i,j}\})\}\) containing tables \(t_i\) with columns \(c_{i,j}\), and a database instance \(\mathcal{D}\), Text-to-SQL aims to generate an executable SQL query \(y\) whose execution result matches the user’s intent. ACE-SQL makes schema linking an explicit upstream decision by factorizing inference into two roles handled by the same LLM policy \(\pi_\theta\):

• Schema Retrieval: Given the complete schema \(\mathcal{S}\) and question \(q\), select a relevant column subset \(\hat{\mathcal{C}} \subseteq \mathcal{C}\), where \(\mathcal{C} = \{c_{i,j}\}\) denotes all columns.

• SQL Generation: Given the pruned schema \(\mathcal{S}|_{\hat{\mathcal{C}}}\) and question \(q\), generate SQL query \(y\).

This factorization separates the decisions without separating the backbone. The retriever and generator share parameters, but use different prompts, rollouts, and rewards. As shown in Figure 2, ACE-SQL is trained in two stages. Supervised fine-tuning first provides a cold start for the explicit retriever\(\to\)generator pipeline (§3.2). Joint GRPO training then uses online execution-correct generator rollouts to construct adaptive retriever targets and optimize both roles under the same execution objective (§3.3). The resulting training dynamics induce bidirectional adaptation: the empirical pool mechanism (§3.3.1) adapts retriever targets toward generator-preferred executable routes, while majority-voted schema selection adapts the generator’s input distribution toward the retriever’s evolving consensus. Execution accuracy grounds both directions of this co-adaptation loop.

3.2 Supervised Fine-Tuning Cold Start↩︎

Reinforcement learning requires a workable retriever-generator pipeline before execution feedback can be useful. We therefore initialize Qwen3-8B [26] with self-distillation supervised fine-tuning. This stage is not used to define a permanent gold retrieval target; it only gives both roles enough initial competence for online rollouts to produce execution-matched SQL.

(1) Source Filtering. We first filter samples of suitable difficulty from SynSQL-2.5M [15] according to query complexity and schema diversity.

(2) Paired Self-Distillation. We use Qwen3-8B itself to synthesize both retriever and generator samples. For each question, retriever outputs are aggregated with self-consistency voting to obtain candidate column sets. These column sets define pruned schemas for generator sampling, and generator samples are kept only when their execution results match those of the gold SQL. If a retriever output cannot support any matched downstream SQL, the corresponding paired sample is discarded.

(3) Mixed Supervised Fine-Tuning. We train the retriever and generator samples together in one full-parameter supervised fine-tuning run. The resulting checkpoint initializes the shared policy \(\pi_\theta\) for joint reinforcement learning.

3.3 Joint GRPO Training↩︎

3.3.1 Rollout and Empirical Pool↩︎

The core of ACE-SQL is to turn successful generator behavior into retriever supervision. Each training-step rollout contains three operations: retriever sampling and parsing, generator sampling and execution, and empirical target update.

3.3.1.1 Retriever Rollout and Schema Voting.

For each question \(q_i\), the policy in retriever mode samples \(N\) column selections \(\{\hat{\mathcal{C}}_i^{(k)}\}_{k=1}^{N}\). These samples are aggregated by majority voting: \[\hat{\mathcal{C}}_i^{\text{maj}} = \operatorname{MajVote}\!\left(\{\hat{\mathcal{C}}_i^{(k)}\}_{k=1}^{N}\right).\] A pruned schema containing only columns in \(\hat{\mathcal{C}}_i^{\text{maj}}\) is then shared by all generator samples for this question. We denote it as \(\hat{\mathcal{S}}_i=\mathcal{S}_i|_{\hat{\mathcal{C}}_i^{\text{maj}}}\). Majority voting reduces rollout noise and provides a stable, retriever-conditioned schema environment for the generator, constituting one direction of bidirectional adaptation: the generator progressively adapts to the schema distribution preferred by the current retriever policy.

3.3.1.2 Generator Rollout.

The same policy in generator mode produces \(N\) responses \(\{o_i^{\text{gen},(j)}\}_{j=1}^{N}\) conditioned on the pruned schema, from which SQLs \(\{y_i^{(j)}\}_{j=1}^{N}\) are parsed. These SQLs are executed against the database. Execution results provide the generator reward and determine which column sets can be credited to the retriever.

3.3.1.3 Empirical Column-Set Pool.

The empirical pool records column sets that the generator has successfully used. Before reinforcement learning, we initialize the pool with a high-recall schema rollout from the SFT checkpoint on SynSQL examples labeled as hard. For each question, the retriever samples 8 column selections, and we take their set union rather than selecting a single voted set: \[\hat{\mathcal{C}}_{i}^{\text{union}} = \bigcup_{k=1}^{8}\hat{\mathcal{C}}_{i,\text{init}}^{(k)}, \qquad \hat{\mathcal{S}}_{i}^{\text{init}}=\mathcal{S}_{i}|_{\hat{\mathcal{C}}_{i}^{\text{union}}}. \label{eq:init95union95schema}\tag{1}\] The downstream generator then samples 16 SQLs under \(\hat{\mathcal{S}}_{i}^{\text{init}}\). This union-based initialization favors recall over early retriever consensus, giving downstream SQL exploration enough schema coverage before the pool is converted into retrieval targets. We retain examples with between 2 and 14 execution-correct SQLs and initialize \(f_{\text{pool}}^q\) from the matched initialization SQLs. During training, later matched rollouts continue updating the pool, while old column sets are exponentially decayed so that newer evidence receives sufficient weight. For each online rollout, we extract column sets from matched SQL samples: \[\mathcal{P}_{\text{cur}}(q)= \{C(y^{(j)}) \mid \text{exec}(y^{(j)})=\text{Match}\},\] where \(C(\cdot)\) extracts columns referenced by a SQL query. Let \(f_{\text{current}}^q(S)\) count how often a column set \(S\) appears in \(\mathcal{P}_{\text{cur}}(q)\). These counts update the historical empirical pool for every set \(S\) observed in either the current rollout or the existing pool: \[f_{\text{pool}}^q(S) \leftarrow \gamma \cdot f_{\text{pool}}^q(S) + f_{\text{current}}^q(S),\] where \(\gamma = 0.5\) discounts older rollout evidence while preserving successful routes across updates. Let \[S^\star(q)=\arg\max_{S} f_{\text{pool}}^{q}(S)\] be the most frequent successful column set for question \(q\). We use \(S^\star(q)\) as the retriever target.

3.3.2 Reward Construction↩︎

Both roles use sparse rewards gated by the same clipped length-penalty function: \[p_{\ell}(o)=0.5\cdot \operatorname{clip}\!\left(\frac{\operatorname{len}(o)-512}{2048-512},\,0,\,1\right), \label{eq:length95penalty}\tag{2}\] where \(\operatorname{len}(\cdot)\) returns the token length and \(\operatorname{clip}(x,0,1)=\min(1,\max(0,x))\). Outputs with at most 512 tokens receive no length penalty, the penalty increases linearly until it reaches 0.5 at 2048 tokens, and outputs are truncated at this maximum response length.

For each question \(q\), the generator and retriever rewards are \[\begin{align} r_{\text{gen}}(y) &= \begin{cases} 1-p_{\ell}(o), & \text{exec}(y)=\text{Match},\\ 0, & \text{otherwise,} \end{cases} \tag{3}\\ r_{\text{ret}}(\hat{\mathcal{C}}) &= \begin{cases} 1-p_{\ell}(o), & \hat{\mathcal{C}}=S^\star(q),\\ 0, & \text{otherwise.} \end{cases} \tag{4} \end{align}\] The SQL \(y\) and column set \(\hat{\mathcal{C}}\) are parsed from the corresponding role outputs. Thus, the length penalty affects only outputs that satisfy the sparse reward condition. Unmatched outputs receive zero reward regardless of length, preventing reward hacking through short but incorrect responses.

3.3.3 Joint GRPO Update↩︎

3.3.3.1 Standard GRPO.

GRPO [20] eliminates the value function in PPO [27] by estimating advantages from within-group reward statistics. We use the standard clipped GRPO surrogate with KL regularization against a frozen reference policy.

3.3.3.2 Dual-Role Extension.

ACE-SQL applies GRPO to two roles of the same policy. For each question, the retriever and generator each sample \(N\) outputs under role-specific prompts. Let \(o^{\text{ret},(k)}\) denote the serialized retriever output parsed into \(\hat{\mathcal{C}}^{(k)}\), let \(o^{\text{gen},(j)}\) denote the serialized generator output parsed into \(y^{(j)}\), and write \(\hat{\mathcal{S}}\) for the majority-voted pruned schema. The role-specific importance ratios are: \[\begin{align} \rho^{\text{ret}}_{k,t} &= \frac{\pi_{\theta}(o^{\text{ret}}_{k,t} \mid \mathcal{S}, q, o^{\text{ret}}_{k,<t})}{\pi_{\theta_{\text{old}}}(o^{\text{ret}}_{k,t} \mid \mathcal{S}, q, o^{\text{ret}}_{k,<t})} \\[3pt] \rho^{\text{gen}}_{j,t} &= \frac{\pi_{\theta}(o^{\text{gen}}_{j,t} \mid \hat{\mathcal{S}}, q, o^{\text{gen}}_{j,<t})}{\pi_{\theta_{\text{old}}}(o^{\text{gen}}_{j,t} \mid \hat{\mathcal{S}}, q, o^{\text{gen}}_{j,<t})} \end{align} \label{eq:importance95ratios}\tag{5}\] Advantages are normalized within each role’s group independently: \[\hat{A}^{\text{ret}}_k = \frac{r^{\text{ret}}_k - \mu_{N}^{\text{ret}}}{\sigma_{N}^{\text{ret}}}, \quad \hat{A}^{\text{gen}}_j = \frac{r^{\text{gen}}_j - \mu_{N}^{\text{gen}}}{\sigma_{N}^{\text{gen}}} \label{eq:advantages}\tag{6}\] Let \(\Phi(o,A;\theta)\) denote the standard per-output GRPO clipped surrogate for a sampled output and its normalized advantage, using the corresponding role-specific importance ratio from Eq. 5 . The role-specific objectives are: \[\begin{align} \mathcal{J}_{\text{ret}} &= \mathbb{E}_{q}\frac{1}{N}\sum_{k=1}^{N} \Phi(o^{\text{ret},(k)}, \hat{A}^{\text{ret}}_k; \theta),\\ \mathcal{J}_{\text{gen}} &= \mathbb{E}_{q}\frac{1}{N}\sum_{j=1}^{N} \Phi(o^{\text{gen},(j)}, \hat{A}^{\text{gen}}_j; \theta). \end{align} \label{eq:dual95role95objectives}\tag{7}\] We use losses \(\mathcal{L}_{\text{ret}}=-\mathcal{J}_{\text{ret}}\) and \(\mathcal{L}_{\text{gen}}=-\mathcal{J}_{\text{gen}}\). At training step \(s\), the generator coefficient \(\lambda_s\in[0,1]\) is linearly increased from 0 to 1: \[\lambda_s = \min\!\left(1,\frac{s-1}{S_\lambda}\right), \label{eq:lambda95schedule}\tag{8}\] where \(S_\lambda\) is the schedule horizon, set to the first 25% of reinforcement-learning steps in our experiments. PCGrad is applied to role gradients to reduce destructive interference between retriever and generator updates: \[g_{\text{ACE}} = \operatorname{PCGrad}\!\left( g_{\text{ret}},\; \lambda_s g_{\text{gen}} \right), \label{eq:pcgrad95update}\tag{9}\] where \(g_{\text{ret}}=\nabla_\theta\mathcal{L}_{\text{ret}}\) and \(g_{\text{gen}}=\nabla_\theta\mathcal{L}_{\text{gen}}\). The retriever contributes with weight 1 throughout training, while the generator contribution is gradually activated. This schedule gives the empirical retriever target time to form before generator gradients receive full weight. In implementation, ACE-SQL computes both role losses at each update and applies one optimizer step with the projected joint gradient \(g_{\text{ACE}}\).

Algorithm 5 in Appendix 7 summarizes the reinforcement learning stage of ACE-SQL, including online rollout, execution verification, empirical target update, sparse reward construction, and the PCGrad-based joint update.

4 Experiments↩︎

4.1 Setup↩︎

4.1.0.1 Benchmarks.

We evaluate on BIRD Dev [28], which contains 1,534 examples over realistic databases, and on Spider [29]. Additional Spider robustness variants, including Spider-DK, Spider-Syn, and Spider-Realistic, are reported in Appendix 9.

4.1.0.2 Training Data.

ACE-SQL uses 14,184 supervised fine-tuning samples and 2,913 reinforcement learning question-database pairs. Data construction details are provided in Appendix 8.

4.1.0.3 Metric.

We report greedy execution accuracy (EX), the percentage of SQL queries generated under greedy decoding whose execution results match the gold SQL. Appendix 10.3 details execution matching and column extraction.

4.1.0.4 Baselines.

We compare with closed-source prompting systems, including DIN-SQL [3], DAIL-SQL [14], MAC-SQL [5], and MCS-SQL [10]. We also compare with open-source Text-to-SQL systems based on base models, supervised fine-tuning, reinforcement learning, and schema-linking modules, including Qwen2.5-Coder [30], Qwen3 [26], CodeS [6], DTS-SQL [7], OmniSQL [16], SQL-R1 [8], MTIR-SQL [24], JOLT-SQL [12], ExSL [11], and BASE-SQL [18]. The cost analysis additionally reports token usage for MAC-SQL, SQL-R1, and MTIR-SQL.

4.1.0.5 Implementation.

We train ACE-SQL with direct joint GRPO, initialized from the SFT Qwen3-8B checkpoint [26]. We set the generator-weight schedule horizon to \(S_\lambda=0.25S_{\text{RL}}\), i.e., the generator coefficient reaches 1 after the first 25% of reinforcement-learning steps. Appendix 10 reports optimization and hardware settings.

4.2 Main Results↩︎

Table 1 presents the main empirical results. Under the greedy decoding setting, ACE-SQL achieves 65.3% execution accuracy on the BIRD development set, outperforming all listed open-source baselines. On Spider, ACE-SQL achieves 87.2% execution accuracy on the test set, while achieving a competitive result of 79.5% on the more challenging Spider-Realistic variant (see Appendix 9). For simpler SQL benchmarks characterized by smaller database scales and cleaner schemas, an explicit retrieval stage may occasionally introduce pruning errors without yielding commensurate gains. Conversely, BIRD is closer to real-world database scenarios with larger, noisier, and more complex schemas and queries, where tight alignment between the retriever and the generator becomes far more critical.

4pt

4.3 Stabilizers Are Necessary for Joint RL Training↩︎

3.5pt

Table 2 isolates the effects of training stages and stabilizers. Supervised fine-tuning raises BIRD Dev from 54.2% to 63.6% and improves retriever ability from 53.1% to 61.5%, providing the necessary cold-start for execution-based reinforcement learning.

The reinforcement learning variants further show why joint optimization requires both stabilizers. Removing PCGrad drops BIRD Dev to 63.2% and reduces both generator and retriever ability, which is consistent with gradient interference between the two role losses (Appendix 12.1) and indicates partial training collapse. Removing the generator-weight schedule still improves over the SFT baseline, but remains below full ACE-SQL. This suggests that, during early training, generator signals can be noisy or even harmful when the generator is optimized under an unstable retriever-defined schema environment. With both stabilizers, ACE-SQL reaches 65.3% BIRD Dev, 72.9% generator ability, and 64.2% retriever ability.

5 Analysis↩︎

5.1 Gold Targets Are Valid But May Be Suboptimal↩︎

As shown in Figure 3 and Figure 4, holding other configurations fixed, using gold columns as the retriever supervision target is a viable training strategy. However, its validation curve shows strong instability and large fluctuations in the early stage, and only begins to generalize clearly on the validation set near the end of training. Its final performance also remains 0.6 points below ACE-SQL.

3.0pt

This indicates that although the gold target is valid, it is not always the best target for the current policy. As the retriever is optimized toward static gold-column selections, the generator is increasingly exposed to a schema distribution that may differ from the executable paths it has learned to use, making early training more brittle. In contrast, execution-based credit assignment turns this one-way dependency into a closed, mutually adaptive loop.

Table 3 supports this on the BIRD Dev hard subset (\(n{=}8\)). ACE-SQL w/ gold target yields the lowest non-gold ratio (32.5%), confirming that static supervision constrains the retriever to annotated routes, yet its hard EX falls 4.1 points behind full ACE-SQL. Moreover, despite the two-stage pipeline inherently limiting column exploration through explicit schema pruning, ACE-SQL still exhibits the highest non-gold ratio (45.1%) among all methods while achieving the highest hard EX. This indicates that empirical credit assignment captures the policy’s own preferred executable routes rather than imposing a fixed annotated path, allowing the model to leverage its learned SQL reasoning patterns for more robust performance.

5.2 Sparse Rewards Perform Better↩︎

We compare two empirical rewards for the retriever: a sparse reward and a dense reward. The sparse reward, defined in Section 3.3.2, is given only when the selected column set exactly matches the empirical target \(S^\star(q)\), while the dense reward assigns a shaped score using continuous soft signals derived from empirical-pool coverage and noise ratio, as detailed in Appendix 11. As shown in Figure 3 and Figure 4, the dense reward improves retriever ability by only +0.8 points, much less than the +2.7 points achieved by the sparse reward, and even degrades the full pipeline by -1.5 points relative to the SFT starting point.

This may be because the dense reward can favor locally reasonable but incomplete column selections, leading to reward hacking. Moreover, in joint optimization, when the generator reward is sparse, the dense retriever reward can more easily produce larger and more frequent gradients, dominate the training direction, and degrade the generation task, as further discussed in Appendix 11.1.

5.3 Cost Analysis↩︎

The two-stage retriever-generator pipeline produces both retrieval and generation outputs, so we report the sum of their average generated output tokens on BIRD Dev as a model-side cost proxy. We compare against Qwen3-8B (base) under the same two-stage prompting setup, and against external baselines including MAC-SQL, SQL-R1-7B, and MTIR-SQL. As shown in Table [tab:cost95lengths], SQL-R1-7B reaches 63.7% BIRD Dev accuracy with 3.10k output tokens, while ACE-SQL reaches 65.3% with 0.93k output tokens.

This comparison indicates that ACE-SQL’s explicit schema-retrieval stage does not rely on longer generations to obtain its gain. Instead, isolating schema retrieval as an explicit stage and restricting the generator context improve both inference efficiency and prediction quality. Relative to SQL-R1-7B, ACE-SQL uses about 70% fewer output tokens while improving BIRD Dev execution accuracy by +1.6 points. Within our own pipeline, reinforcement learning reduces the average generated length from 1.90k tokens after supervised fine-tuning to 0.93k tokens, reflecting the importance of the gated length penalty.

6 Conclusion↩︎

We propose ACE-SQL, a reinforcement learning framework that jointly optimizes schema retrieval and SQL generation through dual-role GRPO with empirical credit assignment. Its core idea is to use execution-correct SQL rollouts as an on-policy basis for assigning credit to explicit schema-retrieval actions, rather than forcing retrieval supervision to follow a single, static gold column set. Joint on-policy training creates bidirectional adaptation, allowing the generator to adapt to the retriever’s evolving schema selections and the retriever to adapt to the generator’s execution-correct outputs. To address the resulting coupling problem, ACE-SQL stabilizes the optimization process with an empirical column-set pool, PCGrad, and a generator-weight schedule. Execution accuracy provides a shared grounding signal that keeps both directions aligned around correct SQL execution. On BIRD Dev, ACE-SQL reaches 65.3% execution accuracy while reducing average output length to 0.93k tokens, suggesting a practical direction for efficient and robust Text-to-SQL systems over complex real-world databases. Moreover, this approach provides an on-policy perspective on general upstream-downstream credit assignment.

Limitations↩︎

Our work has several limitations. First, all experiments use a single 8B-parameter model (Qwen3-8B), and further scaling experiments on larger models and different architectures would better establish generalizability. However, such experiments require substantially more computational resources and are beyond our available compute budget. Second, training data comes exclusively from synthetic SynSQL-2.5M; real-world query-database pairs may reveal different dynamics. Third, the empirical pool is initialized from the supervised checkpoint rather than from the base model. This improves training efficiency and simplifies the pipeline, but may under-explore executable SQL preferences that the base model could express before supervised schema-retrieval adaptation.

7 ACE-SQL Algorithm↩︎

8 Data Construction↩︎

ACE-SQL uses a two-stage training recipe: supervised fine-tuning establishes the explicit retriever\(\to\)generator pipeline, and reinforcement learning then optimizes the same policy with execution-grounded empirical credit.

8.1 Training Data Overview↩︎

8.2 Supervised Fine-Tuning Data↩︎

For supervised fine-tuning, we filter approximately 9,000 question-database pairs from SynSQL-2.5M [15] based on the dataset-provided query-complexity labels and the diversity of the corresponding database schemas. We then apply self-consistency voting (\(n=16\)) with execution-based filtering to produce 14,184 balanced retriever and generator training samples (7,092 per role). Retriever samples provide structured column selections, and generator samples use the corresponding pruned schemas as input. Samples whose downstream SQL execution does not match the gold SQL are discarded.

8.3 Reinforcement Learning Data↩︎

Reinforcement learning uses hard samples from SynSQL-2.5M. We start from the subset of the SFT source data directly labeled as hard in SynSQL, containing 5,637 question-database pairs. Before reinforcement learning, we run an extended rollout with the SFT checkpoint: the retriever samples 8 outputs, their selected columns are unioned into one initialization schema, and the downstream generator samples 16 SQLs under that schema. We retain examples for which between 2 and 14 of the 16 generator rollouts are execution-correct, yielding 2,913 question-database pairs for RL training. The same rollout results initialize a per-question empirical pool. During each RL rollout, retriever samples are aggregated through the majority-voting procedure in Section 3.3.1; generator executions then update the empirical column-set pool with the decay factor \(\gamma = 0.5\), and the decayed pool defines the sparse retriever target \(S^\star(q)\).

9 Additional Benchmark Results↩︎

Table [tab:spider95robustness] reports Spider robustness variants that are omitted from the main table for compactness. We include open-source systems in the 7B to 8B scale with reported values.

10 Training Configuration and Prompts↩︎

10.1 Hyperparameters↩︎

Table 4 summarizes the hyperparameters used in each training stage.

14pt

10.2 Prompt Templates↩︎

We use structured prompts for both the retriever and generator roles. The retriever prompt includes the full database schema (all tables and columns with types) and the natural language question, and instructs the model to output relevant columns in a structured format. The generator prompt includes only the pruned schema (tables and columns selected by the retriever) and the question, and instructs the model to produce SQL within tagged code blocks preceded by reasoning in <think> tags.

Figure 8 shows the rendered prompt templates used in our implementation.

10.3 Execution Matching and Column Extraction↩︎

We use execution matching to evaluate generated SQL queries. We reuse the relatively strict execution function from SQL-R1, which is also trained on SynSQL. During evaluation, we use greedy decoding with one generated SQL per example and apply the execution code associated with the corresponding benchmark. During training rollouts on SynSQL, we use a 30-second execution timeout because the SynSQL databases are relatively small. During evaluation, we use a 3-minute timeout.

For empirical credit assignment, we extract columns from matched SQL queries with SQLGlot. Extracted table and column names are canonicalized through DB-info, which maps SQL mentions back to database table and column identifiers before updating the empirical column-set pool.

11 Reward Design Details↩︎

11.1 Dense Retriever Reward Variant↩︎

We compare ACE-SQL with a dense retrieval reward variant to isolate the effect of sparse empirical credit. This variant is a natural shaped reward over the empirical pool: it gives credit when the selected columns cover any execution-correct route already stored in the pool, and penalizes only columns that never appear in the pool. Let \(\mathcal{B}^q=\{S:f_{\text{pool}}^q(S)>0\}\) be the support of the empirical pool for question \(q\), and let \(U^q=\bigcup_{S\in \mathcal{B}^q}S\) be the union of columns appearing in the pool. The dense variant scores a selected column set by pool coverage minus a noise penalty: \[\begin{align} r_{\text{dense-ret}}(\mathcal{C}) &= \operatorname{coverage}(\mathcal{C}, \mathcal{B}^q)\\ &\quad - 0.5 \cdot \operatorname{noise}(\mathcal{C}, U^q), \end{align}\] where \[\operatorname{coverage}(\mathcal{C}, \mathcal{B}^q) = \max_{S\in \mathcal{B}^q}\frac{|\mathcal{C}\cap S|}{|S|}\] compares the selected set with every column set in the empirical pool and uses the highest coverage ratio. The noise term is \[\operatorname{noise}(\mathcal{C}, U^q) = \frac{|\mathcal{C}\setminus U^q|}{|\mathcal{C}|},\] so only columns completely absent from the pool are counted as noise. The generator reward, PCGrad update, and generator-weight schedule are otherwise unchanged.

Dense retrieval rewards are not uninformative in isolation; they can provide frequent local feedback. The issue is their behavior inside direct joint reinforcement learning with a shared policy. When the retriever reward is dense, the retriever side receives a much more continuous advantage signal than the generator side, whose execution reward is naturally sparse. On difficult samples, this can induce a simple path dependence: the retriever may settle into an intermediate state that looks locally reasonable but is not further refined, while the larger retriever gradients weaken generator learning.

Figure 6 further shows that, under the dense retriever reward variant, the retriever gradient magnitude remains larger than the generator gradient magnitude throughout training. In the early stage, this imbalance is partly caused by the generator-weight schedule, but it remains around 2\(\times\) for much of the middle and late stages. This result shows that reward-density imbalance can induce a persistent gradient-magnitude imbalance between the two roles.

12 Additional Analysis Details↩︎

12.1 Gradient Conflict without PCGrad↩︎

Figure 7 reports the smoothed conflict ratio between retriever and generator gradients before PCGrad projection. The conflict ratio stays high across training, indicating that the two role losses frequently propose incompatible shared-backbone updates. This persistent conflict explains why directly summing the two role gradients can reduce both generator and retriever ability, and why PCGrad is needed to stabilize joint reinforcement learning.

12.2 Impact of Empirical Targets↩︎

The ACE-SQL gold-target baseline in Figure 3 uses the same training data as ACE-SQL and serves as a complementary reference. It optimizes a correct column set, but the retriever still receives sparse updates anchored to a single annotated route. When that route is far from the current policy’s executable path distribution, the optimization trajectory can become less stable and can incur some performance loss even though the target itself is valid. ACE-SQL instead refreshes empirical targets through online rollouts and execution verification, allowing successful non-gold routes to enter the decayed pool that defines retriever supervision.

12.3 Cost Analysis↩︎

For Table [tab:cost95lengths], we use output tokens as the shared cost proxy because the latency and tool-call counts of external methods depend on implementation, hardware, and interaction protocol. Our values are measured as the average total generated output length of each model variant on BIRD Dev. For two-stage variants, this total includes both retriever and generator outputs.

12.4 Case Study↩︎

Figure 9 provides three qualitative examples from BIRD Dev to illustrate why non-gold executable routes can be useful retriever targets. In each case, ACE-SQL uses a column route different from the gold SQL but returns the same execution result under the row- and column-order preserving execution comparison used in our evaluation.

References↩︎