Pith. sign in

REVIEW 4 major objections 5 minor 49 references

A Plug-and-Play Natural Language Rewriter for Natural Language to SQL

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

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

Pith's one-line read REWRITER proposes a plug-and-play module that automatically rewrites flawed natural-language questions—using schema, column values, and foreign keys—and reports consistent execution-accuracy gains across text-to-SQL systems.

desk verdict Sensible NL-rewriting idea for NL2SQL, but the main evaluation may be transductive and an EM collapse is hidden; worth review with protocol fixes. read the letter →

arxiv 2412.17068 v1 pith:NPDTMNW7 submitted 2024-12-22 cs.DB

Peixian Ma , Boyan Li , Runzhi Jiang , Ju Fan , Nan Tang , Yuyu Luo This is my paper · ORCID
classification cs.DB
keywords NL2SQLtext-to-SQLqueryrewritingself-reflectionmulti-agentLLMexecutionaccuracySpiderbenchmarkBIRD
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 tries to establish that the user's natural-language question itself is a fixable bottleneck in text-to-SQL, and that rewriting the question—rather than retraining or swapping the SQL generator—can reliably improve results. REWRITER is a plug-and-play module placed in front of any NL2SQL model, which it treats as a black box; a Checker decides whether the generated SQL matches the user's intent, and only when it does not do a Reflector and Rewriter edit the question using database schema, column values, and foreign-key relationships. The claimed payoff is consistent average execution-accuracy gains of 1.6 points on Spider and 2.0 points on BIRD across baselines ranging from rule-based parsers to GPT-4. A sympathetic reading of the experiments is that selective, database-informed rewriting is a working complement to better SQL models, not a replacement for them.

What carries the argument

The load-bearing mechanism is the weighted self-reflection loop in the Reflector. The Reflector starts by initializing a memory of generic flaw types and rewriting actions, each with a weight; before rewriting a question it loads the highest-weighted experiences as rules, and after the downstream SQL is produced the Checker's binary verdict ('SQL matches NL' or not) updates those weights. This makes REWRITER a data-free, in-context learner whose rewriting guidance adapts to the distribution of flaws it encounters. The second mechanism is the Checker's two-stage gate, which uses executable SQL and an LLM's judgment to restrict rewriting to genuinely flawed questions, minimizing the new hallucinations that rewriting correct questions would introduce.

What would settle it

Run REWRITER on a fresh set of questions with the Reflector's experience weights frozen at their initialization, then run it again with weights updated during evaluation, and compare execution accuracy. If the frozen-weight run does not reproduce the reported 1.6% and 2.0% average gains, the improvement is partly an artifact of updating on the test questions rather than a general property of the rewriting.

Watch

Extended reading notes

Core claim

REWRITER's central claim is that a check-reflect-rewrite loop turns vague, incomplete, or misremembered user questions into clearer ones that existing NL2SQL models translate more accurately. The Checker gates the pipeline: it first discards queries whose SQL fails to execute, then asks an LLM to judge whether the execution result matches the natural-language intent, labeling each sample 'SQL matches NL' or 'SQL does not match NL.' The Reflector extracts the key entities and conditions in the flagged question, compares them against the database, and emits a (keyword, flaw, action) reflection, while the Rewriter applies that reflection to complete missing information, correct wrong entities, resolve ambiguity, or normalize non-standard phrasing. The experiments report consistent execution-accuracy improvements on Spider and BIRD—averaging 1.6% and 2.0% respectively—across bases including C3, DAIL-SQL, DTS-SQL, NatSQL+T5, RESDSQL, and direct GPT-3.5/GPT-4 prompting, and the ablations attribute the gain to the Checker's selective rewriting and the Reflector's accumulated experience.

Load-bearing premise

The entire improvement rests on the Checker's binary verdict being a reliable reward signal, yet in the reported runs that verdict is correct on only 55–82% of the samples it flags, so many rewritten questions were probably never flawed.

Editorial extensions

If this is right

  • Any NL2SQL model can gain accuracy by being wrapped with REWRITER, without changing its parameters; the paper shows gains on rule-based, small open-source, and large closed-source generators.
  • Rewriting only the queries the Checker flags is what preserves accuracy; the ablation in which every question is rewritten typically hurts, so selectivity is the safety mechanism.
  • The Reflector's self-learned experience beats hand-crafted experience on most tested models, implying the loop improves as it sees more flawed questions.
  • Multi-round rewriting can squeeze out additional gains on some systems, with token cost growing slowly because later rounds revisit only the still-flawed subset.
  • Because REWRITER outputs natural language rather than SQL, it should compose with future NL2SQL pipelines, including agent-based ones, without internal changes.

Reading between the lines

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

  • Editorial inference: if the Checker's precision (55–82% on the reported bad samples) is the main ceiling, then a more reliable or calibrated verifier—or a confidence threshold that rewrites only high-certainty positives—could roughly double the reported accuracy gains.
  • Editorial inference: the experience-weight update looks like an online reward-weighted learner, so a natural stress test is whether the weights learned on Spider transfer to BIRD or to an unseen database domain; the paper does not report cross-benchmark transfer.
  • Editorial inference: because weights may be updated on the very dev queries being scored, part of the gain could be transductive; a fixed-weight or train/dev-split evaluation would quantify how much of the improvement generalizes.
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 / 5 minor

Summary. The paper proposes REWRITER, a plug-and-play multi-agent module that rewrites flawed natural language queries before they are passed to an existing NL2SQL system. The module consists of a Checker that decides whether a generated SQL query matches the user's NL, a Reflector that analyzes flaws and accumulates rewriting experience, a Rewriter that produces corrected NL, and a shared Memory. The authors report experiments on the Spider and BIRD dev sets with several NL2SQL baselines, claiming average execution-accuracy gains of 1.6% on Spider and 2.0% on BIRD. Ablations show that removing the Checker or the Reflector generally hurts performance, and that learning-updated experience (LE) gives larger gains than hand-crafted or self-initialized experience.

Significance. If the claimed plug-and-play property holds, the paper addresses a genuinely underexplored bottleneck in NL2SQL: the quality of the user's natural language input rather than the SQL generation model itself. The idea of checking generated SQL, reflecting on flaws, and rewriting only flawed inputs is simple, practical, and broadly applicable to black-box NL2SQL systems. The paper also ships a concrete multi-agent architecture with prompts in the appendix, and the self-initialized (IN) ablation provides partial evidence that the rewriting mechanism itself can help without training data. However, the central claim of 'consistent enhancement' depends on the evaluation protocol being a fair test of a fixed plug-and-play module on fresh inputs, and on the reported averages being reliable. The current manuscript leaves those points ambiguous, so the significance cannot yet be fully assessed.

major comments (4)
  1. [Reflector and Table 4] The main results may be transductive. The Reflector section states that experience weights are adjusted 'before the next round of reasoning and rewriting' based on Checker feedback, and the Memory 'can continuously accumulate historical data from different NL2SQL methods.' Table 4's LE row is 'experience summarized and updated in the multi-round rewriting process.' If the dev set is processed sequentially with shared memory, then Checker feedback on earlier dev queries shapes the experience used to rewrite later dev queries, and the same dev queries are used for the final reported numbers. This would mean the headline gains in Tables 1-2 do not measure a fixed plug-and-play rewriter on fresh inputs. The paper must state explicitly whether experience weights are updated during dev-set evaluation, and if so, report a frozen-experience or per-query-reset condition. The IN row in Table 4 is encouraging but does not resolve this, since the 'All' configurations in Table 3 presumably include learned memory.
  2. [Table 1, DTS-SQL row] The DTS-SQL + REWRITER row shows EM collapsing from 77.2 to 47.9, a drop of 29.3 points, while EX improves only from 75.2 to 77.5. The paper does not mention this catastrophic exact-match degradation anywhere, and the abstract's claim that REWRITER 'consistently enhances downstream models' is directly contradicted on this row by its own metric definition. Even if the authors regard EX as the primary metric, the EM collapse indicates that rewriting can substantially change the generated SQL's structure, and it undermines the claim in the introduction and ablation discussion that the Checker 'minimizes unnecessary rewriting and potential hallucinations.' The paper needs to acknowledge this case and explain why EX is the appropriate conclusion metric here, or provide a decomposition of what happened on this configuration.
  3. [Tables 1-4 and Figure 5] The reported improvements are small (0.3 to 4.3 EX points in most rows) and no error bars, variance, or significance tests are provided for the main NL2SQL results. Figure 5 reports token efficiency averaged over 5 runs, but Tables 1-4 appear to be single runs with LLM-based agents, which are stochastic and multiplicatively amplify variance through the Checker, Reflector, and Rewriter stages. A 1.6% average gain could easily be within run-to-run noise for configurations like C3 + GPT-3.5-turbo (81.9 to 82.4) or DAIL-SQL + GPT-4 (83.1 to 83.6). The authors should report multiple seeds or at least confidence intervals for the headline numbers, especially because the main claim is about consistent improvement.
  4. [Checker evaluation, Tables 1-2] The Checker precision (CP) values in Tables 1-2 range from 53.0 to 82.2, meaning that in several configurations a substantial share of the queries flagged as flawed are actually correct (e.g., CP 55.8 for C3 + GPT-3.5-turbo and CP 53.0 for DAIL-SQL + GPT-4 on BIRD). Since only flagged queries are rewritten, low CP means many correct queries are unnecessarily rewritten, which could introduce hallucinations. The paper does not report how many such false-positive rewrites actually hurt, nor does it analyze the interaction between CP and downstream EX. A precision-recall analysis of the Checker, or an error analysis of the rewritten-but-originally-correct cases, is needed to support the claim that the Checker successfully minimizes negative impact.
minor comments (5)
  1. [Tables 1, 3, 4] The base EX numbers for the same configurations are inconsistent across tables: NatSQL + T5-Base is 69.7 in Table 1 but 69.4 in Tables 3 and 4; NatSQL + T5-3B is 71.4 in Table 1 but 71.8 in Tables 3 and 4; DTS-SQL is 75.2 in Table 1 but the same value appears in Table 4. The authors should clarify whether these are the same runs or different evaluation conditions, and if they differ, why.
  2. [Appendix prompts] Several appendix prompt blocks end with '### OUPUT:' instead of '### OUTPUT:', and one block has a stray 'DONT CONVERT IT INTO QUERY.' without a closing quotation mark. These typos should be fixed for reproducibility.
  3. [Settings] The description of Checker Precision (CP) is circular: CP is defined as 'the precision of the bad samples that NL does not match the SQL,' but it is not stated what the ground-truth label for a 'bad sample' is, nor how the reference standard was obtained for the dev set. The paper should specify the labeling procedure.
  4. [Figure 4] Figure 4 reports multi-round rewriting effects on Spider-dev, but the number of rounds and the stopping criterion are not defined in the text. The reader cannot tell whether 'multi-round' means two rounds, three rounds, or until convergence, and this affects both the accuracy and token-efficiency conclusions.
  5. [Discussion] The Discussion states that 'running and testing of the REWRITER framework and above NL2SQL method resulted in a significant consumption of tokens, estimated to be around 45 million tokens.' This sentence is incomplete about what the 45M tokens correspond to (all experiments? one configuration?) and reads more like a cost footnote than a scientific result. It should be moved or clarified.

Circularity Check

1 steps flagged · score 5.0 of 10

Main results use dev-set-adapted experience memory, making the plug-and-play gains partly transductive; the self-initialized ablation preserves some independent content.

  1. fitted input called prediction [Methodology, Reflector section (paragraph 2); see also Memory section and Table 4 caption.]
    "Before the next round of reasoning and rewriting, the Reflector will adjust the weights of the above experience based on the reward signal, which is characterized by a sparse binary state (NL MATCH SQL or NL DO NOT MATCH SQL) provided by the Checker. By continuously looping through the above process at reasoning, Reflector can accumulate some effective flaw experiences and action experiences, enabling it to adjust itself in time based on the distribution of flaw occurrences in different NL."

    The reported '+REWRITER' rows in Tables 1-2 are produced by the learning-updated experience variant: Table 4's LE values equal the Table 1 plus-REWRITER EX values (e.g., NatSQL+T5-3B 75.7; DTS-SQL 77.5). LE is defined as experience 'summarized and updated in the multi-round rewriting process,' and the update reward is the Checker's binary 'NL MATCH SQL / NL DO NOT MATCH SQL' judgment on the very NL/SQL pairs being evaluated.

full rationale

No self-definitional or self-citation-load-bearing circularity was found. The Checker/Reflector/Rewriter loop is evaluated against gold execution accuracy, not against the Checker's own labels, so the pipeline's output is not simply its input. The main concern is that the headline improvements (abstract's 1.6% and 2.0%, Tables 1-2) correspond to the LE variant, whose experience weights are updated using Checker feedback during the multi-round rewriting process. The paper's language ('accumulate historical data', 'adjust itself in time based on the distribution of flaw occurrences in different NL') indicates persistent memory across the evaluation set, meaning later dev queries benefit from earlier dev queries. This makes the reported 'plug-and-play' gains partly transductive rather than a property of a fixed module applied independently to each query. The IN ablation in Table 4 provides some independent evidence that rewriting with self-initialized (non-updated) experiences still helps, which prevents the central claim from being entirely circular. The Checker's low precision (55-82%) is a correctness risk, not a circularity, since the final metric is gold-based execution accuracy. Overall, the paper would need a reset-per-query or frozen-experience evaluation to fully support the plug-and-play claim.

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

The paper introduces no new physical or mathematical entities; its "Memory" is a software component rather than an invented entity. The free parameters are hand-chosen hyperparameters of the agent loop, and the axioms are domain assumptions about LLM reliability and evaluation protocol.

free parameters (3)
  • Initial experience count = 10
    The Reflector initialization prompt asks for 10 possible problems; this number is hand-chosen and could affect performance.
  • Experience selection batch (top-k) = not specified
    The Reflector loads the "batch of experiences with the highest weight", but the batch size is not given, and it directly influences which rewriting actions are considered.
  • Number of rewriting rounds = not specified
    Figure 4 shows single-round and multi-round results; the main tables do not state how many rounds were used, and multi-round increases token cost.
assumptions (3)
  • domain assumption The Checker's LLM-based judgment of whether SQL execution results match NL intent is reliable enough to serve as a training signal.
    The whole self-reflection loop (Figure 3) depends on this reward signal; CP values of 50-80% in Table 1 suggest the signal is noisy.
  • ad hoc to paper Using the dev set to accumulate rewriting experience does not invalidate the comparison to frozen baselines.
    Table 4's learning-updated experiences (LE) are updated during the multi-round rewriting process on the dev set, yet the same dev set is used for the reported accuracy, which is a form of transductive evaluation.
  • domain assumption The NL2SQL baselines are evaluated in their standard configurations.
    The paper cites baseline scores but does not report its own re-implementations or configurations, so comparability depends on the original papers.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Plug-and-Play Natural Language Rewriter for Natural Language to SQL." pith.science (2026). https://pith.science/paper/NPDTMNW7

@misc{pith2026241217068,
  author       = {Pith},
  title        = {Pith review of: A Plug-and-Play Natural Language Rewriter for Natural Language to SQL},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NPDTMNW7}},
  note         = {Machine review of arXiv:2412.17068}
}
read the original abstract

Existing Natural Language to SQL (NL2SQL) solutions have made significant advancements, yet challenges persist in interpreting and translating NL queries, primarily due to users' limited understanding of database schemas or memory biases toward specific table or column values. These challenges often result in incorrect NL2SQL translations. To address these issues, we propose REWRITER, a plug-and-play module designed to enhance NL2SQL systems by automatically rewriting ambiguous or flawed NL queries. By incorporating database knowledge and content (e.g., column values and foreign keys), REWRITER reduces errors caused by flawed NL inputs and improves SQL generation accuracy. Our REWRITER treats NL2SQL models as black boxes, ensuring compatibility with various NL2SQL methods, including agent-based and rule-based NL2SQL solutions. REWRITER comprises three key components: Checker, Reflector, and Rewriter. The Checker identifies flawed NL queries by assessing the correctness of the generated SQL, minimizing unnecessary rewriting and potential hallucinations. The Reflector analyzes and accumulates experience to identify issues in NL queries, while the Rewriter revises the queries based on Reflector's feedback. Extensive experiments on the Spider and BIRD benchmarks demonstrate that REWRITER consistently enhances downstream models, achieving average improvements of 1.6% and 2.0% in execution accuracy, respectively.

Figures

Figures reproduced from arXiv: 2412.17068 by the authors.

Figure 1
Figure 1. Demonstration of our work. The proposed plug-and [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. An overview of the proposed REWRITER framework, which comprises the following components: (i) Checker, which determines whether NL matches the generated SQL; (ii) Reflector, which analyzes the flawed NL and gives the rewriting reflection with the reference of DB; (iii) Rewriter, which rewrites the flawed NL under the guidance of reflection. In addition, a task-specific Memory module provides information exchange and… view at source ↗
Figure 3
Figure 3. Demonstration of self-reflection mechanism. In the [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Execution accuracy and token efficiency of [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Effectiveness of Checker. Token efficiency vs. Precision on Spider-dev set. experience refers to the experience that the Reflector sum￾marizes and updates in the multi-round rewriting process. Experimental results illustrate that the rules initialized by Reflector can …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 25 canonical work pages

  1. [1]

    , " * write output.state after.block = add.period write newline

    ENTRY address archivePrefix author booktitle chapter edition editor eid eprint howpublished institution isbn journal key month note number organization pages publisher school series title type volume year label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.a...

  2. [2]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize " " * FUNCT...

  3. [3]

    Bao, G.; and Zhang, Y. 2023. A general contextualized rewriting framework for text summarization. IEEE/ACM Transactions on Audio, Speech, and Language Processing, 31: 1624--1635

    work page 2023

  4. [4]

    Dong, X.; Zhang, C.; Ge, Y.; Mao, Y.; Gao, Y.; Lin, J.; Lou, D.; et al. 2023. C3: Zero-shot text-to-sql with chatgpt. arXiv preprint arXiv:2307.07306

    arXiv 2023

  5. [5]

    Dubey, A.; Jauhri, A.; Pandey, A.; Kadian, A.; Al-Dahle, A.; Letman, A.; Mathur, A.; Schelten, A.; Yang, A.; Fan, A.; et al. 2024. The Llama 3 Herd of Models. arXiv preprint arXiv:2407.21783

    arXiv 2024

  6. [6]

    Eyal, B.; Bachar, A.; Haroche, O.; Mahabi, M.; and Elhadad, M. 2023. Semantic Decomposition of Question and SQL for Text-to-SQL Parsing. arXiv preprint arXiv:2310.13575

    arXiv 2023

  7. [7]

    Fu, H.; Liu, C.; Wu, B.; Li, F.; Tan, J.; and Sun, J. 2023. Catsql: Towards real world natural language to sql applications. Proceedings of the VLDB Endowment, 16(6): 1534--1547

    work page 2023

  8. [8]

    R.; Drake, J.; and Zhang, Q

    Gan, Y.; Chen, X.; Xie, J.; Purver, M.; Woodward, J. R.; Drake, J.; and Zhang, Q. 2021. Natural SQL : Making SQL Easier to Infer from Natural Language Specifications. In Findings of the Association for Computational Linguistics: EMNLP 2021, 2030--2042. Punta Cana, Dominican Republic: Association for Computational Linguistics

    work page 2021

Show all 49 references
  1. [9]

    Gao, C.; Li, B.; Zhang, W.; Lam, W.; Li, B.; Huang, F.; Si, L.; and Li, Y. 2022. Towards generalizable and robust text-to-sql parsing. arXiv preprint arXiv:2210.12674

    2022 arXiv

  2. [10]

    Gao, D.; Wang, H.; Li, Y.; Sun, X.; Qian, Y.; Ding, B.; and Zhou, J. 2023. Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation. CoRR, abs/2308.15363

    2023 arXiv

  3. [11]

    GLM, T.; Zeng, A.; Xu, B.; Wang, B.; Zhang, C.; Yin, D.; Rojas, D.; Feng, G.; Zhao, H.; Lai, H.; et al. 2024. ChatGLM: A Family of Large Language Models from GLM-130B to GLM-4 All Tools. arXiv preprint arXiv:2406.12793

    2024 arXiv

  4. [12]

    Gu, Z.; Fan, J.; Tang, N.; Cao, L.; Jia, B.; Madden, S.; and Du, X. 2023 a . Few-shot text-to-sql translation using structure and content prompt learning. Proceedings of the ACM on Management of Data, 1(2): 1--28

    2023

  5. [13]

    Gu, Z.; Fan, J.; Tang, N.; Zhang, S.; Zhang, Y.; Chen, Z.; Cao, L.; Li, G.; Madden, S.; and Du, X. 2023 b . Interleaving Pre-Trained Language Models and Large Language Models for Zero-Shot NL2SQL Generation. CoRR abs/2306.08891 (2023). arXiv preprint arXiv:2306.08891

    2023 arXiv

  6. [14]

    Hua, W.; Fan, L.; Li, L.; Mei, K.; Ji, J.; Ge, Y.; Hemphill, L.; and Zhang, Y. 2023. War and peace (waragent): Large language model-based multi-agent simulation of world wars. arXiv preprint arXiv:2311.17227

    2023 arXiv

  7. [15]

    Hwang, A.; Oza, N.; Callison-Burch, C.; and Head, A. 2023. Rewriting the script: Adapting text instructions for voice interaction. In Proceedings of the 2023 ACM designing interactive systems conference, 2233--2248

    2023

  8. [16]

    Igamberdiev, T.; and Habernal, I. 2023. DP-BART for privatized text rewriting under local differential privacy. arXiv preprint arXiv:2302.07636

    2023 arXiv

  9. [17]

    Katsogiannis-Meimarakis, G.; and Koutrika, G. 2023. A survey on deep learning approaches for text-to-SQL. The VLDB Journal, 32(4): 905--936

    2023

  10. [18]

    Li, B.; Luo, Y.; Chai, C.; Li, G.; and Tang, N. 2024 a . The Dawn of Natural Language to SQL: Are We Fully Ready? Proc. VLDB Endow. , 17(11): 3318--3331

    2024

  11. [19]

    Li, H.; Zhang, J.; Li, C.; and Chen, H. 2023 a . RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL. In AAAI

    2023

  12. [20]

    Li, H.; Zhang, J.; Liu, H.; Fan, J.; Zhang, X.; Zhu, J.; Wei, R.; Pan, H.; Li, C.; and Chen, H. 2024 b . Codes: Towards building open-source language models for text-to-sql. Proceedings of the ACM on Management of Data, 2(3): 1--28

    2024

  13. [21]

    Li, J.; Hui, B.; Qu, G.; Li, B.; Yang, J.; Li, B.; Wang, B.; Qin, B.; Geng, R.; Huo, N.; Zhou, X.; Ma, C.; Li, G.; Chang, K. C. C.; Huang, F.; Cheng, R.; and Li, Y. 2023 b . Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQ...

    2023 arXiv

  14. [22]

    Li, Y.; Yu, Y.; Li, H.; Chen, Z.; and Khashanah, K. 2023 c . TradingGPT: Multi-agent system with layered memory and distinct characters for enhanced financial trading performance. arXiv preprint arXiv:2309.03736

    2023 arXiv

  15. [23]

    Li, Z.; Wang, X.; Zhao, J.; Yang, S.; Du, G.; Hu, X.; Zhang, B.; Ye, Y.; Li, Z.; Zhao, R.; et al. 2024 c . PET-SQL: A Prompt-enhanced Two-stage Text-to-SQL Framework with Cross-consistency. arXiv preprint arXiv:2403.09732

    2024 arXiv

  16. [24]

    Liu, X.; Shen, S.; Li, B.; Ma, P.; Jiang, R.; Luo, Y.; Zhang, Y.; Fan, J.; Li, G.; and Tang, N. 2024. A Survey of NL2SQL with Large Language Models: Where are we, and where are we going? CoRR, abs/2408.05109

    2024

  17. [25]

    Luo, Y.; Qin, X.; Chai, C.; Tang, N.; Li, G.; and Li, W. 2022 a . Steerable Self-Driving Data Visualization. IEEE Trans. Knowl. Data Eng. , 34(1): 475--490

    2022

  18. [26]

    Luo, Y.; Qin, X.; Tang, N.; and Li, G. 2018 a . DeepEye: Towards Automatic Data Visualization. In ICDE , 101--112. IEEE Computer Society

    2018

  19. [27]

    Luo, Y.; Qin, X.; Tang, N.; Li, G.; and Wang, X. 2018 b . DeepEye: Creating Good Data Visualizations by Keyword Search. In SIGMOD Conference , 1733--1736. ACM

    2018

  20. [28]

    Luo, Y.; Tang, N.; Li, G.; Chai, C.; Li, W.; and Qin, X. 2021. Synthesizing Natural Language to Visualization (NL2VIS) Benchmarks from NL2SQL Benchmarks. In SIGMOD Conference , 1235--1247. ACM

    2021

  21. [29]

    Luo, Y.; Tang, N.; Li, G.; Li, W.; Zhao, T.; and Yu, X. 2020. DeepEye: A Data Science System for Monitoring and Exploring COVID-19 Data. IEEE Data Eng. Bull. , 43(2): 121--132

    2020

  22. [30]

    Luo, Y.; Tang, N.; Li, G.; Tang, J.; Chai, C.; and Qin, X. 2022 b . Natural Language to Visualization by Neural Machine Translation. IEEE Trans. Vis. Comput. Graph. , 28(1): 217--226

    2022

  23. [31]

    OpenAI. 2023. GPT-4 Technical Report. arXiv preprint arXiv:2303.08774

    2023 arXiv

  24. [32]

    S.; O'Brien, J

    Park, J. S.; O'Brien, J. C.; Cai, C. J.; Morris, M. R.; Liang, P.; and Bernstein, M. S. 2023. Generative Agents: Interactive Simulacra of Human Behavior. In In the 36th Annual ACM Symposium on User Interface Software and Technology (UIST '23), UIST '23. New York, NY, USA: Asso...

    2023

  25. [33]

    Pourreza, M.; and Rafiei, D. 2023. DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction. arXiv preprint arXiv:2304.11015

    2023 arXiv

  26. [34]

    Pourreza, M.; and Rafiei, D. 2024. DTS-SQL: Decomposed Text-to-SQL with Small Large Language Models. arXiv preprint arXiv:2402.01117

    2024 arXiv

  27. [35]

    Qin, X.; Luo, Y.; Tang, N.; and Li, G. 2020. Making data visualization more efficient and effective: a survey. VLDB J. , 29(1): 93--117

    2020

  28. [36]

    Rai, D.; Wang, B.; Zhou, Y.; and Yao, Z. 2023. Improving Generalization in Language Model-based Text-to- SQL Semantic Parsing: Two Simple Semantic Boundary-based Techniques. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 2: S...

    2023

  29. [37]

    Shen, L.; Shen, E.; Luo, Y.; Yang, X.; Hu, X.; Zhang, X.; Tai, Z.; and Wang, J. 2021. Towards Natural Language Interfaces for Data Visualization: A Survey. CoRR, abs/2109.03506

    2021 arXiv

  30. [38]

    Shu, L.; Luo, L.; Hoskere, J.; Zhu, Y.; Liu, Y.; Tong, S.; Chen, J.; and Meng, L. 2024. Rewritelm: An instruction-tuned large language model for text rewriting. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 38, 18970--18980

    2024

  31. [39]

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

    2024 arXiv

  32. [40]

    Tang, J.; Luo, Y.; Ouzzani, M.; Li, G.; and Chen, H. 2022. Sevi: Speech-to-Visualization through Neural Machine Translation. In SIGMOD Conference , 2353--2356. ACM

    2022

  33. [41]

    Wang, B.; Ren, C.; Yang, J.; Liang, X.; Bai, J.; Chai, L.; Yan, Z.; Zhang, Q.-W.; Yin, D.; Sun, X.; and Li, Z. 2024. MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL. arXiv:2312.11242

    2024 arXiv

  34. [42]

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

    2019 arXiv

  35. [43]

    Wang, L.; Ma, C.; Feng, X.; Zhang, Z.; Yang, H.; Zhang, J.; Chen, Z.; Tang, J.; Chen, X.; Lin, Y.; et al. 2023. A survey on large language model based autonomous agents. arXiv preprint arXiv:2308.11432

    2023 arXiv

  36. [44]

    Wolfson, T.; Geva, M.; Gupta, A.; Gardner, M.; Goldberg, Y.; Deutch, D.; and Berant, J. 2020. Break it down: A question understanding benchmark. Transactions of the Association for Computational Linguistics, 8: 183--198

    2020

  37. [45]

    Wu, Y.; Hu, N.; Qi, G.; Bi, S.; Ren, J.; Xie, A.; and Song, W. 2023. Retrieve-rewrite-answer: A kg-to-text enhanced llms framework for knowledge graph question answering. arXiv preprint arXiv:2309.11206

    2023 arXiv

  38. [46]

    Yu, T.; Zhang, R.; Yang, K.; Yasunaga, M.; Wang, D.; Li, Z.; Ma, J.; Li, I.; Yao, Q.; Roman, S.; Zhang, Z.; and Radev, D. 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 Conference...

    2018

  39. [47]

    Zhang, J.; Xiang, J.; Yu, Z.; Teng, F.; Chen, X.; Chen, J.; Zhuge, M.; Cheng, X.; Hong, S.; Wang, J.; Zheng, B.; Liu, B.; Luo, Y.; and Wu, C. 2024. AFlow: Automating Agentic Workflow Generation. CoRR, abs/2410.10762

    2024 arXiv

  40. [48]

    E.; Li, L.; Wu, J.; Wang, T.; Qiu, S.; Zhang, J.; Chen, J.; Wu, R.; Wang, S.; Zhu, S.; Chen, J.; Zhang, W.; Zhang, N.; Chen, H.; Cui, P.; and Sachan, M

    Zhou, W.; Jiang, Y. E.; Li, L.; Wu, J.; Wang, T.; Qiu, S.; Zhang, J.; Chen, J.; Wu, R.; Wang, S.; Zhu, S.; Chen, J.; Zhang, W.; Zhang, N.; Chen, H.; Cui, P.; and Sachan, M. 2023. Agents: An Open-source Framework for Autonomous Language Agents. arXiv:2309.07870

    2023 arXiv

  41. [49]

    Zhu, Y.; Du, S.; Li, B.; Luo, Y.; and Tang, N. 2024. Are Large Language Models Good Statisticians? CoRR, abs/2406.07815

    2024 arXiv

Pith tools

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