9 个问题带你认识本体（Ontology）及其应用

最近在和一些客户聊起 AI 应用时，经常会被问到一些“本体”的问题。

本文不讲复杂的术语，而是用几个最常见的问题，结合一些简单的领域用例，来帮助大家认识与入门本体。

读完本篇你一定不会成为本体专家，但你应该能听懂一场关于本体的讨论，至少能理解一个本体的应用场景。

让我们从最基本的问题开始：本体到底是什么？

01 本体到底是什么？

想象一个北京司机第一次来到南京，任务是把乘客送到南京南站。

但是TA还不能马上出发：TA不知道汽车站还是火车站、不知道哪条路单行，也不知道哪些通道禁止普通车辆进入。

所以它需要一张地图，需要图例看懂线路，还要遵守必要交通规则。

AI 进入某个企业，面对的情况很相似：通用知识在这里失效了。

比如一个电信企业 AI 需要回答这样一个问题：

为什么我的手机号码无法订购5G套餐？

它的训练数据显然无法解释这个问题，也很难通过数据库或者 RAG 查询到结论 — 因为这需要理解这样的业务知识：

• 手机号码代表一个用户

• 用户的费用计入账户，账户可能欠费

• 欠费账户对应用户的套餐变更请求不予受理

没有这样的业务知识，即使 AI 能够查询数据，也不知道查什么、沿着什么关系查、更无法判断为什么失败。

本体的作用，就是要把这些业务上的概念、关系、规则等告诉 AI — 让 AI 拥有一份企业业务世界的“导航地图”，掌握了这份地图，才可能安全到达目的地。

提到本体，很多人会想到 Palantir。但本体早已存在于人工智能和知识工程中，RDF、OWL 等标准也远早于今天的大模型。Palantir 没有发明本体。

Palantir Ontology 是本体的一种代表性产品实现并取得成功，从而让本体广受关注，但 Palantir 不是本体的起点，本体也非 Palantir 发明。

02 为什么到了 Agent 时代，本体更热了？

上一个问题说到，本体可以给 AI 一张企业业务地图。但为什么到了 Agent 时代，本体被提的更多了？

因为 Agent 有着完全不同于传统软件的使用方式。

过去，我们通过不同的入口进入OA、CRM、SCM等 — 基于菜单和固定流程的操作。字段解释、数据关联、业务规则，都靠代码来解决 — 就像那个新司机，虽然没有地图，但我给你把操作动作固化好，也一样能到目的地。

Agent 不一样。用户可以随时提出新的任务，Agent 要自主的理解意图并推进任务，且有着更高的确定性要求：

简单说就是：

企业 Agent 任务的复杂性与高确定性要求，决定了它更需要一种精确表达业务知识的、统一的结构化“语言” - 本体。

比如，电信企业建设了多个不同的 Agent 系统，它们都要统一理解客户、账户、用户、产品和套餐等系列概念及其关系 — 但如果每个项目都重新编写提示或 Skill 来提供领域知识，不仅繁琐，而且很容易不一致。

而有了统一的本体，这些概念和关系等只需维护一份。

不同 Agent 可以在权限范围内复用同一套业务含义。业务语义发生变化时，也不必逐个修改每个 Agent。

当然，本体也并不是 Agent 的标配。如果业务概念少、关系简单、各方理解一致，一份清楚的 Wiki、数据字典或接口说明也可能够用。

03 本体和数据库的差异在哪？它存数据吗？

一听到“用户、账户、订单、产品及其关系”，熟悉关系型数据库的人很容易产生疑惑：这些东西数据库里不是已经有了吗？

先看数据库与本体在本质上的区别：

数据库保存具体的业务数据（事实）：

• 客户C01名下有用户U05；

• 用户U05使用号码138xxxx；

• 用户订购产品P20，并通过账户A07付费；

• 账户A07当前的账户余额是0；

本体定义的则是这些数据该怎样理解：

• 客户、账户和用户是三类不同的业务概念；

• 手机号码是一种资源，由用户使用；

• 订购产品会产生订单；使用服务会产生账单；

• 哪些关系可以继续推导出新的业务事实

简单的说：

数据库主要记录业务世界发生了什么；本体则解释业务世界本身。

顺着这个思路还有两个常见问题：

数据库的 Schema 不能说明数据关系吗

的确，表结构、E-R图和数据字典本来就是理解系统的重要方式。如果系统比较单一、表名清楚、关系简单，它们可能已经够用。但问题是：

数据库 Schema 的设计往往是优先服务于系统实现的。

一个业务对象可能为了性能被拆到多张表；一些关系也可能藏在代码里（比如外键）；同一个业务概念在不同系统中也可能有不同名称。

本体把这些分散的业务含义提取出来，用统一方法重新表示和连接。它不是否定数据库 Schema，而是在其上增加一层可跨系统共享的业务解释。

本体到底存不存数据？

答案是：通常情况下，不直接承担业务数据的存储。

本体的概念、关系和约束本身需要被保存。但至于“客户C01”、“产品P07”这类数据，会继续留在 CRM 等业务系统中。

本体通过映射与这些数据源连接 — “这个叫【用户】的业务概念在 CRM 数据库中保存在 users 表中”，类似这样。

因此，数据库仍是业务数据的权威来源。本体主要目的不是替代数据库，而是让分散的数据拥有一致的业务含义。

需要注意的是，一些用来存储本体定义的图数据库本身是允许存储业务数据的，比如 GraphDB。

04 本体和知识图谱什么关系？

说到复杂关系的表示，另一个很容易被联想到的概念是：知识图谱。

它们都有节点和连线，也都可以用三元组（类似“用户-订购-产品”这样的关系表达）定义，到底有什么不同？

其实它们的区别，与本体和数据库的区别本质上类似：

本体侧重概念层、语义层。

它定义业务世界中的类型、关系和约束。例如：

• 5G套餐是资费套餐的一类；

• 用户可以订购5G产品；

• 用户的账单通过账户付费。

知识图谱通常侧重事实层。

它记录具体有哪些对象，以及这些对象之间已经发生的关系。例如：

• 用户U05订购了产品P20；

• “畅享299”套餐是“5G套餐”的一种；

• 用户U05的账单由账户A07付费。

尽管都可以写成“主语-关系-宾语”的三元组。但两个表示的层次不同：

这很好理解，类似面向对象中的“类”和“对象”的关系。

但是两者必须一起出现吗？

答案是不一定。

一个小的知识图谱可以没有严格的本体定义，只使用简单的节点和关系。但随着图谱越来越大，不同团队的理解可能出现分歧，这时会采用本体来统一含义。

本体也可以脱离知识图谱单独存在，仅用于业务建模、系统设计和定义数据标准；但不能用于具体事实的判断和推理。

两者也可以配合使用：本体提供概念和规则，知识图谱（可能配合关系型数据库）保存具体事实。 本体让知识图谱数据更容易被一致地理解，知识图谱则让本体能够用于查询和推理。

05 本体怎么表达呢？有哪些标准？

接下来的问题是：这些本体的定义怎样写出来，机器才能读懂？作为初学者，我们可以先了解下面几个语义表达的标准。

RDF/RDFS：定义概念及其基本关系

RDF 提供最基础“主语—关系—宾语”的三元组结构；RDFS 在此基础上补充类、属性、上下级等语义。例如，我们想在本体中表达：

“用户”和“产品”是两个业务概念，“订购”是从用户指向产品的一种关系。

关系图可以简单表示成：

用户 - 订购 - 产品

在正式的RDF/RDFS表示中，可能是这样定义（简化）：

# 定义两个业务概念
tel:用户 rdf:type rdfs:Class .
tel:产品 rdf:type rdfs:Class .

# 定义“订购”关系：
# 关系从“用户”指向“产品”
tel:订购
    rdf:type rdf:Property ;
    rdfs:domain tel:用户 ;
    rdfs:range tel:产品 .

它定义的是业务概念之间的关系，并不是说某个具体用户已经订购了某个产品，更不表示所有用户都订购了所有产品。

OWL：定义更复杂的逻辑关系

如果还要表达传递（服务A包含B，B包含C，则A包含C）、互斥（用户不能既是预付费又是后付费）、限制等逻辑语义，就需要 OWL。例如：

一张产品订单必须关联一个，而且只能关联一个目标产品。

那么大致的定义方式如下：

# 每个产品订单必须关联且仅关联一个产品
tel:产品订单
    rdfs:subClassOf [
        rdf:type owl:Restriction ;
        owl:onProperty tel:目标产品 ;
        owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
        owl:onClass tel:产品
    ] .

这里描述的是针对产品订单的一个限制：

• onProperty 指出限制针对“目标产品”这个属性

• qualifiedCardinality 1表示必须有且只能有一个

• onClass表示目标产品的类型是“产品”

其他一些常见的标准有：

• SKOS：主要用于统一术语定义。比如：“增值业务”和“VAS”一个意思

• SWRL：用来在 OWL 基础上定义业务规则，从而能够基于已有事实推理出新事实。比如：“欠费账户 -> 不可受理的订单”

• SHACL：用来检查数据是否符合定义的约束，类似程序中的校验规则

• SPARQL：本体中的SQL，用来查询和更新 RDF

本体涉及的标准较多，有一定门槛，而且同一业务语义有时可以用不同方式表达。好在实际项目中借助建模工具和 AI ，一般不必手写复杂语法；但了解各项标准大致解决什么问题是有必要的。

06 一个最小的领域业务本体长什么样？

在了解了本体的一个表达“语言”后，现在我们把语法放到一边，来搭建一个最小的电信客户运营领域的本体，建立更具体的印象。

基本概念和关系

首先来画这个本体的骨架 — 业务概念与关系图（部分）：

注意图中没有“用户U05”这样的具体数据，它描述的是电信客户运营的业务世界的部分结构。

一个可用的本体还需要为各类概念定义必要的数据属性，例如资源的状态、账户的余额、订单的创建时间等，并说明这些属性的类型、是否必填等。

但你不必复制数据库里的全部字段，只需要纳入那些对业务理解、查询、校验和推理有价值的属性，否则就变成另一份数据库设计。

此外，还可以补齐下面的一些定义。

层次与关系约束

比如，我们在本体中进一步定义：

• 个人客户、企业客户、VIP客户都属于客户

• 个人客户和企业客户必须互斥

• 新装订单、变更订单和退订订单都属于订单

• 每个产品采用一个资费套餐

• 每张账单包含至少一个费用项

等等。这些规定描述的也是业务本身，而不是某一条具体业务数据。

数据校验规则

可以定义一些针对事实数据的检查规则。比如：

• 一个用户不能使用多个号码

• 手机号码必须符合某种格式

• 订单产品价格必须 >= 用户等级最低价

数据校验规则与前面的关系约束在某些时候会很像（比如，每个账单至少要有一个费用项）；但数据校验规则是用来校验具体数据；而关系约束只是用来描述一种固定的关系。

业务控制规则

定义两条可以推导业务结论的规则：

• 用户订购的产品采用5G资费套餐，则该用户被识别为5G用户

• 用户的费用账户欠费，且提交了任意订单，则该订单不予受理

至此，这个小本体已经包含概念、关系、层次、约束、数据校验和条件规则等。

如何测试建模

初学者可使用 WebProtégé 在浏览器中创建类、属性和关系，无需安装软件；需要本地推理和更多插件时，可使用Protégé Desktop。模型可以导出为Turtle、RDF 或 OWL 文件，或者存入专门的数据库，如 GraphDB。

我最建议的方式是：

先让 AI 根据上述定义生成模型初稿，然后导入Protégé检查。AI可以代写语法，但具体是否符合实际业务，仍需要业务人员确认。

我们把上面的本体用AI生成并导入 Protégé：

07 这个最小本体怎么在 Agent 中使用？

搭好了一个本体模型，下一个问题自然是如何使用。你不能简单的把一个 OWL 文件或图数据库交给 Agent，就指望它立刻就无所不能。

首先的问题是：你需要把本体中的概念与企业系统“连接”起来。比如：

号码资源对应到资源系统中的数据，账单来自计费系统，订单则在CRM系统中产生 — 本体负责业务语义；业务系统负责提供数据；Agent 负责控制逻辑。

现在我们假设有一个 Agent 任务：

给号码 13688888888 的用户更换 299 元 5G 套餐；如果不能办理，请告诉我原因。

任务看似简单，但实际涉及多个业务对象间的复杂关系。号码资源、用户、产品、资费、订单及其关系和相关约束。

Agent 按照如下流程结合本体做处理：

简单说明如下：

1. LLM理解用户意图
   LLM 可以判断，用户希望为指定手机号码办理套餐变更，目标是299元的5G套餐，需要启动订单流程。

2. 触发订单前置检查
   根据约束（如Skill、工具描述、Workflow定义），Agent 必须进行前置的订单检查，于是需要调用“订单前置检查”的工具。

3. 订单前置检查工具

完成如下一系列的任务：

借助本体对齐业务含义

此时，Agent 将自己的理解与本体进行对齐：

• 手机号码属于号码资源，由用户使用；

• “299元套餐”属于资费套餐；

• 资费套餐由产品采用，而订单办理的是产品。

Agent 据此确定关系路径和需要取得的数据：

号码资源 ← 使用 — 用户 — 费用计入 → 账户

用户 — 提交 → 订单 — 办理 → 产品 — 采用 → 资费套餐

这些路径不是 LLM 依靠常识就能可靠得到的，属于企业自身业务定义。

从业务系统取得事实数据

基于数据映射规则（本体可以定义），调用业务系统接口查询到：

• 号码 13688888888 由用户 U05 使用

• U05 的费用账户是 A07，当前处于欠费状态

• 299 元资费套餐对应产品 P299

这些具体数据来自业务系统，不是本体推理出来的。

装入事实并执行本体推理

将事实数据按本体关系组织起来，增加一个待办订单 O01，注入本体。

本体推理机（开源或者数据库内置）先通过数据校验规则检查数据完整性，然后推理得到：

• A07 属于欠费账户

• U05 的费用计入 A07

• U05 准备提交 O01

• 因此O01属于不可受理订单

在完成以上逻辑后，工具返回结果给 Agent。

4. Agent 决定是否执行

Agent 根据推理结果，决定不启动真实的订单流程，而是回复：

号码13688888888对应的费用账户当前欠费，按照订单受理规则，暂时不能办理套餐变更。可以先查询欠费账单或完成缴费。

在这个过程里，我们可以看到一个大致的分工：

• LLM 负责听懂用户的大致意图

• 本体负责对齐业务概念，理解关系

• 业务系统负责提供真实数据

• 本体推理负责得出确定性结论

• Agent 负责把这些能力串联起来

所以，本体在这里并不是替代 LLM 思考，而是补上 LLM 仅凭通用知识无法可靠掌握的业务知识。

08 如何判断我的 Agent 是否需要本体？

每次新的技术概念出现，很容易出现“拿着锤子看谁都像钉子”的情况 — 拿本体去套用所有的 AI 应用。

所以在你决定采用本体之前，先停下来问自己几个问题：

不同系统中的相同业务概念是否存在歧义？

例如，企业 CRM 系统中的“客户”指签约主体；而另一套客服系统中的”客户”可能就是来电人。如果只是帮助员工理解这些术语，一份数据字典或 Wiki 可能足够；但如果多个 Agent 系统需要对齐这些业务概念，本体就会体现出价值。

复杂的关系是否需要跨场景反复使用和推理？

查询某个账户的余额，直接调用查询工具即可完成 — AI 不需要理解账户与其他概念之间的关系。

但如果要回答“某个号码为什么不能更换5G套餐”，就需要连接号码资源、用户、账户、产品、资费和订单，再根据订单规则得出结论。

如果只有这一个复杂场景，你可以用聚合接口封装这些查询和判断；

但如果这组业务关系还要被多个 AI 场景反复组合使用：比如 AI 要回答：

• 某个号码的费用由哪个账户支付；

• 一个欠费账户会影响哪些用户；

• 某个用户正在使用哪些产品，如何计价；

• 一款产品的资费调整会影响哪些用户和订单。

这时候就可以考虑本体 — 这些场景都需要理解同一批业务知识。

同一套业务知识是否需要被多个 Agent 系统共享？

客服 Agent、营销 Agent 和风控 Agent 等，都可能需要理解客户、用户、账户和产品等概念及区别，也都可能需要处理“用户如何找到付费账户”、“订单如何关联产品”等关系。

如果每个 Agent 都通过提示词/Skill 等分别解释一遍，不仅重复，也很难维护一致性；此时用本体提供共享的业务知识就很有意义 — 统一建模、集中维护。

业务判断是否需要说明来源和依据？

这来自于 AI 应用中常见的可解释性、可追溯性问题 — 当你让 AI 润色一篇文章，你可以不关心它为什么这么写；但当 AI 告诉你“此类业务办理失败”，你一定想得到一个确切的答案。

因此，在关键业务环节，借助本体来理解与判断，可以让 AI 更确定的说出完整的决策证据和推理链。

因此，使用本体不只是因为“业务复杂”，更不是“技术先进”。你需要仔细评估上述问题的答案，再结合自身的客观条件（建模与维护能力等）作出决策。

09 企业如何开展本体建模和应用？

即使你决定采用本体，也不必一开始就建设覆盖全部业务的“大本体”。更实际的做法是选择一个价值明确的场景，从具体业务问题出发，边建模、边连接数据、边验证效果，构建出“最小可用本体”后，再尝试扩大业务场景和领域：

如何构建一个“最小可用本体”？

1.选择业务场景做“切入口”

选择一个范围清晰、价值明显的业务领域，确定一个具体的业务问题作为“切入口”，构建“最小可用本体”。

例如，选择“套餐变更”这个场景，构建 Agent 应用能力。

2. 列出业务能力问题

明确 Agent 应用必须回答哪些问题。比如：谁在使用这个号码？费用由谁支付？当前订购了什么产品？当前什么资费？为什么不能办理某个套餐？

这些业务能力问题决定模型需要包含什么，也用于后续验收。

3. 统一业务概念和边界

让相关业务部门与专家共同确认评审术语的含义、边界和例外。例如，“客户”、“用户”、“订单”、“账单”分别指什么、有哪些业务关系、个人客户与企业客户是否互斥、套餐变更有哪些业务约束条件、VIP 客户有什么特权等等。

4. 建立最小的业务知识模型

只定义回答业务能力问题所需的概念、属性、关系、约束和规则，同时保留必要的标识、来源与有效时间。

最小不是越少越好，而是刚好能够支撑一个完整的业务场景所需要的业务能力；覆盖所有相关的业务知识。

5. 映射真实的业务数据来源

明确每个业务概念的数据来自哪个系统、通过什么接口取得；以及同一概念存在多个可能的来源时，以哪个系统为准。

例如，账单来自计费系统；但用户信息与关系来自CRM系统。

6. 从只读应用开始拓展能力

先让应用基于本体完成查询、关联、判断和原因解释类的业务能力；等准确率稳定后，再逐步开放低风险、可审批、可回滚的业务操作能力。

例如，可以先让 Agent 学会分析订单的影响，再考虑允许它提交订单。

7. 用业务结果验收“最小可用本体”

本体只是手段，不是目的。因此验收不要只统计建立了多少业务概念和关系，更多的要看业务处理性能、判断准确率等是否得到改善。

而业务负责人则需要持续确认概念和规则；架构师负责维护模型、数据映射和版本；源系统负责人保证数据质量等。

当一个小模型真正进入业务流程并产生效果后，再沿着相邻问题逐步扩展。

先向同一个业务领域内的其他不同业务场景与流程扩展，纵向整合本体模型，最终构建出本业务领域的完整模型；

接着可以尝试打破领域的边界，实现横向跨领域的语义贯通。比如，不再满足于客户运营，而会与市场营销、产品规划等领域本体进行连接和对齐；

总的来说，本体的价值，就是画一张人和 AI 都能看懂的业务地图 — 适合业务概念多、关系复杂、系统林立的企业应用环境。

但本体不是万能药，更不应为了追逐技术热点轻易搞“大工程”。认真评估业务需求、数据基础和模型维护能力，量力而行，从小切口场景起步，用业务效果验证价值，再逐步迭代演进。