Palantir是如何把咨询能力产品化的？

发布日期：2025-12-25 15:48:24 浏览次数： 2494

作者：见城见智

微信搜一搜，关注“见城见智”

咨询能力，历来被视为人类智慧的高地。它依赖精英大脑的经验、直觉与判断来处理复杂非标的难题，因而长期被认为注定无法被自动化或算法化。本篇我们一起来看看，Palantir 是如何把那些原本只能依靠人力填坑的非标经验，提炼并封装为可无限复用的标准化能力的。

01 FDE，前向部署工程师

在企业软件市场，特别是 Palantir 起家的政府、国防和重工业领域，核心挑战并非是数据匮乏，而是数据的繁杂。每一个大型组织中，都存在着ERP、传感器、自行开发的多个烟囱系统和大量Excel 表组成的独特且混乱的数据“大杂烩”。

要如何充分使用这些数据？传统咨询公司的解决方案投入大量人力，编写定制代码。这些代码通常是不可复用的、脆弱的，并且随着咨询顾问的离场而陷入不能满足业务变化的过时。这是一种卖服务的模式，其价值在于人力的持续投入。

Palantir认识到，系统集成的问题需要人类智能来理解客户数据的语义，但解决方案必须是一个在人类分析师离开后仍能运行的平台。这种二元性需求催生了前向部署工程师（Forward Deployed Engineer, FDE）这一角色的诞生。

Palantir 内部将工程师分为“Devs”（负责构建核心系统的研发工程师）和“Deltas”（即 FDE，负责与客户坐在一起解决问题）。与仅仅配置软件的销售型工程师不同，FDE是拥有完整代码库访问权限的软件工程师。他们的任务是解决客户最棘手的问题，如果现有平台功能不足，他们被鼓励直接编码来解决问题。他们被要求使用平台现有的组件，来构建原型，满足需求。如果组件缺失，则会与产品开发团队合作，将其构建到平台中。

这就是从咨询现场到组件的反馈循环，咨询业务实际上是在为产品的研发买单。

在 COVID-19大流行期间，FDE 被派往全球各地（基本是西方国家）的政府机构，协助管理个人防护装备和疫苗的供应链。这是一种典型的咨询场景：客户面临紧急危机，数据混乱，且没有现成的软件可用。

FDE 并没有花几个月时间进行需求访谈。他们直接开始处理混乱的数据，在几天内构建了供需匹配的工作流。FDE 在现场构建的这些工作流，实际上建立了通用的供应链中断管理模式。这些配置被迅速抽象化，并在随后成为了 Foundry（Palantir的核心产品之一）中的供应链原型的基础。原本为了应对公共卫生危机而进行的人力密集型救火工作，最终变成了一个标准化的软件模块，并在疫情后被出售给汽车制造商（如通用汽车）和零售商，用于管理半导体短缺和物流中断。

Ontology，本体

将咨询能力产品化的首要技术载体是 Palantir Ontology。在传统的IT咨询中，交付物通常是信息化系统，它们将底层数据映射到业务问题上。这些系统通常是静态的、硬编码的，并且与特定的业务数据源紧耦合。

Palantir 将这整个工作层抽象为一个动态的软件对象层，称为Ontology（本体）。本体作为组织的数字孪生，将数据集成的复杂性与业务决策逻辑进行解耦。

对于软件业的从业者，ontology绝不是一个陌生的词。Ontology在计算机科学中，特别是在语义网、知识图谱领域中，是一个存在了几十年的概念。但我们熟悉的本体通常是描述性的、分析性的，用于解决数据异构问题，做知识推理或语义搜索。

Palantir 的 Ontology 与传统定义的核心差异在于，它不仅是只读模型，还是写入和执行的接口。Palantir在语义层之上，加了一个操作层。

例如，你从 SAP、Salesforce 中抽取数据，清洗后存入图数据库（如 Neo4j）中后，可以在图谱上做复杂的关联查询（例如：“找出所有购买了产品 A 的客户的关联公司”）。但如果你想修改客户的地址，你不能在图谱里改，你必须回源到 SAP 里去改，然后再重新抽取数据一遍。但Palantir 的 Ontology是可操作的。Palantir 在对象上定义了行动类型（Action Types）。当你在 Palantir 界面上修改了客户对象的地址时，Ontology 不仅更新图谱中的状态，还会将这个变更回写到SAP或 Salesforce中。

Archetype，原型

2015年，空客面临其 A350 机型产能爬坡的严峻挑战。工程、供应链和装配团队之间的数据孤岛导致生产进度停滞，不仅影响交付，还面临巨额违约风险。Palantir 派遣 FDE 团队介入解决这一问题。

在2015-2016年，FDE 手动集成了来自进度表、零件数据库、缺陷报告和机组人员轮班表的数据。他们构建了 A350 装配线的单一数据源，这使得管理层能够实时看到瓶颈所在。A350 的交付速度加快了 33%，帮助空客实现了年度目标。随后，Palantir 和空客意识到这不仅是一个 A350 的生产问题，而是一个全行业的通用问题。他们将解决方案的范围扩展到包括飞行数据、维护日志和航空公司的运营数据。接着，双方合作推出了 Skywise，一个面向整个航空行业的开放数据平台，连接了140 多家航空公司和 10,000 多架飞机。

最初为了修复生产线而进行的咨询工作，演变成了全球航空业的行业平台。Palantir 不再需要向每家航空公司派遣 50 名 FDE 来构建数仓，他们只需出售 Skywise 许可证。航空公司加入平台不仅是为了管理自己的数据，更是为了利用基于全球机队数据训练出的预测性维护模型。

汲取 Skywise 的经验，Palantir开始主动将 FDE的行业经验打包成 Archetypes（原型）。原型不是模板，它是本体的一个预配置视图，包含了数据连接器、对象定义、业务逻辑和用户界面，专门用来服务特定的行业。这些原型的存在，让Palantir 不再需要通过长达半年的咨询项目来证明价值，而是可以在几天内通过部署原型，让客户看到自己的数据以结构化、可操作的形式呈现。

04 Gotham、Foundry和Apollo

Gotham（2008）、Foundry（2016）和Apollo（2021），是Palantir相当重要的3个系统。

为了解决情报界数据孤岛问题，Palantir 在2008年开发了 Gotham。在这一阶段，核心挑战是如何将来自不同机构的异构数据整合到一个图谱中进行关联分析。这个时期确立了本体作为数据集成核心方法的地位。随着业务拓展至商业领域，Palantir 发现企业面临类似的数据整合挑战，但需要不同的分析方法，这个阶段Foundry 应运而生，继承了Gotham 的本体思路，但增加了大规模数据处理和低代码应用构建能力。随着客户环境日益复杂（如潜艇、石油钻井平台等），传统的手动运维变得难以维持。Palantir 将内部使用的自动化部署工具产品化为Apollo，负责在各种环境中部署、管理和保护整个软件栈。