先说结论
Ontology 可以理解成企业 AI 的“业务骨架”。
大模型负责理解语言，RAG 负责查找资料，知识图谱负责连接实体，而 ontology 负责定义企业业务世界里的对象、关系、规则、权限和动作。
如果没有 ontology，AI 很容易停留在“会聊天、会总结、会写报告”的层面；有了 ontology，AI 才可能进入真实业务流程，理解订单、客户、供应商、产品、风险、合同、设备之间的关系，并进一步支持决策和执行。
为什么业务负责人和 FDE 需要关心 Ontology？
企业引入 AI 时，最容易被关注的是模型能力：哪个模型更强、回答更准、成本更低、速度更快。
但真正进入企业场景后，问题很快会变成：AI 知不知道我们公司里的“客户”是什么意思？知不知道订单和合同、库存、供应商之间的关系？能不能区分普通风险和关键客户风险？建议能不能追溯到证据？能不能在权限范围内触发动作？
这些问题，单靠大模型本身无法稳定解决。因为模型知道的是通用语言知识，而企业需要的是“本企业的业务结构”。Ontology 正是把这套业务结构沉淀下来，让 AI 能够围绕真实业务对象工作。
Ontology 到底是什么？
通俗地说，ontology 是一套“给机器看的业务世界说明书”。它主要定义五类东西：
Ontology 不只是“知识分类”，它更像是企业业务的可执行地图。
一个简单例子
以 AI 产业链研究为例，我们可以定义公司、产品、供应链关系、事件和指标。
当出现一条新闻：“HBM 供应紧张可能影响高端 GPU 交付”，普通 AI 可能只能做新闻摘要。但如果有 ontology，系统可以进一步追踪：HBM 影响哪些 GPU？这些 GPU 由哪些公司生产？哪些云厂商依赖这些 GPU？哪些上市公司可能受到收入或成本影响？是否需要生成投资研究提醒？
这就是 ontology 的价值：它让 AI 不只是读懂一句话，而是能把这句话放进业务网络里。
它和 RAG、知识图谱有什么区别？
RAG 解决的是资料检索问题：用户问问题时，系统去文档库里找相关内容，再交给模型回答。
知识图谱解决的是关系连接问题：把公司、产品、人物、事件等实体用关系连起来，方便查询路径和影响链。
Ontology 解决的是业务语义问题：定义哪些对象存在、它们之间能有什么关系、哪些属性必须有、哪些动作可以执行、哪些规则必须遵守。
在 FDE 工作中的位置
如果把 FDE 理解成 Forward Deployed Engineer，也就是深入客户现场、把 AI 和软件系统交付到真实业务中的工程角色，那么 ontology 是 FDE 的核心工作之一。
FDE 面对的不是干净的教科书问题，而是混乱的真实系统：数据散在不同部门，字段口径不一致，业务流程依赖人，很多关键知识只存在于员工经验里。
FDE 要做的，是把这些现实问题翻译成可运行的软件系统。Ontology 正好位于 FDE 工作的中心：它连接业务理解、数据工程、软件工程和 AI 工程。
更准确地说，FDE 是把客户业务现实转化为 ontology，并基于 ontology 交付 AI 应用的人。
为什么它能形成壁垒？
模型可以换，前端可以重做，数据库也可以迁移，但高质量 ontology 不容易被复制。
原因是 ontology 沉淀的是客户真实业务的结构：哪些对象最重要，哪些关系决定风险，哪些流程影响收入，哪些规则来自管理经验，哪些动作真正能推动业务结果。
这些不是买一个模型就能得到的，也不是看几份文档就能自动生成的。它需要 FDE 和业务团队反复磨合，在真实使用中不断修正。一旦 ontology 成熟，它会变成企业 AI 系统的核心资产。
需要什么系统支撑？
Ontology 不是一张图，也不是一份文档。要真正落地，需要一套系统支持。
MVP 阶段可以先轻量实现：Postgres 存对象和关系，pgvector 存文档片段和向量，Python / FastAPI 提供对象查询和动作接口，LLM 负责信息抽取、解释和问答，前端提供对象视图、关系链路和风险看板。
落地路线
管理层应该关注什么？
一句话总结
Ontology 是企业 AI 的业务操作地图。它让 AI 不只是会说话，而是知道业务对象是谁、关系是什么、风险在哪里、下一步该做什么。