從 Anthropic 的實務經驗看 AI 數據分析：為什麼數據治理比模型能力更重要？

許多工程師在嘗試用 LLM 進行數據分析時，常會陷入一個誤區：認為只要模型夠強（例如從 GPT-4 升級到 Claude 3.5），AI 就能自動理解複雜的資料庫結構並給出正確答案。然而，AI 巨頭 Anthropic 最近分享的內部經驗給了我們一個完全不同的視角。他們成功讓 Claude 處理了公司內部 95% 的分析請求，且準確率達到 95% 以上，但這背後的關鍵並非模型本身的進化，而是極其嚴格的數據治理與語義層設計。

對於初入數據工程或 AI 應用的工程師來說，這篇案例揭示了一個核心真相：AI 分析的上限不取決於模型，而取決於底層數據平台的可靠性。

AI 分析的痛點：為什麼直接查詢會失敗？

在沒有特殊設計的情況下，如果直接讓 AI 讀取資料庫 Schema 並寫 SQL，準確率通常很低。Anthropic 的測試顯示，在沒有賦予特定技能的情況下，Claude 僅能正確回答 21% 的分析問題。

這是因為企業數據環境存在兩個經典矛盾。第一是自助服務的混亂，當每個人都能定義自己的指標時，會出現重複的數據集與衝突的定義（例如不同部門對 週活躍用戶 WAU 的定義不同）。第二是報表僵化，過於嚴格的儀表板雖然準確，但無法回答長尾的、非預期的業務問題，導致儀表板數量爆炸。

解決方案：建立四層 AI 分析架構

為了突破上述限制，Anthropic 並非單純地餵入更多 Prompt，而是建立了一套分層架構，將 AI 從 寫 SQL 的工具 提升為 能夠理解業務邏輯的代理人。

第一層是數據基礎層 Data Foundations。這包含經過治理的模型、標準化指標與元數據 Metadata（描述數據的數據，例如欄位定義、更新頻率）。這確保了 AI 訪問的是經過清洗且權威的數據源，而非混亂的原始表。

第二層是知識層 Knowledge Layer。這層的核心是語義定義 Semantic Definitions 與血緣分析 Lineage。它解決了概念與實體之間的模糊性。當使用者詢問 週活躍用戶 時，知識層會告訴 AI 這對應到數據模型中哪個具體的定義與計算邏輯，而不是讓 AI 自己猜測。

第三層是技能層 Skills。這是將可重複的分析工作流編碼化。透過將業務上下文與分析路徑封裝成技能，AI 不再是隨機生成 SQL，而是遵循一套經過驗證的分析步驟。這讓準確率從 21% 飆升至 95% 以上。

第四層是驗證系統 Validation Systems。用於檢查輸出結果的正確性與一致性，確保 AI 給出的數字在邏輯上是成立的。

核心技術觀點：語義層 Semantic Layer 的決定性作用

從技術實作角度來看，Anthropic 實際上是實作了一個強大的 語義層 Semantic Layer。

語義層就像是數據庫與 AI 之間的一個翻譯層。AI 並非直接查詢原始資料表，而是先透過語義層去確認維度 Dimensions（分析的角度，如時間、地區）、指標定義 Metrics（計算方式，如總營收）以及關聯關係 Joins。

這種做法將分析結果從 隨機生成 轉變為 確定性輸出。對於工程師而言，這意味著我們應該將精力從 優化 Prompt 轉移到 建立單一事實來源 Single Source of Truth。

實務啟示與限制

這套方案給我們的啟示是：AI 性能的瓶頸往往不在於模型能力，而是在於上下文定義 Context Definition。如果你的數據定義是模糊的，再強的模型也只能產出精美的錯誤答案。

然而，這種做法也有其挑戰。它要求團隊投入大量人力進行數據建模與維護，必須持續偵測過時的定義，並確保文檔與實際數據同步。這並非一個可以快速部署的插件，而是一場關於數據工程紀律的長期投資。

總結來說，想要讓 AI 真正接管業務分析，工程師需要做的是為 AI 鋪好路，而不是期待 AI 能在荒原中自行開路。

來源：infoq.com (Anthropic Blog)

本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。