語義層成 Agent 新底座：從 Oracle、Google 同學界本週嘅共識，睇 OntiCards 點定位

三家同一個禮拜做咗同一件事

過去一個禮拜，語義層（Semantic Layer）突然成為數據圈最熱嘅關鍵詞。

Oracle 喺官方網誌發文呼籲：畀 Agent 揀 fixed trusted reports，唔好要佢直接寫 SQL。具體做法係將分析師已經審過嘅查詢封裝成「報表工具」，Agent 只需要喺呢啲工具入面揀一個並填入參數。就算有人繞過 prompt 注入攞到 40+ 個 MCP 漏洞，Agent 可以接觸到嘅數據範圍仍然係固定嘅。

Google Cloud 喺 8 月 13 日發表《Using BigQuery Graphs with measures for trusted agentic workloads》，將 Graph 同 Measures 同時擺入同一套受治理嘅數據模型入面。喺西雅圖冬季夾克銷量下跌 12% 嘅零售案例入面，SQL/Measure 只能夠話畀你聽「跌咗幾多」；而 Graph 能夠話畀你聽「點解跌」——係邊個配送中心、邊條供應鏈、邊場風暴拖慢咗交付。Agent 必須同時擁有「calculator」同「map」先至能夠負責任咁畀建議。

學界都冇閒住。SIGMOD 2026 收錄嘅 A Semantic‑Layer‑Mediated Agent for Natural Language to SQL 論文，將 Gemini 3 Pro 接駁到一個 curated semantic layer、用 Semantic Model Query（SMQ）做中間表示，喺 Spider 2.0‑snow 547 題上面達到 94.15% 執行準確率，位列官方榜第三。同期一篇分析指出，o1‑preview 喺同一基準上面只得 17.0%。17.0% 對 94.15%，幾乎係一倍同五倍嘅差距。

Oracle、Google、學界——三路玩家同一個禮拜押注同一件事。呢個唔係巧合，而係工程共識正在形成：「原始 Schema → 大模型直出 SQL」呢條路線，喺企業入面已經行唔通。

點解「模型直出 SQL」路線突然唔掂？

將過去三年嘅工程經驗拼埋一齊睇，模型直出路線有三層天花板，而每一層都啱啱係語義層解決嘅問題。

第一層業務詞彙唔對應字段。用戶問「高價值客戶嘅流失風險」，數據庫入面冇一列叫呢個名。要將佢計出嚟，需要業務側提供「高價值」嘅定義（最近 12 個月消費金額 + 利潤貢獻 + 合約狀態），模型並唔知道你公司用緊邊一個版本。

第二層指標口徑衝突。Revenue 喺財務係含稅應收、喺銷售部門係訂單金額、喺客服中心係 GMV 減去退款。喺 prompt 入面提提「請使用財務口徑」治標唔治本——切換業務嗰陣模型會唔記得。

第三層JOIN 路徑靠估。客戶表、訂單表、合約表之間嘅關聯通常係隱式嘅，需要業務側提供關係地圖。畀模型自己估 join，最常見嘅產物係重複計數或者漏咗關鍵記錄。

Spider 2.0 將呢三點全部推到極端：1000+ 字段、跨方言、跨 5+ 張表嘅真實企業 schema。o1‑preview 喺呢個基準上面只完成 17.0% 嘅任務，啱啱說明「模型聰明」同「模型做到嘢」係兩件事。

將語義層加入架構之後，模型嘅角色由「獨立寫晒 SQL」切換成「表達意圖」——模型只需要回答「用戶喺問咩業務對象、用邊個指標、喺咩時間窗口同篩選條件下面」，剩下嘅編譯（指標展開、表選擇、JOIN 路徑、權限注入）由語義層同下游編譯引擎負責。Spider 2.0 由 17% 跳到 94.15%，原因唔係 Gemini 比 o1 強 5 倍，而係將模型唔應該做嘅嘢由模型手上攞走咗。

三層語義層 + 業務編譯器嘅實踐路線

為咗令 Agent 真正變得可信，主流玩家開始將語義層擴展到三層：指標層（Measures）+ 實體層（Entities）+ 關係層（Relationships）。每一層獨立維護、獨立治理，下游嘅 Agent 編譯引擎將佢哋編譯做可執行 SQL。

• Google BigQuery Graph with Measures（Preview）：喺 Property Graph DDL 上面直接定義 MEASURE（SUM/AVG/COUNT DISTINCT 等），同節點 KEY 綁定，避免 Graph 展開之後重複計數。強調 zero ETL——企業唔使先起一個獨立嘅圖數據庫。

• Oracle Trusted Reports：將查詢模板固化做「報表工具」，Agent 喺工具池入面揀一個並填參數；查詢邏輯唔可以再畀模型自由改動，從源頭杜絕憑空構造 SQL。

• 螞蟻 Agentar-SQL：用 Agentar-Scale-SQL 框架喺 BIRD-SQL 上面霸榜；某頭部城商行試運營查詢準確率 > 92%，較傳統方案提升 3 倍以上。

• 阿里瓴羊「超級數據分析師」：將「問數 / 解讀 / 報告」三個 Agent 編排起嚟，電商業務人員取數由 2 小時縮短到 10 秒——背後係統一嘅指標語義層。

• Snowflake Cortex Analyst + Semantic Views：將 dbt Semantic Layer / MetricFlow 嘅指標定義直接編譯入 BI Agent 嘅 prompt。

可以見到，所有路線都將「模型唔應該做嘅嘢」由模型手上移走。分別只在於將呢件事做晒成 BI 報表、做晒成 Graph、做晒成 dbt 指標定係做晒成業務對象——但骨架都係：模型表達意圖，語義層負責編譯同治理。

OntiCards 嘅語義層點樣「兩手抓」

返到 OntiCards 自家：四層架構 入面第二層「數據卡片層」，本質上就係一套面向 Agent 嘅語義層工程實現。我哋冇將佢做晒成 Graph、亦冇做晒成 dbt，而係做晒成業務側能夠直接理解、直接治理嘅「數據卡片」。

一張數據卡片係噉樣：

• 實體（業務對象）：訂單 / 商品 / 客戶 / 配送中心（同你著緊嘅嘢一一對應）

• 字段（業務字段而唔係物理字段）：「高價值客戶」、「本月新客」、「已簽未發貨」呢種業務概念

• 關係：實體之間嘅業務關聯（邊個為邊個落單、邊個畀邊個供貨）

• 質量門禁：邊啲字段必須非空、邊啲值必須喺指定範圍、邊啲關聯必須成立

相比 BigQuery 嘅 Graph 模型，OntiCards 嘅卡片更貼近業務：業務人員可以直接定義「高價值客戶」，唔使寫 Property Graph DDL。相比 dbt 嘅指標層，我哋多咗一層術語庫——同一件事可能會叫做「銷售額」、「營收」、「GMV」，術語庫負責將多個口語化嘅叫法統一指去同一個業務對象。

相比 Oracle 嘅 Trusted Reports，我哋更輕：Agent 唔需要每次都喺固化報表池入面揀——佢可以臨時查新指標，前提係呢啲指標已經喺卡片入面被治理過。當新指標進入卡片嗰陣，質量門禁會自動行一遍；唔合格，Agent 永遠都睇唔到佢。

呢個就係點解話 OntiCards 「啱啱中靶心」——呢一波語義層趨勢唔係某一家廠商嘅發明，而係成個行業向同一個方向收斂；OntiCards 一開始就將數據同 Agent 解耦成四層（接入 / 卡片 / 問數 / 消費），只係行業而家先意識到呢條路係必須嘅。

點評估一個語義層合唔合格？

如果你打算畀自家 Agent 接駁語義層（無論係採購定係自建），可以用以下四步快速體檢：

1. 業務可讀：業務人員能直接參與定義。一個唔畀業務理解同編輯嘅語義層，最終會退化成「數據團隊二次維護嘅 Schema」。

1. 指標有口徑：每個業務指標必須能解釋「喺咩時間窗口、按咩狀態、扣咗邊啲項」先至算定義過。

1. 關係可表達：跨表 JOIN 唔可以靠工程師用 prompt 提示 Agent 臨時拼湊；必須由語義層提供顯式關係圖。

1. 治理可閉環：指標錯誤、口徑漂移、字段缺失應當可以喺語義層就被攔截，而唔係喺數據分析師覆核嗰陣先至發現。

如果你嘅語義層喺四步上面都過關，但 Agent 準確率仍然上唔到——嗰大概率問題喺數據接入層（數據質檢與對賬），唔喺語義層。換句話講，語義層唔係萬能解藥，但佢解決咗 Agent 規模化最難嘅一半問題。

參考來源

• Oracle：What we learned about letting agents into a production database

• Google Cloud：Using BigQuery Graphs with measures for trusted agentic workloads

• A Semantic-Layer-Mediated Agent for Natural Language to SQL over Heterogeneous Enterprise Databases（arXiv）

• Spider 2.0 官方排行榜

---

有關語義層同本體（Ontology）嘅分別，可以參考 OntiCards 路線圖；想直接體驗「卡片驅動取數」，歡迎聯絡我哋（hello@onticards.com）申請開通測試賬號。定價 同金融行業方案 亦已就緒。