AmbiSQL: Interactive Ambiguity Resolution for Text-to-SQL

• The paper introduces AmbiSQL, an interactive framework that detects and resolves ambiguities in natural language queries to ensure accurate SQL generation.
• It employs a two-stage pipeline using LLM-based detection and multiple-choice clarification to address both database and reasoning-related ambiguities.
• Experimental results demonstrate that integrating AmbiSQL can improve Text-to-SQL accuracy by up to 50 percentage points on ambiguous queries.

AmbiSQL is an interactive preprocessing framework for Text-to-SQL that addresses ambiguity in natural-language questions by detecting ambiguous phrases, presenting targeted clarification questions in a multiple-choice format, rewriting the question to make the intended meaning explicit, and then passing the clarified query to a downstream Text-to-SQL system (Ding et al., 21 Aug 2025). It is designed for a setting in which LLM based Text-to-SQL systems may generate SQL that is syntactically valid but semantically wrong when the input question is underspecified, particularly in realistic database environments where schema knowledge, latent reasoning, temporal interpretation, and missing SQL-relevant operators all contribute to ambiguity (Ding et al., 21 Aug 2025).

1. Problem setting and formal objective

AmbiSQL is situated within the standard Text-to-SQL formulation

$f : (\mathsf{q}, \mathcal{D}) \mapsto \mathcal{Q},$

where a natural-language question $\mathsf{q}$ and database schema $\mathcal{D}$ are mapped to a SQL query $\mathcal{Q}$ (Ding et al., 21 Aug 2025). Its core premise is that the same question may admit multiple valid mappings or interpretations, so an LLM may confidently commit to the wrong one. The system is therefore organized around ambiguity detection and ambiguity resolution rather than direct one-shot SQL generation.

The paper states the ambiguity detection problem as follows: given a question ${\sf q}$, a Text-to-SQL system $f$, and predefined ambiguity types $A$, identify ambiguous phrases

$P = \{p_1, p_2, \dots, p_k\},$

with corresponding ambiguity types $a_i \in A$, such that these phrases cause $f({\sf q}, \mathcal{D})$ to generate an incorrect SQL $\mathsf{q}$0 (Ding et al., 21 Aug 2025). The ambiguity resolution objective is then to rewrite $\mathsf{q}$1 into $\mathsf{q}$2 so that

$\mathsf{q}$3

This makes the rewritten question, rather than the original ambiguous utterance, the direct input to the downstream semantic parser (Ding et al., 21 Aug 2025).

A central motivation is that many benchmark settings obscure the problem by associating each question with one “gold” SQL even when multiple interpretations are plausible. The system is therefore aimed at realistic cases such as references that map to multiple schema items, vague value mentions, omitted SQL operators, underspecified temporal or spatial constraints, and questions whose resolution depends on external or latent knowledge rather than schema matching alone (Ding et al., 21 Aug 2025).

2. Ambiguity taxonomy

A major contribution of AmbiSQL is a fine-grained ambiguity taxonomy that divides ambiguity into two top-level dimensions: DB-related ambiguity and LLM-related ambiguity (Ding et al., 21 Aug 2025). DB-related ambiguity concerns unclear or underspecified references to schema or content. LLM-related ambiguity concerns cases where SQL generation depends on external knowledge or reasoning and the question does not adequately constrain that reasoning.

Within DB-related ambiguity, AmbiSQL identifies three subtypes. “Unclear schema reference” covers cases such as “oldest user,” which may mean oldest by age or by registration date, or “Which city is the largest one?”, which may mean largest by area or population. “Unclear value reference” covers cases such as asking for “New York City” when the database stores “NYC,” or “COVID-19” when the database contains “coronavirus.” “Missing SQL-related keywords” covers cases like “Show me users by registration date,” which could imply ORDER BY, GROUP BY, or WHERE (Ding et al., 21 Aug 2025).

Within LLM-related ambiguity, the taxonomy contains four subtypes. “Unclear knowledge source” addresses questions such as “female employees,” where it is unclear whether the answer should come from a gender column or be inferred from names. “Insufficient reasoning context” covers cases like “current exchange rate,” where target currencies or date are omitted. “Conflicting knowledge” refers to contradictory assumptions, such as asking about participants in an event that never happened. “Ambiguous temporal/spatial scope” includes examples such as “after the 2018 World Cup,” “end of the Vietnam War,” and “counties in Silicon Valley,” where temporal or geographic boundaries remain underdetermined (Ding et al., 21 Aug 2025).

This taxonomy is broader than a schema-linking inventory. It treats ambiguity not only as a mismatch between words and columns, but also as a failure to specify the source and scope of reasoning. Related benchmark work reinforces the importance of this distinction. AMBROSIA was introduced as a benchmark in which ambiguity persists even when database context is provided, and it reports that even advanced models struggle to identify and interpret ambiguity in questions (Saparina et al., 2024). CLARITY extends this line by emphasizing multi-faceted ambiguities and showing that systems often detect ambiguity yet struggle to accurately localize and resolve the underlying schema-level sources (Sarwar et al., 24 Apr 2026).

3. Interactive detection, clarification, and rewriting

AmbiSQL uses a two-stage pipeline: “Ambiguity Identification” and “Iterative Refinement” (Ding et al., 21 Aug 2025). In the first stage, an ambiguity detection module uses a pre-trained LLM via in-context learning. The prompt includes an explicit definition of ambiguity, the ambiguity taxonomy, and representative examples. The detector identifies ambiguous substrings and classifies each into the appropriate ambiguity type (Ding et al., 21 Aug 2025).

Detected ambiguities are then passed to a clarification question generation module. For each ambiguity, the system generates a targeted clarification question, a short description or supporting context, and a set of candidate answers in multiple-choice form. These questions may be supported by relevant database snippets for DB-related ambiguities, summarized parametric LLM knowledge for reasoning-related ambiguities, and explicit candidate mappings for values, columns, or temporal interpretations (Ding et al., 21 Aug 2025). This design constrains user feedback rather than requiring free-text reformulation.

The second stage is “Iterative Refinement.” User clarifications are stored in a “tree-like preference structure” indexed by ambiguity subtype, with leaf nodes storing concrete choices such as a selected column or an exact temporal interpretation. If a later choice conflicts with an earlier one, AmbiSQL performs LLM-based in-context conflict resolution so that the stored preference reflects the latest user intent (Ding et al., 21 Aug 2025). Users may also add extra constraints, such as “drivers need to be German.” These are handled separately because additional constraints may themselves be ambiguous (Ding et al., 21 Aug 2025).

The end-to-end workflow is explicitly modular:

1. User inputs: natural-language question, target database/dialect.
2. Ambiguity detection: identify ambiguous phrases, classify each according to the taxonomy.
3. Clarification generation: generate one multiple-choice question per detected ambiguity, attach support such as schema snippets or knowledge summaries.
4. User interaction: user selects intended interpretation from drop-down options, optionally adds extra constraints.
5. Preference update: store answers in the taxonomy-indexed preference tree, reconcile conflicts if a new answer contradicts a previous one.
6. Query refinement / rewriting: synthesize original question, user clarifications, and extra constraints into a rewritten question.
7. Iterative ambiguity re-check: rerun detection on the rewritten question if needed.
8. Final Text-to-SQL generation: send clarified question to a downstream system, generate final SQL (Ding et al., 21 Aug 2025).

A common misconception is that AmbiSQL is itself a replacement for an existing parser. The paper instead presents it as a preprocessing layer rather than a replacement for existing Text-to-SQL models (Ding et al., 21 Aug 2025). In that respect it differs from systems such as ODIN, which recasts NL2SQL as recommendation over a set of SQL queries under schema ambiguity (Vaidya et al., 25 May 2025), and from SOMA-SQL, which resolves ambiguity autonomously through synthetic query log construction and ambiguity-driven probing without human-in-the-loop (Somayajula et al., 9 Jun 2026).

4. Experimental setting and empirical results

The demonstration and evaluation use five databases from BIRD: California Schools, Debit Card Specializing, Formula One, Codebase Community, and European Football (Ding et al., 21 Aug 2025). The authors also construct a dataset of 40 ambiguous queries from BIRD and TAG, designed to cover all ambiguity categories in the taxonomy, with each query annotated by humans and paired with ground-truth SQL (Ding et al., 21 Aug 2025). For downstream Text-to-SQL, AmbiSQL is integrated with XiYan-SQL, and all experiments use GPT-4o as the underlying LLM inside AmbiSQL (Ding et al., 21 Aug 2025).

The evaluation protocol uses Exact Match accuracy for SQL generation and precision, recall, and $\mathsf{q}$4 for ambiguity detection. During evaluation, each query is processed without additional user-specified constraints (Ding et al., 21 Aug 2025). The headline result is that on the 40-query ambiguous dataset, XiYan-SQL alone achieves 42.5% exact match, whereas XiYan-SQL + AmbiSQL achieves 92.5% exact match, an absolute improvement of 50 percentage points (Ding et al., 21 Aug 2025).

The benchmark breakdown is also reported. For TAG samples, exact match rises from 20.0% without AmbiSQL to 85.0% with AmbiSQL. For BIRD samples, it rises from 75.0% to 100.0% (Ding et al., 21 Aug 2025). The paper emphasizes the TAG result because TAG queries often require external knowledge, more complex reasoning, and multiple-table reasoning (Ding et al., 21 Aug 2025).

Ambiguity detection performance is reported as 87.2% precision, 89.1% recall, and 88.2% $\mathsf{q}$5 overall (Ding et al., 21 Aug 2025). The paper further reports 83.9% precision, 92.9% recall, and 88.1% $\mathsf{q}$6 for DB-related ambiguity, and 93.8% precision, 83.3% recall, and 88.2% $\mathsf{q}$7 for LLM-related ambiguity (Ding et al., 21 Aug 2025). Among subtypes, “Missing SQL-related keywords” and “Conflicting knowledge” each achieve 100.0 / 100.0 / 100.0, while “Ambiguous temporal/spatial scope” achieves 100.0 / 81.8 / 90.0 (Ding et al., 21 Aug 2025).

These results place AmbiSQL in a broader empirical landscape in which ambiguity remains difficult for current systems. AMBROSIA reports that even strong models often capture one interpretation rather than the ambiguity set (Saparina et al., 2024). CLARITY shows that ambiguity-aware systems can exhibit high ambiguity detection accuracy while still failing on schema-level localization (Sarwar et al., 24 Apr 2026). SOMA-SQL reports a 13.0% average execution-accuracy improvement over state-of-the-art baselines by combining synthetic query logs with ambiguity-driven probing (Somayajula et al., 9 Jun 2026). AmbiSQL’s contribution within this landscape is specifically its interactive clarification loop.

5. Interface, implementation, and deployment model

AmbiSQL is presented as a system demonstration with a three-panel user interface (Ding et al., 21 Aug 2025). The “User Input Panel” allows entry of a custom question, selection of SQL dialect and database, or choice of a predefined ambiguous example. The “Ambiguity Resolution Panel” displays one multiple-choice clarification question for each detected ambiguity, with candidate options in drop-down menus, relevant schema snippets or descriptions as context, and a separate field for extra constraints. The “SQL Generation Panel” compares SQL from XiYan-SQL without ambiguity resolution against SQL from XiYan-SQL after AmbiSQL clarification, and a “Compare” button checks both against predefined ground-truth SQL (Ding et al., 21 Aug 2025).

The implementation is deliberately prompt-based and modular. Ambiguity detection uses in-context learning rather than task-specific fine-tuning, clarification and preference conflict handling also use LLM prompting/in-context learning, and no task-specific training or fine-tuning is required (Ding et al., 21 Aug 2025). The abstract states that code repository and demonstration are available at https://github.com/JustinzjDing/AmbiSQL (Ding et al., 21 Aug 2025).

This design reflects a broader architectural pattern in which enterprise-oriented NL-to-SQL systems increasingly rely on modular orchestration rather than monolithic parsing. For example, “Natural Language Query Engine for Relational Databases using Generative AI” combines retrieval-augmented schema grounding, business-rule retrieval, SQL generation, validation, iterative repair, and natural-language answer generation, but it does not include a dedicated clarification module and explicitly notes that ambiguous questions remain difficult (Fotso, 2024). AmbiSQL’s distinctive implementation choice is therefore not a new execution engine, but an explicit ambiguity-handling front end that can sit in front of an existing parser (Ding et al., 21 Aug 2025).

6. Limitations, interpretation, and significance

AmbiSQL is best understood as a prompted, modular interactive system rather than a mathematically elaborate optimization method (Ding et al., 21 Aug 2025). The paper provides formal definitions for the Text-to-SQL mapping, the ambiguity type set, the ambiguous phrase set, the detection goal, and the resolution goal, but it does not provide explicit equations for ambiguity scoring, clarification ranking, selection probabilities, training objectives, the query rewriting objective, or evaluation metric formulas (Ding et al., 21 Aug 2025). This limits its role as a formal semantic parsing theory.

Several limitations are explicit or implicit in the paper. Ambiguity detection is prompt-based and depends on the capabilities of the underlying model. The evaluation uses a constructed set of 40 ambiguous queries, which is useful but limited in scale. The method improves correctness by involving the user, but this adds interaction steps. The paper provides no formal guarantees or optimization framework, and additional constraints can themselves be ambiguous (Ding et al., 21 Aug 2025). The usability evidence is primarily the demo interface, qualitative examples, and the observed SQL improvements; it does not report a formal human-subject user study, task completion time, or SUS-style usability metric (Ding et al., 21 Aug 2025).

At the same time, AmbiSQL clarifies an important distinction in the literature: ambiguity handling is not reducible to better decoding alone. AmbiQT showed that top-$\mathsf{q}$8 decoders often fail to cover all valid SQL interpretations because they diversify tokens rather than SQL logic (Bhaskar et al., 2023). ODIN approaches schema ambiguity by generating a set of potential SQL queries and dynamically adjusting the number of suggestions (Vaidya et al., 25 May 2025). SOMA-SQL treats ambiguity as latent intent and resolves it through execution-grounded evidence (Somayajula et al., 9 Jun 2026). AmbiSQL’s position within this space is to preserve a human clarification loop, using a taxonomy that covers both database-mapping ambiguity and LLM-reasoning ambiguity, and to operationalize that loop through multiple-choice questioning and query rewriting (Ding et al., 21 Aug 2025).

Its broader significance lies in making ambiguity a first-class object in interactive Text-to-SQL. Rather than assuming that a single SQL program should be inferred from a single ambiguous utterance, it treats the resolution process itself as part of the system. That orientation aligns with the growing benchmark evidence that practical NL2SQL systems must handle not only clean semantic parsing, but also ambiguity, unanswerability, partial clarification, and schema-level uncertainty (Sarwar et al., 24 Apr 2026).