AI 分析的脆弱環節：為何語義層 (Semantic Layer) 是比 Text-to-SQL 模型更根本的解方

當企業急於導入 AI 進行數據分析時，我們常將焦點錯置在模型生成 SQL 的準確率上。然而，真正的脆弱環節並非技術本身，而是組織層面的數據治理。如果一個組織連「活躍用戶」或「淨收入」等核心指標的定義都無法達成共識，再強大的 AI 也只會成為一個高效的「誤解產生器」。它會迅速且自信地，將不同部門、不同口徑的矛盾數字包裝成專業答案，最終侵蝕數據可信度。因此，在追求 AI 自動化分析之前，建立統一的語義層 (Semantic Layer) 來定義指標、確保口徑一致，才是更根本且必要的基礎建設。

「自然語言分析」的陷阱：當 AI 成為高效的誤解製造機

近年來，以自然語言驅動的數據分析工具（Text-to-SQL）在各種產品演示中大放異彩。用戶只需用日常語言提問，AI 就能自動生成 SQL 查詢並呈現結果，這看起來確實是數據民主化的終極解答。然而，在實際導入的過程中，多數團隊很快就會碰到一堵隱形的牆：AI 給出的答案經常不一致，甚至完全錯誤。

問題的根源，很少是 AI 模型「寫錯」了 SQL 語法。更常見的狀況是，AI「猜錯」了業務語境。試想一個簡單的問題：「我們上個季度的總銷售額是多少？」

這個問題看似簡單，但在不同部門眼中卻可能有截然不同的解讀。財務部門可能關注扣除退款、折扣後的「淨銷售額」；行銷部門或許看的是包含所有訂單的「總商品價值 (GMV)」；而營運部門則可能只計算已出貨商品的金額。如果沒有事先約定好的定義，AI Agent 會如何選擇？它很可能根據訓練資料的偏好，隨機選取一種看似合理的 SQL 寫法，但這個選擇幾乎不可能是永遠正確的。

這種模糊性，正是直接讓 AI 面對原始資料庫（Raw Database）的根本風險。AI 缺乏組織內部的領域知識與默契，它無法理解那些沒有寫在資料庫綱要 (Schema) 裡的隱性規則。結果就是，AI 會產出語法正確、但業務邏輯錯誤的查詢，而這種錯誤因為被 AI 光環包裝，往往更難被察覺。

為什麼直接生成 SQL 如此不可靠？

讓大型語言模型直接將自然語言轉為 SQL 查詢，這個看似直觀的路徑，在實務上至少面臨三個重大挑戰，這些挑戰也凸顯了僅僅依賴模型智慧的侷限性。

首先是語義的模糊性 (Semantic Ambiguity)。如前述例子，商業指標充滿了細微但關鍵的定義差異。一個詞彙（如「用戶」）在資料庫中可能對應到多個表格（`users`, `customers`, `leads`），AI 難以在沒有明確指引下做出正確的實體連結。學術界雖然透過如 Spider 這類大型資料集來提升模型的複雜查詢能力，但這些研究仍難以複製企業內部獨特且不斷演變的業務邏輯。

其次是模型的脆弱性 (Model Brittleness)。Text-to-SQL 模型對問題的措辭、資料庫綱要的微小變動都極其敏感。例如，當資料庫中的 `order_date` 欄位更名為 `created_at`，所有依賴舊名稱的 AI 查詢都會立刻失效。這種緊密耦合使得系統維護成本極高。一篇 2023 年的研究就指出，即使是頂尖的 LLM 在處理 Text-to-SQL 任務時，其表現也可能因微小的語義擾動而大幅下降，顯示其穩定性仍有待商榷。

最後是治理與信任的缺失 (Lack of Governance and Trust)。如果每個用戶向 AI 提問都可能得到一組略有不同的 SQL 與結果，那麼數據的信任度將蕩然無存。組織無法建立一個「單一事實來源 (Single Source of Truth)」。這也引出了數據契約 (Data Contracts) 的概念——我們需要為數據的生產與消費建立清晰的、可執行的規範，而讓 AI 直接存取底層數據庫，恰恰繞過了這個重要的治理環節。

語義層如何成為 AI 分析的「翻譯官」與「護欄」？

與其訓練一個「更聰明」的 AI 來猜測業務邏輯，不如從根本上解決問題：為數據建立一個清晰、統一的業務語義層。語義層是一個位於用戶與實體資料庫之間的中介層，它的核心任務是將複雜的數據結構，轉譯成易於理解的商業概念。

例如，我們可以透過語義層預先定義好所有關鍵指標。當用戶詢問「淨銷售額」時，系統不再需要 AI 去猜測 SQL，而是直接取用已經由數據團隊定義、驗證、並標準化的指標。這個指標的計算邏輯（例如：`SUM(payments.amount) - SUM(refunds.amount)`）已經被固化在語義層中。

一個設計良好的語義層，能為 AI 分析提供多重關鍵價值。首先是一致性 (Consistency)，它確保每個人、每次查詢，對於同一個指標都能得到相同的數字，這是數據信任的基石。其次是抽象化 (Abstraction)，語義層能巧妙地將底層數據庫的複雜性隱藏起來，無論底層表格如何變化，只要語義層的指標定義不變，上層的 AI 應用就不會受到影響。此外，它還能強化治理 (Governance)，成為指標定義、權限控管與數據血緣 (Data Lineage) 的中心，讓所有數據的取用都有跡可循。最終，這帶來了更高的敏捷性 (Agility)：一旦核心指標被定義好，AI 就能在這些可信的「積木」上進行更複雜的組合分析，而不用每次都從頭猜測。

近年來，像 dbt Semantic Layer、Cube 或 Google Looker 的 LookML 等工具，都在致力於讓語義層的建構與維護變得更加標準化與便捷。它們讓數據團隊能用程式碼的方式來管理指標（Metrics as Code），將數據治理融入開發流程。

總結來說，企業在導入 AI 數據分析時，最應該投資的或許不是最先進的 LLM，而是最穩固的數據基礎建設。與其期待一個全知的 AI，不如先透過語義層，讓組織自己先對數據的意義達成共識。當指標有了清晰的定義、口徑有了統一的標準，AI 才能真正成為賦能業務的可靠夥伴，而不是一個製造混亂的黑盒子。先治理，再分析，這才是 AI 時代數據策略的務實之道。

延伸閱讀

• Google Cloud BigQuery 公開資料集
• What is a semantic layer? (dbt Labs)
• Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Text-to-SQL Task (arXiv)

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。