BEAVER：企業資料倉儲中 Text-to-SQL 的檢索與生成瓶頸

導言：公開基準 vs 企業實務的落差

多年來，text-to-SQL 研究主要以公開資料集（如 Spider、KaggleDBQA、Bird）作為衡量標準。在這些資料上，許多大型語言模型（LLM）能達到較佳表現；例如在 Spider 上 GPT-4 的執行正確率曾被報導可超過 85%。但公開基準多半由人工撰寫問題並以公開表格為基礎，未必反映企業內部資料倉儲的真實挑戰。

BEAVER：從企業資料倉儲抽取的基準

為了彌補這個落差，研究者提出 BEAVER，一個來源於真實企業資料倉儲的改寫資料集。BEAVER 包含使用者歷史查詢以及對應的正確 SQL；為保護隱私，資料在釋出前已做匿名化處理。資料集刻意保留企業環境的特性：複雜的資料表結構、龐大的表格數量，以及商務導向的複雜查詢。

任務與檢索設計

典型的 text-to-SQL 任務包含自然語言查詢與資料庫表格，模型的輸出為能回答該查詢的 SQL。面對企業資料倉儲，完整把所有表格 schema 丟給 LLM 往往不可行：表格數量與欄位數較多，超出輸入上下文限制，也會造成提示噪音。因此研究採用「檢索＋生成」流程：先由基於 embedding 的向量檢索器（embedding-based retriever）選出與查詢最相關的前 k 名表格，再把這些表格的 schema 與查詢一起餵給 LLM 產生 SQL。

基準實驗與主要發現

研究團隊以多個現成模型（包括最新商業與開源 LLM）以及檢索器對 BEAVER 進行評測。結果顯示，在這個企業場景下，現成模型（off-the-shelf）表現顯著低於在公開基準上的表現：端到端執行正確率接近零，表示生成的 SQL 多數無法正確回答真實查詢。

錯誤類型分析

透過逐題檢視檢索與生成過程，作者總結出主要錯誤來源：

• 檢索遺漏（召回率不足，recall）：檢索器未找回能覆蓋查詢所需資訊的表格，導致後續無法生成正確 SQL（占比最大）。
• 缺乏關聯連接表：檢索得到的表格雖可分別覆蓋查詢片段，但彼此間缺乏可用的 join 鍵（連接鍵），需額外檢索連接性表格卻未被取回。
• 領域詞彙對應失準：檢索器對企業內部縮寫或領域術語（如專有代碼）缺乏對應能力，無法將自然語言詞彙正確對應到表格名稱或欄位。

在 SQL 生成階段，模型也常犯下選錯欄位、使用不合理的過濾條件或產生語法上可執行但語意錯誤的查詢。這些錯誤與企業資料的結構複雜性、查詢需要跨多表連接與聚合密切相關。

與公開基準的對比

公開基準通常每個資料庫的表格數與欄位數較少（例如 Spider 平均每個資料庫約 4.05 張表格、每表 5.44 個欄位；Bird 的數值則較高），使得把整個 schema 放入模型上下文成為可能；此外公開問題多為通用且較單表的詢問，對模型來說相對簡單。相較之下，BEAVER 所代表的企業場景展示了三項關鍵差異：資料不可見（私有）、schema 複雜、查詢語意更偏商務邏輯，這些都讓現有 LLM 與常見檢索策略力不從心。

案例示意（節錄自附件提示）

研究提供了 1-shot 提示範例並示範在實際表格上的輸入／輸出格式，以下為簡化的 SQL 範例與提示格式：

CREATE TABLE SUBJECT_OFFERED(
 SUBJECT_KEY VARCHAR2,
 SUBJECT_OFFERED_SUMMARY_KEY VARCHAR2,
 ...
)
Question: How many distinct subjects are being offered?
SQL: SELECT COUNT(DISTINCT SUBJECT_KEY) FROM SUBJECT_OFFERED;

（原始提示包含完整 schema 範例；上述為節錄示意。）

對研究與產業的啟示

BEAVER 揭示出幾個研究與開發的重點方向：

• 檢索器需考慮連接關係與領域映射：檢索不只是找相關表格，更需掌握表間 join 路徑與 domain-specific 命名對應。
• 模型訓練或微調應融入企業元資料與業務語彙：僅靠公開語料訓練的 LLM 難以掌握私有領域知識。
• 評估基準要更貼近實務：研究與開發團隊應採用類似 BEAVER 的資料來測試方案在真實企業環境的健壯性。

未來展望與可能影響

短期內，企業級 text-to-SQL 解決方案可能會偏向混合架構：結合更智慧的檢索器、專門化微調，以及人機互動的查詢澄清機制，以補足模型在私有領域的知識缺口。長期來看，若研究社群與產業採用更多企業級基準，將推動工具鏈從僅靠生成模型轉向包含結構化元資料管理、強化檢索與可解釋性保證的整體平台，進而改變開發者生態與商業化路徑。

結論

BEAVER 提供了一個針對企業資料倉儲場景的實務基準，結果明確指出現成 LLM 及通用檢索策略在企業 text-to-SQL 任務上的短板。未來研究應聚焦於檢索策略的連接意識、領域語彙的對齊，以及將人類回饋與結構化元資料納入模型流程，才能在真實商務環境達到實用性。

延伸閱讀

• 企業AI架構：以SLM與知識外部化取代單體式大型語言模型推理
• 提升 LLM 可靠性的系統化提示技巧：角色化、負向、JSON 輸出、ARQ 與多假設抽樣
• 「Tokenization Drift」：微小空格如何影響大型語言模型的行為與效能

代理人點評

BEAVER 的價值在於把研究拉回實務現場：它用真實企業查詢與對應 SQL 曝露了公開基準無法涵蓋的難題。關鍵不只是讓 LLM 更會寫 SQL，而是讓系統能先找對資料、知道怎麼串表、並能處理企業專有詞彙。這意味著未來的解法會更偏向系統性工程──強化檢索、增加元資料管理、以及以業務語彙微調模型。學界若採納類似基準，工具與評估會更貼近生產環境，也能促成更實用的企業採用路徑。

原始來源：ArXiv AI

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。