Ontology 是什么？为什么企业 AI 不只有知识库，还需要业务对象与规则

理解企业 AI 中的 Ontology，可以先问：业务里有哪些对象、它们如何关联、有哪些规则与动作、谁有权操作？这比只问“有多少文件可以上传”更接近实际运行。不同领域对本体有不同用法，本文聚焦企业业务建模与 Palantir 的公开产品语境。

Palantir 的概念不等于一个术语表

在 Palantir 的产品语境中，Ontology 连接数据、逻辑、行动和安全，并包含特定平台能力。不能把一张对象表、知识图谱或普通 RAG 直接宣传为等价产品。

珞瑜可借鉴的思想是显式表达业务上下文，使数据与操作有明确含义；具体实现应按场景选择，而不是先承诺建设覆盖全公司的庞大系统。

用产品与订单解释业务对象

假设工业品企业有产品、客户、询盘、报价和订单。产品手册描述参数，询盘包含客户需求，报价引用价格和有效期，订单还受到库存、审批与交付安排影响。

知识库可以帮助查到某型号的规格，却不能仅凭手册知道当前客户是否获准享受某价格，也不能据此自动承诺交期。后者需要实时数据、业务规则、权限和动作接口。

这张表只是轻量业务模型示例，不是完整软件架构，更不是客户实际系统。

文档知识与业务状态怎样结合

一种工作方式是先检索手册获取稳定知识，再从授权接口取得当前业务状态，最后按规则生成建议。任何缺少依据或无权查询的部分，都应在结果中说明，而非由模型补齐。

例如“能否为客户推荐这个型号”可能需要产品条件与需求匹配；“能否今天发货”还需要库存和内部安排。把两个问题都交给同一份文档回答，会混淆长期知识与动态事实。

动作为什么要单独设计

查询、建议、审批和执行是不同能力。模型建议更新订单，不意味着已经获准执行。动作接口应校验参数、对象状态、用户权限和审批条件，并处理重复提交和失败。

第一阶段可以只生成待审核草稿，把后果留给有责任的人确认。只有在规则、接口、测试与回退清楚之后，才逐步增加自动化。业务对象的清晰定义有助于限制可操作范围，但不能单独保证安全。

企业怎样低成本起步

先选择一个流程，只定义必要对象、字段、关系和规则；记录资料来源与负责人；画出用户从提问到行动的路径。简单表格或已有数据库就可能足以表达初始模型，不必先采购图数据库。

在试点中发现共同字段、冲突规则和复用需求后，再决定是否建设共享模型层。不要把每个部门的全部术语一次统一，也不要在没有实际场景时追求完美建模。

怎么验收模型是否有用

检查同一业务概念在不同来源中是否一致、规则是否有人确认、对象状态是否可追溯，以及应用是否减少人工核对。采用代表性任务验证，例如旧型号替代、客户条件缺失、订单状态变化和无权动作。

如果模型很复杂，但用户完成任务仍需绕开它手工核实，可能需要重新缩小范围。衡量标准是业务解释和执行更清楚，而不是对象数量或连线数量。

常见误解

有 Ontology 就不需要知识库吗？不一定。文档提供依据，业务模型表达对象、状态与规则，两者可协作。

没有完整本体就不能用 AI 吗？不是。简单任务可以先采用明确字段和流程，只在需求证明必要时扩展。

能否直接复制 Palantir 的体系？其平台能力、实现和组织资源不能由概念图替代。珞瑜采用厂商中立的实施框架，边界见交付方式。