SocialHub.AI
開發者中心 - 資料架構

資料到智能架構

從原始資料到智慧體驅動的決策——資料透過適配器、零拷貝聯合和收集器匯入;以原始資料形式儲存在 SQL 和 MPP 上;抽象化為事件、使用者畫像、指標和關係;然後透過本體與 AI 智慧體連接。

接收商店摘要決策
專為 AI 應用而構建

為什麼人工智慧代理的四個層面至關重要

代理的性能取決於其推理的上下文。將資料攝取、原始儲存、抽象化和本體分離,可以為模型提供清晰、可控且相互連接的接口,使其決策有理有據、易於解釋且易於迭代。

代理程式讀取上下文,而非原始資料行

每一層都為代理人提供一個穩定的介面──事件、檔案、受管控的指標、關聯的本體。它基於上下文進行推理,而不是在推理時解析和連接原始記錄,這使得其答案具有可重複性。

獨立於來源的攝取

因為資料收集是一個獨立的層,所以模型永遠不會依賴系統的連接方式。新增適配器、就地聯合資料倉儲,或透過開放的 API 推播資料-以上所有方式都使用相同的資料格式,因此新資料來源不會影響您的提示或邏輯。

統一的底層架構

SQL 和 MPP 儲存空間透過變更資料擷取保持一致,因此代理程式的上下文由單一的原始資料支持,而不是由相互矛盾的副本支援。操作讀取和大型分析掃描看到的記錄相同。

受監管的商業真相

指標在語義層中具有權威定義,因此代理操作的資料與您的儀表板顯示的資料一致。決策保持可解釋性和可審計性,而不是依賴臨時聚合。

明確的、可追蹤的關聯關係

本體將意圖、使用者畫像和商業價值關聯起來,因此可以追溯推薦的確切上下文——這些關係存在於模型中,無需代理在每次通話中重新推導。

可安全升級

在穩定的層級合約下,切換模型、新增資料來源或變更儲存。代理程式持續使用相同的抽象概念,因此其頂層智慧無需底層重寫即可不斷演進。

四層

從原始資料到互聯本體

每一層都為其上一層提供更清晰、更規範的介面——從資料攝取、原始儲存、抽象,到人工智慧所依賴的本體——因此,頂層的智慧無需底層程式碼重寫即可演進。

2

原始資料層

攝取原始資料並將其儲存在 SQL 和 MPP 資料庫中,實現即時 CDC 同步。

探索此層 →
4

本體-動作層

透過使用者實體模型關聯意圖、使用者畫像和業務,並支援代理驅動的決策。

探索此層 →
一個訊號,端到端

如何將單一操作轉化為決策

運動中的各層更容易看到。這是一個貫穿所有四個的零售訊號——從原始點擊到代理商的下一個最佳行動。

1攝取

購物者的行為發生

一位會員三次瀏覽同一件夾克並將其添加到購物車,然後未購買就離開了。這些瀏覽和購物車事件會透過追蹤收集器收集,並與已連接的商務和 CRM 系統的訂單歷史記錄一起顯示。

2原始資料儲存庫

一切都如實呈現

事件和記錄會同時以原始資料的形式寫入 SQL 和 MPP 存儲,並透過變更資料擷取保持同步—因此相同的資訊既可用於操作查詢,也可用於大規模分析掃描。

3抽象

原始數據轉化為意義

事件模型將「重複瀏覽 + 購物車,但未購買」解讀為高意圖訊號;標籤將她標記為即將流失的高價值會員;指標層已經知道她的終身價值和兌換率——每個都有各自的定義。

4本體-行動

由代理決定

本體將她的意圖、畫像和價值整合為一個完整的圖像。代理讀取此上下文,並製定個性化的挽回策略,同時提供有限的激勵措施——該決策可以追溯到其背後的確切信號。

高性能與可擴展性
資料安全與合規
開放且可擴展的架構
即時智能分析
面向技術領導者

決定架構的問題

如果我們採用您的語意層和本體進行標準化,如何避免被鎖定?

這些層級是契約,而非黑盒。您的原始資料保留在標準的 SQL 和 MPP 儲存中—或透過零拷貝儲存在您自己的資料倉儲中(我們絕不要求您複製資料)—您的指標、標籤和識別定義是聲明式的、版本化的,並且可以以您控制的形式匯出。您保留資料和定義;抽象層位於開放的儲存中,而不是將它們限制在專有格式中。

我們的資料實際儲存在哪裡?哪些資料會透過零拷貝聯合技術跨越邊界?

對於聯合資料來源,查詢會被下推到您的資料倉儲(Snowflake、Databricks、Salesforce Data Cloud 或 Delta Sharing),並根據您指定的憑證進行就地讀取;原始表永遠不會被複製到我們的儲存中,因此您的資料倉儲仍然是記錄系統,其駐留和存取控制仍然有效。離開您邊界的是經過範圍限定的查詢結果,而不是底層表。攝取的資料來源會進入租戶隔離的存儲,並且同意和隱私狀態會進行版本控制,以便受監管的資料能夠按照策略進行處理,而不是臨時處理。

誰來控制指標的涵義?如何管理數千用戶的指標?

指標定義位於一個統一的語意層,而不是分散在儀錶板和筆記本中。每個定義都有所有者;認證指標需要所有者簽字確認;變更會經過審核並進行版本控制,並帶有審計跟踪,同時還會使自身的緩存失效,從而避免過時的數據長期存在。這正是防止組織層級出現「同一KPI,三種不同答案」問題的關鍵所在。

我們的資料如何與其他租戶的資料隔離?單一漏洞的影響範圍有多大?

租用戶範圍在資料路徑中強制執行,而不是由應用程式程式碼記住過濾器。指標和設定檔存取權限僅針對租用戶範圍的合約檢視進行唯讀操作-這層安全性屏障會在任何查詢存取行之前按租用戶進行篩選-因此即使是自訂查詢也無法存取其他租用戶的資料或原始資料表。由於隔離性取決於查詢路徑而非每個開發人員的技能,因此一個應用程式錯誤不會導致跨租戶風險。

當代理執行操作時,我們如何對其進行審核和約束?

每個智能體的操作都基於受控抽象和本體,因此,每個決策都可以追溯到其所使用的確切意圖、使用者畫像和指標上下文,而不是晦澀難懂的提示。智能體可以執行的寫入操作受到伺服器端防護措施和速率限制的限制,一旦超出限制,敏感操作(例如激勵或支出)可能需要人工審批,並且每個操作都會被記錄以供審計。智能體基於您設定的可靠資訊進行推理,並保持可審查性,而不是基於任何人都無法重構的上下文進行操作。

五年內,分層架構的擁有成本為何比我們的倉庫加點解決方案更低?

倉庫加積分工具堆疊的持續成本在於整合和協調:每個新資料來源都是一個客製化管道,每個工具都會重新定義指標和身份,而您的團隊需要維護它們之間的一致性。將資料攝取、儲存、抽象化和本體分離意味著資料來源只需連接一次,指標只需定義一次,身份只需解析一次——以上所有環節都可以重複使用。您用單一的底層架構和一套統一的定義,取代了日益繁雜且脆弱的整合和相互衝突的定義。

開發者須知

建構基於互聯情境的系統,而非原始管道。

透過適配器、零拷貝聯合、追蹤收集器和開放的 API/SDK 攝取資料;將原始資料儲存到 CDC 同步的 SQL 和 MPP 儲存中;將其抽象化為事件模型、時間軸、設定檔和指標;然後透過使用者實體模型將其連結起來,以便代理根據連接的上下文做出決策。

相關:平台循環和網路追蹤SDK。