混乱是如何开始设想一个企业决策会议首席财务官要求人工智能系统提供按客户群体分类的收入数据。系统返回了三个不同的数字因为对于客户“这个概念CRM将其称为“账户”ERP系统将其称为“客户”而WMS系统则将其标记为”具体的客户名称“。这三个标签虽然不同但它们代表的是同一个概念。然而AI无法清晰地区分它们。这不是RAG检索失败。向量检索正确嵌入也匹配。问题出在上游人工智能根本不知道这三个标签指的是同一个现实世界的事物。这就是语义问题也是大多数人工智能部署性能不佳的根本原因。技术栈的每一层——模型、代理、编排——其可靠性都取决于其下方语义层的可靠性。如果对数据实际代表的含义缺乏共享且统一的理解那么你构建的就不是智能而是大规模地制造混乱。意义是与生俱来的在谷歌进入这个领域之前所有竞争对手都认同一个核心原则意义应该由组织内部有意识地创造。Palantir 指派专业工程师手动开发数字孪生模型。微软的 Fabric IQ 在你现有的基础架构上建立本体契约。而谷歌则提出了一种结构上截然不同的方案意义是一种与生俱来的东西。谷歌与其他企业语义层的主要区别在于它并非通过聘用特定领域的架构师来创造意义而是通过一个能够自动捕捉意义运作方式的学习模型。语义层应六大考量因素Google认为成功实现语义层需要考虑六个关键因素1.联结数据团队与业务团队能促使精通业务逻辑的领域专家与深谙数据分析底层数据的数据专家协同合作。多年来如何大规模地促成这两类专家之间的合作2.支持多个数据源能够跨越多个数据源这样当用户提出问题时不论结构化数据存于何处LLM 都能给出适当的回答3.轻松与更广泛的 AI 平台策略集成能够利用语义建模数据及非语义建模数据来解决问题并执行操作。例如能否通过模型上下文协议服务器公开其查询功能智能体能否轻松访问语义层的 API4.成为企业工作流的一部分确保语义层的范围不局限于孤立存在的对话式体验 并且分析洞见也不局限于对话本身5.适合企业级应用支持 VPC 服务控制等功能以进行边界防御支持客户管理的加密密钥以增强对敏感数据的控制支持专用 IP 连接以隔离流量还要能够确保数据安全与合规。6.驻留以满足监管要求确保针对语义层编写的所有 SQL 均为标准的非专有 SQL避免将逻辑嵌入特定工作簿。谷歌的语义层架构谷歌并非要求企业在构建自己的语义层和购买他人的语义层之间做出选择。它提出的方案是以数据创建的速度持续不断地从数据本身自动提取意义。Google语义层架构由三个相互协调的层组成。智能存储层整合多模态数据数据如PDF或图像进入Google Cloud Storage后自动完成实体解析和实体标记直接变成运行时可用的资产;知识引擎层吸收源头元数据与LookML 语义 借助 Gemini 深度理解多模态数据并自动构建术语体系提供亚秒级、带权限校验的混合检索;企业级AI代理层基于企业特定的语义以及谷歌十多年来开发的关系模型构建企业上下文。在这个架构中本体论如 Looker 中的 LookML 和企业专属定义的“有效合同”与具体的实体节点企业知识图谱共享同一个最高认知层。AI 代理不再需要分别去“查字典”和“找数据”而是直接通过这个持续更新的动态上下文层以人类理解业务的方式去理解现实世界中的结构化关系。谷歌语义层的三驾马车谷歌的语义层策略由三大核心组件支撑知识目录、Looker 语义建模平台与 OKF 开放知识格式。它们分别解决上下文治理、业务指标建模和知识表示标准化的问题。知识目录在2026年的Google Cloud Next大会上谷歌发布了知识目录并将其定位为“面向企业级人工智能的通用上下文引擎”。这种措辞刻意低调实则代表着一项意义重大的架构投入。知识目录是谷歌云专为AI智能体和企业数据治理推出的上下文引擎。它统一了格式化、非格式化和SaaS数据。知识目录并非传统意义上的数据目录它既不是术语表也不是元数据注册表或血缘追踪器。正如谷歌在主题演讲中所述知识目录构建了一个统一的、动态的整个业务上下文图使您能够将所有业务代理与所有业务数据和语义关联起来。知识目录主要功能包括自动收集BigQuery、AlloyDB、Looker等多个系统的信息整合上下文定义 AI 代理有效推理所需的关联和度量建立数据血缘和业务报表打造企业级的统一真实数据源通过API或MCP直接将元数据提供给AI智能体。LookerLooker是 Google Cloud 旗下的企业级商业智能、数据分析与数据建模平台。Looker 的核心定位是构建企业统一的“语义层”它将底层的复杂数据库与上层的业务分析、AI 应用隔离开确保全公司对数据指标拥有统一且受控的定义。Looker主要特性统一的指标层:Looker 的统一指标层确保所有部门的数据准确性和一致性支持多种数据源支持所有主要的云 数据仓库例如 BigQuery、Snowflake以及传统数据 库例如 Postgres、MySQL);LookML 建模语言LookML是Look建模语言Looker 可以使用以 LookML 编写的模型构建针对特定数据库的 SQL 查询通过 LookML 结构开发者可以为业务分析创建一个单一的整体模型;与可视化工具集成 :LookML 是企业级Looker AI 和 BI 平台的组成部分Looker 模型中定义的指标可在所有主流 BI 工具中使用包括Looker Studio、Microsoft Power BI、Tableau 和 ThoughtSpot 等可信的数据供应:Looker能够为整个AI生态系统提供受监管的数据基础。通过集中管理可信的业务逻辑和元数据LookML 可为各种 AI 接口提供一致的高质量输入。Looker的核心作用Looker 扮演着至关重要的语义和业务逻辑提供者的角色。包括元数据与语义提取知识目录支持直接从 Looker中自动提取技术元数据。统一的语义基础传统 AI 代理经常因为缺乏业务上下文而产生“幻觉”或给出错误信息。知识目录通过将 Looker 的核心LookML与 BigQuery 度量一起汇聚并整合。赋予 AI 代理业务理解力LookML 中定义了企业复杂的业务逻辑、维度和指标。知识目录将这些 LookML 逻辑转化为统一受控的语义基础使得上层的 AI 代理无需猜测即可准确理解诸如“什么是活跃用户”或“如何计算本季度利润”等业务定义从而高精度地执行复杂的业务查询。哪些企业更适合Looker有三种方案可用于开发和部署语义模型1.作为数据库的语义视图直接在数据仓库之上构建统一的指标与维度定义作为面向查询的虚拟抽象层。2.嵌入到 BI将语义模型内置于现有 BI 平台复用其治理体系与用户生态在统一环境中实现指标消费。3.独立的解决方案作为与具体 BI 工具解耦的独立语义层通过标准化 API 向多个应用提供跨平台的统一数据语义服务。嵌入到 BI 架构中的语义层能够在智能体企业所需的治理、执行和集成之间取得最佳平衡。Looker 是嵌入式 BI 方案中的理想之选。OKF作为知识目录的核心延伸Google发布了一个开源、厂商中立的文件格式规范OKFOpen Knowledge Format。OKF 是一个开放规范将知识表示为一个带有 YAML frontmatter 的 Markdown 文件目录设计目标是让人和 AI Agent 都能读写无需定制工具。在 OKF 中信息不是直接转储到索引中而是被编译成高度聚焦的、单一的“概念”例如内部API合约、财务指标或数据库模式。概念之间使用标准 Markdown 链接。目录路径定义了概念的唯一标识。OKF目录一个OKF目录是一组带YAML开头的Markdown文件统一表达企业内部散落的表结构、指标定义和运行手册等。一个标准的OKF目录如下company_brain/├── index.md # 渐进式披露的根目录 ├── engineering/│ ├── index.md │ └── service_mesh.md # 架构概念 └── analytics/├── index.md ├── tables/│ ├── customers.md # 单个数据库概念文件 │ └── billing.md └── metrics/└── active_users.md # 精确的业务定义OKF文件每个OKF文件都遵循严格但极简的设计 顶部是YAML frontmatter 块后面跟着自由格式的 Markdown 正文。以下是一个描述关键业务指标的真实 OKF 文件示例---type:metric id:analytics/metrics/active_users title:Weekly ActiveUsers(WAU)owner:data-engcompany.com updated_at:2026-06-15citations:-source:https://github.com/internal-org/dbt/models/wau.sql---# 周活跃用户数(WAU)在滚动7天窗口期内至少触发过一次核心后端 API 事务的用户 ID 总数。 ## 计算规则 我们明确排除内部 QA 和测试帐户 WHERE user_id NOTIN(SELECT user_id FROM staging.internal_testers)## 相关组件-有关主要用户维度映射请参阅[[analytics/tables/customers]]。-有关使用情况与有效订阅周期的关联请参阅[[analytics/tables/billing]]。代理如何使用OKF目录当你问AI代理“编写一个执行SQL查询计算我们第二季度的客户流失率。”代理读取公司 OKF 包的根目录index.md代理根据index.md找到“客户流失率”对应的存放子目录analytics/metrics/churn_rate.md。代理提取经过审核的 SQL 代码片段和结构逻辑;代理跟踪文件内部明确的 Markdown 链接[[analytics/tables/customers]]查找当前模式定义的相关链接。代理生成了一个完全准确的查询引用了确切的文件。总结企业上下文正在从各业务系统的附属品演变为可统一管理的基础设施。谷歌的方案是以数据产生的速度自动从源数据中提取语义并在平台层统一维护避免每个用例重复构建上下文。这使得缺乏资源从零构建本体的组织也能获得可信的语义层基础。参考文档1.Google:《打造值得信赖的AI-AI时代的语义层.pdf》2.https://docs.cloud.google.com/looker/docs/what-is-lookml?hlzh-cn3.https://cloud.google.com/products/knowledge-catalog?hlzh-CN4.https://www.theaiera.cn/blogs/google-open-knowledge-format