你甚至不需要看见一只狗。
隔着一堵墙听到“汪汪汪”，你就知道那边大概率是一只狗；听到“喵喵喵”，你会立刻想到猫。真的看见它们时，这个判断也不会因为毛色、大小和体型不同而轻易改变。
一只柯基腿很短，一只灵缇又高又瘦，一只藏獒满身长毛。它们看上去差别很大，我们仍然知道它们都是狗。
我们究竟识别出了什么？
如果用工程语言描述，这个过程很像一次“特征提取”。
我们识别狗，并不是依靠某一个固定特征。四足行走的身体结构、突出的吻部、头部轮廓、耳朵和尾巴的位置、身体比例，以及站立和运动时的姿态，会共同形成“狗的整体轮廓”。声音、动作和生活经验又提供了更多线索。
单独拿出其中一个特征，往往都不够。猫也有四条腿，狐狸也有突出的吻部，有些狗没有长尾巴。但多种特征组合在一起，我们就能判断眼前的东西“是什么”。
本体要把“它是什么”说清楚
这正是本体论长期追问的问题之一。
亚里士多德在《范畴篇》中区分了实体、数量、性质、关系、地点、时间、动作等范畴。我们不需要记住全部十个名称，只需要抓住其中最重要的区别：一件东西本身是什么，它有哪些特征，又与其他东西存在什么关系。
人可以凭经验完成这个判断。工程上的本体，则要把这套原本存在于人脑里的理解明确写出来，让机器也能使用。
如果只用一句话解释：本体是一套让机器知道“这是什么”的语义模型。
本体把数据库里的值投射成现实对象
来看下面这组数据。表名和表头都被拿掉了，身份证号码也做了脱敏：
张志敏｜男｜15岁｜110101********3219
20240018｜高一三班｜171cm｜58kg
李雨桐｜女｜14岁｜320102********8624
20240029｜高一三班｜162cm｜47kg
王浩然｜男｜15岁｜440106********3517
20240036｜高一四班｜176cm｜63kg
陈思妍｜女｜14岁｜330102********4826
20240042｜高一四班｜159cm｜45kg
即使没有表头，大多数人也能判断：这是一组学生信息。
原因和认出猫狗很像。姓名、年龄、身份证格式、八位学号、“高一三班”这样的班级名称、身高和体重组合在一起，形成了非常明显的学生数据特征。
但数据库本身只保存了一组值。20240018 在数据库里只是一个字符串，高一三班 也只是另一段文本。它们不会主动告诉大模型：前者是学号，后者是班级；这一整行描述的是一个学生；这个学生与某个班级存在“属于”的关系。
本体层做的，就是把这些值投射到真实业务世界里：
- 这组数据属于“学生”这个类；
- 每一条记录对应一个具体学生，也就是一个实体；
- 姓名、性别、年龄、学号、身高和体重是学生的属性；
- “张志敏属于高一三班”是学生与班级之间的关系；
- 学号怎样保持唯一、学生怎样分班、学籍状态怎样变化，属于相关的约束或业务规则。
经过这层映射，大模型看到的就不再是一堆互不相干的字符串。它看到的是学生、班级、属性、关系和规则共同组成的业务世界。
可以把这个过程简单写成：
数据库中的原始值 → 本体层中的业务对象与规则 → 大模型能够理解和使用的业务语义
大模型当然也可能仅凭上下文猜出这是一张学生表。但一次猜对，不代表每次都能得到同样的理解。字段换了名字、数据来自另一套系统、同一个状态码在不同部门含义不同时，临场猜测很容易漂移。
本体的价值，是把一次猜测变成一套稳定、共享、可以审核的语义约定。它是数据与大模型之间的语义桥梁。
大模型为什么不能直接读取业务数据库
前面讲的是数据库里的原始值怎样经过本体获得语义，再交给大模型使用：
业务数据库 → 本体 → 大模型
真正查询数据时，调用方向正好反过来：
大模型 → 本体 → 业务数据库
比如用户问：“高一三班有哪些学生选了数学课？”大模型理解了这句话，却不一定知道学生表叫什么、班级字段里存的是什么、选课关系又该怎样连接。即使把完整表结构交给它，状态码、历史字段和各部门的使用习惯，也不会自动变成清楚的业务含义。
本体层负责完成这次转译。它先把用户的问题落到“学生、班级、课程、选课”这些业务对象和关系上，再把它们转换成受控的数据查询。
这里最关键的一步，就是给字段组合赋予业务语义：
姓名 + 学号 + 班级字段 → 学生 班级编号 + 年级 + 班主任字段 → 班级
如果大模型绕过本体，直接获得数据库连接和自由 SQL 权限，风险不只在“查不准”。模型也可能生成超出问题所需的语句；当数据库账号权限过大时，UPDATE、DELETE 甚至 DROP 都可能改变或破坏业务数据。
所以本体层还承担第二件事：把开放式的自然语言请求，收窄成预先定义的对象、关系、查询和动作。大模型不直接拿数据库的钥匙，而是通过“查询学生”“查找班级成员”这类受控接口读取数据。
需要说明的是，本体本身不会自动拦住一条 DELETE。真正的安全还要靠只读账号、查询白名单、参数校验、权限控制和审计。但本体给这些控制提供了稳定的落点：系统能够知道大模型正在访问哪个业务对象、允许执行哪些动作、哪些数据不应该返回。
因此，两条链路说的是同一层本体的两个作用：
- 业务数据库 → 本体 → 大模型：给数据赋予语义；
- 大模型 → 本体 → 业务数据库：让数据读取受到控制。
从数据库看，一张业务表可以先理解成一个类
从这个角度再看关系数据库，很多东西会变得直观。
在一个设计相对清楚的业务数据库里，我们可以先做这样的浅显理解：
| 数据库里的结构 | 本体中的概念 |
|---|---|
| 一张学生表 | 学生类 |
| 表中的一行 | 一个学生实体 |
| 姓名、学号、身高等字段 | 实体的属性 |
| 外键或关联字段 | 实体之间的关系 |
| 唯一性、状态流转等业务逻辑 | 约束或规则 |
Palantir 的官方文档也用了非常接近的类比：Dataset 对应 Object Type，Row 对应 Object，Column 对应 Property，Join 对应 Link Type。
这正是“一张业务表可以先理解成一个类”的依据。学生表存放学生，班级表存放班级，课程表存放课程。因为它们描述的对象不同，所以会被放进不同的表，也会被映射成不同的类。
那学生选课表怎么办？
它同样可以有自己的业务含义。每一行描述的是“某个学生在某个学期选择了一门课程”这件事。我们可以把它理解为一种选课关系，也可以把“一次选课”建成一个独立的关系类或事件类。表分开了，恰恰说明它描述的主体已经发生变化。
所以在入门阶段，我们完全可以沿着这条线理解本体：
表对应类，行对应实体，字段对应属性，表之间的连接对应关系，处理这些数据的业务逻辑对应规则。
这里说的是业务表的概念映射。报表宽表、临时表和纯技术日志会有自己的处理方式，但不影响这套理解帮助我们快速入门。
一个业务数据库里有很多张表，也就意味着它描述了很多类业务对象。把这些类、实体、属性、关系和规则连接起来，就逐渐形成了这个业务领域的本体。
为什么本体项目里经常出现知识图谱和 GraphRAG
理解了上面的映射，知识图谱就不会显得突然。
当本体只有一个“学生”类时，用一张表就能看清。但业务世界里还有班级、教师、课程、考试和证书。学生属于班级，教师管理班级，学生选择课程，考试产生成绩。这些对象一多，关系就会迅速变复杂。
知识图谱很适合表达这些连接：
张志敏 ──属于──> 高一三班
高一三班 ──班主任──> 李老师
张志敏 ──选择──> 高中数学
本体规定有哪些类、属性、关系和规则；知识图谱把具体实体和它们之间的关系组织起来。规则引擎或约束校验可以进一步判断哪些状态允许出现、哪些关系能够成立。
当大模型要回答“高一三班有哪些学生选了数学课”时，还需要从这些对象和关系中找到相关信息。普通 RAG 可以从文档中检索文本，GraphRAG 则更擅长沿着图中的实体和关系寻找上下文。
因此，知识图谱、规则引擎、RAG 和 GraphRAG，都可以成为本体系统周围的技术手段。它们解决的是怎样存关系、执行规则和找到信息；本体负责的是更前面的一步：先说清这些数据在业务世界里究竟代表什么。
所以，本体到底是什么
再回到开头。
我们听见叫声、看见外形，会从一组特征中判断“这是猫”或“这是狗”。看到没有表头的学生数据，我们也会从姓名、年龄、学号、班级等特征中判断“这是一组学生信息”。
人脑可以在一瞬间完成这种语义投射。本体工程所做的，是把这件事变成机器可以读取、共享和执行的模型。
本体，就是一套把数据库里的值投射为现实业务对象的语义模型。
它告诉机器：这是什么类，每条记录是谁，字段表示什么，对象之间怎样关联，业务规则怎样成立。
数据库负责保存数据，本体负责解释数据，大模型再基于这种解释去查询、推理和回答问题。
这就是本体在 AI 时代重新受到关注的原因。大模型通常不缺语言能力，但进入企业业务以后，经常缺少那套“大家都懂、却从来没有明确写出来”的业务语义。
下一篇，我们继续看 Palantir 怎样把这层本体从“解释数据”，进一步连接到业务逻辑、权限和行动。