本文提供參考架構，協助您使用 Vector Search，設計具備檢索增強生成 (RAG) 功能的生成式 AI 應用程式基礎架構。向量搜尋是一項全代管 Google Cloud 服務，可為大規模向量相似度比對提供最佳化的服務基礎架構。
本文適用於生成式 AI 應用程式的架構師、開發人員和管理員。本文假設您已具備 AI、機器學習 (ML) 和大型語言模型 (LLM) 的基本概念。本文不會提供如何設計及開發生成式 AI 應用程式的指引。
架構
下圖顯示本文介紹的架構概略視圖：
上圖中的架構有兩個子系統：資料擷取和服務。
- 資料擷取子系統會擷取從外部來源上傳的資料。這個子系統會準備 RAG 適用的資料，並與 Agent Platform 互動，為擷取的資料生成嵌入項目，以及建構和更新向量索引。
- 服務子系統包含生成式 AI 應用程式的前端和後端服務。
- 前端服務會處理應用程式使用者的查詢/回覆流程，並將查詢轉送至後端服務。
- 後端服務會使用 Agent Platform 生成查詢嵌入項目、執行向量相似度搜尋，並套用負責任的 AI 技術 安全篩選器和系統指令。
下圖詳細呈現相關架構：
以下各節說明上述架構圖中各子系統的資料流程。
資料擷取子系統
資料擷取子系統會從外部來源擷取資料，並準備 RAG 用的資料。資料擷取和準備流程的步驟如下：
- 資料會從外部來源上傳至 Cloud Storage bucket。外部來源可能是應用程式、資料庫或串流服務。
- 將資料上傳至 Cloud Storage 時，系統會將訊息發布至 Pub/Sub 主題。
- Pub/Sub 主題收到訊息時，會觸發 Cloud Run 函式。
- Cloud Run 函式會剖析原始資料、將資料格式化為必要格式，並將資料分割成區塊。
- 這個函式會使用 Agent Platform Embeddings API ，透過您指定的嵌入模型建立區塊的嵌入。Agent Platform 支援文字和多模態嵌入模型。
- 接著，函式會建構嵌入項目的 Vector Search 索引，然後部署索引。
系統擷取新資料時，會對新資料執行上述步驟，並使用串流更新更新索引。
服務子系統處理使用者要求時，會使用向量搜尋索引進行向量相似度搜尋。下一節將說明放送流程。
服務子系統
服務子系統會處理生成式 AI 應用程式和使用者之間的查詢/回覆流程。服務流程的步驟如下：
- 使用者向提供前端介面 (例如聊天機器人) 的 Cloud Run 服務提交自然語言查詢，要求生成式 AI 應用程式執行作業。
- 前端服務會將使用者查詢轉送至後端 Cloud Run 服務。
- 後端服務會執行下列動作來處理查詢：
- 使用與資料擷取子系統相同的嵌入模型和參數，將查詢轉換為嵌入，以生成擷取資料的嵌入。
- 在 Vector Search 搜尋索引中，對查詢嵌入執行向量相似度搜尋，以擷取相關的基礎資料。
- 結合原始查詢和基礎資料，建構擴增提示。
- 將經過補強的提示傳送至部署在 Agent Platform 上的 LLM。
- LLM 生成回覆。
- 針對每個提示，Agent Platform 會套用您設定的負責任的 AI 技術安全性篩選器，然後將篩選過的回覆和 AI 安全性分數傳送至 Cloud Run 後端服務。
- 應用程式透過 Cloud Run 前端服務將回覆傳送給使用者。
您可以在 Cloud Logging 中儲存及查看查詢/回覆活動的記錄，並使用 Cloud Monitoring 設定以記錄為準的監控功能。您也可以將產生的回覆載入 BigQuery，進行離線分析。
Agent Platform 提示詞最佳化工具可協助您大規模改善提示詞，無論是初始提示詞設計階段，還是持續調整提示詞，都能派上用場。提示最佳化工具會評估模型對機器學習工程師提供的一組範例提示的回覆。評估結果會包含模型對範例提示的回覆、ML 工程師指定的指標分數，以及一組可考慮使用的最佳化系統指令。
使用的產品
這項參考架構使用下列 Google Cloud 產品：
- Gemini Enterprise Agent Platform：全方位平台，可建構、擴充、管理及最佳化調整企業級的 AI 代理。
- 向量搜尋：向量相似度比對服務，可讓您儲存、建立索引及搜尋語意相似或相關的資料。
- Cloud Run：無伺服器運算平台，可讓您在 Google 可擴充的基礎架構上直接執行容器。
- Cloud Run 函式：無伺服器運算平台，可讓您直接在 Google Cloud中執行單一用途的函式。
- Cloud Storage：適用於多種資料類型的物件儲存庫，成本低廉且沒有限制。 資料在 Google Cloud 內外都能存取，且會複製到多個位置，以便提供備援機制。 Google Cloud
- Pub/Sub：可擴充的非同步訊息服務，會分離產生訊息的服務與處理訊息的服務。
- Cloud Logging：即時記錄管理系統，提供儲存、搜尋、分析和快訊功能。
- Cloud Monitoring：這項服務可讓您掌握應用程式和基礎架構的效能、可用性和健康狀態。
- BigQuery：企業資料倉儲，內建機器學習、地理空間分析和商業智慧等功能，有助於管理及分析資料。
用途
RAG 是一種有效技術，可提升 LLM 生成的輸出內容品質。本節提供範例用途，說明如何使用具備 RAG 功能的生成式 AI 應用程式。
個人化的產品推薦內容
線上購物網站可能會使用 LLM 輔助的聊天機器人，協助顧客尋找產品或取得購物相關協助。系統會根據使用者的購物行為和網站互動模式，提供歷來資料來輔助使用者提出的問題。這類資料可能包括儲存在非結構化資料儲存庫中的使用者評論和意見回饋，或是儲存在網站分析數據分析資料倉儲中的搜尋相關指標。LLM 接著會處理增強後的提問，生成個人化回覆，讓使用者覺得更貼近需求且引人入勝。
臨床輔助系統
醫院的醫生需要快速分析和診斷病患的健康狀況，才能決定適當的照護和用藥。使用 Med-PaLM 等醫療 LLM 的生成式 AI 應用程式，可協助醫生進行臨床診斷。應用程式生成的回覆可以歷來病患記錄為依據，方法是使用醫院的電子病歷 (EHR) 資料庫或 PubMed 等外部知識庫的資料，為醫生的提示提供背景資訊。
高效率的法律研究
律師可運用生成式 AI 輔助法律研究，快速查詢大量法規和判例法，找出相關法律先例或歸納複雜的法律概念。律師可從律師事務所的專屬合約、過往法律通訊和內部案件記錄中擷取資料，並將這些資料加入提示，藉此提升研究結果的品質。這種設計方法可確保生成的內容與律師專精的法律領域相關。
設計替代方案
本節將介紹可考慮用於支援 RAG 的生成式 AI 應用程式的替代設計方法。 Google Cloud
AI 基礎架構替代方案
如要運用全代管 Google Cloud 資料庫 (例如 AlloyDB for PostgreSQL 或 Cloud SQL) 的向量儲存功能，為 RAG 應用程式提供支援，請參閱「使用 Gemini Enterprise Agent Platform 和 AlloyDB for PostgreSQL 建構生成式 AI 的 RAG 基礎架構」。
如要使用開放原始碼工具和模型 (Ray、Hugging Face 和 LangChain) 快速建構及部署支援 RAG 的生成式 AI 應用程式，請參閱「使用 GKE 和 Cloud SQL 建構生成式 AI 的 RAG 基礎架構」。
應用程式託管選項
如本文所示架構，Cloud Run 是生成式 AI 應用程式和資料處理的代管服務。Cloud Run 是以開發人員為中心的全代管應用程式平台。如要進一步彈性設定及控管運算基礎架構，您可以將應用程式部署至 GKE 叢集或 Compute Engine VM。
決定要使用 Cloud Run、GKE 或 Compute Engine 做為應用程式主機時，需要權衡設定彈性和管理工作量。使用無伺服器 Cloud Run 選項，將應用程式部署至預先設定的環境，只需投入最少管理工作。使用 Compute Engine VM 和 GKE 容器時，您必須負責管理基礎運算資源，但可享有更高的設定彈性和控制權。如要進一步瞭解如何選擇合適的應用程式代管服務，請參閱下列文件：
其他選項
如要瞭解其他基礎架構選項、支援的模型，以及可在Google Cloud中用於生成式 AI 應用程式的基礎技術，請參閱「為生成式 AI 應用程式選擇模型和基礎架構」。
設計須知
本節說明使用這個參考架構開發拓撲時，應考量的設計因素、最佳做法和設計建議，以符合您在安全性、可靠性、成本和效能方面的特定需求。
本節的指引僅列出部分範例。視應用程式的具體需求，以及您使用的 Google Cloud 和第三方產品與功能而定，您可能需要考量其他設計因素和取捨。
安全性、法規遵循與隱私權
本節說明設計拓撲時的考量事項和建議，確保拓撲符合工作負載的安全性和法規遵循需求。 Google Cloud
| 產品 | 設計注意事項和建議 |
|---|---|
| Agent Platform |
安全控管機制：Agent Platform 支援 Google Cloud 安全控管機制，可協助您滿足資料落地、資料加密、網路安全和存取透明化控管機制方面的需求。詳情請參閱「機器學習服務的安全控管措施」和「生成式 AI 的安全控管措施」。 模型存取權：您可以設定組織政策，限制 Google Cloud 專案中可使用的大型語言模型類型和版本。詳情請參閱「控管對 Model Garden 模型的存取權」。 共同責任：Agent Platform 會保護基礎架構，並提供工具和安全控管機制，協助您保護資料、程式碼和模型。詳情請參閱「Agent Platform 責任共享」。 資料保護：使用 Cloud Data Loss Prevention API 找出提示和回覆中的個人識別資訊 (PII) 等私密資料，並將其去識別化。詳情請觀看「Protecting sensitive data in AI apps」影片。 |
| Cloud Run |
連入安全防護 (前端服務)：如要控管應用程式的外部存取權，請停用前端 Cloud Run 服務的預設 run.app 網址，並設定區域外部應用程式負載平衡器。除了將傳入應用程式的流量進行負載平衡，負載平衡器也會處理 SSL 憑證管理作業。如要加強保護，可以使用 Google Cloud Armor 安全性政策，為服務提供要求篩選、DDoS 防護和速率限制。
連入安全防護 (後端服務)：這個架構中應用程式的後端 Cloud Run 服務不需要從網際網路存取。如要確保只有內部用戶端可以存取服務，請將 資料加密：Cloud Run 預設會使用 Google-owned and Google-managed encryption key加密資料。如要使用您控管的金鑰保護容器，可以採用客戶自行管理的加密金鑰 (CMEK)。詳情請參閱「使用客戶管理的加密金鑰」。 容器映像檔安全性：如要確保只有授權的容器映像檔會部署至 Cloud Run 服務，可以使用二進位授權。 資料落地：Cloud Run 可協助您符合資料落地規定。Cloud Run 容器執行個體會在您選取的區域中執行。 如需容器安全性的更多指引，請參閱「Cloud Run 一般開發提示」。 |
| 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 探索、分類及去識別化資料。詳情請參閱「將 Sensitive Data Protection 與 Cloud Storage 搭配使用」。 網路控制：如要降低 Cloud Storage 資料遭竊的風險，可以使用 VPC Service Controls 建立服務範圍。 資料落地：Cloud Storage 可協助您符合資料落地規定。資料會儲存或複製到您指定的區域。 |
| Pub/Sub |
資料加密：根據預設，Pub/Sub 會使用 Google-owned and Google-managed encryption keys加密所有訊息，包括靜態和傳輸中的訊息。Pub/Sub 支援在應用程式層使用 CMEK 加密訊息。詳情請參閱「設定訊息加密」。 資料落地：如有資料落地規定，您可以設定訊息儲存政策，確保訊息資料儲存在特定位置。 |
| Cloud Logging |
管理活動稽核：根據預設，這個參考架構中使用的所有 Google Cloud 服務都會啟用管理活動記錄功能。您可以透過 Cloud Logging 存取記錄，並使用記錄監控 API 呼叫或其他動作，這些動作會修改 Google Cloud 資源的設定或中繼資料。 資料存取稽核：BigQuery 預設會啟用資料存取事件記錄。對於這個架構中使用的其他服務，您可以啟用資料存取稽核記錄。您可以使用這些記錄監控下列項目：
記錄資料安全性：Google 不會存取或使用 Cloud Logging 中的資料。 資料落地：為協助符合資料落地規定，您可以設定 Cloud Logging，將記錄資料儲存在您指定的區域。詳情請參閱「將記錄區域化」。 |
| 本架構中的所有產品 |
降低資料竊取風險：如要降低資料竊取風險，請在基礎架構周圍建立 VPC Service Controls 範圍。VPC Service Controls 支援此參考架構中使用的所有服務。 部署後最佳化：在 Google Cloud中部署應用程式後，使用 Active Assist 服務取得建議，進一步提升雲端資源的安全性。請查看建議，並視環境需要套用。詳情請參閱「在 Active Assist 中尋找建議」。 存取控管：針對每項雲端服務，遵循最小權限原則。 |
如需在Google Cloud中部署 AI 和 ML 時的一般安全防護指南，請參閱下列資源：
- (網誌) 隆重推出 Google 的安全 AI 架構
- (說明文件) AI 和機器學習安全觀點 位於 Google Cloud 架構完善架構
- (說明文件) Agent Platform 共同責任
- (白皮書) 生成式 AI、隱私權與 Google Cloud
- (影片) 保護 AI 應用程式中的機密資料
可靠性
本節說明設計考量事項和建議，協助您在 Google Cloud中建構及運作可靠的部署基礎架構。
| 產品 | 設計注意事項和建議 |
|---|---|
| Vector Search |
查詢調整：為確保向量搜尋索引可處理查詢負載增加的情況，您可以為索引端點設定自動調度資源。查詢負載增加時，節點數量會自動增加，但不會超過您指定的上限。詳情請參閱「啟用自動調度資源」。 |
| Cloud Run |
基礎架構中斷時的穩定性： Cloud Run 是區域服務。資料會同步儲存在區域內的多個可用區。系統會自動在各可用區之間進行負載平衡。如果發生可用區中斷事件，Cloud Run 會繼續執行，資料也不會遺失。如果發生區域性服務中斷，Cloud Run 會停止執行，直到 Google 解決中斷問題為止。 |
| Cloud Storage | 資料可用性：您可以在三種位置類型中建立 Cloud Storage 值區：單一地區、雙地區或多區域。儲存在區域值區中的資料，會在區域內的多個可用區之間同步複製。如要提高可用性，可以使用雙區域或多區域值區，將資料非同步複製到不同區域。 |
| Pub/Sub |
速率控制：為避免訊息流量暫時暴增時發生錯誤，您可以在發布者設定中設定流量控制，限制發布要求速率。 失敗處理：如要處理發布嘗試失敗的情況，請視需要調整重試要求變數。詳情請參閱「重試要求」。 |
| BigQuery | 基礎架構中斷時的穩定性：您載入 BigQuery 的資料會同步儲存在指定區域內的兩個可用區。這項備援機制可確保區域中斷時，資料不會遺失。如要進一步瞭解 BigQuery 的可靠性功能，請參閱「瞭解可靠性」。 |
| 本架構中的所有產品 | 部署後最佳化：在 Google Cloud中部署應用程式後，使用 Active Assist 服務取得建議，進一步提升雲端資源的可靠性。請查看建議，並視環境需要套用。詳情請參閱「在 Active Assist 中查看建議」。 |
如要瞭解 AI 和機器學習工作負載專用的可靠性原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：可靠性」。
成本最佳化
本節提供指引，說明如何盡量降低設定及運作 Google Cloud 拓撲的成本。您可使用本參考架構建構拓撲。
| 產品 | 設計注意事項和建議 |
|---|---|
| Vector Search |
Vector Search 的計費方式取決於索引大小、每秒查詢次數 (QPS)，以及您用於索引端點的節點數量和機型。對於高 QPS 的工作負載，批次處理查詢有助於降低成本。如要瞭解如何估算 Vector Search 費用，請參閱向量搜尋定價範例。 如要提高部署 Vector Search 索引的運算節點使用率，您可以為索引端點設定自動調度。當需求較低時，節點數量會自動縮減至您指定的下限。詳情請參閱「啟用自動調度資源」。 |
| Cloud Run |
建立 Cloud Run 服務時，您可以指定要分配給容器執行個體的記憶體和 CPU 數量。如要控管費用，請從預設 (最低) CPU 和記憶體配置開始。如要提升效能，可以設定 CPU 限制和記憶體限制，增加分配量。詳情請參閱下列說明文件： 如果您可以預測 Cloud Run 服務的 CPU 和記憶體需求，就能透過承諾用量折扣省下費用。詳情請參閱「Cloud Run 承諾使用折扣」。 |
| Cloud Storage | 對於用來將資料載入資料擷取子系統的 Cloud Storage bucket，請選擇合適的儲存空間級別。選擇儲存空間級別時，請考量工作負載的資料保留和存取頻率需求。舉例來說，如要控管儲存空間費用，您可以選擇 Standard 級別，並使用物件生命週期管理。這樣一來，系統就能根據您設定的條件，自動將物件降級至費用較低的儲存空間級別，或刪除物件。 |
| Cloud Logging |
如要控管記錄檔的儲存費用，可以採取下列做法： |
| BigQuery | BigQuery 可讓您在執行查詢前估算費用。如要盡量降低查詢費用，請最佳化儲存空間和查詢運算。詳情請參閱「估算及控管費用」。 |
| 本架構中的所有產品 | 在 Google Cloud中部署應用程式後，請使用 Active Assist 服務取得建議，進一步提高雲端資源的成本效益。請查看建議，並視環境需要套用。詳情請參閱「在 Active Assist 中查看建議」。 |
如要估算 Google Cloud 資源的費用，請使用 Google Cloud Pricing Calculator。
如要瞭解 AI 和機器學習工作負載專用的成本最佳化原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：成本最佳化」。
效能最佳化
本節說明設計拓撲時的考量事項和建議，以符合工作負載的效能需求。 Google Cloud
| 產品 | 設計注意事項和建議 |
|---|---|
| Vector Search |
建立索引時，請根據效能需求設定分片大小、距離測量類型，以及每個分葉節點的嵌入項目數量。舉例來說，如果應用程式對延遲變異性極為敏感，建議使用較大的分片大小。詳情請參閱「影響效能的設定參數」。 設定部署向量搜尋索引的節點運算容量時，請考量效能需求。選擇合適的機型，並根據預期的查詢負載設定節點數量上限。詳情請參閱「影響效能的部署設定」。
根據查詢效能、可用性和費用需求，設定向量搜尋索引的查詢參數。舉例來說， 最新的索引有助於提高生成回覆的準確度。您可以透過批次或串流更新，更新 Vector Search 索引。透過串流更新，您可以近乎即時地查詢更新後的資料。詳情請參閱「更新及重建有效索引」。 |
| Cloud Run |
根據預設，每個 Cloud Run 容器執行個體都會分配到一個 CPU 和 512 MiB 的記憶體。您可以根據效能需求設定 CPU 上限和記憶體上限。詳情請參閱下列說明文件： 如要確保即使一段時間沒有流量，延遲時間仍維持在最佳狀態，您可以設定執行個體數量下限。這類執行個體處於閒置狀態時，系統會以較低的價格計費。 如需更多效能最佳化指南，請參閱「Cloud Run 一般開發提示」。 |
| Cloud Storage | 如要上傳大型檔案，可以使用平行複合式上傳方法。採用這項策略時，系統會將大型檔案分割成多個區塊。這些區塊會平行上傳至 Cloud Storage，然後在雲端重組資料。如果網路頻寬和磁碟速度不是限制因素，平行複合上傳作業的速度會比一般上傳作業更快。不過，這項策略有一些限制，且會影響費用。詳情請參閱「平行複合式上傳」。 |
| BigQuery |
BigQuery 提供查詢執行圖，可用於分析查詢效能，並取得效能深入分析，瞭解是否發生時段爭用和 Shuffle 配額不足等問題。詳情請參閱「取得查詢效能深入分析」。 解決透過查詢效能洞察資訊發現的問題後，您可以使用減少輸入和輸出資料量等技巧，進一步最佳化查詢。詳情請參閱「最佳化查詢運算」。 |
| 本架構中的所有產品 | 在 Google Cloud中部署應用程式後，請使用 Active Assist 服務取得建議，進一步提升雲端資源的效能。請查看建議，並視環境需要套用。詳情請參閱「在 Active Assist 中查看建議」。 |
如要瞭解 AI 和機器學習工作負載的效能最佳化原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：效能最佳化」。
部署作業
如要部署以這個參考架構為基礎的拓撲，可以下載並使用 GitHub 存放區提供的 Terraform 範例設定。按照存放區中 README 的指示操作。程式碼範例「不」適用於實際工作環境。
後續步驟
- 為生成式 AI 應用程式選擇模型和基礎架構
- 使用 Agent Platform 和 AlloyDB for PostgreSQL 建構生成式 AI 的 RAG 基礎架構
- 使用 GKE 和 Cloud SQL 建構生成式 AI 的 RAG 基礎架構
- 使用 Gemini Enterprise 和 Agent Platform 建構生成式 AI 的 RAG 基礎架構
- 使用 Agent Platform 和 Spanner Graph 建構生成式 AI 的 GraphRAG 基礎架構
- 如要瞭解適用於 Google Cloud中 AI 和機器學習工作負載的架構原則和建議，請參閱 Well-Architected Framework 中的AI 和機器學習觀點。
- 如要查看更多參考架構、圖表和最佳做法，請瀏覽 Cloud Architecture Center。
貢獻者
作者：Kumar Dhanagopal | 跨產品解決方案開發人員
其他貢獻者：
- Assaf Namer | Principal Cloud Security Architect
- Deepak Michael | 網路專員客戶工程師
- Divam Anand | 產品策略與作業負責人
- Eran Lewis | 資深產品經理
- Jerome Simms | 產品管理總監
- Katie McLaughlin | 資深開發人員關係工程師
- Mark Schlagenhauf | 網路技術文件撰稿者
- Megan O'Keefe | 開發人員服務代表
- Nicholas McNamara | 產品和商業化策略主管
- Preston Holmes | 對外產品經理 - 應用程式加速
- Rob Edwards | DevOps 技術實務主管
- Victor Moreno | 雲端網路產品經理
- Wietse Venema | 開發人員關係工程師