Chapter 18 — Machine Learning Foundations

[!] Why a classical ML chapter in an AI engineering course

Three reasons, and none of them is nostalgia. First, most production ML is still not an LLM — ranking, fraud, forecasting, propensity and recommendation are gradient-boosted trees, and they will outlive the current wave. Second, the evaluation discipline here is the same discipline that makes LLM evaluation honest: chapter 5's retrieval metrics and chapter 8's agent scoring are special cases of what this chapter covers generally.

Third, and most practically: an interviewer will ask. "Why not just use an LLM for this?" is a question with a real answer, and 18.20 gives it.

[i] What this assumes, and what it doesn't repeat

It assumes chapter 17: sampling, confidence intervals, base rates and the difference between significance and effect size. Those ideas are used here rather than re-explained, and 18.13's treatment of imbalance is 17.20 applied to a confusion matrix.

It does not cover deep learning architecture — chapter 2 did transformers, and the training mechanics of neural networks are a different subject. This chapter is about the modelling judgement that applies regardless of which algorithm you picked.

18.1 The one idea behind all of it

Strip away the algorithms and machine learning is a single move: instead of writing the rules, you supply examples and let a fitting procedure find the rules. Everything else — every algorithm, every metric, every failure — follows from that one substitution.

[def] Learning, defined operationally

A model is a function with adjustable parameters. Training searches for parameter values that minimise a loss function measuring how wrong the model is on data you have. The bet — and it is a bet — is that parameters which work on data you have will also work on data you don't. That bet is called generalisation, and almost every practice in this chapter exists to check whether it paid off.

[!] The failure mode is built into the method

Because training minimises error on data you already have, a sufficiently flexible model can drive that error to zero by memorising it — learning the answer key rather than the subject. The measured performance then looks superb and the deployed performance is terrible. This is not an occasional bug; it is the default behaviour of any model with enough capacity, which is why 18.8's separation of data is non-negotiable rather than good practice.

[+] When not to use ML at all

If the rules are known, writable and stable, write them. A regex finds email addresses more reliably than a classifier, costs nothing to run, never drifts, and can be debugged by reading it. ML earns its complexity when the rules are genuinely unknown or too numerous to write — and "we could write these rules but it would be tedious" is usually a case for writing the rules. Every model you deploy is a permanent monitoring and retraining obligation (18.18).

18.2 Supervised, unsupervised, reinforcement

The three paradigms, and what each needs from you
Paradigm	You supply	Retail example
Supervised	Inputs and correct outputs	Predicting whether an order will be returned, from past orders labelled returned or not
Unsupervised	Inputs only	Grouping products by purchase pattern with no predefined categories
Reinforcement	An environment and a reward signal	Learning a pricing or bidding policy from the outcomes of its own actions

[+] Where the AI stack you built sits

Embeddings (chapter 3) come from self-supervised learning — labels generated from the data's own structure, such as predicting a masked word, which is what makes web-scale training possible without annotation. An LLM's pretraining is the same idea. RLHF then applies reinforcement learning with human preferences as the reward, which is where instruction-following comes from (1.14). So the models in this course are not a separate discipline — they are these paradigms at unusual scale.

[!] Unsupervised results have no right answer to check against

Supervised learning can be scored against held-out labels. Clustering cannot — there is no ground truth, so any clustering "works" in the sense of producing output. Whether it is useful is a judgement call requiring domain inspection, which is why unsupervised results should never be shipped straight into a decision without someone looking at what the clusters actually contain (18.12).

18.3 Classification versus regression

Within supervised learning, the split is simply what kind of thing you are predicting: a category or a number. It determines the loss, the metrics, and the algorithms available.

Classification: Predicting a category. Binary (will this order be returned?), multi-class (which of twelve departments?), or multi-label (which of these tags apply, possibly several). Scored with precision, recall and friends (18.14).
Regression: Predicting a continuous number: delivery time, expected basket value, demand next week. Scored with error magnitudes (18.16).
Ranking: Predicting an order rather than a value — the search problem from chapter 4. Technically its own family, usually approached by predicting per-item scores and sorting, and scored with NDCG or MRR (5.31).

[+] Predict the probability, threshold it later

A binary classifier should output a probability, not a decision. Keeping the number lets you move the threshold as business needs change without retraining (18.14), route uncertain cases to human review (15.16), and combine the score with other signals. A model that returns only "fraud" or "not fraud" has thrown away the information that makes it operationally useful — and this is exactly the same argument as 17.20's "route by confidence."

18.4 Features, labels, and the data you don't have

[def] Feature engineering

A feature is an input variable. Feature engineering is constructing the ones that make the pattern learnable: turning a raw timestamp into "hour of day" and "is weekend", turning a customer's order history into "orders in the last 90 days" and "median basket value". For tabular data this remains the single highest-leverage activity in modelling, well ahead of algorithm choice.

[!] Your labels are noisier than you think

Everyone scrutinises the model and takes the labels on faith. But "returned" might exclude returns processed in store, "fraud" means whatever the review team flagged last year under a different policy, and "relevant" in a search evaluation set means whatever an annotator thought at 4pm on a Friday. Label noise puts a ceiling on achievable accuracy that no model can exceed. When a model plateaus, the labels are at least as likely to be the constraint as the algorithm — and reviewing a hundred disagreements by hand is usually more informative than another week of tuning.

[retail] The data you don't have is the data you never logged

To predict returns you want the reason for past returns — but if the returns system stores a free-text note nobody parses, that feature does not exist and cannot be reconstructed. This is the most common reason a promising model underperforms: the predictive signal was real, but nobody instrumented it. Deciding what to log is a modelling decision made months before anyone trains anything, which is why the observability work in 8.23 and 16.12 quietly determines what is learnable later.

18.5 Underfitting and overfitting

The two ways a model fails, and they need opposite fixes — which is why diagnosing which one you have is the first thing to do when a model disappoints.

Diagnosing from two numbers
Symptom	Diagnosis	Fix
Poor on training, poor on test	Underfitting. The model is too simple to capture the pattern.	More capacity, better features, train longer. Easy to spot, easy to fix.
Excellent on training, poor on test	Overfitting. The model memorised rather than generalised.	More data, fewer features, regularisation, simpler model. The common case.
Good on both, poor in production	Leakage or drift. Neither of the above — your evaluation was wrong.	The dangerous case, because nothing in your metrics warned you. See 18.9 and 17.18.

[retail] Overfitting, measured

random forest, 20k rows, 2% positive classtext

train ROC-AUC = 1.0000      perfect. suspiciously perfect.
test  ROC-AUC = 0.8485      the honest number

gap = 0.15   <- this gap IS the overfitting

A perfect training score is never good news. An unconstrained forest can isolate every training row, so 1.0000 means only that the model has enough capacity to memorise the data — it says nothing about the pattern. The gap between train and test is the diagnostic, and reporting the training number as if it were performance is one of the fastest ways to lose credibility in a review.

18.6 Bias and variance

Bias: Error from wrong assumptions — the model is too rigid to represent the truth. A straight line fitted to a curve has high bias, and more data will not help.
Variance: Error from sensitivity to the particular training sample. Retrain on a different sample and you get a noticeably different model. More data does help.
Irreducible error: Noise in the world. No model removes it, and pushing error below it means you are fitting noise.

[+] The trade-off, and where the classic framing is out of date

Traditionally: increasing complexity lowers bias and raises variance, so there is a sweet spot in the middle and going past it makes things worse. That picture is a good guide for the tabular models in 18.11 and it is the one to give in an interview.

It is also incomplete for very large models. Modern over-parameterised networks routinely interpolate the training data and generalise well — the "double descent" phenomenon, where test error falls again beyond the point classical theory says it should rise. Knowing both the classical picture and its limits is a stronger answer than reciting either alone.

18.7 Regularisation

[def] Penalising complexity on purpose

Regularisation adds a penalty for complexity to the loss, so the model must earn each additional bit of flexibility by reducing error enough to justify it. It trades a little training accuracy for better generalisation — deliberately fitting the data worse in order to predict better.

The forms you will actually configure
Method	Effect
L2 (ridge)	Shrinks coefficients toward zero without reaching it. The sensible default for linear models.
L1 (lasso)	Drives some coefficients exactly to zero, performing feature selection as a side effect. Useful when you want a sparse, explainable model.
Tree constraints	Max depth, minimum samples per leaf, number of estimators. This is what regularisation looks like for the models in 17.11.
Early stopping	Stop training when validation error stops improving. Simple, effective, and free.
Dropout	Randomly disable units during training so the network cannot rely on any single path. Neural networks only.

[!] More data beats better regularisation

Regularisation manages overfitting; data removes the conditions for it. If you can cheaply obtain ten times the training data, that will almost always outperform careful tuning of a penalty term on the smaller set. Regularisation is what you reach for when more data is genuinely unavailable — which, admittedly, is most of the time.

18.8 Train, validation, test

[def] Three splits, three distinct jobs

Training set. The model fits its parameters here.
Validation set. You compare models, tune hyperparameters and choose a threshold here. The model never trains on it, but you make decisions from it.
Test set. Touched once, at the end, to estimate real-world performance. Every extra look degrades it.

[!] The test set decays every time you look at it

Try forty model variants, pick the one with the best test score, and that score is no longer an unbiased estimate — you have optimised against the test set by hand, and it has quietly become a validation set. This is overfitting operating through the researcher rather than the algorithm, and it is why teams are so often surprised in production despite "good test results". Tune on validation, and touch test once.

[retail] Split by time, and sometimes by customer

For anything with a temporal element — which is nearly everything in retail — a random split lets the model train on December and predict November, learning from the future. Split chronologically: train on the past, test on the following period, exactly as production will run. And if the same customer appears in both splits, the model can memorise that customer rather than the behaviour, so group the split by customer as well. Random splitting is the right default only when rows are genuinely independent, which is rarer than it looks.

18.9 Cross-validation and leakage

[def] K-fold cross-validation

Split the data into k parts, train on k−1 and validate on the remaining one, rotating through all k. Every row is used for both training and validation, just never at the same time. It gives a more stable estimate than one split and — often more usefully — a spread across folds, which tells you how sensitive the result is to which data you happened to get. For time series, use TimeSeriesSplit, which only ever validates forward.

[!] Leakage: the failure that produces beautiful, worthless results

Data leakage is information reaching the model that will not exist at prediction time. It is the most damaging error in applied ML precisely because it makes everything look excellent — there is no warning sign in any metric, because the metrics themselves are contaminated. The model fails only in production, where the leaked information is absent.

[retail] Leakage, demonstrated on data with no signal whatsoever

Two hundred rows, five thousand random features, and a coin-flip label. There is nothing to learn: true accuracy is 50%. Select the twenty best-correlated features first, then cross-validate:

pure noise, two procedurestext

select features on ALL data, then cross-validate   ->  79.5% accuracy
feature selection INSIDE the CV pipeline           ->  51.0% accuracy

The first procedure reports a strong model built entirely from noise. The selection step saw every label, so the chosen features were the ones that happened to correlate with the answers in this sample — and cross-validation then scored them on data they were selected using. Every preprocessing step that learns anything from the data must sit inside the pipeline, so it is refitted on each training fold. That includes scaling, imputation, encoding and selection.

[+] The four leaks worth checking for by name

Preprocessing on the full dataset. Fitting a scaler or imputer before splitting. Fixed by using a Pipeline.
Target leakage. A feature that is a consequence of the outcome — refund_amount when predicting returns. If a feature seems too predictive, ask when it becomes known.
Temporal leakage. Any feature computed over a window that includes the prediction date.
Duplicate rows across splits. The same order appearing in train and test through a join fan-out, so the model is tested on data it memorised.

[i] The deep dive is chapter 21

This section and the next give you the working knowledge. If you want the loss functions underneath, the assumptions that actually matter, ridge versus lasso versus elastic net, the full tree family, variable selection, and how to derive a threshold from the cost of being wrong, see chapter 21.

18.10 Linear and logistic regression

The simplest useful models, and the ones to try first. Not because they usually win, but because they establish whether the problem is learnable at all, and they tell you something a boosted forest never will.

Linear regression: Predicts a number as a weighted sum of features. Each coefficient is the change in the prediction per unit change in that feature, holding others fixed — which is genuinely interpretable, and rare.
Logistic regression: Predicts a probability by passing that same weighted sum through a sigmoid. Despite the name it is a classifier, and it is the workhorse of production propensity modelling.

[+] Always fit one, even when you plan to use something else

A regularised linear model takes seconds to train and gives you three things a complex model does not: a baseline that later work must beat to justify itself, a sanity check — if it scores 0.99 you almost certainly have leakage (18.9) — and directional coefficients you can show a stakeholder. Frequently the boosted model wins by two points and the linear one ships, because it is explainable, fast, and nobody has to debug it at 3am.

[!] Coefficients are only interpretable if features aren't collinear

When two features are strongly correlated — order_count and total_spend, say — the fit can distribute weight between them almost arbitrarily, including giving one a large negative coefficient. The predictions stay fine; the interpretation is nonsense. If you intend to explain the coefficients, check correlations between features first, and be suspicious of any sign that contradicts domain knowledge.

18.11 Trees, forests, and gradient boosting

For tabular data — which is most production ML that isn't language or vision — this family is the default winner, and has been for a decade.

From one tree to the state of the art
Model	How it works	Verdict
Decision tree	Recursively splits on the feature that best separates the target.	Highly interpretable, and overfits badly on its own. Useful mainly as a component.
Random forest	Many trees on bootstrap samples and random feature subsets; average their votes.	Robust, hard to misuse, minimal tuning. The safe default.
Gradient boosting	Trees trained sequentially, each correcting the errors of those before it.	Usually the most accurate on tabular data. Needs tuning and can overfit if unchecked.

[def] Bagging versus boosting, in one line each

Bagging (forests) trains many models independently in parallel and averages them, which reduces variance. Boosting trains models sequentially, each focused on what the previous ones got wrong, which reduces bias. That single distinction explains why forests are so forgiving and why boosted models need early stopping: nothing in a boosting loop stops it from eventually fitting the noise.

[+] Why trees beat neural networks on tabular data

Trees split on thresholds, so they handle mixed types, skewed distributions and non-linear cut-offs natively, need no scaling, and cope with missing values. A neural network must learn all of that from data it does not have enough of. This is why "we should use deep learning" is usually the wrong instinct for a spreadsheet-shaped problem — and worth saying plainly in an interview, because it demonstrates you choose tools by fit rather than fashion.

[!] Feature importance is not causal, and is easily misread

Built-in importance scores are biased toward high-cardinality features and split arbitrarily between correlated ones. More importantly, a high-importance feature is what the model used, not what causes the outcome — and acting on it as if it were causal is exactly the 17.19 error. Prefer permutation importance or SHAP values, and treat all of them as a description of the model rather than of the world.

18.12 Clustering and dimensionality reduction

The unsupervised methods you will actually meet
Method	Does	Watch out for
k-means	Partitions into k spherical clusters.	You must choose k, and it will happily produce k clusters from data with no structure at all.
DBSCAN / HDBSCAN	Density-based; finds arbitrary shapes and labels outliers as noise.	No need to pick k, but sensitive to its distance parameters.
PCA	Linear projection keeping the directions of greatest variance.	Fast and reversible. Components are usually not interpretable.
UMAP / t-SNE	Non-linear projection to 2D for visualisation.	For looking only. Distances between clusters in the plot are not meaningful, and neither is cluster size.

[+] You have already used both, in chapters 3 and 4

Matryoshka truncation (4.7) is dimensionality reduction with the reduction trained into the embedding model. HNSW's graph structure exploits the same clustering tendency that k-means measures. And when 3.14 plotted embeddings to show that similar products land near each other, that was UMAP — with the caveat above, which is why those plots illustrate an idea rather than prove one.

[!] Clustering always succeeds, which is the danger

Ask for five clusters and you get five clusters, whether or not the data has any group structure. Silhouette scores and elbow plots help, but neither answers the real question, which is whether the clusters mean anything. Inspect the members. If cluster three is "products photographed on a white background", you have discovered a property of your image pipeline rather than a customer segment — and that is a genuinely common outcome.

18.13 Why accuracy is usually wrong

Accuracy is the metric everyone reaches for and the one that survives contact with real data least often, because the events worth predicting are nearly always rare.

[retail] The 98% model that predicts nothing

fraud-style dataset, 2% positivetext

model that always predicts "not fraud":
    accuracy = 98.00%
    frauds caught = 0

actual trained model:
    test ROC-AUC = 0.848
    test PR-AUC  = 0.618   <- the number that means something

A model with no parameters and no intelligence scores 98%. Any accuracy figure on imbalanced data has to be compared against that baseline before it means anything, and in practice the comparison is usually damning. If someone reports accuracy without stating the class balance, they have not reported anything.

[def] The confusion matrix, and why it is the only honest starting point

Four numbers: true positives, false positives, true negatives, false negatives. Every classification metric is a ratio of some of these, and each metric is a different opinion about which errors matter. Look at the matrix first — a single scalar has already thrown away the distinction between the two ways of being wrong, and those two ways almost never cost the same.

18.14 Precision, recall, and the threshold

Precision: Of the cases you flagged, what fraction were right. Answers "can I trust an alert?" — the metric that decides whether a review team keeps paying attention.
Recall: Of the cases that existed, what fraction you caught. Answers "how much am I missing?"
F1: Their harmonic mean. A convenient single number, and it silently asserts that precision and recall matter equally — which is almost never true.

[retail] One model, three thresholds, three different products

same trained model, threshold variedtext

threshold    precision    recall
   0.5         1.000       0.300
   0.3         0.818       0.525
   0.1         0.380       0.658

Nothing about the model changed between those rows. At 0.5 every flag is correct and you miss 70% of cases; at 0.1 you catch two thirds and are wrong nearly two times in three. The threshold is a business decision, not a modelling one, and it belongs to whoever owns the cost of each error type. Auto-blocking a payment needs the top row; a queue for human review can afford the bottom one (15.16).

[+] Pick the metric from the cost of each mistake

False positives expensive? Optimise precision. Blocking legitimate orders costs revenue and goodwill.
False negatives expensive? Optimise recall. A missed safety violation or a missed fraud is worse than a wasted review.
Genuinely symmetric? F1 is fine — but state that you checked, because the assumption is doing real work.
Different costs you can quantify? Skip metrics and optimise expected cost directly. If a false negative costs £40 and a false positive £2, that ratio determines the threshold, and no standard metric encodes it.

18.15 ROC-AUC versus PR-AUC

[def] Two summaries across all thresholds

ROC-AUC is the probability that a random positive is scored above a random negative. PR-AUC (average precision) summarises the precision–recall curve. Both avoid committing to a threshold, which makes them useful for comparing models — but they behave very differently when classes are imbalanced.

[!] ROC-AUC flatters imbalanced problems

ROC's false positive rate has the number of negatives in its denominator. When negatives vastly outnumber positives, thousands of false positives barely move that rate, so the curve stays high while precision is dreadful. In the worked example ROC-AUC is 0.848 and PR-AUC is 0.618 — the same model, and the second number is the one that reflects what a reviewer would experience. For rare events, report PR-AUC. It is the same lesson as 17.20's base rate, expressed as a curve.

[+] Always state the baseline for PR-AUC

A random model has PR-AUC equal to the positive class rate — 0.02 on a 2% problem — whereas random ROC-AUC is always 0.5. So PR-AUC of 0.618 against a 0.02 baseline is a thirty-fold improvement, which sounds far less impressive than 0.618 alone and is far more informative. Quote the pair.

18.16 Regression metrics

Choosing an error measure for continuous predictions
Metric	Behaviour	Use when
MAE	Mean absolute error. Same units as the target; treats all errors proportionally.	The interpretable default. "Off by 12 minutes on average" is a sentence anyone understands.
RMSE	Root mean squared error. Squaring means large errors dominate.	When big misses are disproportionately costly. Sensitive to outliers, which is either the point or a problem.
MAPE	Mean absolute percentage error. Scale-free.	Popular and treacherous: undefined at zero, explodes near it, and penalises over-prediction more than under-prediction.
R-squared	Fraction of variance explained.	Fine for comparing models on one dataset; meaningless across datasets with different variance.

[!] The metric you train on shapes what the model predicts

Minimising squared error produces a model that predicts the mean; minimising absolute error produces one that predicts the median. On the skewed data of 17.2 those are materially different predictions, and the choice of loss is therefore a product decision in disguise. If you want to predict a percentile instead — "a delivery estimate we beat 90% of the time" — you need quantile loss, and no amount of tuning a squared-error model will get you there.

18.17 Calibration

[def] A calibrated model means what it says

A model is calibrated if, among cases it scores 0.7, about 70% are actually positive. This is a separate property from ranking ability: a model can order cases perfectly — excellent AUC — while all its probabilities are wrong. The standard measure is the Brier score, the mean squared error of the predicted probabilities, where lower is better.

[!] When calibration actually matters

If you only ever sort by score — ranking search results, prioritising a queue — calibration is irrelevant. It becomes essential the moment the number enters arithmetic: multiplying a probability by an order value to get expected loss, setting a threshold that means something, combining several models' outputs, or showing a confidence to a user. An uncalibrated 0.9 fed into an expected-value calculation produces a confidently wrong decision.

[+] Which models need it, and how to fix it

Logistic regression is well calibrated by construction. Random forests are pulled toward the middle by averaging; boosted trees and SVMs are typically overconfident; neural networks are notoriously overconfident. The fix is to fit a small correction on held-out data — Platt scaling (a logistic fit) or isotonic regression (a monotonic step function) via CalibratedClassifierCV. In the worked example isotonic calibration improved the Brier score from 0.01163 to 0.01078 while leaving the ranking untouched: same AUC, more trustworthy numbers.

[retail] The LLM connection

This is why an LLM saying "I am 90% confident" is not a probability. Nothing in next-token training calibrates that statement against outcomes, and expressed confidence correlates poorly with correctness — which is precisely why 15.15 routes on retrieval evidence and verifier output rather than on the model's own self-assessment. A stated confidence is generated text; a calibrated probability is a measured quantity.

18.18 Why models decay

A model is a snapshot of a relationship that held in the past. The world does not agree to hold still, so performance degrades from the day you deploy — and unlike a software bug, nothing throws an exception.

Three kinds of drift, and how each is detected
Drift	What changed	Detection
Data drift	The inputs shifted. New product categories, a new market, a redesigned app producing different behaviour.	Compare feature distributions against training. No labels needed, so you can do this immediately.
Concept drift	The relationship itself changed. What predicted fraud last year does not this year, because fraudsters adapted.	Needs outcomes, which arrive late. The harder and more dangerous case.
Upstream drift	Nothing changed in the world; a pipeline did. A join changed, a unit changed, a default became null.	Schema and range checks on every feature. The most common cause and the easiest to catch.

[!] The label delay problem

You learn whether a return prediction was right in thirty days, and whether a churn prediction was right in ninety. So the accuracy you can measure today describes a model serving traffic from months ago, and by the time degradation is visible in your metrics it has been happening for a quarter. This is why input monitoring matters more than output monitoring — feature distributions are available instantly, and they are the only early warning you get.

[+] What to monitor, cheapest first

Schema and nulls. Catches the pipeline breakage that causes most incidents.
Feature distributions. Population stability index or a KS test per feature, alerting on shift.
Prediction distribution. If the average predicted probability moves sharply, something changed even if you cannot yet say what.
Outcomes, when they arrive. The ground truth, always late.
A holdout that never gets the model. A small untreated slice is the only clean measure of what the model is actually contributing (19.20).

18.19 Feedback loops

[def] When the model's output becomes its own training data

A ranking model decides what users see; users click what they saw; those clicks train the next model. The system is now learning from its own past decisions, and the training data is no longer a sample of what users want — it is a sample of what the previous model showed them.

[retail] The rich-get-richer failure, concretely

A product ranked highly gets impressions, so it gets clicks, so the next model ranks it higher. A genuinely better product ranked 40th gets no impressions, therefore no clicks, therefore looks unpopular to every future model. Measured click-through rate rises steadily while catalogue coverage collapses, and the metric dashboard shows nothing but improvement. The model is not learning what is good; it is learning what it previously promoted.

[+] Breaking the loop

Log what was shown, not just what was clicked. Without impression data you cannot tell "not wanted" from "never seen", and that distinction is the whole problem.
Inject exploration. Show a small fraction of randomised or lower-ranked results deliberately. It costs a little short-term performance and is the only way to obtain unbiased data.
Weight by inverse propensity. If an item had a 5% chance of being shown, weight its observations up accordingly, so rarely shown items are not systematically underrepresented.
Watch coverage, not just engagement. Track what fraction of the catalogue is ever surfaced. Rising CTR with falling coverage is the signature of a loop closing.

18.20 Classical ML versus an LLM

This is the question an interviewer will ask, and answering it well requires resisting both available reflexes — that LLMs have made this obsolete, and that LLMs are a fad.

Choosing between a trained model and a prompted one
Consideration	Classical ML	LLM
Structured tabular input	Native. Boosted trees are hard to beat here.	Awkward and expensive; you are serialising a spreadsheet into a prompt.
Unstructured text or images	Needs feature engineering or embeddings.	The obvious choice.
Latency and cost per call	Microseconds, effectively free.	Hundreds of milliseconds, priced per token (16.18).
Labelled training data	Required, in quantity.	Zero or few-shot. The decisive advantage when you have no labels.
Calibrated probabilities	Available and correctable (18.17).	Not meaningfully available at all.
Determinism and auditability	Same input, same output, inspectable.	Non-deterministic, and explanations are generated rather than derived.

[+] The honest summary, and the hybrid that usually wins

If you have labels and structured features, train a model. It will be cheaper, faster, more accurate and auditable. If you have no labels and unstructured input, start with an LLM — and consider using it to bootstrap labels, then training a small model on them once volume justifies it.

In practice the strongest systems combine both, and the retail platform in this course is exactly that: embeddings and a cross-encoder reranker (chapter 5) are classical ML doing the retrieval, an LLM handles the generation, and a gradient-boosted model typically decides business ranking. Presenting that division of labour — each component chosen for a property it has and the alternative lacks — is a much stronger answer than advocating for either side.

18.21 Key takeaways

ML replaces writing rules with supplying examples, and everything hard follows from the bet that patterns in data you have hold on data you don't.
If the rules are known and stable, write them. A regex never drifts, costs nothing, and can be debugged by reading it.
Predict probabilities, not decisions. The threshold can then move with business need, route uncertain cases to humans, and combine with other signals.
Label noise caps achievable accuracy. When a model plateaus, reviewing a hundred disagreements usually beats another week of tuning.
The data you never logged is the model you cannot build. Instrumentation decisions made months earlier determine what is learnable.
Diagnose from the train-test gap. Bad on both is underfitting; great on train and bad on test is overfitting; good on both and bad in production is leakage or drift.
A perfect training score is never good news. In the worked example train AUC was 1.0000 against test 0.8485.
Bagging reduces variance, boosting reduces bias. That is why forests are forgiving and boosted models need early stopping.
More data beats better regularisation, when you can get it.
Tune on validation, touch test once. Forty variants scored against the test set means the test set has become a validation set.
Split by time, and often by customer. Random splits let the model learn from the future or memorise individuals.
Every step that learns from data goes inside the CV pipeline. Selecting features on the full dataset scored 79.5% on pure noise; doing it correctly scored 51%.
Trees beat neural networks on tabular data, because splits handle mixed types, skew and missing values natively.
Feature importance describes the model, not the world. It is not causal.
Clustering always succeeds. Inspect the members before believing the segments.
Accuracy on imbalanced data is theatre. Predicting the majority class scored 98% on the worked dataset.
The threshold is a business decision. One model gave precision 1.00 at recall 0.30, or precision 0.38 at recall 0.66, with no retraining.
For rare events report PR-AUC, with its baseline. ROC-AUC was 0.848 where PR-AUC was 0.618, and random PR-AUC is the positive rate.
The loss you train on decides what you predict: squared error gives the mean, absolute error the median, quantile loss a percentile.
Calibration is separate from ranking. It only matters when the number enters arithmetic — and then it matters completely.
An LLM's stated confidence is not a probability. Nothing in next-token training calibrates it against outcomes.
Monitor inputs, because outcomes arrive late. Feature distributions are the only early warning for a model whose labels are ninety days behind.
Log impressions, not just clicks. Without them you cannot distinguish "not wanted" from "never shown", which is how ranking feedback loops close.
Rising engagement with falling coverage is a loop, not a win.
Labels and structure mean train a model; no labels and unstructured input mean start with an LLM. The strongest systems use both, each where it has an advantage.

[i] Vocabulary check

You should be able to explain: supervised versus unsupervised, self-supervised, loss function, generalisation, feature engineering, label noise, underfitting, overfitting, bias, variance, irreducible error, double descent, L1 and L2 regularisation, early stopping, train/validation/test, k-fold cross-validation, data leakage, target leakage, bagging, boosting, permutation importance, PCA, k-means, confusion matrix, precision, recall, F1, ROC-AUC, PR-AUC, MAE, RMSE, quantile loss, calibration, Brier score, Platt scaling, isotonic regression, data drift, concept drift, and inverse propensity weighting.

18.22 Interview drills

ML questions in an engineering interview are mostly checking whether you can be trusted not to fool yourself. The strongest answers name the failure mode before being asked about it.

1. Explain overfitting to a non-technical stakeholder.

It's the difference between a student who understood the subject and one who memorised last year's exam paper. Both score perfectly on that paper; only one handles this year's questions.

Technically, the model has enough flexibility to fit the noise in the training data rather than the underlying pattern. I detect it by holding data back and comparing: in a recent case training AUC was 1.0 and test AUC was 0.85, and that gap is the overfitting. The fixes are more data, a simpler model, or regularisation, which penalises complexity so the model has to earn each bit of flexibility.

2. Our model is 99% accurate. Should we ship it?

My first question is the class balance. If the positive class is 1%, then a model that always predicts "no" is also 99% accurate and catches nothing — so accuracy alone tells me almost nothing.

I'd want the confusion matrix, precision and recall at the operating threshold, and PR-AUC rather than ROC-AUC, because ROC flatters imbalanced problems — its false positive rate has a huge denominator, so thousands of false alarms barely move it. On one dataset I worked with, ROC-AUC was 0.85 while PR-AUC was 0.62, and the second number is the one that reflects what the review team actually experiences.

3. What is data leakage and how do you catch it?

Information reaching the model that won't exist at prediction time. It's the worst error in applied ML because it makes every metric look excellent — there's no warning sign, since the metrics themselves are contaminated. The model only fails in production.

I demonstrated this once on pure noise: 200 rows, 5,000 random features, coin-flip labels. Selecting the best features on the full dataset and then cross-validating gave 79.5% accuracy on data with no signal at all. Doing the selection inside the pipeline gave 51%, which is the truth. So the rule is that every step which learns anything — scaling, imputation, encoding, selection — goes inside the pipeline. Beyond that I check for target leakage, where a feature is a consequence of the outcome, temporal leakage from windows that include the prediction date, and duplicate rows across splits. My heuristic is that a suspiciously good result is a leakage hypothesis until proven otherwise.

4. How do you choose between precision and recall?

From the cost of each error, which is a business question rather than a modelling one. Precision matters when false positives are expensive; recall matters when misses are.

The important framing is that it's a threshold choice on one model, not two different models. The same classifier gave me precision 1.0 at recall 0.30, and precision 0.38 at recall 0.66, just by moving the cut-off. So I'd ship the probability and let the threshold be configuration. If the costs can be quantified — say a miss costs forty pounds and a false alarm two — I'd skip the standard metrics entirely and optimise expected cost, because no off-the-shelf metric encodes that ratio.

5. What is calibration, and when do you care?

A model is calibrated if, among the cases it scores 0.7, roughly 70% really are positive. It's independent of ranking ability — a model can order cases perfectly and still have completely wrong probabilities.

I don't care if I'm only sorting, like ranking search results. I care enormously the moment the number enters arithmetic: multiplying by order value to get expected loss, combining several models, or showing confidence to a user. Logistic regression is calibrated by construction; forests get pulled toward the middle, and boosted trees and neural nets are usually overconfident. The fix is Platt scaling or isotonic regression on held-out data, which changes the probabilities without touching the ranking. It's also why an LLM saying "90% confident" isn't a probability — nothing in its training calibrated that against outcomes.

6. Why not just use a neural network for everything?

For tabular data, gradient-boosted trees usually win, and it's not close. Trees split on thresholds, so they handle mixed types, skewed distributions, non-linear cut-offs and missing values natively, with no scaling. A network has to learn all of that from data you typically don't have enough of.

Networks win where the structure is in the input itself — text, images, audio — because that's where representation learning pays off. So I'd pick by data shape rather than by what's fashionable. There's also an operational argument: a boosted model trains in minutes on a CPU and is straightforward to serve, which matters more than two points of AUC on most projects.

7. How would you split data for a model predicting next month's demand?

Chronologically, never randomly. A random split lets the model train on December and predict November, which is learning from the future — it will look excellent and fail immediately in production.

So train on the earlier period, validate on the next, test on the most recent, which mirrors how it will actually run. For cross-validation I'd use rolling-origin splits that only ever validate forward. I'd also check features for temporal leakage — any aggregate computed over a window that includes the prediction date is a leak — and be careful that seasonality doesn't make one fold structurally harder than another, which shows up as high variance across folds.

8. The model performed well for three months, then degraded. What happened?

Three candidates, and I'd check them in order of likelihood. Upstream drift first — a pipeline change, a unit change, a field that started arriving null. That's the most common cause and the easiest to confirm with schema and range checks.

Then data drift, where the inputs shifted: a new market, a new category, an app redesign changing behaviour. I'd compare current feature distributions against training. Then concept drift, where the relationship itself changed — fraud patterns adapting, for instance — which is hardest because it needs outcomes, and those arrive late. That delay is the real lesson: if labels take ninety days, output monitoring tells me about a problem a quarter after it started, so input monitoring is what actually protects me.

9. Your recommendation model's CTR keeps improving. Is that good?

Possibly, but I'd want to see catalogue coverage alongside it, because steadily rising CTR with falling coverage is the signature of a feedback loop rather than a better model.

The mechanism: the model decides what's shown, users click what they saw, and those clicks train the next model. A product ranked highly keeps getting impressions and looks popular; a genuinely better product ranked 40th never gets shown, so it looks unpopular to every future model. The system is learning what it previously promoted. Fixes are logging impressions and not just clicks, injecting a small amount of exploration, weighting by inverse propensity, and tracking what fraction of the catalogue is ever surfaced.

10. When would you use classical ML over an LLM?

When I have labels and structured features. A boosted model will be cheaper by orders of magnitude, faster by orders of magnitude, more accurate on tabular data, deterministic, and auditable. Serialising a spreadsheet into a prompt to classify it is an expensive way to do something a tree does in microseconds.

I'd reach for an LLM when the input is unstructured and I have no labels, where zero-shot capability is genuinely transformative. A good middle path is using the LLM to bootstrap labels, then training a small model once volume justifies it. In practice strong systems are hybrids — in the search platform we've been building, embeddings and a cross-encoder do retrieval, an LLM does generation, and a gradient-boosted model handles business ranking. Each is there for a property the others lack.

11. Explain the bias-variance trade-off.

Bias is error from the model being too rigid to represent the truth — a straight line through curved data, where more data won't help. Variance is sensitivity to the particular sample: retrain on different data and you get a noticeably different model, and there more data does help.

Classically, increasing complexity lowers bias and raises variance, so there's a sweet spot. That's a good guide for tabular models. I'd add that it's incomplete for very large models — over-parameterised networks routinely fit the training data exactly and still generalise, the double descent phenomenon, where test error falls again beyond where classical theory says it should rise. So I use the classical framing for the models I'm tuning and don't treat it as a universal law.

12. A stakeholder wants to know which feature drives churn. Your model says tenure is most important.

I'd be careful with the word "drives". Feature importance tells me what the model used to make predictions, not what causes the outcome — and the stakeholder is about to make an intervention decision, which requires causation.

There are also technical caveats: built-in importances are biased toward high-cardinality features and split arbitrarily between correlated ones, so I'd use permutation importance or SHAP instead. But the real answer is that if they want to know whether changing something reduces churn, that's an experiment, not a model inspection. I'd propose an intervention on a randomised subset and measure it, which is the only design that balances the confounders nobody thought of.

Where this leaves you

You can now build a model and, more importantly, tell whether it is any good — which turns out to be mostly a discipline of not fooling yourself. Leakage, imbalance, uncalibrated probabilities and feedback loops all produce excellent-looking numbers attached to a system that does not work.

Every check in this chapter, though, was offline. The last chapter takes the same statistical machinery onto live traffic, where the arithmetic is identical and everything operational is harder.