§11.0–11.4Design Process · Performance Metrics · Baselines · Gathering Data

Part II DL pp. 421–427 · ~6 min read

  • bayes error
  • precision (classification)
  • recall
  • pr curve
  • f-score
  • coverage
  • default baseline model

§11.0 A practical design process

Knowing many algorithms matters less than applying a commonplace one correctly. In practice you can usually do far better with a correct application of an everyday algorithm than a sloppy application of an exotic one. That correct application rests on a simple methodology (adapted from Ng 2015):

The recommended design loop — determine goals, build an end-to-end system, instrument to diagnose the bottleneck, then make targeted changes and repeat.
1 · Goalsmetric + target2 · Pipelineend-to-end fast3 · Instrumentfind bottleneck4 · Changedata / tune / swapiterate on findings

The running example throughout is Google’s Street View house-number transcription system — a CNN that reads address numbers from photos to place them on the map.

§11.1 Performance metrics

Your error metric guides every later decision, so choose it — and a realistic target — first. Absolute-zero error is usually impossible: the Bayes error is the floor even with infinite data, because the features may not fully determine the output or the task may be intrinsically stochastic. And the metric usually differs from the training cost.

Plain accuracy (§5.1.2) often isn’t enough. When mistakes have unequal costs (a spam filter blocking a real email ≫ letting spam through), optimize a total cost. For rare events, accuracy is actively misleading: precision (fraction of detections that are correct) and recall (fraction of true events found) tell the real story. Drag the threshold to trade one for the other, and push prevalence toward zero to watch accuracy stay near 100% while precision collapses:

Fig (interactive) — a detector's score distributions. The threshold t trades precision for recall (see the moving PR-curve point); a low prevalence exposes why accuracy is useless for rare events.
tnegativespositivesdetect →
PRPR curve
precision
75.4%
recall
89.1%
F-score
81.7%
accuracy
88.0%

Raising the threshold t makes the model pickier: precision ↑ but recall ↓. The F-score = 2·p·r/(p+r) is high only when BOTH are high. Drag prevalence toward 0 to see why accuracy misleads on rare events.

Sweep the threshold and you trace a PR curve . To collapse it to one number, use the area under it or the F-score :

F-score (eq 11.1)

F=2prp+rF = \frac{2\,p\,r}{p + r}
ppprecision — TP / (TP + FP), how trustworthy a positive prediction is(0,1)
rrrecall — TP / (TP + FN), how many true events are caught(0,1)
FFthe harmonic mean of p and r — high ONLY when both are high (a model that games one alone scores poorly)(0,1)

Some systems may refuse to decide when unsure and hand off to a human. Then coverage — the fraction of examples answered — is the metric, traded against accuracy: refusing everything gives 100% accuracy at 0% coverage. Street View targets human-level 98% accuracy while pushing coverage above 95%. Whatever the choice, fix the metric before iterating, or you won’t know if a change helped.

§11.2 Default baseline models

Establish a sensible end-to-end system fast. If the problem might yield to a few linear weights, start simple (logistic regression). If it’s AI-complete (object/speech recognition, translation), start with deep learning — and pick the baseline by the structure of your data:

Choosing a baseline by data structure — click a cell for detail.
Baseline modelWhy
Fixed-size vectorFeedforward MLP (fully connected)no known topology to exploit
Grid / imageConvolutional networkexploit the 2-D topology
SequenceGated RNN (LSTM or GRU)exploit order & carry state
Dotted-underlined cells have explanations — click one.

Sensible defaults for the rest: optimize with SGD + momentum and a decaying learning rate, or Adam; add batch normalization if optimization struggles (especially CNNs and sigmoidal nets). Include mild regularization from the startearly stopping almost universally, plus dropout (batch norm’s noise can sometimes substitute). If a similar task has been studied, copy its best model — or use transfer learning (e.g. ImageNet CNN features). Use unsupervised learning in the baseline only when the domain (like NLP word embeddings) is known to benefit, or the task is itself unsupervised.

§11.3 Determining whether to gather more data

Once the baseline runs, resist the urge to swap algorithms at random — gathering more data is often more effective. But first, diagnose:

The gather-more-data decision. Check training performance FIRST — more data can’t help a model that isn’t even fitting its training set.
Training error low?noIncrease capacity,tune LR, fix features(do NOT gather data)yesTest gap large?yesGather more data,or add regularization(reduce the gap)nodone

How much more data? Plot generalization error against training-set size (like fig 5.4) and extrapolate. Since a small fraction of extra examples rarely moves the needle, experiment on a logarithmic scale — e.g. double the dataset between runs. If gathering much more data isn’t feasible, improving generalization becomes a research problem (better algorithms), not an application one.

§11.4 Selecting hyperparameters

Deep learning algorithms come with many hyperparameters governing runtime, memory, and model quality. There are two ways to set them: manually (requires understanding what each does and how models generalize) and automatically (less understanding needed, but far more compute). The next section digs into both — manual tuning, grid search, and random search: selecting hyperparameters.

Check yourself — goals, metrics, baselines, and gathering data

1.What is the recommended practical design process?

2.What is the Bayes error?

3.For a rare-event detector (e.g. a disease affecting 1 in a million), why is accuracy a poor metric, and what should you use? (Try the PRThresholdLab with low prevalence.)

4.What is 'coverage', and how does it trade off with accuracy?

5.How should you choose a default baseline model?

6.You want to improve a model. When is gathering more data the right move?

6 questions