Microsoft Fabric IQ中的本体驱动数据代理：实用指南
了解 Microsoft Fabric IQ 如何结合语义模型、本体论及 MCP，推动企业级 AI 智能体从数据检索迈向受管控的商业推理。
来源: Microsoft Fabric IQ and Data Agents for Ontology based Consumption
简而言之，企业人工智能正在经历重大变革。第一波企业生成式人工智能主要侧重于数据检索，而下一代企业智能体将超越单纯的数据获取功能——它们会运用受控的业务逻辑来进行推理。
Question
↓
LLM
↓
Vector Search / RAG
↓
Documents
↓
Answer
新兴模型以基于业务逻辑的推理为核心：
Business Question
│
▼
Agent / Planner
│
┌─────────┴─────────┐
▼ ▼
Semantic Model Ontology
"How measured?" "What does it mean?"
│ │
└─────────┬─────────┘
▼
Enterprise Data
│
▼
Insight / Decision
│
▼
Action
这种差异至关重要。
普通数据库可以向智能体传递类似这样的信息：
customers.CustomerId = sales.CustomerId
相比之下，本体论可以告诉智能体：
Customer ── PURCHASES ──> Product
而语义模型则能更进一步，向智能体传达：
Total Revenue = governed enterprise measure
这代表了三种完全不同的理解深度。
微软正在通过Fabric IQ将这些理念整合在一起：语义模型提供可信的分析指标，本体论提供共享的企业词汇表与关系结构，图层实现关联数据的遍历，而数据智能体则通过对话展现所有这些分析能力。微软将Fabric IQ视为业务上下文层，它能将原始的分析数据和运营数据转化为智能体能够实际理解的商业概念。
让这一方案真正有趣的设计亮点在于：
你可以发布Fabric数据智能体，并通过模型上下文协议（MCP）将其公开，这样微软Foundry智能体或任何其他支持MCP的智能体就能像使用普通工具一样获取受管控的企业智能信息。
Microsoft 现在支持正是这样的工作流程：已发布的 Fabric Data Agent 可以作为 MCP 工具呈现给 Foundry agent，而一个 Foundry agent 则可以协调多个 Fabric Data Agent 以及其他工具和知识源。
1. 为何本体论再度变得重要
本体论并非新概念。
知识图谱也不是新鲜事物。
语义模型同样如此。
真正发生变化的是使用它们的人群。
从历史上看，企业级语义技术主要被以下领域采用：
- 搜索平台
- BI 工具
- 数据集成系统
- 分类法管理
- 基于图的应用程序
- 领域专家
现在又出现了一类新的使用者：
AI 智能体。
而智能体在此处面临着真正的障碍。
大型语言模型能够很好地处理所接收的信息并进行推理，但企业数据库几乎从未以人们自然思维的方式描述业务。
例如：
CUSTOMER_MASTER.CUST_ID
SALES_TXN.CUST_ID
SALES_TXN.PROD_NM
SALES_TXN.NET_REV
然而，人们则是这样思考的：
Customer
│
│ PURCHASES
▼
Product
│
└── generates → Revenue
这两种表达方式之间的差异正是导致智能体产生大量不确定性的原因。
由于缺乏语义依据，智能体不得不进行猜测：
- 哪些表对应哪些业务概念
- 哪些连接实际上是有效的
- 某个列究竟代表什么
- 哪一种度量定义应被视为权威标准
- 实体之间如何相互关联
- 名称不同的两个字段是否实际上表示相同含义
在只有五张表的演示环境中，这还算是个可以接受的问题。
在数百种企业数据产品中，这种情况确实存在很大风险。
Fabric的本体功能专为构建机器可读的共享业务词汇表而设计，该词汇表由实体类型、属性、关系、约束条件以及与真实OneLake数据的关联组成。人类用户和自动化代理都可以使用这一词汇表。
2. 但“知识图谱”并不意味着单一架构
随文提供的可视化决策流程有助于阐明为何选择图谱与本体方法并非万能之策。
[插入：图谱与本体解决方案决策流程]
构建知识图谱并没有唯一的正确方式。
大致上可以将其分为五种模式。
模式1 — RDF/语义知识图谱
这是传统的语义网方法：
Subject ─ Predicate ─> Object
它通常与以下技术结合使用：
RDF
RDFS
OWL
SPARQL
优势：丰富的语义表达能力、基于标准的互操作性、成熟的本体建模方法，以及形式化推理的支持。
缺点：建模复杂性较高，需要专门的技能，且所需的基础设施往往超出实际应用的需求。
3. 带标签的属性图
带标签的属性图（LPG）模型采用更以应用为导向的方法：
(Customer)
│
│ PURCHASED
│ {date, quantity}
▼
(Product)
节点和边都可以拥有自己的属性。
像Neo4j这样的工具推广了这种模型，因为它非常适合那些需要大量遍历操作的应用程序。
优势：直观的图模型构建、出色的遍历性能、成熟的图算法，以及丰富的应用开发经验。
权衡：图结构本身并不能直接形成受规范管理的企业语义词汇表——这一层含义仍需单独进行建模与管理。
Microsoft Fabric Graph采用这种LPG方法，将OneLake表映射为节点和边类型，并通过GQL提供遍历功能。Microsoft实现的GQL遵循ISO标准化的图查询语言。
4. 更轻量的方案：本体与内存中的图结合
并非所有应用都需要完整的企业级图数据库。
对于聊天类应用、边缘场景、功能范围有限的助手或概念验证项目，可以用纯JSON来表示简单的本体结构：
{
"entities": {
"Customer": {},
"Product": {}
},
"relationships": {
"Purchases": {
"from": "Customer",
"to": "Product"
}
}
}
您的应用层可以将该定义加载到 NetworkX、Memgraph、RDF 库或任何其他内存图结构中。
这种方案部署快速且运行成本低廉。
但问题在于，治理、安全、数据溯源、扩展性、数据同步以及语义定义的共享管理等问题都需要您自行解决。
5. 为何 Microsoft Fabric 更为出色
Fabric 从不同的角度来解决这个问题。
它并非以所有企业数据都必须迁移到图数据库为前提，而是假设企业数据仍保留在其原有的 OneLake 中，然后在之上叠加语义和关系智能功能。
用图表表示如下：
Fabric IQ
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Semantic Model Ontology Graph
│ │ │
trusted metrics business meaning traversal
│ │ │
└─────────────────┼──────────────────┘
│
OneLake
微软明确区分了这些职责：语义模型提供可信的关键绩效指标和分析结构，本体提供通用的业务词汇表，图负责在相互关联的数据之间进行遍历，而数据或操作代理则基于该上下文实现智能交互与操作。
这种职责分离在架构设计中非常重要。
6. 语义模型、本体与图是三种不同的概念
这些术语常常被当作同义词使用，但实际上并非如此。
一种有助于理解的方式是：
DATA
"What happened?"
│
▼
SEMANTIC MODEL
"How should it be measured?"
│
▼
ONTOLOGY
"What does it mean?"
│
▼
GRAPH
"How is everything connected?"
│
▼
AGENT
"What should I investigate or do?"
Power BI的语义模型可能会定义诸如以下的度量值：
Total Revenue
Average Order Value
Customer Count
Revenue by Segment
本体可能会定义诸如以下的实体与关系：
Customer
Product
Customer ── PURCHASES ──> Product
图则是实际用于构建并遍历这些连接的结构：
Customer A
│
├── PURCHASES → Laptop
│
├── PURCHASES → Monitor
│
└── PURCHASES → Dock
数据代理随后通过自然语言交互呈现所有这些信息。
Fabric还允许您直接从现有的语义模型中生成本体：表变为实体类型，列变为属性，而语义模型中已定义的关系则成为本体的关系。
7. 构建过程：一个最简的销售数据产品
为使重点集中在架构而非数据工程上，该示例刻意保持简单。
仅使用了两个源表：
NP_SalesDataProduct_LH
customers
──────────────
CustomerId
CustomerName
Segment
City
State
Country
sales
──────────────
OrderId
OrderDate
CustomerId
ProductName
ProductCategory
Quantity
UnitPrice
DiscountPct
Revenue
SalesChannel
它们之间的关系十分直接：
customers.CustomerId
1
│
*
sales.CustomerId
这样便足以完整展示整个架构，同时不会让建模的复杂性妨碍对核心概念的理解。
8. 第一步——创建Fabric数据产品
这两个CSV文件被加载到Fabric Lakehouse中：
NP_SalesDataProduct_LH
│
├── Tables
│ └── dbo
│ ├── customers
│ └── sales
│
└── Files
├── customers.csv
└── sales.csv
[插入截图：显示客户和销售数据的Lakehouse界面]
此时你已经拥有一个可正常运行的Fabric Data Agent。
它能够回答诸如总营收是多少、哪些产品类别带来的营收最高，以及按客户群体划分的营收结构等问题。
但背后其实还发生着一些值得注意的事情。
由于没有定义额外的语义规则，该代理必须自行推断数据连接方式：
customers.CustomerId
=
sales.CustomerId
同时它还必须自行推断出：
Revenue → SUM(Revenue)
这样就能为你提供一个可供对比的基准。
9. 第二步 — 添加语义模型
接下来你需要引入分析契约。
Customer
1
│
*
Sales
其中包括一些受约束的度量指标，例如：
Total Revenue =
SUM(sales[Revenue])
以及：
Total Orders =
DISTINCTCOUNT(sales[OrderId])
此时，代理无需再猜测“总收入”的含义。
该定义属于语义层范畴。
这体现了企业代理的一个重要原则：
代理应使用经过规范管理的指标，而非每次收到查询时都从原始数据列中重新计算企业相关数值。
10. 第3步 —— 添加本体
从这一步开始，工作重点将从分析性定义转向业务层面的含义。
本练习中的本体仅定义了两种实体类型：
Customer
Product
“客户”对应：
customers.CustomerId
customers.CustomerName
customers.Segment
customers.City
customers.State
customers.Country
使用：
KEY = CustomerId
而“产品”则直接从现有的sales表中获取：
sales.ProductName
sales.ProductCategory
使用：
KEY = ProductName
同样，无需为使此功能正常运行而创建单独的实体产品表。
11. 定义业务关系
接下来，需要添加一种关系：
Customer
│
│ PURCHASES
▼
Product
这里有趣的是数据绑定的工作原理。
sales表本身就充当了这种关系的桥梁：
Customer.CustomerId
↑
sales.CustomerId
sales.ProductName
↓
Product.ProductName
因此，像这样的原始销售记录：
sales row:
CustomerId = C001
ProductName = Laptop Pro
会变成：
Customer(C001)
│
│ PURCHASES
▼
Product(Laptop Pro)
正是在这一刻，普通的关联记录才转化为业务层面能够识别的知识形式。
Fabric的本体模型正是为这种工作流程而设计的：首先定义实体类型及其关系，然后将这些抽象定义与存储在OneLake中的具体数据绑定起来。
12. 对智能体来说有什么变化？
以这个问题为例：
企业客户会购买哪些产品？
在没有本体论的情况下，智能体需要通过类似以下方式推理：
Find customers table
↓
Find Segment
↓
Filter Enterprise
↓
Determine CustomerId join
↓
Join sales
↓
Find ProductName
有了本体论之后，推理过程简化为：
Customer
│
Segment = Enterprise
│
└── PURCHASES ──> Product
这个问题几乎可以直接对应到模型本身。
微软将这种转变描述为让智能体不再以单个表格的形式思考，而是转向基于实体、关系、定义、规则和源映射构建的规范化视图。
13. 第4步 — 构建Fabric数据智能体
数据智能体就是将这一切转化为自然语言界面的关键：
User
│
▼
NP_Sales_DataAgent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Lakehouse Semantic Model Ontology
│ │ │
raw facts trusted KPIs relationships
│ │ │
└─────────────┼─────────────┘
▼
OneLake
微软将Fabric数据代理描述为一种限定在特定数据域内的自然语言问答层，而本体论则为这些代理提供其依赖的更深层次业务背景。
14. 接下来是重要的架构变革：MCP
Fabric数据代理无需始终限制在Fabric内部。
你可以将其发布出去。
一旦发布，Fabric就会将该代理作为模型上下文协议服务器暴露出来。
从概念上讲，其流程如下：
Fabric Data Agent
│
│ Publish
▼
MCP Server
│
├── tool description
├── input schema
└── governed execution
至此，你的企业数据智能便变成了可复用的资源——一种其他系统可以调用的代理工具。
15. Microsoft Foundry成为编排层
这带来了更为有趣的架构可能。
USER
│
▼
Microsoft Foundry Agent
│
planning / orchestration
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
CRM Tool Search Tool Fabric MCP
│
▼
Fabric Data Agent
│
┌───────────────────┼───────────────┐
▼ ▼ ▼
Semantic Model Ontology Lakehouse
│ │ │
└───────────────────┼───────────────┘
▼
OneLake
这里的职责分离非常重要。
Foundry智能体负责工作流推理。
Fabric数据智能体负责数据推理。
在目前的版本中，微软的Foundry集成允许Foundry智能体通过Fabric IQ/OneLake目录发现已发布的Fabric数据智能体，并将它们视为MCP工具。一个Foundry智能体也不局限于单一领域——它可以同时调用并使用多个Fabric数据智能体。
16. 实际应用示例
假设用户向Foundry智能体提出如下请求：找出贡献最大营收份额的客户群体，分析是哪些产品推动了该群体的表现，然后将这些分析结果转化为销售团队可据以采取行动的建议。
执行过程可能如下：
USER
│
▼
Foundry Orchestrator
│
│ "I need enterprise sales intelligence."
│
▼
Fabric Data Agent MCP Tool
│
├── Semantic Model
│ → trusted revenue calculation
│
├── Ontology
│ → Customer → PURCHASES → Product
│
└── Lakehouse
→ transaction data
│
▼
Result:
Enterprise customers generate...
Laptop category contributes...
│
▼
Foundry Agent
│
├── reasoning
├── CRM lookup
├── recommendation generation
└── potentially action
│
▼
Sales recommendation
这里重要的并非语言模型给出了推荐，而是该推荐基于规范的商业表示形式，而非从原始表格或猜测的语义中临时拼凑而成。
17. MCP改变了企业智能体架构
在没有MCP的情况下，团队通常会采用如下连接方式：
Agent A → custom Fabric integration
Agent B → another custom Fabric integrationAgent C → another SQL implementationAgent D → another Power BI integration
随着时间推移，每个智能体都会积累关于底层数据平台的深度但脆弱的知识。
引入MCP后，情况则有所不同：
Enterprise Agents
┌───────────┼───────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└───────────┼───────────┘
│
MCP Tool
│
▼
Fabric Data Agent
│
▼
Governed Data IQ
Fabric数据智能体变成了专为智能体设计的数据智能产品，而非每个团队都需要重新构建的定制化集成方案。这看似细微，但实际上对架构影响重大。
18. 另一种选择：直接暴露本体
还有另一种值得考虑的路径。
不必通过 Fabric Data Agent 来处理所有数据，可以直接通过 MCP 将 Fabric Ontology 暴露给任何兼容的外部代理。微软提供了配套工具的本体 MCP 服务器，可用于发现本体实体类型并对本体执行查询。
这样就有两种不同的架构模式：
PATTERN A
External Agent
│
│ MCP
▼
Fabric Data Agent
│
▼
Ontology
与以下模式相对：
PATTERN B
External Agent
│
│ MCP
▼
Fabric Ontology
当希望利用Fabric 自带的对话式及数据代理推理层时，选择第一种模式；而当外部代理已具备成熟的规划逻辑，仅需更直接地访问企业语义模型时，则选择第二种模式。
19. Fabric 架构模式的优缺点
优势
集中式语义管理。业务定义存储在统一的管理位置，而无需复制粘贴到每个提示语中。
基于OneLake构建。无需将全部数据复制到独立的图数据库平台中。
三层结构协同工作。分析指标与关系级语义可在语义模型、本体及图结构中共同存在。
专为智能体设计。Fabric Data Agents与本体层均专门为作为AI智能体的数据来源而构建。
通过MCP实现开放接入。由此产生的智能层既可被Foundry使用，也可被自定义的MCP客户端调用。
职责划分清晰。
Fabric → data intelligence
Foundry → orchestration intelligence
这种划分在企业层面形成了相当清晰的边界。
20. 权衡取舍
有一些重要的注意事项。
其中大部分仍属于预览技术。本体支持、若干Fabric IQ及Foundry集成功能以及相关的MCP能力目前均为预览特性，因此在生产环境中使用前应先查阅微软的当前预览条款。
本体管理是一项持续进行的工作。一旦多个领域开始定义自己的Customer、Account、Product、Contract等实体，就必然需要有人负责命名、版本控制以及跨领域的一致性维护。
本体无法修复糟糕的数据。即便为低质量数据集添加精美的业务语义，得到的结果依然会是低质量的。
并非总是需要本体。对于简单的关键绩效指标汇总，直接查询语义模型可能更为简单且足够。
并非所有图处理场景都适用此方法。复杂的图算法、专门的RDF风格推理或高度定制化的图处理任务可能仍需要专用的图处理平台。
这正是分阶段决策框架如此有用的原因。
21. 我会采用的路线图
与其直接启动全企业范围的本体构建工作，分阶段逐步推进更为合理。
第一阶段 — 数据产品
Sources
↓
OneLake
↓
Domain Data Products
此阶段的目标是建立可靠且归属明确的领域数据。
第二阶段——分析语义学
Data Product
↓
Semantic Model
↓
Measures / KPIs / Dimensions
此阶段定义了组织如何进行度量。
第三阶段——业务语义学
Semantic Models + Data Products
↓
Ontology
↓
Entities / Relationships / Rules
此阶段明确了那些被度量的内容实际代表的含义。
第四阶段——互联智能
Ontology
↓
Graph
↓
Traversal / dependency / impact analysis
在此阶段，仅在遍历关系确实能带来价值时才使用图结构。
第五阶段——领域数据代理
Ontology + Semantic Model + Data
↓
Data Agent
在此处，将积累的领域知识转化为可交流的形式。
第六阶段——MCP
Data Agent
↓
Publish
↓
MCP
此步骤将可交流的产品转化为其他代理能够使用的功能。
第七阶段——企业级代理编排
Foundry Agent
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Sales Data Agent Supply Agent Finance Agent
│ │ │
└──────────────────┼──────────────────┘
│
Fabric IQ
微软已经在朝这个方向发展：Foundry代理可以通过Fabric IQ获取多个已发布的Fabric Data Agent的数据，而这些Agent每一个都作为MCP工具提供。
发展前景
更宏观的架构变化如下：
GENERATION 1
LLM + RAG
│
Documents
逐渐演变为：
GENERATION 2
LLM + Tools + Data
│
SQL / APIs / RAG
最终发展成：
GENERATION 3
Agent Systems
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Documents Tools Enterprise IQ
│
┌──────────┼──────────┐
▼ ▼ ▼
Semantics Ontology Graph
│ │ │
└──────────┼──────────┘
▼
Enterprise Data
在这一领域，竞争的焦点将不再是谁的模型最强大。
取而代之的是，谁能为这些模型构建出最丰富的企业上下文层，谁就能占据优势。
微软将其整体发展方向定义为Microsoft IQ，其中Fabric IQ负责提供关于业务实体和数据的上下文信息，与其他如Work IQ、Foundry IQ和Web IQ共同协作。
那种思路是成立的。
不能仅仅因为某个智能体擅长检索文档，就信任它来处理业务中的某些环节。
它需要理解：
事物是什么。
它们彼此之间的关联。
组织实际上是如何衡量这些事物的。
哪些定义具有权威性。
这些事物目前的状况如何。
最终还需要明白：
结合所有这些信息，哪些行动才是合理的。
结论：从RAG到企业级推理
RAG为企业人工智能提供了获取知识的方法。
工具的使用让智能体能够接入各种系统。
本体论则为它们提供了完全不同的东西：
意义。
当这些含义与受控指标、图关系、实时运营数据以及智能体协调机制相结合时，便能形成一种极具吸引力的架构：
DATA
│
▼
SEMANTICS
│
▼
ONTOLOGY
│
▼
CONNECTED INTELLIGENCE
│
▼
DATA AGENTS
│
▼
MCP
│
▼
ENTERPRISE AGENTS
│
▼
DECISIONS
│
▼
ACTIONS
这正是基于本体的智能体分析所具备的真正价值所在。
它并非只是简单地附加在数据库上的另一个聊天机器人。
这是一种企业级智能架构：数据产品提供事实信息，语义模型提供可信的度量标准，本体赋予意义，图结构展示关系，领域智能体输出智能分析结果，而MCP则让所有这些智能功能能够在更广泛的智能体生态系统中实现整合。
正是这种组合使得下一代企业级人工智能的构建变得更为有趣。