使用 Agent Platform 和 Spanner Graph 建構生成式 AI 的 GraphRAG 基礎架構

Last reviewed 2026-10-16 UTC

本文件提供參考架構，協助您在 Google Cloud中設計 GraphRAG 生成式 AI 應用程式的基礎架構。目標對象包括建構及管理智慧型資訊檢索系統的架構師、開發人員和管理員。本文假設您已具備 AI、圖形資料管理和知識圖譜概念的基本知識。本文不提供設計及開發 GraphRAG 應用程式的具體指引。

GraphRAG 是以圖表為基礎的檢索增強生成 (RAG) 方法。RAG 會使用向量搜尋擷取與情境相關的資料，並用這些資料強化提示，藉此為 AI 生成的回覆建立基準。GraphRAG 結合向量搜尋和知識圖譜查詢，擷取能更準確反映不同來源資料互連關係的比對內容資料。使用 GraphRAG 增強的提示詞，可生成更詳細且相關的 AI 回覆。

架構

下圖顯示 Google Cloud中支援 GraphRAG 的生成式 AI 應用程式架構：

架構中的資料擷取和提供流程。

上圖中的架構包含兩個子系統：資料擷取和服務。以下各節說明子系統的用途，以及子系統內部和之間的資料流程。

資料擷取子系統

資料擷取子系統會從外部來源擷取資料，然後為 GraphRAG 準備資料。資料擷取和準備流程包含下列步驟：

  1. 資料會擷取至 Cloud Storage bucket。這項資料可由資料分析師上傳、從資料庫擷取，或從任何來源串流。
  2. 資料擷取後，系統會將訊息傳送至 Pub/Sub 主題。
  3. Pub/Sub 會觸發 Cloud Run 函式來處理上傳的資料。
  4. Cloud Run 函式會使用 Gemini API 和 LangChain 的 LLMGraphTransformer 等工具，從輸入檔案建構知識圖譜。
  5. 這個函式會將知識圖譜儲存在 Spanner Graph 資料庫中。
  6. 這個函式會使用 LangChain 的 RecursiveCharacterTextSplitter 或 Document AI 的版面配置剖析器等工具，將資料檔案的文字內容分割成精細單位。
  7. 函式會使用 Gemini Enterprise Agent Platform Embeddings API，建立文字片段的向量嵌入。
  8. 這個函式會將向量嵌入和相關聯的圖表節點儲存在 Spanner Graph。

向量嵌入是語意檢索的基礎。知識圖譜節點可讓您遍歷及分析複雜的資料關係和模式。

服務子系統

服務子系統會管理生成式 AI 應用程式和使用者之間的查詢/回覆生命週期。提供流程包含下列步驟：

  1. 使用者向 AI 代理提交自然語言查詢，該代理部署於 Gemini Enterprise Agent Platform 的 Agent Runtime。
  2. 代理會按照下列步驟處理查詢：
    1. 使用 Agent Platform Embeddings API 將查詢轉換為向量嵌入。
    2. 在嵌入資料庫中執行向量相似度搜尋，擷取與查詢相關的圖表節點。
    3. 透過遍歷知識圖譜，擷取與查詢相關的資料。
    4. 結合原始查詢和擷取的圖表資料，擴充提示。
    5. 使用 Agent Search 排名 API 排序結果，其中包含從圖形資料庫擷取的節點和邊緣。排名依據是與查詢的語意關聯性。
    6. 呼叫 Gemini API 總結結果。
  3. 接著，代理會將摘要結果傳送給使用者。

您可以在 Cloud Logging 儲存及查看查詢/回覆活動記錄，並使用 Cloud Monitoring 設定記錄指標監控。

使用的產品

這個參考架構使用下列 Google 產品和工具：

  • Spanner Graph：提供 Spanner 擴充性、可用性和一致性功能的圖形資料庫。
  • Gemini Enterprise Agent Platform：全方位平台，可建構、擴充、管理及最佳化企業級 AI 代理。
  • Cloud Run functions：無伺服器運算平台，可讓您直接在 Google Cloud中執行單一用途函式。
  • Cloud Storage：適用於多種資料類型的物件儲存庫，成本低廉且沒有限制。資料在 Google Cloud內外都能存取，且會複製到多個位置，以便提供備援機制。
  • Pub/Sub：可擴充的非同步訊息服務，會分離產生訊息的服務與處理訊息的服務。
  • Cloud Logging：即時記錄管理系統，提供儲存、搜尋、分析和警告通知功能。
  • Cloud Monitoring：這項服務可讓您掌握應用程式和基礎架構的效能、可用性和健康狀態。

用途

GraphRAG 可協助各產業的應用實例智慧檢索資料。本節將說明醫療保健、金融、法律服務和製造業的幾個用途。

醫療保健和製藥：臨床決策支援

在臨床決策支援系統中，GraphRAG 可將醫學文獻、病患電子健康記錄、藥物交互作用資料庫和臨床試驗結果等大量資料，整合至統一的知識圖譜。當臨床醫師和研究人員查詢病患的症狀和目前用藥時，GraphRAG 會遍歷知識圖譜，找出相關病症和潛在的藥物交互作用。也能根據其他資料 (例如病患的基因剖析) 生成個人化治療建議。相較於關鍵字比對，這種資訊檢索方式能提供更豐富、更有根據的答案。

金融服務：整合財務資料

金融服務公司使用知識圖譜，讓分析師能統一查看來自不同來源的結構化資料，例如分析師報告、法人說明會和風險評估。知識圖譜會識別公司和高階主管等重要資料實體，並對應實體之間的重要關係。這種做法可提供豐富、相互連結的資料網路，讓財務分析更深入、更有效率。分析師可發掘先前隱藏的洞察資訊，例如複雜的供應鏈依附關係、與競爭對手有所重疊的董事會成員，以及面臨的複雜地緣政治風險。

在法律領域，GraphRAG 可根據判例、法規、判例法、法規更新和內部文件，生成個人化法律建議。律師準備案件時，可以針對特定法律論點、類似案件的過往判決，或新法規的影響，提出細緻的問題。GraphRAG 會利用現有法律知識的互連性，找出相關判例並說明其適用性。還能追蹤法律概念、法規和司法解釋之間的關係，提出反駁論點。相較於傳統的知識檢索方法，這種做法可讓法律從業人員獲得更全面、更精確的洞察資訊。

製造與供應鏈：發掘機構知識

製造和供應鏈作業需要高度精確。然而，要維持必要精確度，相關知識往往埋藏在數千份密密麻麻的靜態標準作業程序 (SOP) 文件中。當工廠的生產線或機器故障，或發生物流問題時，工程師和技術人員往往會浪費寶貴的時間，在不連貫的 PDF 文件中搜尋，以診斷及排解問題。結合知識圖譜和對話式 AI，可將隱藏的機構知識轉化為互動式診斷夥伴。

設計替代方案

本文說明的架構為模組化架構。您可以根據需求，調整架構的某些元件，改用其他產品、工具和技術。

建構知識圖譜

您可以使用 LangChain 的 LLMGraphTransformer 工具，從頭開始建構知識圖譜。使用 allowed_nodes、allowed_relationships、node_properties 和 relationship_properties 等 LLMGraphTransformer 參數指定圖表結構定義，即可提升產生的知識圖譜品質。不過，LLMGraphTransformer 可能會從一般網域擷取實體，因此可能不適用於醫療保健或製藥等利基網域。此外，如果貴組織已有完善的知識圖譜建構程序，則可選擇是否採用本參考架構中所示的資料擷取子系統。

儲存知識圖譜和向量嵌入

本文件中的架構使用 Spanner 做為知識圖譜「和」向量嵌入的資料儲存庫。如果企業知識圖譜已存在於其他位置 (例如 Neo4j 等平台)，則可考慮使用向量資料庫儲存嵌入。不過，這種做法需要額外的管理工作，而且可能需要更多費用。Spanner 提供整合式、全球一致的資料儲存庫，可同時儲存圖譜結構和向量嵌入。這類資料儲存庫可統一管理資料，有助於最佳化成本、效能、安全性治理和作業效率。

Agent Runtime

在這個參考架構中，代理會部署在 Agent Runtime，為 AI 代理提供代管執行階段。其他可考慮的選項包括 Cloud Run 和 Google Kubernetes Engine (GKE)。這些選項的討論不在本文件的範圍內。

使用 RAG 建立基準

如「用途」一節所述，GraphRAG 可在多種情境下，以智慧方式擷取資料，用於建立基準。不過，如果用於擴增提示的來源資料沒有複雜的相互關係，RAG 可能適合用於生成式 AI 應用程式。

下列參考架構說明如何使用支援向量的代管資料庫或專門的向量搜尋產品，在 Google Cloud 中建構 RAG 所需的基礎架構：

設計須知

本節說明使用這個參考架構開發拓撲時，應考量的設計因素、最佳做法和建議，以滿足您在安全性、可靠性、成本和效能方面的特定需求。

本節中的指引並未涵蓋所有情況。視工作負載的需求，以及您使用的 Google Cloud 和第三方產品與功能而定，您可能需要考量其他設計因素和取捨。

安全性、隱私權和法規遵循

本節說明在 Google Cloud 中設計拓撲時，應考量的設計事項和建議，以符合工作負載的安全性和法規遵循要求。

Agent Platform 安全性考量

為確保 Agent Platform 設定和使用方式符合安全性需求，請考慮下列建議：

Spanner Graph 資料加密

根據預設，儲存在 Spanner Graph 的資料會使用 Google-owned and Google-managed encryption keys加密。如需使用您控管及管理的加密金鑰，可以使用客戶自行管理的加密金鑰 (CMEK)。詳情請參閱「關於 CMEK」。

Cloud Run functions 安全性考量

為確保 Cloud Run functions 實作符合安全性需求，建議您採取下列做法：

  • 資料加密：Cloud Run 預設會使用 Google-owned and Google-managed encryption keys加密資料。如要使用您控管的金鑰保護容器，可以使用 CMEK。詳情請參閱「使用客戶自行管理的加密金鑰」。
  • 容器映像檔安全性：為確保只有授權的容器映像檔部署至 Cloud Run，您可以使用二進位授權。
  • 資料落地：Cloud Run 可協助您符合資料落地規定。Cloud Run 函式會在所選區域內執行。

Cloud Storage 安全性考量

為確保 Cloud Storage 設定符合安全性需求，建議您採取下列做法：

  • 資料加密：根據預設，儲存在 Cloud Storage 中的資料會使用Google-owned and Google-managed encryption keys加密。如有需要，您可以使用 CMEK，或透過外部管理方法 (例如客戶提供的加密金鑰 (CSEK)) 自行管理金鑰。詳情請參閱「資料加密選項」。
  • 存取控管：Cloud Storage 支援兩種方法，可授予使用者值區和物件的存取權：Identity and Access Management (IAM) 和存取控管清單 (ACL)。在多數情況下，建議您使用 IAM，在 bucket 和專案層級授予權限。詳情請參閱「存取控管總覽」。
  • 資料保護：您透過 Cloud Storage 載入資料擷取子系統的資料可能包含機密資料。您可以使用 Sensitive Data Protection 探索、分類及去識別化機密資料。詳情請參閱「搭配運用 Cloud Storage 和 Sensitive Data Protection」。
  • 資料落地：Cloud Storage 可協助您符合資料落地規定。資料會儲存或複製到您指定的區域。

Pub/Sub 安全性考量

為確保 Pub/Sub 設定符合安全性需求，建議您採取下列做法：

  • 資料加密：Pub/Sub 預設會使用Google-owned and Google-managed encryption keys加密所有靜態和傳輸中的訊息。Pub/Sub 支援在應用程式層使用 CMEK 加密訊息。詳情請參閱「設定郵件加密」。
  • 資料落地：如有資料落地需求，可以設定訊息儲存政策，確保訊息資料儲存在特定位置。

Cloud Logging 安全性考量

為確保 Cloud Logging 設定符合安全性需求，請考量下列設計因素和建議：

  • 管理活動稽核：此參考架構中使用的所有 Google Cloud 服務，預設都會啟用管理員活動稽核記錄。這類記錄會記載 API 呼叫，或是修改 Google Cloud 資源設定或中繼資料的其他動作。
  • 資料存取稽核：針對這個架構中使用的 Google Cloud 服務，您可以啟用資料存取稽核記錄。這類記錄可讓您追蹤讀取資源設定或中繼資料的 API 呼叫，或建立、修改或讀取使用者提供資源資料的使用者要求。
  • 資料落地：為符合資料落地規定，您可以設定 Cloud Logging，將記錄資料儲存在指定區域。詳情請參閱「將記錄檔區域化」。

如要瞭解 AI 和機器學習工作負載專屬的安全原則和建議，請參閱 Google Cloud Well-Architected Framework 中的「AI 和機器學習觀點：安全性」。

可靠性

本節說明設計考量和建議，協助您在 Google Cloud中建構及運作可靠的基礎架構。

Agent Platform 容量和端點可用性

如果要求數量超過分配的容量，系統會傳回錯誤代碼 429。如果工作負載對業務至關重要，且持續需要高處理量，您可以使用佈建處理量預留處理量。如果資料可以跨多個區域或國家/地區共用，則可使用全域端點。

Spanner Graph 資料可用性和災難復原

Spanner 專為高資料可用性和全球擴充性而設計。為確保即使區域中斷服務，資料仍可供使用，Spanner 提供多區域設定，可在多個區域的多個可用區中複製資料。除了這些內建的復原功能外，Spanner 還提供下列功能，可支援全方位的災難復原策略：

  • 資料庫防刪除功能
  • 強大的備份與還原功能，包括排定和跨區域複製
  • 時間點復原 (PITR) 功能可防止邏輯資料損毀、操作員錯誤或意外寫入，最長可達七天

詳情請參閱「災難復原總覽」。

Cloud Run functions 具備基礎架構中斷因應能力

Cloud Run 是區域性服務。資料會同步儲存在區域內的多個可用區。流量會自動在各可用區之間進行負載平衡。如果可用區服務中斷，Cloud Run 會繼續運作，資料也不會遺失。如果發生區域服務中斷，服務會停止運作，直到 Google 解決服務中斷問題為止。

Cloud Storage 資料可用性

您可以在三種位置類型中建立 Cloud Storage bucket：單一區域、雙區域或多區域。儲存在區域 bucket 中的資料，會同步複製到區域內的多個可用區。如要提高可用性，可以使用雙區域或多區域 bucket，資料會以非同步方式跨區域複製。

Pub/Sub 可靠性考量

為確保 Pub/Sub 設定符合可靠性需求，請考慮下列建議：

  • 速率控制：為避免訊息流量暫時激增時發生錯誤，您可以在發布者設定中設定流量控制，限制發布要求的速率。
  • 失敗處理：如要處理失敗的發布嘗試，請視需要調整重試要求變數。詳情請參閱「重試要求」。

架構中所有產品的可靠性建議

在 Google Cloud部署工作負載後，請套用 Active Assist 的相關建議，進一步提高雲端資源的可靠性。

如要瞭解 AI 和機器學習工作負載專屬的可靠性原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：可靠性」。

成本最佳化

本節提供指引，說明如何最佳化使用此參考架構建構的 Google Cloud 拓撲，降低設定和營運成本。

Agent Platform 費用考量

為確保 Agent Platform 設定和用量符合成本需求，建議您採取下列做法：

  • 成本分析與管理：如要分析及管理 Agent Platform 成本，建議您建立每秒查詢次數 (QPS) 和每秒權杖數 (TPS) 的基準，並在部署後監控這些指標。基準也有助於規劃容量。舉例來說，基準可協助您判斷何時需要佈建輸送量。
  • 模型選取：為生成式 AI 應用程式選取合適的模型是一項重要決策，會直接影響成本和效能。如要找出在效能和成本之間取得最佳平衡的模型，請反覆測試模型。建議您先從最具成本效益的模型開始，再逐步改用更強大的選項。
  • 提示工程：提示 (輸入) 和生成的回覆 (輸出) 長度會直接影響效能和成本。撰寫簡短、直接且提供充分背景資訊的提示。 設計提示，讓模型提供簡潔的回覆。例如，加入「用 2 句話總結」或「列出 3 個重點」等詞句。詳情請參閱提示設計最佳做法。
  • 脈絡快取：如果要求包含重複內容，且輸入詞元數量較多，請使用脈絡快取，降低這類要求的成本。
  • 批次要求：如果是可非同步執行的大規模處理工作 (例如內容生成和離線分析)，建議使用批次推論。批次要求的費用低於標準要求。

Spanner Graph 費用注意事項

為確保 Spanner Graph 設定符合成本需求，請參考下列建議：

  • 運算容量自動調整資源配置：使用代管自動配置器，根據 CPU 使用率和儲存空間需求，動態調整 Spanner Graph 資料庫的運算容量，控管成本。即使是小型工作負載，通常也需要最低容量。
  • 費率最佳化：針對可預測、穩定或基準運算容量，購買承諾使用折扣 (CUD)。只要承諾每小時在運算能力上達到一定的支出，即可享有大幅折扣。
  • 備份複製：將備份複製到不同區域，用於災難復原或法規遵循時，請考量網路輸出費用。為降低費用，請只複製必要的備份。

Cloud Run functions 成本考量

為確保 Cloud Run functions 實作符合成本需求，建議您採取下列做法：

  • 資源分配：建立 Cloud Run functions 時，您可以指定要分配的記憶體和 CPU 數量。如要控制成本，請先使用預設 (最低) CPU 和記憶體配置。如要提升效能，您可以設定 CPU 限制和記憶體限制，增加分配量。詳情請參閱下列說明文件：

  • 費率最佳化：如果能預測 CPU 和記憶體需求， 可以透過承諾使用折扣節省費用。

Cloud Storage 儲存空間級別和生命週期管理

針對資料擷取子系統中的 Cloud Storage bucket，請根據工作負載對資料保留和存取頻率的需求，選擇適當的儲存空間級別。舉例來說，如要控管儲存空間費用，您可以選擇 Standard 級別，並使用物件生命週期管理功能。這種做法可讓系統根據指定條件，自動將物件降級至費用較低的儲存空間級別，或自動刪除物件。

Cloud Logging 成本考量

如要控管儲存記錄的費用，建議採取下列做法：

架構中所有產品的成本最佳化建議

為確保架構符合成本需求，建議您參考下列一般建議：

如要瞭解 AI 和機器學習工作負載專屬的成本最佳化原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：成本最佳化」。

效能最佳化

本節說明設計考量和建議，協助您在 Google Cloud 中設計符合工作負載效能需求的拓撲。

Agent Platform 效能注意事項

為確保 Agent Platform 設定和用量符合效能需求，請參考下列建議：

  • 模型選取：為生成式 AI 應用程式選取合適的模型是一項重要決策，會直接影響成本和效能。如要找出在效能和成本之間取得最佳平衡的模型，請反覆測試模型。建議您先從最具成本效益的模型開始，再逐步改用更強大的選項。
  • 提示工程：提示 (輸入) 和生成的回覆 (輸出) 長度會直接影響效能和成本。撰寫簡短、直接且提供充分背景資訊的提示。 設計提示，讓模型提供簡潔的回覆。例如，加入「用 2 句話總結」或「列出 3 個重點」等詞句。詳情請參閱提示設計最佳做法。
  • 提示最佳化：Agent Platform 提示最佳化工具可讓您快速大規模改善及最佳化提示成效，不必手動重寫。最佳化工具可協助您有效率地調整提示，以便在不同模型中使用。

Spanner Graph 結構定義設計和查詢調整

如需最佳化 Spanner Graph 效能的建議，請參閱下列說明文件：

Cloud Run functions 資源分配

根據預設，每個 Cloud Run 函式執行個體都會分配到一個 CPU 和 256 MiB 的記憶體。您可以根據效能需求，設定 CPU 和記憶體限制。詳情請參閱下列說明文件：

如需更多效能最佳化指南，請參閱「Cloud Run 一般開發提示」。

Cloud Storage 平行複合上傳

如要上傳大型檔案，可以使用平行複合上傳功能。這項策略會將大型檔案分割成多個區塊，這些區塊會平行上傳至 Cloud Storage，然後在雲端重新組合。如果網路頻寬和磁碟速度不是限制因素，平行複合上傳的速度可能會比一般上傳作業快。不過，這項策略有一些限制和成本影響。詳情請參閱「平行複合上傳」。

架構中所有產品的效能最佳化建議

在 Google Cloud中部署工作負載後，請套用 Active Assist 的相關建議，進一步最佳化雲端資源的效能。

如要瞭解 AI 和機器學習工作負載專屬的效能最佳化原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：效能最佳化」。

部署作業

如要瞭解 GraphRAG 在 Google Cloud中的運作方式，請從 GitHub 下載並執行下列 Jupyter 筆記本：在 Google Cloud 上使用 Spanner Graph 和 Gemini Enterprise Agent Platform 的 Agent Runtime 執行 GraphRAG。

後續步驟

貢獻者

作者：

其他貢獻者：