[Day 25] RAG 從 Docker Container 到 Production 部署

前幾天，我們已經逐漸把 RAG 從「可以回答問題的 Demo」推向 Production

但這裡還有一個很實際的問題：

我們的 RAG 系統到底要怎麼部署成 Production

如果每次部署都需要設定環境、啟動服務

那麼系統即使架構設計得再漂亮，也很難稱為真正的 Production System

因此今天要把重點放在：

如何把 RAG Application 打包成可以重複部署、更新與管理的 Production Service

Deployment 到底在解決什麼問題？

先想像一個最常見的情境

本機開發可以正常執行

到了 Production Server 因環境變數不同造成執行失敗

這就是：

Environment Inconsistency

Docker 就是解決這類問題的重要工具之一

Docker 到底在做什麼

Docker 的核心概念就是可以簡化

因此 Production Server 不需要手動重新安裝整套環境

Docker 映像 與 Container 有什麼不同

這是使用 Docker 前一定要理解的概念

Docker 映像

Application 的「封裝版本」

Docker Container

Container 則是：

實際執行後的 Instance

Docker 映像不是越小越好

如果 Application 需要額外的系統套件，也必須納入

設定工作目錄

目的：

不要把不需要的檔案放進 Docker 映像

Production 不只是「能跑」

今天很重要的一個觀念：

Deployment ≠ docker run 成功

Production 還需要考慮很多因素

所以今天真正要學的是：

Production Deployment Workflow

Docker Compose：建立整個 RAG Stack

如果每個服務都手動會很麻煩。

Container 之間怎麼互相連線

這是 Docker 很重要的概念

Compose Network 裡的 Service Name

這也是 Container Networking 的基本概念

RAG 的 Vector DB 怎麼處理

這裡要特別注意 Retrieval 結果不一致

因此 Production 要把 Vector DB 當成：

獨立的 Shared Data Service

這對 AI 系統尤其重要

因為新的 Prompt、Embedding Model、Reranker 或 RAG Pipeline 版本，都可能影響回答品質

那 Production RAG 其實還是有問題

因此：

需要注意 Configuration 隨環境注入

這是非常重要的 Deployment 原則

今天學到什麼

今天真正要記住的不是 Docker 指令，而是 Production Deployment 的完整思維

這幾天其實是在建立一個完整的 Production Engineering Loop

現在已經學習到

怎麼讓 RAG 回答得好

怎麼知道它到底好不好

怎麼讓它成為一個可以長期運作的 Production System

當 Deployment 建立之後，下一個很自然的問題就是：

每次 Code Push 都要自己 Build Docker、跑 Test、Push、部署 Production 嗎

很快就會變成新的維運負擔

因此下一步會進入：

Day 26：RAG CI/CD 從 Git Push 到自動化

將把今天的 Deployment 流程進一步自動化

到這裡，這套「智慧助理」才會真正從：

「我可以把它跑起來」

走向：

「我可以持續、可靠地把它交付給使用者」