在 Amazon Quick 中推出 Agentic Catalog 体验

随着企业拥抱 AI 驱动的分析，自然语言（Text2SQL）回答的价值完全取决于其背后的业务上下文。我们正在进入一个阶段：语义的丰富程度（表和列描述、关系）必须直接从上游数据目录和语义工具中产生，然后流入为广大终端用户服务的 AI 产品。Amazon Quick 这样的产品不能再孤立运作，它需要原生地消费和推理数据团队在 AWS Glue Data Catalog、Databricks Unity Catalog 等系统中精心整理的各类定义、关系和治理元数据。从孤立的元数据到互联的、感知目录的 AI，正是实现大规模智能分析的关键。

挑战：打通最后一公里

企业数据团队已经完成了最艰难的投资。他们在 AWS Glue、Databricks Unity Catalog、Snowflake Horizon、Collibra、dbt 等上游目录平台上投入了大量精力，细致地定义了表描述、列语义、主外键关系、术语表和指标定义。然而，当销售经理、市场营销总监、财务负责人等终端用户需要生产就绪的 AI 和可信仪表板时，巨大的鸿沟仍然存在。

数据管理员（BI 工程师、分析负责人、高级分析师）在 Amazon Quick 中为企业用户赋能时，面临三个叠加的挑战：

发现能力受限：企业目录中有数千张表，如何找到已整理好并获批用于报告的上游资产，就像大海捞针。你无法描述自己的需求并让系统去查找。

语义碎片化与手动重建：上游已有的丰富元数据（表和列的业务描述、主外键关系）并不会自动流入。管理员必须从零开始重建资产，重新编写描述，手动统一各种定义。例如，“收入”指的是毛收入还是净收入？“活跃客户”是指 30 天内购买还是 90 天内购买？这些定义已经存在于上游，但需要手动重新录入。

从数据到洞见耗时数周而非数小时：手动发现加上手动重建，使得从数据到可操作洞见的周期从几小时延长到数周。更糟的是，当上游定义发生变化时，Quick 数据集中手动创建的语义会变得过时，产生语义漂移，逐渐侵蚀用户对 AI 回答和仪表板的信任。

这中间的差距并非来自上游，元数据已经存在，治理已定义，关系已映射。问题在于最后一公里：如何将丰富的目录上下文转化为经过整理、可消费的体验，从而提供用户可信赖的、基于事实的 AI 回答和确定性仪表板。

Amazon Quick 推出 Agentic Catalog 体验

今天，我们宣布在 Amazon Quick 中推出 Agentic Catalog Experience。这是一个 AI 驱动的工作流，帮助数据管理员快速定义其上下文边界、继承上游语义，并为终端用户大规模启用 grounded Q&A 和可信仪表板。

该体验的核心是 Quick Agent，其任务限定在目录上下文中的发现、创建和继承。它利用来自目录连接的语义上下文，一目了然地总结整个目录，与客户进行自然语言对话，根据客户的用例呈现最相关的表和关系，并评估元数据的就绪程度。然后，通过一次对话式确认，它会自动创建 Catalog-Generated Datasets 和 Topics，并继承来自上游目录的目标元数据。整个过程无需手动配置、切换上下文或数周的设置。

工作原理

自然语言资产发现

管理员不再需要滚动上千张表来寻找合适的表，而是可以用自然语言描述需求。例如，财务团队的高级分析师说：“我是财务团队的高级分析师，我需要用于季度收入报告和成本分析的表。”Quick Agent 会遍历整个目录，利用所有可用的元数据（包括业务描述、标签、Gold/Silver/Bronze 分级、质量评分、表健康评分和术语表）即时找出最相关的表。

批量代理数据集创建

选定表后，Quick Agent 会在一个引导式工作流中大规模创建目录表示（数据集）。由于默认使用 Direct Query，上游目录仍然是真实来源。带有继承语义的数据集会带有清晰的“Semantics Inherited”徽章，且元数据为只读。作者可以随时点击同步按钮，按需刷新继承的元数据，以与目录保持一致。

语义和关系继承

Quick Agent 会将目录中的目标元数据带入它创建的资源中。目前，继承特意集中在两个关键领域，以避免干扰并保持数据集的干净：表定义和列定义继承到数据集，使管理员和终端用户能获得所需的语义上下文；主键和外键关系继承到主题，Agent 检测关系并利用它们建议和创建多数据集结构（Topics），并预配置星型或雪花型模式连接。请注意，虽然发现阶段会使用所有可用元数据（Gold/Silver 分类、质量分数、标签、健康分数），但今天继承到数据集的元数据特意限定为表和列定义。我们计划在未来向数据集添加更多元数据类型。

即时消费

创建好的数据集和主题立即可用：可以开始与它们进行 Q&A 对话，AI Agent 利用继承的业务描述、术语表和质量分数提供基于事实的回答；可以构建确定性可视化并具有完整语义上下文；还可将数据集添加到 Space 并与业务用户共享，用于自助式 Q&A。创建后，与数据集和主题关联的元数据会流入 Amazon Quick 的语义存储，为 AI 驱动的 Q&A 提供重排序和统一上下文。从目录连接到第一个业务问题只需几分钟，而不是数周。

架构：消费者，而非目录

该体验的一个关键设计原则是：Amazon Quick 是上游目录元数据的消费者，而不是一个专门的目录。这意味着：不重复数据——Catalog-Generated Datasets 使用 Direct Query，不复制或移动任何数据；元数据用于上下文——Quick 中继承的语义是只读的，并流入语义存储以支持重排序和 AI 回答依据；你的上游目录保持权威地位；手动语义同步——作者可以按需点击同步按钮刷新继承的元数据，计划自动同步已提上日程；具备透明性的可扩展性——Catalog-Generated Datasets 以只读方式显示继承的语义（标记为目录表示），如果作者选择编辑数据集，Quick 会明确提示编辑将创建自定义数据集且不再应用语义同步，从而在默认情况下维护目录完整性，同时赋予作者完全控制。

当前支持的目录

目前支持的目录平台包括：AWS Glue Data Catalog（使用 IAM Role ARN 进行身份验证）和 Databricks Unity Catalog（使用 OAuth 2.0 或个人访问令牌）。更多目录平台即将支持。

继承什么？

元数据继承有意聚焦，以保持数据集干净且生产就绪。继承到数据集的内容包括：表的业务和技术描述、列描述和显示名称、数据类型和可空性、术语表和同义词。继承到主题的内容包括：主外键关系、关系定义和基数、星型和雪花型模式模型。

终端用户体验

对下游业务用户而言，这意味着什么呢？以一个销售经理的提问为例：“我们第四季度按地区的销售额是多少？”在幕后，AI Agent 会使用业务描述和术语表搜索 Catalog-Generated Datasets，识别 sales.revenue_by_product 表（Gold 级，质量 98%），应用主题中预配置的连接来组合相关维度，并遵守目录元数据中的 PII 脱敏规则，然后在几秒钟内返回有依据的、可信的答案。无需手动配置数据集。管理员只需用 Quick Agent 定义一次上下文边界，所有终端用户就能立即可用。

统一的企业上下文

Agentic Catalog Experience 并不是孤立存在的。它与 Amazon Quick 更广泛的平台能力（包括 Slack、Outlook、文档和知识库的集成）相结合，使终端用户获得完整的企业上下文：来自目录的结构化数据（通过 Catalog-Generated Datasets）、来自文档、电子邮件和对话的非结构化上下文，以及来自术语表和指标定义的业务规则。这种统一上下文使生产就绪的 AI 回答能够基于组织的特定数据和语义，确保准确可信。

连接到 AWS Glue Data Catalog

要开始使用 Agentic Catalog Experience，请在 Amazon Quick 中创建到 AWS Glue Data Catalog 的数据源连接。建立连接后，Quick Agent 会通过一个对话式工作流引导你完成发现、架构探索和主题创建。在实际操作中，我们连接到 Glue Data Catalog 并构建金融分析主题。在 Amazon Quick 中创建新数据源，从连接类型列表中选择 Glue Data Catalog（预览版），然后选择“下一步”。该连接用于元数据，Quick 可以消费你的团队在 AWS Glue 中已经整理好的表和列定义及关系。Glue Data Catalog 连接与 Amazon Athena 连接配合使用：Glue 提供元数据，Athena 提供对 Amazon S3 中数据本身的查询路径。同时创建 Athena 数据源，以便 Quick 对底层数据运行查询。创建完成后，数据源页面会并排显示两个条目。打开 GDC-Demo 数据源详情页，在“数据连接”下可以看到链接的 Athena 数据源。选择“Explore data”以启动 Quick Agent。面板会打开在右侧，自动限定到 Glue Data Catalog 数据源。