Google Cloud Blog

Grounding agents in one context graph connecting semantic models you already trust

8.5内容质量
Grounding agents in one context graph connecting semantic models you already trust

TL;DR · AI 摘要

Google Knowledge Catalog通过整合多源语义模型提升AI代理准确性,内部测试显示准确率提升4倍且延迟降低33%。

核心要点

  • Knowledge Catalog整合Looker、dbt、Snowflake等7种工具的语义模型
  • AI代理准确性提升4倍,延迟降低33%,token使用减少75%
  • 自学习上下文提取功能可自动更新操作手册、会议记录等非结构化数据

结构提纲

按章节快速跳转。

  1. AI代理因缺乏业务上下文导致数据错误,如将取消订单计入营收

  2. Knowledge Catalog构建统一上下文图关联多源语义模型定义

  3. 新增支持LookML、BigQuery Graph、SAP CSN等7种语义模型格式

  4. 内部基准测试显示准确性提升4倍,延迟降低33%

  5. 通过Gemini模型实现非结构化数据的上下文自动提取与更新

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • Knowledge Catalog语义模型整合
    • 核心价值
      • 提升AI代理准确性(4X)
      • 降低延迟(33%)
    • 技术实现
      • 统一上下文图构建
      • Gemini自学习上下文提取
    • 支持工具
      • Looker
      • dbt
      • Snowflake
      • Databricks
      • SAP

金句 / Highlights

值得收藏与分享的关键句。

#Google Cloud#Knowledge Catalog#AI代理#数据治理#语义模型
打开原文

Knowledge Catalog 中语义模型支持的扩展 | Google Cloud 博客

数据分析

将代理根植于连接您已信任语义模型的统一上下文图中

2026年10月30日

##### Maggy Hu

产品经理

##### Paulina Trzeciak

##### 11月4日:Agentic Data Cloud 活动

与我们的产品负责人共同规划您的智能代理未来

注册

想象这样一个场景:在高管业务评审之前,销售副总裁向AI助手询问:"上个季度我们最重要的企业客户净收入是多少?"几秒钟后,代理返回了一张精美的图表!但令人遗憾的是,这些数字与财务报告不符。为什么会这样?因为代理将取消的订单计算在内,并且从未经验证的暂存表中提取了数据。

代理的失败并非源于模型本身,也不是因为它无法将用户问题转化为查询。真正的问题在于它不理解您的业务。更关键的是,这种理解通常已经以Looker、dbt、Snowflake、Databricks或SAP系统中的语义模型形式存在。但由于每个定义都锁定在各自的工具中,每个代理都只能猜测这些定义……而往往猜错了。

这就是Knowledge Catalog的作用所在。它将所有工具中的语义模型整合到一个统一的上下文图中,使每个代理都能基于相同的可信定义进行工作。当两个工具对同一指标的定义不同时,两个定义及其来源都会同时呈现,数据管理员可以在信息到达终端用户之前解决冲突。

今天,我们宣布扩展语义模型支持功能现已正式上线。Knowledge Catalog 现在原生支持从 Looker LookML、BigQuery 图(包括 BigQuery 度量)、dbt MetricFlow、Snowflake 语义视图、Databricks 指标视图和 SAP 核心模式符号(CSN)中提取语义模型和指标定义,并通过单一上下文图将它们与模式、血缘关系、数据概要、业务术语表和其他关键元数据连接起来,而无需移动数据或用新语言重写业务逻辑。

通过将 AI 代理根植于这些模型,它们可以使用分析师依赖的相同业务定义,从而使回答与业务信任的数字保持一致。事实上,根据内部基准测试,基于 Knowledge Catalog 的代理准确率提高了近 4 倍,延迟降低了高达 33%,使用的 token 数量减少了多达 75%。

统一的上下文图使您能够:

  • 重用您已信任的语义模型:Knowledge Catalog 将 Gemini 代理、BigQuery 会话分析和您的自定义代理根植于团队已定义的指标、过滤器和连接路径中,无论这些定义存储在何处。
  • 超越手动编写的定义,利用自学习上下文:Knowledge Catalog 将语义模型中明确定义的指标和 KPI 定义与从非结构化知识源(如运营手册、会议记录、聊天记录、代码等)中提取的相关上下文进行配对。借助 Gemini 的自学习增强功能,系统持续发现缺失或过时的上下文,并将其转化为受控的、可重复使用的上下文集,确保代理的上下文在定义变化时始终保持最新,而不仅仅依赖于手动整理。
  • 将业务逻辑与企业信任相结合:即使公式本身正确,若运行在过时或未经认证的数据上也会得出错误结论。这就是为什么知识目录可以将语义定义与数据质量评分、新鲜度信号和血缘关系相连接,使代理在编写SQL之前就能明确可信赖的数据范围。

同一问题在Gemini中使用知识目录(右)与未使用知识目录(左)的对比。突显了基于知识图谱的代理(右)在使用更少token和更低延迟的情况下给出准确响应,而未使用知识目录的代理(左)则出现幻觉并消耗更多token且延迟更高。

跨越数据领域的统一上下文图谱

知识目录创建的上下文图谱是您数据与语义资产的互联地图:表、语义模型、术语库条目和数据产品作为节点;血缘关系、关联关系、模式键、从真实查询历史中挖掘的连接关系以及语义模型中声明的连接路径作为边。摄入的语义信息会与现有的治理信号和使用信号一同存在于该图谱中,使代理能够在一次遍历中从业务概念直达可信公式和验证过的连接路径。每个数据源都从自身视角诠释业务:

  • Looker LookML(GA):通过Looker Core的实时同步索引模型、探索、视图和仪表板,捕获编译后的度量SQL、安全连接条件、强制过滤器以及从源表到高管仪表板的血缘关系。
  • BigQuery 图谱(GA):索引原生属性图定义、节点和边表、图度量及商业同义词,使代理能够通过图查询语言(GQL)遍历连接实体,而非使用脆弱的多表自连接。
  • dbt MetricFlow(GA):将源对象与dbt模型和MetricFlow指标关联,同时整合dbt数据质量测试结果、过滤器、保存查询、新鲜度SLA及下游暴露信息。
  • 通过Horizon Catalog的Snowflake语义视图(GA):将联邦的BigQuery或Google Cloud Lakehouse表与Snowflake Horizon元数据配对,引入语义视图维度、事实、度量公式、关系及同义词,同时整合数据度量函数质量评分卡和PII掩码标签。
  • 通过Unity Catalog的Databricks度量视图(GA):摄入来自Unity Catalog的度量视图定义、度量公式、作用域过滤器和连接基数,同时整合表认证徽章和Lakehouse监控分析结果。
  • 通过SAP业务数据云(BDC)的SAP核心模式符号(CSN)(GA):当SAP BDC数据产品通过Google Cloud Lakehouse进行联邦时,捕获业务标签、维度和立方体建模模式、默认聚合、货币和单位绑定、键和复合连接关联以及数据敏感性标志。

由于每个数据源都作为同一图谱中的节点或边存在,LookML连接、dbt暴露、Snowflake关系或SAP关联可以并行遍历,且每个元素都通过链接回溯到其依赖的物理表。同时不会发生静默覆盖:重叠定义会并行保留,每个条目都标注来源,为数据管理员提供完整的全景视图以确定统一版本。

在Knowledge Studio中通过上下文图谱导航语义模型、连接路径和血缘关系。

你可以在知识工作室(预览版)中探索和管理所有这些内容,这是你探索和管理上下文的指挥中心。通过自然语言提示探索你的上下文图,包括语义定义,并通过上下文图画布遍历连接路径。然后,一旦验证了正确的资产和定义,你可以将它们打包成可重用的上下文集,这些上下文集可映射到组织中的特定用例和领域,Gemini和自定义代理可以在生产环境中使用这些上下文集。

入门指南

让我们回到那个关于净收入的问题。通过知识目录,销售副总裁的代理只需发出一个上下文查询即可发现可信资产,应用领域专家定义的精确指标公式和过滤条件,同时尊重跨系统的连接键,并确认底层数据已通过质量检查。更棒的是,报告中的数字是正确的!

要开始使用,请在知识工作室中探索你的上下文图,并访问知识目录文档以连接更多数据源。

发布分类:

  • 数据分析