Text2Cypher: Data Pruning using Hard Example Selection

Makbule Gulcin Ozsoy

REVIEW 4 major objections 5 minor 1 cited by

Text2Cypher: Data Pruning using Hard Example Selection

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 Hard-example selection halves Text2Cypher fine-tuning cost with little accuracy loss.

desk verdict Useful first study of hard-example selection for Text2Cypher, but the cost-saving claim is confounded by unequal training steps and the 'best' row cherry-picks across methods. read the letter →

arxiv 2505.05122 v2 pith:EG2K2LUT submitted 2025-05-08 cs.DB cs.LG

Makbule Gulcin Ozsoy This is my paper · ORCID

classification cs.DBcs.LG

keywords hard-exampleselectiondatapruningText2Cypherfine-tuninglargelanguagemodelsdatasetCyphergenerationcostreduction

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

The paper argues that pruning a Text2Cypher fine-tuning dataset down to fewer than half its examples—by keeping only the hardest queries—cuts training time and cost by more than half with only a modest drop in Cypher-generation accuracy. This matters because fine-tuning LLMs on large synthetic datasets is expensive, and if smaller curated subsets can nearly match full-data models, then training Text2SQL and Text2Cypher systems becomes much cheaper. The paper compares three difficulty heuristics and two combinations against random sampling and the full 39,554-example dataset, and shows that hard-example selection beats random sampling on every reported metric. The strongest subset keeps execution-based Exact Match close to the full-data level (0.2639 versus 0.2740) while using 1,000 training steps instead of 2,500, at the cost of a larger drop in translation-based Exact Match (0.2599 versus 0.3642).

What carries the argument

The load-bearing mechanism is the selection function that scores each training instance as hard. Three variants are used: Complexity-Based selection, which relies on a prior error analysis to flag specific database and data-source groups; Length-Based selection, which ranks ground-truth Cypher queries by their length; and Cypher-Specific selection, which counts Cypher keywords such as MATCH, WHERE, and RETURN. Two further methods first apply the Complexity-Based filter and then sort by query length or keyword count. All subsets are fixed at 16,173 instances so that the comparison isolates selection quality from dataset size; the fine-tuned model is a 4-bit quantized Llama-3.1-8B-Instruct, trained for 1,000 steps versus 2,500 steps for the full data.

What would settle it

Train the 16,173-example hard subset for 2,500 steps with the same learning-rate schedule and seed as the full-data run, and compare it against a random subset trained identically; if the hard subset no longer beats random sampling or no longer closes the gap to the full dataset, the reported advantage is an artifact of the shorter training budget rather than of example difficulty.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that for the Text2Cypher task, deliberately keeping the most difficult training instances—rather than randomly subsampling—preserves most of the Cypher-generation quality of the full dataset while roughly halving resource use. The Complexity-Based selector identifies databases and data sources where the model struggled (the recommendations, companies, and neoflix demonstration databases; the functional_cypher, synthetic_gemini, and text2cypher2023_train data sources) and keeps 16,173 such instances. This subset reaches Google-Bleu 0.7140 and Exact Match 0.2599 in translation-based evaluation, closing most of the gap to the full dataset (0.7585 and 0.3642) while sharply beating random sampling (0.6971 and 0.2048). Execution-based Exact Match stays at 0.2639 versus 0.2550 for random sampling and 0.2740 for the full dataset. The paper reads this as evidence that cost-effective fine-tuning can be built on hard-example selection, with the length- and keyword-based combinations adding only marginal gains.

Load-bearing premise

The Complexity-Based method depends on the author's earlier analysis of which database and data-source groups are hardest, and that analysis was published only as a blog post and may have been shaped by the same test data or model used here; if that difficulty ranking is biased, the selected 'hard' examples may not be the most informative ones.

Editorial extensions

If this is right

Training on 16,173 hard examples takes about 1,000 steps instead of 2,500, so elapsed time and GPU cost drop by more than half.
Hard-example selection dominates random sampling: on every reported metric the best hard subset scores above the same-size random subset.
The best hard subset nearly preserves execution-based Exact Match (0.2639 vs 0.2740 for the full dataset), meaning generated Cypher queries still run correctly on the demonstration databases.
The combined heuristics do not hurt performance but add only marginal gains, so the simple Complexity-Based filter carries most of the benefit.
The full 39,554-example dataset still gives the highest absolute scores, so the paper positions hard-example selection as a cost-efficiency tool rather than a free accuracy improvement.

Reading between the lines

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

The same difficulty-focused pruning recipe could transfer to Text2SQL, where datasets such as Spider and IndDB already carry difficulty annotations, making a direct comparison straightforward.
The divergence between translation-based and execution-based rankings suggests future selectors could treat execution success itself as the difficulty signal instead of query length or keyword counts.
Because the Complexity-Based selector is anchored in the author's earlier blog-post analysis, re-deriving the hardest database and data-source groups on an independent model and a held-out split would test whether the difficulty ranking generalizes.
Training the same 16,173-example subset for more than 1,000 steps might close much of the remaining gap to the full dataset; this is implied but not tested in the paper.

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

My take: this is a reasonable workshop-level first look at pruning Text2Cypher fine-tuning data by selecting hard examples. The application is new as far as I know, and the paper is transparent about his heuristics, reports both lexical and execution-based metrics, and includes a random-sampling baseline. I also give credit for comparing hard selection to random at the same 1K-step budget, where hard selection clearly wins (0.7140 vs 0.6971 Google-Bleu, 0.2599 vs 0.2048 Exact Match). That is a real signal, even if the magnitudes are modest. The soft spots are not minor. First, the headline claim that hard-example selection 'halves cost with minimal impact' is not established because the full dataset is trained for ~2.5K steps while every subset is trained for only 1K steps. The performance gap between full data and subsets could be mostly explained by the extra training budget. The stress-test note is correct: there is no same-step full-data control. Second, the 'Hard Example Selection (best)' row in Table 1 appears to pick the best score per metric across different methods, not a single method's result. That inflates the apparent performance. Report each method separately. Third, the Complexity-Based selection relies on the author's prior test-set analysis (a self-cited Medium post) to identify 'hard' databases and data sources. Using test-set performance to choose training data leaks test information into the selection process, so the method's advantage over random is untrustworthy. Fourth, every number comes from a single run with no error bars, so differences like 0.26 vs 0.25 Exact Match are essentially noise. The paper is honest about some limitations and the writing is clear, so I don't think the authors are trying to hide anything. But the experimental design needs fixing before the central claim can be taken seriously: add a full-data same-step baseline, run multiple seeds, report per-method results, and either drop or properly validate the test-informed selection. Who gets value from this? People working on data pruning for text-to-query tasks, and anyone interested in how evaluation leakage can creep into data selection. It deserves a serious referee rather than a desk reject, because the core question is sensible and the fix is an experimental redesign, not a conceptual dead end. I would not cite the results as evidence until those controls are in place.

Referee Report

4 major / 5 minor

Summary. The paper proposes five hard-example selection methods for pruning the Text2Cypher training dataset: Complexity-Based selection (guided by the author's prior analysis of where models struggle), Length-Based selection, Cypher-Specific term counting, and two combinations of Complexity-Based with each heuristic. All methods produce a 16,173-example subset from the original 39,554 training examples. The experimental protocol fine-tunes a 4-bit quantized 8B Llama 3.1 model on the full dataset for about 2,500 steps and on each subset for 1,000 steps, then compares translation-based (Google-Bleu, Exact Match) and execution-based metrics. The central claim is that hard-example selection roughly halves training time and cost while only minimally affecting Cypher generation performance, and that hard-example selection outperforms random sampling.

Significance. If the central claim were established, the paper would offer a practical, inexpensive data-pruning recipe for Text2Cypher and provide evidence that hardness-based selection is useful for NL-to-query fine-tuning, a relatively underexplored task compared with Text2SQL. The paper has several strengths: it uses a public dataset, it reports hyperparameters and the training seed in Appendix B so that experiments are reproducible in principle, it evaluates with both lexical and execution-based protocols, and it includes a random-sampling baseline. These strengths make the contribution potentially useful to practitioners. However, the headline result is currently confounded by the unequal training budgets between the full-data and subset runs, and by the absence of repeated runs and variance reporting; as a result, the significance of the reported gains over random sampling is not yet quantifiable.

major comments (4)

[Section 4.2.1 and Table 1] The main comparison varies two factors simultaneously: the pruning method and the number of training steps. The full dataset is trained for roughly 2,500 steps while every 16,173-example subset is trained for 1,000 steps (Section 4.2.1, Table 1). Consequently, the drop from 0.3642 to 0.2599 in translation Exact Match, a 29% relative decrease, cannot be attributed to pruning alone; it may reflect the reduced training budget. The paper reports full-data training loss at 1K steps but does not provide full-data evaluation metrics at 1K steps, nor does it train any subset for 2.5K steps. A same-step full-data control, and ideally a same-budget subset run, is necessary before the claim of 'minimal impact' on performance can be accepted.
[Section 3.1] The Complexity-Based selection method chooses databases and data sources where models 'struggled most' according to the author's prior analysis in reference [12]. That reference is a self-cited, non-archival blog post, and as described it is based on evaluation results over the test set. If test-set information is used to define which training examples are hard, the apparent advantage of Complexity-Based selection may be inflated by leakage. The paper should specify the data split used in [12], and either derive the difficulty signal from training/validation data only or demonstrate that the selected databases and data sources are also hard on a held-out split that did not inform the selection rule.
[Section 4.2 and Table 1] All fine-tuning experiments are single runs with a fixed seed (Appendix B, seed=3407). Without multiple seeds, error bars, or significance tests, small differences such as execution-based Exact Match 0.2639 for the best hard-example method versus 0.2550 for random sampling cannot be distinguished from run-to-run noise. The qualitative ranking of methods in Sections 4.2.2 and 4.2.3 may therefore be spurious. Repeating each condition with at least three to five seeds and reporting variance or pairwise significance would make the comparisons reliable.
[Abstract, Conclusion, and Section 4.2.1] The claim that resource usage, 'both in elapsed time and total cost,' is reduced by more than half is not directly supported by any reported measurement. The only resource metric presented is the number of training steps (Section 4.2.1, Figure 2). Step count is a proxy for, not a measurement of, elapsed time or total cost; wall-clock time and GPU cost can vary with data loading, evaluation, and infrastructure. The paper should either report actual elapsed time and cost figures or explicitly restate the claim as a reduction in training steps.

minor comments (5)

[Abstract and Section 1] The abstract says the goal is to 'preserve or improve performance,' but in every condition the pruned datasets underperform the full dataset in Table 1. The conclusion's phrasing 'minimally affecting Cypher generation performance' is more accurate; the abstract should be revised to match the evidence.
[Section 3.3] The Randomly-Sampled baseline is not a simple uniform random sample: it first caps each data-source group at the 75th percentile (2,755) and then refines the result to 16,173 instances. The fairness of this procedure relative to the hard-selection subsets is not justified, and the paper should clarify whether the random draw is seeded and reproducible.
[Sections 3.1 and 3.2] The thresholds that define the subsets, such as the 4,000-instance group cap and the final size of 16,173, are introduced without sensitivity analysis. The comparison across methods could depend on these ad hoc values, so reporting at least one alternative dataset size or group cap would strengthen the conclusions.
[Section 4.1] The execution-based evaluation is said to run on 'about 50% of the dataset' because it requires an active target database. The exact number of test instances used for that protocol should be reported, because the two evaluation protocols measure different subsets and the paper itself observes that they rank methods differently.
[Throughout] There are several small presentation issues: the footnote markers on 'demonstration databases of Neo4j 1 2 ' are awkward, and the data-source names such as 'functional_cypher' and 'text2cypher2023_train' are used without a definition or a pointer to where the dataset fields are described.

Circularity Check

1 steps flagged · score 4.0 of 10

Some self-citation in the Complexity-Based selector's definition of 'hard', but the central cost/performance claim has independent empirical content.

self citation load bearing [Section 3.1, Complexity-Based Hard-Example Selection]
"In our previous work [12], we have executed a comprehensive analysis of model performance on the Neo4j Text2Cypher (2024) dataset [13]. ... Complexity-Based Hard-Example Selection: Guided by our analysis [12], we identified data sources and databases where fine-tuned models struggled most."

The Complexity-Based method's operational definition of 'hard' is imported entirely from the author's own prior blog analysis [12], which is not independently verified in this paper. The specific choice of the three databases and three data sources is not derived from any criterion stated here; it is taken as given from [12]. Since [12] is a self-cited analysis of model struggles, the selection heuristic may encode the same model family's prior failures (and possibly test-set information) into the training subset. The paper then uses the Complexity-Based method's test-set performance as part of its best hard-example-selection result, so the strongest translation-based claim partially depends on a self-referential definition of hardness.

full rationale

The paper's resource-reduction claim is not circular: using a 16,173-instance subset for 1,000 steps instead of a 39,554-instance full dataset for 2,500 steps reduces time and cost by construction, and the paper reports held-out test metrics for all methods. The main circularity concern is the Complexity-Based selector, whose 'hard' examples are defined by the author's own prior blog analysis [12]. That self-citation is load-bearing for the best translation-based results, and it does not meet the criteria for independent support (it is not machine-checked, code-reproduced, or validated outside the author's own fitted values). However, the two purely heuristic methods (Length-Based and Cypher-Specific) do not rely on [12], and the execution-based best result comes from the Cypher-Specific method, so the central claim does not reduce entirely to the self-citation. The 2.5K-versus-1K step confound in the full-data comparison is a real experimental-design weakness, but it is a correctness risk, not a circularity, and therefore does not further raise the circularity score under the stated rules.

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

The central findings rest on arbitrarily chosen dataset sizes and heuristic proxies for difficulty. None of these are derived from first principles or tested for robustness, and the main selection method leans on an unverified prior analysis by the same author.

free parameters (4)

max_group_size = 4000
Complexity-Based selection caps each data-source group at 4,000 instances to balance the dataset; this cap is chosen without justification and directly determines the pruned set.
pruned_dataset_size = 16173
All selection methods are forced to output 16,173 instances to match the complexity-based method; this size is an arbitrary target and not derived from a principled criterion.
random_sample_group_quantile = 75th percentile (2,755 per group)
For the random baseline, instances are sampled per group up to the 75th percentile of group sizes, an arbitrary choice that affects the baseline comparison.
training_seed = 3407
The random seed for fine-tuning is fixed to 3407; the sensitivity of results to seed is not explored.

assumptions (4)

domain assumption Longer Cypher queries are more difficult for the model to generate.
This is the core heuristic behind the Length-Based method (Section 3.1). No evidence is provided that length correlates with generation difficulty beyond intuition.
domain assumption Queries containing more Cypher-specific keywords (MATCH, WHERE, RETURN) are more complex and harder.
Underpins the Cypher-Specific method (Section 3.1). The paper does not validate this assumption against model performance.
ad hoc to paper The prior analysis in [12] correctly identifies the databases and data sources where models struggle most.
The Complexity-Based method depends on this self-cited analysis of the same dataset. The analysis is not peer-reviewed and is only described via a blog post, and the paper does not provide the specific criteria or ensure no leakage to the test set.
domain assumption Fine-tuning the baseline model for 1,000 steps on a smaller subset is a fair comparison against 2,500 steps on the full dataset; more training on the subset would not close the performance gap.
The paper compares subsets trained for 1K steps to full data trained for 2.5K steps, attributing the difference to data selection rather than training budget; they do not train subsets to 2.5K steps to check convergence.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Text2Cypher: Data Pruning using Hard Example Selection." pith.science (2026). https://pith.science/paper/EG2K2LUT

@misc{pith2026250505122,
  author       = {Pith},
  title        = {Pith review of: Text2Cypher: Data Pruning using Hard Example Selection},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EG2K2LUT}},
  note         = {Machine review of arXiv:2505.05122}
}

read the original abstract

Database query languages such as SQL for relational databases and Cypher for graph databases have been widely adopted. Recent advancements in large language models (LLMs) enable natural language interactions with databases through models like Text2SQL and Text2Cypher. Fine-tuning these models typically requires large, diverse datasets containing non-trivial examples. However, as dataset size increases, the cost of fine-tuning also rises. This makes smaller, high-quality datasets essential for reducing costs for the same or better performance. In this paper, we propose five hard-example selection techniques for pruning the Text2Cypher dataset, aiming to preserve or improve performance while reducing resource usage. Our results show that these hard-example selection approaches can halve training time and costs with minimal impact on performance, and demonstrates that hard-example selection provides a cost-effective solution.

Figures

Figures reproduced from arXiv: 2505.05122 by the authors.

**Figure 2.** Original vs. Randomly-Sampled data performance. We next explore whether hard-example selection can retain efficiency while improving outcomes. 4.2.2 Impact of Hard-Example Selection. When fine-tuning the baseline model with datasets prepared using random sampling or hard-example selection approaches, training times remain similar since the dataset sizes were kept equal, as shown in [PITH_FULL_IMAGE:figures/full_fig… view at source ↗

**Figure 4.** Combined Hard-Example Selection approaches [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗

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

25 extracted references · 17 canonical work pages · cited by 1 Pith paper

[12]

Makbule Gulcin Ozsoy. 2025. Neo4j Text2Cypher: Analyzing Model Struggles and Dataset Improvements. https://medium.com/p/0b965fd3ebfa

work page 2025
[1]

Alon Albalak, Yanai Elazar, Sang Michael Xie, Shayne Longpre, Nathan Lambert, Xinyi Wang, Niklas Muennighoff, Bairu Hou, Liangming Pan, Haewon Jeong, et al. 2024. A survey on data selection for language models. arXiv preprint arXiv:2402.16827 (2024)

arXiv 2024
[2]

Abdul Azeemi, Ihsan Qazi, and Agha Raza. 2023. Data pruning for efficient model pruning in neural machine translation. In Findings of the Association for Computational Linguistics: EMNLP 2023 . 236–246

work page 2023
[3]

Hao Chen, Yiming Zhang, Qi Zhang, Hantao Yang, Xiaomeng Hu, Xuetao Ma, Yifan Yanggong, and Junbo Zhao. 2023. Maybe only 0.5% data is needed: A preliminary exploration of low training data instruction tuning. arXiv preprint arXiv:2305.09246 (2023)

arXiv 2023
[4]

Lichang Chen, Shiyang Li, Jun Yan, Hai Wang, Kalpa Gunaratna, Vikas Yadav, Zheng Tang, Vijay Srinivasan, Tianyi Zhou, Heng Huang, and Hongxia Jin

work page
[5]

Qianlong Du, Chengqing Zong, and Jiajun Zhang. 2023. Mods: Model-oriented data selection for instruction tuning. arXiv preprint arXiv:2311.15653 (2023)

arXiv 2023
[6]

HuggingFace. 2024. HuggingFace Evaluate. https://huggingface.co/evaluate- metric

work page 2024
[7]

Ming Li, Yong Zhang, Zhitao Li, Jiuhai Chen, Lichang Chen, Ning Cheng, Jianzong Wang, Tianyi Zhou, and Jing Xiao. 2024. From Quantity to Quality: Boosting LLM Performance with Self-Guided Data Selection for Instruction Tuning. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Langua...

2024

Show all 25 references

[8]

Xinyu Lin, Wenjie Wang, Yongqi Li, Shuo Yang, Fuli Feng, Yinwei Wei, and Tat- Seng Chua. 2024. Data-efficient Fine-tuning for LLM-based Recommendation. In Proceedings of the 47th international ACM SIGIR conference on research and development in information retrieval. 365–374

2024
[9]

Wei Liu, Weihao Zeng, Keqing He, Yong Jiang, and Junxian He. 2024. What Makes Good Data for Alignment? A Comprehensive Study of Automatic Data Se- lection in Instruction Tuning. In The Twelfth International Conference on Learning Representations

2024
[10]

Adyasha Maharana, Prateek Yadav, and Mohit Bansal. 2024. D2 Pruning: Message Passing for Balancing Diversity & Difficulty in Data Pruning. In The Twelfth International Conference on Learning Representations . https://openreview.net/ forum?id=thbtoAkCe9

2024
[11]

Eduardo R Nascimento, Grettel M Garcıa, Lucas Feijó, Wendy Z Victorio, Ye- nier T Izquierdo, Aiko R de Oliveira, GM Coelho, Melissa Lemos, RL Garcia, LAP Leme, et al. 2024. Text-to-SQL meets the real-world. In Proceedings of the 26th international conference on enterprise info...

2024
[13]

Makbule Gulcin Ozsoy, Leila Messallem, Jon Besga, and Gianandrea Minneci. 2025. Text2Cypher: Bridging Natural Language and Graph Databases. In Proceedings of the Workshop on Generative AI and Knowledge Graphs (GenAIK) . 100–108

2025
[14]

RunPod. 2024. RunPod. https://www.runpod.io/

2024
[15]

Haoru Tan, Sitong Wu, Wei Huang, Shizhen Zhao, and Xiaojuan Qi. 2025. Data Pruning by Information Maximization. In The Thirteenth International Conference on Learning Representations

2025
[16]

Unsloth. 2024. Unsloth AI - Open Source Fine-Tuning for LLMs. https://unsloth. ai/. LLM-DPM 2025, 2025, Berlin, Germany Ozsoy et al

2024
[17]

Jiahao Wang, Bolin Zhang, Qianlong Du, Jiajun Zhang, and Dianhui Chu. 2024. A survey on data selection for llm instruction tuning.arXiv preprint arXiv:2402.05123 (2024)

2024 arXiv
[18]

Mengzhou Xia, Sadhika Malladi, Suchin Gururangan, Sanjeev Arora, and Danqi Chen. 2024. LESS: Selecting Influential Data for Targeted Instruction Tuning. In International Conference on Machine Learning (ICML)

2024
[19]

Yuanjian Xu, Qi An, Jiahuan Zhang, Peng Li, and Zaiqing Nie. 2023. Hard Sample Aware Prompt-Tuning. InProceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) . 12356–12369

2023
[20]

Xianjun Yang, Shaoliang Nie, Lijuan Liu, Suchin Gururangan, Ujjwal Karn, Rui Hou, Madian Khabsa, and Yuning Mao. 2025. Diversity-driven data se- lection for language model tuning through sparse autoencoder. arXiv preprint arXiv:2502.14050 (2025)

2025 arXiv
[21]

Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, Dongxu Wang, Zifan Li, James Ma, Irene Li, Qingning Yao, Shanelle Roman, et al. 2018. Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task. In Proceedings of the 2018 Con...

2018
[22]

Jia Zhang, Chen-Xi Zhang, Yao Liu, Yi-Xuan Jin, Xiao-Wen Yang, Bo Zheng, Yi Liu, and Lan-Zhe Guo. 2025. D3: Diversity, Difficulty, and Dependability-Aware Data Selection for Sample-Efficient LLM Instruction Tuning. arXiv preprint arXiv:2503.11441 (2025)

2025 arXiv
[23]

Yiyun Zhang, Sheng’an Zhou, and Gengsheng Huang. 2024. Se-hcl: Schema enhanced hybrid curriculum learning for multi-turn text-to-sql. IEEE Access 12 (2024), 39902–39912

2024
[24]

Chunting Zhou, Pengfei Liu, Puxin Xu, Srinivasan Iyer, Jiao Sun, Yuning Mao, Xuezhe Ma, Avia Efrat, Ping Yu, Lili Yu, et al . 2023. Lima: Less is more for alignment. Advances in Neural Information Processing Systems 36 (2023), 55006– 55021. A DECLARATION ON GENERATIVE AI USAGE...

2023
[2024]

In The Twelfth International Conference on Learning Representations

AlpaGasus: Training a Better Alpaca with Fewer Data. In The Twelfth International Conference on Learning Representations . https://openreview.net/ forum?id=FdVXgSJhvz

Pith tools

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

[1] [12]

Makbule Gulcin Ozsoy. 2025. Neo4j Text2Cypher: Analyzing Model Struggles and Dataset Improvements. https://medium.com/p/0b965fd3ebfa

work page 2025

[2] [1]

Alon Albalak, Yanai Elazar, Sang Michael Xie, Shayne Longpre, Nathan Lambert, Xinyi Wang, Niklas Muennighoff, Bairu Hou, Liangming Pan, Haewon Jeong, et al. 2024. A survey on data selection for language models. arXiv preprint arXiv:2402.16827 (2024)

arXiv 2024

[3] [2]

Abdul Azeemi, Ihsan Qazi, and Agha Raza. 2023. Data pruning for efficient model pruning in neural machine translation. In Findings of the Association for Computational Linguistics: EMNLP 2023 . 236–246

work page 2023

[4] [3]

Hao Chen, Yiming Zhang, Qi Zhang, Hantao Yang, Xiaomeng Hu, Xuetao Ma, Yifan Yanggong, and Junbo Zhao. 2023. Maybe only 0.5% data is needed: A preliminary exploration of low training data instruction tuning. arXiv preprint arXiv:2305.09246 (2023)

arXiv 2023

[5] [4]

Lichang Chen, Shiyang Li, Jun Yan, Hai Wang, Kalpa Gunaratna, Vikas Yadav, Zheng Tang, Vijay Srinivasan, Tianyi Zhou, Heng Huang, and Hongxia Jin

work page

[6] [5]

Qianlong Du, Chengqing Zong, and Jiajun Zhang. 2023. Mods: Model-oriented data selection for instruction tuning. arXiv preprint arXiv:2311.15653 (2023)

arXiv 2023

[7] [6]

HuggingFace. 2024. HuggingFace Evaluate. https://huggingface.co/evaluate- metric

work page 2024

[8] [7]

Ming Li, Yong Zhang, Zhitao Li, Jiuhai Chen, Lichang Chen, Ning Cheng, Jianzong Wang, Tianyi Zhou, and Jing Xiao. 2024. From Quantity to Quality: Boosting LLM Performance with Self-Guided Data Selection for Instruction Tuning. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Langua...

2024