Ontology

Ontology（本体）

定义

把业务概念、关系和规则形式化为机器可读语义层，用来约束 Agent 对企业事实的解释与推理

关键数据点

• 核心定位：本体不是另一个数据库，而是业务世界的语义地图。它回答"什么是什么、对象之间如何关联、什么条件成立"。
• 组成方式：TBox 定义稳定概念、关系和约束，ABox 注入具体业务事实，推理机在两者结合处生成新的分类或结论。
• 企业价值：当 ERP、OMS、MES 等系统对同一词使用不同口径时，本体提供共享语义层，降低 Agent 把同词误判为同义的风险。
• Agent 价值：Ontology-Agent 不让 LLM 直接猜业务规则，而是把关键规则判定交给本体工具和推理机，再由 LLM 解释结果、组织行动。
• 与知识图谱的区别：Knowledge-Graph 更偏事实集合，本体更偏概念、关系、约束和可推理结构。两者常配合使用，但不能互相替代。
• 与代码的关系：本体把业务概念从 prompt、流程和 if/else 中抽出来，成为可版本化、可测试、可解释的概念基础设施。
• Token 效率价值：Agentic 编程的 Token 消耗 85-99% 来自 Input Token，其中依赖探索（追踪实体间关系）是最具结构性的消耗源。Ontology 把"在文本里推断关系"变成"在图谱上查询关系"，Codebase-Memory（arXiv:2603.27277）验证有图谱时 token 消耗压缩 10 倍。
• 运维领域实证：阿里云 UModel 在运维场景中实现从"面向数据"到"面向对象"的转变，告警时直接定位实体并沿关系链聚合关联数据，避免多轮元数据查询和字段映射推断的 Token 开销。
• 长期价值判断：代码场景的本体价值可能被模型内化（代码是预训练主战场），但运维等企业级领域因私有数据、关系推理本质和高准确率要求，本体价值不会被模型吃掉。Palantir 市值 3000 亿+美金是对"企业 Ontology"能力的资本市场定价。
• 决策中心定位（2026-04 Palantir 官方架构文）：Palantir 把 Ontology 定位为"决策操作系统"而非数据库升级——数据架构只描述数据，Ontology 进一步建模决策（上下文、候选选项、下游影响）与行动（"动词"），并自动记录 end-to-end decision lineage 作为 agentic memory 与 fine-tuning 的燃料。详见 Decision-Centric-Architecture。⚠️ vendor 立场，机制可验证、定位表述需打折。
• 与 UNS 的层次关系：制造业场景中 Palantir 把 Unified Namespace（ISA-95 层级 + Sparkplug B 命名）定位为纯数据层，Ontology 是其上叠加 logic + action 的决策层——数据命名统一（UNS/UModel）是本体的前置条件而非目标。
• 反幻觉 grounding 层（2024-07 Palantir Responsible AI #1）：幻觉是 LLM 生成能力的结构性副产品，不可仅靠 retrain 消除，因此需要架构层 grounding。Palantir 把 LLM 经 search-query 间接访问 Ontology（元数据 + data 工具，而非 prompt 塞全表）的模式命名为 OAG（Ontology-Augmented Generation）——RAG 的企业领域特化。它与 tool handoff（计算交接给确定性函数）、human-in-the-loop 审核（提案入队不直接落库）构成按幻觉成因分层的三层防御，三层都建在 Ontology 的 data/logic/action 三要素上。⚠️ vendor 立场：机制可验证，演示为虚构案例、无失效率数据；且 grounding 有效性受制于 ABox 事实的新鲜度与建模质量。

何时值得使用

本体适合规则明确、概念复用高、解释责任强的企业场景。例如订单是否可发货、商品是否属于特殊处理类别、供应商是否满足准入条件、合规对象是否触发审查等。

这些场景的共同点是：错误不是普通问答质量问题，而会影响真实流程、权限、承诺或责任归属。此时只靠 RAG 或长 prompt 不够，因为文本上下文无法稳定表达约束，也无法保证不同 Agent 使用同一套业务口径。

本体不适合把所有企业数据一次性装进去。交易明细、日志、库存数量和客户互动仍应留在数据库或业务系统中。本体只保留稳定语义和必要映射，运行时按需从系统取事实，注入 ABox，再调用推理。

与 Agent 系统的分工

层次	主要职责	典型承载
业务概念	定义对象类型、关系、约束	本体 / TBox
事实数据	存储订单、客户、库存、状态	数据库 / ABox / 知识图谱
确定性判断	根据规则推导分类和结论	OWL 推理机 / GraphDB
语言交互	理解请求、选择工具、解释结果	LLM Agent

这个分工的价值在于把高风险判断从模型内部迁移到可审计组件。LLM 仍然重要，但它负责调度和解释，不负责凭自然语言直觉决定业务规则是否成立。

前提与局限性

• 形式化前提：关键业务概念必须能被说清楚，并能转写成类、属性、关系、约束或规则。
• 组织前提：领域专家必须参与建模。没有业务共识时，本体只会把错误口径形式化。
• 数据前提：ABox 事实必须可靠。TBox 再正确，如果事实字段延迟、缺失或含义混乱，推理结果仍会错。
• 工程局限：推理比普通查询更重，高频实时场景需要缓存、预计算、增量推理或规则下沉。
• 表达局限：OWL 适合分类、约束和一致性检查；时间窗口、审批流程、动作触发等过程性逻辑可能仍需规则引擎或普通代码配合。
• 成本边界：本体把规则维护集中化，但不会让维护消失。它需要版本治理、规则测试、变更评审和生产监控。

关联概念

• TBox：本体的概念与规则部分
• ABox：本体的事实数据部分
• RDF：基础数据标准（三元组）
• OWL：高级本体表示语言
• Protégé：本体建模工具
• Ontology-Agent：基于本体的 AI Agent
• Knowledge-Graph：事实数据的集合（与本体互补）
• Enterprise-Ontology-Application：企业级本体进入 AI Agent 的主题页
• UModel：阿里云基于本体论的 IT 世界统一建模框架