Text-to-SQL 入企業，準確率只剩 25%：語義層點解係必選項

引言：由 90% 跌到 25% 嘅斷崖

2024 年，GPT-4o 喺經典 Text-to-SQL 基準 Spider 1.0 上交出 86.6% 嘅執行準確率。呢個數字夠靚，幾乎令業界相信「自然語言取代 SQL」只係時間問題。

兩年後，同一個模型喺 Spider 2.0 嘅企業級真實工作流測試中，分數驟降至 10.1%。

唔係模型變弱咗——係數據庫變「真實」咗。Spider 2.0 嘅數據庫動輒上千列、多方言混用、單條 SQL 超過 100 行，考察嘅再唔係「寫啱一條查詢」，而係「喺複雜業務語境下完成一次工程級嘅數據探索」。

2026 年 8 月，arXiv 上出現咗一篇更刺眼嘅論文。Bruno Santos Teixeira 提出嘅 SemPlan Benchmark（arXiv:2608.13612）用 1,800 個合成案例測試咗四種企業級 NL2SQL 架構。結果四種方案嘅正確率全部喺 22.25% 到 25.67% 之間——冇一個超過四分之一。

換句話講，你將市面上最先進嘅 Text-to-SQL 系統直接接入企業數據庫，每問四條問題，大概只有一條答啱。而且答錯嗰三條，往往同正確答案一模一樣。

企業數據庫點解令 LLM「失憶」？

學術基準同企業生產環境之間，隔住三道幾乎無法靠「更大模型」跨越嘅鴻溝。

1. Schema 爆炸：上下文裝唔落

Spider 1.0 嘅數據庫平均 6.8 張表、72.5 列。而 BEAVER 項目採集嘅真實企業倉庫平均 101.5 張表、869.4 列。

當你將近萬個字段定義塞入 LLM 嘅上下文窗口，模型注意力被稀釋到近乎隨機。研究顯示，即使畀模型「oracle schema-linking」標註（人工話俾佢聽該用邊張表），準確率都只能由 11.4% 提升到 18.9%。問題唔喺推理能力，而喺資訊過載。

2. 隱式關係：LLM 讀唔明「行業黑話」

真實企業嘅表名往往係噉樣：t_cust_ord_dtl_2024_q3。字段 amt 喺某啲表入面係「含稅金額」，喺另一啲表入面係「退款淨額」——而兩者差咗成個稅率口徑。

冇顯式文件，LLM 只能根據命名「猜」。一篇 2026 年 4 月發表於 arXiv 嘅誤差分析（4,602 條錯誤查詢）指出：81% 嘅失敗屬於 schema 同語義錯誤——揀錯列、連錯表、誤解業務含義。語法錯誤反而係少數。

3. 安全同口徑：沉默嘅致命錯誤

Text-to-SQL 最可怕嘅唔係報錯，而係「靜靜地計錯」。一位工程師喺 35 表嘅生產環境 Shape 數據庫上實測發現：一個 naive 查詢漏咗去重步驟，將收入放大咗 76%，輸出結果睇落完全合理，直到識業務嘅人覆核先發現。

更糟嘅係權限。如果 AI 通過一個擁有 broad read 權限嘅服務賬號訪問倉庫，佢完全可能喺回答「本月新增客戶」時，將包含個人私隱嘅完整聯絡人列表一併吐出嚟。

dbt Labs 嘅對照實驗：語義層能夠將準確率拉回 100%

好消息係，呢個問題有解——而且解唔喺模型本身，而喺模型同數據之間嗰層「翻譯器」。

2026 年 4 月，dbt Labs 發布咗一份可復現嘅基準測試。佢哋喺 ACME Insurance 嘅 15 張表、11 個業務問題上，對比咗純 Text-to-SQL 同經過語義層建模後嘅表現，每條題跑 20 次：

同一批模型、同一批問題、同一個數據庫。唯一嘅變量，係有冇語義層。

dbt Labs 仲喺測試前做咗一組交叉驗證：4 個前沿模型 × 多檔推理強度（由 low 到 max）。結果顯示，語義層路徑上多數組合達到 100%；而純 Text-to-SQL 成績喺 50%-65% 之間嚟回晃——推理預算加得再多，準確率都唔漲。

關鍵結論寫得好直白：將預算花在推理 token 上，回報接近零；花在語義建模上，回報係三四十個百分點。

dbt Labs 特別指出一個被 vendor 普遍回避嘅數據點：喺語義層未覆蓋嘅多跳複雜問題上，語義層得分 0%（因為佢選擇拒絕），而純 Text-to-SQL 仲能蒙啱 70%-100%。

呢個唔係語義層嘅缺陷——恰恰係佢嘅設計意圖：喺能力邊界內畀出可信答案，喺邊界外大聲講「我唔識」，而唔係靜靜地捏造一個數字。

OntiCards 嘅解法：數據卡片即語義層

語義層嘅價值已經被驗證，但對大多數中國企業嚟講，建設語義層係件頭痛嘅事：邊個寫文件？點保證文件跟得上業務變化？口徑唔一致點算？

OntiCards 嘅做法係：畀 AI 自動生成語義層初稿，再由業務專家校準。

喺我哋嘅架構中，呢層語義能力被封裝為數據卡片（Data Card）——每張卡片對應一份數據源，包含六個核心要素：

• 數據源基礎資訊：歸屬空間、來源系統、更新頻率

• 字段語義說明書：每個字段嘅業務含義、枚舉值、口徑定義

• 數據質素標籤：完整率、準確率、異常特徵

• 權限同脫敏規則：邊個可讀、邊啲字段需脫敏

• 業務場景標籤：該數據適用於邊啲分析場景

• 尋址查詢規則：點樣查詢、關聯邊啲數據源

當用戶用自然語言提問時，系統唔會直接將問題拋畀 LLM 寫 SQL。而係先查閱數據卡片，鎖定相關數據源、明確字段口徑、檢查權限邊界，再生成查詢。成個過程由數據卡片體系驅動，而唔係裸模型亂猜。

呢個同 dbt Labs 嘅語義層理念完全同向，但實施路徑更輕量：唔需要數據團隊先花三個月寫 dbt 模型，而係 AI 喺接入數據源嗰日就生成初版卡片，FDE 工程師喺後續迭代中持續校準語義。邊上線、邊建模、邊生長。

喺電商場景數據質素實操中，呢種「卡片驅動」嘅 NL2SQL 已能穩定處理跨表 JOIN、時間窗口、聚合口徑變換等複雜查詢。因為系統知道「銷售額」喺訂單表入面係 net_revenue，喺退款表入面要扣掉 refund_amount，而唔係畀 LLM 去猜。

畀技術負責人嘅一張檢查清單

如果你正喺度評估企業級嘅自然語言問數方案，建議用下面呢五條問題過濾供應商：

1. Schema 超過 50 張表時，系統點保證鏈路穩定？ 靠堆上下文窗口嘅，production 必崩。

1. 模型嘅失敗模式係「報錯」定係「靜靜計錯」？ 後者比前者危險十倍。

1. 語義層由邊個維護？ 純人工寫文件唔可持續，純 AI 生成唔可信賴，人機協作先係正解。

1. 同一業務指標，問三次係咪得到同一答案？ 口徑一致性係底線。

1. 超出覆蓋範圍嘅問題，系統係拒絕定係亂講？ 識拒絕嘅系統先值得信任。

寫喺最後

Text-to-SQL 唔係偽需求。業務人員用自然語言問數，係數據民主化嘅正確方向。但「裸模型直接寫 SQL」呢條路，喺企業環境裏已經被多項獨立研究證偽。

模型能力喺飛速進步，但企業數據嘅複雜度增長得更快。決定答案啱唔啱嘅，唔係模型參數有幾大，而係模型係咪攞到一張準確嘅「企業數據導航地圖」。

語義層——無論叫 Semantic Layer、數據卡片，定係業務口徑庫——就係呢張地圖。冇佢，再強嘅 LLM 都只不過係個喺陌生城市入面冇導航嘅司機。

參考來源

• Bruno Santos Teixeira, SemPlan: Benchmarking Structured Semantic Planning for LLM-Based Queries over Enterprise Data, arXiv:2608.13612, 2026-08-12. https://arxiv.org/abs/2608.13612

• dbt Labs, Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, 2026-04-07. 詳見 Atlan 轉載分析：https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/

• Text-to-SQL Explained: Why It Fails in Production and How to Fix It, Solution Gigs, 2026. https://solutiongigs.in/blog/text-to-sql

• The Semantic Layer: An Operator's Guide to AI Answers You Can Defend, Nufar Gaspar, 2026. https://nufargaspar.com/writing/semantic-layer-operators-guide

• Why Text-to-SQL Fails in the Enterprise, bits-bytes-nn, 2026-07. https://bits-bytes-nn.github.io/insights/data-architecture/2026/07/27/ai-ready-data-semantic-layer-knowledge-graph-en.html

• 語義層不是文件，是編譯器, 夜雨聆風, 2026. https://www.yeyulingfeng.com/a/921179.html