PaperlayerView exact revision on arXiv

Source-linked AI summary

AutoLink: Autonomous Schema Exploration and Expansion for Scalable Schema Linking in Text-to-SQL at Scale

Ziyang Wang, Yuanlei Zheng, Zhenbiao Cao, Xiaojin Zhang, Zhongyu Wei, Pei Fu, Zhenbo Luo, Wei Chen, Xiang Bai

arXiv:2511.17190v1cs.CLcs.DB

TL;DR

Large-schema text-to-SQL makes full-schema input impractical, while existing linking approaches struggle with scalability and the recall–noise trade-off. AutoLink uses an LLM-guided agent to iteratively explore and expand a relevant schema subset without inputting the full schema. It reports state-of-the-art strict recall on Bird and Spider 2.0-Lite, alongside competitive execution accuracy and scalability on large schemas.

  • Problem

    Full-schema input can add irrelevant noise and exceed context windows, while existing schema-linking methods face scalability costs and a recall–noise trade-off.

    Source: Introduction · p. 1, Related Work · p. 2

  • Method

    AutoLink uses an LLM-guided agent to iteratively explore and expand the linked schema subset without requiring the full database schema as input.

    Source: Introduction · p. 1

  • Results

    AutoLink achieves state-of-the-art strict recall on Bird and Spider 2.0-Lite, including 91.2% on Spider 2.0-Lite, with competitive execution accuracy.

    Source: Introduction · p. 2, Conclusion · p. 8

  • Takeaways & Limitations

    AutoLink provides a practical, efficient foundation for industrial text-to-SQL, with robustness and scalability on schemas containing thousands of columns.

    Source: Conclusion · p. 8

    Increasing decoding rounds eventually yields marginal recall gains while token consumption continues to rise.

    Source: Limitations of Increasing Decoding… · p. 16

Abstract

from arXiv · show

For industrial-scale text-to-SQL, supplying the entire database schema to Large Language Models (LLMs) is impractical due to context window limits and irrelevant noise. Schema linking, which filters the schema to a relevant subset, is therefore critical. However, existing methods incur prohibitive costs, struggle to trade off recall and noise, and scale poorly to large databases. We present \textbf{AutoLink}, an autonomous agent framework that reformulates schema linking as an iterative, agent-driven process. Guided by an LLM, AutoLink dynamically explores and expands the linked schema subset, progressively identifying necessary schema components without inputting the full database schema. Our experiments demonstrate AutoLink's superior performance, achieving state-of-the-art strict schema linking recall of \textbf{97.4\%} on Bird-Dev and \textbf{91.2\%} on Spider-2.0-Lite, with competitive execution accuracy, i.e., \textbf{68.7\%} EX on Bird-Dev (better than CHESS) and \textbf{34.9\%} EX on Spider-2.0-Lite (ranking 2nd on the official leaderboard). Crucially, AutoLink exhibits \textbf{exceptional scalability}, \textbf{maintaining high recall}, \textbf{efficient token consumption}, and \textbf{robust execution accuracy} on large schemas (e.g., over 3,000 columns) where existing methods severely degrade-making it a highly scalable, high-recall schema-linking solution for industrial text-to-SQL systems.

Introduction

Large schemas make text-to-SQL harder by adding irrelevant context and straining model context windows, while existing schema-linking approaches face scalability and recall–noise trade-offs. AutoLink instead iteratively discovers relevant schema elements through an LLM-guided agent, with experiments reporting high recall and competitive execution accuracy.

Introduction

  • Supplying full schemas adds irrelevant noise and risks exceeding context windows, while schema linking must balance recall against noise and cost.Missing essential schema elements can limit the upper bound of SQL-generation accuracy.Source: Introduction · p. 1
  • 91.2% strict recall on Spider 2.0-Lite accompanies competitive execution accuracy of 34.92% on Spider 2.0-Lite and 68.71% on Bird.The introduction also reports the lowest average token usage across database scales and less than half the tokens of leading approaches on Spider 2.0-Lite.Source: Introduction · p. 2

Related Work

  • Industrial schema linking faces context and computation bottlenecks, and high-recall retrieval can return enough candidates to restore noise and token costs.Prior work includes element-level scoring, database-level reasoning, graph modeling, and dual-encoder retrieval.Source: Related Work · p. 2

Method

  • AutoLink reframes schema linking as sequential discovery by an LLM agent that expands a relevant schema subset without seeing the full schema.The agent interacts with environments for database exploration and semantic schema search.Source: Method · p. 2

External Environment E

  • The pre-built environment pairs live SQL-based database exploration with a vector store that supports semantic column search.The vector store indexes column metadata, and its search avoids columns already retrieved.Source: External Environment E · p. 2

Agent-Environment Interaction

  • The initial linked schema comes from a broad question-based retrieval, then the agent updates it over multiple turns until it stops.The initial retrieval uses a relatively large n, such as 50 or 100, to provide structural context while remaining potentially incomplete.Source: Agent-Environment Interaction · pp. 3–4

Action Space and Agentic Schema Linking

  • The agent explores schema metadata, retrieves targeted missing columns, verifies sufficiency with SQL, and commits relevant discoveries to the linked schema.The paper particularly encourages adding schema returned by targeted retrieval.Source: Action Space and Agentic Schema Linking · p. 4

SQL Generation

  • SQL generation is a separate downstream stage that uses the question and final linked schema to sample, correct, and vote across candidate queries.The paper uses an existing LLM as the SQL-generation policy rather than treating generation as its core focus.Source: SQL Generation · p. 4

Experiment

Across Bird Dev and Spider 2.0-Lite, AutoLink achieves strong schema-linking results and maintains performance as database size grows. Experiments also examine downstream SQL execution accuracy, agent actions, and sensitivity to initial retrieval size.

Implementation Details

  • The experiments use DeepSeek-V3 as AutoLink’s schema-linking policy, vary initial top-n from 5 to 100, set top-m to 3, and cap interaction at 10 turns.Bird Dev has 11 databases averaging 80 columns and 1,543 cases; Spider 2.0-Lite averages over 800 columns per database and has 547 test cases.Source: Implementation Details · pp. 4–5

Main Results of Schema Linking

  • On Spider 2.0-Lite, AutoLink improves strict recall rate by 27.2% over SQL-to-Schema and reduces maximum token consumption by 87.7%.The comparison uses DeepSeek-V3 for models other than DE-SL and CE-SL; initial top-n is 100 on Spider 2.0-Lite and 30 on Bird Dev.Source: Main Results of Schema Linking · p. 5, Table 1 · p. 5

Results of SQL Generation

  • AutoLink attains 34.92% EX on Spider 2.0-Lite with DeepSeek-R1 and 68.71% EX on Bird Dev with Gemini-1.5-Pro.On Spider 2.0-Lite, ReFoRCE scores 37.84% EX with GPT-o3; AutoLink uses 38.0K average tokens versus ReFoRCE’s 81.1K, with five versus eight candidate SQL queries.Source: Results of SQL Generation · p. 6, Table 2 · p. 6, Table 3 · p. 6

Ablation Study

  • Removing any of @retrieve schema, @explore schema, or @verify schema lowers SRR across initial top-5, top-50, and top-100 settings.Removing schema retrieval has the largest impact; omitting verification causes a smaller but consistent decrease.Source: Ablation Study · p. 6, Table 4 · p. 6

Scalability Analysis of Different Database Scales

  • Above 3,000 columns, baseline SRR falls below 40%, while AutoLink remains near 90% and uses the fewest average tokens across database sizes.All methods’ SRR declines as database size grows, but AutoLink’s decline is slower; it also achieves the highest EX across size ranges.Source: Scalability Analysis of Different… · p. 7, Figure 2 · p. 7

Analysis of Hyperparameter

  • Across varying initial top-n settings, AutoLink consistently outperforms BGE Large in SRR and BGE in Spider 2.0-Lite EX.Increasing top-n improves SRR for both methods, while AutoLink’s EX gains plateau at high top-n; its advantage is most pronounced when initial retrieval is small.Source: Analysis of Hyperparameter · p. 7, Figure 3 · p. 7

Conclusion

AutoLink reframes schema linking as an adaptive, agent-driven process that uses semantic retrieval and lightweight SQL probes to iteratively assemble needed schema elements without requiring the full database schema as input.

  • Semantic retrieval from a vector store and lightweight SQL probes are AutoLink’s paired mechanisms.Source: Conclusion · p. 7
  • AutoLink’s LLM-powered agent iteratively assembles only the schema elements needed for a query without taking the full database schema as input.Source: Conclusion · p. 8
  • AutoLink achieves state-of-the-art strict recall on Spider 2.0-Lite and Bird while reducing token usage and demonstrating scalability and robustness on schemas with thousands of columns.Source: Conclusion · p. 8

Details of Environment Construction

AutoLink’s environments support iterative schema retrieval and verification, with controls on database-query execution and a vector store designed to handle large and partitioned schemas.

Details of Environment Construction

  • Database queries return at most five rows and are capped at 120 seconds, with structured feedback for successful queries, empty results, errors, or timeouts.Source: Details of Environment Construction · p. 11
  • The algorithm starts with top-n retrieved columns, then iterates over agent actions to explore or verify with SQL, retrieve more schema, add schema elements, or stop.The resulting linked schema is passed to SQL generation.Source: Details of Environment Construction · p. 11
  • Merging tables with identical column schemas reduces redundant vector-store entries; Spider 2.0-Lite databases then average 559 columns, versus as many as 100,000 without merging.After merging, the maximum is 6,161 columns.Source: Details of Environment Construction · p. 12
  • The vector store indexes column metadata as 1,024-dimensional embeddings and retrieves semantically similar columns using approximate-nearest-neighbor search.Query encoding and retrieval take an average of 0.05 seconds on one H800 GPU; setup averages 1.4 seconds per Spider 2.0-Lite database and 0.4 seconds per BIRD database.Source: Details of Environment Construction · p. 12

Details of Action Space

  • The @explore schema action uses exploratory SQL to inspect value distributions and schema structure, including checking values, sampling data, and examining ranges.The action-space discussion also describes metadata queries for finding relevant tables or columns.Source: Details of Action Space · p. 13

8 SELECT date, timestamp, time

The examples illustrate exploratory SQL for inspecting table data, date ranges, and database metadata.

  • A MIN(date), MAX(date) query examines the observed range of a date column.Source: §8 · p. 13
  • INFORMATION_SCHEMA and PRAGMA are described as metadata routes for inspecting schema details, with support varying by database system.Source: §8 · p. 13
  • Sampling rows with SELECT * is presented as a way to observe column types and data patterns.Source: §8 · p. 13

6 SELECT column_name

The examples show metadata queries for finding columns by name and filtering on table and column attributes.

  • A metadata search targets columns whose names match a term such as “trips.”Source: §6 · p. 13
  • The example query searches the COLUMNS view in new_york.INFORMATION_SCHEMA.Source: §6 · p. 13
  • Another query is described as filtering by both table attributes and column semantics.Source: §6 · p. 13

11 SELECT column_name

The snippet shows a query reading column metadata from census.INFORMATION_SCHEMA.COLUMNS.

11 SELECT column_name

  • The query references census.INFORMATION_SCHEMA.COLUMNS as its metadata source.The passage contains only the fragment “12 FROM census.INFORMATION_SCHEMA.COLUMNS.”Source: §11 · p. 13

13 WHERE table_name LIKE '%tract%' AND table_name LIKE '%2018%' ,→

AutoLink retrieves candidate schema elements through targeted search and tests its current linked schema with a minimal executable query. Execution errors provide diagnostic signals for further retrieval and schema expansion.

13 WHERE table_name LIKE '%tract%' AND table_name LIKE '%2018%' ,→

  • @retrieve schema searches dynamically using the question and partial schema, including inferred virtual-column names or descriptions of potentially missing columns.This targets missing elements that literal query rewriting may not surface, including context-dependent terms such as “score” when a students table is known.Source: §14 · p. 13
  • @verify schema tests whether the currently linked schema can answer the question by executing a minimal SQL query and using success or errors as diagnostic signals.Errors such as “no such column” or “no such table” indicate missing schema elements and can prompt retrieval, addition, and re-verification.Source: §14 · p. 14

2 SELECT COUNT(*)

AutoLink commits schema discoveries to its candidate set, then generates and refines SQL using the linked schema. Its generation pipeline samples candidates, corrects syntax with execution feedback, and selects among candidates by execution-output groups.

2 SELECT COUNT(*)

  • The @add schema action commits newly discovered relevant elements to the final candidate set, using table name.column name format.The authors encourage frequent additions to improve schema-linking recall.Source: §2 · p. 14

Detail of SQL Generation

  • The SQL-generation pipeline uses the final linked schema to condition SQL generation on the question and schema context.The passage introduces the subsequent generation stage but does not specify its full procedure.Source: Detail of SQL Generation · p. 14
  • Five independently sampled SQL candidates are generated through stochastic LLM decoding.The number of candidates is five in this paper.Source: Detail of SQL Generation · p. 14
  • Each candidate undergoes iterative syntactic correction using execution errors until it executes successfully or reaches the turn limit.The corrected candidate after k turns is denoted as the final version.Source: Detail of SQL Generation · p. 14
  • Candidates producing identical execution results are grouped, and the largest group or tied largest groups determine final selection.A unique largest group yields a randomly selected SQL; tied groups are represented and compared pairwise by an LLM, with the highest-win candidate selected.Source: Detail of SQL Generation · pp. 14–15

More Experiment Details

The experiments specify retrieval and generation settings across Bird and Spider 2.0-Lite, and compare AutoLink with retrieval, schema-linking, and text-to-SQL baselines. Spider 2.0-Lite includes complex enterprise settings, while the schema-linking evaluation uses a 250-example subset.

Experimental Setup

  • Retrieval uses top-n values of 100 for Spider 2.0-Lite and 30 for Bird, top-m of 3, and a maximum of 10 interaction turns.DE-SL and CE-SL use retrieval top-k values of 200 on Spider 2.0-Lite and 40 on Bird; sampling decoding is set to five.Source: Experimental Setup · p. 15
  • SQL generation samples five candidates at temperature 1.0 and allows up to five correction turns; it uses DeepSeek-V3 on Bird and DeepSeek-R1 on Spider 2.0-Lite.The dataset descriptions identify Bird Dev as the Bird evaluation split and Spider 2.0-Lite as involving three database dialects.Source: Experimental Setup · p. 15, Benchmark · p. 15

Benchmark

  • Spider 2.0-Lite features more than 3,000 columns, and schema-linking evaluation uses a 250-example subset with ground-truth SQL.Bird comprises 95 databases totaling 33.4 GB and more than 37 specialized domains; experiments use Bird Dev.Source: Benchmark · p. 15

Baselines

  • Baselines include dual- and cross-encoder linking, MCS-SQL, SQL-to-Schema, RSL-SQL, LinkAlign, and CHESS.The comparisons also include Spider-Agent, ReFoRCE, MAC-SQL, and TA-SQL as text-to-SQL systems or agents.Source: Baselines · pp. 15–16

More Experiment Results

The experiments examine decoding and retrieval trade-offs, AutoLink hyperparameters, Spider 2.0-Lite leaderboard performance, and SQL-generation ablations. Results report strong recall at modest schema sizes and improvements from iterative correction and majority voting.

More Experiment Results

Limitations of Increasing Decoding Time in Iterative Schema Linking

  • Token consumption grows almost linearly with decoding rounds even as recall and result size approach saturation, making comparable recall and scale costly.The authors describe this as a practical limitation of simply increasing decoding rounds.Source: Limitations of Increasing Decoding… · p. 16

Analysis of Hyperparameter

  • With Max Turn rising from 4 to 10, SRR increases from 89.2 to 91.2 and average columns from 138.4 to 159.6; top-m from 1 to 3 raises SRR from 89.2% to 91.2%.Average agent turns rise from 3.72 to 5.79 as Max Turn rises, while token cost remains nearly unchanged; small top-m values already yield high recall.Source: Table 6 · p. 16, Analysis of Hyperparameter · pp. 16–17, Table 7 · p. 17

Analysis of Trade-off Comparison

  • At matched recalled-column counts, AutoLink has higher strict recall than BGE-Large and BGE-Reranker; decoding baselines lack fine-grained control over result size.Increasing decoding iterations improves recall and column counts initially, but gains plateau as token consumption rises dramatically.Source: Figure 4 · p. 17, Analysis of Trade-off Comparison · p. 17

SQL Generation Ablation

  • Iterative correction raises Spider 2.0-Lite EX from 23.47 to 31.34 (+7.87 points), and majority voting raises it to 34.97 (+3.63 points).The passage attributes correction's role to addressing low-level syntax errors during SQL generation.Source: Table 8 · p. 17, SQL Generation Ablation · pp. 17–18

Results on Leaderboard of Spider 2.0-Lite

Prompt Templates

The paper provides prompt templates for four system modules: schema linking, SQL generation, syntactic correction, and SQL selection.

Prompt Templates

Related papers

Loading 2511.17190v1…