重新审视本体：从语义网的挫折到AI智能体的业务地图

什么是本体：概念、属性、关系、规则

本文是“本体的虚与实”系列的第1篇（原理篇）。近来在谈论AI智能体（AI Agent）时，本体（Ontology）又频繁出现。然而，本体究竟是什么、为何一度被遗忘又重新回归，却很少得到清楚的解释。本篇梳理其原理。

W3C的OWL 2概述文档（w1）将本体定义为“涉及特定领域、由用户群体共同使用的形式化术语集合”。术语的含义由它与本体中其他术语之间的关系决定。OWL 2本体由类（概念）、属性、个体（实际对象）和数据值构成。通俗地说，有“客户”“合同”“司机”这样的概念（类），每个概念附带“注册日期”“驾照类型”等属性。再由“司机驾驶车辆”这样的关系把概念连接起来。在此之上，还要加上“满足某种条件就得出某种结论”的规则。

规则为何重要，Thoughtworks的文章（w3）中的例子说明得很清楚。语言模型读了文档，能推测出“司机驾驶车辆”。但它无从得知，在这家公司里，不具备特定通关资格的司机不能被安排到国际线路。这类规则只是散落在人们的头脑、政策文件和部门惯例中，并不在机器能够核查的地方。本体所做的，正是把这些“业务的含义与规则”转写成机器可读的形式。

与模式、分类体系、语义层、知识图谱有何不同

本体常与几种看似相似的工具混淆。Thoughtworks的文章（w3）把模式、受控词表（分类体系）、语义层、本体和知识图谱放在同一条连续谱上。一端是“数据如何存储”，中间是“这些数据是什么意思”，另一端是“机器能推理什么、执行什么行动”。每往上一级，表达能力就越强。但相应地，成本和管理负担也会增加，需要更多负责维护的人。

简要概括如下。数据库模式用表、列、键规定数据如何存放。分类体系事先确定要使用的术语，并按上下级归类。语义层（Semantic Layer）在全公司统一“销售额”“活跃客户”等指标和术语的定义。根据同一篇文章，语义层可能是实际业务中使用最广泛的一层。但它只标准化定义，并不包含智能体可以遵循的关系和逻辑，因此在表达能力轴上位置靠下。

最容易混淆的是本体与知识图谱（Knowledge graph）。同一篇文章（w3）的区分很清楚：本体是设计图（类、关系、规则），知识图谱则是在这张设计图中填入实际数据的产物。智能体实际查询的对象也是知识图谱。LLM与知识图谱路线图论文（paper）总结道，知识图谱以（主体实体，关系，客体实体）形式的三元组存储事实。下表比较了这五种工具各自包含的内容。

语义网为何未能在企业实践中广泛普及

本体最早受到关注的舞台是语义网。其目标是让机器能更好地处理网络内容（w1）。标准确实留存了下来。RDF把所有信息都写成由“主语-谓语-宾语”三个元素构成的三元组。同一对象出现在多个三元组中，信息便连接成图，而这个图可以用名为SPARQL的查询语言来查询（w2）。RDF入门文档（w2）举例说明了其用途：用schema.org词汇给网页附加机器可读的信息，或将数据链接到Wikidata。OWL的第一版于2004年发布，2012年OWL 2成为W3C推荐标准（w1）。

然而一进入企业内部，情况就不同了。第一，要学的东西很多。仅看OWL 2文档（w1），除了作为交换用必备语法的RDF/XML之外，还有Turtle、OWL/XML、Manchester等多种表示法。其语义依据名为SROIQ的描述逻辑（一阶逻辑的一个子集）来定义。推理机是一种强大的工具，能检查类之间是否存在矛盾、一个类是否包含于另一个类。但要使用它，需要专用工具、查询语言以及具备逻辑知识的人。Thoughtworks的文章（w3）称之为“翻译鸿沟”。本体工程师懂形式体系却不懂业务，业务专家懂业务却不懂形式化建模。在两者之间靠访谈来回传递知识，既慢又损失大。

第二个陷阱是全企业单一模型。同一篇文章（w3）指出，由于本体描述的是现实，人们容易产生在交付任何东西之前先把一切都建模的冲动。这类项目往往一年左右就不了了之。文章形容说，全企业主模型不过是给“试图把大海煮沸”这一陷阱起了个体面的名字。

第三个、也是最被低估的问题是维护。靠手工修改的模型跟不上法规变化、组织调整和产品更迭的速度。构建只需一次，与现实保持一致的工作却永无止境。然而在传统方式下，项目一结束，负责人也随之消失。文章（w3）说，如果没有负责人和定期检查，模型会在两个季度内过时，并称之为“披着技术外衣的治理问题”。作为替代方案，文章建议把本体当作产品而非项目来对待。传统方式需要12~24个月才能产生价值，而产品方式每次迭代安排4~8周。总之，问题不在于标准不足，而在于要学的东西多、范围失控、没有组织来维护，因此难以在实践中扎根。

为何再度兴起：LLM和智能体需要业务地图

改变风向的是LLM（大语言模型）。LLM与知识图谱路线图（paper）列举了LLM的弱点：知识隐含在参数中，会产生幻觉（Hallucination），依赖概率做决定，是黑箱，缺乏特定领域知识或新知识。相反，知识图谱结构化、准确、可解释，适合承载领域知识。不过它难以构建，而且总是不完整。该路线图将两者结合的路径归纳为三条：用知识图谱增强LLM，用LLM辅助知识图谱任务（包括构建），以及两者相互协同。

如今智能体会操作业务系统并代表公司采取行动，这些弱点因而暴露得更加明显。Thoughtworks的文章（w3）指出，智能体即使能读文档，也不掌握公司的运营逻辑，最终会碰壁。基于本体的RAG（检索增强生成）OG-RAG（paper）在检索阶段弥补了这一鸿沟。普通RAG用与领域无关的嵌入查找相似的文本片段。OG-RAG则先按照领域本体将文档整理为超图。超边是一次把多个相关事实捆绑在一起的连接。然后只挑选回答问题所需的最小事实组交给LLM。在农业和新闻领域的评估中，该方法在四种LLM上将准确事实的召回率提高了55%，将回答正确性提高了40%。在用户研究中，将答案关联到依据所需的时间减少了30%；在应用预先设定规则的推理任务中，准确率提高了27%。

在约束智能体行为方面，有一项企业智能体研究（paper）。该研究用角色、领域、交互三层本体来绑定智能体。作者指出，当前企业系统只用本体约束输入端（上下文组装、工具发现、治理标准），却不检查输出，存在“不对称”。因此他们提出了一个在输出端也验证回答、推理和合规的框架。在覆盖五个行业、三种LLM、共1,800次运行的实验中，结合本体的智能体在指标准确率和角色一致性上显著领先。效果在LLM训练数据覆盖不足的领域最大。在越南本地化领域，提升幅度是英语领域的2倍。

不过，本体并不等于护栏（Guardrail）。Thoughtworks的文章（w3）明确区分：本体告诉智能体“什么是被允许的”，但那只是知识，而非强制。只有当确定性运行的执行器真正核查规则并遵循结果，且能够证明已经核查过时，规则才会生效。文章还认为，许多运营规则更适合放在策略引擎中，而不是写成形式公理。此外，检索质量来自填入实际数据的图谱，而不是设计图。因此，Entity Resolution（找出并合并同一对象）和关系抽取做得如何，决定了质量的上限。

LLM能降低构建成本吗

语义网时期最大的成本，是由人逐一提取概念、写下关系。如今，把这类初稿工作交给LLM的趋势已很明显。OntoEKG（paper）是一个把工作分为两个阶段的流水线。先从企业的非结构化文档中提取核心类和属性，再将其组织成合乎逻辑的上下级层次，然后导出为标准RDF。在用数据、金融、物流领域文档构建的评估集上，以数据领域为准，模糊匹配F1达到0.724。同时，作者也表示在确定范围边界和层次推理方面暴露出局限。

因此，现实的图景是“LLM来写，人来挑”。Thoughtworks的文章（w3）建议用LLM流水线从现有模式、API定义和维基中提取分类初稿。这样，专家的工作就从编写定义变为审核和打磨初稿。但同一篇文章明确指出，这只能加快构建，对维护毫无帮助。也就是说，前面看到的第三个失败原因，即使有了LLM也依然存在。

处理设备检修记录的Plant Memory（paper）是把人工审核置于设计核心的例子。该系统先基于规则从SAP检修工单中提取事实，LLM只作为可选的“第二读者”。当LLM的解读与规则提取不同时，不会覆盖结果，只会提高该事实的审核优先级。每条事实都附有置信度、作为依据的原文和验证状态。技术人员在审核队列中确认事实；出现新术语时，批准或拒绝本体变更提议。这样验证过的图谱，对人以Web应用形式提供，对AI智能体则以MCP（模型上下文协议）服务器形式提供。不过，评估所用数据是合成的400份工单，因此不应将结果解读为在实际工厂中的性能。

近来走向何方：展示依据的回答，质疑检查器的研究

近期研究可以从两个方向来看。一个方向是以本体为依据，同时展示答案“确定到什么程度”。OA-RAG（paper）是一种混合形式推理与LLM推理的智能体，同时使用本体的逻辑结构和人工添加的说明。其特点是为每个答案报告作为依据的本体观察以及依据等级（蕴含、支持、相关、无关）。在用三个大规模本体构建的基准和六项医疗问答任务上，它在所比较的方法中整体性能最好。依据等级越强，准确率大体也越高。但这只是基准结果，并不代表实际诊疗中的性能。在医疗这类结果直接影响人的领域，最终判断必须由人来做。

另一个方向是质疑本体本身。用基于本体的检查器包裹在知识图谱上作答的智能体，这类做法越来越多。检查器研究（paper）直接检验了其背后“形式模式是可靠的裁判”这一假设。研究人员比较了三类本体：人工精编的本体、LLM生成的本体，以及从数据中提取的模式。每一类分别用作提示上下文、用作检查器，或两者兼用。然后在公开图谱和一个拥有近10亿个三元组的非公开图谱上，统计检查器捕捉到了什么、又错误标记了什么。结果相当冷峻。按公开原样使用的精编模式，有时会与自身数据相矛盾。在UniProt上，精编本体比另外两种方式更多地把正确答案标记为错误。在真实智能体回答上，这些标记的准确度仅略高于随机标记。

把两股趋势放在一起看，信息很明确。本体可用于为智能体的回答和行为提供依据。但效果取决于该本体是否被持续管理、与当前数据保持一致。仅凭花大价钱精编这一事实，并不能使其成为好的裁判。

虚与实的首要判断标准：这是需要本体的问题吗

Thoughtworks的文章（w3）认为，第一个决定应该是“诊断”，而不是“抱负”。要问的不是“是否想拥有本体”，而是“解决眼前这个问题所需的最小语义结构是什么”。该文认为，大多数组织都试图攀升到超出实际需要的层级。仅靠管理良好的语义层和规范的元数据，就能获得分析和检索中相当一部分价值。本体物有所值的场景更窄：需要跨越多步推理的问题、约束条件的自动检查，以及扁平模型无法表达的多领域整合。

可以把判断用的问题归纳为五个。第一，业务部门能否写出当前系统无法回答的具体问题（能力问题）？该文建议把这份问题清单作为拨付预算的关口，并为每个问题关联决策或金额。如果业务部门提不出问题，那不是缺少语义结构，而是价值不明确。第二，要得到答案，是否需要沿着跨越多个概念的关系追溯，还是只需统一“销售额”的定义？若是后者，语义层或整理良好的表格就足够了。第三，是否需要机器核查不得违反的规则？如果是，就必须连同实际执行这种核查的执行器或策略引擎一起设计。第四，LLM是否不熟悉该领域？正如企业智能体研究（paper）的结果所示，越是公司内部特有的术语或本地化领域，本体的效果可能越大。第五，是否有负责人，事先明确术语变更时由谁决定、多久与源系统同步一次（w3）？

也指出几个常见错误：试图一次性为整个公司建模；以为LLM生成了初稿，维护问题也就解决了；认为引入了本体就有了护栏；照单全收精编本体的检查结果。最后一个错误正如检查器研究（paper）所警告的，可能产生让智能体去“修改”正确答案的反效果。

延伸学习，以及第2篇

如果是初次接触，建议先读 Thoughtworks 的文章（w3）。从模式（schema）到知识图谱的连续谱、本体项目失败的原因、如何像产品一样对待本体，都集中在这一篇里。如果对标准感兴趣，可以依次看 RDF 入门（w2）中的三元组示例和 OWL 2 概述（w1）中的结构说明。研究方面建议按以下顺序阅读。首先通过 LLM 与知识图谱路线图（paper）把握全局。接着通过 OG-RAG（paper）和企业智能体研究（paper）了解检索与行动约束在实践中如何设计。最后通过检查器研究（paper）取得平衡。

本篇的结论是：本体作为“框架”仍然有用，但其价值来自用真实数据填充并持续校准的运营。那么，接下来的问题是：如果不让本体停留在静态的知识地图，而是把它做成在数据之上执行审批、分配、订单变更等实际业务行动的运营层，会有什么不同？届时维护与责任问题会得到解决，还是会更加沉重？第 2 篇将围绕这些问题，考察 Palantir 如何把本体转变为“在数据之上叠加行动的运营层”。