Knowledge Catalog 的資料情境可讓您將技術結構、業務規則和實際使用模式，整合至主動情境層。有了 Knowledge Catalog，您和 AI 應用程式就能準確、安全地探索、評估及解讀資料資產，不必手動驗證或擔心幻覺問題。
什麼是背景資訊？
背景資訊是描述資料資產的結構、作業和語意細節。背景資訊不會將資料表呈現為名稱和資料類型的獨立結構定義，而是提供資料的完整資訊。
Knowledge Catalog 會將脈絡資訊分為下列層級：
技術中繼資料。直接從來源系統擷取的結構詳細資料，包括資料庫結構定義、欄位類型、分區鍵和安全性標記 (例如身分與存取權管理 (IAM) 政策)。
語意中繼資料：資料的業務意義，包括組織詞彙、指標關係、分類、領域術語和精確查詢 (對應至正確 SQL 程式碼陳述式的已驗證自然語言問題)。
作業中繼資料：資料隨時間變化的行為和健康狀態，包括執行設定檔、剖析統計資料和資料品質分數。
關係。基礎儲存資料表和概念業務指標之間的推論或定義連結。
信任信號：驗證指標，例如擁有權和認證戳記，可驗證資產是否為權威來源。
代理引導：非結構化說明 (例如 README 檔案、使用注意事項和執行記錄)，引導自主工具如何及何時查詢資源。
Knowledge Catalog 整合這些層級，確保您能充分瞭解資料，避免因資料孤立和未記錄而造成作業瓶頸和不確定性。
資料情境與中繼資料的差異
雖然中繼資料是基礎建構模塊，但「中繼資料」和「情境」並非可互換的概念：
- 中繼資料。描述性屬性，用於定義獨立資料資產的基礎結構、位置和技術屬性 (例如資料欄名稱、資料類型、分區索引鍵和資料表大小)。
- 背景資訊：綜合多維度知識圖譜，結合技術結構定義、業務語意、資料關係、作業行為和信任信號，賦予資料意義並引導推論。
Knowledge Catalog 將中繼資料管理從被動目錄，轉變為動態控制層，下表重點列出被動中繼資料和主動資料情境之間的主要差異：
| 維度 | 技術中繼資料 | 使用中的資料脈絡 |
|---|---|---|
| 核心重點 | 基礎規格和儲存格式。 | 業務意義、作業行為和關係。 |
| 「State」 | 被動：儲存在目錄註冊資料庫中，供工程師手動查詢。 | 主動：由 AI 持續擴充、從查詢記錄中挖掘，並動態組合成 LLM 提示。 |
| 主要消費者 | 資料庫引擎、資料工程師和法規遵循稽核人員。 | AI 代理、大型語言模型 (LLM)、業務分析師和對話式介面。 |
| 主要目的 | 儲存空間管理、索引建立和法規遵循驗證。 | 建立代理推論基準、解決彙整問題，以及防範幻覺。 |
範例：中繼資料與背景資訊的比較
如要瞭解情境如何擴充技術中繼資料，請思考 Knowledge Catalog 如何呈現交易資料欄：
單靠技術中繼資料
技術中繼資料提供結構資訊，但缺乏商業邏輯和作業指南：
- 表格：
fact_orders - 欄：
disc_val - 資料類型：
NUMERIC - 儲存空間屬性：依
order_date分區
如果 AI 代理只使用這項技術中繼資料，可能會猜測 disc_val 代表客戶折扣總額，但無法判斷該值是否包含稅金、製造商回扣或促銷優待券。
充實的資料脈絡
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 代理通常會生成不準確的答案 (幻覺) 或無法執行動作。
如果沒有結構化背景資訊，組織會面臨多項營運瓶頸：
協作工作。如果業務定義不明確，數據分析和 AI 團隊就必須與領域專家 (SME) 持續手動協調，才能對資料表建立基本瞭解。
情境偏移。標準說明文件會保持靜態，並隨著時間過時。如果沒有持續監控，過時的中繼資料會導致錯誤假設，並中斷 AI 代理工作流程。
推論失敗。AI 代理和大型語言模型可能會生成語法正確的 SQL 查詢，但無法遵循基礎企業邏輯，導致從業務角度來看計算結果不正確。
資訊分散：如何正確篩選或彙整資料集的內部知識，仍留存在未記錄的指令碼或資訊主頁設定中，而非登錄在集中式目錄。
為克服這些作業瓶頸，並讓資料發揮作用，組織需要可靠的脈絡引擎，涵蓋整個資料資產。
情境管理的核心要素
為確保資料資產中的脈絡引擎可靠，Knowledge Catalog 運作時會遵循三大原則：
匯總
Knowledge Catalog 會自動從內建資料庫、Iceberg REST 目錄和第三方平台收集中繼資料。這項功能會將這些分散的輸入內容整合至單一、統一的管理區域，確保安全性政策和分類定義能一致繼承。
擴充
資料監管者和脈絡工程師可使用 Knowledge Studio 介面，持續更新及整理整體脈絡圖中的特定脈絡集。Knowledge Catalog 會自動挖掘交易記錄、資料庫結構定義和商業智慧模型，找出資料欄說明和資料表關係。透過 Knowledge Studio 介面，人工審查員可以持續學習，掌握機構知識，並動態套用至資產。
搜尋與擷取
Knowledge Catalog 提供高精確度的語意搜尋功能，可讓您以自然語言查詢資料資產。Knowledge Catalog 瞭解權限群組 (ACL) 和業務術語，因此使用者和自主代理都能以低延遲找出相關資料背景資訊。
如何將中繼資料和背景資訊提供給 Knowledge Catalog
為建構可靠的內容比對引擎，Knowledge Catalog 會透過自動化平台連接器、持續的 AI 擴充和可擴充的自訂介面，擷取及整理資訊。
第一方資料來源和自動收集
Knowledge Catalog 會自動從核心 Google Cloud 服務收集結構和作業中繼資料，不需手動設定：
- 資料庫和分析倉儲。BigQuery、Spanner、Cloud SQL 和 AlloyDB for PostgreSQL 等服務會持續同步技術中繼資料，包括資料表結構定義、欄位資料類型、分區索引鍵、分群規格和資料集邊界。
現成的 BI 語意同步功能。如果是 Looker (Google Cloud 核心)，Knowledge Catalog 會自動同步處理商業智慧資產：
- LookML 語意定義。模型、探索、檢視表、維度和測量指標。
- 商業智慧資訊主頁資產。資訊主頁、資訊主頁元素和 Look 圖表。
資料整合和轉換。Datastream 等服務會擷取變更資料擷取 (CDC) 串流中繼資料，Dataform 會推送資料表定義和 SQL 轉換，Cortex Framework 則會發布已註冊的資料產品。
持續由 AI 驅動的內容管理
除了靜態技術結構定義外，Knowledge Catalog 還會使用內建智慧引擎，動態更新脈絡圖：
- 資料洞察：資料洞察功能採用 Gemini in BigQuery 技術，可挖掘歷來查詢記錄、使用者交易和結構定義模式，生成自然語言資料欄說明、探索資料表關係 (例如彙整鍵)，並提出經驗證的查詢範例 (「精確查詢」)，擷取企業邏輯。詳情請參閱「關於結構化資料的資料洞察」。
- 自動剖析資料並評估資料品質。掃描作業會計算統計分布 (例如不重複計數、空值比率和樣本值)，並根據規則式資料品質檢查評估資料，將即時健康分數附加至目錄項目。詳情請參閱「關於自動資料品質」。
透過 Knowledge Studio 進行人工介入迴路
使用者可在 Knowledge Studio 中管理及自動調度使用中的情境圖。這個介面是主要中心，可供您：
- 脈絡資料集。將相關資料表、非結構化文件和詞彙表分組為統一套件，供 AI 代理使用。
- 資料充實工作流程。查看 AI 建議的資料欄說明、套用組織詞彙對應，以及手動將資產認證為權威。詳情請參閱「管理擴充執行作業」。
- 環境組織。確保不同的網域團隊 (例如財務或工程團隊) 有各自獨立的區域，可管理語意規則。
詳情請參閱「使用 Knowledge Studio 充實背景資訊」。
自訂中繼資料擷取和第三方系統
如果組織有自訂知識庫、第三方治理工具或地端部署系統，Knowledge Catalog 可提供彈性的擷取機制：
- Knowledge Catalog API (CRUD 作業)。使用
CreateEntry、UpdateEntry和CreateAspectTypeAPI 方法，以程式輔助方式註冊外部資產，並附加自訂中繼資料層面 (例如法規遵循評等或系統說明文件)。 - 自訂擴充代理。使用 Agent Development Kit (ADK) 或 LangChain 等代理框架，建構自訂擴充代理。舉例來說，ADK 代理可以從內部 Wiki 或 Git 存放區擷取技術文件，使用 LLM 將文件剖析為標準化的組織詞彙，並附加至目錄項目。詳情請參閱「建構 AI 代理來充實中繼資料」。
- 匯出和匯入作業。使用檔案式 (JSON 或 CSV) 大量匯出和匯入工作流程，查看 AI 生成的業務定義、與資料監管人員協作，以及批次更新中繼資料。詳情請參閱「匯出中繼資料」。
第一方和第三方服務如何使用脈絡
服務和應用程式與 Knowledge Catalog 互動時，會扮演兩種不同的角色：
- 中繼資料供應商。將技術中繼資料、結構定義和 LookML 定義傳送至 Knowledge Catalog 的服務 (例如 Looker、Cloud SQL 和 Spanner)。中繼資料提供者會將中繼資料推送至目錄，但不一定會將組織詞彙定義納入自己的使用者介面。
- Context 消費者。服務、開發人員工具和 AI 代理，可從 Knowledge Catalog 擷取業務定義、作業設定檔和治理規則，做為推論和執行的依據。
應用程式和代理必須先建立基礎業務術語和品質規則，才能使用情境資訊。詳情請參閱「建立基礎資料情境」和「建構政策即程式碼資料品質工作流程」。
AI 應用程式和服務會透過下列機制，使用 Knowledge Catalog 的情境資訊：
內建第一方 (1P) 整合功能
多項 Google Cloud 服務會原生查詢 Knowledge Catalog，提供依據情境調整的 AI 體驗：
- Gemini in BigQuery (對話式代理)。在 BigQuery Studio 輸入自然語言提示時，Gemini 會在背景自動查詢 Knowledge Catalog 組織詞彙定義、資料欄說明和歷史查詢關係。這可讓 Gemini 建立企業業務術語基準，確保生成的 SQL 查詢使用正確的資料表彙整和指標定義。
- BigQuery 的資料工程代理。探索及查詢 Apache Iceberg 和 BigQuery 資料表、自動叫用語意目錄搜尋來解決資產依附元件問題，並在管道執行期間產生目錄中繼資料。
- Gemini 和 Agent Builder。以 Gemini 建構的自訂生成式 AI 代理和搜尋應用程式，會使用目錄中繼資料和業務規則，根據經過驗證的企業事實建立模型推論基準。
- Google Cloud 控制台和商家 UI。使用者和資料監管者可透過自然語言語意搜尋功能探索資產、查看互動式資料關係圖，以及管理組織詞彙。
第三方應用程式和 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。本機 CLI Proxy，可與開發人員 IDE (例如 VS Code 和 Cursor) 和本機開發工作流程整合。詳情請參閱「搭配本機 MCP Toolbox 伺服器使用 Knowledge Catalog」。
使用 LookupContext API 擷取預先格式化的背景資訊
針對自訂 AI 管道和 LLM 應用程式，Knowledge Catalog 提供 LookupContext API 方法。
LookupContext 方法可透過單一要求，擷取統一且預先格式化的豐富中繼資料套件，不必讓代理程式依序發出多個呼叫來檢查結構定義、查詢詞彙、擷取資料品質分數，以及檢查查詢記錄。
LookupContext 方法的主要功能包括：
- LLM 適用格式。傳回格式為
yaml(預設)、json或xml的內容，可直接插入 LLM 系統提示。 - 權杖預算 (
context_budget)：可指定目標字元預算。這是軟性預算，也就是說，API 會智慧截斷中繼資料並排定優先順序，盡可能符合模型的脈絡窗口，但不保證一定會低於限制。 - 可設定的背景資訊檢視畫面。
- BASIC。傳回基本項目中繼資料、結構定義、資料欄說明、總覽文字和代理指南。
- 標準。除了基本中繼資料外，還會周遊情境圖，納入多資料表彙整關係、附加的組織詞彙字詞和同義詞，以及經過驗證的範例查詢。
- 探索到的彙整和精確查詢。包括推論出的資料表彙整條件 (例如
orders.customer_id = customers.id) 和經過驗證的 SQL 查詢範例。
詳情請參閱「擷取資料資產的背景資訊」和 lookupContext REST 參考資料。
背景資訊如何協助使用者和 AI 代理
Knowledge Catalog 將技術結構定義、業務語意和品質指標整合至主動式情境層，在代理式資料雲端中提供通用情境。Knowledge Catalog 透過 Model Context Protocol (MCP)、Context Retrieval API 和語意搜尋等開放介面公開這類中繼資料，協助使用者和自主系統。
免除使用者手動驗證信任的工作
如果沒有集中的語意層，就必須調查基礎資料庫和查詢記錄，才能回答基本的業務問題。標準目錄是被動的結構定義目錄，您必須手動查詢指標定義或驗證資料表是否乾淨。
Knowledge Catalog 可將這種被動治理轉化為主動智慧。Knowledge Catalog 會直接在資料資產旁顯示品質分數、語意說明和使用警告，讓您不必等待工程審查，就能放心使用資料。
建立自主代理並啟用動態管理
AI 代理和大型語言模型 (LLM) 需要嚴格、確定的規則，才能與資料庫互動。如果沒有明確的語意背景資訊，代理可能會對資料欄名稱做出錯誤假設，或生成錯誤的 SQL 查詢。
此外，主動式情境會將中繼資料管理從被動式登錄檔轉換為主動式治理層。組織可直接在 Knowledge Catalog 中定義經過驗證的業務規則、指標和代理指令，控管代理如何擷取、評估及處理企業資料。
Knowledge Catalog 可解決這項問題。並透過 Model Context Protocol (MCP) 或 LookupContext API 等標準介面，將統一的使用中情境設定檔匯出至 AI 應用程式。以這類中繼資料建立模型基準，可盡量減少幻覺、強制執行管理規則，並確保自主行動是以經過驗證的組織事實為依據。
AI 應用程式如何使用情境集
Gemini Enterprise 和其他 AI 應用程式會透過兩種主要模式，使用情境集：
使用語意搜尋動態探索情境：在對話式或自助式數據分析環境中，使用者會以自然語言提出臨時問題 (例如「我們公司帳戶的季度淨留存率是多少？」)。使用者提交提示詞時，代理會對 Knowledge Catalog 發出語意搜尋查詢，找出與問題領域最相關的背景資訊集。代理會將擷取的背景資訊插入有效提示，以便針對基礎資料倉儲生成準確的 SQL 查詢。
專用應用程式的預先設定情境集：您可以在設定期間提供資源 URI，預先設定具有明確情境集參照的代理。繫結專屬情境集可提供確定性的基準，確保日後所有互動都一致使用經過認證的業務定義，不會產生執行階段搜尋負擔。由於週期性擴充工作會隨著時間推移精進背景資訊集，下游應用程式會自動繼承這些品質改善項目，不需手動重新提示或重新部署應用程式。
Knowledge Catalog 透過 Model Context Protocol (MCP) 或 LookupContext API 等標準介面，將統一的主動情境設定檔匯出至 AI 應用程式，盡可能減少幻覺並強制執行管理規則。
透過共用情境協調多代理工作流程
在多代理架構 (或群體) 中，不同的專門代理會協同運作，執行複雜的工作流程。如果這些代理在孤立的環境中運作，沒有共用的情境平面，就會面臨「情境上限」，可能使用衝突的業務規則、無法找到相關依附元件，或重複擷取作業。
將 Knowledge Catalog 做為集中式情境登錄檔，可協助您協調及擴充多代理群。在 Knowledge Catalog 中建立群體基準，可帶來下列好處：
共用業務語意。所有代理都參照相同的業務含義和定義。舉例來說，如果資料分析代理和報表代理都擷取含有銷售數據的資料表，則會使用相同的詞彙定義指標 (例如
Gross Merchandise Value (GMV))，確保一致性。動態依附元件解析。代理程式可使用情境關係，以程式輔助方式探索上游和下游資源。這樣一來，管道疑難排解代理就能追蹤資料失敗的原因，並將工作交給修復代理，不必硬式編碼依附元件規則。
統合連線介面。使用 Model Context Protocol (MCP)，即可向整個群體公開單一語意端點。這樣一來，您就不必為每個代理設定自訂 API 整合。
Perimeter-level security governance (Perimeter 層級安全防護機制)Knowledge Catalog 會根據預先設定的 IAM 角色，檢查代理查詢。這可確保代理只會擷取明確授權存取的資源背景資訊，避免群體中的資料意外外洩。
使用資料背景資訊的用途
如要瞭解資料情境如何解決複雜的查詢，請思考 Knowledge Catalog 在實務上如何套用技術、語意和作業層：
電子商務：個人化搜尋推薦
為配合產品庫存調整季節性行銷廣告活動，搜尋代理必須瞭解非結構化促銷電子郵件與結構化產品目錄和使用者交易資料表之間的關聯。Knowledge Catalog 會對應這些實體，讓推薦模型即時建議相關產品。
製造業：最佳化機械維護
預測性維護模型需要整合結構化零件記錄、非結構化技術人員維修指南，以及即時感應器動態饋給。Knowledge Catalog 會對應零件編號和手冊章節之間的關係，讓分析系統預測設備疲勞，並在故障發生前安排維修。
醫療照護：驗證臨床試驗資料
臨床研究中心必須確認病患統計資料符合嚴格的研究規則，且病患同意書記錄直接對應至試驗結果資料集。Knowledge Catalog 會對應脈絡關係，稽核同意書管道，並在資料剖析異常時提醒研究人員，有助於維護試驗完整性。
金融服務：評估信用風險
貸款承銷模型會使用客戶信用評分、交易記錄和有效債務餘額，這些資料來自不同的來源系統。Knowledge Catalog 提供統一的貸款指標圖表，讓承保工具確認風險評估使用經過認證且符合規範的資產。
電信：診斷網路營運
自主網路管理系統和代理會分析即時訊號行為、偵測效能降低情形，並採取自我修復修正措施。只要將這些代理建立在 Knowledge Catalog 的脈絡中，系統就能安全地對應技術記錄與業務服務領域之間的關係。