Project Maven、Palantir Ontology、Gotham与AIP：从数据融合到作战流程的技术链路

Project Maven、Palantir Ontology、Gotham与AIP：从数据融合到作战流程的技术链路

2017年，美国国防部启动Project Maven。项目最初面对的并不是一个抽象的“智能化战争”命题，而是一个已经影响情报处理效率的现实问题：无人机和其他侦察平台持续产生海量视频与图像，人工分析员难以及时完成筛查。

当时成立的“算法战跨职能团队”尝试将计算机视觉引入情报处理流程，让算法先从连续影像中标记车辆、人员和设施等候选目标，再由分析员完成识别与判断。美国国防部公开资料显示，Project Maven早期的重点是处理数以百万小时计的视频数据，近期目标包括识别38类对象。

这段历史经常被简化成一句话：美国军方开始用AI识别目标。

但如果只把Maven理解为一套目标检测算法，就很难解释它此后的演变，也无法理解Palantir在其中承担的作用。

算法能够在图像上标出一辆车，却不能仅凭这个目标框回答：它是否曾在其他时间出现，是否与某个单位有关，附近是否存在相互印证的雷达航迹或情报报告，这一判断由哪个模型产生，分析员是否已经复核，以及后续应当进入哪个工作流程。

从发现一个目标，到形成一条可以被共享、更新和使用的情报，中间还隔着数据治理、实体识别、关系构建、权限控制和任务协同等多个环节。

Project Maven后来的发展，正是从解决“人看不过来”，逐渐转向解决“数据、算法和任务流程连不起来”。

从算法试验走向军事软件系统

Project Maven初期的技术重点是计算机视觉。算法从全动态视频或静态影像中识别候选目标，减少分析员逐帧搜索的工作量。美国国防部后来回顾这一阶段时，也将其主要工作概括为人在回路中的目标检测、分类与跟踪，而不是完全自动化的军事决策。

然而，军事情报的价值往往不来自一次孤立观测，而来自不同时间、不同地点和不同传感器之间的联系。

假设卫星影像显示某机场新增了三架飞机。对于视觉模型而言，输出可能只是三个检测框、三个类别和相应的置信度；对于分析员而言，还需要进一步判断飞机型号、出现时间、历史活动、可能隶属的单位，以及是否有雷达、通信或其他情报来源提供支持。

这意味着，识别模型的输出必须进入一个更大的信息环境。

在传统系统中，卫星影像、无人机视频、雷达航迹、文字报告、部队信息和装备状态往往由不同部门维护。它们可能采用不同坐标系、时间标准、目标编号和访问规则。分析员不得不在多个系统之间切换，再通过表格、邮件和演示文稿手工拼接结论。

美国陆军在公开总结相关实验时提到，过去许多情报产品仍依赖12小时或24小时更新周期、邮件附件和简报板。新的数字化实践则尝试直接在共享平台中维护对象、态势图和分析结果，使分析活动本身成为持续更新的生产过程。但陆军同时承认，对象同步、平台互操作、版本控制和知识管理仍然存在限制。

Maven Smart System由此逐渐成为一套面向任务的数据与软件环境，而不再只是早期的影像识别项目。

2024年，美国陆军向Palantir授予一份总额4.8亿美元的Maven Smart System原型合同。此后，美国国防部又公布一项7.95亿美元的合同修改，用于Maven Smart System软件许可。这类采购表明，Maven正在从局部试验转向更广泛的软件部署与持续使用。

要理解这一变化，需要沿着数据进入系统后的技术链路往下看。

数据进入系统，首先要解决结构差异

在卫星影像、雷达航迹或文字报告被算法使用之前，系统首先要知道这些数据采用什么结构。

这就是Schema所处理的问题。

Schema通常用于规定一类数据有哪些字段、字段使用什么类型、哪些内容必须填写，以及字段之间需要满足哪些基本约束。

一条雷达航迹记录可能包含：

航迹编号 目标类别 经度 纬度 高度 速度 航向 探测时间 传感器编号 置信度

看起来并不复杂，但不同系统可能把同一个概念写成不同名称。一个系统使用track_id，另一个使用target_number；一个系统采用UTC时间，另一个记录当地时间；坐标可能分别采用经纬度、军事网格或局部坐标；目标类别也可能由自然语言、数字代码或内部缩写表示。

Schema让数据能够被计算机稳定读取，也为接口交换和后续处理建立基础。

但Schema解决的主要是“数据长什么样”，而不是“数据在现实世界中代表什么”。

两个系统中编号相同的目标未必是同一对象；两个距离接近的坐标也未必属于同一装备；文字报告中的“机场北侧两架运输机”，不能只靠字段名称与卫星图像上的两个检测框自动对应。

因此，从原始Schema走向可用于任务的信息，还需要经过数据清洗、单位换算、时间与坐标归一化、来源标记、质量检查、实体解析、时空匹配和置信度评估。

这些工作可能由确定性规则完成，也可能需要统计模型、机器学习方法和人工确认共同参与。

Ontology把数据组织成现实对象

经过处理的数据进入Palantir体系后，不再只是某张数据库表中的记录，而是被映射为飞机、机场、人员、部队、传感器、任务和事件等现实对象。

这就是Palantir Ontology承担的核心工作。

Palantir将Ontology描述为数据集、虚拟表和模型之上的运营层。它既包含对象、属性和链接等语义元素，也包含动作、函数和动态安全控制等运营元素。Palantir还常用“组织的数字孪生”来描述这种结构。

以一架飞机为例，在Ontology中，它可以被表示为一个持续存在的对象，而不是每次观测都生成一条互不关联的新记录。

这个对象可以包含：

• 型号、位置、速度和状态；

• 最近一次观测时间；

• 数据来源与判断置信度；

• 所属单位和所在机场；

• 相关任务与历史活动；

• 被哪些卫星、雷达或其他传感器观测过。

飞机对象还可以与机场、部队、任务、报告和传感器建立关系：

飞机A停放于机场B 飞机A隶属于航空单位C 雷达D观测到飞机A 情报报告E提及飞机A 飞机A参与任务F

不同来源的数据由此不再只是平行摆放，而是围绕同一个对象及其关系进行组织。

这一步的意义在于，分析员研究的不再是一组分散文件，而是一个不断接收新证据、更新状态和扩展关系的对象网络。

但需要说明的是，Ontology并不会自动解决所有实体匹配问题。系统要判断两条记录是否代表同一架飞机，仍然需要唯一标识、时空关联、特征比对、算法模型或人工复核。Ontology提供的是统一承载和维护对象的机制，而不是替代前面的数据处理和实体解析过程。

从描述对象到改变对象

Palantir Ontology与普通数据目录或静态知识图谱的区别，还在于它不仅描述对象，也允许围绕对象定义操作。

例如，分析员发现新的证据后，可以：

• 修改目标状态；

• 补充来源；

• 建立或解除对象关系；

• 发起复核；

• 将目标移交给其他岗位；

• 创建后续调查任务。

Palantir的Action机制可以按照预先设定的规则修改对象、属性和链接；Functions则可以读取对象数据、遍历关系、执行计算并承载较复杂的业务逻辑。所有操作还可以受到对象级、类型级和动作级权限约束。

一个疑似飞机目标可能经历以下过程：

算法发现 → 建立候选对象 → 分析员复核 → 与历史航迹建立关联 → 补充型号判断 → 状态更新 → 进入后续任务流程

这条过程中的修改可以保留时间、来源、执行人和权限记录。

Ontology因此不只是给数据增加语义标签，也是在维护一个能够被人员、应用和算法共同操作的任务环境。

Palantir目前将Ontology概括为整合数据、逻辑、动作和安全的系统，用于为人员和智能体提供统一的决策上下文。

“动态”体现在持续变化，而不是自主改写规则

战场上的对象状态不断变化。

飞机位置会移动，装备状态会从可用变为维修，部队可能调整隶属关系，任务会从计划阶段进入执行阶段，分析员也会根据新证据更新目标置信度。

对象之间的关系同样会变化。

一条新航迹可能与已有目标完成关联；某支部队可能被重新分配任务；一个保障节点可能开始支援新的行动单位。

随着业务需求变化，Ontology模型本身也需要调整。开发人员可能增加新的对象类型、属性、关系、动作和权限规则，或者对既有定义进行版本化修改。

因此，所谓动态性可以理解为三个相互联系的层面：

• 现实对象状态持续更新；

• 对象之间的关系持续调整；

• 用于描述和操作这些对象的业务模型持续演进。

这并不意味着Ontology能够脱离治理程序自行创造军事概念或改变作战规则。模型演进仍然需要设计、测试、权限审批和版本管理。

其价值在于，当任务类型和业务需求发生变化时，系统可以在已有对象体系上进行调整，而不是每增加一种任务就重新建设一套彼此隔离的软件。

Gotham是国防与情报工作的使用环境

Ontology负责组织对象、关系、逻辑和动作，但分析员日常面对的是具体应用和工作界面。

在Palantir产品体系中，Gotham长期面向国防、情报、执法和公共安全场景。它将多源数据、对象查询、地图、时间线、关系分析、协作记录和任务流程呈现在用户面前。

分析员可以在地图中查看目标位置和活动区域，在时间线上观察状态变化，在关系图中研究人员、组织、装备和事件之间的联系，也可以在对象页面中查看数据来源、判断记录和相关任务。

Palantir公开的Gotham接口文档显示，Gotham的RevDB是一种由动态Ontology支撑的对象数据库。同时，Defense Ontology SDK允许第三方应用访问一致的语义数据层，而不必局限于Gotham原有界面。

因此，Ontology与Gotham并不是简单的“底层数据库”和“上层显示页面”关系。

Ontology维持对象及其逻辑，Gotham则把这些对象带入实际的情报分析和任务协作环境。地图、对象页面、关系分析工具和任务工作台，都是对同一个业务对象体系的不同使用方式。

美国陆军公开材料中提到的Gaia、Dossier和Target Workbench，分别涉及态势显示、任务计划和报告编制，以及目标生命周期协作。它们反映的并不是一个孤立软件，而是一组围绕对象和任务组织的应用能力。

Gotham的历史早于今天完整产品化的Ontology架构。早期Gotham本身已经采用对象与关系组织情报数据，随后Palantir逐步将相关能力抽象、扩展并形成目前公开的Ontology、接口和开发工具链。

因此，更准确的理解是，Gotham与Ontology是在产品演进中逐渐形成的相互支撑关系，而不是先完成一个独立Ontology产品，再在其上简单搭建Gotham。

Maven围绕联合任务组织数据与软件

Maven Smart System与Gotham存在共同的平台基础，但两者并非同一个概念。

Gotham是一套面向国防和情报工作的通用平台；Maven Smart System则围绕美国国防部的联合军事任务进行建设和部署。

早期Project Maven侧重影像和视频目标检测。发展到Maven Smart System阶段后，系统需要将不同传感器、AI模型、态势信息和任务流程组织起来，使多个单位能够在共同环境中处理目标、情报和行动信息。

一条典型的信息链可能是：

传感器产生观测 → 算法发现候选目标 → 数据完成清洗与实体解析 → 候选目标被映射为对象 → 与历史记录和其他来源关联 → 分析员复核与补充判断 → 更新共同态势或目标工作流 → 任务结果回写对象状态

在这条链路中，目标检测只是第一个环节。

Maven的核心意义，在于把传感器、算法结果、对象关系、人员协作和任务过程放到一个能够持续运行的软件环境中。

美国陆军公开材料显示，Maven Smart System可以与其他情报数据平台共同维护情报图和作战图，但真实运行中仍然会出现对象传递不完整、数据同步延迟和平台间目标信息交换不顺畅等问题。

这些公开记录说明，Maven并不是一个能够把所有数据“自动融合”的封闭系统。它仍然需要解决接口标准、数据质量、访问权限、对象一致性和人员操作规范等工程问题。

公开资料没有披露Maven Smart System的完整内部架构，因此不宜将其简单描述为Gotham的一个模块，也不能认为它与Gotham无关。

比较稳妥的理解是：Maven是面向特定国防任务建设的软件系统，使用了Palantir在数据融合、Ontology、地理空间分析、协作、权限和任务工作流方面的共同技术能力。

AIP让生成式AI进入既有任务环境

Project Maven早期的AI，主要是目标检测、分类和跟踪模型。大语言模型和智能体技术发展后，Palantir又推出AIP，即Artificial Intelligence Platform。

AIP的目标不是简单增加一个聊天窗口，而是把生成式AI连接到已有数据、Ontology、函数、动作和业务流程中。

Palantir将AIP定义为把生成式AI连接到实际运营领域的平台。其架构包括模型服务、Ontology、工具调用、计算服务、开发工具、监控与评估等组成部分。

例如，分析员可以提出：

最近72小时，哪些机场的航空活动出现明显变化？

大模型不应仅凭自身训练知识直接作答，而是需要通过系统提供的工具完成任务：

1. 识别问题涉及机场、飞机观测和时间范围；

2. 查询Ontology中的相关对象；

3. 调取历史活动和最新观测；

4. 调用统计或变化检测函数；

5. 返回结果、证据来源和不确定性；

6. 由人员决定是否进入下一步处理。

AIP Logic可以从Ontology对象中读取数据，并按照平台权限调用函数或形成建议。Palantir文档强调，AIP Logic沿用平台已有的用户权限和函数权限模型。

当AI被允许修改业务对象时，系统还可以规定修改是直接应用，还是先生成草稿并交由人员复核。

这意味着，大模型的作用不再局限于生成文字，而是可能参与对象查询、工具调用、报告编制、任务建议和流程协作。

但它的活动范围由Ontology、权限、工具和审计机制共同限定。

AIP因此并不简单位于Gotham或Maven之上。它更接近一组横向能力，可以嵌入数据处理、情报分析、对象管理、任务规划和应用开发等环节。

Foundry与Apollo补充了另一部分技术基础

如果只讨论Gotham、Maven和AIP，还不能完整说明Palantir的软件体系。

Palantir目前将Gotham、Foundry、Apollo和AIP列为四个主要软件平台。Foundry主要面向数据集成、分析和运营应用，Gotham主要服务政府、国防和情报用户，AIP负责把生成式AI连接到运营环境，Apollo则用于在云端、本地、机密网络和边缘环境中部署、更新和管理软件。

Ontology贯穿这些平台的数据、逻辑和应用层。

在国防场景中，Palantir软件还必须与既有传感器、情报数据库、通信网络、指挥系统和第三方算法共同运行。Palantir提供的是关键的软件集成与任务环境，而不是替代整个军事信息体系。

可以将其主要技术关系概括为：

卫星、无人机、雷达、数据库、情报报告 ↓ 数据接入、清洗、标准化与质量控制 ↓ Schema映射、坐标和时间归一化 ↓ 实体解析、时空关联与模型推理 ↓ Palantir Ontology 对象—属性—关系—函数—动作—权限 ↓ Gotham及其他国防任务应用 ↓ Maven Smart System 联合态势、目标处理与任务协作 AIP横向接入上述环节： 大模型—智能体—工具调用—评估—审计 Apollo负责不同环境中的部署与更新

这是一张功能关系图，而不是Palantir或美国军方公开发布的物理部署架构。

Palantir改变的是算法进入任务流程的方式

图像识别、语言模型、轨迹预测和优化算法会不断更新，也可能来自不同厂商。

Palantir试图建立的，是一套相对稳定的任务结构，使新的算法能够进入已有的对象、权限和工作流程中。

目标检测模型接入后，结果不再只是存放在单独文件中的标签，而是可以形成带有来源和置信度的候选对象。

新的情报报告进入后，不只是成为一份可检索文档，而是能够与地点、人员、单位、装备和事件建立联系。

分析员更新判断后，不只是修改个人简报，而是改变共享对象的状态，并保留修改记录。

AI智能体提出建议时，也需要通过受控函数和动作进入业务流程，而不是绕开权限直接操作系统。

系统运行的基本单位，由文件和报表逐渐转向对象、关系、状态和动作。

这种方式能够改善多人协作和信息复用，也为AI提供相对稳定的上下文。但它同时提高了对数据治理和操作纪律的要求。多个单位同时修改对象时，来源管理、版本控制、权限边界和质量检查会直接影响共同态势的可靠性。

美国陆军的公开实验已经反映出这些问题：技术平台可以提高情报更新和共享速度，但人员培训、知识管理、对象质量和跨平台互操作仍然决定系统能否稳定运行。

从2017年的Project Maven到后来的Maven Smart System，再到AIP，技术发展的主线并不是让算法完全替代分析员，而是逐步扩大算法在任务体系中的参与范围。

最初，机器帮助人发现目标。

随后，系统开始把目标与历史记录、地理空间、组织关系和任务状态连接起来。

进入AIP阶段后，大模型和智能体又可以通过自然语言理解任务，查询对象、调用工具并参与工作流。

Schema保证不同数据能够被读取和交换；Ontology将数据组织为持续变化的现实对象；Gotham为国防和情报人员提供分析与协作环境；Maven Smart System围绕联合任务连接传感器、算法、态势和工作流程；AIP则让生成式AI在对象、权限和工具约束下参与其中。

这套技术路线的重点，不是构造一个独立于人员和组织运行的“超级大脑”，而是建立一个由数据、算法、软件和人员共同维护的数字化任务环境。

算法负责识别、预测和生成，Ontology维持对象与业务上下文，Gotham和Maven承载分析与任务流程，AIP扩大AI参与方式，而判断、授权和行动仍然受到权限、规则和组织程序的约束。