专栏 · Agent 工程手艺 › 第 213 期 · AI 产品 · 收录于 2026 年 9 月 14 日
什么是本体(预览版)？——Microsoft Fabric IQ
MF
Microsoft Fabric · Microsoft Learn
TL;DR · 三句话
- 一微软把本体定义为"企业词汇 + 语义层"：用实体类型、属性、关系（外加约束）把跨业务域的含义统一起来，定义完再绑定到 OneLake 里的真实数据，作为人和 AI 智能体共用的上下文层——这是官方预览版文档的自我描述，全文没有给出任何效果数据。→ 详细
- 二真正让本体落地的是"数据绑定"：一份绑定写清数据类型、标识键、列→属性、键→关系，并把 schema 演进、质量检查、来源追溯都放在概念层做，让原始数据行和事件变成"受治理的业务对象"；带血缘、按计划刷新的实例图就建在绑定与关系定义之上。→ 详细
- 三查询从实体类型出发，NL2Ontology 让人直接用业务术语提问，并承诺筛选、联接、单位、有效时间窗口都对齐本体里"已发布的定义"；对照 Palantir 四原语，名词层（对象、属性、链接）一一对得上，而"动作"在本页的核心概念里没有对应项。→ 详细
01
官方定义：本体 = 企业词汇 + 语义层，定义完要绑到真数据
- 材料性质：微软官方产品文档（Microsoft Learn，最后更新 2026-07-21），功能是 preview（预览版）。全文只讲概念模型和适用建议，没有客户案例，也没有任何效果数据——当一份公开的参考架构读，别当效果承诺。→ 详细
- 定义：本体是 Fabric IQ 工作负载里的一个"项"（item，Fabric 里可新建、管理的一类资产），「以数字化方式呈现企业词汇与语义层」，在各业务域和 OneLake（Fabric 的统一数据湖）的各数据源之间统一含义。语义层＝夹在数据表和使用者之间、把"字段"翻译成"业务含义"的那一层。企业概念被拆成实体类型（如客户）、属性（客户的姓名、电子邮件）、关系（客户下订单），并「明确这些术语的约束条件」；定义完再绑定到真实数据，「让下游工具共用同一套语言」，人和 AI 智能体据此跨域推理，采取「可直接支撑决策的行动」。→ 详细
- 定位与适用条件：一个「可规模化、安全且受治理的共享业务模型」，作为共享上下文层供团队、Fabric 智能体、工作流和 Real-Time Intelligence（Fabric 的实时数据分析组件）共用，求「一致的推理与行动」。原文给的适用场景：需要跨域一致性、治理或给 AI 智能体做 grounding（让 agent 的回答锚定在真实的业务定义和数据上，而不是凭空推断）之一，并且想跨流程推理的时候（agent 为什么需要一层显式本体当地基，见 ep98）。→ 详细
02
本体作为"业务上下文层"：概念目录、数据绑定、图、查询四件套
- 换个说法 + 四件套：本体是「共享、机器可理解的业务词汇」＝事物（实体类型）＋事实（属性）＋连接（关系），再加让这些表示保持一致的约束和规则。作为业务上下文层，它装着四样东西：① 概念目录（产品、订单、工厂、传感器、路线），「一次定义、处处复用」；② 数据绑定，连到 OneLake 里的实际数据源；③ 图结构，支持导航、血缘（数据从哪来、经过哪些加工）和推理；④ 查询接口，「针对概念（而不仅仅是表）提问」，支持跨数据源联合查询。→ 详细
- 核心概念清单：实体类型、实体实例、属性、关系，一共四个——里面没有"动作"，行动只出现在第一节的定位描述里。→ 详细
03
实体类型：把"运单"抬到任何一张表之上，终结列级定义打架
- 定义：现实世界某个概念（文档举例：运单、产品、传感器）的「可复用逻辑模型」，把它的名称、描述、标识符、属性、约束五样东西标准化。目的原话：「让企业里的每个团队在使用"运单"这样的术语时，指的都是同一个东西」。→ 详细
- 解决什么：它「把概念提升到任何单张表之上，从而消除各数据源之间相互冲突的列级定义」——先有一个公认的"运单"，各张表再往上对齐，而不是每张表各自代表一个"运单"。它同时是统一挂载点：属性、关系、标签都挂在它上面，供下游工具「改进跨表、跨模型的语义」。→ 详细
04
实体实例：由数据绑定填出来的"一行带语义的数据"
- 实体类型的一个具体个体（比如某一张运单），由数据绑定填充而来，文档比作「一行带语义的数据」；它记录由哪个数据源创建、在何时有效，能参与关系，把原始数据变成所有工具和 AI 智能体「以相同的方式理解」的标准化业务对象。→ 详细
05
属性：带数据类型的"具名事实"，规则和质检挂在概念层
- 定义：「关于实体的一项具名事实，并带有声明的数据类型」，可以附带与源数据的绑定，以及语义注释（如"标识符"或元数据特性）。→ 详细
- 价值在"概念层面"：属性「强制统一类型、单位和命名」，并「支持在概念层面执行规则和质量检查」——意思是校验规则可以挂在"客户的电子邮件"这个概念上，而不是在每张表、每段加工脚本里各写一遍。→ 详细
06
关系：有类型、有方向、能带特性和基数，替代各写各的 join
- 定义：「实体类型之间或实例之间有类型、有方向的链接」——一种有名字、有朝向的业务关系，不是泛泛一根连线。→ 详细
- 两项增强：能带特性（文档举例：距离、置信度、effectiveAt 生效时间），一条连接本身就能说明"多远、多可信、何时起算"；能有基数规则（cardinality，规定一边最多连几个另一边），如一个客户可以有多个订单。→ 详细
- 价值：让"事物如何连接"「显式且可复用」，支持遍历（沿关系一跳一跳走下去）、依赖分析、基于规则的推理，「无需编写自定义联接逻辑」就能更清晰地回答业务问题。联接（join）是 SQL 里按键把两张表拼起来的操作——关系从每个人各写一份的查询里，搬进了本体里的一条公共定义。→ 详细
07
数据绑定：定义接上 OneLake 真数据，演进、质检、来源追溯也在这一层
- 绑到哪：定义好本体后可以「将其绑定到数据」，从而「在本体的上下文中对数据进行可视化和查询」。绑定把实体类型、属性、关系连到 OneLake 里的具体数据，点名三类来源：lakehouse 表、eventhouse 流（存实时事件流的库）、Power BI 语义模型（Power BI 里已建好的度量与维度模型）。→ 详细
- 一份绑定写清四件事：数据类型、标识键（判断"两条记录是不是同一个客户"的键）、列→属性的映射、键→关系的映射（跨多个数据源）。属性和关系正是在这一步才落到真实的列和键上。→ 详细
- 治理放在概念层：绑定在概念层启用 schema 演进规则（表结构变了怎么跟着变）、数据质量检查（可空性、取值范围、唯一性）、来源追溯（provenance），原话是「把原始的数据行和事件转化为受治理的业务对象」，确保跨数据源「含义一致、遵循相同的规则，并能追踪其来源」。→ 详细
08
本体图：节点是实例，边分"声明的"和"推导的"，都带血缘、按计划刷新
- 是什么：「基于数据绑定和关系定义构建的可查询实例图」，由 Graph in Microsoft Fabric（Fabric 的图服务）在本体里提供，可在实体类型详细信息页查看。注意它是实例图——画的是具体的客户、订单，而不只是类型之间的结构图。→ 详细
- 图里有什么：节点是实体实例，边是带元数据特性的链接，且边分两种——显式声明的（asserted，直接写明的连接）和推导得出的（derived，由已有信息推出来的连接）。每个节点、每条边都保留数据源血缘，并按计划刷新。→ 详细
- 能干嘛：可视化探索业务上下文；跑图算法（文档举例：路径＝两点之间怎么连过去、中心性＝谁是关键枢纽、社区发现＝哪些节点抱团）；执行规则驱动的推理。原话收束：图「把关系提升为一等公民，使上下文变得显式、可查询且受治理（而不是隐藏在联接逻辑中）」。→ 详细
09
查询本体与 NL2Ontology：用业务术语提问，口径由"已发布的定义"兜底
- 查询从实体类型出发：本体查询让你「借助本体术语，针对已绑定的数据源提出业务层面的问题」——以实体类型为起点，支持按属性筛选、遍历关系、按时间聚合，以及施加其他约束。→ 详细
- 自动路由到最合适的引擎：本体层「自动把查询发送到效率最高的系统」，文档举例：图走 Graph in Microsoft Fabric 的 GQL（图查询语言），事件数据走 Eventhouse 的 KQL（Kusto 查询语言，微软用来查日志与时序数据的语言）。使用者面对的是概念，底下调哪套引擎由本体层决定。→ 详细
- NL2Ontology（自然语言到本体的查询层）：把自然语言问题转成结构化查询再返回结果，让你「直接用业务术语提问，而无需了解数据在不同系统中如何存储的细节」。全篇最值得记的一句承诺是：NL2Ontology 查询「确保筛选条件、联接、单位和有效时间窗口与本体中已发布的定义保持一致」——也就是说，自然语言问答的口径不由模型临场去猜，而是被本体里发布过的定义约束住（直接自然语言转 SQL 在表多时为何会翻车，见 ep99）。这是设计声明：文中没有给出准确率或任何对比数据，"发布"的流程本页也没展开。→ 详细
10
上手路径：开租户设置 → 走教程，或从现成语义模型直接生成本体
- 文末"后续步骤"给了三条：先在租户（tenant，企业在微软云上的整个组织空间）设置里启用本体（预览版）的必需项；再从本体教程开始；或者直接跳到「从语义模型生成本体」——即拿已有的语义模型当起点生成本体，不必从一张白纸开始画。本页只给了链接，没展开具体步骤。→ 详细
11
概念对照：Fabric IQ 本体 vs Palantir 四原语（只列本页真出现的概念）
| Palantir 原语（见 211） |
本页对应概念 |
本页怎么讲 · 差异点 |
出处 |
| Object type（对象类型）及对象实例 |
实体类型 + 实体实例 |
类型标准化名称、描述、标识符、属性、约束；实例由数据绑定填充，记录来源与有效时间 |
→ |
| Property（属性） |
属性 |
带声明的数据类型，可挂语义注释（如标识符），在概念层做规则与质检 |
→ |
| Link type（链接类型） |
关系 |
有类型、有方向；可带特性（距离、置信度、effectiveAt）与基数规则 |
→ |
| Action（动作：修改对象属性的单个事务） |
本页核心概念里没有对应项 |
行动只出现在定位描述中（「可直接支撑决策的行动」「一致的推理与行动」），本页没讲行动怎么定义、执行或写回 |
→ |
| （不属于四原语） |
数据绑定 |
被单列为核心数据概念：数据类型、标识键、列→属性、键→关系，外加 schema 演进、质检、来源追溯 |
→ |
| （不属于四原语） |
本体图 / 本体查询 / NL2Ontology |
使用面：实例图与图算法；从实体类型出发的查询、自动路由到 GQL / KQL；自然语言问答对齐已发布定义 |
→ |
- 名词层几乎一一对上，动词层是空位：Palantir 的三个"名词"原语（对象类型、属性、链接类型）在本页都有直接对应，本页还另外单列了实例、绑定、图和查询；但 Palantir 放进 Action 的"改写业务对象"，在本页核心概念里找不到对应——本页定义的本体，重心是统一含义 + 查询与推理。这只是一篇概述页，不能据此断言产品没有行动能力。→ 详细
- 与同组的碰撞点：实体、属性、关系、基数、标识键这套词和传统的实体-关系数据建模（ER 建模）一脉相承——这页正好是 207 老冯反方论证（本体 = 数据库建模换皮）最该拿来对照的材料；而对 214 卖方"本体层是护城河"的判断，这页也提供了一个参照：大厂已经把实体、属性、关系、数据绑定产品化成 Fabric 里的一个功能项（仍是预览版）。→ 详细