Schema 能告訴 AI 有哪些表、欄位和型別，卻不會告訴它公司如何定義「有效客戶」、退款要不要扣除，或轉換率該用哪個分母。AI 要可靠地查企業資料，除了看懂資料結構，還需要可追溯、可審閱且有適用範圍的業務語意。
Schema 描述資料長相，不描述公司如何做決定
假設資料庫裡有這些欄位：
accounts(account_id, created_at, status)
subscriptions(account_id, started_at, cancelled_at, plan)
events(account_id, event_name, occurred_at)
invoices(account_id, amount, paid_at, refunded_at)
光看名稱，模型可以推測 paid_at 是付款時間、amount 是金額，也能組出語法正確的 SQL。但當使用者問「上個月新客轉換率是多少」，schema 沒有回答下面任何一題：
- 「新客」以帳號建立、首次啟用，還是首次付款認定？
- 同一公司開了三個帳號，分母算一個還是三個？
- 免費方案轉付費是否計入轉換？
- 轉換時間窗是註冊後 7 天、30 天，還是同一曆月？
- 測試帳號、內部帳號與取消後重訂要不要排除？
- 遲到資料與退款應回補到哪一期？
這些不是欄位探索問題，而是業務規則。模型即使完全沒有寫錯 SQL 語法，也可能在多個「都說得通」的定義中選錯一個，最後交出精確但不可用的數字。
2026 年提出的企業 Text-to-SQL benchmark EntSQL，正是為了測量這個落差。它包含五個業務領域、1,066 組中英語意對齊案例；論文指出，多數案例除了問題和 schema，還需要內部指標、報表慣例或組織規則。該研究在英文輸入、提供長篇企業文件的設定下，最佳受測系統只有 15.9%。這不是所有 AI 分析工具的通用準確率，但它說明了一件事：把 schema 丟進 prompt，並不等於模型已理解企業。EntSQL 論文摘要與版本紀錄
AI 分析需要的不是更多欄位，而是六種語意
「語意層（semantic layer）」通常指位於原始資料與使用端之間、集中描述商業概念的模型。不同產品實作並不相同，但常見內容包括 metrics、dimensions、relationships 與計算規則；例如 Salesforce 的 Tableau Semantics 也把維度、量值、關係與指標列為主要定義類型。Tableau Semantics 概念文件
若目標是讓 AI 協助分析，可以先不爭論工具名稱，而是確認六種語意是否齊全：
| 語意 | 必須說清楚的問題 | 缺少時的典型錯誤 |
|---|---|---|
| Entity | 客戶、帳號、訂單分別以什麼 key 識別？ | 把多帳號公司重複計數 |
| Grain | 每列代表事件、日、訂單還是客戶？ | JOIN 後金額或人數膨脹 |
| Metric | 公式、分子、分母與聚合方式是什麼？ | 同名 KPI 算出不同版本 |
| Time | 使用事件時間、入庫時間或財務期間？ | 跨月結果無法對帳 |
| Scope | 哪些狀態、方案、地區與測試資料要排除？ | 把不適用樣本算進結果 |
| Authority | 誰核准、適用哪個專案、何時更新？ | 過期規則持續被重用 |
完整的 semantic layer 可以讓 metrics 與 dimensions 被不同工具重用，甚至把定義轉成查詢。Cube 的官方文件便示範了如何將 measure、dimension、filter 與 calculated measure 寫進可重用資料模型，再由模型生成 SQL。Cube Data Modeling 文件
但「有一份指標字典」與「系統會強制套用同一套計算」仍是兩件事。Markdown、Wiki 或 catalog 可以提供上下文；可執行的 semantic layer 則能在查詢時套用定義。團隊應清楚標示自己目前做到哪一層，不能因為文件存在，就假設所有 AI 查詢都會自動遵守。
把一句指標定義，寫成 AI 能被審查的契約
「付費轉換率＝付費客戶／新客戶」看似已經很清楚，實際上仍缺少執行條件。較可用的定義至少應長成下面這樣：
指標：新客 30 日付費轉換率
適用範圍：台灣自助註冊帳號；排除員工、測試與合作夥伴帳號
Entity：company_id，一家公司只計一次
分母：觀察月首次完成 email 驗證的公司
分子：分母公司中，驗證後 30 日內首次成功付款者
時間欄位：verified_at、paid_at，皆以 Asia/Taipei 計算
重訂規則：觀察月前曾付費者不算新客
資料來源：accounts、company_members、invoices
驗證：分母與 CRM 新客月報對帳；抽查跨月底付款案例
Owner：Growth Ops
版本：2026-07-01 起適用
這個格式的重點不在 Markdown，而在它讓人能提出具體異議：為什麼用 email 驗證而不是建立帳號？企業業務帶來的客戶為何排除？30 日跨越報表月份時如何呈現？
AI 可以協助把契約轉成 SQL，但契約本身不該由模型默默猜完。只要 entity、grain、時間窗或排除條件尚未取得共識，就應先把它標成待確認假設，而不是用最可能的欄位名稱代替決策。
不一定要先買一套 semantic layer，先判斷缺口在哪
導入方式可以按重用需求逐步增加：
- 一次性探索：在分析 Plan 寫清 grain、filter、join 與時間窗，保留 SQL 供審閱。
- 專案內重用：建立指標卡、欄位映射與狀態碼 Reference，指定 owner 和版本。
- 跨工具共用：將穩定 metrics、dimensions、relationships 放進可執行的 semantic layer 或 metrics layer。
- 組織級治理：加入變更審核、權限、測試、lineage 與淘汰流程。
如果公司只有幾張穩定報表，先把最常爭議的十個指標寫清楚，通常比一次建模所有資料更實際。反過來，若同一指標同時供應 BI、試算表、API 與多個 AI Agent，僅靠每次 prompt 附上一份文件，很容易發生版本漂移；這時可執行且集中治理的語意層會更重要。
Lantide Data 如何把業務語意放進可治理的分析流程
Lantide Data 不把自己定位成企業級 semantic layer 或指標服務。它處理的是另一段風險：當分析師與 AI Agent 真的要查資料時，如何讓業務語意被讀取、被審閱，並留在可追溯的交付流程裡。
- Reference docs 適合保存欄位映射、狀態碼、join 說明與完整指標定義；Project Knowledge 中只保留用途與讀取時機，讓 Agent 按任務載入，而不是把大型文件永遠塞進 prompt。
- 跨對話可重用的口徑可由 Agent 提案進 Queued Knowledge，附上可驗證 evidence；只有使用者 Apply 到 User 或指定 Project 後，才會進入後續上下文。
- 正式分析把 entity、grain、filter、時間窗與驗證方式寫進 Plan。使用者審閱並按下 Execute 後，Agent 才依契約執行，最後以 SQL evidence 與限制形成 Report。
這三層分別處理「大型參照資料」「核准後的長期知識」與「本次分析契約」，彼此不能取代。Reference docs 與 Agent Memory 提供上下文，不會像可執行 semantic layer 一樣自動強制所有指標定義；Plan 審閱也不能證明來源資料本身正確。團隊仍需維護上游模型、測試口徑，並由對結果負責的人作最後判斷。產品機制可參考 Agent 分析工作流、可治理的 Agent Memory 與 Reference docs 操作說明。
結語：先找出模型正在猜的那一層
下一次 AI 產出一段能跑的 SQL，先別只檢查語法。逐項問 entity、grain、metric、time、scope 與 authority 是否已有明確答案；沒有答案的地方，就是模型正在猜的地方。
Schema 是分析入口，不是業務契約。可靠的 AI 分析也不只是把更多文件送進 context，而是讓定義有來源、適用範圍與核准者，並讓每次執行留下可審閱的 SQL 和限制。