Text2SQL 已過時？TAG 如何一統 AI 與數據庫江湖！ 精華
1.引言
語言模型的發展使得用戶期望能通過自然語言對數據進行查詢，從而引發了 Text2SQL 和 RAG 等方法的大量研究。但在實際應用中，用戶的問題往往超出這些方法的能力范圍。例如，企業用戶的問題常涉及領域知識、世界知識、精確計算和語義推理的復雜組合。數據庫雖能提供領域知識和大規模精確計算能力，但在語義推理方面較弱；而語言模型雖擅長語義推理和利用世界知識，卻在精確計算和大規模數據處理效率上存在不足。
像 Text2SQL 方法僅適用于能轉換為關系代數的自然語言查詢，無法處理需要語義推理或世界知識的大量用戶查詢。例如，對于“哪些客戶對產品 X 的評價是積極的？”這樣的問題，可能需要對評論進行邏輯行級別的語言模型推理來判斷正負，這超出了 Text2SQL 的能力。RAG 模型則局限于對少量數據記錄的簡單相關性點查找和單次語言模型調用，無法充分利用數據庫的查詢執行能力，且在計算任務上容易出錯、效率低下，長上下文提示下的表現也不佳。因此，需要一種新的方法來統一和擴展數據庫與語言模型的能力，這就是 TAG 模型產生的背景。
2.TAG 模型
查詢合成
查詢合成步驟由 syn 函數完成，它將用戶的自然語言請求 R 轉換為數據庫可執行的查詢 Q。在這個過程中，系統首先要依據表結構等信息推斷出與回答請求相關的數據，然后利用語言模型的語義推理能力將用戶請求解析為數據庫查詢語言（如 SQL）。例如，對于“總結被視為‘經典’的票房最高的愛情電影的評論”這樣的用戶查詢，系統需從數據源中包含電影標題、收入、類型和評論等信息中，確定使用 movie_title、review、revenue 和 genre 等屬性生成 SQL 查詢。并且，由于要識別經典電影，此步驟還可能在查詢中引入對語言模型的調用，以評估每行數據中的電影是否為經典。
查詢執行
exec 函數負責在數據庫系統中執行查詢 Q 以獲取結果表 T。這一步利用數據庫的查詢引擎在大量存儲數據上高效執行查詢。數據庫 API 有多種形式，常見的如基于 SQL 的查詢引擎和基于向量嵌入的檢索系統。在 SQL 查詢引擎設置中，syn 函數會利用數據源知識（如表結構）生成 SQL 查詢；在向量嵌入檢索系統中，syn 函數將自然語言查詢轉換為嵌入，exec 函數在向量存儲中進行相似性檢索。此外，還有一些新興的設置，如使用語義操作符增強關系模型，這些操作符提供了基于 AI 的聲明性操作（如過濾、排名、聚合和自然語言指定的搜索），或者使用語言模型用戶定義函數，為執行優化的基于推理的檢索模式提供了獨特機會。例如在前面提到的電影查詢示例中，使用語義操作符的 TAG 管道可能在查詢執行步驟中使用 sem_filter 操作符根據電影是否為“經典”來過濾行。
答案生成
答案生成步驟的 gen 函數利用語言模型，根據用戶的自然語言請求 R 和計算得到的數據 T 生成最終答案 A。此步驟類似于 RAG 中的生成步驟，但在 TAG 模型中，語言模型的使用方式更加靈活。例如，對于電影評論的查詢，相關數據 T 會被編碼為字符串與原始用戶請求 R 一起傳遞給語言模型，模型利用其語義推理能力對評論列進行總結，從而生成最終答案。
3.TAG 設計空間
查詢類型
TAG 模型具有很強的表達能力，能夠處理多種自然語言用戶查詢。從數據聚合程度來看，它涵蓋了點查詢（如基于檢索的問題，只需查找數據庫中的一行或幾行數據）和聚合查詢（如需要對多行數據進行邏輯推理的總結或排名問題）。從所需知識和能力角度，它支持需要情感分析、分類等不同系統能力的自然語言查詢。例如，在商業數據分析中，既可以查詢特定產品的某條銷售記錄（點查詢），也可以對某類產品在一段時間內的銷售趨勢進行總結（聚合查詢），還能分析客戶對產品的情感傾向（涉及情感分析的查詢）。
數據模型
TAG 模型的底層數據模型可以多樣化。雖然本文的實現主要使用關系數據庫來存儲和檢索結構化屬性，為下游問答任務提供知識基礎，但也可以處理更非結構化的數據（如自由文本、圖像、視頻和音頻）或半結構化數據。這些不同類型的數據可以采用多種數據模型存儲，如鍵值、圖、向量、文檔或對象存儲。這為 TAG 模型在不同領域的應用提供了廣泛的可能性，例如在醫療領域，可以處理病歷文本（非結構化數據）、醫學影像（圖像數據）以及患者基本信息（結構化數據）等多種類型的數據，以回答醫生或患者的各種查詢。
數據庫執行引擎和 API
存儲數據的底層系統可以采用多種數據庫執行引擎和 API。Text2SQL 主要考慮基于 SQL 的查詢引擎來檢索用戶查詢的關系數據，而在其他常見設置中，如基于向量嵌入的檢索系統也有應用。除了這些已被廣泛研究的設置外，還有一些未被充分探索的替代設置，為高效實現 TAG 系統提供了機會。例如，一些新興的系統通過語義操作符增強關系模型，或者在 SQL-based APIs 中增加原生 ML-based 函數，如 MADLib、Google’s BigQuery ML 和 Microsoft’s Predictive SQL 等。這些系統在執行查詢時能夠利用語言模型的能力，實現更復雜的檢索和推理模式。
語言模型生成模式
在答案生成階段，給定相關數據表 T，gen 函數有多種實現方式來生成最終答案 A。與 Text2SQL 省略最終生成步驟和 RAG 通常采用的單次語言模型調用生成方式不同，更近期的研究如 LOTUS 強調了采用迭代或遞歸語言模型生成模式的潛力。這種方式在處理涉及跨多行數據的推理轉換、聚合或排名的查詢時表現出優勢。例如，在分析大量用戶對不同產品的評論數據時，通過迭代調用語言模型，可以逐步提煉和總結出用戶的主要觀點和情感傾向，生成更準確和全面的答案。
4.評估
基準方法
為了評估 TAG 模型及現有方法的性能，本文構建了一個新的基準。該基準基于 BIRD 進行改進，選擇了其中 5 個領域的查詢，并對這些查詢進行修改，使其需要世界知識或語義推理才能回答。例如，在 california_schools 數據庫中，將查詢修改為要求僅返回舊金山灣區的學校信息，這需要模型的世界知識；在 codebase_community 數據庫中，要求找出特定帖子上最具諷刺意味的前 3 條評論，這需要語言模型推理。最終基準包含 80 個修改后的查詢，其中 40 個需要參數知識，40 個需要推理，且每個選定的 BIRD 查詢類型各有 20 個。
在實驗設置中，使用 Meta 的 Llama-3.1 模型（70B 參數的指令調優變體）作為語言模型，SQLite3 作為涉及 SQL 的基線數據庫 API，E5 基礎嵌入模型作為 RAG 基線。并在 8 個 A100 80GB GPU 上運行 Llama-3.1 70B-Instruct 與vLLM。評估指標包括測量與標記正確答案的精確匹配百分比作為準確性（對于匹配、比較和排名查詢類型），對于聚合查詢則進行定性分析，同時還測量每個查詢的執行時間。
基線
Text2SQL：在這個基線方法中，語言模型生成 SQL 代碼，然后在數據庫中運行該代碼以獲取答案。對于給定的自然語言查詢，構建包含查詢域中每個表的表結構的語言模型提示，使用與 BIRD 工作相同的提示格式。通過在 SQLite3 中執行生成的 SQL 代碼并統計錯誤答案數量（包括模型無法生成有效 SQL 代碼的情況）來評估該基線。例如，對于一些復雜的查詢，如涉及多表連接和條件篩選的查詢，模型可能生成錯誤的 SQL 代碼，導致無法得到正確答案。
RAG：RAG 風格的方法在表格檢索中已有應用，本文的基線采用行級嵌入。在將數據嵌入 FAISS 索引之前，將每一行序列化為“col: val”的形式。在查詢時，通過向量相似性搜索檢索 10 個相關行，并與自然語言問題一起作為上下文提供給模型。然而，在實驗中發現，該基線在所有查詢類型中都無法正確回答單個查詢，表明其在處理此類查詢時存在嚴重不足。
Retrieval+LM Rank：此基線是對 RAG 基線的擴展，利用語言模型為檢索到的行分配 0 到 1 之間的分數，在輸入模型之前對行進行重新排名。使用 Llama-3.1-70B-Instruct 作為重新排名器。雖然在比較查詢中能夠正確回答一個查詢，但總體性能仍然較差，不如其他基線方法。
Text2SQL+LM：在這個基線中，模型首先生成 SQL 以檢索一組相關行來回答給定的自然語言查詢，然后將檢索到的行作為上下文提供給模型。與 Text2SQL 基線不同的是，這里模型不是直接生成提供答案的 SQL 代碼。在實驗中，該基線在匹配和比較查詢上表現不佳，因為在執行 SQL 后將許多行提供給模型時會出現一些上下文長度錯誤。
Hand-written TAG：該基線利用 LOTUS 實現手寫的 TAG 管道，通過專家知識構建查詢管道，而不是從自然語言請求自動合成數據庫查詢。LOTUS API 允許程序員使用標準關系運算符和語義運算符（如基于語言模型的過濾、排名和聚合）聲明性地指定查詢管道，并提供了優化的語義查詢執行引擎。
結果
實驗結果表明，手寫的 TAG 基線在所有方法中表現突出。在準確性方面，它在所有選定的 BIRD 查詢類型上始終達到 40%或更高的精確匹配準確率，而其他基線方法均未超過 20%。Text2SQL 基線在所有查詢類型上執行準確率不高于 20%，在排名查詢上尤其差，僅為 10%，因為許多排名查詢需要對文本進行推理。Text2SQL+LM 生成基線在各方面表現類似，在匹配和比較查詢上僅為 10% 的準確率。RAG 基線如前所述無法正確回答任何查詢，Retrieval+LM Rank 基線雖然在比較查詢中有一定改進，但整體仍較差。
手寫的 TAG 基線總體上能正確回答 55%的查詢，在比較查詢上表現最佳，精確匹配準確率為 65%，在除排名查詢外的所有查詢類型上準確率均超過 50%。在執行時間方面，手寫的 TAG 方法也具有優勢，平均執行時間為 2.94 秒，比其他基線方法快達 3.1 倍。這得益于其利用了語言模型的高效批量推理。在聚合查詢的定性分析中，以“提供雪邦國際賽道舉辦的比賽信息”為例，RAG 基線只能提供部分比賽信息，Text2SQL+LM 基線無法利用數據庫信息，而手寫的 TAG 基線能夠提供全面的總結，進一步證明了 TAG 系統在處理聚合查詢方面的潛力。
5.相關工作
Text2SQL
先前的工作對使用語言模型的 Text2SQL 進行了廣泛研究，WikiSQL、Spider 和 BIRD 等都是用于跨域 Text2SQL 的流行數據集。這些數據集包含多個領域的結構化數據，用于評估將自然語言查詢轉換為 SQL 的任務。然而，這些方法僅局限于 SQL 生成，無法處理需要超出靜態數據源的推理或知識的查詢。
RAG
RAG 使語言模型能夠擴展到其參數知識之外的大量文本集合。SQuAD 和 HotPotQA 分別專注于單文檔和多文檔源的問答，密集表檢索（DTR）模型將 RAG 擴展到表格數據。與先前的 RAG 工作不同，TAG 模型在查詢執行步驟中利用語言模型能力，并允許數據庫管理系統進行大規模數據的精確計算，從而涵蓋了更廣泛的用戶查詢領域。
NL Queries over Semi-structured Data
先前的工作探索了半結構化數據源中表實體和非結構化實體字段之間的關系信息。STaRK 評估了跨半結構化知識庫（SKBs）的表檢索方法，SUQL 解決了對話式搜索任務。與這些工作相比，本文的 TAG 模型旨在探索更廣泛的查詢，利用更多語言模型能力來處理搜索和查找之外的任務。
Agentic Data Assistants
近期的工作探索了將語言模型作為數據助手的代理，如 Spider2-V 探索了多模態代理在涉及代碼生成和 GUI 控制任務中的性能。雖然本文將 TAG 模型定義為 syn、exec 和 gen 函數的一次迭代，但未來的工作可以探索在代理循環中擴展它。
6.結論
本文提出的 TAG 模型為解決自然語言與數據庫交互問題提供了一種統一的新范式。通過構建專門的基準來研究需要世界知識和語義推理能力的查詢，發現基線方法在這些任務上表現不佳，而手寫的 TAG 管道能夠實現高達 65%的準確率提升。這表明 TAG 模型具有巨大的研究潛力和應用前景，為后續構建更高效的自然語言與數據庫交互系統指明了方向，有望在數據分析、商業智能等眾多領域引發新的技術變革，推動人工智能與數據庫技術的深度融合與發展。未來的研究可以進一步探索 TAG 模型在不同數據類型、應用場景下的優化和擴展，以及與其他新興技術的結合，不斷提升其性能和適用性。
7.如何使用
話不多說，上代碼
創建 conda 環境并下載依賴項
conda create -n tag python=3.9 -y
conda activate tag
pip install -r requirements.txt
pip install -e .下載 BIRD DB 并將其轉換為 Pandas DataFrames
cd setup
chmod +x get_dbs.sh
./get_dbs.sh現在您應該有一個 dev_folder ?包含數據庫的文件夾和一個pandas_dfs DataFrames 的文件夾。
在每個表上創建索引（建議使用 GPU）
cd setup
chmod +x embed_all_dfs.sh
./embed_all_dfs.sh現在您應該有一個 indexes包含索引的文件夾。
獲取 Text2SQL 提示
cd setup
chmod +x get_text2sql_prompts.sh
./get_text2sql_prompts.sh在執行上述設置步驟后，你可以運行以下內容來重現論文中的結果。在 TAG 目錄中運行這些內容以獲得方法輸出。你應該編輯每個文件中的對象，使其指向你想要使用的語言模型服務器。查看 LOTUS 文檔以配置 models.lm。
LOTUS上運行手寫 TAG??
??
?
python hand_written.py \
--pipelines 0134568101113161819202124108109110111 \
25 27293033353637383940414243444546474849 \
50 5152535455565758596061626364651061079521000 \
81 828586878889909192939495969799100101102103 \
--output_dir out_hand_writtenText2SQL
python text2sql.py --output_dir out_text2sqlText2SQL + LM
python text2sql_lm.py --output_dir out_text2sql_lmRAG
python rag.py --output_dir out_ragRetrieval+LM Rank
python rag.py --output_dir out_rerank --rerank然后，每種方法的準確性和延遲可以通過以下命令進行評估。
python analyze.py --output_dir out_hand_written[1] 論文地址：??https://ar??xiv.org/pdf/2408.14717
[2] 代碼地址：??https://github.com/TAG-Research/TAG-Bench??
??[3] 論文標題：Text2SQL is Not Enough: Unifying AI and Databases with TAG??
??[4] LOTUS ：https://github.com/guestrin-lab/lotus ??
本文轉載自?? AIGC前沿技術追蹤??，作者： AIGC前沿技術追蹤
