Schema Turn in Multi-turn Text-to-SQL

• Schema Turn is a dynamic concept that defines per-turn decisions over relevant database schemas in multi-turn text-to-SQL interactions.
• Track-SQL integrates a dual-extractive framework with a semantic-enhanced schema extractor and a schema-aware context extractor to refine SQL generation.
• Empirical results show that explicit schema tracking boosts execution accuracy by up to 9.55% on benchmark datasets like SParC and CoSQL.

Searching arXiv for the requested paper and closely related multi-turn Text-to-SQL work. arXiv search query: (Chen et al., 6 Mar 2026) arXiv search query: "Track-SQL Enhancing Generative LLMs with Dual-Extractive Modules for Schema and Context Tracking in Multi-turn Text-to-SQL" Track-SQL is a framework for multi-turn Text-to-SQL that augments generative LLMs with dual-extractive modules for explicit schema and context tracking across dialogue turns. Its central premise is that multi-turn parsing introduces a “schema turn” dimension: at each conversational turn, not only the user intent changes, but the relevant part of the database schema shifts, and may depend heavily on what was referenced earlier. To address the inadequacy of generative LLMs in handling context information and dynamic schema linking in multi-turn interactions, Track-SQL combines a Semantic-enhanced Schema Extractor, a Schema-aware Context Extractor, and a generative SQL model. On the SParC and CoSQL datasets, it is reported to achieve state-of-the-art performance, with detailed ablation studies showing improvements in multi-turn execution accuracy of $7.1\%$ and $9.55\%$, respectively (Chen et al., 6 Mar 2026).

1. Multi-turn Text-to-SQL and the notion of a schema turn

Multi-turn Text-to-SQL differs from single-turn settings because later questions often omit information, rely on pronouns, ellipsis, or refer back to previously discussed entities. In this setting, correct SQL generation requires tracking which tables, columns, and filters are currently in play, rather than treating each query independently. The relevant schema at turn $m$ depends on both the current utterance $\mathcal{Q}_m$ and earlier turns $\mathcal{Q}_{<m}$, so schema linking becomes dynamic rather than static (Chen et al., 6 Mar 2026).

The “schema turn” can be understood as the per-turn decision over which tables, columns, and keys are currently relevant, and how those choices relate to prior schema references through carryover, refinement, or shift. This is especially important for ambiguous or underspecified questions such as “How about in Japan?” or “Which countries do they each have?”, whose interpretation depends on previously established entities and schema items. A plausible implication is that multi-turn Text-to-SQL requires explicit modeling of evolving schema relevance, rather than leaving schema alignment entirely to an end-to-end decoder.

Track-SQL operationalizes this problem by maintaining a turn-by-turn record of schema usage and reusing that record to interpret the current turn. In this formulation, the conversational state is not only linguistic history but also a sequence of schema states.

2. Dual-extractive architecture

Track-SQL decomposes multi-turn Text-to-SQL into a dual-extractive plus generative pipeline. At turn $m$, the framework runs schema extraction over the question history and schema, retrieves the most relevant historical SQL conditioned on schema evolution, and then conditions a fine-tuned decoder-only LLM on both the filtered schema and the retrieved SQL base (Chen et al., 6 Mar 2026).

Component	Role	Output
Semantic-enhanced Schema Extractor (SESE)	Discriminative classifier over schema items	Filtered schema $E(\mathcal{S})$, schema probabilities $\hat{\mathcal{Y}}^m$
Schema-aware Context Extractor (SACE)	Schema-conditioned retrieval of historical question–SQL pairs	$SQL_{base}$
Generative SQL model	Decoder-only LLM fine-tuned with LoRA	Current SQL $s_m$

The architecture is explicitly multi-turn. A History Schema Store keeps per-turn schema item probability distributions $9.55\%$0, and a History Question–SQL Store keeps past question–SQL pairs. At each turn, SESE produces the current schema state, SACE compares that state with prior turns to retrieve a base SQL, and the generator consumes $9.55\%$1, $9.55\%$2, and $9.55\%$3.

This design makes schema usage and context reuse explicit. Rather than presenting the full raw schema and entire dialogue history to the LLM, Track-SQL supplies an updated schema turn view and a curated context turn view.

3. Semantic-enhanced Schema Extractor

At turn $9.55\%$4, SESE takes the concatenated multi-turn question sequence $9.55\%$5, the database schema $9.55\%$6, semantic annotations $9.55\%$7, and historical schema marking. Columns extracted at previous turns are marked with a special token $9.55\%$8, so the model can see which schema items have been active across turns. The input sequence is given as

$9.55\%$9

SESE uses GPT-3.5-generated comments to reduce the semantic gap between short schema names and question phrasing. For each column $m$0, values are sampled and a short descriptive comment $m$1 is generated; for each table $m$2, comments $m$3 are generated from column information. Both $m$4 and $m$5 are fed into RoBERTa, and table- and column-level representations are produced with BiLSTM plus nonlinear FC pooling, yielding embeddings $m$6.

The semantic enhancement stage uses gating-based attention to merge schema-name and comment representations: $m$7

$m$8

and analogously for columns,

$m$9

$\mathcal{Q}_m$0

SESE then predicts table and column probabilities: $\mathcal{Q}_m$1 To handle label imbalance, it uses focal loss: $\mathcal{Q}_m$2

A notable design choice is the treatment of * as a special pseudo-column per table, intended to capture implicit all-columns intent. After thresholding by $\mathcal{Q}_m$3, selected schema items are sorted by probability and serialized with foreign key information to form $\mathcal{Q}_m$4. This filtered schema view is the explicit schema turn state for turn $\mathcal{Q}_m$5, together with the probability distribution $\mathcal{Q}_m$6 (Chen et al., 6 Mar 2026).

4. Schema-aware Context Extractor

If SESE answers which schema is relevant at turn $\mathcal{Q}_m$7, SACE answers which historical question–SQL pair is most relevant given that schema focus. For each history turn $\mathcal{Q}_m$8, SACE uses the current question $\mathcal{Q}_m$9, the historical question $\mathcal{Q}_{<m}$0, and the schema extraction distributions $\mathcal{Q}_{<m}$1 and $\mathcal{Q}_{<m}$2.

Semantic similarity between questions is computed with SentenceBERT: $\mathcal{Q}_{<m}$3 To preserve turns that may be semantically dissimilar but schema-overlapping, SACE also computes a Jensen–Shannon-based similarity between schema distributions. Let

$\mathcal{Q}_{<m}$4

then the JS-based quantity is

$\mathcal{Q}_{<m}$5

and similarity is taken as $\mathcal{Q}_{<m}$6. The overall relevance score is

$\mathcal{Q}_{<m}$7

SACE selects the historical SQL with highest $\mathcal{Q}_{<m}$8 as $\mathcal{Q}_{<m}$9. This base SQL serves as schema-conditioned context, encoding which tables, columns, joins, and filters were actually used for a related intent. The mechanism is retrieval-based rather than additionally trained: it relies on pre-trained SentenceBERT and SESE’s schema probabilities, so context selection becomes explicitly schema-aware without introducing another learned module (Chen et al., 6 Mar 2026).

A plausible implication is that SACE reduces the tendency of dialogue-history encoders to overexpose irrelevant turns. Its relevance computation balances lexical-semantic continuity with continuity of schema usage.

5. Generative model and optimization

Track-SQL fine-tunes decoder-only 7B LLMs, specifically CodeLlama-7B, DeepSeek-7B, and Mistral-7B, using LoRA. For each turn $m$0, the input sequence contains the multi-turn question sequence $m$1, the extracted schema sequence $m$2, and the base SQL $m$3, which is empty for the first turn. Schema serialization follows the format Table : Column1, Column2 | Table2 : Column3, ..., ordered so that more relevant tables and columns appear earlier.

The training objective is sequence-level cross-entropy: $m$4 corresponding conceptually to

$m$5

Training is two-stage rather than fully joint. SESE is trained first as a multi-label classifier with AdamW, then its outputs are used to build inputs for generator fine-tuning. The LoRA configuration is rank $m$6, alpha $m$7, dropout $m$8. This two-stage design is described as helping stabilize training and supporting explainability (Chen et al., 6 Mar 2026).

The role of conditioning is narrow and explicit. $m$9 reduces schema redundancy and constrains schema search, while $E(\mathcal{S})$0 supplies an editable prior query structure. This suggests that Track-SQL treats SQL generation less as unconstrained synthesis and more as schema- and context-conditioned refinement over a reduced hypothesis space.

6. Empirical results, ablations, and position within schema-centric Text-to-SQL

On the SParC and CoSQL development sets, Track-SQL with 7B models is reported to outperform both in-context and fine-tuned baselines. Under DeepSeek 7B, the reported results are:

• SParC: QM-EX $E(\mathcal{S})$1; IM-EX $E(\mathcal{S})$2
• CoSQL: QM-EX $E(\mathcal{S})$3; IM-EX $E(\mathcal{S})$4

The gains in multi-turn execution accuracy are $E(\mathcal{S})$5 on SParC and $E(\mathcal{S})$6 on CoSQL (Chen et al., 6 Mar 2026). Because execution accuracy measures whether the predicted SQL produces the correct result regardless of minor syntactic differences, these gains indicate improvements in table and column selection, joins, filters, and handling of cross-turn dependencies.

Ablation results isolate the two extractive modules. Removing SESE causes marked drops, including on CoSQL dev from QM-EX $E(\mathcal{S})$7 to $E(\mathcal{S})$8 and from IM-EX $E(\mathcal{S})$9 to $\hat{\mathcal{Y}}^m$0. Redundancy scores also worsen when SESE’s semantic enhancement is removed: on CoSQL, $\hat{\mathcal{Y}}^m$1 rises from $\hat{\mathcal{Y}}^m$2 to $\hat{\mathcal{Y}}^m$3, and $\hat{\mathcal{Y}}^m$4 rises from $\hat{\mathcal{Y}}^m$5 to $\hat{\mathcal{Y}}^m$6. Removing SACE also harms multi-turn performance, for example on SParC IM-EX $\hat{\mathcal{Y}}^m$7 and on CoSQL IM-EX $\hat{\mathcal{Y}}^m$8. Removing both SESE and SACE yields the full IM-EX drops of $\hat{\mathcal{Y}}^m$9 on SParC and $SQL_{base}$0 on CoSQL, which the paper identifies as the core contribution of schema-and-context turn tracking (Chen et al., 6 Mar 2026).

The framework is positioned against prior multi-turn Text-to-SQL systems that emphasize previous SQL editing or similarity, including EditSQL, CoE-SQL, STaR, and R2SQL, and against systems that emphasize relational encodings and coreference, including RASAT, TP-Link, MIGA, and HIE-SQL. The distinction drawn is that Track-SQL explicitly decouples schema linking and context selection while maintaining per-turn schema distributions (Chen et al., 6 Mar 2026). Within the broader schema-centric literature, RSL-SQL emphasizes robust schema linking with bidirectional schema linking, contextual information augmentation, binary selection, and multi-turn self-correction (Cao et al., 2024); Schema-R1 treats schema linking as a reasoning task trained with reinforcement learning and reports a $SQL_{base}$1 improvement in filter accuracy (Wen et al., 13 Jun 2025); and TRUST-SQL addresses the unknown-schema setting with a four-phase protocol—Explore, Propose, Generate, Confirm—and Dual-Track GRPO (Jian et al., 17 Mar 2026). This suggests that Track-SQL occupies a distinct position: it is centered on the evolving schema subset and context state of a multi-turn interaction, rather than on single-turn schema pruning or tool-mediated schema discovery.

The implementation is reported to be open-sourced at https://github.com/DMIRLAB-Group/Track-SQL (Chen et al., 6 Mar 2026). Inference-time figures reported in the detailed description are approximately $SQL_{base}$2s/sample for SESE and $SQL_{base}$3s/sample for the SQL generator, with inference feasible on 24GB GPUs using approximately $SQL_{base}$4GB for SESE and $SQL_{base}$5GB for the 7B LLM. These practical details reinforce the framework’s role as a modular mechanism for explicit schema turn modeling in multi-turn Text-to-SQL rather than a purely conceptual reformulation.