SDAM: Structure-Difference-Aware Memory Evolution for Complex Text-to-SQL

# SDAM: Structure-Difference-Aware Memory Evolution for Complex Text-to-SQL
Source: [https://arxiv.org/html/2608.12338](https://arxiv.org/html/2608.12338)
Keyan Xu, Dingzirui Wang, Xuanliang Zhang, Qingfu Zhu, Wanxiang Che Harbin Institute of Technology \{kyxu, dzrwang, xuanliangzhang, qfzhu, car\}@ir\.hit\.edu\.cn

###### Abstract

Text\-to\-SQL aims to convert natural language questions into executable SQL queries\. While memory\-based agent system improves complex SQL generation, existing memory design neglect historical experience and suffer from weak structure analysis, shallow semantic understanding, and poor schema alignment\. To address these challenges, we proposeSDAM\. Specifically,SDAMidentifies potential errors via a structure\-difference aware reasoning tree, extracts deep semantic rules through contradiction\-aware reflection, and enhances structural consistency using a schema\-grounded memory evolution mechanism to bind memory with database schemas\. We integrateSDAMinto a Text\-to\-SQL framework namedSDAM\-SQL\. Experiment shows thatSDAM\-SQLachieves2\.0%2\.0\\%and0\.4%0\.4\\%improvement on BIRD\-dev and Spider\-test compared with mainstream Text\-to\-SQL methods, showing the effectiveness ofSDAM\-SQL\.

SDAM: Structure\-Difference\-Aware Memory Evolution for Complex Text\-to\-SQL

Keyan Xu, Dingzirui Wang, Xuanliang Zhang, Qingfu Zhu, Wanxiang Che††thanks:Corresponding author\.Harbin Institute of Technology\{kyxu, dzrwang, xuanliangzhang, qfzhu, car\}@ir\.hit\.edu\.cn

## 1Introduction

![Refer to caption](https://arxiv.org/html/2608.12338v1/figures/images/short.png)Figure 1:Limitations of existing methods and the motivation ofSDAM\. Existing methods suffer from three issues:\(i\)Weak Structure Analysis, addressed by the Structure\-Difference Aware Reasoning Tree \(§[4\.1\.1](https://arxiv.org/html/2608.12338#S4.SS1.SSS1)\);\(ii\)Shallow Semantic Understanding, addressed by Contradiction\-Aware Reflection \(§[4\.1\.2](https://arxiv.org/html/2608.12338#S4.SS1.SSS2)\); and\(iii\)Poor Schema Alignment, addressed by the Schema\-Grounded Memory Evolution Mechanism \(§[4\.1\.3](https://arxiv.org/html/2608.12338#S4.SS1.SSS3)\)\.Text\-to\-SQL aims to translate natural language questions into executable SQL queriesBaeket al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib2)\)\. Currently, agent\-based frameworks have become the mainstream paradigm for complex SQL generationLiuet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib1)\)\. These methods improve Text\-to\-SQL performance through multi\-stage collaborative reasoning\. For example, CHESSTalaeiet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib5)\)employs multi\-agent collaboration for SQL generation, while Alpha\-SQLLiet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib6)\)leverages MCTS to search for optimal reasoning paths\. However, most existing Agent\-for\-SQL methods still rely on static reasoning pipelines and lack continuous and effective utilization of historical experience, making adaptive optimization difficult in complex scenarios\. To address this issue, memory mechanisms should be introduced to store historical experience\. Recent general\-purpose memory methods include the hierarchical graph memory of G\-MemoryZhanget al\.\([2025a](https://arxiv.org/html/2608.12338#bib.bib24)\)and the experience replay mechanism of ExpeLZhaoet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib25)\)\.

Although existing methods have achieved promising progress, their memory design still struggle to meet the demands of complex reasoning in Text\-to\-SQL, mainly in three aspects:\(i\)Weak Structure Analysis: existing methods typically only record linear reasoning processes, making it difficult to model and analyze complex SQL logic such as multi\-table joins and aggregation operations;\(ii\)Shallow Semantic Understanding: existing methods mostly remain at surface\-level semantic analysis and fail to capture the deeper semantics of database fields\. For example,active\_usernot only represents a user’s status, but also implicitly indicates that the user’s login frequency exceeds a certain threshold \(Figure[1](https://arxiv.org/html/2608.12338#S1.F1)\);\(iii\)Poor Schema Alignment: existing memory lacks explicit alignment with the database schema, which can lead to SQL queries inconsistent with the database structure\. For example, when the memory records “prefer using thenamefield when querying user names,” the model may incorrectly usecourse\.nameas the user name field, while the correct field should bestudent\.student\_name\(Figure[1](https://arxiv.org/html/2608.12338#S1.F1)\)\.

To address these issues, we proposeStructure\-Difference\-AwareMemory \(SDAM\), which achieves:\(i\) Weak Structure Analysis: We introduce theStructure\-Difference Aware Reasoning Tree, which generates multiple reasoning paths and organizes them into a reasoning tree to capture structural differences among candidate SQL queries, thereby improving the accurate modeling of complex SQL structures\.\(ii\) Shallow Semantic Understanding: We proposeContradiction\-Aware Reflection, which analyzes logical contradictions in the reasoning process, inconsistencies between SQL and schema, as well as mismatches between execution results and question semantics, enabling the extraction of deep semantic rules from erroneous cases\.\(iii\) Poor Schema Alignment: We design theSchema\-Grounded Memory Evolution Mechanism, which explicitly binds memory to database tables and columns to reduce field confusion and structural errors\.

Based onSDAM, we proposeSDAM\-SQL, a memory evolution framework for Text\-to\-SQL\.SDAM\-SQLleads to0\.4%0\.4\\%and2\.0%2\.0\\%improvement compared with existing mainstream Text\-to\-SQL methods, showing its effectiveness\.

Our contributions are summarized as follows:

- •We proposeSDAM, which achieves the evolution from instance\-level errors to structured semantic knowledge through structure\-difference analysis and contradiction\-driven pattern extraction for complex Text\-to\-SQL reasoning tasks\.
- •Experiments on Spider and Bird benchmarks show that our method consistently outperforms strong baselines with0\.4%0\.4\\%and2\.0%2\.0\\%, further demonstrating its effectiveness\.
- •Extensive analysis demonstrates thatSDAM\-SQLeffectively alleviates the critical limitations of existing methods, achieving a compelling4\.04%4\.04\\%performance leap alongside improved computational efficiency compared to the state\-of\-the\-art general\-purpose memory framework, which firmly substantiates its domain\-specific advantages in Text\-to\-SQL scenarios\.

## 2Related Work

![Refer to caption](https://arxiv.org/html/2608.12338v1/figures/images/method.png)Figure 2:Overview ofSDAM\-SQL\.The workflow consists of two phases: \(a\)Memory Construction: We generate diverse SQL candidates, detect contradictions via structure\-difference aware reasoning tree, contradiction\-aware reflection and schema\-grounded memory evolution mechanism \(§[4\.1](https://arxiv.org/html/2608.12338#S4.SS1)\)\. \(b\)Memory Usage: Relevant memory units are dynamically retrieved via semantic similarity and schema anchors to guide SQL generation \(§[4\.2](https://arxiv.org/html/2608.12338#S4.SS2)\)\.### 2\.1LLM\-Powered Text\-to\-SQL

Large Language Models \(LLMs\) have achieved significant progress in Text\-to\-SQL tasks due to their strong semantic understanding and code generation capabilities\(Yanget al\.,[2025](https://arxiv.org/html/2608.12338#bib.bib15); Achiamet al\.,[2023](https://arxiv.org/html/2608.12338#bib.bib13); Grattafioriet al\.,[2024](https://arxiv.org/html/2608.12338#bib.bib14); Liet al\.,[2023](https://arxiv.org/html/2608.12338#bib.bib11)\)\. Recent studies mainly improve SQL generation through prompt engineering, task decomposition, and multi\-path reasoning\(Taiet al\.,[2023](https://arxiv.org/html/2608.12338#bib.bib17); Liu and Tan,[2023](https://arxiv.org/html/2608.12338#bib.bib16)\)\.

The early methods relied on sophisticated prompting strategies, such as Chain\-of\-Thought \(CoT\)Weiet al\.\([2022](https://arxiv.org/html/2608.12338#bib.bib18)\)and self\-consistency reasoningWanget al\.\([2022](https://arxiv.org/html/2608.12338#bib.bib19)\)\. Later, DIN\-SQLPourreza and Rafiei \([2023](https://arxiv.org/html/2608.12338#bib.bib4)\)significantly improved complex SQL generation through task decomposition, while MCS\-SQLLeeet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib20)\)enhanced robustness via multi\-prompt search\. To further improve complex reasoning ability, recent works introduced multi\-agent collaboration and search\-based mechanisms\. For example, CHESSTalaeiet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib5)\)employs multi\-agent collaboration for high\-accuracy SQL generation, while Alpha\-SQLLiet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib6)\)iteratively explores optimal reasoning paths through Monte Carlo Tree Search \(MCTS\), achieving performance on complex SQL tasks\.

### 2\.2Memory Evolution Agents

Existing memory mechanisms for enhancing LLM agents in complex reasoning tasks can generally be categorized into three types: \(1\) parametric memory, which stores experience through fine\-tuning or external parameter modules for continual adaptation\(Chenet al\.,[2023](https://arxiv.org/html/2608.12338#bib.bib21); Yinet al\.,[2024](https://arxiv.org/html/2608.12338#bib.bib22); Tacket al\.,[2024](https://arxiv.org/html/2608.12338#bib.bib23)\); \(2\) retrieval\-based memory, which abstracts experience into reusable knowledge or skills for long\-term adaptation\(Zhanget al\.,[2025a](https://arxiv.org/html/2608.12338#bib.bib24); Zhaoet al\.,[2024](https://arxiv.org/html/2608.12338#bib.bib25); Zhenget al\.,[2025](https://arxiv.org/html/2608.12338#bib.bib26); Wanget al\.,[2025b](https://arxiv.org/html/2608.12338#bib.bib27)\); and \(3\) implicit memory, which encodes and retrieves historical experience through latent representations\(Wanget al\.,[2025a](https://arxiv.org/html/2608.12338#bib.bib28); Huet al\.,[2025](https://arxiv.org/html/2608.12338#bib.bib29)\)\.

Among them, retrieval\-based memory has recently attracted increasing attention due to its interpretability and scalability\. G\-MemoryZhanget al\.\([2025a](https://arxiv.org/html/2608.12338#bib.bib24)\)organizes multi\-agent experiences with hierarchical graph structures to support collaborative reasoning; ExpeLZhaoet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib25)\)stores historical trajectories and natural language rules through experience replay for iterative self\-improvement; SkillWeaverZhenget al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib26)\)abstracts procedural experience into reusable APIs and executable skills; and Mobile\-Agent\-EWanget al\.\([2025b](https://arxiv.org/html/2608.12338#bib.bib27)\)continuously improves mobile agents through long\-term memory mechanisms\.

## 3Task Formulation

The Text\-to\-SQL task aims to map a natural language question into an executable SQL query\. Formally, given a questionqqand a database schemaS=\{T1,…,Tm\}S=\\\{T\_\{1\},\\ldots,T\_\{m\}\\\}where each table contains a set of columnsTi=\{ci​1,…,ci​n\}T\_\{i\}=\\\{c\_\{i1\},\\ldots,c\_\{in\}\\\}, the goal is to generate the SQL query viay=f​\(q,S\)y=f\(q,S\)\.

Distinguishing from conventional methods, we introduce and maintain a dynamically evolving, structured memory setM=miM=\{m\_\{i\}\}to store structural patterns, semantic rules, and schema\-aligned knowledge extracted from complex reasoning processes\. Consequently, we reformulate the SQL generation task as:y=f​\(q,S,M\)y=f\(q,S,M\)whereMMinjects supplementary structural expertise and semantic constraints into the generation process, thereby enhancing both the execution correctness and schema consistency of the synthesized queries\.

## 4Methodology

This section presentsSDAM, a structured memory framework for Text\-to\-SQL that conceptualizes memory as the artifact of structural discrepancy and contradiction analysis\. The pipeline consists of two primary phases \(Figure[2](https://arxiv.org/html/2608.12338#S2.F2)\): \(1\)SDAMConstruction, which builds dynamically evolving, structured memories via structural difference analysis and contradiction\-driven pattern extraction; and \(2\)SDAMUsage, which retrieves and enforces memory constraints via semantic similarity and schema anchors to guide SQL generation\.SDAMsystematically resolves three core challenges: \(1\)Weak Structure Analysisvia structure\-difference aware reasoning tree \(§[4\.1\.1](https://arxiv.org/html/2608.12338#S4.SS1.SSS1)\) to model complex SQL structures; \(2\)Shallow Semantic Understandingvia contradiction\-aware reflection \(§[4\.1\.2](https://arxiv.org/html/2608.12338#S4.SS1.SSS2)\) to capture latent column semantics; and \(3\)Poor Schema Alignmentvia schema\-grounded memory evolution mechanism \(§[4\.1\.3](https://arxiv.org/html/2608.12338#S4.SS1.SSS3)\) to ensure explicit memory\-to\-schema correspondence\.

### 4\.1SDAMConstruction

#### 4\.1\.1Structure\-Difference Aware Reasoning Tree

To address the weak structure analysis problem,SDAMconstructs a structure\-difference aware reasoning tree\. Specifically, we first leverage the high sensitivity of LLMs to structural variations in schema representationsLiuet al\.\([2026](https://arxiv.org/html/2608.12338#bib.bib31)\)by constructing multiple schema variants through modifying field descriptions and schema organization forms \(See Appendix[B\.1](https://arxiv.org/html/2608.12338#A2.SS1)for details\):

S~=\{Sk\}k=1m\\tilde\{S\}=\\\{S\_\{k\}\\\}\_\{k=1\}^\{m\}Based on different schema variants, the model generates corresponding SQL candidatesyky\_\{k\}and reasoning pathsRkR\_\{k\}in parallel under the contextualized guidance of structured memoryMM:

\(yk,Rk\)=f​\(q,Sk,M\),k=1,…,m\(y\_\{k\},R\_\{k\}\)=f\(q,S\_\{k\},M\),\\quad k=1,\\ldots,m
Since SQL reasoning naturally exhibits staged and structured characteristicsLiet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib6)\), we regard each reasoning pathRkR\_\{k\}as a sequence of structured reasoning nodes organized in a fixed reasoning order \(see Table[8](https://arxiv.org/html/2608.12338#A2.T8)\), including question rephrasing, table selection, column selection, function identification, condition value identification, and SQL generation\.

After obtaining multiple reasoning paths, we further topologically merge semantically identical nodes across different paths while preserving structurally different or logically conflicting parts as divergent, independent branches, thereby constructing a unified reasoning tree:

𝒯=\(V,E\)\\mathcal\{T\}=\(V,E\)whereVVdenotes the set of reasoning nodes andEEdenotes the dependency relations between nodes\. In this way,SDAMcan explicitly model structural differences among candidate SQL queries, enabling more effective detection of potential structural errors in complex SQL reasoning\.

#### 4\.1\.2Contradiction\-Aware Reflection

To address the shallow semantic understanding problem,SDAMfurther introduces contradiction\-aware reflection based on the reasoning tree𝒯\\mathcal\{T\}\. Different from conventional surface\-level reflection that relies only on a single SQL query,SDAMleverages LLMs to jointly analyze the intersection nodes and conflicting branches within the reasoning tree\. Under the organization of the reasoning tree, structural differences and logical conflicts across different reasoning paths are explicitly exposed, making potential contradictions clearer and easier for the model to identify and analyze, thereby uncovering potential errors and implicit semantic information in complex SQL reasoning\.

Specifically, contradictions are analyzed from three complementary perspectives at different granularities \(See Appendix[B\.3](https://arxiv.org/html/2608.12338#A2.SS3)for more details\):

- •Structure Contradiction: captures structural differences and logical conflicts among different reasoning paths;
- •Schema Contradiction: checks the consistency between generated SQL and schema definitions;
- •Execution Contradiction: determines whether the execution results satisfy the question semantics and constraints\.

Finally, all detected contradictions are summarized into a global contradiction set:

𝒞=L​L​MR​e​f​l​e​c​t​o​r​\(𝒯,S~,q\)\\mathcal\{C\}=LLM\_\{Reflector\}\\big\(\\mathcal\{T\},\\tilde\{S\},q\\big\)
By comparing fine\-grained intermediate reasoning branches within the reasoning tree,SDAMcan more effectively identify potential errors in complex divergent SQL reasoning\.

#### 4\.1\.3Schema\-Grounded Memory Evolution

To address the poor schema alignment issue,SDAMintroduces a schema\-grounded memory evolution mechanism, which consists of three stages: memory extraction, memory filtering, and memory evolution\.

First, the system performs structured memory extraction based on the contradiction set𝒞\\mathcal\{C\}, transforming the error patterns and semantic rules identified during reflection into a new memory set:

Mnew=L​L​ME​x​t​r​a​c​t​o​r​\(𝒞\)M\_\{\\text\{new\}\}=LLM\_\{Extractor\}\(\\mathcal\{C\}\)To achieve explicit schema alignment, each memory unit is defined as a quadruple:

m=\(p,c,δ,Sanchor\)m=\(p,c,\\delta,S\_\{\\text\{anchor\}\}\)whereppdenotes the structural or semantic pattern,ccdenotes the triggering condition,δ\\deltadenotes the correction rule, andSanchorS\_\{\\text\{anchor\}\}represents the Schema Anchor, which explicitly binds the memory to tables and columns in the database, thereby reducing column confusion and incorrect schema mappings\.

Next, considering that LLM\-generated memories may contain noise or hallucinations, we further conduct consistency verification and filtering on the newly extracted memories by jointly leveraging the schema variant setS~\\tilde\{S\}and the existing memory setMM, resulting in a high\-confidence memory set:

M∗=L​L​MF​i​l​t​e​r​\(Mnew,S~,M\)M^\{\*\}=LLM\_\{Filter\}\(M\_\{\\text\{new\}\},\\tilde\{S\},M\)
Finally, the memory bank is continuously updated in an incremental manner:

M←M∪M∗M\\leftarrow M\\cup M^\{\*\}
To better handle different types of Text\-to\-SQL challenges, the retained high\-quality memories are further categorized into three types:

- •Domain Memory: stores domain semantics and business rules;
- •Arithmetic Memory: models aggregation, ranking, and numerical computation patterns;
- •SQL Syntax Memory: captures SQL structural patterns and multi\-table join relationships\.

### 4\.2Memory Usage

During SQL generation, we perform dynamic retrieval over structured memory based on the semantic meaning of the query and the database schema, providing auxiliary information for reasoning\.

First, we compute the semantic similarity between the query and each memory unit:

sim​\(q,mi\)=E​\(q\)⋅E​\(mi\)‖E​\(q\)‖​‖E​\(mi\)‖\\text\{sim\}\(q,m\_\{i\}\)=\\frac\{E\(q\)\\cdot E\(m\_\{i\}\)\}\{\\\|E\(q\)\\\|\\\|E\(m\_\{i\}\)\\\|\}whereE​\(⋅\)E\(\\cdot\)denotes an embedding encoder that maps inputs into a shared semantic space\.

Based on this, we introduce a schema\-anchor constraint to filter out memory units that are not aligned with the current schema:

Malign=\{mi∣Sanchor​\(mi\)⊆S\}M\_\{\\text\{align\}\}=\\\{m\_\{i\}\\mid S\_\{\\text\{anchor\}\}\(m\_\{i\}\)\\subseteq S\\\}whereSSdenotes the current database schema\.

Within the aligned memory set, we select the top\-kkmost relevant memory units according to the similarity score:

Mk=TopK​\(sim​\(q,mi\),Malign\)M\_\{k\}=\\text\{TopK\}\(\\text\{sim\}\(q,m\_\{i\}\),M\_\{\\text\{align\}\}\)Finally, the retrieved memory is explicitly injected into the SQL generation process as context\-aware, structured reasoning guidance, enhancing the model’s ability to capture complex semantic patterns and schema constraints\.

## 5Experiment

Table 1:Execution accuracy comparison on BIRD and Spider benchmarks\.Boldindicates the best performance\.### 5\.1Experimental Setup

##### Datasets

We evaluate our proposed method on two representative and challenging Text\-to\-SQL benchmarks: \(1\)SpiderYuet al\.\([2018](https://arxiv.org/html/2608.12338#bib.bib10)\), a classic cross\-domain benchmark containing 10,181 questions and 5,693 unique SQL queries across 200 databases, highlighting the model’s compositional generalization ability on unseen schemas; \(2\)BIRDLiet al\.\([2023](https://arxiv.org/html/2608.12338#bib.bib11)\), a large\-scale real\-world benchmark with 12,751 question\-SQL pairs across 95 large\-sized databases, characterized by noisy data and intricate schemas that pose severe challenges for schema alignment and robustness\.

##### Evaluation Metrics

Following prior work\(Caoet al\.,[2024](https://arxiv.org/html/2608.12338#bib.bib30); Liuet al\.,[2026](https://arxiv.org/html/2608.12338#bib.bib31); Pourrezaet al\.,[2024](https://arxiv.org/html/2608.12338#bib.bib32)\), we adopt Execution Accuracy \(EX\) as our metric\. EX measures correctness by executing both the predicted and gold SQL queries on the target database and verifying whether their execution results are semantically equivalent \(ignoring row order\)\.

##### Baselines

We compareSDAM\-SQLwith a suite of state\-of\-the\-art, prompting\-based Text\-to\-SQL methods\. These approaches follow an in\-context learning paradigm without task\-specific fine\-tuning, leveraging Large Language Models \(LLMs\) directly for SQL generation\. According to the underlying backbone models, they are categorized into two methodological groups:

Close\-Source Model\-Based Methods: This category relies on advanced commercial models \(e\.g\., GPT\-4o, Gemini\) and includes DIN\-SQLPourreza and Rafiei \([2023](https://arxiv.org/html/2608.12338#bib.bib4)\), DAIL\-SQLGaoet al\.\([2023](https://arxiv.org/html/2608.12338#bib.bib33)\), SuperSQLLiet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib34)\), RSL\-SQLCaoet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib30)\), and CHESSTalaeiet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib5)\)\.

Open\-Source Model\-Based Methods: Built upon publicly available, highly scalable open\-weights models \(e\.g\., DeepSeek, Qwen\-Coder\), this group encompasses GBV\-SQLChenet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib35)\), RSL\-SQLCaoet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib30)\), GenaSQLDönderet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib12)\), Alpha\-SQLLiet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib6)\)and ExpeSQL[Zeruiet al\.](https://arxiv.org/html/2608.12338#bib.bib42)\.

Additionally, we employ a vanilla SQL\-generation framework \(See Appendix[A](https://arxiv.org/html/2608.12338#A1)for details\) as our baseline, upon whichSDAM\-SQLis built by integratingSDAM\.

##### Implementation Details

All experiments are conducted on an Ubuntu 22\.04 server\. We locally deploy all open\-weights models via the vLLM frameworkKwonet al\.\([2023](https://arxiv.org/html/2608.12338#bib.bib37)\)on two NVIDIA A100 \(80GB\) GPUs\. To evaluate the generalizability across different foundation capabilities, we implementSDAM\-SQLon various backbone models, including the Qwen3 series \(8B/14B/32B\), the Qwen2\.5\-Coder series \(7B/14B/32B\), and Qwen3\-Coder\-30B\-A3B\-InstructYanget al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib15)\); Huiet al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib38)\), which driveSDAMconstruction and SQL generate \(Appendix[A](https://arxiv.org/html/2608.12338#A1)\) phases\. We adopt the online adaptation setting, where methods are evaluated sequentially on the dev/test split\. For each sample, the model first generates predictions based on the current context and then updates its memory according to the observed reasoning process\. To ensure a fair comparison,SDAMis constructed and evolved autonomously without access to any ground\-truth labels throughout the entire evaluation process\. For semantic value retrieval, we employ Qwen3\-Embedding\-0\.6BZhanget al\.\([2025c](https://arxiv.org/html/2608.12338#bib.bib39)\)\. To enhance the diversity of reasoning paths, we construct five distinct schema representations for each database, generating a candidate SQL query from each representation to enrich the input for subsequent contradiction analysis and memory extraction\. Prompt templates and detailed configurations are provided in the Appendix[E](https://arxiv.org/html/2608.12338#A5)\.

Table 2:Performance comparison between baseline andSDAM\-SQLwith memory evolution across different model scales and datasets\.Boldindicates the best performance\.

### 5\.2Overall Performance

Table[1](https://arxiv.org/html/2608.12338#S5.T1)presents the overall experimental results ofSDAM\-SQLon the BIRD and Spider benchmarks\. The empirical results demonstrate that our method consistently surpasses existing baselines across all configurations on both datasets\.

Specifically, on the highly challenging BIRD benchmark,SDAM\-SQLconfigured with Qwen3\-Coder\-30B\-A3B\-Instruct yields an Execution Accuracy \(EX\) of70\.2%, achieving absolute improvements of2\.0% and2\.7% over the strongest baselines, Alpha\-SQL \(68\.2%68\.2\\%\) and ExpeSQL \(67\.5%67\.5\\%\), respectively\. On the Spider dataset,SDAM\-SQLalso secures a top\-tier EX of88\.0%, outperforming competitive baselines such as GenaSQL \(87\.6%87\.6\\%\) and RSL\-SQL\. Notably, the performance gain ofSDAM\-SQLis more pronounced on BIRD, which features denser complex scenarios, underscores its distinct advantage in overcoming the bottlenecks of complex SQL memory evolution and schema alignment through structural discrepancy analysis and the contradiction\-driven memory mechanism\.

### 5\.3Main Results

Table[2](https://arxiv.org/html/2608.12338#S5.T2)presents the experimental results ofSDAM\-SQLacross varying model scales and datasets\. The empirical findings indicate that our method consistently robustly boosts Text\-to\-SQL performance under most model configurations, with the performance gains becoming more pronounced as the inherent task complexity scales up\.

Specifically: \(1\) On the relatively well\-regulated Spider dataset, most models exhibit stable improvements, where Qwen3\-32B and Qwen2\.5\-Coder\-14B increase to85\.69%85\.69\\%and87\.12%,87\.12\\%,respectively, with the peak performance reaching88\.01%\. \(2\) On the more challenging BIRD benchmark, all models achieve consistent gains; for instance, Qwen3\-8B improves by3\.00%, and Qwen3\-Coder\-30B\-A3B\-Instruct reaches70\.21%, demonstratingSDAM\-SQL’s capability to navigate complex structures and implicit semantic constraints\. \(3\) We observe similar consistent gains on the complex\-reasoning Archer dataset \(Appendix[C\.1](https://arxiv.org/html/2608.12338#A3.SS1)\), where the performance peaks at36\.54%\.These results validate the effectiveness of our memory evolution mechanism in complex Text\-to\-SQL tasks\.

### 5\.4Ablation Study

To verify the effectiveness of each module, we conduct ablation studies on the BIRD benchmark, thereby isolating the unique contribution of each architectural component \(Table[3](https://arxiv.org/html/2608.12338#S5.T3)\):

- •w/o tree: Performance drops by3\.26%, confirming the critical role of the reasoning tree in capturing latent structural errors\.
- •w/o contradiction: The performance drops by2\.35%, indicating that the analysis of multi\-dimensional contradictions effectively breaks the bottleneck of shallow semantic understanding\.
- •w/o schema anchor: Performance declines by1\.76%, demonstrating that explicitly binding memories to database elements effectively reduces schema mapping errors\.
- •w/o filter: Performance also degrades, validating the necessity of the filtering mechanism in suppressing noise and enhancing memory reliability\.

In summary, all modules synergistically contribute positively to the overall performance, with structural discrepancy analysis and schema\-anchored retrieval playing a particularly prominent role in supporting complex reasoning\.

Table 3:Ablation study of different components inSDAM\-SQLon the BIRD dataset\.Table 4:Performance comparison across different SQL difficulty levels on BIRD\.Δ\\Deltadenotes the improvement over the baseline\.Table 5:Performance comparison between ACEZhanget al\.\([2025b](https://arxiv.org/html/2608.12338#bib.bib41)\)andSDAM\-SQL\.Boldindicates the best results;Δ\\Deltarepresents the improvement over baseline\.Table 6:Efficiency comparison in terms of average LLM calls, token consumption, and execution time per query\.Boldindicates the most efficient performance with lower computational overhead\.
### 5\.5Difficulty\-Level Analysis

Table[4](https://arxiv.org/html/2608.12338#S5.T4)presents the performance ofSDAM\-SQLacross different SQL difficulty levels on the BIRD benchmark\. The results indicate that the advantage of our method becomes increasingly pronounced as the task difficulty scaling up, yielding performance gains of2\.27%,3\.67%, and8\.97% under Simple, Moderate, and Challenging settings, respectively\.

Challenging samples typically involve intricate structures such as multi\-table joins and nested aggregations, where conventional generation strategies are highly prone to failure\. In contrast, leveraging structural discrepancy analysis and the reasoning tree mechanism,SDAM\-SQLprecisely pinpoints latent structural defects and distills deep semantic rules through contradiction\-driven memory evolution\. This capability empowers the model with superior error correction and structural modeling in Challenging scenarios, thereby contributing to the most breakthrough performance leaps\.

### 5\.6Comparative Analysis

Table[5](https://arxiv.org/html/2608.12338#S5.T5)presents the comparative results between the SOTA general memory framework ACEZhanget al\.\([2025b](https://arxiv.org/html/2608.12338#bib.bib41)\)andSDAM\-SQLacross various LLM backbones\.

Experimental results demonstrate that after introducing the state\-of\-the\-art general memory framework ACE, the performance of Qwen3\-Coder\-30B\-A3B and Qwen3\-32B decreases by0\.71%0\.71\\%and1\.37%1\.37\\%, respectively\. This indicates that although existing general\-purpose methods can enhance the long\-term experience utilization of agents, they lack the capability to model complex SQL structures, deep column semantics, and schema alignment, thereby making it difficult to effectively adapt to Text\-to\-SQL scenarios\.

In contrast, leveraging structure\-difference analysis, contradiction\-driven memory extraction, and the Schema\-Grounded evolution mechanism,SDAM\-SQLeffectively alleviates structural errors, semantic deviations, and column confusion in complex SQL reasoning\. Specifically,SDAM\-SQLbrings a3\.33%3\.33\\%performance improvement to Qwen3\-Coder \(reaching70\.21%70\.21\\%EX\) and also achieves a stable growth of1\.17%1\.17\\%on Qwen3\-32B\. This firmly substantiates that the structured memory evolution mechanism tailored specifically for Text\-to\-SQL tasks can more efficiently and significantly enhance the generation quality and execution correctness of complex SQL queries\.

### 5\.7Efficiency Analysis

To provide a clear perspective on the computational cost, we evaluate the memory construction efficiency ofSDAM\-SQLagainst the general\-purpose memory framework ACE on Qwen3\-Coder\-30B\-A3B in Table[6](https://arxiv.org/html/2608.12338#S5.T6)\. Experimental results demonstrate thatSDAM\-SQLexhibits distinct advantages across all efficiency metrics\. Specifically, in terms of the average LLM calls per query,SDAM\-SQLsubstantially reduces the frequency from10\.510\.5to8\.68\.6\. This reduction is largely attributed to our carefully designed contradiction\-driven reflection mechanism, which effectively eliminates blind and redundant iterations\. Consequently, in terms of token consumption,SDAM\-SQLsaves approximately11\.9%11\.9\\%of overhead compared to ACE \(dropping from30\.2​K30\.2\\text\{K\}to26\.6​K26\.6\\text\{K\}\)\. Profiting from the streamlined calling pipeline, the average execution time ofSDAM\-SQLis only4\.04\.0seconds, achieving a nearly14\.9%14\.9\\%speedup over ACE \(4\.74\.7seconds\)\. These findings firmly substantiate that while generating high\-quality memory,SDAM\-SQLachieves superior computational efficiency and significantly lower operational overhead\.

## 6Conclusion

In this paper, we proposeSDAM, a structure\-difference\-aware memory method for Text\-to\-SQL, and build its evolution framework,SDAM\-SQL\. Specifically,SDAMleverages a Structure\-Difference Aware Reasoning Tree, incorporates Contradiction\-Aware Reflection, and introduces a Schema\-Grounded Memory Evolution Mechanism to address key challenges in complex SQL memory evolution\. Extensive experiments on the Spider, BIRD, and Archer datasets demonstrate the effectiveness of our approach in complex structural modeling, deep semantic rule extraction, and precise schema alignment\. Moreover, compared with general\-purpose memory frameworks,SDAMdemonstrates clear advantages in both performance and computational efficiency, highlighting its importance for Text\-to\-SQL tasks\. In the future, we will explore memory generalization in cross\-database transfer scenarios and integrate long\-cycle feedback mechanisms to further enhance the system’s self\-evolution capabilities\.

## Limitation

AlthoughSDAMsignificantly improves performance across multiple Text\-to\-SQL benchmarks, it exhibits two primary limitations\. First, the current memory evolution heavily relies on logical contradictions and error feedback during the reasoning process\. Consequently, when encountering highly custom domain\-specific knowledge or extremely rare business logic \(i\.e\., cold\-start scenarios\),SDAMmay struggle to unearth deep semantic rules purely through self\-reflection without the guidance of external domain ontologies or expert priors\. Second, because the Schema\-Grounded Memory Evolution Mechanism explicitly binds memory units to specific database schemas, the generalization and transferability of these localized, structured memories to completely unseen databases with distinct structures remains an open challenge that requires further exploration\.

## Ethics Statement

This work complies with standard ethical guidelines\. All datasets utilized in our evaluation—Spider, BIRD, and Archer—are publicly accessible academic benchmarks that contain no private or personally identifiable information\. The proposed framework is intended solely for research purposes to advance natural language interfaces for databases\. To prevent risks such as accidental data modification or malicious SQL injection in practical applications, real\-world deployment of automated SQL generation should always be equipped with strict privilege control and read\-only execution sandboxes\. We employ the LLM tool to polish the paper writing\.

## References

- J\. Achiam, S\. Adler, S\. Agarwal, L\. Ahmad, I\. Akkaya, F\. L\. Aleman, D\. Almeida, J\. Altenschmidt, S\. Altman, S\. Anadkat,et al\.\(2023\)Gpt\-4 technical report\.arXiv preprint arXiv:2303\.08774\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p1.1)\.
- J\. Baek, H\. Samulowitz, O\. Hassanzadeh, D\. Subramanian, S\. Shirai, A\. Gliozzo, and D\. Bhattacharjya \(2025\)Knowledge base construction for knowledge\-augmented text\-to\-sql\.InFindings of the Association for Computational Linguistics: ACL 2025,pp\. 26569–26583\.Cited by:[§1](https://arxiv.org/html/2608.12338#S1.p1.1)\.
- Z\. Cao, Y\. Zheng, Z\. Fan, X\. Zhang, W\. Chen, and X\. Bai \(2024\)Rsl\-sql: robust schema linking in text\-to\-sql generation\.arXiv preprint arXiv:2411\.00073\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px2.p1.1),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p2.1),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p3.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.12.12.3),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.7.7.3)\.
- B\. Chen, C\. Shu, E\. Shareghi, N\. Collier, K\. Narasimhan, and S\. Yao \(2023\)Fireact: toward language agent fine\-tuning\.arXiv preprint arXiv:2310\.05915\.Cited by:[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1)\.
- D\. Chen, X\. Wang, S\. Ren, Q\. Ma, P\. Zhao, and A\. Liu \(2025\)GBV\-sql: guided generation and sql2text back\-translation validation for multi\-agent text2sql\.arXiv preprint arXiv:2509\.12612\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p3.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.10.10.3)\.
- Y\. D\. Dönder, D\. Hommel, A\. W\. Wen\-Yi, D\. Mimno, and U\. E\. S\. Jo \(2025\)Cheaper, better, faster, stronger: robust text\-to\-sql without chain\-of\-thought or fine\-tuning\.arXiv preprint arXiv:2505\.14174\.Cited by:[Appendix A](https://arxiv.org/html/2608.12338#A1.p1.1),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p3.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.14.14.3)\.
- D\. Gao, H\. Wang, Y\. Li, X\. Sun, Y\. Qian, B\. Ding, and J\. Zhou \(2023\)Text\-to\-sql empowered by large language models: a benchmark evaluation\.arXiv preprint arXiv:2308\.15363\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p2.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.4.4.3)\.
- A\. Grattafiori, A\. Dubey, A\. Jauhri, A\. Pandey, A\. Kadian, A\. Al\-Dahle, A\. Letman, A\. Mathur, A\. Schelten, A\. Vaughan,et al\.\(2024\)The llama 3 herd of models\.arXiv preprint arXiv:2407\.21783\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p1.1)\.
- Z\. Hu, Y\. Wang, H\. Dong, Y\. Xu, A\. Saha, C\. Xiong, B\. Hooi, and J\. Li \(2025\)Beyond’aha\!’: toward systematic meta\-abilities alignment in large reasoning models\.arXiv preprint arXiv:2505\.10554\.Cited by:[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1)\.
- B\. Hui, J\. Yang, Z\. Cui, J\. Yang, D\. Liu, L\. Zhang, T\. Liu, J\. Zhang, B\. Yu, K\. Lu,et al\.\(2024\)Qwen2\. 5\-coder technical report\.arXiv preprint arXiv:2409\.12186\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px4.p1.1)\.
- W\. Kwon, Z\. Li, S\. Zhuang, Y\. Sheng, L\. Zheng, C\. H\. Yu, J\. Gonzalez, H\. Zhang, and I\. Stoica \(2023\)Efficient memory management for large language model serving with pagedattention\.InProceedings of the 29th symposium on operating systems principles,pp\. 611–626\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px4.p1.1)\.
- D\. Lee, C\. Park, J\. Kim, and H\. Park \(2025\)Mcs\-sql: leveraging multiple prompts and multiple\-choice selection for text\-to\-sql generation\.InProceedings of the 31st International Conference on Computational Linguistics,pp\. 337–353\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p2.1)\.
- B\. Li, Y\. Luo, C\. Chai, G\. Li, and N\. Tang \(2024\)The dawn of natural language to sql: are we fully ready?\.arXiv preprint arXiv:2406\.01265\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p2.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.5.5.2)\.
- B\. Li, J\. Zhang, J\. Fan, Y\. Xu, C\. Chen, N\. Tang, and Y\. Luo \(2025\)Alpha\-sql: zero\-shot text\-to\-sql using monte carlo tree search\.arXiv preprint arXiv:2502\.17248\.Cited by:[§1](https://arxiv.org/html/2608.12338#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p2.1),[§4\.1\.1](https://arxiv.org/html/2608.12338#S4.SS1.SSS1.p2.1),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p3.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.16.16.2)\.
- J\. Li, B\. Hui, G\. Qu, J\. Yang, B\. Li, B\. Li, B\. Wang, B\. Qin, R\. Geng, N\. Huo,et al\.\(2023\)Can llm already serve as a database interface? a big bench for large\-scale database grounded text\-to\-sqls\.Advances in Neural Information Processing Systems36,pp\. 42330–42357\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p1.1),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px1.p1.1)\.
- X\. Liu, S\. Shen, B\. Li, P\. Ma, R\. Jiang, Y\. Zhang, J\. Fan, G\. Li, N\. Tang, and Y\. Luo \(2025\)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\.Cited by:[§1](https://arxiv.org/html/2608.12338#S1.p1.1)\.
- X\. Liu and Z\. Tan \(2023\)Divide and prompt: chain of thought prompting for text\-to\-sql\.arXiv preprint arXiv:2304\.11556\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p1.1)\.
- Y\. Liu, Y\. Zhu, Y\. Gao, Z\. Luo, X\. Li, X\. Shi, Y\. Hong, J\. Gao, Y\. Li, B\. Ding,et al\.\(2026\)Xiyan\-sql: a novel multi\-generator framework for text\-to\-sql\.IEEE Transactions on Knowledge and Data Engineering\.Cited by:[§4\.1\.1](https://arxiv.org/html/2608.12338#S4.SS1.SSS1.p1.4),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px2.p1.1)\.
- M\. Pourreza, H\. Li, R\. Sun, Y\. Chung, S\. Talaei, G\. T\. Kakkar, Y\. Gan, A\. Saberi, F\. Ozcan, and S\. O\. Arik \(2024\)Chase\-sql: multi\-path reasoning and preference optimized candidate selection in text\-to\-sql\.arXiv preprint arXiv:2410\.01943\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px2.p1.1)\.
- M\. Pourreza and D\. Rafiei \(2023\)Din\-sql: decomposed in\-context learning of text\-to\-sql with self\-correction\.Advances in neural information processing systems36,pp\. 36339–36348\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p2.1),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p2.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.2.2.3)\.
- J\. Tack, J\. Kim, E\. Mitchell, J\. Shin, Y\. W\. Teh, and J\. R\. Schwarz \(2024\)Online adaptation of language models with a memory of amortized contexts\.Advances in Neural Information Processing Systems37,pp\. 130109–130135\.Cited by:[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1)\.
- C\. Tai, Z\. Chen, T\. Zhang, X\. Deng, and H\. Sun \(2023\)Exploring chain of thought style prompting for text\-to\-sql\.InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing,pp\. 5376–5393\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p1.1)\.
- S\. Talaei, M\. Pourreza, Y\. Chang, A\. Mirhoseini, and A\. Saberi \(2024\)Chess: contextual harnessing for efficient sql synthesis\.arXiv preprint arXiv:2405\.16755\.Cited by:[§1](https://arxiv.org/html/2608.12338#S1.p1.1),[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p2.1),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p2.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.8.8.2)\.
- X\. Wang, J\. Wei, D\. Schuurmans, Q\. Le, E\. Chi, S\. Narang, A\. Chowdhery, and D\. Zhou \(2022\)Self\-consistency improves chain of thought reasoning in language models\.arXiv preprint arXiv:2203\.11171\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p2.1)\.
- Y\. Wang, D\. Krotov, Y\. Hu, Y\. Gao, W\. Zhou, J\. McAuley, D\. Gutfreund, R\. Feris, and Z\. He \(2025a\)M\+: extending memoryllm with scalable long\-term memory\.arXiv preprint arXiv:2502\.00592\.Cited by:[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1)\.
- Z\. Wang, H\. Xu, J\. Wang, X\. Zhang, M\. Yan, J\. Zhang, F\. Huang, and H\. Ji \(2025b\)Mobile\-agent\-e: self\-evolving mobile assistant for complex tasks\.arXiv preprint arXiv:2501\.11733\.Cited by:[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1),[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p2.1)\.
- J\. Wei, X\. Wang, D\. Schuurmans, M\. Bosma, F\. Xia, E\. Chi, Q\. V\. Le, D\. Zhou,et al\.\(2022\)Chain\-of\-thought prompting elicits reasoning in large language models\.Advances in neural information processing systems35,pp\. 24824–24837\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p2.1)\.
- A\. Yang, A\. Li, B\. Yang, B\. Zhang, B\. Hui, B\. Zheng, B\. Yu, C\. Gao, C\. Huang, C\. Lv,et al\.\(2025\)Qwen3 technical report\.arXiv preprint arXiv:2505\.09388\.Cited by:[§2\.1](https://arxiv.org/html/2608.12338#S2.SS1.p1.1),[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px4.p1.1)\.
- D\. Yin, F\. Brahman, A\. Ravichander, K\. Chandu, K\. Chang, Y\. Choi, and B\. Y\. Lin \(2024\)Agent lumos: unified and modular training for open\-source language agents\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 12380–12403\.Cited by:[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1)\.
- T\. Yu, R\. Zhang, K\. Yang, M\. Yasunaga, D\. Wang, Z\. Li, J\. Ma, I\. Li, Q\. Yao, S\. Roman,et al\.\(2018\)Spider: a large\-scale human\-labeled dataset for complex and cross\-domain semantic parsing and text\-to\-sql task\.InProceedings of the 2018 conference on empirical methods in natural language processing,pp\. 3911–3921\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px1.p1.1)\.
- \[31\]Y\. Zerui, Y\. Siyu, Y\. Xu, L\. Song, Y\. Matsuda, Y\. Luo, W\. Han, and B\. BaiExpeSQL: an experience\-guided decompositional search framework for text\-to\-sql\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px3.p3.1),[Table 1](https://arxiv.org/html/2608.12338#S5.T1.15.15.2)\.
- G\. Zhang, M\. Fu, G\. Wan, M\. Yu, K\. Wang, and S\. Yan \(2025a\)G\-memory: tracing hierarchical memory for multi\-agent systems\.arXiv preprint arXiv:2506\.07398\.Cited by:[§1](https://arxiv.org/html/2608.12338#S1.p1.1),[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1),[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p2.1)\.
- Q\. Zhang, C\. Hu, S\. Upasani, B\. Ma, F\. Hong, V\. Kamanuru, J\. Rainton, C\. Wu, M\. Ji, H\. Li,et al\.\(2025b\)Agentic context engineering: evolving contexts for self\-improving language models\.arXiv preprint arXiv:2510\.04618\.Cited by:[§5\.6](https://arxiv.org/html/2608.12338#S5.SS6.p1.1),[Table 5](https://arxiv.org/html/2608.12338#S5.T5)\.
- Y\. Zhang, M\. Li, D\. Long, X\. Zhang, H\. Lin, B\. Yang, P\. Xie, A\. Yang, D\. Liu, J\. Lin,et al\.\(2025c\)Qwen3 embedding: advancing text embedding and reranking through foundation models\.arXiv preprint arXiv:2506\.05176\.Cited by:[§5\.1](https://arxiv.org/html/2608.12338#S5.SS1.SSS0.Px4.p1.1)\.
- A\. Zhao, D\. Huang, Q\. Xu, M\. Lin, Y\. Liu, and G\. Huang \(2024\)Expel: llm agents are experiential learners\.InProceedings of the AAAI Conference on Artificial Intelligence,Vol\.38,pp\. 19632–19642\.Cited by:[§1](https://arxiv.org/html/2608.12338#S1.p1.1),[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1),[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p2.1)\.
- B\. Zheng, M\. Y\. Fatemi, X\. Jin, Z\. Z\. Wang, A\. Gandhi, Y\. Song, Y\. Gu, J\. Srinivasa, G\. Liu, G\. Neubig,et al\.\(2025\)Skillweaver: web agents can self\-improve by discovering and honing skills\.arXiv preprint arXiv:2504\.07079\.Cited by:[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p1.1),[§2\.2](https://arxiv.org/html/2608.12338#S2.SS2.p2.1)\.
- D\. Zheng, M\. Lapata, and J\. Pan \(2024\)Archer: a human\-labeled text\-to\-sql dataset with arithmetic, commonsense and hypothetical reasoning\.InProceedings of the 18th Conference of the European Chapter of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 94–111\.Cited by:[§C\.1](https://arxiv.org/html/2608.12338#A3.SS1.p1.1)\.

## Appendix AGenerate Strategy

Our SQL generation strategy adopts the design fromDönderet al\.\([2025](https://arxiv.org/html/2608.12338#bib.bib12)\), which conceptualizes the pipeline into four primary stages:

\(1\) Schema Linking Stage: This stage utilizes multiple text formats to project the target database structure into diverse representational modalities, and combines multi\-model predictions to identify the tables and columns essential for answering the natural language question\. Subsequently, it outputs three distinct filtering granularities \(unfiltered, table\-only filtering, and full filtering\) to significantly enhance the diversity and robustness of the schema representations\.

\(2\) Few\-shot Retrieval Stage: Leveraging the schema topology information predicted in the current stage, this mechanism dynamically retrieves a fixed number of contextually relevant few\-shot examples \(e\.g\., 3 examples\) from the training set that exhibit the highest semantic affinity and structural alignment, serving as in\-context prompts to precisely guide the subsequent SQL deduction and generation\.

\(3\) Candidate Generation Stage: This stage concurrently feeds the heterogeneous schema representations, varied filtering results, raw user questions, and retrieved few\-shot examples into the generator LLM\. By triggering parallel greedy decoding, it efficiently constructs a diverse ensemble of candidate SQL queries, thereby successfully eliminating the reliance on expensive Chain\-of\-Thought \(CoT\) or temperature sampling\.

\(4\) Candidate Selection Stage: This strategy employs a confidence\-aware two\-stage selection mechanism\. First, it applies regular majority voting across the candidate SQL queries, treating the vote distribution as a confidence metric—whereby absolute dominant results with high confidence are directly outputted\. For ambiguous scenarios characterized by tied or close votes indicating low confidence, it further invokes an LLM\-based pairwise ensemble voting process for the final arbitration\.

## Appendix BSDAMDetails

### B\.1Schema Variants Setting

To enrich the expression forms of database schemas and broaden the search breadth of the reasoning tree, we incorporate a diverse combination of schema formats and filtering granularities in our experiments\. Specifically, we configure five core schema variant settings, as detailed in Table[7](https://arxiv.org/html/2608.12338#A2.T7)\. These variants encompass MAC\-Schema, M\-Schema, and traditional DDL formats, each paired with one of four distinct reduction strategies: No Filtering, Column\-level Filtering \(Col\. Filtering\), Table\-level Filtering \(Table Filtering\), and Full Filtering\. By providing such heterogeneous representational designs, this setup effectively stimulates highly diverse reasoning paths, thereby fundamentally expanding the search space of the reasoning tree\.

### B\.2Reasoning Tree Construction Details

Upon obtaining multiple diverse reasoning paths via sampling, we employ the Mermaid language as an intermediate representation to construct the structured Reasoning Tree\. Mermaid is a lightweight, text\-based declarative graphing language characterized by its simplistic, intuitive syntax and low parsing overhead\. Its naturally text\-driven format makes it exceptionally LLM\-friendly, allowing the large language model to precisely articulate complex hierarchical topologies with minimal token expenditure\.

Specifically, to guide the LLM in accurately mapping divergent inference trajectories into a cohesive tree structure, we manually curate a high\-quality, comprehensive exemplar\. This exemplar demonstrates the exact transformation from a set of candidate SQL paths containing strategic variations into standard Mermaid code, serving as a strict1\-shotdemonstration prompt\. Combined with this task\-specific anchoring, the system dynamically synthesizes the target database schema, the user query, and the sampled reasoning paths into a unified instruction\. The LLM then adaptively generates the corresponding Mermaid syntax, seamlessly realizing the final conflict\-aware Reasoning Tree\.

Table 7:Schema representation formats and corresponding filtering levels used in our experiments\.Table 8:Reasoning Nodes Table in Structure\-Difference Aware Reasoning TreeTable 9:Performance comparison between baseline andSDAM\-SQLacross different model scales on Archer\.Boldindicates the best performance\.Table 10:Case analysis on representative databases from the BIRD dataset\. The "debit\_card" database in Bird is "debit\_card\_specializing"\.Boldindicates the best performance\.Table 11:A case study of theSDAMconstruction process, illustrating how the model performs Structure\-Difference Aware Reasoning Tree analysis, Contradiction\-Aware Reflection, and Schema\-Grounded Memory Evolution to construct SDAM\.Table 12:A case study of SDAM usage, showing how retrieved SDAM guides the model from an incorrect SQL structure to the correct SQL query\.
### B\.3Detailed Mechanism of Contradiction Detection

To enable the proposedSDAMto effectively capture and evolve structured semantic knowledge from instance\-level errors, we design a comprehensive contradiction detection pipeline\. During the reasoning and evolution stages, contradictions are systematically identified across three primary dimensions:

- •Inter\-Structure Contradictions within the Reasoning Tree:This dimension focuses on detecting logical divergences between alternative reasoning paths\. By exploring two or more sibling branches originating from the same parent node within the reasoning tree, the system identifies conflicts in execution strategies\. For instance, one branch might employ a float conversion before a division operation \(e\.g\.,CAST\(total\_score AS FLOAT\) / count\), whereas another sibling branch directly performs integer division\. Identifying such calculative discrepancies allows the framework to explicitly weigh the structural validity of different reasoning paths\.
- •Semantic\-Schema Mismatches:These contradictions occur when the generated candidate SQL query violates the underlying constraints or data formats defined in the database schema\. This encompasses column\-level inconsistencies caused by shallow surface semantics \(e\.g\., referencingStudent\_Namewhile the schema explicitly defines it asFull\_Name, which triggers execution failures\), as well as data\-format discrepancies where the SQL filters rows using a date string \(e\.g\.,’2024\-01\-01’\) while the database stores chronological data as an integer representation \(e\.g\.,20240101\), yielding incorrect empty results\.
- •Execution\-Intent Contradictions:Even when a candidate SQL query is syntactically valid and executes successfully, its final return values may conflict with the user’s natural language intent\. This manifests either as a value mismatch that fails to address the quantitative target of the question \(e\.g\., returning the “total sum” when the user inquires about the “average score”\), or as a column omission that fails to return the full set of requested attributes \(e\.g\., projecting only school names viaSELECT namewhen the query explicitly demands to “list the name and address of all schools”\)\.

## Appendix CSupplementary Experiment

### C\.1Experiments on Archer Dataset

To further evaluate the generalization performance ofSDAM\-SQLin highly sophisticated reasoning scenarios, we conduct extended experiments on theArcherZhenget al\.\([2024](https://arxiv.org/html/2608.12338#bib.bib40)\)benchmark\. Archer is a cross\-domain bilingual dataset specifically designed for complex reasoning, comprising 1,042 English and Chinese questions respectively, paired with 521 unique SQL queries\. By explicitly incorporating arithmetic, common\-sense, and hypothetical reasoning, Archer introduces a substantial shift in structural and logical complexity\. Experimental results \(Table[9](https://arxiv.org/html/2608.12338#A2.T9)\) reveal thatSDAM\-SQLdelivers its most pronounced performance leap on this challenging benchmark\. Notably, when deployed on the Qwen2\.5\-Coder\-14B backbone, our method drives a substantial execution accuracy \(EX\) improvement of5\.77%, while on the strongest backbone, the performance scales up to a peak of36\.54%\. This substantiates that the historical expertise accumulated via our structured memory evolution effectively empowers LLMs to navigate severe multi\-step cross\-domain reasoning bottlenecks\.

### C\.2Single\-Database Analysis

Table[10](https://arxiv.org/html/2608.12338#A2.T10)presents the evaluation results ofSDAM\-SQLacross several representative individual databases\. Incorporating the memory evolution framework leads to significant performance boosts: the EX accuracy ondebit\_card\_specializingescalates from54\.69%54\.69\\%to70\.31%70\.31\\%\(a15\.63% gain\), whiletoxicologyandsuperheroexhibit improvements of10\.34% and10\.07%, respectively\.

Analysis indicates that these databases generally lack comprehensive schema documentation and feature highly specialized domain\-specific semantics \(e\.g\., credit card transactions or toxicology\)\. Consequently, conventional methods are highly susceptible to semantic errors by on surface\-level schema information\. In contrast, leveraging contradiction\-driven memory distillation,SDAM\-SQLprogressively abstracts robust domain rules and implicit constraints from erroneous cases\. Reusing such deep semantic knowledge effectively guides downstream complex reasoning and schema item selection, significantly boosting the model’s generalization capabilities in specialized professional scenarios\.

## Appendix DCase Study

### D\.1SDAM Construction

Table[11](https://arxiv.org/html/2608.12338#A2.T11)presents a case study of the SDAM construction process\. The model first builds a Structure\-Difference Aware Reasoning Tree by generating multiple candidate reasoning paths\. The reasoning divergence occurs at theSegment Filternode, where the incorrect branch introduces unnecessary joins and mistakenly treatsPremiumas a product description\.

Based on this divergence, Contradiction\-Aware Reflection identifies the semantic inconsistency betweenproducts\.Descriptionand gas station segment information\. Finally, the Schema\-Grounded Memory Evolution mechanism binds the extracted knowledge to schema anchors such asgasstations\.Countryandgasstations\.Segment, producing reusable schema\-grounded memory for SQL generation\.

### D\.2SDAM Usage

Table[12](https://arxiv.org/html/2608.12338#A2.T12)presents a case study of SDAM usage during SQL generation\. Without memory, the baseline model produces an invalid SQL query that fails to capture the schema structure and task semantics\. Specifically, the generated SQL contains irrelevant aggregation logic and does not correctly model the relationship between customers, currency constraints, and yearly gas consumption\.

After retrieving relevant SDAM, the model successfully recalls reusable reasoning patterns, including aggregatingSUM\(Consumption\)grouped byCustomerID, filtering records in 2011, and joining thecustomersandyearmonthtables throughCustomerID\. Guided by the retrieved schema\-grounded memory, the model generates the correct SQL query and accurately identifies the target customer\. This case demonstrates that SDAM can effectively transfer historical reasoning experience to subsequent Text\-to\-SQL tasks, thereby improving structural reasoning and schema alignment\.

## Appendix EPrompts

In this section, we present the explicit prompt templates utilized duringSDAMconstruction\. To ensure rigorous reproducibility, all system prompts are detailed in their original configurations\.

Specifically, the instruction for Candidate Generation, Contradiction\-Aware Reflection, Memory Extraction, and Schema\-Grounded Memory Filtering are illustrated in Figure[3](https://arxiv.org/html/2608.12338#A5.F3), Figure[4](https://arxiv.org/html/2608.12338#A5.F4), Figure[5](https://arxiv.org/html/2608.12338#A5.F5), and Figure[6](https://arxiv.org/html/2608.12338#A5.F6), respectively\.

Generator PromptYou write SQL queries for a \{sql\_dialect\} database\. Users are querying their company database, and your task is to assist by generating valid SQL queries strictly adhering to the database schema provided\.The user will provide you with a query intent, an SQL template, and optionally an hint to help create the correct SQL\. They may also provide a set of examples similar to their query from other databases, which should guide your understanding and solution\.Translate the user’s request into one valid \{sql\_dialect\} query\.When generating responses, you must first provide a chain\-of\-thought explanation detailing how you derived the query, referencing the user intent and schema\.\#\#\# Guidelines:1\. \*\*Chain\-of\-Thought Approach \(Mandatory\)\*\*:\- Use \*\*numbered steps\*\* \(1\., 2\., 3\., etc\.\) in the "reasoning" field\.\- Begin by carefully analyzing the user’s query and the examples provided\.\- Understand the user’s intent step by step\.\- Compare the query to the examples to identify similarities and patterns\.\- Use these insights to reason through the structure of the SQL query\.\- Briefly explain your reasoning before generating the query\.Example:\- Intent: "Find all orders placed in the last month by active customers\."\- Steps:1\. Review the provided examples for patterns \(e\.g\., filtering by time, joining specific tables, conditions on customer status\)\.2\. Identify the relevant tables: ‘orders‘ and ‘customers‘\.3\. Filter ‘orders‘ for those created in the last month using the ‘created\_at‘ column\.4\. Join ‘customers‘ with ‘orders‘ on ‘customer\_id‘\.5\. Filter ‘customers‘ where ‘status = ’active’‘\.2\. \*\*Knowledge Handling \(EKE\)\*\*:\- \*\*Essential Knowledge Evidence \(EKE\)\*\*: This is the most critical, question\-specific information \(e\.g\., entity mappings\)\. Prioritize EKE for specific fact\-finding\.3\. \*\*Semantic Integrity \(Crucial\)\*\*:\- \*\*Avoid Over\-Engineering\*\*: Do not let supplementary information \(EKE\) alter the fundamental semantic meaning of the user’s question\.\- \*\*Stay Focused\*\*: If an external hint suggests a complex statistical approach \(like ‘GROUP BY‘ or ‘COUNT‘\) for a simple identification question, or an exclusive logic \(like "only contains"\) for a general existence question, you must prioritize the \*\*original query intent\*\*\.\- \*\*Simplicity Principle\*\*: Use the simplest SQL structure that satisfies the user’s question unless complexity is explicitly required by the intent or EKE\. Do not add redundant columns, joins, or aggregations based on irrelevant hints\.4\. \*\*Schema Adherence\*\*:\- Use only tables, columns, and relationships explicitly listed in the provided schema\.\- Do not make assumptions about missing or inferred columns/tables\.5\. \{dialect\_guidelines\}6\. \*\*Conditions\*\*:\- Always include default conditions for filtering invalid data, e\.g\., ‘deleted\_at IS NULL‘ and ‘status \!= ’cancelled’‘ if relevant\.\- Ensure these conditions match the query’s intent unless explicitly omitted in the user request\.7\. \*\*Output Consistency\*\*:\- The output fields must match the query’s intent exactly\. Do not add extra columns or omit requested fields\.\- For aggregations, ensure correct logic \(e\.g\., ‘AVG‘, ‘SUM‘\) and group only by required fields\.8\. \*\*Reserved Keywords and Case Sensitivity\*\*:\- Escape reserved keywords or case\-sensitive identifiers using double quotes \(‘" "‘\), e\.g\., ‘"order"‘\.If the user’s question is ambiguous or unclear, you must make your best reasonable guess based on the schema\.Translate the user’s intent into a \*\*single valid sql\_dialect\} query\*\* based on the schema provided\. Pay special attention to the examples given by the user\.Ensure the query is optimized, precise, and error\-free\.\#\#\# Output Constraint:The output must be a single, valid JSON object\. Strictly avoid including any analysis text or explanations outside of the JSON structure\.The response must begin with "“‘json\{" and end with "“‘"\.Schema\_description: \{schema\_description\}Question: \{question\}Evidence: \{evidence\}Respond with JSON:“‘json\{"reasoning": "<step\-by\-step chain of thought\>","final\_SQL": "<SQL query\>"\}“‘Figure 3:Generator PromptReflector Prompt\# You are a \*\*Senior Domain\-SQL Analyst\*\*\. Your core mission is \*\*"Conflict\-Driven Reflection and Domain Knowledge Extraction"\*\*\.\# You act as a logic forensic expert, diagnosing failures by merging multiple reasoning paths into a single \*\*Logic Tree\*\* to identify the exact "Singularity of Failure\."\#\#\# Field Definitions for Reasoning Output:\- ‘reasoning\_tree\_mermaid‘: A \*\*Mermaid\.js \(graph TD\)\*\* visualization\. It must map the shared logical root and branch out at points of divergence \(e\.g\., Table Selection, Join Predicates, Aggregation logic\)\. Pruned \(incorrect\) branches must be styled for visual contrast\. \*\*Keep it as simple as possible, but you MUST map the logic paths of ALL candidates to show where each one succeeded or failed\.\*\*\- ‘sql\_vs\_schema\_conflict‘: Forensic analysis of the gap between \*\*SQL Syntax/Logic\*\* and \*\*Database Schema\*\*\. Check for hallucinations in table/column names, invalid JOIN paths, or misuse of data types \(e\.g\., applying string functions to numeric IDs\)\.\- ‘execution\_vs\_question\_conflict‘: Forensic analysis of the gap between \*\*Execution Results\*\* and the \*\*Target Inquiry\*\*\. Evaluate if the output data actually satisfies the user’s intent \(e\.g\., if a 0 result is due to a filter error, or if the result format violates the question’s constraints\)\.\- ‘conflict\_analysis‘: A deep\-dive forensic report on the \*\*Divergence Point\*\*\. Explain \*why\* the pruned paths failed—whether due to misunderstood domain constraints, temporal logic errors, or SQL syntax misuse\.\- ‘most\_correct\_candidate‘: The unique ID of the candidate that survived the horizontal audit and aligns perfectly with the Schema truth\. \*\*\[CRITICAL RULE\]: If all candidates contain logical errors or violate schema constraints, enter "NONE" in this field\.\*\*\- ‘key\_insights‘: A collection of "Golden Rules\." These are distilled, reusable domain truths or SQL patterns discovered during the conflict resolution\.\#\#\# \[\*\*reasoning\_tree\_mermaid\*\* Reference Example\]\*\*Input Candidates\(2 Candidates\):\*\* \{candidates\_example\}\*\*Expected Logical Tree Construction:\*\* \{tree\_example\}\#\#\# Output Constraint:Output a single JSON object\. Start with "“‘json\{" and end with "\}“‘"\. No conversational filler\.\#\#\# \[Forensic Context\]\- \*\*Database ID\*\*: \{db\_id\}\- \*\*Schema\*\*: \{schema\_description\}\- \*\*Target Inquiry\*\*: \{question\}\#\#\# \[Candidates to Audit\]\{predict\_messages\}—\#\#\# \[Audit Task\]\- Merge the reasoning paths of the candidates into a single logical tree\. Pinpoint the node where the logic diverges and determine which path adheres to the database schema and business domain rules\.\- Analyze why the pruned paths failed—whether due to misunderstood domain constraints, temporal logic errors, or SQL syntax misuse\.\- Analyze the sql and execution results of the most correct candidate to ensure it fully satisfies the original question\.\- Extract reusable "Golden Rules" from each resolved conflict\.Respond strictly in JSON format:“‘json\{ "reasoning\_tree\_mermaid": "graph TD;n Root\[Intent\] –\> Common\[Common Logic\];n Common –\> NodeA\[Correct Path\];n Common –\> NodeB\[Incorrect Path\];n style NodeB fill:\#f96,stroke:\#333;", "tree\_conflict\_analysis": "<Analyze the Divergence Node\. Explain why one branch was pruned based on domain logic or schema constraints\.\>","sql\_vs\_schema\_conflict": "<Analysis of the gap between SQL Syntax/Logic and Database Schema: e\.g\., hallucinated table/column names, invalid JOIN paths, misuse of data types\.\>","execution\_vs\_question\_conflict": "<Analysis of the gap between Execution Results and Question Intent\>","most\_correct\_candidate": "<Candidate ID\>","key\_insights": \["<Golden Rule 1\>", "<Golden Rule 2\>", "…"\],"question": "\{question\}" \}“‘Figure 4:Reflector Prompt \(Simplified\)Extractor PromptYou are the \*\*Extractor\*\* for the \*\*Domain\-Specific Text\-to\-SQL memory bank\*\*\. Your core mission is to transform \*\*"Conflict\-Driven Reflections"\*\* into structured, defensive memory updates\.You must act as a knowledge architect, analyzing the \*\*Reasoning Tree\*\* and \*\*Conflict Analysis\*\* to identify where the model’s logic typically collapses and how to prevent it\.\#\#\# Core Philosophy:Every pruned branch in a reasoning tree is a hidden domain trap\. Your job is to extract the "Golden Path" and document the "Pruning Rules" so the model avoids those traps in the future\.\#\#\# Content Guidelines:1\. \*\*Focus on Divergence Nodes\*\*: Pay special attention to the ‘conflict\_analysis‘ and the ‘reasoning\_tree\_mermaid‘ from the reflection\. Extract knowledge that explains why one path was chosen over another\.2\. \*\*Handle ’NONE’ Scenarios\*\*: If no correct candidate exists, focus on the \*\*Common Fatal Flaw\*\*\. Extract instructions that explicitly warn against the collective mistake made by the models\.3\. \*\*Content Types\*\*:\* \*\*Domain Knowledge \(Entity Disambiguation\)\*\*: Clarify which columns/tables represent specific business concepts \(e\.g\., "Use ’Educational Option Type’ instead of ’StatusType’ for school categories"\)\.\* \*\*Calculation/Temporal Rules\*\*: Precise formulas, especially those involving conditional filtering or complex aggregations\.\* \*\*Defensive Syntax Rules\*\*: Specific SQL patterns to avoid common errors \(e\.g\., "Always verify if a filter value exists in the target column before joining"\)\.4\. \*\*Instructional Style\*\*: Content must be \*\*actionable\*\*\. Instead of saying "StatusType is wrong," say "To identify Continuation Schools, filter the ’frpm’ table using ’Educational Option Type’ = ’Continuation School’\."\#\#\# Output Constraint: Output a single JSON object\. Start with "“‘json\{" and end with "\}“‘"\. No conversational filler\.\[Metadata\]Domain \(db\_id\): \{db\_id\}Question: \{question\_context\}\[Reference Knowledge \(Schema & Examples\)\]Schema: \{schema\_description\}Existing Style: \{examples\}\[Input: Conflict\-Driven Reflection\]Fields Definition:\- ‘reasoning\_tree\_mermaid‘: A Mermaid\.js \(graph TD\) visualization mapping the shared logical root and branching at divergence points\.\- ‘tree\_conflict\_analysis‘: Analysis of the divergence node explaining why one branch was pruned\.\- ‘sql\_vs\_schema\_conflict‘: Analysis of gaps between SQL syntax/logic and database schema\.\- ‘execution\_vs\_question\_conflict‘: Analysis of gaps between execution results and target inquiry\.\- ‘most\_correct\_candidate‘: The unique ID of the candidate that survived the audit\. If all candidates are incorrect, this will be "NONE"\.\- ‘key\_insights‘: A collection of "Golden Rules" distilled during conflict resolution\.Reflection: \{reflection\}\#\#\# \[Instruction\]Analyze all fields in reflection\.1\. Identify the \*\*Divergence Point\*\* \(where the model chose the wrong table/column\)\.2\. Extract a list of \*\*Positive Rule\*\* \(What to do\) and a \*\*Negative Constraint\*\* \(What to avoid\) from tree\_conflict\_analysis, sql\_vs\_schema\_conflict, and execution\_vs\_question\_conflict\.3\. Format these into a list of operations to \*\*ADD\*\* to the memory bank\.Respond strictly in JSON format:“‘json\{ "reasoning": "<Analyze the Divergence Node in the reasoning tree and all conflict analyses to extract actionable memory bank updates\.\>","operations": \[\{"type": "ADD","section": "\{db\_id\}","content": "<Concise, instructive rule derived from the conflict\. Format: ’To \[Goal\], use \[Column/Logic\], avoiding \[Common Pitfall\]\.’\>","condition": "<Trigger schema and keywords\. Format: ’When query involves \[Tables/Columns\] and intent is \[Scenario\]’\>","correction": "<Actionable SQL refinement\. Format: ’Change \[Wrong Logic\] to \[Correct Logic\] because \[Semantic Reason\]’\>""tags": \["table:column", …\],"metadata": \{"helpful": 1, "harmful": 0\}\} \],"question": "\{question\_context\}" \}“‘Figure 5:Extractor PromptFilter PromptYou are an expert \*\*Knowledge Verification Specialist\*\* for Text\-to\-SQL systems\. Your mission is to act as a \*\*"Semantic Gatekeeper"\*\*, ensuring every piece of knowledge is factually anchored in the Database Schema and the Trusted Knowledge Pool\.\#\#\# Core Philosophy:A single piece of incorrect domain knowledge is more harmful than no knowledge at all, as it leads to "Confident Hallucinations" in SQL generation\. You must be merciless in pruning any entry that lacks direct evidence in the Schema or Samples\.\#\#\# Core Responsibilities:1\. \*\*Structural Truth\*\*: Reject any knowledge referencing tables or columns not present in the provided Schema\.2\. \*\*Semantic & Value Alignment \(Highest Priority\)\*\*:\* \*\*Enum/Value Matching\*\*: If knowledge suggests a filter like ‘Status = ’Success’‘, but Schema samples show values like ‘1/0‘ or ‘True/False‘, reject it as a factual hallucination\.\* \*\*Unit/Scale Consistency\*\*: Ensure metrics \(e\.g\., currency, duration, weight\) match the Schema’s defined units \(e\.g\., ’minutes’ vs ’seconds’\)\.\* \*\*Data Type Integrity\*\*: Prevent treating categorical strings as sortable numbers or vice versa\.3\. \*\*Logic\-Path Validation\*\*: Verify that the "Pruning Rules" or "Golden Rules" in the candidate knowledge do not contradict the Trusted Knowledge Pool\.4\. \*\*Disambiguation\*\*: If the Schema has multiple columns with similar names \(e\.g\., ‘create\_at‘ vs ‘update\_at‘\), ensure the knowledge correctly specifies which one to use for a given intent\.\#\#\# Output Constraint:Output a single JSON object starting with "“‘json\{" and ending with "\}“‘"\. No conversational filler\.\#\#\# \[Verification Inputs\]\*\*1\. Database Schema \(Ground Truth\):\*\* \{schema\_description\}\*\*2\. Trusted Knowledge Pool:\*\* \{evidences\}\*\*3\. Candidate Knowledge to Verify:\*\* \{content\}—\#\#\# \[Verification Protocol\]Perform a deep forensic audit on the "Candidate Knowledge" using these steps:1\. \*\*Existence Check\*\*: Verify that all table and column identifiers are 100% identical to the Schema\.2\. \*\*Value & Type Audit\*\*: Compare any literal values \(e\.g\., ’Continuation School’, ’Active’\) against the Schema’s samples/enums\. Are they formatted correctly? Do they exist in the data?3\. \*\*Semantic Conflict Test\*\*: Does the logic align with the \*meaning\* of the Schema? \(e\.g\., If the candidate says "filter by status", does that status column actually represent the business state described?\)4\. \*\*Redundancy & Conflict Check\*\*: Does this add new value, or does it contradict the Trusted Knowledge Pool?Respond strictly in JSON format:“‘json\{"reasoning": "<Forensic Analysis: 1\. Confirm structural existence\. 2\. Identify value/unit mismatches \(e\.g\., ’Candidate suggests filtering column A with value B, but Schema samples show values C and D’\)\. 3\. Justify the final filter outcome\.\>","filtered\_knowledge": "<The purified, factually\-anchored knowledge\. Keep it concise and instructional\. Return an empty string if any core part is hallucinated\.\>"\}“‘Figure 6:Filter Prompt