本文提供參考架構，協助您設計基礎架構，透過 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 應用程式架構概略視圖：
這項架構包含服務子系統和嵌入子系統。
- 服務子系統會處理應用程式和使用者之間的要求/回覆流程。這個子系統包含前端伺服器、推論伺服器和負責任的 AI (RAI) 服務。服務子系統會透過向量資料庫與嵌入子系統互動。
- 嵌入子系統可在架構中啟用 RAG 功能。這個子系統會執行下列動作：
- 從 Google Cloud、地端部署和其他雲端平台的資料來源擷取資料。
- 將擷取的資料轉換為向量嵌入。
- 將嵌入內容儲存在向量資料庫中。
下圖詳細呈現相關架構：
如上圖所示，前端伺服器、推論伺服器和嵌入服務會部署在 Autopilot 模式的區域性 GKE 叢集中。系統會透過 Cloud Storage 值區擷取 RAG 的資料。此架構使用 PostgreSQL 適用的 Cloud SQL 執行個體，並以 pgvector 擴充功能做為向量資料庫，儲存嵌入項目並執行語意搜尋。向量資料庫的設計宗旨是有效率地儲存及擷取高維度向量。
以下各節會針對架構內的子系統，說明各個元件和資料流程。
嵌入子系統
以下是嵌入子系統中的資料流程：
- 外部和內部來源的資料會由使用者或以程式輔助方式上傳至 Cloud Storage 值區。上傳的資料可能位於檔案、資料庫或串流資料中。
- (架構圖中未顯示)。資料上傳活動會觸發事件，並發布至 Pub/Sub 等訊息傳遞服務。訊息服務會將通知傳送至嵌入服務。
- 當嵌入服務收到資料上傳事件的通知時，會執行下列動作：
- 透過 Cloud Storage FUSE CSI 驅動程式，從 Cloud Storage 值區擷取資料。
- 讀取上傳的資料，並使用 Ray Data 預先處理資料。預先處理作業可能包括將資料分塊，並轉換成適合產生嵌入內容的格式。
- 執行 Ray 工作，使用部署在相同叢集中的開放原始碼模型 (例如 intfloat/multilingual-e5-small)，建立經過前處理資料的向量化嵌入。
- 將向量化嵌入內容寫入 PostgreSQL 適用的 Cloud SQL 向量資料庫。
如下一節所述，服務子系統處理使用者要求時，會使用向量資料庫中的嵌入，擷取與情境相關的資料。
服務子系統
服務子系統中的要求/回覆流程如下：
- 使用者透過網頁版對話介面，向前端伺服器提交自然語言要求。前端伺服器在 GKE 上執行。
- 前端伺服器會執行 LangChain 程序，該程序會執行下列操作：
- 使用與嵌入服務相同的模型和參數，將自然語言要求轉換為嵌入。
- 在向量資料庫中對嵌入項目執行語意搜尋，擷取相關的基礎資料。語意搜尋可根據提示的意圖 (而非文字內容) 找出合適的嵌入。
- 結合原始要求和擷取的基礎資料，建構含有背景資訊的提示。
- 將含有背景資訊的提示傳送至推論伺服器，該伺服器在 GKE 上執行。
- 推論伺服器會使用 Hugging Face TGI 服務架構，提供開放原始碼 LLM，例如 Mistral-7B-Instruct 或 Gemma 開放模型。
LLM 會生成提示的回覆，而推論伺服器會將回覆傳送至前端伺服器。
您可以在 Cloud Logging 儲存及查看要求/回覆活動的記錄，並使用 Cloud Monitoring 設定記錄式監控。您也可以將產生的回覆載入 BigQuery，進行離線分析。
前端伺服器會叫用 RAI 服務，對回應套用必要的安全性篩選器。您可以使用「Sensitive Data Protection」和「Cloud Natural Language API」等工具，探索、篩選、分類及去識別化回覆中的機密內容。
前端伺服器會將篩選過的回覆傳送給使用者。
使用的產品
以下是上述架構使用的 Google Cloud 和開放原始碼產品摘要：
Google Cloud 產品
- Google Kubernetes Engine (GKE)：Kubernetes 服務，可讓您透過 Google 的基礎架構，大規模部署及操作容器化應用程式。
- Cloud Storage：適用於多種資料類型的物件儲存庫，成本低廉且沒有限制。 資料在 Google Cloud 內外都能存取，且會複製到多個位置，以便提供備援機制。 Google Cloud
- Cloud SQL：全代管關聯式資料庫服務，可協助您在 Google Cloud上佈建、運作及管理 MySQL、PostgreSQL 和 SQL Server 資料庫。
開放原始碼產品
- Hugging Face Text Generation Inference (TGI)：用於部署及提供 LLM 服務的工具包。
- Ray：開放原始碼的整合式運算架構，可協助您擴充 AI 和 Python 工作負載。
- LangChain：這個架構可開發及部署採用 LLM 的應用程式。
用途
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 建構生成式 AI 的 RAG 基礎架構」。
支援向量的 Google Cloud 資料庫
如要為 RAG 應用程式運用 AlloyDB for PostgreSQL 或 Cloud SQL 等全代管 Google Cloud 資料庫的向量儲存功能，請參閱使用 Vertex AI 和 AlloyDB for PostgreSQL 建構生成式 AI 的 RAG 基礎架構。
其他選項
如要瞭解其他基礎架構選項、支援的模型，以及可在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 擁有及管理的金鑰，在應用程式層加密資料。詳情請參閱 在應用程式層級加密密鑰。 如果您使用 Standard GKE 叢集，則可使用下列額外的資料加密功能：
|
| Cloud SQL |
架構中的 Cloud SQL 執行個體不需要從公開網際網路存取。如果需要外部存取 Cloud SQL 執行個體，可以使用 SSL/TLS 或 Cloud SQL 驗證 Proxy 連接器加密外部連線。驗證 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 服務也會啟用 資料存取稽核記錄。您可以使用這些記錄監控下列項目：
|
如要瞭解 AI 和機器學習工作負載專用的安全性原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：安全性」。
可靠性
本節說明建構及運作可靠基礎架構時應考量的設計因素，以便在Google Cloud中支援 RAG 的生成式 AI 應用程式。
| 產品 | 設計須知 |
|---|---|
| GKE |
在本架構中使用的 Autopilot 作業模式下，GKE 提供下列內建的可靠性功能：
為確保在自動調度 GKE 叢集時有足夠的 GPU 容量，您可以建立並使用預留項目。預留功能可確保特定資源在特定可用區的容量。預留項目可專屬於某個專案，或在多個專案之間共用。即使預留資源未佈建或未使用，您仍須支付相關費用。詳情請參閱「 耗用預留區域資源」。 |
| Cloud SQL |
為確保向量資料庫能抵禦資料庫故障和區域中斷，請使用 已設定高可用性的 Cloud SQL 執行個體。如果主要資料庫發生故障或可用區中斷，Cloud SQL 會自動容錯移轉至其他可用區的待命資料庫。您不需要變更資料庫端點的 IP 位址。 如要確保 Cloud SQL 執行個體適用於 服務水準協議，請遵循建議的操作指南。舉例來說，請確保 CPU 和記憶體大小符合工作負載需求，並 啟用自動增加儲存空間。詳情請參閱 操作指南。 |
| Cloud Storage | 您可以在三種位置類型中建立 Cloud Storage 值區：單一區域、雙區域或多區域。儲存在區域值區中的資料會同步複製到區域內的多個可用區。如要提高可用性，可以使用雙區域或多區域值區，將資料非同步複製到各個區域。 |
如要瞭解 AI 和機器學習工作負載專用的可靠性原則和建議，請參閱 Well-Architected Framework 中的「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 資料庫的停機時間。不過，設定為高可用性的執行個體費用，會高於獨立執行個體。如果向量資料庫不需要高可用性，可以使用獨立執行個體來降低費用，但這類執行個體無法抵禦區域中斷。 您可以運用 Active Assist 提供的 Cloud SQL 成本洞察和建議，偵測 Cloud SQL 執行個體是否過度佈建，並最佳化帳單。詳情請參閱「 減少超額佈建的 Cloud SQL 執行個體」。 如果您可以預測 Cloud SQL 執行個體的 CPU 和記憶體需求，就能透過承諾用量折扣省下費用。詳情請參閱 Cloud SQL 承諾使用折扣。 |
| Cloud Storage | 對於用來將資料載入資料擷取子系統的 Cloud Storage bucket，請選擇適當的 儲存空間類別。選擇儲存空間級別時，請考量工作負載的資料保留和存取頻率需求。舉例來說，如要控管儲存空間費用，您可以選擇 Standard 級別，並使用 物件生命週期管理。這樣一來，系統就會根據您設定的條件，自動將物件降級至費用較低的儲存空間級別，或刪除物件。 |
如要估算 Google Cloud 資源的費用，請使用 Google Cloud Pricing Calculator。
如要瞭解 AI 和機器學習工作負載專用的成本最佳化原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：成本最佳化」。
效能最佳化
本節說明在 Google Cloud 中設計及建構支援 RAG 的生成式 AI 應用程式時，應考量的因素，以符合效能需求。
| 產品 | 設計須知 |
|---|---|
| GKE |
根據工作負載的效能需求，為 Pod 選擇適當的運算類別。對於執行推論伺服器和嵌入服務的 Pod，建議使用
GPU 機器類型，例如 nvidia-l4。
|
| Cloud SQL |
如要提升 Cloud SQL 執行個體的效能，請確保分配給執行個體的 CPU 和記憶體足以應付工作負載。詳情請參閱「 最佳化佈建不足的 Cloud SQL 執行個體」。 如要縮短近似近鄰 (ANN) 向量搜尋的回應時間，請使用 反向檔案與平面壓縮 (IVFFlat) 索引或 階層式可導覽小世界 (HNSW) 索引。 為協助您分析及提升資料庫的查詢效能，Cloud SQL 提供查詢洞察工具。您可以使用這項工具監控效能，並追蹤有問題的查詢來源。詳情請參閱「 使用查詢洞察提高查詢效能」。 如要概覽資料庫的狀態和效能，並查看詳細指標 (例如連線數峰值和磁碟使用率)，可以使用「系統洞察」資訊主頁。詳情請參閱「 使用系統深入分析功能提升系統效能」。 |
| Cloud Storage | 如要上傳大型檔案，可以使用「平行複合式上傳」方法。採用這項策略時，系統會將大型檔案分割成多個區塊。系統會平行上傳這些區塊至 Cloud Storage，然後在雲端重組資料。如果網路頻寬和磁碟速度不是限制因素，平行複合上傳作業的速度可能會比一般上傳作業更快。不過，這項策略有一些限制，也可能影響費用。 詳情請參閱 平行複合式上傳。 |
如要瞭解 AI 和機器學習工作負載專用的效能最佳化原則和建議，請參閱 Well-Architected 架構中的「AI 和機器學習觀點：效能最佳化」。
部署作業
如要部署以這個參考架構為基礎的拓撲，您可以下載並使用 GitHub 存放區提供的開放原始碼範例程式碼。程式碼範例不適用於實際工作環境。您可以運用這段程式碼，試著為具備 RAG 功能的生成式 AI 應用程式設定 AI 基礎架構。
程式碼範例會執行下列作業：
- 佈建 PostgreSQL 適用的 Cloud SQL 執行個體，做為向量資料庫。
- 將 Ray、JupyterHub 和 Hugging Face TGI 部署至您指定的 GKE 叢集。
- 將範例網頁型聊天機器人應用程式部署至 GKE 叢集，以驗證 RAG 功能。
如要瞭解如何使用範例程式碼，請參閱程式碼的 README。如果您在使用範例程式碼時發生任何錯誤，且 GitHub 上沒有相關的問題，請在 GitHub 中建立問題。
程式碼範例會部署可計費的 Google Cloud 資源。使用完代碼後，請移除不再需要的資源。
後續步驟
- 請參閱下列 GKE 最佳做法指南：
- 使用 Hugging Face TGI，透過 GKE 上的 GPU 提供 Gemma 開放式模型。
- 使用 Vertex AI 和 Vector Search 建構生成式 AI 的 RAG 基礎架構。
- 使用 Vertex AI 和 AlloyDB for PostgreSQL 建構生成式 AI 的 RAG 基礎架構。
- 使用 Google Agentspace 和 Vertex AI 建構生成式 AI 的 RAG 基礎架構。
- 使用 Vertex AI 和 Spanner Graph 建構生成式 AI 的 GraphRAG 基礎架構。
- 如要瞭解適用於 Google Cloud中 AI 和機器學習工作負載的架構原則和建議，請參閱 Well-Architected Framework 中的AI 和機器學習觀點。
- 如要查看更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：Kumar Dhanagopal | 跨產品解決方案開發人員
其他貢獻者：
- Anna Berenberg | 工程研究員
- Ali Zaidi | 解決方案架構師
- Bala Narasimhan | 產品群經理
- Bill Bernsen | 資安工程師
- Brandon Royal | 對外產品經理
- Cynthia Thomas | 產品經理
- Geoffrey Anderson | 產品經理
- Gleb Otochkin | Cloud Advocate, Databases
- Jack Wotherspoon | 開發人員服務代表
- Julie Amundson | 資深軟體工程師
- Kent Hua | 解決方案經理
- Kavitha Rajendran | AI/機器學習專家、解決方案架構師
- Mark Schlagenhauf | 網路技術文件撰稿者
- Megan O'Keefe | 開發人員服務代表
- Mofi Rahman | Google Cloud 倡議代表