解密Palantir系列三：1.AIP · 把 LLM 嵌入企业决策

解密Palantir系列三：1.AIP · 把 LLM 嵌入企业决策

摘要

企业 AI 真正难的，不是接入一个更强的大模型，而是让模型在实时数据、业务规则、权限审批和审计约束下参与行动。本文以 Palantir AIP 为例，拆解 LLM 从聊天演示走向企业决策现场所需的架构、治理与落地条件。

很多企业的 AI 项目，都经历过相似的一幕：

接入一个大模型，连上几份文档，再做一个漂亮的聊天界面。演示时，它能总结报告、回答问题、生成方案，看起来几乎无所不能。

可一旦准备接入真实业务，问题马上出现：

• 它看到的是不是最新数据？
• 它是否有权读取这些字段？
• 它调用的是企业认可的规则，还是自己“猜”出来的结论？
• 它能不能修改 ERP、MES 或 CRM？
• 高风险动作由谁批准？
• 执行失败后如何回滚？
• 半年后审计，能否还原当时为什么做出这个决定？

这才是企业 AI 从演示走向生产的真正鸿沟。

企业真正缺的，往往不是一个更会回答问题的 LLM，而是一套能把数据、逻辑、行动、权限和责任连接起来的决策闭环。

推理与编排组件Palantir AIP（Artificial Intelligence Platform）试图解决的，正是这件事。

AIP 到底是什么：不是更强的模型，而是受控的 AI 操作层

先说结论：

AIP 不是 Palantir 版 ChatGPT，也不只是企业 RAG 或 LLM API 网关。它更像一层企业 AI 操作系统：让一个或多个 LLM 在 Ontology 提供的业务语义、权限和行动边界内，参与真实业务流程。

这里最重要的词不是“智能”，而是受控。

普通 LLM 应用的基本动作通常是：

用户提问 → 模型生成答案

AIP 面向的流程更接近：

用户提出业务问题 → 系统获取受权限约束的事实 → 调用企业已有逻辑 → 生成可比较方案 → 人工确认或按规则放行 → 写回业务系统 → 记录结果并持续评估

从架构视角看，可以把前者理解为“一次模型调用”，把后者理解为“一次受治理的业务决策”。

这也是为什么 AIP 不能脱离 Foundry 和 Ontology 单独理解：

• Foundry负责集成数据、模型与业务流程；
• Ontology把数据映射为订单、客户、设备、供应商等业务对象，并连接属性、关系、规则和动作；
• AIP再把 LLM 接入这个可操作的业务世界。

LLM 在这里不是最终责任主体，而是一个推理与编排组件。

AIP 的价值不在于让 LLM 更会聊天，而在于让它在受控闭环中参与企业行动。

一张图看懂 AIP：让 AI 扎根于数据、逻辑和行动

Palantir 对 AIP 的核心表达是：AI 要参与决策，必须扎根于企业自己的三类资产。

这三根支柱之外，还有两类不可缺少的能力：

• Operational Interfaces：让业务人员查看、修改、批准和反馈；
• Transparency & Oversight：管理权限、评测、审计、追溯和责任。

因此，AIP 的关键并不是让 LLM 直接连接所有系统。恰恰相反，LLM 应先经过 Ontology、工具治理和权限检查，再接触数据、逻辑与动作。

普通 RAG：
用户问题 → 检索文档 → LLM 回答

AIP 式闭环：
用户问题 → 权限过滤 → Ontology 上下文
         → 企业 Function / Model
         → Scenario 与人工确认
         → Action 写回
         → Decision Lineage 与结果反馈

普通 RAG 的终点通常是“得到答案”。

AIP 关注的终点则是：形成一个经过治理、可以执行、能够追溯的业务结果。

为什么很多企业 AI 项目只能停在 Demo

一个聊天机器人能回答问题，不等于它具备生产能力。

LLM 要进入企业核心流程，至少要通过五道关。

这五道关解释了一个常见误区：

模型能力只决定 AI 能“想多好”；生产基础设施决定它能否“做成事”。

换一个更直白的说法：企业不是给 LLM 接一堆文档，而是要给它接入一个有业务含义、有权限边界、能安全行动的世界。

AI Tool Factory：真正难的不是调用工具，而是治理工具

LLM 想要“动手”，通常依赖 Function Calling 或 Tool Calling：模型选择一个工具，生成参数，再由应用执行。

这个机制本身并不新鲜。真正困难的是企业级治理：

• 工具从哪里来？
• 当前用户能看到哪些工具和数据？
• 参数是否满足业务规则？
• 哪些动作可以自动执行？
• 哪些动作必须人工确认？
• 写回后如何审计和追溯？

AIP 的关键做法，是让 Ontology 中的 Action、Function 和受控查询能力成为 AI 可以请求使用的工具，并让执行继续服从原有权限与安全策略。

一个非常重要的边界是：

LLM 并不是直接“拿到工具并执行”，而是提出工具调用请求；平台再在调用者的权限范围内完成校验和执行。

下面是一个概念化示意，用来说明企业工具需要包含哪些信息。它不是 Palantir 的实际配置语法。

tool: switch_supplier
inputs:
  sku_id: string
  target_supplier: Supplier

permissions:
  required_role: supply_chain_manager

preconditions:
  - target_supplier.status == approved

execution:
  mode: stage_for_human_review

audit:
  record_in_decision_lineage: true

与普通工具调用相比，AIP 强调的是一整套关联机制：

因此，AIP 与普通 Agent 框架的关键差别，不是“有没有工具调用”，而是：

工具是否天然连接业务语义、权限、校验、人工审批和写回审计。

其他 Agent 框架当然也能搭出这些能力，但通常需要企业自行设计、集成并长期维护。

一个供应链案例：LLM 如何参与决策，但不越权

参考 Palantir 官方使用的虚构案例 Titan Industries，假设一家制造企业突然收到消息：关键供应商停产，多个订单可能延期。

如果只问普通 Chatbot，它可能会回答：

“建议寻找替代供应商、调整库存，并及时通知客户。”

这句话没有错，却无法直接运营一家企业。真正的决策需要把事实、计算、方案、审批和执行串起来。

第一步：业务人员提出问题

供应链负责人问：

“这次停产会影响哪些订单？请比较三个可执行方案。”

第二步：平台按权限收集事实

系统通过 Ontology 获取与当前用户权限匹配的供应商、库存、产线、客户和订单信息。敏感价格或财务字段，不会因为用了 LLM 就自动开放。

第三步：LLM 请求调用企业逻辑

LLM 可以编排查询和工具，但关键计算仍交给企业已有的 Function、预测模型或优化器，例如：

• 找出受影响订单；
• 预测延期与收入风险；
• 排序替代供应商；
• 模拟不同物料与产线重分配方案。

这样做的目的，是避免让 LLM 用自然语言“估算”本应由确定性规则或专业模型完成的工作。

第四步：先生成 Scenario，不直接修改生产系统

系统可以形成三个沙箱方案：

此时的 Scenario 是“可演练的决策草案”，不是已经生效的生产计划。

第五步：人类审阅并决定是否放行

对于高金额、跨部门或首次启用供应商等高风险动作，平台可以要求供应链、质量、财务或销售负责人共同确认。

只有被证明可靠、低风险且运行成熟的流程，才适合逐步扩大自动执行范围。

第六步：审批后再写回各业务系统

通过 Action，系统可以分别更新：

• ERP 中的采购订单；
• MES 中的生产计划；
• WMS 中的库存预留；
• CRM 中的客户沟通任务；
• 质量系统中的供应商验证任务。

第七步：记录决策血缘和实际结果

一次完整记录应尽可能覆盖：

• 谁在什么时间提出问题；
• 使用了哪些数据、模型和规则；
• LLM 请求调用了哪些工具；
• 生成过哪些方案；
• 谁批准、修改或驳回；
• 哪些系统被写回；
• 最终是否减少延期、控制成本或改善客户结果。

这就是 AIP 想建立的闭环：

AI 可以参与分析和编排，但责任边界、执行权限和最终结果不能变成黑箱。

AIP 与 RAG、Agent、Copilot、云模型平台有什么不同

下面的比较基于产品的典型架构重心，用来帮助理解定位，并不是性能、成本或效果的第三方基准测试。

这些方案并不是非此即彼。

一家企业完全可以同时使用：

• ChatGPT、Claude 或 Copilot 提升个人生产力；
• RAG 建设内部知识问答；
• 云厂商平台托管和调用模型；
• Agent 框架快速开发局部自动化；
• AIP 管理跨系统、高价值、需要审批与审计的运营决策。

更准确的区分是：

任务适配云模型平台主要解决“如何使用模型”；AIP 更关注“模型如何在企业业务语义和治理边界内参与行动”。

三个容易被误读的技术点

1. 多模型不是“让几个 LLM 投票”

Palantir 将其多模型立场概括为 k-LLM：企业不应把核心业务永久绑定在单一模型上。

它的实际价值主要包括：

• 任务适配：推理、分类、摘要、代码或敏感数据处理，可以选择不同模型；
• 供应商独立性：底层模型变化时，业务应用不必全部重写；
• 环境与合规适配：公有云、私有环境和不同区域可以采用不同组合；
• 对比与评测：在高风险场景中比较模型表现、共识和分歧。

多模型可以做交叉验证，但不意味着“多数模型同意”就能替代业务规则和人类责任。

2. OAG 不是脱离 RAG 的新范式

AIP 语境中的 OAG（Ontology Augmented Generation，本体增强生成），更准确的理解是用 Ontology 改善 RAG 的上下文检索与接地。

普通向量检索也许能找到一段供应商合同，却不一定知道：

• 它对应哪些物料；
• 哪些工厂依赖这些物料；
• 哪些订单会受影响；
• 当前用户能否查看合同价格；
• 哪些 Action 可以被发起。

Ontology 补上的，正是对象、关系、权限、逻辑和动作上下文。

因此，不应简单地说“AIP 不是 RAG”，而应说：

AIP/OAG 仍然使用检索增强，但它试图把检索结果放回一个带业务关系和权限边界的企业语义世界。

3. 安全能力不等于“绝对安全”

Palantir 的公开材料强调，部分第三方托管模型通过技术和合同安排提供零数据保留（ZDR），即第三方不保留客户 prompt 或 completion，也不将传输数据用于模型再训练。

但企业不能因此跳过自己的合规审查。实际边界仍取决于：

• 选择的模型与服务商；
• 公有托管、私有部署还是混合部署；
• 所在区域和数据驻留要求；
• 哪些字段会进入 prompt；
• 日志、审计和保留策略；
• 合同条款与组织内部治理。

正确的表述不是“Palantir 保证一切安全”，而是：

AIP 把权限、数据边界、人在环和审计设计成平台能力；企业仍要为具体部署和使用方式负责。

什么企业值得上 AIP

AIP 更适合以下场景：

• 业务问题跨越多个系统或部门；
• 企业已经能够清晰定义客户、订单、设备、物料等核心对象；
• 现有规则、模型和优化算法需要被 AI 调用；
• AI 的建议最终要进入真实业务系统；
• 不同动作需要不同权限、审批和风险级别；
• 决策过程必须可解释、可审计、可复盘；
• 执行结果有条件回流，形成持续评估闭环。

在立项前，至少应该回答八个问题：

相反，如果需求只是个人写作、会议总结、单纯文档问答或不写回系统的低风险分析，AIP 很可能过重。普通企业助手、RAG、BI 工具或轻量 Agent 往往更合适。

还有两种情况尤其需要谨慎：

没有可靠数据和业务语义基础，AIP 容易退化成昂贵的 Chatbot；没有 Action 治理和责任机制，AI 自动化则可能放大运营风险。

结语：企业需要的不是“更聪明的聊天框”

AIP 最值得借鉴的，不一定是某个具体产品功能，而是一种企业 AI 架构观：

1. 让 AI 基于实时、受权限约束的业务事实；
2. 让确定性规则、专业模型和 LLM 各做擅长的事；
3. 让高风险行动默认经过校验和人工确认；
4. 让每次建议、审批、写回和结果都可追溯；
5. 根据实际表现逐步放权，而不是一开始就追求全自动。

真正成熟的企业 AI，不是让 LLM 取代所有决策者。

它更像一个刚加入团队的新成员：先获得有限信息和有限工具，在监督下完成任务；当组织逐步建立信任，再谨慎扩大它的权限。

所以，判断一个企业 AI 项目是否真正进入生产，不要只问：

“模型回答得准不准？”

还要继续追问：

“它依据什么事实、调用什么逻辑、拥有什么权限、由谁承担责任，又如何把结果安全地带回业务？”

当这些问题都有清晰答案时，LLM 才算真正走出了聊天框，进入企业决策现场。

资料说明

本文主要依据以下本地资料整理并做通俗化重写：

• Palantir AIP Overview：AIP 架构、企业数据 / 逻辑 / 行动三支柱、多模型立场；
• Connecting AI to Decisions with the Palantir Ontology：Titan Industries 供应链案例、Scenario、写回与 Decision Lineage；
• Palantir AIP 第三方 LLM 合规 FAQ：第三方托管模型的数据处理与合规边界；
• Palantir AIP 架构、AIP Logic、Chatbot Studio、OAG 与安全治理相关文档的本地研究笔记。