aws-genai-llm-chatbot：用 CDK 把多模型 RAG 聊天機器人整包部署進你的 AWS 帳號
A modular and comprehensive solution to deploy a Multi-LLM and Multi-RAG powered chatbot (Amazon Bedrock, Anthropic, HuggingFace, OpenAI, Meta, AI21, Cohere, Mistral) using AWS CDK on AWS
秒懂
- 它是什麼？
- 這個 AWS 官方範例把 Bedrock、SageMaker、OpenSearch、Cognito 與 React 前端組成一套可部署的 CDK 應用。它的價值在於省下組裝時間，代價是你得接受一整套基礎設施的維運與升級節奏。
- 適合誰用？
- 如果你已經在 AWS 上、需要一個能接多個模型供應商並自帶 RAG 的內部問答系統，這個範例能讓你在數小時內得到可運作的雛型，前提是你的團隊熟悉 CDK 與 IAM。若你只需要單一模型、單一資料源的輕量聊天介面，整套 OpenSearch、Cognito、API Gateway 的組合會讓你的維運負擔遠超過問題本身。
- 可以商用嗎？
- 可以。MIT-0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 不再維護。擁有者已在 GitHub 上將儲存庫封存，儲存庫變為唯讀，不會再有更新。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是組裝問題，不是模型問題
多數團隊卡住的地方不是呼叫 LLM，而是把 LLM 接進一個有登入、有權限、有對話歷史、有文件檢索的系統。這個專案針對的正是這段工程。README 把它定位為 enterprise-ready 的生成式 AI 聊天機器人，具備 RAG 能力，並且明列多模型支援：Amazon Bedrock 上的 Claude 與 Llama 2、SageMaker 端點，以及自訂模型端點。目標讀者是有 AWS 帳號、有 IAM 管理能力、想把問答功能放進內部系統的後端或平台團隊。它不處理模型微調，也不處理資料清理，這些仍然是你自己的事。
架構：CDK 堆疊串起的六個服務
README 列出的架構包含 Amazon Bedrock 作為模型存取層、Amazon OpenSearch 作為向量儲存、Amazon S3 存放文件、Amazon Cognito 處理驗證、AWS Lambda 做無伺服器處理、Amazon API Gateway 提供 API，前端是 React 介面。資料流大致是：文件進 S3，經 Lambda 切分與向量化後寫入 OpenSearch，使用者提問時由 API Gateway 接收，Lambda 先做語意檢索取回相關片段，再連同對話歷史送進模型。對話記憶由持久化儲存支撐。值得注意的是部署並非單純 cdk deploy，README 說部署流程由 AWS CDK 與 SeedFarmer 共同自動化，這意味著模組化拆分，也意味著你要多理解一層工具鏈。
從 clone 到 cdk deploy 之間的前置條件
README 列出的前置條件相當具體：AWS 帳號與相應權限、已設定認證的 AWS CLI、Node.js 18+ 與 npm、Python 3.8+，以及與 aws-cdk-lib 2.206.0 或更新版本相容的 CDK CLI。安裝指令是 npm install -g aws-cdk@latest，驗證用 cdk --version。這裡有個容易踩的坑，README 特別提醒若部署時出現 Cloud assembly schema version mismatch 錯誤，就是 CDK CLI 版本落後，要用同一道安裝指令更新。這類錯誤訊息本身不好懂，先確認版本再部署能省下不少排查時間。
多模型切換與 RAG 資料源是它的主要賣點
專案同時掛上 amazon-bedrock、sagemaker、kendra、opensearch、pgvector、langchain 等主題標籤，README 也提到可連接多種資料源做上下文感知回應。對照 v5.0.0 於 2025 年 1 月發布，而前一版 v4.0.14 停在 2024 年 8 月，可以看出主要版本之間的間隔約半年，中間是修補版本。這種節奏對範例專案算正常，但你要意識到：當你把它當成產品基礎，升級就跟著上游走，而主要版本跳動通常伴隨破壞性變更。
什麼情況下這套東西反而是負擔
如果你的需求只是單一模型、少量文件的問答，這整套組合並不合適。OpenSearch 叢集、Cognito 使用者池、API Gateway、Lambda 與 S3 一起上線，代表你要面對向量索引的容量規劃、Cognito 的使用者生命週期、以及跨服務的 IAM 政策。這些都是真實的維運面。另一個限制是它綁定 AWS：模型存取走 Bedrock 與 SageMaker，向量儲存走 OpenSearch，驗證走 Cognito。想搬到其他雲或自建，等於重寫。若你已經有既有的身分系統或既有的向量資料庫，硬套這個範例只會多一層要維護的抽象。
與 LangChain 自建路線的差別
另一條常見路線是用 LangChain 加上自己的 FastAPI 服務，自己接向量庫與模型 API。差別在責任邊界。自建路線把檢索邏輯、切分策略、prompt 組裝都攤在你的程式碼裡，你能逐行調整，但登入、權限、前端、部署管線都得自己寫。這個專案把這些都預先綁好，代價是彈性被 CDK 堆疊的結構限制住，想改一段檢索流程往往要先讀懂它怎麼分層。專案本身也用了 LangChain，所以這不是二選一的技術對立，而是你要不要接受一整套已經組好的預設。
授權與升級成本
授權是 MIT-0，這是最寬鬆的一類，允許使用、修改與再散布，且不要求保留姓名標示。對商業內部系統而言這通常不是阻礙，但這只是授權條款層面的描述，實際部署後你仍需自行確認所接模型供應商的服務條款，例如 Bedrock 上各模型的可用區域與資料處理政策。升級成本方面，由於部署依賴 CDK 與 SeedFarmer，每次跟版都要重跑一次完整的合成與部署流程，並確認 CDK CLI 與 aws-cdk-lib 版本對齊。這不是可以隨手更新的依賴，建議在測試帳號先跑一次再動正式環境。
編輯結論
如果你已經在 AWS 上、需要一個能接多個模型供應商並自帶 RAG 的內部問答系統，這個範例能讓你在數小時內得到可運作的雛型，前提是你的團隊熟悉 CDK 與 IAM。若你只需要單一模型、單一資料源的輕量聊天介面，整套 OpenSearch、Cognito、API Gateway 的組合會讓你的維運負擔遠超過問題本身。動手前先確認兩件事：你的 CDK CLI 版本是否與 aws-cdk-lib 2.206.0 相容，以及你是否真的需要多模型切換這個能力。
社群筆記