AI 语义层正成为企业 AI 的基础

Google News 本周突出了一项鲜明论断：AI 语义层正成为企业 AI 的基础，而非又一种可有可无的数据工具。HPCwire 的一篇文章提出了这一观点，并对塑造了许多早期生成式 AI 项目的“模型优先”策略发起挑战。

争议已不再是谁的大语言模型能写出最佳答案，而是任何模型是否真正理解企业对客户、营收、库存、风险或审批的定义。若缺乏一致定义，代理即使能生成流畅的分析，也可能使用错误的指标、关系或访问规则。

Google、Microsoft、Snowflake、Salesforce 以及数据平台厂商，正逐渐趋向同一种架构答案的不同版本：在原始企业系统与 AI 应用之间设置一个受治理的层。不过，它们彼此竞争的实现方式也带来了第二个问题：这一共享的含义来源，同样可能成为新的控制点。

Google News 放大的是架构转变，而非产品发布

重要变化在于，语义技术已从分析基础设施走向企业 AI 战略的核心。

通过 Google News 发布的 HPCwire 标题，并未宣布某一项收购、融资轮次或产品发布。它捕捉到的是已在主要企业平台中显现的更广泛变化。

语义层是以人类和机器都能理解的方式，对业务数据进行受治理表述的一层。它在承载底层记录的物理数据库之上，定义指标、实体、关系、权限和规则。

这听起来并不陌生，因为语义模型多年来一直支持商业智能。销售仪表盘需要对年度经常性收入达成一致定义，AI 助手同样如此。区别在于，定义出错所造成的后果不同。

仪表盘通常只是向人展示信息，以供检查。AI 代理则可以解读这些信息、选择工具、生成查询并发起行动。因此，含义模糊不再只是报告问题，而会演变为运营风险。

设想一个请求：识别具有高价值且存在流失风险的客户。原始语言模型必须推断“高价值”“客户”“风险”和“流失”在该公司内部的具体含义。这些术语可能取决于合同状态、已确认收入、产品活跃度、地域或法律排除项。

模型可以写出有效的 SQL，却仍然回答了错误的问题。它可能将试用账户计为客户，或用预订额代替已确认收入。一段润色精美的说明，并不会揭示这些隐藏的替换。

语义层缩小了这种解释空间。它将业务术语与经批准的数据、计算方式、关系和政策连接起来。代理随后查询的是受管理的表述，而不是直接在数千张表和列之上即兴发挥。

这正是当前讨论超越搜索质量的原因。企业 AI 正从检索文档，转向跨结构化记录、实时运营数据和内部知识进行推理。每增加一个来源，彼此冲突的定义就会更多。

个人和团队知识系统中也存在同样的问题。一个有用的 AI knowledge base 必须在文档之间保留上下文，而不能将每个段落视为孤立事实。企业语义系统则将这一原则应用于受治理的数据和运营决策。

Google News 让这一论点获得更广泛关注，但其背后的转变是具体可见的。厂商正将成熟的指标层、本体和知识图谱转化为代理的事实锚定系统。这一变化给所有承诺可靠企业自动化的公司带来压力。

企业 AI 所需的是含义，而非又一个模型

模型质量依然重要，但企业 AI 的失败日益源于缺失的业务上下文，而非语言生成能力不足。

大语言模型从广泛数据集中学习通用模式。它们并不会天生知道，某家公司将“活跃订阅用户”定义为付款结清之后的状态。它们也不知道哪个系统拥有该状态的最终归属权。

检索增强生成（RAG）可在请求过程中提供相关文档，从而有所帮助。然而，一份检索到的政策文件，并不会自动协调相互冲突的记录，或执行某项指标的批准定义。

语义层解决的是问题的另一部分。它表述概念之间如何关联、哪些计算有效，以及权威数据位于何处。本体则通过明确的实体、属性、关系和约束，进一步扩展这种结构。

在供应链场景中，这一区别十分清楚。一个被问及延迟发货情况的代理，可能检索到承运商邮件和仓库记录，但它仍需了解订单、路线、设施、供应商和服务承诺之间的关系。

受治理的模型可在问题提出之前建立这些关系。代理无需在每次请求时都重新构建公司的运营逻辑，也更少有机会编造看似合理的联系。

MIT 信息系统研究中心将语义层定义为一种为人类和机器维持一致数据表述的技术。其 2026 年语义层简报指出，随着 AI 项目的扩展，领导者正面临加大投资的压力。

这种压力来自多个方向。数据团队必须支持更多对话式界面，安全团队则需要一致的控制措施。业务负责人也希望 AI 的回答与获批报告保持一致。

当代理必须跨越不同团队构建的系统运行时，开发人员同样感受到压力。计费平台中的客户标识符，可能与支持系统中的标识符并不一致。代理需要两者之间可靠的映射关系。

企业买家也面临相关考验。当演示仅覆盖经过精心准备示例的狭窄数据集时，效果可能颇具说服力。生产环境会暴露术语冲突、数据血缘缺失、模式变化以及权限不一致等问题。

语义层承诺将这些依赖关系显式化。它可以为代理提供可复用的度量、维度、层级和关系定义，也能保留从答案回溯至受治理来源的连接。

Google 曾将 Looker 的语义模型定位为生成式 AI 的业务上下文来源。在 2025 年的一篇 Looker 分析中，该公司表示，内部测试将自然语言查询中的数据错误最多减少了三分之二。

这一数字是公司自行报告的结果，并非独立的行业基准。它仍说明了厂商如今希望买家考察的指标：关键不仅在于代理能否作答，还在于它是否能一致地应用获批逻辑。

这一转变也给模型提供商和数据平台公司带来压力。更好的模型可以在演示中掩盖薄弱的事实锚定，但它无法独立裁定组织内部对利润、客户或合规风险敞口存在争议的定义。

企业必须自行提供这些含义。厂商可以提供建模工具，但业务负责人必须决定哪些定义具有权威性。这项组织层面的工作，比连接另一个模型端点更困难。

AI 语义层正成为代理控制平面

更深层的机制是确定性的事实锚定：代理在查询数据或建议行动之前，先参考受治理的业务含义。

“语义层”这一术语涵盖多种相关设计。传统系统聚焦可复用的业务指标和维度；较新的方法则加入本体、知识图谱、非结构化上下文、政策规则以及面向代理的接口。

它们的共同目标，是将业务意图与物理存储分离。员工询问的是客户留存，而非数据仓库表中的某一个列。语义层将该意图转换为获批准的数据操作。

这种分离十分重要，因为企业系统始终在变化。表会迁移，应用会被替换，团队会重命名字段。在工程师更新底层绑定关系的同时，稳定的业务概念仍可继续使用。

对于 AI 代理而言，这一层可作为控制平面。它告知代理存在哪些概念、这些概念如何关联、允许哪些操作，以及支持性证据来自何处。模型仍负责解读请求，但不再自行编造运营规则。

Microsoft 的 Fabric IQ 展示了这一模式如何进入主流平台。其本体通过实体、属性、关系和约束来表述企业术语。这些概念随后可绑定至存储在 OneLake 各类来源中的记录。

Microsoft 还通过 Model Context Protocol（MCP）开放本体能力。MCP 是一种标准接口，AI 系统可借此发现并使用外部工具。当前的本体 MCP 文档描述了实体发现和自然语言查询。

这一接口连接了此前彼此分离的两层。MCP 提供工具连接，而本体提供工具背后的受治理含义。因此，代理获得的不只是另一个数据库端点。

这种方法也改变了自然语言转 SQL 系统。传统实现会让模型检查模式并生成查询。大型企业模式使这一过程变得困难，因为名称往往晦涩，关系也很少显而易见。

一篇 2026 年研究论文在 Spider2-snow 基准测试中测试了一个语义模型中介层。该系统先生成紧凑的语义查询，再将其编译为针对特定数据库的 SQL。报告的基准测试结果在 547 项任务中达到 94.15% 的执行准确率。

这些结果来自单一研究实现，并不能证明通用的生产环境表现。它们支持这样一种架构论点：应在执行前约束模型的选择。编译器可以强制执行自由形式 SQL 生成器可能忽略的关系。

控制平面的理念也延伸至非结构化知识。政策、会议记录、技术文档和客户研究中包含的上下文，从不会出现在指标存储中。企业需要将这些材料与受治理的实体和决策关联起来的方法。

这种关联类似于知识融合：检索到的材料在为综合答案作出贡献时，仍保留其来源上下文。一个 knowledge blending 工作流可以帮助个人综合分散信息。企业层则进一步加入正式的归属、访问控制和共享定义。

一个实用的智能体可能会先通过本体解析出某位客户。随后，它可以检索该客户已获批准的营收指标、未结支持工单以及相关合同条款。每一步都会使用明确的关系，而不是猜测性的关联。

这种机制可以减少 token 使用量，因为模型接收到的是更小且相关的信息表示。它也能提高可审计性，因为系统会记录哪些定义和来源影响了答案。

不过，语义并不能消除概率性推理。语言模型仍可能误解请求，或未能妥善概述证据。这一层会约束数据访问与解读，但不会让每个输出都变得确定无疑。

因此，最强的架构会将受治理的语义与验证机制结合起来。高影响操作应检查权限、验证输入、预览影响并记录结果。当错误可能带来财务或法律后果时，人工审批仍然是合适的做法。

Google、Microsoft 与开放标准正在争夺意义层

核心竞争在于共享语义互操作性与平台专属业务上下文之间的较量。

当企业以某个主要数据平台偏好的模型编码业务含义时，该平台都会从中受益。由于报表、智能体和工作流都依赖这些定义，平台的价值会随之提升，迁移离开的难度也会增加。

Google 已拥有 LookML，这是 Looker 背后的建模语言。它让团队能够在底层数据之上定义维度、指标、连接关系和访问规则。Google 目前正将这一既有层定位为生成式 AI 与智能体工作流的基础支撑。

Microsoft 正从 Power BI 语义模型扩展至本体、图谱、运营型智能体和 MCP 访问。其战略是将业务含义连接到更广泛的 Fabric 与 Microsoft 365 环境中。许多新增本体功能仍处于预览阶段。

Snowflake 和 Salesforce 则通过 Open Semantic Interchange 倡议推动了更具互操作性的方向。BlackRock、dbt Labs 和 RelationalAI 加入了这项于 2025 年宣布的工作。

该倡议旨在标准化指标、维度、层级结构和关系的交换。Snowflake 将该项目描述为厂商中立，其核心原则包括领域专用模型和可扩展性。

这正是本故事中的核心对手。企业可以采用可在工具之间流转的共享语义框架，也可以接受与原生集成更深的平台专属层。到目前为止，两条路线都还没有给出完整答案。

专有系统能够在单一平台内部提供更紧密的性能、治理和用户体验。它可能以更少的定制工程工作，将现有仪表板连接至 AI 智能体。代价是对该平台的概念与接口形成依赖。

开放交换模型可以减少分析工具之间的重复建设。它也可以避免每个智能体平台以不同方式翻译业务定义。然而，标准只有在厂商以足够一致的方式实现时才能成功。

定义所包含的不只是语法。两个平台可以交换“净营收”这一标签，却采用不同的确认时点规则、货币处理方式和排除项。互操作性要求含义、数据血缘和约束条件都能被保留。

这也是企业所有权至关重要的原因。厂商可以托管语义模型，但财务部门必须批准营收定义。运营部门必须定义发货状态，法务团队则必须决定哪项政策应控制自动化操作。

随着模型扩展，维护负担也会增加。新产品会引入实体，收购会带来不兼容的系统，区域性规则会产生例外。若语义层落后于业务，它就会成为一个自信却陈旧的含义来源。

Google News 的报道可能会让这一类别看起来仿佛已尘埃落定，而相关治理问题其实尚未解决。基础设施的比喻很有用，但基础设施需要持续检查。它们不会仅仅因为厂商将其标记为语义层就变得值得信赖。

因此，买方应将可移植性与功能一并评估。定义能否以可用形式导出？另一款智能体能否通过有文档说明的接口查询它们？当数据跨越平台边界时，访问规则能否得以保留？

他们还应区分指标模型与更广泛的运营本体。面向仪表板的层可以一致地计算营收，却未必能表示合同、供应商、设施或审批链。智能体工作流通常既需要计算，也需要关系。

能够连接这些要素、又不把客户锁定在自身平台中的厂商将获得优势。最可能的赢家将同时支持受治理的建模、开放接口和可观测执行。仅凭一个强大的模型无法决定这场竞争。

信任问题转向治理

语义层可以减少歧义，但也可能将错误固化，并传播到每一个相连的 AI 系统中。

集中管理业务含义会带来杠杆效应。修正一个获批准的定义，每个仪表板或智能体都可以继承这一修正。批准了错误定义，同样的系统也会以更大规模重复该错误。

这是反对将 AI 语义层视为自动化基础的最有力怀疑论观点。该技术本身并不会发现组织真相。它记录的是由个人、团队和自动化建模系统作出的决策。

许多企业并没有为关键概念指定单一负责人。销售、财务和客户成功团队可能各自以不同方式定义活跃客户。选择其中一种定义，可能会成为政治决策，而非技术清理工作。

有些差异是合理的。财务可能需要已确认营收视图，而产品团队需要基于活动的视图。一个有用的层必须保留这些上下文，同时不能让智能体在其中悄然自行选择。

时效性带来另一项风险。本体可能准确描述上一季度的流程，却遗漏新引入的产品或控制措施。智能体需要版本管理和生效日期，而不是永恒不变的标签。

权限同样重要。理解某位员工与一条薪酬记录有关联，并不意味着有权访问该记录。语义关系必须在既有安全与隐私控制之下运行。

Microsoft 的本体文档展示了一个受治理的共享模型，但若干相关功能仍处于预览阶段。预览状态意味着接口、限制和运营保障可能发生变化。买方不应将路线图语言视为生产环境证据。

Google 所报告的错误减少同样需要谨慎解读。自然语言查询的准确性取决于数据集、评估方法、模型以及对错误的定义。内部测试得出的百分比无法预测其在每个企业中的表现。

2026 年 SQL 基准测试也有类似边界。在 547 项受控任务上的执行准确率，并不能衡量权限失败、陈旧定义或组织内部意见分歧。生产环境评估必须涵盖这些失败模式。

成本是另一个尚未解决的问题。构建有用的语义模型需要领域专家、数据工程师、治理人员和应用所有者。自动化提取可以加快初稿形成，但专家仍需验证关系和规则。

规模最大的公司可能能够承担这项投资，因为不一致的答案已经带来显著成本。较小组织可能更适合围绕其最高价值决策构建一个狭窄模型。试图为整个企业建模，可能会延迟可用成果的交付。

过度僵化也存在风险。随着团队试验新产品和运营模式，业务语言也会发生变化。如果每个临时概念都需要中央审批，一个高度受控的层可能会拖慢试验。

更好的设计是将稳定定义与探索性定义分开。智能体可以将经过认证的概念用于高影响决策，同时清晰标记实验性指标。接口应展示置信度、所有权和版本状态。

一旦智能体通过该层采取行动，可观测性便不可或缺。团队需要日志来展示所请求的概念、选定的定义、源数据、生成的查询、权限决策和最终操作。否则，治理仍只是一项架构承诺。

人工审核应聚焦于后果，而非每一项查询。只读摘要可以采用与付款审批或账户暂停不同的控制措施。语义支撑有助于实现这种区分，但必须由政策执行机制来落实。

当厂商发布超越精心策划演示的证据时，这一类别才会成熟。买方需要采用混乱的模式、冲突的定义、变化的数据和被拒绝的权限进行可重复评估。他们也需要失败报告，而不仅仅是平均准确率。

在此之前，最稳妥的结论是有条件的。只要定义保持受治理、及时、可移植和可观测，语义层就能提高企业 AI 的可靠性。缺失其中任何一种属性，都可能将错误上移，而非将其消除。

Google News 关注之后该关注什么

下一阶段将由互操作性、可量化的智能体准确性，以及对业务定义的持续所有权决定。

第一个信号是对开放语义交换的生产支持。关注 Google、Microsoft、Snowflake、Salesforce、dbt Labs 和其他厂商是否能在不丢失关系或治理元数据的情况下导入和导出定义。

更广泛的兼容性将强化这样一种判断：语义层正在成为共享的企业基础设施。有限的兼容性则表明，厂商正在以相似的语言构建彼此竞争的控制点。

细节比又一则合作公告更重要。买方应寻找指标、维度、层级结构、权限、数据血缘和生效日期的实际可用传输。缺少这些要素的通用标签，只能提供浅层可移植性。

第二个信号是对具备语义支撑的智能体进行独立评估。测试应在相同的企业任务上，对比原始模式访问、文档检索、指标模型和更丰富的本体。

有用的衡量指标包括查询准确率、政策违规、陈旧答案率、人工干预、延迟和总执行成本。评估还应测试：当获批准的业务含义或授权缺失时，智能体是否会拒绝请求。

不同模型之间持续一致的收益，将支持基础设施这一主张。若收益仅限于某家厂商准备的数据集，则会削弱这一主张。企业买方需要能够经受模式变化和定义冲突考验的结果。

第三个信号是组织采用情况。企业必须为重要概念指定负责人，并公布解决分歧的流程。没有这一运营模式的技术使用，只会以新名称制造语义债务。

关注有多少智能体部署会跨部门复用已批准的定义。复用比目录中录入的概念数量更能说明进展。它表明该层正在影响真实决策。

还要关注修正的频率。频繁的静默变更，可能使过去的智能体决策无法重建。带有可见负责人的版本化变更，则表明治理正在按设计运作。

对开发者而言，眼下应将模型推理与业务规则分离。将关键计算和关系保留在可检查的系统中。要求智能体为具有重要后果的答案引用所使用的定义。

企业买方应从一个边界明确的工作流开始。选择一个责任人明确、源系统已知且错误成本可衡量的决策。在扩展模型之前，先测试语义支撑是否能改善结果。

当 AI 的回答听起来斩钉截铁时，知识工作者应当提出一个更简单的问题：系统采用的是谁的定义？如果界面无法回答，那么流畅的表达正在承担比治理更多的工作。

Google News 的标题捕捉到了一个真实的架构转向，但其基础并不只是语义软件本身，而是共享含义、可问责的所有权、可执行的政策以及可见的证据的结合。

企业会建立这种运营纪律，还是会再购买一层系统，并期待模型替他们化解分歧？下一波部署应当让答案变得可衡量。