企業人工智能面臨一個無人願意提及的生產難題：缺乏上下文層

問題不在於模型，也不在於數據，而在於你的人工智能根本不知道你的數據究竟意味着什麼。

問問任何一家企業人工智能團隊，他們遇到的阻礙是什麼，你都會得到一個比較委婉的説法：「我們正在擴大試點規模。」「我們正在努力提高數據質量。」「我們需要更好的管理。」

他們的真實意思是：人工智能會根據提問者是誰、訪問的是哪張桌子以及當天是星期幾給出不同的答案。而且沒有人足夠信任它，讓它去做任何重要的事情。

這不是模型問題，也不是數據問題，而是意義問題。數據就在那里，可以訪問，也相互關聯。但使用這些數據的AI卻完全不明白，在企業實際運營的背景下，這些數據究竟意味着什麼。

「收入」一詞在三個不同的表格中以三種不同的方式定義。「活躍用户」對產品團隊而言是指每日登錄用户，對增長團隊而言是指過去 30 天內的任意會話用户。「客户」包括 Salesforce 中的試用帳户，但不包括計費系統中的試用帳户。這一列rev_adj_v2_final只有四年前創建它的分析師才覺得有意義。她兩年前就離職了。

人工智能對這些一無所知。它只是隨便選一張表，然后自信滿滿地給出一個數字。還附帶一張圖表。

每個人都在解決錯誤的問題

過去兩年，業界一直在努力構建更完善的基礎設施，包括更強大的連接器、更高效的文本轉SQL系統、更智能的代理和更優秀的模型。數十億美元的投入旨在解決企業級人工智能面臨的難題：如何讓人工智能訪問數據。

並非如此。難點在於如何讓人工智能理解接收到的數據的含義。

現在，各大數據平臺都提供「數據人工智能」服務。對於基於清晰星型模式的演示級問題，這項服務確實有效。「我們昨天處理了多少訂單？」 當然可以。

但企業並非基於清晰的模式運行。（如果你的企業確實如此，恭喜你，你可以不用往下看了。）

他們的運作方式自相矛盾。季度中途更改收入確認規則。三個部門對「客户流失」的定義各不相同。數據團隊早已不復存在，而列名卻成了內部笑話。業務邏輯存在於Slack聊天記錄、無人維護的Confluence頁面中，而分析師主管們隨時可能辭職，帶走公司的全部機構知識。

一旦你完成了演示問題，那種「直接連接數據」的方法並不會報錯，而是會給你一個看似合理卻錯誤的答案。而這一點卻鮮為人知：每一個錯誤的答案不僅僅浪費時間，它還會讓你的組織認為人工智能行不通。這種信任的喪失比任何技術問題都更難挽回。

三個用例，一個缺失的層

目前，所有企業都在追求相同的三個人工智能應用場景。每一個場景都需要比前一個場景更深入的數據理解。而一旦缺乏這種理解，每一個場景都會遭遇更大的失敗。

使用案例 1：與您的數據聊天

業務用户希望用自然語言提問，而不是向分析團隊提交工單。「上個月有多少患者被確診並接受了這種藥物治療？」「我們第四季度企業客户的留存率是多少？」

大多數公司都從這里起步，問題也最先出現在這里。人工智能不知道該用哪個「留存率」的定義，哪個表纔是規範表，也不知道「第四季度」指的是日曆季度還是財政季度。缺乏這些上下文信息，人工智能結合數據查詢的準確率徘徊在20%到30%左右。模型本身並不差，它只是在猜測哪些數據代表什麼，而且大多數時候都是錯誤的。

用例 2：AI 驅動的工作流程

企業希望實現實際流程的自動化：審覈表單、路由請求、驗證信息、基於數據做出決策。而在這里，錯誤的答案不再僅僅是尷尬，而是代價高昂。

如果一個工作流程因為上個月業務規則的變更而觸發了錯誤的操作，它不會生成錯誤的圖表。它會錯誤地處理索賠，將審批發送給錯誤的人，並標記錯誤的賬户進行審覈。而且沒有人發現這個問題，因為自動化的意義就在於無需人工監控每個步驟。（這 相當於企業人工智能版的「在我的機器上運行正常」。）三周后，數據團隊纔在Slack上收到一條驚慌失措的消息，有人發現數據對不上。

用例 3：人工智能代理

前沿領域。能夠推理、決策和行動的智能體：觸發系統、調用工具、執行多步驟工作流程。在這里，數據理解問題演變成了安全問題。

設想一個簡單的客服工作流程：「標記續約風險高的客户」。客服人員需要了解「高風險」的定義（該定義六周前已更改）。他們需要知道哪些客户關係管理 (CRM) 字段是最新的，哪些是過時的。他們還需要知道，流失模型ml_predictions僅涵蓋企業客户，不涵蓋中小企業客户。任何一個環節出錯，都可能導致客服團隊被大量誤報淹沒，或者錯過真正需要關注的客户。

如果一個智能體不知道該信任哪些數據，也不知道該遵循哪些規則，那麼它要麼事事都向人類尋求幫助（這違背了智能體的初衷），要麼基於錯誤的假設行事，造成實際損害。沒有安全的中間路線。

聊天需要人工驗證答案。工作流要求答案無需人工檢查即可正確無誤。智能代理則要求人工智能知道它不知道什麼。每個層級都對數據理解提出了更高的要求，而當前的基礎設施幾乎無法提供這種能力。

在這三者中，企業都遇到了同樣的瓶頸。數據團隊成了所有人工智能項目的瓶頸，他們手動將業務問題轉化為正確的查詢，維護着其他人無法維護的定義，並且不斷收到高管們同樣的沮喪反饋：「為什麼就是不行？」

堆棧中缺失的層

現代數據棧中存在一個尚未被填補的空白。

數據如下：存儲和計算問題已解決。Snowflake、Databricks、BigQuery。數萬億行數據，亞秒級查詢。完成。

以上是數據：人工智能模型已完成。GPT-4、Claude、Gemini 以及其他開源替代方案。它們可以編寫 SQL、分析結果並生成摘要。完成。

數據與人工智能之間：沒有關係。

這纔是業務意義的所在。它包含了定義、關係、規則和上下文，這些要素將原始表格轉化為人工智能系統能夠可靠推理的內容。

像Solid這樣的公司稱之為上下文層，無論你使用什麼工具，這種框架都很有用。它不是儀表盤，也不是數據目錄（你的公司肯定有數據目錄，但上次更新是什麼時候？）。它也不是傳統意義上的BI語義層，儘管兩者有相似之處。

傳統的語義層是為儀表盤服務的。它將業務術語映射到 SQL 查詢，以便 Looker 或 Tableau 能夠生成正確的圖表。雖然有用，但它是靜態的，需要人工維護，並且是為人類消費數據的時代而設計的。上下文層則是為人工智能消費數據的時代而構建的。它需要具備機器可讀性，持續維護，並且足夠智能，能夠理解首席財務官和產品團隊提出的「收入」概念的含義不同。

人們已經嘗試構建這方面的部分功能。dbt 的語義層和 Cube 之類的工具允許你將指標定義為代碼，對其進行版本控制，並將其提供給下游使用。這確實是進步，如果你已經擁有完善的數據工程實踐，那麼這些工具值得使用。但它們解決了定義問題，卻沒有解決發現和維護問題。你仍然需要有人瞭解哪些指標存在、它們之間有何關聯以及它們何時發生了偏差。在一個擁有數百個表和數十個模型的公司里，這樣的人並不存在。

手動方法（僱傭分析師、編寫文檔、維護維基）在小規模下行得通。但在企業級規模下，文檔編寫工作量會隨着數據複雜性的增加而線性增長，而維護團隊的人員卻保持不變。幾周之內，定義就開始出現偏差。新員工查閲維基，發現其中的矛盾之處，於是開始維護他們自己的「影子定義」。一年之內，你就會面臨與最初相同的碎片化問題，只不過現在還多了一個過時的維基，而每個人都把責任推卸給它。

一直以來，我們所缺少的是一個不僅定義語義，而且還能隨着業務變化主動發現、生成、測試和維護語義的平臺。

實際運作是什麼樣的

這就引出了Solid。

Solid 位於人工智能系統和企業數據之間的執行路徑上。它無需數據團隊手動構建和維護語義模型，而是分析數據在整個組織中的實際使用情況：查詢模式、BI 定義、數據庫模型、文檔、Slack 對話等。基於這些信號，它生成語義模型，捕捉數據的含義及其關聯方式。

假設一家公司的數據倉庫中有 200 個表和 40 個語義模型。如果採用人工維護，這些模型大約只能維持三個月的準確性，之后就會出現偏差：表名更改、業務邏輯變更、新增字段，而且沒有人更新文檔。Solid 會監控底層數據和使用模式，並在情況發生變化時自動更新模型。

它還處理了一個比大多數人意識到的更重要的功能：上下文管理。當人工智能系統查詢「收入」時，上下文層會根據提問者的不同而知道應該應用哪個定義。財務部門會得到GAAP收入，產品部門會得到MRR（月度經常性收入），董事會會得到董事會批准的數字。同樣的詞語，不同的正確答案。而且，它還能與現有工具（Snowflake Cortex、Databricks Genie、ChatGPT、dbt）集成，而無需您徹底改造現有技術棧。

它無法解決的問題：那20%的業務邏輯過於複雜、過於依賴上下文，或者過於特殊， 無法實現自動化。（比如「我們之所以這樣計算，是因為2019年的那次收購」之類的。）Solid 的平臺結合了實踐經驗，彌補了這一缺口。我欣賞他們坦誠面對自動化的侷限性，而不是假裝完全自動化是可能的。

SurveyMonkey 是 Solid 的一家生產客户，它從數據團隊中數十個獨立的業務邏輯定義，轉變為一個經過驗證的單一數據源，AI 查詢可以基於該數據源運行。

Solid 報告的數據顯示：人工智能加數據查詢的準確率從 20-30% 提升至 85% 以上；人工語義維護工作量減少 50-70%；部署周期從 1-2 年縮短至 3-6 個月。這些數據未經獨立驗證。但其發展趨勢與我從投資於各種形式結構化業務上下文的數據團隊那里瞭解到的情況相符。

等待的真正代價

我認為大多數公司在這個問題上犯的錯誤是：他們把這個問題當作優化問題，認為應該在人工智能運行正常后再解決。但如果沒有這個問題，人工智能根本無法運行。每個月你都花費大量時間在模糊不清的數據上開發人工智能功能，這不僅僅是在積累技術債務，更是在讓你的組織相信人工智能是不可靠的。

這種想法是毒藥。一旦首席財務官從人工智能助手那里得到錯誤的數字，他們就會停止使用它。一旦工作流程產生了不良結果，團隊就會轉而採用人工操作。一旦高管得出結論「人工智能還無法處理我們的數據」，那麼想要獲得修復預算就難上加難了。我在多家公司都親眼目睹過這種情況。技術問題是可以解決的，但組織信任問題卻無法解決，至少在合理的時間範圍內無法解決。

看看這個模式。每一次企業技術的重大變革都需要一個基礎層，而這個基礎層往往因為不夠吸引人而無人問津。數據庫需要模式，API 需要文檔，雲服務需要身份和訪問管理 (IAM)。每一次，炫酷的應用層都吸引了所有人的目光，而那些忽略基礎層的團隊卻為此付出了多年的代價。

上下文層是企業級人工智能的基礎。現在構建上下文層的公司將積累優勢，因為隨着底層數據的理解加深，每一個新的模型、代理框架和工作流自動化都將運行得更好。

那些跳過這一步的人會不斷詢問他們的數據團隊，為什麼人工智能對同一個問題會給出不同的答案。

Solid 的創始人將「語義工程師」視為一個新興角色：負責機器如何解讀業務數據的人員。無論這最終會成為一個正式的職位，還是僅僅成為數據分析師本已繁重工作職責中的又一項內容，這項職能都不可或缺。必須有人負責語義層面。而目前，在大多數公司里，沒有人承擔這項工作。

本文來自微信公眾號「數據驅動智能」（ID：Data_0101），作者：曉曉，36氪經授權發佈。