本書旨在幫助機器學習（ML）工程師與資料科學家在 ML 系統設計面試中取得成功。對於想從高層次理解 ML 如何應用於真實世界的讀者，本書同樣具有參考價值。

許多工程師將 ML 演算法（如 logistic regression 或 neural network）視為 ML 系統的全部。然而，生產環境中的 ML 系統遠不止於模型開發。一個完整的 ML 系統通常包含以下元件：

• 資料堆疊（Data Stack）：管理資料的收集、儲存與處理
• 服務基礎設施（Serving Infrastructure）：讓系統能服務數百萬使用者
• 評估管線（Evaluation Pipeline）：量測系統效能
• 監控機制（Monitoring）：確保模型效能不會隨時間衰退

在 ML 系統設計面試中，你需要回答開放式問題，例如設計一個電影推薦系統或影片搜尋引擎。這類問題沒有唯一正確答案——面試官想評估的是你的思考過程、對各種 ML 主題的深入理解、端到端系統設計能力，以及在不同方案間做取捨的能力。

系統設計框架#

為了有效設計複雜的 ML 系統，遵循一個結構化框架非常重要。缺乏結構的回答會讓面試官難以跟隨你的思路。本書提出的框架包含以下關鍵步驟：

1. 釐清需求（Clarifying Requirements）
2. 將問題建構為 ML 任務（Framing the Problem as an ML Task）
3. 資料準備（Data Preparation）
4. 模型開發（Model Development）
5. 評估（Evaluation）
6. 部署與服務（Deployment and Serving）
7. 監控與基礎設施（Monitoring and Infrastructure）

每場 ML 系統設計面試都不同，因為問題是開放式的。此框架旨在幫助你組織思路，但無需嚴格遵循。如果面試官主要關注模型開發，你應順應他們的重點。

釐清需求#

ML 系統設計問題通常刻意模糊，僅提供最少的資訊。例如：「設計一個活動推薦系統」。第一步是提出釐清性問題，以下是分類整理的問題清單：

• 商業目標（Business Objective）：例如推薦度假租屋系統，動機可能是增加訂房數或提高營收
• 系統功能需求：哪些功能會影響 ML 系統設計？例如影片推薦系統中，使用者能否「喜歡」或「不喜歡」推薦影片，這些互動可作為訓練資料的標註
• 資料（Data）：資料來源為何？資料集規模多大？資料是否已標註？
• 限制條件（Constraints）：可用的運算資源？雲端系統還是需在裝置上運行？模型是否需自動改進？
• 系統規模（Scale）：使用者數量？項目（如影片）數量？這些指標的成長速度？
• 效能要求（Performance）：預測需多快？是否需要即時方案？準確度與延遲的優先順序？

此清單並非詳盡無遺，隱私與倫理等議題同樣重要。在此步驟結束時，應與面試官就系統範圍和需求達成共識，並將需求與限制條件書面記錄下來。

將問題建構為 ML 任務#

有效的**問題建構（Problem Framing）**對解決 ML 問題至關重要。假設面試官要求你提升影片串流平台的使用者互動度——缺乏互動是一個問題，但並非 ML 任務。我們需要將其建構為 ML 任務，具體做法如下：

• 定義 ML 目標
• 指定系統的輸入與輸出
• 選擇正確的 ML 類別

在面試中，可以安全地假設 ML 對解決問題是有幫助的。實務上則需先判斷問題是否真的需要 ML。

定義 ML 目標#

商業目標可能是「提升銷售額 20%」或「改善使用者留存率」，但我們無法直接告訴模型「提升銷售額 20%」。需要將商業目標轉化為定義明確的 ML 目標。

表 1.1：將商業目標轉化為 ML 目標

指定系統的輸入與輸出#

確定 ML 目標後，需定義系統的輸入與輸出。例如社群平台有害內容偵測系統：輸入為一則貼文，輸出為該貼文是否被視為有害。

某些情況下，系統可能包含多個 ML 模型。例如有害內容偵測可使用一個模型預測暴力內容、另一個模型預測裸露內容，系統再綜合判斷貼文是否有害。

此外，每個模型的輸入輸出可能有多種指定方式，如圖 1.4 所示。

選擇正確的 ML 類別#

問題可以被建構為多種 ML 任務。大多數問題可歸類為圖 1.5 中的某個 ML 類別（葉節點）。

• 監督式學習（Supervised Learning）：模型從標註資料集學習。實務中大多數問題屬此類別，因為從標註資料學習通常能獲得更佳結果
• 非監督式學習（Unsupervised Learning）：模型處理不含正確答案的資料進行預測
• 強化學習（Reinforcement Learning）：電腦代理透過與環境的反覆試錯互動來學習任務。例如機器人行走訓練、AlphaGo 棋藝學習

相較於監督式學習，非監督式學習與強化學習在真實系統中較不常見。因此，本書大部分問題依賴監督式學習。

分類模型（Classification Model） 預測離散的類別標籤，例如將輸入圖片分類為「狗」、「貓」或「兔」。分類模型可分為：

• 二元分類（Binary Classification）：預測二元結果，例如圖片是否包含狗
• 多元分類（Multiclass Classification）：將輸入分類為多個類別，例如狗、貓或兔

面試討論要點#

• 什麼是好的 ML 目標？不同 ML 目標如何比較？各有何優缺點？
• 根據 ML 目標，系統的輸入和輸出為何？
• 若系統涉及多個模型，每個模型的輸入和輸出為何？
• 任務需要監督式還是非監督式學習？
• 應使用迴歸還是分類模型？若為分類，是二元還是多元？若為迴歸，輸出範圍為何？

資料準備#

ML 模型直接從資料中學習，因此具有預測能力的高品質資料對模型訓練至關重要。此階段透過兩個核心流程為 ML 模型準備高品質輸入：資料工程與特徵工程。

資料工程#

資料工程是設計與建構管線（Pipeline）的實踐，涵蓋資料的收集、儲存、檢索與處理。

資料來源#

ML 系統可使用來自多種不同來源的資料。了解資料來源有助於回答以下問題：

• 誰收集了這些資料？
• 資料有多乾淨？
• 資料來源是否可信？
• 資料是使用者產生的還是系統產生的？

資料儲存#

資料儲存（也稱為資料庫）是持久化儲存與管理資料集合的倉庫。不同資料庫針對不同使用場景而設計，因此從高層次理解不同資料庫的運作方式很重要。

在 ML 系統設計面試中，通常不需要了解資料庫內部實作細節。

ETL（Extract, Transform, Load）#

ETL 由三個階段組成：

• Extract（萃取）：從不同資料來源萃取資料
• Transform（轉換）：清洗、對映並轉換資料為特定格式以滿足作業需求
• Load（載入）：將轉換後的資料載入目標位置，可以是檔案、資料庫或資料倉儲

資料型別#

在 ML 中，資料型別與程式語言中的 int、float、string 等不同。資料型別在高層次上可分為結構化資料與非結構化資料。

結構化資料遵循預定義的資料綱要（Schema），如日期、姓名、地址、信用卡號等可以表格形式呈現的資料。非結構化資料沒有底層資料綱要，如圖片、音訊檔、影片和文字。

表 1.2：結構化與非結構化資料的比較

如圖 1.10 所示，ML 模型在不同資料型別上的表現不同。釐清資料屬於結構化還是非結構化，有助於在模型開發階段選擇適當的 ML 模型。

數值資料#

數值資料是以數字表示的資料，可分為：

• 連續數值資料：可取範圍內任意值，例如房價
• 離散數值資料：僅取不同的整數值，例如過去一年售出的房屋數量

類別資料#

類別資料根據名稱或標籤進行識別與儲存。例如性別是類別資料，其值來自有限集合。類別資料可分為兩類：

• 名義資料（Nominal）：類別間無數值關係，例如性別中的「男」與「女」無排序關係
• 序數資料（Ordinal）：類別間有預定的順序，例如評分資料的「不滿意」、「普通」、「滿意」

特徵工程#

特徵工程包含兩個流程：

• 利用領域知識從原始資料中選擇和提取具預測力的特徵
• 將預測特徵轉換為模型可使用的格式

選擇適當的特徵是模型開發與訓練中最重要的決策之一。特徵工程需要領域專業知識，且高度依賴任務本身。

特徵工程操作#

某些特徵可能不是模型可直接使用的格式，需透過特徵工程操作進行轉換。常見技術包括處理缺失值、縮放偏態分佈的值，以及編碼類別特徵。以下列出結構化資料最常見的操作。

處理缺失值#

生產環境中的資料經常存在缺失值，通常可透過兩種方式處理：刪除或填補。

刪除（Deletion）：移除含有缺失值的記錄，可分為：

• 欄刪除（Column Deletion）：若某特徵的缺失值過多，移除整個欄位
• 列刪除（Row Deletion）：若某資料點有大量缺失值，移除該列

刪除的缺點是減少了模型可用的訓練資料量。由於 ML 模型接觸更多資料通常表現更好，這並非理想做法。

填補（Imputation）：以特定值填入缺失值，常見做法包括：

• 以預設值填入
• 以平均數、中位數或眾數填入

填補可能在資料中引入雜訊。處理缺失值沒有完美的技術，每種方法都有其取捨。

特徵縮放#

特徵縮放是將特徵調整到標準範圍與分佈的過程。當資料集的特徵處於不同範圍（例如年齡與收入），許多 ML 模型會難以學習任務。

正規化（Normalization / Min-Max Scaling）：將所有值縮放到 $[0, 1]$ 範圍內：

$z= \frac{x - x_{\min}}{x_{\max} - x_{\min}}$

正規化不會改變特徵的分佈。若需改變分佈使其符合標準分佈，則使用標準化。

標準化（Standardization / Z-score Normalization）：將特徵分佈調整為均值為 $0$、標準差為 $1$：

$z= \frac{x-}{\sigma}$

其中 $\mu$ 為特徵均值，$\sigma$ 為標準差。

對數縮放（Log Scaling）：以對數轉換緩解特徵的偏態問題：

$z= \log(x)$

對數轉換可使資料分佈偏態降低，並加速最佳化演算法的收斂。

離散化（Discretization / Bucketing）#

離散化是將連續特徵轉換為類別特徵的過程。例如將身高分為離散的區間，讓模型僅需學習有限的類別而非無限的可能性。

離散化也可應用於離散特徵。例如將使用者年齡離散化以減少類別數：

表 1.3：數值年齡屬性的離散化

編碼類別特徵#

大多數 ML 模型的輸入和輸出都必須是數值。若特徵為類別型，需在送入模型前進行數值編碼。三種常見方法如下：

整數編碼（Integer Encoding）：為每個唯一類別值分配一個整數。例如「Excellent」為 $1$、「Good」為 $2$、「Bad」為 $3$。此方法適用於類別值之間存在自然順序關係的情況。

若類別間沒有序數關係，整數編碼不是好的選擇，此時應使用 One-hot 編碼。

One-hot 編碼：為每個唯一值建立新的二元特徵。如圖 1.14 所示，將原始特徵（顏色）替換為三個新的二元特徵（紅、綠、藍）。例如「紅色」資料點以「$1$, $0$, $0$」表示。

嵌入學習（Embedding Learning）：將類別特徵對映為 $N$ 維向量。當特徵的唯一值數量非常大時，此方法優於 One-hot 編碼（後者會導致向量維度過大）。

面試討論要點#

• 資料可用性與收集：資料來源為何？可用的資料有哪些？如何收集？資料規模多大？新資料的頻率？
• 資料儲存：資料目前儲存在哪裡？雲端還是使用者裝置？適合的資料格式？如何儲存多模態資料？
• 特徵工程：如何將原始資料處理為模型可用的格式？缺失資料如何處理？需要哪些特徵工程操作？是否需要正規化？如何組合不同型別的資料（文字、數值、圖片）？
• 隱私：可用資料的敏感程度？使用者是否關心隱私？是否需要匿名化？資料能否儲存在伺服器上，還是只能在裝置上存取？
• 偏見（Bias）：資料中是否存在偏見？若有，屬於何種偏見？如何修正？

模型開發#

模型開發是指選擇適當的 ML 模型並訓練其解決任務的過程。

模型選擇#

模型選擇是為預測建模問題選擇最佳 ML 演算法與架構的過程。典型的模型選擇流程如下：

• 建立簡單基準線（Baseline）：例如影片推薦系統中，基準線可以是推薦最熱門的影片
• 嘗試簡單模型：探索訓練速度快的演算法，如 logistic regression
• 轉向更複雜的模型：若簡單模型無法達到滿意結果，考慮深度神經網路等複雜模型
• 使用模型集成（Ensemble）：若需更準確的預測，可透過 bagging、boosting 或 stacking 組合多個模型

面試中常見的模型選項包括：

• Logistic Regression
• Linear Regression
• Decision Trees
• Gradient Boosted Decision Trees / Random Forests
• Support Vector Machines
• Naive Bayes
• Factorization Machines（FM）
• Neural Networks

選擇 ML 演算法時，需考慮以下面向：

• 模型所需的訓練資料量
• 訓練速度
• 超參數選擇與調整技術
• 持續學習的可能性
• 運算需求（例如需 GPU 還是 CPU 即可）
• 模型的可解釋性（更複雜的模型效能可能更好，但結果更難解釋）

沒有任何單一演算法能解決所有問題。面試官想看到的是你對不同 ML 演算法的深入理解、其優缺點，以及根據需求與限制選擇模型的能力。

模型訓練#

模型選擇完成後，進入訓練階段。面試中可能討論的主題包括：

• 建構資料集
• 選擇損失函數
• 從零訓練 vs. 微調（Fine-tuning）
• 分散式訓練（Distributed Training）

建構資料集#

建構模型訓練與評估的資料集通常包含 5 個步驟：

除了「識別特徵與標籤」外，其餘步驟為通用操作，適用於任何 ML 系統設計任務。

收集原始資料：已在資料準備階段詳細討論，此處不再重複。

識別特徵與標籤：特徵的選擇已在特徵工程步驟討論，此處聚焦於為資料建立標籤。取得標籤有兩種常見方式：

• 人工標註（Hand Labeling）：由標註人員手動標記資料。優點是標註準確；缺點是成本高、速度慢、可能引入偏見、需要領域知識，且有資料隱私風險
• 自然標註（Natural Labeling）：無需人工標註，自動推斷真實標籤。例如新聞推薦系統中，以使用者是否按「喜歡」作為標籤（按了為 1，未按為 0），即可自然地標註訓練資料

選擇取樣策略：收集全部資料通常不切實際，取樣是有效減少資料量的方式。常見策略包括便利取樣、滾雪球取樣、分層取樣、蓄水池取樣和重要性取樣。

拆分資料：將資料集分為訓練集、驗證集（Validation）和測試集。

處理類別不平衡：當資料集的類別標籤分佈嚴重偏斜時，稱為不平衡資料集（Imbalanced Dataset）。佔比較大的類別稱為多數類別，佔比較小的稱為少數類別。

不平衡資料集是模型訓練中的嚴重問題，因為模型可能沒有足夠資料學習少數類別。常用的緩解方法：

重新取樣訓練資料（Resampling）：調整不同類別間的比例，使資料更平衡：

• 過取樣（Oversampling） 少數類別
• 欠取樣（Undersampling） 多數類別

調整損失函數：對少數類別的資料點賦予更高權重，使模型在錯誤預測少數類別時受到更大懲罰，從而更有效地學習少數類別。常用的損失函數包括 class-balanced loss 和 focal loss。

選擇損失函數#

損失函數衡量模型預測結果的準確程度，讓最佳化演算法在訓練過程中更新模型參數以最小化損失。

在 ML 面試中，通常需從現有損失函數中根據問題建構方式選擇適當的損失函數，有時需做微幅調整以適應特定問題。

從零訓練 vs. 微調#

微調（Fine-tuning） 指在新資料上繼續訓練模型，對其已學習的參數進行小幅調整。這是可能需要與面試官討論的設計決策。

分散式訓練#

隨著模型越來越大、資料集規模急劇增長，大規模訓練日益重要。分散式訓練將工作分配到多個工作節點，以平行方式加速模型訓練。兩種主要類型：

• 資料平行（Data Parallelism）
• 模型平行（Model Parallelism）

面試討論要點#

• 模型選擇：哪些 ML 模型適合此任務？各有何優缺點？考量因素包括：
  • 訓練所需時間
  • 模型預期的訓練資料量
  • 所需運算資源
  • 推論延遲
  • 能否部署在使用者裝置上？
  • 模型可解釋性
  • 能否利用持續訓練，還是需從零訓練？
  • 模型參數量與記憶體需求
  • 對於神經網路，可討論典型架構（如 ResNet、Transformer），以及超參數選擇（隱藏層數、神經元數、啟動函數等）
• 資料集標籤：如何取得標籤？資料是否已標註？品質如何？若有自然標籤，如何取得？使用者回饋如何收集？自然標籤的延遲多長？
• 模型訓練：
  • 損失函數選擇（如 Cross-entropy、MSE、MAE、Huber loss 等）
  • 正則化方法（如 L1、L2、Entropy Regularization、K-fold CV、Dropout）
  • 反向傳播（Backpropagation）
  • 最佳化方法（如 SGD、AdaGrad、Momentum、RMSProp）
  • 啟動函數選擇與原因（如 ELU、ReLU、Tanh、Sigmoid）
  • 如何處理不平衡資料集？
  • 偏差/變異權衡（Bias/Variance Trade-off）
  • 過擬合與欠擬合的可能原因與解決方法
• 持續學習：是否對每個新資料點進行線上訓練？是否需要為每位使用者個人化模型？重新訓練的頻率為何？

評估#

模型開發後的下一步是評估，即使用不同指標衡量 ML 模型的效能。評估分為離線評估與線上評估兩種方法。

離線評估#

離線評估是在模型開發階段評估 ML 模型效能的過程。通常先以評估資料集進行預測，再使用各種離線指標衡量預測結果與真實值的接近程度。

表 1.4：離線評估的常用指標

面試中需根據任務及問題建構方式，識別適合的離線評估指標。例如排序問題需討論排序指標及其取捨。

線上評估#

線上評估是模型部署後在生產環境中評估其表現的過程。線上指標通常與商業目標直接關聯。

表 1.5：線上評估的可能指標

實務中公司通常追蹤許多線上指標。面試時需選擇最重要的指標來衡量系統影響。線上指標的選擇具有主觀性，取決於產品負責人與商業利害關係人。在此步驟中，面試官在評估你的商業敏感度。

面試討論要點#

• 線上指標：哪些指標對衡量 ML 系統的線上效果重要？這些指標如何與商業目標關聯？
• 離線指標：哪些離線指標適合在開發階段評估模型預測？
• 公平性與偏見：模型是否可能在年齡、性別、種族等屬性上存在偏見？如何修正？若惡意使用者存取你的系統會發生什麼？

部署與服務#

選擇適當的評估指標後，下一步是將模型部署到生產環境並服務數百萬使用者。重要主題包括：

• 雲端 vs. 裝置端部署
• 模型壓縮
• 生產環境測試
• 預測管線

雲端 vs. 裝置端部署#

表 1.6：雲端與裝置端部署的取捨

模型壓縮#

模型壓縮是讓模型更小以降低推論延遲和模型大小的過程。三種常用技術：

• 知識蒸餾（Knowledge Distillation）：訓練小模型（學生）模仿大模型（教師）
• 剪枝（Pruning）：找到最不重要的參數並設為零，產生更稀疏、儲存更高效的模型
• 量化（Quantization）：使用更少的位元表示模型參數（通常從 32-bit 浮點數縮減），以減小模型大小。量化可在訓練過程中或訓練後進行

更多資訊可參考。

生產環境測試#

確保模型在生產環境表現良好的唯一方式是以真實流量測試。常用技術包括 shadow deployment、A/B testing、canary release、interleaving experiments、bandits 等。

Shadow Deployment（影子部署）#

將新模型與現有模型並行部署。每個請求同時路由至兩個模型，但僅提供現有模型的預測結果給使用者。

• 優點：在新模型經過充分測試前，最小化不可靠預測的風險
• 缺點：成本較高，預測數量加倍

A/B Testing#

將新模型與現有模型並行部署，一部分流量路由至新模型，其餘路由至現有模型。

正確執行 A/B Testing 需注意兩個關鍵因素：

• 路由至各模型的流量必須是隨機的
• 需在足夠多的資料點上執行，以確保結果具統計意義

預測管線#

在生產環境服務請求需要建構預測管線，關鍵設計決策是選擇線上預測或批次預測。

批次預測（Batch Prediction）：模型定期進行預測。由於預測已預先計算，不需擔心生成預測所需的時間。

批次預測的兩大缺點：

• 模型對使用者偏好變化的回應性較差
• 僅在能預先知道需計算什麼時才可行（例如語言翻譯系統無法預先翻譯）

線上預測（Online Prediction）：請求到達後立即生成並回傳預測。主要問題是模型可能需要較長時間生成預測。

線上或批次預測的選擇主要由產品需求驅動。線上預測適用於無法預知需計算什麼的情境；批次預測適用於處理大量資料且結果不需即時回傳的場景。

ML 系統開發涉及的不僅是 ML 建模。在面試中提出整體 ML 系統設計，展現了你對不同元件如何協同運作的深入理解。圖 1.23 展示了個人化新聞推薦系統的 ML 系統設計範例（將在第 10 章深入探討）。

面試討論要點#

• 是否需要模型壓縮？常用的壓縮技術有哪些？
• 線上預測還是批次預測更適合？各有何取捨？
• 是否可即時存取特徵？挑戰為何？
• 如何在生產環境中測試已部署的模型？
• ML 系統由多個元件協同服務請求，設計中各元件的職責為何？
• 應使用哪些技術確保服務的速度與可擴展性？

監控#

監控是追蹤、量測與記錄不同指標的任務。生產環境中的 ML 系統可能因多種原因失敗，監控有助於在失敗發生時及時偵測並修復。

面試中需討論的兩個主要面向：

• 系統在生產環境中失敗的原因
• 需要監控什麼

系統在生產環境中失敗的原因#

ML 系統部署後失敗最常見的原因之一是資料分佈偏移（Data Distribution Shift），即模型在生產環境中遇到的資料與訓練時遇到的資料不同。

真實世界中的資料分佈不斷變化，訓練資料隨時間推移變得不再具代表性，導致模型效能逐漸衰退。兩種常見的應對方法：

• 使用大型資料集訓練，讓模型學到更全面的分佈
• 定期重新訓練模型，使用來自新分佈的標註資料

需要監控什麼#

監控技術可分為兩大類：

營運相關指標（Operation-related Metrics）：確保系統正常運行，包括：

• 平均服務時間
• 吞吐量（Throughput）
• 預測請求數
• CPU/GPU 使用率

ML 相關指標（ML-specific Metrics）：

• 輸入/輸出監控：模型好壞取決於其消費的資料，監控輸入輸出至關重要
• 分佈偏移（Drift）：監控系統輸入與模型輸出的底層分佈變化
• 模型準確度：例如期望準確度在特定範圍內
• 模型版本：監控部署的模型版本

基礎設施#

基礎設施是訓練、部署與維護 ML 系統的基石。

許多 ML 面試不會問基礎設施相關問題。但 DevOps 和 MLOps 等角色可能需要基礎設施知識，因此務必釐清面試官對此主題的期望。

基礎設施是一個非常廣泛的主題，若有興趣可參考。

總結#

本章提出了 ML 系統設計面試的框架。雖然許多討論的主題是任務特定的，但部分主題具有通用性，適用於廣泛的任務。本書後續章節僅聚焦於特定問題的獨特討論要點，以避免重複。例如部署、監控和基礎設施相關主題在不同任務間通常相似，因此後續章節不再重複，但面試中通常仍需討論。

沒有工程師能精通 ML 生命週期的每個面向。有些工程師專精於部署與生產化，有些專精於模型開發。根據角色與面試官偏好，某些步驟可能深入討論，某些可能簡要帶過甚至跳過。一般而言，應試者應主導對話方向，同時準備好隨面試官的問題靈活應對。

掌握了這些基礎知識後，我們準備好來挑戰一些最常見的 ML 系統設計面試問題。