使用 GKE 和 Cloud SQL 建構具備 RAG 功能的生成式 AI 應用程式基礎架構

Last reviewed 2024-12-11 UTC

本文件提供參考架構,您可以使用這項架構設計基礎架構,藉此透過 Google Kubernetes Engine (GKE)、Cloud SQL 和 Ray、Hugging Face 和 LangChain 等開放原始碼工具,執行採用檢索增強生成 (RAG) 的生成式 AI 應用程式。為協助您試驗這個參考架構,我們在 GitHub 中提供了應用程式範例和 Terraform 設定。

這份文件適用於想要使用開放原始碼工具和模型,快速建構及部署支援 RAG 的生成式 AI 應用程式的開發人員。本教學課程假設您具備使用 GKE 和 Cloud SQL 的經驗,且對 AI、機器學習 (ML) 和大型語言模型 (LLM) 有概念上的理解。本文件不會提供如何設計和開發生成式 AI 應用程式的相關指引。

架構

下圖為 Google Cloud中支援 RAG 的生成式 AI 應用程式架構概略圖:

在 Google Cloud中,支援 RAG 的生成式 AI 應用程式的整體架構。

此架構包含服務子系統和嵌入子系統。

  • 服務子系統會處理應用程式與使用者之間的要求/回覆流程。這個子系統包含前端伺服器、推論伺服器和負責任 AI (RAI) 服務。服務子系統會透過向量資料庫與嵌入子系統互動。
  • 嵌入子系統可在架構中啟用 RAG 功能。這個子系統會執行以下操作:
    • 從 Google Cloud、內部部署和其他雲端平台的資料來源擷取資料。
    • 將攝入的資料轉換為向量嵌入項目。
    • 將嵌入項目儲存在向量資料庫中。

下圖詳細顯示架構:

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

如上圖所示,前端伺服器、推論伺服器和嵌入服務會在Autopilot 模式的區域性 GKE 叢集中部署。系統會透過 Cloud Storage 值區擷取 RAG 資料。此架構會使用 Cloud SQL for PostgreSQL 執行個體,並搭配 pgvector 擴充功能做為向量資料庫,以便儲存嵌入項目及執行語意搜尋。向量資料庫可有效儲存及擷取高維向量。

以下各節將說明架構內的子系統中,各個元件和資料流程。

嵌入子系統

以下是嵌入子系統中的資料流程:

  1. 來自外部和內部來源的資料會由人類使用者或程式設計上傳至 Cloud Storage 值區。上傳的資料可能是檔案、資料庫或串流資料。
  2. (未顯示在架構圖中)。資料上傳活動會觸發事件,並將事件發布至 Pub/Sub 等訊息傳遞服務。訊息服務會傳送通知給嵌入服務。
  3. 當嵌入服務收到資料上傳事件的通知時,會執行下列操作:
    1. 透過 Cloud Storage FUSE CSI 驅動程式,從 Cloud Storage 值區擷取資料。
    2. 讀取上傳的資料,並使用 Ray Data 進行預先處理。預先處理作業可能包括將資料切割成多個區塊,並轉換成適合用於產生嵌入內容的格式。
    3. 執行 Ray 工作,使用部署在同一叢集中的開源模型 (例如 intfloat/multilingual-e5-small),為預先處理過的資料建立向量化嵌入。
    4. 將向量化嵌入項目寫入 PostgreSQL 適用的 Cloud SQL 向量資料庫。

如以下一節所述,服務子系統處理使用者要求時,會使用向量資料庫中的嵌入,擷取與情境相關的資料。

服務子系統

以下是服務子系統中的要求/回覆流程:

  1. 使用者透過網路聊天介面,向前端伺服器提交自然語言要求。前端伺服器會在 GKE 上執行。
  2. 前端伺服器會執行 LangChain 程序,執行以下操作:
    1. 使用嵌入服務使用的相同模型和參數,將自然語言要求轉換為嵌入。
    2. 在向量資料庫中對嵌入項目執行語意搜尋,擷取相關的基礎資料。語意搜尋可根據提示的意圖 (而非文字內容) 找出合適的嵌入。
    3. 結合原始要求和擷取的基礎資料,建構含有背景資訊的提示。
    4. 將含有背景資訊的提示傳送至在 GKE 上執行的推論伺服器。
  3. 推論伺服器會使用 Hugging Face TGI 服務架構,為 Mistral-7B-InstructGemma 開放模型等開放原始碼 LLM 提供服務。
  4. 大型語言模型會針對提示產生回應,推論伺服器則會將回應傳送至前端伺服器。

    您可以在 Cloud Logging 中儲存及查看要求/回覆活動的記錄,並使用 Cloud Monitoring 設定以記錄為基礎的監控功能。您也可以將產生的回覆載入 BigQuery 進行離線分析。

  5. 前端伺服器會叫用 RAI 服務,將必要的安全過濾器套用至回應。您可以使用 Sensitive Data ProtectionCloud Natural Language API 等工具,探索、篩選、分類及去識別回覆中的機密內容。

  6. 前端伺服器會將篩選後的回應傳送給使用者。

使用的產品

以下是上述架構使用的 Google Cloud 和開放原始碼產品摘要:

Google Cloud 項產品

  • Google Kubernetes Engine (GKE):您可以透過這項 Kubernetes 服務,在 Google 基礎架構大規模部署及操作容器化應用程式。
  • Cloud Storage:適用於多種資料類型的物件儲存庫,成本低廉且沒有限制。資料在 Google Cloud內外都能存取,且會複製到多個位置,以便提供備援機制。
  • Cloud SQL:全代管關聯資料庫服務,可協助您在 Google Cloud上佈建、操作及管理 MySQL、PostgreSQL 和 SQL Server 資料庫。

開放原始碼產品

用途

RAG 是一種有效的技術,可改善 LLM 產生的輸出內容品質。本節將舉例說明可使用支援 RAG 的生成式 AI 應用程式的用途。

個人化的產品推薦內容

線上購物網站可能會使用 LLM 輔助的聊天機器人,協助客戶找到產品或提供購物相關協助。您可以使用使用者的購物行為和網站互動模式歷來資料,進一步強化使用者提出的問題。資料可能包括儲存在非結構化資料儲存庫中的使用者評論和意見回饋,或是儲存在網站分析資料倉儲中的搜尋相關指標。接著,LLM 就能處理增強問題,生成使用者可能會覺得更吸引人且有說服力的個人化回覆。

臨床輔助系統

醫院中的醫師需要快速分析及診斷病患的健康狀況,才能決定適當的照護和用藥方式。使用醫療 LLM (例如 Med-PaLM) 的生成式 AI 應用程式,可協助醫師進行臨床診斷。應用程式產生的回覆可根據醫師提示,使用醫院電子健康記錄 (EHR) 資料庫或 PubMed 等外部知識庫中的資料,將回覆內容置於歷史病患記錄的脈絡中。

有了生成式 AI 技術輔助的法律研究工具,律師就能快速查詢大量法規和判例,找出相關法律先例或概述複雜的法律概念。您可以透過以下方式,提升這類研究的輸出結果:在律師提示中加入律師事務所專屬合約集合體、過去法律通訊內容和內部案件記錄中擷取的資料。這種設計方法可確保產生的回覆與律師專精的法律領域相關。

設計替代方案

本節將介紹可用於 Google Cloud中支援 RAG 的生成式 AI 應用程式的其他設計方法。

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

支援向量的 Google Cloud 資料庫

如果您想利用全代管 Google Cloud 資料庫 (例如 AlloyDB for PostgreSQL 或 Cloud SQL) 的向量儲存功能,為 RAG 應用程式提供支援,請參閱「使用 Vertex AI 和 AlloyDB for PostgreSQL 建構具備 RAG 功能的生成式 AI 應用程式基礎架構」。

其他選項

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

設計須知

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

如需與本參考架構中開放原始碼工具相關的設計指南 (例如 Hugging Face TGI),請參閱這些工具的說明文件。

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

本節說明在 Google Cloud 中設計及建構支援 RAG 的生成式 AI 應用程式時,應考量的因素,以符合安全性、隱私權和法規遵循要求。

產品 設計須知
GKE

在 Autopilot 作業模式中,GKE 會根據安全性最佳做法預先設定叢集,並管理節點,讓您專注於工作負載的安全性。詳情請參閱下列資源:

如要確保在 GKE 中執行的應用程式享有進階存取權控管功能,您可以使用 Identity-Aware Proxy (IAP)。IAP 會與 GKE Ingress 資源整合,確保只有具備正確 Identity and Access Management (IAM) 角色的驗證使用者才能存取應用程式。詳情請參閱「 為 GKE 啟用 IAP」。

根據預設,GKE 中的資料會使用 Google-owned and Google-managed encryption keys加密 靜態資料 傳輸中資料。您可以使用自己擁有並透過 Cloud KMS 管理的金鑰,在應用程式層加密機密資料,為機密資料提供額外一層安全防護。詳情請參閱「 在應用程式層級加密密鑰」。

如果您使用標準 GKE 叢集,則可以使用下列額外資料加密功能:

Cloud SQL

架構中的 Cloud SQL 執行個體不需要開放公眾存取。如果需要外部存取 Cloud SQL 執行個體,您可以使用 SSL/TLS Cloud SQL 驗證 Proxy 連接器,加密外部連線。Auth Proxy 連接器會使用 IAM 提供連線授權。連接器會使用 TLS 1.3 連線搭配 256 位元 AES 加密,驗證用戶端和伺服器身分,並加密資料流量。如果是使用 Java、Python、Go 或 Node.js 建立的連線,請使用適當的語言連接器,而非 Auth Proxy 連接器。

根據預設,Cloud SQL 會使用 Google 擁有且由 Google 管理的資料加密金鑰 (DEK) 和金鑰加密金鑰 (KEK) 來加密靜態資料。如果您需要使用自己控制及管理的 KEK,可以使用 客戶自行管理的加密金鑰 (CMEK)

如要防止未經授權存取 Cloud SQL Admin API,您可以使用 VPC Service Controls 建立服務範圍。

如要瞭解如何設定 Cloud SQL 以符合資料落地規定,請參閱「 資料落地簡介」。

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 資料外洩的風險,您可以使用 VPC Service Controls 建立服務範圍。

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

這個架構中的所有產品

根據預設,對於在這個參考架構中使用的所有 Google Cloud 服務, 管理員活動稽核記錄都會啟用。您可以透過 Cloud Logging 存取記錄,並使用記錄監控 API 呼叫或其他修改 Google Cloud 資源設定或中繼資料的動作。

根據預設,這個架構中的所有 Google Cloud 服務也都會啟用 資料存取稽核記錄。您可以使用這些記錄監控下列項目:

  • 讀取資源設定或中繼資料的 API 呼叫。
  • 使用者要求建立、修改或讀取使用者提供的資源資料。

如需 AI 和機器學習工作負載專屬的安全性原則和建議,請參閱「良好架構架構」中的AI 和機器學習觀點:安全性

可靠性

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

產品 設計須知
GKE

在這個架構中使用的 Autopilot 作業模式下,GKE 提供下列內建可靠性功能:

  • 您的工作負載使用 區域性 GKE 叢集。控制層和 worker 節點會分散在區域內的三個不同可用區。您的工作負載可在可用區停機時持續運作。相較於區域叢集,區域性 GKE 叢集的 SLA 保證運作時間更高。
  • 您不需要建立節點或管理節點集區。GKE 會根據工作負載需求,自動建立節點集區並進行調度。

如要確保在需要自動調整 GKE 叢集時有足夠的 GPU 容量,您可以建立並使用預訂。預留機制可為特定資源在特定區域提供保證容量。預留項目可以專屬於某個專案,也可以跨多個專案共用。即使未佈建或使用預留資源,也必須支付費用。詳情請參閱「 耗用保留區域資源」。

Cloud SQL

為確保向量資料庫能抵禦資料庫故障和區域停機,請使用 HA 設定的 Cloud SQL 執行個體。在主要資料庫發生故障或區域停機時,Cloud SQL 會自動將容錯移轉至其他區域的待命資料庫。您不需要變更資料庫端點的 IP 位址。

如要確保 Cloud SQL 執行個體適用於 服務水準協議,請遵循建議的操作指南。例如,請確保 CPU 和記憶體的大小適合工作負載,並 啟用自動增加儲存空間功能。詳情請參閱 操作指南

Cloud Storage 您可以在三種 位置類型中建立 Cloud Storage 值區:區域、雙區域或多區域。儲存在區域值區中的資料會在區域內的多個可用區中同步複製。如要提高可用性,您可以使用雙區域或多區域值區,讓資料在各區域間以非同步方式複製。

如要瞭解 AI 和機器學習工作負載專屬的可靠性原則和建議,請參閱「良好架構架構」一文中的「AI 和機器學習觀點:可靠性」。

成本最佳化

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

產品 設計須知
GKE

在 Autopilot 模式下,GKE 會根據工作負載需求,最佳化叢集基礎架構的效率。您不必持續監控資源使用率或管理容量來控管成本。

如果您能預測 GKE Autopilot 叢集的 CPU、記憶體和臨時儲存空間用量,就能透過承諾用量折扣節省成本。詳情請參閱 GKE 承諾使用折扣

如要降低執行應用程式的成本,您可以為 GKE 節點使用 Spot VM。Spot VM 的價格低於標準 VM,但不保證可用性。如要瞭解使用 Spot VM 的節點的優點、在 GKE 中如何運作,以及如何在這些節點上排程工作負載,請參閱「 Spot VM」。

如需更多成本最佳化指南,請參閱「 在 GKE 上執行最具成本效益的 Kubernetes 應用程式的最佳做法」。

Cloud SQL

在可用區或執行個體無法使用時,高可用性 (HA) 設定有助於縮短 Cloud SQL 資料庫的停機時間。不過, 設定為高可用性的執行個體費用會高於獨立執行個體。如果向量資料庫不需要 HA,您可以使用獨立執行個體來降低成本,但這種執行個體無法在區域停機時提供強大的保護。

您可以使用 Cloud SQL 成本洞察資料和 Active Assist 提供的最佳化建議,偵測 Cloud SQL 執行個體是否超額佈建,並改善帳單。詳情請參閱「 減少超額佈建的 Cloud SQL 執行個體」。

如果您能預測 Cloud SQL 執行個體的 CPU 和記憶體需求,就能透過承諾用量折扣節省開銷。詳情請參閱 Cloud SQL 承諾使用折扣

Cloud Storage 針對用於將資料載入資料擷取子系統的 Cloud Storage 值區,請選擇適當的 儲存空間級別。選擇儲存空間級別時,請考量工作負載的資料保留和存取頻率需求。舉例來說,如要控管儲存空間費用,您可以選擇 Standard 級別並使用 物件生命週期管理。這樣一來,系統就能根據您設定的條件,自動將物件降級至費用較低的儲存空間級別,或刪除物件。

如要預估 Google Cloud 資源費用,請使用 Google Cloud Pricing Calculator

如要瞭解 AI 和機器學習工作負載專屬的成本最佳化原則和最佳化建議,請參閱「良好架構架構」一文中的AI 和機器學習觀點:成本最佳化

效能最佳化

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

產品 設計須知
GKE 請根據工作負載的效能需求,為 Pod 選擇適當的 運算類別。對於執行推論伺服器和嵌入服務的 Pod,建議您使用 nvidia-l4 GPU 機器類型
Cloud SQL

如要提升 Cloud SQL 執行個體的效能,請確保分配給執行個體的 CPU 和記憶體足以應付工作負載。詳情請參閱「 改善未充分佈建的 Cloud SQL 執行個體」。

如要縮短近似近鄰 (ANN) 向量搜尋的回應時間,請使用 平面壓縮的反轉檔案 (IVFFlat)索引或 階層可導向小型世界 (HNSW)索引

為協助您分析及改善資料庫的查詢效能,Cloud SQL 提供「查詢洞察」工具。您可以使用這項工具監控效能,並追蹤有問題的查詢來源。詳情請參閱「 使用查詢洞察提高查詢效能」一文。

如要概略瞭解資料庫的狀態和效能,並查看詳細指標 (例如最高連線數和磁碟使用率),您可以使用「系統深入分析」資訊主頁。詳情請參閱「 使用系統深入分析資料改善系統效能」。

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

如要瞭解 AI 和機器學習工作負載專屬的效能最佳化原則和最佳化建議,請參閱「良好架構架構」一文中的AI 和機器學習觀點:效能最佳化

部署作業

如要部署以此參考架構為基礎的拓樸圖,您可以下載並使用 GitHub 存放區中提供的開放原始碼範例程式碼。本程式碼範例並非用於正式工作環境。您可以使用這段程式碼,嘗試為支援 RAG 的生成式 AI 應用程式設定 AI 基礎架構。

程式碼範例會執行下列作業:

  1. 佈建 PostgreSQL 適用的 Cloud SQL 執行個體,做為向量資料庫。
  2. 將 Ray、JupyterHub 和 Hugging Face TGI 部署至您指定的 GKE 叢集。
  3. 將網頁式對話方應用程式範例部署至 GKE 叢集,以便驗證 RAG 功能。

如需範例程式碼的使用說明,請參閱程式碼的 README。如果您在使用範例程式碼時發生任何錯誤,且沒有開放的 GitHub 問題,請在 GitHub 中建立問題。

程式碼範例會部署可計費的 Google Cloud 資源。使用完程式碼後,請移除不再需要的任何資源。

後續步驟

貢獻者

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

其他貢獻者: