[Day 26] RAG CI/CD 從 Git Push 到自動化 Production Deployment

我們把 RAG 從 Docker Container 推進到 Production Deployment

但很快又會遇到一個問題：

難道每次修改程式，都要自己 Build Docker，再 SSH 到 Server 部署嗎

如果每天都要手動執行：

不但耗時間，也很容易因為人工操作造成錯誤

因此今天要把 Deployment 自動化

這就是：

CI/CD

CI/CD 到底在解決什麼問題

先看沒有 CI/CD 的情況

其餘流程交給自動化 Pipeline

二、CI 與 CD 有什麼不同

CI/CD 很常被一起講，但其實可以拆成兩個部份

CI：Continuous Integration

重點是：

每次程式碼更新都自動驗證

目的：

不要讓有問題的 Code 進入下一階段

CD：Continuous Delivery or Deployment

把已經通過驗證的版本送到 Production

CD 又可以有兩種意思

Production 還需要人工確認

全部通過後：

自動部署 Production

Production 環境通常會根據風險決定是否需要人工 Approval

RAG 為什麼比一般 Web Application 更需要 CI/CD

一般 Web Application 可能只需要確認 HTTP 200

但 RAG 的問題更複雜

回答品質也可能下降

所以：

RAG 的 CI/CD 不只是測 Code，也要測 AI 品質

第一步：Git 作為 CI/CD 的起點

CI/CD 通常會從 Git Repository 的事件開始

當 Git Server 偵測就觸發

這樣 Production Branch 就不會被隨意修改

RAG Integration Test

Unit Test 只能確認單一 Function

但 RAG 是一條 Pipeline

因此還需要 Integration Test

這類測試可以避免：

Pipeline 雖然啟動成功，但核心功能已經壞掉

因為：

AI 系統的正確性不只取決於 Code 是否能執行

從最初的：

「我想做一個會回答問題的 AI 助理」

一路走到現在：

「我可以建立、評估、監控、擴展、部署，並持續交付一套 Production RAG 系統」

這才是這 30 天真正想建立的能力

CI/CD 建立之後

但還有一個問題：

Production 上線之後，如果流量持續增加、服務需要更新、Container 數量變多，誰來管理這些 Container

因此下一步會進入：

Day 27：RAG 從 Docker Compose 走向 Kubernetes

讓這套 RAG 系統從「可以自動部署」，進一步走向：

可以由平台自動管理與維持運行