Recipe

Take a project from data to a deployed model

Use when: you're starting a new deep-learning project -- or evaluating an existing one -- and need to decide what representation, architecture, loss, and training strategy actually fit, not execute one technique you've already committed to

Goal: a trained, honestly evaluated, ready-to-ship model, with every major decision justified by what came before it, or a clear diagnosis of which earlier step needs to be redone

Taught in The end-to-end decision chain

1. 1

   Identify what structure your data actually has. It could be a grid (pictures), an ordered sequence (text, audio, time series), or flat feature vectors with no spatial or ordered structure at all.

   • pictures or other grid-structured data — convolutional structure (Chapter 15) is the natural fit; go to Step 2.
   • ordered sequences (text, audio, time series) — recurrent or attention-based structure (Chapters 13-16) fits; go to Step 2.
   • flat, tabular feature vectors with no spatial or ordered structure — a plain MLP (Chapter 4) is often enough. A specialized architecture may add complexity without adding accuracy. Go to Step 2.

   Why: the data's own structure decides which inductive bias actually helps. An architecture chosen without looking at this first is a guess, not a decision.

2. 2

   Convert the raw data into the tensor form the network will actually consume: tokens and embeddings for text (Chapter 17), a normalized pixel tensor for pictures (Chapter 15), one-hot or ordinal encoding for tabular categoricals.

   • raw text — tokenize and embed it (Chapter 17) before anything else.
   • raw pixels — keep them as a normalized image tensor (Chapter 15), channels included.

   Why: a network only ever sees the representation it is handed. A representation that throws away word order or spatial adjacency cannot be recovered by any architecture downstream of it.

3. 3

   Match Step 1's data structure to a family. Use a CNN for grid data. Use RNN/LSTM/GRU where cheap in-order processing and modest context are enough. Use attention/Transformer where longer-range dependencies and parallel training matter more. Use a plain MLP where no spatial or in-order bias applies.

   • a sequence task where either a recurrent model or a Transformer could plausibly work — prefer the Transformer once data and compute allow it, the 2026 default (Chapter 21). Fall back to a recurrent model chiefly when unbounded, one-token-at-a-time streaming is the actual deployment constraint.
   • the data has no spatial or ordered structure at all — a plain MLP (Chapter 4) needs no further justification.

   Why: matching architecture to data structure lets a network learn from far less data than a generic MLP would need for the same task. Universal approximation (Chapter 4) says a large enough MLP could learn it, not that it will learn it efficiently.

4. 4

   Regression uses MSE or Huber loss. Classification uses binary or categorical cross-entropy. Ranking or similarity uses contrastive or triplet loss (all Chapter 7).

   • the task matches one of Chapter 7's standard patterns — use that loss directly.
   • the task is genuinely novel — write a custom loss (Chapter 7 §7), as long as it stays differentiable and its minimum matches what "correct" actually means for the task.

   Why: the loss function is the only quantity gradient descent (Step 5) actually optimizes. A well-chosen architecture trained against the wrong loss correctly learns the wrong thing.

5. 5

   Run the forward pass, compute the loss, backpropagate, update the weights, and repeat over epochs. Layer Chapter 11's practices on top: a validation split, checkpointing, early stopping, gradient clipping, a learning-rate schedule, and a fixed random seed.

   Why: this is the mechanism that actually moves the parameters toward lower loss. Every earlier step chose what to train and on what objective. This step is where that choice gets carried out.

6. 6

   Check train-versus-validation curves for over- or underfitting. Compute task-appropriate metrics (accuracy, precision/recall/F1, ROC-AUC — Chapter 12) on a held-out test set that was never touched during training or tuning.

   • validation results track training results and both look good — the model is a reasonable candidate; go to Step 8.
   • a train-validation gap opens, or both stay poor — go to Step 7 to find out which, and why.

   Why: training loss alone says nothing about how a model performs on data it has not seen. That gap is exactly what Chapter 12's split exists to expose.

7. 7

   If Step 6 shows the model is not learning at all, or is not generalizing, run Chapter 14's own recipe, "Debug a network that isn't learning." Its fixed, cheapest-first order checks a tiny batch first, then the learning rate, initialization, labels and leakage, tensor shapes, gradient flow, and numerical stability, in that order. It finds the specific cause instead of guessing at one.

   • the diagnostic recipe finds and fixes a concrete bug — return to Step 5 and retrain.
   • Step 6 already passed cleanly — skip this step entirely and go to Step 8.

   Why: guessing at fixes without isolating the actual cause wastes far more time than the cheapest-first checks Chapter 14's own recipe already runs.

8. 8

   Weigh how much labeled data you have for this exact task against whether a fitting already-trained model already exists for a related task.

   • a large labeled dataset for this exact task exists, and no fitting already-trained model does — train from scratch, i.e. Steps 3-6 above with freshly initialized weights.
   • labeled data is limited, but a model pretrained on a large, related task or domain exists (an ImageNet-pretrained CNN, a pretrained language model) — apply Chapter 16's own recipe, "Apply transfer learning to a new task," to decide how much of the pretrained network to freeze, replace, or fine-tune.
   • the pretrained model itself is very large, and even the fine-tune end of Chapter 16's spectrum is out of reach on compute — reach for a parameter-efficient method like LoRA or QLoRA (Section 6 of this chapter) instead of updating every weight.

   Why: the amount of labeled data available, and the size of the candidate pretrained model, are what actually decide this. Training a large model from scratch on a small dataset wastes the data efficiency transfer learning exists to capture. Fully fine-tuning a huge pretrained model wastes compute a parameter-efficient method exists to avoid.

9. 9

   Check the trained model's size and speed against the real deployment target. A model that is too large or slow may need mixed precision or quantization (Section 8 of this chapter). Confirm Step 6's check actually reflects the deployment data, not just a benchmark split. Write down what the model is and is not checked for (a model card, Section 8) before shipping it.

   Why: a model that only exists as a research checkpoint is not finished. Deployment has its own limits that training-time metrics alone do not capture. Shipping it without an honest record of its limits takes away a choice the eventual user of the model should have gotten to make.