如果你问 AI：「上个月哪些客户购买了产品 A？」
这听起来是一个简单的问题。但对数据系统来说，它至少要回答几件不同的事：
•“客户”对应哪张表？
•订单与客户如何关联？
•一笔订单里有哪些产品？
•“上个月”按下单时间还是付款时间计算？
•已取消的订单要不要算进去？
人们习惯用业务语言提问，数据却通常存放在表、字段和各种系统里。两者之间的距离，正是 AI+BI 落地时经常卡住的地方。
Microsoft Fabric 中的 Ontology（本体），试图在这段距离上搭一座桥。
本文依据微软官方对 Ontology 与 Fabric data agent 集成的公开说明整理。该集成目前处于预览阶段，具体能力以最新官方文档和实际环境验证为准。
可以把 Ontology 理解为一份结构化的“业务地图”。
它描述的不只是有哪些数据表，更包括：
•企业关心哪些业务对象，例如客户、订单、产品；
•每个对象有哪些属性，例如客户名称、订单日期、产品类别；
•对象之间是什么关系，例如客户下订单、订单包含产品；
•这些业务概念如何关联到底层数据。
这样，AI 面对的就不再只是 customer_id、order_date 这样的字段名，还能获得一层业务上下文：这些字段代表什么，它们之间有什么联系。
在 Fabric 中，Ontology 可以作为 Fabric data agent（数据代理）的上下文来源。数据代理利用这些上下文理解问题、选择相关的数据源，再生成该数据源支持的查询。
Ontology 提供的是语义，不是执行查询的地方。
换句话说，它回答“AI 该看哪些表、按什么关系看”，不负责“把数字跑出来”。
假设一家企业有三类核心业务对象：
•客户：谁在购买产品。
•订单：客户发生的一次购买。
•产品：订单中购买的具体商品。
它们之间可以这样理解：
客户 → 下单 → 订单 → 包含 → 产品
为了让 AI 能把这些概念与真实数据联系起来，还需要进一步描述属性和数据映射。
| 业务概念 | 常见属性 | 假设对应的底层数据 |
|---|---|---|
| 客户 | 客户编号、客户名称 | 客户表中的客户 ID、名称字段 |
| 订单 | 订单编号、下单日期、状态 | 订单表中的订单 ID、日期、状态字段 |
| 产品 | 产品编号、产品名称、类别 | 产品表中的产品 ID、名称、类别字段 |
| 订单包含产品 | 产品数量、成交金额 | 订单明细表中的订单 ID、产品 ID、数量和金额 |
这里的表和字段只是一个示意。不同企业的数据结构可能不同：有的把订单和订单明细分开，有的还会把退款、促销和渠道放在其他表里。
关键在于，Ontology 帮助我们把业务人员熟悉的“客户、订单、产品”，与数据人员熟悉的表、字段和关联关系连接起来。
业务人员可以继续用业务语言提问，AI 则多了一份理解这些语言的上下文。
还是以同一个问题为例：
上个月哪些客户购买了产品 A？
数据代理可能需要沿着下面的思路处理：
01理解业务对象：问题涉及客户、订单和产品。
02理解对象关系：客户与订单有关联，订单通过明细关联到产品。
03找到相关数据源：根据 Ontology 中的映射和绑定，识别可以回答问题的底层数据。
04生成并执行查询：针对选定的数据源，生成 SQL、KQL 或 DAX 等适用的查询。
05返回结果：将查询结果整理成用户能理解的回答。
例如，假设相关数据都在同一个支持 SQL 的数据源中，查询可能需要连接客户、订单、订单明细和产品数据，再按产品与日期筛选。
这个过程并不意味着 AI 一定会生成正确查询。Ontology 提供的是帮助理解和选择的上下文，最终结果仍取决于业务定义、数据质量、数据源以及生成查询的准确性。
因为很多业务问题，看似明确，实际藏着口径选择。
例如，“购买了产品 A”的客户，到底包含哪些情况？
•下单但未付款，算不算？
•订单后来取消了，算不算？
•产品发生退款，要不要扣除？
•同一客户买了多次，是列出一次，还是按订单逐条列出？
•“上个月”按下单时间、付款时间还是发货时间计算？
Ontology 可以帮助团队记录和表达业务概念，但它无法替代团队对统计口径的确认。即使定义已经存在，也需要检查数据代理是否在此次查询中正确理解并使用了它们。
尤其对于影响经营决策的结果，建议同时看查询和答案。可以从四个方面检查：
查询是否选中了正确的数据源？是否覆盖了需要分析的业务范围？
客户、订单和订单明细是否正确关联？有没有因关联方式导致重复计数或遗漏？
时间范围、订单状态、退款处理和去重方式，是否符合业务要求？
可以抽取几个熟悉的客户或订单，与明细数据或已有报表交叉核对。结果合理只是开始；能解释结果如何得出，才更有助于建立信任。
根据微软官方的说明，Ontology 与 Fabric data agent 的这项集成目前仍处于预览阶段。实际应用中，有几个边界值得关注。
•不要默认一次提问会跨数据源关联查询。数据代理会将问题路由到相关底层数据源；如果问题需要跨源分析，应先确认数据是否已在可查询的数据源中准备好。
•权限依然有效。数据代理使用提问者对底层数据源的权限执行查询。分享数据代理，并不自动授予底层数据访问权限。
•更新可能不会立即生效。data agent 通常每 10 分钟获取一次最新 Ontology 上下文；也可以手动刷新后再测试。
•不同数据源的支持存在差异。例如，使用 Power BI 语义模型作为底层来源时，查询生成过程可能不会使用部分 Ontology 上下文。具体能力和限制应以最新官方文档及实际环境验证为准。
AI 要回答业务问题，光能识别表和字段还不够；它还需要知道，企业是如何理解“客户”“订单”和“产品”的，以及这些概念如何连接到真实数据。
Fabric Ontology 的价值，就在于把这层业务知识组织起来，提供给数据代理作为上下文，让自然语言问题有更清晰的路径通向底层数据。
但从“AI 给出了答案”到“业务可以使用这个答案”，中间仍有重要的一步：检查查询、核对口径、验证结果。
技术可以帮助我们更快地获得答案，而对业务含义的确认，仍然需要人与数据共同完成。
想让 AI 真正读懂你的业务口径？
申请试用智能小V，与顾问聊聊你的数据场景 →
在线咨询
