数据智能体是什么及其核心应用解析

在微软工作，让我有机会接触到许多前沿的AI分析工具，其中就包括Microsoft Fabric的数据袋里。这促使我想与大家分享我的理解：究竟什么是数据袋里，以及它与“标准”AI袋里有何不同。

开门见山，我对数据袋里的定义是：

数据袋里，是一个你可以与之对话的报告。

对于数据分析领域的同行而言，这意味着两个长久以来的愿望可能即将实现：

第一， 分析师花费在构建可视化图表上的时间将大幅减少。
第二， 自助式洞察将更贴近业务用户。

我们来详细聊聊这两点。

更少的可视化，而非更少的洞察

一份优秀的报告，能清晰地告诉我当前所关注指标的状况，这当然很棒。但作为一名数据分析师，我也深知报告有时会误导对指标的解读，这常常导致业务用户在重要会议前十分钟，急匆匆地来找分析师询问KPI的含义。

这也部分解释了为何我们时常陷入一种恶性循环：精心打造的仪表板无人问津，而利益相关者却总是临时索要“那个数字”，通常以特制报表或电子表格的形式呈现。

好消息是，可视化图表和电子表格并不会消失，但通过Fabric数据袋里，我们有了全新的方式来交付洞察。

与其将查询结果封装成图表，不如将它们与Fabric中治理就绪的数据资产（如湖仓、数据仓库、Power BI语义模型、KQL数据库甚至本体）相结合，并通过提示词和指令进行封装。这意味着，要回答诸如“本周收入与上周相比如何？”这类业务问题，底层数据仍需进行准备和建模。

然而，从设计角度看，你不再需要为回答这个业务问题而创建一个特定范围的可视化报告，取而代之的是创建一个特定范围的数据袋里。这个袋里能够提供此答案，以及从底层数据模型衍生出的其他子集答案。

更具体地说，其输入输出流程如下：
(1) 利益相关者提出问题；
(2) 由Azure OpenAI助手API驱动的袋里，根据数据源模式及其指令集解读问题，并“决定”哪个数据源最有可能包含答案；
(3) 生成相应的查询语句（根据源类型可能是SQL、DAX或KQL）；
(4) 验证查询；
(5) 在提问者的凭证权限下执行查询；
(6) 以文本或表格形式返回结果（目前尚非可视化形式）。

总而言之，利益相关者通过数据袋里获取洞察的过程，本质上是在已治理的数据集上进行的一场问答会话。以往需要通过下钻图表才能获得的信息，现在可以通过后续追问来获得，例如：“能否按细分市场对收入进行拆分？”

由此可见，分析师的工作成果，不再仅仅需要通过仪表板来呈现——而仪表板，长久以来只是数据模型中蕴含的业务逻辑得以交付的一种有形证明。

自助式洞察，贴近业务用户的“主场”

前面提到报告有时会曲解指标，但这并非“建好即用”模式在报告或分析领域屡屡受挫的唯一原因。事实上，理解底层语义模型以及如何使用BI工具在其基础上创建可视化，对很多人来说门槛过高。

这固然指向数据素养问题，属于变革管理的范畴，但一个不争的事实是：目标业务受众，即本应是报告的使用者，往往事务繁忙，无暇为了自助分析而去学习复杂的BI工具。

因此，将洞察交付到终端用户日常工作的“主场”就显得至关重要，而在当下，这通常指向像M365 Copilot这样的AI赋能工具。

通过将数据袋里的洞察能力输出到Fabric之外，分析师现在可以专注于自助式数据袋里背后的分析逻辑，而终端用户则可以在处理其他日常任务的同一AI工具中获取洞察，无需切换到另一个复杂平台。

需要说明的是，这并非将Fabric数据袋里集成到工作流中的唯一方式。无论你是开发者还是消费者，了解下面这一点都很有帮助……

数据袋里与AI袋里的区别

到目前为止，我们了解到Fabric数据袋里是一种专注于只读、受治理数据访问的分析袋里，能够将自然语言提示转换为复杂的数据库查询，从而解锁洞察，甚至可以在Fabric租户之外工作。

另一方面，AI袋里的定义则是一个系统，它使大语言模型能够代表用户或其他系统“做事”，而不仅仅是响应提示，其方式是调用各种工具和知识。

这意味着，整个魔力在于AI袋里的架构设计。你可以在其中将Fabric数据袋里作为一个专门的工具或知识源来使用。

举一个简单的例子来说明。

假设一位授权用户请求AI袋里：“起草一封邮件给团队，总结上周各细分市场的收入情况。”为了完成这项工作，AI袋里需要（除其他事项外）从企业数据库中准备收入洞察数据。因此，为了减少收入计算中的错误，开发者可以设计一个智能工作流，将输入提示路由到Fabric数据袋里工具。数据袋里将负责繁重的工作：确定数据模式、编写查询、执行查询并返回精确数字。最后，AI袋里再利用这些数字来完成其更广泛的工作流程，并撰写邮件。

那么，两者的核心区别是什么？简而言之，AI袋里负责“行动”，而数据袋里负责“奠基”。