Palantir 的 Ontology 给大语言模型提供了很好的 context。概念比较容易理解，但是具体怎么实现，很多同学好奇。今天以一个例子介绍一下这块的设计和实现原理。
Palantir 并非简单地将大语言模型（LLM）作为一个问答机器人，而是将其深度整合进一个已经包含了严谨业务逻辑和操作规则的系统中。
这个过程的核心思想是：将经过验证的、可信的业务逻辑封装成“工具”（Tools），然后让大模型学会去调用这些工具，而不是让大模型自己重新发明或猜测这些逻辑。
下面我们通过一个“采购订单审批”的实际例子，来详细说明这个过程。
场景介绍
假设一家制造企业使用 Palantir Foundry 作为其运营系统。系统中有一个关键流程：当采购订单（Purchase Order, PO）的金额超过一定阈值，或者供应商存在高风险时，需要触发一个特殊的审查流程。
目标： 构建一个AI助手，帮助采购专员快速审查新来的采购订单，并利用系统中已有的逻辑来判断风险。
第1步：定义“本体”（Ontology）- 搭建数字世界的基础
在 Palantir 中，一切都始于“本体”。这不仅仅是数据表，而是对现实世界业务的数字孪生。
- 创建对象 (Objects):
- 采购订单 (Purchase_Order): 包含属性如订单ID、金额、状态、创建日期 等。
- 供应商 (Supplier): 包含属性如供应商ID、名称、风险评级（如高、中、低）、历史交付准时率 等。
- 创建链接 (Links):
- 采购订单 对象会链接到其对应的供应商 对象。
这个本体为所有数据和逻辑提供了统一的、有意义的上下文。
第2步：封装“逻辑”（Logic）- 创建函数与动作
这是“把逻辑放到系统中”的关键一步。我们把业务规则用代码封装成可重用的、受版本控制的组件。
- 创建逻辑函数 (Logic Function):
我们用 Python 编写一个名为 check_purchase_order_risk 的函数。这个函数不是孤立的代码，它能够读取和操作“本体”。
# 这是一个在 Palantir 平台中注册的函数from palantir.functions import Function, Ontologyfrom palantir.ontology import Object@Function()def check_purchase_order_risk(po_object: Object("Purchase_Order")) -> dict:"""检查一个采购订单的风险等级。如果金额超过10万美元，或供应商风险评级为'高'，则标记为高风险。"""# 从本体中获取链接的供应商对象supplier = po_object.get_linked_objects("Supplier")[0]reasons = []is_high_risk = False# 核心业务逻辑if po_object.properties["金额"] > 100000:is_high_risk = Truereasons.append("订单金额超过10万美元阈值。")if supplier.properties["风险评级"] == "高":is_high_risk = Truereasons.append(f"供应商 '{supplier.properties['名称']}' 的风险评级为'高'。")return {"is_high_risk": is_high_risk,"reasons": reasons}
这个函数现在成为了系统中的一个可信逻辑单元。任何人或系统调用它，都会得到基于同样规则的、一致的判断。
- 创建动作 (Action):
我们再定义一个“动作”，允许用户在系统中“批准订单”。这个动作会修改订单对象的状态。
- approve_order(order_id, approver_name): 这个动作将指定order_id 的采购订单 对象的状态属性从“待审批”修改为“已批准”。
第3步：赋能“大模型”（LLM）- 将逻辑作为工具
现在，我们进入 Palantir AIP 的配置界面，将刚刚创建的逻辑单元“武装”给大模型。
- 注册工具 (Register Tools): 我们告诉 AIP，你现在拥有了几个新工具：
- check_purchase_order_risk 工具:
- 描述: “用于检查指定采购订单的风险级别和原因。”
- 输入: 一个Purchase_Order 对象。
- 输出: 一个包含风险状态和原因的结构化信息。
- approve_order 工具:
- 描述: “用于批准一个采购订单。”
- 输入: 订单ID，批准人姓名。
大模型并不知道这些工具背后的 Python 代码是什么，但它理解每个工具的功能、输入和输出。这就像给一个聪明但没有双手的人配上了可以操作世界的机械臂。
第4步：应用与重用 - 在实际场景中交互
现在，采购专员可以与AI助手进行交互了。
采购专员 (User):
“帮我审查一下最新的采购订单 PO-20250705-001。”
AI助手 (LLM) 的内部“思考”过程：
- “用户让我‘审查’一个采购订单。我有一个工具箱。”
- “在我的工具箱里，check_purchase_order_risk 这个工具的描述和我的任务完全匹配。”
- “我需要先找到PO-20250705-001 这个对象，然后把它作为输入，调用check_purchase_order_risk 工具。”
系统执行：
Palantir 平台在后台安全地执行了 check_purchase_order_risk(PO-20250705-001) 这个函数。函数访问了本体，执行了我们预设的逻辑，并返回了结果：
{"is_high_risk": True, "reasons": ["订单金额超过10万美元阈值。"]}
AI助手向用户输出：
“我已经审查了订单 PO-20250705-001。根据系统中设定的业务规则，这是一个高风险订单，因为其金额为$125,000，超过了10万美元的审查阈值。建议您在批准前进行额外确认。您需要我执行‘批准’操作吗，还是需要更多信息？”
这里的关键点在于：
- AI的回答不是凭空猜测，而是明确基于“系统中设定的业务规则”。
- 它**重用（Reused）**了我们封装好的check_purchase_order_risk 函数，保证了判断的准确性和一致性。
- AI的建议是可操作的，它可以继续调用approve_order 这个工具来执行下一步动作。
- 整个过程是可审计的，系统后台清晰地记录了AI在何时调用了哪个函数，输入和输出分别是什么。
总结
Palantir 通过 本体(Ontology) -> 逻辑函数/动作(Logic/Actions) -> AI工具(Tools) 这一链条，完美地实现了将严谨的业务逻辑植入系统，并让大模型安全、可靠地重用这些逻辑。这种方式既发挥了大模型强大的自然语言理解和推理能力，又用确定性的、受治理的系统逻辑为其“兜底”，确保了在企业级复杂应用中的可靠性和安全性。
附录
一、Palantir 概念
Palantir Ontology：从数据治理到决策闭环的智能引擎——业务流程数字孪生的实践与边界
Palantir Ontology：本体怎么建设以及什么是有效本体
二、商业模式和适合的客户
Palantir的黄金客户画像：哪些企业最适合落地数据智能平台？
三、产品实现
Palantir 产品体系深度解构：Ontology 驱动下的分层架构与模块
Palantir Foundry：简单四步将您组织的数据平台扩展到运营领域
Palantir决策模拟：从Ontology到AIP的What-if推演引擎
构建专家反馈闭环：Palantir HITL 驱动AI决策持续进化
四、加作者讨论Palantir和本体
