Ontology 工程落地模式：从概念到受控执行

来源：基于 Palantir Foundry 工程实施范式的模式总结（2026-05-21）参考：Palantir Ontology 文档 | Palantir Actions | Palantir Functions

阅读前提

前四篇解决了四个问题：

01：Ontology 的 6 要素是什么（Object、Link、Action、Function、Rule、Interface 的概念）
02：谁来推动这件事（FDE 角色及其中国变形）
03：没有 Palantir 时能搭出什么，坑在哪
04：你的团队该走哪条路（三档决策框架）

这篇回答：决定走路径 B 或 C 之后，工程化实施有哪些关键决策和实施模式。

01 篇解释了"是什么"，这篇解释"怎么建"。

一句话定义

Ontology 工程化的核心是：把现有数据资产映射成语义层，并在语义层之上建立"LLM 只能申请、平台才执行"的受控执行机制。

一、为什么"有了图数据库"还不够

一个常见误解：知识图谱 ≈ Ontology，把数据存进图数据库，AI 就能理解业务了。

现实是：多数团队已有两端——数据底座（图/数仓/元数据管理）+ AI 上层（Agent 平台/工作流编排）。但中间缺一层：

┌──────────────────────────────────────┐
│  AI 上层（Agent 编排、工作流、对话）    │  ← 已有
└──────────────────────────────────────┘
              ↕ 中间层（缺失）
┌──────────────────────────────────────┐
│  数据底座（图数据库、数仓、元数据管理） │  ← 已有
└──────────────────────────────────────┘

缺失的中间层做三件事：

语义化：把图/表里的技术概念翻译成业务语义（Object Type、Link Type）
可计算化：在语义层上暴露可被 AI 调用的只读能力（Function）和受控写操作（Action）
受控化：确保每次 AI "执行"都经过校验、权限检查、审计

这三件事分开做都有工具，但"三合一"是工程难点，也是 Palantir 的真实壁垒。

二、模式一：现有数据层 → Ontology 6 要素的映射

不需要从零开始。大多数团队已有元数据管理系统或数据建模体系，Palantir 的 6 个本体要素可以寄生在现有层次上，而不是另起炉灶。

典型的四层数据模型与 Ontology 6 要素的对应关系：

现有数据层                        Ontology 要素
──────────────────────────────────────────────────
主题域分组 / 主题域           →  业务理解层（给人看，不直接对应要素）
业务对象（概念分组）          →  概念分组层（不直接对应要素）
实体                         →  Object Type（1:1 对应）
实体数据管理（VertexLabel）   →  图存储层
属性                         →  Property（1:1 对应）

挂在实体层之上的扩展：
  Function 列表              →  Function（只读计算能力）
  Action 列表                →  Action（受控写操作）
  关系定义                   →  Link Type
  权限定义                   →  Permission

关键发现：实体（Entity）才是 Ontology 的核心单元，而不是业务对象（业务对象是概念分组层，给业务人员看的，不直接驱动执行）。

类比 OOP：如果把 Ontology 比作面向对象编程——

OOP 概念	Ontology 对应
类（Class）	Object Type
字段（Field）	Property
引用/外键	Link Type
方法（只读）	Function
方法（写操作，带权限）	Action
包（Package）	子图（Subgraph）

这个映射的价值：让已有元数据系统的团队，可以用扩展字段的方式逐步增加本体能力，而不是推翻重建。

三、模式二：受控执行的三条不变原则

这是整个 Ontology 范式的治理内核。不管用什么技术栈，这三条原则一旦违背，受控执行就名存实亡：

原则一：LLM 只能"申请"，平台才"执行"

用户 / Agent
    │
    ▼ 发出意图（"帮我把这个漏洞工单分配给张三"）
LLM 推理
    │
    ▼ 调用 Action MCP Tool（申请执行）
平台（Action 执行引擎）
    │ ① 校验输入 Schema
    │ ② 检查前置条件
    │ ③ 判断是否需要人工审批（HITL）
    │ ④ 写业务系统（真正执行）
    │ ⑤ 同步写图
    │ ⑥ 审计日志
    ▼
结果返回 Agent

LLM 在这里的角色是意图解析器，不是执行者。执行的每一步都由平台保证。

原则二：业务系统是唯一真相（Source of Truth），图是语义投影

图（知识图谱）存储的是"为 AI 推理和跨系统关联维护的副本"，不是数据主库。

情况	正确处理
业务系统写成功、图同步失败	业务系统数据有效，图进补偿队列重试，不回滚业务操作
图写成功、业务系统写失败	整体拒绝，回滚图的变更
图数据与业务系统数据不一致	以业务系统为准，图属于最终一致

这个立场避免了一个常见陷阱：把图当主库建，然后发现数据治理成本失控。

原则三：每次执行都有审计

Action 执行必须产生审计日志，最少包含：

trace_id：全链路可追溯
caller：谁发起的（Agent / 用户 / 系统）
input_payload：输入了什么
exec_status：结果状态
connector_status：业务系统写入结果

没有审计就没有合规，没有合规 AI 就无法参与核心业务流程。

四、模式三：语义路由链——"AI 理解业务上下文"的工程实现

01 篇解释了 Ontology 让 AI 理解业务，03 篇用制造业案例说明了"SQL 表 vs 关系显式化"的差异。但"理解"在工程层面是怎么实现的？

答案是语义路由链（Semantic Routing Chain）——不是靠 Prompt 里写死的上下文，而是动态检索。

为什么不能靠静态上下文

静态做法：把所有本体定义写进 System Prompt，让 LLM 自己找。

问题：本体规模一旦超过 100 个概念，Prompt 会爆炸，召回质量反而下降（LLM 的注意力机制在超长上下文里会漂移）。

语义路由链的五步

用户自然语言输入（NL）
    │
    ▼ ① 意图分类（SemanticRouter）
    │   READ 意图 → 走查询链
    │   WRITE 意图 → 走 Action 链
    │
    ▼ ② 向量检索（OntologyRetriever）
    │   embed(NL) → 余弦相似度 → 取 top-K 本体元素
    │   命中的是：相关实体、属性、关系类型、枚举值
    │
    ▼ ③ 聚焦上下文组装（ContextAssembler）
    │   只把 top-K 元素的语义描述组装成上下文
    │   不是全量本体，是"与这个查询相关的子集"
    │
    ▼ ④（READ 分支）图查询生成（GremlinPlanner）
    │   NL + 聚焦上下文 → LLM（temperature=0）→ 图查询语句
    │
    ▼ ⑤ Schema 强校验（GremlinSchemaValidator）
        校验生成的查询中的属性名、关系名是否存在于元数据
        合法 → 执行查询 → 返回结果
        非法 → 拒绝执行，返回澄清问题

类比数据库领域：步骤 ④⑤ 类似查询规划器 + Schema 校验，只是输入从 SQL 变成自然语言，中间多了一个 LLM 翻译步骤。

向量索引的工程选型（按规模分档）

阶段	本体元素数量	推荐方案	理由
MVP	< 100 条	内存余弦相似度 + 简单持久化	零新增基础设施
二期	100-1000 条	Redis Vector Search	不引入独立组件
三期	> 1000 条	独立向量数据库（Milvus / Qdrant）	规模化检索性能

关键点：决定召回质量的不是向量数据库的选型，而是每个本体元素的语义扩写文本写得好不好（下一节展开）。

五、模式四：一致性分级——数据质量的务实取舍

Ontology 里的数据有不同的"新鲜度"要求。一刀切地追求强一致，成本高且没必要。

Palantir 范式提供两档：

一致性级别	含义	使用场景
EVENTUAL（最终一致）	用图里的副本，允许有延迟	绝大多数字段（列表、统计、历史数据）
STRONG_ON_READ（读时穿透）	读时直接调业务系统 API 获取最新值	关键决策字段（工单状态、审批状态、库存实时数）

工程实现：每个属性在定义时标注 consistencyLevel。

# 属性定义示例（伪代码）
Property: WorkOrder.status
  sourceSystem: ticket-system
  consistencyLevel: STRONG_ON_READ   # 前置条件校验时，穿透读

Property: Vulnerability.cvssScore
  sourceSystem: scanner
  consistencyLevel: EVENTUAL         # 扫描结果不实时，最终一致够用

工程含义：Action 的前置条件（Precondition）在校验 STRONG_ON_READ 字段时，需要穿透调业务系统 API 而不是查图副本，以避免用过期数据做决策。

这个分级也是控制 API 成本的工具：不是所有字段都要实时穿透，只有在"做决策"的关键节点才穿透。

六、模式五：子图设计——按查询闭环切，不按数据源切

最常见的错误设计：一个数据源对应一个子图。

❌ 错误设计
子图 A：CRM 数据
子图 B：ERP 数据
子图 C：IoT 数据

→ AI 做跨系统关联时，需要跨子图查询，边界打破了子图的隔离意义。

正确原则：子图按"业务场景的查询闭环"划分，一个完整业务问题能在一个子图里得到回答。

✅ 正确设计
子图：安全运营（security_ops）
  装入：Asset / Vulnerability / WorkOrder / Person
  → "上周高危漏洞有没有分配责任人" ← 这个问题能在一个子图里闭环

子图：供应链（supply_chain）
  装入：Supplier / PurchaseOrder / Inventory / Product
  → "这个供应商的哪些订单处于延期风险" ← 同样能在子图内闭环

子图的另一个价值：权限边界。不同角色只能看到自己业务场景的子图，天然的数据隔离。

三个独立维度，不要混淆：

维度	说明
主题域（业务分组）	给人看的业务分类，不等于子图
数据源	数据来自哪个系统，不等于子图
子图	AI 查询的业务闭环单元，也是权限边界

七、辨析：GraphRAG 还是 Ontology-driven？

这是实施时经常出现的技术路线争论。两条路线有本质区别，适用场景不同。

维度	GraphRAG（以微软方案为代表）	Ontology-driven（本篇讨论的方案）
知识来源	非结构化文档，LLM 自动抽取实体关系	建模师人工审核的结构化本体
图的可信度	LLM 抽取有噪声，图本身不精确	语义精确，可直接驱动执行
查询路径	Embedding → 图遍历 → LLM 综合	Embedding → NL → 精确图查询 → 受控执行
可解释性	弱（LLM 自由遍历，结果难溯源）	强（每条查询可审计 + Schema 强校验）
核心目标	非结构化知识问答	知识驱动的受控业务执行

选哪个，看"知识的来源"：

知识来自大量非结构化文档（威胁情报报告、合同、KB 知识库）→ GraphRAG 更合适
知识是结构化业务数据，需要驱动执行（分配工单、更新状态、触发流程）→ Ontology-driven 更合适

两者不是互斥的。GraphRAG 可以作为"非结构化知识补充层"叠加到 Ontology 体系上，但不应替换结构化本体图。

核心判断标准：如果你的目标是让 AI "理解业务数据并执行业务动作"，而不只是"回答文档里的问题"，Ontology-driven 是更精确的路线。

八、建模四步法 + 语义索引层

8.1 建模四步法

Step 1  划定子图范围
        ↳ 先问：哪些业务实体需要跨系统关联？这个问题能在一个子图里闭环吗？
        ↳ 不要一次建全局图，MVP 只建一个子图

Step 2  探查数据骨架
        ↳ 对每个实体：它的主权系统是哪个（谁拥有这条数据）？
        ↳ 有哪些副本系统？跨系统如何做 ID 映射？
        ↳ 哪些字段需要 STRONG_ON_READ，哪些 EVENTUAL 够用？

Step 3  定义要素
        ↳ Object Type / Property / Link Type 先定（静态结构）
        ↳ Function / Action 后定（动态能力）
        ↳ Action 的前置条件（Precondition）和是否需要 HITL 审批需明确

Step 4  验证后入库
        ↳ 每个实体有测试用例（给定 X，查询 Y，结果应该是 Z）
        ↳ 语义索引层填写完整（见下节）
        ↳ 跑一次端到端验证再上线

8.2 语义索引层：决定 AI 召回质量的关键

最容易被忽视的细节：向量检索的召回质量，80% 取决于语义扩写文本写得好不好，而不是向量模型选什么。

语义扩写文本是对每个本体元素的自然语言语义扩写，覆盖同义词、常见问法、英文缩写。建模时必须同步填写。

示例（以"漏洞"实体为例）：

元素类型	元素编码	语义扩写文本（要覆盖的语义）
实体	`Vulnerability`	漏洞 CVE CVSS 安全漏洞待修复已修复漏洞扫描结果
属性	`Vulnerability.severity`	漏洞严重程度危险等级高危中危低危
属性值	`severity=HIGH`	高危漏洞严重漏洞 P0 级 CVSS≥7 紧急处置
关系类型	`关联工单`	漏洞对应的工单处置工单修复任务谁在处理
查询模式	`no_owner_vuln`	没有责任人的漏洞未分配漏洞无人处理的高危漏洞

填写原则：

用业务用语，而不是字段名（用"高危漏洞"不用"severity=HIGH"）
覆盖业务人员可能的真实问法
覆盖英文缩写和全称
"查询模式"类型用于记录常见复合查询的语义锚点，是额外的召回补充

语义索引层不是 ETL 工具能自动生成的——它需要懂业务的人手动填写，这也是建模工作量的重要组成部分。

九、工程红线

实施时有几条红线需要明确，踩了就会出系统性问题：

红线一：LLM 调用链不能发送实例数据

向 LLM 发送的内容只允许：本体元素的语义定义文本（建模师审核过的）和用户查询语句。

禁止发送：IP 地址、外部系统 ID、真实姓名、业务敏感数据。

原因：合规边界。一旦把生产实例数据发给 SaaS 大模型，就可能触发数据出境/合规风险。语义路由链的设计目标之一，就是让 LLM 只接触"元数据"而不是"实例数据"。

红线二：Embedding 维度一旦入库不可变

向量索引的 embedding 维度（如 1536 维），在建表前必须与团队对齐，之后无法更改，否则需要清空重建整个向量库。

红线三：业务系统写入失败时，图不能写

Action 6 步流程的顺序不可颠倒：先写业务系统（Step 4），再写图（Step 5）。反过来可能造成"图有数据、业务系统没有"的幽灵数据。

红线四：子图范围需要稳定

子图的实体类型一旦确定，后期增减涉及向量索引重建和跨团队对齐成本。MVP 阶段宁可范围小，也不要贪大。

十、局限与适用边界

适合这套范式的场景

有明确业务实体和关系（不是非结构化文档知识库）
需要 AI 不只是"回答"而是"执行"业务操作
需要审计和合规（金融、政务、安全运营）
数据横跨多个业务系统，需要跨系统关联推理

不适合这套范式的场景

主要需求是文档问答、报告生成——路径 A（RAG + 工作流）就够了
团队 < 3 人，没有"懂业务又懂技术"的建模者——建模工作无人承担
业务场景尚不稳定，实体定义频繁变化——建模成本会淹没价值

建模成本是真实代价

Ontology 工程化的核心瓶颈不是技术，是建模者资源。

"懂业务又懂技术"的人通常是团队里最稀缺的。建模四步法写起来轻松，但真正实施时，Step 2（探查数据骨架）和语义索引层，往往比预期花费 3-5 倍的时间。

04 篇说"路径 B 的关键难点不在技术，在谁来建模"——这篇从工程角度补充了为什么：建模不是填表，是业务知识提炼。

新产生的追问（已同步到 99-notes-and-insights.md）：
[ ] 语义路由链中，Schema 强校验的粒度如何平衡覆盖率和误拒绝率？过严会拒绝合法查询，过松会执行错误语句
[ ] 子图边界变化时（新增实体类型），向量索引的增量更新机制如何设计，避免全量重建
[ ] 国内私有化 LLM（DeepSeek 本地部署等）在 NL→图查询生成质量上与 GPT-4o 的差距，是否影响语义路由链的可用性

Ontology 工程落地模式：从概念到受控执行 ​

阅读前提 ​

一句话定义 ​

一、为什么"有了图数据库"还不够 ​

二、模式一：现有数据层 → Ontology 6 要素的映射 ​

三、模式二：受控执行的三条不变原则 ​

原则一：LLM 只能"申请"，平台才"执行" ​

原则二：业务系统是唯一真相（Source of Truth），图是语义投影 ​

原则三：每次执行都有审计 ​

四、模式三：语义路由链——"AI 理解业务上下文"的工程实现 ​

为什么不能靠静态上下文 ​

语义路由链的五步 ​

向量索引的工程选型（按规模分档） ​

五、模式四：一致性分级——数据质量的务实取舍 ​

六、模式五：子图设计——按查询闭环切，不按数据源切 ​

七、辨析：GraphRAG 还是 Ontology-driven？ ​

八、建模四步法 + 语义索引层 ​

8.1 建模四步法 ​

8.2 语义索引层：决定 AI 召回质量的关键 ​

九、工程红线 ​

十、局限与适用边界 ​

适合这套范式的场景 ​

不适合这套范式的场景 ​

建模成本是真实代价 ​