如果企业已经花了多年时间建设 Power BI 报表、语义模型和指标体系，为什么引入 AI 之后，还要让它从头猜一遍企业的数据？
这是我们最近做 Power BI 与 Data Agent 结合时，反复在想的一个问题。
这两年，国内外 Data Agent 产品发展很快。自然语言问数、自动生成图表、AI 写分析报告，已经不算新鲜事。但对长期做 Power BI 开发和数据分析的人来说，更值得问的是：企业已经花了很多时间建设语义模型，定义了度量值、维度和模型关系，AI 到底能不能真正用好这些成果？
示意图：企业多年积累的报表与数据资产，本身已经是一套可复用的分析基础。
以 Power BI 语义模型为基础，把指标语义、模型本体、统一业务本体和 Graph 图谱逐层组织起来，AI 才不只会查指标，还能理解指标背后的业务。
这篇文章讲的是智能小V 的技术路线，不是一份功能清单。文中示意图为能力示意，实际效果与项目里的模型治理程度直接相关。
Power BI 最有价值的地方，不只是把数据做成报表，而是通过语义模型，把原本分散的数据、指标和业务关系整理成一套可以复用的分析体系。
一个成熟的 Power BI 语义模型，通常已经包含下面这些内容：
| 语义模型里已沉淀的内容 | 对 AI 问数的意义 |
|---|---|
| 企业确认过的度量值与计算逻辑 | 优先调用已有口径，不必自己推公式 |
| 客户、产品、门店、区域等维度 | 决定结果能按什么切分查看 |
| 表与表之间的业务关系 | 决定跨对象的问题能不能走通 |
| 时间智能与复杂 DAX 计算 | 同环比、累计等不用重新写一遍 |
| 业务名称、描述与指标口径 | 遇到歧义词时有据可依 |
| 数据访问权限 | 可见范围有约束，不越界 |
这些内容不是自动就有的。通常需要数据分析师和 BI 开发人员反复梳理、验证，才慢慢沉淀下来。
过去，这些成果主要用来支撑报表和自助分析。现在有了 Data Agent，更值得思考的是：能不能让 AI 也站在这套已经建立起来的语义基础上工作，而不是每问一次就重新猜一遍指标和计算方式。
更合理的做法是优先使用企业已经定义好的度量值；确实需要组合计算时，再根据真实模型结构生成相应的 DAX 查询，而不是脱离模型另起一套口径。
在企业 Data Agent 项目里，一个很现实的情况是：一个 Power BI 模型里可能有几百个度量值，既有正式经营指标，也有中间计算度量值、历史遗留度量值和各种技术辅助度量值。
把它们不加区分地全部交给 AI，并不是模型越开放，效果就越好。模型越大、命名越复杂，AI 越容易选错指标，或者把相似名称背后的不同口径混在一起。
所以在开展 AI 问数之前，有必要先把模型本身梳理一遍：
| 要先回答的问题 | 不梳理会怎样 |
|---|---|
| 哪些度量值是正式业务指标？ | 中间计算与辅助度量值混在指标列表里，AI 分辨不出主次 |
| 哪些维度适合用于经营分析？ | 几百个字段平铺，缺少层级与业务含义，切分时随手乱选 |
| 哪些计算字段已经失去使用价值？ | 历史遗留字段仍留在模型里，误选概率随字段数上升 |
| 哪些指标需要补充业务说明？ | 只有名字没有口径，同名指标指向不同算法 |
| 哪些指标存在相似名称但不同口径？ | 「销售额」在两张表里算法不一致，答案互相矛盾 |
智能小V 不只是要让 AI 找到一个指标，更要尽量让它选对指标，也支持把无用指标拦截在本体之外。
通过指标语义、维度扩展、业务术语和知识库，把企业内部的表达与模型里的真实对象对应起来。比如业务人员说「有效客户」「重点产品」或「库存积压」，AI 需要知道这些词在这家企业里具体指什么、按什么规则判断，而不是只凭字段名称相似就做选择。
治理得好的 Power BI 模型，价值不应该止步于报表，也可以成为企业 AI 长期利用的业务资产。
但如果 AI 只认识度量值和维度，还谈不上真正理解企业业务。同样是问一句，问题落在哪一层，差别很大：
| 用户的提问 | 实际涉及的能力 |
|---|---|
| 销售额是多少？ | 指标查询 |
| 哪些产品销售下降了？ | 指标与业务对象结合的分析 |
| 为什么这些产品销售下降，同时库存却在增加？ | 多个业务对象及其之间的关系 |
这也是智能小V 把原有的指标语义能力，进一步扩展到模型本体（Model Ontology）的原因。
示意图：多个语义模型之上是业务本体层，通过统一业务本体与 Graph 图谱连接，支撑上层的经营分析、智能问数、管理报告与风险预警。
在智能小V 中，模型本体会把一个语义模型里的业务概念进一步组织起来，包括四类：
| 组成部分 | 举例 | 解决什么 |
|---|---|---|
| 实体类型 | 客户、产品、订单、门店 | 定义有哪些业务对象 |
| 属性 | 编码、名称、日期、状态 | 描述对象自身的特征 |
| 关系 | 不同业务对象之间的联系 | 支持跨对象的分析 |
| 指标 | 销售额、利润、库存周转率 | 挂到对象上计算与解释 |
这样，AI 面对的就不只是度量值名称和字段列表。它还需要理解：这个属性属于哪个业务对象？这个指标描述什么业务？适合按哪些维度分析？它与模型中的其他对象有什么关系？
例如在销售模型中，产品、订单、门店和客户之间的业务联系，可以通过模型本体表达得更清楚。
大部分企业往往有多个 Power BI 语义模型。销售、库存、财务、供应商、客户服务等领域，通常各自建设自己的模型和指标体系。但管理者提出经营问题时，并不会按照这些模型的边界来提问。
他不会只问销售模型的问题，也不会只关心库存模型。他真正关心的是：某个产品销售下降，库存有没有增加？供应商是不是出现了交付异常？
这就需要进一步建立统一业务本体，把不同模型中的业务对象放到一个更完整的业务语境里理解。例如销售模型、库存模型、供应商模型里都有 Product，它们来自不同语义模型，却可能指向同一个企业产品。
保留各模型原有的数据结构和指标计算逻辑，再通过业务实体对齐和关系组织，把这些分散的业务概念连接起来。这一步是整条路线里最花功夫的地方，也是很多 AI 问数工具止步的地方。
边界：本体不是另建一套数据仓库。它不搬数据、不重算指标，改的是「业务对象怎么描述、彼此怎么关联」，指标计算仍然留在原来的语义模型里完成。
以一个家居零售场景为例。
示意图：一款产品（产品 A）的销售异常，沿产品实体串起库存状态、库存变化过程与供应履约四条业务线。
管理者发现某款产品最近销售持续下滑，希望进一步了解原因。以往做这类分析，分析人员通常要分别打开销售、库存和供应商报表，再手动核对产品、时间和业务口径，最后把几边的信息拼起来。
智能小V 希望让这个过程衔接得更自然一些。
| 步骤 | 用户的问题 | 小V 做了什么 | 用到的模型 |
|---|---|---|---|
| 发现异常 | 产品 A 最近销售表现怎么样？ | 用已定义好的指标做自然语言理解与 DAX 查询，分析销售额、销量、趋势和门店表现 | 销售模型 |
| 观察库存 | 同期库存怎么样？ | 通过统一的 Product 实体定位库存模型中的同一产品，再用库存已有指标分析 | 销售 + 库存 |
| 深入过程 | 为什么形成这样的库存？ | 不停留在库存余额，继续查看入库、出库、调拨和库存调整等业务记录 | 库存模型 |
| 延伸供应 | 供应端有没有值得关注的问题？ | 沿产品与供应商之间的业务关系，分析交付表现、延期情况和履约变化 | 供应商模型 |
销售结果 → 库存状态 → 库存变化 → 供应履约。
这里真正有价值的，不是 AI 多查了几个模型，而是它能理解不同业务对象之间的联系，并在当前问题还没有解释清楚时，知道可以沿着哪些业务关系继续分析。
边界：销售下降和库存增加同时发生，不代表两者一定存在因果关系。智能小V 需要结合真实业务记录和数据证据，把已经查到的事实、可能相关的线索和仍需验证的推断区分开。
对数据分析师来说，过去要在多个报表之间来回切换、手动寻找关联的工作，有机会变得更连续、更高效。
评价一个 Data Agent，不能只看它回答得快不快、图表做得漂不漂亮。
企业的实际工作往往是连续的。比如一次经营分析，可能从销售问题开始，接着关联库存、追查业务过程、分析供应商情况，最后还要形成报告，并定时推送给相关人员。
如果每一步都要用户重新描述背景、重新组织任务，那它离真正的工作助手还有距离。
示意图：智能小V 基于 Agent Harness 运行架构，把上下文管理、专业 Skill、MCP 工具、任务编排和自动化任务组织起来。
用户面对的是一个统一的智能小V，系统则根据任务需要调用相应能力：
01需要分析数据时，调用专业的数据分析能力。
02需要制作看板或报告时，调用相应的生成 Skill。
03需要连接 ERP 或其他办公系统时，通过 MCP 调用相应工具。
04需要定期分析时，创建自动化任务，按计划执行并推送结果。
这些环节还涉及任务状态、权限边界、执行失败后的处理和结果交付。企业真正使用时，这些看起来不那么炫的基础工作，往往决定了 Agent 能不能长期稳定运行。
一次回答精彩并不难。难的是知道一项工作需要哪些步骤、调用哪些专业能力，并把任务持续推进下去。
悦策长期服务企业 Power BI 项目，接触过不少已经建设多年报表、语义模型、指标体系和数据治理规范的企业。这些积累来之不易，也不应该因为 AI 的到来就被推倒重来。
比较可惜的是，有些企业为了上 AI，又重新搭一套数据和指标体系，结果原来那些经过业务验证的模型、指标和知识反而没有被充分利用。
| 两种做法 | 要付出的代价 | 最终结果 |
|---|---|---|
| 为了上 AI 重搭一套数据与指标体系 | 迁移、重建、再治理，周期通常以季度计 | 旧模型闲置，新体系仍要重新对齐业务 |
| 在现有语义模型上接 AI | 梳理指标、补业务说明、组织本体 | 已有资产直接复用，AI 面对的是验证过的口径 |
更值得走的是一条延续现有数据资产的路线：先让 AI 理解 Power BI 语义模型和指标，再通过模型本体和 Graph 图谱补足业务对象与跨模型关系，最后结合专业 Skill、MCP 和自动化，把分析延伸到报告交付和企业协同。
示意图：能力中心（Skill / MCP / 插件扩展）、分析工作流（理解问题 → 调用语义模型 → DAX 分析 → 推理）、成果交付与自动化协同。
这也是智能小V 与普通 AI 问数工具的一个重要区别：它希望成为的不只是一个能查询 Power BI 数据的助手，而是一个理解模型、指标和业务关系，并能围绕企业经营问题持续开展分析工作的专业 Data Agent。
边界：文中示意图为产品能力示意。实际效果取决于模型治理程度、指标说明完整度与本体组织范围，上线前建议先选一个业务域做小范围验证。
如果你们也在用 Power BI，想知道现有语义模型能怎样接上 AI 问数、多模型业务分析与自动化报告——
拿一个真实业务场景，和智能小V 一起跑一遍。
预约智能小V 演示 →
在线咨询
