Source-linked AI summary
CodeS: Towards Building Open-source Language Models for Text-to-SQL
Haoyang Li, Jing Zhang, Hanbing Liu, Ju Fan, Xiaokang Zhang, Jun Zhu, Renjie Wei, Hongyan Pan, Cuiping Li, Hong Chen
TL;DR
Most leading text-to-SQL approaches rely on closed-source language models. CodeS uses SQL-centric incremental pre-training, prompt construction, and bidirectional data augmentation; the authors report new state-of-the-art performance on nearly all challenging text-to-SQL benchmarks.
Problem
Most state-of-the-art text-to-SQL approaches rely on closed-source LLMs, whose architectures and training details are hidden and whose API use raises data-privacy and inference-cost concerns.
Source: §1 · pp. 1–2Method
CodeS combines incremental pre-training on a curated SQL-related corpus with comprehensive database prompting and bidirectional data augmentation for adaptation to new domains.
Source: §1 · pp. 2–3Results
CodeS achieves new state-of-the-art performance on nearly all challenging text-to-SQL benchmarks and is reported to be 10x–100x smaller than existing SOTA LLMs.
Source: §1 · p. 2Takeaways & Limitations
Users can select an open-source CodeS model sized to their computational resources for building text-to-SQL applications.
Source: §1 · p. 2The best model, SFT CodeS-15B, requires at least 35GB of GPU memory for inference.
Source: §9.1.2 · p. 9
Abstract
from arXiv · showhide
Language models have shown promising performance on the task of translating natural language questions into SQL queries (Text-to-SQL). However, most of the state-of-the-art (SOTA) approaches rely on powerful yet closed-source large language models (LLMs), such as ChatGPT and GPT-4, which may have the limitations of unclear model architectures, data privacy risks, and expensive inference overheads. To address the limitations, we introduce CodeS, a series of pre-trained language models with parameters ranging from 1B to 15B, specifically designed for the text-to-SQL task. CodeS is a fully open-source language model, which achieves superior accuracy with much smaller parameter sizes. This paper studies the research challenges in building CodeS. To enhance the SQL generation abilities of CodeS, we adopt an incremental pre-training approach using a specifically curated SQL-centric corpus. Based on this, we address the challenges of schema linking and rapid domain adaptation through strategic prompt construction and a bi-directional data augmentation technique. We conduct comprehensive evaluations on multiple datasets, including the widely used Spider benchmark, the newly released BIRD benchmark, robustness-diagnostic benchmarks such as Spider-DK, Spider-Syn, Spider-Realistic, and Dr.Spider, as well as two real-world datasets created for financial and academic applications. The experimental results show that our CodeS achieves new SOTA accuracy and robustness on nearly all challenging text-to-SQL benchmarks.
1 INTRODUCTION
CodeS is an open-source model family designed for text-to-SQL, addressing reliance on closed-source LLMs with incremental pre-training, schema-aware prompts, and data augmentation for new domains.
Evaluation
- 10x-100x smaller than existing SOTA LLMs, CodeS achieves comparable or superior accuracy and new SOTA results on nearly all challenging text-to-SQL benchmarks, including Spider and BIRD.The comparison is presented in Figure 1; the paper also reports new SOTA performance on nearly all challenging benchmarks.Source: Figure 1 · p. 2, §1 · pp. 2–3
CodeS model
- CodeS is a fully open-source, StarCoder-based model family spanning 1B to 15B parameters, addressing closed-source opacity, privacy risks, and inference overheads.The paper notes that closed-source models hide architecture and training details, require data to be sent to providers, and can incur API costs due to their size.Source: §1 · pp. 1–2
C1: Small-model reasoning
- Incremental pre-training on a curated 21.5GB corpus aims to strengthen SQL generation and natural-language understanding in smaller models.The corpus comprises 11GB of SQL-related data, 6GB of NL-to-code data, and 4.5GB of NL-related data.Source: §1 · pp. 2–3
C2: Schema linking
- To improve schema linking, CodeS prompts filter irrelevant tables and columns, clarify ambiguous names with comments, and retrieve large-table values in a coarse-to-fine process.Value retrieval first uses BM25 and then refines matches with the longest common substring algorithm.Source: §1 · pp. 2–3
C3: Domain adaptation
- For new-domain adaptation with few labeled examples, CodeS combines manually annotated real queries expanded with GPT-3.5 and synthetic question-SQL pairs generated from benchmark templates.The templates are populated with tables, columns, and values from the target databases.Source: §1 · pp. 2–3
Evaluation
- Evaluation covers Spider, BIRD, four Spider variants spanning 20 test sets, and academic and finance datasets for domain adaptation.The paper characterizes BIRD as having more complex questions, ambiguous schemas, and large, dirty database values.Source: §1 · p. 2
2 RELATED WORK
The related work surveys supervised fine-tuning, prompting, code language models, schema linking, and data augmentation for text-to-SQL. CodeS differs by directly optimizing open-source models for SQL generation and by proposing bi-directional data augmentation.
Supervised Fine-Tuning-Based Text-to-SQL
- Earlier systems enhanced encoder representations with graph relations [5] [67] or constrained decoder outputs with SQL grammar [57], while database-pretraining studies [13] [27] [59] primarily improved question/schema representation rather than directly SQL-generation capability.Sequence-to-sequence text-to-SQL uses natural-language questions and flattened database information as input, with target SQL as output; T5 [53] and BART [34] are fine-tuned on these pairs.Source: §2 · p. 3
Prompting-Based Text-to-SQL
- Prompting methods achieve SOTA text-to-SQL performance with few-shot examples or task decomposition, but API costs and privacy concerns hinder real-world use.SQL-PaLM [61] and Self-Debugging [9] use few-shot demonstrations; DIN-SQL [51] decomposes the task, while C3 [16] uses instructions for zero-shot parsing.Source: §2 · pp. 3–4
Code Language Models
- Because broad programming-language training can limit small models on SQL, CodeS emphasizes SQL-centric data in open-source generative language models.Existing code models commonly train on diverse languages, including SQL, while CodeS is optimized around a mixture of SQL-centric data.Source: §2 · p. 4
Schema Linking
- Schema linking uses string matching [4] [17] [26] [67] or neural methods [2] [25] [36] to identify relevant schemas and values, with RESDSQL [36] pruning less relevant schemas.String matching can miss synonyms; other methods feed matching results into the text-to-SQL model, whereas RESDSQL uses them to shorten its input.Source: §2 · p. 4
Data Augmentation for Text-to-SQL
- Most data-augmentation methods synthesize SQL-to-question pairs [68] [83], but their questions may differ from real users’ language; CodeS adds question-to-SQL synthesis.The proposed bi-directional strategy combines both synthesis directions to better generate the variety of questions real-world users might ask.Source: §2 · p. 4
3 PRELIMINARIES
The preliminaries define text-to-SQL as generating executable SQL from a question and database, then distinguish language-model pretraining, supervised fine-tuning, and prompt-based in-context learning.
Text-to-SQL Task
- Text-to-SQL generates an executable SQL query from a natural-language question and database, with the parser using schema and metadata such as column types, values, and key relations.The database includes tables, columns, comments, primary keys, and foreign-key relations.Source: §3 · p. 4
Pre-trained Language Models
- Pre-trained language models typically learn from extensive text using next-word prediction or masked-span reconstruction, with Transformer models underpinning much of this work [66].GPT, PaLM [10], and LLaMa [64] exemplify language modeling; BERT, RoBERTa [43], and T5 [53] exemplify masked language modeling.Source: §3 · p. 4
4 OVERVIEW
CodeS combines SQL-focused incremental pre-training, question-aware database prompts, and bidirectional domain adaptation, with fine-tuning or few-shot inference depending on available training data.
Incremental Pre-training
- CodeS is incrementally pre-trained from StarCoder on a corpus of 11GB SQL-related, 6GB NL-to-code, and 4.5GB NL-related data, producing 1B, 3B, 7B, and 15B models.Figure 3 depicts the pre-training framework and the two CodeS usage modes.Source: §4 · p. 4, Figure 3 · p. 5
Database Prompt Construction
- Database prompts combine question-based filtering of irrelevant tables and columns with retrieval of useful values and metadata, including types, comments, representative values, and key relationships.The schema filter and value retriever construct richer context for text-to-SQL models.Source: §4 · p. 4
New Domain Adaptation
- Bidirectional augmentation creates new-domain (question, SQL) pairs by expanding labeled questions with GPT-3.5 and generating refined questions from schema-filled benchmark templates.The approach is intended to ease new-domain fine-tuning with minimal annotation.Source: §4 · pp. 4–5
The Usage of CodeS
- With abundant labeled data, CodeS can be fine-tuned; with limited data, it can use few-shot in-context learning with demonstrations retrieved by question and pattern similarity.Figure 3 presents these as the supervised fine-tuning and direct inference paths.Source: §4 · p. 5, Figure 3 · p. 5
Complexity Discussion
- Incremental pre-training and domain adaptation run offline once, while prompt construction runs online per query; BM25 indexing accelerates value retrieval.Schema filtering uses a compact neural network for fast inference.Source: §4 · p. 5
5 INCREMENTAL PRE-TRAINING
CodeS incrementally pre-trains StarCoder on SQL, natural-language, and natural-language-to-code data, using a curated corpus and language-modeling objective. The section details the corpus composition and training setup.
5.1 Pre-training Corpus
- The corpus combines 11GB of SQL data with 4.5GB of natural-language dialogue from Alpaca-cleaned, Unnatural-instructions, and UltraChat.The SQL data uses the SQL segment of StarCoder’s pre-training corpus [39]. Alpaca-cleaned uses self-instruct [69], Unnatural-instructions is an instruction-following dataset [28], and UltraChat is a multi-turn dialogue dataset produced using two GPT-3.5 APIs [15].Source: §5.1 · pp. 5–6
- The 6GB natural-language-to-code mix includes CoNaLa, StaQC, CodeAlpaca-20k, Jupyter-structured-clean-dedup, and the new NL-SQL-458K dataset.NL-SQL-458K contains 458K SQL queries extracted from The Pile [22], The Stack [31], and GitHub Code, filtered for syntax errors; GPT-3.5 generated questions using eight paired SQL-question demonstrations.Source: §5.1 · p. 6
5.2 Pre-Training Details
- CodeS incrementally pre-trains StarCoder for two epochs on SQL data and one epoch each on natural-language and natural-language-to-code data.CodeS-15B uses StarCoder-15B, while CodeS-1B, 3B, and 7B use the corresponding StarCoderBase models; training maximizes the likelihood of each token in a sequence.Source: §5.2 · p. 6
- Training uses AdamW, a 5e-5 learning rate, cosine decay, 4M-token batches, gradient clipping at 1.0, DeepSpeed ZeRO-3, and BF16 precision.FlashAttention-2 supports extended contexts, capped at 8,192 tokens for CodeS-1B/3B/7B and 6,144 for CodeS-15B; corpus pre-training takes approximately 1.5, 3, 8, and 16 days, respectively.Source: §5.2 · p. 6
6 DATABASE PROMPT CONSTRUCTION
CodeS constructs database prompts with a schema filter, a coarse-to-fine value retriever, and metadata intended to help models link schemas and generate accurate SQL. The section describes how each component selects or represents useful database information.
6 DATABASE PROMPT CONSTRUCTION
- The prompt construction combines a schema filter, value retriever, and database metadata; Algorithm 1 presents the construction process.These strategies aim to provide useful database context while keeping prompts focused.Source: §6 · p. 6, §6.3 · p. 7
6.1 Schema Filter
- To limit prompt length without losing relevant schema, the filter scores tables and columns, retaining the top topk1 tables and top topk2 columns per table.For training samples, it uses ground-truth SQL to identify used schema items, then randomly pads tables and columns when needed to match the retained counts; the filter also alleviates schema-linking pressure.Source: §6.1 · pp. 6–7
6.2 Value Retriever
- Approximately 116.5 million valid values in the BIRD Donor database motivate a coarse-to-fine retriever: BM25 indexes shortlist hundreds of values before LCS matching.The index reduces LCS calls from potentially millions to hundreds; LCS has O(f*u) time complexity for input strings of lengths f and u. Prior work [36] [37] [57] uses LCS to calculate value-question matching.Source: §6.2 · p. 7
6.3 Database Metadata
- Column data types clarify permissible operations, while schema comments help resolve ambiguous table and column meanings for the classifier and database prompt.For example, arithmetic on string-stored data requires CAST; comments support more accurate schema linking.Source: §6.3 · p. 7
- Two distinct non-null values per column are extracted as representative values to convey details such as allowed gender values and date formats.The method uses SELECT DISTINCT {COLUMN} FROM {TABLE} WHERE {COLUMN} IS NOT NULL LIMIT 2, drawing inspiration from [6].Source: §6.3 · p. 7
- Primary-key identifiers and explicit foreign-key equalities supply join relationships; a Spider prompt example shows an extracted reviewer name and keys guiding JOIN ON generation.Figure 4 illustrates the sample prompt, where the question-matched value is Sarah Martinez from reviewer.name.Source: §6.3 · p. 7, Figure 4 · p. 8
7 NEW DOMAIN ADAPTION
To adapt text-to-SQL models to new domains with little labeled data, the section proposes bidirectional augmentation to generate authentic and general question–SQL pairs at minimal annotation cost.
7 NEW DOMAIN ADAPTION
- The technique targets real-world databases where developing text-to-SQL models is difficult because labeled training data is scarce.It aims to generate large sets of authentic and general question–SQL pairs with minimal annotation costs.Source: §7 · p. 8
Question-to-SQL Augmentation
- Question-to-SQL augmentation starts from a few representative user questions and manually labeled SQL queries, then uses GPT-3.5 to synthesize intent-aligned questions and corresponding SQL.Shuffling seed questions and using high-temperature generation promotes question diversity; the small seed set keeps annotation effort minimal.Source: §7 · p. 8
SQL-to-Question Augmentation
- SQL-to-Question augmentation fills 75 Spider-derived SQL templates with a new database schema, then uses GPT-3.5 and manually crafted refinement examples to make templated questions more natural.The resulting refined questions remain paired with their templated SQL.Source: §7 · p. 8
8 USAGE OF CODES
CodeS supports supervised fine-tuning and few-shot in-context learning, with database schemas converted into prompts before model use. Fine-tuning predicts SQL from the combined database prompt and question; few-shot learning retrieves demonstrations for the test question.
8 USAGE OF CODES
- Database prompts represent each training database and pair with its question, while each test input pairs the prompt with the test question.This conversion precedes CodeS usage.Source: §8 · p. 8
8.1 Supervised Fine-Tuning
- With substantial training data, supervised fine-tuning adapts CodeS to the data distribution by predicting SQL from the database prompt and question.The fine-tuned model generates SQL from the same combined inputs at test time.Source: §8.1 · pp. 8–9
8.2 Few-shot In-Context Learning
- When fine-tuning is impractical, CodeS can use few-shot learning with demonstrations retrieved by question patterns rather than entity overlap.The retriever removes entities with NLTK and computes pattern similarity with SimCSE [23]; selected examples are merged with the test sample as model input.Source: §8.2 · p. 9
9 EXPERIMENTS · 9.1 Experimental Setup
The experimental setup evaluates CodeS across standard, robustness, and domain-specific text-to-SQL datasets using benchmark-appropriate metrics and both few-shot and supervised fine-tuning settings. It also specifies the classifier, generation, and baseline procedures used in evaluation.
9.1.1 Datasets.
- Spider and BIRD anchor evaluation, with Spider-family variants and Dr.Spider testing robustness and Bank-Financials and Aminer-Simplified extending evaluation to financial and academic domains.Spider is evaluated on its public development set because the submission platform cannot run the 35GB-minimum SFT CodeS-15B model; BIRD evaluation uses its hidden test set and includes settings with and without external knowledge.Source: §9.1.1 · p. 9, §9.1.2 · p. 9
- Bank-Financials and Aminer-Simplified training sets contain 4,901 and 5,427 samples, respectively, and each derives from 30 manually annotated samples.Their manually annotated test sets contain 91 finance questions and 97 academic questions; Bank-Financials has four tables, with its largest table containing 65 columns.Source: §9.1.1 · p. 9
9.1.2 Evaluation Metrics.
- Spider-family evaluation uses EX and TS where available, while BIRD uses EX as its stable metric after VES proved hardware- and system-sensitive.TS is unavailable for Spider-DK and Dr.Spider; BIRD also defines VES using execution-time ratios, but the paper relies on EX due to VES fluctuations.Source: §9.1.2 · pp. 9–10
9.1.3 Evaluation Settings.
- CodeS is evaluated through few-shot in-context learning without fine-tuning and supervised fine-tuning on training sets, with fine-tuned models tested on development and test sets.The few-shot setting probes pretrained SQL-generation capability, while supervised fine-tuning assesses alignment.Source: §9.1.3 · p. 10
- Schema-item classifier AUC is consistently higher for Spider than BIRD, and external knowledge improves BIRD classification when it identifies relevant tables and columns.Classifiers are trained on each dataset’s training set and evaluated on its development set.Source: §9.1.4 · p. 10
- Supervised CodeS fine-tuning runs for 4 epochs with batch size 128, learning rate 5e−6, and maximum context length 4,096; few-shot prompts use topk1/topk2 values of 5/6 versus 6/10 for fine-tuning.The learning rate uses cosine decay and a linear warmup over the first 5% of training; the authors note hyperparameter tuning might improve SFT performance.Source: §9.1.4 · p. 10
9.1.4 Implementation details.
- Generation uses beam search to produce four SQL candidates and selects the first executable candidate; experiments run in PyTorch 1.13.1 on CentOS Linux 7 with eight NVIDIA A800 80GB GPUs.The system also has an Intel Xeon Platinum 8358 CPU and 1024GB of RAM.Source: §9.1.4 · p. 10, §9.1.5 · p. 10
9.1.5 Enviroments.
- Few-shot baselines include StarCoder [39], CodeGen [45] [46], and Llama2 [65], while fine-tuning comparisons use leaderboard text-to-SQL systems and fine-tuned Llama2-7B and 13B.The Llama2 fine-tuned models serve as competitive baselines.Source: §9.1.6 · p. 10
9.2 Evaluation on Few-shot In-Context Learning · 9.3 Evaluation on Supervised Fine-Tuning · 9.4 Evaluation on Robustness Benchmarks
Across few-shot learning, supervised fine-tuning, and robustness tests, CodeS performs strongly on Spider and BIRD, with fine-tuned models achieving leading results and generalizing to challenging distribution shifts. The evaluations also show trade-offs across model size, external knowledge, retrieval efficiency, and perturbation type.
9.2 Evaluation on Few-shot In-Context Learning
- In 1-, 3-, and 5-shot evaluation, incremental pre-training improves StarCoder’s SQL generation, and CodeS-15B leads open-source pre-trained models.The gains are more pronounced for smaller models; Table 4 reports Spider TS and BIRD EX results, including BIRD with external knowledge.Source: §9.2 · p. 10, Table 4 · p. 11
9.3 Evaluation on Supervised Fine-Tuning
- On Spider’s development set, SFT CodeS-3B beats leading GPT-4-based methods, while SFT CodeS-7B and -15B achieve new SOTA performance.CodeS-7B has a marginal advantage over CodeS-15B, which the authors suggest may reflect overfitting to Spider training data and slightly weaker development-set generalization.Source: §9.3 · p. 10, Table 5 · p. 11
- SFT CodeS-15B raises BIRD test EX from 28.95% to 52.15% over ChatGPT + COT without external knowledge, while CodeS-7B and -15B top the official leaderboard.With external knowledge, SFT CodeS-7B and -15B improve EX over DIN-SQL + GPT-4 by 3.35% and 4.47%, respectively; the small margin over doubled-size CodeS-7B suggests it offers a compute-efficiency trade-off. The paper also reports VES surpassing EX, indicating more execution-efficient SQL than human experts.Source: §9.3 · pp. 10–11, Table 6 · p. 11
9.4 Evaluation on Robustness Benchmarks
- On Spider variants, SFT CodeS-7B gains 2.6% on Spider-Syn, 4.0% on Spider-Realistic, and 4.5% on Spider-DK over the best baselines.SFT CodeS-3B also beats prior SOTA across all three variants; because the models are trained on Spider and tested on its variants, the results indicate generalization under distribution shift.Source: §9.4 · pp. 11–12, Table 7 · p. 12
- On Dr.Spider, SFT CodeS-7B and -15B slightly surpass ChatGPT + ZeroNL2SQL in global average despite lacking a specific robustness design.The authors say these models frequently excel against methods built specifically for text-to-SQL resilience.Source: §9.4 · p. 12
- On Dr.Spider question perturbations, SFT CodeS-7B scores 74.3% and -15B 75.2%, versus 73.2% for ChatGPT + ZeroNL2SQL.CodeS slightly lags that method on database perturbations, mainly DBcontent-equivalence, and slightly lags RESDSQL-3B + NatSQL on SQL perturbations.Source: §9.4 · p. 12
- For Dr.Spider, CodeS uses a sparse retriever to preserve efficiency, whereas ChatGPT + ZeroNL2SQL’s dense retriever is more resource-intensive.The paper attributes RESDSQL-3B + NatSQL’s SQL-perturbation performance to its simpler intermediary representation, while noting NatSQL’s syntax is limited to Spider and less adaptable.Source: §9.4 · p. 12
9.5 Ablation studies · 9.6 Evaluation on Real-World Scenarios · 9.7 Latency and Deployment Requirements
The ablations identify retrieval, schema filtering, value retrieval, comments, representative values, and keys as important components, while evaluations examine domain transfer and deployment pathways for CodeS. CodeS also offers low-latency inference with GPU memory requirements suited to local deployment.
9.5 Ablation studies
- In 3-shot ablations, removing pattern similarity hurts Spider more than BIRD, random demonstration selection reduces performance in most scenarios, and removing schema filtering or value retrieval also hurts performance.Without schema filtering, generation is slower because input sequences are longer; omitting value retrieval especially affects BIRD.Source: §9.5 · p. 12
- Column data types have minor impact, while removing comments notably hurts BIRD; representative database values and primary/foreign keys are essential on Spider and BIRD.Representative values reveal value formats, and keys support accurate JOIN ON generation.Source: §9.5 · p. 12
9.6 Evaluation on Real-World Scenarios
- Bank-Financials challenges models with many columns and ambiguous schema names, while Aminer-Simplified challenges them with intricate table-join relationships.For deployment evaluation, CodeS-7B uses a BIRD-trained schema item classifier; GPT-3.5 receives three random text-to-SQL examples from each new database, and human evaluation supplements strict exact match.Source: §9.6 · p. 12
- For new databases without annotations, checkpoints fine-tuned on Spider and BIRD can be used directly for inference and have certain domain transfer capability; the EX–HE gap is attributed to different annotation habits between benchmarks and new datasets.Source: §9.6 · p. 12
- With limited annotations and scarce compute, CodeS-7B can adapt without parameter tuning using three demonstrations; with resources, augmented training pairs boost accuracy, though per-database fine-tuning adds overhead.These are the paper’s suggested pathways for adapting CodeS to new databases.Source: §9.6 · p. 12
- Fine-tuning one unified model on Spider, BIRD, Bank-Financials, and Aminer-Simplified prevents performance drops and improves performance, especially on Aminer-Simplified.The paper reports this result for “SFT CodeS-7B using merged data” in Table 10.Source: §9.6 · pp. 12–13
9.7 Latency and Deployment Requirements
- CodeS inference takes 0.6, 0.9, 1.1, and 1.5 seconds for the 1B, 3B, 7B, and 15B variants, versus approximately 60 seconds for DIN-SQL+GPT-4; float16 memory needs are 10GB, 13GB, 20GB, and 35GB.These times are reported on Spider, and the memory figures correspond respectively to the same four SFT CodeS variants; the paper says this enables local deployment without the GPT-4 API.Source: §9.7 · p. 13
10 CONLUSION
CodeS combines specialized pre-trained models, an open SQL-focused corpus, database prompt construction, and bi-directional data augmentation; the authors report new state-of-the-art text-to-SQL accuracy and robustness across benchmarks.
10 CONLUSION
- CodeS provides specialized pre-trained models for text-to-SQL applications, and the authors open-source their collected SQL-focused corpus, code, and models.They suggest the corpus may support future SQL-generation innovations through incremental pre-training.Source: §10 · pp. 13–14
- CodeS is reported as the new state-of-the-art pre-trained model for SQL generation, while SFT CodeS achieves state-of-the-art accuracy and robustness across text-to-SQL benchmarks.The conclusion describes evaluations across various text-to-SQL benchmarks.Source: §10 · p. 14
- The authors propose comprehensive database prompt construction and bi-directional data augmentation to help CodeS adapt across domains.They characterize the model as versatile and able to adapt seamlessly to various domains.Source: §10 · p. 14
Related papers
Cited by
- Reliable Text-to-SQL in Resource-Constrained Settings with Small LLMs via Iterative Retry Workflows2026
- Why, Where, How: Taxonomy-guided Error Grounding for Code Repair in NL2SQL2026
- ProcArena: A Multi-Scenario Benchmark for LLMs on Direct and Interactive PL/SQL Development from Natural Language2026
- BIRD-History: A Benchmark for History-Driven Text-to-SQL with Fine-Grained Knowledge Annotations2026
- CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL2024