使用 Vertex AI 和 AlloyDB for PostgreSQL 建構具備 RAG 功能的生成式 AI 應用程式基礎架構

Last reviewed 2024-12-11 UTC

本文提供參考架構，協助您設計基礎架構，以執行檢索增強生成 (RAG) 生成式人工智慧 (AI) 應用程式。本文適用對象包括生成式 AI 應用程式的開發人員和管理員，以及雲端架構師。本文假設您已具備 AI、機器學習 (ML) 和大型語言模型 (LLM) 概念的基本知識。本文不會提供如何設計及開發生成式 AI 應用程式的指引。

架構

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

這張圖概略呈現 Google Cloud中支援 RAG 的生成式 AI 應用程式架構。

此架構包含下列相互連結的元件：

元件 目的 互動
資料擷取子系統 準備及處理用於啟用 RAG 功能的外部資料。 資料擷取子系統會透過資料庫層，與架構中的其他子系統互動。
服務子系統 處理生成式 AI 應用程式與使用者之間的要求/回覆流程。 服務子系統會透過資料庫層與資料擷取子系統互動。
品質評估子系統 評估服務子系統生成的回覆品質。 品質評估子系統會直接與服務子系統互動，並透過資料庫層與資料擷取子系統互動。
資料庫 儲存下列資料：
  • 提示
  • RAG 所用資料的向量嵌入
  • 資料擷取和品質評估子系統的無伺服器工作設定
 架構內的所有子系統都會與資料庫互動。

下圖詳細呈現相關架構：

這張圖詳細呈現 Google Cloud上支援 RAG 的生成式 AI 應用程式架構。

以下各節會針對架構內的子系統詳細說明各個元件和資料流程。

資料擷取子系統

資料擷取子系統從檔案、資料庫和串流服務等外部來源擷取資料。上傳的資料包含用於評估品質的提示。資料擷取子系統在架構中的用途，是提供 RAG 功能。下圖詳細說明架構中的資料擷取子系統：

Google Cloud中支援 RAG 的生成式 AI 應用程式資料擷取子系統。

資料擷取流程的步驟如下：

  1. 資料會上傳至 Cloud Storage 值區。資料來源可能是上傳、擷取資料庫或串流資料的應用程式使用者。
  2. 上傳資料後，系統會傳送通知至 Pub/Sub 主題。
  3. Pub/Sub 會觸發 Cloud Run 工作來處理上傳的資料。
  4. Cloud Run 開始執行工作時，會使用儲存在 AlloyDB for PostgreSQL 資料庫的設定資料。
  5. Cloud Run 工作會使用 Document AI 準備資料，以便進一步處理。例如，準備作業可能包含剖析資料、將資料轉換成所需格式，以及將資料區隔為分塊。

  6. Cloud Run 工作會使用 Vertex AI Embeddings for Text 模型，建立已擷取資料的向量化嵌入。

  7. Cloud Run 會將嵌入儲存在 AlloyDB for PostgreSQL 資料庫，並啟用 pgvector 擴充功能。如下一節所述，服務子系統處理使用者要求時，會使用向量資料庫中的嵌入，擷取與情境相關的資料。

服務子系統

服務子系統會處理生成式 AI 應用程式和使用者之間的要求/回覆流程。下圖顯示架構中服務子系統的詳細資料：

Google Cloud中支援 RAG 的生成式 AI 應用程式服務子系統。

以下是服務子系統中要求/回應流程的步驟：

  1. 使用者透過聊天機器人或行動應用程式等前端，向生成式 AI 應用程式提交要求。

  2. 生成式 AI 應用程式會將自然語言要求轉換為嵌入。

  3. 應用程式會完成 RAG 方法的擷取部分：

    1. 在資料擷取子系統維護的 AlloyDB for PostgreSQL 向量儲存庫中，應用程式會對嵌入執行語意搜尋。語意搜尋可根據提示的意圖 (而非文字內容) 找出合適的嵌入。
    2. 應用程式會結合原始要求，以及按相符嵌入擷取的原始資料，建立含有背景資訊的提示。

  4. 應用程式將含有背景資訊的提示，傳送到在 Vertex AI 執行的 LLM 推論堆疊。

  5. LLM 推論堆疊會使用生成式 AI LLM (可以是基礎 LLM 或自訂 LLM)，生成符合情境的回覆。

    1. 應用程式可在 Cloud Logging 儲存要求/回覆活動的記錄。您能透過 Cloud Monitoring 查看及使用記錄進行監控。Google 不會存取或使用記錄資料。
    2. 應用程式會將回覆載入至 BigQuery，以便進行離線分析。

  6. 應用程式會使用負責任的 AI 技術篩選機制來過濾回覆。

  7. 應用程式透過前端將篩選後的回覆傳給使用者。

品質評估子系統

下圖顯示架構中品質評估子系統的詳細資料：

Google Cloud中支援 RAG 的生成式 AI 應用程式品質評估子系統。

品質評估子系統收到要求後，會執行下列動作：

  1. Pub/Sub 會觸發 Cloud Run 工作。
  2. Cloud Run 開始執行工作時，會使用儲存在 AlloyDB for PostgreSQL 資料庫的設定資料。
  3. Cloud Run 工作會從 AlloyDB for PostgreSQL 資料庫提取評估提示。該提示先前由資料擷取子系統上傳。

  4. Cloud Run 工作會使用評估提示，掌握服務子系統生成回覆的品質。

    評估結果會包含事實準確率和關聯性等指標的評估分數。

  5. Cloud Run 會將評估分數和完成評估的提示與回覆，載入到 BigQuery 供日後分析。

使用的產品

以下是上述架構使用的所有 Google Cloud 產品摘要：

  • Vertex AI：機器學習平台，可讓您訓練及部署機器學習模型和 AI 應用程式，並自訂 LLM 用於 AI 輔助的應用程式。
  • Cloud Run：無伺服器運算平台，可讓您在 Google 可擴充的基礎架構上直接執行容器。
  • BigQuery：企業 data warehouse，內建機器學習、地理空間分析和商業智慧等功能，可協助您管理及分析資料。
  • Cloud Storage：適用於多種資料類型的物件儲存庫，成本低廉且沒有限制。 資料在 Google Cloud 內外都能存取，且會複製到多個位置，以便提供備援機制。 Google Cloud
  • AlloyDB for PostgreSQL：與 PostgreSQL 相容的全代管資料庫服務，專為最嚴苛的工作負載 (包括混合型交易和分析處理作業) 而設計。
  • Document AI：文件處理平台，可將文件中的非結構化資料轉為結構化資料。
  • Pub/Sub：可擴充的非同步訊息服務，會分離產生訊息的服務與處理訊息的服務。
  • Cloud Logging：即時記錄管理系統，提供儲存、搜尋、分析和快訊功能。
  • Cloud Monitoring：這項服務可讓您掌握應用程式和基礎架構的效能、可用性和健康狀態。

用途

RAG 是一種有效技術，可提升 LLM 生成的輸出內容品質。本節提供可使用支援 RAG 的生成式 AI 應用程式的用途範例。

個人化的產品推薦內容

網路購物網站可能會使用 LLM 輔助的聊天機器人，協助顧客尋找產品或取得購物相關協助。系統會根據使用者的購物行為和網站互動模式，擴充使用者提出的問題。這類資料可能包括儲存在非結構化資料儲存庫中的使用者評論和意見回饋，或是儲存在網站分析資料倉儲中的搜尋相關指標。LLM 接著會處理擴增問題，生成使用者可能更感興趣的個人化回覆。

臨床輔助系統

醫院的醫生需要快速分析和診斷病患的健康狀況，才能決定合適的照護和用藥。如果生成式 AI 應用程式使用 Med-PaLM 等醫療 LLM，就能協助醫生進行臨床診斷。應用程式生成的回覆可根據病患的病歷記錄，透過醫院電子健康記錄 (EHR) 資料庫或 PubMed 等外部知識庫的資料，為醫生的提示提供背景資訊。

律師可以運用生成式 AI 輔助法律研究，快速查詢大量法規和判例，找出相關法律先例或摘要複雜的法律概念。律師可從律師事務所的專屬合約、過往法律通訊和內部案件記錄中擷取資料，並將這些資料加入提示，藉此提升研究結果的品質。這種設計方法可確保生成的回覆與律師專精的法律領域相關。

設計替代方案

本節將介紹其他設計方法，供您在 Google Cloud為支援 RAG 的生成式 AI 應用程式採用。

如果您需要使用全代管向量搜尋產品的架構，可以採用 Vertex AI 和 Vector Search，這項服務提供經過最佳化的基礎架構，可處理大規模向量搜尋。詳情請參閱「使用 Vertex AI 和 Vector Search 建構具備 RAG 功能的生成式 AI 應用程式基礎架構」。

開放原始碼工具和模型

如要使用開放原始碼工具和模型 (Ray、Hugging Face 和 LangChain) 快速建構及部署支援 RAG 的生成式 AI 應用程式，請參閱「使用 GKE 和 Cloud SQL 建構具備 RAG 功能的生成式 AI 應用程式基礎架構」。

其他選項

如要瞭解其他基礎架構選項、支援的模型，以及可在Google Cloud生成式 AI 應用程式中使用的基礎技術，請參閱「為生成式 AI 應用程式選擇模型和基礎架構」。

設計須知

本節提供指引，協助您在 Google Cloud 中開發支援 RAG 的生成式 AI 架構，滿足安全性、法規遵循、可靠性、成本和效能方面的特定需求。本節的指引僅列出部分範例。視生成式 AI 應用程式的具體需求，以及您使用的 Google Cloud 產品和功能而定，您可能需要考量其他設計因素和取捨。

安全性與法規遵循

本節說明在 Google Cloud 設計及建構支援 RAG 的生成式 AI 應用程式時，應考量的因素，確保應用程式符合安全性與法規遵循需求。

產品 設計須知
Vertex AI Vertex AI 支援 Google Cloud 安全控管機制 ，可協助您滿足資料落地、資料加密、網路安全和存取透明化控管機制等方面的需求。詳情請參閱「 Vertex AI 的安全控管機制」和「 生成式 AI 的安全控管機制」。
Cloud Run

根據預設，Cloud Run 會使用 Google-owned and Google-managed encryption key加密資料。如要使用您控管的金鑰保護容器，可以採用客戶自行管理的加密金鑰 (CMEK)。詳情請參閱「 使用客戶管理的加密金鑰」。

如要確保只有授權的容器映像檔會部署至 Cloud Run 作業，可以使用 二進位授權。

Cloud Run 可協助您符合資料落地規定。Cloud Run 容器執行個體會在您選取的地區中執行。
AlloyDB for PostgreSQL

根據預設，儲存在 AlloyDB for PostgreSQL 的資料會使用 Google-owned and Google-managed encryption keys加密。如要使用您控管及管理的加密金鑰，可以採用 CMEK。詳情請參閱「 關於 CMEK」。

如要降低從 AlloyDB for PostgreSQL 資料庫竊取資料的風險，可以使用 VPC Service Controls 建立服務範圍。

根據預設，AlloyDB for PostgreSQL 執行個體只接受使用 SSL 的連線。如要進一步確保與 PostgreSQL 適用的 AlloyDB 資料庫連線安全無虞，可以使用 PostgreSQL 適用的 AlloyDB Auth Proxy 連接器。Auth Proxy 連接器提供以 Identity and Access Management (IAM) 為基礎的連線授權，並使用 TLS 1.3 連線搭配 256 位元 AES 加密，驗證用戶端和伺服器身分，以及加密資料流量。詳情請參閱「 PostgreSQL 適用的 AlloyDB Auth Proxy 簡介」。如要透過 Java、Python 或 Go 建立連線，請使用適當的語言連接器，而非 Auth Proxy 連接器。

PostgreSQL 適用的 AlloyDB 可協助您符合資料落地規定。 資料會儲存或複製到您指定的區域。

BigQuery

BigQuery 提供許多功能，可用於控管資料存取權、保護敏感資料，以及確保資料準確度和一致性。詳情請參閱 BigQuery 資料控管簡介。

BigQuery 可協助您符合資料落地規定。資料會儲存在您指定的區域。

Cloud Storage

根據預設，儲存在 Cloud Storage 中的資料會使用 Google-owned and Google-managed encryption keys加密。如有需要，您可以使用 CMEK，或透過外部管理方法 (例如客戶提供的加密金鑰 (CSEK)) 管理自己的金鑰。詳情請參閱「 資料加密選項」。

Cloud Storage 支援兩種方法，可授予使用者存取值區和物件的權限：IAM 和存取控制清單 (ACL)。在大多數情況下，我們建議使用 IAM，因為您可以在值區和專案層級授予權限。詳情請參閱 存取權控管總覽。

透過 Cloud Storage 載入資料擷取子系統的資料可能包含機密資料。如要保護這類資料，可以使用 Sensitive Data Protection 服務探索、分類及去識別化資料。詳情請參閱 搭配 Cloud Storage 使用機密資料保護功能。

Cloud Storage 可協助您遵守資料落地規定。資料會儲存或複製到您指定的區域。

Pub/Sub

根據預設，Pub/Sub 會使用 Google-owned and Google-managed encryption keys加密所有訊息，包括靜態和傳輸中的訊息。Pub/Sub 支援使用 CMEK 在應用程式層加密訊息。詳情請參閱「 設定訊息加密」。

如有資料落地規定，為確保訊息資料儲存在特定位置，您可以 設定訊息儲存政策。
Document AI 根據預設，靜態資料會使用 Google 代管的加密金鑰加密。如需使用您控管及管理的加密金鑰，可以採用 CMEK。詳情請參閱 Document AI 安全性與法規遵循。
Cloud Logging

根據預設，這個參考架構中使用的所有 Google Cloud 服務都會啟用 管理員活動稽核記錄。這類記錄會記錄 API 呼叫，或是修改 Google Cloud 資源設定或中繼資料的其他動作。

資料存取稽核記錄預設為啟用 BigQuery。對於這個架構中使用的其他服務，您可以啟用資料存取稽核記錄。您可以透過稽核記錄追蹤 API 呼叫，瞭解資源的設定或中繼資料，以及使用者建立、修改或讀取使用者提供資源資料的要求。

為協助符合資料落地規定，您可以設定 Cloud Logging，將記錄檔資料儲存在您指定的區域。詳情請參閱「 將記錄區域化」。

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

可靠性

本節說明設計因素，您應考量這些因素，在Google Cloud中為支援 RAG 的生成式 AI 應用程式建構及運作可靠的基礎架構。

產品 設計須知
Cloud Run

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

個別 Cloud Run 工作或工作可能會失敗。如要處理這類失敗，可以使用 工作重試和檢查點。詳情請參閱「 作業重試和檢查點最佳做法」。
AlloyDB for PostgreSQL

根據預設，PostgreSQL 適用的 AlloyDB 叢集會提供高可用性 (HA) 和自動容錯移轉功能。主要執行個體有位於同一地區兩個不同區域的備援節點。這項備援機制可確保叢集不受區域中斷影響。

如要規劃從區域服務中斷事件復原，可以使用 跨區域複製。
BigQuery

載入 BigQuery 的資料會同步儲存在您指定區域內的兩個可用區。這項備援機制有助於確保區域中斷時，資料不會遺失。

如要進一步瞭解 BigQuery 的可靠性功能，請參閱「 瞭解可靠性」。
Cloud Storage 您可以在三種位置類型中建立 Cloud Storage 值區：單一區域、雙區域或多區域。儲存在地區值區中的資料，會同步複製到該地區的多個可用區。如要提高可用性，可以使用雙區域或多區域值區，將資料非同步複製到不同區域。
Pub/Sub

如要管理訊息流量的暫時尖峰，您可以在發布商設定中設定 流量控管。

如要處理發布失敗的情況，請視需要調整重試要求變數。詳情請參閱「 重試要求」。
Document AI

Document AI 是地區性服務，資料會同步儲存在區域內的多個可用區。系統會自動在各可用區之間進行負載平衡。如果發生區域中斷，資料不會遺失。如果發生區域中斷，Google 解決中斷問題前，您將無法使用 Document AI。

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

成本最佳化

本節提供指引，協助您在 Google Cloud中，盡量降低設定及運作支援 RAG 的生成式 AI 應用程式成本。

產品 設計須知
Cloud Run

建立 Cloud Run 工作時，請指定要分配給容器執行個體的記憶體和 CPU 數量。為控管費用，請從預設 (最低) CPU 和記憶體配置開始。如要提升效能，可以設定 CPU 上限和 記憶體上限，增加分配量。

如果您可以預測 Cloud Run 工作的 CPU 和記憶體需求，就能透過承諾用量折扣省下費用。詳情請參閱「 Cloud Run 承諾使用折扣」。
AlloyDB for PostgreSQL

根據預設，PostgreSQL 適用的 AlloyDB 叢集主要執行個體會具備高可用性 (HA)。執行個體有一個作用中節點和一個待命節點。如果作用中節點發生故障，PostgreSQL 適用的 AlloyDB 會自動容錯移轉至待命節點。如果資料庫不需要高可用性，您可以將叢集的主要執行個體設為基本執行個體，藉此降低費用。基本執行個體無法抵禦區域中斷，且維護作業期間的停機時間較長。詳情請參閱「 使用基本執行個體來降低成本」。

如果您可以預測 PostgreSQL 適用的 AlloyDB 執行個體的 CPU 和記憶體需求，就能透過承諾用量折扣省下費用。詳情請參閱「 PostgreSQL 適用的 AlloyDB 承諾使用折扣」。
BigQuery BigQuery 可讓您在執行查詢前估算費用。如要盡量降低查詢費用，請最佳化儲存空間和查詢運算。詳情請參閱「 預估及控管費用」。
Cloud Storage 針對用於將資料載入資料擷取子系統的 Cloud Storage 值區，請根據工作負載的資料保留和存取頻率需求，選擇合適的 儲存空間級別。舉例來說，您可以選擇 Standard 儲存空間級別，並使用 物件生命週期管理功能，根據您設定的條件自動將物件降級至成本較低的儲存空間級別，或刪除物件，藉此控管儲存空間成本。
Cloud Logging

如要控管記錄檔的儲存費用，可以採取下列做法：

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

成效

本節說明在 Google Cloud 設計及建構符合效能需求的 RAG 支援生成式 AI 應用程式時，應考量的因素。

產品 設計須知
Cloud Run 根據預設，每個 Cloud Run 容器執行個體都會分配到一個 CPU 和 512 MiB 的記憶體。您可以根據 Cloud Run 作業的效能需求，設定 CPU 上限和記憶體上限。
AlloyDB for PostgreSQL

為協助您分析及提升資料庫的查詢效能，AlloyDB for PostgreSQL 提供查詢洞察工具。您可以使用這項工具監控效能，並追蹤有問題的查詢來源。詳情請參閱「 查詢洞察總覽」。

如要查看資料庫的狀態和效能總覽，以及尖峰連線數和最大複寫延遲等詳細指標，可以使用「系統洞察」資訊主頁。詳情請參閱「 使用 PostgreSQL 適用的 AlloyDB 系統洞察資訊主控台監控執行個體」。

如要減少主要 AlloyDB for PostgreSQL 執行個體的負載，並擴充處理讀取要求的容量，可以將讀取集區執行個體新增至叢集。詳情請參閱「 PostgreSQL 適用的 AlloyDB 節點和執行個體」。
BigQuery

BigQuery 提供查詢執行圖，可用於分析查詢效能，並針對 Slot 爭用和 Shuffle 配額不足等問題取得效能深入分析。詳情請參閱「 取得查詢效能深入分析」。

解決透過查詢效能洞察發現的問題後，您可以使用減少輸入和輸出資料量等技巧，進一步最佳化查詢。詳情請參閱「 最佳化查詢運算」。
Cloud Storage 如要上傳大型檔案，可以使用「平行複合式上傳」方法。採用這項策略時，系統會將大型檔案分割成多個區塊。系統會平行上傳這些區塊至 Cloud Storage，然後在雲端重組資料。如果網路頻寬和磁碟速度不是限制因素，平行複合上傳作業的速度會比一般上傳作業更快。不過，這項策略有一些限制，且會影響費用。詳情請參閱 平行複合式上傳。

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

部署作業

如要開始建構基礎架構，並試驗具備 RAG 功能的生成式 AI 應用程式，請使用 Google Cloud 快速部署解決方案：使用 Cloud SQL 的生成式 AI RAG。這項解決方案會在 Cloud Run 上部署以 Python 為基礎的聊天應用程式，並使用全代管的 Cloud SQL 資料庫進行向量搜尋。您可從 GitHub 取得本解決方案的範例程式碼。

後續步驟

貢獻者

作者：Kumar Dhanagopal | 跨產品解決方案開發人員

其他貢獻者：