?在互聯網時代，數據爆發式增長，如果高效的分析數據成為一個亟待解決的問題。SQL是數據分析師的常用工具，編寫高效的SQL需要用戶具備一定的IT基礎，對于普通人員來說存在一定門檻。

Text-to-SQL技術可以實現自然語言轉換成SQL，用戶只需要用自然語言描述自己的目標，Text-to-SQL工具就可以自動生成對應的SQL，大大降低SQL編寫的門檻和效率。

為了提高Text-to-SQL的效果，北航提出了一個基于LLM和智能體的Text-to-SQL框架。實驗表明，新方法在執行準確率和完全匹配準確率上得到顯著提升。論文地址：https://arxiv.org/pdf/2408.16991

最近我們建了交流群，感興趣的朋友可以點贊關注后加我v: longyunfeigu 拉進群，也可以直接掃描下面二維碼加群

摘要

最新的Text-to-SQL方法利用大型語言模型（LLMs）和數據庫系統反饋，有效解決SQL查詢中的執行錯誤。然而，對于不引發執行異常但與數據庫不匹配的問題，如條件不匹配和嚴格約束不匹配等方面表現出挑戰性。

為解決此類問題，提出了一個名為SQL檢查和細化的工具輔助代理框架，裝備有兩個專門工具：檢索器和檢測器，能診斷和糾正SQL查詢與數據庫的不匹配問題。這增強了LLMs處理實際查詢的能力。

同時引入了一個新的數據集Spider-Mismatch，專門構建以反映真實場景中遇到的條件不匹配問題。實驗結果表明，該方法在Spider和Spider-Realistic數據集的平均結果上實現了最高性能，并且在更現實的數據集Spider-Mismatch上明顯優于基線方法。

簡介

Text-to-SQL任務致力于將自然語言問題自動轉化為結構化查詢語言（SQL）查詢，便于非專家用戶訪問數據庫。歷史上，此任務的研究集中于開發需要大量標注數據的訓練模型。近期，研究轉向利用大型語言模型（LLMs）和上下文學習（ICL），通過提供示例進行模型微調。最初的ICL方法旨在通過創建更好的提示來利用LLMs的推理能力，而后續研究通過多步驟過程輔助LLMs生成SQL查詢。這包括自校正方法和基于執行反饋的細化方法，后者通過數據庫管理系統（DBMS）執行反饋來改進查詢。

盡管這些方法通過DBMS反饋解決執行錯誤，但難以處理不觸發執行異常的數據庫不匹配錯誤。這包括條件不匹配和查詢器約束的不匹配，這兩種情況在現實場景中常見，下圖展示了這兩種錯誤：

為了解決這些問題，提出了一個工具輔助代理框架，使用數據庫檢索器和錯誤檢測器工具來檢測和糾正SQL查詢中的錯誤。

此外，主流Spider數據集及其變體很少反映真實場景中的條件不匹配問題。為了彌合這一差距，引入了Spider-Mismatch數據集，專門設計來突出SQL條件子句中的不匹配問題，通過特定干擾挑戰模型，更貼合現實世界情況。

相關工作

Text-to-SQL

在近年來，大型語言模型（LLMs）對于文本轉SQL（Text-to-SQL）任務的應用成為了研究的熱點，眾多研究致力于通過各種方法提升LLMs在此領域中的表現。特別是，關于如何設計更有效的提示以挖掘LLMs在解析Text-to-SQL任務時的潛力成為了研究的焦點。

例如，ACT-SQL和一個由Tai等人在2023年提出的方法，都通過構建復雜的思維鏈提示來增強LLMs的推理能力。另一方面，DAIL-SQL在2024年由Gao等人進行的研究中，對LLM在Text-to-SQL任務中的提示工程進行了系統性的探討，這包括了問題的表示、示例的選擇以及示例的組織方式。

近期的研究趨向采用一種多階段的框架策略，意圖通過將Text-to-SQL任務細分為若干更小的子任務，并為每個子任務定制專門的提示，從而提升LLMs的處理性能。比如，Pourreza和Rafiei在2024年提出的DINSQL方法，就是將Text-toSQL任務分解為模式鏈接、問題分類、SQL生成及自相關四個子步驟，以期減輕任務的整體難度。接著，Xie等人在2024年進一步對DINSQL的流程進行了增強，引入了DEA-SQL，該方法不僅沿用了DINSQL的框架，還新增了一個主動學習模塊。

為了降低生成SQL查詢中的錯誤率，多階段方法通常會集成一個錯誤校正模塊。DIN-SQL和DEA-SQL通過采用自我糾錯機制，指導LLMs依據提示中的規則對SQL進行修正。此外，MAC-SQL方法由Wang等人在2024年提出，它通過利用數據庫管理系統的反饋來指導LLMs，專注于解決SQL查詢執行過程中的錯誤。

LLM Agent

隨著大型語言模型（LLM）的迅速發展，基于這些模型的代理技術的應用潛力正逐步被挖掘。這些代理的核心優勢之一在于它們的識別工具能力，此功能極大地彌合了LLM代理與外部世界之間的信息鴻溝。在此背景下，多個項目和研究團隊投入了大量資源，開發出了一系列旨在增強這些代理功能的工具和框架。

AutoGPT（團隊于2023年提出）是一種開源的AI代理實現，它集成了眾多工具，旨在提升單個代理的能力。同時，OpenAgents（由Xie等人在2023年開發）設計了三種不同的代理，每種都聚焦于特定的應用領域，并搭載了專為該領域定制的工具。

另外，ToolLLM（由Qin等人在2024年提出）和API-Bank（由Li等人在2023年提出）專注于促進LLM代理與支持RESTful API的開放域實際應用之間的交互。這為代理提供了與真實世界應用程序進行交互的能力，極大地擴展了它們的應用范圍。

在更具體的應用場景中，如Text-to-SQL任務，MAC-SQL（由Wang等人在2024年提出）引入了一個多代理框架。該框架旨在獨立解決Text-to-SQL轉換過程中遇到的各種子任務，例如通過執行異常來精細調整SQL語句。盡管在利用工具診斷SQL查詢錯誤及提供反饋以幫助LLM代理進行SQL細化方面已取得了一定進展，但在檢測和解決SQL查詢與數據庫不匹配的問題上，相關研究仍相對匱乏。

為了填補這一研究空白，研究人員開始探索使用工具來識別和解決SQL查詢中的數據庫不匹配問題。這一進展不僅提高了基于LLM的代理處理復雜查詢的能力，也為進一步提升代理與外部數據交互的準確性和效率開辟了新的路徑。

方法

基于LLM的Text-to-SQL任務

LLM的方法通常采用上下文學習范式，將Text-to-SQL視為生成任務。生成過程可以公式化為：

其中，對大語言模型f的輸入包括任務指令提示I、一組演示示例E、數據庫D的數據庫模式S和新查詢Q。證明E = [（S，Q，Y），...，（S，Q，Y）]由來自訓練集的k個示例組成，每個示例具有預期輸出Y。LLM的輸出Y可以是SQL查詢或其他形式的中間結果。

框架

Tool-SQL，這是一個工具輔助的代理框架，旨在使用基于LLM的代理指導的多個工具來持續檢查和改進SQL查詢。這個框架定義了一組Python函數作為基于LLM的代理的動作空間。這些函數對應于不同的SQL子句。輸出Y是表示SQL查詢的操作序列，而不是SQL查詢本身。通過Python解釋器執行操作序列，工具集中的每個工具T都被調用，以根據問題Q和數據庫D檢查函數調用Y中的不同錯誤。如果檢測到錯誤，每個工具都會向基于LLM的代理提供特定的反饋，幫助代理細化特定的SQL子句，而不是盲目地修改SQL查詢。檢查過程可表述為：

檢查和細化過程是迭代的。在基于LLM的代理生成一系列操作之后，將調用所有工具來檢查潛在問題。如果所有工具都批準了操作序列，則它將用于組裝最終的SQL查詢。相反，如果任何工具檢測到問題，則代理將基于原始序列Y和來自工具的反饋來生成新的動作序列Y。該過程可以重復多次，直到所有工具都批準該序列或達到最大嘗試次數。細化過程可以公式化為：

大致方法如下：

1. 為基于LLM的代理設計了一系列Python函數調用，以執行一系列操作
2. 方法中集成了兩個工具：數據庫索引器和錯誤檢測器。前者檢查SQL條件子句的有效性，并通過探索數據庫內容來協助代理，而后者則根據SQL執行語法、數據庫模式和SQL功能或領域專家定義的更嚴格的約束來檢測查詢中的錯誤
3. 獲取最終SQL查詢的過程，其中Python解釋器執行動作序列，并使用LLM補充SQL查詢中缺失的信息

函數

在設計了一套基于SQL的函數庫，該庫包含八個專門針對構建和細化SQL查詢的Python函數。這些函數分別對應SQL的不同子句，以便簡化和組織查詢的構建過程。例如，處理“WHERE”子句的任務交由“add where”函數負責。進一步地，為了減少基于大型語言模型（LLM）的代理在執行任務時需要考慮的操作范圍，將SQL中用于查詢串聯的操作符（如“UNION”、“INTERSECT”和“EXCEPT”）整合進一個統一的“添加合并”函數中。同時，邏輯運算符如“AND”和“OR”，通常用于“WHERE”或“HAVING”子句，被設計成在函數內部處理，留給LLM在最終步驟中解決，以此簡化查詢構建過程。每個函數接受特定于其對應SQL子句的參數，例如，一個“WHERE”子句的“A = B”條件，會以“add where（A，=，B）”的形式傳遞給函數。這種參數化的設計方式不僅提高了工具在診斷SQL子句錯誤方面的效率，也減少了字符串解析的復雜度。

檢驗工具

數據庫檢索器

定義了兩個工具-數據庫檢索器和錯誤檢測器，它們檢查SQL查詢中的問題，并幫助基于LLM的代理改進SQL查詢。

數據庫檢索器數據庫檢索器的主要職責是協助基于LLM的代理驗證SQL條件子句的正確性。如圖3所示，檢索器檢查條件動作中的參數（例如，“add where”和“add having”）匹配數據庫中的任何條目，如果沒有找到匹配項，則為代理提供對類似單元格的引用。通過使用檢索器，代理可以將SQL查詢中的值與數據庫中相應的單元格對齊，或者決定從條件子句中排除列，這對于實際場景中的Text-to-SQL任務至關重要。在現實環境中，用戶問題通常包含與數據庫中的標準化值不同的不規則值，因此在執行查詢之前需要進行驗證。此外，用戶問題的模糊性可能使其具有挑戰性，即使對于高級代理來說，在條件子句中定位正確的列名也是如此。

錯誤檢測器

錯誤檢測器的功能在于識別與嚴格約束不匹配的問題，并間接訪問數據庫以發現SQL執行中的錯誤。當LLM生成的SQL包含錯誤時，通常是由于對特定領域的SQL不熟悉或受到幻覺等因素的影響，這使得錯誤檢測變得尤為重要。為了進行廣泛的檢測，開發了一個驗證程序，它通過解析Python函數的參數，并在數據庫的協助下執行。

與Wang et al. 2024提出的MAC-SQL方法不同，該方法并不直接在數據庫管理系統（DBMS）中執行SQL查詢來獲取反饋。這種差異化的做法是因為直接執行SQL查詢的方法在錯誤檢測能力上有限，通常只能捕捉到語法錯誤和數據庫模式錯誤等執行異常。

在進行錯誤檢測的過程中，首要步驟是提取數據庫的模式信息，這包括所有表名、列名及其類型、外鍵關系等。隨后，通過設計的驗證程序對照這些信息檢查函數參數是否滿足SQL操作和數據庫模式的要求。針對更嚴格的約束，診斷過程聚焦于基于SQL特征來檢測諸如外鍵關系不匹配、"JOIN"操作的冗余或缺失、條件子句中列類型不匹配、以及"GROUP BY"子句的缺失或不當使用等錯誤。

此外，還特別強調了該工具的可擴展性，它能夠輕松適應檢測用戶定義的約束。在實際應用場景中，這意味著通過分析函數調用的參數，工具可以針對具有特定數據處理需求的場景進行調整。例如，對于需要排除"NULL"值或需要以特定格式處理列數據的情況，該工具能夠進行相應的擴展以滿足這些特定的需求。

SQL生成

在最后階段，我們使用糾正后的動作序列生成SQL查詢。我們使用Python解釋器來執行這些函數調用并提取SQL查詢的主要組件。對于“WHERE”或“HAVING”子句中缺失的邏輯運算符“AND”和“OR”（不包括在動作序列中），我們依靠LLM來預測它們。有了所有的組件，我們就可以組裝完整的SQL查詢了。

Spider-Mismatch數據集

數據集構建

在真實世界的應用場景中，用戶提出的問題呈現出廣泛的多樣性，這些問題與數據庫的實際內容之間往往存在不小的差距。為了更精確地評價不同模型在實際環境中的適應性及泛化能力，Spider基準測試應運而生。然而，Spider基準并非完美，因此衍生出了幾個新的數據集，包括Spider-SYN、Spider-DK和Spider-Realistic，以便更好地應對不同的挑戰。同時，Bird數據集的推出，關注點放在了處理更為復雜的數據庫內容和提升SQL查詢的效率上。大多數現行方法并沒有充分考慮到用戶問題中提到的數值與數據庫中實際數值之間的潛在不匹配問題，為解決這一問題，SpiderMismatch數據集被引入。這個新數據集通過增添模型在生成正確的條件子句時所需克服的難度，引入了用戶問題與數據庫內容之間的微妙差異性，從而推動了模型性能的進一步提升。

條件后處理模塊

當前的LLM Text-to-SQL技術在處理SQL查詢中的值方面存在不足，這讓生成準確的條件子句變得復雜。針對這一問題，本文引入了一個被稱為條件后處理的新模塊。該模塊的作用是從預測的SQL語句中抽取出值的引用，并利用SimCSE檢索技術，將每個值與其所在列最匹配的單元格進行替換。為了確保評估的一致性，本研究在所有測試方法中均應用了條件后處理模塊，以便進行公正比較。

實驗

實驗設置

1. **數據集: **使用Spider和Spider-Realistic數據集
2. **LLM: **使用ChatGPT和GPT-4
3. **評估指標: **包括執行準確率和完全匹配準確率
4. **基線: **包括DIN-SQL、MAC-SQL和ACT-SQL

DIN-SQL：一種多階段方法，采用自校正方法來細化SQL查詢; MAC-SQL：一種多代理協作方法，根據DBMS的反饋改進SQL; ACT-SQL：一種單階段方法，引入了用于SQL生成的思想鏈范例，與使用ChatGPT的其他方法相比，該方法在Spider-Realistic數據集上取得了優異的結果。

結果

實驗結果表明，Tool-SQL在Spider數據集和Spider-Realistic數據集上的執行準確率最高，且在Spider-Mismatch數據集上也表現出色。Tool-SQL的性能穩定，能夠有效地處理不同場景下的挑戰。

消融分析

研究發現，在去除數據庫檢索功能的情況下，ChatGPT與GPT-4的執行效率分別降低了4.1%和3.2%。這一現象揭示了，在面對用戶提問的多義性時，語言模型生成精確的SQL條件子句遇到了挑戰。進一步的實驗顯示，移除錯誤檢測機制對ChatGPT的性能影響更為顯著，暗示了在錯誤識別方面，性能較弱的模型可能更加脆弱。另外，當錯誤檢測工具被數據庫驗證工具取代時，ChatGPT和GPT-4的準確性分別降低了1.6%和1.0%，這一結果強調了錯誤檢測功能在維護SQL查詢準確性中的關鍵作用。

討論

研究展示了ChatGPT和GPT-4在作為優化代理時，對SQL查詢錯誤修正過程的影響。主要發現是大部分錯誤能通過單次修正得到解決，尤其是那些涉及執行錯誤和約束不匹配的情況。然而，仍需多輪迭代來精細調整，特別是對條件子句的修改。這意味著在處理復雜的用戶問題時，基于大型語言模型（LLM）的代理可能需要多次嘗試才能找到正確的條件。

實驗結果還表明，結合Tool-SQL的ChatGPT和GPT-4在進行錯誤修正時的平均迭代次數分別為0.74和0.44。這種方法避免了在沒有錯誤檢測時引入不必要的步驟，減少了額外成本。

此外，研究還考察了去除條件后處理模塊對性能的影響。結果顯示，移除該模塊后，所有基準測試的性能都有所下降，這強調了LLM預測值與數據庫實際值之間存在差異。盡管如此，由于該方法能夠協助LLM代理生成正確的條件子句，去除后處理模塊并未導致性能降低。反之，該模塊在實際應用中可能會導致錯誤的答案，因為它會強制替換條件子句中的值為與之最相似的數據庫單元格，從而可能引起無答案或錯誤答案的問題。

結論

在本文中，我們提出了工具SQL框架設計的SQL生成在更現實的情況下。這個框架著重于使用基于LLM的代理來改進SQL查詢，并從各種工具中獲得有針對性的反饋，以檢查SQL查詢中的特定問題。我們設計了一個數據庫檢索器和一個錯誤檢測器，以解決現實世界中常見的潛在數據庫不匹配問題。在Spider數據集和Spider-Realistic數據集上的平均實驗結果表明，我們的方法在少數情況下達到了最高的性能。此外，在SpiderMismatch上的實驗結果表明，該方法在實際干擾下仍能保持較高的性能，說明了該方法在增強SQL查詢性能方面的有效性。

?

本文轉載自公眾號AI 博物院 作者：longyunfeigu

原文鏈接：??https://mp.weixin.qq.com/s/MVn_eNQ8kxqIHrqJFG128Q??