NL2SQL技術方案系列(1)：NL2API、NL2SQL技術路徑選擇；LLM選型與Prompt工程技巧，揭秘專案落地最佳化之道

汀、人工智能發表於2024-04-19
SQLAPI

NL2SQL技術方案系列(1)：NL2API、NL2SQL技術路徑選擇；LLM選型與Prompt工程技巧，揭秘專案落地最佳化之道

NL2SQL基礎系列(1)：業界頂尖排行榜、權威測評資料集及LLM大模型（Spider vs BIRD）全面對比優劣分析[Text2SQL、Text2DSL]

NL2SQL基礎系列(2)：主流大模型與微調方法精選集，Text2SQL經典演算法技術回顧七年發展脈絡梳理

NL2SQL進階系列(1)：DB-GPT-Hub、SQLcoder、Text2SQL開源應用實踐詳解

NL2SQL進階系列(2)：DAIL-SQL、DB-GPT開源應用實踐詳解[Text2SQL]

NL2SQL進階系列(3)：Data-Copilot、Chat2DB、Vanna Text2SQL最佳化框架開源應用實踐詳解[Text2SQL]

☆☆NL2SQL進階系列(4)：ConvAI、DIN-SQL、C3-浙大、DAIL-SQL-阿里等16個業界開源應用實踐詳解[Text2SQL]

☆☆NL2SQL進階系列(5)：論文解讀業界前沿方案（DIN-SQL、C3-SQL、DAIL-SQL、SQL-PaLM）、新一代資料集BIRD-SQL解讀

NL2SQL實踐系列(1)：深入解析Prompt工程在text2sql中的應用技巧

NL2SQL實踐系列(2)：2024最新模型實戰效果(Chat2DB-GLM、書生·浦語2、InternLM2-SQL等)以及工業級案例教學

1.大模型之NL2SQL、資料智慧分析簡介

NL2SQL任務的目標是將使用者對某個資料庫的自然語言問題轉化為相應的SQL查詢。隨著LLM的發展，使用LLM進行NL2SQL已成為一種新的正規化。在這一過程中，如何利用提示工程來發掘LLM的NL2SQL能力顯得尤為重要。

現狀：大語言模型雖然在不斷的迭代過程中越來越強大，但類似商業智慧這樣的企業級應用要遠比分析一個 Excel 檔案、總結一個 PDF 檔案的問題要複雜的多：

  • 資料結構複雜：企業資訊系統的資料結構複雜性遠遠超過幾個簡單的 Excel 檔案，一個大型企業應用可能存在幾百上千個資料實體，所以在實際應用中，大型 BI 系統會在前端經過匯聚、簡化與抽象成新的語義層，方便理解。

  • 資料量較大：分析類應用以海量歷史資料為主，即使一些資料在分析之前會經過多級彙總處理。這決定了無法在企業應用中把資料簡單的離線成檔案進行分析處理。

  • 分析需求複雜：企業應用的資料分析需求涵蓋及時查詢、到各個維度的報表與指標展現、資料的上下鑽、潛在資訊的挖掘等，很多需求有較複雜的後端處理邏輯。

這些特點決定了，當前大語言模型在企業資料分析中的應用無法完全的取代目前所有的或者部分的分析工具。其合適的定位或許是：作為現有資料分析手段的一種有效補充，在部分需求場景下，給經營決策人員提供一種更易於使用與互動的分析工具。

具體的應用場景包括：‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

  • 及時資料查詢。提供對運營或統計資料的簡單自定義查詢，當然你只需要使用自然語言。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

  • 傳統 BI 工具能力的升級。很多傳統 BI 工具會定義一個抽象的語義層，其本身的意義之一就是為了讓資料分析對業務人員更友好。而大模型天然具有強大的語義理解能力，因此將傳統 BI 中的一些功能進化到基於自然語言的互動式分析，是非常水到渠成的。

  • 簡單的資料探勘與洞察。在某些場景下的互動式資料探勘與洞察，可以利用大語言模型的 Code 生成能力與演算法實現對資料隱藏模式的發現。

1.1 三種基礎技術方案介紹

  • 自然語言轉資料分析的 API，text2API

    類似現有的一些 BI 工具會基於自己的語義層開放出獨立的 API 用於擴充套件應用，因此如果把自然語言轉成對這些資料分析 API 的呼叫，是一種很自然的實現方式。當然完全也可以自己實現這個 API 層。

    這個方案的特點是受到 API 層的制約，在後面我們會分析。

  • 自然語言轉關聯式資料庫 SQL，text2SQL

    這也是目前最受關注的一種大模型能力（本質上也是一種特殊的 text2code）。由於 SQL 是一種相對標準化的資料庫查詢語言，且完全由資料庫自身來解釋執行，因此把自然語言轉成 SQL 是最簡單合理、實現路徑最短的一種解決方案。

  • 自然語言轉資料分析的語言程式碼，即 text2Code

    即程式碼直譯器方案。簡單的說，就是讓 AI 自己編寫程式碼（通常是 Python）然後自動在本地或者沙箱中執行後獲得分析結果。當然目前的 Code Interpreter 大多是針對本地資料的分析處理（如 csv 檔案），因此在面對企業應用中的資料庫內資料時，需要在使用場景上做特別考慮。

2.方案一：text2API

用下圖來表示 text2API 這種方案的大致架構：

基本流程

  • 首先你需要定義良好的資料分析 API 介面（如現有 BI 系統的開放 API），這個需要根據各自的業務情況進行充分設計與實現，形成 API 的使用 “說明書”（JSON Schema 描述，也就是 Agent 裡面的 Tools 工具描述）。

  • 使用者輸入自然語言，系統藉助 LLM 將使用者的輸入問題轉化為對 API 工具的呼叫，包括 API 的名稱與提取的引數。

  • 根據 LLM 的響應呼叫指定的 API，取得返回的資料。根據情況需要，在一些場景下可能還需要將返回的資料再附加到使用者輸入，再次交給 LLM，由 LLM 來輸出最終響應給客戶的分析結果。

2.1問題一：Text2API 的實現探討

如何實現大語言模型的 text2API 能力？由於這是私有企業應用的定製 API，無法藉助於一些已經對網際網路公開 API 訓練過的一些 text2Tool 模型。

  • 一般需要藉助提示工程來讓大語言模型為你實現這種轉換，比如類似這樣的 Prompt：
"""
請遵循如下要求與約束：
1.參考以下的工具列表，找到需要使用的工具，並輸出以下JSON格式內容用來使用工具。注意要確保下面內容在輸出結果中只出現一次:
{"api_calls":[{"name":name of tool,"args":{"arg1":value1,"arg2":value2...}}]}
2.請根據工具的定義與引數描述來生成呼叫文字, 參考案例如下:
工具列表：
[
    {
      "name": "get_current_weather",
      "description": "獲取給定位置的當前天氣資訊",
      "parameters": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "需要查詢天氣的城市"
          }
        },
        "required": ["location"]
      }
    }
  ],
使用者輸入：查詢北京的天氣
返回撥用JSON文字:
{"api_calls":[{"name":"get_current_weather","args":{"location":"Beijing"}}]}
3.如果無法理解使用者意圖，請回復“我無法理解您的意圖”。
4.請根據使用者問題與上下文來推理與提取本次工具呼叫需要的引數內容。
5.直接輸出上述的JSON結果，不要有多餘解釋。
上下文:
{context}
工具列表:
{tools}
使用者問題:
{question}
"""

在藉助 LLM 把自然語言轉化為 API 的呼叫及引數後，透過對輸出的解析，我們就可以呼叫對應的 API 取得結果。當然，實際使用時需要對 Prompt 進行細緻的調優與反覆測試來驗證準確率與穩定性。

2.2 問題二：企業的 APIs 過多的問題

在大型的企業 BI 應用系統中，資料分析的需求可能非常複雜，即使只考慮部分的需求實現，其潛在的 API 數量也可能非常龐大。由於在大語言模型的無狀態特徵，每次我們在輸入使用者問題時，理論上需要攜帶全部的 API 規格說明。這就可能導致上下文超出模型的最大允許 tokens。

  • 一種可能的解決方案是：
    藉助於向量資料庫的語義搜尋能力對所有的工具即 APIs 進行一次過濾，在每次需要 LLM 進行 text2API 的轉換時，只攜帶與使用者問題相關的 API Schema，這樣可以大大減少輸入的 tokens 與上下文大小。

大致過程為：

  1. 對所有的工具即 API 的功能描述做嵌入儲存到向量資料庫

  2. 根據使用者輸入問題進行語義搜尋，獲取到相關的 API 描述

  3. 藉助檢索到 chunk 的後設資料關聯獲取需要攜帶的 API Schema

  4. 在傳送給大模型的提示中僅攜帶關聯的 API Schema，從而節省上下文長度

text2API 總結

text2API 方案本質上是在傳統的資料分析系統之上增加一層自然語言的 UI，核心的資料分析功能需要自行設計 API 來實現。所以這種方案的好處是：

核心的分析邏輯不依賴於大模型（在 API 中），因此更可控。對於一些包含了複雜分析邏輯的任務（涉及不同的資料來源、較多的邏輯判斷和資料實體等），或者分析邏輯經常變化的任務，可以把內部的複雜性對大模型遮蔽，從而減少對輸出穩定性的影響。

而這種方案的不足是：

  • **核心分析邏輯 API 實現，需要極高的業務理解與抽象能力。
    **

  • 靈活性與擴充套件能力差，受限於已經實現與開放的 API 庫。

因此，可以認為這種方案更適合用在輸入輸出結構上較簡單（決定了 API 更簡潔），但是內部資料處理與分析邏輯較複雜的任務。

3.方案二 NL2SQL

text2SQL 的實現原理非常簡單，其核心就在於如何把自然語言組裝成 Prompt，並交給 LLM 轉化成 SQL。我們不妨看一下 OpenAI 公司在官網給出的一個標準的 chatGPT 做自然語言轉 SQL 的例子：

System

/*系統指令*/
Given the following SQL tables, your job is to write queries given a user’s request.

/*資料庫內表結構*/
CREATE TABLE Orders (
  OrderID int,
  CustomerID int,
  OrderDate datetime,
  OrderTime varchar(8),
  PRIMARY KEY (OrderID)
);

...此處省略其他表...

/*問題*/
Write a SQL query which computes the average total order value for all orders on 2023-04-01.

確實，這個看似複雜的任務僅需一個簡潔的“咒語”即可完成。實際應用時，或許需針對所用的大模型微調，但不論形式如何變化，text2SQL的Prompt主要由幾個核心部分構成。

  • 指令（Instruction）：比如，“你是一個 SQL 生成專家。請參考如下的表格結構，直接輸出 SQL 語句，不要多餘的解釋。”

  • 資料結構（Table Schema）：類似於語言翻譯中的 “詞彙表”。即需要使用的資料庫表結構，由於大模型無法直接訪問資料庫，你需要把資料的結構組裝進入 Prompt，這通常包括表名、列名、列的型別、列的含義、主外來鍵資訊。

  • 使用者問題（Questions）：自然語言表達的問題，比如，“統計上個月的平均訂單額”。

  • 參考樣例（Few-shot）：這是一個可選項，當然也是提示工程的常見技巧。即指導大模型生成本次 SQL 的參考樣例。

  • 其他提示（Tips）：其他你認為有必要的指示。比如要求生成的 SQL 中不允許出現的表示式，或者要求列名必須用 “table.column" 的形式等。

3.1 NL2SQL會遇到的難點

實現text2SQL的原型固然簡單，但在實際運用中，其表現往往難以達到預期。核心問題在於，當前AI模型生成SQL的準確性遠遜於人類工程師。深度學習模型的預測本身就存在置信度問題，無法確保絕對可靠，這一挑戰在大語言模型中同樣顯著。此外，輸出的不確定性已成為阻礙大模型在關鍵企業系統廣泛應用的最大障礙。

除了模型自身的知識能力以外，還有一些客觀原因：

  • 自然語言表達本身的歧義性，而 SQL 是一種精確程式語言。因此在實際應用中，可能會出現無法理解，或者錯誤理解的情況。比如，“誰是這個月最厲害的銷售”，那麼 AI 是理解成訂單數量最多，還是訂單金額最大呢？

  • 儘管你可以透過 Prompt 輸入資料結構資訊幫助 AI 模型來理解，但有時候 AI 可能會由於缺乏外部行業知識導致錯誤。比如，“分析去年的整體客戶流失率？”，那麼如果 AI 缺乏對 “客戶流失率” 的理解，自然就會出錯或者編造。

Text2SQL 的方案在企業應用中還會面臨兩個嚴重的挑戰：

3.1.1 可以執行但結果錯誤

即正常的完成了任務，但實際結果是錯誤的。由於 text2SQL 是直接輸出用於資料庫訪問的語句，理論上來說，只要不存在基本的語法錯誤，就可以執行成功，即使轉換的 SQL 在語義上是錯誤的！這與 text2API 的區別在於：API 由於有很嚴格的結構化輸入輸出規範與校驗，因此如果模型轉換錯誤，很大機率會導致 API 呼叫的異常，使用者能夠獲得錯誤反饋（當然也存在 “假象” 的可能）。

比如這樣一個問題，LLM 的兩個輸出都可以正常執行，但是第二個顯然是錯誤的。而且這樣的錯誤對於使用者來說，很可能是難以察覺的：

這個問題其實來自於 text2SQL 輸出正確性的評估困難。這種 text2SQL 輸出語義準確性衡量的複雜性本質上來自於這樣一個事實：判斷 AI 輸出的一段程式碼是否正確，要比判斷一個選擇題答案是否正確，或者一段字串的相似度要複雜的多。

下面這個來自於 text2SQL 模型的輸出評估工具 TestSuiteEval 中的例子：

其中 Gold 代表正確答案，predicted1 和 2 代表模型的兩個輸出，這裡正確的是 predicted2，錯誤的是 predicted1，我們來看兩種評估方法：

  • 如果用 SQL 執行結果來判斷：Predicted1 的結果和正確 SQL 的結果很可能一樣，但實際上 Predicted1 的 SQL 是錯誤的。

  • 如果直接對比輸出的 SQL：由於 Predicted2 和正確的 SQL 不完全一致，你可能判斷它是錯誤的，但其實 Predicted2 的 SQL 在這個場景下是正確的。

這就是評估 text2SQL 模型輸出正確性的複雜所在：你既不能用輸出 SQL 的執行結果來判斷，也不能簡單的把輸出 SQL 與標準答案對比來判斷。

3.1.2 企業應用的特點會加大錯誤輸出的機率

企業應用分析場景的一些特點：

  • 真實企業應用資料庫的結構要遠比測試應用複雜。

  • 真實企業應用的分析邏輯會更復雜。在企業應用即使有幾百行的一個 SQL 統計語句為了生成一個報表也不用奇怪。

  • 真實企業應用不僅有正確性的要求，還有效率即響應效能的要求，特別對於大型的資料倉儲。

那麼大語言模型在應對這些問題時是否有很好的解決方案呢？遺憾的是，從當前的一些模型測試結果看，讓大語言模型能夠在這些場景下完全勝任，達到人類工程師的精度是不現實的。但是我們可以在幾個方面考慮其最佳化，以實現在部分場景下的優先可用。

  • **選擇或者微調合適的大模型
    **

  • 提示詞工程最佳化

  • 應用場景的限制與設計

4.最佳化一:選擇合適的大模型

  • 更多分析見：

NL2SQL基礎系列(1)：業界頂尖排行榜、權威測評資料集及LLM大模型（Spider vs BIRD）全面對比優劣分析[Text2SQL、Text2DSL]

NL2SQL基礎系列(2)：主流大模型與微調方法精選集，Text2SQL經典演算法技術回顧七年發展脈絡梳理

4.1 開源大模型對比

  • 【Spider 基準測試】

Spider 是一個被廣泛用於評估 text2SQL 模型與任務的資料集。你可以在官方網站直接下載這個資料集，然後用來評估你選擇或者訓練的模型。這個資料集包含了 1 萬多個自然語言的問題和相關的 SQL 語句，以及用來執行這些 SQL 的 200 多個資料庫，橫跨了 100 多個應用領域。你甚至可以把模型和測試程式碼提交給官方，官方會在一個不公開的測試集上測試你的模型，並公開結果排名。

目前 Spider 公開的官方最新測試結果，注意 Model 部分不僅列出了大模型，也包括可能的提示工程技術（比如 DAIL-SQL，參考下一部分）：

  • 【BIRD 基準測試】

BIRD 是阿里達摩院聯合香港大學一起推出的針對 text2SQL 的測試資料集。其作用與 Spider 類似，但是相對於 Spider 更專注於學術研究，BIRD 則更加考慮了真實應用中的資料庫中資訊的複雜性，且考慮了模型生成的 SQL 執行效率。BIRD 也包含了約 12000 多個自然語言與 SQL，涵蓋了約 37 個專業領域的 90 多個資料庫。與 Spider 類似，你也可以提交測試程式碼與模型給官方獲得官方測試結果。最新排名如下：

注意到，在這個相對複雜的測試資料集下，大模型的最高分也只有 65.45，離人類能力的 92.96 分還有相當的距離！

4.2 微調模型

  • 詳細參考：

NL2SQL進階系列(1)：DB-GPT-Hub、SQLcoder、Text2SQL開源應用實踐詳解

NL2SQL進階系列(2)：DAIL-SQL、DB-GPT開源應用實踐詳解[Text2SQL]

NL2SQL進階系列(3)：Data-Copilot、Chat2DB、Vanna Text2SQL最佳化框架開源應用實踐詳解[Text2SQL]

  • DB-GPT-Hub

  • SQLCoder

  • 更多內容請參考

NL2SQL技術方案系列(1)：NL2API、NL2SQL技術路徑選擇；LLM選型與Prompt工程技巧，揭秘專案落地最佳化之道

5.最佳化二：提示工程

  • 更多內容參考

☆☆NL2SQL進階系列(4)：ConvAI、DIN-SQL、C3-浙大、DAIL-SQL-阿里等16個業界開源應用實踐詳解[Text2SQL]

NL2SQL實踐系列(1)：深入解析Prompt工程在text2sql中的應用技巧

NL2SQL實踐系列(2)：2024最新模型實戰效果(Chat2DB-GLM、書生·浦語2、InternLM2-SQL等)以及工業級案例教學

5.1 DAIN-SQL

5.2 C3-SQL

6. 最佳化三：應用場景

更多優質內容請關注公號：汀丶人工智慧；會提供一些相關的資源和優質文章，免費獲取閱讀。

  • 更多內容請參考

NL2SQL技術方案系列(1)：NL2API、NL2SQL技術路徑選擇；LLM選型與Prompt工程技巧，揭秘專案落地最佳化之道

相關文章