1.引言

語言模型的發(fā)展使得用戶期望能通過自然語言對數(shù)據(jù)進(jìn)行查詢，從而引發(fā)了 Text2SQL 和 RAG 等方法的大量研究。但在實(shí)際應(yīng)用中，用戶的問題往往超出這些方法的能力范圍。例如，企業(yè)用戶的問題常涉及領(lǐng)域知識、世界知識、精確計(jì)算和語義推理的復(fù)雜組合。數(shù)據(jù)庫雖能提供領(lǐng)域知識和大規(guī)模精確計(jì)算能力，但在語義推理方面較弱；而語言模型雖擅長語義推理和利用世界知識，卻在精確計(jì)算和大規(guī)模數(shù)據(jù)處理效率上存在不足。

像 Text2SQL 方法僅適用于能轉(zhuǎn)換為關(guān)系代數(shù)的自然語言查詢，無法處理需要語義推理或世界知識的大量用戶查詢。例如，對于“哪些客戶對產(chǎn)品 X 的評價(jià)是積極的？”這樣的問題，可能需要對評論進(jìn)行邏輯行級別的語言模型推理來判斷正負(fù)，這超出了 Text2SQL 的能力。RAG 模型則局限于對少量數(shù)據(jù)記錄的簡單相關(guān)性點(diǎn)查找和單次語言模型調(diào)用，無法充分利用數(shù)據(jù)庫的查詢執(zhí)行能力，且在計(jì)算任務(wù)上容易出錯(cuò)、效率低下，長上下文提示下的表現(xiàn)也不佳。因此，需要一種新的方法來統(tǒng)一和擴(kuò)展數(shù)據(jù)庫與語言模型的能力，這就是 TAG 模型產(chǎn)生的背景。

2.TAG 模型

查詢合成

查詢合成步驟由 syn 函數(shù)完成，它將用戶的自然語言請求 R 轉(zhuǎn)換為數(shù)據(jù)庫可執(zhí)行的查詢 Q。在這個(gè)過程中，系統(tǒng)首先要依據(jù)表結(jié)構(gòu)等信息推斷出與回答請求相關(guān)的數(shù)據(jù)，然后利用語言模型的語義推理能力將用戶請求解析為數(shù)據(jù)庫查詢語言（如 SQL）。例如，對于“總結(jié)被視為‘經(jīng)典’的票房最高的愛情電影的評論”這樣的用戶查詢，系統(tǒng)需從數(shù)據(jù)源中包含電影標(biāo)題、收入、類型和評論等信息中，確定使用 movie_title、review、revenue 和 genre 等屬性生成 SQL 查詢。并且，由于要識別經(jīng)典電影，此步驟還可能在查詢中引入對語言模型的調(diào)用，以評估每行數(shù)據(jù)中的電影是否為經(jīng)典。

查詢執(zhí)行

exec 函數(shù)負(fù)責(zé)在數(shù)據(jù)庫系統(tǒng)中執(zhí)行查詢 Q 以獲取結(jié)果表 T。這一步利用數(shù)據(jù)庫的查詢引擎在大量存儲數(shù)據(jù)上高效執(zhí)行查詢。數(shù)據(jù)庫 API 有多種形式，常見的如基于 SQL 的查詢引擎和基于向量嵌入的檢索系統(tǒng)。在 SQL 查詢引擎設(shè)置中，syn 函數(shù)會利用數(shù)據(jù)源知識（如表結(jié)構(gòu)）生成 SQL 查詢；在向量嵌入檢索系統(tǒng)中，syn 函數(shù)將自然語言查詢轉(zhuǎn)換為嵌入，exec 函數(shù)在向量存儲中進(jìn)行相似性檢索。此外，還有一些新興的設(shè)置，如使用語義操作符增強(qiáng)關(guān)系模型，這些操作符提供了基于 AI 的聲明性操作（如過濾、排名、聚合和自然語言指定的搜索），或者使用語言模型用戶定義函數(shù)，為執(zhí)行優(yōu)化的基于推理的檢索模式提供了獨(dú)特機(jī)會。例如在前面提到的電影查詢示例中，使用語義操作符的 TAG 管道可能在查詢執(zhí)行步驟中使用 sem_filter 操作符根據(jù)電影是否為“經(jīng)典”來過濾行。

答案生成

答案生成步驟的 gen 函數(shù)利用語言模型，根據(jù)用戶的自然語言請求 R 和計(jì)算得到的數(shù)據(jù) T 生成最終答案 A。此步驟類似于 RAG 中的生成步驟，但在 TAG 模型中，語言模型的使用方式更加靈活。例如，對于電影評論的查詢，相關(guān)數(shù)據(jù) T 會被編碼為字符串與原始用戶請求 R 一起傳遞給語言模型，模型利用其語義推理能力對評論列進(jìn)行總結(jié)，從而生成最終答案。

3.TAG 設(shè)計(jì)空間

查詢類型

TAG 模型具有很強(qiáng)的表達(dá)能力，能夠處理多種自然語言用戶查詢。從數(shù)據(jù)聚合程度來看，它涵蓋了點(diǎn)查詢（如基于檢索的問題，只需查找數(shù)據(jù)庫中的一行或幾行數(shù)據(jù)）和聚合查詢（如需要對多行數(shù)據(jù)進(jìn)行邏輯推理的總結(jié)或排名問題）。從所需知識和能力角度，它支持需要情感分析、分類等不同系統(tǒng)能力的自然語言查詢。例如，在商業(yè)數(shù)據(jù)分析中，既可以查詢特定產(chǎn)品的某條銷售記錄（點(diǎn)查詢），也可以對某類產(chǎn)品在一段時(shí)間內(nèi)的銷售趨勢進(jìn)行總結(jié)（聚合查詢），還能分析客戶對產(chǎn)品的情感傾向（涉及情感分析的查詢）。

數(shù)據(jù)模型

TAG 模型的底層數(shù)據(jù)模型可以多樣化。雖然本文的實(shí)現(xiàn)主要使用關(guān)系數(shù)據(jù)庫來存儲和檢索結(jié)構(gòu)化屬性，為下游問答任務(wù)提供知識基礎(chǔ)，但也可以處理更非結(jié)構(gòu)化的數(shù)據(jù)（如自由文本、圖像、視頻和音頻）或半結(jié)構(gòu)化數(shù)據(jù)。這些不同類型的數(shù)據(jù)可以采用多種數(shù)據(jù)模型存儲，如鍵值、圖、向量、文檔或?qū)ο蟠鎯?。這為 TAG 模型在不同領(lǐng)域的應(yīng)用提供了廣泛的可能性，例如在醫(yī)療領(lǐng)域，可以處理病歷文本（非結(jié)構(gòu)化數(shù)據(jù)）、醫(yī)學(xué)影像（圖像數(shù)據(jù)）以及患者基本信息（結(jié)構(gòu)化數(shù)據(jù)）等多種類型的數(shù)據(jù)，以回答醫(yī)生或患者的各種查詢。

數(shù)據(jù)庫執(zhí)行引擎和 API

存儲數(shù)據(jù)的底層系統(tǒng)可以采用多種數(shù)據(jù)庫執(zhí)行引擎和 API。Text2SQL 主要考慮基于 SQL 的查詢引擎來檢索用戶查詢的關(guān)系數(shù)據(jù)，而在其他常見設(shè)置中，如基于向量嵌入的檢索系統(tǒng)也有應(yīng)用。除了這些已被廣泛研究的設(shè)置外，還有一些未被充分探索的替代設(shè)置，為高效實(shí)現(xiàn) TAG 系統(tǒng)提供了機(jī)會。例如，一些新興的系統(tǒng)通過語義操作符增強(qiáng)關(guān)系模型，或者在 SQL-based APIs 中增加原生 ML-based 函數(shù)，如 MADLib、Google’s BigQuery ML 和 Microsoft’s Predictive SQL 等。這些系統(tǒng)在執(zhí)行查詢時(shí)能夠利用語言模型的能力，實(shí)現(xiàn)更復(fù)雜的檢索和推理模式。

語言模型生成模式

在答案生成階段，給定相關(guān)數(shù)據(jù)表 T，gen 函數(shù)有多種實(shí)現(xiàn)方式來生成最終答案 A。與 Text2SQL 省略最終生成步驟和 RAG 通常采用的單次語言模型調(diào)用生成方式不同，更近期的研究如 LOTUS 強(qiáng)調(diào)了采用迭代或遞歸語言模型生成模式的潛力。這種方式在處理涉及跨多行數(shù)據(jù)的推理轉(zhuǎn)換、聚合或排名的查詢時(shí)表現(xiàn)出優(yōu)勢。例如，在分析大量用戶對不同產(chǎn)品的評論數(shù)據(jù)時(shí)，通過迭代調(diào)用語言模型，可以逐步提煉和總結(jié)出用戶的主要觀點(diǎn)和情感傾向，生成更準(zhǔn)確和全面的答案。

4.評估

基準(zhǔn)方法

為了評估 TAG 模型及現(xiàn)有方法的性能，本文構(gòu)建了一個(gè)新的基準(zhǔn)。該基準(zhǔn)基于 BIRD 進(jìn)行改進(jìn)，選擇了其中 5 個(gè)領(lǐng)域的查詢，并對這些查詢進(jìn)行修改，使其需要世界知識或語義推理才能回答。例如，在 california_schools 數(shù)據(jù)庫中，將查詢修改為要求僅返回舊金山灣區(qū)的學(xué)校信息，這需要模型的世界知識；在 codebase_community 數(shù)據(jù)庫中，要求找出特定帖子上最具諷刺意味的前 3 條評論，這需要語言模型推理。最終基準(zhǔn)包含 80 個(gè)修改后的查詢，其中 40 個(gè)需要參數(shù)知識，40 個(gè)需要推理，且每個(gè)選定的 BIRD 查詢類型各有 20 個(gè)。

在實(shí)驗(yàn)設(shè)置中，使用 Meta 的 Llama-3.1 模型（70B 參數(shù)的指令調(diào)優(yōu)變體）作為語言模型，SQLite3 作為涉及 SQL 的基線數(shù)據(jù)庫 API，E5 基礎(chǔ)嵌入模型作為 RAG 基線。并在 8 個(gè) A100 80GB GPU 上運(yùn)行 Llama-3.1 70B-Instruct 與vLLM。評估指標(biāo)包括測量與標(biāo)記正確答案的精確匹配百分比作為準(zhǔn)確性（對于匹配、比較和排名查詢類型），對于聚合查詢則進(jìn)行定性分析，同時(shí)還測量每個(gè)查詢的執(zhí)行時(shí)間。

基線

Text2SQL：在這個(gè)基線方法中，語言模型生成 SQL 代碼，然后在數(shù)據(jù)庫中運(yùn)行該代碼以獲取答案。對于給定的自然語言查詢，構(gòu)建包含查詢域中每個(gè)表的表結(jié)構(gòu)的語言模型提示，使用與 BIRD 工作相同的提示格式。通過在 SQLite3 中執(zhí)行生成的 SQL 代碼并統(tǒng)計(jì)錯(cuò)誤答案數(shù)量（包括模型無法生成有效 SQL 代碼的情況）來評估該基線。例如，對于一些復(fù)雜的查詢，如涉及多表連接和條件篩選的查詢，模型可能生成錯(cuò)誤的 SQL 代碼，導(dǎo)致無法得到正確答案。

RAG：RAG 風(fēng)格的方法在表格檢索中已有應(yīng)用，本文的基線采用行級嵌入。在將數(shù)據(jù)嵌入 FAISS 索引之前，將每一行序列化為“col: val”的形式。在查詢時(shí)，通過向量相似性搜索檢索 10 個(gè)相關(guān)行，并與自然語言問題一起作為上下文提供給模型。然而，在實(shí)驗(yàn)中發(fā)現(xiàn)，該基線在所有查詢類型中都無法正確回答單個(gè)查詢，表明其在處理此類查詢時(shí)存在嚴(yán)重不足。

Retrieval+LM Rank：此基線是對 RAG 基線的擴(kuò)展，利用語言模型為檢索到的行分配 0 到 1 之間的分?jǐn)?shù)，在輸入模型之前對行進(jìn)行重新排名。使用 Llama-3.1-70B-Instruct 作為重新排名器。雖然在比較查詢中能夠正確回答一個(gè)查詢，但總體性能仍然較差，不如其他基線方法。

Text2SQL+LM：在這個(gè)基線中，模型首先生成 SQL 以檢索一組相關(guān)行來回答給定的自然語言查詢，然后將檢索到的行作為上下文提供給模型。與 Text2SQL 基線不同的是，這里模型不是直接生成提供答案的 SQL 代碼。在實(shí)驗(yàn)中，該基線在匹配和比較查詢上表現(xiàn)不佳，因?yàn)樵趫?zhí)行 SQL 后將許多行提供給模型時(shí)會出現(xiàn)一些上下文長度錯(cuò)誤。

Hand-written TAG：該基線利用 LOTUS 實(shí)現(xiàn)手寫的 TAG 管道，通過專家知識構(gòu)建查詢管道，而不是從自然語言請求自動合成數(shù)據(jù)庫查詢。LOTUS API 允許程序員使用標(biāo)準(zhǔn)關(guān)系運(yùn)算符和語義運(yùn)算符（如基于語言模型的過濾、排名和聚合）聲明性地指定查詢管道，并提供了優(yōu)化的語義查詢執(zhí)行引擎。

結(jié)果

實(shí)驗(yàn)結(jié)果表明，手寫的 TAG 基線在所有方法中表現(xiàn)突出。在準(zhǔn)確性方面，它在所有選定的 BIRD 查詢類型上始終達(dá)到 40%或更高的精確匹配準(zhǔn)確率，而其他基線方法均未超過 20%。Text2SQL 基線在所有查詢類型上執(zhí)行準(zhǔn)確率不高于 20%，在排名查詢上尤其差，僅為 10%，因?yàn)樵S多排名查詢需要對文本進(jìn)行推理。Text2SQL+LM 生成基線在各方面表現(xiàn)類似，在匹配和比較查詢上僅為 10% 的準(zhǔn)確率。RAG 基線如前所述無法正確回答任何查詢，Retrieval+LM Rank 基線雖然在比較查詢中有一定改進(jìn)，但整體仍較差。

手寫的 TAG 基線總體上能正確回答 55%的查詢，在比較查詢上表現(xiàn)最佳，精確匹配準(zhǔn)確率為 65%，在除排名查詢外的所有查詢類型上準(zhǔn)確率均超過 50%。在執(zhí)行時(shí)間方面，手寫的 TAG 方法也具有優(yōu)勢，平均執(zhí)行時(shí)間為 2.94 秒，比其他基線方法快達(dá) 3.1 倍。這得益于其利用了語言模型的高效批量推理。在聚合查詢的定性分析中，以“提供雪邦國際賽道舉辦的比賽信息”為例，RAG 基線只能提供部分比賽信息，Text2SQL+LM 基線無法利用數(shù)據(jù)庫信息，而手寫的 TAG 基線能夠提供全面的總結(jié)，進(jìn)一步證明了 TAG 系統(tǒng)在處理聚合查詢方面的潛力。

5.相關(guān)工作

Text2SQL

先前的工作對使用語言模型的 Text2SQL 進(jìn)行了廣泛研究，WikiSQL、Spider 和 BIRD 等都是用于跨域 Text2SQL 的流行數(shù)據(jù)集。這些數(shù)據(jù)集包含多個(gè)領(lǐng)域的結(jié)構(gòu)化數(shù)據(jù)，用于評估將自然語言查詢轉(zhuǎn)換為 SQL 的任務(wù)。然而，這些方法僅局限于 SQL 生成，無法處理需要超出靜態(tài)數(shù)據(jù)源的推理或知識的查詢。

RAG

RAG 使語言模型能夠擴(kuò)展到其參數(shù)知識之外的大量文本集合。SQuAD 和 HotPotQA 分別專注于單文檔和多文檔源的問答，密集表檢索（DTR）模型將 RAG 擴(kuò)展到表格數(shù)據(jù)。與先前的 RAG 工作不同，TAG 模型在查詢執(zhí)行步驟中利用語言模型能力，并允許數(shù)據(jù)庫管理系統(tǒng)進(jìn)行大規(guī)模數(shù)據(jù)的精確計(jì)算，從而涵蓋了更廣泛的用戶查詢領(lǐng)域。

NL Queries over Semi-structured Data

先前的工作探索了半結(jié)構(gòu)化數(shù)據(jù)源中表實(shí)體和非結(jié)構(gòu)化實(shí)體字段之間的關(guān)系信息。STaRK 評估了跨半結(jié)構(gòu)化知識庫（SKBs）的表檢索方法，SUQL 解決了對話式搜索任務(wù)。與這些工作相比，本文的 TAG 模型旨在探索更廣泛的查詢，利用更多語言模型能力來處理搜索和查找之外的任務(wù)。

Agentic Data Assistants

近期的工作探索了將語言模型作為數(shù)據(jù)助手的代理，如 Spider2-V 探索了多模態(tài)代理在涉及代碼生成和 GUI 控制任務(wù)中的性能。雖然本文將 TAG 模型定義為 syn、exec 和 gen 函數(shù)的一次迭代，但未來的工作可以探索在代理循環(huán)中擴(kuò)展它。

6.結(jié)論

本文提出的 TAG 模型為解決自然語言與數(shù)據(jù)庫交互問題提供了一種統(tǒng)一的新范式。通過構(gòu)建專門的基準(zhǔn)來研究需要世界知識和語義推理能力的查詢，發(fā)現(xiàn)基線方法在這些任務(wù)上表現(xiàn)不佳，而手寫的 TAG 管道能夠?qū)崿F(xiàn)高達(dá) 65%的準(zhǔn)確率提升。這表明 TAG 模型具有巨大的研究潛力和應(yīng)用前景，為后續(xù)構(gòu)建更高效的自然語言與數(shù)據(jù)庫交互系統(tǒng)指明了方向，有望在數(shù)據(jù)分析、商業(yè)智能等眾多領(lǐng)域引發(fā)新的技術(shù)變革，推動人工智能與數(shù)據(jù)庫技術(shù)的深度融合與發(fā)展。未來的研究可以進(jìn)一步探索 TAG 模型在不同數(shù)據(jù)類型、應(yīng)用場景下的優(yōu)化和擴(kuò)展，以及與其他新興技術(shù)的結(jié)合，不斷提升其性能和適用性。

7.如何使用

話不多說，上代碼

創(chuàng)建 conda 環(huán)境并下載依賴項(xiàng)

conda create -n tag python=3.9 -y
conda activate tag
pip install -r requirements.txt
pip install -e .

下載 BIRD DB 并將其轉(zhuǎn)換為 Pandas DataFrames

cd setup
chmod +x get_dbs.sh
./get_dbs.sh

現(xiàn)在您應(yīng)該有一個(gè) dev_folder ?包含數(shù)據(jù)庫的文件夾和一個(gè)pandas_dfs DataFrames 的文件夾。

在每個(gè)表上創(chuàng)建索引（建議使用 GPU）

cd setup
chmod +x embed_all_dfs.sh
./embed_all_dfs.sh

現(xiàn)在您應(yīng)該有一個(gè) indexes包含索引的文件夾。

獲取 Text2SQL 提示

cd setup
chmod +x get_text2sql_prompts.sh
./get_text2sql_prompts.sh

在執(zhí)行上述設(shè)置步驟后，你可以運(yùn)行以下內(nèi)容來重現(xiàn)論文中的結(jié)果。在 TAG 目錄中運(yùn)行這些內(nèi)容以獲得方法輸出。你應(yīng)該編輯每個(gè)文件中的對象，使其指向你想要使用的語言模型服務(wù)器。查看  LOTUS 文檔以配置 models.lm。

LOTUS上運(yùn)行手寫 TAG??
??

python hand_written.py \
    --pipelines 0134568101113161819202124108109110111 \
    25 27293033353637383940414243444546474849 \
    50 5152535455565758596061626364651061079521000 \
    81 828586878889909192939495969799100101102103 \
    --output_dir out_hand_written

Text2SQL

python text2sql.py --output_dir out_text2sql

Text2SQL + LM

python text2sql_lm.py --output_dir out_text2sql_lm

RAG

python rag.py --output_dir out_rag

Retrieval+LM Rank

python rag.py --output_dir out_rerank --rerank

然后，每種方法的準(zhǔn)確性和延遲可以通過以下命令進(jìn)行評估。

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] 論文標(biāo)題：Text2SQL is Not Enough: Unifying AI and Databases with TAG??

??[4] LOTUS ：https://github.com/guestrin-lab/lotus ??

本文轉(zhuǎn)載自?? AIGC前沿技術(shù)追蹤??，作者： AIGC前沿技術(shù)追蹤