首页 Ontology 应用场景深度推演

应用场景深度推演

不做概念翻译,做因果推敲——每一个场景拆成五步,数据如何变成对象,对象如何触发推理,推理如何驱动行动

先建立共识:Ontology 如何驱动一次完整决策

在 Palantir 的架构中,任何业务场景都可以还原成下面五步。不涉及黑箱,每一步都有确定的输入、确定的输出、确定的状态变化。理解了这五步,再看场景就不会觉得"好像有道理但说不清怎么做到的"。

1

数据进入

IoT传感器、ERP记录、卫星图像、API——任意数据源通过 Pipeline 流式接入。Palantir 不做数据搬迁,通过 Pipeline Builder 建立与源系统的持续连接。

2

本体映射

Pipeline 的输出被映射到 Ontology 中的对象(Object)。例如温度读数 → DistributionCenter["DC-3"].temperature = 180°F。对象=实体,属性=该实体的实时快照。

3

数字孪生状态

一个属性变了,所有关联对象同步更新。DC-3 状态变了 → 它的下游 PurchaseOrder 对象全部自动标记"at_risk"。这个连锁反应是预定义的——Link 定义了什么影响什么。

4

AI 推理

AIP 收到状态变更事件后,拉取受影响对象的完整上下文(Ontology 子图),交给 LLM 推理。LLM 看到的是结构化知识图谱,不是零散文本片段。

5

写回行动

AI 的推理结果通过 Ontology Action 写回源系统(ERP/CRM/MES)。Action 的执行结果又被 Ontology 记录,成为下次推理的历史参照。

📦

场景一:配送中心火灾 — 供应链应急推演

供应链医疗AIP

下列推演基于 Palantir AIP 官方 Demo 场景。场景假设:泰坦工业的医疗用品配送中心 DC-3 突发火灾,需要立即识别受影响客户、评估替代供应方案、自动触发应急采购。传统流程需要数天,Ontology 驱动的数字孪生将其压缩到分钟级。

STEP 1 数据进入:IoT 传感器触发异常事件

配送中心 DC-3 安装了温度传感器和烟雾探测器。2026-05-27 14:32:05,传感器报告:

// 原始传感器数据,经由 Foundry Pipeline 接入
Event {
  source:       "sensor:DC-3:temp-zone-b"
  timestamp:    "2026-05-27T14:32:05Z"
  temperature:  182.3  // °F,正常范围 60-85°F
  smoke_density: 0.87  // 0-1 归一化值,阈值 >0.7 触发报警
  event_type:   "FIRE_DETECTED"
}

Pipeline 检测到事件类型 FIRE_DETECTED,自动触发 Ontology 属性更新链路。

STEP 2 本体映射:属性变更 → 关联对象级联标记

Ontology 中 DC-3 的 DistributionCenter 对象收到属性更新。同时,Link 定义的传播规则自动执行:

// Ontology 对象属性变更前后的快照对比
// DistributionCenter 对象
DistributionCenter["DC-3"] {
  status:      "operational""FIRE_ACTIVE"
  temperature: 78.2 → 182.3
  affected_at: null → "2026-05-27T14:32:05Z"
  LINKS:stocks: Inventory[12 items, see below]
}

// 经由 Link 自动级联: DC-3 —[hosts]→ Inventory —[fulfills]→ PurchaseOrder —[belongs_to]→ Customer
// 受影响链路:
DC-3
 → Inventory["IVT-0042"]   // 外科口罩,5000单位
 → Inventory["IVT-0087"]   // 无菌手套,12000单位
 → Inventory["IVT-0103"]   // 输液泵耗材,800单位
   → PurchaseOrder["PO-8451"]  // status: "pending_shipment" → "at_risk"
   → PurchaseOrder["PO-8492"]  // status: "in_transit_planning" → "at_risk"
   → PurchaseOrder["PO-8517"]  // status: "pending_shipment" → "at_risk"
     → Customer["City General Hospital"]  // tier: "critical_care"
     → Customer["Regional Clinic Network"] // tier: "standard"
     → Customer["Metro Surgery Center"]    // tier: "critical_care"

关键机制:一次属性变更(DC-3 status → FIRE_ACTIVE),通过预定义的 Link 关系自动传播到三级间接关联的对象。不需要手动查询"哪些订单受影响"——数字孪生已经算好了。

STEP 3 数字孪生状态快照:实时全貌一览

这一步不需要 AI。Ontology 已经给出了当前时刻的精确状态——这就是"数字孪生"的价值:不是事后查数据,而是时刻持有真相。

// 数字孪生当前时刻的态势快照(自动聚合,非人工查询)
{
  affected_distribution_centers:  ["DC-3"]
  affected_inventory_items:       3
  at_risk_purchase_orders:        23  // 不止上面3条,包括未来48h排期的PO
  affected_customers:             18
  critical_care_customers_hit:    5
  total_pending_delivery_value:   $2,470,000
  estimated_delay_hours:          48 – 120  // 基于 DC-3 恢复时间预估
}
STEP 4 AI 推理:AIP 基于 Ontology 子图进行结构化推理

AIP 不是把"23 个订单受影响"这句话扔给 LLM 让它猜。它从 Ontology 拉取受影响对象的完整知识图谱子图,LLM 拿到的是结构化的对象和关系,不是离散文本。

Q1: 哪些客户必须优先保障?

遍历 18 个 Customer 对象的 tier 属性。5 个标记为 "critical_care"。City General Hospital 和 Metro Surgery Center 的关联 PO 包含输液泵耗材——不可替代,必须优先处理。

Q2: 替代 Inventory 是否存在?

查询所有 Supplier 对象,筛选与 at_risk Inventory 中相同 SKU、且 linked DistributionCenter 状态为 "operational" 的库存。找到 Supplier-B 和 Supplier-D 有充足替代库存。

Q3: 替代运输时间是否可接受?

Supplier-B → City General Hospital:公路运输 4h。Supplier-D → Metro Surgery Center:空运 2h + 公路 1h = 3h。均在 SLA 允许范围内。

Q4: 成本增量多少?

替代采购总成本增加 $42,000(Supplier-B 单价高 8% + 紧急运费)。对比断供的合规风险(可能触发合同违约金 $150,000+),成本可控。

STEP 5 写回行动:触发 Ontology Action → 写入 ERP → 闭环

AI 将推理结果转换成 Action 调用。AIP 中的 Agent 不直接操作 ERP——它通过 Ontology 定义的 Action Type 来执行,Action 内部封装了对源系统的写回逻辑:

// AI 生成的 Action 执行计划
ActionBatch {
  actions: [
    {
      type:    "CreateEmergencyPurchaseOrder"
      target:  Supplier["Supplier-B"]
      params:  { sku: "IVT-0042", qty: 5000, priority: "critical", ship_to: "City General Hospital" }
      approval: "required"  // 金额超过阈值,需要人工确认
    },
    {
      type:    "CreateEmergencyPurchaseOrder"
      target:  Supplier["Supplier-D"]
      params:  { sku: "IVT-0103", qty: 800, priority: "critical", ship_mode: "air", ship_to: "Metro Surgery Center" }
      approval: "required"
    },
    {
      type:    "NotifyCustomer"
      target:  Customer["Regional Clinic Network"]
      params:  { message: "Your order may be delayed 48-72h. Rerouting in progress.", severity: "info" }
      approval: "auto"  // 纯通知,无需人工确认
    },
    {
      type:    "UpdateDigitalTwin"
      params:  { dc: "DC-3", recovery_eta: "72h", reassess_interval: "30min" }
      approval: "auto"  // 设置监控循环:每 30 分钟重评估一次恢复进度
    }
  ]
}

闭环:采购主管在 AIP 界面中一键批准前两个 Action → Action 通过 Ontology API 写回 ERP 系统创建新采购单 → 新 PO 对象自动关联到 Ontology 中对应的 Supplier 和 Customer → 数字孪生更新风险状态。30 分钟后,定时 Action "ReassessRisk" 重新评估所有风险 PO 的交付进度。

这条链路的核心要点

  • 没有一次查询是"现查"的。当 DC-3 的 status 变成 FIRE_ACTIVE 那一刻,所有受影响的对象已经被 Link 自动标记。AI 推理时不需要"搜索哪些订单受影响",它只需要读当前 Ontology 状态即可。
  • AI 不猜,它基于结构化事实推理。LLM 收到的不是"请分析火灾影响",而是 23 个 PurchaseOrder 对象 + 18 个 Customer 对象 + 它们的属性和关系图。结论是推导出来的,不是拍脑袋的。
  • 写回是确定的,不是建议。Action 有明确的类型定义、参数校验、审批策略。执行结果写回 Ontology 成为新一轮推理的历史数据。
✈️

场景二:波音制造 — 质量缺陷的全链路追溯

制造航空Foundry

波音防务(BDS)有 10+ 条军用生产线(F-15、F/A-18、KC-46、卫星等),2025 年 9 月与 Palantir 合作部署 Foundry。以下推演基于典型的航空制造场景:一个关键零部件批次被发现质量缺陷。

STEP 1数据进入:QC 检测发现超差
// MES 质量检测系统推送检测结果
QualityInspection {
  component_id:   "COMP-HYD-PUMP-A73"  // 液压泵组件
  batch_number:   "BATCH-2026-05-19"
  supplier:       "AeroComponents Inc."
  test_type:      "pressure_tolerance"
  measured_value:  2850  // PSI,规格要求 3000±50 PSI → 不合格
  result:         "FAIL"
  inspector:      "QC-A73-Operator"
  timestamp:      "2026-05-27T09:15:00Z"
}

Pipeline 将检测结果流入 Foundry,触发 Ontology 中对应 Component 对象的属性更新。

STEP 2本体映射:单个零件故障 → 波及范围自动展开
// 该 Component 对象在 Ontology 中的关系网络
Component["COMP-HYD-PUMP-A73"] {
  quality_status: "pending" → "FAILED"
  batch: "BATCH-2026-05-19"
  LINKS:supplier:     Supplier["AeroComponents Inc."]
    → installed_in: Aircraft["F-15EX #1042"]  // 已装机
                   Aircraft["F-15EX #1045"]  // 已装机consumed_by:  WorkOrder["WO-28741"]  // F-15EX #1042 装配工单
                   WorkOrder["WO-28756"]  // F-15EX #1045 装配工单

// Batch 关联的所有 Component(同批次,全部标记为 suspect)
Batch["BATCH-2026-05-19"] →  47 components, 其中 12 个已装机, 8 个在途, 27 个库存

关键洞察:一个零件的质量缺陷,不是孤立事件。Ontology 的同批次 Link 自动将 47 个同批组件全部标记为 "suspect",再通过 installed_in Link 定位到具体飞机,通过 consumed_by Link 定位到具体工单。没有 Ontology,这个追溯需要人工跨 MES、PLM、ERP 三个系统手动对账。

STEP 3数字孪生:从零件到飞机的投影

数字孪生现在可以回答一个传统 BI 回答不了的问题:"如果这 12 个已装机的 suspect 零件全部需要更换,对哪几架飞机的交付时间线影响最大?"

// 数字孪生自动计算的受影响范围
{
  suspect_components:                 47
  installed_in_aircraft_count:        2   // F-15EX #1042, #1045
  same_supplier_pending_deliveries:   3   // 另有 3 架飞机正在等该供应商的零件
  alternative_supplier_options:       2   // Supplier-J 和 Supplier-K 有同规格零件
  estimated_rework_hours_per_aircraft: 120 // 更换液压泵需要拆装周边子系统
  affected_delivery_milestones:       3   // USAF 合同中有罚金条款的交付节点
}
STEP 4AI 推理:四维决策空间

Q1: 立即停飞还是等替代零件到货再停?

AI 评估:#1042 已进入总装最后阶段(进度 87%),#1045 在前期装配(进度 32%)。建议 #1042 继续总装(液压泵在后期测试阶段才需要)、#1045 暂停相关工位。(依据:WorkOrder.progress + AssemblyStage 属性)

Q2: 换用替代供应商的代价?

Supplier-J 有现货但需重新认证(+14 天)、Supplier-K 已通过认证但单价高 12%。综合考虑交付节点,推荐 Supplier-K。(依据:Supplier.certification_status, Supplier.unit_price, DeliveryMilestone.deadline)

Q3: 通知客户的最佳时机?

当前延迟预估 14-21 天。USAF 合同规定延迟 >10 天必须通知。AI 建议立即通知并附带修改后的交付时间线,同时准备替代补偿方案。(依据:Customer.contract_terms, DeliveryMilestone.penalty_clause)

Q4: 这个供应商要不要降级?

该供应商过去 12 个月的质量事件:1 次 minor(4 个月前)+ 本次 major。尚未达到降级阈值(3 次 major)。AI 建议记录但不降级,下次采购时提高检验比例。(依据:Supplier.quality_history + Action "AdjustInspectionLevel")

STEP 5写回行动:一条决策链路,多次系统写入

这次不只是一次 Action,而是一组有序执行的 Action 链。其中某些步骤需要人工决策节点:

// 多步骤 Action 链(有顺序依赖)
Chain "QualityDefectResponse" {
  step 1: Action["HoldWorkOrders"] {
    params: { wo_ids: ["WO-28756"], reason: "suspect_component_batch" }
    target_system: "MES", approval: "auto"  // 自动化停线
  }
  step 2: Action["InitiateReinspection"] {
    params: { batch: "BATCH-2026-05-19", scope: "installed + in_transit" }
    target_system: "QC_System", approval: "auto"
  }
  step 3: Action["CreateEmergencyPO"] {
    params: { supplier: "Supplier-K", component: "COMP-HYD-PUMP", qty: 12 }
    target_system: "ERP", approval: "required"  // 触发采购主管审批
  }
  step 4: Action["NotifyCustomer"] {
    params: { customer: "USAF", aircraft: ["F-15EX #1045"], revised_eta: "2026-06-14" }
    approval: "required"  // 客户通知需要项目经理审批
  }
  step 5: Action["LogQualityEvent"] {
    params: { supplier: "AeroComponents Inc.", severity: "major", recommendation: "increase_inspection" }
    target_system: "Ontology", approval: "auto"  // 写入 Ontology 成为供应商历史记录
  }
}

闭环:完成上述 Action 链后,Ontology 中受影响 Aircraft 的 delivery_status 更新为 "AT_RISK_REVISED",新的交付时间线自动反映在所有相关 Dashboard 和下游系统中。30 天后,AIP 会主动推送提醒:"F-15EX #1045 新 ETA 是否仍然 on track?"

这条链路的核心要点

  • Batch 维度的威力。一个零件出问题,同批次 47 个全标记。这个关联在 ERP 里不存在——BOM 里只知道用了哪个零件,不知道哪个批次。Ontology 的 Batch Link 填补了这个断层。
  • 供应商质量是持续学习的。Action "LogQualityEvent" 将本次事件写入供应商历史,下次采购决策时 AI 会自动参考这个记录。供应商质量不是一次性判断,而是持续更新的动态评估。
  • 人工节点在关键位置。采购和客户通知两步设置了 required 审批,确保高成本/高风险操作必须人工确认。其余步骤自动执行。
🎯

场景三:Gotham — 战场多源情报融合

军事情报Gotham

以下场景为 Palantir Gotham 平台在军事领域的典型应用模式的抽象还原。核心挑战:卫星图像、SIGINT(信号情报)、HUMINT(人力情报)三种来源的数据格式完全不同,但指向同一件事。

STEP 1数据进入:三路异构情报同时到达
// 时间窗口: 2026-05-27 06:00-06:30 UTC
// 来源 A: 卫星图像 (GEOINT)
SatelliteImage[ID: "SAT-IMG-9471"] {
  coordinates:   (34.5231, 69.1832)  // 喀布尔近郊
  timestamp:     "06:12 UTC"
  detected_objects: [
    { type: "vehicle", count: 8, classification: "light_tactical", confidence: 0.91 },
    { type: "vehicle", count: 2, classification: "heavy_transport", confidence: 0.87 },
    { type: "structure", subtype: "temporary_assembly_point", confidence: 0.78 }
  ]
  analyst_notes: "Vehicles in convoy formation, unusual for this area at this time"
}

// 来源 B: 信号情报 (SIGINT)
SIGINTIntercept[ID: "SIG-22841"] {
  coordinates:   (34.5238, 69.1840)  // 与卫星图像相差 ~200m
  timestamp:     "06:18 UTC"
  signal_type:   "encrypted_tactical_radio"
  frequency:     "VHF band"
  traffic_pattern: "burst_transmission"  // 短促突发传输,典型战前通信模式
  transcript:    "unable_to_decrypt"
}

// 来源 C: 人力情报 (HUMINT)
HUMINTReport[ID: "HUM-11892"] {
  region:        "Kabul East District"
  timestamp:     "06:25 UTC"
  source_rating: "B"  // 可信度评级 B (A=最高, E=最低)
  content:       "Movement of armed personnel reported near grid 34.52/69.18. Unconfirmed weapons transfer observed."
}
STEP 2本体映射:三路数据被统一建模为同一张图上的节点

这是 Ontology 最核心的能力——不是把不同格式的数据转换成同一种格式,而是让它们指向同一个语义对象。

// 三个异构输入 → 映射到共同的 GeoRegion 对象 → 自动创建关联的 Event 对象

// 第一步:空间关联。三个输入的坐标都在 GeoRegion["Kabul-East-Sector-7"] 边界内
GeoRegion["Kabul-East-Sector-7"] {
  activity_level: "normal" → "ELEVATED"
  active_sensors: [SAT-IMG-9471, SIG-22841, HUM-11892]
}

// 第二步:自动创建 Event 对象,聚合三个来源
Event["EVT-473"] {  // 自动生成的事件 ID
  type:          "FORCE_MOBILIZATION"  // Ontology 自动分类
  confidence:    0.82  // 多源交叉验证:三种独立来源指向同一事件 → 置信度提升
  geo_region:    → GeoRegion["Kabul-East-Sector-7"]
  linked_intel:  → [SatelliteImage["SAT-IMG-9471"], SIGINTIntercept["SIG-22841"], HUMINTReport["HUM-11892"]]
  observed_at:   "2026-05-27T06:12:00Z"
}

// 第三步:关联到受影响 Unit 对象
Event["EVT-473"] → affects → Unit["Alpha-Company"]  // 距离 23km
                  → Unit["Bravo-Company"]  // 距离 41km
                  → Unit["Charlie-Platoon"]  // 距离 12km ← 最近的友军单位

关键:任何一条情报单独看,置信度都很低(卫星图像 0.78、SIGINT 无法破译、HUMINT 来自 B 级来源)。但 Ontology 把三种来源关联到同一时空交叉点后,置信度上升到 0.82——这就是"多源融合"的数学本质。

STEP 3数字孪生:战场态势实时映射
// 数字孪生当前战场快照
{
  elevated_regions:           ["Kabul-East-Sector-7", "Kabul-East-Sector-6"]
  active_events:              ["EVT-473: FORCE_MOBILIZATION (confidence 0.82)"]
  nearest_friendly_unit:      Unit["Charlie-Platoon"]  // 12km
  charlie_platoon_status:     "standard_patrol"  // 当前任务:常规巡逻
  charlie_platoon_readiness:  0.94  // 装备完好率 94%,弹药充足
  historical_pattern_match:   "pre-strike mobilization (14 similar events in region)"
  reinforcement_eta:          45 minutes  // 最近增援部队到达时间
}
STEP 4AI 推理:基于历史模式和当前状态的威胁评估

Q1: 这个事件有多危险?

历史上有 14 次类似模式(卫星图像车辆集结 + SIGINT 突发通信 + HUMINT 武器流动),其中 11 次在 4-8 小时内升级为交火。当前三源交叉验证置信度 0.82,AI 评定威胁等级:HIGH。(依据:历史事件库中匹配的 Outcome 分布)

Q2: Charlie-Platoon 应该做什么?

当前位置 12km,常规巡逻状态。AI 计算:如果敌方兵力约 30-50 人(基于 8+2 辆车的运力估算),Charlie 的兵力比为 1:1.2~2.0,在无增援下不建议正面接触。推荐:撤至 Position-Alpha(距离 8km,有天然掩体和后勤支持),同时呼叫增援。

Q3: 什么时机不该撤?

如果敌方行动方向指向 Bravo-Company(41km 外),Charlie 在当前位置可以作为早期预警前哨。但当前估算敌方行动方向概率:朝向 Charlie 方向 0.58、朝向 Bravo 0.31、其他 0.11。基于最大化存活概率,推荐撤退。

Q4: 撤退的风险是什么?

撤退路线经过 Sector-8,该区域过去 3 天无异常活动报告。但该区域有一条已知的简易爆炸装置(IED)走廊——最近一次事件 11 天前。AI 建议派出无人侦察机先行扫描。(依据:GeoRegion["Sector-8"].historical_IED_events)

STEP 5写回行动:经由指挥链的决策执行
// AI 将推理结果转换成作战建议,由指挥员决策
Recommendation {
  title:           "Charlie-Platoon: Recommending Redeployment"
  urgency:         "IMMEDIATE"
  primary_action:   Action["RedeployUnit"] {
    unit: "Charlie-Platoon"
    destination: "Position-Alpha"
    route: "via Sector-8 (pre-scanned by UAV)"
    reasoning: "Proximity to EVT-473 assembly + historical pattern (11/14 similar events escalated)"
  }
  supporting_actions: [
    Action["DeployUAV"] { target: "Sector-8", mission: "route_scan" },
    Action["RequestReinforcement"] { from: "Battalion-Reserve", eta: "45min" },
    Action["UpdateThreatLevel"] { region: "Kabul-East-Sector-7", level: "HIGH" }
  ]
  approval:         "required_from: Battalion_Commander"
  fallback:         "If no response in 15min → escalate to Brigade"
}

// 指挥员批准后,Action 链执行:
// 1. DeployUAV 写回无人机控制系统
// 2. RedeployUnit 写回 C2 (Command & Control) 系统
// 3. RequestReinforcement 写回后勤调度系统
// 4. UpdateThreatLevel 写回 Ontology,更新数字孪生

闭环:指挥员在 Gotham 界面上看到 AI 推理的完整依据(三个情报来源、14 次历史事件对比、撤退路线风险分析),做出决策。每次决策的结果——包括指挥员是接受还是推翻 AI 建议——都被写回 Ontology,成为未来推理的参考。

这条链路的核心要点

  • 多源 ≠ 多点。三种不同格式的情报之所以能交叉验证,是因为它们被映射到了同一个 GeoRegion 和 Event 对象上。不是"搜索同一个关键词",而是"指向同一个语义实体"。
  • AI 给出的是 reasoning,不是 prediction。Attack prediction confidence 0.82 有明确的数学依据(14 次类似事件中 11 次升级)。指挥员能看到这个依据,判断要不要信。
  • CDR(指挥员决策记录)是 Ontology 闭环中的一环。指挥员选择撤退还是坚守,这个选择被记录、执行结果被记录。10 次类似场景后,AI 的推荐会更准——不是模型训练,是历史数据积累。

三个场景,一条统一链路

步骤供应链火灾波音质量缺陷战场情报融合
1. 数据进入IoT 温度传感器 182°FMES 质检 FAIL 报告卫星图像 + SIGINT + HUMINT
2. 本体映射DC-3.status → FIRE_ACTIVE
级联标记 23 个 PO
Component.quality → FAILED
Batch Link 标记 47 个零件
三源 → 同一 GeoRegion → 一个 Event
交叉验证置信度 0.82
3. 数字孪生受影响 $2.47M 订单 + 18 个客户实时快照2 架受影响飞机 + 3 个交付里程碑的精确画像Charlie-Platoon 距离 12km + 增援 ETA 45min
4. AI 推理4 维评估:客户优先级 + 替代库存 + 运输时间 + 成本4 维评估:停线时机 + 替代供应商 + 客户通知 + 供应商评级4 维评估:威胁等级 + 行动方案 + 撤退路线 + IED 风险
5. 写回行动2 个紧急 PO (人工审批) + 客户通知 (自动)5 步 Action 链:停线 → 复检 → 采购 → 通知 → 日志4 步 Action 链:无人机 → 部署 → 增援 → 威胁更新
共通模式

Ontology 解决的是"同一个东西不同系统叫不同名字"的问题。配送中心、液压泵零件、战场坐标——在各自系统里它们只是 ID、只是坐标、只是图片。Ontology 让它们成为同一个语义对象的不同属性。一旦这个同一性建立起来,数字孪生就能自动反映真实世界的变化,AI 就能基于结构化事实推理,Action 就能精准写回。

不是魔法,是把"数据→对象→关系→推理→行动"的每一步都做成了确定性的工程链路。陌生读者只要理解这五个词之间的关系,就能看懂任何 Ontology 场景。

← 上一篇: 路线对比 返回专题首页