本体论的基本核心概念

核心概念

Ontology（本体）

本体不是某一张表，而是整个组织共享的语义模型：它定义了企业里有哪些实体类型、实体有哪些属性、实体之间如何关联、可以对实体执行哪些操作。

在许多应用场景中，本体充当了组织的“数字孪生”（Digital Twin），兼具支持各类用例所需的语义元素（对象、属性、链接）和动力学元素（操作、函数、动态安全管控）。

• 对象类型（Object type） 定义了组织中的一个实体或事件。
• 属性（Property） 定义了对象类型的特征。
• 链接类型（Link type） 定义了两个对象类型之间的关系。
• 操作类型（Action type） 定义了如何对对象类型进行修改。

Object Type & Object（对象类型与对象）

Object Type（对象类型） 是对一类业务实体的建模，类似面向对象编程中的"类"；Object（对象） 是它的实例。营销场景下典型的本体对象：Customer（客户）、Segment（人群包）、Campaign（营销活动）、Coupon（优惠券）、Order（订单）、Creative（创意素材）。

• 每个对象类型背后由数据集支撑（backing dataset），对象不是凭空录入的，而是由数据管道持续计算/同步出来的——这一点与手工维护的知识图谱截然不同；
• 对象类型是应用、搜索、AI 推理的统一入口：运营搜索"618 大促"，搜到的是 Campaign 对象，而不是一张表。

Property（属性）

属性描述对象的特征，类似类的字段。

1Campaign 属性:
2  name: string                 # 活动名称
3  objective: enum[拉新, 促活, 召回, GMV]
4  budget: decimal              # 总预算
5  daily_cap: decimal           # 日消耗上限
6  status: enum[草稿, 审核中, 投放中, 已暂停, 已结束]
7  roas: double                 # 实时广告支出回报
8  start_date / end_date: date
9
10Customer 属性:
11  member_level: enum[普通, 银卡, 金卡, 黑金]
12  ltv: decimal                 # 生命周期价值
13  last_purchase_date: date     # 最近一次购买
14  churn_risk: double           # 流失风险分
15

要点：

• 属性有业务标题（title）与描述，这是语义化的关键——字段 lst_pur_dt 被翻译成人和 AI 都看得懂的"最近一次购买日期"；
• 支持复杂类型：struct、数组、地理空间（Geo）等（例如客户的"偏好品类列表"）；
• 支持共享属性类型，保证"会员等级"在客户、订单、活动对象中语义一致。

Palantir目前支持的属性类型

Link Type（关联关系）

链接类型定义对象类型之间的关系，是本体构成"图"的基础。

1Campaign   ──targets──▶   Segment        （活动定向人群包）
2Customer   ──M:N belongs_to──▶ Segment   （客户所属人群，经由圈选结果表）
3Campaign   ──issues──▶    Coupon         （活动发放的券）
4Customer   ──redeemed──▶  Coupon         （客户核销的券）
5Customer   ──placed──▶    Order          （客户下的订单）
6Campaign   ──contains──▶  Creative       （活动包含的素材）
7

要点：

• 支持一对一、一对多、多对多；
• 实现上要么走外键 属性，要么走独立的连接数据集（join dataset） ，例如"客户 × 人群包"的圈选结果表；
• 关系是有向、有语义的（"定向""核销""下单"），这为归因分析、影响圈定和 AI 推理提供了骨架——比如"这场活动发出去的券，最终被哪些高价值客户核销了"，沿链路三步可达。

Action Type（动作）

这是 Palantir 本体最具辨识度的概念。Action 是受治理的、有副作用的业务操作，把本体从"只读模型"变成"可执行系统"。

1ActionType: BatchSendCoupons（批量发券）
2  参数:
3    - campaign: Campaign       # 所属活动对象
4    - segment: Segment         # 目标人群包对象
5    - coupon_template: Coupon  # 券模板
6    - send_time: timestamp
7  校验规则:
8    - campaign.status == 投放中
9    - campaign.budget - 已消耗 >= 本次预算占用     # 预算校验
10    - segment.size <= 500万                        # 单次触达上限
11    - 频次控制：人群内客户 7 天内触达次数 < 3       # 防打扰
12  副作用:
13    - 生成发券任务并推送至 MA 执行引擎
14    - 回写 campaign.已占用预算
15    - 触发合规留痕记录
16  权限: 仅营销运营组可提交；预算 > 10 万需主管二级审批
17  审计: 记录操作人、时间、人群规模、前后预算值
18

一个 Action 通常包含：参数（Parameters）→ 校验（Validations）→ 业务逻辑（可绑定 Function）→ 提交条件 → 副作用（修改对象/触发 Webhook/写回源系统）→ 权限与审计。

为什么重要？因为它把"发券、投放、暂停"这些高风险操作，变成了带权限、带校验、带审计流水线的标准操作。运营在工作台点按钮、外部系统通过 OSDK 调用、AI Agent 自动执行——走的都是同一条受控通道。你敢不敢让 AI 碰营销执行？有 Action 层的 校验和 审计，才真的敢。

Function（函数）

Functions（Functions on Objects）是运行在服务器端的可复用逻辑单元，通常用 TypeScript 编写，用于对本体做查询、计算和编排：

1@Function()
2public async getHighValueSleepingCustomers(days: integer): Promise<Customer[]> {
3  return Objects.search()
4    .customer()
5    .where(
6      Customer.ltv.gt(5000),
7      Customer.lastPurchaseDate.lt(Date.now().minusDays(days))
8    )
9    .fetchPage();
10}
11
12@Function()
13public async calculateROAS(campaign: Campaign): Promise<double> {
14  const gmv = await campaign.orders().sum(Order.payAmount);
15  const cost = await campaign.spend();
16  return gmv / cost;
17}
18

要点：

• 函数可以挂到对象类型上成为方法，可以被 Action 调用作为业务逻辑，也可以注册为 Query 供搜索与 AI 使用；
• 通过 OSDK（ Ontology SDK） ，这些对象、关系、Action、函数会以强类型客户端的形式暴露给外部应用——本体变成了可编程平台；
• 在 AIP 中，函数就是 LLM 的工具（tools） ：模型不直接碰数据库，而是调用语义清晰的函数——"帮我看看哪些活动 ROAS 低于 1.5"会被翻译成对 calculateROAS 的调用，而不是让模型自己写 SQL。

Rule（规则）

在 Palantir 的体系中，"规则"是一组贯穿性的概念，营销场景的典型形态：

1. Action 校验规则：执行动作前的前置条件（如 3.5 的预算校验、频次控制）；
2. Workflow / 告警规则：定义在对象上的条件触发器，例如"活动 ROAS 连续 3 天 < 1.5 → 自动创建复盘任务并通知活动负责人"；"人群包每日新增人数异常波动 > 30% → 触发数据质量核查"；
3. AIP Logic 中的决策规则：用可视化逻辑编排 LLM + 函数 + 规则，实现"AI 判断 + 硬性约束"的混合决策，例如"AI 生成营销文案 → 敏感词与折扣力度规则校验 → 通过后进入人工审核队列"；
4. 治理规则：权限策略、数据标记（如黑金客户名单的行级权限）、敏感字段脱敏规则。

规则的价值在于：把营销纪律从文档和人脑里搬进系统，变成可执行、可验证、可审计的约束。 人类操作和 AI 自动操作遵守同一套规则，这是"AI 可控落地"的前提。

为什么需要本体？

1. 弥合语义鸿沟：业务语言与数据语言互不相通，本体是翻译层，也是唯一事实来源——"高价值客户"不再是每个部门各算各的。
2. 从分析到运营的闭环：传统平台止步于"看"，本体通过 Action/Function 支持"写回"与"执行"——洞察直接变成发券、调预算、暂停投放。
3. 复用与一致性：对象、关系、Action 定义一次，所有活动、所有团队、所有 AI 共享，杜绝每个项目重复建模、口径打架。
4. 治理内生：权限、审计、血缘不是外挂组件，而是本体的内在属性——敏感人群的保护、营销动作的合规，天然落在模型里。
5. AI 时代的刚需：LLM 的幻觉与越权风险，根因是缺乏结构化、受治理的企业语义接地。本体恰好提供了：LLM 用自然语言理解意图 → 映射到对象与函数 → 通过受约束的 Action 安全执行。Palantir 的判断是：没有本体的企业 AI，只能做问答；有本体的企业 AI，才能干活。 放到营销上就是：没有本体的营销 AI 只能写文案，有本体的营销 AI 才能端到端地跑活动。

本体与 RAG、GraphRAG、元数据、血缘、知识图谱、DDD

vs 元数据（Metadata）

可以理解为：元数据回答"这张标签表是什么结构"，本体回答"我的客户是谁、这场活动能做什么"。

vs 数据血缘（Lineage）

血缘描述的是数据的流动路径：源系统 → 管道 → 数据集 → 对象/报表。它回答"这个数从哪来、改动会影响谁"。

• 血缘是观测与治理工具，本体是语义与操作模型；
• 二者互补：Foundry 中每个对象都能下钻到支撑它的数据集与 Transform 血缘——当"沉睡客户"人群包数量异常时，可以一路追到上游 ID-Mapping 的哪条管道出了问题；反过来，本体给血缘提供了业务语义——影响分析不再停在"表级"，而是"这场活动、这个人群级"。

vs 知识图谱（Knowledge Graph）

这是最容易混淆的一对。本体在结构上确实是一种知识图谱（实体 + 关系 + 属性），但工程定位差异很大：

一句话：知识图谱 是静态的世界快照，Palantir 的本体是活的、可操作的企业数字孪生。 落到营销：传统客户知识图谱告诉你"这个客户喜欢母婴品类"，本体还能让你直接对他发起一场受控的触达。

vs RAG

RAG（检索增强生成）是一种技术模式：把文档切片向量化，LLM 提问时先检索相关片段再生成答案。

但二者不是竞争关系，而是互补：

• 本体增强 RAG：检索前先通过对象定位精确上下文（比如先找到"618 会员召回"活动对象，再拉取它关联的复盘报告和历史文案库），大幅提升准确率；
• RAG 补充本体：本体里存不下的长尾非结构化内容（活动复盘文档、客服对话、爆款素材笔记），用 RAG 兜底；
• Palantir AIP 的实践正是两者融合：LLM 同时以本体（结构化工具调用）和检索（非结构化知识）作为上下文来源。第五章的语义搜索，正是"本体增强检索"的具体实现。

vs GraphRAG

GraphRAG（以 Microsoft 方案为代表）先用 LLM 从语料中自动抽取实体与关系构图，再做社区检测与摘要，以增强全局性问答。

有趣的是，GraphRAG 可以成为本体的"进料口" ：用 LLM 从客服对话、社媒评论、活动复盘中抽取候选的"客户需求""品类趋势"实体，经人工或规则审核后沉淀为正式本体标签与人群规则——非结构化洞察由此获得治理与可操作性。

vs DDD（领域驱动设计）

这一对最容易被忽视，但精神血缘最近：

可以说：本体是 DDD 理想形态的一次平台级实现——DDD 倡导的"统一语言"、"以领域为中心"，在本体里不再依赖团队自觉，而是由平台强制沉淀、全局共享。反过来，做营销本体建模时，DDD 的战略/战术设计方法（事件风暴识别"活动、人群、券、订单"等核心对象，区分聚合边界）是极好的实操指导。

一张总表

《本体论的基本核心概念》 是转载文章，点击查看原文。