Knowledge Catalog：为 Agent 聚合、补全和检索业务上下文

立即试用 Gemini

AI 在工作场所的前门

立即试用

今天，我们在 Knowledge Catalog中推出自学习上下文丰富（预览版）和重新构想的 Knowledge Studio 体验（预览版），Knowledge Catalog 是 Google Cloud 面向智能体的上下文引擎。自学习丰富建立在 Knowledge Catalog 现有的 Gemini 驱动丰富功能之上，通过分析智能体和用户交互来发现缺口，并让你的业务上下文保持准确和最新。Knowledge Studio 是上下文工程师和数据管理员的新指挥中心，他们可以通过对话方式探索数据资产、浏览可视化上下文图谱，并在将上下文图谱的拟议变更发布给用户和智能体之前进行审核。

智能体的能力取决于它所推理的组织级定义、规则和关系——也就是所谓的上下文。这就是为什么整理上下文已成为企业智能体能力中最重要的学科之一。如今，这项工作大部分是手工完成的。上下文工程师逐个智能体编写提示词和映射，而数据管理员则试图手动在数千个资产中保持定义最新。但随着组织从少量智能体发展到数千个、最终数百万个智能体，这种方式就会失效。

Knowledge Catalog 由 Gemini 驱动的自学习丰富功能将这种手动维护转变为持续反馈循环。通过分析智能体和用户交互，它可以精准定位缺失或过时的上下文，并从操作手册、代码仓库和业务文档中提取经验证的的定义，纳入受治理、可复用的上下文集。然后，借助优化的搜索，每个智能体都能获得它所需的确切上下文，而不是在臃肿的提示词和原始架构上进行推理，并从组织内的共享学习中受益。根据内部基准测试，Knowledge Catalog 使 AI 智能体的准确性提高近 4 倍，延迟降低多达 33%，并使用的 token 减少多达 75%。

借助由 Gemini 驱动的自学习丰富功能让上下文保持最新

考虑向 Gemini 智能体提出一个简单问题：“上一季度 EMEA 的净营收是多少？”要正确回答这个问题，需要知道你的公司如何定义净营收、哪些表包含预订数据以及它们如何连接，但这种知识通常分散在 Google Docs 中的财务操作手册、GitHub 中的数据模型和 Confluence 页面中。静态目录期望主题专家预先手动捕获和更新业务定义、指标和其他上下文，以便智能体能够有效地查询正确的数据。然而，现实中，专家很少有时间记录每个资产，而当财务团队下季度修改合作伙伴信用的处理方式时，静态定义就会落后，每个硬编码公式的智能体都会开始给出错误答案。

Knowledge Catalog 的丰富能力在你已经存储业务知识的地方发挥作用：贯穿你团队的每个文档、仓库和表格。它连接跨第一方和第三方来源的结构化数据，以及 Cloud Storage、Google Workspace、GitHub、Confluence 和 SharePoint 中的非结构化数据。它为你查找、提取、组装和维护这些业务知识，将操作手册和维基等非结构化来源及其上下文与 Knowledge Catalog 中的结构化元数据（如表和架构）关联起来，使你的结构化数据更易于发现和操作。按需或按计划，它会提出业务定义、表和列描述、连接关系、黄金查询以及特定于任务的智能体指令，每项都带有来源引用和置信度分数。在每次运行时，它会检测源端发生的变化，淘汰过时的定义，并标记冲突以供审核。

它从你的用户和智能体交互中学习。你可以配置丰富功能来分析来自 Gemini 智能体、BigQuery 中的 Conversational Analytics 或你的自定义智能体的交互轨迹，同时屏蔽 PII，它会精准定位智能体遇到困难的地方，例如模糊的列查找、无依据的指标、缺失的定义，或用户反复改写同一个问题。然后它会找到权威答案并暂存修复方案，从而避免同样的错误再次发生。这就是上下文工程如何跟上数百万次智能体交互的步伐，让专家能够审核变更，而不是从头编写变更。

配置具有连接来源、评估和自学习的丰富任务

自动化并不意味着放弃控制。你可以随时选择启用或禁用自动发布，并设置拟议变更自动批准的准确置信度分数（例如 85%）。低于你的阈值的任何内容，以及删除等敏感更新，都会成为变更请求，供管理员批准、编辑或拒绝。你还可以提供自己的评估集，以端到端测试拟议更新。每次变更都会记录完整的来源信息，并且可以还原。当然，Google 绝不会使用你的数据来训练其模型。

在发布前审核丰富建议、置信度分数和变更差异

使用上下文集为每个受众设置正确的上下文

按照设计，企业上下文图的范围相当广泛，但对于特定任务而言，代理和用户通常只需要其中正确且可信的部分。Knowledge Catalog 通过上下文集实现这一点——上下文集是上下文图中经过策划和治理的子集，包含特定领域、团队、代理或终端用户群组的定义、指标、连接逻辑和黄金查询。例如，销售代理可以绑定到 Sales 上下文集，而财务分析师的助手可以绑定到 Finance 上下文集。由于“净收入”对每个群体而言可能合理地具有不同含义，因此每个领域都在同一目录中维护自己的定义。然而，代理不必绑定到单个集合；借助 Knowledge Catalog 中的搜索，代理还可以动态搜索并找到适合任何给定任务的正确上下文集。

上下文集还提供内置的数据治理和精细访问控制。对每个上下文集的访问均通过 IAM 管理，因此管理员可以决定哪些代理和用户可以读取、使用或编辑它。代理仅从它们被授权使用的集合中检索上下文，而对底层数据的访问继续遵循您现有的权限。每次更新都可追溯、可回滚，并且由于上下文集构建于 Open Knowledge Format (OKF) 之上，您可以导入 OKF 包使其成为上下文集，并将其重新导出为 OKF，从而保持上下文的可移植性。

已批准的富集内容发布到受治理的上下文集

在 Knowledge Studio 中探索并治理一切

所有这些能力都汇聚在重新构想的 Knowledge Catalog 体验中，专为为代理策划和治理上下文的上下文工程师和数据管理员而构建。

在 Knowledge Studio 中以可视化方式浏览上下文图

全新的 Knowledge Studio 将 Knowledge Catalog 从静态清单存储库转变为交互式命令中心，让您可以：

• 一目了然地查看上下文覆盖情况： 浏览跨云数据资产的可视化地图，从运营数据库和数据仓库到语义模型、上下文集和文档。
• 以对话方式探索上下文： 用自然语言提出业务问题，遍历企业上下文图中的关系，并确切了解代理如何基于您的元数据进行推理。
• 在一处审查和验证富集内容： 检查每项提议的更改、来源引用和置信度分数。用真实问题测试上下文集，并通过软件风格的版本控制来批准、编辑或回滚变更请求。
• 监控富集运行： 跟踪每个富集任务的计划、结果、令牌使用量和运行时长，并在运行完成时通过电子邮件收到通知。

开始使用

观看演示：Knowledge Catalog 的自学习富集如何为代理提供依据

这些功能将在未来几周内面向客户推出。 注册 以请求立即访问，并访问 文档 获取分步指导。

发布于

• 数据分析