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

Text-to-SQL技術(shù)可以實(shí)現(xiàn)自然語言轉(zhuǎn)換成SQL，用戶只需要用自然語言描述自己的目標(biāo)，Text-to-SQL工具就可以自動生成對應(yīng)的SQL，大大降低SQL編寫的門檻和效率。

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

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

摘要

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

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

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

簡介

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

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

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

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

相關(guān)工作

Text-to-SQL

在近年來，大型語言模型（LLMs）對于文本轉(zhuǎn)SQL（Text-to-SQL）任務(wù)的應(yīng)用成為了研究的熱點(diǎn)，眾多研究致力于通過各種方法提升LLMs在此領(lǐng)域中的表現(xiàn)。特別是，關(guān)于如何設(shè)計更有效的提示以挖掘LLMs在解析Text-to-SQL任務(wù)時的潛力成為了研究的焦點(diǎn)。

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

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

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

LLM Agent

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

AutoGPT（團(tuán)隊(duì)于2023年提出）是一種開源的AI代理實(shí)現(xiàn)，它集成了眾多工具，旨在提升單個代理的能力。同時，OpenAgents（由Xie等人在2023年開發(fā)）設(shè)計了三種不同的代理，每種都聚焦于特定的應(yīng)用領(lǐng)域，并搭載了專為該領(lǐng)域定制的工具。

另外，ToolLLM（由Qin等人在2024年提出）和API-Bank（由Li等人在2023年提出）專注于促進(jìn)LLM代理與支持RESTful API的開放域?qū)嶋H應(yīng)用之間的交互。這為代理提供了與真實(shí)世界應(yīng)用程序進(jìn)行交互的能力，極大地擴(kuò)展了它們的應(yīng)用范圍。

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

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

方法

基于LLM的Text-to-SQL任務(wù)

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

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

框架

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

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

大致方法如下：

1. 為基于LLM的代理設(shè)計了一系列Python函數(shù)調(diào)用，以執(zhí)行一系列操作
2. 方法中集成了兩個工具：數(shù)據(jù)庫索引器和錯誤檢測器。前者檢查SQL條件子句的有效性，并通過探索數(shù)據(jù)庫內(nèi)容來協(xié)助代理，而后者則根據(jù)SQL執(zhí)行語法、數(shù)據(jù)庫模式和SQL功能或領(lǐng)域?qū)＜叶x的更嚴(yán)格的約束來檢測查詢中的錯誤
3. 獲取最終SQL查詢的過程，其中Python解釋器執(zhí)行動作序列，并使用LLM補(bǔ)充SQL查詢中缺失的信息

函數(shù)

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

檢驗(yàn)工具

數(shù)據(jù)庫檢索器

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

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

錯誤檢測器

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

與Wang et al. 2024提出的MAC-SQL方法不同，該方法并不直接在數(shù)據(jù)庫管理系統(tǒng)（DBMS）中執(zhí)行SQL查詢來獲取反饋。這種差異化的做法是因?yàn)橹苯訄?zhí)行SQL查詢的方法在錯誤檢測能力上有限，通常只能捕捉到語法錯誤和數(shù)據(jù)庫模式錯誤等執(zhí)行異常。

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

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

SQL生成

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

Spider-Mismatch數(shù)據(jù)集

數(shù)據(jù)集構(gòu)建

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

條件后處理模塊

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

實(shí)驗(yàn)

實(shí)驗(yàn)設(shè)置

1. **數(shù)據(jù)集: **使用Spider和Spider-Realistic數(shù)據(jù)集
2. **LLM: **使用ChatGPT和GPT-4
3. **評估指標(biāo): **包括執(zhí)行準(zhǔn)確率和完全匹配準(zhǔn)確率
4. **基線: **包括DIN-SQL、MAC-SQL和ACT-SQL

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

結(jié)果

實(shí)驗(yàn)結(jié)果表明，Tool-SQL在Spider數(shù)據(jù)集和Spider-Realistic數(shù)據(jù)集上的執(zhí)行準(zhǔn)確率最高，且在Spider-Mismatch數(shù)據(jù)集上也表現(xiàn)出色。Tool-SQL的性能穩(wěn)定，能夠有效地處理不同場景下的挑戰(zhàn)。

消融分析

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

討論

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

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

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

結(jié)論

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

?

本文轉(zhuǎn)載自公眾號AI 博物院 作者：longyunfeigu

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