核心章 · Chapter 02

Ontology:
為什麼是靈魂

拿掉 Ontology,Palantir 就只是一家貴的資料整合公司。它是唯一讓「資料」變成「可被決策與行動的世界模型」的那一層。

先給你一句能記一輩子的定位,然後我們一層一層拆,而且——照規矩——每一個主張都掛一個具體範例。

決策從來不是對「表格裡的一行」做的,而是對一架特定的飛機、一個特定的病人、一批特定的貨做的。Ontology 的工作,就是把 table-shaped 的資料,變成 decision-shaped 的物件。

The AnatomyOntology 的三層解剖

官方把 Ontology 描述成一個由數十個元件組成的多模系統,但你只要記住它疊在資料層之上、由三層構成。看懂這張圖,後面全部都是註腳:

治理層誰、在什麼前提下、能看到與做到什麼。動態安全、purpose-based access、稽核軌跡。

動能層我能對世界做什麼。Action(改變狀態並寫回源系統)、Function(任意複雜的商業邏輯)、Automation。

語意層世界是什麼。Object(物件)、Property(屬性)、Link(連結)——真實世界實體的數位分身。

資料層底下才是 SAP / Salesforce / 資料湖 / 感測器串流。Ontology 不是這一層——它坐在這一層之上。

關鍵誤解澄清:Snowflake、Databricks 活在最底下那層(儲存與運算)。BI 工具(Tableau、Power BI)只碰語意層的一半、而且唯讀。Palantir 的護城河,幾乎全部在動能層 + 治理層——也就是別人幾乎沒碰的上面兩層。

Layer 1 · Semantic語意層:把「行」變成「物件」

主張:Object / Property / Link 讓「什麼是客戶」被中央定義一次,全公司共用同一份語意,而不是每個 App、每個模型各自從原始表格重新推導。

實體解析 · Entity Resolution

同一個客戶,在三個系統裡有三個身分:

SAP 裡叫 KUNNR = 0004417;Salesforce 裡叫 Account_ID = ACME-TW;工廠 MES 裡叫 cust_code = 88213。「這三筆是同一個客戶」這件事,傳統上只存在某位資深員工的腦袋裡。

Ontology 把它們解析成一個 Customer 物件,帶屬性 .name、.creditLimit,並連到 Order、Shipment。從此之後,任何儀表板、模型、App、AI agent 問「ACME 的信用額度」,都指向同一個真相,不必再各自 join 一次原始表。

主張:Link 不只是外鍵——它讓「關係」成為可被遍歷、可被推理的一級公民。

關係遍歷 · Link Traversal

航空公司問:「3 號引擎供應商延遲,會影響哪些明天要起飛的航班?」在 SQL 世界這是一串痛苦的多表 join。在 Ontology 裡是一句沿著連結走的話:

Supplier → (供應) → Part → (裝在) → Aircraft → (執飛) → Flight.filter(date = tomorrow)

關係本身被建模了,所以「找出受影響的航班」是圖的遍歷,不是 join 的拼裝。這也是為什麼 Palantir 的東西天生適合做「牽一髮動全身」的影響分析。

Layer 2 · Kinetic動能層:90% 的人漏看的決定性差異

這是整份手冊你最該記住的地方。語意層競品還能追;動能層是護城河的核心。

Action:受治理的「改變世界」

主張:一個 Action 不是「更新一列資料」,而是一個封裝了權限、驗證、副作用、稽核、以及寫回源系統的操作。它讓「決策 → 執行」變成一個安全、可追溯的原子動作。

寫回源系統 · Write-back

維修主管在 App 上點下 groundAircraft(N-773)「停飛 773 號機」。這一下,Ontology 在後台做了一串事:

權限檢查確認此人角色是 MaintenanceLead,且對該機隊有寫入權;否則按鈕根本不會出現。
驗證規則檢查前置條件:飛機當前不在飛行中、有可用的替代機。不通過就擋下,並回一句「N-773 正在執飛 BR-225,無法停飛」。
改變狀態把 Aircraft.status 從 IN_SERVICE 改為 GROUNDED。
寫回源系統在維修系統(Maximo/SAP)開一張維修工單,並把受影響的 Flight 標記為待改派。
稽核 + 觸發留下「誰、何時、為何停飛」的紀錄,並觸發下游 Automation 通知排程團隊。

對比 Snowflake:你能算出「這架飛機該停飛」,但你不能在 Snowflake 裡停飛它。這就是 analytical 與 operational 的分水嶺。

Function:活在操作情境裡的商業邏輯

主張:Function 讓任意複雜的商業邏輯被寫成程式碼、版本控管、並在儀表板/App 裡即時執行——邏輯只寫一次,到處重用,而不是散落在 20 個 Excel 與 15 個報表的 case-when 裡。

集中化邏輯 · Reusable Logic

銀行的「這筆貸款要不要人工複審」規則極複雜:金額、行業、擔保品、KYC 風險、地緣制裁名單……過去每個系統各寫一份,結果三個部門算出三種答案。

在 Ontology 裡寫成一個 requiresManualReview(loan),回傳 true/false + 理由。放款 App 用它、風控儀表板用它、之後的 AI agent 也用它——同一段邏輯,同一個答案。改規則?改一個 Function,全公司同步生效。

Layer 3 · Governance治理層:讓「安全」不是事後補丁

主張:權限不是綁在「表」或「欄」上,而是綁在物件與目的(purpose)上,並且是動態的——同一個 Object,不同人看到的內容不同。這是政府/醫療/金融能用它的前提。

動態安全 · Purpose-based Access

醫院裡有一個 Patient 物件。護理師登入,只看得到自己病房的病人,而且看不到 HIV 狀態欄;主治醫師看得到完整病歷;帳務人員只看得到帳單相關欄位、看不到診斷。

這不是三個不同的資料表,是同一個 Patient 物件,由治理層依「你是誰 + 你為什麼要看」動態決定露出什麼。權限跟著物件走,不是跟著報表各做一份——這也是為什麼它敢碰機密與個資場景。

The Closed Loop為什麼叫「operational」而非「analytical」

主張:三層合起來,讓迴圈閉合。分析型資料棧停在「洞見」;Ontology 一路走到「寫回操作系統」,再由新資料回饋成下一輪的洞見。

閉環 · Sense → Decide → Act → Sense

感知感測器串流更新 Aircraft.engineVibration,超過門檻。
決策Function 判定風險等級,操作型 App 把這架機推到主管的待辦清單最上面。
行動主管按 groundAircraft(),寫回維修系統、改派航班。
再感知維修完成的資料流回,狀態自動變回 IN_SERVICE,迴圈重來。

Snowflake / Databricks 天生只有第 1–2 步。第 3 步(帶治理的寫回)是 Palantir 把自己和「資料倉儲」永久區隔開的地方。

The Moat in the LLM Era為什麼 LLM 時代,Ontology 反而更值錢

2026 年的殘酷現實:LLM 已經商品化。沒解決的是——怎麼讓一個「機率性文字產生器」安全地在企業裡真的去做事。Ontology 一次解掉三個要命問題:

LLM 的問題	Ontology 如何解	具體範例
幻覺	給模型結構化的世界模型去推理(對 Object 做檢索,不只是對文件)	問「ACME 逾期金額多少」,答案來自 Customer 物件的真實屬性,不是模型瞎編
不懂業務	Object/Link/Property 本身就是你的業務語意,直接當 context	模型知道「機隊→飛機→航班」的關係,因為那是建模好的圖
不能安全行動	模型只能呼叫 Ontology 允許的那組 Action 當工具;模型提議,Action 的權限與驗證把關	agent 想停飛,只能走 groundAircraft(),一樣要過驗證、留稽核——它拿不到「直接寫 DB」的權力

「模型不是產品,Ontology 才是產品。」模型是可抽換的零件——今天 GPT,明天 Claude,無所謂;Ontology 是沉澱下來、換不掉的資產。

AI 的手銬與手 · Governed Agency

你對 AIP agent 說:「幫我處理今天所有高風險逾期帳戶。」它不是自由地去操作資料庫,而是:讀 Account 物件 → 用 riskScore() 篩選 → 對每個帳戶提議 freezeAccount() 或 escalateToHuman()。每個 Action 一樣跑權限與驗證,一樣留稽核。

Ontology 同時是 AI 的手(讓它能做事)和手銬(限制它只能做被授權的事)。2026 年他們更把這套 Action 集合包成 OMCP(Ontology MCP server),讓外部 AI agent 透過 MCP 標準協定連進來讀物件、跑 Action——等於把「企業的動作層」變成 AI 世界的標準工具介面。

The Flywheel為什麼是護城河,而不只是功能

主張:Ontology 是一塊一塊堆出來的資產。建好之後,每個新用例都重用既有物件,第 N 個 App 的邊際成本大幅下降——這就是 land-and-expand 的引擎,也是轉換成本高到嚇人的原因。

重用複利 · Compounding Reuse

某製造商第一個用例是「供應鏈可視化」,為此建了 Part、Supplier、Factory、Shipment 四個物件(這步很貴,要 FDE 陪跑)。

第二個用例「產能規劃」——零新建物件,直接接既有的 Factory 加幾個 Action。第三個「碳排追蹤」又重用 Shipment。到第十個用例,交付幾乎只剩「組裝」。這就是為什麼 Palantir 客戶一旦過了臨界點,用量會指數上升——而要換掉它,等於把整個營運模型重新編碼一遍。

De-mystification祛魅:一個 CTO 該有的懷疑

不賣你信仰。這裡是懷疑論者最狠的攻擊,以及工程上誠實的回應。

Ontology 是不是只是舊東西的重新包裝?

攻擊

語意層(dbt)、主資料管理(MDM)、商業流程引擎(BPM)、權限系統(RBAC)——每一塊都是二十年的老技術。Ontology 只是把它們換個酷名字打包,再收十倍的錢。

回應

個別零件確實不新。但 MDM / 語意層 / BPM 專案失敗了幾十年,正因為沒人把它們整合成一個「可治理、可部署、可寫回」的單一基座。整合本身 + 讓它真的上線的紀律(FDE + Apollo)才是價值。

反例:失敗的 MDM 專案

一家企業 2015 年花兩年做 MDM,建了漂亮的「客戶主檔」。結果:它是唯讀的,沒有動能層——沒人能對主檔「做動作」;它跟操作系統不同步,三個月後就過時;沒有治理層,合規不敢讓它碰敏感欄。於是它變成一個沒人用的昂貴目錄。Ontology 之所以不同,正是因為它強制把動能與治理長在語意上,而不是各做各的。

鎖定與黑箱

攻擊

你把整個營運模型編碼進一個專有層,資料血緣、邏輯、動作全在 Palantir 手裡。哪天想走,遷移成本天文數字——這不是護城河,是人質。

回應

這是真實風險,不該粉飾。緩解點:底層資料仍在你的雲/倉儲、可導出;OSDK 讓邏輯以標準 TypeScript/Python 存在;但 Action/治理/血緣的語意確實綁在平台。導入前務必把「退出成本」寫進評估——見第 08 章。

你真正該盯的問題:Ontology 的護城河能撐多久?Databricks(Unity Catalog + agents)、Snowflake(Cortex + semantic views)正在往上補語意層。但目前 Palantir 領先的三件事——動能/寫回層、跨安全邊界的部署、把東西真的推上線的紀律——競品都還很弱。這三點會不會被補上,就是你判斷「值不值」的主戰場。完整比較在第 08 章。

Ontology:為什麼是靈魂