一、學習目標
完成本單元後，你將能夠：
- 說明 AI 專案與傳統軟體專案在本質上的四大差異
- 描述 AI 專案生命週期的四個核心階段及各階段的關鍵任務
- 辨識 AI 專案中的主要角色及其職責分工
- 解釋如何將敏捷（Agile）方法論調整應用於 AI 實驗型專案
- 列舉 AI 專案常見失敗原因並提出對應的預防策略
二、核心內容
1. AI 專案與傳統軟體專案有何不同？
許多組織在導入 AI 時，習慣套用傳統軟體開發（Software Development Life Cycle, SDLC）的思維，結果屢屢碰壁。根本原因在於：AI 專案的本質和傳統軟體專案有四個根本差異。
生活類比：傳統軟體開發像是「蓋房子」——你先畫好設計圖，按步驟施工，完工時一定知道房子長什麼樣。AI 專案更像是「培育一棵樹」——你知道大概想要什麼樣的樹，但實際結果取決於土壤、水分、陽光（即資料品質）、氣候（即運算資源），中間充滿不確定性，需要持續觀察與調整。
| 面向 | 傳統軟體專案 | AI 專案 |
|---|---|---|
| 輸出確定性 | 輸入相同，輸出必定相同（Deterministic） | 輸出為機率性（Non-deterministic），相同輸入可能有不同輸出 |
| 成功條件 | 程式邏輯正確，需求功能實現 | 模型指標（Metrics）達標，且指標本身需要提前定義清楚 |
| 瓶頸來源 | 需求不清、技術複雜度 | 資料品質、資料量、特徵工程、模型選擇 |
| 開發模式 | 計畫導向（Plan-driven），可預測性高 | 實驗導向（Experiment-driven），需要容忍失敗與迭代 |
考試重點：AI 專案的「非確定性輸出（Non-deterministic Output）」是最常考的特性。AI 不像傳統程式，不能保證每次產生一模一樣的結果，這直接影響測試方式與品質標準的定義。
2. AI 專案生命週期：四大階段
階段一：問題定義與範疇確認（Problem Definition & Scoping）
這是整個 AI 專案中最被低估、卻最重要的階段。在這個階段，你需要回答三個核心問題：
問題一：這個問題真的需要 AI 嗎？
AI 並非萬靈丹。以下情況通常不需要 AI：
- 問題可以用規則（Rule-based）系統清楚解決
- 資料量極少（通常少於數百筆難以訓練有效模型）
- 預測錯誤的代價極高，且無法接受機率性輸出（如核電廠安全系統）
問題二：成功指標（Success Metrics）是什麼？
在啟動前必須定義清楚：技術指標（如準確率、F1 分數、AUC）與業務指標（如客服成本降低 30%、退貨率下降 15%）。兩者都需要，且業務指標優先。
問題三：利害關係人（Stakeholder）是否對齊？
- 業務方（Business Stakeholder）：關心 ROI 與業務影響
- 技術方（Tech Team）：關心可行性與技術架構
- 法務/合規（Legal/Compliance）：關心資料使用的合法性
- 最終使用者（End User）：關心易用性與信任感
考試重點：「問題定義不清」是 AI 專案最常見的失敗原因之一。在 iPAS 考試中，常考「導入 AI 前應優先確認哪些事項」，答案通常圍繞：業務問題定義、成功指標、資料可用性。
階段二：資料階段（Data Phase）
資料階段通常佔 AI 專案總工時的 60% 至 80%，是整個專案最耗時的部分，也是品質的根基。
生活類比：模型訓練就像廚師炒菜，演算法是廚師的廚藝，資料是食材。再厲害的廚師，拿到劣質食材，也做不出好菜。「Garbage in, garbage out」（垃圾進，垃圾出）是 AI 界的金科玉律。
資料階段包含以下四個子任務：
| 子任務 | 說明 | 常見工具/方法 |
|---|---|---|
| 資料盤點（Data Audit） | 確認現有資料的範圍、格式、品質、存放位置 | 資料目錄（Data Catalog）、SQL 查詢 |
| 資料收集（Data Collection） | 從內部系統、外部來源或網路爬取取得所需資料 | 爬蟲、API 串接、資料採購 |
| 資料清理（Data Cleaning） | 處理缺失值、重複值、異常值、格式不一致 | Pandas、Great Expectations |
| 資料標注（Data Labeling） | 由人工或半自動方式為資料添加標籤（Label） | Label Studio、Scale AI、Amazon Mechanical Turk |
考試重點：資料標注（Data Labeling）是監督式學習（Supervised Learning）的必要步驟，品質直接決定模型上限。「資料品質差」是僅次於「問題定義不清」的第二大 AI 專案失敗原因。
階段三：模型開發（Model Development）
模型開發是最核心的技術階段，但它在整個專案中所佔的工時其實遠低於資料階段。
基準模型（Baseline Model）：在投入複雜演算法前，先建立一個簡單的基準模型（如邏輯回歸、決策樹），用來確認資料管道是否正確運作，並作為後續改進的比較基準。
實驗追蹤（Experiment Tracking）：AI 開發本質上是大量實驗——不同的特徵組合、不同的演算法、不同的超參數（Hyperparameter）。每次實驗的參數與結果都必須記錄，避免「不知道上次怎麼得到好結果」的窘境。
超參數調校（Hyperparameter Tuning）：超參數是在訓練前由人工設定的參數（如學習率 Learning Rate、樹的深度），需要透過系統化搜尋（Grid Search、Random Search、Bayesian Optimization）找到最佳組合。
模型評估（Model Evaluation）：根據任務類型選擇合適指標：
- 分類任務：準確率（Accuracy）、精確率（Precision）、召回率（Recall）、F1 分數、AUC-ROC
- 回歸任務：MAE、RMSE、R²
- 業務指標：最終仍需對應到商業價值
階段四：部署與維運（Deployment & Monitoring）
模型訓練完成不等於專案完成。將模型安全地推上生產環境，並長期維持其效能，才是真正的挑戰。
A/B 測試（A/B Testing）：將流量隨機分配給新舊模型，比較兩者在真實用戶行為下的表現差異，用統計顯著性來決定是否全面切換。
金絲雀部署（Canary Deployment）：先將新模型僅對 1%～5% 的流量開放，觀察是否出現異常（如錯誤率上升、延遲增加），確認穩定後逐步擴大到 100%。名稱來自礦工過去用金絲雀（Canary）進礦坑偵測毒氣——金絲雀先受影響，礦工就知道危險了。
模型漂移監控（Model Drift Monitoring）：模型在上線後效能往往會隨時間下降，原因有兩類：
- 資料漂移（Data Drift）：輸入資料的分布發生變化（如疫情改變了消費者行為）
- 概念漂移（Concept Drift）：輸入與輸出之間的關係改變（如市場偏好轉移）
重訓觸發條件（Retraining Triggers）：設定明確的重訓時機，例如：
- 定時重訓（每週/每月）
- 指標下降觸發（準確率低於設定閾值時）
- 資料量累積觸發（收集到足夠新標注資料時）
3. AI 專案的主要角色
| 角色 | 英文職稱 | 主要職責 |
|---|---|---|
| 資料科學家 | Data Scientist | 建立模型、特徵工程、實驗分析 |
| 機器學習工程師 | ML Engineer | 模型部署、MLOps 管道、效能優化 |
| 資料工程師 | Data Engineer | 資料管道、ETL 流程、資料倉儲 |
| 領域專家 | Domain Expert | 提供業務知識、協助資料標注、驗證模型輸出合理性 |
| AI 專案經理 | AI Project Manager | 協調各方、管理時程、風險管理、利害關係人溝通 |
考試重點：「領域專家（Domain Expert）」的角色常被忽略，但在醫療、法律、金融等垂直領域中，缺乏領域專家的 AI 專案極易失敗——技術人員不懂業務邏輯，做出來的模型在現實場景中毫無用處。
4. 敏捷方法論在 AI 專案的應用
傳統的瀑布式開發（Waterfall）不適合 AI 專案，因為 AI 開發充滿不確定性，需要頻繁迭代。敏捷（Agile）更適合，但需要調整：
AI Sprint 的特殊考量：
- Sprint 目標不應承諾「達到 XX% 準確率」，而應承諾「完成 XX 個實驗並分析結果」
- 失敗的實驗是有價值的——它排除了無效方向，應被視為進展而非浪費
- 定期舉行「模型評審（Model Review）」，讓業務方參與評估模型輸出是否符合業務直覺
- 資料準備工作需要在 Sprint 計畫時充分估算，否則容易低估工時
5. AI 專案常見失敗原因
| 失敗原因 | 說明 | 預防方法 |
|---|---|---|
| 問題定義不清 | 不知道 AI 要解決什麼具體問題 | 導入前先完成業務問題定義工作坊 |
| 資料品質差 | 訓練資料含有大量錯誤、缺失或偏差 | 資料盤點與品質評估列為前置必要步驟 |
| 不切實際的期望 | 高層期待 AI 解決所有問題，立竿見影 | 提前溝通 AI 的能力邊界與時程預期 |
| 缺乏領域專家 | 純技術團隊不理解業務脈絡 | 確保每個 AI 專案有對應領域專家持續參與 |
| 忽略部署挑戰 | 模型準確率高，但無法整合進現有系統 | 早期邀請 IT 基礎架構團隊參與評估 |
6. AI 專案常用工具
| 工具 | 用途 | 類別 |
|---|---|---|
| MLflow | 實驗追蹤、模型版本管理、模型部署 | 開源 MLOps 平台 |
| Weights & Biases (W&B) | 實驗追蹤與視覺化、超參數搜尋 | 商業/開源混合 |
| DVC (Data Version Control) | 資料集版本控制，類似 Git 但用於資料 | 開源資料管理 |
| Apache Airflow | 資料管道（Pipeline）排程與編排 | 開源工作流排程 |
三、關鍵名詞中英對照
| 中文 | 英文 | 說明 |
|---|---|---|
| 非確定性輸出 | Non-deterministic Output | AI 模型相同輸入可能產生不同輸出 |
| 問題定義 | Problem Definition / Scoping | 明確 AI 要解決的業務問題與成功標準 |
| 成功指標 | Success Metrics | 衡量 AI 專案是否成功的量化標準 |
| 利害關係人對齊 | Stakeholder Alignment | 確保各方對目標與期望達成共識 |
| 資料盤點 | Data Audit | 評估現有資料的品質、範圍、可用性 |
| 資料標注 | Data Labeling | 為訓練資料添加正確標籤的過程 |
| 基準模型 | Baseline Model | 作為改進比較基準的簡單模型 |
| 實驗追蹤 | Experiment Tracking | 記錄每次模型實驗的參數與結果 |
| 超參數 | Hyperparameter | 訓練前由人工設定、非模型學習得到的參數 |
| 超參數調校 | Hyperparameter Tuning | 系統化搜尋最佳超參數組合 |
| A/B 測試 | A/B Testing | 同時對照測試新舊版本，用統計方式決定勝出者 |
| 金絲雀部署 | Canary Deployment | 將新版本先釋出給少量用戶，逐步擴大的部署策略 |
| 模型漂移 | Model Drift | 模型上線後效能隨時間衰退的現象 |
| 資料漂移 | Data Drift | 生產環境中輸入資料的分布發生變化 |
| 概念漂移 | Concept Drift | 輸入與輸出之間的真實關係發生變化 |
| 重訓觸發 | Retraining Trigger | 啟動模型重新訓練的預設條件 |
| 機器學習維運 | MLOps (ML Operations) | 將 ML 模型部署、監控、維護系統化的工程實踐 |
四、考試重點提示
考試重點：以下是 iPAS 人工智慧考試中與 AI 專案管理相關的高頻考點：
- AI 與傳統軟體的核心差異：「非確定性輸出」和「實驗導向開發」是最常考的兩點
- 資料階段佔比：AI 專案中資料準備（收集、清理、標注）通常佔總工時 60%～80%
- 失敗原因排序：問題定義不清 > 資料品質差 > 不切實際的期望 > 缺乏領域專家
- 金絲雀部署的意義：先開放小流量，觀察新模型穩定性，降低全面上線風險
- 模型漂移的兩種類型：資料漂移（Data Drift）與概念漂移（Concept Drift）要能區分
- 角色分工：資料科學家（建模）vs 機器學習工程師（部署）vs 資料工程師（資料管道）的職責差異是常考題
- 敏捷 + AI：Sprint 目標應以「完成實驗」而非「達成準確率」來衡量，因為 AI 結果難以保證
Q1. 下列哪一項是 AI 專案與傳統軟體專案最根本的差異？
- A. AI 專案一定需要更大的開發團隊
- B. AI 專案的輸出具有非確定性（Non-deterministic），相同輸入可能產生不同結果
- C. AI 專案不需要進行需求訪談
- D. AI 專案的開發週期一定比傳統軟體更短
Q2. 在 AI 專案生命週期中，哪個階段通常佔用最多工時（約 60%～80%）？
- A. 模型開發（Model Development）
- B. 問題定義（Problem Definition）
- C. 資料階段（Data Phase），包含收集、清理與標注
- D. 部署與監控（Deployment & Monitoring）
Q3. 「金絲雀部署（Canary Deployment）」的主要目的是什麼？
- A. 替換所有舊版模型，加速上線流程
- B. 先對少量用戶開放新模型，觀察穩定性後再逐步擴大，降低風險
- C. 在沒有真實用戶的測試環境中評估模型效能
- D. 使用金融領域的語料訓練語言模型
Q4. 下列關於「模型漂移（Model Drift）」的描述，何者最為正確？
- A. 模型漂移是指模型在訓練過程中過擬合的現象
- B. 資料漂移（Data Drift）是指輸入資料分布改變；概念漂移（Concept Drift）是指輸入與輸出的真實關係改變
- C. 模型漂移只發生在自然語言處理（NLP）任務中
- D. 模型漂移可以透過增加模型參數量來完全避免
Q5. 在 AI 專案中，「領域專家（Domain Expert）」的主要貢獻是？
- A. 負責編寫模型訓練程式碼
- B. 管理雲端運算資源與 GPU 排程
- C. 提供業務知識、協助資料標注，確保模型輸出符合現實業務邏輯
- D. 負責 A/B 測試的統計分析
解答與解析
| 題號 | 答案 | 解析 |
|---|---|---|
| Q1 | B | AI 模型的輸出是機率性的（Non-deterministic），這是與傳統規則型程式最根本的差異，直接影響測試方式、品質標準與使用者期望管理。 |
| Q2 | C | 資料階段（收集、清理、標注）通常佔 AI 專案總工時的 60%～80%，遠超模型開發本身。這也是「Garbage in, garbage out」原則強調資料品質優先的根本原因。 |
| Q3 | B | 金絲雀部署（Canary Deployment）名稱來自礦工用金絲雀偵測毒氣的做法，核心概念是「先以小流量測試新版本，確認穩定後再全面切換」，以降低大規模上線風險。 |
| Q4 | B | 資料漂移（Data Drift）是輸入資料本身的分布變化（如疫情改變消費行為）；概念漂移（Concept Drift）是輸入與輸出間映射關係的改變（如市場偏好轉移）。兩者都會導致模型效能隨時間下降。 |
| Q5 | C | 領域專家的核心價值在於將業務知識注入 AI 開發流程——協助定義問題、標注訓練資料、驗證模型輸出是否符合業務直覺。缺乏領域專家是 AI 專案常見失敗原因之一。 |