Mission: the architecture tradeoff note
This mission is mostly writing, with a code spine: draft the note against one concrete task, then stress the rubric until it either holds up or admits ambiguity out loud.
The job: a one-page tradeoff note for a concrete task — the written artifact that turns architecture lore into a decision someone can review. (Chapter 13 did this for model choice; this is the training-side twin.) Plus the tiny rubric function in the starter, so the decision logic is code as well as prose.
The note's required sections:
- The task, in data terms — input shape and type, output, dataset size, latency and serving constraints (chapters 42/46 vocabulary).
- Candidates and their bias — for each of dense/CNN/ transformer (and the ch.39 non-deep ladder!): what structural assumption it brings, and whether your data actually has that structure. One plain-spoken sentence each.
- The costs — parameters and data appetite, training compute, inference cost (last lesson's serving lens). "Transformer" without a serving plan is a wish.
- The pick and the exit — your choice, the measurable result that would prove it wrong, and the fallback. Chapter 21's eval-first habit, applied to architecture.
- Stress the rubric — feed your
recommend()an ambiguous case (tabular data with a text column, say) and make its answer — or its refusal to answer glibly — defensible.
Chapter 16's buy-vs-build coda bears down with extra force here: for language and vision, the strongest baseline is usually a pretrained model (fine-tuned or just prompted) rather than anything trained from scratch. Your note should say why you're training at all — chapter 22's rubric already asked the question.