当每个平台都在定义“客户”：比数据孤岛更危险的，是语义孤岛

多年来，企业一直在与碎片化的数据作斗争。如今，它们又面临另一种碎片化，而这种碎片化对 AI 时代可能更具深远影响：碎片化的含义。

在整个数据与技术领域，各平台正在大力投资语义能力。数据平台、分析环境、业务应用和 AI 技术越来越希望更丰富地理解企业数据所代表的内容：客户、产品、收入、风险、员工、资产，以及它们之间的关系。

这是一个积极的发展。语义之所以变得越来越重要，正是因为现代分析与 AI 无法仅靠技术数据结构可靠运行。知道一个字段叫 CUST_ID、另一个字段包含货币值、两张表可以连接，并不等同于理解“客户”是什么、适用哪一种收入定义，或者某个特定关系对业务意味着什么。

但语义日益重要，也带来了一个新的架构问题：当每一个主流平台都有自己的业务含义版本时，会发生什么？语义之战正是从这里开始。

人们很容易把新兴市场框定为又一场平台之战：哪个厂商将建立主导性的语义层？哪个环境将成为企业业务含义的来源？分析应用和 AI 智能体将采用哪个平台的定义？

但这种框架误解了大多数大型企业的实际运作方式。未来企业不太可能只有一个语义环境，它会拥有许多个：

而且，组织很少会在所有这些领域都标准化到单一技术平台，因此，挑战未必是选择那个会胜出的语义层，而是确定当多个语义世界共存时，企业如何继续运作。

这很重要，因为语义碎片化比数据碎片化更难被发现。

当信息位于两个不同数据库时，分隔显而易见；两个平台暴露相同的底层信息，却对其做出不同解释时，问题可能一直隐藏，直到有人——或者越来越多是某个 AI 系统——试图据此做出决策。

以看似直截了当的“客户”为例：

对某个系统而言，客户可能是个人账户持有人；对另一个系统而言，可能是法律实体；再换一个系统，可能是家庭。销售平台可能根据商业关系定义客户，财务可能根据账单状态定义客户，而风险部门可能又有另一种定义。

这些定义未必有错，它们在各自语境中可能完全合适。问题始于企业级流程、分析应用或 AI 智能体需要跨这些定义运作时。

同样的情况也适用于收入、产品、员工、供应商、资产、风险敞口、索赔、公民、患者或风险等概念。

如果每个平台都更擅长在本地定义含义，而企业在全局协调含义方面却更差，那么我们并没有消除孤岛。

我们只是把孤岛边界从数据转移到了语义。

即使没有 AI，这一点也很重要。有了 AI，它就变得更加重要。传统分析通常会在解释过程中安排一个人，经验丰富的分析师可能识别出两份报告使用了不同的收入定义，或者“客户”在两个应用中含义不同。

AI 系统和自主智能体越来越多地在没有这种隐性人工协调的情况下运作。一个 AI 模型可能在语言和推理方面极其强大，却仍然被喂给它相互矛盾的企业表征。

模型无法天然知道哪个定义对某项特定决策具有权威性。它可能不知道一个语义模型反映监管报告，另一个反映运营报告，还有一个反映商业视图。它可能不理解哪个定义适用于这个用户、这个工作流、这个地域或这个时刻。

而且，给模型更多语义信息并不一定能解决这个问题。正如更多上下文并不自动等于正确的上下文，更多语义也并不自动等于共享含义。

谁的含义适用——针对这项决策、在这个业务语境中、就在此刻？这与单纯创建一个语义层是根本不同的问题。

这还有另一个维度。语义模型不只是描述数据，它们越来越多地影响人和 AI 如何解读企业。这使得对语义的控制具有战略重要性。

如果某个技术平台为其所支撑的 AI 系统定义概念、关系和业务规则，那么该平台所做的就不只是存储或处理信息，它正在影响这些系统如何理解业务，这就是为什么组织应开始思考语义主权。

这里的主权并不是说每个企业都必须构建一个庞大的专有语义模型。相反，组织需要保留这种能力：确定哪些含义具有权威性，协调不同语义环境之间的差异，并避免企业理解被恰好承载某一工作负载的技术所支配。

因此，语义层正在成为企业架构中的一个新控制点，而语义之战并非真正是厂商之间的战斗，它是一场关于业务含义存在于何处、由谁控制，以及如何在整个企业中流转的战斗。

对语义碎片化有一个显而易见的回应：再创建一个企业语义层，并要求其他一切向它看齐。对某些组织和领域而言，更高程度的标准化当然有价值。

但用一个新语义帝国取代多个语义孤岛，可能只是重复企业在数据领域已经遇到过的架构模式。

大型组织之所以异构，有其充分理由。不同平台服务不同工作负载，不同领域拥有不同专业知识。并购引入不同架构，监管要求各不相同，合作伙伴和生态体系在企业直接控制之外运作。

因此，更现实的目标未必是消除语义多样性，而是让这种多样性实现互操作。这意味着能够连接定义、协调关系、理解溯源、确立权威，并在业务含义已经存在的各个环境中呈现一致的业务含义。换言之：在合理之处保留本地语义，在企业需要之处形成共享理解。

仅靠语义所能提供的东西也有局限。语义可以告诉 AI 系统某事物意味着什么。但一项重要的企业决策还可能取决于关系、历史、当前状态、溯源、策略、权限和业务规则。

知道“客户”意味着什么很有用。但知道这位客户刚刚更改地址、持有三款产品、受到特定监管处理、存在未解决的欺诈警报，并且正通过具有特定权限的渠道交互，可能才是真正决定何为适当决策的因素。

这就是语义含义与决策相关理解之间的区别。

在 Denodo，我们用 Active Context（动态上下文）这一术语，来指代为特定决策或行动，将相关数据与其含义、关系、溯源、策略和当前状态汇聚在一起。因此，演进路径变为：分布式数据 → 共享数据 → 共享语义 → Active Context（主动上下文）→ 业务理解 → 决策。

语义至关重要，但它们不是旅程的终点。

这一区分对 Denodo 尤其重要。我们的立场不应是：组织必须放弃其现有平台的语义能力，并用我们的能力取而代之。那会让我们陷入我们认为企业需要超越的那种平台之战。

更有价值的角色，是帮助组织跨异构语义环境连接、协调并运营化含义。企业可能在云平台、分析环境、应用、数据产品和领域架构中都拥有语义。这些投资不应被迫消失。

但当应用、分析师或 AI 智能体需要跨这些边界运作时，组织需要一种方式来创建连贯的共享理解。这正是逻辑方法尤其相关之处。

企业不必要求所有数据和含义先迁移到另一个物理平台，而可以跨分布式来源和语义环境建立一个受治理层，既保留本地投资，又能在需要之处提供共享含义。

归根结底，这不是为了架构而架构的辩论。当不同语义环境对同一个企业问题给出不同答案时，它就变成了业务问题：

• 我们对这位客户的风险敞口是多少？

• 这款产品的盈利能力如何？

• 哪些供应商使这项运营面临风险？

• 这位公民是否有资格获得这项服务？

• 这位患者的完整情况告诉我们什么？

如果多个系统因为各自基于不同的语义世界观运作，而能给出多个技术上站得住脚的答案，那么企业就存在共享理解问题。

AI 会更快暴露这个问题，因为 AI 越来越多地跨越那些过去容纳不同含义的组织和技术边界，这就是为什么语义互操作性现在就需要成为企业 AI 架构讨论的一部分。

每个主要平台都有充分理由让自己的环境更具语义智能，企业应当利用这些能力，但它们也应认识到其架构后果。

随着语义不断扩散，企业理解正成为一个跨平台问题，因此，战略问题不是“我们应该把企业押注在哪个语义层上”，而是“我们如何在保留不同语义环境价值的同时，创造足够的共享含义，让人、应用和 AI 能够一致地理解企业”。

解决这一问题的组织，未必是赢得语义之战的组织，而是那些不再需要选择赢家的组织。

我们如何在保留不同语义环境价值的同时，创造足够的共享含义，让人、应用和 AI 能够一致地理解企业？