Dial: A Knowledge-Grounded Dialect-Specific NL2SQL System

This paper introduces Dial, a knowledge-grounded framework that addresses the challenges of generating executable SQL across heterogeneous database systems by employing dialect-aware logical planning, a hierarchical intent-aware knowledge base, and an execution-driven debugging loop, achieving significant improvements in translation accuracy and dialect feature coverage on the newly constructed DS-NL2SQL benchmark.

The Gist

Imagine you are a master chef (the AI) who needs to cook a specific dish (a database query) for a customer. The customer gives you a simple description: "I want a spicy soup with chicken and carrots."

In the world of databases, this is called NL2SQL (Natural Language to SQL). The problem is that every restaurant (database system like Oracle, MySQL, or PostgreSQL) has its own dialect.

• Restaurant A says: "You can't use salt; use soy sauce instead."
• Restaurant B says: "You must chop the carrots before adding them, or the pot explodes."
• Restaurant C says: "If you want spicy, you must add the pepper after the soup boils, not before."

Most existing AI chefs are trained only on Restaurant A's menu. If you ask them to cook for Restaurant B, they might bring the wrong ingredients, use the wrong knife, or ignore the safety rules, causing the kitchen to shut down (an error).

"Dial" is a new, super-smart kitchen manager designed to solve this. Here is how it works, broken down into simple steps:

1. The "Universal Recipe Card" (Dialect-Aware Logical Query Planning)

Instead of immediately shouting out the specific ingredients for a specific restaurant, Dial first translates the customer's request into a universal, abstract recipe.

• Analogy: Instead of saying "Add 2 cups of soy sauce," it writes: "Add a salty liquid seasoning."
• Why it helps: This separates the intent (what the user wants) from the syntax (how the specific database says it). It ensures the chef understands the goal before worrying about the specific rules of the kitchen.

2. The "Giant Rule Book" (HINT-KB)

Dial doesn't just guess; it carries a massive, organized library called HINT-KB. Think of this as a library with three specific sections:

• The Dictionary: Tells you that "Soy Sauce" in Restaurant A is called "Salt" in Restaurant B.
• The Safety Manual: Reminds you that in Restaurant C, you cannot put the lid on while the soup is boiling (a hidden rule).
• The Cheat Sheet: Shows you exactly how to chop carrots for Restaurant D so they don't burn.
• Why it helps: Most AI models try to memorize these rules in their brain. If they forget, they hallucinate. Dial looks them up in a structured book, ensuring it never mixes up the rules.

3. The "Taste Test & Fix" Loop (Adaptive Debugging)

Even with a recipe and a book, mistakes happen. Maybe the chef used a slightly wrong knife.

• The Old Way: If the soup tastes bad, the AI just guesses a new recipe from scratch, often changing the flavor entirely (e.g., turning soup into a salad).
• The Dial Way: Dial runs the query in the database. If the database says, "Error! You can't use soy sauce here," Dial doesn't panic.
  1. It checks the Rule Book to see the correct ingredient.
  2. It swaps the ingredient.
  3. Crucially: It checks the Universal Recipe Card to make sure it didn't accidentally change the soup into a salad while fixing the salt. It keeps the flavor (logic) the same while fixing the ingredients (syntax).

4. The "Learning Kitchen" (Incremental Knowledge)

Every time Dial fixes a mistake, it writes a new note in its Rule Book.

• Analogy: If a new chef joins and learns that "Restaurant X hates cilantro," Dial writes that down so the next time someone orders for Restaurant X, it remembers immediately. It gets smarter over time without needing to be retrained from scratch.

The Result?

The researchers tested Dial on six different "restaurants" (databases like Oracle, MySQL, PostgreSQL, etc.).

• Old AI Chefs: Often failed because they tried to use MySQL rules in an Oracle kitchen, leading to broken dishes (errors).
• Dial: Successfully cooked the dish correctly in almost every kitchen, using the right local ingredients and following all local safety rules.

In short: Dial is a translator that doesn't just translate words; it translates intent while respecting the unique grammar, laws, and quirks of every specific database system, ensuring the final result actually works.

Technical Summary

Here is a detailed technical summary of the paper "Dial: A Knowledge-Grounded Dialect-Specific NL2SQL System".

1. Problem Definition

The paper addresses the critical gap in existing Natural Language to SQL (NL2SQL) systems: dialect specificity. While most current methods target a single dialect (typically SQLite or MySQL), real-world enterprises often deploy heterogeneous database systems (e.g., Oracle, PostgreSQL, SQL Server, DuckDB), each with distinct syntax rules, built-in functions, and execution constraints.

Key Challenges Identified:

• C1: Intent-to-Syntax Mapping: Users express intent dialect-agnostically (e.g., "calculate months since registration"), but the required operators vary significantly (e.g., TIMESTAMPDIFF in MySQL vs. nested EXTRACT/AGE in PostgreSQL).
• C2: Implicit Constraints: Queries often fail due to dialect-specific compilation rules not explicitly stated in the prompt (e.g., ORDER BY restrictions under SELECT DISTINCT in PostgreSQL, or argument limits in Oracle's CONCAT).
• C3: Correction & Adaptation: Existing correction strategies often cause "semantic drift" (altering the user's intent to fix syntax) or lack a mechanism to learn from repairs for future queries.

2. Methodology: The Dial Framework

Dial is a knowledge-grounded framework designed to decouple logical intent modeling from dialect realization. It consists of three core modules:

A. Dialect-Aware Logical Query Planning (NL-LQP)

Instead of generating SQL directly, Dial first converts the user's natural language query into a Natural Language Logical Query Plan (NL-LQP).

• Decomposition: The query is broken down into a linearized chain of standardized, dialect-agnostic macro-operators (e.g., Data Sourcing, Filtering, Scalar Calculation, Aggregation, Result Organization).
• Implicit Logic Mining: The system identifies missing intermediate steps (e.g., detecting that a text column needs casting to numeric before aggregation) based on schema metadata.
• Divergence-Aware Specification: The system identifies which operators are "dialect-sensitive" and maps them to standardized functional categories (e.g., [String_Processing], [Temporal_Manipulation]). This creates a precise blueprint for SQL generation that separates what needs to be done from how the specific database does it.

B. Hierarchical Intent-Aware Knowledge Base (HINT-KB)

To bridge the gap between abstract intent and concrete syntax, Dial constructs a structured knowledge base from official vendor documentation. It is organized into three layers:

1. Canonical Syntax Reference: Normalizes operations into 11 universal categories (e.g., Date & Time Operations) to reduce storage complexity.
2. Declarative Function Repository ($\mathcal{F}_{func}$): Maps abstract intents to specific dialect implementations (e.g., mapping "age calculation" to TIMESTAMPDIFF for MySQL or AGE for PostgreSQL), indexed by natural language usage patterns.
3. Procedural Constraint Repository ($\mathcal{R}_{rule}$): Encodes implicit structural rules and compilation constraints (e.g., quoting conventions, aliasing rules) indexed by diagnostic error signatures. This allows the system to retrieve specific fixes when execution fails.

C. Adaptive & Iterative Debugging and Evaluation

Dial employs a closed-loop generation process:

1. Knowledge-Grounded Initialization: Generates an initial SQL query by retrieving templates from $\mathcal{F}_{func}$ based on the NL-LQP.
2. Adaptive Syntactic Recovery: If execution fails, the error message triggers a retrieval from $\mathcal{R}_{rule}$ to apply specific transformation rules (e.g., changing LIMIT to FETCH FIRST for Oracle).
3. Semantic Logic Verification: Once the query is executable, it is audited against the original NL-LQP to ensure no semantic drift occurred during the repair process.
4. Incremental Knowledge Consolidation: Successful repair trajectories are distilled into new rules and fed back into HINT-KB, allowing the system to learn and improve autonomously.

3. Key Contributions

1. Framework Design: Proposes Dial, the first framework to explicitly decouple semantic intent from dialect realization using a logical query plan and execution-driven verification.
2. Knowledge Architecture: Introduces HINT-KB, a hierarchical knowledge base that separates functional syntax mappings from implicit procedural constraints, enabling automated knowledge distillation from documentation.
3. NL-LQP Abstraction: Defines a strictly linearized, dialect-agnostic operator chain that normalizes free-form user intent into structured relational operators.
4. Benchmark Creation: Constructs DS-NL2SQL, a new benchmark covering six major database systems (SQLite, PostgreSQL, MySQL, SQL Server, DuckDB, Oracle) with 2,218 dialect-specific test cases, focusing on dialect incompatibility and execution equivalence.
5. Performance Gains: Demonstrates significant improvements in translation accuracy and dialect feature coverage compared to state-of-the-art baselines.

4. Experimental Results

The authors evaluated Dial against three categories of baselines: Prompt-based (DIN-SQL, Agentar), Fine-tuned models (EXESQL), and Tool-augmented translators (SQLGlot, Dialect-SQL).

• Overall Performance: Dial achieved an overall Execution Accuracy (Acc) of 48.39% and Executability (Exec) of 97.33% across all six dialects under a strict "all-or-nothing" evaluation metric.
• Improvement over SOTA:
  • Translation Accuracy: Improved by 10.25% over the best baseline.
  • Dialect Feature Coverage (DFC): Improved by 15.77%, indicating Dial successfully uses native dialect features rather than generic fallbacks.
• Robustness: Dial significantly outperformed fine-tuned models (which suffered from overfitting to MySQL) and rule-based tools (which failed on complex nested queries) in challenging dialects like Oracle and DuckDB.
• Ablation Studies: Confirmed that removing any core component (Logical Planning, HINT-KB, or Debugging loop) caused significant performance drops, particularly in DFC and Executability.

5. Significance

• Enterprise Readiness: The system directly addresses the practical needs of enterprises managing heterogeneous database environments, moving beyond the "SQLite-only" assumption of most research.
• Semantic Fidelity: By separating syntax recovery from logic auditing, Dial solves the "semantic drift" problem common in iterative correction methods, ensuring the final SQL answers the user's original question.
• Scalability: The knowledge-grounded approach allows for the addition of new dialects without retraining the underlying LLM, simply by updating the HINT-KB with vendor documentation.
• Benchmarking: The introduction of DS-NL2SQL provides a rigorous standard for evaluating dialect-specific capabilities, highlighting the limitations of current benchmarks that ignore dialect nuances.

In conclusion, Dial represents a paradigm shift in NL2SQL research, moving from monolithic generation to a modular, knowledge-grounded, and execution-verified approach that ensures both syntactic validity and semantic correctness across diverse database ecosystems.