为什么业务本体更便于 AI 使用？从一张排课表讲起

先让 AI 看看这张表，它已经知道什么？

我们先不提本体，直接看数据。排课表中有下面这样一行：场次 S17，课程 C04，教室 R301，周日 14:00–16:00 上课，状态为 1。AI 可以读懂表头，也可以把某列取出来、按条件筛选；如果给它数据库查询工具，它还可以生成或调用 SQL——一种用于查询表格数据的语言。

但一个会读表的人，也未必知道这行记录背后的全部业务。“状态 1”是已发布、已开始，还是已结束？C04 是整门摄影课程，还是一次具体授课？R301 和维修系统写的“东楼三层大教室”是不是同一个地方？这些问题并不是靠读取更多行就一定能解决。

AI 可能根据列名作出合理猜测，也可能因为拿到了字段说明而答对。问题在于，换教室会影响真实排期，我们希望它使用已经确认的答案。于是，第一步不是换一个更会猜的模型，而是把这些本来由工作人员掌握的含义明确提供出来。

本节事实核查：官方资料 [14]

先确定“它是谁”：编号要对应稳定的业务身份

“摄影基础课”是一门课程，周日下午的那一场授课只是这门课程的一次安排。它们应该分开：课程 C04 可以每周开课，每一场都有自己的编号、时间和教室。取消 S17，不应该连下周的课也一起取消；修改课程名称，也不应该让以前的报名找不到归属。

在本体中，“课程”“场次”“教室”“报名”分别可以定义为 Object type，即对象类型。“401 教室”则是“教室”类型里的一个具体 Object，也就是对象。具体对象有稳定的身份，通常用主键标识；主键就是能够唯一认出它的编号，不能只靠一个可能重复或被修改的名称。

如果排课系统用 R301，维修系统用 EAST-3-01，却都表示东楼 301 教室，实施人员要建立准确的对应。这样，“投影仪损坏”的维修记录才能归到正确的教室对象上。这个对应关系不是 AI 看见两个相似名称后自行认定，也不是一启用 Ontology 就自动出现。同一对象可以由多个来源共同描述，因此也不能机械地把每张表原样做成一个对象类型。需要先认清业务里的事物，再决定怎样把资料对应过去。

这一步减少的是身份上的猜测。之后再问“301 的故障影响了哪一场课”，人、页面和 AI 可以指向同一个教室、同一个场次。至于这间教室目前能否使用，还需要解释它的属性。

本节事实核查：官方资料 [2]官方资料 [14]

再说明“它是什么情况”：状态值不能只留一个数字

Property 是属性，用来描述对象的特点。例如教室有名称、座位数、设备状态；场次有开始时间和授课状态。属性不只是一个字段名，还应有明确含义：座位数统计固定座位还是允许临时加椅子后的总数？时间属于哪个时区？设备状态来自哪次检查？

同一个数字，在不同表里完全可能有不同含义。在这个案例里，排课表的状态 1 表示“已发布”，维修表的状态 1 表示“故障尚未处理”。把它们都改名为“状态”并放到一个界面里，仍然不够。本体的属性定义和数据转换需要把各自的含义说清，让使用者读到“场次已发布”和“投影仪故障待修”。

还有一个更容易出错的数字：报名表一共有 28 条记录，但其中 2 条已取消、1 条尚未付款，实际确认参加的只有 25 人。如果 AI 直接数行，它会得到 28；如果有人把“有效报名”的定义明确为“已付款且未取消”，系统就可以按这条规则得到 25。对于选教室，究竟采用哪个人数，是业务决定，不是算术决定。

数据更新也必须被考虑。昨晚的“设备正常”无法证明现在仍正常。一个设计完整的流程会保留来源和更新时间；当维修资料尚未到达时，返回“状态待确认”，而不是把没有查到故障当成正常。业务模型让含义更明确，不能让陈旧或错误的输入自动变真。

本节事实核查：官方资料 [12]官方资料 [1]

把“它和谁有关”写清楚，查询才有确定路径

现在我们知道课程、场次和教室分别是什么，也知道几个关键属性是什么意思。接下来要回答：哪些报名属于 S17？它原来安排在哪间教室？是哪一条维修记录影响了上课？这就需要关系。

Link type 是关系类型，它定义两类对象怎样相连。例如“场次属于课程”“报名对应场次”“场次安排在教室”。具体的一条关系则是“S17 属于 C04”或者“S17 安排在 R301”。它不仅表示两个编号可以对上，还明确了这条连接在业务上代表什么。

如果只给几张没有说明的表，AI 可能要猜哪些字段可以连接，或者每次重新生成表连接查询。有时它猜对了编号，却把“教室平时的管理员”当成“这场课的负责人”。把两种关系分别命名和定义，就能避免把看起来都与人员有关的信息混为一谈。

当对象与关系建好，并通过查询工具提供给 AI 后，取数过程就可以沿确定路径进行：先找到 S17，再取它的有效报名，再读它安排的教室与设备状态。这不是要求 AI 盯着一张漂亮的关系图“看懂业务”，而是让软件实际提供可调用的对象与关系查询。图只是帮助人理解这套结构的表现方式。

这些定义先帮助的是人。新来的教务同事不必反复追问“这列状态是什么意思、哪张名单才算有效”；原来的分析人员离职后，已经定义的查询和规则也仍可供团队使用。AI 复用的，正是这份原本就应该由团队共同掌握的知识。

本节事实核查：官方资料 [13]官方资料 [11]

知道事实之后，还要把“合不合适”变成可计算的规则

我们已经确认：S17 在周日 14:00–16:00 上课，有 25 名有效报名学员，需要投影仪。下面是当时查到的三间备选教室。即使 AI 能把它们准确列出来，也还没有完成选择；我们需要说明什么叫“合适”。

在这个案例里，合适意味着上课时段空闲、座位不少于 25 个，并且投影仪正常。因此，302 太小，501 的设备不满足要求，401 才满足这三项条件。座位比较可以由程序计算，无须让语言模型根据“宽敞”“设备齐全”之类的介绍词猜测。

这样的计算可以组织成 Function，也就是可重复调用的函数。这里的函数不必理解成复杂公式，它可以就是“输入场次，返回符合条件的教室”。页面、排课助手和 AI 都可以调用同一份逻辑。若教务部门以后要求额外预留两个座位，也有一个明确的地方维护这项判断。

于是，AI 少承担了一类原本容易出错的工作：每次从文字里临时推导人数定义、座位要求和设备条件。它可以使用已经实现的计算结果，再向人解释推荐理由。不过，函数是否正确、规则是否完整，依然取决于实现；如果还有无障碍通行要求却没有写进去，选出的教室仍可能不适合。

本节事实核查：官方资料 [11]官方资料 [1]官方资料 [15]

“推荐 401”与“已经换到 401”，中间还差一个动作

到这一步，AI 可以说：“推荐 401，因为它空闲、有 30 个座位且投影仪正常，能容纳 25 位学员。”但这句话不会自动改变排课。真正改动业务记录，需要一个明确的操作，例如“更换场次教室”。

在 Palantir 中，Action type 是动作类型，即一种可反复使用的操作定义；Action 是按这份定义实际执行的一次动作。更换教室的定义需要包含目标场次、新教室、变更原因，以及提交时重新检查的条件。确认成功后，它修改 S17 与教室之间的关系，并记录相应信息。

为什么提交时还要再检查？因为从 AI 推荐到负责人点击确认之间，401 可能已经被另一场课占用。正确流程不能只说“推荐时是空的”，而要在执行前再次确认。对于已结束的场次，通常也不能再按普通“换教室”流程修改。这些允许或拒绝的条件，需要明确定义。

官方把一次动作中的本体修改描述为一个事务，可理解为把规定的相关修改放在一次明确提交里处理。短信通知、外部排期系统等步骤仍有各自结果：可能教室关系已经改好，三条短信却未送达。此时应保留正确的新安排，并继续处理通知，而不是把全部过程压成一个含糊的“成功”或“失败”。

本节事实核查：官方资料 [3]官方资料 [16]

谁有权改变安排，也应该由系统检查

推荐是否合理，与谁有权确认，是两个不同问题。在这个例子里，助教可以查看场次并提出换教室申请，课程负责人可以批准，客服可以读取用于通知的联系方式。这些权利不应因为有人能够打开一个页面，就全部同时获得。

本体可以配置对象和属性的读取限制：助教也许能知道有 25 位学员，却不能看到每个人的手机号。动作还需要相应权限和提交条件。AI 通过工具读取或修改资料时，同样要使用获得授权的身份，并接受工具与平台的检查。

因此，“AI 知道可以换教室”不意味着“AI 可以自行更改”。如果流程要求负责人批准，就要在批准前停留在建议或申请阶段。授权之外的数据和动作，不能靠模型在回答里声称“我已完成”就变成事实。

权限也不是只在本体页面里考虑一次就结束。若把联系方式导出成表格，或者把结果送往其他系统，还要由相应的共享和导出控制继续约束。业务模型让权限有可以配置的落点，实际能保护到哪里仍取决于完整流程。

本节事实核查：官方资料 [9]官方资料 [16]官方资料 [15]

回到最初的问题：这一次，AI 可以怎样工作？

现在重新问：“周日下午摄影课的投影仪坏了，能不能换教室并通知学员？”经过配置的 AI 流程可以先找到 S17，读取 25 名有效报名学员和设备要求，再调用筛选教室的函数，得到 401。它据此生成解释，并把换教室方案提交给有权的负责人。

负责人确认后，流程调用更换教室动作。动作再次核对时段和权限，提交变更，然后按配置发起通知。AI 最后应根据实际结果回复，例如“已改为 401；22 人通知成功，3 人待补发”，而不是把“我建议这样做”表述为“我已经做完了”。

和最初只给一张排课表相比，模型获得的并不是一份更长的神秘提示词。它得到了明确的业务身份、解释过的属性、已定义的关系查询、可复用的计算，以及受约束的操作入口。原本需要临时猜测的许多内容，已经由业务人员和工程人员事先确认并实现。

AI 仍要理解用户意图、选择合适工具、处理缺失信息并解释结果。因此不能保证它永远不犯错。但我们已经能看清：哪些判断来自模型，哪些来自数据查询，哪些由规则计算，哪些必须由人确认。错误也更容易被定位到具体一步。

Palantir 官方用数据、逻辑、动作和安全四部分来概括这套设计。放回故事里：25 名有效学员和教室状态是数据；筛选合适教室的条件与计算是逻辑；实际更换场次安排是动作；谁能读取信息、谁能批准修改，是安全规则。它们共同支撑一次决定，而不是四个互不相关的名词。

本节事实核查：官方资料 [11]官方资料 [3]官方资料 [15]

这与 OAG、RAG 有什么关系？

RAG 的全称是 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。意思很直接：先查到与问题相关的外部资料，再让模型结合资料回答。例如有人问“换教室要提前多久通知”，系统先找出教务制度里的对应条款，再解释给他听。

OAG 的全称是 Ontology-Augmented Generation，可以译为“本体增强生成”。Palantir 用这个说法强调，把本体里的业务数据、逻辑和动作用于 AI 流程。前面从场次查询、人数计算，到获批后的换教室操作，就是为帮助理解而设计的一种本体增强工作方式。并不存在一个名为“OAG 文档”的独立产品；那是指官方介绍这种方法的文档。

不要把两者记成“RAG 只能读文本，OAG 才能读业务数据”。RAG 可以结合多种数据来源，也可以与工具调用配合；OAG 流程同样可以检索制度文档。区别在这篇文章里的关注点：除了找到资料，还把资料放回具体业务对象及可用操作中。两种方法可以共同使用。

例如，决定哪间教室合适，需要当前人数、排期和设备状态；说明应该怎样通知学员，可能需要一段制度文本。一个完整流程可以同时取得这两类依据。官方 OAG 文档也强调检索方法要随具体数据和问题选择，没有对所有任务都最好的固定方案。模型回答不对时，首先要确认正确资料是否真的被取到并交给它。

把这类信息和逻辑做成可复用资源，还可能减少每次请求中重复解释业务的篇幅与计算工作。但不应据此保证费用或响应时间一定下降：检索与工具调用也有成本，实际效果要看任务、数据量和实现方式。AI 是否掌握上下文，取决于这一请求实际获得了什么信息，不能仅凭“接入了本体”判断。

本节事实核查：官方资料 [5]官方资料 [10]

把表和接口说明完整，不也能做到吗？

能。AI 并不是不能理解数据表。本体背后的资料也可能来自数据表。如果数据库已经有准确的字段说明、业务含义、可靠的关联，以及封装好的查询、计算和操作接口，再加上权限和审核流程，也可以支撑刚才的换教室工作。

所以，公平的比较不是“表格很笨、本体聪明”，而是这套额外的业务知识怎样组织、维护并供人使用。Palantir 把对象、关系、函数、动作和权限放进一套相互配合的产品能力中，让多个应用和 AI 工作流程可以使用。收益来自已确认的知识和规则被反复复用，而不是把数据行换个名字叫对象。

知识图谱主要帮助表达实体和关系，也可以结合规则与操作系统；数据库也有触发器等执行逻辑的机制。这些技术并非天然对立。读原文里“本体不仅是数据库或图谱”的说法时，应理解为它强调了业务操作、权限和持续使用，而不能推导出其他技术绝对无法做到。

哲学中的本体论研究存在的基本类别；信息系统中的本体借用了对事物进行明确分类和关联的思路。Palantir Ontology 是具体的业务产品实现。对于本篇的理解目标，抓住“把业务含义和可用操作明确提供给人、应用和 AI”就够了，无须先掌握哲学术语。

本节事实核查：官方资料 [1]官方资料 [15]官方资料 [4]

业务一直在变，这份模型也要继续维护

故事还没有结束。下个月，课程开始允许两名讲师共同授课；“场次负责人”可能需要与“授课讲师”分开。团队就要调整对象关系、通知和批准规则。官方提供本体分支，让相关资源在独立版本中修改，再通过提案评审。这解决的是模型如何安全改变的问题。关键对象还可以按权限和资源保护规则要求评审，避免每个人都直接改正式定义；这需要配置，并非所有环境自动开启。

如果负责人只是想比较“把两场课合并会怎样”，则是另一种需要。Ontology scenarios，即本体情景，提供隔离的假设分析空间，可以尝试修改对象数据并运行已有计算，暂不直接改变正式排期。它不能自动推导未配置的成本或冲突规则。官方目前仍标为 Beta，也就是测试阶段，并明确它不是保存某个历史时刻的快照工具。

真实操作的记录也有不同用途。Action log（动作日志）可按配置记录成功提交的动作，例如谁在什么时候确认了换教室，并关联受影响的对象。它不记录所有失败，也不等于每个来源的完整编辑历史；这些问题需要相应的动作指标、编辑历史或外部系统记录来回答。

回看整个例子，本体没有自动替我们知道哪门课要用投影仪，也没有自动发现数据错误。它做的是为这些已经确认的业务知识提供一种可维护、可调用的组织方式。定义越清楚，多个页面和 AI 越少需要各自猜测；定义遗漏或来源失真时，再完整的工具体系也仍需要人去修正。如果只是把所有原始字段和难懂编号原样搬过来，模型仍会保留原系统的混乱。通常从一个范围较小、每天真正有人使用的业务开始，团队更容易发现定义遗漏，并逐步修正。

本节事实核查：官方资料 [7]官方资料 [8]官方资料 [6]

适用边界与容易误解的地方

术语速查

Ontology

把业务对象、关系、计算和操作连接起来，让应用与 AI 共用的业务模型。

对象类型

一类事物的定义，例如“教室”；301 教室则是具体对象。

Action type

一种操作的定义，说明输入、检查条件和要发生的修改。

OAG

本体增强生成：把本体中的业务信息与可用能力用于 AI 工作流程。

RAG

检索增强生成：先找出与问题相关的外部资料，再让模型据此作答。

Ontology scenarios

在隔离环境中尝试假设变化，比较方案对对象数据的影响。

来源与核查

对应原文

Rahul Garg · 2026-07-02 · Vanyar

1. Palantir：Ontology building核对产品本体的基本组成。
2. Palantir：对象类型核对类型、实例与业务实体的关系。
3. Palantir：Action types核对对象变更事务与动作定义。
4. PostgreSQL：触发器说明数据库也能执行逻辑，避免绝对化比较。
5. Palantir：Ontology-augmented generation核对上下文检索及按场景选择方法的原则。
6. Palantir：Action log核对日志需启用且仅记录成功动作提交。
7. Palantir：本体分支核对分支、评审与资源保护前提。
8. Palantir：Ontology scenarios核对情景用途、Beta 状态及非历史快照边界。
9. Palantir：对象和属性安全策略核对读取控制与下游导出边界。
10. Palantir 官方介绍：Building with AIP | RAG & OAGPalantir 官方账号说明 OAG 使用本体中的数据、逻辑和动作；文中教学案例为自行设计。
11. Palantir：Functions核对可复用的计算逻辑及函数与本体的关系。
12. Palantir：属性核对属性定义。
13. Palantir：关系类型核对关系类型和具体关系。
14. Palantir：本体核心概念核对对象、类型、属性与关系的基础定义。
15. Palantir：为什么建立本体核对数据、逻辑及操作的组织与复用思路。
16. Palantir：动作提交条件核对动作执行条件及权限检查的配置方式。

资料核对日期：2026-09-15。本文用中文概括原文观点，结合一手资料独立讲解；分析、图解和教学示例由本指南编写。主题清单用于检查议题覆盖，不表示逐项复写原文全部细节。产品能力以所在部署的当前官方文档与实际配置为准。