微軟Fabric數據智能體：用大白話問數據，3天變3秒

如果你見過業務分析師為了"上季度營收前10的產品是什么"這種簡單問題，在數據團隊門外干等三天——你就知道決策是怎么被拖死的。從產生疑問到獲得洞察之間的時差，就是機會流失的黑洞。

微軟Fabric數據智能體（目前處于預覽階段）正是為填平這個鴻溝而生。它讓組織內任何人都能用大白話向企業數據提問，獲得結構化、準確的答案——無需懂SQL、DAX或KQL。

這東西到底是什么？底層怎么運轉？上手需要知道什么？我們逐層拆解。

【它是什么：對話式問答系統】

Fabric數據智能體是架設在微軟Fabric OneLake數據之上的對話式問答系統。它調用大語言模型——具體是Azure OpenAI的Assistant API——來理解自然語言問題，并將其轉譯成針對真實數據源的查詢。

可以把它理解為一個智能中介，干四件事：聽懂你的問題、判斷哪個數據源最適合回答、生成并執行正確的查詢、返回人類可讀的答案。

它能連接的數據源包括：數據湖倉（lakehouse）、數據倉庫、Power BI語義模型、KQL數據庫、本體知識庫，以及Microsoft Graph——全部在受管控的Fabric生態內運轉。

在微軟Fabric更廣泛的智能體架構中，數據智能體扮演對話式分析組件的角色，通過多種數據源類型接入受管控數據，服務于多智能體解決方案。

【底層機制：四步流水線】

所謂"魔法"，其實是一套精心編排的流程：

第一步：問題解析與校驗

用戶提交問題后，智能體調用Azure OpenAI Assistant API進行處理。但在做任何事之前，它先檢查三項：安全協議、負責任AI（RAI）策略、請求用戶的權限。

關鍵限制：智能體對所有數據源僅有只讀權限——不能寫入、修改或刪除任何數據。

第二步：數據源識別

智能體用你的憑證訪問可用數據源的schema（不是數據本身）。它將你的問題與所有已連接源進行匹配，判定哪個源最適合回答。你還可以添加自定義指令來引導路由——例如："財務指標類問題導向Power BI語義模型；原始數據探索導向數據湖倉。"

第三步：查詢生成

確定數據源后，智能體調用對應的翻譯工具生成查詢：

? 數據湖倉/倉庫 → NL2SQL（自然語言轉SQL）

? Power BI語義模型 → NL2DAX（自然語言轉DAX）

? KQL數據庫 → NL2KQL（自然語言轉KQL）

? Microsoft Graph → Graph API查詢

第四步：查詢校驗與執行

生成的查詢先經過正確性與安全合規校驗，再對數據源執行。結果被格式化為人類可讀的響應——表格、摘要、關鍵洞察。

【核心設計：安全與管控優先】

這套系統的架構處處體現"先鎖門再開窗"的思路。只讀權限是硬約束，從源頭上消除數據被意外篡改的風險。權限校驗發生在問題解析階段，意味著未授權用戶連問題都提交不進去，更看不到任何數據schema。

負責任AI策略的嵌入也值得關注——不是事后補丁，而是流程前置。這與微軟在AI倫理上的公開立場一致，但具體執行細節（比如RAI策略包含哪些條款）原文未展開，此處不做推測。

【實際意義：誰的工作會被改變】

最直接的沖擊對象是數據團隊與業務分析師的協作模式。傳統流程中，業務方提需求→數據團隊排期→寫查詢→交付結果，周期以天計。智能體把這個循環壓縮到秒級，但代價是數據團隊需要前置投入：數據源必須預先接入OneLake、schema必須清晰可理解、權限體系必須梳理清楚。

另一個隱性成本是"自定義指令"的維護。路由規則寫得越精細，智能體的判斷越準確；但業務邏輯變化時，這些指令也需要同步更新。這創造了一類新工作：不是寫SQL，而是調教智能體如何選SQL。

【上手門檻與現狀】

目前處于預覽階段，意味著功能未定型、服務等級協議（SLA）未承諾。企業用戶需要評估的是：現有數據是否已沉淀在Fabric生態內？OneLake中的數據源覆蓋度是否足夠支撐日常問答？權限模型是否與組織架構對齊？

技術實現上，NL2SQL/NL2DAX/NL2KQL并非微軟獨有，但深度整合進統一數據平臺（OneLake）+ 統一身份體系（Microsoft Entra）+ 統一AI服務（Azure OpenAI）的組合，構成了差異化壁壘。競爭對手要在同等體驗上追趕，需要補齊的不只是一項技術，而是一整套數據基建。

一個值得觀察的變量：當業務用戶習慣用自然語言獲取洞察后，對"實時性"的期望會被永久抬高。今天的"三天等待"明天會變成"三秒太慢"——這種期望通脹，可能是數據智能體帶來的最深遠影響。