論文地址：https://arxiv.org/pdf/2408.05109

解讀：邁向數據民主化——大型語言模型時代下的Text-to-SQL技術綜述

近期，一篇名為《A Survey of Text-to-SQL in the Era of LLMs》的綜述論文系統性地梳理了自然語言到SQL查詢（Text-to-SQL）技術的發展脈絡、核心挑戰與未來方向。該技術旨在將用戶的自然語言問題直接翻譯成可在關系型數據庫上執行的SQL查詢，從而極大地降低了數據訪問的技術門檻。隨著大型語言模型（LLMs）的崛起，Text-to-SQL的性能得到了顯著提升，使其成為學術界和工業界關注的焦點。

這篇綜述提出了一個覆蓋Text-to-SQL任務全生命周期的分析框架，從模型、數據、評估和錯誤分析四個維度展開。

一、 Text-to-SQL的演進之路：從規則到智能

論文通過一張“模型演進流圖”清晰地展示了Text-to-SQL技術的發展歷程，這個過程與自然語言處理（NLP）方法的進步緊密相連。

1. 規則驅動階段（~1990s）： 早期的Text-to-SQL系統依賴于預定義的規則和語義解析器，使用N-gram等統計語言模型進行關鍵詞匹配和轉換。這類方法雖然直接，但泛化能力、可擴展性和適應性都非常有限，主要處理單表查詢。

2. 神經網絡階段（~2013-2018）： 為了克服規則方法的局限性，研究者引入了神經網絡，特別是基于LSTM的序列到序列（sequence-to-sequence）架構和圖神經網絡。這些模型提升了對同義詞和用戶意圖的理解能力，使研究從單表查詢進入了更復雜的多表場景。然而，模型的性能依然受限于模型規模和訓練數據的數量。

3. 預訓練語言模型（PLM）階段（2018~）： 以BERT和 T5為代表的預訓練語言模型（PLMs）的出現，為Text-to-SQL領域帶來了重大突破。這些在海量文本上預訓練的模型極大地增強了對自然語言的理解能力，在如Spider等基準測試上取得了優異的成績。盡管如此，它們在處理極其復雜的查詢和數據庫模式時仍會遇到瓶頸。

4. 大型語言模型（LLM）階段（2020~）： 當前，我們正處于由LLM主導的新階段。以GPT-4為代表的LLMs展現出了超越傳統PLMs的“涌現能力” (emergent capabilities)。這些能力使得LLMs可以通過提示（Prompting）直接執行Text-to-SQL任務，而無需進行專門的微調。研究焦點也隨之轉向數據庫特有的挑戰，例如處理海量數據和特定領域的解決方案，這催生了像BIRD這樣的新基準測試。

二、 核心挑戰：橫亙在自然語言與結構化查詢之間的鴻溝

盡管技術取得了長足進步，但Text-to-SQL任務依然面臨著三大固有挑戰和一系列技術難題。

固有挑戰：

• 自然語言的不確定性： 用戶提問中普遍存在詞匯歧義（一個詞有多種含義）、句法歧義（句子結構可被多種方式解析）以及信息不充分（under-specification）的問題。例如，論文中提到“2023年的勞動節”在美國指9月4日，而在中國則指5月1日。
• 數據庫的復雜性： 現代數據庫模式可能包含數百張表和復雜的相互關系。此外，數據庫中可能存在模糊的屬性名、不一致或缺失的“臟數據”，這都給準確生成SQL帶來了困難。
• 從“自由”到“嚴謹”的轉換鴻溝： 將形式自由、靈活多變的自然語言，精確翻譯成語法嚴格、邏輯嚴謹的SQL查詢，本身就是一個巨大的挑戰。同一個自然語言問題，可能對應多種邏輯等價的SQL寫法，這增加了任務的復雜性。

技術挑戰：

• 成本效益與效率： 部署基于LLM的解決方案需要巨大的硬件資源或API調用成本，如何在模型性能和成本之間取得平衡是一個關鍵問題。
• 數據稀缺與噪聲： 高質量的Text-to-SQL訓練數據難以獲取，公開數據集規模有限且可能包含標注錯誤。
• 可信度與可靠性： Text-to-SQL系統必須能夠持續穩定地產生正確結果，并提供一定的透明度，以便用戶理解和驗證生成的SQL查詢。

三、 LLM時代下的兩大主流技術路徑

在LLM時代，研究者主要通過兩種方式來利用其強大能力解決Text-to-SQL任務：

1. 上下文學習（In-Context Learning）： 這種方法將LLM視為一個“開箱即用”的工具，通過精心設計提示（Prompt）來引導模型生成正確的SQL，而不改變模型本身的參數。例如，DAIL-SQL就是通過有效的提示工程技術在GPT-4上取得了強大的性能。

2. 預訓練與微調（Pre-train and Fine-tune）： 對于擁有充足數據和計算資源的場景，可以通過在特定領域或任務相關的大規模語料上對LLM進行預訓練或微調，從而打造出專門用于Text-to-SQL的模型。一個典型的例子是CodeS，它通過在一個大型Text-to-SQL相關語料庫上預訓練StarCoder模型，在BIRD等基準測試中表現出色。

四、 現代Text-to-SQL系統的模塊化架構

現代基于PLM和LLM的解決方案通常將復雜的Text-to-SQL任務分解為三個核心階段：預處理（Pre-processing）、翻譯（Translation）和后處理（Post-processing）。這種模塊化設計不僅反映了任務日益增長的復雜性，也順應了多代理（multi-agent）或多模塊協同工作的研究趨勢。

• 預處理（可選）： 該階段旨在優化輸入信息，為核心翻譯模塊提供最相關、最精簡的上下文。它包括模式鏈接、數據庫內容檢索和額外信息獲取等子模塊。
• 翻譯： 這是系統的核心，負責將經過處理的自然語言查詢轉換為SQL代碼。這一階段涉及編碼策略、解碼策略以及針對LLM的特定提示策略等關鍵技術。
• 后處理（可選）： 此階段用于檢驗和優化初步生成的SQL查詢，以提升其準確性和可執行性。常見方法包括語法修正、一致性投票和基于執行結果的重排序等。

基于這種模塊化思想，研究者進一步提出了多代理協作框架。例如，MAC-SQL 設計了一個包含三個獨立代理的架構，分別負責模式鏈接、查詢生成和執行引導優化；而CHASE-SQL 和 Alpha-SQL 則采用“分而治之”和動態規劃的策略，讓不同的模塊或代理協同解決問題。

五、 深度剖析：預處理策略

預處理是提升Text-to-SQL性能的關鍵第一步，尤其是在LLM存在輸入長度限制的背景下，其重要性愈發凸顯。

1. 模式鏈接（Schema Linking）：
   此模塊旨在從龐大的數據庫模式中識別出與用戶問題最相關的表和列。其技術演進分為三個階段：

   • 基于字符串匹配： 早期方法如 IRNet 通過精確或模糊的字符串匹配技術來建立鏈接，但在處理同義詞和拼寫變體時能力有限。
   • 基于神經網絡： RESDSQL 和 FinSQL 等模型利用深度神經網絡來理解查詢和數據庫模式之間的復雜語義關系，顯著提升了鏈接的準確性。
   • 基于上下文學習（In-Context Learning）： LLM的強大推理能力被直接用于模式鏈接。C3-SQL 和 CHESS 等工作通過設計零樣本（zero-shot）提示，引導GPT-3.5或GPT-4直接識別出相關的數據庫組件。

2. 數據庫內容檢索（Database Content Retrieval）：
   該模塊專注于高效地從數據庫中提取與查詢條件（如WHERE子句）相關的單元格值。主要方法包括：

   • 基于字符串匹配： BRIDGE 等方法通過啟發式規則和序列匹配技術從自然語言中提取單元格值。
   • 基于神經網絡： TABERT 和 RAT-SQL 等模型通過注意力機制或圖結構來捕捉查詢、列名和單元格值之間的語義關系。
   • 基于索引策略： 為了處理大型數據庫，CHESS 和 CodeS 等現代方法采用索引技術來加速檢索。例如，CodeS 使用BM25算法建立索引進行粗粒度搜索，再通過最長公共子串算法進行精細匹配。

3. 額外信息獲取（Additional Information Acquisition）：
   通過引入領域知識、示例或其他外部信息，可以顯著增強模型對查詢意圖的理解。

   • 基于樣本的方法： 在LLM的上下文中，研究者常將額外的知識或“少樣本”（few-shot）示例直接整合到提示中。例如，DIN-SQL 通過在提示中包含多個階段的示例來處理復雜的查詢。
   • 基于檢索的方法： 為避免提示過長導致成本和效率問題，PET-SQL 等方法會從一個知識庫中檢索與當前問題最相似的k個示例，并將其用于構建提示。REGROUP 則能從外部知識庫中檢索公式化知識并將其轉換為自然語言描述。

六、 解構核心：翻譯方法

翻譯是整個系統的“心臟”，它將自然語言輸入轉化為結構化的SQL查詢。這一過程主要涉及編碼和解碼兩個環節。

1. 編碼策略（Encoding Strategy）：
   編碼器負責將自然語言和數據庫模式轉換成模型可以處理的內部表示。

   • 順序編碼（Sequential Encoding）： 這是最直接的策略，將自然語言查詢和線性化后的數據庫模式拼接成一個單一的token序列進行處理。T5 和 BRIDGE 等模型采用了此方法。
   • 基于圖的編碼（Graph-based Encoding）： 為了更好地捕捉數據庫的內在關系結構（如外鍵關系），RAT-SQL 和 Graphix-T5 等模型將數據庫模式表示為圖結構，并使用圖神經網絡進行編碼。
   • 分離編碼（Separate Encoding）： 該策略獨立地對輸入的不同部分（如查詢和模式）進行編碼，之后再進行交互。例如，SC-Prompt 將編碼過程分為“結構”和“內容”兩個獨立階段。

2. 解碼策略（Decoding Strategy）：
   解碼器則負責將編碼器生成的內部表示轉換成最終的SQL查詢字符串。

   • 基于貪心搜索的解碼（Greedy Search-based Decoding）： 這是一種簡單高效的策略，在生成SQL的每一步都選擇概率最高的token。許多基于GPT的模型（如DTS-SQL）默認采用此方法。其缺點是容易陷入局部最優，可能導致全局結果不佳。
   • 基于束搜索的解碼（Beam Search-based Decoding）： 相比貪心搜索，束搜索在每一步都會保留k個最可能的候選序列，從而在更廣闊的搜索空間中尋找最優解，通常能生成更高質量的結果。

除了貪心搜索和束搜索，為了保證生成SQL的語法正確性，研究者還提出了更精密的解碼策略。

• 約束感知的增量解碼 (Constraint-aware Incremental Decoding): 該策略在解碼的每一步都強制應用SQL語法規則，從根本上杜絕語法錯誤的產生。代表性工作 PICARD 在解碼循環中集成了SQL語法檢查器，確保生成的每個token都符合語法規范。BRIDGE 則更進一步，引入了模式一致性引導，確保生成的查詢與數據庫模式保持一致。

4. 面向LLM的任務特定提示策略
   在LLM時代，提示工程（Prompt Engineering）成為引導模型行為的關鍵技術。

   • 思維鏈提示 (Chain-of-Thought, CoT): CoT通過向LLM展示解決問題的推理過程，顯著提升了生成結果的準確性和可解釋性。例如，CHESS 利用CoT來指導其從模式選擇到SQL生成與修正的整個流程。CoT還可以與上下文學習、多代理系統等技術結合，形成更強大的Text-to-SQL框架。
   • 分解策略 (Decomposition Strategy): 該策略將復雜的Text-to-SQL任務分解為一系列更簡單的子任務。例如，TKK 將SQL解析分解為分別處理SELECT、FROM、WHERE子句的子任務；MAC-SQL 則引入了一個“分解器”代理，專門負責將用戶問題拆分為多個易于處理的子問題。

5. 中間表示 (Intermediate Representation, IR)
   為了彌合自然語言的“自由形式”與SQL的“嚴格約束”之間的鴻溝，研究者引入了中間表示（IR）作為橋梁。

   • 類SQL的語法語言 (SQL-like Syntax Language): 這是一種簡化的、語法更寬松的SQL方言。SyntaxSQLNet 和 SemQL 通過移除SQL中的部分子句來簡化語法。其中，NatSQL 是目前廣泛使用的一種IR，它去除了不常見的SQL操作符和關鍵字，簡化了模式鏈接過程，并取得了優異的性能。
   • 類SQL的草圖結構 (SQL-like Sketch Structure): 該方法利用SQL的結構特性，將不同的自然語言查詢映射到一個預定義的“草圖”或“模板”空間中，從而降低解析的復雜性。CatSQL 構建了帶有“插槽”的通用模板，模型的核心任務就是填充這些插槽。RESDSQL 則采用“骨架感知”的解碼框架，先生成SQL的骨架，再填充具體內容。

七、 精益求精：后處理策略

在生成初步的SQL后，后處理步驟可以進一步修正和優化結果。

• SQL修正 (SQL Correction): 針對模型可能產生的語法錯誤，DIN-SQL 引入了零樣本（zero-shot）的自修正模塊，直接讓模型識別并糾正錯誤的SQL。ZeroNL2SQL 則采用多級匹配方法來修正錯誤的列名或值。
• 輸出一致性 (Output Consistency): 為提升結果的可靠性，DAIL-SQL 采用了自洽性（self-consistency）策略，即多次生成結果并選取最一致的答案。PET-SQL 更進一步提出了跨一致性（cross-consistency）策略，讓多個不同的LLM共同生成SQL并根據執行結果進行投票。
• 執行引導策略 (Execution-Guided Strategies): 將生成的SQL在真實數據庫上執行，并利用其執行結果（如報錯信息或空值）作為反饋來指導模型的修正。CHESS 和 CodeS 都采用了這種策略來迭代優化或篩選SQL查詢。
• N-best重排序 (N-best Rerankers): 該策略首先讓模型生成Top-N個候選SQL，然后利用一個更強大或擁有額外知識的“重排序器”對這些候選者進行重新排序，以選出最優解。

八、 發展的基石：Text-to-SQL基準

Text-to-SQL領域的發展離不開各類基準數據集的推動。論文對這些數據集進行了系統性的梳理和分析。

• 數據集的演變：
  • 單領域: 早期的ATIS（航班信息）、GeoQuery（地理知識）等。
  • 跨領域: WikiSQL是首個大型跨領域數據集，而Spider則引入了更復雜的多表關系數據庫。近期的BIRD進一步增加了對復雜SQL函數和操作的考察。
  • 多輪對話: SParC 和 CoSQL 支持交互式對話場景，考驗模型的上下文理解能力。
  • 魯棒性測試: Spider-Syn 通過引入同義詞來模擬用戶對模式的不熟悉，Dr.Spider 則對數據庫、問題和SQL本身施加擾動來全面評估模型的魯棒性。
  • 效率測試: BIRD 首次引入了對SQL執行效率的評估。
  • 知識增強: KaggleDBQA 和 Spider-DK 在數據集中加入了額外的領域知識文檔，考驗模型的知識利用能力。
  • 歧義問題: AmbiQT 是首個專注于評估模型處理歧義問題能力的數據集。

盡管數據集日益豐富，但論文指出，現有基準在SQL查詢的復雜性（如嵌套查詢和復雜計算）方面與真實世界場景仍有差距。

九、 成功的標尺：評估指標與工具

如何科學地評估模型性能至關重要。論文介紹了以下核心評估指標：

• 執行準確率 (Execution Accuracy, EX): 比較預測SQL與標準答案SQL的執行結果是否一致。
• 精確匹配準確率 (Exact-Match Accuracy, EM): 基于組件匹配，要求預測SQL的所有結構化組件都與標準答案完全一致。
• 組件匹配準確率 (Component-Match Accuracy, CM): 分別比較SELECT, WHERE等不同SQL組件的匹配度。
• 有效效率得分 (Valid Efficiency Score, VES): 由BIRD提出，同時衡量SQL查詢的準確性和執行效率。
• 查詢方差測試 (Query Variance Testing, QVT): 衡量模型在處理同一SQL對應的不同自然語言問法時的魯棒性。

此外，為了進行更全面、低成本的評估，社區還開發了如NL2SQL360等評估工具包，以彌補標準基準評估的不足。

十、 知錯能改：Text-to-SQL的錯誤分析

為了持續改進模型性能，理解并歸類其產生的錯誤至關重要。

• 現有的錯誤分類法： 此前的研究已提出多種錯誤分類體系。例如，Ning等人從“句法”（錯誤發生在哪個SQL關鍵詞）和“語義”（對自然語言的何種誤解）兩個維度進行劃分。SQL-PaLM則將錯誤分為模式鏈接、數據庫內容、知識證據、推理和語法五類。而NL2SQL-BUGs則專注于對語義錯誤進行更細致的分類。

• 構建優秀分類法的原則： 現有分類法往往與特定數據集綁定，缺乏普適性。為此，論文提出了構建一個標準化錯誤分類法的四項基本原則：

  1. 全面性 (Comprehensiveness): 應覆蓋所有可能的錯誤類型。
  2. 互斥性 (Mutual Exclusivity): 每種錯誤類型應清晰界定，避免歸類模糊。
  3. 可擴展性 (Extensibility): 能適應技術發展，納入新出現的錯誤類型。
  4. 實用性 (Practicality): 便于用戶在真實場景中診斷和解決問題。

• 論文提出的兩級錯誤分類法： 基于上述原則，作者提出了一個兩級分類體系：

  • 第一級：錯誤定位 (Error Localization): 識別錯誤發生的具體SQL組件，如SELECT或WHERE子句，以便進行針對性修復。
  • 第二級：錯誤原因 (Cause of Error): 探究錯誤的根本原因。例如，WHERE子句中的值錯誤可能反映了模型在數據庫內容檢索或理解上的缺陷。

該分類法在對DIN-SQL模型的錯誤進行分析時表現出了很高的實用性和有效性。

十一、 從理論到實踐：開發者的實用指南

本部分為開發者在不同場景下構建和優化Text-to-SQL解決方案提供了清晰的路線圖和決策流程。

1. 數據驅動的LLM優化路線圖：
   論文根據數據隱私和數據量這兩個關鍵因素，為選擇和優化LLM提供了指導。

   • 考慮數據隱私： 對于隱私敏感數據，推薦使用可本地部署的開源LLM，以確保數據安全。對于非隱私數據，則可以使用閉源LLM的API服務。
   • 考慮數據量：
     • 對于開源LLM，若擁有海量相關數據，可進行預訓練 (Pre-train)；若有數千級別的標注數據，可進行微調 (Fine-tune)。
     • 在數據量較少的情況下，**少樣本學習 (Few-shot)**是推薦策略。
     • 在完全沒有標注數據時，則只能依賴零樣本學習 (Zero-shot)。

2. Text-to-SQL模塊選擇決策流：
   針對不同的應用場景，論文推薦了相應的技術模塊，并分析了其優缺點。

   • 場景1：數據庫模式復雜、表和列眾多
     • 建議： 采用模式鏈接 (Schema Linking) 模塊。
     • 優勢： 可以減少無關模式信息帶來的噪聲，并降低輸入模型的token成本。
     • 劣勢： 會增加額外的時間開銷。
   • 場景2：可以訪問SQL的執行結果
     • 建議： 采用執行引導 (Execution-Guided) 策略。
     • 優勢： 能有效過濾掉無法執行的SQL，從而提升系統性能。
     • 劣勢： 查詢執行本身會消耗大量時間，尤其是在大型數據庫上。

十二、 未來展望：局限性與開放性問題

盡管基于LLM的方法取得了巨大成功，但它們在真實世界應用中仍面臨諸多挑戰，這也為未來的研究指明了方向。

• 當前LLM方案的局限性：

  • 環境封閉： 模型通常在單個固定數據庫上訓練和運行，缺乏處理跨庫查詢和多源數據聚合的能力。
  • 成本高昂： LLM的推理過程消耗大量token，導致高成本和低效率。
  • 缺乏可解釋性： 大多數方法像一個“黑箱”，用戶難以理解其生成邏輯或調試潛在的語義錯誤。
  • 適應性差： 對新領域的適應能力有限，且高度依賴高質量的訓練數據。

• 開放性問題與研究方向：

  1. 開放域Text-to-SQL (Open-Domain Text-to-SQL): 現實中，一個問題可能需要查詢多個數據庫并聚合結果。這帶來了全新的挑戰，包括：如何從海量數據源中檢索相關數據庫、處理異構的模式、規劃跨庫查詢并聚合答案等。
  2. 高性價比的Text-to-SQL方法： 降低LLM的高昂成本是關鍵。一個有前景的方向是結合LLM和PLM的優勢，構建模塊化或多代理框架，讓它們協同工作。
  3. 可信賴的Text-to-SQL解決方案： 提升系統的可靠性至關重要。這包括：
     • 可解釋性： 運用可解釋AI（XAI）技術來揭示模型的決策過程。
     • 調試工具： 開發能同時檢測語法和語義錯誤的Text-to-SQL調試器。
     • 交互式工具： 為數據庫管理員（DBA）等專業用戶提供人機協作工具，以迭代方式構建和優化復雜的SQL查詢。
  4. 自適應的訓練數據合成： 研究如何根據模型的性能反饋，自動并增量地生成高質量的（自然語言，SQL）訓練對，從而幫助模型彌補短板，持續學習和進化。

十三、 結論

這篇綜述以LLM時代為背景，從生命周期的視角全面回顧了Text-to-SQL技術。它系統地定義了任務和挑戰，總結了從預處理、翻譯到后處理的各項關鍵技術模塊，并深入分析了基準數據集和評估指標。通過提供實用的開發路線圖和展望未來的開放性問題，該文為研究者和實踐者在通往數據民主化的道路上提供了寶貴的導航。