5.3.1 · D4MLOps & Deployment

Exercises — ML project lifecycle

2,106 words10 min readBack to topic

Before we start, here is the one map to keep in your head. Every exercise lives on one of these five stages, and the arrows are why we call it a loop, not a line.


The three formulas you will reuse

We will only ever need three little tools. Let us re-state each in plain words before any symbol is used, so a reader who has never seen them can still follow.


Level 1 — Recognition

Recall Solution

Order: Scoping → Data → Modeling → Deployment → Monitoring. The stage that first quantifies worth is Scoping (it uses Tool 1, the expected-value formula). WHAT this looks like: the leftmost box in the figure above, before you ever touch data.

Recall Solution

(a) ::: Data drift (b) ::: Canary deployment (c) ::: Shadow deployment See Deployment strategies (shadow, canary, blue-green) and Data drift and concept drift.


Level 2 — Application

Recall Solution

Plug into Tool 1: WHY this step: we price feasibility () and ongoing cost () in one number. \mathbb{E}[\text{Value}] = +\50{,}000 > 0$ → green-light in scoping.

Recall Solution

Set and solve for : WHY this step: at break-even the payoff exactly covers all fixed costs. Any feasibility makes it worthwhile. Answer: ====.


Level 3 — Analysis

Recall Solution

Tool 2: Bias () variance (), so the biggest lever is the model / features (bigger model, better architecture, richer features), not more data. See Bias-variance decomposition.

Recall Solution

Now variance () dominates. The lever is more / cleaner data and regularization — attack the generalization gap, not the model size.

Recall Solution

A negative avoidable bias is meaningless as a "gap to close." WHAT it really means: , so the model beats humans on the training set — the classic signature of overfitting (it memorized noise). See Human-level performance and Bayes error. The real signal now lives entirely in the variance term (): fix generalization.


Level 4 — Synthesis

Recall Solution

(a) ::: Data drift — the inputs changed (new vocabulary); the rule is fine. (b) ::: Jump back to Stage 2 (Data) — collect + label the new inputs, then retrain. Retraining on old data cannot help because old data lacks the new inputs. (c) ::: Shadow deployment — the new model runs on live traffic with output ignored, so you compare silently and spot the mismatch before it reaches users. See Model monitoring and observability.

Recall Solution

(a) ::: Concept drift — same , but changed (same input, new correct answer). (b) ::: Relabeling new data under the new policy helps; the old labels are now wrong, so you must re-label to the new concept and retrain. This is why concept drift is nastier than data drift — even your history is stale.


Level 5 — Mastery

Recall Solution

(a) ::: Model B. The north-star is the business metric subject to the satisficing constraint. Model A violates latency ( ms), so its higher accuracy is disqualified — a fast beats a too-slow . This is a scoping decision. (b) ::: Shadow deployment at the "Shadow" automation level: A runs on live traffic, its output is logged but never used, so you compare A vs B silently with zero user risk. See Deployment strategies (shadow, canary, blue-green).

Recall Solution

(a) Tool 1: Build it — positive expected value even after pricing the ongoing monitoring team. (b) ::: Data-centric. The dominant error category (60%) is noisy labels, so relabeling that one category (fixing the data for a fixed model) is the 80/20 move — clean data generalizes better. See Data-centric vs model-centric AI.


Recall

One-line self-check: which single formula would you use for each of — "is it worth building?", "where do I spend the week?", "which arrow after a production drop?" Answer ::: Tool 1 (expected value); Tool 2 (bias/variance gaps); Tool 3 (data vs concept drift).