RSL-SQL 論文導讀

SECTION 01

問題定義 — Schema Linking 的雙面刃

Schema linking 是 LLM-based Text-to-SQL 的標準減噪手段，但它同時帶來兩個風險：漏掉必要欄位、以及破壞 schema 結構完整性。RSL-SQL 直接把這個風險建模成「正收益 vs 負衝擊」的權衡，並設計四個步驟去最大化正收益、最小化負衝擊。

為什麼 schema linking 會「越減越糟」

把完整的 database schema（表名、欄名、外鍵、註解、樣本值）全部塞進 prompt 雖然資訊最完整，但會 (1) 把 token 數推到上限，(2) 引入大量無關 noise 導致 LLM 走錯方向。Schema linking 就是先選出「跟問句相關的子集」再餵給 LLM。

論文用兩個風險定義這個權衡：

Risk 1（漏召）：若 schema linking 沒有完整召回必要的 table/column，生成的 SQL 一定錯（假設 LLM 不會幻覺出不存在的欄位）。

Risk 2（破壞結構）：就算所有必要欄位都召回了，schema linking 仍可能：忽略外鍵關係而 join 錯、把欄位精簡到語意更模糊、放大歧義 —— 進而讓原本答對的問題答錯。

把這兩個效應量化成兩個變數：

net gain = y − x
y = 完整 schema 答錯 → 簡化後答對的題數（正收益）
x = 完整 schema 答對 → 簡化後答錯的題數（負衝擊）

Schema linking 只在 y > x 時划算。RSL-SQL 的整體策略就是放大 y、壓低 x。

論文的兩個 headline 貢獻

方法

提出 RSL-SQL — 結合雙向 schema linking、contextual augmentation、binary selection、multi-turn self-correction 的四步框架，在 BIRD dev 上以 67.21% EX 取得 open-source SOTA。

跨模型可遷移

用便宜的 DeepSeek 也能贏過多數 GPT-4-based 方法，GPT-4 每 token 成本是 DeepSeek 的 215 倍，但效能差距明顯收斂。

SECTION 02

方法論 — 四步驟全景

RSL-SQL 把流程切成 4 個 LLM 呼叫階段，每一步都針對「正收益 / 負衝擊」其中一邊發力。框架的關鍵設計：永遠保留一份用完整 schema 跑出來的 SQL₁ 當保險，再用 LLM 在「完整 vs 簡化」兩個版本間做最終仲裁。

圖 1 · RSL-SQL 框架四步驟全景（依論文 Fig. 1 重繪）

Prompt 共用元素

所有步驟共用同一套 prompt building blocks，差別只在「用完整 schema 𝒮 還是簡化 schema 𝒮′」、「要不要塞額外的 contextual augmentation H_Aug」：

𝒮 / 𝒮′

Schema：表名、欄名、外鍵。完整版 𝒮 給保險用，簡化版 𝒮′ 用於 Step 2 之後。

𝒱 / 𝒱′

Value samples：每張表抽幾列當值範例，過長截斷。

𝒟 / 𝒟′

Schema descriptions：用 LLM（沿用 TA-SQL）為每張表/欄產生語意說明。只在簡化後使用，因為原始完整版太長。

ℰ

Few-shot examples：用 Euclidean distance 從訓練集挑 top-k 相似題（沿用 DAIL-SQL/PET-SQL）。

𝒬

User question — 主要輸入。

𝒞

Additional context（選擇性）：BIRD 提供的 evidence / hint 即屬此類。

SECTION 03

STEP 1 — Bidirectional Schema Linking

BSL 的賣點是 strict recall 94%（BIRD 上 SOTA），同時把每題平均輸入欄位數壓掉約 83%。關鍵是把 schema linking 拆成「向前」與「向後」兩個互補方向，再做聯集。

Forward Schema Linking (FSL)

用 𝒮 + 𝒱 + 𝒬 + 𝒞 直接問 LLM「哪些 table/column 跟這題相關？」要求輸出 table_name 與 table_name.column_name。若 𝒞 提到任何欄名，也一併加入。結果記作 L_fwd。

Preliminary SQL Generation

用完整 𝒮 + L_fwd + 其他元素，讓 LLM 先生一版 SQL₁。注意此步刻意不放 𝒟（描述），因為描述每張表/欄都會炸 prompt 長度。

Backward Schema Linking (BSL')

反過來 — parse SQL₁，掃過資料庫中每個 table_name.column_name，若 column_name 出現在 SQL₁ 中就加入 L_bwd。論文有意選用「欄名 exact match」而非 SQLGlot 嚴謹解析 — 雖然會多召回一些冗餘欄位，但對抵抗 SQL₁ 本身的錯誤更穩。

Schema Simplification

取 L_fwd ∪ L_bwd，從 𝒮、𝒱、𝒟 切出 𝒮′、𝒱′、𝒟′（簡化版），交給下游步驟。

為什麼雙向 > 單向？FSL 召回率偏低（語意 grounding 不一定夠），但 BSL' 假設「如果 SQL₁ 本身是對的，那它用到的欄位就是 ground truth」—— 這個假設讓 BSL' 的召回率衝到 ~90%。兩者聯集後既補了 FSL 的漏洞，也修正了 BSL' 在 SQL₁ 錯時的偏差。

欄名 exact match vs SQLGlot：作者的取捨

# Backward schema linking 的兩種實作

# 選項 A：exact column-name match（論文採用）
for table, col in all_db_columns:
    if col in SQL_1:        # 字串比對，會多召回同名欄
        L_bwd.add((table, col))

# 選項 B：SQLGlot AST parse（更精準但更脆）
import sqlglot
for tbl_col in sqlglot.parse_one(SQL_1).find_all(sqlglot.exp.Column):
    L_bwd.add(tbl_col)

作者的判斷：選項 A 雖然 noise 較高，但對「SQL₁ 已經錯了」的情況比較容錯 —— 反正 noise 在後續步驟還會被 binary selection 過濾掉。

SECTION 04

STEP 2 — Contextual Information Augmentation

在簡化後的 𝒮′ 上生 SQL₂ 之前，先讓 LLM 把這題的 SQL「拆零件」 — 預測出可能用到的 elements、conditions、keywords，當成額外的 context 再餵進 SQL₂ 生成階段。實驗顯示這一步貢獻 2–3% 的 EX 提升。

SQL Components Generation

用 𝒬、𝒮′、𝒱′、𝒟′、𝒞 餵給 LLM，要它分別輸出三個元件：

H_E — Elements

可能要用到的 table / column 列表（與 FSL 完全相同的輸出格式）。

H_C — Conditions

把問句拆解後，列出可能的 WHERE 子句條件。

H_K — Keywords

從問句裡的指標詞推測 SQL 關鍵字 (例如 MIN, DISTINCT, GROUP BY)。

H_Aug = { 𝒟′ , H_E , H_C , H_K }
SQL₂ = f_LLM( 𝒮′ , 𝒱′ , H_Aug , ℰ , 𝒬 , 𝒞 )

為什麼 augmentation 比直接生 SQL 還有效？論文抽樣 20 題做質性分析後給的解釋：把 schema 簡化以後，LLM 經常「focus 不夠細」 — 拆 zero-shot 的 components 等於強迫 LLM 先做一次「自我 plan」，把該注意的 keyword 與 condition 攤在 prompt 裡，再生 SQL 時就不容易漏。

例子：keyword 提示如何救一題

問題：What is the preferred foot when attacking of the player with the lowest potential?

H_Aug（CIA 輸出）：

Elements:
[player_attributes.potential]
[player_attributes.preferred_foot]

Keywords: ['MIN', '=']

Conditions:
['preferred foot when attacking']
['player with the lowest potential']

SQL₁（Step 1，錯）：

SELECT preferred_foot
FROM Player_Attributes
ORDER BY potential ASC
LIMIT 1     -- 漏掉「並列最低」的可能

SQL₂（Step 2，對）：

SELECT preferred_foot
FROM player_attributes
WHERE potential = (
    SELECT MIN(potential)
    FROM player_attributes
)

關鍵詞 MIN 被明確列出後，LLM 意識到「最低 potential 可能不唯一」，改寫成 subquery 模式避免 LIMIT 1 的偏差。

SECTION 05

STEP 3 — Binary Selection Strategy

這一步是整個 framework 真正的「風險對沖」：用 LLM 在 SQL₁（完整 schema）與 SQL₂（簡化 + augmented schema）之間二選一。這步貢獻 ~1.5% EX 提升，且明顯壓低了 Step 2 帶來的負衝擊。

核心 insight：完整 schema 與簡化 schema 各有偏差 — 前者保留結構但有 noise，後者乾淨但可能漏。比 voting / self-consistency 更便宜：只比兩個候選。

判斷依據：執行結果而非語法

SQL₁ 和 SQL₂ 都先被執行，產出結果 ℛ₁、ℛ₂。LLM 拿到的 prompt 包含：

SQL₃ = f_LLM( 𝒮′ , 𝒱′ , 𝒟′ , ℰ , 𝒬 , 𝒞 , SQL₁ , SQL₂ , ℛ₁ , ℛ₂ )

把實際執行結果交給 LLM 看，等於是把「semantic check + execution check」合在一個呼叫裡 — 空結果或形狀不對的那一邊很容易被汰除。

例子：BSS 把錯誤的 SQL₂ 退回 SQL₁

問題：Is molecule TR151 carcinogenic?

✓ SQL₁（Step 1）

SELECT label
FROM molecule
WHERE molecule_id = 'TR151'

執行結果：[('-',)] — 1 列，回答「否」

✗ SQL₂（Step 2）

SELECT label
FROM molecule
WHERE molecule_id = 'TR151'
  AND label = '+'

執行結果：空 — Step 2 多加了不必要的 filter

LLM 比較兩者後 選回 SQL₁ 作為 SQL₃。BSS 之所以能糾錯，是因為 ℛ₂ 空集這個事實非常顯眼，遠比讓 LLM 純靠語意比較可靠。

SECTION 06

STEP 4 — Multi-Turn Self-Correction

最後一道保險網：對「執行失敗」或「空結果」這類高風險 SQL 做多輪對話式修正。實驗上這步只小幅提升精度，但對 robustness 重要 — 因為它直接讓系統「拒絕」明顯壞掉的輸出。

判斷高風險的規則

SQL₃ 直接執行：

語法錯 → 進入修正迴圈
空結果 → 進入修正迴圈（可能是 over-constrained 或欄位錯）
正常結果 → 直接 return

對話式迴圈

把當前 SQL 與錯誤訊息丟回去，要 LLM 改寫。如果改寫後仍有錯，把整段對話歷史保留下來繼續，直到成功或達到最大輪數 N：

SQL₄⁽ⁱ⁺¹⁾ = f_LLM( 𝒮′ , 𝒱′ , 𝒟′ , ℰ , 𝒬 , 𝒞 , SQL₄^(≤i) , E^(≤i) )
直到 SQL₄⁽ⁱ⁾ 執行成功，或 i = N

def mtsc(SQL_3, N):
    sql, err = SQL_3, check_error(SQL_3)
    history = []
    for i in range(N):
        if err is None:
            return sql           # 執行成功且非空
        history.append((sql, err))
        sql = LLM_refine(history, S_prime, V_prime, D_prime, E, Q, C)
        err = check_error(sql)
    return sql                   # 用盡輪數，回傳當前最佳

SECTION 07

資料集與評估指標

BIRD

大型 cross-domain，強調髒外部知識、髒值、複雜查詢 — 比 Spider 困難。主要評估場。

Spider

大型 cross-domain，多表複雜查詢，泛化能力測試。

SDS

Subsampled Development Set — 沿用 CHESS 抽 BIRD dev 每個 DB 10% 做 ablation，可控成本。

四個評估指標

EX — Execution Accuracy

預測 SQL 的執行結果與 ground truth 完全相符的比例。標準指標。

VES — Valid Efficiency Score

合法 SQL（結果相符的那些）的執行效率分數。BIRD 自帶。

NSR — Non-Strict Recall

linked schema 與 GT schema 的交集元素總數 / GT 元素總數。允許部分缺漏。

SRR — Strict Recall Rate

linked schema 必須完整包含 GT 才算 1，否則 0。論文的關鍵突破點。

NSR = Σ |S_gt,i ∩ S̃_i| / Σ |S_gt,i|
SRR = Σ 𝕀( S̃_i ⊇ S_gt,i ) / n

論文目標：最大化 SRR，同時讓 |S̃| 盡可能小 — 既要召回完全又要 prompt 簡短。

SECTION 08

實驗結果 — 跨 backbone 的可遷移性

重點展示三件事：(1) BIRD dev 67.21% 是 open-source SOTA；(2) Spider test 87.9% 接近 MCS-SQL；(3) DeepSeek backbone 比多數 GPT-4 系統便宜，但效能相當。

BIRD dev 摘要

EX (GPT-4o)

67.21

open-source SOTA

VES (GPT-4o)

70.32

valid efficiency

SRR (GPT-4o)

94%

strict schema recall，新 SOTA

Spider Test Set

Table II · Execution Accuracy on Spider Test Set。* = fine-tuned
Method	Model	Date	EX
DAIL-SQL	GPT-4	Sep 2023	86.6
DIN-SQL	GPT-4	Sep 2023	85.3
DTS-SQL*	DeepSeek 7B	Feb 2024	84.4
MCS-SQL	GPT-4	May 2024	89.6
TA-SQL	GPT-4	May 2024	85.0
CHESS	Openllms	Jun 2024	87.2
PET-SQL	GPT-4	Jun 2024	87.6
MAG-SQL	GPT-4	Aug 2024	85.6
MAC-SQL	GPT-3.5-Turbo	Sep 2024	75.5
MAC-SQL	GPT-4	Sep 2024	82.8
MSc-SQL*	Gemma-2-9B	Oct 2024	84.7
RSL-SQL (本文)	DeepSeek	Oct 2024	87.5
RSL-SQL (本文)	GPT-4o	Oct 2024	87.9

RSL-SQL 在 Spider 上不算 SOTA（MCS-SQL 89.6 領先），但 RSL-SQL 用 DeepSeek 都能逼近 GPT-4 baseline，是這個方法可遷移性的證據。

Token Consumption 與成本

Table V · 不同方法在 BIRD dev 全集上的 token 消耗與成本估算
Method	Model	Input (M)	Output (M)	Cost ($)	EX
MAC-SQL	GPT-4	9.63	0.89	342.44	59.39
TA-SQL	GPT-4	10.71	0.51	351.55	56.19
E-SQL	GPT-4o	67.28	1.44	182.56	65.58
RSL-SQL (本文)	DeepSeek	21.90	0.73	3.27	63.56
RSL-SQL (本文)	GPT-4o	21.90	0.73	62.06	67.21

關鍵對照：RSL-SQL (GPT-4o) $62 vs E-SQL $182 — token 數只有 E-SQL 的 1/3，EX 還高 1.6 個百分點。換成 DeepSeek 只要 $3.27 就能達到 63.56% EX，已經贏過很多 GPT-4 baseline。

Schema Linking 召回（Table III 摘要）

論文的核心數據 — bidirectional schema linking 在 BIRD 上達到 SRR 94%（GPT-4o），超越：

CHESS — 89.7% SRR（用 retrieval + 多輪 LLM filter）
MCS-SQL — 89.8% SRR（multi-prompt + multiple-choice）

更重要的是 RSL-SQL 只需要 1–2 輪 LLM call，CHESS / MCS-SQL 需要多輪。同時欄位數比完整 schema 少約 83%。FSL 單獨召回率較低，BSL' 單獨就接近 90%，兩者聯集才達到 94%。

SECTION 09

Ablation — 哪些零件最有用？

作者在 BIRD dev 上逐步加組件，觀察 EX 變化。結論：Step 2 (CIA) 和 Step 3 (BSS) 是核心，加起來貢獻全部增益的 70%+。

逐步加組件的趨勢（BIRD dev）

圖 2 · BIRD dev EX 隨步驟疊加的趨勢示意（依論文 Table IV / Fig. 8 重繪，數值為論文文本中提到的端點）

論文敘述明確指出：

Basic prompt（GPT-4o）→ 62.06%；DeepSeek → 57.63%
每步增益落在 1–3 個百分點
Step 2 (CIA) + Step 3 (BSS) 加起來貢獻整體增益的 70%+
Step 4 (MTSC) 提升較小但對 robustness 關鍵

Negative impact vs Positive gain（Fig. 7）

論文用兩張 bar chart 呈現：Step 2 加 H_Aug 之後，negative impact 微升、positive gain 大升，所以 net 為正。Step 3 (BSS) 接著把 negative impact 顯著壓回去，同時正收益繼續上升。

BSL 在不同 backbone 上的差別

強模型 vs 弱模型對 schema linking 反應不同：

• GPT-4o：bidirectional > backward > forward，因為強模型不太怕 noise，召回率提升直接轉成 EX 提升。

• DeepSeek：只用 backward schema linking 反而比 bidirectional 稍好，因為弱模型對 precision 敏感，過高 recall 反帶來干擾。

這呼應了論文 [40] 的結論：模型越強，recall 影響越大；模型越弱，precision 越重要。

CIA 內部組件的貢獻（Table VI/VII）

把 H_E、H_C、H_K 與 𝒟′ 個別去掉，發現：

𝒟′ (column descriptions) 是最穩定的單一組件 — 無論 GPT-4o 還是 DeepSeek 都帶來 1%+ 增益
SQL components (H_E+H_C+H_K) 整體再加 2%+，但 DeepSeek 上只加 0.46%（因為 DeepSeek 自己生的 components 品質較差）

SECTION 10

Case Study — 兩種補救方式

(A) Maximize positive gain（CIA 救一題）

前面 §04 已展示 preferred_foot + MIN potential 的例子：CIA 預測 'MIN' 為關鍵字後，LLM 把 ORDER BY + LIMIT 1 改寫成正確的 subquery，避開「並列最低」的 corner case。

(B) Minimize negative impact（BSS 退回 SQL₁）

前面 §05 已展示 molecule TR151 的例子：Step 2 多加了 label='+' 這個不該加的 filter，導致 ℛ₂ 為空。BSS 看到 ℛ₂ 空、ℛ₁ 有 1 列回傳 '-'，正確選回 SQL₁。

把這兩個 case 連起來看：CIA 是「進攻 — 把該補的補進來」，BSS 是「防守 — 把過頭的退回去」。RSL-SQL 的設計巧妙之處在於這兩個方向同時放進 pipeline，互相補位。

SECTION 11

限制與啟示

論文沒有明寫但值得關注的限制

限制 1 · Backward linking 依賴 SQL₁ 不能太爛。論文用 exact column-name match 部分緩解，但若 SQL₁ 嚴重幻覺出不存在的欄名，BSL' 就無法救援。

限制 2 · BSS 仰賴 LLM 能正確讀懂執行結果。當 ℛ₁ 和 ℛ₂ 都非空但都「看起來合理但都錯」時，BSS 沒有 oracle 信號可用。

限制 3 · 對弱模型的可遷移性有 ceiling。Ablation 顯示 DeepSeek 上 bidirectional 反而稍輸 backward-only，意味著這個 framework 在更弱的開源模型上可能需要重新調權重。

實務上的可借用設計

把 SQL₁ 當保險

不要把第一輪 prompt 當作丟掉的草稿。「完整 schema 的草稿 SQL」是個非常便宜的安全網，能在 schema linking 失誤時兜底。

用 execution result 做 ensembling

比 LLM 純語意 vote 便宜也更可靠。不需要 sample N 個，兩個有差異的就足夠 hedge。

讓 LLM 先預測 keyword

CIA 的 H_K 等於強迫 LLM 自我 plan，比 raw question 更好 ground 到 SQL 結構。

區分強/弱 backbone 的 schema linking 策略

不要假設「召回越高越好」 — 對 7B/13B 級模型，過多 noise 反而拖累 EX。

問題定義 — Schema Linking 的雙面刃

為什麼 schema linking 會「越減越糟」

論文的兩個 headline 貢獻

方法

跨模型可遷移

方法論 — 四步驟全景

Prompt 共用元素

𝒮 / 𝒮′

𝒱 / 𝒱′

𝒟 / 𝒟′

ℰ

𝒬

𝒞

STEP 1 — Bidirectional Schema Linking

Forward Schema Linking (FSL)

Preliminary SQL Generation

Backward Schema Linking (BSL')

Schema Simplification

欄名 exact match vs SQLGlot：作者的取捨

STEP 2 — Contextual Information Augmentation

SQL Components Generation

HE — Elements

HC — Conditions

HK — Keywords

例子：keyword 提示如何救一題

STEP 3 — Binary Selection Strategy

判斷依據：執行結果而非語法

例子：BSS 把錯誤的 SQL₂ 退回 SQL₁

✓ SQL₁（Step 1）

✗ SQL₂（Step 2）

STEP 4 — Multi-Turn Self-Correction

判斷高風險的規則

對話式迴圈

資料集與評估指標

BIRD

Spider

SDS

四個評估指標

EX — Execution Accuracy

VES — Valid Efficiency Score

NSR — Non-Strict Recall

SRR — Strict Recall Rate

實驗結果 — 跨 backbone 的可遷移性

BIRD dev 摘要

EX (GPT-4o)

VES (GPT-4o)

SRR (GPT-4o)

Spider Test Set

Token Consumption 與成本

Schema Linking 召回（Table III 摘要）

Ablation — 哪些零件最有用？

逐步加組件的趨勢（BIRD dev）

Negative impact vs Positive gain（Fig. 7）

BSL 在不同 backbone 上的差別

CIA 內部組件的貢獻（Table VI/VII）

Case Study — 兩種補救方式

(A) Maximize positive gain（CIA 救一題）

(B) Minimize negative impact（BSS 退回 SQL₁）

限制與啟示

論文沒有明寫但值得關注的限制

實務上的可借用設計

把 SQL₁ 當保險

用 execution result 做 ensembling

讓 LLM 先預測 keyword

區分強/弱 backbone 的 schema linking 策略

H_E — Elements

H_C — Conditions

H_K — Keywords