Unifying enterprise context and semantics: LookML in Knowledge Catalog is now GA

知识目录中的LookML元数据索引现已正式上线 | Google Cloud 博客

商业智能

统一企业上下文与语义：知识目录中的LookML现已正式上线

2026年10月27日

##### Maire Newton

Google Cloud 外向产品经理

##### Ramanan Balakrishnan

Data Cloud 外向产品总监

当企业从实验性AI代理原型转向生产环境应用时，数据团队逐渐认识到数据的可访问性并不等同于对数据的理解。为弥合这一差距，今天，我们宣布Looker Core在Google Cloud上的知识目录中LookML语义语言索引的正式上线（GA）。

要准确回答复杂业务问题，AI代理需要上下文信息——包括表结构、数据血缘、治理策略、业务定义等。然而，上下文并非单一维度；了解数据存储位置与掌握如何用数据计算指标是截然不同的能力。在企业环境中，团队常将宽泛的组织上下文（通常以结构化和非结构化文档中的元数据形式存在）与确定性的业务语义（如净收入或客户流失等指标所依赖的精确SQL公式、连接路径和过滤规则）混为一谈，假设单一数据目录或同时处理企业级资产发现和精确指标计算的商业智能（BI）工具就能满足需求。

实际上，没有任何工具能独自承担代理AI的全部工作负载，因为企业代理需要同时具备组织上下文和确定性业务语义。在Google Cloud环境中，这两方面分别由知识目录和LookML提供支持：

• 知识目录提供宽泛的企业上下文：代理需要一个统一的上下文图谱，能够聚合结构化表和非结构化文档中的元数据。通过知识目录，代理可以发现资产、检查数据质量、追踪端到端血缘、遵守列级隐私标签，并呈现企业政策文件。上下文图谱告诉代理数据存在哪些位置、如何被治理以及如何相互连接。

• LookML提供确定性数学语义：目录本身无法定义数字的计算方式。描述表结构与定义表连接方式或指标计算逻辑是两回事。Looker的建模语言LookML编码了经过生产验证的语义逻辑——多粒度连接保护、条件过滤和精确KPI公式——使代理无需在运行时猜测SQL数学计算。

通过这种原生集成，驱动您可信BI报告的LookML业务逻辑会自动索引到知识目录中——使Gemini Enterprise和自定义AI代理同时具备企业级资产发现能力和确定性BI语义。

• 天真的连接扩散：复杂模式通常包含发票、明细项和退款之间的多对一（1:N）和零对多（0:N）关系。如果没有预先建模的连接关系和对称聚合规则，代理生成的SQL可能会导致行数倍增并夸大财务总额。

Knowledge Catalog和Looker协同解决此问题，使您能够在LookML中建模一次，并在Google Cloud的AI生态系统各处访问这些语义。Knowledge Catalog在语义建模工具定义逻辑时强制执行语义数学；LookML则提供一种成熟且经过生产验证的语言，用于定义这些精确的数学关系。

新增功能：Knowledge Catalog中的LookML

此前，目录集成仅捕获浅层的文件级指针和基本仪表板清单。此次发布后，LookML的确定性语义成为Knowledge Catalog上下文图中的首层结构。现在，代理在图中找到指标时，也能在同一位置、同一治理框架下找到其精确定义、连接路径及其回溯到源表的血缘关系。默认情况下同步功能始终开启，无需用户操作，且通过实时同步，任何推送到生产环境的LookML更新都会在Knowledge Catalog中近乎实时地反映出来，使代理能够基于最新的业务逻辑运行。

由于此元数据默认直接索引到Knowledge Catalog，因此可立即供Gemini Enterprise使用，无需自定义代理代码或独立目录数据存储。当连接到Knowledge Catalog时，Gemini Enterprise会使用内置的只读技能和混合搜索功能，在单一步骤中查找技术模式、业务术语表和已索引的LookML逻辑，并将这些丰富上下文直接传递给您的联邦BigQuery连接器以生成准确的SQL。（对于开发自定义代理的开发者，相同的上下文包也可通过LookupContext API访问。）

Knowledge Catalog现在在Google Cloud上的Looker Core中捕获并链接以下实体层级：

• LookML模型（looker-model）：捕获描述性元数据、数据库连接路由、包含层次结构、数据验证测试（assert）以及父子EntryLinks映射模型到相关Explores、Views和LookML仪表板的映射关系。

• LookML Explores（looker-explore）：将完整的关联连接逻辑（类型、sql_on、关系基数如many_to_one扩散保护、外键、必填连接和sql_where）作为Schema-Join关系进行索引。它还捕获强制过滤防护（always_filter、access_filter）、继承的维度和度量，以及预定义的初始查询，帮助代理和分析师克服冷启动问题。

• LookML视图和字段（looker-view）：提取列级编译的LookML SQL表达式（例如，${total_revenue} / NULLIF(${count}, 0)）、主键、维度组时间范围、字段同义词以及派生表转换逻辑（包括SQL和原生派生表、分区键和聚类键）。

• 仪表板、视图和图块（looker-dashboard, looker-dashboard-element, looker-look）：对通过用户界面创建和通过LookML定义的仪表板及可视化图块进行分类，包含仪表板筛选器、图表类型、所有权和使用统计信息。知识目录中的用户能够查看从底层BigQuery表到单个仪表板图块的表级和列级血缘关系，使数据工程师能够在中断发生前主动评估模式变更。

Looker Core在Google Cloud上会自动将解析后的LookML模型、Explores、Views、血缘关系和仪表板直接索引到知识目录中。

数据代理的三种模式

将LookML引入知识目录，使Gemini Enterprise（以及更广泛的代理生态系统）能够在一个统一位置获取知识目录中的组织上下文和治理信息，以及LookML中明确的数学关系和SQL定义。

要观察在Gemini Enterprise中结合这两层的影响，可以比较三种架构如何处理一个复杂的跨领域提示："上一个财政季度按产品类别划分的总营收是多少，以及适用的区域性促销政策限制是什么？"

代理架构

系统机制

数据逻辑与治理解析

用户体验与令牌效率

模式1：基线数据库代理

仅限数据仓库

LLM直接针对仓库表编写原始SQL，没有任何语义或目录上下文。

无治理且非确定性

无法查看数据质量、PII标签或公司文档，盲目猜测SQL指标逻辑——假设标准的1月财政日历，汇总未完成订单，并暴露受限的客户PII。

脆弱且高风险

容易产生模式幻觉，在需要非结构化政策上下文的问题上失败，并在多轮SQL调试循环中消耗令牌。

模式2：上下文锚定代理

未索引语义的知识目录

Gemini Enterprise或其他代理平台使用知识目录查找表描述、术语表、PII治理要素和非结构化政策PDF，然后通过仓库连接器编写SQL。

上下文锚定，但缺乏语义SQL逻辑

执行知识目录治理并检索非结构化促销政策规则，但缺乏SQL指标和表关系的语义定义。这种方法可能遗漏条件会计规则（如order_status = 'Complete'）或导致跨多粒度表的连接扩散。

受控发现，数学不一致

解决资产发现、合规性和非结构化上下文问题，但仍存在文本到SQL计算偏差和多轮SQL重试问题。

模式3：上下文+语义锚定代理

知识目录+Google Cloud上带有索引LookML的Looker Core

Gemini Enterprise或其他代理平台连接到包含索引LookML元数据的知识目录，自动检索广泛目录上下文和LookML连接路径及字段公式，用于锚定其SQL生成。

受控上下文+语义SQL定义

执行知识目录PII要素，检索非结构化政策PDF，并基于知识目录中索引的LookML精确数学定义生成SQL，应用status = 'Complete'、5-7月财政日历以及仓库表之间的预定义连接条件。

准确且高效：

/

预映射的 LookML 连接蓝图和编译后的 SQL 表达式消除了猜测，防止连接扇出，减少 SQL 重试循环，并使代理能够将用户引导至相关的 Looker 仪表板和 Explores。

当您遵循模式 3 并在企业代理工作流中将 Knowledge Catalog 与 Looker 的语义层结合使用时，代理将从猜测原始 SQL 转变为受控的两阶段执行流程：

• Knowledge Catalog 中的上下文和治理发现：在接触任何数据之前，代理会搜索 Knowledge Catalog，验证 thelook_ecommerce LookML 模型是否获得黄金认证，检查列级治理标签，并将提示映射到精确的 LookML 维度和度量，将自然语言转换为结构化业务意图。

• 确定性语义执行：与让 LLM 随机生成 SQL 不同，代理将 SQL 基于 Knowledge Catalog 中索引的 LookML 精确数学定义进行构建，返回可信赖且可重复的结果。

除了答案外，代理还会返回一个交互式 "在 Looker Explore 中打开" 链接，其中已预填充精确的度量和筛选条件，使用户只需单击即可切片、切块并检查行级明细。

基线代理直接查询 BigQuery（左）与受 Knowledge Catalog 和 Looker 管理的代理（右）的并排对比：前者猜测原始 SQL 和财政日期，后者应用索引的 LookML 定义并返回交互式 "在 Looker Explore 中打开" 链接。

为 BI 和企业扩展代理

数据领导者常见的问题是："如果我们使用 Looker 对话式分析，何时需要使用基于 Knowledge Catalog 的企业代理？"

这两种体验在您的组织中设计用于互补的任务：

• Looker 对话式分析是您的专用 BI 助手：当业务用户在 BI 工作流中工作并询问针对特定精选 Looker Explores 的问题时，对话式分析可直接在 Looker 中提供即时的自助数据探索和可视化。

• Knowledge Catalog + Looker 为您的企业级代理提供动力：当用户在 Gemini Enterprise 中跨联邦 Data Cloud 源（如 BigQuery）提问时，问题通常涉及结构化表、BI 指标和非结构化文档。在 Gemini Enterprise 中启用 Knowledge Catalog 可使助手具备内置技能，动态发现数百个 LookML 模型中的相关语义，将索引的 LookML 连接定义、指标 SQL 公式和初始查询传递给 BigQuery 连接器，防止连接幻觉，并实施集中治理和 IAM。

入门

由于 Looker Core on Google Cloud、Knowledge Catalog 和 Gemini Enterprise 本机集成，您只需点击几次即可将现有 LookML 业务逻辑连接到企业 AI 助理，无需任何自定义代理代码。

要开始发现 Looker 语义并构建您的代理：

• 首先确认已在 Google Cloud 上为 Looker Core 启用第一方元数据索引功能。该功能对新实例默认启用，存储 Looker 技术元数据无需额外费用。功能启用后，元数据同步到 Knowledge Catalog 将默认始终开启（包括初始索引和持续实时更新）。请在项目中启用 Cloud Dataplex API 和 Data Lineage API，并为用户分配必要的查看角色（roles/dataplex.viewer、roles/looker.schemaViewer 和 roles/datalineage.viewer），使解析后的 LookML 模型、Explores、Views、连接路径和仪表板可自动同步到 Knowledge Catalog。

• 在 Gemini Enterprise 中启用 Knowledge Catalog。当您以联邦查询模式将 BigQuery（或 Spanner、Cloud SQL 或 AlloyDB）数据存储连接到 Gemini Enterprise 应用时，Knowledge Catalog 集成将自动启用。您也可以随时通过 Google Cloud 控制台操作：打开 Gemini Enterprise 应用，导航至配置 > 助手，切换 Enable Knowledge Catalog 开关，然后点击保存并发布。

• 提问查询。Gemini Enterprise 通过终端用户凭证连接 Knowledge Catalog，这意味着用户只能发现和查询其拥有 IAM 查看权限（如 roles/bigquery.dataViewer）的数据资产。在后台，助手会自动在 Knowledge Catalog 中查找已索引的 LookML 定义、连接逻辑和预置查询，并将其传递给联邦连接器，从而提供准确且受控的答案。

如需深入了解，请阅读《使用 Knowledge Catalog 管理 Google Cloud 上的 Looker Core》文档，并学习如何在 Gemini Enterprise 中《连接到 Knowledge Catalog》。如需构建更定制化的体验，请查看 GitHub 上的 ADK agent 代码实验室。

发布分类：

• 商业智能

• 数据分析