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