5.3.14 · D4MLOps & Deployment

Exercises — A - B testing for models

2,340 words11 min readBack to topic

Two constants recur, so let us anchor them once, in plain words, before any symbol is used.

Figure — A - B testing for models

Level 1 — Recognition

Exercise 1.1 — Name the pieces

In a test, the currently deployed model serves half the users and a new candidate serves the other half. The team splits traffic by hashing the user ID. They watch conversion rate and reject the "no difference" idea only if the false-alarm rate stays under .

Identify: (a) control, (b) treatment, (c) randomization unit, (d) , (e) the null hypothesis in symbols.

Recall Solution 1.1
  • (a) Control (A) = the currently deployed model.
  • (b) Treatment (B) = the new candidate model.
  • (c) Randomization unit = the user (they hash the user ID).
  • (d) — the tolerated false-positive rate.
  • (e) — the two models have the same true conversion probability.

Exercise 1.2 — Read the sample-size formula

Look at . Without computing anything, say what happens to if you halve the MDE .

Recall Solution 1.2

depends on . Halving means becomes one quarter, so becomes four times larger. quadruples. Tiny effects are enormously expensive to detect — this is the single most important intuition in test design.


Level 2 — Application

Exercise 2.1 — Compute a pooled rate and standard error

Group A: , conversions. Group B: , conversions. Compute (a) , (b) , (c) the pooled rate , (d) the standard error .

Recall Solution 2.1
  • (a) .
  • (b) .
  • (c) . Why pooled? under both arms share one true rate, so use all the data to estimate it.
  • (d) . Then

Exercise 2.2 — Finish the z-test

Using Exercise 2.1's numbers, compute the z-statistic and the two-sided p-value . At , do you reject ?

Recall Solution 2.2
  • .
  • .
  • Two-sided p-value .
  • Since , do NOT reject . The lift is not yet significant — same story as the parent note's Example 1, but with fewer users the noise is even larger.

Level 3 — Analysis

Exercise 3.1 — Design the sample size

You want to detect a lift from to (so ) with () and power (). Compute the required per group.

Recall Solution 3.1

  • .
  • ; ; sum .
  • .
  • per group.

So users each side — round up to be safe, e.g. .

Exercise 3.2 — Confidence interval on the lift

Return to Exercise 2.1's data. Build a confidence interval for the true lift . Here you must use the un-pooled standard error and the multiplier . Does the interval contain , and does that agree with Exercise 2.2?

Recall Solution 3.2
  • .
  • .
  • Sum ; .
  • Interval: , i.e. .
  • The interval contains . This agrees with Exercise 2.2 (we did not reject ): whenever a two-sided CI on the difference covers , the two-sided test at fails to reject. See Confidence Intervals for why these two views are the same coin.

Level 4 — Synthesis

Exercise 4.1 — Peeking inflates false positives

A team runs an A/A test (both arms are the same model, so the true lift is exactly ). They peek times during the run, each time doing an independent-looking test at , and they stop and declare a winner the first time any peek shows . If the peeks were independent, what is the probability they falsely declare a winner at least once? Compare to the intended .

Recall Solution 4.1

The probability a single peek does not trigger is . For independent peeks all staying quiet: So , i.e. — over four times the intended .

(Real peeks are correlated because they share accumulated data, so the true inflation is somewhat less than this independent upper bound — but it is always above , and it grows with the number of looks.) Fix: fix in advance, or use sequential/alpha-spending methods. This is exactly the peeking mistake in A - B testing for models.

Exercise 4.2 — Guardrails override significance

Model B lifts conversion from to , and with per arm this is statistically significant. But B's p99 latency rises and error rate goes . The OEC is conversion; latency and errors are guardrails that must not regress by more than relative. Decide: ship or not, and justify with numbers.

Recall Solution 4.2
  • Conversion lift (relative) — significant and positive. ✅
  • Latency guardrail: relative change — vastly exceeds the regression budget. ❌
  • Error-rate guardrail: relative change . ❌

Decision: do NOT ship. A single OEC win cannot buy back massive guardrail regressions — statistical significance shippability. Investigate why B is slower/erroring (perhaps a heavier model needing optimization) before re-running. Relatedly, watch Model Monitoring & Drift post-launch.


Level 5 — Mastery

Exercise 5.1 — Full experiment design from a brief

You currently convert at . Product wants to ship any model that lifts conversion by at least absolute percentage point (, so ). You get eligible users per day, split . Use and power . (a) Required per group. (b) How many days must the test run? (c) Name one reason you should still run at least a full week even if the math says fewer days.

Recall Solution 5.1

(a) Sample size:

  • as before.
  • ; ; sum .
  • .
  • per group.

(b) You get /day split into two arms per arm per day. Days day. So in raw traffic terms under one day suffices.

(c) Still run days because: weekly seasonality (weekend users behave differently from weekday users) and novelty/primacy effects (users react to change itself in the first days). A sub-day test would sample only one slice of behavior and could mislead. See Offline vs Online Evaluation for why online timing matters.

Exercise 5.2 — When A/B is the wrong tool

For each scenario, choose A/B test vs. an alternative from the vault, and justify in one sentence. (i) You must rank candidate creatives and keep earning while learning which is best. (ii) You want to run the new model on live traffic but never show its output to users, just to check it doesn't crash. (iii) You want to expose the new model to of users first, then ramp to if healthy.

Recall Solution 5.2
  • (i) Multi-armed bandit (Multi-Armed Bandits) — it adaptively shifts traffic toward winners, minimizing regret while exploring, which fits "keep earning while learning" better than a fixed-split A/B.
  • (ii) Shadow deployment (Shadow Deployment) — the model scores real traffic but its outputs are discarded, so you validate stability and latency with zero user risk. A/B would expose users.
  • (iii) Canary release (Canary Releases) — a staged ramp () with automatic rollback on guardrail breach, which is about safe rollout, not statistical comparison.

A/B testing answers "is B statistically better on the OEC?" — a different question from "is B safe to roll out?" (canary/shadow) or "how do I optimally allocate traffic across many arms?" (bandit).