SOMA-SQL: Resolving Multi-Source Ambiguity in NL-to-SQL via Synthetic Log and Execution Probing

# Soma-SQL: Resolving Multi-Source Ambiguity in NL-to-SQL via Synthetic Log and Execution Probing
Source: [https://arxiv.org/html/2606.11424](https://arxiv.org/html/2606.11424)
Sai Ashish Somayajula\*,Marianne Menglin Liu\*,Chuan Lei,Fjona Parllaku,Daniel Garcia,Rongguang Wang,Syed Fahad Allam Shah,Ankan Bansal,Sujeeth Bharadwaj,Tao Sheng,Sujith Ravi,Dan RothOracle AI\{ashish\.somayajula, marianne\.liu, dan\.roth\}@oracle\.com

###### Abstract

Natural language interfaces to databases aim to translate user questions into executable SQL, yet remain brittle in real\-world settings where questions are underspecified and schemas are large and ambiguous\. Ambiguity across user questions, database schemas, and model interpretations are central failure modes in NL2SQL, leading to misaligned intent, incorrect schema grounding, and erroneous SQL generation\. Existing approaches rely on human clarification or treat ambiguity as a schema representation problem, but these do not scale nor resolve ambiguity autonomously\. We proposeSoma\-SQLto automatically resolve ambiguity via targeted synthetic query log and ambiguity\-driven probing\.Soma\-SQLconstructs synthetic query log to ground schema interpretation and guide candidate SQL generation; it then executes targeted probing queries, driven by a structured ambiguity taxonomy and candidate disagreements, to produce disambiguation evidence for final SQL selection and repair\. This active approach to ambiguity discovery and resolution generalizes across unseen schemas and query distributions without human\-in\-the\-loop\. Experiments on six public benchmarks demonstrate thatSoma\-SQLimproves execution accuracy by 13\.0% on average over state\-of\-the\-art baselines, with gains of up to 16\.7% on ambiguous questions\.

∗Equal contribution\.

## 1Introduction

Translating natural language \(NL\) questions into SQL queries \(NL2SQL\) is a long\-standing problem at the intersection of semantic parsing, pragmatics, and database systems\. Despite recent advances in large language models \(LLMs\), NL2SQL systems\[[33](https://arxiv.org/html/2606.11424#bib.bib33),[27](https://arxiv.org/html/2606.11424#bib.bib27),[4](https://arxiv.org/html/2606.11424#bib.bib4),[38](https://arxiv.org/html/2606.11424#bib.bib38)\]remain brittle under the ambiguity and scale of enterprise deployments\. Real\-world databases are large, complex, and often poorly documented, with schemas spanning hundreds of tables and ambiguous naming conventions\[[13](https://arxiv.org/html/2606.11424#bib.bib13),[6](https://arxiv.org/html/2606.11424#bib.bib6),[18](https://arxiv.org/html/2606.11424#bib.bib18)\]\. User questions are frequently underspecified\[[31](https://arxiv.org/html/2606.11424#bib.bib31),[35](https://arxiv.org/html/2606.11424#bib.bib35),[5](https://arxiv.org/html/2606.11424#bib.bib5)\], omitting aggregation metrics, filters, or join conditions, while implicitly assuming the system shares their domain knowledge and business logic\. As a result, while modern NL2SQL agents\[[38](https://arxiv.org/html/2606.11424#bib.bib38),[32](https://arxiv.org/html/2606.11424#bib.bib32)\]perform well in idealized settings with clean schemas and well\-specified queries, they continue to struggle against realistic enterprise databases with large, complex schemas and abstract, business\-driven questions\.

Motivating example\.Consider a sales analyst querying an enterprise database: “What were the top\-performing regions in New York last quarter?” The phrasetop\-performingcould refer to total revenue, growth rate, or number of closed deals, each requiring a fundamentally different aggregation\.Last quartermay refer to the calendar quarter, fiscal quarter, or a rolling 90\-day window\. Evenregionsis underspecified when the database contains multiple possible geographic or business groupings, such as sales territories, geographic regions, or market segments\.New Yorkmay refer to different entities \(e\.g\.,New York Cityvs\.New York State\) and may also appear in different surface forms \(e\.g\.,NYorNYC\)\. A system must silently commit to certain assumptions for each ambiguity, producing SQL queries that are syntactically valid yet return results that do not match the analyst’s intent, a failure that may not surface until downstream decisions have already been made\.

![Refer to caption](https://arxiv.org/html/2606.11424v1/x1.png)Figure 1:An overview ofSoma\-SQLconsisting of \(a\) Synthetic Query Log Construction for Disambiguation, \(b\) Ambiguity\-aware SQL Probing and Correction, and \(c\) Multi\-SQL Generation\.Challenges\.These limitations manifest as three ambiguity\-driven failure modes\. First,query\-level ambiguityarises when user intent is underspecified\. The desired aggregation, filter condition, or temporal granularity is left implicit, forcing the system to guess among equally valid interpretations\. Second,schema\-level ambiguityoccurs when overlapping or poorly named schema elements obscure which table, column, or value a query phrase refers to\. For instance, “revenue” may map to multiple columns with different semantics in the database\. Third,contextual ambiguityemerges when questions presuppose domain knowledge or business logic absent from both the question and the schema, such as metric definitions, organizational hierarchies, or implicit filtering conventions, leaving the model without sufficient grounding to reason correctly\.

State\-of\-the\-art approaches\.While some recent works explicitly target ambiguity in NL2SQL, each addresses only a narrow facet of the problem\. One line of work resolves ambiguity through human\-in\-the\-loop clarification\[[31](https://arxiv.org/html/2606.11424#bib.bib31),[35](https://arxiv.org/html/2606.11424#bib.bib35),[5](https://arxiv.org/html/2606.11424#bib.bib5)\], prompting users to select among candidate interpretations\. Though effective in controlled settings, these approaches require synchronous user interaction at inference time and fail silently when ambiguities escape detection\. A second line of work\[[36](https://arxiv.org/html/2606.11424#bib.bib36),[20](https://arxiv.org/html/2606.11424#bib.bib20)\]treats ambiguity as a byproduct of poor schema representation, improving grounding through richer schema encoding or retrieval\-augmented context, but cannot distinguish a genuinely underspecified query from one that is merely hard to ground\. A fundamental gap remains: no existing system reasons explicitly about why a query is ambiguous, which type of ambiguity is present, or how to resolve it autonomously, nor do they exploit the semantic divergence across multiple plausible SQL interpretations as a diagnostic signal for unresolved intent\.

Soma\-SQLoverview\.We proposeSoma\-SQL\(Synthetic Query Log and Probing forMulti\-sourceAmbiguity Resolution\), a generalizable NL2SQL system that resolves ambiguity without human\-in\-the\-loop \(shown in Fig\.[1](https://arxiv.org/html/2606.11424#S1.F1)\)\. Given an NL question,Soma\-SQLfirst exploits query log generated synthetically to enrich schema understanding with ambiguity\-aware supervision\. After agentic schema linking\[[38](https://arxiv.org/html/2606.11424#bib.bib38)\], a multi\-SQL generation workflow produces diagnostic SQL candidates; an ambiguity\-aware SQL selector identifies a seed SQL for refinement, while cross\-candidate disagreements expose the unresolved semantic ambiguities\.Soma\-SQLthen maps these conflicts, guided by a predefined ambiguity taxonomy, into structured ambiguity dimensions, and probes the database with targeted SQL queries to gather evidence for each\. The resulting probing report resolves the ambiguity dimensions and repairs the seed SQL to produce the final SQL with data\-grounded evidence\.

Contributions\.Our contributions can be summarized as follows: \(1\) we presentSoma\-SQL, a generalizable NL2SQL system that tackles multi\-source ambiguity through iterative disambiguation and execution\-grounded reasoning, producing semantically correct SQL without human\-in\-the\-loop; \(2\)Soma\-SQLleverages synthetic query log constructed from SQL queries without corresponding NL questions, as is typical in enterprise settings, as a unified mechanism for ambiguity grounding, transforming SQL variations into structured signals for schema enrichment, semantic interpretation, and probing guidance; \(3\) we develop an execution\-grounded probing framework in which candidate SQL disagreements and a structured ambiguity taxonomy jointly guide targeted probe generation, producing concrete resolution evidence for SQL refinement; and \(4\) experimental results on six public benchmarks show thatSoma\-SQLimproves execution accuracy by 13\.0% on average over state\-of\-the\-art baselines, with gains of up to 16\.7% on ambiguous questions\.

## 2Related Works

NL2SQL systems\.LLMs have dramatically advanced NL2SQL, with methods such as DIN\-SQL\[[26](https://arxiv.org/html/2606.11424#bib.bib26)\], DAIL\-SQL\[[7](https://arxiv.org/html/2606.11424#bib.bib7)\], and MAC\-SQL\[[37](https://arxiv.org/html/2606.11424#bib.bib37)\]demonstrating that decomposed prompting and multi\-agent collaboration yield strong results on benchmarks like Spider\[[40](https://arxiv.org/html/2606.11424#bib.bib40)\]and BIRD\[[15](https://arxiv.org/html/2606.11424#bib.bib15)\]\. More recent agentic frameworks further improve schema linking and error correction\. ReFoRCE\[[4](https://arxiv.org/html/2606.11424#bib.bib4)\]combines schema compression with execution\-guided exploration; AutoLink\[[38](https://arxiv.org/html/2606.11424#bib.bib38)\]performs iterative schema linking without requiring the full schema upfront; PV\-SQL\[[34](https://arxiv.org/html/2606.11424#bib.bib34)\]alternates between probing queries and rule\-based verification for iterative refinement; and SQLens\[[8](https://arxiv.org/html/2606.11424#bib.bib8)\]uses AST\-level comparisons to localize semantic errors beyond LLM self\-reflection\. DeepEye\-SQL\[[14](https://arxiv.org/html/2606.11424#bib.bib14)\]decomposes NL2SQL into schema linking, reasoning, implementation, debugging, and final selection\. EnrichIndex\[[3](https://arxiv.org/html/2606.11424#bib.bib3)\]leverages LLMs offline to construct semantically enriched indices, highlighting the effectiveness of structured signals for downstream tasks\. In contrast, BIRD\-INTERACT\[[11](https://arxiv.org/html/2606.11424#bib.bib11)\]exposes the limitations of current systems in multi\-turn, interactive settings\. These works, however, largely assume well\-formed input and offer no principled mechanism for handling query ambiguity\.

Ambiguity in NL2SQL\.AMBROSIA\[[31](https://arxiv.org/html/2606.11424#bib.bib31)\]benchmarks three types of ambiguity in NL questions \(i\.e\., scope, attachment, and vagueness\) showing that even frontier LLMs fail to resolve them reliably\. Wang et al\.\[[36](https://arxiv.org/html/2606.11424#bib.bib36)\]detect and explain ambiguous or unanswerable queries via a Detecting\-Then\-Explaining framework trained on counterfactually generated data\. ODIN\[[35](https://arxiv.org/html/2606.11424#bib.bib35)\], AtomSQL\[[20](https://arxiv.org/html/2606.11424#bib.bib20)\], and AmbiSQL\[[5](https://arxiv.org/html/2606.11424#bib.bib5)\]address schema and query ambiguity through candidate generation, user feedback, or clarification questions\. Our approach differs by learning ambiguity patterns from execution feedback and by automatically resolving ambiguities without human intervention\. We discuss the broader literature on ambiguity resolution in NL beyond NL2SQL in Appendix[A](https://arxiv.org/html/2606.11424#A1)\.

## 3Methodology

### 3\.1Problem Formulation

LetSSdenote a database schema,DDa database instance, andxxa natural language question\. An NL2SQL system generates an executable SQL query111SQL is a family of dialects, including SQLite, BigQuery SQL, Snowflake SQL, and Oracle SQL; and our solution is applicable to all of them\. We refer to an NL question as a “question” and its corresponding SQL as a “query”\.q∈𝒬​\(S\)q\\in\\mathcal\{Q\}\(S\), where𝒬​\(S\)\\mathcal\{Q\}\(S\)denotes the set of valid SQL queries overSS\. Since different SQL queries can produce the same result when executed, we treat the target SQL as one representative among all queries with equivalent execution semantics\. In practice, enterprise queries are often underspecified: users may omit the intended metric, filter, time window, aggregation level, join path, or business convention\. For example, “top\-performing regions in New York last quarter” may depend on the ranking metric \(e\.g\., revenue, growth, or deal count\), the definition of last quarter \(e\.g\., calendar or fiscal\), and the interpretation of schema\-specific entities such as regions and locations\. We model the missing semantics as an underspecified intent variableZZwith finite support𝒵​\(x,S\)\\mathcal\{Z\}\(x,S\), the set of plausible user interpretations ofxxunder schemaSS\. A realizationz∈𝒵​\(x,S\)z\\in\\mathcal\{Z\}\(x,S\)denotes one concrete intent assignment\. Conditioned onzz, an NL2SQL system induces a distribution over executable SQL queries:Pθ​\(q∣x,S,z\),q∈𝒬​\(S\),P\_\{\\theta\}\(q\\mid x,S,z\),q\\in\\mathcal\{Q\}\(S\),whereθ\\thetadenotes the pipeline configuration of the NL2SQL system\[[27](https://arxiv.org/html/2606.11424#bib.bib27),[33](https://arxiv.org/html/2606.11424#bib.bib33)\]\. The core challenge is that the user’s true intentz⋆z^\{\\star\}is unobserved, making it impossible to directly condition onz⋆z^\{\\star\}during generation\.

###### Problem definition\.

Given a natural language questionxx, a database schemaSS, and a database instanceDD, the task is to produce an executable SQL queryq^∈𝒬​\(S\)\\hat\{q\}\\in\\mathcal\{Q\}\(S\)whose execution semantics match those of the gold SQL queryq⋆q^\{\\star\}\. Since the user’s true intentz⋆∈𝒵​\(x,S\)z^\{\\star\}\\in\\mathcal\{Z\}\(x,S\)is unobserved, this requires \(i\) identifying the finite set of plausible intent assignments𝒵​\(x,S\)\\mathcal\{Z\}\(x,S\), \(ii\) estimatingz^∈𝒵​\(x,S\)\\hat\{z\}\\in\\mathcal\{Z\}\(x,S\)from execution\-grounded evidence, and \(iii\) generating the final SQL asq^∈arg⁡maxq∈𝒬​\(S\),Pθ​\(q∣x,S,z^\)\\hat\{q\}\\in\\arg\\max\_\{q\\in\\mathcal\{Q\}\(S\)\},P\_\{\\theta\}\(q\\mid x,S,\\hat\{z\}\)\.

Ambiguity dimensions\.We decompose the underspecified intent variable into*ambiguity dimensions*Z=\(Z1,…,Zm\),Z=\(Z\_\{1\},\\ldots,Z\_\{m\}\),where eachZjZ\_\{j\}captures one unresolved semantic decision, such as the ranking metric, time convention, filter, aggregation, or join path\. A realized intent assignmentz=\(z1,…,zm\),z=\(z\_\{1\},\\ldots,z\_\{m\}\),selects a concrete valuezjz\_\{j\}for each dimensionZjZ\_\{j\}\. The dimensions need not be independent; valid joint assignments may form only a subset of the Cartesian product of the dimension option sets\. For example, in “top\-performing regions in New York last quarter,”Z1Z\_\{1\}\(ranking metric\),Z2Z\_\{2\}\(time convention\), andZ3Z\_\{3\}\(entity reference\) each admit multiple options, resolving them asz1=revenuez\_\{1\}=\\text\{\{revenue\}\},z2=fiscal quarterz\_\{2\}=\\text\{\{fiscal quarter\}\}, andz3=New York Statez\_\{3\}=\\text\{\{New York State\}\}yields a fully specified intent from which the target SQL is deterministically derived\.

### 3\.2Multi\-SQL Generation Workflow

Soma\-SQLis an ambiguity\-first NL2SQL framework built around a widely adopted plan\-generate\-critique workflow, as illustrated in Fig\.[1](https://arxiv.org/html/2606.11424#S1.F1)\. Before invoking the workflow,Soma\-SQLenriches the database schema\[[17](https://arxiv.org/html/2606.11424#bib.bib17),[3](https://arxiv.org/html/2606.11424#bib.bib3)\]and performs agentic schema linking\[[38](https://arxiv.org/html/2606.11424#bib.bib38)\]to identify the relevant subset ofSSfor each questionxx222For ease of notation, we refer to this subset asSSthroughout\.\. This step avoids prompt context overflow \(see Appendix[G](https://arxiv.org/html/2606.11424#A7)for details\)\. Prior to intent resolution, the workflow induces a distributionPθ​\(q∣x,S\),P\_\{\\theta\}\(q\\mid x,S\),reflecting uncertainty over the underspecified intent\. Running the workflowKKtimes produces candidatesqk∼Pθ​\(q∣x,S\)​for​k=1,…,K,q\_\{k\}\\sim P\_\{\\theta\}\(q\\mid x,S\)\\text\{ for \}k=1,\\ldots,K,defining the diagnostic candidate set

𝒬K​\(x,S\)=\{q1,…,qK\}⊂𝒬​\(S\)\.\\mathcal\{Q\}\_\{K\}\(x,S\)=\\\{q\_\{1\},\\ldots,q\_\{K\}\\\}\\subset\\mathcal\{Q\}\(S\)\.These candidates serve as diagnostic samples rather than final answers: disagreements in their choice of metric, filter, join path, or temporal constraint expose the unresolved ambiguity dimensions defined in Sec\.[3\.1](https://arxiv.org/html/2606.11424#S3.SS1)\. In each run, the planner produces a structured planπk=Plan​\(x,S\)\\pi\_\{k\}=\\mathrm\{Plan\}\(x,S\)specifying relevant tables, joins, filters, aggregations, grouping keys, ordering logic, and temporal constraints\. The dialect\-aware generator then translates the plan into an initial SQL query:qk=Gen​\(x,S,πk\)\.q\_\{k\}=\\mathrm\{Gen\}\(x,S,\\pi\_\{k\}\)\.

The critique module refinesqkq\_\{k\}using schema validation, abstract syntax tree \(AST\) parsing\[[19](https://arxiv.org/html/2606.11424#bib.bib19)\], SQL planning diagnostics, and lightweight execution diagnostics:qk=Critique​\(x,S,D,πk,qk\)\.q\_\{k\}=\\mathrm\{Critique\}\(x,S,D,\\pi\_\{k\},q\_\{k\}\)\.FollowingGong et al\. \[[8](https://arxiv.org/html/2606.11424#bib.bib8)\]for parsing\-based and execution diagnostics, we retain only the checks that provided the largest gains and generalized across datasets: invalid join predicates unsupported by the schema, suboptimal join trees containing unnecessary tables, incorrectGROUP BYstructure, and abnormal execution outputs \(e\.g\., all\-zero results orNaNs\)\. We encode these high\-impact diagnostics directly into the critique prompt\. Repeating this loop fork=1,…,Kk=1,\\ldots,Kyields𝒬K​\(x,S\)\\mathcal\{Q\}\_\{K\}\(x,S\)\. We optimize the planner’s system prompt to mitigate common failure modes; prompts for each stage are in Appendices[G\.1](https://arxiv.org/html/2606.11424#A7.SS1),[G\.2](https://arxiv.org/html/2606.11424#A7.SS2),[G\.3](https://arxiv.org/html/2606.11424#A7.SS3), and[G\.4](https://arxiv.org/html/2606.11424#A7.SS4)\.

Soma\-SQLresolves the unresolved ambiguity dimensions in𝒬K​\(x,S\)\\mathcal\{Q\}\_\{K\}\(x,S\)using two complementary sources of evidence, namely synthetic query log \(Sec\.[3\.3](https://arxiv.org/html/2606.11424#S3.SS3)\) and execution\-grounded probing \(Sec\.[3\.4](https://arxiv.org/html/2606.11424#S3.SS4)\), to produce an evidence\-supported intent estimatez^\\hat\{z\}, conditioned on which the final SQL is generated\.

### 3\.3Ambiguity Supervision from Synthetic Query Log

#### Ambiguity resolution set construction\.

A SQL query log contains validated SQL queries executed over a schema, without associated NL questions\. Such logs are common in enterprise databases; when available,Soma\-SQLleverages them to construct reusable supervision for recurring ambiguities and failure patterns\. Algorithm[1](https://arxiv.org/html/2606.11424#alg1)summarizes the synthetic ambiguity supervision pipeline\.

Intent anchors\.Each logged SQL queryqilogq\_\{i\}^\{\\log\}serves as an*intent anchor*, representing a historically resolved user need\. For each anchor,Soma\-SQLprompts an LLM to generate a fully specified NL description, and then derives several underspecified variantsxi\(j\)x\_\{i\}^\{\(j\)\}by removing details along common ambiguity dimensions\[[5](https://arxiv.org/html/2606.11424#bib.bib5)\]\. The detailed prompts are in Appendices[G\.7](https://arxiv.org/html/2606.11424#A7.SS7)and[G\.8](https://arxiv.org/html/2606.11424#A7.SS8)\.

Candidate disagreement\.For eachxi\(j\)x\_\{i\}^\{\(j\)\},Soma\-SQLruns the multi\-SQL generation workflow to produceKKcandidate SQL queries,𝒬K​\(xi\(j\),S\)⊂𝒬​\(S\)\\mathcal\{Q\}\_\{K\}\(x\_\{i\}^\{\(j\)\},S\)\\subset\\mathcal\{Q\}\(S\)\. Becausexi\(j\)x\_\{i\}^\{\(j\)\}is intentionally underspecified, these candidates often reflect distinct plausible interpretations\.Soma\-SQLpresents allKKcandidates to an LLM and prompts it to identify implementation\-level differences across the full SQL structure\. The resulting differences are consolidated into a set of discrepanciesΔi\(j\)\\Delta\_\{i\}^\{\(j\)\}, with each unique discrepancy recorded once\. For example, two candidate filters,city = ‘NYC’andcity = ‘New York’, are consolidated into a predicate\-value discrepancy set as a single entry inΔi\(j\)\\Delta\_\{i\}^\{\(j\)\}\.

Ambiguity supervision\.Soma\-SQLconvertsΔi\(j\)\\Delta\_\{i\}^\{\(j\)\}into structured ambiguity records, each a triple\(Zj,𝒪,ℰ\)\(Z\_\{j\},\\mathcal\{O\},\\mathcal\{E\}\), whereZjZ\_\{j\}is an ambiguity dimension,𝒪\\mathcal\{O\}is the set of plausible semantic options, andℰ⊆Δi\(j\)\\mathcal\{E\}\\subseteq\\Delta\_\{i\}^\{\(j\)\}is the set of implementation\-level SQL differences that induce the distinction\. For example, if candidates disagree betweencity = ‘New York City’andstate = ‘New York’, this induces an entity\-reference ambiguity dimension with options \{New York City, New York State\} and evidence drawn from the observed predicate differences\.

More generally, each option represents a distinct resolution ofZZ, such as a choice of aggregation, filter condition, grouping level, or join path\. The option set𝒪\\mathcal\{O\}is induced from candidate disagreement, capturing both correct and plausible\-but\-incorrect interpretations\. The anchorqilogq\_\{i\}^\{\\log\}identifies the historically supported optiono∈𝒪o\\in\\mathcal\{O\}; if absent,Soma\-SQLadds a grounded option derived fromqilogq\_\{i\}^\{\\log\}\. This converts unlabeled candidate disagreement into labeled ambiguity supervision\. Each supervision item is stored asc=\(xi\(j\),S,Z,𝒪,o,ℰ\),c=\(x\_\{i\}^\{\(j\)\},S,Z,\\mathcal\{O\},o,\\mathcal\{E\}\),which isolates a semantic decision, enumerates competing resolutions, and links them to concrete SQL differences\.

Ambiguity resolution set\.Aggregating all MCQ\-style records across anchors and their variants yields theambiguity resolution set𝒞\\mathcal\{C\}\. It provides dimension\-level supervision, namely identifying which semantic decisions are typically underspecified, which alternatives are plausible, which resolution is historically supported, and what SQL evidence distinguishes the alternatives\.

Example\.Starting from an intent anchorqilogq\_\{i\}^\{\\log\},Soma\-SQLgenerates a detailed NL question, “List the top\-5 regions by total revenue in the most recent fiscal quarter,” and removes key details to obtain the underspecified questionxi\(j\)x\_\{i\}^\{\(j\)\}: “top\-5 performing regions last quarter\.” The multi\-SQL generation workflow then producesKKcandidates that resolve the missing details differently: candidates may rank regions bySUM\(revenue\),SUM\(profit\), orCOUNT\(deals\), and may interpret “last quarter” as calendar rather than fiscal\. From the resulting discrepanciesΔi\(j\)\\Delta\_\{i\}^\{\(j\)\},Soma\-SQLextracts two ambiguity dimensions:Z1=Z\_\{1\}=“ranking metric,” with𝒪1=\{revenue,profit,deal count\}\\mathcal\{O\}\_\{1\}=\\\{\\text\{revenue\},\\text\{profit\},\\text\{deal count\}\\\}, andZ2=Z\_\{2\}=“time convention,” with𝒪2=\{calendar quarter,fiscal quarter\}\\mathcal\{O\}\_\{2\}=\\\{\\text\{calendar quarter\},\\text\{fiscal quarter\}\\\}\. The intent anchorqilogq\_\{i\}^\{\\log\}selectso1=revenueo\_\{1\}=\\text\{revenue\}ando2=fiscal quartero\_\{2\}=\\text\{fiscal quarter\}, yielding two labeled MCQ items added to𝒞\\mathcal\{C\}\.

#### Applying the ambiguity resolution set at inference time\.

When𝒞\\mathcal\{C\}is available,Soma\-SQLfirst retrievesm′m^\{\\prime\}MCQ records most similar to the user questionxxand schemaSS, and then uses a reranker \(see Appendix[G\.9](https://arxiv.org/html/2606.11424#A7.SS9)\) to select the most relevantmmexamples:

𝒞x=Rerankm​\(x,S,Retrievem′​\(x,S,𝒞\)\),m<m′\.\\mathcal\{C\}\_\{x\}=\\mathrm\{Rerank\}\_\{m\}\\\!\\left\(x,S,\\mathrm\{Retrieve\}\_\{m^\{\\prime\}\}\(x,S,\\mathcal\{C\}\)\\right\),m<m^\{\\prime\}\.The retrieved MCQs are provided as in\-context examples to the planning, SQL generation, and critique prompts\. They expose likely ambiguity dimensions, indicate historically supported resolutions, and flag wrong implementations that the model has previously found plausible\. If historical log is unavailable, this step is omitted and𝒞x=∅\\mathcal\{C\}\_\{x\}=\\varnothing\.

### 3\.4Ambiguity Discovery, Probing, and Final Generation

At inference time,Soma\-SQLcombines ambiguity\-set evidence with database probing to resolve ambiguities\. Given a questionxx, schemaSS, and retrieved records𝒞x\\mathcal\{C\}\_\{x\}if available, the workflow described in Sec\.[3\.2](https://arxiv.org/html/2606.11424#S3.SS2)samplesKKdiagnostic candidates,𝒬K​\(x,S\)\\mathcal\{Q\}\_\{K\}\(x,S\)\. Algorithm[2](https://arxiv.org/html/2606.11424#alg2)summarizes the full ambiguity probing and repair procedure\.Soma\-SQLfirst selects a seed SQL,

q\(0\)=Select​\(x,S,𝒬K​\(x,S\)\),q^\{\(0\)\}=\\mathrm\{Select\}\(x,S,\\mathcal\{Q\}\_\{K\}\(x,S\)\),using an LLM judge \(Appendix[G\.10](https://arxiv.org/html/2606.11424#A7.SS10)\) to takexx,SS, and allKKsampled SQLs as input and selects the one SQL closest to the intent ofxx\. The seed is not assumed to be correct; it is the single candidate subsequently repaired\.Soma\-SQLidentifies ambiguity dimensions to probe from two complementary signals\. First, comparing SQL structures within𝒬K​\(x,S\)\\mathcal\{Q\}\_\{K\}\(x,S\)yieldsmcm\_\{c\}candidate\-induced ambiguity dimensions\{\(Ztcand,ℰtcand\)\}t=1mc,\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\},whereℰtcand\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}contains the implementation\-level differences, such as alternative aggregations, filters, grouping keys, or join paths, that surface thett\-th ambiguity dimensionZtcandZ\_\{t\}^\{\\mathrm\{cand\}\}\. Because candidate differences alone can miss plausible interpretations or conflate distinct semantic choices into similar implementations,Soma\-SQLadditionally prompts an LLM with\(x,S\)\(x,S\)and a database\-sourced ambiguity taxonomy\[[5](https://arxiv.org/html/2606.11424#bib.bib5)\]to obtainmtm\_\{t\}taxonomy\-induced dimensions\{Zjtax\}j=1mt,\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\},whereZjtaxZ\_\{j\}^\{\\mathrm\{tax\}\}is thejj\-th taxonomy\-induced ambiguity dimension\. The union of both sets defines the probing targets\.

#### Probing unresolved dimensions\.

Identifying an ambiguity dimension reveals what is underspecified, but not its intended resolution\. For each dimension,Soma\-SQLgenerates targeted probe SQLs and executes them on the database instanceDD\. Probe SQLs are executable queries designed to gather evidence for a specific ambiguity dimension rather than answer the user query directly\. Candidate\-induced probes are guided byℰtcand\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}and schema context, while taxonomy\-induced probes instantiate plausible alternatives from schema elements and database values\.

Consider the query*“show me churn for enterprise customers last quarter\.”*A discovered ambiguity dimension concerns the definition of*churn*: it may refer to canceled subscriptions, inactive accounts, lost revenue, or customers with no recent purchases\.Soma\-SQLconstructs probe SQLs for each interpretation and executes them against the database\. If the canceled\-subscription interpretation yields substantially stronger and more temporally consistent evidence than the alternatives, the probe results favor that interpretation\. A full prompt\-and\-report example is provided in Appendix[M](https://arxiv.org/html/2606.11424#A13)\.

#### Grounding report and resolution\.

The probe outputs are compiled into a grounding report

R=Probe​\(x,S,D,\{\(Ztcand,ℰtcand\)\}t=1mc,\{Zjtax\}j=1mt\)\.R=\\mathrm\{Probe\}\\\!\\left\(x,S,D,\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\},\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\}\\right\)\.RRrecords, for each ambiguity dimension, the execution results and database\-grounded evidence for each candidate alternative\. For candidate\-induced dimensions, the alternatives are drawn fromℰtcand\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}; for taxonomy\-induced dimensions, they are first instantiated from schema elements and database values before probing\.Soma\-SQLthen resolves the discovered dimensions with an LLM\-based resolver:

z^=Resolve​\(x,S,𝒞x,\{\(Ztcand,ℰtcand\)\}t=1mc,\{Zjtax\}j=1mt,R\),\\hat\{z\}=\\mathrm\{Resolve\}\\\!\\left\(x,S,\\mathcal\{C\}\_\{x\},\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\},\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\},R\\right\),producing an evidence\-supported intent estimatez^∈𝒵​\(x,S\)\\hat\{z\}\\in\\mathcal\{Z\}\(x,S\)\. It denotes the resolved interpretations of the candidate\-induced and taxonomy\-induced ambiguity dimensions, based on the accumulated evidence inRR\. Ambiguity resolution prompt is in[G\.6](https://arxiv.org/html/2606.11424#A7.SS6)\.

#### Final generation\.

Givenz^\\hat\{z\}, the seed SQLq\(0\)q^\{\(0\)\}, and the grounding reportRR,Soma\-SQLgenerates the final SQL by sampling from the intent\-conditioned distributionq^∼Pθ​\(q∣x,S,z^,q\(0\),R\)\.\\hat\{q\}\\sim P\_\{\\theta\}\\bigl\(q\\mid x,S,\\hat\{z\},q^\{\(0\)\},R\\bigr\)\.Diagnostic candidates are used to expose ambiguity, probe SQLs provide database\-grounded evidence inRR, and the resolver produces the clarified intentz^\\hat\{z\}\. The final SQL is generated by repairing the seed query under this evidence\-supported interpretation\.

### 3\.5Automated Disambiguation as Human Clarification Proxy

Givenxx,SS, and𝒞x\\mathcal\{C\}\_\{x\}if available,Soma\-SQLgenerates diagnostic candidates𝒬K​\(x,S\)\\mathcal\{Q\}\_\{K\}\(x,S\), detects ambiguity dimensions from candidate differences and taxonomy\-guided signals, and probes the database to collect resolution evidence\. In an ideal human\-in\-the\-loop setting, detected ambiguities would be presented to the user as an MCQ, and the response would directly reveal the intended interpretation\. We formalize this ideal setting using three random variables:ZZdenotes the latent user intent, as defined above;UUdenotes the ideal human clarification signal induced by the MCQ interaction; andYYdenotes the automated evidence constructed bySoma\-SQL:

Y≜\(𝒬K​\(x,S\),𝒞x,\{\(Ztcand,ℰtcand\)\}t=1mc,\{Zjtax\}j=1mt,R\),Y\\triangleq\\Bigl\(\\mathcal\{Q\}\_\{K\}\(x,S\),\\;\\mathcal\{C\}\_\{x\},\\;\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\},\\;\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\},\\;R\\Bigr\),whereYYhistorical log based resolution, aggregates candidate SQLs, retrieved ambiguity records, detected ambiguity dimensions, and probe\-execution results\.

###### Proposition 1\(Automated proxy for clarification\)\.

For\(x,S\)\(x,S\), suppose the automated proxyYYis a noisy approximation of the ideal human clarification signalUUin the sense that, after conditioning onUUand\(x,S\)\(x,S\), observingYYprovides no further information aboutZZ\. Then,I​\(Z;Y∣x,S\)≤I​\(Z;U∣x,S\)\.I\(Z;Y\\mid x,S\)\\leq I\(Z;U\\mid x,S\)\.Thus, human clarification is an information\-theoretic ceiling, andSoma\-SQLconstructs a tractable automated proxy below this ceiling\.

The proof is in Appendix[E](https://arxiv.org/html/2606.11424#A5)\. The proposition characterizes whenSoma\-SQLcan approach the human\-in\-the\-loop ceiling\. Real database workloads are repetitive: for a fixed schemaSS, many questions follow recurring intent patterns\. As historical log covers these patterns, retrieved ambiguity records𝒞x\\mathcal\{C\}\_\{x\}recover previously resolved ambiguity decisions, narrowing the gap betweenI​\(Z;Y∣x,S\)I\(Z;Y\\mid x,S\)andI​\(Z;U∣x,S\)I\(Z;U\\mid x,S\)\. The remaining gap is concentrated on rare or novel intents where the log lacks precedent\.

## 4Experiments

### 4\.1Experimental Setup

Datasets\.We evaluateSoma\-SQLon six NL2SQL benchmarks: Spider 2\.0 Lite\[[13](https://arxiv.org/html/2606.11424#bib.bib13)\], BIRD\-dev\[[15](https://arxiv.org/html/2606.11424#bib.bib15)\], Archer\-dev \(English and Chinese\)\[[41](https://arxiv.org/html/2606.11424#bib.bib41)\], BEAVER \(Oracle dialect\)\[[2](https://arxiv.org/html/2606.11424#bib.bib2),[25](https://arxiv.org/html/2606.11424#bib.bib25)\], and AMBROSIA\[[31](https://arxiv.org/html/2606.11424#bib.bib31)\]\. Details can be found in Appendix[F](https://arxiv.org/html/2606.11424#A6)\.

Evaluation metrics\.Following prior work\[[4](https://arxiv.org/html/2606.11424#bib.bib4),[14](https://arxiv.org/html/2606.11424#bib.bib14),[38](https://arxiv.org/html/2606.11424#bib.bib38)\], we report Execution Accuracy \(EX\) as the primary metric\. A prediction is correct if the predicted SQL program executes successfully and its result matches that of the ground\-truth SQL program under the benchmark’s evaluator\. We use each benchmark’s official evaluator where available; otherwise, we fall back to the evaluation logic provided by Spider 2\.0 Lite\.

Baselines\.We compareSoma\-SQLagainst AutoLink\[[38](https://arxiv.org/html/2606.11424#bib.bib38)\]and DeepEye\-SQL\[[14](https://arxiv.org/html/2606.11424#bib.bib14)\], the leading open\-source methods on the Spider 2\.0 Lite and BIRD leaderboards, respectively\.

#### Models\.

We evaluate all methods using three backbone LLMs: GPT\-5\.3\-Codex\[[24](https://arxiv.org/html/2606.11424#bib.bib24)\], GPT\-5\[[22](https://arxiv.org/html/2606.11424#bib.bib22)\], and Gemma\-4\-31B\[[9](https://arxiv.org/html/2606.11424#bib.bib9)\], representing coding\-oriented, general\-purpose, and open\-source models\.

Implementation settings\.We use GPT\-5\.3\-Codex to generate synthetic query log and sentence\-transformers/all\-MiniLM\-L6\-v2 for retrieval embeddings; we rerank the top1010candidates with GPT\-5\.4\[[23](https://arxiv.org/html/2606.11424#bib.bib23)\]and keep up to33\. For ambiguity\-driven probing, we use codex\-cli \(v0\.111\.0\) and implement the probing workflow using agent skills \(see Appendix[G\.6](https://arxiv.org/html/2606.11424#A7.SS6)\)\. For multi\-SQL generation, we sample1010candidate SQLs and allow up to55critique rounds\.

Table 1:Execution accuracy \(EX\) in % across benchmarks without synthetic query log; “Avg\.” is the mean across Spider 2\.0 Lite, BIRD, Archer\-en, Archer\-zh, and BEAVER\. Values highlighted in blue and annotated with gains denote absolute improvements over the second\-best result\.Soma\-SQLconsistently outperforms baselines across datasets, dialects, languages, and backbone models\.

### 4\.2Main Results

#### Comparison with baselines\.

We compareSoma\-SQLwith AutoLink and DeepEye\-SQL across five NL2SQL benchmarks: Spider 2\.0 Lite, BIRD, Archer\-en, Archer\-zh, and BEAVER\. To ensure a fair comparison, we assumeno access to query logas additional disambiguation signals during inference, a setting consistent across all methods\. Table[1](https://arxiv.org/html/2606.11424#S4.T1)summarizes the results across these benchmarks\. First,Soma\-SQLachieves consistent gains across all benchmarks and models, improving over the strongest baseline by 9\.3%, 12\.8%, and 16\.7% on average for GPT\-5\.3 Codex, GPT\-5, and Gemma\-4\-31B, respectively, demonstrating the generalizability of our approach without reliance on any dataset\-specific supervision\. Second, competing baselines fail to generalize across datasets\. AutoLink, submitted to Spider 2\.0 leaderboard, ranks second compared toSoma\-SQLbut is outperformed by DeepEye\-SQL on BIRD\. Conversely, DeepEye\-SQL, which is tuned for BIRD, underperforms AutoLink on every other benchmark\. This cross\-dataset inconsistency reveals that prior methods overfit to their target leaderboards, whereasSoma\-SQLmaintains top performance across all five benchmarks\. Third,Soma\-SQLgeneralizes across SQL dialects and languages\. Spider 2\.0 and BEAVER together span Snowflake, BigQuery, SQLite, and Oracle dialects, andSoma\-SQLachieves the largest absolute gains on these benchmarks, indicating robustness to dialect variation\. Furthermore, strong improvements on Archer\-zh confirm cross\-lingual generalization\.

Table 2:Execution accuracy \(EX\) on subsampled AMBROSIA partitions with Gemma\-4\-31B and no synthetic query log\. Gap is the drop from unambiguous to ambiguous EX\.
#### Results on ambiguity\-focused benchmark\.

To directly evaluate ambiguity resolution, we use AMBROSIA, an NL2SQL benchmark where each ambiguous question admits multiple valid interpretations\. We evaluateSoma\-SQLusing Gemma\-4\-31B on a balanced 300\-example split: 150 ambiguous questions and 150 unambiguous questions\. The ambiguous set contains 50 examples from each ambiguity category \(i\.e\., attachment, scope, and vague references\)\[[31](https://arxiv.org/html/2606.11424#bib.bib31)\]\. Table[2](https://arxiv.org/html/2606.11424#S4.T2)shows thatSoma\-SQLachieves 92\.0% EX on ambiguous questions and 94\.7% EX on unambiguous questions, outperforming both DeepEye\-SQL and AutoLink on both partitions\. The ambiguous–unambiguous gap is also smallest forSoma\-SQL: 2\.7%, compared to 11\.4% for AutoLink and 7\.3% for DeepEye\-SQL\. Thus,Soma\-SQLretains most of its accuracy under ambiguous inputs, suggesting its robustness to semantic underspecification\.

Table 3:Effectiveness of synthetic query log\. We report execution accuracy \(EX\)\.

### 4\.3Impact of Synthetic Query Log

We study the effectiveness of targeted synthetic query log on improvingSoma\-SQLbeyond the no\-log setting in Table[1](https://arxiv.org/html/2606.11424#S4.T1)\. We choose Spider 2\.0 Lite, BEAVER, and AMBROSIA to cover diverse SQL dialects, schema complexity, and ambiguous question types\. For each dataset, we use the provided gold SQLs only as intent anchors for generating synthetic query log entries, following Sec\.[3\.3](https://arxiv.org/html/2606.11424#S3.SS3)\. Note, no gold SQL is exposed in the MCQs or added to the NL2SQL generation workflow\. Instead, we derive ambiguity\-focused MCQs, use them to disambiguate the synthetic question, and convert the selected option into an NL clarification stored in the synthetic query log\. Examples are provided in Appendix[H](https://arxiv.org/html/2606.11424#A8)\. Table[3](https://arxiv.org/html/2606.11424#S4.T3)shows that the synthetic query log consistently improve execution accuracy across datasets and backbone models\. On Spider 2\.0 Lite,Soma\-SQLwith query log improves performance by 7\.3% and 2\.7% for Gemma\-4\-31B and GPT\-5\.3 Codex, respectively\. On BEAVER, the gains are larger, with improvements of 10\.1% and 8\.7%, respectively\. On AMBROSIA, query log further improve performance by 2\.7% and 4\.0%\. These results show that targeted synthetic query log provide useful ambiguity grounding beyond schema information\.

Helpfulness of synthetic MCQ clarifications for SQL generation\.Using an LLM\-as\-a\-Judge\[[10](https://arxiv.org/html/2606.11424#bib.bib10)\]described in Appendix[I](https://arxiv.org/html/2606.11424#A9), we evaluate whether each synthetic MCQ clarification provides useful guidance for generating the intended SQL\. Given the original question, the synthetic MCQ clarification, and the gold SQL if available, the judge assigns one of two labels:helpfulif the clarification guides the NL2SQL system toward the intended SQL semantics, andnot\_helpfulif it provides little or no useful guidance for SQL generation\. The judge labels 145/150 AMBROSIA examples \(96\.7%\), 207/209 BEAVER examples \(99\.0%\), and 421/456 Spider 2\.0 Lite examples \(92\.3%\) ashelpful\. These results confirm that the synthetic MCQs generally provide useful guidance for generating the intended SQL\.

Table 4:Effectiveness of ambiguity\-aware SQL selection and probing across datasets\. “Avg\.” is the mean across Spider 2\.0 Lite, BEAVER, and AMBROSIA\.
### 4\.4Impact of Ambiguity\-Driven Probing

Table 5:Accuracy gains from ambiguity\-driven probing on difficult Spider 2\.0 Lite instances\.We evaluate probing on Spider 2\.0, BEAVER, and AMBROSIA, covering diverse SQL dialects and ambiguous question types\. All methods are evaluated in the query\-log setting described in Sec[4\.3](https://arxiv.org/html/2606.11424#S4.SS3)\. We compare our full method, LLM\-as\-a\-Judge \(LLMaaJ\)\-based seed selection with ambiguity\-driven probing, against two baselines: Majority Voting and naive LLMaaJ\. The LLMaaJ prompt is provided in Appendix[G\.10](https://arxiv.org/html/2606.11424#A7.SS10)\. As shown in Table[4](https://arxiv.org/html/2606.11424#S4.T4), our method, on average, improves performance by 9\.0% over Majority Voting \(67\.4 vs\. 58\.4\) and 7\.0% over LLMaaJ \(67\.4 vs\. 60\.4\), demonstrating the effectiveness of ambiguity\-driven probing beyond selection alone\.

#### Probing primarily benefits hard instances\.

To understand the impact of ambiguity\-driven probing, we characterize difficulty on Spider 2\.0\-Lite by runningSoma\-SQLwith Gemma\-4\-31B ten times per instance and recording the number of correct executions\. We label instances with zero correct runs asnever correctand those with one to four correct runs assparsely correct; see Appendix[K](https://arxiv.org/html/2606.11424#A11)for details\. Our analysis focuses on these hard cases, where the system succeeds in at most 4 out of 10 runs\. As shown in Table[5](https://arxiv.org/html/2606.11424#S4.T5), adding probing to LLMaaJ\-based selection yields the largest improvements on the hardest instances\. Fornever correctinstances, probing improves execution accuracy from 0% to 30\.6%, recovering 82 previously unsolved cases\. Forsparsely correctinstances, probing improves execution accuracy from 61\.1% to 81\.5%\. These results suggest that probing is particularly effective for difficult questions that selection alone cannot resolve\.

Quality of ambiguity probing\.We evaluate ambiguity probing quality using LLMaaJ on Spider 2\.0\-Lite outputs generated bySoma\-SQLwith Gemma\-4\-31B\. We measure three binary metrics:Probing Groundedness\(whether probes are justified by the question and grounded in implementation differences or ambiguity taxonomy evidence\),Resolution Correctness\(whether the selected resolution matches user intent\), andSQL Repair Faithfulness\(whether the repaired SQL reflects the chosen resolution without unrelated changes\)\. We audit 50 proportionally sampled instances spanning cases where probing improves, preserves, or fails to change execution outcomes \(e\.g\., wrong→\\rightarrowcorrect and wrong→\\rightarrowwrong\)\. Details are provided in Appendix[L](https://arxiv.org/html/2606.11424#A12)\. On the audited set, ambiguity probing achieves 0\.94 probing groundedness, 0\.90 resolution correctness, and 0\.96 SQL repair faithfulness \(0–1 scale\), indicating that probes are generally well\-grounded and downstream SQL repairs are highly faithful\.

## 5Conclusion

We presentSoma\-SQL, a novel ambiguity\-aware framework for autonomous ambiguity resolution in text\-to\-SQL\.Soma\-SQLleverages synthetic query log, multi\-SQL disagreement signals, and database\-grounded probing to identify and resolve unresolved user intent\. It detects ambiguity through structured reasoning over divergent SQL candidates, maps conflicts into interpretable ambiguity dimensions, and applies evidence\-driven refinement to repair or select the final SQL query\. Experiments on six public benchmarks demonstrate thatSoma\-SQLimproves execution accuracy by 13\.0% on average over state\-of\-the\-art baselines, with gains of up to 16\.7% on ambiguous questions, without requiring human interaction at inference time\.

## 6Limitations

Soma\-SQLrelies on LLM\-based reasoning for ambiguity detection, interpretation, and SQL refinement, and therefore inherits limitations of the underlying models\. In particular, ambiguity resolution depends on the diversity and semantic coverage of generated SQL candidates: when all candidates converge to the same incorrect interpretation, unresolved intent may remain undetected\. Some ambiguity dimensions also require world knowledge or long\-range reasoning beyond current frontier LLM capabilities, leading to incomplete or incorrect resolutions\.

## References

- Aliannejadi et al\. \[2019\]Mohammad Aliannejadi, Hamed Zamani, Fabio Crestani, and W Bruce Croft\.Asking clarifying questions in open\-domain information\-seeking conversations\.In*Proceedings of the 42nd international acm sigir conference on research and development in information retrieval*, pages 475–484, 2019\.
- Chen et al\. \[2024\]Peter Baile Chen, Devin Yang, Weiyue Li, Fabian Wenz, Yi Zhang, Nesime Tatbul, Michael Cafarella, Çağatay Demiralp, and Michael Stonebraker\.Beaver: an enterprise benchmark for text\-to\-sql\.*arXiv preprint arXiv:2409\.02038*, 2024\.
- Chen et al\. \[2025\]Peter Baile Chen, Tomer Wolfson, Michael Cafarella, and Dan Roth\.Enrichindex: Using llms to enrich retrieval indices offline\.*arXiv preprint arXiv:2504\.03598*, 2025\.
- Deng et al\. \[2025\]Minghang Deng, Ashwin Ramachandran, Canwen Xu, Lanxiang Hu, Zhewei Yao, Anupam Datta, and Hao Zhang\.Reforce: A text\-to\-sql agent with self\-refinement, consensus enforcement, and column exploration\.*arXiv preprint arXiv:2502\.00675*, 2025\.
- Ding et al\. \[2026\]Zhongjun Ding, Yin Lin, Tianjing Zeng, Rong Zhu, Bolin Ding, and Jingren Zhou\.Ambisql: Interactive ambiguity detection and resolution for text\-to\-sql\.In*Companion of the International Conference on Management of Data*, pages 26–29, 2026\.
- Floratou et al\. \[2024\]Avrilia Floratou, Fotis Psallidas, Fuheng Zhao, Shaleen Deep, Gunther Hagleither, Wangda Tan, Joyce Cahoon, Rana Alotaibi, Jordan Henkel, Abhik Singla, Alex Van Grootel, Brandon Chow, Kai Deng, Katherine Lin, Marcos Campos, K\. Venkatesh Emani, Vivek Pandit, Victor Shnayder, Wenjing Wang, and Carlo Curino\.NL2SQL is a solved problem… not\!In*Proceedings of the Conference on Innovative Data Systems Research \(CIDR\)*, 2024\.URL[https://www\.cidrdb\.org/cidr2024/papers/p74\-floratou\.pdf](https://www.cidrdb.org/cidr2024/papers/p74-floratou.pdf)\.
- Gao et al\. \[2023\]Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, and Jingren Zhou\.Text\-to\-sql empowered by large language models: A benchmark evaluation\.*arXiv preprint arXiv:2308\.15363*, 2023\.
- Gong et al\. \[2026\]Yue Gong, Chuan Lei, Xiao Qin, Kapil Vaidya, Balakrishnan Narayanaswamy, and Tim Kraska\.Sqlens: An end\-to\-end framework for error detection and correction in text\-to\-sql\.*Advances in Neural Information Processing Systems*, 38:135571–135604, 2026\.
- Google DeepMind \[2026\]Google DeepMind\.Gemma 4\.[https://deepmind\.google/models/gemma/gemma\-4/](https://deepmind.google/models/gemma/gemma-4/), 2026\.Accessed: 2026\-05\-06\.
- Gu et al\. \[2024\]Jiawei Gu, Xuhui Jiang, Zhichao Shi, Hexiang Tan, Xuehao Zhai, Chengjin Xu, Wei Li, Yinghan Shen, Shengjie Ma, Honghao Liu, et al\.A survey on llm\-as\-a\-judge\.*The Innovation*, 2024\.
- Huo et al\. \[2026\]Nan Huo, Xiaohan Xu, Jinyang Li, Per Jacobsson, Shipei Lin, Bowen Qin, Binyuan Hui, Xiaolong Li, Ge Qu, Shuzheng Si, et al\.Bird\-interact: Re\-imagining text\-to\-sql evaluation via lens of dynamic interactions\.In*The Fourteenth International Conference on Learning Representations*, 2026\.
- Keyvan and Huang \[2022\]Kimiya Keyvan and Jimmy Xiangji Huang\.How to approach ambiguous queries in conversational search: A survey of techniques, approaches, tools, and challenges\.*ACM Computing Surveys*, 55\(6\):1–40, 2022\.
- Lei et al\. \[2024\]Fangyu Lei, Jixuan Chen, Yuxiao Ye, Ruisheng Cao, Dongchan Shin, Hongjin Su, Zhaoqing Suo, Hongcheng Gao, Wenjing Hu, Pengcheng Yin, et al\.Spider 2\.0: Evaluating language models on real\-world enterprise text\-to\-sql workflows\.*arXiv preprint arXiv:2411\.07763*, 2024\.
- Li et al\. \[2026\]Boyan Li, Chong Chen, Zhujun Xue, Yinan Mei, and Yuyu Luo\.Deepeye\-sql: A software\-engineering\-inspired text\-to\-sql framework\.*Proceedings of the ACM on Management of Data*, 4\(3 \(SIGMOD\):1–28, 2026\.
- Li et al\. \[2023\]Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, Binhua Li, Bowen Li, Bailin Wang, Bowen Qin, Ruiying Geng, Nan Huo, et al\.Can llm already serve as a database interface? a big bench for large\-scale database grounded text\-to\-sqls\.*Advances in Neural Information Processing Systems*, 36:42330–42357, 2023\.
- Liu et al\. \[2025\]Marianne Menglin Liu, Sai Ashish Somayajula, Syed Fahad Allam Shah, Sujith Ravi, and Dan Roth\.Oraplan–sql: A planning\-centric framework for complex bilingual nl2sql reasoning\.In*International Joint Conference on Knowledge Graphs*, pages 537–544\. Springer, 2025\.
- Liu et al\. \[2026\]Yifu Liu, Yin Zhu, Yingqi Gao, Zhiling Luo, Xiaoxia Li, Xiaorong Shi, Yuntao Hong, Jinyang Gao, Yu Li, Bolin Ding, et al\.Xiyan\-sql: A novel multi\-generator framework for text\-to\-sql\.*IEEE Transactions on Knowledge and Data Engineering*, 2026\.
- Luo et al\. \[2025\]Yuyu Luo, Guoliang Li, Ju Fan, Chengliang Chai, and Nan Tang\.Natural language to SQL: State of the art and open problems\.*Proceedings of the VLDB Endowment*, 18\(12\):5466–5471, 2025\.doi:10\.14778/3750601\.3750696\.
- Mao and contributors \[2023\]Toby Mao and SQLGlot contributors\.SQLGlot: A no\-dependency sql parser, transpiler, optimizer, and engine\.[https://github\.com/tobymao/sqlglot](https://github.com/tobymao/sqlglot), 2023\.Accessed: 2026\-04\-29\.
- Mazumder et al\. \[2026\]Aritra Mazumder, Parth Desai, Fuheng Zhao, and Anna Fariha\.AtomSQL: Interactive disambiguation of NL\-to\-SQL via user\-guided atom\-level alignment\.*Proceedings of the VLDB Endowment*, 19, 2026\.Demo Track, VLDB 2026\.
- Min et al\. \[2020\]Sewon Min, Julian Michael, Hannaneh Hajishirzi, and Luke Zettlemoyer\.Ambigqa: Answering ambiguous open\-domain questions\.In*Proceedings of the 2020 conference on empirical methods in natural language processing \(EMNLP\)*, pages 5783–5797, 2020\.
- OpenAI \[2025\]OpenAI\.Introducing gpt\-5\.[https://openai\.com/index/introducing\-gpt\-5/](https://openai.com/index/introducing-gpt-5/), 2025\.Accessed: 2026\-05\-06\.
- OpenAI \[2026a\]OpenAI\.Introducing gpt\-5\.4\.[https://openai\.com/index/introducing\-gpt\-5\-4/](https://openai.com/index/introducing-gpt-5-4/), 2026a\.Accessed: 2026\-05\-06\.
- OpenAI \[2026b\]OpenAI\.Introducing gpt\-5\.3\-codex\.[https://openai\.com/index/introducing\-gpt\-5\-3\-codex/](https://openai.com/index/introducing-gpt-5-3-codex/), 2026b\.Accessed: 2026\-05\-06\.
- Oracle Corporation \[2024\]Oracle Corporation\.Beaver \(oracle conversion\)\.[https://github\.com/oracle\-samples/beaver](https://github.com/oracle-samples/beaver), 2024\.GitHub repository, accessed: 2026\-04\-27\.
- Pourreza and Rafiei \[2023\]Mohammadreza Pourreza and Davood Rafiei\.Din\-sql: Decomposed in\-context learning of text\-to\-sql with self\-correction\.*Advances in neural information processing systems*, 36:36339–36348, 2023\.
- Pourreza et al\. \[2025\]Mohammadreza Pourreza, Hailong Li, Ruoxi Sun, Yeounoh Chung, Shayan Talaei, Gaurav Tarlok Kakkar, Yu Gan, Amin Saberi, Fatma Ozcan, and Sercan Arik\.Chase\-sql: Multi\-path reasoning and preference optimized candidate selection in text\-to\-sql\.In*International Conference on Learning Representations*, volume 2025, pages 60385–60415, 2025\.
- Rao and Daumé III \[2018\]Sudha Rao and Hal Daumé III\.Learning to ask good questions: Ranking clarification questions using neural expected value of perfect information\.In*Proceedings of the 56th Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\)*, pages 2737–2746, 2018\.
- Reza \[1994\]Fazlollah M Reza\.*An introduction to information theory*\.Courier Corporation, 1994\.
- Rice \[2025\]Kris Rice\.Oracle db skills: Sql development\.[https://github\.com/krisrice/oracle\-db\-skills/tree/main?tab=readme\-ov\-file\#sql\-development](https://github.com/krisrice/oracle-db-skills/tree/main?tab=readme-ov-file#sql-development), 2025\.GitHub repository, accessed 2026\-05\-06\.
- Saparina and Lapata \[2024\]Irina Saparina and Mirella Lapata\.Ambrosia: A benchmark for parsing ambiguous questions into database queries\.*Advances in Neural Information Processing Systems*, 37:90600–90628, 2024\.
- Sun et al\. \[2025\]Ji Sun, Guoliang Li, Peiyao Zhou, Yihui Ma, Jingzhe Xu, and Yuan Li\.Agenticdata: An agentic data analytics system for heterogeneous data, 2025\.URL[https://arxiv\.org/abs/2508\.05002](https://arxiv.org/abs/2508.05002)\.
- Talaei et al\. \[2024\]Shayan Talaei, Mohammadreza Pourreza, Yu\-Chen Chang, Azalia Mirhoseini, and Amin Saberi\.Chess: Contextual harnessing for efficient sql synthesis\.*arXiv preprint arXiv:2405\.16755*, 2024\.
- Tian and Zhang \[2026\]Yuan Tian and Tianyi Zhang\.Pv\-sql: Synergizing database probing and rule\-based verification for text\-to\-sql agents\.*arXiv preprint arXiv:2604\.17653*, 2026\.
- Vaidya et al\. \[2025\]Kapil Vaidya, Abishek Sankararaman, Jialin Ding, Chuan Lei, Xiao Qin, Balakrishnan Narayanaswamy, and Tim Kraska\.Odin: A nl2sql recommender to handle schema ambiguity\.*arXiv preprint arXiv:2505\.19302*, 2025\.
- Wang et al\. \[2023\]Bing Wang, Yan Gao, Zhoujun Li, and Jian\-Guang Lou\.Know what i don’t know: Handling ambiguous and unknown questions for text\-to\-sql\.In*Findings of the Association for Computational Linguistics: ACL 2023*, pages 5701–5714, 2023\.
- Wang et al\. \[2025\]Bing Wang, Changyu Ren, Jian Yang, Xinnian Liang, Jiaqi Bai, Linzheng Chai, Zhao Yan, Qian\-Wen Zhang, Di Yin, Xing Sun, et al\.Mac\-sql: A multi\-agent collaborative framework for text\-to\-sql\.In*Proceedings of the 31st International Conference on Computational Linguistics*, pages 540–557, 2025\.
- Wang et al\. \[2026\]Ziyang Wang, Yuanlei Zheng, Zhenbiao Cao, Xiaojin Zhang, Zhongyu Wei, Pei Fu, Zhenbo Luo, Wei Chen, and Xiang Bai\.Autolink: Autonomous schema exploration and expansion for scalable schema linking in text\-to\-sql at scale\.In*Proceedings of the AAAI Conference on Artificial Intelligence*, volume 40, pages 33809–33817, 2026\.
- Ye et al\. \[2024\]Jiayi Ye, Yanbo Wang, Yue Huang, Dongping Chen, Qihui Zhang, Nuno Moniz, Tian Gao, Werner Geyer, Chao Huang, Pin\-Yu Chen, et al\.Justice or prejudice? quantifying biases in llm\-as\-a\-judge\.*arXiv preprint arXiv:2410\.02736*, 2024\.
- Yu et al\. \[2018\]Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, Dongxu Wang, Zifan Li, James Ma, Irene Li, Qingning Yao, Shanelle Roman, et al\.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 on empirical methods in natural language processing*, pages 3911–3921, 2018\.
- Zheng et al\. \[2024\]Danna Zheng, Mirella Lapata, and Jeff Pan\.Archer: A human\-labeled text\-to\-sql dataset with arithmetic, commonsense and hypothetical reasoning\.In*Proceedings of the 18th Conference of the European Chapter of the Association for Computational Linguistics \(Volume 1: Long Papers\)*, pages 94–111, 2024\.

## Appendix ARelated Works

Beyond NL2SQL: Ambiguity in NL\.Ambiguity is a well\-studied challenge in NLP broadly\. AmbigQA\[[21](https://arxiv.org/html/2606.11424#bib.bib21)\]establishes that open\-domain questions frequently admit multiple valid interpretations\. Rao and Daumé\[[28](https://arxiv.org/html/2606.11424#bib.bib28)\]frame clarification question generation as maximizing expected information gain, while Aliannejadi et al\.\[[1](https://arxiv.org/html/2606.11424#bib.bib1)\]demonstrate the value of proactive clarification in conversational search\. Keyvan and Huang\[[12](https://arxiv.org/html/2606.11424#bib.bib12)\]survey ambiguity handling in task\-oriented dialogue\. Unlike these approaches, our work exploits database\-intrinsic signals \(e\.g\., SQL syntax and schema metadata\) that are uniquely available in the NL2SQL setting to derive rich signals for disambiguation\.

## Appendix BNotation

Table[6](https://arxiv.org/html/2606.11424#A2.T6)summarizes the main notation used throughout the paper\.

Table 6:Notations and operators\.
## Appendix CAlgorithm \- Synthetic Query Log

Algorithm 1Soma\-SQL: Ambiguity Supervision from Synthetic SQL Query Log1:SQL query log

ℒ=\{qilog\}i=1N\\mathcal\{L\}=\\\{q\_\{i\}^\{\\log\}\\\}\_\{i=1\}^\{N\}, schema

SS, number of candidates

KK
2:Ambiguity resolution set

𝒞\\mathcal\{C\}
3:Initialize ambiguity resolution set:

4:

𝒞←∅\\mathcal\{C\}\\leftarrow\\varnothing
5:foreach intent anchor

qilog∈ℒq\_\{i\}^\{\\log\}\\in\\mathcal\{L\}do

6:Intent Anchor Generation:

7:Generate fully specified NL question:

8:

xi←Describe​\(qilog,S\)x\_\{i\}\\leftarrow\\mathrm\{Describe\}\(q\_\{i\}^\{\\log\},S\)
9:Generate underspecified variants by removing details along common ambiguity dimensions:

10:

\{xi\(j\)\}j=1mi←Underspecify​\(xi\)\\\{x\_\{i\}^\{\(j\)\}\\\}\_\{j=1\}^\{m\_\{i\}\}\\leftarrow\\mathrm\{Underspecify\}\(x\_\{i\}\)
11:foreach underspecified question

xi\(j\)x\_\{i\}^\{\(j\)\}do

12:Candidate Disagreement Extraction:

13:Generate candidate SQL queries:

14:

𝒬K​\(xi\(j\),S\)⊂𝒬​\(S\)\\mathcal\{Q\}\_\{K\}\(x\_\{i\}^\{\(j\)\},S\)\\subset\\mathcal\{Q\}\(S\)
15:Present all

KKcandidates to an LLM and extract implementation\-level discrepancies:

16:

Δi\(j\)←ConsolidateUniqueDiffs​\(𝒬K​\(xi\(j\),S\)\)\\Delta\_\{i\}^\{\(j\)\}\\leftarrow\\mathrm\{ConsolidateUniqueDiffs\}\(\\mathcal\{Q\}\_\{K\}\(x\_\{i\}^\{\(j\)\},S\)\)
17:Ambiguity Supervision Construction:

18:Convert discrepancies into structured ambiguity records:

19:

\{\(Z,𝒪,ℰ\)\}←ExtractAmbiguities​\(Δi\(j\)\)\\\{\(Z,\\mathcal\{O\},\\mathcal\{E\}\)\\\}\\leftarrow\\mathrm\{ExtractAmbiguities\}\(\\Delta\_\{i\}^\{\(j\)\}\)
20:foreach ambiguity record

\(Z,𝒪,ℰ\)\(Z,\\mathcal\{O\},\\mathcal\{E\}\)do

21:Identify anchor\-supported option:

22:

o∗←MatchAnchor​\(qilog,𝒪\)o^\{\*\}\\leftarrow\\mathrm\{MatchAnchor\}\(q\_\{i\}^\{\\log\},\\mathcal\{O\}\)
23:if

o∗∉𝒪o^\{\*\}\\notin\\mathcal\{O\}then

24:Add grounded option derived from

qilogq\_\{i\}^\{\\log\}to

𝒪\\mathcal\{O\}
25:endif

26:Construct MCQ\-style supervision item:

27:

c←\(xi\(j\),S,Z,𝒪,o∗,ℰ\)c\\leftarrow\(x\_\{i\}^\{\(j\)\},S,Z,\\mathcal\{O\},o^\{\*\},\\mathcal\{E\}\)
28:Add supervision item to ambiguity resolution set:

29:

𝒞←𝒞∪\{c\}\\mathcal\{C\}\\leftarrow\\mathcal\{C\}\\cup\\\{c\\\}
30:endfor

31:endfor

32:endfor

33:return

𝒞\\mathcal\{C\}

## Appendix DAlgorithm \- Ambiguity Discovery, Probing, and Repair

Algorithm 2Soma\-SQL: Ambiguity Discovery, Probing, and Repair1:Question

xx, schema

SS, retrieved ambiguity records

𝒞x\\mathcal\{C\}\_\{x\}\(optional\), database

DD, number of diagnostic candidates

KK
2:Final SQL query

q^\\hat\{q\}
3:Diagnostic Candidate Generation:

4:Sample diagnostic SQL candidates:

5:

𝒬K​\(x,S\)\\mathcal\{Q\}\_\{K\}\(x,S\)
6:Select seed SQL using an LLM judge:

7:

q\(0\)←Select​\(x,S,𝒬K​\(x,S\)\)q^\{\(0\)\}\\leftarrow\\mathrm\{Select\}\(x,S,\\mathcal\{Q\}\_\{K\}\(x,S\)\)
8:Ambiguity Discovery:

9:Extract candidate\-induced ambiguity dimensions and implementation evidence:

10:

\{\(Ztcand,ℰtcand\)\}t=1mc\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\}
11:

←ExtractCandidateAmbiguities​\(𝒬K​\(x,S\)\)\\leftarrow\\mathrm\{ExtractCandidateAmbiguities\}\(\\mathcal\{Q\}\_\{K\}\(x,S\)\)
12:Extract taxonomy\-induced ambiguity dimensions:

13:

\{Zjtax\}j=1mt\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\}
14:

←ExtractTaxonomyAmbiguities​\(x,S\)\\leftarrow\\mathrm\{ExtractTaxonomyAmbiguities\}\(x,S\)
15:Form probing targets:

16:

𝒵←\{\(Ztcand,ℰtcand\)\}t=1mc∪\{Zjtax\}j=1mt\\mathcal\{Z\}\\leftarrow\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\}\\cup\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\}
17:Database Probing:

18:foreach candidate\-induced dimension

\(Ztcand,ℰtcand\)\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)do

19:Construct probe SQLs using implementation evidence:

20:

𝒫t←BuildCandidateProbes​\(Ztcand,ℰtcand,x,S,D\)\\mathcal\{P\}\_\{t\}\\leftarrow\\mathrm\{BuildCandidateProbes\}\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\},x,S,D\)
21:Execute probes and collect grounding evidence:

22:

Rtcand←Execute​\(𝒫t,D\)R\_\{t\}^\{\\mathrm\{cand\}\}\\leftarrow\\mathrm\{Execute\}\(\\mathcal\{P\}\_\{t\},D\)
23:endfor

24:foreach taxonomy\-induced dimension

ZjtaxZ\_\{j\}^\{\\mathrm\{tax\}\}do

25:Instantiate plausible alternatives from schema and database:

26:

𝒜j←InstantiateAlternatives​\(Zjtax,S,D\)\\mathcal\{A\}\_\{j\}\\leftarrow\\mathrm\{InstantiateAlternatives\}\(Z\_\{j\}^\{\\mathrm\{tax\}\},S,D\)
27:Construct probe SQLs:

28:

𝒫j←BuildTaxonomyProbes​\(Zjtax,𝒜j,x,S,D\)\\mathcal\{P\}\_\{j\}\\leftarrow\\mathrm\{BuildTaxonomyProbes\}\(Z\_\{j\}^\{\\mathrm\{tax\}\},\\mathcal\{A\}\_\{j\},x,S,D\)
29:Execute probes and collect grounding evidence:

30:

Rjtax←Execute​\(𝒫j,D\)R\_\{j\}^\{\\mathrm\{tax\}\}\\leftarrow\\mathrm\{Execute\}\(\\mathcal\{P\}\_\{j\},D\)
31:endfor

32:Aggregate grounding report:

33:

R←\{Rtcand\}t=1mc∪\{Rjtax\}j=1mtR\\leftarrow\\\{R\_\{t\}^\{\\mathrm\{cand\}\}\\\}\_\{t=1\}^\{m\_\{c\}\}\\cup\\\{R\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\}
34:Ambiguity Resolution:

35:Resolve ambiguity dimensions using retrieved records and grounding evidence:

36:

z^←Resolve​\(x,S,𝒞x,\{\(Ztcand,ℰtcand\)\}t=1mc,\{Zjtax\}j=1mt,R\)\\hat\{z\}\\leftarrow\\mathrm\{Resolve\}\\\!\\left\(x,S,\\mathcal\{C\}\_\{x\},\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\},\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\},R\\right\)
37:SQL Repair and Final Generation:

38:Repair the seed SQL under resolved intent:

39:

q^∼Pθ​\(q∣x,S,z^,q\(0\),R\)\\hat\{q\}\\sim P\_\{\\theta\}\(q\\mid x,S,\\hat\{z\},q^\{\(0\)\},R\)
40:return

q^\\hat\{q\}

## Appendix EProof and Discussion of Proposition[1](https://arxiv.org/html/2606.11424#Thmproposition1)

###### Proof\.

Given a question\-schema pair\(x,S\)\(x,S\), denoteZZas the latent user intent,UUthe ideal human clarification signal induced by the MCQ interaction, andYYthe automated clarification proxy constructed bySoma\-SQL\.

We assume that, conditional on\(x,S\)\(x,S\),YYis a noisy proxy forUU, formalized by the Markov chain

Z−U−Y∣\(x,S\)\.Z\-U\-Y\\mid\(x,S\)\.Equivalently, once the ideal clarification signalUUis known, the proxyYYprovides no additional information about the latent intent:

Z⟂⟂Y∣U,x,S\.Z\\perp\\\!\\\!\\\!\\perp Y\\mid U,x,S\.
By the conditional data\-processing inequality\[[29](https://arxiv.org/html/2606.11424#bib.bib29)\],

I​\(Z;Y∣x,S\)≤I​\(Z;U∣x,S\)\.I\(Z;Y\\mid x,S\)\\leq I\(Z;U\\mid x,S\)\.Thus, the information thatSoma\-SQL’s automated proxy carries about the latent intent is upper\-bounded by the information available from ideal human clarification\.

∎

#### Why the Markov assumption is appropriate\.

The assumption does not mean thatSoma\-SQLobservesUUdirectly\. Rather, it modelsUUas the ideal ambiguity\-resolving signal: if a user were asked the MCQ produced from the discovered ambiguity options, their response would directly specify the intended resolution\. The automated proxyYYis designed to approximate this clarification signal using only system\-generated evidence:

Y≜\(𝒬K​\(x,S\),𝒞x,\{\(Ztcand,ℰtcand\)\}t=1mc,\{Zjtax\}j=1mt,R\)\.Y\\triangleq\\Bigl\(\\mathcal\{Q\}\_\{K\}\(x,S\),\\;\\mathcal\{C\}\_\{x\},\\;\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\},\\;\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\},\\;R\\Bigr\)\.Here,𝒬K​\(x,S\)\\mathcal\{Q\}\_\{K\}\(x,S\)is the diagnostic candidate set,𝒞x\\mathcal\{C\}\_\{x\}is the retrieved confusion set,\{\(Ztcand,ℰtcand\)\}t=1mc\\\{\(Z\_\{t\}^\{\\mathrm\{cand\}\},\\mathcal\{E\}\_\{t\}^\{\\mathrm\{cand\}\}\)\\\}\_\{t=1\}^\{m\_\{c\}\}are candidate\-induced ambiguity dimensions with SQL evidence,\{Zjtax\}j=1mt\\\{Z\_\{j\}^\{\\mathrm\{tax\}\}\\\}\_\{j=1\}^\{m\_\{t\}\}are taxonomy\-induced ambiguity dimensions, andRRis the probe\-execution grounding report\. Together, these components constitute the evidenceSoma\-SQLuses to approximate the ambiguity resolution that would otherwise be supplied by the user\.

#### When the proxy approaches the human ceiling\.

The gap

I​\(Z;U∣x,S\)−I​\(Z;Y∣x,S\)I\(Z;U\\mid x,S\)\-I\(Z;Y\\mid x,S\)measures the remaining value of explicit human clarification overSoma\-SQL’s automated proxy\. This gap is small when the historical log contains resolved examples of the same or similar ambiguity pattern\. In that case, retrieved confusion records act as synthetic human feedback: they identify ambiguity dimensions and historically supported resolutions that approximate the clarification a user would provide\.

This is especially relevant for database workloads, which are often repetitive for a fixed schema\. As historical log accumulates coverage of recurring intent patterns,𝒞x\\mathcal\{C\}\_\{x\}becomes more likely to retrieve useful precedents\. For such covered patterns,YYcan approach the information content ofUU\. For rare or novel intents, however, the log lacks precedent, and the residual gap remains large\. These are precisely the cases where explicit human clarification is most valuable\.

#### Uncertainty\-reduction interpretation\.

Although the main proposition focuses on the human\-clarification ceiling, the same evidence variableYYalso admits a standard uncertainty\-reduction interpretation\. We quantify the ambiguity of a question by the conditional entropyH​\(Z∣x,S\)H\(Z\\mid x,S\)of the underspecified intentZZgivenxxandSS\. High entropy indicates that many interpretations remain plausible after observing the question and schema, whereas low entropy indicates that only a few interpretations are likely\.

By the definition of conditional mutual information,

I​\(Z;Y∣x,S\)=H​\(Z∣x,S\)−𝔼Y∣x,S​\[H​\(Z∣x,S,Y\)\]\.I\(Z;Y\\mid x,S\)=H\(Z\\mid x,S\)\-\\mathbb\{E\}\_\{Y\\mid x,S\}\\left\[H\(Z\\mid x,S,Y\)\\right\]\.
Rearranging the expression gives

𝔼Y∣x,S​\[H​\(Z∣x,S,Y\)\]=H​\(Z∣x,S\)−I​\(Z;Y∣x,S\)\.\\mathbb\{E\}\_\{Y\\mid x,S\}\\left\[H\(Z\\mid x,S,Y\)\\right\]=H\(Z\\mid x,S\)\-I\(Z;Y\\mid x,S\)\.
Therefore, if

I​\(Z;Y∣x,S\)\>0,I\(Z;Y\\mid x,S\)\>0,then

𝔼Y∣x,S​\[H​\(Z∣x,S,Y\)\]<H​\(Z∣x,S\)\.\\mathbb\{E\}\_\{Y\\mid x,S\}\\left\[H\(Z\\mid x,S,Y\)\\right\]<H\(Z\\mid x,S\)\.
Hence, conditioning on the evidenceYYproduced bySoma\-SQLdecreases the expected posterior entropy of the latent intentZZ\. Equivalently, the observationYYprovides information aboutZZ, reducing uncertainty in expectation\.

This identity clarifies the contribution of each component ofYY\. Diagnostic candidates𝒬K​\(x,S\)\\mathcal\{Q\}\_\{K\}\(x,S\)expose ambiguity through implementation\-level disagreements\. Taxonomy\-guided detection adds ambiguity dimensions that candidate disagreement may miss\. Confusion\-set retrieval𝒞x\\mathcal\{C\}\_\{x\}supplies historically resolved ambiguity decisions when relevant log is available\. Probe execution contributes database\-grounded evidence about the consequences of candidate resolutions\. Each component can increase the information thatYYcarries aboutZZbeyond what is available from the question and schema alone\.

## Appendix FDataset Details

Spider 2\.0 Lite contains 547 questions over 158 large, heterogeneous databases with up to 800\+ columns and multiple SQL dialects \(e\.g\., SQLite, Snowflake, BigQuery\), emphasizing multi\-step reasoning and dialect robustness\. BIRD\-dev contains 1,534 questions over 11 real\-world databases with complex queries, realistic schemas, and noisy values\. Archer\-dev evaluates reasoning\-intensive NL2SQL in English and Chinese, with 104 questions over 2 databases per split involving arithmetic, hypothetical, and commonsense reasoning\. BEAVER \(Oracle dialect\) contains 209 enterprise\-oriented questions over 6 databases with business\-specific semantics and substantial schema and value ambiguity; we use the Oracle SQL version\[[25](https://arxiv.org/html/2606.11424#bib.bib25)\]to evaluate dialect robustness\. Ambrosia\[[31](https://arxiv.org/html/2606.11424#bib.bib31)\]evaluates robustness to semantic ambiguity with 4,242 questions containing multiple valid interpretations and corresponding SQL programs\.

## Appendix GAdditional Details aboutSoma\-SQL

Realistic databases often contain hundreds of tables and thousands of columns\. Including the full schema in the prompt is therefore impractical: it increases context length and can cause prompt context overflow\. Before running the main workflow,Soma\-SQLfirst enriches the raw schema with additional semantic information, such as column descriptions, value hints, and index\-derived evidence\[[17](https://arxiv.org/html/2606.11424#bib.bib17),[3](https://arxiv.org/html/2606.11424#bib.bib3)\]\. It then applies agentic schema\[[38](https://arxiv.org/html/2606.11424#bib.bib38)\]to select the subset of tables, columns, and relationships most relevant to the input questionxx\. The downstream workflow operates only on this linked schema subset, which we denote bySSfor notational simplicity\. This preprocessing step keeps prompts compact while preserving the schema evidence needed for SQL generation\.

We also tune the system prompt used by the planner\. Following the prompt\-refinement strategy ofLiu et al\. \[[16](https://arxiv.org/html/2606.11424#bib.bib16)\], we run a pilot study on a small held\-out subset of the Archer training data\[[41](https://arxiv.org/html/2606.11424#bib.bib41)\], inspect recurring failure modes, and incorporate the resulting corrective guidelines into the planner’s system prompt\. For dialect\-specific instructions for SQLite, Snowflake, and BigQuery SQL, we followWang et al\. \[[38](https://arxiv.org/html/2606.11424#bib.bib38)\]and explicitly condition SQL generation on the target database dialect\. For Oracle dialect instructions, we follow\[[30](https://arxiv.org/html/2606.11424#bib.bib30)\]\.

### G\.1Prompt for SQL Plan Generation

SQL Plan Generation PromptRoleYou are a Plan Decomposer\. Your task is to read a natural language question, a SQL database schema, and optional additional information\. Then output a short, step\-by\-step plan in natural language that MUST be followed to write the SQL query\.Inputs•Question: \{question\}•Additional Information \(Optional\): \{external\_info\}Output Format \(Strict\)1\.…2\.…3\.…Return columns: <…\>General Rules•Use ONLY column and table names in schema\. Do not invent names\.•Prefer scalar subqueries for single values; use JOINs only when necessary\.•Keep each step focused \(3–6 steps total\)\.•End with exactly one line:Return columns: <exact list\>•Use at most two guardrails per plan\.Projection Minimality \(Strict\)•Return only explicitly requested fields, in exact order\.•“Which <entity\> … ?”→\\rightarrowreturn only entity name\.•Single\-value questions→\\rightarrowreturn a single scalar column\.•“Names and ages”→\\rightarrowexactly two columns: name, age\.•Do not include helper or intermediate values unless requested\.Schema``` {schema} ```

### G\.2Prompt for SQL Generation

Prompt for SQL GenerationYou are an expert NL2SQL translator\. Your task is to convert natural language questions into accurate and executable SQL queries for \{dialect\} databases\.Requirements•Interpret complex logic \(e\.g\., relative time, comparisons, conditional joins\)\.•Use correct SQL syntax and valid table relationships\.•Use only valid \{dialect\} syntax\.•Prefer UPPERCASE SQL keywords\.•Output only raw SQL \(no comments, no explanations, no markdown\)\.Inputs•Question: \{question\}•Execution Plan: \{plan\}•Additional Information: \{external\_info\}•Database Schema: \{schema\_txt\}Output•A single valid SQL query\.•No comments, no explanations, no extra text\.SQL Query

### G\.3Prompt for SQL Query Plan Correction

SQL Query Plan Correction PromptRoleYou are an experienced and professional database administrator tasked with analyzing and correcting SQL queries that are potentially wrong\.ContextYou are provided with:•A \{dialect\} database schema•A user question•A proposed SQL query intended to answer the question•An error report for the proposed SQL queryDatabase Schema•The schema consists of table descriptions\.•Each table contains multiple column descriptions\.•Example values for each column are provided\.Instructions•Carefully review the provided context\.•Analyze the error report\.•If the SQL is incorrect, generate a corrected SQL query that answers the question\.•Use only valid \{dialect\} syntax\.•Prefer UPPERCASE SQL keywords\.•Avoid unnecessarily complex queries\.•Prefer JOINs over overly nestedEXISTSclauses when equivalent\.•Output only the SQL query\.•Do not include explanations or comments\.Inputs•Question: \{question\}•External Knowledge: \{external\_info\}•Previous Compile Error Log: \{previous\_compile\_error\_log\}•Previous SQL: \{previous\_sql\}•Relevant Function Documentation: \{function\_documentation\}•Database Schema: \{schema\_txt\}TaskAnalyze the error report and generate a corrected SQL query that answers the user question\.Output``` <correct SQL query> ```

### G\.4Prompt for SQL Critique

You are an experienced database administrator tasked with validating SQL and correcting it only when there is clear evidence of an error\.Inputs•A \{dialect\} database schema•A user question•A proposed SQL query•An error report, which may contain false positivesDatabase Schema•Table descriptions•Column descriptions•Frequent column valuesTask•Analyze the error report\.•Keep the SQL unchanged if it is already correct\.•Otherwise, generate a corrected SQL query\.Editing Policy•If the error report is UNKNOWN, N/A, FALSE, or only warnings, return the original SQL unchanged\.•Do not rewrite for style, readability, or optimization\.•Edit only when there is a concrete, localizable defect\.•If unsure, output the original SQL verbatim\.Instructions•Use valid \{dialect\} syntax only\.•Output only SQL in a code block \(no comments or explanations\)\.•Avoid unnecessary complexity \(e\.g\., preferJOINoverEXISTSwhen equivalent\)\.Dialect Rules\{dialect\_rules\}Inputs•Question: \{question\}•Old SQL:\{prev\_sql\}•Error Report:\{error\_report\}•Database Info: \{schema\_txt\}Determine whether the SQL requires correction and, if so, generate the corrected query\.Final SQL

### G\.5Prompt for Ambiguity Driven SQL Probing and Repair

Prompt for Ambiguity Probing SQL RepairYou are using$sql\-error\-fixing\-coreskill to repair \{instance\_id\} with ambiguity driven SQL probing and repair\. Your goal is to repair or select the SQL only when probe evidence supports a concrete correction or selection\.Instance Context•Dataset profile: \{dataset\_name\}•Current SQL: \{before\_fix\_sql\_path\}•Seed run name: \{seed\_run\_name\}•Seed source run for current SQL: \{seed\_source\_run\_name\}•Question text available: \{question\_text\_available\}•Question source: \{question\_text\_source\}•Question: \{question\_text\}•Seed mode: \{seed\_mode\}Candidate SQL Context•Candidate SQL count from run\_records: \{candidate\_sql\_count\}•Candidate run names: \{candidate\_run\_names\}•Candidate SQL artifacts dir: \{candidate\_sql\_dir\}•Candidate SQL manifest path: \{candidate\_sql\_manifest\_path\}•Candidate SQL context: \{candidate\_sql\_overview\}Probing Policy•Save all probing outputs under \{probe\_reports\_instance\_dir\}\.•Use \{probe\_reports\_root\} as the probing reports root for this run\.•If implementation diff is available, create 8–9 clarification probes total with exactly 3 implementation\-diff\-grounded probes and 5–6 baseline taxonomy\-grounded probes\.•If implementation diff is unavailable, create exactly 9 baseline taxonomy\-grounded probes and 0 implementation\-diff\-grounded probes\.•Treat implementation diff only as ambiguity hypotheses\.•Do not patch directly from diff; patch only from probe evidence\.Scope and System Prompts•Scan scope policy: \{scan\_scope\_instructions\}•Read scope instructions: \{read\_scope\_instructions\}•SQL fixing system prompt: \{sql\_fixing\_system\_prompt\}•Probing resolution system prompt: \{probing\_resolution\_system\_prompt\}•System prompt files: sql\_fixing=\{sql\_fixing\_system\_prompt\_path\}, probing\_resolution=\{probing\_resolution\_system\_prompt\_path\}Repair Target•Write the final repaired SQL to \{fixed\_sql\_path\}\.•Save results under this exact root directory only: \{save\_results\_dir\}\.Now perform ambiguity probing, resolve the SQL only from probe evidence, and produce the repaired SQL\.Final SQL

### G\.6Ambiguity\-Driven SQL Probing and Repair Contract

We implement ambiguity\-driven SQL probing and repair with thesql\-error\-fixing\-coreskill, whose detailed repair contract is defined below\. The module processes one instance at a time and uses probe\-grounded evidence to decide whether to keep the current SQL, select an existing candidate, or repair the query\.

Ambiguity\-Driven SQL Probing and Repair Workflow1\.Input: question, seed SQL \(primary patch target\), candidate SQLs, implementation difference report of candidate SQLs, schema evidence, and optional external info\.2\.Generate a clarifying\-question plan\.\(a\)For each question, assignquestion\_id, taxonomy \(AmbiSchema,AmbiValue,AmbiIntent\),ambiguity\_question,why\_high\_impact, andprobe\_sql\_rationale\.\(b\)Generate exactly 8–9 questions\.\(c\)If implementation\-diff is available, exactly 3 must be diff\-grounded and the rest taxonomy\-grounded; otherwise all taxonomy\-grounded\.3\.Generate and execute ambiguity probes\.\(a\)AmbiSchema: ambiguous schema mappings \(table/column/grain/metric\)\.\(b\)AmbiValue: question values do not directly align with database values, leading to ambiguous filter literals\.\(c\)AmbiIntent: ambiguous SQL semantics \(e\.g\.,ORDER BYvs\.GROUP BY\)\.\(d\)Write one probe SQL per question and execute all probes, saving SQL and CSV artifacts\.4\.Convert probe results into resolved assumptions\.5\.Apply a minimal probe\-evidence\-backed SQL patch\.\(a\)Patch only the seed SQL baseline; use candidates as reference only\.\(b\)Apply changes only when supported by probe evidence; keep edits minimal and localized\.\(c\)Use implementation diff as hypothesis context only, never as a patch source\.\(d\)Ensure all rewrites are probe\-evidence\-backed \(ambiguity\_resolutions\); otherwise retain the baseline SQL\.6\.Run final sanity and freeze\.\(a\)Execute final SQL withexecute\_sql\.py\.\(b\)If execution fails or returns empty, fall back to baseline SQL\.\(c\)Always producefixed\_sql/<instance\_id\>\.sql; limit to 3 attempts\.Constraints•Do not read or use gold SQL or gold execution during fixing\.•No SQL patch before probe evidence exists\.•If implementation diff is provided, treat it as hypothesis\-only context\.•Never patch SQL directly from implementation\-diff alternatives or snippets\.•Patch assumptions must be traceable to probe outputs; if any consensus item looks inconsistent with question or schema, validate by probe before patching\.•Probe execution and sanity checks must useexecute\_sql\.py\.Outputs•fixed\_sql/<instance\_id\>\.sql\.•Probe SQL and CSV artifacts\.•Probe report and summary files\.•Consolidated ambiguity\-resolution metadata\.

### G\.7Prompt for Detailed NL Question Generation in Synthetic Query Log Generation

We generate synthetic query log by reconstructing precise natural\-language questions from analytical logic\. The following prompt instructs the model to reverse\-engineer detailed and unambiguous business questions that preserve the full computational semantics of the underlying SQL\.

Prompt for Detailed NL Question GenerationYou are an expert data analyst who reconstructs precise business questions from analytical logic\. Your task is to reverse\-engineer a natural\-language question that fully specifies the computation implied by the given analytical logic\.Inputs•Backend/Dialect: \{backend\}•Database ID: \{db\_id\}•Schema: \{references\}•Gold SQL: \{gold\_sql\}ProcessCarefully reconstruct the full analytical workflow before writing the question\. Identify:•The exact population and all filtering conditions, including status, date, category, and NULL handling\.•Any lookup, mapping, or normalization steps \(e\.g\., string transformations or case normalization\)\.•Entity relationships and how records are brought into scope\.•All intermediate metrics, transformations, and timestamp or date extraction steps\.•Ranking, scoring, segmentation, or window operations\.•All conditional rules, including full classification logic and thresholds\.•Aggregation logic, including grouping and multi\-stage aggregation\.•Ordering, limits, offsets, and tie\-breaking rules\.•Any excluded or unassigned records\.RequirementsThe generated question must:•Fully specify the population and all filtering conditions\.•Describe all intermediate computations and transformations\.•Define all metrics, aggregations, rankings, and classification rules precisely\.•Preserve all nuances of the analytical logic, including low\-level details such as normalization and date extraction\.•Clearly state the final output and what each value represents\.•Be written as a single coherent natural\-language paragraph\.Constraints•Do not omit any logic from the analytical specification\.•Do not introduce assumptions not present in the logic\.•Avoid vague phrases \(e\.g\., “analyze trends”\)\.•Do not mention implementation terms \(e\.g\., SQL, query, table, column, join\)\.•Do not use bullet points or numbered lists in the output\.•Do not include explanations or preamble text\.Output•Return only a single detailed natural\-language question\.

### G\.8Prompt for Ambiguous NL Question Generation in Synthetic Query Log Generation

We generate realistic ambiguous user questions by relaxing fully specified analytical questions while preserving their SQL\-equivalent intent\. The following prompt instructs the model to produce natural text\-to\-SQL questions that omit details commonly left implicit by users, such as metric definitions, aggregation choices, calculation explanations, and output formatting, while retaining all hard constraints required to recover the same result\.

Prompt for Ambiguous Text\-to\-SQL Question GenerationYou create realistic user questions for text\-to\-SQL\. Given a precise detailed question and its GOLD SQL, write up to \{num\_questions\} ambiguous user\-style questions that ask for the same result while omitting details real users often leave implicit, such as exact metric definitions, calculation explanations, aggregation choices, or output formatting\.Goal•Simulate natural user requests that preserve the same overall intent and result as the GOLD SQL\.•Use the schema only to understand available concepts and entities, such as customers, orders, products, payments, categories, or events\.•Do not mention table names or column names explicitly\.•When appropriate, include mild schema ambiguity, such as referring to “orders” vs\. “items”, “customers” vs\. “users”, or “products” vs\. “categories”\.Ambiguity Patterns•Prefer missing intent keywords, such as “sales” without specifying revenue vs\. count, “average value” without specifying the aggregation level, or “top customers” without fully explaining the ranking metric\.•Include insufficient reasoning context, such as “active customers”, “customer spend”, or “performance” without restating all business\-rule details\.•Use mild entity\-level ambiguity when natural, such as orders vs\. order items, products vs\. categories, or deliveries vs\. shipments\.•Leave soft output details implicit when possible, such as ordering, rounding precision, aliases, tie\-breaking rules, or output formatting\.Constraint Preservation•First identify hard constraints in the GOLD SQL: filters, date ranges, ranking limits, grouping targets, aggregation scope, distinctness, conditional fallback rules, and required entity relationships\.•Preserve every hard constraint in every generated question, even if phrased naturally or implicitly\.•Do not remove or alter constraints that determine which records are included or how a core metric is computed\.•Soft constraints may be omitted when they do not change the core result, including rounding precision, column aliases, output order, and explanatory calculation steps\.Precision Rules•Preserve exact time and duration logic\.•Do not replace duration\-based constraints with calendar\-period phrasing; for example, “within 7 days” is not the same as “within the same week”\.•Do not introduce new filters, assumptions, entities, rankings, or business rules not implied by the GOLD SQL\.•Avoid technical language and do not mention SQL, query, database, table, column, join, CTE, or subquery\.Inputs•Backend/Dialect: \{backend\}•Database ID: \{db\_id\}•Number of Questions: \{num\_questions\}•Schema: \{references\}•Detailed Question: \{detailed\_question\}•GOLD SQL: \{gold\_sql\}Self\-Check•Ensure every hard constraint is logically present in each question\.•Ensure no question contradicts or changes the GOLD SQL\.•Ensure no duration, date, ranking, grouping, or filter boundary has drifted\.•Ensure a competent solver could recover the same intended result from the question\.Output•Output 1 to \{num\_questions\} lines\.•Each line must be exactly one natural question sentence\.•Each line must end with “?”\.•Output only the questions\.•No numbering, bullets, explanations, markdown, or extra text\.Ambiguous Questions

### G\.9Prompt for Ambiguity\-Resolution Reranking

We use an ambiguity\-resolution reranker for NL2SQL to select the safest and most useful in\-context candidate from the synthetic query log\. The reranker first infers the core ambiguity slots in the question, then scores each retrieved candidate by ambiguity relevance, assumption consistency, and contradiction risk, and finally returns a compact set of candidates for downstream prompting\.

Prompt for Ambiguity\-Resolution RerankerYou are an ambiguity\-resolution reranker for NL2SQL\. Given a current question and a set of retrieved candidate questions with ambiguity explanations, select up toreranker\_top\_kcandidates that are safest and most useful as in\-context ambiguity\-resolution guidance\.Step 1: Analyze the Question•Infer the core ambiguity slots relevant to the question\.•Common slot types include grouping grain or entity identifier, metric definition, counting rule, temporal conversion rule, ranking key, filtering scope, join scope or schema grounding, and null or missing\-data rule\.•For each core slot, infer the likely intended interpretation when supported by the question text\.•If a slot cannot be confidently inferred, mark it as uncertain rather than guessing\.•Prefer stable and schema\-safe interpretations for uncertain slots\.Step 2: Evaluate Each Candidate•Judge ambiguity relevance, resolution consistency, and contradiction risk\.•Do not reward topical similarity alone\.•Judge assumptions, not just topic overlap\.•Reject candidates that conflict with core assumptions or introduce harmful changes to grouping, filtering, aggregation, ranking, or final results\.•Treat grouping\-grain mismatches, counting\-rule mismatches, ranking\-key mismatches, metric\-construction mismatches, filtering\-scope mismatches, temporal\-conversion mismatches, and aggregation\-grain mismatches as contradictions when they can change results\.•Prefer concrete SQL\-relevant clarifications\.•When uncertain between keep and reject, prefer reject\.Step 3: Select the Final Set•Select up toreranker\_top\_kcandidates as a set\.•Maximize safety, consistency, coverage of distinct core ambiguity slots, and low redundancy\.•Prefer candidates that cover different ambiguity slots\.•For aggregation\-heavy questions, prioritize grouping, counting, and metric\-definition slots\.•For temporal or formula\-heavy questions, prioritize computation formulas and filtering rules\.•Return fewer thanreranker\_top\_kcandidates if necessary\.Output•Return valid JSON only\.•Include question analysis, per\-candidate evaluations, the selected set, and a concise selection summary\.•Mark contradictions explicitly and provide concrete harmful assumptions when possible\.

### G\.10Prompt for LLM\-as\-a\-Judge SQL Selection with Clarification

LLM\-as\-a\-Judge Prompt for SQL Candidate SelectionYou are a SQL correction judge for text\-to\-SQL systems\. Your job is to select the single best SQL query from exactly 10 candidates\.Task•You will be given:–a natural\-language question,–optional clarifying ambiguity questions and answers,–a schema,–exactly 10 candidate SQL queries\.•Choose the one candidate that best satisfies the user’s true intent\.•If clarifying question\-answer pairs are provided and non\-empty, treat them as the highest\-priority source of intent\.•If no clarifying Q&A is provided, infer the most likely intent from the question and schema alone\.Interpretation Rules•Translate clarifying Q&A into explicit semantic constraints, such as:–metric definition,–grouping grain,–filters,–join path,–time window,–ordering,–limits,–output columns\.•Prefer the candidate that best matches the clarified requirements with the fewest contradictions\.•If multiple candidates are similar, choose the one that is most faithful to the clarified intent and schema\.•Use only the provided question, clarifications, schema, and candidate SQLs\. Do not rely on outside knowledge\.Strict Constraints•Select exactly one of the 10 provided candidates\.•Do not rewrite, edit, combine, or synthesize SQL\.•The output SQL must be copied verbatim from one candidate, word\-for\-word\.•Before finalizing, verify that the SQL appears exactly in the candidate list\.•If a candidate uses invalid tables or columns according to the schema, do not choose it unless every other candidate is worse and the issue is minor; otherwise reject it in favor of the best valid option\.Selection Procedure1\.Parse the question and any clarifying Q&A into a precise intent\.2\.Compare all 10 candidates against that intent\.3\.Check schema validity and semantic faithfulness\.4\.Select the single best candidate\.5\.Output the candidate number and the exact SQL text, unchanged\.Output Format``` Candidate: <N> <exact SQL copied verbatim from candidate N> ``` Input Fields•Question: \{question\}•Clarifying Ambiguity Q&A: \{ambi\_blob\}•Candidate SQLs \(10\): \{generated\_sql\_list\}•Schema: \{references\}Hard Requirement•Output only the candidate number and the selected SQL\.•No explanation\.•No markdown\.•No extra text\.

## Appendix HExamples of Derived Clarification Questions

We show some examples of generated MCQ questions and answers from synthetic query log of AMBROSIA, Beaver, and Spider 2\.0 Lite\.

Examples of Original Questions and Derived MCQsAMBROSIA\.Original Question:Show all the action movies and romantic comedies lasting 2 hours\.Derived MCQ 1:Which interpretation best matches what you meant?A\)Show all 2\-hour films that are classed as either action or romantic comedy\.B\)Show all action movies, and only romantic comedy films lasting 2 hours\.C\)None of the above / not what I meant\.Selected Answer:A\.Explanation:Return films that are both 2 hours long and classified as either action or romantic comedy\.BEAVER\.Original Question:List the name and floor of the building with the largest floor number\.Derived MCQ 1:How should “largest floor number” be determined?A\)Use the floor\-ordering fieldFLOOR\_SORT\_SEQUENCEto identify the top floor, and returnBUILDING\_NAMEandFLOOR\.B\)Use the displayed floor valueFLOORitself to identify the top floor, and returnBUILDING\_NAMEandFLOOR\.C\)None of the above / not what I meant\.Selected Answer:B\.Explanation:Compare the numeric floor labels shown inFLOOR, ignoring non\-numeric floor values instead of using a separate sort field\.Spider 2\.0 Lite\.Original Question:For each visitor who made at least one transaction in February 2017, how many days elapsed between the date of their first visit in February and the date of their first transaction in February, and on what type of device did they make that first transaction?Derived MCQ 1:When a visitor has multiple purchase sessions on their earliest purchase date, which session should determine the reported device type?A\)Use the device from the first purchase session on that date, i\.e\., the earliestvisitStartTime\.B\)Use the device from any purchase session on that date, without imposing a specific time ordering\.C\)None of the above / not what I meant\.Selected Answer:A\.Explanation:Take the device type from the earliest purchase session on the first purchase day\.

## Appendix IPrompt for MCQ from Synthetic Log Helpfulness Evaluation

Prompt for NL2SQL Clarification Helpfulness EvaluationYou are evaluating the utility of injected Clarification MCQs for NL2SQL\. Assume the Clarification MCQ has already been injected into the prompt\.Evaluation GoalJudge whether the injected MCQ clarification makes the intended SQL semantics easier and more reliable for a strong NL2SQL model to recover\.Inputs•Instance ID: \{instance\_id\}•Original question: \{original\_question\}•Injected Clarification MCQ: \{mcq\_blob\}•Gold SQL context: \{gold\_sql\_section\}Decision Rule•Use the gold SQL as the primary signal for intended meaning when available\.•Label ashelpfulif the clarification plausibly reduces the risk of a semantically incorrect SQL query\.•Label asnot\_helpfulif the clarification is redundant, vague, unsupported by the gold SQL, or unlikely to change the model’s SQL interpretation\.Helpful Cases•The clarification resolves or partially resolves a SQL\-critical ambiguity\.•It reduces the chance of an incorrect filter, join, aggregation, ranking, temporal scope, or inclusion/exclusion decision\.•It is useful for recovering the intended SQL semantics, even if incomplete\.Not Helpful Cases•The clarification mostly repeats information already clear from the question\.•It adds no material ambiguity resolution\.•It is too vague to guide SQL construction\.•It is unsupported by the gold SQL\.•It does not meaningfully change what a strong NL2SQL model would infer\.Output Requirements•Return exactly one JSON object per evaluated instance\.•Output only the binaryhelpful/not\_helpfuljudgment\.•Be concrete and concise\.•Do not output multi\-class labels\.Output Format``` { "helpfulness_label": "helpful", "gold_sql_used": true, "key_sql_semantic_issue": "...", "rationale": "..." } ```

## Appendix JPrompt for Ambiguity\-Driven Probing Quality Analysis

LLM\-as\-a\-Judge Prompt for Ambiguity\-Driven Probing Quality AnalysisYou are an evaluator for ambiguity probing reliability in text\-to\-SQL systems\.Evaluation Dimensions•Probing Groundedness–Label = 1 iff every probing ambiguity question is justified by the NLQ, implementation diff evidence, and/or ambiguity taxonomy grounding\.•Resolution Correctness–Label = 1 iff every selected ambiguity resolution is logically correct and supported by probe evidence\.•SQL Repair Faithfulness–Label = 1 iff the repaired SQL implements the selected resolution\(s\) without unrelated semantic drift\.Inputs•Instance ID: \{instance\_id\}•NLQ: \{question\}•Taxonomy Context: \{taxonomy\_context\}•Implementation Diff Blob: \{implementation\_diff\_blob\}•Ambiguity Question Plan JSON: \{ambiguity\_question\_plan\_json\}•Ambiguity Resolutions JSON: \{ambiguity\_resolutions\_json\}•Probe Report JSONL: \{ambiguity\_probe\_report\_jsonl\}•Before SQL: \{before\_sql\}•Fixed SQL: \{fixed\_sql\}Rules•Base judgments only on the provided inputs\.•If required evidence for a metric is missing, assign label = 0 for that metric and explain why\.•Keep evidence concise and specific\.•Output strict JSON only\.Output Format``` { "instance_id": "{instance_id}", "groundedness": { "label": 0, "grounded_questions": 0, "total_questions": 0, "precision_grounded": 0.0, "evidence": ["..."], "rationale": "..." }, "resolution_correctness": { "label": 0, "correct_resolutions": 0, "total_resolutions": 0, "precision_resolution": 0.0, "evidence": ["..."], "rationale": "..." }, "repair_faithfulness": { "label": 0, "required_changes_count": 0, "implemented_changes_count": 0, "precision_faithful": 0.0, "unrelated_drift_detected": false, "evidence": ["..."], "rationale": "..." }, "all_three_pass": 0 } ```

## Appendix KBucketed Analysis of Hard Spider 2\.0\-Lite Instances

Table 7:Execution Accuracy on difficult Spider 2\.0\-Lite instances using Gemma\-4\-31B\. To estimate baseline variability, we first runSoma\-SQLten times per instance before applying probing and group instances by the number of correct executions across runs\. Instances with zero correct executions are labelednever correct, while instances with one to four correct executions are labeledsparsely correct\. Baseline results report mean execution accuracy and standard deviation across the 10 runs, whereas probing is evaluated once on the resulting buckets\.
## Appendix LAmbiguity Probing Quality Analysis

#### Sampling strategy\.

We construct the audit set from the full 547\-instance Spider 2\.0 evaluation generated by SOMA\-SQL with Gemma\-4\. To reduce sampling bias, we use outcome\-stratified proportional sampling over four transition categories:

wrong→\\rightarrowcorrect: the original SQL prediction is incorrect before probing, but the repaired SQL becomes correct after ambiguity probing and repair;

correct→\\rightarrowcorrect: the original SQL prediction is already correct before probing and remains correct after ambiguity probing and repair;

wrong→\\rightarrowwrong: the original SQL prediction is incorrect before probing and remains incorrect after ambiguity probing and repair;

correct→\\rightarrowwrong: the original SQL prediction is correct before probing, but ambiguity probing and repair introduce an incorrect final SQL prediction\.

We sample 50 instances proportionally from these categories and additionally require artifact completeness, including the probing plan, ambiguity resolutions, and probe report\.

#### Metric definitions\.

Each sampled instance is evaluated using binary labels on three dimensions: \(1\)Probing groundedness, \(2\)Resolution correctness, and \(3\)SQL repair faithfulness\.

Probing groundednessmeasures whether probing questions are justified by the NLQ and supported by either implementation\-diff evidence or ambiguity taxonomy grounding \(AmbiSchema,AmbiValue, orAmbiIntent\)\.

Resolution correctnessmeasures whether the selected ambiguity resolutions are supported by probe evidence and consistent with the intended user meaning\.

SQL repair faithfulnessmeasures whether the repaired SQL correctly implements the selected resolution\(s\) without introducing unrelated semantic drift\.

For each metric, a label of 1 is assigned only if all relevant sub\-items within the instance satisfy the criterion; otherwise, the instance receives label 0\.

#### Judge configuration\.

We use a separate judge model \(gpt5\.4\) from the generation model \(gemma\-4\) to reduce self\-enhancement bias\[[39](https://arxiv.org/html/2606.11424#bib.bib39)\]from LLM as a judge\. The judge is required to produce structured JSON outputs containing binary labels and supporting rationale for each metric\. The full judge prompt is provided in[J](https://arxiv.org/html/2606.11424#A10)\.

## Appendix MEnd\-to\-End Example: Ambiguity\-Guided SQL Repair

### M\.1Task Overview

Question:show me churn for enterprise customers last quarterAmbiguity: The term “churn” may correspond to multiple business definitions:•canceled subscriptions•inactive accounts•lost revenue•customers with no purchasesAmbiguity Hypothesis \(Implementation Diff\)``` slot: churn_definition candidates: { canceled_subscription, inactive_account, revenue_loss, no_recent_purchase } trigger: "churn" mention in NL ```

This example demonstrates howSoma\-SQLresolves semantic ambiguity using database\-grounded probing\.

### M\.2Repair Prompt \(Condensed\)

``` Use $sql-ambiguity-driven-probing to fix demo_churn_001. Question text available: true Question: show me churn for enterprise customers last quarter Candidate SQL count from run_records: 10 Candidate run names: run_1,...,run_10 Candidate SQL context: multiple candidate SQL variants available Implementation diff available: true implementation_diff_blob: slot = churn_definition candidates = { canceled_subscription, inactive_account, revenue_loss, no_recent_purchase } ambiguity trigger = "churn" Probe policy: - Create 8–9 clarification probes total - Exactly 3 probes grounded in implementation diff - Remaining probes grounded in taxonomy Constraints: - Treat implementation diff as ambiguity hypotheses only - Do not patch directly from diff - Patch only using probe evidence Execution policy: - Execute probes against the database - Use database results as grounding evidence Repair objective: - Apply minimal, probe-supported SQL changes - Preserve original semantics unless evidence supports change ```

### M\.3Ambiguity Probing Report

Probe 1: Canceled subscription interpretation``` SELECT COUNT(*) AS churned_customers FROM subscriptions s JOIN customers c ON s.customer_id = c.customer_id WHERE c.segment = ’enterprise’ AND s.status = ’canceled’ AND s.cancel_date >= date(’now’,’start of month’,’-3 month’) AND s.cancel_date < date(’now’,’start of month’); Result: [[4821]] ``` Probe 2: Inactive account interpretation``` SELECT COUNT(*) AS inactive_customers FROM customers c WHERE c.segment = ’enterprise’ AND c.last_activity_date < date(’now’,’start of month’,’-3 month’); Result: [[137]] ``` Probe 3: No recent purchase interpretation``` SELECT COUNT(DISTINCT c.customer_id) FROM customers c LEFT JOIN orders o ON c.customer_id = o.customer_id WHERE c.segment = ’enterprise’ GROUP BY c.customer_id HAVING MAX(o.order_date) < date(’now’,’start of month’,’-3 month’); Result: [[94]] ```

### M\.4Resolution

Resolved Ambiguity InterpretationResolved Interpretation“Churn” refers tocanceled subscriptions\.EvidenceCanceled subscriptions produce substantially stronger and temporally consistent signals compared to alternative interpretations\.Why Alternatives FailInactive\-account and no\-purchase interpretations yield sparse evidence and do not align with observed subscription behavior\.Decision RuleSelect the interpretation with the strongest database\-grounded evidence\.Repair ActionApply filtering on subscription cancellation status and cancellation timestamps\.

### M\.5Final Repaired SQL

``` SELECT COUNT(DISTINCT s.customer_id) AS churned_enterprise_customers FROM subscriptions s JOIN customers c ON s.customer_id = c.customer_id WHERE c.segment = ’enterprise’ AND s.status = ’canceled’ AND s.cancel_date >= date(’now’,’start of month’,’-3 month’) AND s.cancel_date < date(’now’,’start of month’); ```