L21302 AI 技術系統集成與部署
2系統集成 — 五大整合面向
AI 模型 ↔ 企業現有資訊架構無縫整合
2.A資料來源與資料管線整合
| 資料來源 | 定位 | 典型內容 |
|---|---|---|
| ① 資料倉儲 Data Warehouse | 企業內部結構化資料 | 歷史交易、業務報表 |
| ② 資料湖 Data Lake | 大規模非結構資料 | 影像、音訊、Log、原始檔 |
| ③ IoT 裝置 | 即時回傳的感測資料 | 邊緣串流、感測器訊號 |
| ④ 第三方系統 API | 外部服務介面 | 外部資料源、雲端服務 |
| 資料管線（Data Pipeline）四階段 | 動作 |
|---|---|
| ① 資料擷取 | 從來源收集 |
| ② 格式轉換 | 統一資料格式 |
| ③ 清理 | 去除錯誤與雜訊 |
| ④ 入庫流程 | 寫入儲存以供模型使用 |
2.B企業內部系統整合
| 系統 | 定位 | 教材範例 |
|---|---|---|
| ERP 企業資源規劃 | 採購、財務、庫存核心 | ERP 根據需求預測動態調整採購 |
| CRM 客戶關係管理 | 客戶資料與互動 | CRM 自動根據模型推薦寄送促銷信件 |
| POS 銷售點 | 銷售前線即時數據 | 結帳、條碼、銷售資料 |
| MES 製造執行系統 | 產線執行調度 | 產線監控與排程 |
2.CAPI 與平台接軌
| 介面方式 | 使用情境 | 特性 |
|---|---|---|
| RESTful API | 最常見的實作方式（HTTP） | 通用、易整合、廣泛工具支援 |
| gRPC | 依效能與雙向通訊需求採用 | 二進位高效、雙向 streaming |
| Webhooks | 事件觸發推送 | 被動接收事件回呼 |
| 穩定性三機制 | 作用 |
|---|---|
| 容錯 | 節點故障時仍維持服務 |
| 快取 | 減少重複運算與延遲 |
| 負載管理 | 分散請求壓力 |
2.D安全與權限控管
| 安全措施 | 核心動作 | 關鍵詞 |
|---|---|---|
| ① OAuth2 / JWT （JSON Web Token） | 用戶身份驗證與授權 | Token / Bearer / 授權碼流程 |
| ② 角色權限分級 | 對不同角色設定不同的存取權限 | 例：僅部分用戶可進行模型重訓或調參 |
| ③ API Gateways | 實作存取日誌記錄與流量控管 | 限流、稽核、API Key 管理 |
2.E跨雲與異質系統整合
| 異質環境 | 典型任務 |
|---|---|
| 本地資料中心 | 訓練作業（隱私敏感的密集運算） |
| 邊緣裝置 | 推論前線（低延遲） |
| 雲端平台（AWS、Azure） | 彈性擴展、跨地區部署 |
| Service Mesh 三大職責 | 說明 |
|---|---|
| ① 統一管理資料同步 | 跨平台資料一致性 |
| ② 服務調用 | 標準化跨服務呼叫 |
| ③ 狀態追蹤 | 監控連線、回應、錯誤 |
3系統架構設計 — 四大支柱
穩定 / 高可用 / 可擴展 / 易於維運的技術架構
3.A微服務架構（Microservices Architecture）
| 面向 | 內容 |
|---|---|
| 定義 | 將單一應用程式拆分為一組小型服務的架構風格；每個服務實作單一功能，可獨立部署、更新與擴展 |
| 三大優點 | 說明 |
|---|---|
| ① 易於隔離錯誤 | 單一模組失效不影響全系統 |
| ② 適合跨團隊並行開發 | 各小組獨立負責一個微服務 |
| ③ 彈性調整資源 | 例：推論流量增加時擴增模型 API 模組 |
| 兩大挑戰 | 說明 |
|---|---|
| ① 模組間介接需設計標準 API | 缺乏統一介面會造成耦合 |
| ② 分散式管理複雜度高 | 監控、追蹤、debug 難度上升 |
3.B容器化與編排（Containerization and Orchestration）
| 容器工具 | 角色 |
|---|---|
| Docker | 容器映像建構與執行 — 將應用程式與其依賴環境封裝在一起，確保跨平台部署一致性 |
| Kubernetes（K8s） | 容器編排、資源調度、故障恢復 — 管理大量容器 |
| 常見實作原則 | 做什麼 |
|---|---|
| 滾動更新 Rolling Update | 不中斷服務地更新容器版本 |
| 自動擴縮 Autoscaling | 根據流量自動調整容器數量 |
| 負載平衡 Load Balancing | 確保多個推論節點分擔請求壓力 |
3.C模型服務化與 API 封裝
| 常用工具 | 定位 |
|---|---|
| Flask / FastAPI | 輕量級 Python Web 框架，常用於封裝推論 API |
| TensorFlow Serving | 專為 TF 模型設計的高效推論服務 |
| 封裝設計要點 | 說明 |
|---|---|
| 多版本管理 Model Versioning | 同時提供新舊版本，便於切換與回退 |
| API 安全機制 | 使用者驗證、速率限制 |
| 記錄與監控 Log & Metrics | 提供模型推論結果的可觀測性 |
3.D可擴充與高可用性設計
| 設計策略 | 作用 |
|---|---|
| 冗餘部署 Redundancy | 多節點部署避免單點故障 |
| 容錯切換 Failover | 一個節點故障時自動切換至備援節點 |
4部署模式 — 四種環境決策地圖
公有雲 / 私有雲 / 邊緣運算 / 混合部署
4.A公有雲部署（Public Cloud）
| 面向 | 內容 |
|---|---|
| 代表平台 | AWS（Amazon Web Services）/ Microsoft Azure / GCP（Google Cloud Platform） |
| 優勢 | 資源彈性擴充、部署速度快、全球節點支援、按量付費 |
| 適用情境 | 新創團隊、中大型企業 AI 專案、跨地區部署、GPU 資源密集型訓練 |
| 挑戰 | 敏感資料需關注法規遵循（GDPR）、資料主權、供應商鎖定風險 |
4.B私有雲部署（Private Cloud）
| 面向 | 內容 |
|---|---|
| 代表平台 | OpenStack、VMware（架設於本地資料中心） |
| 優勢 | 資安風險可控、資料僅在內部可控環境（不外流）、可依產業法規定制化 |
| 適用情境 | 政府、金融、醫療等對資料保護要求嚴格的領域 |
| 挑戰 | 建置與維運成本高、彈性與資源擴展性受限 |
4.C邊緣運算（Edge Computing）
| 面向 | 內容 |
|---|---|
| 定義 | 在靠近資料來源端的裝置（IoT、手機、車載系統）上進行模型推論 |
| 優勢 | 即時反應、降低傳輸延遲、提升隱私保護 |
| 適用情境 | 工業設備監控、智慧城市、車聯網、邊緣 AI 智慧應用 |
| 挑戰 | 運算資源有限、更新與同步需額外設計 |
4.D混合部署（Hybrid Deployment）
| 面向 | 內容 |
|---|---|
| 定義 | 結合公有雲、私有雲、邊緣架構，依任務配置最合適位置 |
| 經典模式 | 雲端進行模型訓練，邊緣進行即時推論 |
| 優勢 | 兼顧計算能力、反應速度、資料保護；彈性適應多元情境 |
| 挑戰 | 系統整合難度高、需設計良好的同步機制與一致性管理流程 |
5MLOps 與持續維運 — DevOps × ML
CI/CD + 模型版本 + 監控與回饋
5.A持續整合與持續部署（CI/CD）
| 階段 | 內容 |
|---|---|
| CI 持續整合 Continuous Integration | 原始碼與資料變動即觸發模型訓練與測試流程；整合單元測試、模型準確率驗證與效能基準比較 |
| CD 持續部署 Continuous Deployment | 通過測試門檻的模型，自動部署至測試或生產環境；支援 A/B 測試或藍綠部署（Blue-Green Deployment）以控制風險 |
| 模型版本控管 Model Versioning | 追蹤每次訓練的參數、資料版本與模型成果，建立可重現性 |
| 版本工具 | 定位 |
|---|---|
| MLflow | 開源平台 — 管理機器學習全流程：實驗記錄、模型訓練、部署與版本控制 |
| DVC Data Version Control | 專為 ML 項目設計的版本控制工具，支援資料集與模型的版本追蹤與再現性 |
5.B模型監控與回饋機制
| 監控項目 | 說明 |
|---|---|
| 模型漂移 Model Drift | 模型預測分佈與訓練時期不同，可能表示模型已不再適用 |
| 資料漂移 Data Drift | 輸入資料的統計特徵改變，如欄位分佈或異常比例異常 |
| 效能指標 | 錯誤率、延遲、吞吐量 |
| 回饋與自動修正流程 | 動作 |
|---|---|
| ① 設定觸發門檻 | 例如準確率下降 5%（教材鎖死值） |
| ② 啟動再訓練流程 | Retraining Pipeline 自動執行 |
| ③ 替換模型版本 | 透過熱更新（Hot Swap）或滾動更新（Rolling Update）替換 |
| 可視化與預警 | 工具 |
|---|---|
| Log 分析 + Dashboard | Prometheus + Grafana |
| 自動警告/提示系統 | 異常偵測時通知相關工程人員 |
6成效追蹤與優化 — 三層 KPI × 持續優化
系統 / 應用 / 業務指標雙軌制 + Feedback Loop + 模型更新策略
6.A成效指標設計與回收週期
| KPI 層級 | 指標 | 關注重點 |
|---|---|---|
| 系統層級 | 推論延遲（Inference Latency）/ 吞吐量（Throughput）/ 服務可用率（Uptime）/ 資源使用率（如 GPU 記憶體） | 技術運行穩定度 |
| 應用層級 | 推薦點擊率（CTR）/ 預測準確率（Accuracy）/ 分類 F1-Score / 異常偵測精確度 | 模型實際表現 |
| 業務層級 | 轉換率提升 / 成本節省 / 客戶留存率變化 / ROI（投資報酬率） | 商業價值 |
| 資料與績效回收週期（Feedback Loop） | 頻率 |
|---|---|
| 每日 | 監控推論效能與使用情況 |
| 每週 | 收集錯誤樣本與業務回饋 |
| 每月 | 進行一次模型重新評估或 retraining 需求確認 |
6.B模型更新與持續優化
| 更新策略 | 說明 |
|---|---|
| 版本控管 + 滾動更新 Rolling Update | 避免中斷服務或部署風險 |
| 藍綠部署 Blue-Green Deployment | 新舊版本並行，瞬間切換 |
| 金絲雀部署 Canary Deployment | 少量流量先試新版本，降低新模型不穩定風險 |
| 持續優化機制 | 說明 |
|---|---|
| 再訓練與資料再標註 | 資料漂移超過門檻時，自動觸發模型再訓練，並更新資料集標註品質 |
| 使用者與業務回饋 | 客服/銷售回報錯誤案例、自動標記錯誤樣本（Human-in-the-Loop）、使用者點擊行為記錄 |
| AutoML / Online Learning | 對於變化快速或大規模資料情境，實現持續模型微調，保持預測準確度 |
7跨部門整合 — 角色 × 溝通 × 治理
AI 不是技術團隊的專案，是組織協作
7.A明確部門角色與參與責任
| 部門 | 角色與責任 |
|---|---|
| 業務與行銷 | 提供實際需求情境與績效指標，根據 AI 模型輸出（預測結果、推薦清單）進行策略應用與反饋調整 |
| 客服與營運 | 在模型應用端與客戶接觸最頻繁，負責回收實際互動案例與異常反應，用於持續優化 |
| 法務與風險 | 針對資料隱私、模型公平性與風險揭露進行審查，協助建立符合法規的使用框架 |
| 資訊部門 | 負責部署、權限管理、API 整合與維運支援，確保 AI 系統可穩定接軌企業基礎架構 |
7.B建立常態溝通與決策機制
| 機制 | 說明 |
|---|---|
| ① 定期 AI 專案工作小組 | 協調各部門目標與需求差異 |
| ② 推動共用績效指標 | 如「AI 成效影響 KPI」作為跨部門合作的共同成果基準 |
| ③ 快速協調與決策通道 | 對模型調整、資料異常處理、實務需求更動建立應變機制 |
7.CAI 納入組織治理流程
| 治理舉措 | 角色與功能 |
|---|---|
| AI 治理委員會 | 統籌資源分配、風險審查與戰略發展 |
| 內部 AI 產品經理 / 協調人員 | 作為技術與部門間的橋梁，確保語言一致與任務協同 |
| 跨部門培訓與教育機制 | 強化非技術人員對 AI 模型意義與限制的理解，減少誤解與溝通摩擦 |
AIONDAILY × 咖啡 AI 學 · iPAS AI 應用規劃師中級 · L21302 考前複習筆記 · v1.0（2026-05 表格化精簡版）