AV-SQL: Decomposing Complex Text-to-SQL Queries with Agentic Views Minh Tam Pham1 , Trinh Pham1 , Tong Chen2 , Hongzhi Yin2 , Quoc Viet Hung Nguyen1 , Thanh Tam Nguyen1 1 Griffith University (Australia), 2 The University of Queensland (Australia)
arXiv:2604.07041v1 [cs.DB] 8 Apr 2026
ABSTRACT Text-to-SQL is the task of translating natural language queries into executable SQL for a given database, enabling non-expert users to access structured data without writing SQL manually. Despite rapid advances driven by large language models (LLMs), existing approaches still struggle with complex queries in real-world settings, where database schemas are large and questions require multi-step reasoning over many interrelated tables. In such cases, providing the full schema often exceeds the context window, while one-shot generation frequently produces non-executable SQL due to syntax errors and incorrect schema linking. To address these challenges, we introduce AV-SQL, a framework that decomposes complex Textto-SQL into a pipeline of specialized LLM agents. Central to AV-SQL is the concept of agentic views: agent-generated Common Table Expressions (CTEs) that encapsulate intermediate query logic and filter relevant schema elements from large schemas. AV-SQL operates in three stages: (1) a rewriter agent compresses and clarifies the input query; (2) a view generator agent processes schema chunks to produce agentic views; and (3) a planner, generator, and revisor agent collaboratively compose these views into the final SQL query. Extensive experiments show that AV-SQL achieves 70.38% execution accuracy on the challenging Spider 2.0 benchmark, outperforming state-of-the-art baselines, while remaining competitive on standard datasets with 85.59% on Spider, 72.16% on BIRD and 63.78% on KaggleDBQA. Artifact Availability: The source code is available at https://github.com/pminhtam/AV-SQL.
1
INTRODUCTION
Text-to-SQL translates a natural language question into an executable SQL query, enabling natural language interfaces to relational databases. Recent advances in large language models (LLMs) have improved semantic parsing and compositional SQL generation, especially on benchmarks such as Spider-1.0 [46] and BIRD [25]. However, most Text-to-SQL systems [8, 12, 24, 28, 31] implicitly assume that the full database schema can be provided in the prompt. While feasible for small schemas, this becomes impractical for real-world databases with thousands of tables and columns due to context-window limits, degraded attention in long prompts, and increased risk of schema-linking mistakes. Robustness is another barrier: even strong methods [24, 29, 31, 37, 39] frequently generate SQL that fails to execute because of syntax or invalid references, and repairing a single complex query is difficult when errors are entangled. As illustrated in Fig. 1, these issues arise when complex questions lead to diverse SQL errors that are difficult to fix.
SELECT T1.name FROM cards AS T1 INNER JOIN sets AS T2 ON T2.code = T1.setID WHERE T2.set_name = 'Journey into Nyx Hero''s Path’ ORDER T1.convertedManaCost DESC LIMIT 1
Complex Question: Which card name in the set 'Journey into Nyx Hero's Path' has the highest converted mana cost.
Traditional method
Database Schema
Small parts of Our method schema
Table: legalities: [id, format, uuid, status ] Table: sets: [id, name, code, mcmId, … ]
…… Tablem: [c1m, c2m, …, cnm m ]
Out of context length
JOIN wrong column … syntax error No such column name …
1 (𝒱CTE ) WITH nyx_card_set_cte AS (
sets: [id, name, code, … ] legalities: [id, format, uuid, … ]
…
Tablem-1: Tablem:
… k (𝒱CTE )
SELECT sets.code, sets.name FROM sets WHERE sets.name = 'Journey into Nyx Hero''s Path') SELECT T1.name FROM cards AS T1 INNER JOIN nyx_card_set_cte AS T2 ON T2.code = T1.setCode ORDER BY T1.convertedManaCost DESC LIMIT 1
Figure 1: A motivating example from BIRD-dev (sample 501) illustrates the limitations of traditional Text-to-SQL on complex questions over large schemas. Providing the full schema in a single prompt can exceed the context window and increase the risk of syntax and logical errors. Our approach instead splits the schema into smaller chunks, generates and (1) (𝑘 ) validates agent views (CTE queries: VCTE ,. . . VCTE ), and then composes them into the final SQL, improving robustness under long-context constraints. Example 1.1. The complex question in Fig. 1, when handled by traditional Text-to-SQL, may produce a SQL query with multiple intertwined errors, including incorrect joins (e.g., T2.code=T1.setID, where T1.setID is not a foreign key)„ schema-linking mistakes (e.g., referencing the non-existent column T2.set_name) , and syntax errors (e.g., omitting BY after ORDER). Because execution feedback is often limited to syntax errors and non-existent columns, it is difficult to identify and repair all of these errors holistically. Moreover, fixing one error may expose or even introduce others, making it challenging to produce an executable query. Spider-2.0 [18] makes these limitations explicit by introducing complex questions over large, intricate schemas that often cannot fit into an LLM’s context window. Moreover, many gold queries rely on Common Table Expressions (CTEs) to organize multi-step logic, which improves readability for humans but increases the surface area for syntactic and logical errors in automatic generation. Consequently, one-shot generation with global schema prompting becomes unreliable at real-world scale. To address these challenges, we propose AV-SQL, a multi-stage framework for robust Text-to-SQL. Inspired by Chain-of-Agents long-context decomposition [47], AV-SQL partitions the full schema into table-centric chunks and processes them sequentially. However,
Minh Tam Pham et al.
unlike standard long-context summarization, Text-to-SQL requires exact schema grounding, so intermediate representations must preserve table and column names rather than compress them away. To achieve this, AV-SQL treats chunk-level reasoning as schema filtering and represents intermediate decisions as executable CTEs. Specifically, AV-SQL consists of three stages: (1) Question Rewriting, where a rewriter agent reformulates the question and external evidence into a concise, explicit form; (2) Agent View Generation, where view generator agents examine schema chunks, produce CTE-based agent views, and validates them through execution with iterative repair; and (3) SQL Generation, where planner, SQL generator, and revisor agents compose the validated agent views into the final executable SQL. As shown in Fig. 1, this design reduces long-context pressure, makes schema filtering explicit, and improves executability by validating intermediate CTEs before final synthesis. Example 1.2. In Fig. 1, AV-SQL partitions the schema into smaller chunks and lets each view generator focus on one chunk at a time. For a chunk containing the sets and legalities tables, the agent produces nyx_card_set_cte, an executable CTE that captures the information needed for the question. Because this CTE only uses the sets table, the legalities table can be identified as irrelevant and excluded from later stages, which reduces context overload. After iterative validation and repair to ensure executability and correctness, this CTE can be directly incorporated into the final SQL query, lowering the risk of syntax and schema-linking errors.
Motivated by these design advantages, our main contributions are as follows: • A novel multi-stage agentic Text-to-SQL framework. AV-SQL introduces a three-stage framework using specialized agents for question reformulation, CTE-based intermediate view construction, and final SQL synthesis. • CTE-based agent views with execution-guided repair. Agent views are introduced as executable CTEs that make intermediate schema-filtering decisions explicit and verifiable, using CTE-level execution feedback to iteratively repair errors before final SQL synthesis. • Strong empirical performance. Extensive experiments show that AV-SQL outperforms state-of-the-art methods on large and complex real-world benchmarks, particularly Spider 2.0, while remaining competitive on standard benchmarks such as Spider, BIRD, and KaggleDBQA. • Zero-shot setting. AV-SQL performs strongly in a fully zero-shot setting, requiring neither post-training nor incontext exemplars, and achieves strong results on Spider 2.0-Snow, Spider, BIRD, and KaggleDBQA. • Open-source release. All code and artifacts will be released to support reproducibility and future research. The rest of the paper is organized as follows: §2 reviews related work; §3 formally defines the problem and describes the overview of the AV-SQL framework; §4 details the design of each agent and the overall pipeline; §5 presents experimental results and analysis; and §6 concludes with a summary.
2
RELATED WORK
Text-to-SQL benchmarks. Early single-domain benchmarks include Academic [22], MAS, IMDB, and YELP [45], and Advising [10]. Later work broadened the scope: WikiSQL [48] enabled large-scale table-based evaluation; Spider [46] introduced cross-domain multitable SQL; BIRD [25] covered 37 professional domains; and KaggleDBQA [16] targeted real-world web databases. Spider 2.0 [18] further raises the bar with complex queries over schemas with thousands of columns, making full-schema prompting impractical. Text-to-SQL methods. Text-to-SQL modeling has progressed through several stages. Pre-LLM neural semantic parsers relied on structured decoding and explicit schema modeling. RAT-SQL [40] used relation-aware attention for schema linking; and RESDSQL [23] improved robustness via schema pruning. RASAT [33], and LGESQL [4] further refined graph-based schema-question modeling, while CatSQL [11] combined rule-based and neural approaches via a sketchbased framework. With LLMs, early work [27, 34] showed that zero- and few-shot prompting yields competitive performance without task-specific training. Methods such as DIN-SQL [31], MAC-SQL [39], C3SQL [8], DAIL-SQL [12], DTS-SQL [32], and ZeroNL2SQL [9] improved performance via task decomposition, demonstrations, and multi-model pipelines. Supervised fine-tuning approaches including CodeS [24] and XiYan-SQL [13] strengthened open-source models, while hybrid and multi-candidate methods such as CHESS [37], MCS-SQL [17], and Super-SQL [20] further improved robustness. More recent systems – CHASE-SQL [30], AlphaSQL [21], and Long Context NL2SQL [5] – incorporate planning, candidate selection, and execution feedback for complex schemas. Although existing methods perform strongly on Spider and BIRD, they struggle on Spider 2.0’s larger schemas and more complex queries. Recent agentic approaches – ReForCE [7] (self-refinement with majority-vote consensus), DSR-SQL [14] (dual-state reasoning), and AutoLink [43] (iterative schema linking) – still achieve only 35.83%, 35.28%, and 34.92% execution accuracy, respectively. In contrast, AV-SQL introduces a novel approach that uses verifiable CTE-based agent views, generated from smaller schema chunks, as intermediate steps to guide the final SQL synthesis. This enables AV-SQL to achieves a new state-of-the-art result of 70.38% on Spider 2.0, while remaining competitive on Spider (85.59%), BIRD (72.16%) and KaggleDBQA (63.78%). Long Context Modeling for LLMs. LLMs have finite context windows, making long inputs such as large documents and database schemas difficult to handle. Common strategies include extending context length (e.g.,from 2048 in GPT-3 [3] to 128k in GPT-4 [1] and 400k tokens in GPT-5 [36]), though performance can still degrade due to context rot [15]; RAG, which retrieves relevant evidence [19, 26, 41, 44] but may omit necessary context [2]; and agentic frameworks such as CoA, where multiple agents process context segments and a manager aggregates their outputs [47]. Inspired by CoA [47], AV-SQL adapts long-context decomposition to Text-to-SQL by splitting large schemas into manageable chunks, allowing agents to process table/column subsets sequentially rather than loading the full schema into a single prompt. This makes schema filtering explicit, alleviates full-schema prompting, and improves robustness by validating intermediate agent views before composing the final SQL query.
AV-SQL: Decomposing Complex Text-to-SQL Queries with Agentic Views
3 PROBLEM FORMULATION 3.1 Model and Problem Statement Given a natural language question Q, a database schema S, and optional external knowledge K, the goal of Text-to-SQL is to generate an executable SQL query Y to answer the question Q. We define the database as D = (T , C, R), where T = {T1, T2, . . . , T𝑚 } is the set of 𝑚 tables, and each table T𝑖 is associated with a column set C𝑖 = {𝑐 𝑖1, 𝑐 𝑖2, . . . , 𝑐𝑛𝑖 𝑖 }, with 𝑛𝑖 denoting the number of columns in T𝑖 . Let C = {C1, C2, . . . , C𝑚 } be the collection of column sets for all tables, and let R denote the foreign-key relations among tables. Then, the Text-to-SQL task can be formulated as Y = 𝑓 (Q, S, K | 𝜽 ),
Table 1: Summary of Important Notations
3.2
Method
Description Natural language question external knowledge evidence A relational database Schema of the database D Set of tables in the database D Set of columns of table 𝑖 in the database D Set of 𝑘 schema chunks CTE-based agent views for chunk 𝑗 JSON-based schema selection for chunk 𝑗
Challenges
Text-to-SQL systems in practical environments face several interrelated challenges: (C1) Long-context overload. Real-world databases may be accompanied by long external documents and large schemas with hundreds of tables and thousands of columns, making the input extremely long. To answer a single question, the system may need to process both the external knowledge and the full database schema, which can easily exceed the context window of LLMs. Even when all inputs fit, the long context can dilute attention, making it harder to identify relevant evidence and correctly ground schema elements. As a result, schema grounding weakens, increasing the risk of incomplete or incorrect SQL generation. (C2) Limitations of schema reduction. A common mitigation is to filter the schema by selecting tables and columns relevant to the question. However, in long-context settings, such filtering can reduce accuracy by removing useful schema elements, breaking valid join paths, or providing insufficient structure for correct SQL synthesis. (C3) SQL complexity and error propagation. Real-world questions often require complex SQL with multiple joins, nested conditions, aggregations, and multi-step reasoning. This complexity increases the likelihood of both schemalinking errors and semantic mistakes, and small errors in one part of the query can propagate to the final result. (C4) Difficulty of debugging monolithic SQL. When an LLM generates a single large SQL query, debugging is difficult:
Single candidate Zero-shot Handle large DB
DIN-SQL [31], DAIL-SQL [12] , MAC-SQL [39] MCS-SQL [17], CHESS [37] Alpha-SQL [21] ReForCE [7], AutoLink [43] AV-SQL
(1)
where the function 𝑓 (· | 𝜽 ) can represent a model or pipeline system with the parameter 𝜽 , Y is SQL query can execute against the database instance D to get the data which use requires in Q. All important notations are summarized in Table 1.
Notation Q K D S T = {T1, T2, . . . , T𝑚 } C𝑖 = {𝑐 𝑖1, 𝑐 𝑖2, . . . , 𝑐𝑛𝑖 𝑖 }, 1 , . . . , S 𝑗 , . . . , S𝑘 } Π(S) = {Ssub sub sub 𝑗 VCTE 𝑗 J
Table 2: Comparison of AV-SQL with representative Text-toSQL methods in terms of (i) single-candidate generation, (ii) zero-shot applicability, and (iii) ability to handle large databases (e.g., Spider 2.0 schemas).
✓
✗
✗
✗ ✗ ✗ ✓
✗ ✓ ✓ ✓
✗ ✗ ✓ ✓
if execution fails or results are incorrect, it is often unclear which clause (e.g., join, filter, grouping) caused the issue. This makes iterative correction inefficient and unreliable.
3.3
Framework Overview
To address the challenges above, we propose AV-SQL, a multi-stage Text-to-SQL framework that uses executable CTE-based agent views as intermediate representations. Rather than generating a single monolithic SQL query over the full schema, AV-SQL constructs intermediate agent views that make schema filtering explicit, can be executed and validated against the database, and enable early error detection before final SQL synthesis. This design reduces fullschema prompting, improves error localization, and makes complex reasoning more tractable. Table 2 compares AV-SQL with representative Text-to-SQL methods along three practical dimensions: single-candidate generation, zero-shot applicability, and support for large databases. Promptingbased methods such as DIN-SQL, DAIL-SQL, and MAC-SQL typically generate a single candidate, but are not designed for largeschema settings. Methods such as CHESS and MCS-SQL rely on selecting from multiple candidates, while recent Spider 2.0-oriented systems such as ReForCE and AutoLink handle large schemas but also depend on multi-candidate exploration. In contrast, AV-SQL supports single-candidate generation in a fully zero-shot setting while explicitly targeting large-database scenarios. This combination is particularly appealing for practical deployments, where minimizing sampling/selection overhead is important, yet robust handling of long schemas and complex joins remains essential. In more detail, AV-SQL decomposes Text-to-SQL into three stages that progressively clarify the user intent, construct validated intermediate agent views from schema chunks, and synthesize the final executable SQL. As shown in Fig. 2, the framework consists of the following stages: • Question Rewriting: This stage rewrites the original question and external knowledge into a clearer and more explicit form. By extracting useful external knowledge, resolving underspecified references, and clarifying implicit constraints such as missing filters or aggregation criteria, it reduces linguistic ambiguity and improves downstream schema linking. The output is a clarified question that preserves the user’s intent while making downstream reasoning more reliable, helping to mitigate challenges (C1) and (C3) by attention on relevant information to reduce the likelihood of semantic errors in SQL generation.
Minh Tam Pham et al.
Preprocessing & Env Small parts of schema (Π 𝒮 )
Database Schema(𝒮) Table: legalities: [id, format, uuid, status ] Table: sets: [id, name, code, mcmId, … ] Table: cards: [id, name, setCode, colors,… ]
1 (𝒮sub :)
sets: [id, name, code, … ] legalities: [id, format, uuid, … ]
sets: [id, name, code, … ] legalities: [id, format, uuid, … ]
k (𝒮sub :) Tablem-1: Tablem:
Tablem: [c1m, c2m, …, cnm m ]
Agent View Generation
(𝒬rewrite )
1 (𝒮sub :)
…
……
Part of schema
SQL Generation
Planner
1,t
(𝒱CTE , 𝒥 1,t :)
cards: [id, name, setCode, … ]
Feedback: • Execution (err 1,𝑡 ) • Retrieval values (ℒ𝒟1,𝓉 )
External knowledge(𝒦)
Question Rewriting (𝒬: ) Which card name in the set 'Journey into Nyx Hero's Path' has the highest converted mana cost.
View generator
AI Agent
Database (𝒟)
Rewriter
(𝒦: ) set 'Journey into Nyx Hero's Path' refers
• Consistency (msg consistency )
Error: No such column name “set_name”
1 (𝒱CTE :)
Agent View+ JSON Selction
Conditions: set name corresponds to the condition name = 'Journey into Nyx Hero''s Path’ find the card with the highest converted mana cost Output needs to contain: card name with the highest converted mana cost.
WITH nyx_card_set_cte AS ( SELECT sets.code, sets.name FROM sets WHERE sets.name = 'Journey into Nyx Hero''s Path’) The cte could filter the condition: The card is part of the set named ------------------------------------------(𝒥1 :) { “sets”: ["code", "name"], }
to name = 'Journey into Nyx Hero''s Path'
(𝑉ℂ𝕋𝔼 )
Planning(𝒫)
𝑡 (𝒴SQL :)
(err 1,𝑡 : )
(𝒬rewrite : )
(𝒬rewrite)
WITH nyx_card_set_cte … SELECT T1.name FROM cards AS T1 INNER JOIN nyx_card_set_cte AS T2 ON T2.code = T1.setCode ORDER T1.convertedManaCost DESC LIMIT 1
1,𝑡
Vector Database
(𝒮filtered )
Aggregated Agent Views
Step 1: Filter the `sets` table to include only those cards in the set 'Journey … Step 2: Order these filtered cards by their `convertedManaCost` … Step 3: Select the top card … …
WITH nyx_card_set_cte AS ( SELECT sets.code, sets.name FROM sets WHERE sets.set_name = 'Journey into Nyx Hero''s Path’ ) …..
2 (𝒮sub :)
Global Schema Selection
Feedback: • Execution (err t ) • Revision
SQL generator
(err t : )
Revisor
Near “order” syntax error sets: [name, code]
Filtered Schema 1 (𝒮filtered )
Final SQL (𝒴 ⋆ : ) WITH nyx_card_set_cte AS ( SELECT sets.code, sets.name FROM sets WHERE sets.name = 'Journey into Nyx Hero''s Path') SELECT T1.name FROM cards AS T1 INNER JOIN nyx_card_set_cte AS T2 ON T2.code = T1.setCode ORDER BY T1.convertedManaCost DESC LIMIT 1;
Figure 2: Overview of AV-SQL. The framework begins with preprocessing—schema splitting and vector database initialization for value preprocessing—followed by three main stages: (1) Question Rewriting which reformulates the input question, optionally using external knowledge, into a clearer and more explicit form; (2) Agent View Generation, which decomposes the long-context schema into smaller chunks and produces execution-validated intermediate CTE-based agent views that capture key reasoning steps while identifying relevant schema elements; and (3) SQL Generation, which uses three agents: a planner, a SQL generator, and a revision agent to produce the final executable SQL query from the filtered schema and validated agent views. • Agent View Generation: This stage uses multiple viewgeneration agents to process partial schema contexts, generating executable CTE-based intermediate views that incrementally capture the information needed to answer the clarified question. Each agent view is an executable Common Table Expressions (CTE) representing a specific reasoning step, such as identifying candidate entities, constructing join paths, applying filters, or computing aggregates. The agent views are validated through execution, or other database-level checks to ensure that the they are syntactically correct, structurally consistent, and semantically aligned with the intended query. They also provide useful insight into the database contents and the expected form of the final result. This stage addresses challenges (C1), (C2), (C3), and (C4) by decomposing long-context schemas into verifiable steps, making schema filtering explicit, and enabling early error detection before final SQL synthesis. • SQL Generation: This stage generates the final SQL query using three agents: a planner that determines the query structure, including selection target, filtering conditions, required FROM and JOIN clauses, and any nested structures; a SQL generator that produces the query; and a revision that checks the generated SQL for correctness and consistency with the question. Rather than using the full raw schema, these agents use only on the filtered schema elements and
validated CTE-based agent views from the previous stage, narrowing the search space and preventing hallucinated columns or incorrect joins. Building upon modular intermediate views makes the reasoning process transparent and verifiable, directly addressing challenges (C3) and (C4).
4
METHODOLOGY
This section presents AV-SQL in detail, as illustrated in Fig. 2. To address large-scale Text-to-SQL over real-world databases with hundreds of tables, our framework organizes the task into three stages: Question Rewriting, Agent View Generation, and SQL Generation. This decomposition reduces schema complexity and improves generation accuracy by dividing the long schema context into smaller and more manageable schema chunks. In particular, Question Rewriting clarifies the input question and extracts useful context, Agent View Generation builds validated intermediate agent views from partial schema contexts, and SQL Generation constructs the final SQL query using the filtered schema and validated CTE-based agent views.
4.1
Preprocessing
Before introducing the main stages of AV-SQL, we first apply a set of preprocessing steps to prepare the database. In particular, the preprocessing procedure consists of three components: database
AV-SQL: Decomposing Complex Text-to-SQL Queries with Agentic Views
schema compression, schema splitting into smaller chunks, and database value preprocessing.
12.5 10.0 7.5 5.0 2.5 0.0
Compact 0.8 Full 0.6 Density
Count
4.1.1 Database schema compression. This step reduces the token length of Spider 2.0 schemas by grouping near-duplicate tables and columns into pattern-based clusters. Spider 2.0 often contains very large schemas with many similar tables and columns whose names differ only by numeric suffixes, such as year, month, or index. Directly serializing these schemas into prompts introduces substantial redundancy and may cause the model to miss important schema details. To reduce this redundancy, we compress the schema by clustering redundant tables and columns based on shared naming patterns. Extending [7], we further verify structural consistency before merging: tables are merged only when they share the same column sets and key information, and columns are grouped only when their types and metadata are consistent. This process compresses large schemas by about 10× (see Fig. 3), substantially reducing prompt length and improving efficiency.
0.4 0.2 3
4
5 6 token_len (log scale)
7
0.0
Figure 3: Token-length distribution of large database schemas before and after schema compression. Example 4.1. In the G360 database in Spider2-snow, the schema contains multiple tables such as GOOGLE_ANALYTICS_SAMPLE.GA_SESSIONS_20170201, GOOGLE_ANALYTICS_SAMPLE.GA_SESSIONS_20170202, ..., GOOGLE_ANALYTICS_SAMPLE.GA_SESSIONS_20170228, ... . Since these tables have similar column sets and metadata, we group them into a single table cluster with the pattern GOOGLE_ANALYTICS_SAMPLE.GA_SESSIONS_{NUM}. In the WORLD_BANK database in Spider2-snow, the table WORLD_BANK_GLOBAL_POPULATION.POPULATION_BY_COUNTRY contains columns such as year_2003, year_2004, year_2005, ..., year_2022. Because these columns share the same data type (Number) and similar metadata, we group them into a single column cluster with the pattern year_{NUM}.’ 4.1.2 Database schema splitting. In large-scale benchmarks such as Spider 2.0, database schemas can be extremely long, reaching up to ∼ 1.5 million tokens, which exceeds the context window of current LLMs. To make schema grounding feasible for view generation stage of our framework, we partition the full schema into multiple smaller chunks, where each chunk contains one or more complete table definitions. Let the full database schema be S. We partition it into 𝑘 chunks: 1 2 𝑘 Π(S) = {Ssub , Ssub , . . . , Ssub }.
(2)
𝑗 Each chunk Ssub contains a set of tables together with their complete column information and any foreign-key relations visible 𝑗 within that chunk : Ssub = T 𝑗 , C 𝑗 , R 𝑗 , where T 𝑗 denotes the set of tables, C 𝑗 the set of columns, and R 𝑗 the set of foreign-key relations visible in chunk 𝑗. There are several possible strategies for splitting S: (i) assigning one table to each chunk, (ii) grouping tables by foreign-key connected components, or (iii) length-based partitioning. In practice, however, large schemas in Spider 2.0 do not provide foreign-key information, so partitioning by connected components is not applicable. We therefore use length-based partitioning, in which complete table definitions are packed into chunks such that the estimated token length of each chunk does not exceed a predefined limit 𝐵: 𝑗 ∀Ssub ∈ Π(S),
𝑗 Ssub <𝐵
(3)
where | · | denotes the estimated token length of the corresponding schema chunk. 4.1.3 Database Value Preprocessing. Accurately retrieving database values that match a user’s natural-language intent is important for reliable Text-to-SQL generation [28]. In practice, SQL queries typically reference only a small subset of values from potentially large databases, most often in filtering predicates such as WHERE clauses. A common challenge is the mismatch between how users mention an entity and how the corresponding value is stored in the database (e.g., a user writes “USA” while the database stores “US”). Following [21, 37], we adopt a two-stage pipeline with offline pre-processing and online retrieval to mitigate this discrepancy. Offline Pre-processing. In the offline stage, we index text-based entity values that are likely to vary in surface form, such as country names, organization names, abbreviations, and short categorical strings. We exclude primarily numeric values, such as phone numbers, dates, IDs, and postcodes. Each retained value is converted into a MinHash-based LSH signature [6] and stored in a vector database for efficient retrieval. Online Retrieval. At query time, we extract candidate literals from the generated agent views. For each value, we compute its MinHash LSH signature [6] and retrieve similar entries from the offline index. We then filter the candidates using edit-distance and semantic-similarity thresholds (𝜏𝑒𝑑𝑖𝑡 , 𝜏𝑠𝑒𝑚𝑎𝑛𝑡𝑖𝑐 ), where semantic similarity is computed with all-MiniLM-L6-v2 [35, 42]. The selected database values are then incorporated into the agent prompt, providing additional context for view generation and SQL synthesis.
4.2
Question Rewriting
This stage employs a single agent, 𝐿𝐿𝑀𝑅𝑒𝑤𝑟𝑖𝑡𝑒𝑟 , to reformulate the user request into a clearer and more explicit form for downstream agents (e.g., the view generator, planner, and SQL generator). It takes as input the original natural-language question Q and optional external knowledge K, and produces a rewritten question Qrewrite that explicitly states the user intent, key constraints, and necessary domain assumptions. External knowledge K provides schema-external information such as concept-to-column mappings, metric definitions (e.g., Average_score), business rules, and explanations of coded values. In benchmarks like BIRD, this knowledge is typically brief (often just 1–2 sentences). However, in large-scale datasets like Spider 2.0,
Minh Tam Pham et al.
K frequently consists of lengthy documents filled with noisy or question-irrelevant details. Providing the full K directly to downstream LLM agents increases prompt length and can distract the model, degrading Text-to-SQL reliability. Therefore, 𝐿𝐿𝑀𝑅𝑒𝑤𝑟𝑖𝑡𝑒𝑟 filters out irrelevant information from K, integrates only the pertinent details, and rewrites the original question. The rewritten question structures the key requirements explicitly, for example: Qrewrite = ⟨task, required outputs, filters/constraints, sorting/limit⟩. Formally, the overall rewriting objective is: Qrewrite = 𝐿𝐿𝑀𝑅𝑒𝑤𝑟𝑖𝑡𝑒𝑟 Q, K | Q , (4) s.t.
Intent(Qrewrite ) = Intent(Q, K),
Where Intent(·) is denoted as the expressed user intent in the question. As a result, downstream agents receive only the clarified Qrewrite rather than the raw question paired with the full K, which reduces irrelevant context and improves robustness in subsequent reasoning and SQL generation.
4.3
Agent View Generation
This stage is the core component for schema exploration and intermediate reasoning. It consists of multiple view-generator agents, denoted 𝐿𝐿𝑀𝑉 𝑖𝑒𝑤 , each receiving a partial schema chunk. Specifically, each agent takes as input (i) the rewritten question Qrewrite 𝑗 from §4.2 and (ii) a schema chunk Ssub from the schema-splitting procedure in §4.1.2. Restricting each agent to a partial schema reduces prompt length and encourages the model to focus on a manageable subset of tables and columns, mitigating information overload in long-context settings. Each view-generator agent, denoted 𝐿𝐿𝑀𝑉𝑗 𝑖𝑒𝑤 , produces two outputs: (a) a CTE-based agent view 𝑗 VCTE , consisting of one or more intermediate CTE queries with their natural-language rationale, and (b) a JSON schema selection J 𝑗 identifying the candidate tables and columns needed to answer the question (see Fig. 2 for an example). The generation process for each schema chunk 𝑗 is defined as: 𝑗 𝑗 VCTE , J 𝑗 = 𝐿𝐿𝑀𝑉𝑗 𝑖𝑒𝑤 Qrewrite, Ssub , (5) 𝑗 Each CTE query within VCTE acts both as a data exploration step
over the database and as a compressed logical representation of the reasoning behind table and column selection, encoding operations such as joins, filters, and aggregations in a modular form that can be directly reused during final SQL generation. The JSON selection is defined as J 𝑗 = (TJ𝑗 , CJ𝑗 ), where TJ𝑗 and CJ𝑗 denote the selected tables and columns, respectively. These dual outputs serve two purposes: (i) it enables schema filtering for downstream SQL generation, and (ii) supporting automatic grounding quality checks by comparing the JSON selection against the schema elements actually used in the generated CTE. To improve output quality, an iterative validation and repair procedure is applied to each agent view, covering keyword value extraction and retrieval, execution-based validation to fix syntax 𝑗 and schema-linking errors, and consistency checking between VCTE 𝑗 and J . Outputs are refined until valid or a maximum number of repair iterations is reached. Once all schema chunks are processed, the validated agent views and JSON selections are aggregated into a set of executable agent views and a global schema selection, passed
to the downstream SQL Generation stage as compact, reusable intermediate reasoning context. The full procedure is described in algorithm 1, with each step detailed below. Keyword Value Extraction and Retrieval. In addition to producing intermediate queries, the CTE program exposes useful literals (e.g., string constants in WHERE clauses). Unlike prior work [21, 37] that extracts keywords directly via prompting, we use sqlglot to 𝑗 extract literals LCTE from the generated CTE: 𝑗 𝑗 LCTE = Literal VCTE . (6) 𝑗 For each literal ℓ ∈ LCTE , we retrieve and normalize candidate ( 𝑗,𝑡 ) database values denoted L D using the online value-matching ( 𝑗,𝑡 ) procedure described in §4.1.3. The retrieved candidate set L D 𝑗 is then feedback to the CTE Agent to regenerate or refine Vcte , improving value grounding and increasing the likelihood that the CTE-based agent view executes correctly. Execution-based validation. This step is to fix any syntax error in CTE query. Each agent view contain one or more CTE queries, which is executable and can be validated by running it against the database. We use sqlglot to parse the agent view and extract the underlying SQL for execution, which detects both syntax errors and schema-linking errors. If execution fails, the error message is fed back to the model , which is prompted to revise the agent view. 𝑗 We denote Valid(Exec(VCTE , D)) as the execution-based valida𝑗 tion function, which returns True if VCTE executes successfully on database instance D without error, and False otherwise. If there are any errors (denoted err 𝑗 ), this error message will be feedback to 𝑗 the model to repair the CTE query. Valid(Exec(VCTE , D)) = True means that there is no error while executing the CTE query err 𝑗 = ∅ Consistency checking. We also enforce consistency between the CTE-based agent view and the JSON selection, denoted 𝑗 𝑗 Consistent(VCTE , J 𝑗 ). Let TV𝑗 and CV be the sets of tables and 𝑗 columns used by agent view CTE query VCTE , and JSON selection 𝑗 𝑗 𝑗 J = (TJ , CJ ). The consistency checking require:
• If the JSON output selects no columns and table, the agent must not generate any CTE-based view. It refer that this schema chunk is not relevant to answer the question, so there are not any table or column related to the question. 𝑗 TJ𝑗 = ∅ ∧ CJ𝑗 = ∅ =⇒ VCTE = ∅. • If a CTE-based view exists, the JSON output must include at least one selected column. It indicates that this provided schema chunk is related to the question, so JSON selection must choose at least one column or table which relevant to 𝑗 the question. VCTE ≠ ∅ =⇒ CJ𝑗 ≠ ∅ ∨ CJ𝑗 = ∅ • All tables and columns referenced in the CTE-based view must appear in the JSON selection. This enforces that the CTE-based agent view uses only the tables and columns which are selected in JSON selection. 𝑗 (TV𝑗 ⊆ TJ𝑗 ) ∧ (CV ⊆ CJ𝑗 ) After checking the consistency, the step will also feedback a ( 𝑗,𝑡 ) consistency message denoted by msgconsistency which could contain information about which table or column in CTE query is not selected in JSON selection, or any other inconsistency between CTE query and JSON selection. This message will be used to repair
AV-SQL: Decomposing Complex Text-to-SQL Queries with Agentic Views
Algorithm 1: Agent view Generation Pipeline
both CTE query and JSON selection in the next iteration. This consistency checking step ensure that the response of model is correct in logic. Since the model is required to express schema grounding in two forms–the CTE-based agent view and the JSON selection–any inconsistency between them may indicate a semantic error. Note that we allow redundancy: J 𝑗 may include additional tables/columns not used in the current CTE, since they can be useful when integrating evidence from other schema segments. ( 𝑗,0) Iterative validation and repair. The initial outputs (VCTE , J ( 𝑗,0) ) may contain errors, including SQL syntax errors, schema-linking errors such as invalid table or column names, and inconsistencies between the CTE and the JSON selection. We therefore apply an iterative validation-and-repair loop, regenerating both outputs until the CTE is executable and the selection is consistent: ( 𝑗,𝑡 +1) 𝑗 ( 𝑗,𝑡 ) VCTE , J ( 𝑗,𝑡 +1) = 𝐿𝐿𝑀𝑉𝑗 𝑖𝑒𝑤 (Qrewrite, Ssub , VCTE , J ( 𝑗,𝑡 ) , (7) 𝑗 ( 𝑗,𝑡 ) LD , err ( 𝑗,𝑡 ) , msgconsistency )
Input: Rewritten question Qrewrite ; Full schema S; and database instance D; Token budget 𝐵 for schema segments; Max repair iterations 𝑇max ; thresholds 𝜏𝑒𝑑𝑖𝑡 and 𝜏𝑠𝑒𝑚𝑎𝑛𝑡𝑖𝑐 Output: Aggregated Validated Agent Views VCTE ; Global Schema Selection Sfiltered
This loop continues until the validation conditions are satisfied or the maximum number of repair iterations denoted 𝑇max is reached. Aggregation. After all schema chunks have been processed, we aggregate the validated agent views and JSON selections: n o𝑘 𝑗 𝑗 𝑗 VCTE = VCTE Valid Exec(VCTE , D) ∧ Consistent(VCTE , J 𝑗) , 𝑗=1
n
𝑗 J = J 𝑗 Consistent(VCTE , J 𝑗)
o𝑘 . 𝑗=1
(8) We then compute the globally selected tables and columns by taking the union over all chunks: 𝑘 𝑘 Ø Ø T★ = TJ𝑗 , C★ = CJ𝑗 . (9) 𝑗=1
𝑗=1
𝑗 Since the consistency check enforces (TV𝑗 ⊆ TJ𝑗 ) and (CV ⊆ CJ𝑗 ), the union of JSON selections forms a safe superset of all schema elements grounded by the validated CTEs. The global schema selection passed to the SQL Generation stage is: Sfiltered = {T ★, C★ }. The following outputs are passed to the downstream SQL Generation stage:
• Aggregated Validated Agent Views VCTE : validated, executable CTE-based agent view programs with their execution results and natural-language rationales explaining how each agent view contributes to the final answer. • Global Schema Selection Sfiltered : a reduced schema derived from the aggregated JSON selections, containing only the relevant tables and columns. Together, these outputs provide the SQL Generation stage with a compact and well-validated context, enabling it to reuse intermediate reasoning steps, avoid distraction from irrelevant schema elements, and leverage rationales to guide final query construction.
4.4
SQL Generation
The SQL Generation stage synthesizes the final SQL query that answers the user question. It consists of three agents: a planner agent 𝐿𝐿𝑀𝑃𝑙𝑎𝑛𝑛𝑒𝑟 , a SQL generator agent 𝐿𝐿𝑀SQL , and a revision agent 𝐿𝐿𝑀𝑅𝑒𝑣𝑖𝑠𝑜𝑟 . This stage receives a compact, structured context from earlier stages: (i) the rewritten question Qrewrite from §4.2,
1 , . . . , S𝑘 } ← SplitSchemaByTokenBudget(S, 𝐵) {Ssub sub VCTE ← ∅; J ← ∅ for 𝑗 ← 1 to 𝑘 do // Initial generation ( 𝑗,0) 𝑗 (VCTE , J ( 𝑗,0) ) ← 𝐿𝐿𝑀𝑉𝑗 𝑖𝑒𝑤 (Qrewrite, Ssub ) response_valid ← False 𝑗 LD ←∅ // retrievel candidate values 𝑡 ←0 // Execution-based validation while 𝑡 < 𝑇max and response_valid = False do // Keyword Value Extraction and Retrieval. ( 𝑗,𝑡 ) L ( 𝑗,𝑡 ) ← Literal(VCTE ) foreach ℓ ∈ L ( 𝑗,𝑡 ) do 𝑗 𝑗 L D ← L D ∪ Retrieve(ℓ, 𝜏𝑒𝑑𝑖𝑡 , 𝜏𝑠𝑒𝑚𝑎𝑛𝑡𝑖𝑐 ) ( 𝑗,𝑡 ) , D) (Z ( 𝑗,𝑡 ) , err ( 𝑗,𝑡 ) ) ← Exec(VCTE ( 𝑗,𝑡 ) exec_valid ← (err = ∅) // Consistency checking ( 𝑗,𝑡 ) ( 𝑗,𝑡 ) is_consistent, msgconsistency ← Consistent(VCTE , J ( 𝑗,𝑡 ) )
if exec_valid ∧ is_consistent then response_valid ← True else ( 𝑗,𝑡 +1) (VCTE , J ( 𝑗,𝑡 +1) ) ← 𝑗 ( 𝑗,𝑡 ) 𝐿𝐿𝑀𝑉 𝑖𝑒𝑤 (Qrewrite, Ssub , VCTE , J ( 𝑗,𝑡 ) , ( 𝑗,𝑡 ) 𝑗 ) , err ( 𝑗,𝑡 ) , msgconsistency LD
𝑡 ←𝑡 +1 if response_valid = True then 𝑗 VCTE ← VCTE ∪ {VCTE } ; J ← J ∪ {J 𝑗 } // Aggregation Ð Ð T ★ ← T 𝑗 ∈J TJ ; C★ ← C 𝑗 ∈J CJ J
J
Sfiltered ← {T ★, C★ } return (VCTE, Sfiltered )
(ii) the aggregated validated agent views VCTE with their execution results and natural-language rationales from §4.3, and (iii) the global schema selection Sfiltered containing only relevant tables and columns from §4.3. This reduced context keeps the agents focused on the necessary schema elements and lowers the risk of distraction from irrelevant database structures. The stage follows a three-step procedure: 𝐿𝐿𝑀𝑃𝑙𝑎𝑛𝑛𝑒𝑟 constructs a high-level query plan to reduce structural errors; 𝐿𝐿𝑀SQL generates the SQL query with execution feedback; and 𝐿𝐿𝑀𝑅𝑒𝑣𝑖𝑠𝑜𝑟 verifies and revises the generated SQL for
Minh Tam Pham et al.
semantic correctness. The full procedure is described in algorithm 2, and each step is detailed below. Planning. Before writing SQL, 𝐿𝐿𝑀𝑃𝑙𝑎𝑛𝑛𝑒𝑟 constructs a high-level query plan to guide generation and reduce structural errors. The plan P specifies which CTEs and tables to use, required join paths, hidden formulas, necessary projections, and operations such as filtering, grouping, aggregation, and ordering:
Algorithm 2: SQL Generation Pipeline
P = 𝐿𝐿𝑀𝑃𝑙𝑎𝑛𝑛𝑒𝑟 (Qrewrite, VCTE, Sfiltered ) .
// Planning P ← 𝐿𝐿𝑀Planner (Qrewrite, VCTE, Sfiltered )
(10)
Execution-based validation. Given the plan and the structured context from earlier stages, 𝐿𝐿𝑀SQL generates the final SQL query. Similar to the execution-based validation loop in §4.3, execution feedback is incorporated to iteratively repair syntax and schemalinking errors: 𝑡 +1 𝑡 YSQL = 𝐿𝐿𝑀SQL P, Qrewrite, VCTE, Sfiltered, YSQL , err (𝑡 ) (11) where err (𝑡 ) is the execution error message at iteration 𝑡. This loop terminates when the query YSQL executes successfully on the database instance D without error or when the maximum number of iterations 𝑇max is reached. Semantic verification and revision. Successful execution does not guarantee semantic correctness. After obtaining an executable query from 𝐿𝐿𝑀SQL , 𝐿𝐿𝑀𝑅𝑒𝑣𝑖𝑠𝑜𝑟 is applied to verify whether the result matches the intent of Qrewrite : ★ 𝑡 YSQL = 𝐿𝐿𝑀𝑅𝑒𝑣𝑖𝑠𝑜𝑟 Qrewrite, YSQL . (12) If the revision agent confirms that YSQL is semantically correct, it acts as an identity mapping and returns the same query unchanged. Otherwise, 𝐿𝐿𝑀𝑅𝑒𝑣𝑖𝑠𝑜𝑟 edits the query according to the corrective ★ . This step reduces feedback and produces a revised query YSQL semantic errors that may survive execution-based validation. ★ The SQL Generation stage outputs the final verified query YSQL and its execution result as the system answer.
5
EXPERIMENTS
This section presents experiments evaluating the effectiveness, scalability, and reliability of AV-SQL. To systematically assess the contribution of each design choice, we organize our experiments around the following research questions. (RQ1) Normal-scale performance: How well does the framework perform on standard Text-to-SQL benchmarks: Spider, BIRD and KaggleDBQA? (RQ2) Large-scale scalability: How well does the framework perform on large scale, enterprise oriented benchmarks Spider 2.0-Snow? (RQ3) Multi-Candidate SQL Generation: What is the performance of AV-SQL under a multiple SQL candidates setting? (RQ4) Ablation study (Component contribution): How do the key components–the rewriter, planner, revisor, and execution feedback for the view generator and SQL generator– contribute to overall performance? (View Generation Output Contribution): How do the two outputs of the Agent View Generation stage §4.3, Aggregated Validated Agent Views (VCTE ) and Global Schema Selection (Sfiltered ) contribute to the correctness of the final SQL query?
Input: Rewritten question Qrewrite ; Aggregated Validated Agent Views VCTE ; Global Schema Selection Sfiltered and database D; Max execution-repair iterations 𝑇max ★ and execution result Z Output: Final SQL query YSQL
// Initial SQL generation from the plan (0) YSQL ← 𝐿𝐿𝑀SQL (P, Qrewrite, VCTE, Sfiltered ) 𝑡 ←0 // Execution-based validation while 𝑡 < 𝑇max do (𝑡 ) (Z (𝑡 ) , err (𝑡 ) ) ← Exec YSQL ,D
if err (𝑡 ) = ∅ then ★ ← Y (𝑡 ) YSQL SQL break (𝑡 +1) (𝑡 ) ← 𝐿𝐿𝑀SQL P, Qrewrite, VCTE, Sfiltered, YSQL YSQL , err (𝑡 ) 𝑡 ←𝑡 +1 // Semantic verification and revision ★ ← 𝐿𝐿𝑀 𝑡 YSQL Revisor Qrewrite , YSQL ★ ,D (Z, _) ← Exec YSQL ★ , Z) return (YSQL
(RQ5) Schema Filtering: What is the accuracy of the Agent View Generation stage in identifying and filtering relevant tables and columns? (RQ6) Component cost analysis:What are the runtime and computational cost contributions of each agent in the proposed framework? (RQ7) Error analysis: What are the common error types and failure modes of the proposed framework? (RQ8) Hybrid LLM Configuration: What is the impact of using heterogeneous LLM backbones across agents, compared to a single shared backbone?
5.1
Experimental settings
Databases and benchmarks. We evaluate our approach on both standard Text-to-SQL benchmarks and a large-scale, enterpriseoriented benchmark. • Normal-scale databases. We evaluate on three widely used Text-to-SQL benchmarks: Spider [46], which contains 200 multi-table databases across 138 diverse domains; BIRD [25], which includes 95 databases totaling 33.4 GB from 37 professional domains; and KaggleDBQA [16], a cross-domain benchmark of real-world web databases with domain-specific data types, original formatting, and unrestricted questions. For BIRD, we use the development version bird_dev_20251106.
AV-SQL: Decomposing Complex Text-to-SQL Queries with Agentic Views
• Large-scale databases. To assess scalability on real-world schema, we evaluate on Spider2-Snow a Spider 2.0 [18] subtask with 547 complex questions designed for enterprisescale Text-to-SQL. Compared with standard academic benchmarks, it features much larger and more heterogeneous schemas, averaging about 800 columns per database, which makes schema understanding and SQL generation significantly more challenging. The Spider2-Snow requires generating SQL in the Snowflake dialect. Evaluation metrics. We evaluate model performance using Execution Accuracy (EX). EX measures whether the SQL query predicted by the model produces the same execution result as the groundtruth SQL when run on the target database, and we use it as the primary indicator of correctness. It is important to note that the definition of EX differs across benchmarks. Spider, BIRD and KaggleDBQA use strict execution evaluation, requiring an exact match to the gold result in both content and column order. In contrast, Spider 2.0-Snow is more lenient, requiring only that the returned result contain the core information of the gold answer, without enforcing column order or penalizing extra columns. LLM configurations. Experiments are conducted using several LLMs from closed-source flagship models (Gemini-3-Pro-Preview and GPT-5-Mini) and open-source models (Llama-3.3-70B and Qwen2.532B, short for Qwen2.5-Coder-32B). Unless otherwise specified, the decoding temperature is set to 1.0, with similarity thresholds 𝜏edit = 0.5 and 𝜏semantic = 0.5, and a maximum of 𝑇max = 5 execution feedback iterations. The token budget 𝐵 is set per model: 10,000 for Qwen2.5-32B, 20,000 for Llama-3.3-70B, 80,000 for GPT-5-Mini, and 100,000 for Gemini-3-Pro. Baselines. We compare our approach against representative Textto-SQL systems, including both existing frameworks and pretrained models such as CodeS [24], DIN-SQL [31], DAIL-SQL [12], and CHESS [37]. For Spider 2.0-Snow, we additionally include baselines specifically designed for Spider 2.0 [18], including SpiderAgent [18], AutoLink [43], DSR-SQL [14] and ReFoRCE [7].
5.2
Normal databases performance (RQ1)
To answer RQ1, AV-SQL is evaluated on three standard Text-toSQL benchmarks: BIRD, Spider, and KaggleDBQA. Table 3 reports Execution Accuracy (EX) on BIRD and Spider, comparing AV-SQL against both multi-candidate and single-candidate baselines, along with latency where available. AV-SQL with Gemini-3-Pro achieves the best BIRD result among single-candidate methods (72.16%) and competitive Spider accuracy (85.59%). With the same Qwen2.532B model, AV-SQL reaches 67.99% on BIRD, closely approaching Alpha-SQL-32B (69.70%)—a multi-candidate method with latency exceeding 1000s—while avoiding expensive candidate search. Table 4 and Table 5 break down performance by difficulty level on Spider and BIRD, respectively. On Spider, AV-SQL performs competitively on Easy and Medium questions while achieving strong results on Hard and Extra queries. On BIRD, AV-SQL with Gemini3-Pro attains the highest accuracy across all difficulty tiers. Notably, AV-SQL with open-source LLM (Qwen and Llama) outperforms both the fine-tuned CodeS model and the methods DAIL-SQL and MAC-SQL using closed-source GPT-4.
Table 3: Execution Accuracy (EX) of our approach compared to baselines on the Spider and BIRD benchmarks. Method Infer model BIRD↑ Spider↑ Latency(s)↓ Multi-candidate MCS-SQL [17] GPT-4 63.36 86.80 Alpha-SQL-7B [21] Qwen2.5-7B 66.80 84.00 >1000 Alpha-SQL-14B [21] Qwen2.5-14B 68.70 87.00 >1000 Alpha-SQL-32B [21] Qwen2.5-32B 69.70 >1000 XiyanSQL-32B [13] XiyanSQL-32B 73.34 CHESS [37] GPT-4 68.31 87.2 118.61 ZeroNL2SQL [9] GPT-4 84.00 Single-candidate DIN-SQL [31] GPT-4 50.72 82.80 24.09 DAIL-SQL [12] GPT-4 55.90 83.10 MAC-SQL [39] GPT-4 59.59 86.75 24.64 SFT Llama2-13B [38] Llama2-13B 53.91 81.60 CodeS-7B [24] CodeS-7B 57.17 85.40 1.87 CodeS-15B [24] CodeS-15B 58.47 84.90 3.52 XiyanSQL-32B [13] XiyanSQL-32B 66.88 XiyanSQL-7B [13] XiyanSQL-7B 60.10 LC-NL2SQL [5] Gemini-1.5-pro 67.41 87.10 12.3 AV-SQL 83.38 + Qwen2.5-32B 67.99 84.33 – + Llama 3.3-70B 68.19 83.66 – + Gemini-3-Pro 72.16 85.59 – Table 4: Execution Accuracy (EX) across different query hardness levels on the Spider benchmark. Method CodeS-7B [24] CodeS-15B [24] DIN-SQL(GPT-4) [31] DAIL-SQL(GPT-4) [12] Alpha-SQl-7B [21] Alpha-SQl-14B [21] AV-SQL +Qwen2.5-32B +Llama 3.3-70B +Gemini-3-Pro
Easy 94.80 95.60 92.30 91.50 94.00 94.00
Medium 91.00 90.40 87.40 90.10 89.20 91.00
Hard 75.30 78.20 76.40 75.30 76.40 79.90
Extra 66.90 61.40 62.70 62.70 63.30 72.30
90.73 91.13 90.32
90.13 85.43 86.55
79.31 82.76 89.08
64.46 68.67 72.29
Table 6 evaluates AV-SQL on KaggleDBQA, a more challenging out-of-domain benchmark. AV-SQL with Gemini-3-Pro attains 63.78% overall EX, outperforming all listed baselines. Notably, AV-SQL with the open-source LLaMA model also surpasses most baselines that rely on closed-source LLMs, including ZeroNL2SQL with GPT3.5, ZeroNL2SQL with GPT-4 and DIN-SQL with GPT-4.
5.3
Large scale database performance (RQ2)
To address RQ2 under more challenging conditions, we evaluate on Spider 2.0-Snow, which stress-tests text-to-SQL systems with substantially larger schemas and higher domain heterogeneity. Table 7 reports EX and average token usage on Spider 2.0-Snow. Standard methods such as CodeS-15B, DIN-SQL and LC-NL2SQL score 0.00%, as they are not designed to handle large-scale Snowflake databases. The recent method ReFoRCE [7] reach only ∼ 35%. AV-SQL substantially outperforms all baselines, achieving up to 70.38% EX with
Minh Tam Pham et al.
Method Simple Mod Chall DAIL-SQL(GPT-4) [12] 63.00 45.60 43.10 MAC-SQL(GPT-4) [39] 65.73 52.69 40.28 CodeS-7B [24] 64.60 46.90 40.30 CodeS-15B [24] 65.80 48.80 42.40 Alpha-SQL-7B [21] 72.60 59.30 53.10 Alpha-SQL-14B [21] 74.60 61.00 55.90 Alpha-SQL-32B [21] 74.50 64.00 57.20 AV-SQL +Qwen2.5-32B 72.37 64.44 52.41 +Llama 3.3-70B 72.91 62.28 57.93 +Gemini-3-Pro 76.60 67.46 60.69 Table 6: Execution Accuracy (EX) of our approach compared to baselines on the KaggleDBQA dataset. Method DIN-SQL(gpt-4) [31] Incremental ICL [9](gpt-3.5) RESDSQL [23] RAT-SQL [40] ZeroNL2SQL(gpt-4) [9] ZeroNL2SQL(gpt-3.5) [9] LC-NL2SQL [5](Gemini-1.5-Pro) AV-SQL +Llama 3.3-70B +Gemini-3-Pro
Easy 65.94
Medium 57.83
EX (%) Hard 64.86
Extra 50.81
All 27.00 34.60 31.90 13.56 42.40 44.90 61.10
65.96 72.34
56.00 58.00
57.14 67.35
30.77 56.41
53.51 63.78
Gemini-3-Pro, while consuming fewer tokens (92k) than DAILSQL (124k) and ReFoRCE (230k). This advantage holds consistently across different backbone models: using the same Qwen2.5-32B model, AV-SQL reaches 25.05% EX compared to 5.48% for SpiderAgent, demonstrating that AV-SQL consistently improves across different backbone LLMs. Table 8 further breaks down performance by difficulty level. Spider-Agent (o1-preview) degrades sharply across easy, medium, and hard splits (39.84%, 21.14%, 15.61%), whereas AV-SQL with Gemini3-Pro maintains consistently high accuracy (74.22%, 72.36%, 64.74%). The performance gap widens significantly on harder queries, demonstrating AV-SQL’s stronger handling of compositional reasoning challenges in large-schema settings.
5.4
Multi-Candidate SQL Generation (RQ3)
To answer RQ3, AV-SQL is evaluated in a multi-candidate setting on Spider2-Snow, where the SQL generation agent is prompted to output 𝑘 candidate queries. Performance is measured using recall Execution Accuracy, which considers a question correctly answered if at least one of the 𝑘 generated candidates is executable correct. As shown in Fig. 4, increasing 𝑘 yields consistent gains for both backbones: Gemini-3-Pro improves from 70.38% at 𝑘=1 to 74.77% at 𝑘=16, while GPT-5-mini rises from 65.08% to 74.00% over the same range. These results indicate that generating more candidates increases the chance of producing at least one correct SQL query, improving robustness on challenging large-schema queries. This
Table 7: Execution Accuracy (EX) on Spider 2.0-Snow. Values in parentheses mark cases where the score reported in the published paper differs substantially from the official leaderboard; the parenthesized number corresponds to the leaderboard score. Method SFT CodeS-15B [24] DIN-SQL [31] CHESS [37] DAIL-SQL [12] LC-NL2SQL [5] Spider-Agent [18] Spider-Agent [18] Spider-Agent [18] Spider-Agent [18] ReFoRCE [7] ReFoRCE [7] AutoLink [43] DSR-SQL [14] AV-SQL + + + +
Infer model EX↑ Avg Tokens↓ CodeS-15B 0.00 – GPT-4o 0.00 32k GPT-4o 1.28 – GPT-4o 2.20 124k gpt-5-mini 0.00 – Qwen2.5-32B 5.48 – GPT-4o 12.98 – o3-mini 19.20 – o1-preview 23.58 – o1-preview 31.26 ≈230k o3 35.83 (62.89) ≈230k DeepSeek-R1 34.92 (54.84) – DeepSeek-R1 35.28 (63.80) – 92k Qwen2.5-32B 25.05 – Llama3.3-70B 27.42 – gpt-5-mini 65.08 – Gemini-3-Pro 70.38 –
Table 8: Execution Accuracy (EX) by difficulty level (easy/medium/hard) on Spider2-snow dataset Method Infer model Spider-Agent [18] + o1-preview + o3-mini + GPT-4o + Qwen2.5-32B AV-SQL + Qwen2.5-32B + Llama3.3-70B + Gpt-5-mini + Gemini-3-Pro
Easy Medium Hard 39.84 31.25 24.22 4.47
21.14 15.61 18.29 11.56 11.38 6.94 2.31 5.48
39.84 38.28 75.78 74.22
24.39 32.11 68.29 72.36
75 Recall EX(%)
Table 5: Execution Accuracy (EX) on BIRD dev set by difficulty level. For brevity, the abbreviation ”Mod” stands for ”Moderate” while ”Chall” denotes ”Challenging”
70.38
70
71.12
70.77
68.01
65
65.08
0
65.99
2
15.03 12.71 52.60 64.74
72.58 71.85
74.77 74.00
gpt-5-mini gemini-3-pro
4 8 No. Candidate
16
Figure 4: Recall Execution Accuracy on the Spider2.0-Snow benchmark under the multi-candidate setting. suggests that incorporating a candidate selector into the multicandidate setting–one that reliably identifies the correct query among candidates–could further improve overall performance.
AV-SQL: Decomposing Complex Text-to-SQL Queries with Agentic Views
Table 9: Ablation study of major pipeline component–rewriter, planner, revisor, and execution feedback (exe feedback)– measured by Execution Accuracy (EX) across Spider2-Snow, Spider, BIRD, and KaggleDBQA. Llama-3.3 denotes Llama-3.3-70B. Spider-2-snow Spider BIRD KaggleDBQA GPT-5-mini Gemini-3-Pro Llama-3.3 Gemini-3-Pro Llama-3.3 Gemini-3-Pro Llama-3.3 Gemini-3-Pro w/o rewriter 57.22 64.90 78.34 84.53 65.45 71.64 48.65 62.16 w/o exe feedback (SQL) 50.82 63.99 80.33 84.91 64.54 71.77 51.35 61.62 w/o exe feedback (CTE+SQL) 41.68 57.77 79.01 84.77 64.47 70.90 50.81 61.08 55.76 63.99 79.40 84.62 65.97 72.23 54.05 61.62 w/o planner w/o reviseSQL 60.15 65.08 82.50 87.14 67.47 72.82 54.59 65.41 All components 65.08 70.38 83.66 85.59 68.19 72.16 53.51 63.78 Setting
Table 10: Ablation study on the contribution of each output from the Agent View Generation stage – (VCTE ) and (Sfiltered ) – to SQL generation performance (EX) across Spider2-Snow, Spider, BIRD, and KaggleDBQA. Llama-3.3 denotes Llama-3.3-70B. Spider2-snow Spider BIRD KaggleDBQA GPT-5-mini Gemini-3-Pro Llama-3.3 Gemini-3-Pro Llama-3.3 Gemini3-Pro Llama3.3 Gemini3-Pro Aggregated Validated Agent Views (VCTE ) 58.68 64.72 79.83 85.42 67.41 71.64 51.89 62.70 Global Schema Selection (Sfiltered ) 57.59 63.25 79.57 84.72 65.71 71.77 50.27 61.62 All outputs (VCTE + Sfiltered ) 65.08 70.38 83.66 85.59 68.19 72.16 53.51 63.78 Information provided
5.5
Ablation study (RQ4)
Component contribution. To answer the first aspect of RQ4, a controlled ablation is conducted by disabling one component at a time—the rewriter, planner, revisor, and execution feedback for the view generator and SQL generator—while keeping all others intact. Table 9 shows that the full pipeline consistently outperforms all ablated variants across Spider2.0-Snow, Spider, BIRD, and KaggleDBQA. Removing execution feedback from both CTE and SQL generation causes the largest drops, with Gemini-3-Pro falling from 70.38% to 57.77% and GPT-5-mini from 65.08% to 41.68% on Spider2.0-Snow, confirming that multi-stage correction is critical for preventing error propagation. Notably, removing the revisor yields marginal improvements on Spider, BIRD, and KaggleDBQA (e.g., Gemini3-Pro: 85.59% → 87.14%, 72.16% → 72.82%, 63.78% → 65.41%). the strict EX metric in these benchmarks requires an exact match of execution results in both content and column order (see §5.1), meaning the revisor’s edits—such as adding or removing columns— can cause a semantically correct query to be marked incorrect due to minor output differences. Overall, these results confirm that each component contributes to final performance, with execution feedback playing the most critical role in large-schema settings. View Generation Output Contribution. To answer the second aspect of RQ4, this experiment isolates the contribution of each output from the View Generation stage to final SQL generation: (i) Aggregated Validated Agent Views (VCTE ) and (ii) Global Schema Selection (Sfiltered ) As shown in Table 10, combining both outputs consistently achieves the highest accuracy across all datasets and backbones. Consistent gains appear on Spider, BIRD, KaggleDBQA, and Spider2.0-Snow, confirming that schema selection and executable intermediate agent views are complementary and jointly necessary for accurate SQL generation.
5.6
Schema Filtering (RQ5)
To answer RQ5, this experiment evaluates schema filtering quality by measuring precision and recall of schema elements selected by each method. Precision measures whether selected elements
are correct (few false positives), while recall measures whether all relevant elements are captured (few false negatives). Three baseline strategies are compared: (i) MACSQL [39], which prompts the model with the full schema to return relevant tables and columns; (ii) CHESS [37], which evaluates table relevance one at a time before selecting columns from relevant tables; and (iii) an encoder– decoder schema selector [24], which predicts relevant schema items from the question and schema as input. As shown in TaTable 11: Precision and recall of schema filtering across methods and inference models in Spider2-snow dataset. Method Infer model Precision Recall MACSQL [39] + Qwen2.5 62.00 63.88 + Llama 3.3 68.30 68.91 + GPT-5-Mini 59.41 79.22 + Gemini-3-Pro 70.62 86.45 CHESS [37] + Qwen2.5 49.03 77.78 + Llama 3.3 27.99 76.70 + GPT-5-Mini 27.50 91.12 + Gemini-3-Pro 36.87 90.58 Encoder-Decoder [24] 41.50 79.60 CTE generation in AV-SQL + Qwen2.5 69.74 69.27 + Llama 3.3 77.76 74.67 + GPT-5-Mini 81.41 82.70 + Gemini-3-Pro 86.34 81.59
ble 11, CHESS achieves high recall (90.58–91.12%) but low precision (27.50–36.87%), indicating excessive false positives. MACSQL achieves a better balance (59.41–70.62% precision, 63.88–86.45% recall), while the encoder–decoder baseline yields 41.50% precision and 79.60% recall. AV-SQL’s CTE generation achieves the highest precision across all backbones (81.41–86.34% with proprietary models; 69.74–77.76% with open-weight models) while maintaining competitive recall (81.59–82.70%), confirming that CTE-based intermediate reasoning produces cleaner and more reliable schema filtering than prompting or learned approaches.
Minh Tam Pham et al.
5.7
5.9
Component cost analysis (RQ6)
To answer RQ6, Fig. 5 presents the token usage and runtime breakdown per pipeline agent for AV-SQL with Gemini-3-Pro on Spider2.0Snow. The view generator agent dominates both dimensions, con-
Running Time
Step
55.5%
71.3%
77.2%
0.79% 1.04% 5.2% 1.85% 8.0% 5.9% 2.4% 5.7% 2.5% 5.9%3.4%
Token Usage 7.0%
3.9% 7.8%
15.8% 17.1%
Rewriter View Generator Planner SQL Generator Revisor
Token type Input Output
Figure 5: Token usage and runtime breakdown by pipeline agent for AV-SQL with Gemini-3-Pro on Spider2.0-snow. The left nested donut chart shows the proportion of token usage, while the right pie chart shows the proportion of total runtime spent on each agent. suming 77.2% of total tokens (71.3% input, 5.9% output) and 55.5% of total runtime, reflecting the cost of processing multiple schema chunks with iterative validation. The SQL generator and revisor agents account for 8.4% and 7.0% of token usage, and 17.1% and 15.8% of runtime, respectively. The planner contributes 5.9% of tokens and 7.8% of runtime, while the rewriter is the lightest stage at 1.83% of tokens and 3.9% of runtime. Overall, the cost profile is heavily concentrated in the view generation agent, which is expected given its role as the core intermediate reasoning, schema exploration and schema filtering component, while the remaining agents impose relatively modest overhead.
5.8
Error Analysis (RQ7)
To answer RQ7, a human evaluation is conducted on the failure cases of AV-SQL with Gemini-3-Pro on Spider2-Snow. Filtering 36.2%
Aggregation 34.1%
Table 12: Execution Accuracy (EX) on Spider2-Snow under hybrid LLM configurations, where different backbone models are assigned to different agents. Rewriter
Schema 10.9% Other 2.9%
Figure 6: Error taxonomy of AV-SQL with Gemini-3-Pro on Spider2-snow. Fig. 6 shows the resulting error taxonomy. Filtering (36.2%) and aggregation (34.1%) errors dominate, together accounting for over 70% of failures, indicating that complex filter conditions and aggregation logic over large schemas remain the primary challenges. Schema errors contribute 10.9%, while syntax errors account for only 9.4%, confirming that execution feedback effectively suppresses most malformed queries. The remaining errors correspond to lacking ground truth (6.5%) and miscellaneous cases (2.9%). These results suggest that future work should prioritize more precise filter and aggregation reasoning.
View Gen.
Planner
SQL Generation SQL Gen. Revisor
EX↑
Homogeneous Llama-3.3 Llama-3.3 Llama-3.3 Llama-3.3 Llama-3.3 27.42 GPT-5-mini GPT-5-mini GPT-5-mini GPT-5-mini GPT-5-mini 65.08 Gemini-3-Pro Gemini-3-Pro Gemini-3-Pro Gemini-3-Pro Gemini-3-Pro 70.38 Hybrid Llama-3.3 Llama-3.3 Llama-3.3 GPT-5-mini GPT-5-mini 40.40 GPT-5-mini Llama-3.3 GPT-5-mini GPT-5-mini GPT-5-mini 42.96 Gemini-3-Pro Llama-3.3 Gemini-3-Pro Gemini-3-Pro Gemini-3-Pro 55.21 Gemini-3-Pro GPT-5-mini Gemini-3-Pro Gemini-3-Pro Gemini-3-Pro 61.60
backbones achieve the best results, all-GPT-5-mini 65.08%, and allGemini-3-Pro 70.38% on Spider2-Snow. Replacing only the SQL generation stage with a stronger model while retaining Llama-3.3 for the rewriter and CTE generator improves performance from 27.42% to 40.40%, demonstrating that a stronger SQL generator can better exploit the filtered context produced by the CTE stage. This is also cost-efficient, since the CTE generation stage dominates token usage §5.7, meaning the expensive backbone is only applied where it matters most. However, mixing backbones does not consistently improve performance: using Gemini-3-Pro for the rewriter and CTE generator but GPT-5-mini for view generation yields only 61.60%, falling below the homogeneous GPT-5-mini baseline (65.08%), suggesting that misalignment between the CTE generator and SQL generator can degrade performance even when individual components are strong.
6 Syntax 9.4% Ground truth 6.5%
Hybrid LLM configuration (RQ8)
To answer RQ8, Table 12 evaluates the effect of assigning different LLM backbones to different agents, compared to a single unified backbone. Homogeneous configurations with strong LLM
CONCLUSIONS
This paper presents AV-SQL, a multi-agent Text-to-SQL framework designed for robust SQL generation across both standard and largescale database settings. AV-SQL decomposes the generation process into three stages: (1) Question Rewriting rewrites the input question (and optional external knowledge) into a clearer and more concise form; (2) Agent View Generation processes schema chunks, producing validated CTE-based agent views and a global schema selection; and (3) SQL Generation composes the validated agent views and filtered schema to generate the final executable SQL query. Extensive experiments demonstrate that AV-SQL achieves competitive or state-of-the-art execution accuracy across Spider, BIRD, KaggleDBQA, and Spider2.0-Snow. Notably, on Spider2.0-Snow, where large schemas pose significant challenges to conventional pipelines, AV-SQL achieves 70.38% EX with Gemini-3-Pro, surpassing the previous methods and proving that processing schema chunks into verifiable intermediate views provides a highly scalable solution. Future work will focus on enhancing reasoning mechanisms for complex filtering and aggregation, which remain our primary sources of error. Additionally, we aim to integrate robust candidate selection and optimize heterogeneous LLM alignments to further improve performance and cost-efficiency.
AV-SQL: Decomposing Complex Text-to-SQL Queries with Agentic Views
REFERENCES [1] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 (2023). [2] Scott Barnett, Stefanus Kurniawan, Srikanth Thudumu, Zach Brannelly, and Mohamed Abdelrazek. 2024. Seven failure points when engineering a retrieval augmented generation system. In CAIN. 194–199. [3] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020. Language models are few-shot learners. NeurIPS 33 (2020), 1877–1901. [4] Ruisheng Cao, Lu Chen, Zhi Chen, Yanbin Zhao, Su Zhu, and Kai Yu. 2021. LGESQL: Line Graph Enhanced Text-to-SQL Model with Mixed Local and NonLocal Relations. In IJCNLP. 2541–2555. [5] Yeounoh Chung, Gaurav T Kakkar, Yu Gan, Brenton Milne, and Fatma Ozcan. 2025. Is long context all you need? leveraging LLM’s extended context for NL2SQL. PVLDB 18, 8 (2025), 2735–2747. [6] Mayur Datar, Nicole Immorlica, Piotr Indyk, and Vahab S Mirrokni. 2004. Localitysensitive hashing scheme based on p-stable distributions. In SoCG. 253–262. [7] Minghang Deng, Ashwin Ramachandran, Canwen Xu, Lanxiang Hu, Zhewei Yao, Anupam Datta, and Hao Zhang. 2025. Reforce: A Text-to-SQL agent with selfrefinement, format restriction, and column exploration. In ICLR 2025 Workshop: VerifAI: AI Verification in the Wild. [8] Xuemei Dong, Chao Zhang, Yuhang Ge, Yuren Mao, Yunjun Gao, Jinshu Lin, Dongfang Lou, et al. 2023. C3: Zero-shot text-to-sql with chatgpt. arXiv preprint arXiv:2307.07306 (2023). [9] Ju Fan, Zihui Gu, Songyue Zhang, Yuxin Zhang, Zui Chen, Lei Cao, Guoliang Li, Samuel Madden, Xiaoyong Du, and Nan Tang. 2024. Combining small language models and large language models for zero-shot NL2SQL. PVLDB 17, 11 (2024), 2750–2763. [10] Catherine Finegan-Dollak, Jonathan K Kummerfeld, Li Zhang, Karthik Ramanathan, Sesh Sadasivam, Rui Zhang, and Dragomir Radev. 2018. Improving text-to-sql evaluation methodology. arXiv preprint arXiv:1806.09029 (2018). [11] Han Fu, Chang Liu, Bin Wu, Feifei Li, Jian Tan, and Jianling Sun. 2023. Catsql: Towards real world natural language to sql applications. PVLDB 16, 6 (2023), 1534–1547. [12] Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, and Jingren Zhou. 2024. Text-to-sql empowered by large language models: A benchmark evaluation. PVLDB 17, 5 (2024), 1132–1145. [13] Yingqi Gao, Yifu Liu, Xiaoxia Li, Xiaorong Shi, Yin Zhu, Yiming Wang, Shiqi Li, Wei Li, Yuntao Hong, Zhiling Luo, et al. 2024. XiYan-SQL: A Multi-Generator Ensemble Framework for Text-to-SQL. arXiv preprint arXiv:2411.08599 (2024). [14] Zhifeng Hao, Qibin Song, Ruichu Cai, and Boyan Xu. 2025. Text-to-SQL as Dual-State Reasoning: Integrating Adaptive Context and Progressive Generation. arXiv preprint arXiv:2511.21402 (2025). [15] Kelly Hong, Anton Troynikov, and Jeff Huber. 2025. Context rot: How increasing input tokens impacts llm performance. Technical Report. Chroma. https:// trychroma.com/research/context-rot [16] Chia-Hsuan Lee, Oleksandr Polozov, and Matthew Richardson. 2021. KaggleDBQA: Realistic evaluation of text-to-SQL parsers. In IJCNLP. 2261–2273. [17] Dongjun Lee, Choongwon Park, Jaehyuk Kim, and Heesoo Park. 2025. Mcssql: Leveraging multiple prompts and multiple-choice selection for text-to-sql generation. In COLING. 337–353. [18] Fangyu Lei, Jixuan Chen, Yuxiao Ye, Ruisheng Cao, Dongchan Shin, Hongjin Su, Zhaoqing Suo, Hongcheng Gao, Wenjing Hu, Pengcheng Yin, et al. 2024. Spider 2.0: Evaluating language models on real-world enterprise text-to-sql workflows. arXiv preprint arXiv:2411.07763 (2024). [19] Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, et al. 2020. Retrieval-augmented generation for knowledge-intensive nlp tasks. NeurIPS 33 (2020), 9459–9474. [20] Boyan Li, Yuyu Luo, Chengliang Chai, Guoliang Li, and Nan Tang. 2024. The dawn of natural language to sql: Are we fully ready? PVLDB 17, 11 (July 2024), 3318–3331. [21] Boyan Li, Jiayi Zhang, Ju Fan, Yanwei Xu, Chong Chen, Nan Tang, and Yuyu Luo. 2025. Alpha-sql: Zero-shot text-to-sql using monte carlo tree search. arXiv preprint arXiv:2502.17248 (2025). [22] Fei Li and Hosagrahar V Jagadish. 2014. Constructing an interactive natural language interface for relational databases. PVLDB 8, 1 (2014), 73–84. [23] Haoyang Li, Jing Zhang, Cuiping Li, and Hong Chen. 2023. Resdsql: Decoupling schema linking and skeleton parsing for text-to-sql. In AAAI, Vol. 37. 13067– 13075. [24] Haoyang Li, Jing Zhang, Hanbing Liu, Ju Fan, Xiaokang Zhang, Jun Zhu, Renjie Wei, Hongyan Pan, Cuiping Li, and Hong Chen. 2024. Codes: Towards building open-source language models for text-to-sql. PACMMOD 2, 3 (2024), 1–28.
[25] Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, Binhua Li, Bowen Li, Bailin Wang, Bowen Qin, Ruiying Geng, Nan Huo, et al. 2024. Can llm already serve as a database interface? a Modeling Ambiguityse grounded text-to-sqls. NeurIPS 36 (2024), 42330–42357. [26] Sheng-Chieh Lin, Akari Asai, Minghan Li, Barlas Oguz, Jimmy Lin, Yashar Mehdad, Wen-tau Yih, and Xilun Chen. 2023. How to train your dragon: Diverse augmentation towards generalizable dense retrieval. arXiv preprint arXiv:2302.07452 (2023). [27] Aiwei Liu, Xuming Hu, Lijie Wen, and Philip S Yu. 2023. A comprehensive evaluation of ChatGPT’s zero-shot Text-to-SQL capability. arXiv preprint arXiv:2303.13547 (2023). [28] Xinyu Liu, Shuyu Shen, Boyan Li, Peixian Ma, Runzhi Jiang, Yuxin Zhang, Ju Fan, Guoliang Li, Nan Tang, and Yuyu Luo. 2025. A survey of text-to-sql in the era of llms: Where are we, and where are we going? TKDE (2025). [29] Yuyu Luo, Guoliang Li, Ju Fan, Chengliang Chai, and Nan Tang. 2025. Natural language to sql: State of the art and open problems. PVLDB 18, 12 (2025), 5466– 5471. [30] Mohammadreza Pourreza, Hailong Li, Ruoxi Sun, Yeounoh Chung, Shayan Talaei, Gaurav Tarlok Kakkar, Yu Gan, Amin Saberi, Fatma Ozcan, and Sercan O Arik. 2024. Chase-sql: Multi-path reasoning and preference optimized candidate selection in text-to-sql. arXiv preprint arXiv:2410.01943 (2024). [31] Mohammadreza Pourreza and Davood Rafiei. 2023. DIN-SQL: Decomposed InContext Learning of Text-to-SQL with Self-Correction. In NeurIPS. 36339–36348. [32] Mohammadreza Pourreza and Davood Rafiei. 2024. Dts-sql: Decomposed textto-sql with small large language models. arXiv preprint arXiv:2402.01117 (2024). [33] Jiexing Qi, Jingyao Tang, Ziwei He, Xiangpeng Wan, Yu Cheng, Chenghu Zhou, Xinbing Wang, Quanshi Zhang, and Zhouhan Lin. 2022. RASAT: Integrating Relational Structures into Pretrained Seq2Seq Model for Text-to-SQL. In EMNLP. 3215–3229. [34] Nitarshan Rajkumar, Raymond Li, and Dzmitry Bahdanau. 2022. Evaluating the text-to-sql capabilities of large language models. arXiv preprint arXiv:2204.00498 (2022). [35] Nils Reimers and Iryna Gurevych. 2019. Sentence-bert: Sentence embeddings using siamese bert-networks. In EMNLP-IJCNLP. 3982–3992. [36] Aaditya Singh, Adam Fry, Adam Perelman, Adam Tart, Adi Ganesh, Ahmed El-Kishky, Aidan McLaughlin, Aiden Low, AJ Ostrow, Akhila Ananthram, et al. 2025. OpenAI GPT-5 System Card. arXiv preprint arXiv:2601.03267 (2025). [37] Shayan Talaei, Mohammadreza Pourreza, Yu-Chen Chang, Azalia Mirhoseini, and Amin Saberi. 2024. CHESS: Contextual Harnessing for Efficient SQL Synthesis. arXiv preprint arXiv:2405.16755 (2024). [38] Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yasmine Babaei, Nikolay Bashlykov, Soumya Batra, Prajjwal Bhargava, Shruti Bhosale, et al. 2023. Llama 2: Open foundation and fine-tuned chat models. arXiv preprint arXiv:2307.09288 (2023). [39] Bing Wang, Changyu Ren, Jian Yang, Xinnian Liang, Jiaqi Bai, Linzheng Chai, Zhao Yan, Qian-Wen Zhang, Di Yin, Xing Sun, et al. 2024. Mac-sql: A multi-agent collaborative framework for text-to-sql. arXiv preprint arXiv:2312.11242 (2024). [40] Bailin Wang, Richard Shin, Xiaodong Liu, Oleksandr Polozov, and Matthew Richardson. 2020. RAT-SQL: Relation-Aware Schema Encoding and Linking for Text-to-SQL Parsers. In ACL. 7567–7578. [41] Liang Wang, Nan Yang, Xiaolong Huang, Binxing Jiao, Linjun Yang, Daxin Jiang, Rangan Majumder, and Furu Wei. 2022. Text embeddings by weakly-supervised contrastive pre-training. arXiv preprint arXiv:2212.03533 (2022). [42] Wenhui Wang, Furu Wei, Li Dong, Hangbo Bao, Nan Yang, and Ming Zhou. 2020. Minilm: Deep self-attention distillation for task-agnostic compression of pre-trained transformers. NeurIPS 33 (2020), 5776–5788. [43] Ziyang Wang, Yuanlei Zheng, Zhenbiao Cao, Xiaojin Zhang, Zhongyu Wei, Pei Fu, Zhenbo Luo, Wei Chen, and Xiang Bai. 2025. AutoLink: Autonomous Schema Exploration and Expansion for Scalable Schema Linking in Text-to-SQL at Scale. arXiv preprint arXiv:2511.17190 (2025). [44] Peng Xu, Wei Ping, Xianchao Wu, Lawrence McAfee, Chen Zhu, Zihan Liu, Sandeep Subramanian, Evelina Bakhturina, Mohammad Shoeybi, and Bryan Catanzaro. 2023. Retrieval meets long context large language models. arXiv preprint arXiv:2310.03025 (2023). [45] Navid Yaghmazadeh, Yuepeng Wang, Isil Dillig, and Thomas Dillig. 2017. Sqlizer: query synthesis from natural language. PACMPL 1 (2017), 1–26. [46] Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, Dongxu Wang, Zifan Li, James Ma, Irene Li, Qingning Yao, Shanelle Roman, Zilin Zhang, and Dragomir Radev. 2018. Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task. In EMNLP. 3911–3921. [47] Yusen Zhang, Ruoxi Sun, Yanfei Chen, Tomas Pfister, Rui Zhang, and Sercan Arik. 2024. Chain of agents: Large language models collaborating on long-context tasks. NeurIPS 37 (2024), 132208–132237. [48] Victor Zhong, Caiming Xiong, and Richard Socher. 2017. Seq2sql: Generating structured queries from natural language using reinforcement learning. arXiv preprint arXiv:1709.00103 (2017).