Source-linked AI summary
Text-to-SQL as Dual-State Reasoning: Integrating Adaptive Context and Progressive Generation
Zhifeng Hao, Qibin Song, Ruichu Cai, Boyan Xu
TL;DR
Existing Text-to-SQL benchmarks such as Spider capture only moderate schema complexity and fail to reflect enterprise-scale realities. DSR-SQL couples schema refinement and adaptive selection with progressive SQL generation guided by execution feedback. Without post-training or in-context examples, DSR-SQL achieves strong zero-shot performance on Spider 2.0-Snow and BIRD and can match or surpass methods requiring additional supervision.
Problem
Existing Text-to-SQL benchmarks such as Spider capture only moderate schema complexity and fail to reflect enterprise-scale realities.
Source: §1 · p. 1Method
DSR-SQL couples schema refinement and adaptive selection with progressive SQL generation guided by execution feedback.
Source: §1 · p. 2, §3.3 · pp. 4–5Results
Takeaways & Limitations
The findings suggest that balancing external context management and internal reasoning-state evolution can be an effective path toward more reliable structured reasoning.
Source: §5 · p. 8DSR-SQL still lags behind some techniques that use post-training, in-context examples, or multi-path generation.
Source: Limitations · pp. 8–9
Abstract
from arXiv · showhide
Recent divide-and-conquer reasoning approaches, particularly those based on Chain-of-Thought (CoT), have substantially improved the Text-to-SQL capabilities of Large Language Models (LLMs). However, when applied to complex enterprise databases, such methods struggle to maintain coherent reasoning due to limited context capacity, unreliable schema linking, and weak grounding in database semantics. To overcome these issues, we introduce DSR-SQL, a \textbf{D}ual-\textbf{S}tate \textbf{R}easoning framework that models Text-to-SQL as an interaction between an adaptive context state and a progressive generation state. The first constructs a compact, semantically faithful environment by refining large schemas and selecting relevant structures, while the second formalizes SQL synthesis as feedback-guided state transitions, enabling the model to self-correct and align with user intent. Without any post-training or in-context examples, DSR-SQL achieves competitive performance, reaching 35.28\% execution accuracy on Spider 2.0-Snow and 68.32\% on BIRD development set. Our implementation will be open-sourced at: https://github.com/DMIRLAB-Group/DSR-SQL.
1 Introduction
Enterprise Text-to-SQL must align user language with large, heterogeneous schemas, but existing methods struggle to do so within limited context. DSR-SQL couples adaptive context construction with feedback-guided SQL generation.
1 Introduction
- The framework is presented as a response to one-way approaches in which context and generation states evolve independently, preventing effective correction or adaptation.The proposed paradigm lets the two states interact dynamically through feedback.Source: §1 · pp. 1–2
- Static CoT decomposition can split a question linguistically yet remain unaware of the true schema, leading to execution failure.Figure 1 contrasts this with DSR-SQL revising intermediate states and probing the database when mismatches occur.Source: §1 · p. 1, Figure 1 · p. 2
- DSR-SQL treats Text-to-SQL as an interaction between adaptive context and progressive generation, refining schema fragments and evolving partial SQL from execution signals.Its two reasoning loops co-evolve to support query–schema alignment under enterprise-scale complexity.Source: §1 · p. 2
- In a zero-shot setting without post-training or in-context examples, DSR-SQL achieves strong execution accuracy on Spider 2.0-Snow and BIRD and can match or surpass methods requiring additional supervision.The framework is motivated by the challenge of maintaining accurate query–schema alignment as schema size and domain heterogeneity grow.Source: §1 · pp. 1–2
2 Related Work
Prior Text-to-SQL work addresses complex schemas through schema compression or retrieval and through static question decomposition. These approaches can lose relevant schema information or remain detached from database content, while DSR-SQL integrates feedback into iterative generation.
2 Related Work
- Some zero-shot methods use execution feedback only to validate or optimize complete SQL candidates, whereas DSR-SQL integrates feedback into iterative generation to explore database structure and align intent with database semantics.The cited post-hoc feedback approaches include Pourreza and Rafiei (2023), Xie et al. (2024), and Lee et al. (2024); Qu et al. (2025) is cited for the shared limitation.Source: §2 · p. 3
3 Method
DSR-SQL constructs a compact, question-relevant context and evolves partial SQL through execution feedback. Its method combines schema refinement, adaptive selection, semantic alignment, and iterative generation.
3.1 Problem Formulation
- DSR-SQL formalizes Text-to-SQL as alternating context construction and generation evolution under context-length constraints.The context state contains visible schema and knowledge; the generation state contains a partial query and its execution feedback.Source: §3 · p. 3, §3.1 · p. 3
3.2.1 Schema and Knowledge Refinement
- Schema and knowledge refinement consolidate structurally equivalent tables, prune consistently null or uninformative columns, and summarize question-relevant external knowledge.For example, versioned tables with nearly identical column layouts are represented by a canonical table and an annotation; knowledge summaries retain details such as units, enumerations, or temporal ranges.Source: §3.2.1 · p. 3
3.2.2 Adaptive Schema Selection
- Most refined M-schemas fall below 128K tokens, and adaptive selection reduces most per-query schemas to under 32K tokens.Figure 3 compares original schema size, size after refinement, and average per-query size after adaptive selection.Source: §3.2.1 · p. 3, Figure 3 · p. 4, §3.2.2 · p. 4
- Adaptive schema selection uses global exploration when the refined schema fits the context limit and partitioned exploration when larger databases exceed it.Global exploration retains tables appearing in high-confidence candidate SQL structures; partitioned exploration evaluates tables independently with query–table similarity prompts.Source: §3.2.2 · pp. 3–4
3.2.3 Schema-aware Alignment
- Schema-aware alignment probes selected tables with simple queries, then summarizes observed values and relationships into semantic cues for generation.The probes can reveal frequent values, ranges, and join patterns; the resulting alignment prior can capture enumerations, units, and synonyms.Source: §3.2.3 · p. 4
3.3 Generation-State Evolution
- Generation-state evolution updates a partial SQL query using execution feedback and prepared context, extending, revising, exploring, or finalizing according to the feedback.Unexpected or empty outputs prompt exploratory queries, while semantic or logical inconsistencies prompt revision; the process ends when sub-goals are resolved and outcomes align with user intent.Source: §3.3 · pp. 4–5
4 Experiments
Experiments evaluate DSR-SQL on Spider 2.0-Snow and BIRD, reporting zero-shot benchmark results and analyses of its component modules. The results cover benchmark setup, module contributions, schema selection, alignment, and generation-state evolution.
4.1 Benchmarks
- The evaluation uses Spider 2.0-Snow, which requires Snowflake-dialect SQL, and BIRD, which emphasizes fine-grained schema details and typographical errors in questions.Spider 2.0 databases average approximately 800 columns.Source: §4.1 · p. 5
4.2 Evaluation Metrics
- Execution Accuracy is the core metric, but BIRD requires exact result and column-order matches whereas Spider 2.0-Snow permits extra columns and ignores their order.Snow evaluation requires the returned results to contain the gold answer’s core information.Source: §4.2 · p. 5
4.3 Implementation Details
- Experiments use DeepSeek and Qwen models at temperature 0.2 by default, with up to 20 GSE iterations for Snow and 10 for BIRD.All methods receive a query-correction loop of up to five iterations for minor syntax errors.Source: §4.3 · p. 5
4.4 Comparison Results
- 35.28% EX with DS-R1 on Spider 2.0-Snow is 6.03% above ReFORCE’s 8-path voting; BIRD accuracies are 68.32% with DS-V3.1 and 65.58% with Qwen3-30B.The BIRD results surpass existing zero-shot methods and are comparable to or exceed most methods using post-training or in-context examples.Source: §4.4 · pp. 5–6, Table 1 · p. 6, Table 2 · p. 7
4.5.1 Overall Ablation Study
- Removing any DSR-SQL module causes a performance drop; the authors describe SKR as foundational and ASS and SAA as crucial to selecting and grounding relevant structures.GSE uses the resulting context state to align user intent with the database through feedback-guided transitions.Source: §4.5.1 · p. 6, Table 3 · p. 7
4.5.2 Analysis of Adaptive Schema Selection
- ASS reaches 91.13% recall on Snow versus ReFoRCE’s 62.59%, using 34.35K versus 23.23K tokens but reducing average LLM calls from 13.29 to 6.06.On BIRD, ASS achieves over 98% recall with both tested models.Source: §4.5.2 · p. 6, Table 4 · p. 8
4.5.3 Analysis of Schema-aware Alignment
- Removing SAA drops performance by approximately 3.5%; raw Exploration result pairs without summarization underperform, while summarization without grounded Exploration context can be detrimental.Even divide-and-conquer improves when augmented with SAA.Source: §4.5.3 · pp. 6–7, Table 5 · p. 8
4.5.4 Analysis of Generation-State Evolution
- Dynamic generation improves performance over static divide-and-conquer by approximately 7.49% on Spider 2-Snow and also performs better on BIRD development queries.Across generation paths, DSR-SQL’s largest relative accuracy gains are on Exploratory paths: 14.95% on Snow and 20.64% on BIRD.Source: §4.5.4 · pp. 7–8, Table 6 · p. 8, Figure 4 · p. 8
5 Conclusions
DSR-SQL models Text-to-SQL as interaction between adaptive context and progressive generation states. Experiments on Spider 2.0-Snow and BIRD show strong zero-shot performance without post-training or in-context examples.
5 Conclusions
- DSR-SQL models Text-to-SQL as interaction between an adaptive context state and a progressive generation state.The authors suggest balancing external context management and internal reasoning-state evolution as a path toward more reliable structured reasoning.Source: §5 · p. 8
Limitations
The conclusion identifies a performance gap against some methods that use additional supervision or multi-path generation.
Limitations
- DSR-SQL still lags behind certain techniques using post-training, in-context examples, or multi-path generation.Addressing this disparity is identified as future work.Source: Limitations · pp. 8–9
A Table description generation
The appendix describes generating concise descriptions for structurally equivalent tables and details modifications to the M-Schema representation.
A Table description generation
- For structurally equivalent tables, an LLM receives table names and column descriptions and generates a concise table description.The appendix points to Figure 5 for an example.Source: A Table description generation · p. 10, Figure 5 · p. 10
B M-Schema
- The modified M-Schema deduplicates column value examples, randomly selects up to three, truncates each to 50 characters, and adds a Table Description field for compressed tables.M-Schema also includes value examples and column descriptions.Source: B M-Schema · p. 10
C Example of Different Generation-State Evolution Paths
This section contrasts generation paths, describes the divide-and-conquer baseline, and outlines the Adaptive Schema Selection and Generation-State Evolution algorithms.
C Example of Different Generation-State Evolution Paths
- The Optimal Path reaches the correct answer in one step using an INNER JOIN’s implicit null-value filtering, whereas the Circuitous Path takes multiple steps.The comparison highlights Schema-aware Alignment’s role in guiding more direct reasoning.Source: C Example of Different… · pp. 10–11
D divide-and-conquer Baseline
- For Spider 2.0-Snow, the baseline uses DeepSeek R1 without few-shot examples and prompts sub-question → sub-SQL → final SQL decomposition.For BIRD, it uses a CoT strategy similar to Pourreza et al. (2024), with fixed few-shot examples.Source: D divide-and-conquer Baseline · p. 11
E Adaptive Schema Selection Algorithm
- Adaptive Schema Selection takes a question, refined schema and knowledge, an LLM, sample count, and threshold, and returns a question-relevant schema subset.The section presents the algorithm as pseudocode.Source: E Adaptive Schema Selection Algorithm · p. 11
F Generation-State Evolution
- Generation-State Evolution takes context containing the question, selected schema, refined knowledge, and alignment knowledge, and produces a final SQL query.The section presents this process as an algorithm.Source: F Generation-State Evolution · p. 12
G Compared Baselines
The paper compares DSR-SQL against benchmark-specific baseline methods and reevaluates several baselines in a unified environment.
G Compared Baselines
- Spider 2.0-Snow comparisons use Spider-Agent and ReFoRCE, while BIRD comparisons span hybrid, post-training, in-context learning, and zero-shot methods.Several baselines were reevaluated using their open-source implementations under a unified model and experimental environment.Source: G Compared Baselines · pp. 12–13
H Error Analyses
The error analysis manually examines 70 incorrect predictions among 121 Spider 2.0-Snow samples with gold SQL, categorizing errors while noting that failures can cascade. Two case studies illustrate revision after feedback and progressive discovery of database semantics.
H Error Analyses
- The manual error analysis covers 70 incorrect predictions from 121 samples with gold SQL, and the authors qualify its generalizability given the limited sample size.They propose continued work on context management, domain-knowledge alignment, and adaptation to SQL dialects.Source: H Error Analyses · pp. 13, 16
- 27.11% of errors were Logical Construction Errors, the most prevalent category; these involve partially understood intent but flawed SQL logic.The analysis classifies errors into five major categories and records multiple types in a case when causes cascade.Source: H Error Analyses · p. 13
- Other reported logic failures include aggregation, filtering, operation order, joins, and sorting; complex scenarios involve multi-step reasoning or complex business logic.Examples include incorrect aggregation or constraints, wrong calculation order, and incorrect join implementation.Source: H Error Analyses · pp. 13–14
- Intent Misunderstanding accounted for approximately 26.22% of errors, while Schema Linking Errors involve mapping natural language to database elements incorrectly.The five categories also include Complex Scenario Failure, Data Processing Error, and Logical Construction Error.Source: H Error Analyses · pp. 13–15
- The analysis also identifies concept and language mismatches, missed complex logic, ignored constraints, correction failures, multi-hop failures, and hard-coding of intermediate results.Hard-coding partial results from an earlier step undermines query generalizability.Source: H Error Analyses · pp. 14–15
- Schema-linking and data-processing subtypes include field mapping, wrong data sources, join paths, complex data types, function use, data types, regex, and numeric conversion.The analysis also identifies time-series errors involving temporal continuity, dependencies, and window calculations.Source: H Error Analyses · p. 15
I Case Study: Leveraging ’Revise’ Actions for Feedback-Driven Correction
- In the revision case, execution feedback prompted the model to expand its calculation from Active Accounts to All Accounts, correctly capturing single-transaction surges.The authors call this feedback-driven correction process a Refinement Path.Source: I Case Study: Leveraging ’Revise’… · p. 16
J Case Study: How Execution Feedback Drives Problem Solving
- In the problem-solving case, an empty result led to exploration of where “strategy” was stored, followed by discovery of its database representation and semantic alignment.The model then proceeded to final generation after gathering the needed context.Source: J Case Study: How Execution Feedback… · p. 16
K Other results
The paper reports results under both versions of the revised Spider 2.0 evaluation script and includes a Spider 2.0-Lite ranking; it also discloses LLM use during development and manuscript preparation.
K Other results
- The Spider 2.0 evaluation script changed after submission, potentially making reported scores inconsistent; the paper reports results under both script versions.It also reports a third-place ranking on Spider 2.0-Lite at submission time.Source: K Other results · p. 16, Table 7 · p. 16
L Disclosure of Large Language Model Usage
- An LLM assisted with utility-function code generation and manuscript grammar polishing; the authors reviewed and verified the generated content.The authors unanimously consent to its inclusion.Source: L Disclosure of Large Language Model… · p. 16