一種詞彙，兩種受眾：為什麼您的人工智慧和儀表板必須共享語義層

number 包含三種不同意義

詢問同一家公司的三個團隊「本季活躍會員」的數量，你通常會得到三個不同的數字。行銷部統計的是打開郵件的使用者。忠誠度團隊統計的是購買過商品的會員。財務部統計的是兌換過價值的會員。他們都沒有說謊。他們只是基於不同的定義，使用不同的 SQL 編碼，並運行在不同的工具中。雖然都用了「活躍會員」這個詞，但意思卻不一樣。

當這些數據僅供人類使用時，這尚可接受。經驗豐富的分析師會詢問你指的是哪個定義，投影片上的腳註可以掩蓋其他問題。但一旦你將相同的資料交給人工智慧代理，腳註就會消失，歧義就會變成隱患。代理並不知道「活躍」一詞有爭議。它會選擇一個定義——或者更糟，編造一個定義——並以呈現其他所有內容的相同自信來呈現結果。

工具是動詞；語意層是詞彙

當你賦予代理工具時，你實際上是賦予了它動詞：查詢、總結、比較、預測。 Anthropic 的模型上下文協定對此進行了形式化定義——工具是模型可以呼叫的類型化、命名的能力。這種框架是正確且有用的。但一個沒有共同詞彙支持的動詞，就等於給了即興發揮的許可。 「告訴我收入」這句話只有在「收入」只有一個經過認證的定義時才是安全的，這個定義必須與人們在儀表板上看到的定義相同，並且每次計算的方式都一樣。

這是核心論點：經過認證的指標語意層是共享詞彙表，它確保代理的動詞真實可靠。工具讓代理執行操作。語意層定義了這些操作的含義。將兩者分離，你會得到一個可以執行查詢但無法被信任地解釋查詢結果的代理。將它們統一起來，代理就能免費繼承分析師們已經努力達成一致的所有定義。

接下來的原則簡單易懂，難以偽造：一套詞彙表，兩個受眾群體。使用者透過儀錶板和臨時問題取得資訊。代理透過 MCP 工具和輔助系統取得資訊。兩者都從同一個認證層讀取數據，因此無論是用戶還是代理提出 number 請求，其含義都相同。

缺乏共享層時的故障模式

跳過語意層，三個失敗同時出現。首先，人工智慧產生幻覺——不是因為模型被破壞了，而是因為你要求它對沒有任何規範定義的原始表格進行推理，所以它用合理的猜測填補了空白。其次，KPI 定義發生了變化：每個團隊、工具和筆記本重新實現的「流失」或「AOV」都略有不同，差異悄悄加劇。第三，「自助分析」產生相互矛盾的數字，組織悄悄地不再信任所有這些數字。

德勤的《企業人工智慧現況》研究始終表明，信任與治理──而非模式本身的能力──才是企業將人工智慧從試點階段擴展到生產階段的關鍵因素。這與分析問題直接相關。真正的障礙很少在於模型是否能夠編寫SQL語句，而是在於是否有人能夠充分信任模型的分析結果並據此採取行動，以及他們之後能否解釋number的來源。

已認證的定義及其版本歷史記錄

經過認證的指標是指由所有者審核並簽署確認的唯一權威定義。 「活躍會員」並非目前查詢的計算結果，而是一個命名明確、受管理的 object，具有明確的邏輯、所有者和狀態。當行銷、客戶忠誠度計畫和財務部門意見不一致時，他們不再需要爭論 SQL 語句。他們只需公開討論一次定義即可。然後，該定義將被認證，所有人——包括每個人和每個代理商——都將獲得相同的答案。

版本控制是確保資料持久性的關鍵。定義會不斷演進：財務日曆會更改，細分市場會進行最佳化，資料來源會修正。如果沒有版本控制，重新定義會悄無聲息地改寫歷史記錄，導致上個季度的 number 資料無法再複製。有了它，每個指標都帶有其來源信息，因此您可以回答審計人員和首席財務官真正提出的問題——不僅僅是“什麼是number”，而是“在我們報告的日期，number是什麼，依據的是哪個定義”。

一個查詢入口點，租用戶範圍在其外部強制執行

定義的可靠性取決於執行路徑的可靠性。在我們的架構中，所有指標——無論是透過儀表板還是代理工具請求——都透過單一查詢入口點進行解析。人工智慧沒有其他更寬鬆的路徑。副駕駛系統和螢幕上的圖表運行著完全相同的認證邏輯，這正是它們數值不會出現差異的根本原因。

租戶隔離在查詢外部強制執行，而非內部。呼叫方永遠不會提供，也無法影響其所檢視的租用戶資料；作用域由執行層從已認證的上下文中套用。這對於代理來說至關重要，因為它們會以您未編寫腳本的方式組合輸入。如果隔離存在於模型幫助建構的查詢 string 內部，那麼巧妙的提示可能會幹擾它。由於作用域位於查詢外部，因此任何提示（無論是對抗性的還是偶然的）都無法跨越租戶邊界。結果是，答案從建構之初就具有可複現性、租戶隔離性和可審計性。

基於授權的唯讀視圖：模型無法繞過的安全機制

目前企業級人工智慧中最危險的模式是將聊天機器人直接連接到原始資料表。這種做法示範效果可能很漂亮，但會在你無法承受的地方出現問題。一旦獲得表格存取權限，代理程式就可以連接原本不應該連接的數據，提取原本不應該離開來源系統的列，並以三種看似有效但實際上相互矛盾的方式計算指標。你竟然信任一個機率系統會遵守那些僅存在於約定俗成中的邊界。

另一種方法是在模型下方的資料庫中強制執行邊界。我們透過基於授權的唯讀視圖公開認證層。 AI 的憑證只能讀取這些列入白名單的安全視圖，除此之外別無他物——無法存取原始表、寫入路徑或認證範圍之外的列。模型永遠不會看到任何可能被它誘惑而跨越的邊界，因為邊界是資料庫授權，而不是系統提示符號中的一段指令。這正是 NIST AI RMF 1.0 等框架所倡導的那種明確的技術控制：管理並映射 AI 系統的實際存取和資料流，而不是僅僅信任模型的行為。

將代理連接到此介面屬於連接問題，而非重建。為人工儀錶板提供支援的相同認證層透過 MCP 工具和 SoCode 向代理開放，因此代理基於認證指標進行推理，而非原始表格。人工智慧無法憑空捏造數據，因為它根本不產生數據——它向該層發出請求，而該層返回認證的 number。

共享層如何確保無程式碼創作的安全性

自助服務聽起來像是一種治理風險：為業務用戶提供一個指標建立器，他們肯定會透過其他方式創建相同的相互衝突的定義。反之亦然，前提是建造者位於經過認證的層之上。無程式碼和結構化指標創作讓使用者可以在白名單安全視圖上編寫新指標（選擇經過認證的維度、篩選器和聚合），而無需編寫原始 SQL，也無需觸及基底表。

由於每個自訂指標都由已建立的、經過治理的模組組成，因此其安全屬性得以繼承，無需重新評估。新指標與已認證的指標一樣，具有租戶範圍、可復現性和可審計性：它們透過相同的入口點、相同的視圖、在相同的授權下運作。治理不再是阻礙使用者速度的障礙，而是成為讓更多使用者安全建置的基礎。這是唯一一種能夠在不重新分散定義的情況下實現規模化的自助服務模式。

首席資料長 (CDO) 的實際職責

如果你是首席資料長 (CDO)，正在建立 AI 分析層，請克制住從聊天機器人入手的衝動。聊天機器人雖然看似簡單，卻是最危險的部分。首先要從詞彙表入手。明確你的核心指標－定義它們，指定負責人，並進行版本控制。將它們置於一個統一的查詢入口點之後，該入口點能夠從外部強制執行租戶範圍限制。透過基於授權的唯讀視圖公開這些指標。只有這樣，才能透過類似 MCP 的工具將代理連接到這個受控介面。按照這個順序操作，AI 從一開始就值得信賴，因為它沒有任何可以隨意猜測的對象。

這不是理論探討。那些利用人工智慧實現客戶留存閉環的品牌，其代理商和控制面板都已實現無縫對接——例如，McDonald's China 與 SocialHub.AI 合作，將會員 GMV 佔比從 5% 提升至 85%。如此規模的成果只有在資料經過驗證、可複現，且對於查看控制面板的人員和執行操作的代理而言一致時，才具有可信度。

這個論點可以用一句話概括：工具是動詞，語意層是詞彙，你需要一套詞彙來服務兩個受眾，這樣無論使用者或客服人員提出問題，number 的意思都相同。如果您正在建立 AI 分析層，並想了解經過認證、租戶隔離且可審計的指標如何為儀錶板和客服人員提供來自同一資料來源的支持，請預約演示，我們將根據您提供的定義，指導您的團隊完成演示。