Knowledge Catalog 中的数据上下文可让您将技术结构、业务规则和实际使用模式统一到一个活跃的上下文层中。借助 Knowledge Catalog，您和您的 AI 应用可以准确、安全地发现、评估和解读数据资产，而无需手动验证，也不会出现幻觉。
什么是上下文？
上下文是描述数据资产的结构、操作和语义细节的丰富结构。上下文不会将表表示为名称和数据类型的独立架构，而是提供数据的完整故事。
Knowledge Catalog 将上下文整理为以下层级：
技术元数据。直接从源系统提取的结构化详细信息，包括数据库架构、字段类型、分区键和安全标记（例如 Identity and Access Management [IAM] 政策）。
语义元数据。数据的业务含义，包括业务术语库、指标关系、分类、领域术语和黄金查询（映射到正确 SQL 代码语句的经过验证的自然语言问题）。
运营元数据。数据随时间变化的行为和健康状况，包括执行配置文件、分析统计信息和数据质量得分。
关系。底层存储表与概念性业务指标之间的推断或定义关联。
信任信号。验证指标，例如所有权和认证标记，用于验证资产是否为权威来源。
客服人员指导。非结构化说明（例如 README 文件、使用说明和执行日志），用于指导自主工具如何以及何时查询资源。
通过统一这些层，Knowledge Catalog 有助于确保您的数据得到充分理解，从而帮助您避免与孤立和未记录的数据相关的运营瓶颈和不确定性。
数据上下文与元数据的区别
虽然元数据提供了基础构建块，但元数据和上下文不能互换：
- 元数据。描述性属性，用于定义隔离数据资产的基础结构、位置和技术属性（例如，列名称、数据类型、分区键和表大小）。
- Context. 综合的多维知识图谱，结合了技术架构、业务语义、数据关系、操作行为和信任信号，可赋予数据含义并指导推理。
Knowledge Catalog 将元数据管理从被动目录转变为主动上下文的动态控制平面。下表重点介绍了被动元数据和主动数据上下文之间的主要区别：
| 维度 | 技术元数据 | 有效的数据上下文 |
|---|---|---|
| 核心重点 | 底层规范和存储格式。 | 业务含义、运营行为和关系。 |
| 州/省/直辖市/自治区 | 被动：存储在目录注册表中，供工程师手动查找。 | 主动：由 AI 持续丰富，从查询历史记录中挖掘，并为 LLM 提示动态组装。 |
| 主要消费者 | 数据库引擎、数据工程师和合规性审计员。 | AI 智能体、大语言模型 (LLM)、业务分析师和对话式界面。 |
| 主要用途 | 存储管理、索引编制和合规性验证。 | 接地智能体推理、解析联接并防止幻觉。 |
示例：元数据与上下文
为了解上下文如何扩展技术元数据，请考虑 Knowledge Catalog 如何表示交易列：
仅技术元数据
技术元数据提供结构化信息，但缺乏业务逻辑和操作指南：
- 表：
fact_orders - 列：
disc_val - 数据类型：
NUMERIC - 存储属性：按
order_date分区
仅使用此技术元数据的 AI 智能体可能会猜测 disc_val 表示客户折扣总额，但无法确定该值是否包含税费、制造商返款或促销优惠券。
丰富的数据上下文
Knowledge Catalog 通过语义、关系和操作层丰富技术元数据，将其整合为统一的上下文载荷：
- 技术架构：
fact_orders.disc_val(NUMERIC)。 - 语义定义：映射到业务术语库术语“促销折扣”，定义为在结账时应用的客户折扣，不包括制造商返款和运费补贴。
- 发现的关系：自动将
fact_orders.customer_id关联到dim_customers.id，将fact_orders.promo_id关联到dim_promotions.id。 - 运营用途：查询历史记录显示，90% 的业务查询会按
status = 'COMPLETED'过滤此表，并将其与dim_promotions联接。 - 信任度和质量：自动化数据质量扫描给出的有效性评分为 99.8%，且数据新鲜度已在过去 2 小时内得到验证。
- 黄金查询：包含一个经过验证的 SQL 模板，演示了如何使用
disc_val计算已确认的净收入。
有了这些完整的上下文，AI 智能体或数据分析师可以准确生成查询并解读数据，而无需人工验证，也不会出现幻觉。
使用没有背景信息的数据所面临的挑战
在分布式数据资产中，没有上下文的原始数据很少能解决业务问题。当结构化数据库、非结构化日志和分析指标缺乏业务含义时，用户和自主系统会面临上下文上限，导致数据难以发现、信任或用于 AI。人工分析师必须执行手动验证来核实数据源，而 AI 智能体通常会生成不准确的答案（幻觉）或无法执行操作。
如果没有结构化上下文，组织会面临以下几个运营瓶颈：
协作繁琐。由于缺乏明确的业务定义，分析和 AI 团队不得不与主题专家 (SME) 进行持续的手动协调，以建立对表的基本理解。
上下文偏移。标准文档保持静态，并随着时间的推移而失效。如果没有持续监控，过时的元数据会导致错误的假设和 AI 智能体工作流中断。
推理失败。AI 智能体和大语言模型可能会生成语法正确的 SQL 查询，但无法遵循底层企业逻辑，从而导致从业务角度来看计算结果不正确。
信息孤岛。有关如何正确过滤或联接数据集的内部知识仍被困在未记录的脚本或信息中心设置中，而不是在集中式清单中注册。
为了克服这些运营瓶颈并使数据可付诸行动，组织需要一个可靠的上下文引擎来管理其数据资产。
上下文管理的核心支柱
为了在整个数据资产中维护这一可靠的内容相关引擎，Knowledge Catalog 依托三大核心支柱运行：
汇总
Knowledge Catalog 会自动从内置数据库、Iceberg REST 目录和第三方平台收集元数据。它将这些分散的输入整合到一个统一的治理区域中，有助于确保安全政策和分类定义的一致继承。
丰富
数据监管员和上下文工程师可以使用 Knowledge Studio 界面，在整个上下文图谱中持续更新和精选特定的上下文集。Knowledge Catalog 会自动挖掘事务日志、数据库架构和商业智能模型，以发现列说明和表关系。通过 Knowledge Studio 界面，这种持续学习可让人工审核员捕获其机构知识，并将其动态应用于您的资产。
搜索和检索
Knowledge Catalog 提供高精度语义搜索，让您可以使用自然语言查询数据资产。由于 Knowledge Catalog 能够理解权限组 (ACL) 和业务术语，因此用户和自主智能体都能以低延迟找到相关数据上下文。
如何将元数据和上下文输入 Knowledge Catalog
为了构建可靠的情境引擎，Knowledge Catalog 通过自动化平台连接器、持续的 AI 扩充和可扩展的自定义接口来提取和整理信息。
第一方数据源和自动收集
Knowledge Catalog 会自动从核心 Google Cloud 服务中收集结构和操作元数据，而无需手动配置：
- 数据库和分析仓库。BigQuery、Spanner、Cloud SQL 和 AlloyDB for PostgreSQL 等服务会持续同步技术元数据，包括表架构、字段数据类型、分区键、聚类规范和数据集边界。
开箱即用的 BI 语义同步。对于 Looker (Google Cloud core)，Knowledge Catalog 会自动同步商业智能资产：
- LookML 语义定义。模型、探索、视图、维度和测量
- BI 信息中心资产。信息中心、信息中心元素和 Look。
数据集成和转换。Datastream 等服务会捕获变更数据捕获 (CDC) 流元数据，Dataform 会推送表定义和 SQL 转换，Cortex Framework 会发布已注册的数据产品。
持续的 AI 驱动型上下文精选
除了静态技术架构之外，Knowledge Catalog 还会使用内置智能引擎动态更新其上下文图谱：
- 数据洞见。数据洞察由 Gemini in BigQuery 提供支持，可挖掘历史查询日志、用户事务和架构模式，以生成自然语言列说明、发现表关系（例如联接键），并提出可捕获企业逻辑的经过验证的示例查询（“黄金查询”）。如需了解详情，请参阅结构化数据的数据洞见简介。
- 自动化数据分析和数据质量评估。扫描会计算统计分布（例如非重复计数、null 比率和样本值），并根据基于规则的数据质量检查评估数据，从而将实时健康状况得分附加到目录条目。如需了解详情，请参阅自动数据质量简介。
通过 Knowledge Studio 进行人机协同管理
为了管理和编排活跃上下文图谱，用户需要在 Knowledge Studio 中操作。此界面是以下操作的主要中心：
- 上下文集。将相关表、非结构化文档和术语表分组到统一的软件包中，以便 AI 智能体使用。
- 丰富化工作流。审核 AI 建议的列说明、应用业务术语库映射，以及手动将资产认证为权威资产。如需了解详情，请参阅管理丰富运行作业。
- 环境组织。确保不同的领域团队（例如财务或工程）拥有各自独立的区域来管理语义规则。
如需了解详情，请参阅使用 Knowledge Studio 丰富上下文。
自定义元数据提取和第三方系统
对于拥有定制知识库、第三方治理工具或本地系统的组织，Knowledge Catalog 提供了灵活的提取机制：
- Knowledge Catalog API（CRUD 操作）。使用
CreateEntry、UpdateEntry和CreateAspectTypeAPI 方法以编程方式注册外部资产并附加自定义元数据方面（例如合规性评级或系统文档）。 - 自定义丰富代理。使用智能体开发套件 (ADK) 或 LangChain 等智能体框架构建自定义丰富化智能体。例如，ADK 智能体可以从内部 Wiki 或 Git 代码库中注入技术文档，使用大语言模型将其解析为标准化的业务术语库，并将其附加到目录条目。如需了解详情，请参阅构建 AI 智能体以丰富元数据。
- 导出和导入操作。使用基于文件（JSON 或 CSV）的批量导出和导入工作流，查看 AI 生成的业务定义、与数据监管人员协作，以及批量更新元数据。如需了解详情，请参阅导出元数据。
第一方和第三方服务如何使用上下文
服务和应用以两种不同的角色与 Knowledge Catalog 交互：
- 元数据提供方。将技术元数据、架构和 LookML 定义发送到 Knowledge Catalog 的服务（例如 Looker、Cloud SQL 和 Spanner）。元数据提供方会将元数据推送到目录中，但不一定会将业务术语库定义应用到自己的界面中。
- 上下文消费者。服务、开发者工具和 AI 智能体，它们从 Knowledge Catalog 中检索业务定义、运营配置文件和治理规则，以此作为其推理和执行的基础。
在应用和智能体可以使用上下文之前，您需要建立基础业务术语和质量规则。如需了解详情，请参阅建立基础数据上下文和构建政策即代码数据质量工作流。
AI 应用和服务通过以下机制使用 Knowledge Catalog 中的上下文：
内置第一方 (1P) 集成
多项 Google Cloud 服务原生查询 Knowledge Catalog， 以提供情境感知 AI 体验：
- Gemini in BigQuery（对话智能体）。当您在 BigQuery Studio 中输入自然语言提示时，Gemini 会自动在后台查询 Knowledge Catalog 业务术语库定义、列说明和历史查询关系。这使 Gemini 能够基于企业业务术语，确保生成的 SQL 查询使用正确的表联接和指标定义。
- BigQuery 中的数据工程智能体。发现和查询 Apache Iceberg 和 BigQuery 表，自动调用语义目录搜索来解析资产依赖项，并在流水线执行期间生成目录元数据。
- Gemini 和 Agent Builder。基于 Gemini 构建的自定义生成式 AI 智能体和搜索应用会使用目录元数据和业务规则，让模型推理以经过验证的企业事实为依据。
- Google Cloud 控制台和 Business 界面。最终用户和数据监管者可以使用自然语言语义搜索来探索资产、查看交互式数据关系图，以及管理业务术语库。
第三方应用和 AI 智能体生态系统
没有内置集成的服务和自主系统通过开放协议和专用检索 API 使用上下文：
Model Context Protocol (MCP)
Model Context Protocol (MCP) 是一种开放标准，可让 AI 智能体、开发者工具和 IDE 直接连接到 Knowledge Catalog 工具。MCP 提供了一个标准化接口，用于检查表架构、查找术语表定义以及验证数据质量得分。
Knowledge Catalog 支持两种 MCP 部署选项：
- 远程 MCP 服务器。由 Google Cloud 托管（或部署在 Cloud Run 上）的托管式端点，适用于云原生智能体、无服务器工作流和多智能体平台。如需了解详情，请参阅使用 Knowledge Catalog 远程 MCP 服务器。
- 本地 MCP Toolbox。一个本地 CLI 代理，可与开发者 IDE（例如 VS Code 和 Cursor）以及本地开发工作流集成。如需了解详情，请参阅将 Knowledge Catalog 与本地 MCP Toolbox 服务器搭配使用。
使用 LookupContext API 检索预先设置格式的上下文
对于自定义 AI 流水线和 LLM 应用，Knowledge Catalog 提供了 LookupContext API 方法。
LookupContext 方法无需智能体进行多次依序调用来检查架构、查找术语表、提取数据质量得分和检查查询日志，而是通过单个请求检索统一、预格式化的丰富元数据包。
LookupContext 方法的主要功能包括：
- LLM 就绪格式。返回格式化为
yaml（默认）、json或xml的上下文，旨在直接插入 LLM 系统提示中。 - Token budgeting (
context_budget)：可让您指定目标字符预算。这是一个软预算，这意味着 API 会智能地截断元数据并确定其优先级，以尝试适应模型的上下文窗口，但不能保证严格保持在限制范围内。 - 可配置的上下文视图。
- BASIC。返回基本条目元数据、架构、列说明、概览文本和代理指南。
- 标准。除了基本元数据之外，还会遍历上下文图，以包含多表联接关系、附加的业务术语库术语和同义词，以及经过验证的示例查询。
- 发现的联接和黄金查询。包括推断出的表联接条件（例如
orders.customer_id = customers.id）和经过验证的示例 SQL 查询。
如需了解详情，请参阅检索数据资产的上下文和 lookupContext REST 参考文档。
上下文如何帮助最终用户和 AI 智能体
Knowledge Catalog 通过将技术架构、业务语义和质量指标统一到一个活跃的上下文层中，在其智能体数据云中提供通用上下文。通过 Model Context Protocol (MCP)、上下文检索 API 和语义搜索等开放接口公开这些元数据，Knowledge Catalog 可为用户和自主系统提供帮助。
消除用户的手动信任工作
如果没有集中式语义层，您必须调查底层数据库和查询历史记录，才能回答基本的业务问题。标准目录充当架构的被动清单，需要您手动查找指标定义或验证表是否干净。
Knowledge Catalog 将这种被动治理转变为主动智能。Knowledge Catalog 直接在数据资产旁边显示质量得分、语义描述和使用警告，让您无需等待工程审核即可信任并使用数据。
为自主代理提供依据并实现动态治理
AI 智能体和大语言模型 (LLM) 需要严格、确定的规则来与数据库交互。如果没有明确的语义上下文，智能体可能会对列名称做出错误的假设，或生成错误的 SQL 查询。
此外，活跃上下文会将元数据管理从被动注册表转换为主动治理层。通过直接在 Knowledge Catalog 中定义经过验证的业务规则、指标和智能体指令，组织可以治理智能体检索、评估和处理企业数据的方式。
Knowledge Catalog 填补了这一空白。它通过 Model Context Protocol (MCP) 或 LookupContext API 等标准接口，将统一的活跃上下文配置文件导出到 AI 应用。将模型与这些元数据进行接地，可最大限度地减少幻觉，强制执行治理规则，并有助于确保自主操作基于经过验证的组织事实。
AI 应用如何使用上下文集
Gemini Enterprise 和其他 AI 应用通过两种主要模式使用上下文集：
使用语义搜索进行动态上下文发现：在对话式或自助式分析环境中，用户会用自然语言提出临时问题（例如，我们企业账号的季度净留存率是多少？）。当用户提交提示词时，智能体会针对 Knowledge Catalog 发出语义搜索查询，以找到与问题领域最相关的上下文集。智能体会将检索到的上下文注入到活跃提示中，从而针对底层数据仓库生成准确的 SQL 查询。
为专用应用预配置上下文集：您可以在设置期间提供代理的资源 URI，从而使用显式上下文集引用预配置代理。绑定专用上下文集可提供确定性接地，确保所有未来的交互都一致地使用经过认证的业务定义，而不会产生运行时搜索开销。由于周期性丰富任务会随着时间的推移不断优化上下文集，下游应用会自动继承这些质量改进，而无需手动重新提示或重新部署应用。
Knowledge Catalog 通过 Model Context Protocol (MCP) 或 LookupContext API 等标准接口将统一的主动上下文配置文件导出到 AI 应用，从而最大限度地减少幻觉并强制执行治理规则。
通过共享上下文协调多智能体工作流
在多智能体框架（或群组）中，不同的专业智能体协同工作，以运行复杂的工作流。当这些智能体在没有共享上下文平面的孤立环境中运行时，它们会面临上下文上限，即它们可能会使用冲突的业务规则、无法找到相关依赖项或重复检索工作。
将 Knowledge Catalog 用作集中式上下文注册表，有助于您协调和扩缩多智能体集群。在 Knowledge Catalog 中建立 swarm 的依据具有以下优势：
共享业务语义。所有代理都引用相同的业务含义和定义。例如，如果数据分析代理和报告代理都检索包含销售数据的表，则它们会使用相同的指标（例如
Gross Merchandise Value (GMV)）术语表定义，以帮助确保一致性。动态依赖项解析。代理可以使用上下文关系以编程方式发现上游和下游资源。这样一来，流水线问题排查智能体就可以将数据故障追溯到其源表，并将任务移交给修复智能体，而无需对依赖项规则进行硬编码。
统一的连接界面。通过使用 Model Context Protocol (MCP)，您可以向整个集群公开单个语义端点。这样就无需为每个代理配置自定义 API 集成。
边界级安全治理。 Knowledge Catalog 会根据预配置的 IAM 角色检查智能体查询。这有助于确保智能体仅检索其获得明确授权访问的资源上下文，从而防止整个集群中发生意外数据泄露。
使用数据上下文的用例
为了解数据上下文如何解决复杂的查询，请考虑 Knowledge Catalog 如何在实践中应用技术、语义和操作层：
电子商务：个性化搜索推荐
为了使季节性营销活动与商品库存保持一致，搜索代理必须了解非结构化促销电子邮件与结构化商品清单和用户交易表之间的关系。Knowledge Catalog 会映射这些实体，让推荐模型能够实时推荐相关商品。
制造业：优化机械维护
预测性维护模型需要将结构化零件日志与非结构化技术人员维修指南和实时传感器数据流集成。通过映射部件号与手册章节之间的关系，Knowledge Catalog 可让分析系统预测设备疲劳情况，并在故障发生前安排维修。
医疗保健：验证临床试验数据
临床研究中心必须验证患者统计信息是否符合严格的研究规则，以及患者同意记录是否直接映射到试验结果数据集。Knowledge Catalog 可映射上下文关系，以审核意见征求流水线，并提醒研究人员注意数据分析中的异常情况，从而帮助维护试验的完整性。
金融服务：评估信用风险
贷款承保模型使用来自不同源系统的客户信用评分、交易记录和活跃债务余额。 Knowledge Catalog 提供贷款指标的统一图谱，让承保工具能够确认风险评估使用的是经过认证且合规的资产。
电信：诊断网络运营
自主网络管理系统和智能体可分析实时信号行为、检测性能下降，并应用自我修复纠正措施。通过将这些智能体与 Knowledge Catalog 上下文相结合，系统可以安全地映射技术日志与业务服务领域之间的关系。