在 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 數據源。