Paper deep dive
ACTS-SQL: Agentic and Critic-Oriented Tree-Structured SQL Correctness with Large Language Models
Xinmei Huang, Jie Song, Peng Li, Fuxin Jiang, Jing Zhang, Tieying Zhang, Jianjun Chen, Chenming Liu, Tao Yang, Maoyin Liu, Wenda Li, Hong Chen, Cuiping Li
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 8/18/2026, 5:46:27 AM
Summary
The paper introduces ACTS-SQL, a training-free framework for SQL correction that uses a plan-guided, tree-structured debugging process with large language models. Unlike linear agentic approaches, ACTS-SQL employs branching and backtracking to mitigate error accumulation and semantic drift. It integrates execution-based verification and clause-level diagnostic tools to improve accuracy, achieving state-of-the-art results on the BIRD-Critic benchmark and significant improvements in a real-world industrial deployment (Volcano Engine's Torch Log Service).
Entities (10)
Relation Signals (9)
ACTS-SQL â deployedin â Torch Log Service
confidence 95% ¡ The framework is also deployed in the Torch Log Service (TLS) of Volcano Engine
ACTS-SQL â includestool â Detect Ambiguities
confidence 95% ¡ we introduce a Detect Ambiguities tool that explicitly analyzes underspecified user intents
ACTS-SQL â includestool â Split and Fix Syntax Error SQL
confidence 95% ¡ we introduce a Split and Fix Syntax Error SQL tool that decomposes erroneous queries
ACTS-SQL â includestool â Run SQL
confidence 95% ¡ we equip the framework with database-interaction tools, including Run SQL for execution-based validation
ACTS-SQL â mitigates â Error Accumulation
confidence 95% ¡ By maintaining multiple correction strategies and enabling backtracking, the framework mitigates error accumulation
ACTS-SQL â uses â tree-structured debugging
confidence 95% ¡ formulates SQL correction as a plan-guided, tree-structured debugging process.
ACTS-SQL â improvesaccuracyof â GPT-5
confidence 90% ¡ improves execution accuracy from 36.77% to 53.61% on real user queries with a representative strong LLM backbone (GPT-5).
ACTS-SQL â outperforms â previous state-of-the-art method
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Large Language Models (LLMs) have been increasingly adopted in Text-to-SQL systems, yet SQL errors remain a major obstacle in real-world Text-to-SQL inference pipelines. Existing SQL correction approaches either rely on large-scale, high-quality training data with substantial overhead, or adopt single-path agentic workflows that are brittle to early mistakes and prone to error propagation. To develop a practical SQL correctness system for industrial scenarios, we present a training-free framework that formulates SQL correction as a plan-guided, tree-structured debugging process. By maintaining multiple correction strategies and enabling backtracking, the framework mitigates error accumulation during iterative refinement. We further integrate execution-based verification and clause-level diagnostic tools to support strategy pruning and precise error localization. We evaluate the system on the BIRD-Critic benchmark and observe consistent accuracy gains over strong LLM backbones and representative agent-based baselines, achieving a 9.42% improvement over the previous state-of-the-art method. The framework is also deployed in the Torch Log Service (TLS) of Volcano Engine to support an online Text-to-TLS API. In production, it improves execution accuracy from 36.77% to 53.61% on real user queries with a representative strong LLM backbone (GPT-5). These results demonstrate the effectiveness and stability of our approach in real-world deployments.
Tags
Links
- Source: https://arxiv.org/abs/2608.15145v1
- Canonical: https://arxiv.org/abs/2608.15145v1
Trouble viewing inline? Open PDF directly â
Full Text
75,111 characters extracted from source content.
Expand or collapse full text
ACTS-SQL: Agentic and Critic-Oriented Tree-Structured SQL Correctness with Large Language Models Xinmei Huang Affiliation: Renmin University of China email: huangxinmei@ruc.edu.cn , Jie Song Affiliation: ByteDance Inc. email: jie.song@bytedance.com , Peng Li Affiliation: ByteDance Inc. email: peng.li01@bytedance.com , Fuxin Jiang Affiliation: ByteDance Inc. email: jiangfuxin@bytedance.com , Jing Zhang Affiliation: Renmin University of China email: zhang-jing@ruc.edu.cn , Tieying Zhang Affiliation: ByteDance Inc. email: tieying.zhang@bytedance.com , Jianjun Chen Affiliation: ByteDance Inc. email: jianjun.chen@bytedance.com , Chenming Liu Affiliation: ByteDance Inc. email: liuchenming.123@bytedance.com , Tao Yang Affiliation: ByteDance Inc. email: yangtao.alan@bytedance.com , Maoyin Liu Affiliation: ByteDance Inc. email: liumaoyin@bytedance.com , Wenda Li Affiliation: ByteDance Inc. email: liwenda.wonder@bytedance.com , Hong Chen Affiliation: Renmin University of China email: chong@ruc.edu.cn and Cuiping Li Affiliation: Renmin University of China email: licuiping@ruc.edu.cn Abstract. Large Language Models (LLMs) have been increasingly adopted in Text-to-SQL systems, yet SQL errors remain a major obstacle in real-world Text-to-SQL inference pipelines. Existing SQL correction approaches either rely on large-scale, high-quality training data with substantial overhead, or adopt single-path agentic workflows that are brittle to early mistakes and prone to error propagation. To develop a practical SQL correctness system for industrial scenarios, we present a training-free framework that formulates SQL correction as a plan-guided, tree-structured debugging process. By maintaining multiple correction strategies and enabling backtracking, the framework mitigates error accumulation during iterative refinement. We further integrate execution-based verification and clause-level diagnostic tools to support strategy pruning and precise error localization. We evaluate the system on the BIRD-Critic benchmark and observe consistent accuracy gains over strong LLM backbones and representative agent-based baselines, achieving a 9.42% improvement over the previous state-of-the-art method. The framework is also deployed in the Torch Log Service (TLS) of Volcano Engine to support an online Text-to-TLS API. In production, it improves execution accuracy from 36.77% to 53.61% on real user queries with a representative strong LLM backbone (GPT-5). These results demonstrate the effectiveness and stability of our approach in real-world deployments. â authors: . PVLDB Reference Format: PVLDB, 14(1): X-X, 2020. doi:X.X/X.X â This work is licensed under the Creative Commons BY-NC-ND 4.0 International License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of this license. For any use beyond those covered by this license, obtain permission by emailing info@vldb.org. Copyright is held by the owner/author(s). Publication rights licensed to the VLDB Endowment. Proceedings of the VLDB Endowment, Vol. 14, No. 1 ISSN 2150-8097. doi:X.X/X.X PVLDB Artifact Availability: The source code, data, and/or other artifacts have been made available at URL_TO_YOUR_ARTIFACTS. Figure 1. A failure mode of linear SQL correction, illustrating how early implicit assumptions and error accumulation lead to semantic drift, causing the final query to deviate from the userâs intent. 1. Introduction Relational databases underpin modern data-driven applications, with SQL serving as the primary interface for querying structured data. However, writing correct SQL remains difficult even for experienced users. Beyond syntactic proficiency, it requires precise reasoning over complex schemas, join relationships, aggregation semantics, and predicate logic. In large real-world databases, minor mistakesâsuch as incorrect join conditions or misplaced filtersâcan silently produce logically incorrect results. Large Language Models (LLMs) have substantially advanced Text-to-SQL systems, significantly reducing the burden of manual query writing. However, generating correct SQL in a single pass remains challenging. Even strong base and fine-tuned models frequently produce syntax errors, incorrect join paths, aggregation mismatches, and other semantic inconsistencies. For example, on the Text-to-SQL benchmark Spider2.0 (19), a strong base model such as Claude-4 (4) achieves only 25.78% accuracy. In industrial products, such as Torch Log Service (TLS) on Volcano Engine, where databases are highly heterogeneous and customized SQL dialects are common, such errors occur even more frequently. These challenges highlight the necessity of SQL correction beyond one-pass generation. Recent agentic approaches attempt to address this issue by incorporating multi-round interaction and execution-guided correction into the inference process 40; 20. However, the correction module in these approaches typically rely on execution-guided refinement or agent-style self-debugging, but often follow single-path reasoning and are vulnerable to early errors or limited generalization. As a result, achieving reliable and scalable SQL issue resolution remains an open problem. Real-World Deployment: Applications & Constraints. With the growing adoption of large language models (LLMs) for Text-to-SQL 22; 20; 13, SQL correctness has become critical module in real-world pipelines of Text-to-SQL applications based on LLMs. In industrial LLM-based Text-to-SQL systems in ByteDance, automated SQL correction is critical in two stages. During training, large-scale datasets are frequently synthesized or augmented using LLM-generated SQL, where uncorrected errors directly degrade data quality. During inference, correcting imperfect SQL outputs before returning to users substantially improves the reliability and usability of online Text-to-SQL APIs. Therefore, effective SQL correction is essential for both training data quality and end-to-end system performance. Additionally, although training on large-scale in-domain data can significantly enhance LLM performance in specific domains 22; 21, such approaches face challenges in real-world SQL correctness systems. First, collecting high-quality supervision for SQL correctness is costly and time-consuming, as it requires realistic user intents, diverse database schemas, and verified ground-truth SQL queries. Second, real-world deployments typically involve multiple SQL dialects, whereas models fine-tuned on limited dialects often exhibit degraded generalization when transferred to unseen ones. For example, we observe that the Xiyan model (28), trained on the maintain dialect such as MySQL, PostgreSQL and so on, achieves 13.40% accuracy on our real-world Torch Log Service (TLS) benchmark, while the corresponding base model without additional fine-tuning (GPT-5 (9)) attains 36.77%. These limitations substantially hinder the scalability and practicality of training-based solutions, motivating the need for a training-free SQL correctness framework that can robustly adapt to diverse SQL environments. Limitations of Existing Methods. Recent training-free SQL correction methods commonly adopt agent-based workflows, where LLMs iteratively refine SQL queries based on execution feedback 35; 40; 2; 15; 8; 43. In this line of work, the correction process typically follows a linear refinement paradigm, in which the agent revises a single SQL candidate step by step, guided by runtime errors or execution results. However, this paradigm inherently constrains the agent to a single correction trajectory. As a consequence, the overall process becomes fragile, as it heavily depends on early decisions, and unreliable, since errors introduced at early stages tend to accumulate and persist throughout subsequent iterations. We illustrate the intrinsic limitations of linear refinement through the following example. Example. Figure 1 presents a representative failure mode of linear, single-path SQL correction. The task is to extract a numeric quantity and classify product types from textual descriptions following an âMĂNMĂ Nâ pattern, where M denotes a number and N denotes a product type string. Notably, the user intent only requires identifying products whose descriptions contain the keyword âElectronicsâ, rather than enforcing an exact or canonicalized match (see the correct SQL in the figure). This illustrates the limitations of linear refinement: (1) Fragility caused by early implicit assumptions. In the first correction step, the model implicitly assumes that identifying âElectronicsâ requires an exact string match. Once this assumption is adopted, all subsequent revisions operate within the same restricted hypothesis space, focusing on refining string normalization and matching strictness without reconsidering whether exact equality is semantically appropriate. As a result, alternative plausible interpretationsâsuch as substring containmentâare never explored. This example shows that linear refinement is highly sensitive to early assumptions: a single misinterpretation can dominate the entire correction process. Thus, the linear refinement process could be fragile due to the sensitivity of such implicit assumptions. (2) Unreliability due to error accumulation and irreversibility. As illustrated by this example, the model progressively introduces increasingly restrictive constraints, such as string normalization (lowercasing and trimming) and regex-based exact matching. These modifications are cumulatively applied to the SQL query, causing the revised query to deviate substantially from its original structure and intent. In SQL tasks, seemingly local changesâsuch as adding a filtering condition or tightening a predicateâoften have global semantic implications, since they directly affect the result set produced by query execution. When such clause-level modifications are repeatedly layered on top of the SQL query being modified, the compounded effect can cause the final query to drift significantly away from the userâs true intent and initial SQL query. As a result, linear, iterative correction processes are highly susceptible to error accumulation and semantic drift, which fundamentally undermines their reliability for SQL debugging. Our Proposal. The limitations discussed above highlight a fundamental requirement for SQL correction: once semantic deviations are introduced, the system must be able to revert to earlier steps, rather than continuing refinement along a single irreversible path. To meet this requirement, we adopt tree-based reasoning as an alternative to linear SQL refinement. Specifically, we formulate SQL correction as a tree-structured debugging process, where different critic strategies and semantic hypotheses are explicitly modeled as separate branches, and earlier modification nodes can be revisited when errors are detected. This formulation mitigates both the fragility caused by early assumptions and the unreliability arising from error accumulation in linear refinement. Such a tree-structured process relies on two key mechanisms. (1) Branching preserves alternative correction strategies when multiple revision plans are plausible, for example under ambiguous user intent or underspecified natural language queries. (2) Backtracking enables the system to discard erroneous paths once inconsistencies are identified, instead of propagating their effects forward through the entire correction trajectory. Effectively realizing these mechanisms places higher demands on the modelâs reasoning and verification capabilities. In particular, tree-based SQL debugging requires the LLM to support the following capabilities. Capability (i) Proposing multiple candidate correction paths, which is essential for branching, as the quality and diversity of proposed alternatives directly determine whether the correct solution space is preserved. This includes recognizing potential ambiguities in user intent and enumerating reasonable interpretations instead of committing to a single implicit assumption. Capability (i) Accurately assessing SQL correctness is critical for backtracking, since identifying semantic mismatches and determining when a branch should be abandoned form the core of recovering from erroneous paths. Notably, syntactically valid SQL may still fail to satisfy user intent, making execution success alone insufficient for reliable validation. Capability (i) Rapidly recovering from syntactic errors while preserving semantic consistency ensures that tree exploration can proceed without being stalled by non-executable intermediate queries. Efficient syntactic repair allows the framework to resume semantic verification and branching decisions promptly, thereby maintaining the effectiveness of both branching and backtracking. To enable tree-structured SQL debugging, we propose Agentic and Critic-Oriented Tree-Structured SQL Correctness (ACTS-SQL ), a framework that organizes SQL correction as a plan-guided execution process and provides a set of specialized tools to support efficient and robust debugging. Given a user query and a faulty SQL, the LLM first generates a revision plan that decomposes the correction process into a sequence of tool invocations. This plan is structured as a tree, where each node corresponds to a specific diagnostic or correction operation, and branching points are introduced whenever multiple plausible interpretations or revision strategies arise. Serving as a high-level blueprint, the tree-structured plan enables systematic exploration of alternative hypotheses and controlled rollback when semantic deviations are detected. The tree-based formulation naturally supports the LLM in proposing multiple candidate correction paths. To further enhance this capability (Capability (i)), we introduce a Detect Ambiguities tool that explicitly analyzes underspecified user intents and enumerates multiple plausible semantic hypotheses as branches of the tree. In addition, accurately assessing SQL correctness (Capability (i)) requires grounding validation in concrete database instances rather than relying solely on LLM reasoning. In SQL tasks, the correctness of joins, filters, and aggregation strategies often depend on data distributions or formats. To address this, we equip the framework with database-interaction tools, including Run SQL for execution-based validation and schema-aware inspection operators such as Inspect Columns. Finally, to enable rapid recovery from syntactic failures (Capability (i)), we introduce a Split and Fix Syntax Error SQL tool that decomposes erroneous queries into clause-level components and precisely localizes syntax errors. By repairing syntax errors at the clause level instead of regenerating the entire query, the framework restores executability with minimal disruption to previously validated semantics. Evaluation & Application. We evaluate our framework on the BIRD-Critic benchmark, a comprehensive dataset covering multiple SQL dialects and diverse levels of query errors. Experimental results demonstrate that our method achieves state-of-the-art performance, surpassing the previous best system by 9.42%. Beyond public benchmarks, we further validate our approach on a real-world Text-to-TLS dataset collected from an industrial log analytics system in Volcano Engine. In production deployment within the Text2TLS pipeline, using a representative strong LLM backbone (GPT-5), our framework improves execution accuracy by 16.84 percentage points on real user queries under practical latency and cost constraints. Similar improvement trends are observed across other LLM backbones, indicating that the effectiveness of our framework generalizes beyond a specific model. These results demonstrate the robustness and deployability of our approach in real-world environments. Contributions. Our main contributions are summarized as follows: ⢠We introduce a revision-planâbased debugging paradigm that structures the SQL correction process into a hierarchical, decision-guided plan. This paradigm better aligns with human debugging behavior and significantly enhances interpretability and efficiency. ⢠We design an enriched operator space comprising specialized tool interfaces for ambiguity detection, sub-query decomposition, and schema inspection. These operators effectively assist LLMs in addressing both syntactic and semantic challenges frequently encountered in real-world SQL debugging. ⢠We conduct extensive experiments on the BIRD-Critic benchmark, demonstrating that our approach achieves state-of-the-art performance, outperforming the previous best fine-tuned model by 9.42%, thus validating the effectiveness of our framework. Moreover, when deployed in an industrial Text-to-TLS system with a representative strong LLM backbone (GPT-5), our framework improves execution accuracy from 36.77% to 53.61%, demonstrating the robustness and general applicability of our method in real-world settings. Figure 2. Overview of our framework. 2. Related Work 2.1. Text-to-SQL System Recent research has explored agentic reasoning and test-time scaling for Text-to-SQL systems. The recent survey (13) finds that both reasoning-specialized and general-purpose LLMs consistently benefit from test-time scaling strategies such as divide-and-conquer (41), few-shot prompting, and ReAct-style reasoning (45), leading to robust performance improvements across different model families. Several works, including LearNAT (24), MAG-SQL (44), MAC-SQL (39), and CoE-SQL (46), adopt a compositional reasoning paradigm in which each Common Table Expression (CTE) or subquery corresponds to an intermediate reasoning step. These approaches decompose SQL generation into hierarchical subgoals, improving interpretability and controllability. Although these approaches incorporate SQL refinement or revision modules, the refinement process itself typically follows a one-pass or linear trajectory. Alpha-SQL (20) also introduces a tree-structured framework, modeling schema linking, SQL generation, SQL revision and other sub-tasks as nodes in a hierarchical reasoning process. However, its tree structure primarily organizes generation stages rather than exploring alternative correction branches. In particular, its revision component refines SQL along a single trajectory. 2.2. SQL Revision SQL debugging approaches can be broadly categorized into static analysis and AI-based refinement. Traditional static toolsâsuch as UPM (30), Visual Expert (38), SQLFluff (37), and SQLCheck (7)âapply rule-based analysis on Abstract Syntax Trees (ASTs) to identify anti-patterns, type inconsistencies, and inefficient query structures. While these systems provide reliable diagnostics, they lack semantic awareness of user intent and cannot adaptively repair queries. In contrast, AI-based refinement methods leverage LLMs to iteratively inspect, execute, and modify SQL queries 6; 34; 3. SQLFixAgent (2) employs a ârubber-duck debuggingâ paradigm, generating perturbed query variants to explore diverse semantic hypotheses. CSC-SQL (35) improves candidate selection through collaborative training between a SQL generator and a merger guided by execution feedback. To enhance correction precision, recent studies introduce decomposition-based refinement: Tool-based decomposition. Tool-Assisted Agent (43) defines modular functions for modifying SQL clauses (e.g., JOIN, WHERE, GROUP) and provides validity feedback for each action; CoE-SQL (46) models AST editing as sequential reasoning steps; Qr-Hint (15) introduces actionable hints for error localization. Clause-based decomposition. SQLCritic (3) contrasts incorrectâcorrect clause pairs to train a critic model for clause-level quality assessment. Subtask-based decomposition. DAC (40) decomposes the overall refinement process into entity linking, skeleton parsing, and SQL validation, aligning task-specific feedback with the final correction. Despite these advances, most existing frameworks rely on linear refinement loops, which suffer from error propagation and limited exploration capability when debugging complex queries. 2.3. Code Revision The idea of iterative self-improvement has been widely studied in the code refinement domain. Systems such as PAG (18), CYCLE (5), LeDex (17), QualityFlow (14), AdaCoder (52), RefineCoder (50), and CodeCoR (33) employ cyclic refinement pipelines in which the model repeatedly executes, inspects, and revises generated code. These frameworks demonstrate the effectiveness of execution-guided feedback and self-reflective reasoning, but their repair trajectories remain single-threaded and prone to cumulative errors. To enhance controllability, several works incorporate external tool integration: RepairAgent (1), CodeAgent (47), and LANTERN (29) enable the LLM to decide when to invoke specialized repair or verification tools. Notably, MGDebugger (36) constructs a hierarchical debugging tree (syntax â function â algorithm) that progressively refines the program through structured iterations, while Divide & Conquer Revision (41) separates error localization from repair. However, when directly applied to SQL debugging, these frameworks face additional challenges: SQLâs symbolic compositionality and semantic dependencies (e.g., among SELECT, JOIN, and WHERE clauses) make single-path refinement unstable. This motivates our approach, which introduces an explicit revision plan to organize the debugging process into a tree-structured reasoning space, enabling multi-branch exploration, dynamic tool feedback integration, and interpretable refinement trajectories. âş 3. System Overview SQL correction in practical environments is challenging due to the tightly coupled structure of SQL queries, the complexity and variability of real-world database schemas, and the inherent ambiguity in user intent etc. Our framework addresses these challenges by structuring SQL correction as a revision-planâguided process and equipping the model with specialized operators for ambiguity detection, sub-query decomposition, and schema inspection etc. This design enables systematic debugging, improves correction reliability across diverse scenarios, and reduces the human effort required in both development workflows and Text-to-SQL production systems. 3.1. Workflow The system operates through a structured, plan-driven workflow which begins with the LLM first producing an initial revision plan according to the given user query and the faulty SQL. The plan can be described as a tree, each node of the tree specifies a tool invocation and potential branching paths depending on the toolâs return signals. This plan acts as a high-level blueprint that decomposes the debugging process into interpretable and actionable steps. After producing an initial plan, the system executes it by calling predefined tools and allowing the Central Agent to decide the next branch based on returned tool results. The plan can expand dynamically whenever a tool introduces new decision points. When a tool returns multiple candidate branchesâfor example, ambiguity hypotheses from the detect-ambiguities toolâthe controller selects the most credible one and continues execution along that path. Once a complete SQL candidate is generated, the Central Agent evaluates its correctness based on the histories and execution feedback. If it is incorrect, the system performs a bottom-up rollback to explore alternative paths. The process ends when the controller finds a correct SQL. 3.2. Components Our framework consists of two main componentsâCentral Agent and Tools, which including five main useful tools Detect Ambiguous, Inspect Columns, Run SQL, Split and Fix Syntax Error SQL and Generate SQL. These components collaboratively perform the SQL refinement task as follows: Central Agent . Central Agent serves as the âbrainâ of our framework. It is responsible for generating the initial revision plan, selecting the appropriate branch whenever the plan diverges, and evaluating the correctness of the produced SQL. The agent takes as input the user query, database schema, issue SQL, and relevant execution history, and outputs decisions that drive each stage of the correction process. Through these responsibilities, the Central Agent coordinates the entire system, ensuring that SQL refinement progresses coherently and converges toward a correct or high-confidence solution. Tools. Tools define the operator space of our framework, providing the actionable steps through which the Central Agent refines SQL. The tools include: LLM-based tools such as for usersâ intent interpretation, execution tools for running SQLs and returning feedback, and hybrid tools that combine reasoning with execution. Together, they provide the exploration space that enables iterative and reliable SQL correction. Detect Ambiguous(LLM-based tool). User queries often contain ambiguous expressions. For example, in the StackOverflow database, the term âactive usersâ could refer to users who post, users who answer, or pre-mine users. This tool takes the raw user query as input and uses an LLM to identify potentially ambiguous phrases, along with plausible interpretive assumptions for each. Inspect Columns(execution tool). Column values can guide SQL correction by revealing actual data patterns, which aids in crafting precise matching predicates. This tool provides an interface to retrieve sample values from specified database columns. Run SQL(execution tool). In practice, human data analysts often execute sub-SQLs to inspect intermediate query results or run simplified queries to validate SQL syntax. This tool provides flexibility by allowing the execution of any given SQL query and returning the corresponding execution result, supporting the debugging process by facilitating query validation. Split and Fix Syntax Error SQL(hybrid tool). To improve the efficiency of fixing syntax errors, this tool leverages the LLM to decompose error SQL into smaller, independent subqueries. These subqueries can then be executed in parallel, reducing the time spent on error identification and correction. The execution results, along with the subqueries, are subsequently fed back into the LLM for further refinement, ultimately returning a revised SQL query free from syntax errors. Generate SQL(hybrid tool). This tool appears as a leaf node in the tree-structured revision plan to output the final SQL. After reasoning by the Central Agent and the execution of intermediate tools, the accumulated history, along with the user query, original SQL, and database schema are provided to the LLM. The LLM generates the corrected SQL query and returns both the revised query and its execution result, completing the SQL correction process. Figure 3. An example of the tree-based SQL correction pro- cess. Starting from ambiguity detection, the system branches into alternative semantic interpretations of âoverlappingâ. The incorrect interpretation (total booking count) is pruned after semantic validation based on evidence obtained from the inspect_columns tool, triggering backtracking. The cor- rect branch (concurrent time overlap) proceeds through SQL generation and syntax repair, ultimately producing a validated query. Each node corresponds to a tool invocation, and branching, backtracking, and acceptance decisions are made by Central Agent based on execution feedback. 4. ACTS-SQL In this section, we introduce our plan-guided revision framework. We first detail how the system generates, expands, and executes the tree-structured revision plan. We then introduce the Central Agent , including its input prompt design and the outputs that orchestrate the overall correction process. 4.1. Plan Generation and Execution The non-linear debugging workflow in our framework is represented as a tree in which each node corresponds to a tool invocation and each edge denotes a potential follow-up action. The overall procedure is summarized in Algorithm 1. 4.1.1. Plan Generation Given the user issue, SQL dialect, database schema, problematic SQL query, and its execution result, the system first constructs an initial revision plan (line 1). This plan specifies the root diagnostic operation and enumerates major branches, each representing a distinct interpretation of the error or a plausible repair direction. The debugging process then starts from the root node (line 2). Input: User issue U, initial SQL S0S_0, database schema D Output: Corrected SQL SâS^* 1 TâGenerateInitialPlanâ(U,S0,D)Tâ GenerateInitialPlan(U,S_0,D) ; 2 nâT.rootnâ T.root ; 3 4 while True do 5 6 râeâsâuâlâtâExecuteâ(n)resultâ Execute(n) ; 7 8 if n.tool=detect_ambiguitiesn.tool= detect\_ambiguities then 9 nâExpandTreeâ(T,râeâsâuâlât)nâ ExpandTree(T,result) ; 10 end if 11 12 if |n.children|>1|n.children|>1 then 13 nâSelectNextNodeâ(râeâsâuâlât)nâ SelectNextNode(result) ; 14 continue ; 15 end if 16 17 if n.tool=generate_sqln.tool= generate\_sql then 18 if ValidSQL(result) then 19 return râeâsâuâlâtresult ; 20 end if 21 else 22 nâRollbackâ(T,n)nâ Rollback(T,n) ; 23 continue ; 24 end if 25 end if 26 27 if |n.children|=1|n.children|=1 then 28 nân.childrenâ[0]nâ n.children[0] ; 29 end if 30 end while 31 Algorithm 1 Tree-Structured SQL Debugging 4.1.2. Dynamic plan expansion When the current tool detects ambiguity in the userâs natural-language query, it expands the current node by generating additional child branches that represent alternative hypotheses (lines 5â7). Each child node corresponds to one such hypothesis, and Central Agent then selects the most plausible branch for continued reasoning, following the same decision mechanism described in the next subsection. 4.1.3. Choose Next Node to Execute During execution, the system iteratively selects the next node to traverse based on the outcomes of previously executed steps. When the current node contains multiple child nodes, Central Agent chooses the most promising one according to the intermediate results produced at that node (lines 8â11). This iterative cycle of traversal and selective expansion enables the system to adapt its reasoning path as additional evidence is gathered. 4.1.4. Terminal of the Execution Execution terminates when a leaf node yields a SQL candidate that satisfies the Central Agent âs validation checks. Once the generate_sql tool is invoked, a candidate SQL is produced and Central Agent evaluates its correctness (line 13). If the candidate passes validation, the debugging process terminates. Otherwise, Central Agent may backtrack to any node in the plan and continue the revision process. 4.2. Central Agent As the âbrainâ of our framework, Central Agent serves as the central agent responsible for generating and orchestrating the execution of the revision plan. Figure 3 illustrates an example of the overall workflow. Specifically, Central Agent generates the initial revision plan, selects branches at NâOâDâEâ 0NODE\ 0, and evaluates the SQL produced at NâOâDâEâ 2NODE\ 2, NâOâDâEâ 3NODE\ 3, and NâOâDâEâ 4NODE\ 4 to determine whether to continue, backtrack, or accept the result. To support these responsibilities, we design the prompt for Central Agent to include the following components to provide comprehensive information: ⢠Task Overview & Instruction. This section defines the agentâs core objectives and responsibilities, outlining high-level principles such as when to construct an initial plan, how to select subsequent nodes, and how to determine termination conditions. ⢠Available Tools. We provide detailed specifications for all tools accessible during debugging, including their purposes, recommended usage scenarios, and inputâoutput formats. This enables Central Agent to reason over a well-defined operator space when revising queries. ⢠Output Format. The Central Agent is responsible for three core tasks: (i) constructing the tree-structure revision plan, (i) selecting the next node to execute when branching occurs, and (i) determining whether the SQL candidate is correct upon reaching a leaf node. To unify these control actions, we formalize the entire process as operations over a JSON object. The initial plan generation corresponds to producing this JSON structure, whereas intermediate decisions correspond to updating it. Each plan nodeâcorresponding to a single tool invocationâis represented as a dictionary containing a unique node identifier, a short textual description, the tool name, the tool input, and a list of child nodes representing possible follow-up actions. To enable dynamic control flow, we introduce a global cursor field that marks the node currently being executed; Central Agent perform task (i) by updating this field to point to the next selected node. ⢠Input Information. Central Agent receives comprehensive contextual information to support accurate, stateful reasoning. This includes the SQL dialect, database schema, user-issued problem description, the problematic SQL, and its execution results. We also provide the complete interaction historyâthe current plan (in JSON form) and the outputs of previously executed nodes. Executed nodes are annotated with their corresponding execution results, and the cursor is updated accordingly to reflect the most recent execution event, ensuring coherent and context-aware reasoning throughout the revision process. 4.3. Details of Tools The tool set defines the actionable space through which Central Agent explores and refines the debugging trajectory. To address the limitations in resolving syntax and semantic error SQLs of existing methods mentioned in Section 1, we construct a tool space that accelerate syntax error SQL fixing and detect semantic mismatches. Specifically, tools such as Detect Ambiguities, Run SQL, and Inspect Column Format allow the agent to systematically probe the mismatch between user intent and SQL behavior, providing crucial signals for resolving semantic inconsistencies. Meanwhile, Split Syntax Error SQL decomposes faulty queries into clause-level substructures, enabling parallel validation and rapid localization of multiple syntax issues within a single iteration. This section presents the tools used in our framework. We first describe tools for detecting semantic ambiguity, followed by tools that execute or inspect SQL behavior. We then introduce tools designed for structural decomposition of syntax error SQL, and finally, the Generate SQL tool that generate corrected SQL candidates. 4.4. Detect Ambiguities The Detect Ambiguities tool is an LLM-based semantic diagnostic module that identifies unclear or underspecified phrases in the userâs natural-language request. Specifically, the prompt includes task description, an example and input information including database schema, user issue and wrong SQL. Thanks to that, the tool highlights ambiguous intent terms and provides 2â3 plausible schema-grounded interpretations for each. These interpretations become semantic branches in the debugging tree (e.g., NODE 0 in Figure 3), enabling the agent to explore and verify different meanings during later execution. By making implicit ambiguities explicit, this tool provides the foundation for resolving semantic errors that cannot be detected by SQL execution alone. 4.5. Execution Tools The execution tools allow Central Agent to directly interact with the database and obtain reliable behavioral feedback during debugging. They provide the signals needed to validate assumptions, evaluate intermediate hypotheses, and other that cannot be inferred from static SQL analysis. Run SQL. This tool executes any SQL statement proposed by Central Agent and returns the resulting tuples in list form. It enables the agent to test semantic assumptions, validate sub-queries, and check whether a candidate SQL behaves consistently with the intended logic and so on. Inspect Column Format. To support lightweight schema probing, this tool takes a table name and column name provided by Central Agent and fills them into a fixed query template (e.g., SELECT âcolumnâ FROM âtableâ). It then returns the sampled values in that column. This allows the agent to get data format without manually constructing full queries. 4.6. Split and Fix Syntax Error SQL The Split and Fix Syntax Error SQL tool is invoked when a syntactic error is detected in the generated SQL (e.g., NODE 4 in Figure 3). It decomposes a syntactically invalid SQL query into a set of minimal, independently executable sub-SQL units. We first prompt the LLM to rewrite the faulty query into primitive relational formsâsuch as table projection, table filtering, table join, or table aggregationâeach consisting of exactly one flat SELECT statement without nested structures. This decomposition preserves the original semantics while exposing an explicit dependency structure among the generated sub-SQLs. Since this tool focuses solely on syntax validation, we create empty temporary tables to enable parallel execution. For instance, if SQL B depends on SQL A, we create a temporary table named A whose schema matches the output columns of SQL A, allowing both statements to be executed independently for syntax checking. Importantly, the generated sub-SQL statements together with their execution results (e.g., syntax errors or validation signals) are fed back to the LLM as structured diagnostic feedback. Based on this fine-grained clause-level information, the LLM synthesizes a revised SQL statement that resolves the detected syntax errors while preserving the intended semantics. By isolating syntax violations at the clause level and exposing intermediate relational structures, this tool provides precise diagnostic signals that guide the subsequent correction process toward generating a syntactically valid final query. 4.7. Generate SQL The Generate SQL tool is invoked to produce a candidate corrected SQL query and typically serves as a leaf node in the correction tree (e.g., NODE 2 and NODE 4 in Figure 3). After generation, the SQL is automatically executed, and the SQL is evaluated by Central Agent to determine whether to accept the query or trigger further refinement (e.g., backtracking or syntax repair). To generate the repaired SQL, the LLM receives the full contextual stateâincluding the userâs intent description, the database schema, the problematic SQL, execution feedback, and diagnostic signals accumulated during earlier tool invocations from root to current nodeâand produces a revised SQL query that is both syntactically valid and semantically aligned with the userâs goal. In this tool, the LLM is instructed to minimally edit the original query, avoid speculative assumptions, and ground its modifications strictly in the provided evidence. This design ensures that the final output is a faithful, precise correction rather than an overly rewritten or hallucinated alternative. Once generated, the SQL candidate is executed to confirm correctness, completing the debugging workflow. 5. Experimental Evaluation We evaluate the proposed system through a comprehensive set of experiments designed to assess its effectiveness, robustness, and practicality. We first report benchmark results to quantify overall performance gains, followed by ablation studies to analyze the contribution of key components. We then present results on a real-world Text-to-SQL (TLS) benchmark to demonstrate performance under practical system constraints. In addition, we provide representative case studies to illustrate the systemâs correction behavior in complex scenarios, analyze runtime cost and latency characteristics, and finally discuss its application in a real-world production deployment. Table 1. Main results on the BIRD-CRITIC benchmark. Methods Bird-critic Open Bird-critic PG PostgreSQL MySQL SQLServer Oracle Raw model Deepseek-R1 (11) 36.96% 38.78% 32.65% 19.39% 39.62% GPT-o3 (32) 41.30% 26.53% 32.65% 18.37% 38.87% GPT-5 (9) 39.13% 28.57% 29.59% 23.71% 35.85% grok-4 (10) 39.49% 35.71% 33.67% 15.31% 39.06% Agents SQLFixAgent (2) 21.38% 22.79% 33.12% 17.68% 40.56% DAC (40) 19.00% 16.00% 18.00% 3.00% 31.32% RepairAgent (1) 34.94% 33.67% 34.20% 28.12% 35.27% MapleRepair (34) 44.20% 37.76% 39.79% 22.45% 37.74% Xiyan Model (28) 49.28% 45.92% 43.88% 28.57% 44.53% ACTS-SQL 58.70% 64.29% 53.06% 33.67% 45.85% 5.1. Evaluation on Benchmarks In this section, we evaluate ACTS-SQL on the public BIRD-CRITIC benchmark (23) and compare it with representative baselines to validate its effectiveness in SQL debugging. 5.1.1. Evaluation Settings We describe the benchmarks, baselines, and evaluation metrics used in this experiments below. Benchmark - BIRD-CRITIC. We evaluate ACTS-SQL on BIRD-CRITIC, a benchmark for SQL issue debugging built from real-world user-reported SQL errors (23). It contains a PostgreSQL subset (BIRD-CRITIC-PG) and a multi-dialect subset spanning four database dialects. The benchmark is highly challenging and targets systematic SQL debugging rather than SQL generation. We report results on both the PostgreSQL and the open multi-dialect subsets. Baselines. We compare our approach with representative baselines covering different SQL tasks. ⢠Raw Models. We evaluate several strong general-purpose LLMs as raw baselines, including GPT-o3 (32), GPT-5 (9), and DeepSeek-R1 (11). These models are prompted to directly perform SQL correction without any additional training or external tools. For all raw models, we use official inference APIs and adopt consistent decoding configurations, with temperature set to 0.1, top-p set to 0.95, and a maximum input length of 8K tokens. ⢠SQL Correction Agents. We include SQLFixAgent (2), a trained agent-based method that performs semantic mismatch diagnosis and candidate generation using a rubber-duck debugging strategy. We also evaluate two training-free SQL correction frameworks, DAC (40) and MapleRepair (34), which diagnose and repair SQL errors through sub-task comparison and rule-based symptom detection, respectively, with optional LLM-based regeneration. All these methods follow a predominantly linear refinement paradigm, where correction decisions are made sequentially without explicitly preserving alternative revision branches. ⢠Fine-tuned Text-to-SQL Models. We include XiYan-SQL, a strong fine-tuned Text-to-SQL model trained with multi-task objectives across diverse SQL formats and database dialects (28). XiYan-SQL has demonstrated state-of-the-art performance on standard Text-to-SQL benchmarks such as BIRD and Spider. For fair comparison, we adopt the same prompting protocol as used in the Bird-Critic leaderboard for evaluating raw models, and apply it consistently across the fine-tuned baselines. Table 2. Ablation study of ACTS-SQL on the BIRD-CRITIC benchmark. Variants Bird-critic Open Bird-critic PG PostgreSQL MySQL SQLServer Oracle Full Method ACTS-SQL (Full) 58.70% 64.29% 53.06% 33.67% 45.85% Plan Structure w/ Linear Plan 45.81% 36.93% 38.88% 20.47% 36.56% Tools w/o Execution Tool 39.84% 32.66% 29.85% 21.48% 37.92% w/o Ambiguity Detection 43.89% 27.37% 31.28% 25.67% 38.45% Implementation Details. All methods are evaluated under the same experimental settings. For agent-based approaches, we follow the official implementations and configurations released by the authors. Unless otherwise specified, large language models are used with deterministic decoding settings to reduce randomness during evaluation. SQL correctness is determined by execution-based evaluation, where a predicted SQL query is considered correct if it produces the same result as the ground-truth query under the target database. 5.1.2. Results on Benchmark We evaluate ACTS-SQL on the BIRD-CRITIC benchmark, which is specifically designed for SQL debugging and correction across multiple SQL dialects. Table 1 summarizes the results on both the BIRD-CRITIC-Open (multi-dialect) and BIRD-CRITIC-PG settings and we have the following findings: Compared with raw LLMs, ACTS-SQL consistently outperforms strong raw and reasoning-based LLMs on both BIRD-CRITIC-PG and the multi-dialect setting. We attribute this improvement to the fact that SQL debugging is inherently a structured program repair task, which requires precise error localization and iterative verification rather than one-shot generation. While powerful foundation models exhibit strong reasoning abilities, they typically perform implicit, end-to-end correction, making them brittle when facing complex or compositional SQL errors. In contrast, our approach externalizes the debugging process into a sequence of structured steps, allowing the model to explicitly test intermediate hypotheses through execution-based feedback and revise SQL in a controlled manner. These results suggest that better task structuring and feedback integration, rather than stronger base models alone, are crucial for effective SQL issue debugging. Compared with existing agent-based SQL correction methods, our approach achieves consistently better performance on BIRD-CRITIC. Although prior agents are also able to execute SQL and leverage execution feedback, they typically follow a linear refinement process. In practice, linear correction often commits to an early semantic assumption about the error. When this assumption is incorrect, subsequent edits tend to accumulate errors or repeatedly apply local fixes without addressing the root cause. ACTS-SQL avoids this issue by structuring SQL correction as a plan-guided process that allows alternative hypotheses to be explored and revised based on execution feedback. This design makes our agent more robust to misleading intermediate results and better suited for complex SQL debugging scenarios. Compared with a Text-to-SQL model fine-tuned on public SQLite-based datasets. While the fine-tuned model achieves strong performance on standard Text-to-SQL benchmarks, it shows limited effectiveness on BIRD-CRITIC, particularly in the multi-dialect setting. This suggests that fine-tuning on a single dialect and generation-oriented task does not readily transfer to SQL debugging scenarios involving diverse dialects and error patterns. In contrast, ACTS-SQL improves SQL correctness through a training-free, execution-guided correction process at inference time, making it less dependent on dialect-specific supervision. This results in more consistent performance across PostgreSQL, MySQL, SQL Server, and Oracle, demonstrating good transferability in practical multi-dialect environments. Overall, ACTS-SQL consistently outperforms strong base models, representative agent-based approaches, and a fine-tuned Text-to-SQL model on BIRD-CRITIC. The results indicate that structured, execution-guided correction is more effective than linear refinement or dialect-specific fine-tuning, and generalizes better across diverse SQL dialects. Table 3. Performance of different critic strategies on the TLS dataset. Accuracy (Acc., %, â ) measures exact-match correctness. Latency (Lat., seconds, â ) reports the average end-to-end runtime. Base Model Critic Strategy No Critic LLM Critic DAC (40) MapleRepair (34) ACTS-SQL Acc.â Lat.â Acc.â Lat.â Acc.â Lat.â Acc.â Lat.â Acc.â Lat.â GPT-5 (9) 36.77% 6.31 47.42% 26.52 37.74% 72.51 46.83% 15.51 53.61% 218.91 GPT-o3 (32) 40.55% 18.17 51.89% 35.40 40.55% 139.25 50.41% 17.49 56.36% 277.41 DeepSeek-R1 (11) 22.68% 6.04 22.96% 13.24 22.68% 96.04 22.68% 14.55 23.85% 38.65 Xiyan (28) 13.40% 7.01 13.40% 15.67 13.40% 76.54 13.40% 18.90 13.75% 42.56 5.2. Ablation Study We conduct ablation studies on both the BIRD-CRITIC Open and PG subsets to analyze the contribution of key components in our framework. By selectively removing or simplifying individual components, we examine how the planning structure and critical tools affect overall performance. 5.2.1. Ablation on Planning Structure We conduct an ablation study to examine the role of structured planning in our SQL critic framework. As the full method allows the model to generate a tree-structured refinement plan and supports branching and rollback during execution process of the plan, we introduce a linear variant that restricts the refinement process to a single sequential path. Specifically, the LLM is only allowed to calling tools and generating SQLs step-by-step in this variant. This design allows us to isolate the effect of tree-structured planning. Removing the tree-structured planning mechanism and constraining the refinement process to a linear, step-by-step correction results in a substantial performance drop on both BIRD-CRITIC Open and PG subsets (Table 2). This performance degradation highlights the importance of structured planning with branching and rollback in SQL correction. Without the ability to explore alternative refinement paths, the linear variant is forced to commit to a single correction hypothesis at each step. Once an incorrect intermediate decision is made, subsequent refinements are restricted to this flawed trajectory, leading to error accumulation or premature convergence to suboptimal corrections. In contrast, the tree-structured plan enables the model to defer commitment, recover from invalid intermediate decisions, and maintain robustness against early-stage mistakes. 5.2.2. Ablation on Key Tools We further perform ablation studies on the key tools integrated into our framework to evaluate their individual contributions during refinement. Specifically, we remove the SQL execution tool (including run SQL and inspect columns) and the user query ambiguity detection tool, respectively. These ablations aim to quantify the importance of execution-based feedback and ambiguity handling in guiding reliable SQL correction, with results summarized in Table 2. As shown in Table 2, removing either the SQL execution tool or the user query ambiguity detection tool consistently degrades performance on both the BIRD-CRITIC Open and PG subsets, confirming the importance of both execution-based feedback and explicit ambiguity handling for reliable SQL correction. In particular, removing the SQL execution tool results in a substantially larger performance drop. This suggests that execution feedback plays a critical role during refinement by providing an interface for the LLM to inspect data distributions or intermediate results. Without such an interface, the evidence available for branch selection and rollback becomes significantly weaker, preventing the tree-structured debugging process from fully exercising its advantages. In contrast, the ambiguity detection tool primarily affects early-stage user intent disambiguation. Its removal increases the likelihood that the refinement process proceeds along correction paths based on misinterpreted user intent, which in turn leads to degraded performance. 5.3. Evaluation on Real-world Data In this section, we evaluate ACTS-SQL on a real-world industrial dataset and compare it with representative baselines, aiming to assess its effectiveness and efficiency in practical deployment scenarios. 5.3.1. Evaluation Settings We describe the real-world dataset, task formulation, and evaluation criteria used in our experiments below. Real-world Dataset - TLS. We evaluate ACTS-SQL on a real-world Text-to-SQL dataset collected from an industrial log analytics service, referred to as TLS. TLS is a SQL-like domain-specific query language for large-scale log analysis, which differs substantially from mainstream SQL dialects such as PostgreSQL and SQLite11 1 TLS syntax documentation: https://w.volcengine.com/docs/6470/1335024?lang=zh, https://w.volcengine.com/docs/6470/73638?lang=zh. Due to its non-standard syntax and domain specificity, TLS is not covered by existing Text-to-SQL benchmarks and has limited publicly available training data. The dataset consists of real user-issued natural language queries and their corresponding ground-truth TLS queries executed in the production system. It spans 288 TLS topics (tables), with an average of 21.33 columns per table, reflecting substantial schema diversity. Unlike SQL correction benchmarks, the TLS dataset does not provide erroneous SQL as input; instead, each method must directly generate a TLS query from the user request, making this a pure Text-to-TLS generation task. Figure 4. Comparison between linear refinement and our tree-structured debugging on a representative SQL correction case. Linear refinement method iteratively applies local fixes under a fixed but incorrect semantic assumption, leading to repeated failure. ACTS-SQL branches on ambiguous interpretations, validates each branch independently, and backtracks from invalid paths, successfully correcting the SQL. Task Definition and Evaluation Criteria. Given a natural language user query, each method first generates an initial TLS query, which is then executed against the target log system. A prediction is considered correct if its execution result matches that of the ground-truth TLS query. When critic-based or agent-based methods are applied, they iteratively diagnose and refine the initially generated TLS query based on execution feedback, rather than correcting a pre-existing erroneous query. We report both the initial accuracy of the generated TLS queries and the final accuracy after refinement. In addition, we measure the end-to-end latency introduced by different critic modules, covering the complete refinement process, to assess their practical usability in real-world systems. Baselines. We evaluate multiple Text-to-TLS generation backbones, including strong general-purpose LLMs and fine-tuned Text-to-SQL/Text-to-TLS models. To study the impact of different correction strategies, we further equip these backbones with various critic mechanisms, including LLM-based critics and representative agent-based SQL correction methods. Notably, the agent-based baselines used in this setting are consistent with those evaluated on BIRD-CRITIC, allowing us to examine their effectiveness when transferred to a real-world Text-to-TLS scenario. This design enables a controlled comparison of different critic modules under the same generation and execution conditions. 5.3.2. Results on Real-world Data We further analyze the effectiveness of ACTS-SQL on the TLS dataset, which represents a real-world Text-to-TLS task collected from an industrial log analytics system. Experimental results are shown in table 3, we have the following findings: Effectiveness. ACTS-SQL consistently achieves the highest accuracy on the TLS dataset across all evaluated settings. Compared with the initial Text-to-TLS generation, the introduction of our critic mechanism leads to significant performance improvements, indicating that execution-aware refinement is highly effective in real-world scenarios. In addition, our approach outperforms existing LLM-based critics and agent-based baselines, demonstrating its stronger ability to identify and correct semantic and logical issues in generated TLS queries. These results confirm that ACTS-SQL can substantially enhance end-to-end Text-to-TLS performance on realistic user queries. Efficiency. We further report the runtime latency of different critic-based methods to assess their practical usability. Although our approach performs iterative refinement, its additional latency remains moderate and comparable to other agent-based baselines. Importantly, the observed performance gains are achieved without introducing prohibitive execution overhead, suggesting that ACTS-SQL strikes a favorable balance between effectiveness and efficiency. This makes it suitable for deployment in real production systems where both accuracy and response time are critical. Figure 5. Screenshot of the Text-to-TLS API interface and error TLS repair copilot in the production environment. Robustness. The effectiveness of ACTS-SQL is consistently observed across multiple LLM backbones, indicating that the proposed refinement mechanism does not rely on a specific model architecture or training condition. Moreover, ACTS-SQL remains effective in the pure Text-to-TLS setting, where queries are generated from scratch rather than corrected from pre-existing erroneous inputs. These results suggest that our approach is robust to both backbone variations and task settings, and can reliably improve generation quality in realistic scenarios where no explicit error signals are provided upfront. 5.3.3. Discussion The results on the TLS dataset indicate that our critic-based framework is both effective and practical for real-world Text-to-TLS systems, supporting its deployment in industrial pipelines. During training and data construction, LLM-generated queries are commonly used for dataset synthesis and augmentation, where uncorrected errors directly affect data quality. ACTS-SQL offers a training-free correction mechanism that consistently improves the correctness of generated queries across different backbones, making it suitable for automated data cleaning without additional annotation or fine-tuning costs. During online inference, imperfect query generation remains unavoidable even with strong LLMs. The observed accuracy gains and moderate latency overhead show that our critic can be integrated as a post-generation refinement module, improving system reliability while satisfying practical efficiency requirements. Moreover, its stable performance across multiple backbones suggests that it can function as a general-purpose correction layer, rather than being tied to a specific model. 5.4. Case Study We present a representative real-world case to illustrate how our tree-structured debugging framework resolves semantic ambiguities that systematically trap linear refinement-based agents. The user query asks for the top-3 products with the highest monthly sales in 2022 for each product category. While seemingly simple, the phrase âmonthly salesâ is underspecified and admits multiple plausible interpretations, making it a common failure mode for SQL correction systems. 5.4.1. Failure of Linear Refinement As shown in Figure 4 (left), the base model generates an initial SQL query that aggregates sales over the entire year 2022 and directly ranks products by the aggregated value. This reflects an implicit assumption that âmonthly salesâ can be derived from annual aggregation, without explicitly modeling month-level granularity. Linear refinement-based agents inherit this early semantic commitment. Although execution feedback indicates incorrect results, the agent never revisits the interpretation of âmonthly salesâ. Instead, it repeatedly applies local modificationsâsuch as changing aggregation functions, adjusting grouping keys, or relaxing temporal filtersâwhile preserving the same flawed assumption. Despite modifying different SQL components across iterations, all refinements remain constrained to the same annual-aggregation view. As a result, the agent repeatedly produces syntactically valid but semantically incorrect SQL and fails to recover after multiple execution-feedback cycles. 5.4.2. Tree-Structured Debugging with Backtracking In contrast, ACTS-SQL explicitly identifies âmonthly salesâ as an ambiguous semantic decision point and branches the debugging process accordingly, as shown in Figure 4 (right). The agent explores multiple alternative hypotheses in parallel. One branch follows the annual-aggregation interpretation adopted by linear methods, while another introduces explicit month-level aggregation before computing product-level statistics. Each branch is independently validated through SQL execution. When the annual-aggregation branch produces inconsistent results, the system backtracks to the ambiguity node and continues exploration along the alternative path. By validating and pruning semantic hypotheses early, the agent successfully converges to the correct interpretation and generates the correct SQL. This branching-and-backtracking mechanism enables recovery from erroneous early commitments that fundamentally limit linear refinement approaches. 5.5. Cost Analysis We analyze the runtime cost of ACTS-SQL on a real-world business benchmark, where we measure the number of LLM API calls, end-to-end latency, and token consumption. Our evaluation includes both reasoning and non-reasoning LLMs. For token accounting, we only report the visible output tokens returned by the API, excluding internal reasoning tokens that are not exposed to users, which ensures a consistent and practical measurement across different model types. Overall, ACTS-SQL invokes the LLM API 4.97 times per instance on average, with a mean visible token consumption of 8,984.5 tokens (measured with GPT-o3). The API calls mainly arise from the central agentâs decision-making steps, LLM-based tools such as user query ambiguity detection, and iterative SQL generation during refinement. Despite the use of multiple tools, the total number of interaction rounds remains moderate, reflecting a compact workflow design. In terms of latency, the average end-to-end runtime is around 3 minutes when using non-reasoning models such as GPT-5, and increases to approximately 4â5 minutes with reasoning models such as GPT-o3. This latency difference is primarily attributed to the model-side inference time of reasoning models, rather than additional API calls or tool interactions introduced by our framework. SQL execution and validation also contribute to the overall runtime but account for a relatively small portion compared to LLM inference. These results indicate that the higher latency observed with reasoning models is largely a property of the models themselves, while our workflow does not introduce substantial additional overhead. 5.6. Application ACTS-SQL has been integrated into the Text2TLS interface of Volcengine Log Service and is currently deployed in production to support real-world log analysis queries. In particular, the TLS repair capability shown in Figure 5 incorporates our proposed tree-structured debugging framework to automatically correct erroneous TLS queries during execution. Its online effectiveness is reflected by the results on the Text2TLS benchmark reported in Section 5.3. 6. Conclusion In this paper, we present a training-free SQL correction framework that formulates debugging as a tree-structured, plan-guided process, enabling systematic exploration of alternative repair strategies and recovery from incorrect decisions. By integrating lightweight diagnostic tools for ambiguity analysis, execution feedback, and clause-level validation, our approach improves the reliability of SQL correction without requiring additional supervision or model fine-tuning. We evaluate our method on the public BIRD-Critic benchmark and observe state-of-the-art performance across multiple SQL dialects. Beyond offline benchmarks, we deploy the framework in a real-world industrial Text-to-SQL pipeline, where it significantly improves end-to-end execution accuracy with practical latency and cost. The results demonstrate that our approach is robust across different LLM backbones and suitable for production use, supporting both online SQL generation and large-scale training data curation. Overall, this work shows that structured, plan-based SQL correction provides an effective and deployable solution for improving SQL correctness in real-world LLM-based systems. References Bouzenia et al. (2025) I. Bouzenia, P. Devanbu, and M. Pradel Repairagent: an autonomous, llm-based agent for program repair. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), p. 2188â2200. Cited by: §2.3, Table 1. Cen et al. (2025) J. Cen, J. Liu, Z. Li, and J. Wang Sqlfixagent: towards semantic-accurate text-to-sql parsing via consistency-enhanced multi-agent collaboration. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 39, p. 49â57. Cited by: §1, §2.2, 2nd item, Table 1. Chen et al. (2025) J. Chen, L. Gan, Z. Zhao, Z. Wang, D. Wang, and C. Zhuang SQLCritic: correcting text-to-sql generation via clause-wise critic. arXiv preprint arXiv:2503.07996. Cited by: §2.2, §2.2. [4] (2026) Claude 4: your intelligent conversational ai. Note: https://claude4.net/Accessed: 2026-02-27 Cited by: §1. Ding et al. (2024) Y. Ding, M. J. Min, G. Kaiser, and B. Ray Cycle: learning to self-refine the code generation. Proceedings of the ACM on Programming Languages 8 (OOPSLA1), p. 392â418. Cited by: §2.3. Ding et al. (2025) Z. Ding, Y. Lin, and T. Zeng Ambisql: interactive ambiguity detection and resolution for text-to-sql. arXiv preprint arXiv:2508.15276. Cited by: §2.2. Dintyala et al. (2020) P. Dintyala, A. Narechania, and J. Arulraj SQLCheck: automated detection and diagnosis of sql anti-patterns. In Proceedings of the 2020 ACM SIGMOD international conference on management of data, p. 2331â2345. Cited by: §2.2. Gong et al. (2025) Y. Gong, C. Lei, X. Qin, K. Vaidya, B. Narayanaswamy, and T. Kraska SQLENS: an end-to-end framework for error detection and correction in text-to-sql. arXiv preprint arXiv:2506.04494. Cited by: §1. [9] (2025) GPT-5 official release. OpenAI. Note: https://openai.com/zh-Hans-CN/gpt-5/Accessed: 2026-02-27 Cited by: §1, 1st item, Table 1, Table 3. [10] (2025) Grok 4: the most intelligent ai model from xai. xAI. Note: https://x.ai/news/grok-4Accessed: 2026-02-27 Cited by: Table 1. Guo et al. (2025a) D. Guo, D. Yang, H. Zhang, J. Song, P. Wang, Q. Zhu, R. Xu, R. Zhang, S. Ma, X. Bi, et al. Deepseek-r1: incentivizing reasoning capability in llms via reinforcement learning. arXiv preprint arXiv:2501.12948. Cited by: 1st item, Table 1, Table 3. Guo et al. (2024) D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y. Wu, Y. Li, et al. DeepSeek-coder: when the large language model meets programmingâthe rise of code intelligence. arXiv preprint arXiv:2401.14196. Guo et al. (2025b) J. Guo, K. Patel, J. P. Ono, W. He, and L. Ren Rethinking agentic workflows: evaluating inference-based test-time scaling strategies in text2sql tasks. arXiv preprint arXiv:2510.10885. Cited by: §1, §2.1. Hu et al. (2025) Y. Hu, Q. Zhou, Q. Chen, X. Li, L. Liu, D. Zhang, A. Kachroo, T. Oz, and O. Tripp Qualityflow: an agentic workflow for program synthesis controlled by llm quality checks. arXiv preprint arXiv:2501.17167. Cited by: §2.3. Hu et al. (2024) Y. Hu, A. Gilad, K. Stephens-Martinez, S. Roy, and J. Yang Qr-hint: actionable hints towards correcting wrong sql queries. Proceedings of the ACM on Management of Data 2 (3), p. 1â27. Cited by: §1, §2.2. Huang et al. (2024) X. Huang, H. Li, J. Zhang, X. Zhao, Z. Yao, Y. Li, T. Zhang, J. Chen, H. Chen, and C. Li E2etune: end-to-end knob tuning via fine-tuned generative language model. arXiv preprint arXiv:2404.11581. Jiang et al. (2024) N. Jiang, X. Li, S. Wang, Q. Zhou, S. B. Hossain, B. Ray, V. Kumar, X. Ma, and A. Deoras Ledex: training llms to better self-debug and explain code. Advances in Neural Information Processing Systems 37, p. 35517â35543. Cited by: §2.3. Jiang et al. (2025) Y. Jiang, Y. Xiong, Y. Yuan, C. Xin, W. Xu, Y. Yue, Q. Zhao, and L. Yan Pag: multi-turn reinforced llm self-correction with policy as generative verifier. arXiv preprint arXiv:2506.10406. Cited by: §2.3. Lei et al. (2024) F. Lei, J. Chen, Y. Ye, R. Cao, D. Shin, H. Su, Z. Suo, H. Gao, W. Hu, P. Yin, et al. Spider 2.0: evaluating language models on real-world enterprise text-to-sql workflows. arXiv preprint arXiv:2411.07763. Cited by: §1. Li et al. (2025a) B. Li, J. Zhang, J. Fan, Y. Xu, C. Chen, N. Tang, and Y. Luo Alpha-sql: zero-shot text-to-sql using monte carlo tree search. arXiv preprint arXiv:2502.17248. Cited by: §1, §1, §2.1. Li et al. (2025b) H. Li, S. Wu, X. Zhang, X. Huang, J. Zhang, F. Jiang, S. Wang, T. Zhang, J. Chen, R. Shi, et al. Omnisql: synthesizing high-quality text-to-sql data at scale. arXiv preprint arXiv:2503.02240. Cited by: §1. Li et al. (2024) H. Li, J. Zhang, H. Liu, J. Fan, X. Zhang, J. Zhu, R. Wei, H. Pan, C. Li, and H. Chen Codes: towards building open-source language models for text-to-sql. Proceedings of the ACM on Management of Data 2 (3), p. 1â28. Cited by: §1, §1. Li et al. (2025c) J. Li, X. Li, G. Qu, P. Jacobsson, B. Qin, B. Hui, S. Si, N. Huo, X. Xu, Y. Zhang, et al. Swe-sql: illuminating llm pathways to solve user sql issues in real-world applications. arXiv preprint arXiv:2506.18951. Cited by: §5.1.1, §5.1. Liao et al. (2025) W. Liao, X. Gao, T. Jia, R. Qiu, Y. Zhu, Y. Lin, X. Chu, J. Zhao, and Y. Wang LearNAT: learning nl2sql with ast-guided task decomposition for large language models. arXiv preprint arXiv:2504.02327. Cited by: §2.1. Liu et al. (2024) A. Liu, B. Feng, B. Xue, B. Wang, B. Wu, C. Lu, C. Zhao, C. Deng, C. Zhang, C. Ruan, et al. Deepseek-v3 technical report. arXiv preprint arXiv:2412.19437. Liu et al. (2025a) X. Liu, S. Shen, B. Li, P. Ma, R. Jiang, Y. Zhang, J. Fan, G. Li, N. Tang, and Y. Luo A survey of text-to-sql in the era of llms: where are we, and where are we going?. IEEE Transactions on Knowledge and Data Engineering. Liu et al. (2025b) X. Liu, S. Shen, B. Li, N. Tang, and Y. Luo Nl2sql-bugs: a benchmark for detecting semantic errors in nl2sql translation. In Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V. 2, p. 5662â5673. Liu et al. (2026) Y. Liu, Y. Zhu, Y. Gao, Z. Luo, X. Li, X. Shi, Y. Hong, J. Gao, Y. Li, B. Ding, et al. Xiyan-sql: a novel multi-generator framework for text-to-sql. IEEE Transactions on Knowledge and Data Engineering. Cited by: §1, 3rd item, Table 1, Table 3. Luo et al. (2025) W. Luo, J. W. Keung, B. Yang, J. Klein, T. F. Bissyande, H. Tian, and B. Le Unlocking llm repair capabilities through cross-language translation and multi-agent refinement. arXiv preprint arXiv:2503.22512. Cited by: §2.3. Ohayon (2022) D. Ohayon Enabling static analysis of sql queries at meta. Meta Engineering. Note: https://engineering.fb.com/2022/11/30/data-infrastructure/static-analysis-sql-queries/Accessed: 2026-02-27 Cited by: §2.2. OpenAI (2024) OpenAI Introducing openai o1: a new series of reasoning models. Note: https://openai.com/zh-Hans-CN/o1/Accessed: 2026-02-27 OpenAI (2025) OpenAI Introducing openai o3 and o4âmini: advanced reasoning models. Note: https://openai.com/zh-Hans-CN/index/introducing-o3-and-o4-mini/Accessed: 2026-02-27 Cited by: 1st item, Table 1, Table 3. Pan et al. (2025) R. Pan, H. Zhang, and C. Liu Codecor: an llm-based self-reflective multi-agent framework for code generation. arXiv preprint arXiv:2501.07811. Cited by: §2.3. Shen et al. (2025) J. Shen, C. Wan, R. Qiao, J. Zou, H. Xu, Y. Shao, Y. Zhang, W. Miao, and G. Pu A study of in-context-learning-based text-to-sql errors. arXiv preprint arXiv:2501.09310. Cited by: §2.2, 2nd item, Table 1, Table 3. Sheng and Shuai (2025) L. Sheng and X. S. Shuai Csc-sql: corrective self-consistency in text-to-sql via reinforcement learning. In Proceedings of the 14th International Joint Conference on Natural Language Processing and the 4th Conference of the Asia-Pacific Chapter of the Association for Computational Linguistics, p. 1473â1496. Cited by: §1, §2.2. Shi et al. (2024) Y. Shi, S. Wang, C. Wan, M. Wang, and X. Gu From code to correctness: closing the last mile of code generation with hierarchical debugging. arXiv preprint arXiv:2410.01215. Cited by: §2.3. [37] (2026) SQLFluff: the sql linter for humans. Note: https://w.sqlfluff.com/Accessed: 2026-02-27 Cited by: §2.2. [38] (2026) Static analysis and impact analysis of pl/sql code with visual expert. Visual Expert. Note: https://w.visual-expert.com/EN/stored-procedure-pl-sql-oracle-plsql/code-function-analysis-impact-source_wpve.htmlAccessed: 2026-02-27 Cited by: §2.2. Wang et al. (2025a) B. Wang, C. Ren, J. Yang, X. Liang, J. Bai, L. Chai, Z. Yan, Q. Zhang, D. Yin, X. Sun, et al. Mac-sql: a multi-agent collaborative framework for text-to-sql. In Proceedings of the 31st International Conference on Computational Linguistics, p. 540â557. Cited by: §2.1. Wang et al. (2024a) D. Wang, L. Dou, X. Zhang, Q. Zhu, and W. Che DAC: decomposed automation correction for text-to-sql. arXiv preprint arXiv:2408.08779. Cited by: §1, §1, §2.2, 2nd item, Table 1, Table 3. Wang et al. (2025b) S. Wang, B. Lin, L. Chen, and X. Mao Divide-and-conquer: automating code revisions via localization-and-revision. ACM Transactions on Software Engineering and Methodology 34 (3), p. 1â26. Cited by: §2.1, §2.3. Wang et al. (2020) Y. Wang, Q. Yao, J. T. Kwok, and L. M. Ni Generalizing from a few examples: a survey on few-shot learning. ACM computing surveys (csur) 53 (3), p. 1â34. Wang et al. (2024b) Z. Wang, R. Zhang, Z. Nie, and J. Kim Tool-assisted agent on sql inspection and refinement in real-world scenarios. arXiv preprint arXiv:2408.16991. Cited by: §1, §2.2. Xie et al. (2024) W. Xie, G. Wu, and B. Zhou Mag-sql: multi-agent generative approach with soft schema linking and iterative sub-sql refinement for text-to-sql. arXiv preprint arXiv:2408.07930. Cited by: §2.1. Yao et al. (2022) S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. R. Narasimhan, and Y. Cao React: synergizing reasoning and acting in language models. In The eleventh international conference on learning representations, Cited by: §2.1. Zhang et al. (2024a) H. Zhang, R. Cao, H. Xu, L. Chen, and K. Yu Coe-sql: in-context learning for multi-turn text-to-sql with chain-of-editions. arXiv preprint arXiv:2405.02712. Cited by: §2.1, §2.2. Zhang et al. (2024b) K. Zhang, J. Li, G. Li, X. Shi, and Z. Jin Codeagent: enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), p. 13643â13658. Cited by: §2.3. Zhang et al. (2025) Y. Zhang, M. Fan, J. Fan, M. Yi, Y. Luo, J. Tan, and G. Li Reward-sql: boosting text-to-sql via stepwise reasoning and process-supervised rewards. arXiv preprint arXiv:2505.04671. Zhao et al. (2025) X. Zhao, H. Li, J. Zhang, X. Huang, T. Zhang, J. Chen, R. Shi, C. Li, and H. Chen Llmidxadvis: resource-efficient index advisor utilizing large language model. arXiv preprint arXiv:2503.07884. Zhou et al. (2025) C. Zhou, X. Zhang, D. Song, X. Chen, W. Gu, H. Ma, Y. Tian, M. Zhang, and L. Hu Refinecoder: iterative improving of large language models via adaptive critique refinement for code generation. arXiv preprint arXiv:2502.09183. Cited by: §2.3. Zhu et al. (2025a) Y. Zhu, L. Wang, C. Yang, X. Lin, B. Li, W. Zhou, X. Liu, Z. Peng, T. Luo, Y. Li, et al. A survey of data agents: emerging paradigm or overstated hype?. arXiv preprint arXiv:2510.23587. Zhu et al. (2025b) Y. Zhu, C. Liu, X. He, X. Ren, Z. Liu, R. Pan, and H. Zhang Adacoder: an adaptive planning and multi-agent framework for function-level code generation. IEEE Transactions on Software Engineering. Cited by: §2.3. *