E-SQL

問題定義 — Problem Statement

Text-to-SQL 的目標是把自然語言問句翻譯成可執行 SQL,給非專家一個資料庫的自然語言介面。LLM 出現後仍有約 20% 的人類精度差距,意味著最先進的 pipeline 都還沒到「真實部署可用」的程度。

作者把問題拆成三類具體挑戰:

傳統路線:Schema Filtering — 但作者反對

過去主流做法是過濾 schema(schema pruning):先把與問句無關的表/欄丟掉再餵給 LLM,代表性工作如 RESDSQL、DIN-SQL、C3、CHESS。但作者引用 Maamari et al. (2024) 並用自己的實驗證實:當使用最先進的 LLM(GPT-4o 級)時,schema filtering 反而會傷害效能。原因是先進 LLM 已能自己做隱性 schema linking,顯式過濾反而可能誤刪正確 schema。

本文的替代路徑:Question Enrichment

不要動 schema,而是把 schema 「壓」進問句裡:把相關的 table、column、value、SQL 構造步驟,直接寫進使用者問句裡,讓 LLM 看到的問句本身就已經完成了 schema linking。再搭配從原始 candidate SQL 抽出的候選 predicate(用 LIKE 從 DB 抓出實際候選值),補上錯誤值/錯誤欄的修正空間。

五大貢獻

方法論 — E-SQL Pipeline 全景

E-SQL 由四個主要模組組成,順序為 CSG → CPG → QE → SR。一個額外的 SF 模組僅用於消融比較,最終 pipeline 不包含 SF。

2.1 Database Description & Value Selection — 共通前處理

真實 DB 的 description 檔與資料值很龐大,無法全部塞進 prompt。E-SQL 用 BM25 排序:

這比 RESDSQL 的 Longest Common Substring (LCS) 法快,也比 CHESS 的 LSH 簡單。

四大模組細節

3.1 CSG — Candidate SQL Generation

第一階段先生一份「候選 SQL」。重點不是要它正確,而是要它大致正確 —— 表用對了、欄大致對、值大致對 —— 因為下游 CPG 要從中抽出 token 去 DB 撈候選值。Prompt 設計:

• • 9-shot 範例:每個難度層級(simple / moderate / challenging)各 3 個,且範例與當前 query 必須來自不同 DB,避免洩漏
• • 範例由簡單到複雜排序
• • Schema 用 DAIL-SQL 推薦的 code representation(create table 語法,不是自然語言)
• • 加上 BM25 抽出的 10 個欄值 + 20 句 description,再以 "Let's think step by step" 觸發 CoT

3.2 CPG — Candidate Predicate Generation

這是 E-SQL 第二個獨特設計。作者列舉了 LLM 生成 predicate 的 6 種情況,其中 (2)–(5) 都是「表或欄或值有部分錯」可以被資料庫實際資料糾正的情況:

具體做法:從候選 SQL 抽 predicate 中的 token,在 DB 跑下面這個 query:

SELECT DISTINCT <COLUMN>
FROM <TABLE>
WHERE <COLUMN> LIKE '%<VALUE>%';

產生 <table>.<column> <op> <value> 形式的候選 predicate 列表,塞進 QE 與 SR 的 prompt。

3.3 QE — Question Enrichment(本文核心)

不要過濾 schema,而是把 schema 寫進問句裡 —— 同時附上 SQL 構造計畫作為 reasoning。

給定原問句 + schema + DB description + DB values + 候選 predicates,讓 LLM 產生兩樣東西:

兩者連接成 Fully Enriched Question(完整富化問句),作為下游 SR 的輸入。

Few-shot 設計:作者手動標註 12 個(每個難度 4 個範例),從中隨機選 9 個(每難度 3 個);範例同樣強制與當前 query 來自不同 DB。整個富化在「一次 prompt」內完成,不做迭代。

3.4 SR — Predicate & Error-Aware SQL Refinement

最後一步把所有東西匯總:fully enriched question、候選 SQL、執行錯誤訊息(若有)、候選 predicates、schema、description,讓 LLM 決定是修補候選 SQL 或重新寫一份。

3.5 SF — Schema Filtering(僅用於消融比較)

作者實作了一個 single-step schema filtering 模組(連帶一個 Filtered Schema Correction 步驟),用在消融實驗來證實:把 SF 加進 pipeline 反而會掉分。因此最終 E-SQL pipeline 不含 SF。

資料集與評估指標

資料集

評估指標(BIRD 三件套)

實驗設定

主力模型:GPT-4o-mini(成本是 GPT-4o 約 1/3)+ GPT-4o 補強。小模型探索:Qwen2.5 Coder 1.5B/7B、DeepSeek Coder 1.3B/7B。 Temperature 0.0、top_p 1.0、max_tokens 2048。每模組 9-shot(3/3/3 跨難度)、10 個欄值、20 句 description。

主要結果

5.1 BIRD Leaderboard 對比

5.2 按難度拆解:E-SQL 在 challenging 級別優勢明顯

消融研究(下節)會顯示:QE 模組在 challenging 題目上帶來近 5% 提升,是 E-SQL 在難題上勝出的主因。

5.3 Spider Test Set

在 Spider 上 E-SQL 沒有奪冠,因為 Spider 相對「乾淨」、複雜性低於 BIRD,SOTA 方法的差距較難拉開。E-SQL 的設計優勢在 BIRD 這類有真實 DB 複雜性的場景才能彰顯。

消融研究 — 證實每個模組的貢獻

6.1 Schema Filtering 加進去就掉分

無論 SF 放在哪個位置,把 schema filtering 加進 basic pipeline 都會傷害效能 —— SF-G 的 Moderate EX 直接掉了 12.28 個百分點。反之 QE-G 比 baseline G 全面提升,尤其在 challenging 級別 +4.14。

6.2 E-SQL 拿掉哪個模組就掉多少?

6.3 SR 模組到底改了什麼?

SR 對較弱的 LLM(GPT-4o-mini)效益更大 —— 模型越強,SR 能補救的空間越小。GPT-4o 大多時候 CSG 就已寫得不錯。

小模型實驗 — Enriched Question 才是關鍵

作者做了一個有趣的隔離實驗:用 GPT-4o 預先生成 enriched question,然後讓小模型只看「原問句 vs enriched question」、不給 few-shot 也不給 DB description,純測 enriched question 的效益。

計算成本

問句從 18 → 291 token 看似暴漲,但相對於 prompt 動輒 7k-16k token(主要是 schema + DB values + few-shot),富化只佔總量很小比例。每模組僅呼叫一次的設計,讓 E-SQL 在成本上勝過 self-consistency 多次生成的方法。

Prompt 模板 — 從 GitHub 原始檔

論文附錄 A 列出了四個模組的完整 prompt skeleton(實際檔案在 prompt_templates/)。以下節選最關鍵的設計選擇 —— 完整版本請看原文 Appendix A.1-A.4。

8.1 QE Prompt 的 8 步驟 instruction(核心)

Question Enrichment prompt 要求 LLM 依序執行 8 個步驟。每一步都精準對應 schema linking 的子任務:

# Step 1 - Read the Question Carefully: 找出 named entities、術語、關鍵詞,
       為問句與 schema 建立連結。
# Step 2 - Analyze the Database Schema: 用 DB samples 檢視 schema,
       識別與問句相關的 table / column / value。
# Step 3 - Review the Database Column Descriptions: 用 column description
       理解每欄具體含義,強化問句與 schema 的對應。
# Step 4 - Analyze and Observe The Database Sample Values: 從 DB sample 值
       觀察各欄的實際資料分布,藉相似度比對找出相關項目。
# Step 5 - Review the Evidence: 利用 evidence 提供的具體資訊指向相關元素。
# Step 6 - Analyze the Possible SQL Conditions: 分析 CPG 給的候選 predicates,
       對應到問句的片語與關鍵字。
# Step 7 - Identify Relevant Database Components: 點名最終會用到的表/欄/值。
# Step 8 - Rewrite the Question: 把識別到的 schema 項目與條件詳細寫進問句,
       使問句清楚、易懂、無冗訊。

輸出 JSON 強制要求兩個 key:

{
  "chain_of_thought_reasoning": "... detail explanation ...",
  "enriched_question": "... expanded clean question ..."
}

8.2 QE 輸出實例(附錄 B)

# Original Question
Among the schools with the average score in Math over 560 in the SAT test,
how many schools are directly charter-funded?

# Enriched Question
Please find the number of schools (COUNT(frpm.`School Code`)) whose
charter funding type is directly funded
(frpm.`Charter Funding Type` = 'Directly funded'), and whose
AvgScrMath larger than 560 in the SAT test
(satscores.AvgScrMath > 560). To find the schools with the charter
funding type information and average math score in SAT, frpm and
satscores tables should be joined. Apply the charter funding type
condition and average math score condition. Calculate the number of
schools using COUNT aggregate function in the SELECT statement.

看出來了 —— enriched question 已經幾乎是用自然語言寫的 SQL plan,LLM 下游只要做「翻譯」就行。這就是「direct schema linking」名稱的由來。

8.3 CSG / SR / SF 共通設計

所有模組的 system prompt 開頭都一樣:

### You are an excellent data scientist. You can capture the link
### between the question and corresponding database and perfectly
### generate valid SQLite SQL query to answer the question.

共通的細節防呆 instruction(每個 prompt 都重複):

8.4 SR Prompt 的修補邏輯

SR 是把所有東西匯總後再決定要「修改 candidate SQL」還是「重寫」:

# Step 3 - Analyze the Possible SQL Query: 識別 candidate 中可能的錯誤
       (缺漏條件、錯誤函式、聚合誤用、語法錯誤、未識別 token、模糊欄位)。
# Step 4 - Investigate Possible Conditions and Execution Errors:
       仔細看 CPG 給的候選 predicates(格式為 <table>.<col><op><val>),
       並分析 candidate SQL 的執行錯誤訊息(若有)。
# Step 5 - Finalize the SQL: 結合問句意圖、evidence、候選條件,
       決定修補或重寫 candidate。

限制與未來工作

一句話結論

E-SQL 把 schema linking 從「過濾無關項」翻轉成「把相關項寫進問句」,在 BIRD test set 達 66.29% EX,並證實在先進 LLM 時代schema filtering 反而有害 —— 為 Text-to-SQL 提供了一條成本可控、對複雜查詢特別有效的新路徑。