ML Fundamentals
Learn machine learning fundamentals: supervised and unsupervised learning, model types, and core ML concepts.
What is machine learning?
Machine learning is a way to build software that learns a useful pattern from examples. Instead of writing every decision rule by hand, a team defines what should be predicted, provides representative evidence, and trains a model to map inputs to an output.
ML matters when the pattern is valuable but too complex or changeable to maintain as explicit rules. It also changes the engineering contract: behavior depends on data, feature definitions, model parameters, and decision policy, so quality must be measured on unseen cases and monitored after deployment.
The core invariant is generalization. A model is useful when it performs well on representative examples it did not train on, not when it merely remembers the training set.
A prediction has four moving parts
Evidence
Data
Features describe each case. Labels or observed outcomes provide the signal the system should learn. Coverage and correctness set an upper bound on useful quality.
Representation
Model
A parameterized function converts features into a value, category, score, ordering, or generated output.
Learning
Training
An optimization process compares predictions with an objective and adjusts parameters to reduce error on training examples.
Decision
Inference
The trained model processes a new input. Product policy turns its output and uncertainty into an action.
These parts form one versioned behavior. Changing a feature definition while keeping the same model can be just as dangerous as deploying incompatible code.
Learning modes answer different questions
Known target
Supervised learning
Learn from input-target pairs. Use it for outcomes such as delivery time, fraud status, demand, or relevance when trustworthy labels can be defined.
No target label
Unsupervised learning
Find structure in inputs without one correct target per example. Common goals include grouping similar cases, compressing representations, and finding unusual patterns.
Sequential reward
Reinforcement learning
Learn a policy from actions, outcomes, and delayed reward. The action changes what happens next, so exploration and long-term consequences matter.
This lesson concentrates on supervised learning because its explicit targets make the basic contracts easiest to see. The same discipline still applies elsewhere: define the evidence, objective, action, and evaluation boundary before selecting an algorithm.
Match the model output to the product decision
In supervised learning, the target shape determines the task family. The output only becomes useful when a product can turn it into a bounded action.
- Regression predicts a continuous value such as price, duration, or demand.
- Classification predicts a category or class probability such as fraud versus legitimate.
- Ranking orders candidates by expected relevance, utility, or risk.
- Forecasting predicts values over time and must respect temporal order when splitting data.
Define the prediction contract before choosing a model
A complete contract names:
- the prediction unit;
- the target and how its label is observed;
- the moment the prediction is needed;
- the features available at that moment;
- the product action and the cost of mistakes.
A feature that is created after the prediction moment leaks future information. It can make offline evaluation look excellent while making the production model impossible to reproduce.
Training is an experiment, not the finish line
1 Frame
Define the decision
Name the unit, target, prediction time, action, baseline, and unacceptable mistakes before collecting model features.
2 Split
Build protected evidence
Create training, validation, and test boundaries that prevent the same entity, future event, or duplicate example from leaking across splits.
3 Train
Fit and compare
Optimize on training data, use validation data for model decisions, and compare every candidate with a simple baseline.
4 Operate
Release with limits
Evaluate important slices, latency, and failures; then use shadow or canary traffic before letting predictions control the full workflow.
Keep evaluation roles separate
- Training set: changes the model parameters.
- Validation set: supports choices such as features, model family, thresholds, and stopping point.
- Test set: provides a final estimate after those choices are frozen.
- Production slices: reveal populations, time periods, or operating conditions hidden by one aggregate score.
Repeatedly choosing a model based on test results turns the test set into another validation set. Preserve a genuinely untouched boundary when an unbiased final estimate matters.
Generalization exposes underfitting, overfitting, and shift
Training error alone cannot show whether a learned pattern transfers. Compare training behavior with representative unseen behavior and inspect the gap together with the absolute quality of both.
Too little useful fit
Underfitting
Training and unseen quality are both weak. Improve signal, features, optimization, or capacity one controlled step at a time.
Fit does not transfer
Overfitting
Training quality is strong while unseen quality lags. Try simpler capacity, regularization, early stopping, or more representative data.
The population changed
Distribution shift
The deployment population differs from the evaluation evidence. Report important slices and update the data boundary before trusting one aggregate metric.
Choose metrics from the cost of mistakes
One metric rarely describes the whole product decision. Start with the failure costs, then choose measurements and thresholds that expose them.
How far off?
Regression errors
MAE gives each absolute error equal weight. RMSE emphasizes large errors. Report domain units and important slices so a good average cannot hide costly misses.
Which mistake?
Classification errors
Precision describes how often positive predictions are right; recall describes how many actual positives are found. The decision threshold trades one mistake type against the other.
Where is relevance?
Ranking errors
Metrics such as precision at K or NDCG emphasize the positions users actually inspect. Online outcomes still need guardrails against feedback loops and position bias.
Evaluate more than predictive quality
- Calibration: does a predicted probability of 0.8 correspond to the event occurring about 80% of the time for comparable cases?
- Slice quality: do regions, devices, languages, or user groups experience materially different error rates?
- System behavior: does inference meet latency, throughput, availability, and cost targets?
- Safety and policy: can the workflow defer, abstain, fall back, or request human review when confidence or evidence is insufficient?
Prefer rules when uncertainty adds no value
Deterministic
Start with rules
Use explicit logic when rules are stable, exact explanation is required, and the cases remain practical to maintain directly.
Learned pattern
Consider ML
Use ML when representative examples reveal a repeatable signal, error can be measured, and better predictions create enough value to fund ongoing operation.
Missing foundation
Stop and reframe
Do not proceed without a measurable target, an actionable output, representative evidence, a baseline, and a plan for high-cost mistakes.
An ML prototype is not automatically an ML product. If a heuristic meets the product target with lower operational risk, it is the stronger system design.
Production ML versions behavior and evidence together
Behavior has multiple versions
Code, feature definitions, training data, model artifacts, and thresholds must remain compatible. A rollback restores the complete working set.
Tests become statistical
Unit and integration tests still matter, but learned behavior also needs protected holdouts, confidence ranges, slice analysis, and invariant checks.
Predictions create feedback
Model decisions influence which items users see and which labels arrive later. Exposure and selection bias can reinforce the current policy.
Quality shares the budget
A useful model must also satisfy latency, throughput, cost, privacy, fairness, reliability, and maintainability constraints.
Continue with ML Problem Framing to turn a product decision into measurable objectives, baselines, and launch criteria.
Budget for the work around the model
- Data operations: collection, labeling, validation, backfills, lineage, retention, and access control continue after the first training run.
- Experimentation: compute, artifact storage, reproducibility, and comparison infrastructure grow with every candidate.
- Serving: inference needs packaging, capacity planning, fallback behavior, and feature compatibility.
- Monitoring: teams must observe inputs, drift, outputs, user outcomes, and system health together.
- Incident response: silent quality regressions need explicit owners, thresholds, evidence capture, and rollback playbooks.
Start with the simplest baseline that can be shipped and measured. Reliable evidence and operations usually create more value than sophistication whose failure modes are invisible.