在滿足數據居留要求的同時，使用AWS混合和邊緣服務實施RAG

隨著亞馬遜基岩代理 (Amazon Bedrock Agents) 的普遍可用性，您可以快速開發生成式人工智慧應用程式，以在各種企業系統和數據來源中執行多步驟任務。然而，一些受數據保護和隱私法規約束的地區和行業希望將雲端的生成式人工智慧服務與本地的受管數據結合。在這篇文章中，我們將展示如何將亞馬遜基岩代理擴展到混合和邊緣服務，如 AWS Outposts 和 AWS Local Zones，以建立使用本地數據的分散式檢索增強生成 (Retrieval Augmented Generation, RAG) 應用程式，以改善模型結果。透過 Outposts，我們還將介紹一個完全本地的 RAG 應用程式的參考模式，該應用程式要求基礎模型 (FM) 和數據來源都位於本地。

解決方案概述

對於處理或存儲敏感信息（例如個人可識別信息 (PII)）的組織，客戶要求 AWS 全球基礎設施解決這些特定地區的問題，包括確保數據存儲和處理符合當地法律和法規的機制。透過 AWS 的混合和邊緣服務，如 Local Zones 和 Outposts，您可以享受 AWS 雲端的可擴展性和靈活性，並利用本地基礎設施的低延遲和本地處理能力。這種混合方法允許組織在更接近數據來源的地方運行應用程式和處理數據，從而減少延遲，提高對於時間敏感工作負載的響應能力，並遵守數據法規。

雖然使用 Outposts 機架和 Local Zone 進行數據居留架構的討論已經廣泛，但生成式人工智慧和基礎模型引入了一組額外的架構考量。隨著生成式人工智慧模型變得越來越強大和普及，客戶詢問我們如何考慮將模型部署到更接近生成和消費數據的設備、傳感器和最終用戶。此外，對於小型語言模型 (SLM) 的興趣也在增長，這些模型使資源受限的設備能夠執行複雜的功能，例如自然語言處理和預測自動化。要了解客戶使用 SLM 的機會，請參閱我們 AWS 行業部落格上的《小型語言模型為電信業帶來的機會：來自 AWS 和 Meta 的見解》。

除了 SLM，對於邊緣生成式人工智慧的興趣主要受到兩個因素的驅動：

延遲 – 在邊緣基礎設施上運行這些計算密集型模型可以顯著減少延遲並改善實時響應能力，這對於許多時間敏感的應用程式（如虛擬助手、擴增實境和自動化系統）至關重要。

隱私和安全 – 在邊緣處理敏感數據，而不是將其發送到雲端，可以通過最小化數據暴露來增強隱私和安全性。這在醫療保健、金融服務和法律行業中特別有用。

在這篇文章中，我們涵蓋了兩種主要的架構模式：完全本地 RAG 和混合 RAG。

完全本地 RAG

在 Outposts 機架上部署大型語言模型 (LLM) 的 RAG 用例中，LLM 將在 G4dn 實例上自我託管，並在 Outpost 機架上創建知識庫，使用 Amazon 彈性區塊存儲 (Amazon Elastic Block Storage, Amazon EBS) 或 Amazon S3。上傳到機架上知識庫的文件可能是私密和敏感的，因此不會轉移到 AWS 區域，並將完全保留在 Outpost 機架上。您可以使用本地向量數據庫，無論是託管在 Amazon 彈性計算雲 (Amazon Elastic Compute Cloud, Amazon EC2) 上，還是使用 Amazon 關聯數據庫服務 (Amazon Relational Database Service, Amazon RDS) 的 PostgreSQL 在 Outpost 機架上，並使用 pgvector 擴展來存儲嵌入。以下圖示為例。

混合 RAG

某些客戶因數據保護或隱私法規要求必須將其數據保留在特定的州界內。為了符合這些要求並仍然使用這些數據進行生成式人工智慧，擁有混合和邊緣環境的客戶需要在區域和邊緣同時託管其基礎模型 (FM)。這種設置使您能夠將數據用於生成目的，同時遵守安全法規。要協調這種分散系統的行為，您需要一個能夠理解提示細微差別的系統，並將您引導到在合規環境中運行的正確 FM。亞馬遜基岩代理使得在混合系統中實現這種分散系統成為可能。

亞馬遜基岩代理使您能夠在應用程式中構建和配置自主代理。代理協調 FM、數據來源、軟體應用程式和用戶對話之間的互動。協調包括調用 AWS Lambda 函數以調用其他 FM 的能力，開啟了在邊緣運行自我管理 FM 的可能性。透過這個機制，您可以為受到數據居留要求的高度受管行業構建分散式 RAG 應用程式。在混合部署場景中，根據客戶提示，亞馬遜基岩可以在指定區域執行某些操作，並將其他操作延遲到在 Local Zone 中自我託管的 FM。以下示例說明了混合 RAG 的高層架構。

在接下來的部分中，我們將深入探討這兩種解決方案及其實施。

完全本地 RAG：解決方案深入探討

首先，您需要在 Outpost 機架上配置虛擬私有雲 (VPC) 和邊緣子網。要在 Outpost 上創建邊緣子網，您需要找到要創建子網的 Outpost 亞馬遜資源名稱 (ARN)，以及 Outpost 的可用區。創建互聯網閘道、路由表和子網關聯後，啟動一系列 EC2 實例在 Outpost 機架上運行您的 RAG 應用程式，包括以下組件。

向量存儲 – 為了支持 RAG（檢索增強生成），在 AWS Outposts 上的 EC2 實例（C5 系列）上部署開源向量數據庫，如 ChromaDB 或 Faiss。這個向量數據庫將存儲您的文檔的向量表示，作為本地知識庫的關鍵組件。您選擇的嵌入模型將用於將文本（包括文檔和查詢）轉換為這些向量表示，以實現高效的存儲和檢索。實際的知識庫由原始文本文檔及其對應的向量表示組成，這些向量表示存儲在向量數據庫中。要查詢這個知識庫並根據檢索到的結果生成回應，您可以使用 LangChain 將通過向量搜索檢索到的相關文檔鏈接到提供給大型語言模型 (LLM) 的提示中。這種方法允許檢索並將相關信息整合到 LLM 的生成過程中，增強其回應的本地、特定領域知識。

聊天機器人應用程式 – 在第二個 EC2 實例（C5 系列）上，部署以下兩個組件：一個負責接收提示並將請求代理回在 Outpost 上運行的 LLM 的後端服務，以及一個簡單的 React 應用程式，讓用戶可以向本地生成式人工智慧聊天機器人提出問題。

LLM 或 SLM – 在第三個 EC2 實例（G4 系列）上，部署 LLM 或 SLM 以通過流行框架（如 Ollama）進行邊緣推理。此外，您可以使用 SageMaker SDK 的 ModelBuilder 將其部署到本地端點，例如運行在邊緣的 EC2 實例。

可選地，您的底層專有數據來源可以存儲在 Outposts 上的亞馬遜簡單存儲服務 (Amazon Simple Storage Service, Amazon S3) 中，或使用運行在亞馬遜 EC2 實例上的與亞馬遜 S3 兼容的解決方案，並使用 EBS 卷。

這些組件通過以下圖示所示的流量流進行互通。

工作流程包括以下步驟：

使用前端應用程式，用戶上傳將作為知識庫的文檔，並存儲在 Outpost 機架上的 Amazon EBS 中。這些文檔由應用程式進行分塊，並發送到嵌入模型。

嵌入模型在與本地 LLM API 推理伺服器相同的 EC2 實例上進行託管，將文本塊轉換為向量表示。

生成的嵌入被發送到向量數據庫並存儲，完成知識庫的創建。

通過前端應用程式，用戶向聊天機器人介面提出問題。

提示被轉發到本地 LLM API 推理伺服器實例，在那裡提示被標記並使用本地嵌入模型轉換為向量表示。

問題的向量表示被發送到向量數據庫，進行相似性搜索以獲取來自知識庫的匹配數據來源。

當本地 LLM 獲得查詢和來自知識庫的相關上下文後，它處理提示，生成回應，並將其發送回聊天機器人應用程式。

聊天機器人應用程式通過其介面向用戶展示 LLM 的回應。

要了解更多關於完全本地 RAG 應用程式的資訊或親自體驗示範應用程式，請參閱我們公共 AWS 工作坊的第二模組：《在 AWS 混合與邊緣服務上實作生成式人工智慧》。

混合 RAG：解決方案深入探討

首先，您需要配置一個 VPC，並設置一個邊緣子網，這可以對應於 Outpost 機架或 Local Zone，具體取決於用例。在創建互聯網閘道、路由表和子網關聯後，在 Outpost 機架（或 Local Zone）上啟動一個 EC2 實例以運行您的混合 RAG 應用程式。在 EC2 實例上，您可以重用與完全本地 RAG 相同的組件：向量存儲、後端 API 伺服器、嵌入模型和本地 LLM。

在這個架構中，我們非常依賴於管理服務，如 Lambda 和亞馬遜基岩，因為只有與高度受管數據相對應的特定 FM 和知識庫需要存在於邊緣，而不是協調器本身。為了做到這一點，我們將擴展現有的亞馬遜基岩代理工作流程到邊緣，使用一個由 FM 驅動的客戶服務機器人示例。

在這個客戶服務機器人示例中，我們是一個鞋類零售商機器人，提供購買鞋子的客戶服務支持，並以類似人類的對話提供選項。我們還假設有關製鞋的知識庫是專有的，因此位於邊緣。因此，關於製鞋的問題將由知識庫和在邊緣運行的本地 FM 解決。

為了確保用戶提示有效地代理到正確的 FM，我們依賴於亞馬遜基岩代理的動作組。動作組定義了代理可以執行的動作，例如下訂單或檢查庫存。在我們的示例中，我們可以在現有的動作組中定義一個額外的動作，稱為 hybrid_rag 或 learn_shoemaking，專門處理只能由 AWS 混合和邊緣位置解決的提示。

作為代理的 InvokeAgent API 的一部分，代理會與 FM 解釋提示（例如「製鞋時如何使用皮革？」），並生成下一步應採取的邏輯，包括對動作組中最明智行動的預測。在這個示例中，我們希望提示「你好，我想要一些鞋子的購買建議。」被指向 /check_inventory 動作組，而提示「製鞋時如何使用皮革？」則可以指向 /hybrid_rag 動作組。

以下圖示說明了這種協調，該協調由亞馬遜基岩代理的協調階段實現。

要創建額外的邊緣特定動作組，新的 OpenAPI 架構必須反映新的動作 hybrid_rag，並包含詳細描述、結構和參數，這些參數定義了在特定邊緣位置僅可用的數據領域的動作組中的動作作為 API 操作。

在使用 OpenAPI 規範定義動作組後，您可以定義一個 Lambda 函數來編程動作組的業務邏輯。這個 Lambda 處理程序（見以下代碼）可能包括支持函數（例如 queryEdgeModel），用於對應於每個動作組的個別業務邏輯。

然而，在對應於邊緣 LLM 的動作組中（如下代碼所示），業務邏輯不會包括基於區域的 FM 調用，例如使用亞馬遜基岩 API。相反，將調用客戶管理的端點，例如使用在 Local Zone 或 Outpost 中託管邊緣 FM 的 EC2 實例的私有 IP 地址。這樣，AWS 原生服務如 Lambda 和亞馬遜基岩可以協調複雜的混合和邊緣 RAG 工作流程。

當解決方案完全部署後，您可以訪問亞馬遜基岩代理控制台上的聊天遊樂場功能，並詢問問題「鞋子的橡膠鞋跟是如何製作的？」儘管大多數提示將專注於鞋子訂購的零售客戶服務操作，但亞馬遜基岩代理的原生協調支持無縫地將提示引導到運行 LLM 的邊緣 FM。

要了解更多關於這個混合 RAG 應用程式或親自體驗跨環境應用程式，請參閱我們公共 AWS 工作坊的第一模組：《在 AWS 混合與邊緣服務上實作生成式人工智慧》。

結論

在這篇文章中，我們展示了如何將亞馬遜基岩代理擴展到 AWS 混合和邊緣服務，如 Local Zones 或 Outposts，以在受到數據居留要求的高度受管行業中構建分散式 RAG 應用程式。此外，為了與最嚴格的數據居留要求保持一致，我們提出了將知識庫、計算和 LLM 整合在 Outposts 硬體內的架構。

要開始使用這兩種架構，請訪問 AWS 工作坊。要開始使用我們新發布的工作坊，請參見《在 AWS 混合與邊緣服務上實作生成式人工智慧》。此外，查看其他 AWS 混合雲解決方案或聯繫您的當地 AWS 帳戶團隊，了解如何開始使用 Local Zones 或 Outposts。

關於作者

羅伯特·貝爾森 (Robert Belson) 是 AWS 全球電信業務單位的開發者倡導者，專注於 AWS 邊緣計算。他專注於與開發者社群和大型企業客戶合作，使用自動化、混合網絡和邊緣雲解決他們的商業挑戰。

阿迪提亞·洛拉 (Aditya Lolla) 是亞馬遜網路服務的高級混合邊緣專家解決方案架構師。他協助全球客戶從本地環境遷移和現代化到雲端，並在 AWS 邊緣基礎設施上構建混合架構。阿迪提亞的興趣領域包括私有網絡、公有和私有雲平台、多接入邊緣計算、混合和多雲策略以及計算機視覺應用。