Palantir AIP与对象存储拆解：Ontology如何打通LLM三堵墙

继续正本清源。昨天我们把 Palantir Foundry 的官网做了翻译、整理和加工，对内发布了蓝皮书。整理完之后发现，其实还有很多东西值得进一步总结，研究一手资料能挖出不少新结论。这篇文章也同步发布在 云栈社区，欢迎交流讨论。

接下来看看 AIP——基于官网文档本地复刻（20 个页面）的一手证据，做一次深度解读。

先给结论：AIP = 把 LLM 接进企业本体（Ontology）与业务流程动作、且全程受治理的集成能力层。它不是一个普通的 LLM 应用，而是一层受治理的能力套件。差异化不在模型（模型只是被集成的 commodity），而在三件事：本体打通（LLM 够得着企业数据）、动作可执行（LLM 改得动企业系统）、全程治理 / 可观测 / 可评测（敢上线）。

多从一手信息来看，确实会有收获。

一、关于 Palantir AIP 的一些细节

企业想用 LLM，但横着三道硬墙：

墙①和墙②说明 LLM 与企业之间缺一座桥；墙③说明这座桥还必须带护栏。AIP 就是这座桥，它的全部设计都是为了同一个目标：让 LLM 既能读企业数据、又能改企业数据 / 触发动作，且每一步都在治理框架内。

官网把 AIP + Foundry + Apollo 称为“操作系统”更多是定位话术，工程上 AIP 是跑在 Foundry（数据底座）之上的、受治理的 LLM 能力套件。

但问题在于，很多人把 AIP 当成企业版 RAG / 套一层 LangChain，这其实有偏差，直接拉表对比更清楚：

关键论据来自 aip-features/overview 原文：文档反复强调 AIP 一切能力都 “backed by the data in your Ontology”；Chatbot Studio 生成的智能体不只是回答问题，还能直接 edit Ontology data、触发业务动作。注意动词是 “edit”（写回），不是 “read”（读取）。这正是墙①②被同时打通的证据——RAG 给的是上下文，本体给的是操作权限与接口。

顺着这个思路，其实可以做个选型判断：AIP 选择本体而不是向量库，不是技术偏好，而是目标函数不同。

• 如果你的目标是让 LLM 读得懂我的文档 → RAG + 向量库足够。
• 如果你的目标是让 LLM 操作我的业务系统 → 必须把企业数据建模成可寻址的对象 + 可执行的动作，这就是本体。LLM 的 function-calling 直接落到这些动作上，才叫 AI 操作系统，否则只是 AI 聊天框。

所以本体的工程本质，是 LLM 与企业系统之间的一层语义 API 契约：对象定义了 LLM 能知道什么，动作定义了 LLM 能干什么，权限 / 审计挂在对象与动作上，于是墙③也顺带破了。

最终形成如下架构：

这里可以顺便对比下直接 API / RAG / 竞品的本质差异。差异不在哪个模型更强（模型都是集成的），而在动作可执行 + 对象级治理 + 可 air-gapped 部署三者叠加，且绑定客户既有本体存量。

如果要复刻这个 AIP，其实并不容易。工程能力竞品理论上都能抄，但 AIP 真正抄不动的，是下面三样靠时间积累出来的资产：

AIP 的壁垒 = 模型（commodity）× 本体存量 × 信任 × 部署底座。

前三者是时间积累，后两者是工程 + 资质门槛。对手能做出类似的 LLM 套件，但做不出客户已运行 5 年的本体 + 已签 10 年的政府合规契约 + 能在核潜艇里更新的部署系统。

所以 AIP 卖的从来不是模型，是把模型焊进客户关键业务的那套体系。国内也很难抄。

二、再看 Palantir Foundry 的底层存储

上面说了，AIP = 把 LLM 接进企业本体与业务流程。本体层就是那个“接入口”的地基，LLM 要读的是 object/property/link，要写的是 action。没有 Ontology，AIP 就没有“读企业数据、改企业系统”的抓手，只能退化成“直接调 OpenAI API 聊聊天”。

因此这里必须再谈谈底层存储。前面的文章里已经见过，这里重点讲架构演进：OSv1 → OSv2 的职责解耦。本体后端由一组微服务构成，官方列出六大功能组件（object-backend/overview）：

• Object Storage v1（Phonograph）把索引、查询、写入、搜索、聚合合并在一个服务里；
• Object Storage v2 把这些职责彻底解耦。

官方原文是“通过分离负责索引和查询数据的子系统，Object Storage v2 可以更轻松地水平扩展”。这是一次典型的“单体 → 分权”重构：

这样一来，可以拿到一些具体结果：

• 增量索引：所有 object type 默认启用增量对象索引，索引性能显著提升。OSv2 的关键优化是增量对象索引（默认启用），只重算变化部分，而非全量重建。
• 数百亿：单个 object type 索引吞吐量提升到数百亿个对象；
• 列级权限：多数据源对象类型支持列 / 属性级别的细粒度权限；
• 10000：单 Action 支持编辑最多 10,000 个对象（更高需提变更请求）；
• 流式：支持流式数据源低延迟索引，每 object type 最多 2000 个属性；
• 100000 个 SearchAround：周边搜索默认上限 100000 个对象。

参考文献

1、https://www.palantir.com/docs/foundry/data-integration/

2、https://www.palantir.com/docs/foundry/aip/overview/