隨著生成式AI的應用越來越廣為人知，不少企業紛紛躍躍欲試，期望能夠透過概念驗證方式找到專屬於企業的最佳應用。當企業逐步進入大規模的生產部署階段時，成本和效能成為首要考量。為了應對這些挑戰，客戶通常會採用傳統的快取技術來降低讀取密集型工作負載的成本。然而，在生成式 AI 的領域，其困難點之一在於應用程式（例如聊天機器人）如何有效快取所接收的自然語言請求，因為輸入的表達方式可能有多種變化。
博弘雲端架構師專欄，今天要來帶企業看如何使用「Amazon MemoryDB」的向量搜尋功能，如何部署 MemoryDB 作持久性的語義快取層（Permanent Semantic Cache），透過根據查詢中的語義意涵或上下文儲存回應。不僅如此，我們更會結合 Amazon Bedrock 的知識庫，藉由實施檢索增強生成（RAG）技術，知識庫會搜尋數據以找到最有用的資訊，並用於回答自然語言問題，從而提升生成式 AI 應用程式的效能！
為什麼選擇Memory DB 與 BedRock 來降本增效？
在開始之前，本次的架構師實戰案例當中，會透過Amazon MemoryDB 中使用持久性語義快取並與 Amazon Bedrock 知識庫結合的概念，建立一個使用該快取的聊天機器人應用程式作為示範。為什麼會選擇 MemoryDB 作為這次應用場景的快取層？主要原因是，它在 AWS 主流的向量資料庫中，提供了最快的向量搜尋性能和最高的召回率。另外，這次示範中用到 Amazon Bedrock 的知識庫作為向量資料庫，讓您無需撰寫額外的程式碼，即可讓應用程式實現並維護了 RAG 功能。
持久性的語意快取層是什麼？
持久性記憶體資料庫可以作為持久的語意快取，用來儲存向量嵌入（白話文：捕捉非結構化數據語意關係的數值表示，像是文字、影音與圖片等），並能在毫秒內進行檢索。這種資料庫不僅限於精確匹配，還能透過向量空間進行不同類型的查詢，找出相似項目。
舉例來說，當使用者向聊天機器人提問時，問題的文本會轉換成數值表示（嵌入向量），並用來搜尋先前已回答的相似問題。一旦找到相似問題，該問題的答案也可直接供應應用程式使用，無需查詢知識庫或向大型基礎模型（Foundation Models, FM）發出請求。 這樣做有兩大好處，首先是降低延遲，因為減少了對大型模型和知識庫的請求；另外則是減少處理請求的時間，降低運算成本，特別是對使用 AWS Lambda 等無伺服器架構的企業。
動手實作部署前 六個必知的提醒！
部署本次的架構之前，有六個您必須要知道的溫馨提醒，以便在運用Amazon MemoryDB 替生成式AI應用程式進行降本增效前，有效理解AWS雲端架構的部署訣竅：
- 本次的架構設計遵照AWS最佳實踐，將快取系統部署在私有子網路中。因此，Lambda 函數被部署在與 MemoryDB 叢集相同的虛擬私有雲（VPC）中。
- 使用 RANGE 查詢在快取中尋找語意上相似的問題，並將半徑參數設置為 0.4。半徑參數決定問題必須有多相似才能命中快取（檢索到結果）。數值越低，要求的相似度越高。這個值通常透過實驗設定，並取決於問題的多樣性、知識庫的多樣性，以及在快取命中率、成本與準確性之間的平衡。進行此查詢的程式碼可在 GitHub 儲存庫中的 Lambda 函數內找到。
- 為簡化操作，這次使用使用 NAT 閘道（NAT Gateway）來訪問 Amazon Bedrock API。為了避免與 NAT 閘道相關的網路費用或數據傳輸成本，建議使用 AWS PrivateLink。
- Lambda 函數啟用了 Amazon X-Ray 追蹤功能，可以提供每個 API 呼叫的延遲詳情。
- 為了簡化操作，已部署的 API 使用 API 金鑰進行強制認證。當需要用戶層級的認證時，建議使用 API Gateway 配合 Lambda 認證器或 Amazon Cognito 認證器。
- 此程式碼適用於開發環境。在將此解決方案遷移到生產環境之前，我們建議遵循 AWS Well-Architected Framework。
究竟在架構部署方面該如何一步一步將Amazon MemoryDB設定建置在開發環境中？在下一期的博弘雲端架構師專欄當中，我們將帶您進一步掌握！