Page 8 of 8~112 min topic

Train a tiny model

Ship and explain the tiny linear model

Page 8 packages proved vs unproved evidence so another engineer can run, trust, or reject the hours→score linear fit with holdout.

~14 min this pageMastery and shipping

1Learn the idea

Read

Assemble the ship record

A shippable lab artifact includes: how to run it, the metric result (holdout absolute error; slope sign matches the hours/score trend), the failure you can still reproduce (training on the test row, or reporting R² without the holdout error), the security gate for publishing per-learner residuals that re-identify students, and a rollback note. The user decision it supports remains: estimate slope/intercept from study hours and score a held-out row honestly.

Read

Freeze the evidence

print({'artifact':'hours-score linear fit','proved':['holdout mae'],'unproved':['new semester'],'owner':'ml-lab'})

Expected evidence: tiny-model ship note. Store this beside the fixture version so scores remain meaningful after content changes in train-a-tiny-model.

Read

Explain limits without apology

State operating limits for the tiny linear model in plain language: fixture size, offline vs live dependencies, and what would require a new eval set. Shipping train-a-tiny-model is honest scoping, not maximal confidence language.

Read

Lab notebook: proved vs unproved

Fill this table in your notes for the tiny linear model:

  • Proved on small hours/score table with one held-out pair: …
  • Unproved beyond the fixture: …
  • Metric that blocks release: holdout absolute error; slope sign matches the hours/score trend
  • Failure still reproducible: training on the test row, or reporting R² without the holdout error
  • Security gate: publishing per-learner residuals that re-identify students
  • Rollback: …

Ship the narrative only when the unproved list is honest. Reviewers trust narrow claims that support estimate slope/intercept from study hours and score a held-out row honestly more than maximal language that collapses under the first production oddity.

Read

Worked judgment

Hand your ship note to a peer and ask them to recreate a proved/unproved ship note with rollback without watching you type. If they cannot, your evidence is still tribal knowledge. Tighten the run command and the metric line until a stranger can validate the tiny linear model against small hours/score table with one held-out pair.

Read

Why this stage matters for the tiny linear model

At the mastery and shipping stage for train-a-tiny-model, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about small hours/score table with one held-out pair that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: predict mean train score for the holdout before fitting.

For this page specifically, success looks like a proved/unproved ship note with rollback while still centering the user decision to estimate slope/intercept from study hours and score a held-out row honestly. If you cannot point to a file, command, or assertion that proves that for the tiny linear model, stay on this page instead of advancing.

Overfitting glossary

Previous

Go deeper

Before you start

Why this matters

List two things this chapter proved on the fixture and two things it did not prove about the tiny linear model. If you cannot name the gaps, you are not ready to ship the narrative—even if the code runs.

Check your understanding

Page assessment

Answer from memory. Completion is saved from this evidence, not from opening the next page.

1. Are proved and unproved lists both non-empty?
2. Is rollback concrete (command or version pin)?
3. Would a stranger reproduce the metric on the fixture?
4. Does the note still center the decision: estimate slope/intercept from study hours and score a held-out row honestly?

All responses are required.