NL2SQL：基于LLM的解決方案是最好的嗎？
1. NL2SQL現狀
自然語言轉SQL（nl2sql）技術是指自然語言查詢轉化為SQL查詢，降低普通用戶和專家用戶在訪問海量數據集和獲取數據分析結果時的門檻。
1.1 我們目前處于何方？
圖片
上圖展示了過去二十年nl2sql方法的演進歷程，從基于規則的方法，到基于深度神經網絡的方法，再到可調的預訓練語言模型（PLMs），直至大型語言模型（LLMs），整個過程伴隨著數據集的發展，比如Spider和BIRD等基準測試的發展。
LLMs（如GPT-4和Llama2）相較于PLMs（如GPT-2和BART）是規模更大的語言模型，展現出更深層次的語言理解能力。在nl2sql 任務中應用PLMs需要在特定任務的數據集上進行微調，而利用LLMs則可以通過提示（上下文學習）或僅對開源LLMs進行微調（即SFT）。
圖片
上圖對比了基于PLM（藍點）和基于LLM（綠點）的nl2sql模型在Spider排行榜上的準確率。
可以看出基于LLM的nl2sql模型自2023年2月（DINSQL + CodeX）起便與基于PLM的模型展現出相當的準確率。
然而，隨著LLMs的迅猛發展，基于LLM和PLM模型之間的性能差距正在擴大，表明了基于LLM方法優勢十分明顯。
1.2 基于LLM的模型是否明顯勝出？
根據上圖，是否可以斷定基于LLM的模型是所有nl2sql應用的“首選”？換句話說，總是選擇排行榜首位的模型是否總是最佳策略？
討論這一問題前，作者分析了商業化場景的一些特征：
?多樣化的數據領域（Various Data Domains）：類似Tableau 這樣的BI平臺通常涵蓋多個領域（如電影、體育等），每個領域都有其獨特的架構和術語。理想的nl2sql模型必須能夠在這些不同領域間靈活轉換，同時針對每個特定領域進行調整，以有效滿足即時需求。
?復雜的SQL操作（Complex SQL operations）：實際應用中往往需要執行包含多個JOIN、嵌套查詢和聚合函數等高級操作的復雜SQL查詢。準確生成這些復雜查詢的能力是衡量nl2sql模型性能的重要指標。
?新興的語言現象（New Linguistic Phenomena）：對于同一查詢意圖，不同用戶可能會使用不同的縮寫、同義詞和問題風格提出問題。因此，nl2sql模型準確解讀各種自然語言查詢變體的能力至關重要。
圖片
上圖從多個維度對比了Spider開發數據集上的SOTA PLM和LLM模型，評價指標是執行準確性（Execution-Accuracy）。
?多樣化的數據領域（Various Data Domains）：上圖（a）在競賽領域內比較了不同模型。結果表明基于微調的LLM/PLM方法全面超越了所有基于提示的LLM方法。表現最佳的基于PLM的方法RESDSQL-3B+NatSQL，達到了83.9%的執行準確率，比表現最佳的基于提示的LLM方法DAILSQL（搭配GPT-4）高出3.3個百分點。結果表明，微調是提升nl2sql模型領域適應能力的關鍵策略。
?復雜的SQL操作（Complex SQL operations）：上圖(b)比較了僅包含JOIN操作符的SQL查詢用例中的不同模型。基于PLM的方法RESDSQL-3B+NatSQL位居榜首，超越了所有基于LLM的方法。然而，當比較僅包含嵌套SQL查詢的用例時，基于LLM的方法通常優于基于PLM的方法。
?新興的語言現象（New Linguistic Phenomena）：比較了不同語言現象下方法的平均準確率（例如，“返回所有消費總額超過1000的客戶”與“消費超過1000的客戶名單是什么？”）。上圖(d)顯示，盡管兩種類型的方法都表現良好，但微調的LLM和PLM在nl2sql任務上優于基于提示的LLM。主要是因為微調模型能更好地將不同的查詢變體與數據庫架構相匹配。
所以，并非所有情況都適用同一解決方案；也就是說，即使是目前最強大的LLM GPT-4支持的模型，也沒有一個nl2sql模型能在所有不同的使用場景中都成為明顯的贏家。真實應用場景遠比公共nl2sql基準測試（如Spider和BIRD）所能考察的要復雜得多。因此，迫切需要能夠從不同角度系統評估給定基準上nl2sql模型的工具。
1.3 全局視角看NL2SQL
根據文章最開始的進化樹，NL2SQL可以分為四大流派：
? 基于規則的方法：早期研究依賴于預設規則或語義解析器。例如，NaLIR利用句法解析器和手工規則將自然語言查詢轉換為SQL查詢。但這些方法在適應性、擴展性和泛化力上存在局限。
? 基于神經網絡的方法：利用神經網絡將自然語言查詢譯為SQL查詢。隨之發布了若干大規模基準數據集，例如WikiSQL和Spider。相繼開發了諸如IRNet的序列到序列nl2sql方法。IRNet通過編碼器對自然語言查詢和數據庫架構進行編碼，并借助解碼器生成SQL查詢。
? 基于PLM的方法：隨著Transformer的問世和Spider數據集的推出，基于神經網絡的方法迅速崛起，BERT和T5等模型開啟了預訓練語言模型的新紀元，在基準數據集上屢創佳績。例如，RESDSQL，作為Spider排行榜的佼佼者，采用兩階段框架：先從自然語言查詢中識別相關架構元素，再構建SQL查詢。
? 基于LLM的方法：ChatGPT和GPT-4等大型語言模型的出現，徹底革新了nl2sql解決方案。如今，基于LLM的方法已在nl2sql領域占據主導地位。以DAIL-SQL為例，它借助GPT-4和提示工程，在Spider數據集上取得了不俗的成績。
NL2SQL系統的關鍵組件
圖片
上表根據核心模型和若干關鍵組件對當前領先的nl2sql方法進行了分類。
2. NL2SQL360：NL2SQL的全方位測試平臺
為了更好的、系統性的測評NL2SQL任務，作者推出了NL2SQL測評平臺。
圖片
上圖展示了NL2SQL360測試平臺框架，由六個核心組件構成：
? 基準數據集。匯集了多種廣泛采用的基準數據集，包括Spider 、BIRD 、Spider-Realistic 、Dr.Spider 、KaggleDBQA 、WikiSQL 等。
? 模型庫。收錄了一系列在Spider和BIRD排行榜上表現出色的競爭性開源NL2SQL模型，主要包括基于LLM和PLM的方法。
? 數據集篩選器。傳統評估方法通過計算整個基準數據集的平均性能，忽略了不同場景下NL2SQL的細微差別。為彌補這一不足，精心挑選了特定的基準數據集子集，包括特定的數據庫、自然語言查詢和SQL查詢，以凸顯查詢復雜性、數據庫架構多樣性以及SQL特性（如JOIN操作或嵌套查詢）等獨特要素。因此，在NL2SQL360中引入了數據集篩選機制。這使得測試數據集能夠根據不同的標準被劃分為更加專注的子集：
? (1) 場景一：
SQL復雜度。
根據復雜度對SQL查詢進行分類，從簡單查詢到包含多個子句和條件的復雜查詢。
分類標準遵循Spider的準則，目的是評估NL2SQL方法處理不同難度SQL的能力。
? (2) 場景二：
SQL特性。
檢驗主要利用特定特性的SQL查詢，例如JOIN操作、子查詢或聚合函數。
通過基于這些特性對查詢進行分類，評估NL2SQL系統處理不同SQL功能的能力。
例如，商業智能平臺經常需要處理包含嵌套子查詢的分析型查詢。
? 評估標準。采納了廣受認可的評估標準。
? 采用執行準確度（EX）與完全匹配準確度（EM）來評價生成的SQL查詢的效果。
? 利用有效效率得分（VES）來衡量生成有效SQL查詢的效率。
? 查詢變異性測試更全面地評估nl2sql解決方案處理自然語言查詢變化時的穩定性與適應性
? 評估工具。根據日志中的數據，評估工具自動生成定量評估報告，并以表格或排行榜等直觀格式展示。配備了可視化工具和儀表板，支持用戶進行交互式分析，輕松比較不同nl2sql解決方案在數據庫領域和SQL特性等方面的性能表現。
3. LLM好還是PLM好？
作者采用了Spider 和 BIRD 的開發數據集進行實驗，分別包含1034和1534個自然語言與SQL樣本。BIRD數據集的SQL結構更為復雜，涵蓋了Spider未包含的CASE、IIF等關鍵字，增加了對模型自然語言轉SQL能力的挑戰。此外，BIRD中的數據庫結構也比Spider更為復雜。
圖片
3.1 測評基準
3.1.1 4種基于LLM提示工程的基準方法
? (1) DINSQL：將SQL查詢生成分解為多個子任務，并為每個子任務設計了特定的提示，以指導GPT-4生成最終的SQL查詢。
? (2) DAILSQL：以SQL代碼風格對問題和數據庫架構進行編碼，根據結構和查詢的相似性選擇少量示例，這些元素被整合成一個高效的提示，引導GPT-4進行操作。
? (3) DAILSQL(SC) ：DAILSQL的自我一致性（SC，Self Consistence）策略后處理版本。
? (4) C3SQL ：結合了模式鏈接過濾（schema linking filterin）和為GPT-3.5定制的校準偏差提示，用于生成SQL查詢，并采用自我一致性策略（SC，Self Consistence）進行后處理。
33.1.2 9種基于finetune的LLM方法
? (5-8) SFT CodeS (1B/3B/7B/15B) 是基于StarCoder ，使用大量SQL相關語料庫逐步預訓練的，在后續實驗中，使用了與Spider或BIRD數據集微調的SFT CodeS。實驗中包含了SFT CodeS家族的四個版本。
? (9) Llama2-7B 采用優化的Transformer作為自回歸語言模型，由Meta在龐大的語料庫上預訓練。
? (10) Llama3-8B 在超過15T的令牌數據上訓練，訓練數據集規模是Llama 2的7倍，包括4倍多的代碼。
? (11) StarCoder-7B 是一個代碼LLM，已在GitHub上許可的數據上進行訓練，包括超過80種編程語言的代碼。
? (12) CodeLlama-7B 是Llama2的增強版，通過在代碼庫數據集上進行額外訓練進行了優化。
? (13) Deepseek-Coder-7B 在項目級代碼語料庫和填空任務上進行訓練，以提升代碼補全能力。
3.1.3 7種基于PLM的自然語言轉SQL方法
? (1) Graphix-3B+PICARD 將預訓練的T5-3B變換器與圖感知增強集成，用于自然語言轉SQL任務，并利用PICARD 提高性能。
? (2-4) RESDSQL(Base/Large/3B) 引入了排名增強編碼和骨架感知解碼，將模式鏈接與骨架解析分離。
? (5-7) RESDSQL(Base/Large/3B)+NatSQL 結合了NatSQL 以獲得更好性能的版本。實驗中使用了六個版本的RESDSQL家族模型。
3.2 實驗一：微調是否必要？
圖片
圖片
從執行準確度（EX）的視角來看（上面兩圖分別展示了Spider數據集和Bird數據集上結果），基于LLM的方法在不同難度的子集中均超越了基于PLM的方法。特別是在BIRD測試數據集中，DAILSQL(SC)在挑戰性子集上的表現超過了基于LLM的最新最佳方法SFT CodeS15B，這可能是由于GPT-4在推理能力上的顯著優勢。
從精確匹配準確度（EM）的角度分析，經過監督微調的基于LLM的方法通常比基于提示的LLM方法展現出更高的EM性能。微調之后，無論是基于LLM還是PLM的模型，其輸出都更加貼近特定數據集的數據分布，從而能夠預測出與該數據集中相似的SQL結構。
洞察1：微調是提升性能的必由之路。特別是，經過微調的基于LLM的方法在執行準確度（EX）指標上取得了最優的整體表現，而基于PLM的方法在精確匹配準確度（EM）指標上整體表現最為出色。
3.3 實驗二：精確度與SQL特性的較量
在真實場景中，經常需要構建包含諸如子查詢、邏輯連接器、排序（ORDER BY）以及多重連接（JOIN）等高級操作的SQL查詢。
因此，將檢驗自然語言轉SQL模型在生成具有不同特性的SQL查詢方面的精準度。
所以，根據四個維度對SQL查詢進行分類：
? (1) 是否包含子查詢
? (2) 邏輯連接器的數量
? (3) 是否使用排序功能
? (4) 連接操作的次數
NL2SQL360能夠根據單個SQL子句、它們的組合或用戶自定義的條件來過濾SQL查詢。展示了四個具有代表性的維度。
3.3.1 實驗2.1：子查詢的挑戰
圖片
圖片
從上面兩個可以看出，在涉及子查詢的情況下，所有方法的表現都不盡如人意，表明通過子查詢進行邏輯推理是一個難題。
圖片
上圖揭示了在沒有子查詢的情況下，基于LLM的方法在Spider數據集上略微領先于基于PLM的方法，而在BIRD數據集上則平均表現顯著更佳。
當存在子查詢時，基于LLM的方法在兩個數據集上都大放異彩。這是因為構建帶有子查詢的SQL語句要求模型先深入理解子查詢，再生成完整的SQL語句，這對模型的邏輯推理能力提出了高要求。
所有基于LLM的方法，尤其是那些由GPT-4驅動的，處理子查詢時更為出色，不僅超越了經過微調的基于LLM的方法，也超過了基于PLM的方法。模型內在的推理能力對于處理含子查詢的SQL至關重要。
洞察2：在包含子查詢的場景中，基于LLM的方法總體上超越了基于PLM的方法，尤其是那些采用GPT-4的（即基于提示的LLM）方法，表現尤為突出。模型的內在推理能力可能是準確預測子查詢的關鍵所在。
3.3.2 實驗2.2：邏輯連接符的運用
邏輯連接符（如AND、OR）用于連接條件、篩選查詢結果及其他操作，因此評估模型處理邏輯連接符的性能至關重要。
在未涉及邏輯連接符的情況下，基于LLM的智能體在Spider數據集上并未明顯超越基于PLM的方法。但在結構更復雜的BIRD數據集中，基于LLM的智能體則表現出色。
一旦涉及到邏輯連接符，基于LLM的智能體在兩個數據集上均持續領先于基于PLM的智能體。
洞察3：在需要邏輯連接符的情境下，基于LLM的智能體相較于基于PLM的智能體，展現出更優的性能。
3.3.3 實驗2.3：多表連接的藝術
實際應用中，經常需要構建涉及多表連接的SQL查詢，對模型準確把握復雜數據庫架構的能力提出了挑戰。
在不涉及連接操作的情況下，基于LLM和PLM的方法在Spider和BIRD數據集上的表現參差不齊，難分伯仲。
當涉及到需要執行連接操作的場景時，基于LLM的在兩個數據集中均顯著優于基于PLM的。可能是因為連接操作要求深入理解數據庫的復雜結構，而LLM在這方面通常表現出色，得益于其卓越的上下文理解能力。
NatSQL的積極作用也不容忽視。在處理包含連接的SQL查詢時，DINSQL在基于提示的智能體中表現最佳，而RESDSQL-3B+NatSQL則在基于PLM的智能體中獨占鰲頭。兩者都采用了NatSQL 作為中間表示層，這可能得益于其簡化的形式，省去了連接關鍵字并減少了架構項的預測，從而在連接場景中簡化了SQL的預測過程。
洞察4：在需要執行連接操作的場景中，基于LLM的智能體比基于PLM的智能體表現更佳。采用NatSQL作為中間表示層，不僅降低了預測連接操作的復雜性，還可能進一步提升模型的性能。
3.3.4 實驗2.4：排序指令
在缺乏ORDER BY指令時，基于LLM的在Spider與BIRD兩個數據集上均優于基于PLM的方法。但當引入ORDER BY指令后，情況在Spider數據集上發生了逆轉，基于LLM的方法表現稍遜一籌，而在BIRD數據集上則依舊保持領先。這種差異可能源于BIRD數據集的復雜度高于Spider。
洞察5：在涉及ORDER BY指令的場景中，基于PLM和LLM的智能體在不同數據集間的表現呈現出差異。大體來看，基于LLM的智能體展現出了更優越的泛化能力。
3.4 實驗3：查詢變異性測試（Query Variance Testing，QVT）
檢驗nl2sql系統對多樣化自然語言表述和結構的適應力，模擬實際應用中可能遇到的豐富場景。
在BIRD數據集中，很少有SQL查詢與多個不同的自然語言表達相對應。因此，選用了Spider開發集來構建QVT數據集，它包含了469個SQL查詢，每個都對應著兩個以上的不同自然語言查詢，這正符合QVT的初衷。
圖片
如上圖，基于LLM的智能體與基于PLM的智能體在QVT方面難分伯仲。
不過，經過微調的LLM智能體通常在QVT上表現更佳，可能是因為微調使得模型輸入與特定數據分布更加吻合，從而減少了自然語言變化對性能的沖擊。
值得注意的是，盡管Graphix+PICARD方法在整體執行準確度（EX）上不及其他基于提示的智能體，卻在QVT上超越了它們。
洞察6：在QVT方面，基于LLM與基于PLM的智能體并無明顯優劣之分。針對特定任務數據集對模型進行微調，可能有助于提高其在面對自然語言變化時的性能穩定性。
3.5 實驗4：數據庫領域適配
在自然語言到SQL的實際應用案例中，往往需要處理特定領域的數據庫，比如電影或體育領域，各自擁有獨特的架構設計和專業術語。因此，跨不同領域的細致表現評估對于模型的有效應用極為關鍵。
對Spider訓練集中的140個數據庫和開發集中的20個數據庫進行了分類，共劃分出33個不同的領域。所有基于微調的LLM和PLM智能體均使用訓練集進行調優。
圖片
上圖展示了Spider數據集中，不同數據庫領域內的執行準確度（EX）表現。不同的自然語言到SQL方法對不同領域有著不同的偏好，基于LLM和基于PLM的智能體并沒有明顯的優劣之分。
圖片
上圖展示了整體表現。在擁有較多訓練數據庫的領域（如大學、競賽、交通），基于微調的方法表現更佳。而在訓練數據庫較少的領域，基于提示的方法則更為出色。這說明，在微調階段引入領域內的訓練數據對于提升模型在特定領域的性能至關重要。
洞察7：不同方法對不同領域有著不同的偏好，基于LLM和基于PLM的智能體并無絕對的勝出者。不過，在微調階段的領域內訓練數據對于模型在特定領域的表現極為重要。
3.6 實驗5：LLM智能體的監督式微調
探究在自然語言轉SQL任務中，對開源大型語言模型（LLM）進行監督式微調（SFT）的效果。
DAILSQL 在SFT過程中，不同樣本量和提示表述的影響，但并未明確指出哪些開源LLM最適合用于自然語言轉SQL任務的SFT。采用SQL風格的提示對提升效果有益，因此在零樣本設置中也采取了類似的提示策略，如下圖。
圖片
考慮到自然語言轉SQL任務與代碼編寫密切相關，挑選了五款具有不同代碼處理能力的開源LLM，并通過HumanEval (Pass@1) 指標進行了評估。
圖片
如上圖，經過SFT，各模型的性能（EX）均有提升，但提升幅度在不同基礎模型間差異顯著。
性能提升與模型在SFT前的內在編碼能力（HumanEval）之間存在正相關關系。這表明，選擇具有優秀編碼能力的LLM作為基礎模型，對于適應自然語言轉SQL任務大有裨益。
洞察8：在對開源LLM進行自然語言轉SQL任務的監督式微調（SFT）后，發現SFT后的性能與模型在SFT前的固有編碼能力之間存在正相關。這說明，具備高級編碼能力的LLM是適應自然語言轉SQL任務的關鍵。
3.7 實驗6：基于LLM的方法的經濟性
考慮到國內模型很便宜，這部分感覺意義不大，直接看洞察
洞察9：根據執行準確度（EX）與平均成本的比值，發現調用GPT-3.5-turbo的基于提示的LLM智能體具有更高的成本效益。雖然DAILSQL(SC)在Spider和BIRD數據集上相較于DAILSQL在EX上有所提升，但其增加的成本也降低了其整體的成本效益。
3.8 實驗7：基于PLM方法的執行效率
對六種模型進行了三項指標的評估：
? 執行準確度（EX）
? 樣本延遲
? GPU內存
圖片
如上圖，隨著模型規模的增長，GPU內存消耗和延遲也隨之上升。但是，RESDSQL-Base+NatSQL（2.2億參數）與RESDSQL-Large（7.7億參數）在執行準確度上表現相近（分別為80.2%和80.1%），而前者在延遲和內存使用上更為經濟。同樣，RESDSQL-Large+NatSQL與RESDSQL-3B在執行準確度上不相上下，但在延遲和硬件需求上存在差異。因此，在模型的選擇上，需要權衡延遲和硬件資源。
洞察10：隨著模型參數規模的擴大，其延遲和硬件資源的需求也會相應增長。此外，即便性能相近，不同模型在延遲和硬件資源需求上也可能大相徑庭。
3.9 實驗8：SQL效能探究 - 有效效率評分
在現實世界的運用中，不僅需確保模型產出的SQL查詢準確無誤，更要注重其執行的高效性。BIRD 提出了有效效率評分（VES，Valid Efficiency Score），用以衡量正確生成的SQL查詢的執行效能。
圖片
上圖展示了實驗的成果。橙色標注了最高的VES得分。在各個難度層級的子集中，VES得分最高的方法并不固定，無論是基于LLM還是基于PLM的方法，都未見明顯的優勢。大體而言，同一方法在處理更為復雜的子集時，往往會有較低的VES表現，這可能與執行難度的增加和所需時間的延長有關。
洞察11：依據VES評分，在基于LLM和基于PLM的方法之間，并沒有明顯的贏家。對于同一方法而言，它在面對更具挑戰性的子集時，往往會展現出較低的VES。
3.10 實驗9：訓練樣本數量的效應
圖片
無論是基于PLM還是經過微調的LLM方法，隨著自然語言到SQL訓練數據的增多，性能均有所提升，并在訓練樣本達到4000時獲得滿意的性能表現。然而，隨著數據集規模的擴大，執行準確度（EX）的增益逐漸減少。
洞察12：隨著自然語言到SQL訓練數據的增加，基于PLM和LLM的方法性能均有所提高。但值得注意的是，隨著數據集規模的增長，執行準確度（EX）的提升幅度逐漸降低。若數據隱私成為關注點或有足夠的標注數據，對LLM/PLM進行微調展現出巨大的潛力。
4. NL2SQL的模塊化設計
圖片
如上圖，可以將NL2SQL方案大致劃分為以上模塊：
? (1) 預處理階段：預處理環節涵蓋了架構關聯和數據庫內容兩大核心。架構關聯將自然語言查詢指向數據庫架構元素（例如表和列），從而提升了跨領域通用性和復雜查詢的生成能力。數據庫內容模塊通過字符串匹配，常常用于將查詢條件與數據庫內容相匹配，進一步豐富列的細節信息。
? (2) 提示策略：提示策略可分為零樣本和少樣本兩種，零樣本策略在模型輸入中不包含任何自然語言到SQL的示例，而少樣本策略則包含一定數量的示例，如“3樣本”、“5樣本”等。基于PLM的方法通常偏好零樣本策略，而基于LLM的方法則各有千秋：C3SQL采用零樣本策略，而DAILSQL和DINSQL則采用少樣本策略。DINSQL的少樣本示例是人工設計且固定的，相較之下，DAILSQL的示例則是基于目標問題與訓練集示例間的相似度動態選擇的。
? (3) SQL構建策略：語言智能體在生成SQL時采取多樣化的策略，這些策略可歸納為三個核心要素：分步構建、解碼技巧和中間表達形式。
? (a) 分步構建，類似于思維鏈（Chain-of-Thought, COT）的邏輯，通過分階段構造SQL查詢，尤其適合處理復雜查詢。
兩種分步策略：
“SQL框架 - SQL”策略源自基于PLM的RESDSQL ，“子查詢 - SQL”策略則來自DINSQL 。
? (b) 解碼技巧關注的是LLM在解碼過程中如何確保輸出結果的有效性。
基于PLM的PICARD 確保其輸出嚴格遵守SQL語法規則，而基于LLM的方法則通過OpenAI的API進行操作，不受此類解碼層面的限制。
? (c) 中間表達形式策略探討是否采用某種中介查詢格式來彌合自然語言與SQL之間的差異，因為SQL面向關系數據庫的設計并不總是與自然語言的語義相吻合。
市場上已經出現了諸如NatSQL等多樣化的解決方案。
基于LLM的DINSQL 和若干基于PLM的方法都采用了NatSQL。
? (4) 后處理：考慮了以下幾類后處理策略：
? (a) 自我糾錯，由DINSQL 提出，它允許智能體對生成的SQL進行自我審查，以修正潛在的錯誤。
? (b) 自我一致性檢查，涉及對單一自然語言查詢執行多種有效的SQL查詢，并通過比對結果的一致性，采用投票機制選出最合適的SQL作為最終結果。
這一策略在C3SQL和DAILSQL中得到了應用。
? (c) 執行引導的SQL篩選器，作為一個模塊，它依次執行智能體生成的SQL查詢，并將首次無誤的執行結果作為有效的SQL。
? (d) N-best重排器，通過為多個候選SQL查詢打分，挑選出可能性最高的查詢作為最終的查詢。
5 SuperSQL：頂尖NL2SQL方案
基于以上結論，作者提出了SuperSQL，SuperSQL包括如下組件：
? (1) 預處理：采用RESDSQL的架構鏈接和BRIDGE v2的數據庫內容；
? (2) 提示：DAILSQL的少量樣本模塊通過相似性挑選上下文中的示例；
? (3) SQL生成：采用OpenAI的貪婪解碼策略，不涉及多步驟或NatSQL；
? (4) 后處理：采用DAILSQL的自我一致性模塊。
SuperSQL在Spider開發集上對SuperSQL進行評估，EX達到了87.0%，超越了其他方法。
SuperSQL在中等難度、高難度以及額外難度子集上均有出色的表現，證實了其有效性。在BIRD開發集上，SuperSQL同樣展現了不俗的性能。
還對Spider和BIRD的測試集進行了SuperSQL評估，在Spider上EX達到了87.0%（排名第二），在BIRD上EX達到了62.66%（排名第九）。
SuperSQL在其設計空間內超越了所有基準。具體來說，在BIRD測試集上，SuperSQL比最強的基準——DAILSQL(SC)——提高了5.25%。這一提升主要得益于我們的NL2SQL360-AAS，它有效地在設計空間內基于不同基準尋找更優的模塊組合。預計通過NL2SQL360-AAS加入更多強大的基準將進一步優化SuperSQL。
SuperSQL的高效性能：SuperSQL在兩個數據集上分別獲得了99.18和61.99的VES總分，均優于其他方法。
6 未來研究方向
? 提升自然語言到SQL方法的可信度：現有方法可能產生不準確的SQL結果，原因可能包括：
? 1.自然語言查詢含糊且不完整
? 2.數據庫架構模糊且內容不規范
? 3.架構鏈接能力不足。
? 應對含糊和不明確的自然語言查詢：考慮以下策略來改善這些問題：
? (i) 查詢改寫器旨在自動優化給定的自然語言查詢，確保其明確性。
? (ii) 查詢自動補全通過推薦與數據庫高度相關的候選詞匯，協助用戶構建查詢。
? 解析自然語言到SQL的解決方案。
? (i) 自然語言到SQL調試工具能夠發現錯誤的SQL查詢，允許用戶逐步跟蹤SQL生成流程，并輔助識別錯誤或不匹配之處。
? (ii) SQL及查詢結果的解釋方法使用戶能夠評估生成的SQL和查詢結果是否符合預期。
? 打造高性價比的自然語言到SQL方法。基于LLM的自然語言到SQL方法前景廣闊，但在令牌消耗上成本較高，這影響了成本和推理時間。探索在減少令牌使用的同時提升準確性的方法至關重要。特
? 自適應訓練數據生成。自然語言到SQL方法的有效性極大程度上依賴于訓練數據的質量和廣度。這些方法在適應未知數據庫時常常遇到挑戰。一個充滿希望的研究方向是利用模型評估反饋動態生成（自然語言，SQL）對，這種方法通過從自然語言到SQL的性能洞察中汲取經驗，確保訓練數據的多樣性和高質量，解決領域適應問題。
本文轉載自 ??大語言模型論文跟蹤??，作者：HuggingAGI
