Pith. sign in

REVIEW 4 major objections 7 minor 2 cited by

RASL: Retrieval Augmented Schema Linking for Massive Database Text-to-SQL

T0 review · 4 major / 7 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims text-to-SQL scales to massive database catalogs with no fine-tuning: decompose schemas into semantic entities, retrieve by question keywords, then let an LLM rank tables — a recipe that beats every trained baseline it…

desk verdict Solid system paper with strong ablations, but the 'massive' claim is not tested at the scale that motivates it. read the letter →

arxiv 2507.23104 v1 pith:MGXFYPP7 submitted 2025-07-30 cs.CL cs.AIcs.LG

Jeffrey Eben , Aitzaz Ahmad , Stephen Lau This is my paper
classification cs.CLcs.AIcs.LG
keywords retrievalaugmentedgenerationtext-to-SQLschemalinkingtablezero-shotentity-leveldecompositionmassivedatabasecatalogs
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that text-to-SQL can scale to massive database catalogs without any domain-specific fine-tuning, using only retrieval and prompting. Its system, RASL, decomposes each table and column into small semantic entities — names, aliases, descriptions, value formats — indexes every entity separately in a vector store, retrieves with keywords extracted from the question, and then has an LLM rank the surviving tables before generating SQL. The reported numbers beat every baseline: top-15 table recall of 98.0/97.8/69.2 on Spider/BIRD/Fiben versus 97.6/94.6/56.9 for the best trained router, and end-to-end execution accuracy of 64.5% on Spider and 53.5% on BIRD against best baselines of 62.5% and 52.9%. If this holds, an enterprise catalog that constantly changes would need only a vector-index refresh, not model retraining, to keep a natural-language query interface working.

What carries the argument

The load-bearing object is the schema entity: one atomic piece of metadata, such as the string 'zip_code' as a column name or a table's alias, embedded independently and indexed per entity type in a vector database. A light LLM reduces each question to keywords, and every keyword plus the full question is issued as a parallel retrieval query against each entity-type index; the scores are rescaled by entity-type weights $w_\lambda = |\Lambda| \cdot \mathrm{AUC}(\lambda)^2 / \sum_{\lambda' \in \Lambda} \mathrm{AUC}(\lambda')^2$, which amplify the entity types whose table-level recall is strongest over a few hundred training questions. Entities are then projected onto their parent tables, the top $N=50$ tables form the context budget, and a second LLM call ranks the relevant tables before full schemas are loaded for SQL generation. This two-stage design, broad entity retrieval followed by narrow LLM table prediction, is what keeps the system zero-shot while matching or exceeding trained routers.

What would settle it

Assemble a catalog larger than 10,000 tables by combining the three benchmarks and adding synthetic schemas with realistic name overlaps, run RASL's full pipeline over it, and measure top-15 table recall, end-to-end execution accuracy, per-query latency, and schema-token use. If recall falls materially below the reported 98.0/97.8/69.2, or if cost and latency grow with catalog size, the central scalability claim fails.

Watch

Extended reading notes

Core claim

The central discovery is that granular entity-level retrieval feeding a two-stage retrieve-then-predict loop outperforms both fine-tuned schema routers and coarse table-level retrieval for text-to-SQL over large schema collections. RASL builds separate vector indexes per entity type — table name, table alias, column name, column alias, column description, value description — so each fragment of schema metadata can be matched on its own; at query time the question is decomposed into keywords, each keyword is run in parallel against every entity index, and per-entity-type relevance weights, squared AUC over a small training sample when one exists, rescale the scores. Retrieved entities are collapsed onto their tables, the top 50 tables are kept, which is under 3% of all table entities and under 1% of all column entities, and an LLM ranks the truly relevant tables before their full schemas are loaded for SQL generation. On the three benchmarks, adapted so every test record sees the whole schema collection as one massive catalog, this zero-shot pipeline reports top-15 table recall of 98.0 on Spider, 97.8 on BIRD, and 69.2 on Fiben, with end-to-end execution accuracy of 64.5% and 53.5%, and its token budget stays flat as the candidate pool grows.

Load-bearing premise

The claim that the approach scales to enterprise catalogs assumes that what was measured on catalogs of at most 876 tables — retrieval accuracy, token use, and latency — carries over to the 10,000-table enterprise catalogs that motivate the paper, a scale the experiments never reach.

Editorial extensions

If this is right

  • Enterprise catalogs would no longer need retraining for schema changes: a schema update requires only re-embedding the changed entities, since the pipeline itself is zero-shot.
  • Prompt cost stops growing with the candidate pool: RASL's schema-token use is identical at $N=15$ and $N=30$, while all baselines scale linearly in the tables they include.
  • Keyword-level retrieval is the main driver of performance; dropping keywords in favor of the raw question costs several recall points at top-5 on every benchmark.
  • The system still works with no training data at all (Fiben), while calibrating on a few hundred samples adds its largest gain on the most overlapping catalog (Spider).
  • Synthesized table descriptions improve table prediction further, but their token cost outweighs the benefit in most settings, so the primary system is evaluated without them.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The 10,000-table headline is an extrapolation: the largest catalog evaluated has 876 tables, and nothing in the experiments shows how retrieval accuracy, retrieval latency, or the embedding index behave at ten to a hundred times that size.
  • The zero-shot claim is softer than it reads: for Spider and BIRD, per-entity-type relevance weights are calibrated on 200 labeled training questions, so the completely retraining-free regime is demonstrated only on Fiben, which the paper's own ablation shows still works without calibration.
  • The architecture implies that metadata quality, not model reasoning, is the binding constraint at enterprise scale; catalogs with generic, duplicated, or missing column names should expect smaller gains than the benchmarks show, since the paper's error analysis identifies schema overlap as the main failure mode at small candidate pools.
  • A testable extension the authors flag as open is replacing the fixed top-50-table cutoff with a relevance threshold or dynamic token-budget rule, which would directly probe how context size trades off against retrieval accuracy.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. The paper introduces RASL, a retrieval-augmented schema linking system for text-to-SQL over large database catalogs. At build time, RASL decomposes each table and column into fine-grained semantic entities (names, aliases, descriptions, value formats), embeds them with a commercial embedding model, and indexes them in a vector database. At inference, the user question is decomposed into keywords with a lightweight LLM; for each keyword and entity type, the top-100 entities are retrieved, scores are calibrated by entity-type weights derived from AUC on a small training sample, and entities are filtered to the top-50 tables. An LLM then predicts the relevant tables, and the full schemas of those tables are used for zero-shot SQL generation with self-correction. The method is evaluated on Spider, BIRD, and Fiben, with the full benchmark schemas treated as one large catalog. The paper reports that RASL outperforms BM25, sentence-transformers, CRUSH, DTR, and DBCopilot on table Recall@5/15 and on end-to-end execution accuracy, while using comparable or smaller schema prompts. Ablations isolate the contributions of keyword-level retrieval, entity-type calibration, and synthesized table descriptions, and a cost analysis projects constant cost as the number of retrieved tables grows. The paper claims the system scales to massive databases without domain-specific fine-tuning.

Significance. If the claims hold, RASL is a practically valuable contribution: it offers a fine-tuning-free, component-based retrieval architecture that reduces schema context to under 3% of the full catalog while maintaining high table recall and SQL accuracy, and it provides a careful token- and cost-accounting framework. The ablation study is well designed, with a standardized context budget and clear decomposition of retrieval query type and calibration effects. The paper also includes honest limitation statements in Section 6.2 and appendix material on failed calibration ideas. However, the headline claim of scalability to 'massive databases' is not directly tested: the largest catalog used has 876 tables, whereas the motivation in Section 1 concerns catalogs with 10,000 tables and roughly 500,000 schema entities. The evaluation also relies on baseline numbers from a prior paper in which different LLM backends were used, and no repeated runs or error bars are reported. The significance is therefore conditional on whether the retrieval pipeline degrades gracefully at the scale the paper motivates.

major comments (4)
  1. [Section 1, Table 1, Section 5.5] The paper motivates the method with 10,000-table enterprise catalogs containing roughly 500,000 schema entities, but all experiments are on catalog-level unions of Spider (876 tables), BIRD (597 tables), and Fiben (152 tables). The retrieval pipeline's constant-cost property in Appendix G and the claim that RASL 'scales to massive databases' depend on the candidate pool (top-100 entities per keyword per type, then top-50 tables) still containing the correct tables when the index is an order of magnitude larger and schema names are more repetitive. Appendix E shows that name overlap already causes recall errors at hundreds of tables, so this concern is concrete. The authors should either evaluate on a larger catalog (e.g., a synthetic catalog built from repeated or perturbed schemas) or substantially temper the scaling claims in the abstract and contributions.
  2. [Section 5.2, Section 5.4, Table 2] The primary comparison in Table 2 is not controlled for the LLM backbone or the evaluation protocol. Recall metrics for BM25, SXFMR, CRUSH, DTR, and DBCopilot are 'directly adopt[ed]' from DBCopilot [23], where CRUSH uses GPT-3.5-turbo for schema hallucination, whereas in the ablation reproductions the authors use Claude 3.5 Sonnet-v2 for CRUSH. RASL itself uses Claude 3.5 Sonnet-v2 for table prediction and SQL generation. This makes it difficult to attribute the observed gains to the RASL architecture rather than to differences in the underlying LLM strength or to the source of the baseline numbers. Additionally, no standard deviations, confidence intervals, or repeated-run results are reported anywhere; temperature 0.0 aids reproducibility but does not remove run-to-run variance in LLM outputs, especially with self-correction. Please report variance or at least perform multiple runs for the main comparisons, and either re-run baselines with the same backbone or explicitly discuss the confound.
  3. [Section 4.3.2, Section 5.4, Section 1] The paper repeatedly describes RASL as 'zero-shot' and claims 'no model training,' but Section 4.3.2 fits entity-type relevance weights w_lambda using AUC over ground-truth training samples, and Section 5.4 states that 200 training instances are used for Spider and BIRD. This is a form of supervised calibration that is dataset-specific: the weights learned on Spider or BIRD may not transfer to a new enterprise catalog, and the paper does not evaluate how sensitive the results are to the choice or size of the calibration set. The Fiben results, where no calibration is used, only partially address this. I recommend either dropping 'zero-shot' from the claims or reporting all primary results both with and without calibration, and discussing transfer of the weights across datasets.
  4. [Section 5.6, Table 3] The 'standardized context budget' protocol in Section 5.6 is described only qualitatively. For RASL, entities are filtered to the top N=50 tables, while for BM25 and SXFMR the paper states 'Add full table schemas' until reaching RASL's context budget, and for CRUSH it adds column names. The actual token counts per method are not shown in Table 3, and the statement that 'RASL's context size never exceeds baselines' is not backed by the reported data. Moreover, the budget-matching procedure may favor RASL if baseline schemas are padded with less informative entities. Please report token counts for each method in the comparison and provide a sensitivity analysis over the context budget (e.g., plot Recall@5 versus tokens) to make the equal-budget comparison transparent.
minor comments (7)
  1. [Section 1] There is a typo in the contributions list: 'hierarcy' should be 'hierarchy'.
  2. [Section 5.5] The text 'apporach' should be 'approach'.
  3. [Table 6] The CRUSH_BM25 BIRD Recall value is reported as 80.92 with two decimals while all other values in the table use one decimal; please standardize the precision.
  4. [Figure 4] The label 'SXFRMR' in Figure 4 appears to be a typo for 'SXFMR'; this should be corrected.
  5. [Appendix F] The text 'Anthropic Calude 3.5 Sonnet-v2' should read 'Anthropic Claude 3.5 Sonnet-v2'.
  6. [Table 4] The header for the BIRD columns is inconsistent: 'Avg Toks.' and 'Avg Tokens' both appear; please unify the notation.
  7. [Section 5.9] The paper states that self-correction is applied for SQL generation but does not specify the number of self-correction iterations or whether the reported token counts in Table 6 include these iterations. Please clarify, since this affects the cost analysis in Appendix G.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; RASL's claims are evaluated against external ground-truth SQL, and the only fitted component is standard supervised calibration on a training split.

full rationale

RASL's derivation is self-contained with respect to circularity. The retrieval pipeline (Section 4) decomposes schemas into entities, embeds them, retrieves by keyword/question, and ranks tables; none of these stages is defined in terms of the target results. The entity-type relevance calibration (Eq. 1) computes w_lambda from AUC(lambda) over 200 training instances, which is standard supervised weight selection, disclosed in Section 5.4, and is not a prediction claimed as a first-principles result. All primary metrics (Tables 2, 3, 6) are Recall@N against ground-truth tables used in SQL queries and execution accuracy on held-out test sets (Spider/BIRD dev sets, Fiben test), so the reported numbers are not forced by construction. The paper contains no load-bearing self-citations: the reference list is entirely external prior work (CHESS, CRUSH, DBCopilot, M-Schema), and those citations are used for inspiration or baseline reproduction, not to justify RASL's correctness. The limitation that scalability is demonstrated only on catalogs up to 876 tables while the motivation is 10,000-table enterprise catalogs (Table 1 vs Section 1) is an external-validity and generalization concern, explicitly a missing evaluation rather than a circular derivation; the skeptic's concern about ambiguous names and retrieval degradation at scale is an untested assumption, not an identity between input and output. Accordingly, the appropriate circularity score is 0.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The central claim rests mainly on the choice of entity-type calibration weights (a fitted parameter), the fixed top-N limit, and the assumptions that embeddings capture semantic relevance and that the benchmark adaptation is a good proxy for massive catalogs. No new physical or theoretical entities are introduced.

free parameters (3)
  • Entity-type relevance weights w_lambda = Not reported numerically; computed from AUC over 200 training samples per dataset
    Equation (1) in Section 4.3.2 calibrates entity type importance using ground-truth training questions; these weights affect the final retrieval ranking and are fitted to data.
  • Top-N table filter N = 50
    Section 5.4 sets N=50 to keep schema entities below 3% per type; chosen by the authors, affects context budget and performance.
  • Top-100 entities per keyword per entity type = 100
    Constrained by the Bedrock Knowledge Bases maximum result count, not tuned by the authors.
assumptions (5)
  • domain assumption Cosine similarity between embeddings is a valid relevance measure for schema entities.
    Section 3 defines similarity via cosine; the entire retrieval is built on this assumption.
  • domain assumption Training ground-truth SQL labels are representative of test questions for calibrating entity-type weights.
    Section 4.3.2 uses 200 training instances to compute AUC; assumes this calibration transfers to test.
  • domain assumption The vector database returns accurate approximate nearest neighbors.
    The system relies on Bedrock Knowledge Bases for retrieval; assumes its top-k results are correct.
  • domain assumption Benchmark schemas and ground truth SQL are correct and the adapted multi-database setting is a valid proxy for massive enterprise catalogs.
    Section 5.1 describes the adaptation of Spider and BIRD to a massive catalog setting.
  • domain assumption LLMs can rank relevant tables accurately given relevant context.
    Section 4.4 uses an LLM for table prediction; this is a design premise.

how reviews work

0 comments
Cite this review

Pith. "Pith review of RASL: Retrieval Augmented Schema Linking for Massive Database Text-to-SQL." pith.science (2026). https://pith.science/paper/MGXFYPP7

@misc{pith2026250723104,
  author       = {Pith},
  title        = {Pith review of: RASL: Retrieval Augmented Schema Linking for Massive Database Text-to-SQL},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MGXFYPP7}},
  note         = {Machine review of arXiv:2507.23104}
}
read the original abstract

Despite advances in large language model (LLM)-based natural language interfaces for databases, scaling to enterprise-level data catalogs remains an under-explored challenge. Prior works addressing this challenge rely on domain-specific fine-tuning - complicating deployment - and fail to leverage important semantic context contained within database metadata. To address these limitations, we introduce a component-based retrieval architecture that decomposes database schemas and metadata into discrete semantic units, each separately indexed for targeted retrieval. Our approach prioritizes effective table identification while leveraging column-level information, ensuring the total number of retrieved tables remains within a manageable context budget. Experiments demonstrate that our method maintains high recall and accuracy, with our system outperforming baselines over massive databases with varying structure and available metadata. Our solution enables practical text-to-SQL systems deployable across diverse enterprise settings without specialized fine-tuning, addressing a critical scalability gap in natural language database interfaces.

Figures

Figures reproduced from arXiv: 2507.23104 by the authors.

Figure 1
Figure 1. System overview. (left) Build-time process of constructing the schema metadata knowledge base. (right) Inference-time [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Table 𝑅𝑒𝑐𝑎𝑙𝑙@𝑁 over BIRD (left) and Fiben (right). BIRD benefits from both Λ𝐶 and Λ𝑇 , achieving notable recall improvement over individual 𝜆 at higher 𝑁, while Fiben primarily leverages 𝐸𝐶. (2) full-system, which applies table prediction after filtering 𝐸 to entities from the top 𝑁 ranked tables. For full-system, we limit the retrieved candidate entities to 𝑁 = 50 tables, as we find that this consistently keeps sch… view at source ↗
Figure 5
Figure 5. Failure of lexical table retriever due to lack of gran [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Failure of semantic table retriever due to lack of [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. The Case for Text-to-SQL Friendly Logical Database Design

    cs.DB 2026-06 unverdicted novelty 7.0 of 10

    Introduces LLM-friendly logical database design via three operators (+A, +P, +R) that yield up to 4.2% gains in execution accuracy on BIRD-Union and Spider-Union benchmarks.

  2. Schema-First Retrieval: Embedding Catalogs for Natural Language Analytics

    cs.IR 2026-06 unverdicted novelty 5.0 of 10

    Schema-First Retrieval embeds catalog metadata rather than rows and uses parallel retrieval plus reranking to raise table and column recall and cut SQL execution errors on three benchmarks.

Reference graph

Works this paper leans on

39 extracted references · 24 canonical work pages · cited by 2 Pith papers

  1. [23]

    sentence transformers. [n. d.]. all-mpnet-base-v2. https://huggingface.co/ sentence-transformers/all-mpnet-base-v2

    work page

  2. [1]

    Anthropic. 2024. Claude 3.5 Haiku. https://www.anthropic.com/claude/haiku

    work page 2024

  3. [2]

    Anthropic. 2024. Claude 3.5 Sonnet-v2. https://www.anthropic.com/news/ claude-3-5-sonnet

    work page 2024

  4. [3]

    Amazon Web Services (AWS). [n. d.]. Bedrock Knowledge Base. https://docs. aws.amazon.com/bedrock/latest/userguide/knowledge-base-build.html

    work page

  5. [4]

    Amazon Web Services (AWS). [n. d.]. Bedrock Pricing. https://aws.amazon.com/ bedrock/pricing/

    work page

  6. [5]

    Dorian Stuart Brown. [n. d.]. Okapi BM25 Algorithm. https://pypi.org/project/ rank-bm25/

    work page

  7. [6]

    Peter Baile Chen, Yi Zhang, and Dan Roth. 2025. Is Table Retrieval a Solved Problem? Exploring Join-Aware Multi-Table Retrieval. arXiv:2404.09889 [cs.IR] https://arxiv.org/abs/2404.09889

    work page Pith review arXiv 2025

  8. [7]

    Cohere. 2022. Cohere Embed v3. https://cohere.com/blog/introducing-embed-v3

    work page 2022

Show all 39 references
  1. [8]

    Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, and Jingren Zhou. 2023. Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation. arXiv:2308.15363 [cs.DB] https://arxiv.org/abs/2308. 15363

    2023 arXiv

  2. [9]

    Yingqi Gao, Yifu Liu, Xiaoxia Li, Xiaorong Shi, Yin Zhu, Yiming Wang, Shiqi Li, Wei Li, Yuntao Hong, Zhiling Luo, Jinyang Gao, Liyu Mou, and Yu Li. 2025. A Preview of XiYan-SQL: A Multi-Generator Ensemble Framework for Text-to-SQL. arXiv:2411.08599 [cs.AI] https://arxiv.org/ab...

    2025 arXiv

  3. [10]

    Jonathan Herzig, Thomas Müller, Syrine Krichene, and Julian Martin Eisensch- los. 2021. Open Domain Question Answering over Tables via Dense Retrieval. arXiv:2103.12011 [cs.CL] https://arxiv.org/abs/2103.12011

    2021 arXiv

  4. [11]

    Zijin Hong, Zheng Yuan, Qinggang Zhang, Hao Chen, Junnan Dong, Feiran Huang, and Xiao Huang. 2025. Next-Generation Database Interfaces: A Survey of LLM-based Text-to-SQL. arXiv:2406.08426 [cs.CL] https://arxiv.org/abs/2406. 08426

    2025

  5. [12]

    Mayank Kothyari, Dhruva Dhingra, Sunita Sarawagi, and Soumen Chakrabarti

  6. [13]

    Dongjun Lee, Choongwon Park, Jaehyuk Kim, and Heesoo Park. 2024. MCS-SQL: Leveraging Multiple Prompts and Multiple-Choice Selection For Text-to-SQL Generation. arXiv:2405.07467 [cs.CL] https://arxiv.org/abs/2405.07467

    2024 arXiv

  7. [14]

    Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, Binhua Li, Bowen Li, Bailin Wang, Bowen Qin, Rongyu Cao, Ruiying Geng, Nan Huo, Xuanhe Zhou, Chenhao Ma, Guoliang Li, Kevin C. C. Chang, Fei Huang, Reynold Cheng, and Yongbin Li. 2023. Can LLM Already Serve as A Database Interface? A...

    2023 arXiv

  8. [15]

    Karime Maamari, Fadhil Abubaker, Daniel Jaroslawicz, and Amine Mhedhbi

  9. [16]

    OpenAI. [n. d.]. gpt-3.5-turbo-0125. https://platform.openai.com/docs/models

  10. [17]

    Mohammadreza Pourreza, Hailong Li, Ruoxi Sun, Yeounoh Chung, Shayan Talaei, Gaurav Tarlok Kakkar, Yu Gan, Amin Saberi, Fatma Ozcan, and Sercan O. Arik

  11. [18]

    Nils Reimers and Iryna Gurevych. 2019. Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. arXiv:1908.10084 [cs.CL] https://arxiv.org/abs/ 1908.10084

    2019 arXiv

  12. [19]

    Jaydeep Sen, Chuan Lei, Abdul Quamar, Fatma Ozcan, Vasilis Efthymiou, Ayushi Dalmia, Greg Stager, Ashish Mittal, Diptikalyan Saha, and Karthik Sankara- narayanan. 2020. ATHENA++: Natural Language Querying for Complex Nested SQL Queries. Proc. VLDB Endow. 13, 11 (2020), 2747–2759

    2020

  13. [20]

    arXiv:2410.01943 [cs.LG] https://arxiv.org/abs/2410

    CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL. arXiv:2410.01943 [cs.LG] https://arxiv.org/abs/2410. 01943

    arXiv

  14. [21]

    Shayan Talaei, Mohammadreza Pourreza, Yu-Chen Chang, Azalia Mirhoseini, and Amin Saberi. 2024. CHESS: Contextual Harnessing for Efficient SQL Synthesis. arXiv:2405.16755 [cs.LG] https://arxiv.org/abs/2405.16755

    2024 arXiv

  15. [22]

    Bing Wang, Changyu Ren, Jian Yang, Xinnian Liang, Jiaqi Bai, LinZheng Chai, Zhao Yan, Qian-Wen Zhang, Di Yin, Xing Sun, and Zhoujun Li. 2025. MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL. arXiv:2312.11242 [cs.CL] https://arxiv.org/abs/2312.11242

    2025 arXiv

  16. [24]

    latitude

    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. 2019. Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task. arXi...

    2019 arXiv

  17. [26]

    Tianshu Wang, Xiaoyang Chen, Hongyu Lin, Xianpei Han, Le Sun, Hao Wang, and Zhenyu Zeng. 2025. DBCopilot: Natural Language Querying over Massive Databases via Schema Routing. arXiv:2312.03463 [cs.CL] https://arxiv.org/abs/ 2312.03463

    2025 arXiv

  18. [28]

    Examine the question carefully to understand what data would be needed to answer it

  19. [29]

    Analyze the database schema to determine which tables contain relevant information

  20. [30]

    Rank tables by relevance - tables listed first should be most central to answering the question

  21. [31]

    Consider both direct mentions and implied data needs

  22. [32]

    Select only tables that would contribute to a SQL query answering the question

  23. [33]

    Consider join paths needed to connect relevant information

  24. [34]

    database_name

    IMPORTANT: The table schemas are incomplete and only contain possibly relevant columns. There are many columns not shown within each table. RASL: Retrieval Augmented Schema Linking for Massive Database Text-to-SQL Ranking Criteria: - Primary tables: Directly contain data expli...

    2022

  25. [35]

    The table’s main purpose and real-world concept it represents

  26. [36]

    Its context within the broader database domain

  27. [37]

    Typical query patterns or business questions it helps answer

  28. [38]

    Key relationships with other tables (if any)

  29. [39]

    For tables with many columns, focus on the overall table purpose and categories of data rather than describing individual columns

    Alternative terms users might use when referring to this table Keep your description under 150 words, focusing on semantic meaning rather than technical details. For tables with many columns, focus on the overall table purpose and categories of data rather than describing indi...

  30. [2023]

    arXiv:2311.01173 [cs.CL] https://arxiv.org/abs/2311.01173

    CRUSH4SQL: Collective Retrieval Using Schema Hallucination For Text2SQL. arXiv:2311.01173 [cs.CL] https://arxiv.org/abs/2311.01173

    arXiv

  31. [2024]

    arXiv:2408.07702 [cs.CL] https://arxiv.org/abs/2408.07702

    The Death of Schema Linking? Text-to-SQL in the Age of Well-Reasoned Language Models. arXiv:2408.07702 [cs.CL] https://arxiv.org/abs/2408.07702

    arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.