最近Palantir突然又火了，刷到了好多分析它的文章。很多文章写的很专业，我没有那么专业，理论水平也还十分有限，仅仅是谈一谈自己的理解。
早期知识图谱以语义网（Semantic Web） 、链接数据（Linked Data）技术等为代表，当代知识图谱则以Google Knowledge Graph （融合了更早的产品FreeBase 项目）、Wikidata 等项目为代表。传统的语义网主要关注本体层，强调树形层级体系（Hierarchy ）和知识推理，形成了以RDF、RDFS、OWL的语义网技术体系，代表产品就是斯坦福Protégé 。语义网的知识表达非常直观，推理计算能力强，但存在难以规模化、依赖领域专家构建的问题。Linked Data是数据层面的语义信息，可以理解为更加通用的网页超链接，可以方便数据资源的相互关联，但是语义层次比较低，未在业务应用领域发挥作用。Knowledge Graph核心是通过更先进的NLP技术（基于机器学习）实现非结构化数据的知识抽取，使得能够从网页等文档获取大量具体的知识，促进了实体抽取、关系抽取、事件抽取等技术的大量研究和应用。Wikidata项目，作为目前规模最大的开源知识图谱项目，将概念和实例统称为object，属性和关系统一为property，object与property都是item，虽然对对象属性有明确定义，但总体上更加关注实例层。
与传统知识图谱或学术研究中的本体不一样的是，Ontology是更加全面的知识图谱平台。
首先，Ontology同时包含本体层和实例层。对比传统知识图谱，Ontology明确包括本体层和实例层，本体层通过领域专家构建（这一点显然是从语义网发展而来），实例层则通过Pipeline Builder、NLP、大模型等技术进行自动化构建。Ontology对业务领域中的各类对象进行统一建模，AIP利用大模型能力实现业务数据与Ontology的对齐，成为现实世界的数字孪生。
第二，Ontology具有更全面的元知识类型 。不仅包括对象 、事件 、属性 、数据类型 等静态知识，还包括**函数（Function）和 行动（Action）**动态知识。传统知识图谱是相对静态的，它的新增、修改、删除、扩展等是由另一套程序负责，比如信息抽取算法或者人工管理操作。Ontology将业务逻辑与数据管理逻辑无缝关联起来，在业务状态发生变化时，自动驱动相关Create Update Delete改变系统内的知识状态，从而与真实世界同步；同时又通过系统知识状态的改变，驱动下游业务的真实动作，例如安排物流运输，或者执行无人机侦察任务。行动是对对象、事件等实体状态进行改变的操作，包括修改对象及其属性的新增、修改、删除等操作。函数是一种可以自定义输入与输出的数据转换逻辑，可以用于定义数据转换、数据修改逻辑，同时其输入输出参数不是任意数据，而是与Ontology中定义的对象/事件/数据类型关联。
第三，Ontology支持更丰富的数据类型 。在本体中，数据类型也是一种元知识。不管是对象、事件、属性，还是函数、逻辑、行动，都需要更底层的数据结构进行描述，以便计算机能够存储和计算。除了最基本的布尔、数值（整数，小数）、文本、日期，较为复杂的元组/列表、集合、字典/哈希表、JSON等，还支持对象 、时序 、空间对象GEO 、向量等数据类型。其中GEO支持点、线、面等类型。时序则是包含时间和具体数值的序列，例如车辆位置，人的工作经历。向量虽然本质上是由小数构成的列表，但对于建立向量索引、支持语义检索非常重要，单独处理更加方便。此外，支持自定义数据类型，根据业务需要直接定义，无需定制开发。这种能力好比编程语言，开发人员基于语法规则可以设计非常复杂的数据结构，Ontology让项目实施人员或用户具备相当的能力。
第四，Ontology提供混合异构的数据存储 。简单知识图谱系统采用一款图数据库 （如Neo4j ）即可。而Ontology的数据模型更加复杂且数据类型多样化，单一数据库选型显然是不够的。Ontology以基于某种图数据库存储的知识图谱为核心，还包括时序数据库 （OpenTSDB？）、空间数据库 （PostGIS？）、向量数据库 （FaiSS或Chroma？）、对象数据库 （HDFS，存储文档文件、图片等）、全文索引 （Lucene或ElasticSearch？）等。如此复杂的存储系统势必要求进行良好的分层结构设计，逐层封装抽象，保证底层具体存储选型与接口访问对于上层应用透明无感，也能支持根据特定需求进行针对性选择。此外，需要充分考虑业务需求，提供常见的API，这些API将不仅被上层代码调用，也用于大模型进行复杂任务推理与规划。Ontology核心存储引擎（图数据库或对象数据库）主要存储知识图谱主体结构，对于时序数据、空间数据、向量数据、文档内容数据等，单独存储，图谱中只需要保存对应数据的引用（如URI 或UUID）。
第五，Ontology知识管理更加完整灵活 。在更加丰富完备的数据类型和知识类型基础上，通过增加相关元信息 ，更加便于数据存储、查询以及跨系统交互。例如，可以将事故分析报告建模为一种"文档"类型对象，为了支持语义检索，为该对象增加semanticVector的属性，该属性的数据类型是向量。为了实现向量索引和检索，还需要向量维度、相似度检索方法、索引结构、向量化模型等。为了支持这样完整地定义，对"向量"这一数据类型本身本身也是作为一种知识进行管理和定义。因此，Ontology支持完整自洽的知识和元知识管理，最终将复杂的上层的对人直观友好表示的知识，转换为底层逻辑严谨的可存储可计算的数据结构。大多数软件系统设计很难做到这一点，有的知识表示过于低层次，对用户来说不直观且工作量大，有的则针对特定业务逻辑进行设计而不能够灵活扩展。Ontology这套强大的知识管理体系，使得项目实施人员能够真正做到FDE（Forward Deploy Engineering），避免定制开发成本，而这一设计理念和能力不只是体现在Ontology种，还包括Data集成、模型集成、流程构建等，几乎包括了信息化、数字化、智能化的所有必要基础软件基础。
作为AIP的核心，Ontology不仅为各类业务知识提供直观表示与、高效存储&查询、推理，也是一种更加彻底的面向对象思维方式，更重要的是，作为一套完善的工具体系，覆盖了业务场景中建模、处理、分析、展示、决策等诸多需求，极大减少了定制开发工作量。软件研发团队既可以围绕一套技术体系进行持续完善，还可以快速定制出大量更加业务化的产品，从而降低项目实施成本、提高项目复用性。当然，整个系统架构的庞大复杂也必然带来管理、维护、升级等过程的复杂性，工程师们必需具备非常高的业务抽象能力和架构设计能力。否则，Palantir出来了很多年，宣传了很多年，也被同行学习研究了很多年，早就应该被模仿、被超越了。事实是，一直被模仿，却从未被超越。这背后的原因到底是什么？