Snowflake Business Ontology 將開放預覽：AI 代理查營收前，誰決定哪個定義算數？

同樣問本季營收，財務和業務可能各有合理的數字。如果 AI 代理只找得到資料表，仍可能選錯公司要用的定義。

Snowflake 在 2026 年 11 月 3 日介紹 Business Ontology，準備把業務名詞、負責人、核准狀態及資料實作連在一起。

Ontology 在這裡可理解成業務概念及其關係的共同紀錄，不只是替欄位加註解。它要讓人和代理知道一個名詞由誰負責、在哪種範圍適用。

官方將這項能力與 Cortex Sense 都標示為即將開放公開預覽，並把它們和執行計算的 Semantic Views 分成不同層。

這個安排適合用來觀察企業 AI 如何接上資料治理，但它不代表模型會自行決定公司政策。重要定義仍需要組織的負責人審閱與核准。

要理解三層為何不能混成一個功能，先看清楚找得到資料、認得業務意思和算出指標之間的差別。

Business Ontology 如何讓名詞有負責人？

它要把名詞的意思、適用範圍、核准狀態和負責人放在同一份可追查的紀錄裡，讓代理知道公司認可哪個解釋。

依 Snowflake 正式介紹，Business Ontology 屬於 Horizon Context 的治理脈絡層，將連接業務概念與實作這些概念的資料及模型。

只有資料字典，為何可能不夠？

資料字典通常解釋欄位儲存什麼，但一個業務問題還可能涉及範圍與計算政策。以營收為例，團隊需要知道問題使用哪個部門核准的口徑，以及哪些資料應被納入。

因此，光是讓代理找到名叫 revenue 的欄位，不一定能回答問題。欄位名稱相同，可能仍對應不同期間、計算方式或部門用途，需要有明確的業務解釋。

定義由誰決定？

官方把建立、編輯與核准權限交給組織的治理控制，並由可負責的擁有人決定什麼內容成為正式版本。AI 建議和匯入的解釋，都是審閱起點。

這個責任安排很重要，因為定義會影響分析結果與後續決策。若沒有人負責核准，代理只是從多份說法中選一個，看似統一的回答仍可能缺乏組織依據。

不過，名詞有了負責人，還沒有完成資料發現與計算。這也解釋了為何 Snowflake 同時提出不同脈絡層，而不是讓單一工具包辦所有工作。

Cortex Sense、業務定義與 Semantic Views 各處理什麼？

三層分別處理自動取得背景、決定正式意思與執行指標計算，因此可以互相連接，但不宜視為同一種能力。

Cortex Sense 從查詢紀錄、儀表板與既有資料模型推論背景。Business Ontology 管理業務意思及其責任，Semantic Views 則把指標、分析維度與資料連接方式包成可查詢的物件。

為何推論不等於核准？

系統可以從平常使用方式推測某張表的用途，卻不因此自動取得替公司制定政策的權力。某種查詢很常見，也不代表它就是正式認可的財務口徑。

官方因此讓 Cortex Sense 提出初稿，再交由組織審閱。當已核准的解釋與自動推論衝突時，代理使用核准版本，而推論系統會從這項回饋學習。

計算為何還要保留在 Semantic Views？

業務定義回答的是一個指標代表什麼，計算物件則決定資料如何被聚合及連接。把兩者連起來，可以讓使用者從意思找到實際執行的位置。

但連接不會直接改掉每個 view 的計算邏輯，計算內容仍由原本擁有人管理。因此，治理流程既要處理語意，也要確保相連的實作符合核准範圍。

官方表示，三層不是固定先後順序。團隊可先處理最迫切的名詞或指標問題，再加入其他層，避免為了建一張大而全的模型，反而延後實際用途。

一個營收定義如何接上不同資料實作？

先寫清楚業務範圍，再連到負責計算的物件，能讓不同工具使用相同意思，同時保留各自的實作責任。

官方以淨營收示範：分析人員定義名詞、設定財務範圍、指定負責人並取得核准，接著連到計算該指標的 Semantic View。代理因此不只看到名稱，也能沿著關係找到數值來源。

同義詞為何有用？

員工可能用縮寫、部門慣用語或不同語言問同一件事。把同義詞連到同一概念，有助於降低因用詞不同而找錯資料的機會。

不過，名稱相似不代表意思一定相同。治理流程仍要確認它們是否真的指向同一項指標，而不能只因兩個欄位都含有營收，就自動合併。

如何讓答案可以回查？

一個較容易驗收的答案，應能讓人找到使用的定義、核准狀態及計算位置。這些連結提供的是查核路徑，並不代表所有計算或輸入資料都已自動保證正確。

如果數字與預期不同，使用者便能先辨認是選錯適用範圍、計算實作有差異，還是資料本身需要更新。把問題分開，比只問模型為什麼回答另一個數字更容易處理。

遇到不同品牌與地區口徑時，為何不能強行合併？

有些差異本來就是業務需要，治理的目的應是讓差異可辨認，而不是把所有部門改成同一種答案。

Snowflake 以餐飲公司不同品牌的同店銷售為例，說明各品牌可以保留分別核准的版本，並連到相應計算。這表示同一類概念可以有清楚標記的不同範圍。

一個問題缺少範圍時會怎樣？

如果使用者只問營收，卻沒有交代地區或部門，資料再完整也可能產生多個合理答案。代理要選哪個範圍，仍需要依問題及組織規則處理。

因此，統一背景不等於取消澄清。對會影響決策的問題，保留適用情境與核准來源，才能讓不同答案有可解釋的差異。

為何這比只放一份詞彙表更進一步？

靜態詞彙表能記錄意思，但若沒有連到資料和計算，內容變動後仍容易失聯。這次設計把業務概念與實作關係連在一起，讓人有機會追到改動影響哪些使用情境。

實際導入時，團隊仍要安排更新責任。當指標定義的計算政策變更，擁有人需要確認相關定義及實作是否同步，否則共用同一個入口仍可能取得過期背景。

從既有紀錄推論的脈絡如何變成核准知識？

先從已經存在的使用方式蒐集線索，再讓負責人審閱重要概念，能減少從空白開始建模的負擔，同時保留決策責任。

Horizon Context 的連接器會蒐集結構、查詢紀錄、儀表板定義與使用訊號，並透過跨平台資料血緣追蹤來源與轉換。資料血緣指資料從哪裡來、經過哪些加工、最後被用在哪裡。

自動蒐集後還需要人做什麼？

不同工具可能留下互相衝突的理解。官方說明，Cortex Sense 會辨認衝突並詢問團隊信任哪個來源，而不是直接把最多人使用的說法當作正式政策。

這讓回饋成為治理流程的一部分。團隊可先圈定特定業務問題，連接相關背景，再用評估及修正逐步提高適用性，不必一次替所有資料表建立完整解釋。

哪些概念應先處理？

較合理的起點，是對決策影響大、又常被不同部門解讀不一致的指標。若每一個不影響判斷的欄位都投入相同核准工作，治理成本可能超過短期用途。

這是依產品分層提出的導入判斷，不是官方已公布所有公司的最佳清單。真正的優先順序，仍要由團隊常遇到的問題與資料責任決定。

既有分析工具如何提供背景？

官方列出的來源包括 Tableau、Power BI、dbt 和不同資料庫。它們留下的查詢與模型紀錄，能提供資料平常如何被使用的線索，讓新代理不必完全從欄位名稱猜用途。

但這些來源扮演的角色不同：儀表板顯示業務如何閱讀結果，轉換模型說明資料如何加工，查詢紀錄則反映人們實際怎麼提問。把它們連起來，才比較容易理解同一個數字的來處。

因此，跨平台脈絡的價值不只是多接幾個連接器，而是讓使用者沿著來源、轉換與呈現方式找到關係。若其中某段缺少紀錄，團隊也需要知道這個限制。

背景更新後，核准知識也會自動改嗎？

Cortex Sense 可以依團隊選定的節奏更新其知識，但它推論到新情況，與組織正式變更計算政策仍有差別。重要定義若要修改，需要保留負責與審閱安排。

例如，某份新報表開始使用不同名稱，系統可以找到線索，但是否與既有營收概念相同，仍需由熟悉業務的人確認。這是說明推論與核准差異的情境，不是官方公布的新自動核准功能。

因此，資料團隊需要把「新線索進來」和「正式定義改版」視為可追蹤的不同事件。這樣一來，代理答案改變時，才比較容易辨認是資料變動、範圍改變，還是組織真的調整了業務意思。

當同一指標被多個應用使用，定義改版的影響也會擴大。負責人需要知道哪些計算與使用情境連到這個概念，才有機會在調整前確認相依關係。

因此，關係圖的用途不只是方便搜尋，還能作為討論變更的共同背景。它是否涵蓋所有下游使用，仍取決於已連接的來源與紀錄完整度，不能單憑畫面就假設整家公司都已納管。

跨工具使用如何保留計算與權限責任？

定義可以在工具間移動，並不表示使用者會自動取得原本沒有的資料權限，因此開放格式與存取管理仍需一起看。

官方說明 Semantic Views 可匯入、匯出 Apache Ossie 定義，也允許外部代理透過 MCP 查詢。MCP 是讓代理以一致方式連接外部工具與資料的協定，這裡的存取仍受 Horizon Catalog 管理。

開放格式解決哪個問題？

它希望減少每換一種工具就重建指標的工作。但格式能交換，與不同平台對每項概念的支援是否完全相同，仍是需要驗證的兩件事。

因此，企業可以用一個已有核准定義的指標，檢查匯入後是否保留範圍、關係與計算連結。只確認檔案能被讀入，還不足以證明業務意思已完整保留。

與 CoCo、CoWork 有何關係？

Snowflake 同期的 CoCo 更新及 CoWork 更新呈現代理進入更多企業工作的方向。這些應用越能使用資料，背景的責任與一致性就越重要。

但應用範圍擴大，不代表新的治理功能都已正式可用。Business Ontology 與 Cortex Sense 仍列為即將開放公開預覽，企業需再確認可用資格與支援條件。

Snowflake Business Ontology 常見問題

Business Ontology 已經正式開放了嗎？

本次官方文章標示為即將開放公開預覽，不能寫成全面正式可用。實際試用資格、地區與時間，應依後續官方安排確認。

它會自動修改公司的計算方式嗎？

官方將業務意思與實際計算分開，計算邏輯仍留在 Semantic Views 及其擁有人的責任範圍。連接定義不等於直接改寫所有計算。

所有部門都必須用同一個營收口徑嗎？

不同業務範圍可以保留分別核准的版本。重點是讓代理知道使用哪個範圍，並能追到負責人與實作，而非把合理差異全部取消。

AI 建議是否直接成為正式定義？

AI 推論與匯入內容是供審閱的起點，正式版本仍需由組織的負責人核准。這讓共同背景具有可追究的責任來源。

先整理會影響決策的定義，再擴大代理使用

Snowflake 這次把企業背景拆成推論、核准與計算，值得資料團隊用來檢查自己的責任缺口。先從一個常被問錯的業務指標開始，會比只追求代理能連多少資料，更容易看見實際改善。

想持續追蹤企業資料如何支撐可靠的 AI 工作流程，歡迎免費訂閱 AI 郵報。

延伸閱讀

延伸閱讀：Knowledge Catalog 語意模型整合正式開放：AI 為何需要同一套營收定義？

延伸閱讀：Databricks 與 SAP 擴大合作：企業資料如何接到 Genie、代理與應用？

原始資料來源

• Snowflake Business Ontology正式介紹
• Snowflake CoCo雲端代理更新
• Snowflake CoWork工作流程更新