UniQL

問題定義 — 被 SQLite 遮住的那一半

現有的 text-to-SQL benchmark 幾乎全部跑在 SQLite 上。但真實世界的資料庫是 PostgreSQL、Oracle、Hive、Teradata、ClickHouse⋯⋯每一種的語法、內建函式、型別系統與執行語意都不一樣。於是一個很基本的問題從來沒被正面量測過：模型能不能把同一個意圖，在不同資料庫系統上都寫對？

SQL 生態其實是碎裂的

經過數十年的標準化努力，SQL 生態依然高度分裂。各家引擎雖然都採用類 SQL 介面，但在語法、內建函式與最佳化行為上差異巨大——語意等價的查詢常常需要方言專屬的寫法，SQL 的可攜性一直是真實資料系統裡的老問題。

與此同時，LLM 把資料互動從「以 SQL 為中心」推向「以自然語言為中心」。使用者直接用自然語言表達查詢意圖，不再需要手寫方言專屬的 SQL。這帶來一個誘人的可能性：自然語言成為跨異質資料庫系統的統一介面（unified interface）。在 data agent 與自動化分析的時代，一個使用者請求可能同時涉及查詢、整合、操作多個不同的資料庫後端，而不是只面對單一系統。

但現有 benchmark 量不到這件事

問題在於，目前的 text-to-SQL 評估仍然以 SQLite 為主：

• Spider（Yu et al., 2018）與 BIRD（Li et al., 2023）主要聚焦 SQLite 執行，無法評估可執行的跨系統泛化能力。
• Spider 2.0（Lei et al., 2025）確實引入了企業級、跨多個資料庫系統的 text-to-SQL 工作流，但它的任務是系統專屬（system-specific）的，而不是「同一組自然語言意圖在各方言下的對齊實現」。因此它無法把方言差異，從 schema、任務、資料庫環境的差異中分離出來。

一個在某方言可執行且語意正確的查詢，換到另一個系統可能直接失敗、行為改變，或需要大幅改寫——原因包含執行語意、函式庫、排序行為、隱式型別轉換、聚合規則與方言專屬語法的差異。結果是：目前的 benchmark 設定可能高估了 text-to-SQL 系統的穩健性與普適性，同時忽略了它們對方言變異的敏感度。

三個貢獻

與相關工作的分界

另一條相關的研究線是 SQL 方言翻譯：SQLGlot、JOOQ、SQLines 這類規則式系統依賴人工維護的方言映射；MALLET（Ngom & Kraska, 2024）、RISE（Xie et al., 2026）、CrackSQL（Zhou et al., 2025）則導入 LLM、執行回饋或方言專屬規則。PARROT（Zhou et al., 2026）進一步評估跨系統的 SQL-to-SQL 翻譯。

這些工作與 UniQL 互補而非重疊：它們關注的是 SQL → SQL 的可攜性；UniQL 評估的是模型能否在對齊的跨方言條件下，直接從自然語言生成可執行的方言專屬 SQL。

注意 UniQL 刻意不追求問題數量：它的問題數比 BIRD 少一個數量級，但把每一題展開成 16 個方言實現。這個 trade-off 就是整篇論文的設計主張——要量測方言泛化，必須犧牲題數換取對齊性。

資料集建構 — 五道關卡的混合式管線

建構高品質的跨方言 benchmark 遠不只是翻譯 SQL 字串。翻譯後的查詢必須在目標資料庫系統上真的能跑，而且必須保留原始自然語言問題的意圖。UniQL 的做法是：一層自動化管線攔下多數案例，攔不下的全部丟給人工。

2.1 資料庫遷移（Database Migration）

跨方言的可執行評估需要真的把 SQL 跑在實際的資料庫系統上，所以第一步是把原始 BIRD 資料庫遷移到每個目標系統。

雖然遷移的目標是盡可能保留原始 schema 與值，但一對一的精確遷移在異質 DBMS 之間並不總是可能：不同系統在型別名稱、識別字規則、大小寫敏感性、命名空間組織、保留字與支援的 constraint 上都有差異。例如有些系統透過 schema 或 user 組織資料，而不是獨立的 database namespace；有些系統對表名／欄位名有不同慣例。因此作者在遷移時做了輕量的 schema 與資料正規化：型別映射、識別字正規化、命名空間調整，以及必要的格式轉換。

2.2 自動翻譯與驗證

給定 NL 問題 x、來源 SQLite 查詢 q_s、來源資料庫 D_s、遷移後的目標資料庫 D_t，目標是構造出在方言 τ_t 下可在 D_t 執行、且保留 q_s 語意的查詢 q_t。

翻譯出的查詢接著送進執行式驗證（execution-based verification）。令 E(q, D) 表示查詢 q 在資料庫 D 上的執行結果，只有當翻譯結果在目標資料庫上成功執行、且結果與來源執行結果等價時，才會被自動接受：

當規則式翻譯無法被自動接受時，改由 LLM 翻譯器接手，其條件包含來源 SQL、目標 schema S_t、方言資訊與當前規則集 R：

若生成的查詢仍未通過等價驗證，模型進入有界的自我反思迴圈。在第 k 輪，回饋物件 F_k 包含前一次的目標 SQL、執行錯誤與結果不匹配資訊：

這個過程重複到查詢被自動接受，或達到最大輪數為止。實作上 LLM 翻譯器用的是 GPT-5-mini，每個失敗案例最多允許 3 輪執行回饋反思，之後就路由到後續建構階段。

2.3 迭代式翻譯規則演化（Iterative Translation Rule Evolution）

這是整條管線最有意思的一環：自動翻譯的失敗不被當成孤立的 query-level 錯誤處理，而是被收集成 failure log，抽象成可重用的方言轉換規則。

對每個目標方言，令 L_fail 為執行導引 refinement 後仍失敗的翻譯集合。這些失敗連同當前規則集 R^n 與方言文件 D_doc 一起被分析，產出更新後的規則集：

精煉後的規則集接著被納入後續的翻譯嘗試。這個回饋迴圈讓管線能漸進地處理重複出現的方言專屬失敗——函式改寫、型別轉換、日期時間操作、聚合行為、系統專屬語法約束等。作者用 Gemini-2.5-Pro 作為 rule summarizer，跑 3 輪規則演化。

管線因此結合了三種東西：確定性翻譯的效率、LLM 改寫的彈性，以及累積方言知識的可重用性。

2.4 人工驗證

經過自動翻譯、自我反思與規則精煉之後，剩下的案例送人工。人工驗證是最終的品質關卡，處理那些無法被自動執行驗證可靠接受的例子：真正的翻譯失敗、不受支援的方言構造，以及來源與目標執行結果因方言相依行為或原始 SQL 語意欠指定而不同的案例。

舉例來說：當查詢沒有完整指定 tie-breaking 時，不同系統可能回傳不同的 row order；重複敏感的輸出則需要超越單純集合比較的語意判斷。

整體而言，UniQL 的建構遵循「嚴格自動接受 + human-in-the-loop 驗證」策略：自動階段高效解決絕大多數翻譯，人工驗證處理需要語意判斷的長尾。這個流程為 15 個目標方言產出完整的可執行 SQL 覆蓋，加上原始 SQLite 標註，形成 16 方言的 benchmark。

資料統計 — 哪些方言真的難翻

涵蓋的 16 種方言為：SQLite, ClickHouse, Doris, Drill, Druid, DuckDB, Hive, MySQL, Oracle, PostgreSQL, Presto, Spark, StarRocks, Teradata, Trino, T-SQL。由於所有方言共享同一組 NL 問題、對齊的 schema 與資料庫內容，UniQL 能在不把方言變異與任務／schema／領域變異混淆的情況下，做受控的方言泛化評估。

SQLite 為來源方言，不經過建構管線。BIRD 難度切分在所有方言上都是 925 / 464 / 145。

評估協定 — 比 BIRD 更嚴格的 EX

UniQL 用 execution accuracy (EX) 作為主要指標，而且建構期的自動驗證與評估期的模型評測用的是同一套執行協定。但這個 EX 不是 BIRD 的 EX。

給定預測 SQL q̂、gold SQL q*、資料庫 B，先在同一個資料庫上執行兩者：

與把查詢輸出轉成無序集合的 BIRD 式 EX 不同，UniQL 的指標在需要時保留順序與重複度。對於具有顯式排序語意的查詢（例如含 ORDER BY），比較的是有序 list：

這防止「回傳正確的 row 但順序錯誤」的預測被誤判為正確。

對於無序查詢，結果順序被忽略，但重複度仍然保留。不是轉成 set，而是用 multiset 式比對：R̂ 的每一列都必須在 R* 中被匹配並移除，只有當所有列都精確匹配、且沒有剩餘未匹配的列時才算正確：

這避免了把「重複列數量不同」的輸出視為等價。

主要結果 — 最強的模型也只到 54.63%

所有模型都在 inference-only 設定下評估：沒有任務專屬的 SFT、沒有 RL、沒有 few-shot 範例挑選、沒有方言專屬適配。每個測試實例給模型目標 SQL 方言、資料庫 schema 與自然語言問題，要求生成一條指定方言的可執行 SQL。所有模型共用同一個 prompt template。

Observation 1：更強的模型確實更好，但任務依然困難

前沿 API 模型取得最強的整體結果，Claude-4.5-Sonnet 在多數方言上領先。但最佳平均 EX 也只有 54.63%，代表 UniQL 對先進 LLM 仍暴露出實質的剩餘限制。開源模型中 DeepSeek-v4-flash（48.12）與 Qwen3-32B（47.77）平均最強，但仍有相當大的改進空間。

Observation 2：只看 SQLite 會遮蔽方言專屬的弱點

Observation 3：模型家族內的 scaling 有效，但消除不了方言差異

Qwen3 系列展現清楚的 scaling 趨勢：平均 EX 從 Qwen3-1.7B 的 33.01 上升到 Qwen3-4B 的 42.29、Qwen3-8B 的 44.17、Qwen3-32B 的 47.77。Llama 家族也有類似趨勢（Llama-3-70B-Inst 22.04 → 39.78，大幅超越 8B）。

但作者強調：scaling 主要提升的是整體能力，而不是消除方言層級的變異。Druid、Presto、Teradata 這些困難方言，對更大的模型依然困難。

Observation 4：方言表現反映的是「模型熟悉度」，不只是「內在複雜度」

Table 2 最後一列顯示方言之間的巨大差異。Oracle 拿到最高的平均 EX（48.92），其後是 SQLite、MySQL、Hive、Spark、StarRocks；而 Teradata（29.03）與 Druid（29.65）最難。

分層分析 — 兩種切分，兩種診斷

作者用兩種 partition 進一步分析：BIRD 原始難度標籤，以及 UniQL 引入的建構來源（construction source）。這兩種切分能區分模型失敗的原因，是「原始 text-to-SQL 問題本身複雜」，還是「目標 SQL 實現落在較難的跨方言建構路徑上」。

6.1 依問題難度

在幾乎所有模型上，準確率都隨難度單調下降。

論文 Figure 3 另外給出全部 13 個模型在 simple 檔的 macro-average 準確率，可作為整體強弱的參考序：

「–」表示論文只在 Figure 3 的柱狀圖中呈現、正文未列出精確數值，此處不做推測。

這個趨勢說明 UniQL 保留了原始 text-to-SQL 任務的語意難度結構：跨方言生成不只是產出方言專屬語法的問題，同時也需要解決越來越複雜的查詢語意。

6.2 依建構來源

更有診斷價值的是第二種切分：參考 SQL 標註是在建構管線的哪一階段取得的。趨勢非常清楚——規則式工具直接解掉的例子明顯較容易；需要 LLM 翻譯、自我反思、規則演化或人工驗證的例子則普遍更難。

跨方言一致性 — 這篇論文最重要的那張表

主結果是在每個方言內部聚合問題算出來的。但因為 UniQL 是對齊的，我們可以問一個嚴格得多的問題：對同一個意圖，模型能答對幾種方言實現？

對每個問題，計算答對的方言數（0 到 16），作者稱之為 cross-dialect consistency。並額外報告 SQLite→15：在 SQLite 上答對的問題中，有多少百分比在其餘 15 個方言上也都保持正確。

這兩個視角合起來，強化了主要觀察：單方言評估是不足的。平均 EX 衡量的是「聚合過方言之後的表現」，而 All-16 一致性問的是「模型能否在所有方言實現上都保持正確」。兩者之間的巨大落差顯示，當前模型距離成為 dialect-universal 的自然語言資料庫介面還很遠。

錯誤分析 — 失敗模式是方言相依的

作者對主實驗中表現最好的 Claude-4.5-Sonnet 做了 post-hoc 錯誤分析，把每個失敗預測歸入五個粗分類。分析基於儲存的模型預測、執行錯誤、執行結果與人工校準。

三種截然不同的失敗指紋

代表性例子

論文 Table 5 給了四個主要錯誤類別的代表案例（SQL 有縮短以利閱讀，但保留關鍵失敗模式）：

Prompt 原始碼 — 三個 template

論文 Appendix B 給出建構與評估用的三個 prompt template。{dialect}、{db_details}、{question}、{evidence}、{schema}、{error_logs} 等 placeholder 會以對應的資料庫、查詢與執行回饋資訊實例化。

① Text-to-SQL Inference — 評估模型時用的 prompt

所有 13 個模型共用這個 template，只有 {dialect}、{db_details}、{question} 會變，指令格式跨模型完全不變。這是「公平比較」的基礎。

Task Overview:
You are a data science expert. Below, you are provided with
a database schema and a natural language question. Your
task is to understand the schema and generate a valid SQL
query to answer the question.

Database system:
{dialect}

Database Schema:
{db_details}
This schema describes the database's structure, including
tables, columns, primary keys, foreign keys, and any
relevant relationships or constraints.

Question:
{question}

Evidence:
{evidence}

Instructions:
- Make sure you only output the information that is asked
  in the question. If the question asks for a specific column,
  make sure to only include that column in the SELECT clause,
  nothing more.
- The generated query should return all of the information
  asked in the question without any missing or extra
  information.
- Before generating the final SQL query, please think
  through the steps of how to write the query.

Output Format:
In your answer, please enclose the generated SQL query in a
code block:
```sql
-- Your SQL query
```
Take a deep breath and think step by step to find the
correct SQL query.

② LLM Translator — 建構管線第 ② 關

對應公式 (3)。注意 {specific_rules} 就是規則演化（公式 5）累積出來的方言規則集 R，這是把迭代學到的知識注回翻譯的接口。

You are an expert SQL translator. Your task is to convert a
{source_dialect} query into an executable {target_dialect}
query.

Target {target_dialect} Schema (Reference for Exact
Table/Column Names and Types):
{schema}

Source {source_dialect} SQL:
{source_sql}

General Translation Rules:

Schema Fidelity: The provided Schema is the ABSOLUTE TRUTH.
Do not invent columns or tables.
Logic Preservation: Preserve the logic of the source SQL
(filters, joins, ordering) as much as possible, adapting
syntax to the target dialect.
Data Types: Be careful with Date/Time and String/Number
comparisons.

Specific Dialect Rules (Iteratively Refined):
{specific_rules}

Output Format:
In your answer, please enclose the translated SQL query in
a code block:
```sql
-- Your SQL query
```

③ Rule Summarizer — 建構管線第 ④ 關

對應公式 (5)，用 Gemini-2.5-Pro 執行、跑 3 輪。它吃 failure log，吐出可重用的規則清單，餵回 ② 的 {specific_rules}。

You are an expert Database Administrator and SQL Architect.
We are translating SQL queries from {source_dialect} to
{target_dialect}.
We have a list of failed translations where the translated
SQL result did not match the ground truth.

Your task is to analyze these error logs and summarize
specific, actionable translation rules to fix these issues.

Target {target_dialect} Schema (Reference for Exact
Table/Column Names and Types):
{schema}

Error Logs:
{error_logs}

Instructions:

Identify common patterns of failure (e.g., date formatting,
integer division, quoting rules, NULL handling, ordering
differences).
Formulate concise rules to address these failures.
The rules should be instructions for an AI translator (e.g.,
"When translating X, always do Y").
If a failure seems to be due to ambiguous logic rather than
SQL equivalence (e.g., unpredictable sort order), note it
but prioritize strict syntax/semantics rules.
Refer to the specific Schema info provided in each error
log to understand column types (e.g., if a column is
VARCHAR or INT).

Output Format:
Return ONLY the list of rules as a bulleted list. Do not
include introductory text.

開源狀況

程式碼與資料在 github.com/JerryGao818/UniQL：包含各方言的 SQL 標註（data/queries/）、schema 描述（data/schemas/）、方言專屬的執行式評估器（evaluation/）、開放權重模型的 vLLM 推論腳本（inference/）、各方言的資料庫遷移腳本（migration/），以及建構管線元件（construction/）。

限制與未來工作

以下都是作者自己在 Section 8 明確寫出的限制，不是我加的。

限制 1：對齊的代價是「用不到 native 資料模型」

限制 2：SQL 標註偏向「可攜寫法」而非「方言慣用寫法」

限制 3：執行式驗證無法完全保證語意等價

怎麼用這篇論文

結論

UniQL 引入了一個人工驗證的 benchmark，用來評估跨方言 text-to-SQL 生成：1,534 個自然語言意圖對齊到 16 種 SQL 方言、24,544 筆方言專屬標註。透過資料庫遷移、混合翻譯、執行導引驗證、迭代規則摘要與人工驗證，UniQL 能受控地評估模型是否能在不同資料庫系統間保留同一個查詢意圖。

實驗顯示當前 LLM 距離 dialect-universal 還很遠：即使是強模型，平均也只解掉約一半的 benchmark，跨方言表現差異巨大，而且經常無法把 SQLite 上的成功轉移到其他資料庫系統。這些發現凸顯了對齊式跨方言 benchmark 與 dialect-aware text-to-SQL 方法的需求。