微软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）的组合，构成了差异化壁垒。竞争对手要在同等体验上追赶，需要补齐的不只是一项技术，而是一整套数据基建。

一个值得观察的变量：当业务用户习惯用自然语言获取洞察后，对"实时性"的期望会被永久抬高。今天的"三天等待"明天会变成"三秒太慢"——这种期望通胀，可能是数据智能体带来的最深远影响。