Machine Learning

Machine learning is often described informally as teaching computers to improve at a task by exposure to data rather than through explicit, hand-written rules, but the field also has a precise, widely cited formal definition. In his 1997 textbook Machine Learning, Carnegie Mellon professor Tom Mitchell wrote: 'A computer program is said to learn from experience E with respect to some class of tasks T and performance measure P, if its performance at tasks in T, as measured by P, improves with experience E.' This definition is useful precisely because it forces a designer to be specific about three things before calling a system a learner: what the task actually is, how success on that task will be measured, and what data or interaction the program will learn from. Consider a spam-filtering program: the task T is classifying incoming emails as spam or not spam, the performance measure P is the percentage of emails correctly classified, and the experience E is a set of emails that a user has hand-labeled as spam or not spam over time. If the fraction of correctly classified emails rises as the program processes more labeled examples, then by Mitchell's definition, the program is learning. This E, T, P framework generalizes across nearly every machine learning system, from image recognizers to game-playing agents, and is still taught as the canonical starting point in introductory machine learning courses.

Once a problem has been framed in terms of experience, task, and performance measure, the next question is what kind of experience E the learner receives, and this is how the field divides into its major paradigms. In supervised learning, the experience consists of a training set of labeled examples, that is, pairs of an input x and its correct output y, and the Stanford CS229 lecture notes formalize the goal as learning a function h, called a hypothesis, that maps inputs to outputs so that h(x) is a good predictor of the true y for new, unseen inputs. When the output y is a continuous quantity, such as predicting a house's sale price from its square footage and location, CS229's notes call this a regression problem; when y takes on a small number of discrete categories, such as labeling an email as spam or not spam, it is called a classification problem. Supervised learning is by far the most widely deployed paradigm in industry today because labeled data directly encodes the exact behavior a model should reproduce, which makes both training and evaluation straightforward compared to settings where correct answers are not provided.

The other two paradigms remove the labels or the notion of a single correct answer entirely. In unsupervised learning, the experience E consists only of unlabeled inputs, and the learning algorithm's task is to find useful structure in the data on its own, for example grouping customers into clusters of similar purchasing behavior without being told in advance what the groups should be, or reducing many correlated variables down to a smaller set of dimensions that still capture most of the underlying variation. Reinforcement learning is different again: an agent interacts with an environment over a sequence of time steps, choosing actions and receiving reward signals rather than being told the correct action directly, and its experience E is this stream of state-action-reward interactions rather than a fixed dataset prepared in advance. A classic reinforcement learning example is an agent learning to play a board game by playing many games against itself, receiving a positive reward for winning and a negative reward for losing, and gradually adjusting its strategy, or policy, to increase the reward it collects over time. Stanford's CS229 curriculum devotes dedicated sections to each of these three paradigms, supervised learning, unsupervised learning, and reinforcement learning and control, reflecting how central this three-way division is to how the discipline is organized and taught.

Once a model has learned from data, a critical question arises: how do we know whether it will perform well on new examples it has never seen, rather than merely memorizing the examples it was trained on? The standard solution, described in Google's Machine Learning Crash Course, is to split the available data into three disjoint subsets: a training set that the model actually learns from, a validation set that performs initial testing on the model as it is being developed and tuned, and a test set reserved for a final evaluation of the trained model. The reasoning behind this three-way split is that testing on examples different from the ones used for training is a much stronger proof of a model's fitness than testing on the same data it was trained on, since a model can trivially achieve perfect performance on data it has already memorized. Google's course further explains why a validation set is needed in addition to a test set: if a developer repeatedly tunes a model and checks its performance directly against the test set, the model configuration will gradually be shaped to fit that particular test set, a problem informally described as teaching to the test, so the validation set absorbs this repeated tuning while the test set is touched only once, at the very end, to give an unbiased estimate of real-world performance.

This evaluation methodology exists because of two closely related failure modes: underfitting and overfitting. Underfitting occurs when a model is too simple to capture the true underlying pattern in the data, so it performs poorly even on the training set itself; a straight line fit to data that clearly follows a curve is a typical example. Overfitting is the opposite and more common failure in practice: a model becomes so flexible that it starts fitting the noise and idiosyncrasies of the particular training examples it saw, achieving very low training error while generalizing poorly to new data, which shows up as a large gap between training performance and validation or test performance. Google's Machine Learning Crash Course material on generalization frames this directly around the training, validation, and test split described above, since it is only by checking performance on held-out data that overfitting can be detected at all; a model's training error alone cannot reveal it.

The formal explanation for why models underfit or overfit is given by the bias-variance tradeoff, a concept developed in detail in Stanford CS229's supplementary notes on the topic. Bias refers to the systematic error that arises when a learning method is not flexible enough to represent the true relationship between inputs and outputs, so even with unlimited training data, a high-bias model such as an overly simple straight-line fit will consistently miss real patterns, which is the mathematical signature of underfitting. Variance, by contrast, refers to how much the fitted model would change if it were trained on a different random sample of training data drawn from the same underlying distribution; a high-variance model is one whose learned parameters swing wildly from one training set to another because it is flexible enough to chase the specific noise in whichever sample it happened to see, and this instability is the signature of overfitting. CS229's notes decompose a model's expected prediction error at a given point into three terms, an irreducible noise term, the squared bias, and the variance, showing formally that reducing bias by adding model complexity tends to increase variance, and vice versa, which is why the two cannot generally be minimized simultaneously. Practitioners manage this tradeoff by monitoring training and validation performance together: a large gap where training error is low but validation error is high signals high variance and overfitting, while uniformly poor performance on both signals high bias and underfitting, guiding decisions such as adding more training data, simplifying the model, or applying regularization.