Enterprise Text-to-SQL

問題定義 — Spider 90% 不等於企業可用

Spider/BIRD 的執行準確率從 54% 一路衝到 90% 以上,但這些數字一搬到真實企業 data lake 就崩潰。LinkedIn 想做一個「全公司任何員工都能用」的 SQL 助手 — 而這篇 paper 就是把這條工程之路完整公開。

1.1 為什麼學術 benchmark 翻不動企業場景

連 Uber 自家 QueryGPT 在內部 eval set 上,也只有大約 50% 的 ground truth tables overlap。換言之,只用一個 fine-tuned LLM 套上 schema 是不夠的。

1.2 LinkedIn 場景的四大挑戰

三層架構總覽

系統由下而上分三層:Knowledge Graph (語意基底) → Query Writer Agent (生 SQL 的核心 agent) → Multi-Agent Chat UI (使用者介面與意圖分流)。三層之間的資料流如下圖。

下圖中的每一層,在後續章節都會展開細節。先記三個關鍵字:knowledge graph 提供語意、Query Writer Agent 把語意變成 SQL、multi-agent UI 處理任何不只是 T2S 的問題。

Knowledge Graph — 把企業語意串成圖

Knowledge Graph 的中心節點是 Table,從 table 可以出發找到欄位、常見 join、example query、domain knowledge、可讀取的使用者群組。另一個組織節點是 Product Area,把 table 跟團隊綁在一起。

3.1 Node 屬性 (Table 1)

關鍵設計: Certification Status 標出資料治理已認可的高品質 table;Column Type 把欄位分成 metric / dimension / attribute,讓 LLM 知道哪些是度量、哪些是維度。沒有 human description 時用 Glean Chat API 自動補一份 AI description。

3.2 五個 Index (2.1.2)

ICA 表叢集 — 從百萬 table 中挑出每個 team 的常用集合

百萬張 table 不可能整個塞給 LLM。LinkedIn 用三個月的 query history 中的 user-table access matrix,跑 Independent Component Analysis (ICA) 做 soft clustering,讓每個 user 與 product area 對應到自己最相關的 table 子集。

4.1 流程 (Algorithm 1)

4.2 為什麼選 ICA 而不是 K-means?

K-means 是 hard clustering — 一張 table 只能歸到一個 cluster,但實際上一張 member 表可能同時是 growth、ads、search 都會用的「共用表」。ICA 的軟分群讓共用 table 自然出現在多個 cluster 裡,而且當有 team 解散、table deprecated 時,只要重跑 weekly job 就會自動重新分配。

4.3 候選 Table 組裝 (Algorithm 4)

function GetCandidateTables(user, product_areas):
    user_clusters        = GetUserGroupClusters(user)
    product_email_groups = GetEmailGroups(product_areas)
    representative_users = GetEmployees(product_email_groups)
    product_area_clusters = GetUserGroupClusters(representative_users)
    clusters             = merge(user_clusters, product_area_clusters)

    inferred_tables = GetExtendedTables(clusters)
    explicit_tables = GetExplicitTables(product_areas)

    return merge(inferred_tables, explicit_tables)

每次 chat session 開始時,先用這支函式把 user + 選定 product area 對應的 cluster 全部攤平、加上手動標註的 explicit table,當作後續 EBR 的搜尋範圍。長尾 table 透過 chat 中的後續詢問動態補入。

Query Writer Agent — 4 步驟生 SQL

用 langchain 實作。Input 三件事:question、user name、product area list。Output 是包含 SQL、解釋、用到的 table/column、與要 verify 的 assumption 的 dict。

5.1 Step 1 — Retrieve Context

目標:高 recall。先用 §04 的候選 table list 圈住搜尋範圍,接著從三個來源各取若干:

1. EBR with user question — 用問題的 embedding 查 table index,結果限制在候選 table 內。
2. Tables in retrieved examples — 先用問題 retrieve 相似的 example query,取出這些 query 用到的 table。
3. Tables in user question — 從 user 明確提到的 table 名直接抓 — 這條沒有候選集限制,user 想用什麼就用什麼。

三條合起來取 K_ret = 20 張 table,接著抓所有對應的 column,再加上 product area 對應的 domain knowledge 與 jargon。

5.2 Step 2 — Rank Context (Table Ranker + Column Ranker)

從 20 張 table 用 LLM 細選到 K_rnk = 7 張。Table Ranker LLM 給每張 table 1–10 的相關度分數並附解釋,所用線索包括:

• • table name 與 description
• • 已用到此 table 的 example queries
• • 常一起 join / co-query 的 table
• • domain knowledge 與 jargon 解釋

作者特別註明:把 table schema 也丟給 ranker 反而降低 recall 並增加 latency,所以這一步不附 schema。

Column Ranker 接著從 7 張 table 的所有 column 中挑出兩個 tier:relevant 與 potentially relevant。把 potentially relevant 也帶進去能提升 recall。每張 table 用 CREATE TABLE 形式呈現,column 依 usage popularity 排序。

5.3 Step 3 — Write Query

把上一階段選出的 table + column + 相關度分數與解釋 + examples + domain knowledge + jargon 全部塞進 prompt,Query Writer LLM (gpt-4o) 回傳:

{
  "assumptions": [...],   # 給用戶 verify 的假設
  "query": "SELECT ...",
  "explanation": "...",
  "tables": [...],
  "columns": [...]
}

5.4 Step 4 — Validate & Fix (Researcher Agent 出場)

Query validation loop 最多跑 兩次,處理兩種錯誤:

5.5 Researcher LLM Agent

Researcher 是一個會自我反思的 agent,專門解 hallucination。它有工具可以搜 table、抓 table schema、抓 metadata。例如它可以根據 hallucinated 的 table 名搜出最相似的真實 table。

5.6 Hyperparameters 整理

Multi-Agent UI — 比 LLM 更重要的可能是介面

線上後作者學到的最大教訓:user 想要的不是 Text-to-SQL,是一個能寫 query、找 table、修 bug、回答任何資料問題的通用資料助手。所以系統長出了 multi-agent 結構。

6.1 Intent Classifier 分四種 agent

6.2 Q&A Agent 的速度技巧

Q&A 範圍最廣,作者用三招控速度:① 判題目難度,簡單題目跳過 self-reflection;② 預先抓 table metadata,避免反覆 tool call;③ 兩個 LLM 都用 gpt-4o-mini。

6.3 UI 設計重點

評測 — 消融與指標

作者自製了一份內部 benchmark:133 個問題 × 10 個 product area × 167 個 ground truth table,而且 60% 的題目允許多個正確答案 (multiple ground truths)。

7.1 評測指標分三類

7.2 評分 rubric (Figure 4)

7.3 消融研究 (Table 2) — 完整重現

Models: 例句 embedding 用 E5-large-v2,table/column embedding 用 text-embedding-ada-002,Researcher LLM 用 gpt-4o-mini-2024-07-18,其餘 LLM 用 gpt-4o-2024-05-13,temperature = 0,單次運行。

7.4 重要觀察

線上部署數據

Chatbot 自 2024 年 7 月上線,以下是 paper 寫作時 (2025.04) 的真實使用數據。

8.1 採用度

8.2 專家審查 (Expert Review)

讓 10 個 product area 的 domain expert 評 production 版本的回答,收到 124/133 題回應:

8.3 用戶滿意度調查

負面結果 — 學界常用的招在這裡都不靈

這節最值得讀。作者試了三個學界主流技巧,在 LinkedIn 場景上全部失敗。這對任何想做 enterprise T2S 的工程師都是免費教訓。

9.1 Multi-query + Self-Consistency:沒辦法跑 query 就死了

學界做法是產生多個 query、選最一致的那個 (e.g. CHASE-SQL, CHESS)。但在 enterprise 場景中:

• ❌ 沒有 data access — 不能執行 query 來比對輸出
• ❌ 用戶等不了 — 多輪 query generation 顯著拉長 latency

變通方案 (產生最多 3 個寫法當作 CoT) — 沒提升 recall。作者結論:self-consistency 的有效性來自 input shuffling 與實際執行,缺一不可。

9.2 Query Planner LLM Decomposition:把問題拆小反而更差

仿 DIN-SQL 的做法 — 用 planner LLM 把問題拆成多個子任務,逐步解。結果:

• ❌ 增加額外延遲
• ❌ 生成的 query過度巢狀
• ❌ Recall 與 quality 都下降

即使後來限制 planner「儘量少拆」+ few-shot 例子,仍敗。作者假設:gpt-4o 本身已經夠強,任務分解只會額外限制它的解題空間 — 較小模型也許需要,但 gpt-4o 不需要。

9.3 用 Planner 的子任務做 Query Expansion:對 EBR 沒幫助

把 planner 拆出的子任務當作 query 字串去做 retrieval (一種 query expansion)。結果 沒有改善 EBR table recall。作者推測:更明確設計成「query expansion」的 prompt 也許有效,但子任務的格式不夠好。

結論與啟發

作者宣稱這是第一份完整、公開的 enterprise Text-to-SQL 系統 paper。對於想做企業內部 SQL chatbot 的團隊,這篇是必讀。

10.1 量化成績總結

10.2 paper 未明說但值得注意的限制