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小时哪些机场的航空活动出现明显变化大模型不应仅凭自身训练知识直接作答而是需要通过系统提供的工具完成任务识别问题涉及机场、飞机观测和时间范围查询Ontology中的相关对象调取历史活动和最新观测调用统计或变化检测函数返回结果、证据来源和不确定性由人员决定是否进入下一步处理。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参与方式而判断、授权和行动仍然受到权限、规则和组织程序的约束。