What Is Machine Learning?

1. The one-sentence intuition

Machine learning is writing a program by showing it examples instead of typing the rules by hand. You don't code if email contains "viagra" then spam; you collect 100,000 emails labeled spam/not-spam and let an algorithm fit a function that maps email → label. The "code" is a big pile of numbers (the model's parameters) that got tuned to match your examples. As a SWE: it's like having a fuzzy spec and an enormous test suite, and a compiler that searches for any implementation that passes the tests — except the artifact it produces is a numeric function, not source you'd read.

The catch — and the entire field, really — is this: passing the tests you showed it is easy. The job is making it work on inputs it has never seen.

2. Why a software engineer needs this

Every pillar downstream of here is ML wearing a costume:

• Transformers / LLMs (/transformers) are one giant learned function. "It's just predicting the next token" only means something once you know what learning a function from data is.
• Fine-tuning (/finetuning) = continuing the training process on your own examples. You can't reason about LoRA, SFT, or DPO without the train/validate/test and overfitting vocabulary from this lesson.
• RAG (/rag) leans on embeddings — vectors that come out of a self-supervised model. "Why does cosine similarity find related docs?" is an ML question.
• Evals (/evals) are literally the test set from this lesson, formalized. Every "our agent scores 82%" claim is a generalization claim.

Interviews silently assume you can say, in plain English, what supervised vs. self-supervised learning is, why we hold out a test set, and what overfitting looks like. Get these wrong and you sound like someone who has only used the API, never understood the machine. This lesson is the map; the rest of /ml-foundations fills in the territory.

3. Build it up from scratch

3.1 Programming vs. learning

Nobody can write the if/else for "is this photo a cat" or "is this the right next word." There are too many cases and no crisp rule. So instead we pick a flexible function with knobs and turn the knobs until it matches examples. That's it.

3.2 The core objects: features, labels, model, parameters

• Features (x): the input, as numbers. A house is [sqft, bedrooms, zip]; an image is a grid of pixel values; text becomes token IDs. Turning raw stuff into useful numbers is feature engineering (deep learning automates much of it).
• Label (y): the answer you want — a price, a category, the next word.
• Model (f): the function shape, e.g. a line, a tree, a neural network.
• Parameters (θ, "theta"): the knobs inside f that learning adjusts. A linear model f(x) = w·x + b has parameters w (weights) and b (bias); GPT-class models have hundreds of billions.

The model with its knobs set is written f_θ — "f parameterized by θ." Learning = finding good θ.

3.3 The four kinds of learning

The flavors differ only in what kind of examples (supervision signal) you get.

• Supervised is the workhorse: classification (discrete label — cat/dog, spam/ham) and regression (continuous label — a price, a temperature). Most "ML 101" is here.
• Unsupervised finds structure with no answer key: clustering (group similar items, e.g. k-means) and dimensionality reduction (compress features, e.g. PCA).
• Self-supervised is the trick that powers modern AI. There's no human labeling 10 trillion words. Instead you take raw text and manufacture a supervised problem from it for free: "the cat sat on the ___" → label is mat. The input and the label both come from the same sentence. Do this billions of times and the model learns grammar, facts, and reasoning as a side effect of getting good at filling blanks. This is pretraining.
• Reinforcement learning has no fixed answer key — only a reward that says how good an outcome was. The model takes actions, gets scored, and shifts toward actions that earn more reward. Great for sequential decisions (games, robotics, agents).

Which one do LLMs use? Both, in stages. First self-supervised pretraining (next-token prediction over the internet) to learn language and world knowledge. Then post-training to make it a helpful assistant, classically via RLHF — Reinforcement Learning from Human Feedback: humans rank model answers, that trains a reward model, and RL nudges the LLM toward higher-reward (more helpful, less harmful) responses. So a chatbot is self-supervised pretraining plus an RL-style alignment step. You'll go deep on this in /finetuning.

3.4 Training vs. inference

Two distinct phases, and conflating them is a classic beginner error:

• Training (offline, expensive, once-ish): show examples, adjust θ to reduce error. This is where GPUs burn for weeks.
• Inference (online, cheap-ish, every request): freeze θ, feed a new x, read off f_θ(x). Every time you call an LLM API, you're doing inference; the parameters don't change.

Think compile-time vs. run-time. Training is the slow build that bakes the artifact; inference is calling the built binary.

3.5 The minimal math: a loss and an objective

To "turn the knobs," you need a number that says how wrong the model currently is. That's the loss function L. For regression, a standard choice is squared error: L(ŷ, y) = (ŷ − y)², where ŷ = f_θ(x) is the prediction ("y-hat") and y is the truth. Squaring makes all errors positive and punishes big misses harder.

Learning is then an optimization problem — find the θ that minimizes average loss over your N training examples:

θ* = argmin_θ  (1/N) Σᵢ L( f_θ(xᵢ), yᵢ )

Reading it symbol by symbol: argmin_θ = "the θ that makes the following smallest"; Σᵢ = "sum over training examples i = 1..N"; (xᵢ, yᵢ) = the i-th example's features and label; f_θ(xᵢ) = the model's prediction for it. The quantity being minimized — average loss on the training set — is called the training error (a.k.a. empirical risk). How you actually find θ* is gradient descent, the subject of /how-models-learn; here just hold the idea "search for knob settings that make the loss small."

3.6 Generalization is the whole game

Here's the twist. You don't actually care about training error. You care about loss on future, unseen data drawn from the same source — the generalization error. Minimizing training error is only a proxy; a model can ace the training set and be useless on anything new, the way code can pass exactly the tests you wrote and break in production.

To estimate the thing you actually care about, split your data before training:

A hyperparameter is a setting you choose, not something learned — model size, how long to train, regularization strength. You tune those by checking the validation set. The test set is sacred: you look at it once, at the end. The reason for three splits and not two: the moment you use a set to make decisions, you start (subtly) fitting to it. Validation absorbs that contamination so the test set stays an uncontaminated estimate of real-world performance. Reusing the test set to pick models is data leakage, and it's why a "95% accurate" model can faceplant in production. (More in /ml-foundations/evaluation-and-data.)

3.7 Overfitting, underfitting, and the bias–variance tradeoff

Watch the gap between training error and validation error:

• Underfitting (high bias): the model is too simple to capture the pattern. Training error is high and validation error is high too. It's a straight line trying to trace a curve. The model has a strong, wrong bias about the shape of the world.
• Overfitting (high variance): the model is too flexible and memorizes the training examples including their noise. Training error is near zero, but validation error is high. Change a few training points and the fit swings wildly — that sensitivity is variance.
• Just right: both errors are low and close together.

This is the bias–variance tradeoff. Conceptually, expected test error decomposes as:

expected test error  ≈  bias²  +  variance  +  irreducible noise

bias = error from wrong assumptions (too simple); variance = error from over-sensitivity to the particular training sample (too complex); irreducible noise = randomness no model can remove. Make the model more powerful → bias drops but variance rises; simplify it → the reverse. The sweet spot minimizes the sum. (Modern very-large nets complicate this picture, but the intuition is the right starting mental model — and exactly what interviewers want.)

The cure for overfitting is regularization — anything that discourages the model from memorizing. The intuition: penalize complexity so the model prefers the simplest explanation that fits (Occam's razor, enforced numerically). Common forms: L2/weight decay (add a penalty for large weights, so it can't contort wildly), dropout (randomly silence neurons during training so it can't rely on any single one), early stopping (quit when validation error starts climbing), and the cheapest cure of all — more data. We'll make this concrete in /how-models-learn.

3.8 Worked micro-example

You want to learn y = sin(x), but you only get 12 noisy training points. Fit polynomials of different complexity and compare training vs. test error (test = many clean points). Real output from the code in §4:

The degree-11 polynomial threads exactly through all 12 noisy dots (train MSE = 0.000) — and pays for it, wiggling between them and doing worse on unseen points than the simple degree-3 fit. That single table is the whole lesson: low training error is not the goal; low error on data you haven't seen is.

4. See it in code

A complete, runnable demonstration of underfit → good → overfit in ~15 lines of NumPy.

import numpy as np
 
rng = np.random.default_rng(0)
 
# The TRUE relationship we want to learn. In real life we never get to see this —
# we only see noisy samples of it.
def true_fn(x):
    return np.sin(x)
 
# Training set: 12 points, each corrupted by random noise (std 0.3).
x_train = np.linspace(0, 2 * np.pi, 12)
y_train = true_fn(x_train) + rng.normal(0, 0.3, size=x_train.shape)
 
# Test set: 200 CLEAN points the model never trains on — our generalization probe.
x_test = np.linspace(0, 2 * np.pi, 200)
y_test = true_fn(x_test)
 
def fit_and_score(degree):
    coeffs = np.polyfit(x_train, y_train, degree)   # TRAINING: tune parameters on train data only
    f = np.poly1d(coeffs)                           # the learned function f_θ
    train_mse = np.mean((f(x_train) - y_train) ** 2)  # error on data it has seen
    test_mse  = np.mean((f(x_test)  - y_test)  ** 2)  # error on data it has NOT seen
    return train_mse, test_mse
 
for degree in (1, 3, 11):
    tr, te = fit_and_score(degree)
    print(f"degree={degree:2d}  train_mse={tr:.3f}  test_mse={te:.3f}")

Line by line: true_fn is the hidden pattern. y_train adds noise — the model must not trust it too literally. np.polyfit(x, y, degree) is the entire training step: it finds polynomial coefficients (the parameters θ) minimizing squared error on the training data — that's §3.5's argmin in one call. degree is the hyperparameter controlling model flexibility. We then score on train and on a held-out test set. Running it reproduces the table above: as degree climbs, train error marches to zero while test error bottoms out at degree 3 and then rises — overfitting, made visible.

5. Mental models & SWE analogies

• Training ≈ compile time, inference ≈ run time. Training bakes the artifact (slow, once); inference runs it (fast, every request). API calls to an LLM are pure inference — the weights are frozen.
• The model is a learned, lossy function — and parameters are its "config" baked from data. Not handwritten config; config discovered by fitting examples.
• The test set is production traffic you're forbidden to peek at. Tune on staging (validation); ship and measure on prod (test). Peeking early = data leakage = a green dashboard that lies.
• Overfitting ≈ hardcoding to your test cases. A function that special-cases every input in your test suite passes CI and breaks on the first real user. Regularization is the linter that says "stop hardcoding, write the general solution."
• Loss ≈ a fitness/cost metric the optimizer descends. Lower is better; learning is search for parameters that minimize it. (The gradient — which direction reduces loss — is the next lesson.)

6. Common confusions

• "More training accuracy is always better." No — past a point it means memorization. Watch the train-vs-validation gap, not training error alone.
• "AI = ML = deep learning = LLMs." Nested, not equal. AI ⊃ ML ⊃ deep learning (neural nets) ⊃ LLMs. ML is the part where systems learn from data; the rest are subsets.
• "The model keeps learning as I use it." Almost never at inference. A deployed LLM has frozen weights; it doesn't remember your last chat unless you re-feed it as context. Updating weights requires a new training run.
• "Unsupervised and self-supervised are the same." Both use unlabeled data, but self-supervised manufactures a supervised task (predict the hidden word) and trains on it — that's why LLMs learn so much from raw text.
• "LLMs are trained with reinforcement learning." Only the alignment stage (RLHF). The heavy lifting is self-supervised next-token prediction; RL is a comparatively thin finishing layer.
• "Features and parameters are the same thing." Features are the input (x); parameters are the learned knobs (θ) inside the model.
• "Regularization makes the model more accurate." It usually raises training error on purpose — trading a bit of fit for better generalization.

7. Check yourself

8. Go deeper

• Stanford CS229 — Machine Learning (cs229.stanford.edu): the canonical supervised/unsupervised treatment; notes 1–2 cover exactly this framing.
• Stanford CS231n — Image Classification intro (cs231n.github.io/classification): the clearest "data-driven approach vs. writing rules" explanation, plus train/val/test discipline.
• Dive into Deep Learning — Generalization (d2l.ai): free, runnable chapter on overfitting, underfitting, and model selection.
• Goodfellow, Bengio & Courville — Deep Learning, Ch. 5 (deeplearningbook.org): the rigorous reference for capacity, bias–variance, and regularization.
• scikit-learn — Cross-validation (scikit-learn.org): practical, code-first take on why and how we hold data out.

Next: /ml-foundations/math-for-ml — the vectors, matrices, derivatives, and probability you'll lean on everywhere — then /ml-foundations/how-models-learn, where gradient descent actually turns the knobs.