導論 · Chapter 01

本質:
Palantir 賣的是三個鴻溝的橋

忘掉「大數據公司」「監控公司」這些標籤。要懂 Palantir,你只需要懂它填的三個坑:語意、操作、部署

Palantir 官方對自己的一句話定義是:「幫組織整合他們的資料、決策與營運的軟體。」注意——不是「儲存資料」,是「整合決策與營運」。這個用詞差異,就是整家公司的全部。

DNA它從哪裡長出來

主張:Palantir 的產品哲學不是從「資料分析」長出來的,是從「在對抗性環境下即時抓壞人」長出來的——這解釋了它為什麼偏執於操作、寫回、與治理。

起源 · PayPal Mafia · 2003

共同創辦人 Peter Thiel、Alex Karp 等人把 PayPal 對抗詐騙的思路(人機協作:讓分析師與演算法一起圍捕詐騙網路)搬出來,成立 Palantir。早期金主之一是 CIA 的創投 In-Q-Tel,第一批客戶是情報與國防機構。

影響至今:他們預設「使用者要對一個具體目標採取行動」,而不是「使用者要看一張報表」。這就是為什麼 Ontology 天生有動能層——反詐騙不能只「知道」,必須「凍結帳戶」。

The Core Thesis核心命題:問題不在資料,在鴻溝

企業失敗,幾乎從不是因為「缺資料」或「缺 ML 模型」。是因為資料與真實營運決策之間,有一道跨不過去的鴻溝。Palantir 賣的就是這座橋。

這道鴻溝其實是三道。理解這三道,你就有了看待 Palantir 全部產品的統一框架:

① 語意鴻溝資料是「行與列」,不是「客戶、飛機、病人」。人腦裡的業務意義沒有進到系統。→ Ontology 語意層
② 操作鴻溝你能「算出」該做什麼,卻不能在同一個地方「做」並寫回源系統。分析與行動斷開。→ Ontology 動能層 + Foundry App
③ 部署鴻溝軟體要能同時活在公有雲、客戶地端、甚至斷網的機密環境,還要持續更新。這是大多數 SaaS 死掉的地方。→ Apollo
三鴻溝合體 · 一個真實場景

一家醫院想做「急診壅塞預測與即時分流」。語意鴻溝:病人資料散在 HIS、檢驗、影像三套系統,沒有統一的 Patient操作鴻溝:就算模型預測某科要爆了,護理長也不能在儀表板上「把病人改分流」——她得走回另一個系統手動改。部署鴻溝:病歷是高敏感資料,雲端合規過不了,軟體必須跑在醫院自己的機房。

一般 BI 廠商只能解語意鴻溝的一半。Palantir 三個都碰——這就是它敢開高價的底氣,也是祛魅時要拷問的地方(這三個真的都需要一家廠商綁在一起嗎?見第 08 章)。


Product Map四個產品,一句話認清

Palantir 的產品線常讓人混亂。用一句話 + 一個範例定位每一個:

產品一句話誰用 / 範例
Gotham情報與國防的調查/目標作業平台(最老)情報分析師把訊號、影像、線報融成一張目標圖 → 第 06 章
Foundry商業世界的資料操作系統,Ontology 的家製造商把 ERP+MES+感測器整成一個可操作的營運分身 → 第 03 章
AIP把 LLM 綁在 Ontology 上,讓 AI 能安全做事agent 讀物件、跑被授權的 Action → 第 04 章
Apollo把上面三者持續部署到任何環境的引擎(看不見但關鍵)同一版軟體,一鍵送上雲、地端、與斷網艦艇 → 第 05 章
心智模型:Gotham 與 Foundry 是「應用平台」,Ontology 是它們共用的大腦,Apollo 是把大腦與應用送到世界各地並持續更新的物流系統。AIP 則是 2023 年之後長在 Ontology 上的 AI 層。四者共用同一個 Ontology,是整套東西能複利的根本原因。

De-mystification祛魅:它是不是一家披著軟體皮的顧問公司?

「Palantir 只是很貴的顧問公司」

攻擊

它派一堆「前進部署工程師(FDE)」駐點幫你客製,本質是人力堆出來的顧問服務,不是可規模化的軟體。毛利遲早被服務拖垮。

回應

早年確實高度依賴 FDE。但 FDE 建的東西沉澱成可重用的 Ontology 與 App,不是一次性交付;而且它的軟體毛利(~80%)其實高於 Snowflake/Databricks。真正該問的不是「是不是顧問」,而是「沉澱下來的資產能不能自我複利」——這才是第 07 章的重點。