AI 智能体的可移植业务本体：如何避免厂商锁定

“本体”这个词如今很流行。为什么？因为智能体以及驱动它们的 LLM 需要相关的业务上下文。

在决定采用某个本体之前，先问问供应商：“当本体把我们的业务理解错了，我们的人该如何纠正——还有哪些部分仍然依赖你们？”这个答案会告诉你很多关于你正在买入的是谁的业务模型。它也指向更大的利害关系：随着业务变化，你改进该模型的能力，以及在你更换平台时让这笔投资继续有用的能力。

区分本体和知识图谱会有所帮助，尽管两者常常重叠。

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

想象你对一个智能体说：“计算同店销售增长，但要并排展示：一边显示所有门店，另一边排除开业不足 2 年的门店；然后把两边都拆分为国内、国际和合计。”

这个请求依赖于智能体无法猜测的细节：

存在哪些门店、它们何时开业

它们位于何处

“同店销售”的内部定义

某项政策可能会排除开业未满一年的门店；所要求的两年分组又增加了一层筛选。即便如此，你是在门店一符合条件就按日历月比较，还是只有在完整的上一个财年之后才将其纳入？

本体需要把这些门店与管辖该计算的政策连接起来。找到相关事实有帮助；应用正确的规则才能让答案有用。

智能体可以利用图中的关系，在回答问题之前检索相关上下文。难怪它们有用，因为知识领域很容易变得非常复杂。

但抽取也可能把错误编码进去。团队可能对同一实体使用不同名称，从而产生重复项。来源可能相互矛盾或变得过时。即使是干净的来源，也可能被 LLM 误读。让这些错误看起来权威，并不会让它们变得不那么危险。

当业务模型变成一个据此行动的系统时，这些风险会增大。错误的关系可能触发错误的行动，而不只是错误的答案。

本体产品的风险

首先，要警惕不灵活的模型。以“开箱即用”为名，供应商可能把自己的实体设为一等公民，同时限制你的实体能做什么。如果自定义类型失去搜索、验证或行动能力，那么可定制性就不够。

其次，寻找一条从发现到治理的路径。工具应当让你能从 LLM 所看到的内容引导出一个图，然后依据明确的约束对其进行验证。你应当能够把例外升级给人员，并在不把探索性知识当作已批准业务数据的前提下保留它。

最大的风险是把业务流程绑定在你无法离开的平台上。你的本体代表你的业务：它的知识、流程和关系。即使你更换工具，在策展和业务逻辑上的这笔投资也应当继续有用。为什么供应商有权把它锁起来？

图嵌入在哪些方面有帮助

随着知识图谱变得非常庞大，选择一个支持图嵌入的工具或供应商可能是值得的。图嵌入与驱动许多 RAG 应用的语义嵌入是近亲。有两个有用的好处值得考虑。

首先，在密集连接的图中走几跳，可能产生太多实体而无法处理。通过学习实体和关系的数值表示，嵌入提供了另一种找到图中相关部分的方法。对于合适的任务，这可能比遍历图更高效。

其次，嵌入模型可以对候选的缺失关系进行排序。同样的学习可以揭示某一实体类型典型的属性和关系模式，帮助构建更完整的图。

渐进改进的理由

为了掌握自己的命运、避免锁定，并建模你真实的业务而不是供应商口述的漫画式版本，在没有一支前置部署工程师大军的情况下，你该如何开始？我认为，如果工具支持一条从发现到验证的路径，现代 AI 正是在这里大放异彩。

首先，使用自动发现和抽取。从业务文档、政策、电子邮件或 Slack 消息中，你可以构建某个领域的初始视图。关键之处在于，在它得到验证之前，你不能信任它是准确的。

验证是第二部分。你的工具必须为你提供一条顺畅的路径，从抽取出的候选项到有来源依据的断言，再到由负责人或权威系统验证的知识。保留每个断言的来源。

保持新鲜度是持续的工作。处理故障工单的流程，或者“新泽西州有多少家门店”的答案，今天可能和三年前不一样。但更新今天的知识绝不能抹去昨天的现实。事实被记录的时间与它适用的时间可能不同；有用的本体需要同时支持当前答案和准确的历史视图。仍然必须有人让这些知识保持最新。

范围可能非常庞大。先从较小的语料库开始，梳理出一个有用的领域，逐步构建全面的图景，同时在此过程中创造价值。

客户支持是一个有用的切入点：呼入电话、电子邮件、工单系统、自动解决、能够响应客户的支持团队，以及将真正的缺陷升级到工程部门的路径。它将知识与行动连接起来，并在一个可控的领域中暴露出同样的风险与回报。

ServiceNow 的通用服务数据模型（Common Service Data Model）说明了这一约束。其 CSDM 5 白皮书警告称：“如果没有将这些数据放入规定的表中，你可能无法获得 ServiceNow AI 平台的完整价值。”这一警告本身就构成了一种设计与运营上的约束：要么顺应厂商的模型，要么承担风险。如果这意味着把你的圆钉硬塞进他们的方孔里呢？

现在假设某个本体平台还提供数据摄取、转换、操作和业务规则。你或许能够导出实体、属性和关系。但你是否也能移植那些在你的数据库中执行变更、调用 webhook 并产生其他副作用的转换和操作流水线？紧密耦合的集成可能让业务本身陷入锁定。

为什么灵活性在当下至关重要

软件正在吞噬世界，而 AI 正在吞噬软件。随着团队既使用 AI 来构建软件，又用它来驱动软件，越来越多的业务逻辑可能与这些平台绑定。每一个有用的自动化也可能成为又一个迁移依赖。让厂商横亘在你与敏捷性之间是危险的。

结论

能生活在这样一个时代真是太棒了！难怪人们正在探索用本体为智能体提供上下文。将这种上下文延伸到流程和集成中可以创造真正的价值。回到开头那个问题。你的团队所做的修正应当让模型更好地反映你的业务。这种积累起来的理解太过宝贵，不应在你更换平台时被搁置。而现在也是一个糟糕的时机，让自己陷入无路可退的困境。