在 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 資料來源。