Palantir在企业的机会

推荐语

Palantir如何赋能企业数字化转型？深入解析其核心产品Foundry与AIP的落地价值。

核心内容：
1. Palantir核心产品架构解析：Foundry与AIP的差异化优势
2. 本体论在数据平台中的关键作用与实施路径
3. 国内企业对标Palantir的能力评估标准与实践案例

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

今年，Palantir 作为备受关注的企业，许多用户都希望了解其能力在国内有哪些具体场景可以实现落地。我们也注意到，在某些企业的招投标项目中，已开始将本体论等相关能力列为评估项之一。

与此同时，大家也普遍存在一些疑问：Palantir 的核心能力究竟包含哪些？目前国内不少厂商正在对标或学习 Palantir 的能力，并为企业提供相应解决方案，又该如何评估这些能力的具体标准？

针对以上问题，今天会分享已有的实践与成果。这一方向我们后续将持续推进，并定期与大家交流相关进展。

内容已做精简，如需获取专家完整版视频，请扫码领取。

01 

• Gotham 主要面向政府与公共领域客户，例如国防、情报与执法机构，用于情报分析与数据决策，因此与大多数企业用户的关联性不大。
• Foundry 则更值得企业用户关注。它主要服务于商业客户，是一个涵盖数据开发、管理、治理到上层服务的企业级一体化平台。它在功能上与常说的“数据中台”有相似之处，但也存在差异。其核心是以本体论（Ontology）为基础，进行数据整合、清洗、建模与可视化应用。许多基于 Palantir 的数据决策类应用，在企业环境中都构建于此平台之上，因此 Foundry 也是目前市场上关注度较高的部分。

• Foundry 着力于构建 AI-ready 的数据基础；
• AIP 则专注于高效搭建各类智能体应用。

02 

传统的数据架构通常包含以下层次：底层是数据仓库、数据湖等数据存储与计算基础；之上是数据集成、开发、治理与服务化的能力层；再往上则是直接面向业务的应用层。

而 Foundry 的一个关键差异，在于它在数据基础与上层应用之间，引入了一个“本体层”，或称统一语义层。这一层的核心在于定义对象（Object）、关系（Link）、逻辑（Logic）与动作（Action）。

因此，其架构可以理解为，底层是数据基础设施，中间是数据中台能力，而Foundry在此基础上新增了一个本体层，其上再对接如 AIP 这类智能体开发平台以及最终的智能体应用。

03 

首先，对象层的主要作用是统一业务概念。在企业中，不同部门对同一事物的描述和称呼往往存在差异。对象层的任务正是将这些概念进行标准化，形成一致的理解。虽然传统数据平台也尝试通过数据字典等方式实现类似目标，但 Palantir 的独特之处更体现在上层的逻辑与行动两层。

其次，逻辑层的关键在于明确业务规则。它将业务专家的决策经验、流程逻辑等转化为 AI 可以严格执行和理解的规则库。这既包括基于统计的规则引擎，也涵盖传统的机器学习、深度学习等行业小模型。本质上，这一层沉淀了企业业务决策中的所有规则，使 AI 能够基于历史经验和模型进行判断。

04 

在探讨如何用 Palantir 的本体论实现企业内部知识与工具的运营时，我们发现它提供了一条非常清晰的路径。

当前，许多企业都在尝试落地 Agent 应用，但在实践中常遇到一个关键难题：缺乏足够的企业内部知识。

以之前提到的设备运维场景为例，企业可能已定义了设备名称、具备运维巡检和故障维修的基本 SOP 与标准，但仍然缺失大量关键内容。

缺失的主要是两类知识：一是过程性案例与行动记录。过去，维修人员现场解决问题后，很少会将维修过程中的思考逻辑、依据何种规则进行故障判断和选择检修方式的经验沉淀下来。二是具体行动与系统交互。维修中涉及的实际操作，例如去库房领取配件或工具，以及这些行动与现有系统（如库存系统）的关联，通常也未被系统化记录。

然而，当企业试图让 AI 智能体来承担类似任务时，会发现这些知识和数据恰恰是 AI 理解并完成整个流程所必需的。没有它们，AI 无法实现端到端的执行。

此时，在积累这类知识的过程中，又会浮现一个新的问题，企业内可能存在多个场景、多个团队同时在进行知识积累。如果每个团队都按照各自独立的方式和框架去做，最终很可能又形成一堆“知识孤岛”，这些知识仍然无法被统一调用和整合。

而 Palantir 的本体论恰恰为此提供了一个非常好的知识与工具运营思路。它核心是提供一套统一的理念和知识整理框架，能够将各个场景中 AI 所需的知识有效地统一起来，实现整合管理。

具体来说：

• 对象与关系层，可以对应解决领域专业知识术语、组织架构、岗位职责等静态知识及其关联关系的定义与统一。

  
  

• 逻辑层，则能沉淀内部的决策规则、经验机制和合规要求。例如设备维修中从故障判断到方案生成的背后规则，或是现场施工必须遵守的安全规定，这些都可以纳入此层。它最终沉淀的将是一系列的规则引擎和行业小模型。

  
  

• 行动层，关注的是将思路转化为具体步骤。在判断之后，第一步、第二步要做什么？这涉及到具体的工作流，并且需要与原有的业务系统集成对接，例如从设备管理系统开立工单，从资产管理系统申领物料等。

  
  

05 

大家通常会提到第一代的知识图谱，以及近两年兴起的 RAG，还有两者结合的 Graph RAG 等技术。那么，以本体论为核心的 OAG 与它们究竟有何不同？

首先，与知识图谱相比。知识图谱本质上处理的是对象和关系，它提供的是一个静态的知识网络。它的局限在于，一方面，难以承载动态的逻辑决策；另一方面，也无法驱动具体的行动执行。因此，它更多是呈现一个关系结构，而非一个可运行的决策系统。

其次，与 RAG 相比。RAG 通过检索外部知识来增强大模型的生成，已经引入了动态“思考”的过程。但其主要问题在于精度不足。由于其检索机制与语义相似性，若要获得非常精确的结果，则需在提示词工程和上下文优化上投入大量精力。而且，整个过程高度依赖大模型本身的泛化能力，人为可干预和控制的节点相对有限。

相比之下，基于本体论的路径具有以下明显优势：

1.可执行的决策：它不仅描述知识，还能将逻辑与行动纳入体系，最终输出可落地、可执行的决策或工作流。这是它与静态知识图谱的根本区别。

2.精准的检索：由于本体论在构建时形成了高度结构化的对象、关系、逻辑与行动网络，基于此的检索可以非常精准，直接定位到所需的业务实体、规则或操作步骤，而非模糊的语义近似。

3.深度结构化的上下文：它所提供的上下文具有高度结构化与丰富的业务语义，相比基于文档片段的传统 RAG ，其知识增强效果和理解能力更强。

4.显性化、可调整、可追溯：

• 本体论构建的规则和逻辑是显性化的，可以图形化地呈现出来。

  
  

• 业务专家能够基于这些显性规则进行审查、优化和调整。

  
  

• 整个分析决策过程是可追溯的。如果最终结果或行动出现错误，可以回溯到中间具体环节，定位问题根源并进行修正。

  
  

06 

关于其实现方式，从技术路径上看，它与我们熟知的数据平台或知识工程平台有相似之处。传统数据平台通过开发流程构建数据资产，知识工程平台则将碎片化文档与知识组织成图谱结构。而我们可以将这类平台理解为 “数智本体平台”，其核心同样是进行构建，只不过最终产出的是一个统一的语义层，即本体。

该本体一旦构建完成，其全生命周期的管理、迭代、呈现，以及与智能体等应用的对接，都将基于这个平台来实现。因此，整个技术开发和实现的框架，与原有数据平台并无本质差异。

真正的区别和难点在于构建过程本身。与以往一样，它高度依赖业务专家的深度参与，共同完成本体的设计与填充。这一构建的难度和复杂性，目前看来远超传统数据平台中对数据字段的梳理，也高于一般知识图谱的构建。

因此，本体构建并非适用于所有场景。它更适用于那些流程复杂、需要深度推理，且需求具有重复性的业务场景。这一点很关键，如果一个应用场景只是偶尔出现，或解决问题后类似需求不再频繁发生，那么为此构建本体的投入产出比可能不高。

本体构建的价值，恰恰体现在能够反复应对复杂性高、流程化强的重复性问题之上。这才是它最适合发挥作用的领域。

07 

接下来我们探讨 AIP 这一部分。通常来说，Agent 的落地会涉及几个关键组件：大模型、知识库、流程编排与工具调用。

左图展示了我们以往对 Agent 落地的典型理解，通过一个 Agent 去调用企业的小模型、知识库、辅助流程与工具。这种方式往往是分层、分散的，并且需要部署多种不同能力的 Agent 来逐步完成任务。

而 Palantir 的 AIP 平台在 Agent 开发的产品功能层面，与目前市场上多数的 Agent 开发平台存在较多相似之处，其真正的差异点在于如何更有效地调取本体层的能力。

由于本体层中包含了大量的“行动”，AIP 在设计上会更侧重于与这些行动的安全、可靠集成。相比传统偏静态的工作流实现，AIP 加强了与安全性和合规性相关的优化。例如，它提供了流程模拟功能，允许在实际执行前对整个流程进行预跑，验证其是否能够顺畅执行，如有问题可及时调整。同时，由于许多流程和接口需要与外部业务系统打通，平台在合规与安全层面也会有更多的考量。

因此，从 AIP 这一层来看，目前 Palantir 的产品功能与其他同类 Agent 产品在表面上差异并不显著。它的主要定位，是为了更高效、更安全地调用和支撑下层本体层的能力。这也印证了我们之前的观点，Palantir 目前的核心能力与创新，重点仍在于本体层本身的构建与应用。

08 

在与众多企业用户交流时，许多人会提出一个共同问题：面向 AI 时代，企业内部团队应当如何构建？许多企业既拥有自身的 IT 团队，也成立了数字化公司或数据科技子公司。这些团队都需要思考，面对 AI 场景，应该配备怎样的人才，或者现有的 IT 团队需要培养和构建哪些新的能力。

• Echo团队主要负责与客户共同挖掘场景。其核心工作是深入客户交流，一方面展示相关的用例或 Demo，另一方面通过理解客户需求，共同探讨并确定在现阶段，哪些 Demo 或产品方向能够有效解决客户的实际问题，并为客户带来显著价值。
• Delta团队（部署工程师团队）则更侧重于快速实现。他们擅长利用现有工具，通过快速编写代码来构建解决方案和产品原型。目标是让客户能够迅速看到可交互的 Demo，验证其是否真正符合需求，进而将其部署为可运行的产品。Palantir 的模式核心在于，一方面通过与客户紧密共创来挖掘需求、确定场景方向；另一方面依靠强大的工程能力快速构建原型、迭代验证，直至找到真正契合客户需求的解决方案。目前来看，FDE 团队正是这一模式得以有效运行的关键。

09 

我们可以看到，传统的开发模式通常是：业务部门提出明确需求，由IT部门承接后，或依靠内部开发团队，或寻找外部供应商。再由产品经理或项目经理统筹，进行 IT 开发与实施，最终上线。整个过程是一个传导链条长、周期漫长的线性流程。

然而，在当前尤其是 Agent 应用的场景下，情况发生了很大变化：它要求开发过程高度敏捷，并且能够快速迭代。

这背后有两层原因：

一方面，从技术角度看，模型本身仍处于持续迭代和快速演进阶段。这意味着更先进的工具会不断涌现，团队需要持续学习和应用新技术，因此必须具备较强的快速迭代能力。

另一方面，从客户或业务部门角度看，Agent 场景有一个显著特点，效果立即可见。与建设一个信息化系统需要很长的开发周期、上线后一两年才能看到效果不同，Agent 应用在开发后能快速呈现结果。

业务部门提出需求，可以迅速验证该需求是否能够被响应和满足。如果可以，再逐步完善。因此，整个建设思路与以往大不相同。

在这种情况下，需要一个关键的中间角色，既要深刻理解业务部门的实际场景与需求，又需要清晰把握 AI 的能力边界。这样，才能基于业务需求快速判断，哪些需求当前能力可以解决，哪些暂时无法解决。

这个角色，我们更倾向于称之为“AI BP”。他/她应该与业务部门站在一起，帮助设计和规划产品或方向。这个角色有点类似于Palantir FDE 团队中的成员，兼具共同设计产品和推动快速部署落地的双重能力。

因此，对于整个IT组织而言，未来的工作方式可能会发生改变：

• 无论是通过外部采购还是自建平台，核心目标都是构建一个能让这个“AI  BP”团队高效、快速实现场景落地和上线的支持环境。

  
  

• 在此过程中，最终仍需抽象和沉淀出本体论这一统一语义层。这一层能力虽然其构建工具可以外采，但其核心内容必须由企业结合自身业务来构建和积累。长期来看，这恰恰是企业内部最有价值的资产。

  
  

我们认为 Palantir 的这种模式，以融合业务与技术的敏捷团队为核心，通过快速迭代验证价值，并持续沉淀企业独有的语义层，能够很好地适用于企业面向 AI 的组织转型与场景落地。