万字长文！不要尬吹Ontology本体论，中国也不会有Palantir

一直很奇怪为什么那么多人追崇Palantir这家公司。

中国不会有Palantir，在美国它也是非常特殊的存在。

这个公司不是近几年才火的，十年前投资行业追大数据概念的时候就已经很火了，当时同事还给我传过它的BP资料，当然我们国企不会去跟进这种海外项目。这十年间，国内拿Palantir作为对标、讲故事的大数据公司一抓一大把，但跟它做一样事情的大数据公司一个都没有。

我不会去否认Palantir的特殊价值，毕竟它一直都是独占鳌头的，业绩和市值也摆在那里。

Palantir的成功给做国内Ai软件to B业务的创业公司和投资人很大信心，我在朋友圈看到（尤其是人民币基金）的大部分投资人都是非常喜欢研究这家企业的。

但如果用来讲“中国本体论和对标Palantir”的故事，我就是泼冷水的一方。

一、Palantir的存在很特殊，Ontology属于封闭系统下的技术选型

Palantir，它的政商关系、它的业务和客户、它采用的产品技术路线，都是很特殊的。但正是因为它的特殊性，你无法投出或复制下一个Palantir。

政商关系占主导。彼得蒂尔跟政治圈保守派的人走的很近，在硅谷科技圈被认为是自由意志主义（libertarian）的代表人物。像CIA、FBI这种总统任命下的情报组织，把业务给亲近政治圈、经过实战验证的供应商是很合理的。

并且，政治圈并不以商业能力为唯一、首要导向，比如“追踪本拉登”过程中Gotham提供了情报整合和关联分析支持的作用，这一个业绩就足以锁定未来的重大合同了。关键事件导向>>>商业业绩导向。同时也是结果导向，甲方不懂、也并不关心你背后的技术路线。但这种“事件&结果导向”很难简单移植到企业圈的。

特定业务和客户下的技术选型。

作为情报这种封闭系统，早期在技术选型上用Ontolopy本体论是合理的。

因为情报系统需要通过实体迅速找到关联，比如“本拉登”相关联的人员、资金、通讯、地理信息。而且数据也是封闭的，那些军政部门数据、间谍情报数据、截获通讯、空天防卫数据、历史战事、公共安全数据等等，不同于互联网的开放信息空间，Ai大模型都是涉猎不到的。尤其是在深度学习和大模型思维链和推理能力不足的2010-2019年代，Ontology通过人为构建的概念模型和语义关联，能够实现用户端可解释、可审计的情报分析效果，这正是Palantir首款产品Gotham能发挥价值的地方。

反过来讲，开放世界中商业企业和老百姓现实生活的大量信息——电商交易、供应链流转、金融风控、医疗病历——对情报系统没什么用，比如不需要推荐算法，也不需要处理海量消费行为数据。

因为企业端远比情报系统更复杂，Palantir的本体论方法论适配情报系统，却并非天然适配企业级to B业务，它自己拓展企业级商业市场时也有长达数年的产品化调整和Foundry平台的迭代过程。这里面我认为Palantir进行了很长时间的数据底座和Ai的“补课”，这恰恰是它能够拓展to B业务的技术重心，而不仅仅是本体论。

在大模型的今天，如果中国的大数据/企业服务企业从头去学习Palantir十几年前的本体论，却忽略底层数据工程能力和先进Ai的底层技术，那就是刻舟求剑、把路走偏了。

二、Palantir技术体系的演进：从本体到数据底座与Ai

1、Palantir的本体论本身是很“陈旧”的。

本体论是上个世纪就有的，所谓实体、关系、属性（三元组）也是知识图谱/专家系统的基本元素，大范围属于符号主义Ai。在算力匮乏的上世纪50年代到80年代，符号主义Ai就是主流范式（事实垄断），业界在专家系统研究方面投入了大量精力。后来90年代互联网兴起，语义网络和知识本体成为研究热点，并且谷歌于2012年提出“知识图谱”并应用于搜索引擎优化、智能问答、推荐系统等领域。

由于符号主义系统都是熟悉业务的专家预先定义好了的知识结构和规则，对于已经编码的常见问题，处理速度很快——规则一经触发，就很快完成推理。

Gotham（2008年左右推出）：面向国防、情报、执法的数据融合与情报分析平台。其核心是将多源异构情报数据（HUMINT、SIGINT、IMINT等）整合为统一的、可操作的知识视图，支持地理空间分析、社交网络分析、时序关联等。

现在的Gotham已经发展为一个动态本体Dynamic Ontology产品（其实与企业级Foundry产品类似），这是一个将多源异构情报数据整合为统一的、可操作的知识资产平台，一个可以到行级和字段级军事安全的动态图谱结构。

基础设施层：Foundry（数据管道、分支、数据集、权限）、Apollo（隔离网络代码部署配置与更新）、Security Framework（访问控制和动态权限）

数据层：RevDB（版本控制数据库，类Git）、Horizon（内存数据库、类Apache Spark）、Federation（联邦查询，外部数据库的按需查询）

本体层：Object Types（对象类型）、Link Types（关系类型）、Properties（属性）、Action（动作）

应用层：Graph（图谱可视化）、Map（地理空间）、Object Explorer（对象浏览）、browser（对象详情）、Dossier（情报报告）、Chat（协作通信）。

我让Kimi画了几张图来描述Gotham（或Foundry吧）这种知识本体架构与主流神经网络的差异，【注：这里图有点错误，

DevDB、Dynamic Ontology等是后面Foundry产品才有的，Gotham不具备；反正理解它们与神经网络的差异的意思就行了】：

Gotham这种系统适应自上而下的规则逻辑，是人为设计的模拟决策系统。其优势是可解释性、精准执行，以及人为设计的灵活定制，比如分析师可以添加/移除/重新排列节点。作为语义框架，每个关系、查询、操作可被追溯，满足国防和情报领域对问责制的要求。

但这类符号主义体系的知识本体也存在明显的短板：意味着依赖专家知识、初始构建成本高、不具备扩展性、无法scale。并且容易系统老化、需要人为维护，

很容易背负“技术债”。

这与连接主义Ai（神经网络）的“学习能力”背道而驰。

随着先进Ai技术的持续演进，2006年的深度信念网络，2012年的AlexNet，2016年的AlphaGo，2017年的Transformer，2018年的Bert，2020年的GPT3，2022年的思维链，连接主义是当前Ai的主流，尤其是大模型统一了语言和视觉的技术底层，发展自主Agent能力，并向多模态和世界模型进发。符号主义Ai已经完全落后了。

当然Palantir的Ontology并非传统静态知识图谱，其工程化设计比如RevDB的版本控制、Transforms数据管道、Dynamic Ontology动态语义等，大大缓解了技术债。Ontology的技术债依然存在，初始设计仍然需要业务专家深度参与，本体结构的重大调整仍然成本高昂，数据管道的复杂依赖网络也会随时间积累债务。

2、延伸到企业级，必须强化吸收数据库基础能力。

Palantir作为盈利导向的大公司，早已从情报系统延伸到大型商业公司。2016年就推出了耗时7年的Foundry，时间非常久，我理解为Foundry的软件架构势必要比Gotham复杂地多。这期间的资本投入，

Foundry里面Ontology语义层应该不是最难的，我猜测企业级的全栈数据库和数据处理层才是花钱的重点——如何将异构数据源、批流一体计算、权限、版本控制、回写一致性，封装到一个涵盖Ontology语义层的平台中。这是克服知识本体技术债的必然路径。

1）Palantir Foundry的数据封装和微服务组件

我们先把Foundry数据库中的术语与关系数据库/流式数据库中的术语进行一一对应（从简单的概念角度反正都是一致的），建立初步印象。那么所谓Object对象、Property属性、Link关联、Action动作等所谓本体论的东西，与数据库中的技术概念其实也是一样的嘛（但并非等同）：

Object（对象）,Table Row / Record（表行/记录）,Event / Entity（事件/实体）

Property（属性）,Column / Field（列/字段）,Field / Attribute（字段/属性）

Link / Relation（关联）,Foreign Key（外键） / Join（连接）,Stream Join / Event Relationship（流式关联）

Backing Dataset（支撑数据集）,Base Table / Source Table（基表/源表）,Source Stream / Input Topic（源流/输入主题）

Primary Key（主键）,Primary Key（主键）,Key / Partition Key（键/分区键）

Time Series（时间序列）,—（关系数据库需额外建表存储历史）,Stream / Time-Series Data（流/时序数据）

Function（函数）,Stored Procedure / Trigger（存储过程/触发器）,User-Defined Function (UDF)

Action（动作）,DML Operation (INSERT/UPDATE/DELETE) + Trigger（数据操作+触发器）,Stream Processing Job（流处理作业）

Write-back（回写）,ETL / Data Pipeline Write（ETL写入）,Sink / Output Connector（输出连接器）

Phonograph（留声机/同步引擎）,Change Data Capture (CDC) / Transaction Log（变更数据捕获/事务日志）,Event Log / Commit Log（事件日志/提交日志）

Traversal（遍历）,Recursive CTE / Graph Query（递归查询/图查询）,Stream Graph Processing（流图处理）

Lineage（血缘）,Data Dictionary / Metadata（数据字典/元数据）,Stream Lineage（流血缘）

Granularity（颗粒度）,Table Partitioning / Row Granularity（表分区/行粒度）,Event Granularity / Window Size（事件粒度/窗口大小）

Cardinality（基数）,Cardinality Constraint（基数约束）,Join Cardinality（连接基数）

Multipass（权限控制）,Row-Level Security (RLS) / Column-Level Security（行级/列级安全）,Stream ACL / Field-Level Security（流访问控制/字段级安全）

Scenarios（沙箱/情景）,Database Snapshot / Clone（数据库快照/克隆）,Stream Replay / Branching（流回放/分支）

Object Graph（对象图谱）,Entity-Relationship Diagram (ER图) / Graph View（实体关系图/图视图）,Event Graph / Knowledge Graph（事件图谱/知识图谱）

Ontology Management App (OMA),Schema Designer / DDL（模式设计器/数据定义语言）,Stream Schema Registry（流模式注册中心）

Workshop（低代码平台）,Application Layer / ORM（应用层/对象关系映射）,Stream App Builder（流应用构建器）

Digital Twin（数字孪生）,Materialized View / Dashboard（物化视图/仪表盘）,Real-Time Dashboard / Live View（实时仪表盘/实时视图）,

Palantir 的 Ontology 本质上就是一个面向业务人员的、包装精美的数据建模层。它将数据库中已有的概念（表、行、列、外键、存储过程、触发器、物化视图、CDC 等）用业务语言重新命名，并叠加了可视化界面和权限控制。其"本体论"的哲学外衣之下，底层实现仍然完全依赖传统关系型数据库和流式处理系统的技术栈——并没有发明新的数据管理范式，而是做了语义层的重新封装。

我们看看Palantir从数据到语义的封装结构，我让Kimi画了一张图：

抛弃概念，看看具体的微服务架构设计。Palantir Foundry的数据封装层（微服务架构设计），有一些核心服务：

A. 数据基础设施层微服务组件：

Foundry Pipelines，数据管道，特征工程+模型训练，输出为版本化数据集，

Spark Compute，计算引擎，Foundry Pipelines的底层执行引擎，支持批处理和流式计算的统一，

Foundry Datasets，原始文档（PDF、图像、视频）存储为版本化数据集，支持Git式的分支、合并和版本控制，

Virtual Tables，联邦查询表，允许零拷贝访问外部数据（如Delta Lake），无需将数据迁入Foundry，

Streaming Datasources，

流式数据源，支持 Kafka/Pulsar 等实时数据接入。通过 Funnel Streaming 实现低延迟索引（秒级到分钟级），

B. 数据层微服务组件：

官方说有300+微服务，负责语义的定义、数据查询、写入编排与治理，典型的比如：

Object Storage V2 (OSv2)，新版对象存储，从第一性原理重建。分离索引与查询职责，支持水平扩展、增量索引、多数据源对象类型，单类型支持数十亿对象，

Ontology Metadata Service，定义对象Object Types、关系Link Types、动作类型Action Types、函数Functions等，是 Ontology 的"schema 源"，

Object Set Service，读服务，搜索/过滤/聚合/加载，支持Object Set（对象集合）的静态/动态定义，

Action Service，写服务，带副作用的受控写入，负责应用用户编辑到Object Databases，每次提交生成Action Log，支持事务级校验、权限控制、以及外部系统回写的闭环确认——并非简单Webhook，而是"Action Service → 外部API → 业务确认 → Ontology状态更新 → 失败标记"的完整流程，

Object Databases，索引存储对象数据，OSv2 的核心组件。负责存储已索引的对象数据，优化快速检索，非通用查询数据库，

OSv2 中采用多专用数据库并行架构，

RevDB，版本控制数据库，类似Git的分布式版本控制系统。记录数据谱系、变更历史和血缘追溯，支持分支开发和审计，

Funnel，编排写入，CDC（Change Data Capture）同步。数据不是每次都查询都从源系统实时获取，而是通过CDC机制预索引到对象数据库，粒度为对象级。

Funnel Batch Pipeline批处理索引管道，内部作业管道，从数据集或用户编辑中高效索引数据到 Object Databases；Funnel Streaming Pipeline流式索引管道，以Foundry Streams为输入，实现低延迟数据索引，

另外还有一些扩展服务：Functions on Objects，函数服务，无副作用的计算逻辑。Action Log，审计日志。Scenario，沙盒推演，基于写时复制（Copy-on-Write）的逻辑分支。Search Around Engine，关系扩散引擎，处理对象间的链接遍历和关系扩散查询（如"查找与某客户关联的所有订单"，OSv2 中采用基于Spark的查询执行层）。Ontology Manager，本体管理工具，供数据工程师和业务专家合作构建 Ontology。

C. 应用层微服务组件：

比如Workshop低代码应用构建器、Object Explorer对象搜索发现工具、Insight对象分析工具、Contour/Quiver专有可视化工具、Objects API Gateway外部接口网关、Fusion数据融合工具、Data Lineage数据血缘服务

上述数据层组件支撑上一层即语义层的Ontology原语，比如Object Types、Link Types、Action Types、Functions、Semantic Search、Media Reference等。再经过这些语义层（Semantic+Kinetic）组合映射成为语义资产层（Semantic Assets），即Model/Document/Metric。

例如，一个"飞机"对象可以有一个maintenance_report属性，其值为指向PDF文档的Media Reference，该文档通过语义搜索可被检索和关联。

2）吸收新一代数据底座和数据处理层技术

同时期Snowflake、Databricks等公司的云数据平台技术正在引领行业新一代大数据技术的发展，Palantir的数据库从情报系统要转型支持企业级，但是数据异构、多源、规模大，已经不再适应新时代要求，需要更健壮的数据层才能支撑语义本体建模。Palantir吸收了Snowflake、Databricks的Lakehouse的技术理念，并将Ontology后端基于Object Storage V1（Phonograph）（OSv1）索引和查询耦合的单一架构，升级为OSv2读写分离的架构。

早期Palantir的数据技术不足体现在：索引和查询集中在同一backend，无法独立扩展。数据量增长时，性能互相制约。数据更新时需要全量重建索引，无法增量更新，开销巨大。当数据量达到数百亿级对象需求时，Palantir的Horizon数据库就无法水平扩展了。

Palantir开始引入类似Lakehouse开放兼容的技术。我按自己的理解划分，分了数据底座层、数据分析层、逻辑语义层来进行比较：

A. 在数据底座层，Foundry的数据底座逐渐向与同时期的Lakehouse数据湖架构演进，从架构、存储、计算、索引、权限等各方面全面寻求改变：

OSv2读写职责分离。写入由Object Data Funnel统一编排（多数据源），查询由Object Set Service对外服务。OSv2通过一个异步漏斗（Asynchronous Funnel）架构实现了数据流与语义层的解耦，不再依赖Phonograph中的回写数据集。

Foundry从Horizon的专有格式转变。支持Parquet/Iceberg作为底层存储格式，2025年引入Virtual Tables，实现了跨平台的语义访问。Foundry Datasets底层采用对象存储（S3/ADLS），实现云原生架构。

Foundry Pipelines采用Spark/Flink作为统一计算引擎，实现批流一体。SQL查询支持Photon向量化引擎实现12x性能提升。支持serverless计算。

OSv2引入增量更新/Z-Ordering，即funnel增量索引，仅处理变更数据，支持单一对象类型索引数百亿实例。

OSv2支持列/属性级权限。

2025年Palantir与Databricks宣布战略合作，改善了自己的存储和计算层。引入Virtual Tables技术，意味着 Lakehouse的开放基础设施可以作为Foundry语义层的底层数据底座，Foundry的Ontology直接映射到Delta Lake表，无需数据迁移。亦可用Databricks Spark Pushdown替代内部Spark。

B. 在支持数据分析的“中间”层，我们可以看看Foundry产品哪些地方是被Lakehouse类产品替代/增强的，我让Kimi从流式事务处理、关联聚合、星型/雪花模型、BI支持几个分析维度进行了比较：

流式事务处理：Delta lake可提供开源的ACID事务保证，支持structured streaming实现流批统一；毫秒级延迟，自动Z-Ordering和列跳过优化；Python引擎加速SQL查询。对比而言，Foundry streaming是专有实现，支持事务性和原子性，但Python支持有限（仅Java支持流式转换）。

关联聚合：

Spark SQL/Photon引擎支持物理预聚合和物化视图；Z-Ordering优化多维查询，列式存储加速聚合；星型/雪花模型的物理事实表+维度表结构。Ontology方案采用高度规范化的对象-关系模型，聚合通过逻辑图遍历实现，无物理星型结构，查询性能只能依赖逻辑层优化，聚合性能差异巨大。

星型/雪花模型：Lakehouse类方案，dbt提供成熟的维度建模框架，物理事实表+维度表；与Tableau/PowerBI等BI工具原生兼容。Foundry的Ontology方案是对象导向的规范化模型，无物理事实表/维度表之分，所有数据以对象Object和关系Link形式存在。

BI 支持：Lakehouse类方案，Tableau/PowerBI通过标准JDBC/ODBC连接，比如Databricks SQL Serverless提供原生BI连接器。Foundry方案中，Contour / Quiver是专有可视化工具，仅Contour提供有限SQL支持， BI工具成熟度和用户基数不足。

C. 逻辑语义层，这就是Foundry的强项了。Foundry的语义架构被分为了三层：语义层，定义对象、属性、关系；动力层，受控Action写入外部系统；动态层，实时模拟、多步优化和Agent决策。

Lakehouse的语义层仅提供"数据指标定义"，缺乏Foundry的"动作"层——即带有副作用和权限控制的写入/操作类型（如"批准采购订单"、"标记异常交易"）。

一般数据库Unified Catalog提供表/列级治理，但缺乏对象级动作治理，而Foundry的Ontology内置治理，每个对象、关系、动作都有细粒度ACL；安全治理方面，在国防/情报场景中，Foundry的FedRAMP High和机密网络部署能力仍无可替代；Foundry的Workshop允许非技术人员基于Ontology构建运营应用，这是Lakehouse生态（面向数据工程师）所缺乏的。

可以认为Ontology语义层是最重要的区别，但是如果仔细研究，就发现其实Palantir早期对Foundry语义层的对象定义也并不复杂，就是在数据库表查询之上的人为“封装”成Ontology版的“格式/协

议”；早期kinetic层触发全为规则层面的，如简单规则、函数规则、权限规则等。

Palantir只是在它擅长的领域积累很多年而已。

Palantir的真正壁垒不在于Ontology概念的先进性，而在于将语义层与数据管道、权限治理、回写闭环、嵌入式服务深度耦合的工程能力，以及在情报和高端商业场景中积累的领域Know-how。

3、积极拥抱Ai，推出AIP平台。

1）AIP，受控的LLM

在Ai时代，Ontology架构这种人为设计的业务逻辑和执行动作，在深度学习和大模型时代也就显得落伍了。Palantir所用的技术也在积极扩展，更是积极拥抱了Ai。

2023年Palantir整合了LLM大模型推出AIP平台。

AIP的组件包括：AIP Logic，这是个低代码环境，定义LLM工作流；AIP Agent Studio，用来配置多Agent协作网络；AIP Evals，确定性测试框架；AIP Assist/Analyst，对话式查询Ontology数据。

2024-2025年，Palantir与英伟达深化技术合作，在AIP中集成NVIDIA AI Enterprise和GPU加速能力，提升大模型推理性能。同时，AIP保持模型中立，支持OpenAI、Anthropic、Meta、Google等多厂商模型接入。 

但是AIP并非对Ontology的替代关系，而是在Ontology之上的编排层（感知推理），LLM大模型被“栓”在Ontology的物理现实（操作约束）之上。Gartner评价AIP，“复杂的初试设置仍然需要专家帮助”，看不出哪里能够LLM自动化。

2）传统Ontology构建方式面临挑战

目前语义层的行业趋势是，利用大模型上下文自动提取语义，这可以对传统人工构建Ontology的模式构成冲击。在大模型LLM和自动化Agent面前，需要重新评估Ontology的适应性。

Palantir的本体技术的保留场景是：

业务规则的显式表达（如事务一致性、同步要求），规则要求精准建模，而不能依赖隐式推理，

快速确定性的action执行，比如毫秒级业务操作（比如“冻结账户”），成本角度不需要浪费大量token的概率思考，

可以减少LLM对于多源异构数据的语义幻觉与冲突，

细粒度权限控制，满足审计与合规要求。

Palantir的本体技术的长期缺陷是：

构建Ontology本质是声明式的，

需要FDE驻场开发，每次新增数据源/业务流程变更/组织架构调整，都要人工重新建模，

大量的技术债，就像前面吸收Lakehouse技术、被拴住的AIP一样，变革影响面难以预估，

只是说Palantir在特殊的历史时期（2003至2015年），通过Ontolopy的传统知识工程技术、在特殊的客户场景“骗”成功了，并一步步链接到了新一代Lakehouse的数据底座、Ai大模型技术体系。这种成功路径是无法复制的。

3）Palantir的Ai自救，AIP对Ontology的变革

Palantir也意识到这些问题，并且推出了HyperAuto工具，试图自动化部分Ontology构建。自动化读取源系统元数据，理解表结构、字段含义和关联关系，并且自动推断数据同步方案、转换逻辑，甚至生成本体草案（仍需FDE审核和调优）。

AIP对Ontology的“变革”体现在：

AIP通过OCR/VLM文档解析自动提取实体和关系，

AIP将非结构化数据向量化，嵌入Ontology对象，支持RAG查询，

AIP Analyst允许自然语言对话式建模，查询和修改Ontology（修改由专家完成），

AIP Logic中的LLM（Agent）被“教会”使用Ontology工具，

AIP Agent Studio编排多个LLM，

AIP Evals用确定性规则测试概率LLM的输出，定义“评估包”，验证LLM行为稳定性。

但是AIP依然看起来是很初步的外部补充，更像是“智能消费界面”、“辅助构建工具”，而非“自动构建引擎”。而且目前的Agent技术编排能力自身也还不够，主体依然是Ontology体系。

Palantir的竞争对手Uniphore Business，则更进一步，明确提出了"Emergent Ontology"（涌现式本体）概念，试图将Ontology置于LLM之中：

其metadata crawler自动摄取企业系统的schema、关系和结构信号，

80-90%的Ontology覆盖度可自动发现，剩余10-20%仅需人工审核合规约束，

成本从"每年$1-2M的FDE投入"降至"接近零"。

三、“本体论"知识工程的技术，其实并非主流

本体论属于符号主义Ai知识工程的体现。七八年前，如果接触过Ai1.0时代的NLP企业，很多企业都会讲本体语言/知识图谱/专家系统这些符号主义Ai，如何与连接主义的NLP神经网络相结合。因为那个时候的NLP技术在实践中尚不成熟——大模型出来之前以LSTM为技术基础的NLP困惑度大约在100以上（GPT-2为20，GPT-3为10），生成质量和语义理解能力有限，还没能到较好的可用性。

对于早期技术不成熟的神经网络，那么辅以知识图谱/专家系统/规则引擎作为技术手段，也是合理的；好处是直截了当、精准、速度快，不需要像神经网络/模型那样，依赖大量标注数据、慢慢训练学习很长时间了，依然出现幻觉、不精准、不可解释。尤其是作为神经网络/模型的下游“执行层”，在特定场景下甚至是不可替代的。

但是当Bert和GPT等大模型出来之后，实现了能力大幅跃迁，NLP的很多传统算法（比如分词、词性标注、情感分析、命名实体识别）都被大模型覆盖/淘汰了，那些知识图谱/专家系统/规则引擎的作用也不大了。

从Ai1.0的NLP到Ai2.0的大模型，知识图谱/专家系统/规则引擎本质都是属于符号主义Ai（符号主义Ai定义为基于逻辑规则、符号推理和显式知识表示实现智能）。而进入2012年后，符号主义Ai在连接主义Ai面前从来都是辅助，从来不是主流（除了古早的上世纪八九十年代）。它们是特定阶段的技术“拐杖”，说是早就被淘汰了也不为过【这点我前面已经讲过】。

专家知识和人为规则意味着它是低维的、刚性的，而非可学习的，更不可能像大模型那样随着参数规模的扩展而识别出很高维度的隐形关联。

我甚至早就将符号主义Ai从Ai里面直接剔除了，不限于语言，其他领域也一样，比如自驾规则、早期医疗诊断、工业控制逻辑、运维根因分析等等。虽然符号主义Ai在高确定性、强合规、精准推理的场景仍有价值，但是它们的表达能力边界明显，其地位正在被可学习的大模型一步步蚕食。我不理解为什么人民币基金还在追崇符号主义Ai时代的技术。

四、bitter lesson：不要投知识工程

Ontology和RAG比较：都是知识工程罢了同样属于前端数据处理的知识工程，RAG不是人为搭建和设计的“本体”系统，而是喂养大模型的知识库向量化流程。由于开源技术（比如OpenSearch的存在），一般企业用RAG倒也没有什么技术层面需要突破的难点，同Ontology/KG一样，反正都是服务于to B知识处理的常规技术手段。

一个简单的RAG流程：用户问题->query embedding->向量检索（FAISS/Milvus）->召回Chunk->Rerank->LLM生成答案。当然RAG也有RAG的问题，它是从检索出发的数据处理手段，经常失灵并导致“检索不准、上下文碎片化、逻辑混乱”。

原因也简单，RAG是被动的信息检索“找资料”，但不理解业务逻辑。另外规模化和延迟、语义理解能力本身也是个两难问题。

从投资角度，我也不看好专门投资RAG的前景，毕竟太常规技术了（依然是智能体Agent架构的核心组件）。之间有RAG与长文本上下文的争论，其实显然可以得出，长文本上下文>>>RAG。而且随着上下文工程、harness工程的火爆，原始的RAG可以说已经被“拍死”了，亦非技术人士关注的重点。在早些年投资向量数据库，作为刚需产品，倒是有价值的。

业界有提出OAG（本体增强生成），因为本体恰好可以补充RAG不足的部分——业务逻辑、数据协同、推理决策。本体模型的实体关联关系，有助于检索更准确的关联信息，结合本体规则，生成决策方案。流程为“本体建模-语义检索-LLM生成-规则校验”。

但是OAG这里的挑战跟前面Ontology体系在大模型LLM面前的挑战是类似的——LLM要能够通过本体模型理解复杂的业务逻辑。本体中的类层次、属性约束、关系推理，也对LLM语义解析能力有很高要求。Ontology Action可以刚性地实现逻辑校验、规则触发，但从理解上下文、到规则行动，又需要大模型和Agent灵活推理能力，这是个“理解生成”和“决策行动”相统一的过程。

Ontology与LLM&Agent的关系

Ontology/KG也好，RAG也罢，都是知识工程方法，都可以与LLM和Agent相结合，都可以理解为在数据层面上为LLM&Agent服务的技术手段，反正都是“外挂”。但这些并非难点，家家企业都有知识库+RAG，也都有自己的“语义层”。

这里不得不提到bitter lessen，我们需要衡量什么技术才是最符合技术演进规律的，要利用计算本身的扩展性（搜索、学习），这才是最重要的，而非人为的知识工程/显式编码。从这个角度，最本真的还是底层Ai大模型和Agent的突破，而非投资知识工程技术。

不投垂直Ai+的知识工程技术

相比通用赛道而言，Ontology/KG和RAG在垂直领域应用更多，都可以服务于具体企业级的业务应用。这里的难点是数据融合和domain知识，比如工业场景：一是采集端的数据融合，有声音图像传感器等多模态数据。二是得有专家经验、推理逻辑，得懂机理模型。

但是这些“前端”工作完成后，算法。部分局部场景由于数据量少、分散，用机器学习、深度学习或小模型就可以解决，从性价比角度也许不需要大模型训练和微调。但当场景数据量提升、场景推理要求提升后，依然得依赖于大模型的能力才能实现一定的泛化，就需要微调和强化学习了。

真正的技术创新要做的不是比较现状，不是衡量目前大模型的能力与专家经验和机理模型的差距，也不是指出目前大模型还无法做到什么（比如多模态），而是如何将数据端和领域知识更早地嫁接于大模型，并在模型的进化中慢慢站稳脚跟。随着RFT、智能体等能力提升，未来垂直模型的整体迭代成本也会下降的。

之前政策上鼓吹垂直应用的“Ai+”，政策上可以理解。从投资上，我不太认同“Ai+”，大模型和Agent时代，还是应当投资通用Ai技术的突破（或通用的Agent设计）。

垂直领域Ai+并不一定需要体现多少Ai技术，数据量少、都不一定支持神经网络训练；反过来讲，大模型每迭代一次也可以“内化”一部分能力，领域适配层也会更成熟（微调、RAG、Agent编排、强化学习），所以也不能将技术一直寄托于扩展性差的小模型和专家经验，被覆盖的风险是很高的。因此，长远看，还是得用发展的眼光投资模型能力，同时用知识工程和传统机理进行补充。

因此，可以理解投资人不轻易投LLM能力覆盖的场景应用，通用比如语言/coding/工作流应用，垂直比如工业运维质检/医疗决策/金融数据挖掘与分析等，而是投资离通用LLM大模型相对比较远（或者说尚不成熟）的技术领域，比如多模态、具身模型之类的。

这与Ai1.0时代的投资逻辑可完全不同，毕竟那时候没有通用的大模型底座，做NLP和隔壁做图像基本上是两拨人，Ai1.0时代的推荐引擎、图像识别、语音识别、智能决策等等，本来就是强垂直的Ai技术。比如做图像识别很容易链接安防这种强垂直的领域。

五、为什么说中国不会有Palantir

说完了老美特殊的客情，和本体论技术特点。进一步说明，为什么说中国不会有Palantir。

在国内，但凡涉及“数据治理”，一定是最差的商业模型！

这些年来我国搞大数据的公司都混得一般。涉及到“数据治理”的都是很差的商业模型，采数据、洗数据的脏活累活都得做。有着投入大、周期长、议价能力差、付费意愿低，这些老生常谈的问题。相比Palantir在军政体系中运行，数据主权、隐私法规和跨部门的数据共享机制，这些都太难得了，与中国企业数据治理的制度环境差异很大。我之前了解到某一数据中台企业的下游场景，数据非常分散、也没有现成的标签体系，每个数据标签都得自己人设计并采集（现在有Agent了，应该能省不少力气），而且好像最后的标签体系也多大实用价值，该企业已经几年没融资消息了。

退一步讲，就算数据治理环境改善，也存在在知识图谱+企业级数据分析领域扎的很深、业务做透的“好”公司，最后也很难有高毛利、高净利。Palantir表面上是高毛利，是因为驻场咨询被计入了费用，而不是成本里面，就如同国内很多SaaS或PaaS公司一样；虽然无论中美这是通用做法，但我依然有质疑，我们一般讲“交付成本”而非“交付费用”。【歪一句，看毛利没用，还是看净利吧；没有净利的话，就关注拓新和留存复购、以及背后付出的成本费用代价（别看ARR和Churn这些短期指标!）】。

如果真有高毛利、高净利，大概率也是因为客情关系、或者恰好踩中了某赚钱细分领域，就像某些国产数据库那种。

也许有这种传统公司最后规模大了，能够走到上市，但是市盈率和市销率肯定不乐观，无法像前沿通用Ai企业那样支撑起千亿市值！

FDE本质还是咨询那一套。很多咨询/外包公司的技术人员也会在客户现场贴身服务，同样也会反馈到产品改进上。无论怎么吹嘘FDE，跟咨询的本质是一样的，无非是咨询水平的高低。这也很容易理解，情报系统本是封闭系统，不贴身服务，根本无法理解客户业务。

我国的大块头企业都在体制内、封闭系统，按理说跟FDE模式很像嘛。但是问题是，我国是销售导向、而非产品导向，真正提供产品和技术服务的乙方角色是最卑微的存在，可能已经被分包好几次了。而且也不会是一个“Palantir”服务啊，而是大大小小集成商。很可能技术和产品没到位呢，利益已经被分的差不多了。我曾经拜访过军工体系的供应商，今年中标的项目两年前就规（nei）划（ding）好了，只需要按“双流水”安排好就行。

另外，之前的央企数科公司不就是这样嘛。权力垄断，利益分配，外包泛滥，阻碍创新。我形容数科公司就是转包扒皮，没有任何其他的实质意义。

国内的Ai数据服务商如果不想成为末端外包咨询角色，如同Palantir，也需要被甲方巨头托举，第四范式就是国内典型，能够获得五大银行投资，就不简单嘛。

（本篇完）

近期AI领域万字长文的梳理涉及了：大模型强化学习媒体和资本对大模型的三次“错误”判断，关于Agent大道至简，OpenClaw打破了之前Agent的框架路径，关于多模态1.8万字，讲透多模态模型的技术进展，关于注意力机制[万字长文]线性or稀疏？阿里和Kimi的Gated DeltaNet线性注意力能掀桌子吗？，本篇属于垂直Ai应用。我会持续梳理AI各相关领域，后面可能会再发的长文：世界模型（结合具身智能），Infra相关，

AI4S，量子科技，等等吧。

文章来自于微信公众号 “蓝喵怂狸花勇”，作者 “蓝喵怂狸花勇”