核心概念
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（属性）
属性描述对象的特征，类似类的字段。
yaml
Campaign 属性:
name: string # 活动名称
objective: enum[拉新, 促活, 召回, GMV]
budget: decimal # 总预算
daily_cap: decimal # 日消耗上限
status: enum[草稿, 审核中, 投放中, 已暂停, 已结束]
roas: double # 实时广告支出回报
start_date / end_date: date
Customer 属性:
member_level: enum[普通, 银卡, 金卡, 黑金]
ltv: decimal # 生命周期价值
last_purchase_date: date # 最近一次购买
churn_risk: double # 流失风险分要点：
- 属性有业务标题（title）与描述 ，这是语义化的关键------字段
lst_pur_dt被翻译成人和 AI 都看得懂的"最近一次购买日期"； - 支持复杂类型：struct、数组、地理空间（Geo）等（例如客户的"偏好品类列表"）；
- 支持共享属性类型，保证"会员等级"在客户、订单、活动对象中语义一致。
Palantir目前支持的属性类型
| 属性基础类型 | 可作为业务键？ | 可作为主键？ | 备注 |
|---|---|---|---|
| 常用类型： String（字符串）、Integer（整型）、Short（短整型） | 是 | 是 | - |
| 时间类型： Date（日期）、Timestamp（时间戳） | 是 | 不推荐 | 通常情况下，时间类型不适合作为主键。因为存储格式与显示格式的不同可能会导致意外的哈希冲突或唯一性问题。大多数情况下，建议改用 String。 |
| 类似数值类型： Boolean（布尔型）、Byte（字节型）、Long（长整型） | 是 | 不推荐 | • Boolean 会将对象类型限制为最多两个对象实例。 • Byte 属性在操作（Actions）中只能通过 Integer 参数赋值，因此大多数情况下建议改用 Integer 属性。 • Long 在 JavaScript 中存在大数表示精度问题，部分前端库和代码在处理大于 10^{15（1e15）的 Long 值时可能会出现异常。大多数情况下，建议改用 String。 |
| 浮点 /定点数值类型： Float（单精度浮点）、Double（双精度浮点）、Decimal（小数/定点数） | 是 | 否 | - |
| Vector （向量） | 否 | 否 | - |
| Array（数组） | 是 | 否 | • 数组属性不能包含 null 元素。 • 如果数组的内部元素类型不是有效的标题属性，则该数组属性也不能用作标题属性。 • Object Storage v2 不支持嵌套数组。 |
| Struct（结构体） | 否 | 否 | Struct 属性不支持嵌套，且字段不能为数组。关于支持的字段类型详情，请参阅 Struct 相关文档。 |
| Media Reference（媒体引用）、 Time Series （时序数据）、Geotemporal Series（时空时序）、Attachment（附件） | 否 | 否 | - |
| Geopoint（地理坐标点） | 是 | 否 | Geopoint 的值存储为逗号分隔的字符串，格式为 纬度,经度（例如：57.64911,10.40744）。 另请参阅：在本体中使用地理空间数据 、创建 GeoPoint 、转换为本体 GeoPoint 和 验证本体 GeoPoint 是否有效。 |
| Geoshape（地理空间形状） | 否 | 否 | - |
| Marking（安全标记） | 否 | 否 | - |
| Cipher（密文/加密类型） | 是 | 否 | - |
Link Type（关联关系）
链接类型定义对象类型之间的关系，是本体构成"图"的基础。
sql
Campaign ──targets──▶ Segment （活动定向人群包）
Customer ──M:N belongs_to──▶ Segment （客户所属人群，经由圈选结果表）
Campaign ──issues──▶ Coupon （活动发放的券）
Customer ──redeemed──▶ Coupon （客户核销的券）
Customer ──placed──▶ Order （客户下的订单）
Campaign ──contains──▶ Creative （活动包含的素材）要点：
- 支持一对一、一对多、多对多；
- 实现上要么走外键 属性 ，要么走独立的连接数据集（join dataset） ，例如"客户 × 人群包"的圈选结果表；
- 关系是有向、有语义的（"定向""核销""下单"），这为归因分析、影响圈定和 AI 推理提供了骨架------比如"这场活动发出去的券，最终被哪些高价值客户核销了"，沿链路三步可达。
Action Type（动作）
这是 Palantir 本体最具辨识度的概念。Action 是受治理的、有副作用的业务操作，把本体从"只读模型"变成"可执行系统"。
yaml
ActionType: BatchSendCoupons（批量发券）
参数:
- campaign: Campaign # 所属活动对象
- segment: Segment # 目标人群包对象
- coupon_template: Coupon # 券模板
- send_time: timestamp
校验规则:
- campaign.status == 投放中
- campaign.budget - 已消耗 >= 本次预算占用 # 预算校验
- segment.size <= 500万 # 单次触达上限
- 频次控制：人群内客户 7 天内触达次数 < 3 # 防打扰
副作用:
- 生成发券任务并推送至 MA 执行引擎
- 回写 campaign.已占用预算
- 触发合规留痕记录
权限: 仅营销运营组可提交；预算 > 10 万需主管二级审批
审计: 记录操作人、时间、人群规模、前后预算值一个 Action 通常包含：参数（Parameters）→ 校验（Validations）→ 业务逻辑（可绑定 Function）→ 提交条件 → 副作用（修改对象/触发 Webhook/写回源系统）→ 权限与审计。
为什么重要？因为它把"发券、投放、暂停"这些高风险操作，变成了带权限、带校验、带审计流水线的标准操作 。运营在工作台点按钮、外部系统通过 OSDK 调用、AI Agent 自动执行------走的都是同一条受控通道。你敢不敢让 AI 碰营销执行？有 Action 层的 校验和 审计，才真的敢。
Function（函数）
Functions（Functions on Objects）是运行在服务器端的可复用逻辑单元，通常用 TypeScript 编写，用于对本体做查询、计算和编排：
vbnet
@Function()
public async getHighValueSleepingCustomers(days: integer): Promise<Customer[]> {
return Objects.search()
.customer()
.where(
Customer.ltv.gt(5000),
Customer.lastPurchaseDate.lt(Date.now().minusDays(days))
)
.fetchPage();
}
@Function()
public async calculateROAS(campaign: Campaign): Promise<double> {
const gmv = await campaign.orders().sum(Order.payAmount);
const cost = await campaign.spend();
return gmv / cost;
}要点：
- 函数可以挂到对象类型上成为方法 ，可以被 Action 调用作为业务逻辑，也可以注册为 Query 供搜索与 AI 使用；
- 通过 OSDK（ Ontology SDK） ，这些对象、关系、Action、函数会以强类型客户端的形式暴露给外部应用------本体变成了可编程平台；
- 在 AIP 中，函数就是 LLM 的工具（tools） ：模型不直接碰数据库，而是调用语义清晰的函数------"帮我看看哪些活动 ROAS 低于 1.5"会被翻译成对
calculateROAS的调用，而不是让模型自己写 SQL。
Rule（规则）
在 Palantir 的体系中，"规则"是一组贯穿性的概念，营销场景的典型形态：
- Action 校验规则：执行动作前的前置条件（如 3.5 的预算校验、频次控制）；
- Workflow / 告警规则：定义在对象上的条件触发器，例如"活动 ROAS 连续 3 天 < 1.5 → 自动创建复盘任务并通知活动负责人"；"人群包每日新增人数异常波动 > 30% → 触发数据质量核查"；
- AIP Logic 中的决策规则：用可视化逻辑编排 LLM + 函数 + 规则，实现"AI 判断 + 硬性约束"的混合决策，例如"AI 生成营销文案 → 敏感词与折扣力度规则校验 → 通过后进入人工审核队列"；
- 治理规则：权限策略、数据标记（如黑金客户名单的行级权限）、敏感字段脱敏规则。
规则的价值在于：把营销纪律从文档和人脑里搬进系统，变成可执行、可验证、可审计的约束。 人类操作和 AI 自动操作遵守同一套规则，这是"AI 可控落地"的前提。
为什么需要本体？
- 弥合语义鸿沟：业务语言与数据语言互不相通，本体是翻译层，也是唯一事实来源------"高价值客户"不再是每个部门各算各的。
- 从分析到运营的闭环：传统平台止步于"看"，本体通过 Action/Function 支持"写回"与"执行"------洞察直接变成发券、调预算、暂停投放。
- 复用与一致性：对象、关系、Action 定义一次，所有活动、所有团队、所有 AI 共享，杜绝每个项目重复建模、口径打架。
- 治理内生：权限、审计、血缘不是外挂组件，而是本体的内在属性------敏感人群的保护、营销动作的合规，天然落在模型里。
- AI 时代的刚需 ：LLM 的幻觉与越权风险，根因是缺乏结构化、受治理的企业语义接地。本体恰好提供了：LLM 用自然语言理解意图 → 映射到对象与函数 → 通过受约束的 Action 安全执行。Palantir 的判断是：没有本体的企业 AI，只能做问答；有本体的企业 AI，才能干活。 放到营销上就是：没有本体的营销 AI 只能写文案，有本体的营销 AI 才能端到端地跑活动。
本体与 RAG、GraphRAG、元数据、血缘、知识图谱、DDD
vs 元数据（Metadata）
| 元数据 | 本体 | OMCP | PMCP | |
|---|---|---|---|---|
| 关注点 | 数据本身的技术描述（表、列、类型、Owner） | 业务对象的语义与行为 | 本体 MCP Server | 平台基础设施 MCP Server |
| 粒度 | 面向存储与模式 | 面向业务实体 | 第三方 AI 客户端 | AI 编程助手/数据工程师 |
| 能力 | 描述、检索、治理 | 描述 + 关联 + 操作 + 逻辑 | 本体语义与操作 | 数据集/管道等基础设施 |
| 关系 | 本体消费并超越元数据：对象属性的背后是列级元数据，但本体叠加了业务语义与可操作性 | MCP 协议 | MCP 协议 | |
| 治理 | 完整继承 | 完整继承 | 完整继承（scoped token） | 完整继承 |
| 一句话定位 | 本体的可编程 API | Foundry 原生 AI | 给 AI 用的 OSDK | AI 数据工程师的工具箱 |
可以理解为：元数据回答"这张标签表是什么结构"，本体回答"我的客户是谁、这场活动能做什么"。
vs 数据血缘（Lineage）
血缘描述的是数据的流动路径：源系统 → 管道 → 数据集 → 对象/报表。它回答"这个数从哪来、改动会影响谁"。
- 血缘是观测与治理工具 ，本体是语义与操作模型；
- 二者互补：Foundry 中每个对象都能下钻到支撑它的数据集与 Transform 血缘------当"沉睡客户"人群包数量异常时，可以一路追到上游 ID-Mapping 的哪条管道出了问题；反过来，本体给血缘提供了业务语义------影响分析不再停在"表级"，而是"这场活动、这个人群级"。
vs 知识图谱（Knowledge Graph）
这是最容易混淆的一对。本体在结构上确实是一种知识图谱（实体 + 关系 + 属性），但工程定位差异很大：
| 传统知识图谱 | Palantir 本体 | |
|---|---|---|
| 构建方式 | 常由抽取/NLP/人工录入构建 | 由数据管道从源系统持续物化，与业务系统同步 |
| 侧重点 | 推理、问答、检索 | 运营、决策、写回、行动 |
| 数据地位 | 往往是一份"拷贝" | 与源系统双向联动（Action 写回） |
| 权限治理 | 通常较弱 | 一等公民 |
| 生命周期 | 项目制，易腐化 | 平台级持续运营 |
一句话：知识图谱 是静态的世界快照，Palantir 的本体是活的、可操作的企业数字孪生。 落到营销：传统客户知识图谱告诉你"这个客户喜欢母婴品类"，本体还能让你直接对他发起一场受控的触达。
vs RAG
RAG（检索增强生成）是一种技术模式：把文档切片向量化，LLM 提问时先检索相关片段再生成答案。
| RAG | 本体 | |
|---|---|---|
| 数据形态 | 非结构化文本块 | 结构化对象与关系 |
| 检索方式 | 向量相似度（模糊） | 属性过滤、图遍历、函数查询（精确） |
| 回答精度 | 依赖切片质量，易丢上下文 | 精确到字段级事实 |
| 权限控制 | 需要在向量库层额外实现 | 原生继承 |
| 行动能力 | 无 | Action 直接执行 |
但二者不是竞争关系，而是互补：
- 本体增强 RAG：检索前先通过对象定位精确上下文（比如先找到"618 会员召回"活动对象，再拉取它关联的复盘报告和历史文案库），大幅提升准确率；
- RAG 补充本体：本体里存不下的长尾非结构化内容（活动复盘文档、客服对话、爆款素材笔记），用 RAG 兜底；
- Palantir AIP 的实践正是两者融合：LLM 同时以本体（结构化工具调用）和检索（非结构化知识）作为上下文来源。第五章的语义搜索，正是"本体增强检索"的具体实现。
vs GraphRAG
GraphRAG（以 Microsoft 方案为代表）先用 LLM 从语料中自动抽取实体与关系构图，再做社区检测与摘要，以增强全局性问答。
| GraphRAG | 本体 | |
|---|---|---|
| 图的来源 | LLM 从非结构化文本抽取 | 从业务源系统经管道构建 |
| 图的地位 | 服务于检索的中间产物 | 企业运营的核心底座 |
| 可信度 | 抽取产物有幻觉风险 | 与源系统一致，可审计 |
| 目标 | 问答质量 | 决策与执行 |
有趣的是，GraphRAG 可以成为本体的"进料口" ：用 LLM 从客服对话、社媒评论、活动复盘中抽取候选的"客户需求""品类趋势"实体，经人工或规则审核后沉淀为正式本体标签与人群规则------非结构化洞察由此获得治理与可操作性。
vs DDD（领域驱动设计）
这一对最容易被忽视，但精神血缘最近：
| DDD | 本体 | |
|---|---|---|
| 本质 | 软件建模方法论 | 运行时数据平台语义层 |
| 统一语言 | 通过文档/会议对齐 | 直接固化为对象类型与属性定义 |
| 实体/聚合 | 代码中的领域模型 | 平台中的 Object Type |
| 领域服务/命令 | 应用代码 | Action Type |
| 限界上下文 | 按上下文拆分微服务 | 按模块/命名空间拆分本体，但保持全局可链接 |
可以说：本体是 DDD 理想形态的一次平台级实现------DDD 倡导的"统一语言"、"以领域为中心"，在本体里不再依赖团队自觉，而是由平台强制沉淀、全局共享。反过来，做营销本体建模时，DDD 的战略/战术设计方法（事件风暴识别"活动、人群、券、订单"等核心对象，区分聚合边界）是极好的实操指导。
一张总表
| 概念 | 一句话定位 | 与本体的关系 |
|---|---|---|
| 元数据 | 数据的技术说明书 | 本体的底层依赖，被本体语义化 |
| 血缘 | 数据的流动地图 | 为本体提供可信度与影响分析 |
| 知识图谱 | 实体关系的语义网络 | 本体的结构基础；本体是其"运营化"形态 |
| RAG | 非结构化知识接入 LLM 的模式 | 与本体的结构化检索互补融合 |
| GraphRAG | 用 LLM 构图增强检索 | 可作为本体的非结构化进料口 |
| DDD | 领域建模方法论 | 本体建模的方法论源泉 |
| 本体 | 可执行的企业数字孪生 | 语义 + 数据 + 操作 + 治理的统一体 |