面向 AI 智能体的可移植业务本体

如今，“本体”一词正流行起来。为什么？智能体及其背后的大语言模型（LLM）都需要相关的业务背景信息。

在决定采用某种本体之前，不妨问供应商：“如果本体对我们的业务理解有误，我们的员工该如何纠正？又有哪些方面仍然依赖你们？”答案能让你充分了解，购买的究竟是谁构建的业务模型。这也揭示了更大的利害关系：随着业务变化，你能否持续改进这个模型；即使更换平台，这项投入能否继续发挥作用。

尽管本体与知识图谱往往有所重叠，区分二者仍会有所帮助。

本体：定义存在哪些事物、关系意味着什么，以及适用哪些规则。设备、部件、团队、角色、流程。例如，本体可以定义“设备”这一类型，以及与“部件”相关的“包含”关系。随后，知识图谱便可以断言：“泵 P-101 包含密封件 S-7”：其中有两个具体实体及其关系。

设想你对智能体说：“计算同店销售额增长率，但请并列展示两种结果：一种涵盖所有门店，另一种排除开业未满 2 年的门店；然后把两种结果分别细分为国内、国际和合计。”

这个请求依赖一些智能体无法自行猜出的细节：

• 有哪些门店，以及它们何时开业
• 它们位于何处
• “同店销售额”的内部定义

一项政策可能规定，门店开业满一年后才能纳入统计；而你要求的两年分组则进一步增加了一项筛选条件。即便如此，门店符合条件后，是立即按日历月进行比较，还是要等到完整度过上一财年后才纳入？

本体需要将这些门店与适用于该项计算的政策关联起来。找到相关事实固然有帮助，但只有应用正确的规则，答案才真正有用。

智能体可以在回答问题之前，利用图谱中的关系检索相关背景信息。知识领域很容易变得极其复杂，因此智能体确实能派上用场。

图 1：图示：合并后的公开 SysML 模型：TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0)、CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0)、Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause)，以及虚构的 MDC 星座内容和公开规范（IS-GPS-200、IS-GPS-705、GSFC-STD-7000B）。使用 Kamiwaza Kaizen 渲染。

但抽取过程也可能把错误写入图谱。团队可能会用不同的名称指代同一个实体，从而造成重复。不同来源的信息可能彼此矛盾，也可能已经过时。即使来源干净无误，LLM 也可能误读。把这些错误包装得煞有介事，并不会降低它们的危险性。

当业务模型变成一个能够对业务采取行动的系统时，这些风险会进一步加剧。错误的关系可能会触发错误的操作，而不只是给出错误的答案。

本体产品的风险

首先，要警惕缺乏灵活性的模型。供应商可能打着“开箱即用”的旗号，将自有实体设为一等公民，却限制你能用自己的实体做什么。如果自定义类型无法使用搜索、验证或操作功能，那么仅仅能够自定义并不足够。

其次，要关注从发现到治理的实现路径。工具应当允许你根据 LLM 发现的内容快速搭建图谱，再依据明确的约束对其进行验证。你应该能够将例外情况上报给相关人员，并保留探索过程中获得的知识，而不把这些知识当作已获批准的业务数据。

最大的风险，是让业务流程依赖一个你无法脱离的平台。本体代表着你的业务：其中的知识、流程和关系。即使更换工具，你在整理知识和构建业务逻辑方面的投入也应继续发挥作用。供应商凭什么能把这些成果锁起来？

图嵌入的作用

随着知识图谱不断扩大，选择一款或一家支持图嵌入的工具或供应商，或许值得考虑。图嵌入与许多 RAG 应用所依赖的语义嵌入十分相似。值得考虑的优势有两项。

首先，在连接密集的图谱中，只需经过几跳，就可能得到过多待处理的实体。嵌入通过学习实体及其关系的数值表示，提供了另一种查找图谱中相关部分的方法。对于合适的任务，这种方法可能比遍历图谱更高效。

其次，嵌入模型可以对可能缺失的关系候选项进行排序。同一学习过程还可以揭示某类实体通常具有的属性和关系模式，从而帮助构建更完整的图谱。

循序渐进、持续改进的理由

要掌握自己的命运、避免被供应商锁定，并根据真实业务建模，而不是接受供应商强加的失真版本，如果没有一支大规模的前沿部署工程师团队，该如何起步？我认为，只要工具支持从发现到验证的路径，现代 AI 就能在这方面大显身手。

首先，利用自动化工具发现并提取信息。你可以从业务文档、政策文件、电子邮件或 Slack 消息中，构建对某个领域的初步认识。关键在于，在经过核实之前，不能认定这些信息准确无误。

核实是第二个环节。你的工具必须提供顺畅的流程，让提取出的候选信息逐步转化为有来源依据的主张，并成为经负责人或权威系统验证的知识。每项主张都要保留其来源。

确保信息保持最新是一项持续工作。处理故障工单的流程，或“新泽西州有多少家门店”这个问题的答案，今天可能已与 3 年前不同。但更新当前知识时，不能抹去过去的实际情况。事实的记录时间与其适用时间可能并不一致；实用的本体需要既能支持当前答案，也能准确呈现历史情况。仍然需要有人持续更新这些知识。

范围可能非常庞大。可以先从较小的语料库入手，梳理一个实用的领域，并在逐步创造价值的同时，逐渐构建全面的全景图。

客户支持是一个有用的切入领域，涵盖来电、电子邮件、工单系统、自动解决方案、能够回应客户的支持团队，以及将真正的程序缺陷升级给工程团队的途径。它将知识与行动连接起来，并在一个范围可控的领域中展现同样的风险与回报。

ServiceNow 的通用服务数据模型说明了这一限制。其CSDM 5 白皮书警告说：“如果这些数据没有存储在指定的表中，你可能无法充分发挥 ServiceNow AI Platform 的全部价值。”这项警告本身就带来了设计和运营上的限制：要么采用供应商的模型，要么承担风险。如果这意味着非要把圆钉塞进对方的方孔里呢？

现在假设某个本体平台还提供数据摄取、转换、操作和业务规则。你或许可以导出实体、属性和关系。但你能否同时迁移转换流程和操作管道——它们会在数据库中执行更改、调用 Webhook，并产生其他副作用？集成若紧密耦合，企业本身就可能被锁定在该平台上。

为何灵活性在当下至关重要

软件正在吞噬世界，而 AI 正在吞噬软件。随着团队既用 AI 构建软件，也用 AI 为软件提供动力，越来越多的业务逻辑可能会与这些平台绑定。每项实用的自动化也可能成为另一项迁移依赖。让供应商挡在你与敏捷性之间，是危险的做法。

结论

这是一个令人惊叹的时代！人们纷纷探索本体，为智能体提供上下文，这不足为奇。将这些上下文延伸到流程和集成中，能够创造真正的价值。回到开篇提出的问题：员工的修正应当让模型更准确地反映你的业务。积累起来的这些认知太有价值了，不应在更换平台时被困在旧平台上。而现在也正是一个很容易让自己陷入困境的时代。