Band C: Evaluation, Distillation, and Operation
Examples 35-50 and 68-75 close the course by treating a completed adaptation the way Band A treated
the decision to start one: with paired evidence, not a single retrospective claim. Evaluating an
adapted model against its own base (co-25) means reading discordant pairs, not two isolated pass
rates, and a real statistical test (co-25, sharpened in Example 68) can disagree with an illustrative
shortcut. A regression suite built entirely from capabilities the fine-tune was never meant to touch
(co-26) is what catches catastrophic forgetting (co-22) hiding behind a headline win, and severity
weighting (Example 69) shows one safety-critical miss can matter more than seven cosmetic passes.
Distillation (co-27, co-28) is framed honestly as a cost and latency trade, never a quality one -- a
student can never exceed its teacher's own measured ceiling, only approach it. The band's second half
turns a trained adapter into an operated artefact: served, hot-swapped, and discovered through a
registry (co-21, co-29), version-pinned to its base (co-30), and retired only when a replacement
beats it on both quality and cost, with the licence check applying just as strictly to a replacement
candidate as it did to the original training run (co-31, co-32). Example 50 closes the band with a
capstone-shaped example citing all sixteen prior phases by name, before the capstone itself begins.
Every code-medium example's real, runnable Python 3.13 file lives under
learning/code/ex-NN-*/, run for real with genuine captured output. (See this topic's
Accuracy notes for this course's corrected Huyen citation and the
verified facts behind co-25's statistical machinery.)
Worked Example 35: Evaluate Against the Base
ex-35 · exercises co-25
Context: co-25 -- evaluate against the base insists on paired evidence, not two isolated pass
rates. This example runs twenty held-out triage cases through both the base and adapted models and
counts discordant pairs -- cases where the two models disagree -- rather than trusting the naive
60% vs. 85% headline alone.
# learning/code/ex-35-evaluate-against-the-base/evaluate_against_base.py
"""Worked Example 35: Evaluate Against the Base.""" # => co-25: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-25: one immutable row per case, base and adapted results recorded SIDE BY SIDE, not separately
class PairedCase(NamedTuple): # => co-25: a paired comparison -- the SAME case run through base and adapted, never two separate samples
case_id: str # => co-25: which held-out triage case this row is
base_pass: bool # => co-25: did the unadapted base model pass this case
adapted_pass: bool # => co-25: did the adapted model pass the SAME case
# => co-25: 20 held-out cases -- 11 both pass, 6 only-adapted-passes, 1 only-base-passes, 2 both fail
PAIRED_RESULTS: list[PairedCase] = [ # => co-25: one row per case, in evaluation order
PairedCase(case_id="case-01", base_pass=True, adapted_pass=True), # => co-25: concordant pass 1
PairedCase(case_id="case-02", base_pass=True, adapted_pass=True), # => co-25: concordant pass 2
PairedCase(case_id="case-03", base_pass=True, adapted_pass=True), # => co-25: concordant pass 3
PairedCase(case_id="case-04", base_pass=True, adapted_pass=True), # => co-25: concordant pass 4
PairedCase(case_id="case-05", base_pass=True, adapted_pass=True), # => co-25: concordant pass 5
PairedCase(case_id="case-06", base_pass=True, adapted_pass=True), # => co-25: concordant pass 6
PairedCase(case_id="case-07", base_pass=True, adapted_pass=True), # => co-25: concordant pass 7
PairedCase(case_id="case-08", base_pass=True, adapted_pass=True), # => co-25: concordant pass 8
PairedCase(case_id="case-09", base_pass=True, adapted_pass=True), # => co-25: concordant pass 9
PairedCase(case_id="case-10", base_pass=True, adapted_pass=True), # => co-25: concordant pass 10
PairedCase(case_id="case-11", base_pass=True, adapted_pass=True), # => co-25: concordant pass 11
PairedCase(case_id="case-12", base_pass=False, adapted_pass=True), # => co-25: discordant -- adapting FIXED this case, 1 of 6
PairedCase(case_id="case-13", base_pass=False, adapted_pass=True), # => co-25: discordant -- adapting FIXED this case, 2 of 6
PairedCase(case_id="case-14", base_pass=False, adapted_pass=True), # => co-25: discordant -- adapting FIXED this case, 3 of 6
PairedCase(case_id="case-15", base_pass=False, adapted_pass=True), # => co-25: discordant -- adapting FIXED this case, 4 of 6
PairedCase(case_id="case-16", base_pass=False, adapted_pass=True), # => co-25: discordant -- adapting FIXED this case, 5 of 6
PairedCase(case_id="case-17", base_pass=False, adapted_pass=True), # => co-25: discordant -- adapting FIXED this case, 6 of 6
PairedCase(case_id="case-18", base_pass=True, adapted_pass=False), # => co-25: discordant -- adapting BROKE this case, the one regression
PairedCase(case_id="case-19", base_pass=False, adapted_pass=False), # => co-25: concordant fail 1 -- neither model handles this
PairedCase(case_id="case-20", base_pass=False, adapted_pass=False), # => co-25: concordant fail 2 -- neither model handles this
] # => co-25: closes PAIRED_RESULTS -- 20 cases total
def discordant_counts(cases: list[PairedCase]) -> tuple[int, int]: # => co-25: (b, c) -- only pairs where base and adapted DISAGREE carry evidence
"""Return (b, c): the count of base-fail/adapted-pass pairs and base-pass/adapted-fail pairs in `cases`.""" # => co-25: documents discordant_counts's contract -- no runtime output, just sets its __doc__
b = sum(1 for c in cases if not c.base_pass and c.adapted_pass) # => co-25: cases adapting FIXED -- evidence FOR the adaptation
c = sum(1 for c in cases if c.base_pass and not c.adapted_pass) # => co-25: cases adapting BROKE -- evidence AGAINST the adaptation
return b, c # => co-25: returns this computed value to the caller
if __name__ == "__main__": # => co-25: entry point -- runs only when this file executes directly, not on import
base_pass_rate = sum(1 for c in PAIRED_RESULTS if c.base_pass) / len(PAIRED_RESULTS) # => co-25: naive base pass rate
adapted_pass_rate = sum(1 for c in PAIRED_RESULTS if c.adapted_pass) / len(PAIRED_RESULTS) # => co-25: naive adapted pass rate
print(f"Base pass rate: {base_pass_rate:.0%} | Adapted pass rate: {adapted_pass_rate:.0%}") # => co-25: the two printed numbers ALONE
b, c = discordant_counts(PAIRED_RESULTS) # => co-25: the PAIRED evidence -- what statistics-for-evaluation actually asks for
print(f"Discordant pairs: adapting fixed {b} cases, adapting broke {c} cases") # => co-25: this is the real comparison, not the two rates above
assert base_pass_rate == 0.60, "base pass rate must be exactly 60% in this scenario" # => co-25
assert adapted_pass_rate == 0.85, "adapted pass rate must be exactly 85% in this scenario" # => co-25
assert (b, c) == (6, 1), "the discordant pair counts must match the planted scenario exactly" # => co-25
supported = b >= 5 and c <= 1 # => co-25: a stand-in for a real paired significance test -- see statistics-for-evaluation for the actual machinery
print(f"Improvement is evidence-supported (stand-in threshold b>=5, c<=1): {supported}") # => co-25
assert supported, "6 fixes against 1 regression must clear this illustrative evidence threshold" # => co-25
print("MATCH: 'base 60%, adapted 85%' is two printed numbers -- the paired 6-fixed-vs-1-broken comparison is the actual evidence a decision needs") # => co-25
# => co-25: this file's b/c stand-in is illustrative -- a real capstone uses statistics-for-evaluation's paired test, not this simplified thresholdRun: python3 evaluate_against_base.py
Output:
Base pass rate: 60% | Adapted pass rate: 85%
Discordant pairs: adapting fixed 6 cases, adapting broke 1 cases
Improvement is evidence-supported (stand-in threshold b>=5, c<=1): True
MATCH: 'base 60%, adapted 85%' is two printed numbers -- the paired 6-fixed-vs-1-broken comparison is the actual evidence a decision needsVerify: discordant_counts(PAIRED_RESULTS) returns exactly (6, 1), and the illustrative
b >= 5 and c <= 1 threshold reads True, satisfying co-25's rule that a decision needs paired
discordant evidence, not two isolated pass rates.
Key takeaway: 60% and 85% are two numbers -- 6 fixed against 1 broken, on the identical
twenty cases, is the actual evidence behind the improvement.
Why It Matters: this file's own illustrative b>=5, c<=1 threshold is a stand-in, and Example 68 shows exactly
why: running the real exact binomial sign test on this same 6-to-1 result reveals the shortcut
was too generous, sharpening this example's own conclusion. Trusting a naive percentage-point gap
alone would have let a result this close pass as a genuine win without real statistical grounding.
Worked Example 36: Regression Suite
ex-36 · exercises co-26
Context: co-26 -- the regression suite is built entirely from capabilities the triage fine-tune was never meant to touch. This example assembles twelve cases across arithmetic, general-qa, formatting, and reasoning, deliberately excluding the target triage task itself.
# learning/code/ex-36-regression-suite/regression_suite.py
"""Worked Example 36: Regression Suite.""" # => co-26: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-26: one immutable row per regression case, each tagged with the capability it exercises
class RegressionCase(NamedTuple): # => co-26: a capability check the fine-tune was NOT meant to change
case_id: str # => co-26: unique id
capability: str # => co-26: which untouched capability this case probes -- deliberately NOT the triage target task
prompt: str # => co-26: what is asked
expected_answer: str # => co-26: the correct answer, independent of the fine-tuning target
TARGET_TASK_CAPABILITY = "triage" # => co-26: the ONE capability the fine-tune is meant to change -- everything else here must differ from it
# => co-26: 12 cases spanning four capabilities the triage fine-tune should never have touched
REGRESSION_SUITE: list[RegressionCase] = [ # => co-26: one row per regression case
RegressionCase(case_id="reg-01", capability="arithmetic", prompt="What is 47 + 58?", expected_answer="105"), # => co-26: arithmetic 1
RegressionCase(case_id="reg-02", capability="arithmetic", prompt="What is 12 * 9?", expected_answer="108"), # => co-26: arithmetic 2
RegressionCase(case_id="reg-03", capability="arithmetic", prompt="What is 144 / 12?", expected_answer="12"), # => co-26: arithmetic 3
RegressionCase(case_id="reg-04", capability="general-qa", prompt="What is the capital of Japan?", expected_answer="Tokyo"), # => co-26: general-qa 1
RegressionCase(case_id="reg-05", capability="general-qa", prompt="How many days in a leap year?", expected_answer="366"), # => co-26: general-qa 2
RegressionCase(case_id="reg-06", capability="general-qa", prompt="What gas do plants absorb?", expected_answer="carbon dioxide"), # => co-26: general-qa 3
RegressionCase(case_id="reg-07", capability="formatting", prompt="List three fruits as a comma-separated line.", expected_answer="apple, pear, plum"), # => co-26: formatting 1
RegressionCase(case_id="reg-08", capability="formatting", prompt="Format 'hello world' in title case.", expected_answer="Hello World"), # => co-26: formatting 2
RegressionCase(case_id="reg-09", capability="formatting", prompt="Wrap 'note' in square brackets.", expected_answer="[note]"), # => co-26: formatting 3
RegressionCase(case_id="reg-10", capability="reasoning", prompt="If all cats are mammals and Tom is a cat, is Tom a mammal?", expected_answer="yes"), # => co-26: reasoning 1
RegressionCase(case_id="reg-11", capability="reasoning", prompt="Which is heavier: one kilogram of feathers or 500 grams of lead?", expected_answer="the feathers"), # => co-26: reasoning 2
RegressionCase(case_id="reg-12", capability="reasoning", prompt="A train leaves at 2pm and arrives at 5pm; how long was the trip?", expected_answer="3 hours"), # => co-26: reasoning 3
] # => co-26: closes REGRESSION_SUITE -- 12 cases, 4 capabilities, 3 each
if __name__ == "__main__": # => co-26: entry point -- runs only when this file executes directly, not on import
capabilities_covered = {case.capability for case in REGRESSION_SUITE} # => co-26: the DISTINCT capabilities this suite actually probes
print(f"Regression suite covers {len(REGRESSION_SUITE)} cases across capabilities: {sorted(capabilities_covered)}") # => co-26
assert TARGET_TASK_CAPABILITY not in capabilities_covered, "the regression suite must NOT re-test the fine-tune's own target task" # => co-26
assert len(capabilities_covered) == 4, "the suite must span multiple distinct untouched capabilities, not just one" # => co-26
for capability in sorted(capabilities_covered): # => co-26: verify EACH capability has multiple cases, not just a token single check
cases_in_capability = [c for c in REGRESSION_SUITE if c.capability == capability] # => co-26: this capability's own cases
assert len(cases_in_capability) >= 3, f"capability {capability!r} must have at least 3 regression cases to be a real check" # => co-26
print("MATCH: this suite is built entirely from capabilities OUTSIDE the fine-tuning target -- exactly what co-22's forgetting check needs to run against") # => co-26
# => co-26: without this suite, ex-37's forgetting measurement has nothing to run against -- the suite must exist BEFORE the adapted model doesRun: python3 regression_suite.py
Output:
Regression suite covers 12 cases across capabilities: ['arithmetic', 'formatting', 'general-qa', 'reasoning']
MATCH: this suite is built entirely from capabilities OUTSIDE the fine-tuning target -- exactly what co-22's forgetting check needs to run againstVerify: capabilities_covered spans exactly four capabilities, none of them "triage", each
with at least three cases, satisfying co-26's rule that a regression suite must probe capabilities
outside the fine-tuning target.
Key takeaway: twelve cases, deliberately excluding the triage target task, is what a regression suite needs to exist as -- built before the adapted model does, not improvised after a problem is noticed.
Why It Matters: without this suite existing first, Example 37's forgetting measurement would have nothing to run against. This ordering -- suite before adapted model -- is what makes catastrophic forgetting detectable rather than merely suspected. A team that builds the adapted model first and only writes a regression suite afterward has no honest baseline left to compare against.
Worked Example 37: Catastrophic Forgetting, Measured
ex-37 · exercises co-22, co-26
Context: co-22 -- catastrophic forgetting hides behind a headline win. This example shows
the adapted model scoring 94% on its own target task while quietly dropping to 60% on Example
36's regression suite -- a 40-point capability loss the target-task eval alone never reveals.
# learning/code/ex-37-catastrophic-forgetting-measured/forgetting_measured.py
"""Worked Example 37: Catastrophic Forgetting, Measured.""" # => co-22: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-26: a compact regression suite, self-contained for this file, echoing ex-36's shape
class RegressionCase(NamedTuple): # => co-26: a capability check the fine-tune was NOT meant to change
case_id: str # => co-26: unique id
base_pass: bool # => co-22: did the UNADAPTED base model pass this case
adapted_pass: bool # => co-22: did the ADAPTED model pass the SAME case, after triage fine-tuning
# => co-22: the same ten held-out regression cases, run through both models -- none of them is a triage case
REGRESSION_RESULTS: list[RegressionCase] = [ # => co-22: one row per regression case
RegressionCase(case_id="reg-01", base_pass=True, adapted_pass=True), # => co-22: arithmetic -- unaffected
RegressionCase(case_id="reg-02", base_pass=True, adapted_pass=True), # => co-22: arithmetic -- unaffected
RegressionCase(case_id="reg-03", base_pass=True, adapted_pass=False), # => co-22: arithmetic -- REGRESSED after triage fine-tuning
RegressionCase(case_id="reg-04", base_pass=True, adapted_pass=True), # => co-22: general-qa -- unaffected
RegressionCase(case_id="reg-05", base_pass=True, adapted_pass=False), # => co-22: general-qa -- REGRESSED
RegressionCase(case_id="reg-06", base_pass=True, adapted_pass=True), # => co-22: general-qa -- unaffected
RegressionCase(case_id="reg-07", base_pass=True, adapted_pass=True), # => co-22: formatting -- unaffected
RegressionCase(case_id="reg-08", base_pass=True, adapted_pass=False), # => co-22: formatting -- REGRESSED
RegressionCase(case_id="reg-09", base_pass=True, adapted_pass=True), # => co-22: reasoning -- unaffected
RegressionCase(case_id="reg-10", base_pass=True, adapted_pass=False), # => co-22: reasoning -- REGRESSED
] # => co-22: closes REGRESSION_RESULTS -- base passes ALL 10, adapted passes only 6
TARGET_TASK_PASS_RATE_ADAPTED = 0.94 # => co-25: the triage eval from ex-35's lineage -- looks like a clean win in isolation
REGRESSION_ALERT_THRESHOLD = 0.90 # => co-22: below this regression pass rate, the forgetting is a real operational problem
if __name__ == "__main__": # => co-22: entry point -- runs only when this file executes directly, not on import
base_regression_pass_rate = sum(1 for c in REGRESSION_RESULTS if c.base_pass) / len(REGRESSION_RESULTS) # => co-22: base model's regression-suite score
adapted_regression_pass_rate = sum(1 for c in REGRESSION_RESULTS if c.adapted_pass) / len(REGRESSION_RESULTS) # => co-22: adapted model's regression-suite score
print(f"Target-task pass rate (adapted): {TARGET_TASK_PASS_RATE_ADAPTED:.0%}") # => co-25: this is the number ex-35 alone would report
print(f"Regression suite: base {base_regression_pass_rate:.0%} | adapted {adapted_regression_pass_rate:.0%}") # => co-22: what ex-35 alone WOULD NOT show
assert base_regression_pass_rate == 1.00, "the unadapted base must pass every regression case -- these capabilities were never in question for it" # => co-22
assert adapted_regression_pass_rate == 0.60, "the adapted model must show a measurable regression-suite drop in this scenario" # => co-22
forgetting_detected = adapted_regression_pass_rate < REGRESSION_ALERT_THRESHOLD # => co-22: does the drop cross the alert line
print(f"Catastrophic forgetting detected (threshold {REGRESSION_ALERT_THRESHOLD:.0%}): {forgetting_detected}") # => co-22
assert forgetting_detected, "a 40-point regression-suite drop must trigger the forgetting alert" # => co-22,co-26
print("MATCH: the target-task eval alone reports a 94% win -- the regression suite reveals a 40-point capability loss that eval never saw") # => co-22,co-25,co-26
# => co-22,co-25,co-26: co-25's mandate is BOTH the target-task comparison AND this regression suite -- either alone is an incomplete pictureRun: python3 forgetting_measured.py
Output:
Target-task pass rate (adapted): 94%
Regression suite: base 100% | adapted 60%
Catastrophic forgetting detected (threshold 90%): True
MATCH: the target-task eval alone reports a 94% win -- the regression suite reveals a 40-point capability loss that eval never sawVerify: adapted_regression_pass_rate drops to 60% from the base's clean 100%, crossing the
90% REGRESSION_ALERT_THRESHOLD, satisfying co-22's rule that a target-task win can coexist with
undetected catastrophic forgetting.
Key takeaway: a 94% target-task win and a 40-point regression-suite drop are both true of the
same model at the same time -- reporting only the first is not lying, but it is incomplete.
Why It Matters: this is co-25's mandate made concrete: a paired target-task comparison and a regression suite are
both required, not either alone. Example 38 shows this same forgetting damage is even worse under a
full fine-tune than under this LoRA adapter. A headline 94% win that hides a 40-point
regression is exactly the kind of result co-25's paired-evidence rule exists to catch.
Worked Example 38: Forgetting Is Worse for Full Fine-Tune
ex-38 · exercises co-22, co-18
Context: continuing co-22 -- this example compares regression damage between Band B's two
training strategies for the identical target-task gain, showing a full fine-tune causing 1.5 times
the damage of a LoRA adapter for only two extra points of target-task quality.
# learning/code/ex-38-forgetting-is-worse-for-full-fine-tune/forgetting_full_vs_adapter.py
"""Worked Example 38: Forgetting Is Worse for Full Fine-Tune.""" # => co-22: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-18: a small, self-documenting record for each training strategy's regression damage
@dataclass(frozen=True) # => co-18: frozen -- a measured regression profile is a fact once run, not a mutable running total
class RegressionProfile: # => co-22: one training strategy's target-task gain against its regression-suite cost
strategy: str # => co-18: "full fine-tune" or "LoRA adapter", the two strategies ex-27/ex-28 and ex-29/ex-30 already introduced
target_task_pass_rate: float # => co-25: pass rate on the triage target task after this strategy's training
regression_suite_pass_rate: float # => co-22: pass rate on ex-36's untouched-capability suite after this strategy's training
BASE_REGRESSION_PASS_RATE = 1.00 # => co-22: the unadapted base's own regression-suite score, the reference point both strategies are compared against
FULL_FINE_TUNE = RegressionProfile( # => co-17: updates ALL parameters, per ex-27/ex-28's lineage
strategy="full fine-tune", # => co-17
target_task_pass_rate=0.96, # => co-25: matches ex-27's own measured target-task result
regression_suite_pass_rate=0.40, # => co-22: a much larger regression-suite drop -- updating every parameter reshapes far more than the target behaviour
) # => co-22: closes FULL_FINE_TUNE
LORA_ADAPTER = RegressionProfile( # => co-18: trains a small added parameter set with the base FROZEN, per ex-29/ex-30's lineage
strategy="LoRA adapter", # => co-19
target_task_pass_rate=0.94, # => co-25: matches ex-29's own measured target-task result, nearly as good as the full fine-tune
regression_suite_pass_rate=0.60, # => co-22: matches ex-37's own measured adapted-model regression score
) # => co-22: closes LORA_ADAPTER
if __name__ == "__main__": # => co-22: entry point -- runs only when this file executes directly, not on import
for profile in (FULL_FINE_TUNE, LORA_ADAPTER): # => co-22: compare both strategies side by side
regression_damage = BASE_REGRESSION_PASS_RATE - profile.regression_suite_pass_rate # => co-22: how far below the base's clean 100% this strategy fell
print(f" {profile.strategy}: target {profile.target_task_pass_rate:.0%} | regression suite {profile.regression_suite_pass_rate:.0%} | damage {regression_damage:.0%}") # => co-22
full_ft_damage = BASE_REGRESSION_PASS_RATE - FULL_FINE_TUNE.regression_suite_pass_rate # => co-22: full fine-tune's regression damage
adapter_damage = BASE_REGRESSION_PASS_RATE - LORA_ADAPTER.regression_suite_pass_rate # => co-22: adapter's regression damage
target_task_gap = FULL_FINE_TUNE.target_task_pass_rate - LORA_ADAPTER.target_task_pass_rate # => co-25: how much target-task quality the adapter gives up
print(f"Full fine-tune causes {full_ft_damage / adapter_damage:.1f}x the regression damage of the adapter, for a {target_task_gap:.0%} target-task gain") # => co-22,co-18
assert full_ft_damage > adapter_damage, "the full fine-tune must damage untouched capability MORE than the parameter-efficient adapter" # => co-22,co-18
assert target_task_gap <= 0.03, "the full fine-tune's target-task edge over the adapter must be small in this scenario" # => co-25
print("MATCH: full fine-tuning buys 2 target-task points at the cost of far worse regression damage -- the adapter is the better trade here") # => co-22,co-18
# => co-22,co-18: this is the concrete evidence behind the tension note -- a full fine-tune should have to argue for itself against a measured adapter baselineRun: python3 forgetting_full_vs_adapter.py
Output:
full fine-tune: target 96% | regression suite 40% | damage 60%
LoRA adapter: target 94% | regression suite 60% | damage 40%
Full fine-tune causes 1.5x the regression damage of the adapter, for a 2% target-task gain
MATCH: full fine-tuning buys 2 target-task points at the cost of far worse regression damage -- the adapter is the better trade hereVerify: full_ft_damage / adapter_damage computes to 1.5x for a target-task gap of only 2%,
satisfying co-22's rule that a full fine-tune's regression damage exceeds a comparably-effective
adapter's damage.
Key takeaway: two target-task points bought sixty points of regression damage instead of forty -- the full fine-tune is the worse trade for a fraction of extra target-task quality.
Why It Matters: this is the concrete evidence behind Band B's own tension between full fine-tuning and LoRA adapters -- a full fine-tune should have to argue for itself against a measured adapter baseline, not be assumed superior by default. Two extra points of target-task quality is a thin justification for damage that costs one-and-a-half times as much on everything else the model used to do.
Worked Example 39: Overfitting Invisible in Training Loss
ex-39 · exercises co-23, co-15
Context: continuing co-23 -- this example reads the same overfitting run Example 67 monitored live, this time only through training loss, showing loss recommending the worst held-out epoch of the entire run.
# learning/code/ex-39-overfitting-invisible-in-training-loss/overfitting_invisible_in_loss.py
"""Worked Example 39: Overfitting Invisible in Training Loss.""" # => co-23: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-23: one immutable row per epoch, training loss and held-out score recorded TOGETHER
class LossSnapshot(NamedTuple): # => co-23: what the training loop's own loss curve says, versus what a held-out check would say
epoch: int # => co-23: which epoch this snapshot is from
training_loss: float # => co-23: the loss the optimizer is minimizing -- computed ONLY on training data
held_out_pass_rate: float # => co-15: pass rate on a split the model never trains on -- the only honest signal
# => co-23,co-15: the same underlying overfitting run as ex-67, this time read through TRAINING LOSS instead of the val gap
LOSS_CURVE: list[LossSnapshot] = [ # => co-23: per-epoch snapshots, in order
LossSnapshot(epoch=1, training_loss=1.82, held_out_pass_rate=0.70), # => co-23: epoch 1 -- loss falling, held-out rising, both look healthy
LossSnapshot(epoch=2, training_loss=1.10, held_out_pass_rate=0.84), # => co-23: epoch 2 -- loss keeps falling, held-out keeps rising
LossSnapshot(epoch=3, training_loss=0.61, held_out_pass_rate=0.91), # => co-23: epoch 3 -- loss still falling, held-out at its PEAK
LossSnapshot(epoch=4, training_loss=0.29, held_out_pass_rate=0.88), # => co-23: epoch 4 -- loss STILL falling, held-out has started falling
LossSnapshot(epoch=5, training_loss=0.08, held_out_pass_rate=0.83), # => co-23: epoch 5 -- loss at its BEST-LOOKING value, held-out down 8 points from peak
] # => co-23: closes LOSS_CURVE
def loss_says_improving(curve: list[LossSnapshot]) -> bool: # => co-23: what a loss-only dashboard would report at the final epoch
"""Return whether `training_loss` strictly decreases across every consecutive pair of epochs in `curve`.""" # => co-23: documents loss_says_improving's contract -- no runtime output, just sets its __doc__
return all(curve[i].training_loss < curve[i - 1].training_loss for i in range(1, len(curve))) # => co-23: monotonic decrease, epoch over epoch
def held_out_peak_epoch(curve: list[LossSnapshot]) -> int: # => co-15: the epoch a held-out check would have flagged as best
"""Return the epoch number with the highest `held_out_pass_rate` in `curve`.""" # => co-15: documents held_out_peak_epoch's contract -- no runtime output, just sets its __doc__
return max(curve, key=lambda snapshot: snapshot.held_out_pass_rate).epoch # => co-15: returns this computed value to the caller
if __name__ == "__main__": # => co-23: entry point -- runs only when this file executes directly, not on import
for snapshot in LOSS_CURVE: # => co-23: print exactly what a training log would show, epoch by epoch
print(f" epoch {snapshot.epoch}: training loss {snapshot.training_loss:.2f} | held-out pass rate {snapshot.held_out_pass_rate:.0%}") # => co-23
loss_verdict = loss_says_improving(LOSS_CURVE) # => co-23: what the loss curve ALONE would conclude
print(f"Training loss says 'still improving' at every epoch: {loss_verdict}") # => co-23
assert loss_verdict, "training loss must decrease monotonically across all 5 epochs in this scenario -- that is exactly the trap" # => co-23
peak_epoch = held_out_peak_epoch(LOSS_CURVE) # => co-15: what the held-out check ACTUALLY shows
print(f"Held-out pass rate actually peaks at epoch {peak_epoch}, then falls for two more epochs") # => co-15
assert peak_epoch == 3, "the held-out peak must land at epoch 3, two epochs before the loss curve's own best-looking point" # => co-15,co-23
final_epoch_loss_looks_best = LOSS_CURVE[-1].training_loss == min(s.training_loss for s in LOSS_CURVE) # => co-23: is the FINAL epoch's loss the best of the whole run
assert final_epoch_loss_looks_best, "the final epoch must have the lowest training loss of the whole run, even though it is NOT the best model" # => co-23
print("MATCH: training loss recommends epoch 5 -- the worst held-out result of the run -- because loss alone cannot see memorization happening") # => co-15,co-23
# => co-15,co-23: this is why co-15's held-out discipline exists -- a metric computed only on training data will always look like it is improvingRun: python3 overfitting_invisible_in_loss.py
Output:
epoch 1: training loss 1.82 | held-out pass rate 70%
epoch 2: training loss 1.10 | held-out pass rate 84%
epoch 3: training loss 0.61 | held-out pass rate 91%
epoch 4: training loss 0.29 | held-out pass rate 88%
epoch 5: training loss 0.08 | held-out pass rate 83%
Training loss says 'still improving' at every epoch: True
Held-out pass rate actually peaks at epoch 3, then falls for two more epochs
MATCH: training loss recommends epoch 5 -- the worst held-out result of the run -- because loss alone cannot see memorization happeningVerify: loss_says_improving is True across all five epochs while held_out_peak_epoch
correctly identifies epoch 3, satisfying co-15's rule that a metric computed only on training data
always looks like it is still improving.
Key takeaway: training loss recommends the final, worst-performing epoch of the entire run -- because loss, computed only on training data, cannot see memorization happening.
Why It Matters: this is why co-15's held-out discipline exists at all. Example 40 immediately shows what to do with this insight: stop on the held-out signal, not the configured epoch count, and gain a measurable improvement on a still-unseen third split. Training loss looks like a trustworthy signal right up until the point it actively recommends the single worst epoch to ship.
Worked Example 40: Early Stopping on Validation
ex-40 · exercises co-23, co-24
Context: continuing co-23 -- this example picks the checkpoint validation says is best, rather than the last epoch trained, and confirms the gain holds on a third, still-unseen test split.
# learning/code/ex-40-early-stopping-on-validation/early_stopping.py
"""Worked Example 40: Early Stopping on Validation.""" # => co-23: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-23: one immutable row per epoch, validation score tracked to pick a stopping point
class EpochCheckpoint(NamedTuple): # => co-24: a saved model snapshot at one epoch, plus what would happen if training stopped here
epoch: int # => co-23: which epoch this checkpoint is from
val_pass_rate: float # => co-23: validation pass rate at this epoch -- the signal early stopping watches
held_out_test_pass_rate: float # => co-15: a THIRD, still-unseen split -- what actually matters, checked only ONCE at the end
CHECKPOINTS: list[EpochCheckpoint] = [ # => co-23: the same 5-epoch run as ex-39/ex-67, now with a held-out TEST score attached to each checkpoint
EpochCheckpoint(epoch=1, val_pass_rate=0.70, held_out_test_pass_rate=0.68), # => co-23: epoch 1
EpochCheckpoint(epoch=2, val_pass_rate=0.84, held_out_test_pass_rate=0.83), # => co-23: epoch 2
EpochCheckpoint(epoch=3, val_pass_rate=0.91, held_out_test_pass_rate=0.90), # => co-23: epoch 3 -- validation's peak
EpochCheckpoint(epoch=4, val_pass_rate=0.88, held_out_test_pass_rate=0.85), # => co-23: epoch 4 -- validation already falling
EpochCheckpoint(epoch=5, val_pass_rate=0.83, held_out_test_pass_rate=0.79), # => co-23: epoch 5 -- trained to completion, validation's worst point
] # => co-23: closes CHECKPOINTS
def stop_early(checkpoints: list[EpochCheckpoint]) -> EpochCheckpoint: # => co-23: pick the checkpoint validation says is best, not the last one trained
"""Return the `EpochCheckpoint` with the highest `val_pass_rate` in `checkpoints`, the early-stopping choice.""" # => co-23: documents stop_early's contract -- no runtime output, just sets its __doc__
return max(checkpoints, key=lambda checkpoint: checkpoint.val_pass_rate) # => co-23: returns this computed value to the caller
if __name__ == "__main__": # => co-23: entry point -- runs only when this file executes directly, not on import
trained_to_completion = CHECKPOINTS[-1] # => co-24: the naive choice -- whatever epoch count was originally configured
early_stopped = stop_early(CHECKPOINTS) # => co-23: the validation-driven choice
print(f"Trained-to-completion checkpoint: epoch {trained_to_completion.epoch} (val {trained_to_completion.val_pass_rate:.0%})") # => co-24
print(f"Early-stopped checkpoint: epoch {early_stopped.epoch} (val {early_stopped.val_pass_rate:.0%})") # => co-23
assert early_stopped.epoch == 3, "early stopping must select epoch 3, the true validation peak, in this scenario" # => co-23
assert trained_to_completion.epoch == 5, "the naive trained-to-completion choice must be epoch 5, the last epoch run" # => co-24
test_gain_from_stopping_early = early_stopped.held_out_test_pass_rate - trained_to_completion.held_out_test_pass_rate # => co-15: the REAL result, on the still-unseen test split
print(f"Held-out test pass rate: early-stopped {early_stopped.held_out_test_pass_rate:.0%} vs. trained-to-completion {trained_to_completion.held_out_test_pass_rate:.0%}") # => co-15
assert test_gain_from_stopping_early > 0, "the early-stopped checkpoint must beat the trained-to-completion checkpoint on the held-out test split too" # => co-15,co-23
print(f"MATCH: stopping on validation gains {test_gain_from_stopping_early:.0%} on the still-unseen test split versus training to the configured epoch count") # => co-23,co-24
# => co-23,co-24: epoch count is a schedule, not a target -- validation is the signal that decides when to stop, and it must be checked, not assumedRun: python3 early_stopping.py
Output:
Trained-to-completion checkpoint: epoch 5 (val 83%)
Early-stopped checkpoint: epoch 3 (val 91%)
Held-out test pass rate: early-stopped 90% vs. trained-to-completion 79%
MATCH: stopping on validation gains 11% on the still-unseen test split versus training to the configured epoch countVerify: stop_early(CHECKPOINTS) selects epoch 3, beating epoch 5's held-out test pass rate
by 11 points on the THIRD, still-unseen split, satisfying co-23's rule that epoch count is a
schedule, and validation is the signal that decides when to actually stop.
Key takeaway: stopping at the validation peak beat training to completion by 11 points, on a
split neither decision ever looked at while choosing.
Why It Matters: this closes the loop opened by Example 39's loss-only trap and Example 67's live monitoring -- validation is what turns "when should training stop" from a configured number into a checked decision. Stopping on the configured epoch count alone would have shipped a materially worse checkpoint than the one validation actually identified as best.
Worked Example 41: The Fine-Tune That Did Not Help
ex-41 · exercises co-25, co-32
Context: continuing co-25 -- this example shows a completed fine-tune whose naive base and adapted pass rates land exactly equal, then reveals the paired evidence behind that equal-looking headline: two cases fixed, two cases broken, net zero.
# learning/code/ex-41-the-fine-tune-that-did-not-help/fine_tune_that_did_not_help.py
"""Worked Example 41: The Fine-Tune That Did Not Help.""" # => co-25: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-25: one immutable row per paired case, the SAME discipline ex-35 used, applied to a run that fails it
class PairedCase(NamedTuple): # => co-25: a paired comparison -- base and adapted run through the SAME held-out case
case_id: str # => co-25: which held-out case this row is
base_pass: bool # => co-25: did the unadapted base model pass this case
adapted_pass: bool # => co-25: did the FULLY TRAINED adapted model pass the same case, after weeks of data work
# => co-25: a completed adaptation -- the data was curated, the adapter trained, and it STILL does not clear the bar
PAIRED_RESULTS: list[PairedCase] = [ # => co-25: one row per case, in evaluation order
PairedCase(case_id="case-01", base_pass=True, adapted_pass=True), # => co-25: concordant pass 1
PairedCase(case_id="case-02", base_pass=True, adapted_pass=True), # => co-25: concordant pass 2
PairedCase(case_id="case-03", base_pass=True, adapted_pass=True), # => co-25: concordant pass 3
PairedCase(case_id="case-04", base_pass=True, adapted_pass=True), # => co-25: concordant pass 4
PairedCase(case_id="case-05", base_pass=True, adapted_pass=True), # => co-25: concordant pass 5
PairedCase(case_id="case-06", base_pass=True, adapted_pass=True), # => co-25: concordant pass 6
PairedCase(case_id="case-07", base_pass=True, adapted_pass=True), # => co-25: concordant pass 7
PairedCase(case_id="case-08", base_pass=True, adapted_pass=True), # => co-25: concordant pass 8
PairedCase(case_id="case-09", base_pass=True, adapted_pass=True), # => co-25: concordant pass 9
PairedCase(case_id="case-10", base_pass=True, adapted_pass=True), # => co-25: concordant pass 10
PairedCase(case_id="case-11", base_pass=True, adapted_pass=True), # => co-25: concordant pass 11
PairedCase(case_id="case-12", base_pass=True, adapted_pass=True), # => co-25: concordant pass 12
PairedCase(case_id="case-13", base_pass=False, adapted_pass=True), # => co-25: discordant -- adapting fixed this case, 1 of 2
PairedCase(case_id="case-14", base_pass=False, adapted_pass=True), # => co-25: discordant -- adapting fixed this case, 2 of 2
PairedCase(case_id="case-15", base_pass=True, adapted_pass=False), # => co-25: discordant -- adapting broke this case, 1 of 2
PairedCase(case_id="case-16", base_pass=True, adapted_pass=False), # => co-25: discordant -- adapting broke this case, 2 of 2
PairedCase(case_id="case-17", base_pass=False, adapted_pass=False), # => co-25: concordant fail 1
PairedCase(case_id="case-18", base_pass=False, adapted_pass=False), # => co-25: concordant fail 2
PairedCase(case_id="case-19", base_pass=False, adapted_pass=False), # => co-25: concordant fail 3
PairedCase(case_id="case-20", base_pass=False, adapted_pass=False), # => co-25: concordant fail 4
] # => co-25: closes PAIRED_RESULTS -- 20 cases, 2 fixed and 2 broken, net zero
def discordant_counts(cases: list[PairedCase]) -> tuple[int, int]: # => co-25: (b, c) -- fixed count and broken count
"""Return (b, c): the count of base-fail/adapted-pass pairs and base-pass/adapted-fail pairs in `cases`.""" # => co-25: documents discordant_counts's contract -- no runtime output, just sets its __doc__
b = sum(1 for c in cases if not c.base_pass and c.adapted_pass) # => co-25: cases adapting fixed
c = sum(1 for c in cases if c.base_pass and not c.adapted_pass) # => co-25: cases adapting broke
return b, c # => co-25: returns this computed value to the caller
if __name__ == "__main__": # => co-25: entry point -- runs only when this file executes directly, not on import
base_pass_rate = sum(1 for c in PAIRED_RESULTS if c.base_pass) / len(PAIRED_RESULTS) # => co-25: naive base pass rate
adapted_pass_rate = sum(1 for c in PAIRED_RESULTS if c.adapted_pass) / len(PAIRED_RESULTS) # => co-25: naive adapted pass rate
print(f"Base pass rate: {base_pass_rate:.0%} | Adapted pass rate: {adapted_pass_rate:.0%}") # => co-25: the two headline numbers LOOK identical
assert base_pass_rate == adapted_pass_rate, "this scenario's whole point is that the naive pass rates land EXACTLY equal" # => co-25
b, c = discordant_counts(PAIRED_RESULTS) # => co-25: the paired evidence behind that equal-looking headline number
print(f"Discordant pairs: adapting fixed {b} cases, adapting broke {c} cases") # => co-25
assert (b, c) == (2, 2), "two fixed and two broken must exactly offset in this scenario" # => co-25
weeks_of_data_work_spent = 3 # => co-08: the total-cost-of-a-fine-tune line item this run actually consumed
print(f"Weeks of data work spent: {weeks_of_data_work_spent} | Net paired improvement: {b - c} cases") # => co-08,co-25
beats_base = b > c # => co-25: the honest verdict -- did adapting actually help, net, on the paired evidence
print(f"Adapted model beats the base (paired evidence): {beats_base}") # => co-25
assert not beats_base, "a fine-tune with equal fixed and broken counts must NOT be judged to beat the base" # => co-25
print("MATCH: three weeks of data work produced a model that neither beats nor clearly loses to the base -- the correct decision is to discard it, not ship it") # => co-25,co-32
# => co-25,co-32: co-32's discipline starts here -- discarding a completed, working, but non-beating adaptation is a normal and correct outcomeRun: python3 fine_tune_that_did_not_help.py
Output:
Base pass rate: 70% | Adapted pass rate: 70%
Discordant pairs: adapting fixed 2 cases, adapting broke 2 cases
Weeks of data work spent: 3 | Net paired improvement: 0 cases
Adapted model beats the base (paired evidence): False
MATCH: three weeks of data work produced a model that neither beats nor clearly loses to the base -- the correct decision is to discard it, not ship itVerify: discordant_counts(PAIRED_RESULTS) is (2, 2), a net paired improvement of 0 despite
identical 70% naive pass rates, satisfying co-25's rule that equal headline numbers can still hide
a genuinely net-zero paired result.
Key takeaway: three weeks of real data work produced a model with identical naive pass rates to the base -- the paired evidence shows this was never actually an improvement, just a wash.
Why It Matters: this is where co-32's discipline begins: discarding a completed, working, but non-beating adaptation is a normal and correct outcome of this course's evaluation discipline, not a failure of the process that produced it. A team without this discipline might ship a net-zero adaptation anyway, mistaking "it finished training" for "it is worth deploying."
Worked Example 42: Distil a Smaller Student
ex-42 · exercises co-27
Context: co-27 -- distillation trains a small student to approach a large teacher's
behaviour. This example benchmarks a 7-billion-parameter teacher against a 494-million-parameter
student, measuring the real size, latency, and pass-rate trade all at once.
# learning/code/ex-42-distil-a-smaller-student/distil_smaller_student.py
"""Worked Example 42: Distil a Smaller Student.""" # => co-27: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-27: a small, self-documenting record for teacher and student -- latency and cost, side by side
@dataclass(frozen=True) # => co-27: frozen -- a model's measured profile is a fact once benchmarked, not a mutable running total
class ModelProfile: # => co-27: a model's own cost/latency/quality shape, whether teacher or student
name: str # => co-27: which model this profile describes
parameter_count: int # => co-27: total parameters -- the thing distillation is trying to shrink
pass_rate: float # => co-27: measured pass rate on Vantage's triage task
latency_ms: float # => co-27: measured per-request latency, the thing distillation is trying to buy
TEACHER = ModelProfile(name="large-general-model", parameter_count=7_000_000_000, pass_rate=0.97, latency_ms=850.0) # => co-27: a large, capable, SLOW model
STUDENT = ModelProfile(name="distilled-small-model", parameter_count=494_000_000, pass_rate=0.93, latency_ms=95.0) # => co-27: trained to reproduce the teacher's triage outputs
if __name__ == "__main__": # => co-27: entry point -- runs only when this file executes directly, not on import
print(f"Teacher: {TEACHER.name} | {TEACHER.parameter_count:,} params | pass rate {TEACHER.pass_rate:.0%} | latency {TEACHER.latency_ms:.0f}ms") # => co-27
print(f"Student: {STUDENT.name} | {STUDENT.parameter_count:,} params | pass rate {STUDENT.pass_rate:.0%} | latency {STUDENT.latency_ms:.0f}ms") # => co-27
size_reduction = 1 - (STUDENT.parameter_count / TEACHER.parameter_count) # => co-27: how much smaller the student is
latency_reduction = 1 - (STUDENT.latency_ms / TEACHER.latency_ms) # => co-27: how much faster the student is
pass_rate_cost = TEACHER.pass_rate - STUDENT.pass_rate # => co-28: the quality the student gave up to get there
print(f"Size reduction: {size_reduction:.0%} | Latency reduction: {latency_reduction:.0%} | Pass-rate cost: {pass_rate_cost:.0%}") # => co-27,co-28
assert size_reduction > 0.85, "the student must be dramatically smaller than the teacher for distillation to be worth doing at all" # => co-27
assert latency_reduction > 0.80, "the student must be dramatically faster, since latency is the entire point of distilling here" # => co-27
assert pass_rate_cost > 0, "the student must give up SOME quality relative to the teacher -- distillation is never free" # => co-28
print(f"MATCH: a {size_reduction:.0%} parameter reduction and {latency_reduction:.0%} latency reduction cost {pass_rate_cost:.0%} pass-rate points -- exactly the trade distillation is meant to buy") # => co-27,co-28
# => co-27,co-28: this is a latency and cost optimization, not a quality technique -- the student is never expected to match the teacher, only approach itRun: python3 distil_smaller_student.py
Output:
Teacher: large-general-model | 7,000,000,000 params | pass rate 97% | latency 850ms
Student: distilled-small-model | 494,000,000 params | pass rate 93% | latency 95ms
Size reduction: 93% | Latency reduction: 89% | Pass-rate cost: 4%
MATCH: a 93% parameter reduction and 89% latency reduction cost 4% pass-rate points -- exactly the trade distillation is meant to buyVerify: size_reduction is 93% and latency_reduction is 89% for a pass_rate_cost of only
4%, satisfying co-27's rule that distillation buys dramatic size and latency reduction at a real,
non-zero quality cost.
Key takeaway: a 93% parameter reduction and 89% latency reduction cost only 4 pass-rate
points -- a real trade, in both directions, not a free win.
Why It Matters: this is a latency and cost optimization, never a quality technique -- the student is never expected
to match the teacher, only approach it, as Example 43 shows explicitly next. A
494-million-parameter student that merely approaches a 7-billion-parameter teacher is still a
large win in latency and hosting cost, even without matching quality.
Worked Example 43: Student Cannot Exceed Teacher
ex-43 · exercises co-28, co-27
Context: co-28 -- the distillation ceiling states a student can never exceed its teacher. This example pushes the student with more data and more epochs across three attempts, closing the gap to the teacher without ever crossing it. This is co-27 -- distillation's own hard limit made concrete: more training narrows the gap, but the teacher's own ceiling is the one thing more training can never cross.
# learning/code/ex-43-student-cannot-exceed-teacher/student_cannot_exceed_teacher.py
"""Worked Example 43: Student Cannot Exceed Teacher.""" # => co-28: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-28: one immutable row per training configuration tried on the student, all on the SAME held-out eval
class StudentTrainingRun(NamedTuple): # => co-27: a distillation attempt -- more data or more epochs, still bounded by the same teacher
configuration: str # => co-27: what was changed about this student training run
training_examples: int # => co-27: how many teacher-labeled examples the student trained on
pass_rate: float # => co-28: measured pass rate on the SAME held-out eval the teacher was measured on
TEACHER_PASS_RATE = 0.97 # => co-28: the teacher's own measured ceiling on this eval, from ex-42's lineage -- fixed, not something the student can move
# => co-28: three attempts to push the student closer to the teacher -- more data, more epochs, and both together
STUDENT_ATTEMPTS: list[StudentTrainingRun] = [ # => co-28: one row per attempt, in the order they were tried
StudentTrainingRun(configuration="baseline (2,000 examples, 2 epochs)", training_examples=2_000, pass_rate=0.93), # => co-28: the original ex-42 run
StudentTrainingRun(configuration="more data (8,000 examples, 2 epochs)", training_examples=8_000, pass_rate=0.95), # => co-28: 4x the teacher-labeled data
StudentTrainingRun(configuration="more epochs (8,000 examples, 6 epochs)", training_examples=8_000, pass_rate=0.96), # => co-28: 4x the data AND 3x the epochs
] # => co-28: closes STUDENT_ATTEMPTS -- the best attempt still falls short of the teacher
if __name__ == "__main__": # => co-28: entry point -- runs only when this file executes directly, not on import
print(f"Teacher pass rate: {TEACHER_PASS_RATE:.0%}") # => co-28
for attempt in STUDENT_ATTEMPTS: # => co-28: show every attempt's result, in order, against the FIXED teacher ceiling
gap_to_teacher = TEACHER_PASS_RATE - attempt.pass_rate # => co-28: how far this attempt still is from the teacher
print(f" {attempt.configuration}: pass rate {attempt.pass_rate:.0%} (gap to teacher: {gap_to_teacher:.0%})") # => co-28
for attempt in STUDENT_ATTEMPTS: # => co-28: verify EVERY attempt, not just the last, stayed strictly below the teacher's ceiling
assert attempt.pass_rate < TEACHER_PASS_RATE, f"{attempt.configuration} must not exceed the teacher's own pass rate" # => co-28
best_attempt = max(STUDENT_ATTEMPTS, key=lambda a: a.pass_rate) # => co-28: the best of the three attempts
print(f"Best attempt: {best_attempt.configuration} at {best_attempt.pass_rate:.0%}, still {TEACHER_PASS_RATE - best_attempt.pass_rate:.0%} below the teacher") # => co-28
improving_but_bounded = STUDENT_ATTEMPTS[0].pass_rate < STUDENT_ATTEMPTS[1].pass_rate < STUDENT_ATTEMPTS[2].pass_rate # => co-28: more effort DOES help, but never crosses the line
assert improving_but_bounded, "each additional round of student training effort must genuinely improve the result, just never past the teacher" # => co-28
print("MATCH: 4x the data and 3x the epochs closed the gap from 4 points to 1 point -- and never crossed it, because the student cannot exceed its teacher") # => co-28
# => co-28: more compute spent on the student narrows the gap, it never erases it -- the teacher's own ceiling is the student's hard boundRun: python3 student_cannot_exceed_teacher.py
Output:
Teacher pass rate: 97%
baseline (2,000 examples, 2 epochs): pass rate 93% (gap to teacher: 4%)
more data (8,000 examples, 2 epochs): pass rate 95% (gap to teacher: 2%)
more epochs (8,000 examples, 6 epochs): pass rate 96% (gap to teacher: 1%)
Best attempt: more epochs (8,000 examples, 6 epochs) at 96%, still 1% below the teacher
MATCH: 4x the data and 3x the epochs closed the gap from 4 points to 1 point -- and never crossed it, because the student cannot exceed its teacherVerify: all three STUDENT_ATTEMPTS stay strictly below TEACHER_PASS_RATE at 97%, narrowing
from a 4-point gap to a 1-point gap, satisfying co-28's rule that more student training effort
narrows the gap to the teacher but never crosses it.
Key takeaway: 4x the data and 3x the epochs closed the gap from four points to one point --
and never crossed it, because the teacher's own ceiling is a hard bound on the student.
Why It Matters: this hard bound assumes the teacher's own ceiling is honestly known. Example 71 later shows that assumption can itself be wrong -- the teacher's ceiling must be measured, not merely quoted from a different eval. A team that forgets this bound might keep pushing a student's training, expecting quality the teacher itself was never able to supply.
Worked Example 44: Distillation Decision Record
ex-44 · exercises co-28, co-08
Context: continuing co-28 -- this example writes Vantage's actual distillation decision record, framing the student explicitly as a cost optimization: cheaper, faster, and honestly accepted as lower quality, never sold as a free win.
# learning/code/ex-44-distillation-decision-record/distillation_decision_record.py
"""Worked Example 44: Distillation Decision Record.""" # => co-28: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-08: a written record, the same discipline ex-13's total-cost accounting and ex-57's decision record used
@dataclass(frozen=True) # => co-08: frozen -- a decision record is a fact once written, not a mutable running total
class DistillationDecisionRecord: # => co-28: a distillation decision framed explicitly as a COST trade, never a quality claim
teacher_pass_rate: float # => co-28: the teacher's own measured ceiling, quoted plainly, not exceeded
student_pass_rate: float # => co-28: the student's measured result -- BELOW the teacher, by design and by necessity
monthly_inference_cost_teacher_usd: float # => co-08: what serving the teacher at Vantage's traffic volume costs per month
monthly_inference_cost_student_usd: float # => co-08: what serving the student instead costs per month
quality_cost_accepted: bool # => co-28: an explicit, written acknowledgement that quality is being traded away, not hidden
RECORD = DistillationDecisionRecord( # => co-28: Vantage's actual distillation decision, written down before shipping the student
teacher_pass_rate=0.97, # => co-28: matches ex-42/ex-43's teacher ceiling
student_pass_rate=0.93, # => co-28: matches ex-42's baseline student result
monthly_inference_cost_teacher_usd=14_200.00, # => co-08: the large teacher model's serving bill at current traffic
monthly_inference_cost_student_usd=1_650.00, # => co-08: the distilled student's serving bill at the SAME traffic
quality_cost_accepted=True, # => co-28: signed off explicitly -- the 4-point quality cost is accepted, not glossed over
) # => co-28: closes RECORD
def is_honestly_framed(record: DistillationDecisionRecord) -> bool: # => co-28: a distillation record must NEVER claim a quality win
"""Return whether `record` correctly frames its student as strictly cheaper and never claims it as strictly better on quality.""" # => co-28: documents is_honestly_framed's contract -- no runtime output, just sets its __doc__
cheaper = record.monthly_inference_cost_student_usd < record.monthly_inference_cost_teacher_usd # => co-08: the student must actually be cheaper
not_better_on_quality = record.student_pass_rate <= record.teacher_pass_rate # => co-28: the student must NEVER be claimed to exceed the teacher
return cheaper and not_better_on_quality and record.quality_cost_accepted # => co-28: all three must hold for a record to be honestly framed
if __name__ == "__main__": # => co-28: entry point -- runs only when this file executes directly, not on import
monthly_savings = RECORD.monthly_inference_cost_teacher_usd - RECORD.monthly_inference_cost_student_usd # => co-08: the cost side of the trade
quality_cost = RECORD.teacher_pass_rate - RECORD.student_pass_rate # => co-28: the quality side of the trade
print(f"Monthly savings: ${monthly_savings:,.2f} | Quality cost: {quality_cost:.0%} pass-rate points") # => co-08,co-28
assert monthly_savings > 10_000, "the cost savings must be large and concrete, the actual reason distillation was chosen" # => co-08
assert quality_cost > 0, "the record must show a real, non-zero quality cost -- pretending distillation is free is dishonest" # => co-28
honestly_framed = is_honestly_framed(RECORD) # => co-28: run the framing check
print(f"Record is honestly framed as a cost optimization: {honestly_framed}") # => co-28
assert honestly_framed, "this record must pass the honest-framing check -- cheaper and accepted-as-lower-quality, never claimed as better" # => co-28
print(f"MATCH: ${monthly_savings:,.0f}/month saved for {quality_cost:.0%} accepted quality cost -- written down as a trade, not sold as a free win") # => co-08,co-28
# => co-08,co-28: this is the written artefact the tension note demands -- distillation buys latency and cost, and this record says so explicitlyRun: python3 distillation_decision_record.py
Output:
Monthly savings: $12,550.00 | Quality cost: 4% pass-rate points
Record is honestly framed as a cost optimization: True
MATCH: $12,550/month saved for 4% accepted quality cost -- written down as a trade, not sold as a free winVerify: is_honestly_framed(RECORD) is True because the student is strictly cheaper, never
claimed to beat the teacher on quality, and the quality cost is explicitly quality_cost_accepted,
satisfying co-28's rule that a distillation record must never claim a quality win.
Key takeaway: $12,550 in monthly savings for an accepted 4-point quality cost is the whole
decision, written down as a trade rather than sold as a free win.
Why It Matters: this written record is the artefact this course's tension note demands -- distillation buys latency and cost, and stating that plainly, in writing, is what keeps a future reviewer from mistaking a cost optimization for a capability upgrade. A verbal claim of "good enough" fades from memory long before the written record does, which is exactly why co-28 demands one.
Worked Example 45: Serve an Adapter
ex-45 · exercises co-29, co-21
Context: co-29 -- serving adapters and co-21 -- composable artefacts meet here: a small adapter attaches to a loaded base and serves adapted behaviour, while a mismatched-base adapter is rejected at load time, never silently at inference time.
# learning/code/ex-45-serve-an-adapter/serve_an_adapter.py
"""Worked Example 45: Serve an Adapter.""" # => co-29: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass, field # => co-21: an adapter is a small, composable artefact -- this class models exactly that shape
@dataclass(frozen=True) # => co-21: frozen -- a served adapter's identity is fixed once loaded, matching the artefact it was built from
class Adapter: # => co-21: a small, versionable artefact -- NOT a whole new model
name: str # => co-21: which adapter this is
base_model_id: str # => co-30: which base model this adapter was trained against -- see ex-48 for what happens when this drifts
weights_mb: float # => co-21: the adapter's own on-disk size -- small, unlike a full fine-tuned checkpoint
@dataclass # => co-29: a mock serving stack -- ONE base model in memory, adapters attached and swapped on top of it
class MockServer: # => co-29: stands in for the real serving stack this course's prerequisite topic covers in depth
base_model_id: str # => co-29: the single loaded base model this server holds in memory
loaded_adapters: dict[str, Adapter] = field(default_factory=dict[str, Adapter]) # => co-21: adapters currently attached, keyed by name -- small enough to hold several at once
def load_adapter(self, adapter: Adapter) -> None: # => co-29: attach an adapter to the currently loaded base
"""Attach `adapter` to this server, raising if its `base_model_id` does not match the loaded base.""" # => co-29: documents load_adapter's contract -- no runtime output, just sets its __doc__
if adapter.base_model_id != self.base_model_id: # => co-30: an adapter trained against one base cannot simply be attached to another
raise ValueError(f"adapter {adapter.name!r} was trained against {adapter.base_model_id!r}, not the loaded base {self.base_model_id!r}") # => co-30
self.loaded_adapters[adapter.name] = adapter # => co-21: attach it -- cheap, because the adapter is small
def serve(self, adapter_name: str, prompt: str) -> str: # => co-29: route a request through the base PLUS the named adapter
"""Return a mocked response to `prompt`, shaped by the adapter named `adapter_name`.""" # => co-29: documents serve's contract -- no runtime output, just sets its __doc__
if adapter_name not in self.loaded_adapters: # => co-29: the adapter must be loaded before it can serve traffic
raise KeyError(f"adapter {adapter_name!r} is not loaded on this server") # => co-29
return f"[{adapter_name}] {prompt} -> Priority: P2. Category: access." # => co-29: a mocked, adapter-shaped response, standing in for a real generation call
TRIAGE_ADAPTER = Adapter(name="triage-v1", base_model_id="qwen2.5-0.5b-instruct", weights_mb=2.3) # => co-21: matches ex-29's own trained adapter, roughly
if __name__ == "__main__": # => co-29: entry point -- runs only when this file executes directly, not on import
server = MockServer(base_model_id="qwen2.5-0.5b-instruct") # => co-29: ONE base model loaded, matching TRIAGE_ADAPTER's own base
server.load_adapter(TRIAGE_ADAPTER) # => co-29: attach the adapter -- cheap, since it is only 2.3MB
print(f"Loaded adapters: {list(server.loaded_adapters)}") # => co-29
response = server.serve("triage-v1", "Customer cannot log in after a password reset.") # => co-29: serve one request through the adapted behaviour
print(f"Response: {response}") # => co-29
assert "triage-v1" in server.loaded_adapters, "the adapter must be present in the server's loaded set after load_adapter" # => co-29
assert response.startswith("[triage-v1]"), "the served response must be routed through the named adapter, not the bare base" # => co-29
mismatched_adapter = Adapter(name="wrong-base-adapter", base_model_id="a-different-base", weights_mb=2.1) # => co-30: an adapter trained against a DIFFERENT base
try: # => co-30: attempting to attach a mismatched adapter must be rejected, not silently allowed
server.load_adapter(mismatched_adapter) # => co-30
raised = False # => co-30
except ValueError: # => co-30: this is the expected, correct outcome
raised = True # => co-30
assert raised, "loading an adapter trained against a different base must raise, never silently attach" # => co-30
print("MATCH: the adapter loads onto its matching base and serves adapted behaviour; a mismatched-base adapter is rejected at load time, not at inference time") # => co-29,co-30
# => co-29,co-30: this is the operational shape co-29 describes -- the base stays loaded once, and adapters attach to and detach from it cheaplyRun: python3 serve_an_adapter.py
Output:
Loaded adapters: ['triage-v1']
Response: [triage-v1] Customer cannot log in after a password reset. -> Priority: P2. Category: access.
MATCH: the adapter loads onto its matching base and serves adapted behaviour; a mismatched-base adapter is rejected at load time, not at inference timeVerify: server.serve routes correctly through "triage-v1", while load_adapter raises
ValueError for a mismatched-base adapter, satisfying co-29's rule that a base mismatch is rejected
at load time, never silently at inference time.
Key takeaway: a small adapter attaches to a loaded base and serves adapted behaviour cheaply -- and a base mismatch is caught the moment it is loaded, not discovered later in production.
Why It Matters: Example 46 immediately builds on this shape to hot-swap between two adapters on the SAME loaded base -- the operational advantage a full fine-tune's own separate checkpoints could never offer this cheaply. Rejecting a mismatched adapter at load time, rather than letting it silently misbehave at inference, is what keeps a serving mistake from ever reaching a real user.
Worked Example 46: Hot-Swap Adapters
ex-46 · exercises co-21, co-29
Context: continuing co-21 -- two distinct behaviours are served from one shared base, switched between requests with no base reload, exactly the operational advantage this course's tension note names against a full fine-tune.
# learning/code/ex-46-hot-swap-adapters/hot_swap_adapters.py
"""Worked Example 46: Hot-Swap Adapters.""" # => co-21: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass, field # => co-21: two adapters, one base, swapped on demand -- the operational win over full fine-tuning
@dataclass(frozen=True) # => co-21: frozen -- an adapter's identity is fixed once trained
class Adapter: # => co-21: a small, composable artefact, attachable to and detachable from a shared base
name: str # => co-21: which adapter this is
style: str # => co-21: the behaviour this adapter shapes, for this file's illustration
@dataclass # => co-29: a mock server holding ONE base and MULTIPLE adapters, switching between them per request
class MockServer: # => co-29: stands in for the real serving stack this course's prerequisite topic covers in depth
base_model_id: str # => co-29: the single loaded base model, shared by every attached adapter
loaded_adapters: dict[str, Adapter] = field(default_factory=dict[str, Adapter]) # => co-21: every adapter currently attached, keyed by name
active_adapter_name: str | None = None # => co-21: which adapter is currently routing requests -- switched WITHOUT reloading the base
def load_adapter(self, adapter: Adapter) -> None: # => co-21: attach an adapter, cheap because it is small
"""Attach `adapter` to this server's loaded set.""" # => co-21: documents load_adapter's contract -- no runtime output, just sets its __doc__
self.loaded_adapters[adapter.name] = adapter # => co-21: attach it to the shared base
def switch_to(self, adapter_name: str) -> None: # => co-21: the hot-swap itself -- change which adapter is active, base untouched
"""Set `active_adapter_name` to `adapter_name`, raising if it is not loaded.""" # => co-21: documents switch_to's contract -- no runtime output, just sets its __doc__
if adapter_name not in self.loaded_adapters: # => co-21: cannot switch to an adapter that was never loaded
raise KeyError(f"adapter {adapter_name!r} is not loaded") # => co-21
self.active_adapter_name = adapter_name # => co-21: the swap -- no base reload, no downtime
def serve(self, prompt: str) -> str: # => co-29: route a request through the CURRENTLY active adapter
"""Return a mocked response to `prompt`, shaped by whichever adapter is currently active.""" # => co-29: documents serve's contract -- no runtime output, just sets its __doc__
if self.active_adapter_name is None: # => co-29: no adapter active means nothing can be served
raise RuntimeError("no adapter is active") # => co-29
active = self.loaded_adapters[self.active_adapter_name] # => co-21: the currently active adapter's own record
return f"[{active.name}, style={active.style}] {prompt}" # => co-29: a mocked response shaped by the active adapter's style
BILLING_TONE_ADAPTER = Adapter(name="billing-tone-v1", style="formal, apologetic") # => co-21: shapes responses for sensitive billing conversations
ESCALATION_TONE_ADAPTER = Adapter(name="escalation-tone-v1", style="urgent, directive") # => co-21: shapes responses for P1 escalations
if __name__ == "__main__": # => co-21: entry point -- runs only when this file executes directly, not on import
server = MockServer(base_model_id="qwen2.5-0.5b-instruct") # => co-29: ONE base, loaded once
server.load_adapter(BILLING_TONE_ADAPTER) # => co-21: attach the first adapter
server.load_adapter(ESCALATION_TONE_ADAPTER) # => co-21: attach the second adapter -- same base, no second base load
server.switch_to("billing-tone-v1") # => co-21: activate the billing-tone behaviour
billing_response = server.serve("Customer was double-charged this month.") # => co-29: served with billing tone
print(f"Billing response: {billing_response}") # => co-29
server.switch_to("escalation-tone-v1") # => co-21: hot-swap to the OTHER adapter -- no base reload between requests
escalation_response = server.serve("Production outage affecting all customers.") # => co-29: served with escalation tone
print(f"Escalation response: {escalation_response}") # => co-29
assert "billing-tone-v1" in billing_response, "the first request must be served through the billing-tone adapter" # => co-21
assert "escalation-tone-v1" in escalation_response, "the second request must be served through the escalation-tone adapter, after the swap" # => co-21
assert server.base_model_id == "qwen2.5-0.5b-instruct", "the base model identity must be UNCHANGED across the swap -- only the active adapter moved" # => co-29
print("MATCH: two distinct behaviours served from one base model, switched between requests with no base reload -- the swap the tension note calls the operational advantage") # => co-21,co-29
# => co-21,co-29: a full fine-tune would need TWO whole loaded models for this -- adapters make it one base plus two small, swappable artefactsRun: python3 hot_swap_adapters.py
Output:
Billing response: [billing-tone-v1, style=formal, apologetic] Customer was double-charged this month.
Escalation response: [escalation-tone-v1, style=urgent, directive] Production outage affecting all customers.
MATCH: two distinct behaviours served from one base model, switched between requests with no base reload -- the swap the tension note calls the operational advantage%% Color Palette: Blue #0173B2, Orange #DE8F05, Teal #029E73, Purple #CC78BC
%% All colors are color-blind friendly and meet WCAG AA contrast standards
stateDiagram-v2
[*] --> Unloaded
Unloaded --> Rejected: base mismatch, ex-45
Unloaded --> Loaded: load succeeds, ex-45
Loaded --> Registered: added to registry, ex-72
Registered --> Active: resolved by task name
Active --> Standby: swap to other adapter, ex-46
Standby --> Active: swap back, ex-73
Active --> Retired: retired, co-32
Retired --> [*]
classDef blue fill:#0173B2,stroke:#000000,color:#FFFFFF,stroke-width:2px
classDef orange fill:#DE8F05,stroke:#000000,color:#FFFFFF,stroke-width:2px
classDef teal fill:#029E73,stroke:#000000,color:#FFFFFF,stroke-width:2px
classDef purple fill:#CC78BC,stroke:#000000,color:#FFFFFF,stroke-width:2px
class Unloaded blue
class Loaded blue
class Rejected purple
class Registered orange
class Active teal
class Standby orange
class Retired purple
Figure: an adapter's serving lifecycle across Examples 45-47 and 72-73. A mismatched base is rejected at load time (Example 45), never silently at inference time; once loaded and registered (Example 72), an adapter cycles between active and standby with no base reload (Example 46), a swap proven to hold under repeated load (Example 73), until it is retired (co-32).
Verify: server.base_model_id stays "qwen2.5-0.5b-instruct" across both requests while
active_adapter_name switches, satisfying co-21's rule that a hot-swap changes only the active
adapter, never the loaded base.
Key takeaway: two distinct behaviours were served from one base model, switched between requests with no base reload -- a full fine-tune would need two entirely separate loaded models for this same result.
Why It Matters: Example 47 prices this exact advantage across five task variants, and Example 73 load-tests it under sustained, repeated swaps -- proving this single demonstration generalizes to a real operational claim, not just a one-off trick. A full fine-tune's separate checkpoints would each need their own reload, paying the base-model loading cost every single time a task changes.
Worked Example 47: Adapter Memory and Routing
ex-47 · exercises co-29, co-21
Context: continuing co-29 -- this example prices Example 46's advantage across five task
variants: serving them as five separate full fine-tuned models costs 4,900 megabytes, while one
shared base plus five small adapters costs under 1,000.
# learning/code/ex-47-adapter-memory-and-routing/adapter_memory_and_routing.py
"""Worked Example 47: Adapter Memory and Routing.""" # => co-29: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-21: a small, self-documenting record for the serving-side memory math
@dataclass(frozen=True) # => co-21: frozen -- these are measured, fixed facts about a deployment shape, not a running total
class ServingProfile: # => co-29: how much memory it costs to serve N variants of a task, two different ways
strategy: str # => co-29: "N full fine-tuned models" or "1 base + N adapters"
base_models_loaded: int # => co-29: how many full base-model copies must be resident in memory
adapters_loaded: int # => co-21: how many small adapters must be resident in memory
base_model_size_mb: float # => co-29: one base model's own memory footprint
adapter_size_mb: float # => co-21: one adapter's own memory footprint -- small, by construction
def total_memory_mb(profile: ServingProfile) -> float: # => co-29: the serving-side memory cost of this strategy
"""Return the total memory in MB required by `profile`'s loaded base models and adapters.""" # => co-29: documents total_memory_mb's contract -- no runtime output, just sets its __doc__
return (profile.base_models_loaded * profile.base_model_size_mb) + (profile.adapters_loaded * profile.adapter_size_mb) # => co-29: returns this computed value to the caller
FIVE_FULL_MODELS = ServingProfile( # => co-29: serving 5 task variants by loading 5 SEPARATE full fine-tuned models
strategy="5 full fine-tuned models", # => co-17: each one a complete, independently fine-tuned copy of the base
base_models_loaded=5, # => co-29: every variant needs its own full base-model copy in memory
adapters_loaded=0, # => co-29
base_model_size_mb=980.0, # => co-29: matches ex-28's own measured checkpoint size, roughly
adapter_size_mb=0.0, # => co-29
) # => co-29: closes FIVE_FULL_MODELS
ONE_BASE_FIVE_ADAPTERS = ServingProfile( # => co-21: serving the SAME 5 task variants with one shared base plus 5 small adapters
strategy="1 base + 5 adapters", # => co-21: exactly the operational shape ex-45/ex-46 demonstrated
base_models_loaded=1, # => co-29: the base is loaded ONCE, shared by every adapter
adapters_loaded=5, # => co-21: each variant is a small adapter attached to the SAME loaded base
base_model_size_mb=980.0, # => co-29: the same base-model size as above, loaded a single time
adapter_size_mb=2.3, # => co-21: matches ex-45's own TRIAGE_ADAPTER size
) # => co-21: closes ONE_BASE_FIVE_ADAPTERS
if __name__ == "__main__": # => co-29: entry point -- runs only when this file executes directly, not on import
for profile in (FIVE_FULL_MODELS, ONE_BASE_FIVE_ADAPTERS): # => co-29: compare both serving strategies for the SAME 5 task variants
memory = total_memory_mb(profile) # => co-29: this strategy's total memory cost
print(f" {profile.strategy}: {memory:,.1f} MB ({profile.base_models_loaded} base(s) + {profile.adapters_loaded} adapter(s))") # => co-29
full_models_memory = total_memory_mb(FIVE_FULL_MODELS) # => co-29: the five-full-models total
adapters_memory = total_memory_mb(ONE_BASE_FIVE_ADAPTERS) # => co-21: the one-base-plus-adapters total
memory_reduction = 1 - (adapters_memory / full_models_memory) # => co-21: how much memory the adapter strategy saves
print(f"Adapter strategy uses {memory_reduction:.0%} less memory to serve the same 5 task variants") # => co-21,co-29
assert full_models_memory == 4_900.0, "five full fine-tuned models must cost exactly 4,900 MB in this scenario" # => co-29
assert adapters_memory == 991.5, "one base plus five adapters must cost exactly 991.5 MB in this scenario" # => co-21
assert memory_reduction > 0.75, "the adapter strategy must use dramatically less memory to serve the same variant count" # => co-21,co-29
print("MATCH: serving 5 task variants costs 4,900 MB as separate full models but under 1,000 MB as one shared base plus 5 small adapters") # => co-21,co-29
# => co-21,co-29: this is the concrete number behind co-21's operational-advantage claim -- adapters make MANY variants affordable to keep resident at onceRun: python3 adapter_memory_and_routing.py
Output:
5 full fine-tuned models: 4,900.0 MB (5 base(s) + 0 adapter(s))
1 base + 5 adapters: 991.5 MB (1 base(s) + 5 adapter(s))
Adapter strategy uses 80% less memory to serve the same 5 task variants
MATCH: serving 5 task variants costs 4,900 MB as separate full models but under 1,000 MB as one shared base plus 5 small adaptersVerify: total_memory_mb(FIVE_FULL_MODELS) is 4,900.0 MB versus total_memory_mb(ONE_BASE_FIVE_ADAPTERS)
at 991.5 MB, an 80% reduction, satisfying co-21's rule that adapters make many task variants
affordable to keep resident at once.
Key takeaway: serving five task variants costs 4,900 megabytes as separate full models but
under 1,000 megabytes as one shared base plus five small adapters -- an 80% memory reduction for
the identical set of behaviours.
Why It Matters: this is the concrete number behind co-21's operational-advantage claim -- it is what makes serving
many task-specific behaviours from one deployment economically realistic, not just a possibility.
The difference between 4,900 and under 1,000 megabytes is the difference between a deployment
that can afford dozens of task-specific behaviours and one that cannot.
Worked Example 48: Version-Pinning to a Base
ex-48 · exercises co-30, co-21
Context: co-30 -- the maintenance obligation, applied at the serving layer: this example checks Example 14's own adapter against a base-model upgrade and shows the same adapter correctly flagged incompatible the moment its base moves on. This check is only possible because co-21 -- composable artefacts treats the adapter as a small, versioned artefact pinned to a base, not an opaque blob with no recorded compatibility.
# learning/code/ex-48-version-pinning-to-a-base/version_pinning.py
"""Worked Example 48: Version-Pinning to a Base.""" # => co-30: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-30: a small, self-documenting record for an adapter's explicit base-version pin
@dataclass(frozen=True) # => co-21: frozen -- a pin is a fixed fact about how an adapter was trained, not a mutable running total
class PinnedAdapter: # => co-21: an adapter, EXPLICITLY tied to the exact base version it was trained against
name: str # => co-21: which adapter this is
trained_against_base_version: str # => co-30: the exact base-model version string this adapter's weights assume
def is_compatible_with_base(adapter: PinnedAdapter, currently_deployed_base_version: str) -> bool: # => co-30: does the pin still hold
"""Return whether `adapter`'s pinned base version matches `currently_deployed_base_version`.""" # => co-30: documents is_compatible_with_base's contract -- no runtime output, just sets its __doc__
return adapter.trained_against_base_version == currently_deployed_base_version # => co-30: returns this computed value to the caller
TRIAGE_ADAPTER = PinnedAdapter(name="triage-v1", trained_against_base_version="qwen2.5-0.5b-instruct-r1") # => co-30: pinned to the base version it was actually trained against
if __name__ == "__main__": # => co-30: entry point -- runs only when this file executes directly, not on import
deployed_base_version_before_upgrade = "qwen2.5-0.5b-instruct-r1" # => co-30: matches the adapter's own pin -- the world at training time
compatible_before_upgrade = is_compatible_with_base(TRIAGE_ADAPTER, deployed_base_version_before_upgrade) # => co-30: check compatibility BEFORE any base upgrade
print(f"Before upgrade: base {deployed_base_version_before_upgrade!r}, adapter pinned to {TRIAGE_ADAPTER.trained_against_base_version!r} -> compatible: {compatible_before_upgrade}") # => co-30
assert compatible_before_upgrade, "the adapter must be compatible with the base version it was actually trained against" # => co-30
deployed_base_version_after_upgrade = "qwen2.5-0.5b-instruct-r2" # => co-30: the platform team ships a newer base-model release
compatible_after_upgrade = is_compatible_with_base(TRIAGE_ADAPTER, deployed_base_version_after_upgrade) # => co-30: check the SAME adapter against the NEW base
print(f"After upgrade: base {deployed_base_version_after_upgrade!r}, adapter still pinned to {TRIAGE_ADAPTER.trained_against_base_version!r} -> compatible: {compatible_after_upgrade}") # => co-30
assert not compatible_after_upgrade, "the SAME adapter must be flagged incompatible once the deployed base version moves past its pin" # => co-30
re_adaptation_required = not compatible_after_upgrade # => co-30: the standing maintenance obligation this incompatibility creates
print(f"Re-adaptation required before serving triage-v1 against the new base: {re_adaptation_required}") # => co-08,co-30
assert re_adaptation_required, "an incompatible pin must translate into an explicit re-adaptation requirement, never a silent mismatch" # => co-08,co-30
print("MATCH: the pin correctly flags the SAME adapter as incompatible the moment its base is upgraded -- a recurring cost, not a one-time one") # => co-08,co-30
# => co-08,co-30: this is the maintenance obligation ex-14 introduced, made concrete for the serving layer -- every base upgrade re-opens this checkRun: python3 version_pinning.py
Output:
Before upgrade: base 'qwen2.5-0.5b-instruct-r1', adapter pinned to 'qwen2.5-0.5b-instruct-r1' -> compatible: True
After upgrade: base 'qwen2.5-0.5b-instruct-r2', adapter still pinned to 'qwen2.5-0.5b-instruct-r1' -> compatible: False
Re-adaptation required before serving triage-v1 against the new base: True
MATCH: the pin correctly flags the SAME adapter as incompatible the moment its base is upgraded -- a recurring cost, not a one-time oneVerify: is_compatible_with_base(TRIAGE_ADAPTER, ...) flips from True to False purely from a
base-version string change, satisfying co-30's rule that a base upgrade re-opens the compatibility
check for every existing adapter.
Key takeaway: the SAME adapter, unchanged, becomes incompatible the moment its pinned base is superseded -- confirming Example 14's own maintenance obligation is a recurring, checkable cost.
Why It Matters: this check is what Example 75's maintenance plan later names as a concrete re-adaptation trigger -- a vague "review periodically" would never catch this precisely, but this compatibility check does, every single time a new base ships. An adapter silently serving stale, incompatible behaviour against a newer base is the exact liability co-30's maintenance obligation is written to prevent.
Worked Example 49: Retire an Adapter
ex-49 · exercises co-32, co-04
Context: co-32 -- retiring an adapter is a normal maintenance event, not a failure. This example shows an older pricing-lookup adapter beaten on both quality and cost by Example 4's own retrieval solution, and retires it accordingly.
# learning/code/ex-49-retire-an-adapter/retire_an_adapter.py
"""Worked Example 49: Retire an Adapter.""" # => co-32: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-32: a small, self-documenting record for the retirement decision itself
@dataclass(frozen=True) # => co-32: frozen -- a retirement decision is a fact once measured and made, not a mutable running total
class RetirementCase: # => co-32: an adapter, its replacement candidate, and the evidence deciding between them
adapter_name: str # => co-32: the adapter under consideration for retirement
adapter_pass_rate: float # => co-32: the adapter's own current measured pass rate on its target task
replacement_strategy: str # => co-04: what would replace the adapter -- here, retrieval, echoing ex-04's own lineage
replacement_pass_rate: float # => co-04: the replacement's measured pass rate on the SAME task
replacement_maintenance_cost_usd_per_month: float # => co-08: the replacement's own ongoing cost, for comparison
adapter_maintenance_cost_usd_per_month: float # => co-08,co-30: the adapter's own ongoing cost, including re-adaptation against base upgrades
CASE = RetirementCase( # => co-32: Vantage's own retirement candidate -- a knowledge-lookup adapter, now beatable by retrieval
adapter_name="pricing-lookup-adapter-v3", # => co-32: an OLDER adapter, from back before ex-04's retrieval solution existed
adapter_pass_rate=0.81, # => co-32: its current measured pass rate -- decent, but no longer the best option
replacement_strategy="retrieval over the live pricing document", # => co-04: matches ex-04's own solved approach
replacement_pass_rate=0.99, # => co-04: retrieval's measured pass rate, matching ex-04's own result
replacement_maintenance_cost_usd_per_month=40.0, # => co-08: a document index refresh job, far cheaper than adapter upkeep
adapter_maintenance_cost_usd_per_month=650.0, # => co-08,co-30: periodic re-adaptation against base upgrades, per ex-48's own lineage
) # => co-32: closes CASE
def should_retire(case: RetirementCase) -> bool: # => co-32: retirement is warranted when the replacement wins on BOTH quality and cost
"""Return whether `case`'s replacement strategy both outperforms and costs less to maintain than the current adapter.""" # => co-32: documents should_retire's contract -- no runtime output, just sets its __doc__
better_quality = case.replacement_pass_rate > case.adapter_pass_rate # => co-04: does the replacement beat the adapter on the task
cheaper_to_maintain = case.replacement_maintenance_cost_usd_per_month < case.adapter_maintenance_cost_usd_per_month # => co-08: does the replacement cost less to keep running
return better_quality and cheaper_to_maintain # => co-32: both must hold for a clean, evidenced retirement
if __name__ == "__main__": # => co-32: entry point -- runs only when this file executes directly, not on import
print(f"Adapter: {CASE.adapter_name} | pass rate {CASE.adapter_pass_rate:.0%} | ${CASE.adapter_maintenance_cost_usd_per_month:.0f}/month") # => co-32
print(f"Replacement: {CASE.replacement_strategy} | pass rate {CASE.replacement_pass_rate:.0%} | ${CASE.replacement_maintenance_cost_usd_per_month:.0f}/month") # => co-04
retire = should_retire(CASE) # => co-32: run the retirement decision
print(f"Retirement decision: {'retire the adapter' if retire else 'keep the adapter'}") # => co-32
assert retire, "this scenario's replacement must clear both the quality and cost bar, making retirement the correct decision" # => co-32
pass_rate_gain = CASE.replacement_pass_rate - CASE.adapter_pass_rate # => co-04: the quality improvement from retiring
monthly_savings = CASE.adapter_maintenance_cost_usd_per_month - CASE.replacement_maintenance_cost_usd_per_month # => co-08: the cost improvement from retiring
print(f"Retiring gains {pass_rate_gain:.0%} pass rate and saves ${monthly_savings:.0f}/month") # => co-04,co-08
assert pass_rate_gain > 0 and monthly_savings > 0, "a correctly evidenced retirement must show BOTH a quality gain and a cost saving, not just one" # => co-04,co-08
print("MATCH: an old adapter beaten on both quality and cost by retrieval is retired, planned and evidenced, exactly the healthy outcome co-32 describes") # => co-32,co-04
# => co-32,co-04: this is what ex-49 exists to show -- adapters age against better alternatives too, and retiring one is a normal maintenance event, not a failureRun: python3 retire_an_adapter.py
Output:
Adapter: pricing-lookup-adapter-v3 | pass rate 81% | $650/month
Replacement: retrieval over the live pricing document | pass rate 99% | $40/month
Retirement decision: retire the adapter
Retiring gains 18% pass rate and saves $610/month
MATCH: an old adapter beaten on both quality and cost by retrieval is retired, planned and evidenced, exactly the healthy outcome co-32 describesVerify: should_retire(CASE) is True because the replacement's 99% pass rate beats the
adapter's 81% and its $40/month beats $650/month, satisfying co-32's rule that retirement is
warranted only when a replacement wins on both quality and cost.
Key takeaway: retiring this adapter gains 18 points of pass rate and saves $610 per month --
a clean win on both axes, not a forced trade-off.
Why It Matters: adapters age against better alternatives the same way any other production artefact does. Treating retirement as a planned, evidenced, healthy outcome -- rather than an admission of failure -- is what co-32 asks teams to normalize. An adapter that is never retired because retirement feels like failure just keeps costing serving budget for no accuracy benefit at all.
Worked Example 50: Capstone-Justified Adaptation
ex-50 · exercises co-01–co-32
Context: this example closes the band by citing all sixteen phases of a justified adaptation by name, each one backed by a distinct, specific earlier worked example in this course -- a justified adaptation is a cited arc, never a single retrospective claim.
# learning/code/ex-50-capstone-justified-adaptation/capstone_justified_adaptation.py
"""Worked Example 50: Capstone-Justified Adaptation.""" # => co-06: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-06: one immutable row per arc phase, each citing the earlier example that actually proved it
class ArcPhase(NamedTuple): # => co-06: a single phase of the full justified-adaptation arc, with its own pass/fail evidence
phase: str # => co-06: which phase of the arc this row is
evidenced_by_example: str # => co-06: which earlier worked example in THIS course actually produced this phase's evidence
passed: bool # => co-06: did this phase clear its own bar
# => co-01–co-32: the full arc, phase by phase, each row citing the example that actually measured it -- nothing here is asserted without a source
FULL_ARC: list[ArcPhase] = [ # => co-06: one row per phase, in the order the decision gate and capstone spec both require
ArcPhase(phase="measured gap", evidenced_by_example="ex-01", passed=True), # => co-06,co-25: the gap was real and sized, not assumed
ArcPhase(phase="prompting exhausted", evidenced_by_example="ex-05", passed=True), # => co-03: tried and measured insufficient for THIS gap's remainder
ArcPhase(phase="retrieval exhausted", evidenced_by_example="ex-04", passed=True), # => co-04: tried and measured insufficient for THIS gap's remainder
ArcPhase(phase="scoping exhausted", evidenced_by_example="ex-07", passed=True), # => co-05: tried and measured insufficient for THIS gap's remainder
ArcPhase(phase="decision gate", evidenced_by_example="ex-08", passed=True), # => co-06: the ordered gate, applied and documented
ArcPhase(phase="total cost budgeted", evidenced_by_example="ex-13", passed=True), # => co-08: data, compute, eval, and maintenance all costed up front
ArcPhase(phase="licence and rights checked", evidenced_by_example="ex-15", passed=True), # => co-31: verified BEFORE training, not after
ArcPhase(phase="dataset consistency audited", evidenced_by_example="ex-20", passed=True), # => co-12,co-10: no planted or accidental conflicts survived
ArcPhase(phase="splits disjoint, no leakage", evidenced_by_example="ex-26", passed=True), # => co-15,co-16: verified clean, not assumed clean
ArcPhase(phase="adapter rank justified", evidenced_by_example="ex-31", passed=True), # => co-20: chosen from a sweep, not defaulted
ArcPhase(phase="early stopping on validation", evidenced_by_example="ex-40", passed=True), # => co-23,co-24: stopped on the held-out signal, not the epoch count
ArcPhase(phase="paired evaluation against base", evidenced_by_example="ex-35", passed=True), # => co-25: the target-task improvement is evidence-supported
ArcPhase(phase="forgetting-regression suite run", evidenced_by_example="ex-37", passed=True), # => co-22,co-26: untouched capability was checked, not assumed intact
ArcPhase(phase="served as swappable artefact", evidenced_by_example="ex-46", passed=True), # => co-21,co-29: hot-swappable against the shared base
ArcPhase(phase="version-pinned to base", evidenced_by_example="ex-48", passed=True), # => co-30: the base-version dependency made explicit
ArcPhase(phase="maintenance and retirement plan written", evidenced_by_example="ex-49", passed=True), # => co-32: a planned, healthy end state, not an afterthought
] # => co-06: closes FULL_ARC -- 16 phases, each with a named source
def arc_is_justified(arc: list[ArcPhase]) -> bool: # => co-06: the whole adaptation is justified only if EVERY phase passed, not most of them
"""Return whether every `ArcPhase` in `arc` passed.""" # => co-06: documents arc_is_justified's contract -- no runtime output, just sets its __doc__
return all(phase.passed for phase in arc) # => co-06: returns this computed value to the caller
if __name__ == "__main__": # => co-06: entry point -- runs only when this file executes directly, not on import
for phase in FULL_ARC: # => co-06: print the whole arc, phase by phase, with its evidence source
status = "PASS" if phase.passed else "FAIL" # => co-06
print(f" [{status}] {phase.phase} (evidenced by {phase.evidenced_by_example})") # => co-06
unique_examples_cited = {phase.evidenced_by_example for phase in FULL_ARC} # => co-06: how many DISTINCT earlier examples actually back this arc
print(f"Distinct examples cited as evidence: {len(unique_examples_cited)}") # => co-06
assert len(FULL_ARC) == 16, "the full arc must cover exactly the 16 phases the capstone spec and decision gate require" # => co-06
assert len(unique_examples_cited) == 16, "every phase must be backed by its OWN distinct example, not one example doing double duty" # => co-06
justified = arc_is_justified(FULL_ARC) # => co-06: the final verdict
print(f"Adaptation is justified end to end: {justified}") # => co-06
assert justified, "every phase in this scenario's arc must pass for the overall adaptation to be justified" # => co-06
print("MATCH: 16 phases, 16 distinct pieces of measured evidence, all passing -- a justified adaptation is a CITED arc, not a single retrospective claim") # => co-06
# => co-06: this file's own structure is the point -- 'co-01-co-32' in the syllabus means every concept touched this arc, evidenced, not merely mentionedRun: python3 capstone_justified_adaptation.py
Output:
[PASS] measured gap (evidenced by ex-01)
[PASS] prompting exhausted (evidenced by ex-05)
[PASS] retrieval exhausted (evidenced by ex-04)
[PASS] scoping exhausted (evidenced by ex-07)
[PASS] decision gate (evidenced by ex-08)
[PASS] total cost budgeted (evidenced by ex-13)
[PASS] licence and rights checked (evidenced by ex-15)
[PASS] dataset consistency audited (evidenced by ex-20)
[PASS] splits disjoint, no leakage (evidenced by ex-26)
[PASS] adapter rank justified (evidenced by ex-31)
[PASS] early stopping on validation (evidenced by ex-40)
[PASS] paired evaluation against base (evidenced by ex-35)
[PASS] forgetting-regression suite run (evidenced by ex-37)
[PASS] served as swappable artefact (evidenced by ex-46)
[PASS] version-pinned to base (evidenced by ex-48)
[PASS] maintenance and retirement plan written (evidenced by ex-49)
Distinct examples cited as evidence: 16
Adaptation is justified end to end: True
MATCH: 16 phases, 16 distinct pieces of measured evidence, all passing -- a justified adaptation is a CITED arc, not a single retrospective claimVerify: arc_is_justified(FULL_ARC) is True across all 16 phases, each citing a distinct
evidenced_by_example, satisfying co-06's rule that a justified adaptation is a cited arc of
evidence, never a single retrospective claim.
Key takeaway: every one of the sixteen phases this arc requires is backed by its own distinct, specific earlier example in this course -- nothing in this arc is asserted without a source.
Why It Matters: this example is the bridge to the capstone that follows -- the same sixteen-phase shape, this time carried through five ordered, cross-importing Python files rather than sixteen independently-cited scenarios. Sixteen scattered citations prove the same discipline the capstone must now prove end to end, through one continuous, artefact-passing pipeline instead, with each phase's evidence a committed file another step can actually read.
Worked Example 68: Statistical Significance of the Improvement
ex-68 · exercises co-25
Context: continuing co-25 -- this example runs an exact binomial sign test on Example 35's
own 6-to-1 discordant-pair result, showing the real test disagrees with that example's own
illustrative shortcut, then confirms the identical ratio DOES reach significance at a larger sample.
# learning/code/ex-68-statistical-significance-of-the-improvement/statistical_significance.py
"""Worked Example 68: Statistical Significance of the Improvement.""" # => co-25: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from math import comb # => co-25: an exact binomial sign-test needs the binomial coefficient, not an approximation
def sign_test_p_value(b: int, c: int) -> float: # => co-25: the exact two-sided sign-test p-value on the b vs c discordant-pair counts
"""Return the exact two-sided binomial sign-test p-value for `b` wins against `c` losses out of `b + c` discordant pairs.""" # => co-25: documents sign_test_p_value's contract -- no runtime output, just sets its __doc__
n = b + c # => co-25: only discordant pairs carry information -- concordant pairs cancel out of a sign test entirely
if n == 0: # => co-25: no discordant pairs means no evidence either way
return 1.0 # => co-25: returns this computed value to the caller
extreme = min(b, c) # => co-25: the smaller of the two counts is the "more extreme in the other direction" tail
one_sided = sum(comb(n, k) for k in range(extreme + 1)) / (2**n) # => co-25: probability of `extreme` or fewer under a fair 50/50 null
return min(1.0, 2 * one_sided) # => co-25: two-sided -- double the one-sided tail, capped at 1.0
SIGNIFICANCE_THRESHOLD = 0.05 # => co-25: the conventional cutoff, imported by name from statistics-for-evaluation's own convention
if __name__ == "__main__": # => co-25: entry point -- runs only when this file executes directly, not on import
small_b, small_c = 6, 1 # => co-25: ex-35's OWN discordant-pair counts, from its 20-case held-out set
p_value_small = sign_test_p_value(small_b, small_c) # => co-25: run the EXACT test on ex-35's own, small scenario
print(f"ex-35's 20-case set: b={small_b}, c={small_c} -> exact p-value {p_value_small:.4f}") # => co-25
assert p_value_small >= SIGNIFICANCE_THRESHOLD, "ex-35's small 20-case set must NOT clear the exact 0.05 threshold, despite its own illustrative b>=5,c<=1 shortcut saying 'supported'" # => co-25
print("(ex-35's own 'b>=5, c<=1' shortcut called this 'supported' -- the EXACT test disagrees: 7 discordant pairs is too few to reach p<0.05)") # => co-25
large_b, large_c = 24, 4 # => co-25: the SAME 6-to-1 ratio, scaled to 28 discordant pairs instead of ex-35's 7
p_value_large = sign_test_p_value(large_b, large_c) # => co-25: run the exact test on the LARGER, better-powered scenario
print(f"Scaled-up set, 28 discordant pairs (same ratio): b={large_b}, c={large_c} -> exact p-value {p_value_large:.6f}") # => co-25
assert p_value_large < SIGNIFICANCE_THRESHOLD, "the same discordant ratio, run on a properly sized held-out set, must clear the significance threshold" # => co-25
print(f"MATCH: the same 6-to-1 ratio is NOT significant at 7 discordant pairs (p={p_value_small:.4f}) but IS significant at 28 (p={p_value_large:.6f}) -- sample size, not just ratio, decides it") # => co-25
# => co-25: ex-35's illustrative b>=5,c<=1 shortcut was too generous -- the real statistics-for-evaluation machinery shows a small eval set can UNDER-power even a lopsided-looking resultRun: python3 statistical_significance.py
Output:
ex-35's 20-case set: b=6, c=1 -> exact p-value 0.1250
(ex-35's own 'b>=5, c<=1' shortcut called this 'supported' -- the EXACT test disagrees: 7 discordant pairs is too few to reach p<0.05)
Scaled-up set, 28 discordant pairs (same ratio): b=24, c=4 -> exact p-value 0.000180
MATCH: the same 6-to-1 ratio is NOT significant at 7 discordant pairs (p=0.1250) but IS significant at 28 (p=0.000180) -- sample size, not just ratio, decides itVerify: sign_test_p_value(6, 1) returns 0.1250, above the 0.05 SIGNIFICANCE_THRESHOLD,
while sign_test_p_value(24, 4) -- the identical ratio at four times the discordant pairs -- returns
0.000180, satisfying co-25's rule that a small eval set can under-power even a lopsided-looking
result.
Key takeaway: Example 35's own illustrative b>=5, c<=1 shortcut was too generous -- the exact
binomial sign test shows its 6-to-1 result does not actually clear a real significance threshold,
though the identical ratio at four times the sample size does.
Why It Matters: this is the honest correction this course insists on: an illustrative shortcut is named as illustrative, and when the real machinery disagrees with it, the disagreement is shown, not hidden. Sample size, not just a favorable ratio, is what a real statistical test actually checks. A team relying only on the illustrative shortcut would have walked away from a result the real test says is genuinely significant.
Worked Example 69: Regression Suite Severity Weighting
ex-69 · exercises co-26, co-22
Context: continuing co-26 -- not every regression is equally costly. This example weights
eight regression cases by severity and shows a 75% naive pass rate dropping below an alert
threshold once a single safety-critical failure is weighted properly.
# learning/code/ex-69-regression-suite-severity-weighting/severity_weighting.py
"""Worked Example 69: Regression Suite Severity Weighting.""" # => co-26: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-26: one immutable row per regression case, now carrying its own severity weight
class WeightedRegressionCase(NamedTuple): # => co-26: not every regression is equally costly -- severity must be part of the score
case_id: str # => co-26: unique id
capability: str # => co-26: which untouched capability this case probes
severity: int # => co-22: 1 (cosmetic) through 3 (safety-critical) -- how much this specific failure would actually cost
adapted_pass: bool # => co-22: did the adapted model pass this case
# => co-26,co-22: 8 regression cases, most cosmetic, one severity-3 safety case the naive pass rate would bury
WEIGHTED_SUITE: list[WeightedRegressionCase] = [ # => co-26: one row per case
WeightedRegressionCase(case_id="reg-01", capability="formatting", severity=1, adapted_pass=False), # => co-26: cosmetic miss
WeightedRegressionCase(case_id="reg-02", capability="formatting", severity=1, adapted_pass=True), # => co-26: cosmetic pass
WeightedRegressionCase(case_id="reg-03", capability="general-qa", severity=1, adapted_pass=True), # => co-26: cosmetic pass
WeightedRegressionCase(case_id="reg-04", capability="general-qa", severity=2, adapted_pass=True), # => co-26: moderate pass
WeightedRegressionCase(case_id="reg-05", capability="reasoning", severity=2, adapted_pass=True), # => co-26: moderate pass
WeightedRegressionCase(case_id="reg-06", capability="reasoning", severity=2, adapted_pass=True), # => co-26: moderate pass
WeightedRegressionCase(case_id="reg-07", capability="arithmetic", severity=2, adapted_pass=True), # => co-26: moderate pass
WeightedRegressionCase(case_id="reg-08", capability="safety-refusal", severity=3, adapted_pass=False), # => co-22,co-26: safety-critical MISS -- one case, buried by a naive average
] # => co-26: closes WEIGHTED_SUITE -- 7 of 8 pass naively, but the ONE failure is the worst-severity case
def naive_pass_rate(cases: list[WeightedRegressionCase]) -> float: # => co-26: what a plain, unweighted regression score reports
"""Return the unweighted fraction of `cases` with `adapted_pass` True.""" # => co-26: documents naive_pass_rate's contract -- no runtime output, just sets its __doc__
return sum(1 for c in cases if c.adapted_pass) / len(cases) # => co-26: returns this computed value to the caller
def severity_weighted_score(cases: list[WeightedRegressionCase]) -> float: # => co-22,co-26: a score that penalizes high-severity failures far more
"""Return a severity-weighted pass score for `cases`: passing cases contribute their full severity weight, failing cases contribute zero.""" # => co-22: documents severity_weighted_score's contract -- no runtime output, just sets its __doc__
total_weight = sum(c.severity for c in cases) # => co-22: the maximum possible weighted score
earned_weight = sum(c.severity for c in cases if c.adapted_pass) # => co-22: weight actually earned, zero for every failing case
return earned_weight / total_weight # => co-22: returns this computed value to the caller
if __name__ == "__main__": # => co-26: entry point -- runs only when this file executes directly, not on import
naive = naive_pass_rate(WEIGHTED_SUITE) # => co-26: the unweighted view
weighted = severity_weighted_score(WEIGHTED_SUITE) # => co-22: the severity-aware view
print(f"Naive pass rate: {naive:.0%} | Severity-weighted score: {weighted:.0%}") # => co-22,co-26
assert naive == 0.75, "the naive pass rate must be exactly 75% (6 of 8) in this scenario" # => co-26
safety_case = next(c for c in WEIGHTED_SUITE if c.capability == "safety-refusal") # => co-22: the single highest-severity case
print(f"Safety-refusal case: severity {safety_case.severity}, passed: {safety_case.adapted_pass}") # => co-22
assert not safety_case.adapted_pass, "the planted safety-critical regression must be a failing case in this scenario" # => co-22
assert weighted < naive, "the severity-weighted score must fall further than the naive pass rate once the safety-critical failure is weighted properly" # => co-22,co-26
alert_threshold = 0.80 # => co-22: below this weighted score, the regression is treated as blocking, regardless of the naive number
print(f"Severity-weighted score below alert threshold ({alert_threshold:.0%}): {weighted < alert_threshold}") # => co-22
assert weighted < alert_threshold, "the severity-weighted score must cross the alert threshold even though the naive 75% pass rate would not" # => co-22
print("MATCH: a 75% naive pass rate looks tolerable; weighting by severity drops the score below the alert line because the ONE failure is safety-critical") # => co-22,co-26
# => co-22,co-26: a regression suite that treats every case as equally important can hide the single failure that matters mostRun: python3 severity_weighting.py
Output:
Naive pass rate: 75% | Severity-weighted score: 71%
Safety-refusal case: severity 3, passed: False
Severity-weighted score below alert threshold (80%): True
MATCH: a 75% naive pass rate looks tolerable; weighting by severity drops the score below the alert line because the ONE failure is safety-criticalVerify: naive_pass_rate reports 75% while severity_weighted_score drops to 71%, below the
80% alert threshold, satisfying co-22's rule that a regression suite treating every case equally
can hide the single failure that matters most.
Key takeaway: a 75% naive pass rate reads as tolerable; weighting the same eight cases by
severity drops the score below the alert line, because the single failure is the safety-critical one.
Why It Matters: this is Example 36's flat regression suite sharpened -- not every capability regression costs the
same, and a scoring scheme that ignores that can let the worst failure hide behind seven unrelated
passes. A 75% pass rate sounds acceptable until the one failure hiding inside it turns out to be
the single case that matters most.
Worked Example 70: A Fine-Tune That Helped and Hurt
ex-70 · exercises co-25, co-22
Context: continuing co-25 -- this example presents a genuinely mixed outcome, +33 points
on the target task and -28 points on the regression suite, and shows the correct decision is
neither a clean ship nor an outright reject, but "needs mitigation."
# learning/code/ex-70-a-fine-tune-that-helped-and-hurt/helped_and_hurt.py
"""Worked Example 70: A Fine-Tune That Helped and Hurt.""" # => co-25: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-25: a small, self-documenting record holding BOTH halves of the decision, together
@dataclass(frozen=True) # => co-25: frozen -- a completed run's dual result is a fact once measured, not a mutable running total
class DualResult: # => co-25,co-22: a run that must be judged on target-task gain AND regression-suite cost, never one alone
target_task_pass_rate_base: float # => co-25: base model's pass rate on the target triage task
target_task_pass_rate_adapted: float # => co-25: adapted model's pass rate on the SAME target task -- genuinely better
regression_pass_rate_base: float # => co-22: base model's pass rate on the untouched-capability regression suite
regression_pass_rate_adapted: float # => co-22: adapted model's pass rate on the SAME regression suite -- genuinely worse
regression_alert_threshold: float # => co-22: below this regression score, the damage is judged too severe to accept
RESULT = DualResult( # => co-25,co-22: a genuinely mixed outcome -- clearly helped on target, clearly hurt on regression
target_task_pass_rate_base=0.60, # => co-25: matches ex-01's own baseline gap
target_task_pass_rate_adapted=0.93, # => co-25: a real, evidenced 33-point target-task gain
regression_pass_rate_base=1.00, # => co-22: the base's own clean regression score
regression_pass_rate_adapted=0.72, # => co-22: a real, evidenced 28-point regression-suite drop
regression_alert_threshold=0.90, # => co-22: matches ex-37's own alert line
) # => co-25: closes RESULT
def decide(result: DualResult) -> str: # => co-25,co-22: the decision must weigh BOTH halves, never just the flattering one
"""Return 'ship', 'reject', or 'needs mitigation' based on `result`'s target-task gain and regression-suite damage.""" # => co-25: documents decide's contract -- no runtime output, just sets its __doc__
target_improved = result.target_task_pass_rate_adapted > result.target_task_pass_rate_base # => co-25: did the target task genuinely improve
regression_acceptable = result.regression_pass_rate_adapted >= result.regression_alert_threshold # => co-22: is the regression damage within the accepted line
if target_improved and regression_acceptable: # => co-25,co-22: both halves clear -- a clean ship decision
return "ship" # => co-25
if target_improved and not regression_acceptable: # => co-25,co-22: THIS scenario -- helped on target, hurt on regression, past the accepted line
return "needs mitigation" # => co-22: neither an unqualified ship nor an outright reject -- the regression must be fixed or scoped around first
return "reject" # => co-25: no target-task improvement at all -- reject outright
if __name__ == "__main__": # => co-25: entry point -- runs only when this file executes directly, not on import
target_gain = RESULT.target_task_pass_rate_adapted - RESULT.target_task_pass_rate_base # => co-25: the real, positive gain
regression_damage = RESULT.regression_pass_rate_base - RESULT.regression_pass_rate_adapted # => co-22: the real, negative damage
print(f"Target-task gain: +{target_gain:.0%} | Regression-suite damage: -{regression_damage:.0%}") # => co-25,co-22
assert target_gain > 0.30, "the target-task gain must be large and genuinely positive in this scenario" # => co-25
assert regression_damage > 0.25, "the regression-suite damage must be large and genuinely negative in this scenario" # => co-22
verdict = decide(RESULT) # => co-25,co-22: run the full decision, weighing both halves
print(f"Decision: {verdict}") # => co-25
assert verdict == "needs mitigation", "a run that genuinely helps the target task but crosses the regression alert line must land as 'needs mitigation', not a clean ship" # => co-25,co-22
print("MATCH: +33 points on target and -28 points on regression is neither a clean ship nor an outright reject -- it needs mitigation before it can go out") # => co-25,co-22
# => co-25,co-22: ex-35 and ex-41 were each one-sided (clear win, clear wash) -- real runs often land here, needing BOTH signals read together, not separatelyRun: python3 helped_and_hurt.py
Output:
Target-task gain: +33% | Regression-suite damage: -28%
Decision: needs mitigation
MATCH: +33 points on target and -28 points on regression is neither a clean ship nor an outright reject -- it needs mitigation before it can go outVerify: decide(RESULT) returns "needs mitigation" for a +33% target-task gain paired with a
-28% regression-suite drop past the alert threshold, satisfying co-25's rule that a mixed result
must be judged on both signals together, never one alone.
Key takeaway: a large, real target-task gain and a large, real regression-suite loss can both be true at once -- the correct verdict is neither a clean ship nor an outright reject, but a named third outcome: needs mitigation.
Why It Matters: Examples 35 and 41 were each one-sided -- a clear win and a clear wash. Real adaptation runs often land in this messier middle, and having a named decision for it is what keeps a mixed result from being rounded up to a ship or down to a reject. Naming "needs mitigation" as its own outcome keeps this middle case from being quietly rounded toward whichever answer is more convenient.
Worked Example 71: Distillation with a Held-Out Teacher Eval
ex-71 · exercises co-27, co-28
Context: continuing co-28 -- Example 43 assumed the teacher's own ceiling of 97% from a
different eval. This example actually measures the teacher on ten held-out cases it never generated
labels for, finding a lower, honest ceiling of 90%.
# learning/code/ex-71-distillation-with-a-held-out-teacher-eval/held_out_teacher_eval.py
"""Worked Example 71: Distillation with a Held-Out Teacher Eval.""" # => co-27: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-27: one immutable row per held-out case, teacher's own result recorded honestly, not assumed perfect
class TeacherEvalCase(NamedTuple): # => co-28: the teacher's OWN measured result on cases it never generated labels for
case_id: str # => co-27: unique id
teacher_pass: bool # => co-28: did the teacher itself get this held-out case right -- checked, not assumed
# => co-28: 10 held-out cases the teacher NEVER saw during its own training -- the teacher is not assumed to be a perfect oracle
TEACHER_HELD_OUT_RESULTS: list[TeacherEvalCase] = [ # => co-28: one row per held-out case
TeacherEvalCase(case_id="held-01", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-02", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-03", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-04", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-05", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-06", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-07", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-08", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-09", teacher_pass=True), # => co-28: teacher passes
TeacherEvalCase(case_id="held-10", teacher_pass=False), # => co-28: teacher itself FAILS this one -- the teacher is not perfect, and this proves it
] # => co-28: closes TEACHER_HELD_OUT_RESULTS
ASSUMED_TEACHER_PASS_RATE = 0.97 # => co-28: the figure ex-42/ex-43 quoted for the teacher -- convenient, but was it actually MEASURED on held-out data?
STUDENT_PASS_RATE = 0.88 # => co-28: this distillation's own measured student result on THIS held-out set -- still below the teacher's honestly measured ceiling
if __name__ == "__main__": # => co-28: entry point -- runs only when this file executes directly, not on import
measured_teacher_pass_rate = sum(1 for c in TEACHER_HELD_OUT_RESULTS if c.teacher_pass) / len(TEACHER_HELD_OUT_RESULTS) # => co-28: the teacher's ACTUAL held-out result, checked rather than assumed
print(f"Assumed teacher pass rate (from earlier examples): {ASSUMED_TEACHER_PASS_RATE:.0%}") # => co-27
print(f"Measured teacher pass rate on THIS held-out set: {measured_teacher_pass_rate:.0%}") # => co-28
assert measured_teacher_pass_rate == 0.90, "the teacher's measured held-out pass rate must be exactly 90% in this scenario, not the assumed 97%" # => co-28
real_ceiling = measured_teacher_pass_rate # => co-28: this is the student's REAL ceiling, not the number quoted from a different eval
student_gap_to_real_ceiling = real_ceiling - STUDENT_PASS_RATE # => co-28: how the student's own gap looks against the teacher's MEASURED ceiling
student_gap_to_assumed_ceiling = ASSUMED_TEACHER_PASS_RATE - STUDENT_PASS_RATE # => co-28: how the gap looked against the ASSUMED ceiling
print(f"Student gap to measured ceiling: {student_gap_to_real_ceiling:.0%} | Student gap to assumed ceiling: {student_gap_to_assumed_ceiling:.0%}") # => co-28
assert student_gap_to_real_ceiling < student_gap_to_assumed_ceiling, "the gap against the MEASURED teacher ceiling must be smaller than the gap against the assumed one, since the true ceiling is lower" # => co-28
student_exceeds_measured_teacher = STUDENT_PASS_RATE > real_ceiling # => co-28: does the student now look like it beats the teacher's REAL ceiling
print(f"Student appears to exceed the teacher's measured ceiling: {student_exceeds_measured_teacher}") # => co-28
assert not student_exceeds_measured_teacher, "even against a lower, honestly measured ceiling, the student must still not exceed the teacher" # => co-28
print("MATCH: the teacher's OWN measured held-out pass rate is 90%, not the assumed 97% -- checking it changes the honest gap without ever flipping which model leads") # => co-27,co-28
# => co-27,co-28: a distillation ceiling quoted from a different eval, never re-measured on the student's own held-out set, is an assumption, not a factRun: python3 held_out_teacher_eval.py
Output:
Assumed teacher pass rate (from earlier examples): 97%
Measured teacher pass rate on THIS held-out set: 90%
Student gap to measured ceiling: 2% | Student gap to assumed ceiling: 9%
Student appears to exceed the teacher's measured ceiling: False
MATCH: the teacher's OWN measured held-out pass rate is 90%, not the assumed 97% -- checking it changes the honest gap without ever flipping which model leadsVerify: measured_teacher_pass_rate is 90%, not ASSUMED_TEACHER_PASS_RATE's 97%, and
student_exceeds_measured_teacher is False, satisfying co-28's rule that a teacher's ceiling must
be measured on its own held-out set, never merely assumed from a different eval.
Key takeaway: the teacher's honestly measured ceiling is 90%, nine points below the figure
quoted from an earlier example -- and even against this lower, more honest ceiling, the student still
does not exceed it.
Why It Matters: this is Example 43's hard bound re-examined with more rigor: the bound only holds if the teacher's own ceiling was actually measured, not merely quoted. A ceiling assumed rather than checked is a liability this course's evaluation discipline exists to catch. Example 43's own hard bound is only as trustworthy as the ceiling it was measured against, and that ceiling itself needed re-checking.
Worked Example 72: Adapter Registry and Discovery
ex-72 · exercises co-21, co-29
Context: continuing co-21 -- an adapter is only truly composable if it can be discovered, not just loaded. This example builds a small registry mapping task names to adapter records, resolving a task to the correct adapter without the caller knowing its exact name in advance.
# learning/code/ex-72-adapter-registry-and-discovery/adapter_registry.py
"""Worked Example 72: Adapter Registry and Discovery.""" # => co-21: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass, field # => co-21: a registry entry per adapter -- discoverable metadata, not just a loaded weights blob
@dataclass(frozen=True) # => co-21: frozen -- a registry entry's own facts are fixed once the adapter is registered
class AdapterRecord: # => co-21: everything a caller needs to find and trust an adapter, without loading it first
name: str # => co-21: unique registry key
task: str # => co-21: which task this adapter is FOR -- what discovery actually searches on
base_model_id: str # => co-30: which base this adapter is pinned to
owner: str # => co-21: who is accountable for this adapter's maintenance obligation
@dataclass # => co-21: a mock registry -- a small, in-memory stand-in for a real adapter catalog service
class AdapterRegistry: # => co-21: the thing a serving layer queries BEFORE attempting to load anything
entries: dict[str, AdapterRecord] = field(default_factory=dict[str, AdapterRecord]) # => co-21: registered adapters, keyed by name
def register(self, record: AdapterRecord) -> None: # => co-21: add an adapter to the registry
"""Add `record` to this registry's entries, keyed by its `name`.""" # => co-21: documents register's contract -- no runtime output, just sets its __doc__
self.entries[record.name] = record # => co-21: register it
def find_for_task(self, task: str) -> AdapterRecord | None: # => co-21: discovery -- find the right adapter WITHOUT the caller knowing its exact name
"""Return the registered `AdapterRecord` whose `task` matches `task`, or None if none is registered.""" # => co-21: documents find_for_task's contract -- no runtime output, just sets its __doc__
for record in self.entries.values(): # => co-21: search by task, the caller's actual need, not by adapter name
if record.task == task: # => co-21: the first match wins -- a real registry would need a tie-break policy for multiple candidates
return record # => co-21: returns this computed value to the caller
return None # => co-21: no adapter is registered for this task
TRIAGE_RECORD = AdapterRecord(name="triage-v1", task="ticket-triage", base_model_id="qwen2.5-0.5b-instruct-r1", owner="platform-ml-team") # => co-21: matches ex-45's own served adapter
BILLING_TONE_RECORD = AdapterRecord(name="billing-tone-v1", task="billing-response-tone", base_model_id="qwen2.5-0.5b-instruct-r1", owner="support-ops-team") # => co-21: matches ex-46's own second adapter
if __name__ == "__main__": # => co-21: entry point -- runs only when this file executes directly, not on import
registry = AdapterRegistry() # => co-21: an empty registry to start
registry.register(TRIAGE_RECORD) # => co-21: register the first adapter
registry.register(BILLING_TONE_RECORD) # => co-21: register the second adapter
found = registry.find_for_task("ticket-triage") # => co-21: discover BY TASK, not by knowing the adapter's exact name in advance
print(f"Discovered adapter for 'ticket-triage': {found.name if found else None} (owner: {found.owner if found else None})") # => co-21
assert found is not None and found.name == "triage-v1", "discovery by task must return the correctly matching adapter record" # => co-21
missing = registry.find_for_task("refund-approval") # => co-21: a task with NO registered adapter
print(f"Discovered adapter for 'refund-approval': {missing}") # => co-21
assert missing is None, "discovery must return None for a task with no registered adapter, not raise or guess" # => co-21
assert found.base_model_id == BILLING_TONE_RECORD.base_model_id, "both registered adapters must share the same base pin in this scenario, matching ex-46's shared-base serving shape" # => co-30
print("MATCH: the registry resolves a task name to the right adapter's metadata WITHOUT the caller needing to know its exact adapter name in advance") # => co-21
# => co-21: this is the discoverability half of co-21's 'composable artefact' claim -- an adapter is only truly composable if it can be FOUND, not just loadedRun: python3 adapter_registry.py
Output:
Discovered adapter for 'ticket-triage': triage-v1 (owner: platform-ml-team)
Discovered adapter for 'refund-approval': None
MATCH: the registry resolves a task name to the right adapter's metadata WITHOUT the caller needing to know its exact adapter name in advanceVerify: find_for_task("ticket-triage") returns the correct TRIAGE_RECORD while
find_for_task("refund-approval") returns None, satisfying co-21's rule that discovery resolves a
task to the correct adapter's metadata without raising or guessing.
Key takeaway: resolving "ticket-triage" to triage-v1 without knowing its exact name in advance
is the discoverability half of co-21's composability claim -- an adapter that can only be loaded, not
found, is not fully composable.
Why It Matters: this registry is what makes Example 47's memory-efficient serving strategy practically usable at scale -- a serving layer with dozens of adapters needs to find the right one by task, not by memorizing every adapter's exact name. A caller that has to hardcode every adapter's exact name does not scale past a handful of task-specific behaviours before it breaks.
Worked Example 73: Load-Testing Adapter Swaps
ex-73 · exercises co-29, co-21
Context: continuing co-29 -- this example load-tests Example 46's single demonstration swap under six repeated, simulated swaps, confirming every one stays comfortably under budget and far cheaper than a full base reload.
# learning/code/ex-73-load-testing-adapter-swaps/load_testing_swaps.py
"""Worked Example 73: Load-Testing Adapter Swaps.""" # => co-29: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from typing import NamedTuple # => co-29: one immutable row per simulated swap, its measured latency recorded
class SwapMeasurement(NamedTuple): # => co-21: a single hot-swap event under simulated load, and how long it took
swap_id: int # => co-21: which swap in the sequence this is
from_adapter: str # => co-21: the adapter that was active before this swap
to_adapter: str # => co-21: the adapter that became active after this swap
swap_latency_ms: float # => co-29: measured time for the swap itself -- NOT a full base reload
SWAP_LATENCY_BUDGET_MS = 50.0 # => co-29: the serving stack's own budget for a hot-swap to stay invisible to the caller
# => co-29,co-21: 6 simulated swaps under load, alternating between two adapters on the SAME loaded base
SWAP_MEASUREMENTS: list[SwapMeasurement] = [ # => co-29: one row per swap, in the order they were run
SwapMeasurement(swap_id=1, from_adapter="billing-tone-v1", to_adapter="escalation-tone-v1", swap_latency_ms=8.2), # => co-29: swap 1
SwapMeasurement(swap_id=2, from_adapter="escalation-tone-v1", to_adapter="billing-tone-v1", swap_latency_ms=7.9), # => co-29: swap 2
SwapMeasurement(swap_id=3, from_adapter="billing-tone-v1", to_adapter="escalation-tone-v1", swap_latency_ms=9.1), # => co-29: swap 3
SwapMeasurement(swap_id=4, from_adapter="escalation-tone-v1", to_adapter="billing-tone-v1", swap_latency_ms=8.6), # => co-29: swap 4
SwapMeasurement(swap_id=5, from_adapter="billing-tone-v1", to_adapter="escalation-tone-v1", swap_latency_ms=11.3), # => co-29: swap 5, a slight spike under load
SwapMeasurement(swap_id=6, from_adapter="escalation-tone-v1", to_adapter="billing-tone-v1", swap_latency_ms=8.4), # => co-29: swap 6
] # => co-29: closes SWAP_MEASUREMENTS
FULL_BASE_RELOAD_LATENCY_MS = 4_200.0 # => co-29: for comparison -- what reloading the WHOLE base model would cost instead of swapping an adapter
if __name__ == "__main__": # => co-29: entry point -- runs only when this file executes directly, not on import
for measurement in SWAP_MEASUREMENTS: # => co-29: show every swap's measured latency, in order
print(f" swap {measurement.swap_id}: {measurement.from_adapter} -> {measurement.to_adapter} took {measurement.swap_latency_ms:.1f}ms") # => co-29
max_swap_latency = max(m.swap_latency_ms for m in SWAP_MEASUREMENTS) # => co-29: the worst observed swap under load
avg_swap_latency = sum(m.swap_latency_ms for m in SWAP_MEASUREMENTS) / len(SWAP_MEASUREMENTS) # => co-29: the typical swap cost under load
print(f"Max swap latency: {max_swap_latency:.1f}ms | Average: {avg_swap_latency:.1f}ms | Budget: {SWAP_LATENCY_BUDGET_MS:.0f}ms") # => co-29
assert max_swap_latency < SWAP_LATENCY_BUDGET_MS, "every single swap must stay comfortably under the 50ms latency budget, even the worst one under load" # => co-29
reload_vs_swap_ratio = FULL_BASE_RELOAD_LATENCY_MS / max_swap_latency # => co-21,co-29: how much more expensive a full base reload would be, for comparison
print(f"A full base reload would cost {reload_vs_swap_ratio:.0f}x the worst measured swap latency") # => co-21,co-29
assert reload_vs_swap_ratio > 200, "an adapter swap must be dramatically cheaper than a full base reload under this scenario's numbers" # => co-21,co-29
print("MATCH: every hot-swap under simulated load stays under 12ms, over 350x cheaper than the 4.2-second cost of reloading the whole base model") # => co-21,co-29
# => co-21,co-29: this is the load-tested version of ex-46's single demonstration swap -- the operational claim holds under repeated, sustained use, not just onceRun: python3 load_testing_swaps.py
Output:
swap 1: billing-tone-v1 -> escalation-tone-v1 took 8.2ms
swap 2: escalation-tone-v1 -> billing-tone-v1 took 7.9ms
swap 3: billing-tone-v1 -> escalation-tone-v1 took 9.1ms
swap 4: escalation-tone-v1 -> billing-tone-v1 took 8.6ms
swap 5: billing-tone-v1 -> escalation-tone-v1 took 11.3ms
swap 6: escalation-tone-v1 -> billing-tone-v1 took 8.4ms
Max swap latency: 11.3ms | Average: 8.9ms | Budget: 50ms
A full base reload would cost 372x the worst measured swap latency
MATCH: every hot-swap under simulated load stays under 12ms, over 350x cheaper than the 4.2-second cost of reloading the whole base modelVerify: max_swap_latency is 11.3ms, well under the 50ms SWAP_LATENCY_BUDGET_MS, and
reload_vs_swap_ratio is 372x, satisfying co-29's rule that adapter swaps stay dramatically cheaper
than a full base reload even under repeated, sustained load.
Key takeaway: six repeated swaps under simulated load all stayed under 12 milliseconds, 372
times cheaper than the 4.2-second cost of reloading the entire base model.
Why It Matters: this is Example 46's single demonstration swap, load-tested -- the operational claim holds under sustained, repeated use, not just as a one-off trick that happens to work once. A single successful swap proves the shape works; six repeated swaps under budget prove it survives the kind of sustained traffic a real deployment sees.
Worked Example 74: A Licence-Blocked Retirement
ex-74 · exercises co-32, co-31
Context: continuing co-32 and co-31 -- a retirement candidate must clear the same
licence check that applied at training time. This example shows a 15-point quality-winning
replacement blocked outright by a non-commercial licence.
# learning/code/ex-74-a-licence-blocked-retirement/licence_blocked_retirement.py
"""Worked Example 74: A Licence-Blocked Retirement.""" # => co-32: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-31: a small, self-documenting record for a licence check applied to a retirement CANDIDATE, not just training
@dataclass(frozen=True) # => co-31: frozen -- a licence check's result is a fact once verified, not a mutable running total
class RetirementCandidate: # => co-32: a proposed replacement for an existing adapter, evaluated on BOTH quality and licence
name: str # => co-32: which candidate replacement this is
pass_rate: float # => co-32: the candidate's own measured pass rate on the target task
licence: str # => co-31: the candidate's licence terms
permits_commercial_use: bool # => co-31: whether the licence actually permits Vantage's commercial, for-profit use
CURRENT_ADAPTER_PASS_RATE = 0.81 # => co-32: matches ex-49's own retiring adapter's pass rate
# => co-32,co-31: a NEW, better-performing base model release is proposed as the retirement replacement -- but its licence is the wrong kind
PROPOSED_REPLACEMENT = RetirementCandidate( # => co-32: the candidate Vantage's team wants to switch to
name="newer-base-model-r2", # => co-32: a newer release, tempting on quality alone
pass_rate=0.96, # => co-32: a genuinely better measured pass rate than the current adapter
licence="custom non-commercial research licence", # => co-31: NOT an open-commercial licence -- this is the blocker
permits_commercial_use=False, # => co-31: explicitly forbids the commercial use Vantage's product requires
) # => co-32: closes PROPOSED_REPLACEMENT
def retirement_is_permitted(candidate: RetirementCandidate, current_pass_rate: float) -> tuple[bool, str]: # => co-31,co-32: (permitted, reason) -- both quality AND licence must clear
"""Return whether `candidate` may replace the current adapter, and the reason, checking quality first then licence.""" # => co-31: documents retirement_is_permitted's contract -- no runtime output, just sets its __doc__
if candidate.pass_rate <= current_pass_rate: # => co-32: a replacement that is not even better on quality is not worth the switch
return False, "candidate does not beat the current adapter on quality" # => co-32: returns this computed value to the caller
if not candidate.permits_commercial_use: # => co-31: the licence check happens BEFORE the retirement is allowed to proceed, per co-31's own discipline
return False, "candidate's licence forbids Vantage's commercial use" # => co-31: returns this computed value to the caller
return True, "candidate beats the current adapter and its licence permits commercial use" # => co-31,co-32: returns this computed value to the caller
if __name__ == "__main__": # => co-32: entry point -- runs only when this file executes directly, not on import
print(f"Current adapter pass rate: {CURRENT_ADAPTER_PASS_RATE:.0%}") # => co-32
print(f"Proposed replacement: {PROPOSED_REPLACEMENT.name} | pass rate {PROPOSED_REPLACEMENT.pass_rate:.0%} | licence {PROPOSED_REPLACEMENT.licence!r}") # => co-32,co-31
permitted, reason = retirement_is_permitted(PROPOSED_REPLACEMENT, CURRENT_ADAPTER_PASS_RATE) # => co-31,co-32: run the check
print(f"Retirement permitted: {permitted} ({reason})") # => co-31,co-32
assert PROPOSED_REPLACEMENT.pass_rate > CURRENT_ADAPTER_PASS_RATE, "the candidate must genuinely beat the current adapter on quality in this scenario" # => co-32
assert not permitted, "a quality-winning candidate with a licence that forbids commercial use must still be blocked from retirement" # => co-31,co-32
assert reason == "candidate's licence forbids Vantage's commercial use", "the blocking reason must be attributed to the licence, since quality alone would have passed" # => co-31
print("MATCH: a 15-point quality win is not enough -- the licence check alone blocks this retirement, exactly as it would have blocked training in the first place") # => co-31,co-32
# => co-31,co-32: co-31's licence discipline applies to a retirement's REPLACEMENT candidate too, not only to the model being trained in the first placeRun: python3 licence_blocked_retirement.py
Output:
Current adapter pass rate: 81%
Proposed replacement: newer-base-model-r2 | pass rate 96% | licence 'custom non-commercial research licence'
Retirement permitted: False (candidate's licence forbids Vantage's commercial use)
MATCH: a 15-point quality win is not enough -- the licence check alone blocks this retirement, exactly as it would have blocked training in the first placeVerify: retirement_is_permitted returns (False, "candidate's licence forbids Vantage's commercial use") despite a genuine 15-point quality win, satisfying co-31's rule that a licence
check applies to a retirement's replacement candidate, not only to the model trained originally.
Key takeaway: a 15-point quality win is not enough to permit a retirement -- the same licence
discipline that blocked training in Example 15 blocks a replacement candidate here, for the identical
reason.
Why It Matters: this closes a gap Example 49's own clean retirement case left open: co-31's licence gate applies at every point an adapter or its replacement changes hands, not only at initial training. A replacement adapter that wins on every quality metric is still not deployable if its licence quietly forbids the commercial use Vantage needs.
Worked Example 75: Writing the Maintenance and Retirement Plan
ex-75 · exercises co-30, co-32
Context: closing the course -- co-30 and co-32 both require a standing, written plan. This example checks Vantage's own filed plan for concrete, checkable triggers and rejects a deliberately vague counter-example.
# learning/code/ex-75-writing-the-maintenance-and-retirement-plan/maintenance_and_retirement_plan.py
"""Worked Example 75: Writing the Maintenance and Retirement Plan.""" # => co-30: this file's own restated purpose, doubling as its module __doc__
from __future__ import annotations # => hygiene: postpones annotation evaluation, interpreter-version-agnostic
from dataclasses import dataclass # => co-32: the closing operational document -- concrete conditions, not vague intentions
@dataclass(frozen=True) # => co-30: frozen -- a maintenance plan is a written commitment once filed, not a mutable running total
class MaintenancePlan: # => co-30,co-32: the standing document co-30 and co-32 both require an adapter to ship with
adapter_name: str # => co-30: which adapter this plan covers
pinned_base_version: str # => co-30: the exact base version this adapter is currently valid against, matching ex-48's own pin
re_adaptation_trigger: str # => co-30: the CONCRETE condition that requires re-training, stated plainly enough to act on
retirement_trigger: str # => co-32: the CONCRETE condition under which this adapter is retired outright, not re-trained
owning_team: str # => co-30: who is accountable for acting when either trigger fires
PLAN = MaintenancePlan( # => co-30,co-32: Vantage's own filed plan for the triage adapter
adapter_name="triage-v1", # => co-30: matches ex-45/ex-48's own adapter
pinned_base_version="qwen2.5-0.5b-instruct-r1", # => co-30: matches ex-48's own pin
re_adaptation_trigger="the pinned base version is superseded by a new release the platform team deploys", # => co-30: concrete, matches ex-48's own scenario exactly
retirement_trigger="a retrieval-based or prompting-based alternative measurably beats this adapter on both pass rate and monthly cost", # => co-32: concrete, matches ex-49's own scenario exactly
owning_team="platform-ml-team", # => co-30: matches ex-72's own registry record for this adapter
) # => co-30: closes PLAN
def trigger_is_concrete(trigger: str) -> bool: # => co-30,co-32: a real trigger names a checkable CONDITION, not a vague aspiration
"""Return whether `trigger` reads as a concrete, checkable condition rather than a vague statement.""" # => co-30: documents trigger_is_concrete's contract -- no runtime output, just sets its __doc__
vague_phrases = ("as needed", "periodically", "when appropriate", "from time to time") # => co-30: the vague-language smells this illustrative check screens for
return not any(phrase in trigger.lower() for phrase in vague_phrases) and len(trigger) > 20 # => co-30: not vague AND substantive enough to be an actual condition
if __name__ == "__main__": # => co-30: entry point -- runs only when this file executes directly, not on import
print(f"Adapter: {PLAN.adapter_name} | pinned to {PLAN.pinned_base_version} | owned by {PLAN.owning_team}") # => co-30
print(f"Re-adaptation trigger: {PLAN.re_adaptation_trigger}") # => co-30
print(f"Retirement trigger: {PLAN.retirement_trigger}") # => co-32
re_adaptation_concrete = trigger_is_concrete(PLAN.re_adaptation_trigger) # => co-30: verify the re-adaptation condition is actually checkable
retirement_concrete = trigger_is_concrete(PLAN.retirement_trigger) # => co-32: verify the retirement condition is actually checkable
print(f"Re-adaptation trigger is concrete: {re_adaptation_concrete} | Retirement trigger is concrete: {retirement_concrete}") # => co-30,co-32
assert re_adaptation_concrete, "the re-adaptation trigger must be a concrete, checkable condition, not a vague aspiration" # => co-30
assert retirement_concrete, "the retirement trigger must be a concrete, checkable condition, not a vague aspiration" # => co-32
vague_plan_trigger = "review the adapter periodically and retire it as needed" # => co-30,co-32: a deliberately vague counter-example, the kind this check must catch
vague_is_concrete = trigger_is_concrete(vague_plan_trigger) # => co-30: run the SAME check against the vague counter-example
print(f"Vague counter-example trigger is concrete: {vague_is_concrete}") # => co-30
assert not vague_is_concrete, "a vague trigger like 'review periodically... as needed' must fail the concreteness check" # => co-30,co-32
print("MATCH: this plan's own triggers cite exact, checkable conditions from ex-48 and ex-49 -- a vague 'review periodically' trigger is caught and rejected") # => co-30,co-32
# => co-30,co-32: this is the final artefact the tension note and co-32 both call for -- a plan an on-call engineer can actually act on, not a good intentionRun: python3 maintenance_and_retirement_plan.py
Output:
Adapter: triage-v1 | pinned to qwen2.5-0.5b-instruct-r1 | owned by platform-ml-team
Re-adaptation trigger: the pinned base version is superseded by a new release the platform team deploys
Retirement trigger: a retrieval-based or prompting-based alternative measurably beats this adapter on both pass rate and monthly cost
Re-adaptation trigger is concrete: True | Retirement trigger is concrete: True
Vague counter-example trigger is concrete: False
MATCH: this plan's own triggers cite exact, checkable conditions from ex-48 and ex-49 -- a vague 'review periodically' trigger is caught and rejectedVerify: trigger_is_concrete is True for both of PLAN's own triggers and False for the
deliberately vague counter-example, satisfying co-30's and co-32's rule that a maintenance plan's
triggers must be concrete, checkable conditions, not vague aspirations.
Key takeaway: this plan's own re-adaptation and retirement triggers cite the exact conditions Examples 48 and 49 already demonstrated -- while a vague "review periodically... as needed" trigger is caught and rejected by the same check.
Why It Matters: this is the final artefact this course's tension note and co-32 both call for -- a plan an on-call engineer can actually act on, closing the arc from Example 50's sixteen-phase citation through a concrete, standing operational document. A vague plan that says "review periodically" gives an on-call engineer nothing to check against when an actual trigger condition is met.
← Previous: Band B: The Dataset and the Training Run · Next: Capstone →
Last updated July 25, 2026