OmniSQL

問題定義 — 微調模型「考過試卻不會做事」

Text-to-SQL 把自然語言問句翻成可執行 SQL，讓非專家也能查資料庫。LLM 時代有兩條路線：prompting 與 fine-tuning，但兩者在真實場景都有硬傷。OmniSQL 主張：用「大規模、多樣、高品質」的合成資料去微調開源模型，才能同時解決成本、隱私與泛化。

兩種主流範式各自的痛點

為什麼不直接擴增既有資料？

過去的 data augmentation 多半是「貼著既有資料集的分佈」去長新樣本，導致多樣性、品質、可擴展性都受限；不少方法還要人工設計複雜的模板或文法，難以規模化。OmniSQL 要的是一個同時滿足三個條件的框架：

框架總覽 — 把難題拆成四個簡單步驟

核心難點是「自動化 + 可擴展」與「品質 + 多樣性」之間的矛盾。OmniSQL 的解法是一條漸進式管線（progressive pipeline）：把合成任務解耦成四個彼此獨立、各自可控的子任務，每步都用相對小型的開源 LLM 就能完成。

注意這條管線的方向是 「SQL → Question」（先有 SQL，再回譯成自然語言），而非反過來。原因：把 SQL 翻成自然語言，比把模糊的自然語言翻成精確 SQL 來得「更準確、歧義更低」，這保證了 <question, SQL> 配對的品質。

為了避免單一 LLM 的偏好造成風格偏差，論文在不同步驟用上多個開源模型家族分工：Llama3.1（8B/70B）、DeepSeek-Coder（6.7B/33B、V2-Lite）、Qwen2.5（7B–72B）、Qwen2.5-Coder（7B–32B），越大的模型分配越多合成工作量以確保品質。

步驟一 — 用網路表格「長」出真實資料庫

真實企業資料庫因為敏感資訊而難以取得，但結構化的 web tables 卻在網路上俯拾即是。OmniSQL 的洞見：給 LLM 一張網路表格，請它推斷背後合理的商業情境，再設計一個能存放這些資料的關聯式資料庫。

兩階段：生成 + 增強

為什麼相信 LLM 能生出好 schema？論文分析 StarCoder 的預訓練資料，找到 975,420 個 .sql 檔，其中 42% 至少含一個 CREATE TABLE 敘述 —— LLM 在預訓練階段就大量見過 schema 定義。相較之下，GitSchemas / SchemaPile 從 GitHub 抽 DDL，可擴展性受限於高品質 SQL 檔的稀缺；WikiDBs 從 Wikidata 拼表，又有「把不相關的表硬連在一起」的一致性風險。

實際 prompt（節錄自 repo）

資料庫合成 prompt 要 LLM 一次做三件事：判斷領域、構思企業級情境、輸出 JSON schema；並特別要求加入「15–50 欄的超寬表」。以下節錄自 data_synthesis/database_synthesis/prompt_templates/schema_prompt.txt：

**Task Overview:**
Given a table in Markdown format, your task is to complete the following three tasks:

## Task 1
Analyze the table's header and rows to briefly summarize its domain.
The output domain should be surrounded by [START_DOMAIN] and [END_DOMAIN].

## Task 2
Based on the table, propose a complex, enterprise-level, real-world
business scenario ... surrounded by [START_SCENARIO] and [END_SCENARIO].

## Task 3
Create a comprehensive database schema in json format ...
The schema for each table should comprise: table_name, table_description,
column_names, column_types, column_descriptions, primary_key, sample_rows.
... establish and define the foreign_keys ...
3. **Ultra-Wide Tables**: Incorporate ultra-wide tables ... 15-50 columns ...

步驟二 — 複雜度可控的 SQL 生成

直接叫 LLM 寫 SQL 會出現複雜度失衡：小模型只會寫簡單查詢、大模型又愛寫超複雜的。OmniSQL 的解法是明確定義四級複雜度，每次隨機抽一級、要求 LLM 對齊該級別。

四級複雜度（依 repo 的判準）

除了複雜度，prompt 還塞進幾個關鍵元件來確保查詢「有意義又真實」：

• Advanced SQL Functions：隨機抽幾個資料庫引擎支援的進階函式（附名稱與說明），鼓勵但不強制使用。本研究以 SQLite 引擎為主。
• Database Values：隨機抽幾個欄位的實際值，幫助 LLM 生出有語意的述詞（predicate）。
• Column Selection Constraint：限制最終 SELECT 的欄位數，取自幾何分佈（p = 0.6） —— 自然偏向小數字，貼近「真實問句通常只要幾個欄位」的情境。

後處理：把雜訊濾掉

生成後做品質控管：(1) 用規則濾掉非 SELECT 查詢，並在合成資料庫上實際執行，剔除語法錯誤或逾時的；(2) 抽取 SQL 模板（只遮掉值），每個模板只留一條，確保多樣性。例如 ... WHERE age > 18 和 ... WHERE age > 55 同模板，只保留一條。

SQL 合成 prompt 本體很精簡（節錄自 sql_synthesis_prompt.txt）：

**Task Overview**
Create an executable SQL query based on the provided information.

**Database Schema**  {schema_str}
{sql_function_prompt}
{db_value_prompt}

**SQL Query Complexity**
Ensure the SQL query matches the {complexity} level ... {criterion}

**SQL Query Requirements**
1. Use the syntax specific to the {db_engine} database engine.
2. Incorporate advanced functions if appropriate, but ... not mandatory.
3. Address real-world data analysis needs. Avoid trivial ... queries.
4. (Very important) Ensure the final SQL query selects {column_count} columns.

**Answer**  Let's proceed step by step.

步驟三 — 九種語氣的問題回譯

把 SQL 回譯成自然語言問句時，OmniSQL 同時追求「語意準確」與「語言多樣」。真實使用者問問題的方式千變萬化 —— 從正式明確到含糊隱喻，若訓練資料只有一種腔調，模型遇到同義詞替換或改寫就會崩。

九種語言風格

語意一致性選擇器（Semantic Consistency Selector）

每條 SQL 會生成多個候選問句。為了挑出語意最準的那個，用 Sentence Transformers（all-mpnet-base-v2）把候選嵌入向量，計算每個候選與其他候選的平均餘弦相似度，選最接近語意中心的那條。直覺：語意正確的問句會彼此靠近，離群的往往是翻錯的。

步驟四 — CoT 解題（順手修正錯誤 SQL）

為了銜接「問題」與「SQL」之間的鴻溝，OmniSQL 為每個 <database, question, SQL> 三元組生成一段 chain-of-thought 解題，明確寫出從問句推導到 SQL 的步驟。這不只提升可解釋性，更提供高品質的訓練訊號。

典型的 CoT 會：先分析問題要什麼 → 找出相關的表 / 欄 / 過濾條件 → 一步步組裝 join、filter、aggregation、grouping，最後吐出完整 SQL。

關鍵設計：CoT prompt 把原始 SQL 當成「同事給的參考解」，並明說它「可能對也可能錯」、要 LLM 別在答案裡提到它。這巧妙地讓 LLM 願意推翻錯誤的參考解。節錄自 cot_synthesis_prompt_template.txt：

You are a senior data analyst specializing in SQL. Your task is to
translate a natural language question into an executable SQLite query,
providing a detailed reasoning trace.

You will also receive a reference solution from a colleague, which
may or may not be correct. ... you are asked not to mention the
reference solution in any form. The reference solution might include:
1. Unnecessary table and column selections.
2. Incorrect or excessive joins.
3. Misalignment with the question.
4. Opportunities for simplification.

[Database Schema]: {schema}
[Natural Language Question]: {question}
[Reference Solution]: ```sql {sql} ```
Provide your step-by-step text-to-SQL solution here.

SynSQL-2.5M — 第一個百萬級資料集

把上述管線跑起來，就得到 SynSQL-2.5M：2,544,390 筆 <database, question, SQL, CoT> 四元組，橫跨 16,583 個合成資料庫、各種真實領域（社群情緒分析、商品庫存、電影分析、星系形態分析…）。種子來自 TabLib 取樣的約 132 萬張網路表格，經語言 / 大小 / 去重 / 語意四道過濾後留下 19,935 張，最終成功展開成 16,583 個結構完整的資料庫。

SynSQL 的 SQL 平均 1.75 joins/query（Spider 0.48、BIRD 0.94），約 40% 的查詢用到 CTE，涵蓋 83 種引擎函式、超過 219 萬種 unique skeleton —— 在複雜度與多樣性上都明顯勝過人工資料集。

品質評估：贏過人工標註的 BIRD

OmniSQL — 模型與訓練

用 SynSQL-2.5M 加上 Spider / BIRD 的人工資料，微調出 7B / 14B / 32B 三種規模的 OmniSQL，基座是 Qwen2.5-Coder-Instruct 系列。

輸入 / 輸出怎麼組

輸入＝資料庫 schema（格式化為 CREATE TABLE 敘述）＋自然語言問題。每個欄位再以註解附上三種輔助資訊：欄位描述、代表值（每欄取兩個值）、與問題相關的值。輸出＝CoT 解題（含逐步推理與最終 SQL）。由於 Spider / BIRD 只有黃金 SQL 沒有 CoT，論文用步驟四的技術替它們補上 CoT。

訓練細節

• 基座：Qwen2.5-Coder-7B / 14B / 32B-Instruct（預訓練涵蓋 92 種程式語言）。
• 微調方式：7B 與 14B 用全參數微調；32B 因算力受限改用 LoRA（r = 256、α = 512，掛在 q/k/v_proj）。另提供 7B/14B 的 LoRA 版供對照。
• 超參數：AdamW、batch size 512、2 epochs、context length 8192；peak LR 分別 2e-5 / 4e-6 / 2e-4；5% linear warmup 後 cosine 衰減到 10%。bfloat16 + DeepSpeed-Zero。
• 算力：單機 8×A800-80GB；7B / 14B / 32B 各約 6 / 12 / 20 天。推理用 vLLM。

主結果 — 7B 開源模型打贏 GPT-4o

在 9 個資料集上評估（標準 3 + 領域 3 + 強健性 3），指標為執行準確率 EX 與 test-suite 準確率 TS。「Gre」= greedy decoding，「Maj」= 取樣 8 個再依執行結果多數決。重點：OmniSQL 在單步推理、單一模型設定下評估，不與多 agent 框架直接比較。

逐 benchmark 拆解（greedy decoding）

有趣的是：部分開源模型（如 Qwen2.5-Coder-32B、Llama-3.1-70B）在標準資料集上反而贏過閉源模型，但一到領域資料集優勢就消失 —— 因為它們很可能在預訓練 / 微調時吃過 Spider / BIRD 的訓練集。OmniSQL 則在標準與領域 benchmark 上都保持穩定領先。

Ablation — 拆開看每個設計的貢獻

論文用 Qwen2.5-Coder-7B 當基座做了多組消融，全部 greedy decoding。

對比既有 data augmentation 方法

同樣用 LLM 合成的 Sense 在 BIRD 只帶來 +1.3%，OmniSQL 的管線卻帶來 +8.8% —— 「SQL→Question + CoT 修正」的解耦設計，品質明顯更高。

限制與啟示

論文相當誠實地標出幾個邊界，也指出可延伸的方向。

三個值得記住的設計巧思

資料集、三種規模模型與完整合成 / 訓練 / 評估程式碼皆已開源（SynSQL-2.5M 採 Apache 2.0）。對想自建 text-to-SQL 訓練資料的人來說，這四步驟管線是一份可直接照抄的食譜。