在上週的架構師專欄當中，我們提到了使用「Amazon MemoryDB」以及「Amazon BedRock 」來替生成式AI的應用程式降本增效的理論，同時採用持久性語意快取層的方法，解決成本與延遲性過高的問題。而本週的架構師專欄，博弘雲端將帶您看要部署哪些解決方案，來讓生成式AI應用程式達到平衡的成本效益，增加其效能！
如何佈建MemoryDB架構？
在這次的解決方案建置當中，將會採用AWS良好架構框架的準則，並且使用Amazon MemoryDB 中的持久性語意快取層，來替生成式AI應用將本增效：
這項解決方案架構是以「創建自動聊天機器人」為設計，對於任何已經回答過的問題，應用程式可以從緩存中找到答案並直接返回給使用者，甚至連相似的問題，都無需搜索文檔或再度調用基礎模型，就可以直接提供緩存內的答案。詳細的工作流程如下：
- 使用者藉由Amazon API Gateway的URL從終端使用設備中提出問題。
- 當API Gateway接收到請求時，會調用一個Lambda函數。
- Lambda函數使用Amazon Titan Embeddings G1 – Text模型將問題轉換為嵌入，這是為了在緩存中搜索問題所需要佈建的服務。
- Lambda函數使用前一步生成的嵌入來搜索由MemoryDB支持的持久性語義緩存。假設找到類似問題的話，該問題的答案將返回給使用者。
- 如果沒有找到類似問題，Lambda將使用Amazon Bedrock的知識庫來搜索與問題相關的文章，並調用Amazon Bedrock上的Anthropic Claude 3 Sonnet模型生成答案。
- 最後，Lambda函數將生成的答案保存到MemoryDB持久性緩存中，以便後續類似查詢中重複使用，並將答案返回給用戶。
然而，實際應用中，還有許多因素會影響對使用者的客製化回答。在這些情況下，企業可能不希望對語義上相似的問題使用相同的緩存答案，怕會讓人覺得「這家企業怎麼用同樣的答案敷衍我」。
因此，為了解決這個問題，MemoryDB允許在向量搜索查詢中進行預過濾。舉例來說，如果您有特定領域的答案，可以用這些領域標籤來標記緩存的響應，這樣您就可以在與用戶相關的領域中預過濾向量空間，從而只根據地理位置與年齡，給予跟使用者相關語義上，相似問題的緩存答案。
速度實測！採用MemoryDB後能夠增加多少效能？
第一次執行這個Lambda 函數的調用可能需要幾秒鐘。我們在實測，輸出顯示了API第一次響應「營運卓越支柱是什麼？」這個問題時，耗費5.021秒。然而，後續的API調用所需的時間更短，甚至可以來到毫秒等級。因為第一次生成答案後，結果已經存儲在持久性緩存中。 透過 Amazon X-Ray 追蹤控制台上可以看到調用的延遲細節。從下圖顯示，大部分時間花在使用Amazon Bedrock的知識庫和Anthropic Claude 3 Sonnet來回答問題上（4.30秒），而將答案添加到緩存中僅需0.005秒（5毫秒）。
大家也好奇說，同樣的問題像是「請告訴我更多有關營運卓越支柱」的部分，其實也能夠在緩存中找到，因為這個問題與先前所詢問的「營運卓越支柱是什麼？」在語意上非常相似。所以實測當中，即便「請告訴我更多有關營運卓越支柱」這個問題並沒有被問過，但仍然只花了0.589秒就產生出答案給使用者。
採用MemoryDB後 省下多少的計算成本？
現在我們可以根據不同的緩存命中率，換算出「持久性語義緩存」在大規模應用中，能夠替這個聊天機器人節省多少的時間與成本。假設聊天機器人每天收到10萬個問題來算的話，試算表提供給大家參考：
- 在緩存中找到的答案（緩存命中）需要0.6秒（600毫秒）返回給使用者。這包括整個API調用過程，其中緩存讀取只需要數毫秒。
- 未在緩存中找到的答案，且需要由Anthropic Claude 3 Sonnet生成的答案需要6秒，才能返回給使用者。這中間包括整個API調用過程，加上將響應添加到緩存中只需單位數毫秒。
- 每個問題需要1,900個輸入標記和250個輸出標記，Anthropic Claude 3的收費標準為每1,000個輸入標記$0.003，每1,000個輸出標記$0.015。
- 使用了一個包含三個db.r7g.xlarge實例的MemoryDB集群，費用為每小時$0.617，100%的利用率，以及每天寫入17 GB數據，費用為每GB $0.20。緩存已提前加熱。
在這樣的計算結果下，一個月企業能夠省下1300多美金（相當於近4萬台幣），這對有大量聊天機器人應答需求的企業來說，是省下莫大成本非常重要的策略！
您是否也對於生成式AI的博弘雲端架構師擁有絕佳的技術能力，不僅能夠在生成式AI應用程式中協助客戶達成商業目標，更能夠應對相關的成本策略，進行節費，讓您能夠用精準預算，達到龐大效益，完成重要的商業里程碑！