完整定義
AI 系統架構（AI System Architecture）涵蓋從資料收集、預處理、模型訓練到推論服務的完整技術鏈。常見架構包含：數據管道（Data Pipeline）、特徵 Store、模型訓練叢集、推論服務（REST API/gRPC）、監控儀表板。iPAS 考試重點：能根據業務需求設計合適的 AI 部署架構，理解公有雲、私有雲與混合雲的選型考量。
白話說明
你有沒有想過，當你對 Siri 說「明天台北天氣如何」，這句話要經過多少個系統才能變成一個回答？
語音先被轉成文字，文字被理解成意圖，意圖去查天氣資料庫，查到的資料再被組成一句話念給你聽。這整條路徑上的每一個元件怎麼連接、怎麼分工、怎麼部署，就是AI系統架構在解決的問題：它不是某一個模型，而是讓模型能在真實環境中穩定運作的完。
你可以把它想成一個先回答「用途是什麼」的入口，抓住生活場景後，再看技術細節會更容易。
記住這句
模型是引擎，系統架構是整台車的設計圖。
容易混淆
AI 系統架構 vs 模型架構 vs MLOps
模型架構：指模型內部的結構設計（例如 Transformer 有幾層、注意力機制怎麼接），只關注「模型本身」。
AI 系統架構：指模型加上周圍所有支撐系統的完整技術結構（資料管道、推論服務、監控），關注「模型怎麼在生產環境中運作」。
MLOps：指維運 AI 系統的流程和工具（CI/CD、模型版本管理、自動化部署），關注「怎麼持續交付和維護」。
最關鍵的區別：模型架構是零件設計，系統架構是整台機器的藍圖，MLOps 是讓這台機器持續運轉的維修手冊。
實際案例
電商推薦系統
一家電商想在用戶瀏覽商品時即時推薦相關產品。模型本身只是一小塊，完整的系統架構包含：用戶行為收集管道（點擊、瀏覽、購買）、特徵儲存庫（把原始行為轉成模型可用的數值）、訓練叢集（每天用最新資料重新訓練模型）、推論服務（每次頁面載入時在 50 毫秒內回傳推薦結果）、A/B 測試框架（比較新舊模型的轉換率）、監控儀表板（追蹤推論延遲和模型準確度）。少了任何一層，推薦功能都無法穩定上線。
自駕車的邊緣部署
自駕車不能靠雲端做決策，因為網路延遲可能致命。系統架構需要把模型部署在車上的邊緣裝置，同時設計雲端和邊緣的分工：邊緣負責即時感知和決策（毫秒級），雲端負責收集駕駛資料、重新訓練模型、再把更新版推回車上。這種雲邊協同的架構，是 AI 系統架構中最複雜的類型之一。
算法與應用
- 層級
- 資料層
- 負責什麼
- 蒐集、清洗、儲存訓練和推論用的資料
- 關鍵元件
- 資料管道、資料湖、特徵儲存庫
- 層級
- 模型層
- 負責什麼
- 訓練、評估、版本管理模型
- 關鍵元件
- 訓練叢集、實驗追蹤、模型註冊表
- 層級
- 服務層
- 負責什麼
- 將模型包裝成 API 供應用呼叫
- 關鍵元件
- REST/gRPC 推論服務、負載平衡、快取
- 層級
- 監控層
- 負責什麼
- 追蹤系統健康度和模型表現
- 關鍵元件
- 延遲監控、資料漂移偵測、告警系統
- 模式
- 全雲端
- 適用場景
- 用戶量大但延遲要求不嚴格
- 優缺點
- 彈性擴展容易，但依賴網路
- 模式
- 邊緣部署
- 適用場景
- 延遲要求極高（自駕、工業控制）
- 優缺點
- 即時回應，但裝置運算資源有限
- 模式
- 混合雲邊
- 適用場景
- 需要即時推論又需要雲端訓練
- 優缺點
- 兼顧兩者，但架構複雜度最高
情境判斷
Q1（直覺題）： 一家新創公司想上線一個聊天機器人，用戶量初期不大，團隊只有三個工程師。應該自己從零搭建完整的 AI 系統架構，還是用雲端託管服務（如 AWS SageMaker）？
用雲端託管服務。團隊小、用戶少的階段，自建架構的維運成本遠超收益，託管服務把資料管道、訓練、部署都包好了，讓團隊專注在模型和產品上。
Q2（判斷題）： 一家醫院想部署一個 AI 輔助診斷系統，法規要求病患資料不能離開醫院內網。應該選公有雲、私有雲、還是混合架構？
看情況。資料不能出院意味著訓練和推論都必須在院內完成，私有雲是基本要求。但如果醫院想用外部的大型預訓練模型做遷移學習，可能需要混合架構：在公有雲用去識別化資料做預訓練，再把模型搬回院內用真實資料微調。純粹的法規遵循選私有雲，兼顧模型能力選混合架構。
iPAS 考題
出題方向： 高頻考點，常考根據業務需求選擇部署架構（雲端/邊緣/混合）、各層級元件的功能辨識。
題目
在 AI 系統架構中，負責將訓練好的模型包裝為可供應用程式呼叫的服務，屬於哪個層級？
(A) 資料層 (B) 模型層 (C) 服務層 (D) 監控層
答案：C。 服務層負責把模型包裝成 API（如 REST 或 gRPC），讓其他應用可以呼叫模型做推論。
常見問題
不需要一步到位。初期可以用 Jupyter Notebook 訓練、Flask 包一個 API 就上線。隨著用戶量和模型複雜度增加，再逐步補上特徵儲存、自動化訓練、監控等元件。架構是演進的，不是一次設計完的。
最大的差異是「資料驅動」。傳統軟體的行為由程式碼決定，AI 系統的行為由資料和模型共同決定。這意味著 AI 系統架構必須多處理資料版本管理、模型再訓練、資料漂移偵測這些傳統軟體不需要的問題。
可以，這就是混合雲邊架構。典型做法是雲端負責訓練和模型更新，邊緣負責即時推論。兩邊透過模型同步機制保持一致。手機上的語音助手就是這種架構：模型在雲端訓練，推到手機上執行。
至少要畫出資料來源與資料管線、特徵處理、模型訓練、模型登錄、推論服務與監控，並標示資料與請求的流向。Google Cloud 的 MLOps 文件指出，機器學習程式碼只占實際系統的一小部分，資料驗證、服務基礎設施與監控同樣要畫進去。
可以當起點。常見做法是請生成式 AI 依文字描述產出 Mermaid 或 PlantUML 這類圖表語法，再貼到支援的工具轉成圖。產出的元件與連線仍要由懂系統的人檢查，避免畫出不存在的服務或錯誤的資料流向。
主要依業務需求設計 AI 系統的整體結構，包括資料怎麼收集與流動、模型在哪裡訓練與部署、怎麼監控與更新，以及成本、資安與法規之間的取捨。實際職責依公司而異，通常會和資料工程師、機器學習工程師與維運團隊一起工作。
出現在這些考古題
官方公告試題的逐題解析裡，這 2 題把AI 系統架構列為延伸術語。
立即測驗
想測試你對 AI 系統架構 的掌握程度？用考古題作答
相關術語
來源
這個術語目前沒有標註外部來源。
考試範圍：iPAS AI 應用規劃師評鑑內容範圍參考（115.02 更新），經濟部產業人才能力鑑定，實際考試內容以官方公告為準。
其他格式：Markdown 版本