Enhancing Text2Cypher with Schema Filtering

Makbule Gulcin Ozsoy

REVIEW 4 major objections 5 minor 1 cited by

Enhancing Text2Cypher with Schema Filtering

T0 review · 4 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read Schema pruning makes Text2Cypher cheaper and at least as accurate for most models tested.

desk verdict Useful practical study on schema filtering for Text2Cypher, but the headline cost claim omits the overhead of the dynamic filtering itself, and there are no error bars. read the letter →

arxiv 2505.05118 v2 pith:UXKA2AQY submitted 2025-05-08 cs.DB cs.LG

Makbule Gulcin Ozsoy This is my paper · ORCID

classification cs.DBcs.LG

keywords Text2Cypherschemafilteringlinkinglargelanguagemodelscypherquerygenerationprompttokenlengthcostreduction

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 asks whether, when an LLM translates a natural-language question into a Cypher query, it is better to hand the model the full graph-database schema or only the schema elements that are relevant to that question. The author proposes three dynamic pruning methods, alongside two static full-schema formats, and tests them on a public Text2Cypher benchmark. The central finding is that reducing schema size improves or maintains query-generation accuracy for most tested models while consistently lowering token cost. If the finding holds beyond the benchmark, it means that prompt engineering for graph queries should treat the schema not as a fixed appendix but as a per-question resource to be filtered.

What carries the argument

The central mechanism is the schema-pruning step inserted between the natural-language question and the Cypher prompt. The paper compares two static schemas (Enhanced Schema, which includes example property values, and Base Schema, which does not) with three dynamic schemas: 'Pruned by Exact-Match,' which retains schema elements whose node labels, relationship types, or properties appear as case-insensitive exact matches in the question; 'NER Masked & Pruned by Exact-Match,' which first replaces named entities with their entity types to avoid semantically irrelevant string matches; and 'Pruned by Similarity,' which keeps elements whose embedding-based similarity to question terms exceeds a threshold. The pruning step is what determines prompt length, and prompt length in turn drives both model accuracy and token cost.

What would settle it

Take a real-world knowledge graph with thousands of node labels and relationship types, build a test set with naturally phrased questions that do not literally repeat schema element names, and measure execution-based exact-match accuracy for Llama-3.1-8B under the five schema formats. If exact-match pruning performs worse than the full Base Schema on that test set, the paper's central claim would fail for the regime it is meant to generalize to.

Watch

Extended reading notes

Core claim

The paper's central claim is that dynamically pruning the database schema before feeding it to an LLM is both a performance-improving and cost-reducing strategy for Text2Cypher. Among the five schema formats evaluated, the 'Pruned by Exact-Match Schema' produced the highest lexical accuracy (Google-BLEU) and the highest execution-based exact-match accuracy for the Llama-3.1-8B model, while cutting the 95th-percentile prompt token length from roughly 2,700 tokens to roughly 529 tokens. For smaller models, shorter prompts clearly improved both lexical and execution-based translation quality. For Gemini-1.5-Flash, the larger model with a long context window, longer prompts delivered slightly better results, but the drop from pruning remained below five percent, and cost savings applied to every model tested.

Load-bearing premise

The benchmark databases are demo-oriented and simple, with the longest schema around 2,700 tokens, so the finding that exact-match schema pruning helps may not hold for real-world graph schemas that are much larger, much more deeply nested, or full of overlapping labels.

Editorial extensions

If this is right

For applications built on moderately sized models, serving a Text2Cypher system with per-question exact-match schema pruning should be the default baseline rather than the full-schema prompt, because it simultaneously improves measured accuracy and reduces input tokens.
For very large models with long context windows, pruning will not necessarily improve accuracy, but it can still cut costs enough to be worthwhile in high-volume serving.
The 'NER Masked' variant demonstrates a concrete failure mode of naive exact matching: string overlap between a named entity and a schema element can retain irrelevant properties. Applying entity-type masking before matching is a cheap, testable fix that may matter more on domains with many ambiguous labels.
Because the paper's heuristic pruning operates on node labels, relationship types, and properties rather than on query intent, its effectiveness may depend on how well the natural-language question names database elements verbatim; richer languages that paraphrase schema terms will likely need similarity-based or LLM-assisted filtering.
The cost calculations, which scale linearly with input token count and hold output length constant, offer a practical planning equation for anyone choosing between self-hosted and API-based LLM deployment for graph query generation.

Reading between the lines

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

The paper's exact-match pruning result hints at a broader principle for all schema-linked text-to-query tasks: the marginal value of a schema token to an LLM may be negative when it competes with the question itself for attention, and positive only when it carries information the model cannot infer from context. That principle, if true, would also apply to Text2SQL and Text2SPARQL, and would justi
A testable extension would be to apply the same five schema formats to a real-world knowledge graph with several hundred node types and relationships, where exact-match pruning is likely to retain too many elements via accidental string overlaps; the paper's own NER-masking and similarity variants would then become the main contenders.
The finding that execution-based accuracy drops by only around two percent for two of three models when schemas are pruned suggests that most of the information an LLM needs is already encoded in the question itself. This strengthens the case for treating schema linking as a recoverable-from-failure step rather than an all-or-nothing prerequisite.
The paper measures cost only through input tokens. A more complete cost model would include the latency of the pruning step itself, the cost of misgenerated queries that must be repaired by a human, and the cost of serving output tokens; these factors could alter the threshold at which pruning stops being beneficial.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

The paper is a modest, honest empirical study of schema filtering for Text2Cypher. What is actually new is a systematic comparison of two static and three dynamic schema-pruning methods on one public dataset, with an analysis of token distributions and a rough cost model. The finding that exact-match pruning helps smaller models and that larger models benefit less is consistent with prior Text2SQL and Text2GQL work, and the author says so. The paper does not oversell novelty: it cites Liang et al. and NAT-NL2GQL, positions the contribution as an extension, and openly lists limitations.

What it does well: the experimental design is clear, the two static schemas are well described, and the token-distribution analysis gives a concrete sense of how much pruning can shrink prompts. The cost table, while simplified, makes the token savings tangible. The performance evaluation uses both lexical and execution-based metrics, which is the right thing to do for query generation.

The soft spots are real but not fatal. The biggest one, which the stress-test note correctly identifies, is the cost claim. The paper says dynamic pruning reduces cost for all methods tested, but Table 3 counts only input tokens under the assumption that output lengths remain constant and ignores the compute cost of running regex, spaCy NER, and similarity scoring per query. For the self-hosted LLaMA row, that overhead could be substantial relative to the token savings. The paper acknowledges the overhead exists but dismisses it as minimal without measuring it. Since cost reduction is a headline contribution, this is a load-bearing gap. A few latency numbers or a breakdown of preprocessing time would fix it.

Second, all results are single runs with no error bars, significance tests, or standard deviations. For LLM generation, this matters. The performance differences between schema formats are small in some cases (2–5% for Qwen and Gemini), and without variance we cannot tell if they are noise. Third, the similarity threshold and the spaCy embedding model are not specified, which hurts reproducibility. Fourth, the datasets are demo-oriented with simple schemas; the author acknowledges this, and the largest schema is around 2,700 tokens. That does not invalidate the conclusions, but it limits generalization.

The citation pattern is fine. The author cites the relevant Text2SQL and Text2GQL schema-linking literature and her own prior dataset paper, which is appropriate. I do not see circular reasoning or invented entities.

Who is this for? Practitioners building Text2Cypher systems on moderately sized schemas, and researchers looking for a benchmark comparison of cheap filtering heuristics. It is not a research-landscape-changer, but it is a legitimate incremental contribution with transparent limitations.

Recommendation: I would send it to peer review for the workshop it is targeting. It deserves a serious referee, but the referee should ask for overhead measurements, error bars, and the missing parameters. As it stands I would not fully endorse the cost-reduction claim as an end-to-end result until the filtering overhead is accounted for.

Referee Report

4 major / 5 minor

Summary. This paper studies schema filtering for Text2Cypher, the task of translating natural language questions into Cypher graph queries. The authors compare two static schema formats (Enhanced Schema and Base Schema from Neo4j) with three dynamic pruning methods (exact-match pruning, NER-masked exact-match pruning, and embedding-similarity pruning) using a public Text2Cypher dataset. They report token-length statistics, translation-based (Google-BLEU) and execution-based (exact-match) accuracy for Llama-3.1-8B, Qwen2.5-7B, and Gemini-1.5-Flash, and a cost model based on input token counts. The main claims are that exact-match pruning yields the highest accuracy on their tested setup, that reducing schema size improves performance for most models, and that schema filtering reduces cost for all tested models. The paper also acknowledges limitations: the dataset consists of demo-oriented databases with relatively simple schemas, and the methods are heuristic.

Significance. If the results hold, the paper provides a practical and low-cost recipe for improving Text2Cypher performance with smaller models and for reducing token expenditures across models. The exact-match pruning method is simple, easy to implement, and the empirical comparison across static and dynamic schemas on a large public dataset is a useful contribution for practitioners. The use of both lexical and execution-based metrics is a strength, and the paper is transparent about the dataset subset and the heuristic nature of the filtering. However, the central cost claim is not fully supported because the overhead of dynamic pruning is not measured, and the performance claims lack error bars or significance testing. The contribution is therefore incremental but potentially useful if the open issues are addressed.

major comments (4)

[Section 4.2.1, Table 3] The cost-reduction claim in Section 4.2.1 and the conclusion ("reduced cost for all of those we tested") is based on Table 3, which counts only input tokens under the assumption that "output lengths remain constant and only input tokens contribute to the cost." This ignores the per-query compute overhead of the dynamic pruning methods: exact-match requires regex processing, NER masking requires spaCy inference, and similarity pruning requires embedding computation. The paper asserts in Section 4.2.1 that this overhead is "minimal," but no latency, CPU/GPU time, or additional API cost is measured. For self-hosted models billed by wall-clock GPU time, or for API-based deployments where preprocessing runs on paid infrastructure, the token savings may not translate into end-to-end cost savings. The cost claim is load-bearing for the paper's main practical recommendation, so it should be either measured end-to-end or explicitly qualified as token-cost-only.
[Section 4.2.2, Figures 5 and 6] The performance claims, including "The highest accuracy is achieved with the 'Pruned by Exact-Match Schema'" and "reducing schema size improved performance for most models," are based on single evaluation runs without error bars, confidence intervals, or significance tests. Given that models can be sensitive to sampling temperature and other sources of randomness, the observed differences (some around 2-5%) may not be robust. The paper should either run multiple independent trials and report variance, or present the raw scores with a clear statement that the comparison is anecdotal. This is load-bearing because the main empirical contribution is that pruning improves or preserves accuracy for most models.
[Section 3.2, Pruned by Similarity] The similarity-based pruning method is not reproducible as described: the paper does not specify the similarity threshold, the embedding model used (beyond "spaCy framework" in Section 4.1), or the exact similarity measure. These are free parameters that directly control how many schema elements are retained and thus affect both token length and performance. The paper should report these details, and ideally include a sensitivity analysis over the threshold. This is load-bearing for the method's reproducibility and for interpreting the token-distribution results in Table 2.
[Section 5, Conclusion and Abstract] The abstract and conclusion make general claims such as "schema filtering effectively optimizes Text2Cypher" and "reducing schema size improved performance for most models," while the paper's own limitation statement in Section 5 notes that the evaluation used "demo-oriented databases" with the longest schema around 2700 tokens, which are simpler than real-world schemas. This is a scope mismatch: the central claim is broader than the evidence provided. The authors should either qualify the claims to explicitly reference the tested schema-complexity range, or add a discussion of why the findings are expected to transfer to more complex schemas. This is load-bearing because the practical value of the paper depends on generalization beyond the demo databases.

minor comments (5)

[Section 1, Table 1] The user instruction prompt in Table 1 contains a placeholder {schema} but the system instruction mentions "Use only the provided relationship types and properties in the schema." It would be clearer to also include the model-specific output format constraints (e.g., no leading whitespace or markdown) that the post-processing step in Section 4.1 addresses.
[Section 3.2, Pruned By Exact-Match] The text says "This approach compares node labels, relationship types, and properties to words in the input question" and then mentions "exact case-insensitive match." It would be helpful to specify whether stemming or lemmatization is applied, and whether matching is done on whole tokens or substrings.
[Section 4.1, Models] The paper refers to "GoogleAIStudio/Gemini-1.5-Flash" but the Gemini model is accessed via an API; the paper should specify the API configuration (e.g., temperature, top-p, max tokens) to ensure reproducibility.
[Section 4.2.1, Table 3] Table 3 uses "20K instances" in the cost scenario, while the test set is 2,471 samples. The scenario is clearly labelled, but it is worth noting explicit that the cost table is a hypothetical scale-up and not the actual experimental cost.
[References and author affiliation] There is a typographical artifact in the author affiliation: "/envel⌢pe-⌢penmakbule.ozsoy@neo4j.com" should be cleaned up, and the spaCy library should be cited properly.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper reports empirical measurements on a public benchmark, with cost computed from measured token counts and stated prices rather than from a fitted or self-referential derivation.

full rationale

The paper's central claims are empirical: schema filtering reduces token counts, and on the tested models shorter prompts improve or maintain Text2Cypher accuracy. These claims are supported by measured token distributions (Table 2), computed cost estimates from those token counts and listed API/hardware prices (Table 3), and execution/translation evaluation against a public dataset [18]. No parameter is fitted to the test set and then renamed as a prediction. The prompt template is taken from the author's own prior Text2Cypher work [18], but that prior work is used as a fixed baseline and dataset source, not as justification for the paper's conclusions; the experimental results are evaluated externally against reference Cypher queries. The cost reduction conclusion is a direct arithmetic consequence of the explicit assumption that output lengths remain constant and only input tokens contribute to cost, and the paper states that assumption rather than hiding it. The dynamic pruning overhead is asserted to be 'minimal' without measurement, and the conclusion generalizes from 'demo-oriented databases with simpler schemas'; both are internal-limitation or correctness-risk concerns, not circularity. The paper itself acknowledges these limitations in Section 5. Overall, the derivation chain is self-contained as an empirical study and does not reduce to its own inputs by construction.

Assumptions & free parameters 2 free parameters · 2 assumptions · 0 invented entities

The central claim rests on an empirical evaluation, not on a theoretical construction. Key free parameters are the similarity threshold and embedding model for the similarity-based method. The domain assumptions about dataset representativeness and tokenizer portability bound how far the results generalize.

free parameters (2)

similarity_threshold
Pruned by Similarity retains schema elements whose embedding similarity exceeds a predefined threshold, but the threshold value and how it was chosen are not reported.
spaCy embedding model = unspecified
Similarity scores rely on spaCy for named entity recognition and embedding-based similarity, but the specific model or vector representation is not stated, which affects which schema elements are retained.

assumptions (2)

domain assumption The selected subset of the Text2Cypher dataset is representative of real-world Text2Cypher workloads.
Section 4.1 uses 22,093 training and 2,471 test samples that have accessible databases; Section 5 acknowledges these are demo-oriented and simpler than real databases.
domain assumption Token counts measured with the Llama-3.1-8B tokenizer approximate token counts for all models in the cost analysis.
Section 4.2.1 and Table 3 use median token counts from Table 2, computed with the Llama tokenizer, to estimate costs for Gemini and self-hosted models, even though tokenizers differ.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Enhancing Text2Cypher with Schema Filtering." pith.science (2026). https://pith.science/paper/UXKA2AQY

@misc{pith2026250505118,
  author       = {Pith},
  title        = {Pith review of: Enhancing Text2Cypher with Schema Filtering},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UXKA2AQY}},
  note         = {Machine review of arXiv:2505.05118}
}

read the original abstract

Knowledge graphs represent complex data using nodes, relationships, and properties. Cypher, a powerful query language for graph databases, enables efficient modeling and querying. Recent advancements in large language models allow translation of natural language questions into Cypher queries - Text2Cypher. A common approach is incorporating database schema into prompts. However, complex schemas can introduce noise, increase hallucinations, and raise computational costs. Schema filtering addresses these challenges by including only relevant schema elements, improving query generation while reducing token costs. This work explores various schema filtering methods for Text2Cypher task and analyzes their impact on token length, performance, and cost. Results show that schema filtering effectively optimizes Text2Cypher, especially for smaller models. Consistent with prior research, we find that larger models benefit less from schema filtering due to their longer context capabilities. However, schema filtering remains valuable for both larger and smaller models in cost reduction.

Figures

Figures reproduced from arXiv: 2505.05118 by the authors.

**Figure 2.** Example static schemas for the example database presented in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Dynamic schemas for the question: "List the articles that mention the organization ’Acme Group’." It additionally provides example values for the fields. For instance, if the property is the ’name’ of the ’Actor’ node, examples might include: [’Tom Hanks’, ’Julia Roberts’, ...]. An example enhanced schema is presented in Figure 2a. • Base Schema: This is another default schema types provided by Neo4j. It provides si… view at source ↗

Figures from the paper (3 more)

**Figure 4.** Figure 4: Token distributions of the training and test sets, based on the tokenizer from the Llama-3.1-8B model. The 95th percentile (p95) value is marked with a purple line. • Pruned by Similarity: This approach extends exact-match pruning by incorporating similaritybased filt…

**Figure 5.** Figure 5: Performance across various schema formats (a) Translation-based - Google-Bleu score (b) Execution-based - Exact-match score [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]

**Figure 6.** Figure 6: Performance comparison of various models align with observation made by previous research [2, 3]: The impact of schema length varies across models, with Gemini-1.5-Flash potentially benefiting from longer context while the other smaller models perform better with short…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

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

STRuCT-LLM: Unifying Tabular and Graph Reasoning with Reinforcement Learning for Semantic Parsing
cs.CL 2025-06 conditional novelty 6.0 of 10

Jointly reinforcing LLMs on SQL and Cypher with a graph-edit-distance reward improves structured parsing performance and transfers to table and graph QA tasks.

Reference graph

Works this paper leans on

37 extracted references · 12 canonical work pages · cited by 1 Pith paper

[1]

Hogan, E

A. Hogan, E. Blomqvist, M. Cochez, C. d’Amato, G. D. Melo, C. Gutierrez, S. Kirrane, J. E. L. Gayo, R. Navigli, S. Neumaier, et al., Knowledge graphs, ACM Computing Surveys (Csur) 54 (2021) 1–37

2021
[2]

H. A. Caferoğlu, Ö. Ulusoy, E-sql: Direct schema linking via question enrichment in text-to-sql, arXiv preprint arXiv:2409.16751 (2024)

arXiv 2024
[3]

Chung, G

Y. Chung, G. T. Kakkar, Y. Gan, B. Milne, F. Ozcan, Is long context all you need? leveraging llm’s extended context for nl2sql, arXiv preprint arXiv:2501.12372 (2025)

arXiv 2025
[4]

T. Yu, R. Zhang, K. Yang, M. Yasunaga, D. Wang, Z. Li, J. Ma, I. Li, Q. Yao, S. Roman, et al., Spider: A large-scale human-labeled dataset for complex and cross-domain semantic parsing and text-to-sql task, arXiv preprint arXiv:1809.08887 (2018)

arXiv 2018
[5]

J. Guo, Z. Zhan, Y. Gao, Y. Xiao, J.-G. Lou, T. Liu, D. Zhang, Towards complex text-to-sql in cross-domain database with intermediate representation, arXiv preprint arXiv:1905.08205 (2019)

arXiv 2019
[6]

H. Li, J. Zhang, C. Li, H. Chen, Resdsql: Decoupling schema linking and skeleton parsing for text-to-sql, in: Proceedings of the AAAI Conference on Artificial Intelligence, volume 37, 2023, pp. 13067–13075

work page 2023
[7]

Y. Fan, Z. He, T. Ren, C. Huang, Y. Jing, K. Zhang, X. S. Wang, Metasql: A generate-then-rank framework for natural language to sql translation, arXiv preprint arXiv:2402.17144 (2024)

arXiv 2024
[8]

K. Shen, M. Kejriwal, Select-sql: Self-correcting ensemble chain-of-thought for text-to-sql, arXiv preprint arXiv:2409.10007 (2024)

arXiv 2024

Show all 37 references

[9]

J. Lee, I. Baek, B. Kim, H. Lee, Safe-sql: Self-augmented in-context learning with fine-grained example selection for text-to-sql, arXiv preprint arXiv:2502.11438 (2025)

2025
[10]

F. Brei, J. Frey, L.-P. Meyer, Leveraging small language models for text2sparql tasks to improve the resilience of ai assistance, arXiv preprint arXiv:2405.17076 (2024)

2024 arXiv
[11]

Meyer, J

L.-P. Meyer, J. Frey, F. Brei, N. Arndt, Assessing sparql capabilities of large language models, arXiv preprint arXiv:2409.05925 (2024)

2024 arXiv
[12]

Emonet, J

V. Emonet, J. Bolleman, S. Duvaud, T. M. de Farias, A. C. Sima, Llm-based sparql query generation from natural language over federated knowledge graphs, arXiv preprint arXiv:2410.06062 (2024)

2024 arXiv
[13]

Opitz, N

D. Opitz, N. Hochgeschwender, From zero to hero: generating training data for question-to-cypher models, in: Proceedings of the 1st International Workshop on Natural Language-based Software Engineering, 2022, pp. 17–20

2022
[14]

Z. Zhao, X. Ge, Z. Shen, C. Hu, H. Wang, S2ctrans: Building a bridge from sparql to cypher, in: International Conference on Database and Expert Systems Applications, Springer, 2023, pp. 424–430

2023
[15]

Z. Zhao, W. Liu, T. French, M. Stewart, Cyspider: A neural semantic parsing corpus with baseline models for property graphs, in: Australasian Joint Conference on Artificial Intelligence, Springer, 2023, pp. 120–132

2023
[16]

Z. Zhao, W. Liu, T. French, M. Stewart, Rel2graph: Automated mapping from relational databases to a unified property knowledge graph, arXiv preprint arXiv:2310.01080 (2023)

2023 arXiv
[17]

Zhong, L

Z. Zhong, L. Zhong, Z. Sun, Q. Jin, Z. Qin, X. Zhang, Synthet2c: Generating synthetic data for fine-tuning large language models on the text2cypher task, arXiv preprint arXiv:2406.10710 (2024)

2024 arXiv
[18]

M. G. Ozsoy, L. Messallem, J. Besga, G. Minneci, Text2cypher: Bridging natural language and graph databases, in: Proceedings of the Workshop on Generative AI and Knowledge Graphs (GenAIK), 2025, pp. 100–108

2025
[19]

J. Guo, L. Du, H. Liu, M. Zhou, X. He, S. Han, Gpt4graph: Can large language models understand graph structured data? an empirical evaluation and benchmarking, arXiv preprint arXiv:2305.15066 (2023)

2023 arXiv
[20]

H. Xu, B. Zhang, Z. Jin, T. Zhu, Q. Wu, H. Weng, Topochat: Enhancing topological materials retrieval with large language model and multi-source knowledge, arXiv preprint arXiv:2409.13732 (2024)

2024
[21]

W. W. Baraki, Leveraging large language models for accurate Cypher query generation: Natural language query to Cypher statements, Master degree project, University of Skövde, 2024. https: //www.diva-portal.org/smash/get/diva2:1881385/FULLTEXT01.pdf

2024
[22]

Y. Liu, X. Wang, J. Ge, H. Wang, D. Xu, Y. Jia, Text to graph query using filter condition attributes, Proceedings of the VLDB Endowment. ISSN 2150 (2024) 8097

2024
[23]

Liang, K

Y. Liang, K. Tan, T. Xie, W. Tao, S. Wang, Y. Lan, W. Qian, Aligning large language models to a domain-specific graph database for nl2gql, in: Proceedings of the 33rd ACM International Conference on Information and Knowledge Management, 2024, pp. 1367–1377

2024
[24]

W. Lei, W. Wang, Z. Ma, T. Gan, W. Lu, M.-Y. Kan, T.-S. Chua, Re-examining the role of schema linking in text-to-sql, in: Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), 2020, pp. 6943–6954

2020
[25]

Z. Cao, Y. Zheng, Z. Fan, X. Zhang, W. Chen, X. Bai, Rsl-sql: Robust schema linking in text-to-sql generation, arXiv preprint arXiv:2411.00073 (2024)

2024 arXiv
[26]

Maamari, F

K. Maamari, F. Abubaker, D. Jaroslawicz, A. Mhedhbi, The death of schema linking? text-to-sql in the age of well-reasoned language models, arXiv preprint arXiv:2408.07702 (2024)

2024 arXiv
[27]

T. Yu, Z. Li, Z. Zhang, R. Zhang, D. Radev, Typesql: Knowledge-based type-aware neural text-to-sql generation, arXiv preprint arXiv:1804.09769 (2018)

2018 arXiv
[28]

Z. Dong, S. Sun, H. Liu, J.-G. Lou, D. Zhang, Data-anonymous encoding for text-to-sql generation, in: Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP)...

2019
[29]

Bogin, M

B. Bogin, M. Gardner, J. Berant, Global reasoning over database structures for text-to-sql parsing, arXiv preprint arXiv:1908.11214 (2019)

2019 arXiv
[30]

B. Wang, R. Shin, X. Liu, O. Polozov, M. Richardson, Rat-sql: Relation-aware schema encoding and linking for text-to-sql parsers, arXiv preprint arXiv:1911.04942 (2019)

2019 arXiv
[31]

Pourreza, D

M. Pourreza, D. Rafiei, Din-sql: Decomposed in-context learning of text-to-sql with self-correction, Advances in Neural Information Processing Systems 36 (2023) 36339–36348

2023
[32]

Talaei, M

S. Talaei, M. Pourreza, Y.-C. Chang, A. Mirhoseini, A. Saberi, Chess: Contextual harnessing for efficient sql synthesis, arXiv preprint arXiv:2405.16755 (2024)

2024 arXiv
[33]

Glass, M

M. Glass, M. Eyceoz, D. Subramanian, G. Rossiello, L. Vu, A. Gliozzo, Extractive schema linking for text-to-sql, arXiv preprint arXiv:2501.17174 (2025)

2025 arXiv
[34]

Z. Yuan, H. Chen, Z. Hong, Q. Zhang, F. Huang, X. Huang, Knapsack optimization-based schema linking for llm-based text-to-sql generation, arXiv preprint arXiv:2502.12911 (2025)

2025 arXiv
[35]

P. E. Hart, N. J. Nilsson, B. Raphael, A formal basis for the heuristic determination of minimum cost paths, IEEE transactions on Systems Science and Cybernetics 4 (1968) 100–107

1968
[36]

Liang, T

Y. Liang, T. Xie, G. Peng, Z. Huang, Y. Lan, W. Qian, Nat-nl2gql: A novel multi-agent framework for translating natural language to graph query language, arXiv preprint arXiv:2412.10434 (2024)

2024 arXiv
[37]

https://huggingface.co/evaluate-metric

HuggingFace, Huggingface evaluate, 2024. https://huggingface.co/evaluate-metric

2024

Pith tools

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

[1] [1]

Hogan, E

A. Hogan, E. Blomqvist, M. Cochez, C. d’Amato, G. D. Melo, C. Gutierrez, S. Kirrane, J. E. L. Gayo, R. Navigli, S. Neumaier, et al., Knowledge graphs, ACM Computing Surveys (Csur) 54 (2021) 1–37

2021

[2] [2]

H. A. Caferoğlu, Ö. Ulusoy, E-sql: Direct schema linking via question enrichment in text-to-sql, arXiv preprint arXiv:2409.16751 (2024)

arXiv 2024

[3] [3]

Chung, G

Y. Chung, G. T. Kakkar, Y. Gan, B. Milne, F. Ozcan, Is long context all you need? leveraging llm’s extended context for nl2sql, arXiv preprint arXiv:2501.12372 (2025)

arXiv 2025

[4] [4]

T. Yu, R. Zhang, K. Yang, M. Yasunaga, D. Wang, Z. Li, J. Ma, I. Li, Q. Yao, S. Roman, et al., Spider: A large-scale human-labeled dataset for complex and cross-domain semantic parsing and text-to-sql task, arXiv preprint arXiv:1809.08887 (2018)

arXiv 2018

[5] [5]

J. Guo, Z. Zhan, Y. Gao, Y. Xiao, J.-G. Lou, T. Liu, D. Zhang, Towards complex text-to-sql in cross-domain database with intermediate representation, arXiv preprint arXiv:1905.08205 (2019)

arXiv 2019

[6] [6]

H. Li, J. Zhang, C. Li, H. Chen, Resdsql: Decoupling schema linking and skeleton parsing for text-to-sql, in: Proceedings of the AAAI Conference on Artificial Intelligence, volume 37, 2023, pp. 13067–13075

work page 2023

[7] [7]

Y. Fan, Z. He, T. Ren, C. Huang, Y. Jing, K. Zhang, X. S. Wang, Metasql: A generate-then-rank framework for natural language to sql translation, arXiv preprint arXiv:2402.17144 (2024)

arXiv 2024

[8] [8]

K. Shen, M. Kejriwal, Select-sql: Self-correcting ensemble chain-of-thought for text-to-sql, arXiv preprint arXiv:2409.10007 (2024)

arXiv 2024