在當(dāng)今數(shù)字化時代，數(shù)據(jù)已經(jīng)成為了企業(yè)和組織的核心資產(chǎn)。然而，如何高效地從海量數(shù)據(jù)中提取有價值的信息，一直是困擾許多人的難題。想象一下，如果你能夠直接用自然語言向數(shù)據(jù)庫提問，就像和朋友聊天一樣輕松，那該有多方便？比如，你想知道第三季度西部地區(qū)最暢銷產(chǎn)品的銷售額，或者去年?duì)I銷支出與客戶獲取成本之間的相關(guān)性，只需要簡單地問一句，數(shù)據(jù)庫就能自動給出答案。這聽起來是不是很神奇？這就是Text-to-SQL技術(shù)所承諾的未來。

一、Text-to-SQL的挑戰(zhàn)與機(jī)遇

Text-to-SQL，即將人類的自然語言翻譯成數(shù)據(jù)庫能夠理解的結(jié)構(gòu)化查詢語言（SQL），聽起來似乎并不復(fù)雜，但實(shí)際操作起來卻困難重重。盡管像GPT-4和Gemini這樣的大型語言模型（LLM）在理解和生成人類語言方面展現(xiàn)出了驚人的潛力，但將復(fù)雜、含糊或微妙的問題準(zhǔn)確地轉(zhuǎn)換為精確可執(zhí)行的SQL代碼，仍然是一個巨大的挑戰(zhàn)。早期的嘗試往往因?yàn)樯烧Z法錯誤的查詢、誤解用戶意圖，或者“幻想”出錯誤的數(shù)據(jù)庫結(jié)構(gòu)而失敗。

不過，好消息是，這一領(lǐng)域正在迅速發(fā)展。最近，兩篇開創(chuàng)性的論文《CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL》（Pourreza等人，Google Cloud & Stanford）和《A PREVIEW OF XIYAN-SQL: A MULTI-GENERATOR ENSEMBLE FRAMEWORK FOR TEXT-TO-SQL》（高等人，阿里巴巴集團(tuán)）展示了新的方向：采用多智能體或多生成器集成框架。這些方法通過多個專業(yè)化的AI組件協(xié)同工作——就像一個專家團(tuán)隊(duì)一樣——來生成、優(yōu)化和選擇最佳的SQL查詢。

這些進(jìn)展不僅僅是小幅度的改進(jìn)，而是實(shí)現(xiàn)了質(zhì)的飛躍。在著名的BIRD和Spider等復(fù)雜基準(zhǔn)測試中，這些新框架取得了最先進(jìn)的成果。那么，Text-to-SQL究竟難在哪里？這些創(chuàng)新框架又是如何打破傳統(tǒng)限制的呢？接下來，讓我們深入探討一下。

二、為什么用自然語言與數(shù)據(jù)庫對話如此困難？

將自然語言轉(zhuǎn)換為SQL，看似簡單的任務(wù)背后隱藏著諸多復(fù)雜因素：

（一）自然語言的模糊性

人類的語言天生靈活且常常不精確。例如，“給我看看上個季度的銷售情況”，這里的“上個季度”是指日歷季度還是財年季度？“銷售”是指收入、利潤還是銷售數(shù)量？這些數(shù)據(jù)又存儲在哪個表中？這些問題都可能導(dǎo)致理解上的歧義。

（二）數(shù)據(jù)庫結(jié)構(gòu)的復(fù)雜性

現(xiàn)實(shí)世界的數(shù)據(jù)庫通常是復(fù)雜的關(guān)系網(wǎng)絡(luò)，包含眾多的表、列和關(guān)系。一個簡單的問題可能需要連接多個表，理解晦澀的列名（比如usr_acq_src而不是UserAcquisitionSource），以及復(fù)雜的外鍵關(guān)系。語言模型需要隱式地理解這種結(jié)構(gòu)。

（三）SQL的復(fù)雜性

SQL本身也有其復(fù)雜性。不同的數(shù)據(jù)庫使用略有不同的SQL方言（如SQLite、PostgreSQL、MySQL等）。知道何時使用GROUP BY、HAVING、嵌套查詢、窗口函數(shù)或特定的日期/時間函數(shù)，需要深入的理解。

（四）值的錨定

問題中常常包含具體的值，比如“加利福尼亞的客戶”或“價格超過50美元的產(chǎn)品”。AI需要正確識別這些值，并將其映射到數(shù)據(jù)庫中正確的列和格式（例如，知道“加利福尼亞”對應(yīng)State = 'CA'）。拼寫錯誤或變體（如“Calif.”或“Cali”）又增加了難度。

（五）LLM的局限性

• 上下文窗口限制：數(shù)據(jù)庫可能有數(shù)百個表和數(shù)千個列，將所有這些結(jié)構(gòu)信息以及用戶的問題都塞進(jìn)LLM有限的上下文窗口中通常是不可能的。
• 一致性問題：多次向LLM詢問同一個問題，可能會得到不同的SQL查詢結(jié)果，有些正確，有些則不正確。
• 忠實(shí)度問題：LLM生成的SQL可能看起來合理，但并不真正反映數(shù)據(jù)庫結(jié)構(gòu)或用戶的真實(shí)意圖。

這些挑戰(zhàn)表明，僅僅依靠強(qiáng)大的LLM進(jìn)行簡單的提示是遠(yuǎn)遠(yuǎn)不夠的，尤其是在復(fù)雜的真實(shí)場景中。

三、從簡單提示到智能選擇：Text-to-SQL的發(fā)展歷程

利用LLM實(shí)現(xiàn)有效Text-to-SQL的探索經(jīng)歷了快速的演變：

（一）零樣本/少樣本提示

最初的方法是將數(shù)據(jù)庫結(jié)構(gòu)和問題提供給LLM，有時附帶一些示例（少樣本），并要求其生成SQL。雖然這種方法在簡單情況下表現(xiàn)令人印象深刻，但在處理復(fù)雜問題時卻顯得力不從心。

（二）思維鏈（CoT）提示

受人類逐步解決問題的啟發(fā)，CoT提示鼓勵LLM“大聲思考”，在生成最終SQL之前先分解推理過程。這種方法在處理更復(fù)雜的查詢時表現(xiàn)有所提升。

（三）自一致性

認(rèn)識到LLM可以產(chǎn)生多種不同的答案，自一致性方法會生成多個SQL候選答案，并選擇執(zhí)行結(jié)果出現(xiàn)頻率最高的那個。雖然這種方法提高了魯棒性，但存在一個關(guān)鍵缺陷：最受歡迎的答案并不一定是正確的答案。

CHASE-SQL論文中生動地展示了這一局限性。在具有挑戰(zhàn)性的BIRD數(shù)據(jù)集上，自一致性方法的準(zhǔn)確率僅為68.84%，而如果有一個“先知”能夠從生成的候選答案中挑選出最佳查詢，潛在的準(zhǔn)確率可以達(dá)到82.79%。這14%的差距揭示了一個明確的機(jī)會：如果我們能夠生成一組高質(zhì)量的多樣化候選答案，并智能地選擇其中最佳的一個，那么將有可能實(shí)現(xiàn)顯著的性能提升。這也為CHASE-SQL和XiYan-SQL的多智能體/集成方法奠定了基礎(chǔ)。

四、深入剖析CHASE-SQL：多路徑推理的力量

CHASE-SQL引入了一個基于兩個核心思想的框架：通過不同的推理策略生成多樣化的高質(zhì)量SQL候選答案，并使用訓(xùn)練有素的“選擇代理”來挑選最佳答案。可以將其想象成派遣多個采用不同方法的專家偵探（生成器）去調(diào)查一個案件，然后由一位經(jīng)驗(yàn)豐富的首席偵探（選擇器）審查他們的發(fā)現(xiàn)，以確定最準(zhǔn)確的結(jié)論。

（一）候選答案生成：通往SQL的三條路徑

CHASE-SQL并不依賴單一的提示策略，而是采用了三種不同的方法，以高效的方式利用LLM的內(nèi)在知識，盡可能在單次LLM調(diào)用中完成：

1. 分而治之（DC）CoT

• 概念：將復(fù)雜的自然語言問題分解為更小、更易管理的子問題，為每個子問題生成偽SQL，分別解決它們，然后將解決方案組合成最終的SQL查詢。
• 類比：就像解決一個復(fù)雜的數(shù)學(xué)問題時，將其分解為更簡單的中間步驟，分別解決后再組合成最終答案。
• 優(yōu)勢：特別適用于涉及嵌套邏輯、復(fù)雜的WHERE/HAVING子句或高級數(shù)學(xué)運(yùn)算的復(fù)雜查詢。
• 示例：解決一個查詢，要求找到最低平均工資分行中年齡最小客戶的性別，需要分步驟進(jìn)行：找到最低平均工資的分行 -> 找到該分行中年齡最小的客戶 -> 獲取其性別。

2. 查詢計劃（QP）CoT

• 概念：從數(shù)據(jù)庫引擎的執(zhí)行計劃角度推理查詢。它模擬數(shù)據(jù)庫的步驟：識別表、規(guī)劃連接、過濾數(shù)據(jù)和選擇輸出列。
• 類比：就像GPS導(dǎo)航器在出發(fā)前規(guī)劃最優(yōu)路線（查詢計劃），考慮交通（數(shù)據(jù)分布）和道路類型（索引）。CHASE-SQL將技術(shù)性的EXPLAIN輸出轉(zhuǎn)換為LLM可以理解的推理鏈。
• 優(yōu)勢：在查詢需要復(fù)雜推理關(guān)系問題的不同部分與數(shù)據(jù)庫結(jié)構(gòu)之間的關(guān)系時表現(xiàn)出色（例如，復(fù)雜的連接、基于連接數(shù)據(jù)的過濾）。
• 示例：查找特定縣中具有特定餐食數(shù)量的高中，需要理解學(xué)校和免費(fèi)/減價餐（frpm）表之間的連接方式，以及如何根據(jù)兩個表的列進(jìn)行過濾。

3. 在線合成（OS）示例生成

• 概念：而不是使用通用的少樣本示例，這種方法會動態(tài)生成針對當(dāng)前測試問題數(shù)據(jù)庫結(jié)構(gòu)和潛在SQL功能（如JOIN、聚合）量身定制的合成問題-SQL對。它將涵蓋常見SQL模式的示例與使用當(dāng)前問題相關(guān)表/列的示例混合在一起。
• 類比：就像在LLM真正開始處理實(shí)際問題之前，給它一些高度相關(guān)的定制練習(xí)題，專注于它即將遇到的主題和結(jié)構(gòu)。
• 優(yōu)勢：幫助LLM更好地理解其正在處理的具體數(shù)據(jù)庫結(jié)構(gòu)，避免過度擬合到靜態(tài)示例中看到的通用模式。提高了多樣性和相關(guān)性。

（二）輔助角色：值檢索和查詢修復(fù)器

• LSH值檢索：在生成之前，CHASE-SQL使用局部敏感哈希（LSH）結(jié)合語義相似性，根據(jù)問題中的關(guān)鍵詞從數(shù)據(jù)庫中找到相關(guān)的值（例如，找到與“加利福尼亞”相似的數(shù)據(jù)庫條目）。這有助于為LLM的生成提供依據(jù)。
• 查詢修復(fù)器：如果生成的查詢在語法上有誤或返回錯誤/空結(jié)果，修復(fù)模塊（使用自我反思）會根據(jù)錯誤反饋嘗試對其進(jìn)行糾正。

（三）明星角色：選擇代理

這可能是與簡單自一致性相比最重要的創(chuàng)新。而不是簡單地選擇出現(xiàn)頻率最高的執(zhí)行結(jié)果，CHASE-SQL訓(xùn)練了一個單獨(dú)的、經(jīng)過微調(diào)的LLM（在他們的實(shí)驗(yàn)中是Gemini-1.5-flash）作為選擇代理。

• 機(jī)制：它進(jìn)行成對比較。給定兩個針對同一問題的候選SQL查詢（C?, C?），代理預(yù)測哪一個更有可能是正確的。它會考慮問題、數(shù)據(jù)庫結(jié)構(gòu)（特別是C?和C?使用的結(jié)構(gòu)的并集）以及查詢本身。
• 訓(xùn)練：代理在已知一個查詢正確而另一個錯誤的數(shù)據(jù)上進(jìn)行微調(diào)（從訓(xùn)練集中推導(dǎo)而來）。如果兩個候選查詢都正確/錯誤或產(chǎn)生相同的結(jié)果，則分別處理（如果結(jié)果一致，則優(yōu)先考慮一致性）。
• 最終選擇：每個候選查詢根據(jù)贏得的成對比較次數(shù)獲得一個分?jǐn)?shù)。得分最高的候選查詢被選中。
• 為什么更好：這種方法直接訓(xùn)練模型理解使一個SQL查詢比另一個更適合特定問題的細(xì)微差別，而不是依賴于可能有缺陷的假設(shè)，即正確性等于流行度。實(shí)驗(yàn)表明，這種經(jīng)過微調(diào)的二元分類顯著優(yōu)于零樣本LLM選擇和自一致性。

引人深思的問題：CHASE-SQL的選擇代理使用成對比較。是否可以通過訓(xùn)練更復(fù)雜的排名模型，同時評估多個候選答案，來實(shí)現(xiàn)更高的準(zhǔn)確性？

通過結(jié)合多樣化的生成路徑和智能的訓(xùn)練選擇，CHASE-SQL在發(fā)布時在BIRD開發(fā)集上取得了最先進(jìn)的成果（73.01%的執(zhí)行準(zhǔn)確率）。

五、深入剖析XiYan-SQL：集成力量與M-Schema革命

由阿里巴巴集團(tuán)開發(fā)的XiYan-SQL進(jìn)一步推動了多生成器概念的發(fā)展，明確創(chuàng)建了一個集成框架，融合了不同類型模型的優(yōu)勢，并引入了一種新穎的數(shù)據(jù)庫結(jié)構(gòu)表示方法。

（一）M-Schema：數(shù)據(jù)庫的更好藍(lán)圖

將數(shù)據(jù)庫結(jié)構(gòu)有效地呈現(xiàn)給LLM是一個核心挑戰(zhàn)。傳統(tǒng)方法常常不足：

• DDL（數(shù)據(jù)定義語言）：標(biāo)準(zhǔn)的CREATE TABLE語句雖然精確，但缺乏描述性上下文、示例值或清晰的關(guān)系標(biāo)記，這些都有助于LLM理解語義。
• MAC-SQL結(jié)構(gòu)：早期嘗試改進(jìn)這一問題，但XiYan-SQL發(fā)現(xiàn)其存在限制，例如缺少數(shù)據(jù)類型和冗長的格式。

XiYan-SQL引入了M-Schema，這是一種為LLM理解而設(shè)計的半結(jié)構(gòu)化表示：

• 層次化：清晰標(biāo)記數(shù)據(jù)庫ID（【DB_ID】）、表（# Table）和外鍵（【外鍵】）。
• 詳細(xì)列信息：對于每一列，它包括：

       a.名稱

       b.數(shù)據(jù)類型（對于正確操作至關(guān)重要）

       c.描述（從數(shù)據(jù)庫中提取，提供語義上下文）

       d.主鍵標(biāo)記

       e.示例值（簡潔且相關(guān)）

• 明確關(guān)系：清晰列出表之間的外鍵連接。
• 緊湊且清晰：使用特定的標(biāo)記和格式規(guī)則，比以前的方法更簡潔，同時保留了比DDL更重要的信息。

類比：可以把DDL看作是一個基礎(chǔ)的建筑藍(lán)圖。M-Schema就像是這個藍(lán)圖加上了建筑師詳細(xì)的注釋，解釋每個房間的用途、使用的材料、家具的擺放示例以及房間之間的管道連接。這種更豐富的上下文幫助LLM（建筑工人）更可靠地構(gòu)建正確的SQL查詢。實(shí)驗(yàn)表明，與DDL和MAC-SQL相比，M-Schema在不同LLM上都一致地提高了性能。

（二）結(jié)構(gòu)鏈接：聚焦相關(guān)性

在生成之前，XiYan-SQL執(zhí)行結(jié)構(gòu)鏈接，類似于CHASE-SQL：

• 檢索模塊：識別問題中的關(guān)鍵詞/實(shí)體，并使用語義相似性和LSH檢索可能相關(guān)的列和數(shù)據(jù)庫值。
• 列選擇器：使用LLM，通過少樣本示例提示，修剪檢索到的結(jié)構(gòu)，只保留與特定用戶查詢最相關(guān)的列。然后將這個最小化的、聚焦的結(jié)構(gòu)使用M-Schema格式化。

（三）混合生成：兩全其美（SFT + ICL）

XiYan-SQL采用了強(qiáng)大的生成器集成：

1. 微調(diào)（SFT）生成器

• 概念：使用專門針對Text-to-SQL任務(wù)微調(diào)的模型。這允許對特定的SQL方言或模式進(jìn)行更大的控制和優(yōu)化。
• 訓(xùn)練策略：一個兩階段過程：

     a.基礎(chǔ)語法訓(xùn)練：首先在涵蓋不同方言的基本SQL語法的大型數(shù)據(jù)集上進(jìn)行訓(xùn)練，創(chuàng)建一個有能力的基礎(chǔ)模型。

     b.生成增強(qiáng)訓(xùn)練：然后，使用多任務(wù)數(shù)據(jù)（SQL-to-Question、SQL-to-Evidence、SQL辨別/再生）和偏好數(shù)據(jù)（導(dǎo)致相同SQL的釋義問題）進(jìn)行進(jìn)一步微調(diào)，以提高語義理解和生成多樣化、高質(zhì)量輸出的能力。

• 優(yōu)勢：SFT模型可以更小、更快，并且在它們專門訓(xùn)練的任務(wù)上可能更準(zhǔn)確?？梢杂?xùn)練多個具有不同偏好的SFT生成器。

2. 上下文學(xué)習(xí)（ICL）生成器

• 概念：使用強(qiáng)大的通用LLM（如GPT-4o或Gemini 1.5 Pro），通過骨架相似性選擇的相關(guān)示例進(jìn)行提示。
• 骨架相似性：為了找到最佳示例，XiYan-SQL掩蓋用戶問題和訓(xùn)練問題中的命名實(shí)體（例如，“顯示<產(chǎn)品名稱>在<地區(qū)>的銷售情況”），然后比較這些結(jié)構(gòu)“骨架”。這避免了過度關(guān)注特定實(shí)體匹配，并找到了具有相似查詢結(jié)構(gòu)的示例。
• 優(yōu)勢：利用大型基礎(chǔ)模型的廣泛知識和推理能力，特別是對于在SFT訓(xùn)練數(shù)據(jù)中未得到充分代表的新穎或復(fù)雜查詢。

混合生成類比：想象建造一臺復(fù)雜的機(jī)器。你有專門從事特定組件的高技能專家（SFT生成器），還有可以利用手冊和示例解決新問題的天才總工程師（ICL生成器）。將他們的輸出結(jié)合起來，就為你提供了最大的成功機(jī)會。

（四）精煉器和選擇代理

• SQL精煉器：類似于CHASE-SQL，這個模塊會根據(jù)執(zhí)行反饋嘗試糾正生成候選答案中的語法或邏輯錯誤。
• 選擇代理：像CHASE-SQL一樣，XiYan-SQL使用經(jīng)過微調(diào)的模型進(jìn)行選擇，發(fā)現(xiàn)它優(yōu)于自一致性。它根據(jù)執(zhí)行結(jié)果對候選答案進(jìn)行分組，識別不一致的答案，并使用訓(xùn)練有素的選擇器從這個集合中選擇最合理的候選答案，基于問題和結(jié)構(gòu)上下文。他們還在選擇器的訓(xùn)練中加入了釋義，以處理SQL語法的變化。

通過結(jié)合M-Schema表示、聚焦結(jié)構(gòu)鏈接、混合SFT + ICL生成集成和智能選擇，XiYan-SQL在多個基準(zhǔn)測試中表現(xiàn)出色。

六、正面交鋒：CHASE-SQL與XiYan-SQL——性能與方法

這兩個框架都代表了Text-to-SQL的前沿水平，遠(yuǎn)遠(yuǎn)超越了早期的方法。它們的表現(xiàn)如何呢？

（一）性能快照

• BIRD數(shù)據(jù)集：CHASE-SQL在Gemini 1.5 Pro上取得了73.01%的執(zhí)行準(zhǔn)確率，而XiYan-SQL在GPT-4o、Gemini 1.5 Pro和Claude 3.5的混合模型上取得了更高的準(zhǔn)確率。
• Spider數(shù)據(jù)集：XiYan-SQL在多個模型組合下表現(xiàn)出色，尤其是在處理復(fù)雜的多表連接和高級SQL功能時。

（二）方法關(guān)鍵差異

• 多生成器與訓(xùn)練選擇代理：兩個框架都驗(yàn)證了使用多個生成器和專門訓(xùn)練的選擇代理優(yōu)于簡單的自一致性。
• XiYan-SQL的全面性：XiYan-SQL似乎更具綜合性，它結(jié)合了SFT和ICL生成，并引入了新穎的M-Schema，這可能有助于其在不同數(shù)據(jù)庫類型和方言上實(shí)現(xiàn)更廣泛的SOTA性能。
• CHASE-SQL的推理模式：CHASE-SQL提供了在ICL框架內(nèi)有效的特定推理模式（DC-CoT、QP-CoT）的深入見解，并明確展示了經(jīng)過訓(xùn)練的成對選擇的優(yōu)勢。

這兩個框架都是重大進(jìn)展，將Text-to-SQL的能力推向了更接近無縫自然語言數(shù)據(jù)交互的夢想。

七、技術(shù)深度剖析：幕后細(xì)節(jié)

對于對技術(shù)細(xì)節(jié)感興趣的讀者來說，以下是這些框架背后的一些關(guān)鍵技術(shù)：

（一）LSH（局部敏感哈希）

兩個框架都使用LSH進(jìn)行值檢索。LSH是一種算法，可以在高維空間中高效地找到近似最近鄰。它將相似的輸入項(xiàng)以高概率哈希到相同的“桶”中。這使得系統(tǒng)能夠快速找到與用戶問題中提到的關(guān)鍵字在語法或語義上相近的數(shù)據(jù)庫值，而無需與數(shù)據(jù)庫中的每個值進(jìn)行比較。

（二）成對選擇訓(xùn)練（CHASE-SQL）

為了訓(xùn)練選擇代理，他們?yōu)锽IRD訓(xùn)練集中的問題生成候選查詢。他們根據(jù)執(zhí)行結(jié)果對這些候選查詢進(jìn)行聚類。對于一對候選查詢（C?來自與真實(shí)結(jié)果匹配的聚類，C?來自不匹配的聚類），他們創(chuàng)建訓(xùn)練示例，如（問題，結(jié)構(gòu)（C?, C?），C?，C?，標(biāo)簽=正確索引）。隨機(jī)打亂順序以避免順序偏差。

（三）骨架相似性（XiYan-SQL）

這涉及到使用命名實(shí)體識別（NER）工具（如NLTK）來識別用戶查詢和潛在示例查詢中的實(shí)體（PERSON、LOCATION、ORGANIZATION、數(shù)字等）。這些實(shí)體被替換為通用占位符（例如，、）。然后計算這些掩蓋后的“骨架”之間的相似性（可能使用嵌入余弦相似性），允許檢索具有相似結(jié)構(gòu)的示例，而不管提到的具體實(shí)體是什么。

（四）M-Schema格式細(xì)節(jié)（XiYan-SQL）

精確的格式使用特定的類似Markdown的語法（# Table、【DB_ID】、【外鍵】）和列的元組表示（名稱：TYPE，描述，主鍵？，示例：[vals]），使其易于被LLM解析，同時保持信息密集。

（五）SFT訓(xùn)練階段（XiYan-SQL）

兩階段訓(xùn)練（基礎(chǔ)語法 -> 生成增強(qiáng)）是一種常見策略。第一階段構(gòu)建基礎(chǔ)能力，第二階段通過更復(fù)雜的任務(wù)（如SQL-to-Question，這迫使模型更好地理解SQL在上下文中的含義）和偏好調(diào)整（學(xué)習(xí)風(fēng)格變化）來專業(yè)化模型。

八、現(xiàn)實(shí)世界的影響與未來展望

CHASE-SQL和XiYan-SQL所展示的進(jìn)展具有重要意義：

（一）民主化數(shù)據(jù)訪問

更可靠的Text-to-SQL降低了非技術(shù)用戶（業(yè)務(wù)分析師、經(jīng)理、研究人員）直接查詢數(shù)據(jù)庫的門檻，加快了洞察力的生成。

（二）增強(qiáng)的BI工具

商業(yè)智能平臺可以整合這些先進(jìn)的框架，提供更強(qiáng)大、更靈活的自然語言查詢能力。

（三）更智能的對話式AI

聊天機(jī)器人和虛擬助手可以更擅長回答數(shù)據(jù)驅(qū)動的問題，通過準(zhǔn)確查詢后端數(shù)據(jù)庫。

（四）數(shù)據(jù)科學(xué)加速

數(shù)據(jù)科學(xué)家可以利用自然語言更快地進(jìn)行初始數(shù)據(jù)探索或特征工程。

然而，旅程尚未結(jié)束。未來的發(fā)展方向包括：

（一）更好的選擇

超越成對比較，開發(fā)更復(fù)雜的排名模型用于選擇。

（二）處理結(jié)構(gòu)演變

數(shù)據(jù)庫會隨著時間而變化。Text-to-SQL系統(tǒng)需要優(yōu)雅地適應(yīng)結(jié)構(gòu)更新。

（三）復(fù)雜推理

處理多輪對話式查詢，處理隱式上下文，并執(zhí)行更復(fù)雜的分析推理（例如，通過SQL進(jìn)行預(yù)測、異常檢測）。

（四）跨領(lǐng)域泛化

在全新的數(shù)據(jù)庫和領(lǐng)域中，以最少的特定訓(xùn)練或提示實(shí)現(xiàn)更好的性能。

（五）可解釋性

為用戶提供清晰的解釋，說明自然語言查詢是如何轉(zhuǎn)換為SQL的，建立信任并允許進(jìn)行修正。

（六）超越關(guān)系型數(shù)據(jù)庫

將這些強(qiáng)大的技術(shù)更穩(wěn)健地擴(kuò)展到圖數(shù)據(jù)庫（如Neo4j、Nebula Graph——XiYan-SQL已經(jīng)開始使用nGQL）、文檔存儲和其他非關(guān)系型數(shù)據(jù)源。

引人深思的問題：隨著Text-to-SQL變得越來越強(qiáng)大，允許通過自然語言訪問敏感數(shù)據(jù)庫時，可能對數(shù)據(jù)安全和隱私帶來哪些風(fēng)險？如何緩解這些風(fēng)險？

九、結(jié)語：數(shù)據(jù)交互的新紀(jì)元

Text-to-SQL是使數(shù)據(jù)真正可訪問的基石技術(shù)。盡管LLM提供了重要的初始推動力，但CHASE-SQL和XiYan-SQL等框架表明，實(shí)現(xiàn)穩(wěn)健的現(xiàn)實(shí)世界性能的路徑在于更復(fù)雜、多組件的架構(gòu)。

關(guān)鍵要點(diǎn)如下：

• 多智能體/集成至關(guān)重要：僅依賴單一LLM提示通常是不夠的。使用多個專業(yè)化的生成器（無論是多樣化的提示策略還是SFT/ICL模型的組合）增加了生成正確查詢的機(jī)會。
• 智能選擇優(yōu)于一致性：簡單地選擇最常見的答案（自一致性）是有缺陷的。訓(xùn)練專門的選擇代理，根據(jù)細(xì)微差別和上下文評估候選答案，可以顯著提高結(jié)果。
• 結(jié)構(gòu)表示很重要：將數(shù)據(jù)庫結(jié)構(gòu)呈現(xiàn)給LLM的方式深刻影響其理解。像M-Schema這樣的創(chuàng)新比傳統(tǒng)方法具有明顯優(yōu)勢。
• 輔助組件至關(guān)重要：有效的值檢索、列選擇以及查詢精煉/修復(fù)在整體流程中發(fā)揮著重要作用。
• 最先進(jìn)的技術(shù)正在迅速發(fā)展：這些框架在具有挑戰(zhàn)性的基準(zhǔn)測試中顯著提高了性能，使無縫自然語言數(shù)據(jù)交互的夢想更接近現(xiàn)實(shí)。

CHASE-SQL和XiYan-SQL團(tuán)隊(duì)背后的工作代表了一個巨大的飛躍。通過巧妙地結(jié)合多樣化的生成技術(shù)、優(yōu)化的結(jié)構(gòu)表示和智能選擇機(jī)制，他們?yōu)槟軌虿粌H理解我們關(guān)于數(shù)據(jù)的問題，還能準(zhǔn)確檢索答案的AI系統(tǒng)鋪平了道路，為每個人解鎖洞察力。

本文轉(zhuǎn)載自公眾號Halo咯咯    作者：基咯咯

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