Kiran Kumar
Modeling of patterns for prediction
In the previous post, the collection and analysis of data was used to confirm a pattern worth pursuing, and a hypothesis driven exploration kept that search honest and grounded in the original question rather than in whatever the data happened to show. This post picks up right where that one left off: a pattern has been found and validated well enough to trust for now, and the task is to turn it into a model that can produce a prediction for a record it has never seen.
Modeling of patterns for prediction is really a decision making exercise before it is a coding exercise. A data scientist has to choose how complex a model should be, how to know whether the model has actually learned the pattern rather than memorized the training data, and how to balance accuracy against the practical needs of the people who will act on the prediction. This post works through those choices at a conceptual level and sets up the next two posts, which go deeper into numerical methods for reducing error and into qualitative, rule based modeling.
- Hypothesis
- Measurement variables
- Latent or unobservable factors
- Experimental design (0 to 1)
- Collection and analysis of data for pattern discovery
- Modeling of patterns for prediction (discussed here)
- Generalizing or scaling the experiment (1 to n)
- Establishing a baseline
- Monitoring through controls and baselines
- Ethics and governance
From pattern to model
The previous step in this series, collection and analysis of data for pattern discovery, produced something narrower than a full model: a pattern, backed by a hypothesis driven exploration, that seems to hold up in the data collected so far. A pattern is a description. A model is a function. The difference matters. A pattern such as "claims filed on a Friday afternoon have a higher rate of misrepresentation" or "patients discharged without a follow up appointment scheduled return to the hospital more often" is a useful observation, but it does not, by itself, produce a number a business can act on for a specific new case. Modeling is the step of turning that observation into $\hat{y} = f(x)$, a function that takes the measurement variables identified earlier in the series and produces a prediction for records the function has not seen before.
Everything covered in this post, choosing a model class, checking that the model generalizes, splitting data properly, and reasoning about bias and variance, exists to answer one question: will $f(x)$ still be useful once it leaves the data set it was built on.
Choosing a model class
A model class is a family of functions with a particular shape: a straight line, a small set of if then rules, a tree, an ensemble of trees, or a network of nonlinear units stacked in layers. Picking a class is the first real decision in modeling, and it is easy to treat it as a purely technical choice when it is really a tradeoff among several things a data scientist cares about at once: accuracy, interpretability, the amount of data available, how the model will be maintained, and who has to trust its output.
Simple, interpretable models
Linear regression, logistic regression, and short decision lists or trees are simple in the sense that a person can trace, by hand, how an input became an output. Logistic regression, for example, produces a prediction of the form
$$ P(y=1 \mid x) = \frac{1}{1 + e^{-(\beta_0 + \beta_1 x_1 + \beta_2 x_2 + \cdots + \beta_p x_p)}} $$
and each coefficient $\beta_i$ has a plain reading: holding everything else constant, an increase in $x_i$ raises or lowers the odds of the outcome by a fixed, quotable amount. A short decision list, such as "if prior admissions in the last year is greater than two, and age is over 65, flag as high risk, otherwise check the next rule", is even easier to explain out loud, since it reads like a checklist rather than an equation.
The strength of these models is not that they are more accurate. Often they are not. Their strength is that a domain expert, an auditor, or a regulator can inspect the reasoning and agree or disagree with it on its own terms, and that the model degrades gracefully. A missing or noisy input tends to produce a small, explainable shift in the prediction rather than an unpredictable one.
Complex, flexible models
Gradient boosted trees, random forests, and neural networks sit at the other end of the spectrum. They can represent interactions and nonlinear relationships that a linear model cannot: the effect of one variable can depend on the value of another in ways that would need dozens of hand built interaction terms to approximate with a simple model. This flexibility usually buys accuracy, particularly when the underlying pattern really is complicated, the data set is large, and the measurement variables interact with each other in ways not fully understood ahead of time.
The cost is that the reasoning inside the model becomes difficult, or impossible, to state in a sentence. Tools such as feature importance scores, partial dependence plots, or Shapley value explanations can approximate an explanation after the fact, but an approximation of an explanation is not the same as an explanation, and that distinction matters more in some settings than others.
Matching the model to the problem
A short set of questions tends to narrow the choice quickly:
- How much does an individual prediction need to be explained to the person acting on it, in the moment they are acting on it?
- Is the relationship among the measurement variables likely to be simple, or full of interactions that a linear model would need many hand built terms to approximate?
- How much data is available to fit a flexible model without it memorizing noise instead of signal?
- What is the cost of a wrong prediction, and does that cost fall on the same people who would need to trust the model's reasoning in order to act on it?
There is no universally right answer to these questions. The right model class is the one that fits the shape of this problem, not the one that scored highest on a leaderboard for a different problem.
Generalization and overfitting
What generalization means
A model that has generalized has captured the pattern rather than the particular data set the pattern was found in. Overfitting is the failure to generalize: the model has fit itself to the noise, quirks, and coincidences of the training data as if they were signal, and it will perform far worse on new data than its training performance suggests.
Overfitting is said to occur when a model achieves a low error on the data it was trained on by fitting details specific to that data set, details that do not repeat in new data, rather than by capturing the general pattern the training data was sampled from.
Why a perfect fit on training data can still fail in production
Consider a model with enough free parameters to draw an intricate boundary that separates every single training example correctly, including the mislabeled ones, the outliers, and the clusters that occurred only because of how the sample happened to be drawn. Training error for such a model can be pushed arbitrarily close to zero. None of that guarantees anything about a new record, because a new record was not part of the coincidence the model memorized. The model has, in a sense, learned the training set by heart rather than learned the rule the training set was an example of.
A classic illustration is fitting a polynomial curve to a handful of points. A straight line might miss some of the wiggle in the data, but a high degree polynomial can be made to pass through every single point exactly. The high degree curve has zero error on the points used to fit it and yet swings wildly between those points, producing wild predictions for any $x$ that was not one of the original points. Training error alone is a poor guide to how a model will behave once it is asked to predict on new data, and the gap between training error and future error is precisely what generalization measures.
Train, validation, and test splits
Why three sets, not one
If the only measurement available were error on the data the model was fit to, overfitting would be invisible. A model builder needs data that played no part in fitting the model to get an honest read on how it will perform once deployed. This is why data is commonly split into three parts that do not overlap, before any model is fit.
- Training set: used to fit the parameters of the model, whatever those are: the coefficients of a logistic regression, the splits of a tree, the weights of a network.
- Validation set: used to choose among model classes or tune settings that are not learned directly from the training data, such as how deep a tree is allowed to grow, how heavily a model is regularized, or which of several candidate model classes to prefer. Performance on the validation set guides these choices.
- Test set: held back and touched only once, at the very end, to report how the finally chosen model is expected to perform on new data. Because the test set played no role in fitting parameters or in choosing settings, it is the only one of the three that gives an unbiased estimate of future performance.
It is tempting to fit on training data and check performance on a single holdout set, then keep going back to that same holdout set every time a setting is adjusted or a model class is swapped. Doing that quietly turns the holdout set into a second training set: the choices are now shaped by how well they perform on it, so its performance number stops being a fair estimate of performance on data the model builder has genuinely never seen. The validation set absorbs that iterative tuning, and the test set stays clean for a final, honest check.
When data is scarce, k fold cross validation is a common way to reuse the training and validation split several times over different partitions of the data, averaging the result, while still keeping a separate test set untouched until the end.
A typical split in practice
A common starting point is something like sixty percent training, twenty percent validation, and twenty percent test, though the right split depends heavily on how much data is available. With millions of records, a much smaller percentage set aside for validation and test can still contain enough examples to give a stable estimate. With a few hundred records, that three part split can leave the test set too small to trust, which is another reason cross validation is popular for smaller problems.
The bias and variance tradeoff
The choice of model class and the discipline of a train, validation, and test split come together in one of the more useful mental models in the field: the bias and variance tradeoff. Error on new data can be thought of as coming from three sources.
$$ E\big[(y - \hat{f}(x))^2\big] = \text{Bias}\big[\hat{f}(x)\big]^2 + \text{Var}\big[\hat{f}(x)\big] + \sigma^2 $$
$\sigma^2$ is irreducible noise in the outcome itself, the part no model, however good, can predict away. The other two terms are the ones a data scientist has real control over, and they tend to move in opposite directions as a model class is made simpler or more flexible.
High bias: models that are too simple
Bias is the error that comes from a model class that is not flexible enough to represent the true pattern, no matter how much data it is given or how well its parameters are fit. A straight line fit to a genuinely curved relationship will have bias: more data will make the fitted line more stable, but it will not make a straight line curve. High bias shows up as a model that performs about the same, and not particularly well, on both the training set and the validation set. It is, informally, underfitting: the model has not even captured the pattern in the data it was trained on.
High variance: models that are too flexible
Variance is the error that comes from a model class flexible enough to fit the noise as well as the signal, so that small changes in which records happened to end up in the training set produce large changes in the fitted model. High variance shows up as a large gap between training performance and validation performance: the model looks excellent on the data it was fit to and noticeably worse on data it was not. This is overfitting from the previous section, restated in terms of variance.
Finding the sweet spot
Reducing bias, by moving to a more flexible model class or adding more informative measurement variables, usually raises variance. Reducing variance, by simplifying the model class, adding more training data, or regularizing the fitting process to penalize overly flexible solutions, usually raises bias. There is rarely a model class that minimizes both at once for a given problem and a given amount of data. The practical task is to find the point on that spectrum where the sum of bias and variance, not either one alone, is smallest for the problem at hand, and to use the validation set introduced above to locate that point empirically rather than by guessing.
The next post in this series, numerical analysis for error reduction, works through concrete techniques, regularization, ensembling, cross validation among them, for moving a model along this tradeoff deliberately rather than by accident.
Worked example: predicting 30 day hospital readmission risk
Framing the prediction problem
Consider a hospital that wants to predict, at the time of discharge, whether a patient is likely to be readmitted within 30 days. The pattern discovery step earlier in this series might already have surfaced a signal along the lines of "patients discharged without a scheduled follow up appointment, or with more than two prior admissions in the past year, return more often". The modeling task is to turn that pattern, plus whatever other measurement variables were identified (age, primary diagnosis, length of stay, medication count, prior admission history, social factors such as living alone), into $P(\text{readmitted within 30 days} \mid x)$ for each patient at the moment they leave the hospital.
Why a clinician facing team might choose a simpler model
A hospital could reasonably fit a gradient boosted tree model on this data and very likely get a higher area under the ROC curve than a logistic regression would produce. Readmission genuinely depends on interactions: an elderly patient with a complex diagnosis and no follow up appointment scheduled is at much higher risk than either factor alone would suggest, and a flexible model class is well suited to capturing exactly that kind of interaction.
Despite that, many hospital teams deliberately choose a simpler model, logistic regression or a short decision list with perhaps five or six conditions, for this particular use case. A few reasons recur.
- The people acting on the score are clinicians and discharge planners, not data scientists, and they are being asked to change their behavior, add a follow up call, schedule an earlier appointment, flag a case for a social worker, based on a number a machine produced. A clinician who can see that a score is high because of prior admission count and a missing follow up appointment can weigh that reasoning against their own read of the patient. A clinician handed a score with no accessible reasoning has much less basis to trust it, override it when their own judgment disagrees, or explain a decision to a patient or a colleague.
- Readmission scores influence real decisions with real consequences: extra monitoring, resource allocation, and sometimes billing and quality reporting. A simple model whose behavior can be audited by a hospital committee or a regulator is easier to certify and defend than a model whose reasoning is opaque even to the team that built it.
- The cost of a wrong prediction is asymmetric in a way that rewards interpretability: a missed high risk patient is a bigger problem than a slightly less accurate risk score, and a model whose mistakes can at least be understood and corrected for is often preferred over one whose mistakes are only visible in aggregate accuracy statistics.
Connecting the choice to bias, variance, and trust
This decision is a direct application of the bias and variance tradeoff. Logistic regression, as a model class, carries more bias for this problem: it cannot represent every interaction among prior admissions, diagnosis, and social factors the way a boosted tree can, so it will tend to underperform a flexible model on held out accuracy. What it gives up in bias it can make up for in lower variance and, more importantly here, in a form the clinician facing team can inspect, argue with, and adopt. The team is explicitly trading some accuracy, the part attributable to bias, for a model whose behavior is stable, explainable, and trusted enough to actually change how discharge planning happens.
That last point, trust, is easy to underweight in a purely technical read of the tradeoff. A highly accurate model that clinicians route around, second guess, or ignore produces close to zero value despite its lower error on a held out test set. The right choice of model class in a case like this one depends as much on who has to act on the prediction, and how much they need to understand it, as it does on the raw number that comes out of the validation set.
What comes next
This post has stayed at the level of the concepts every modeling exercise has to work through: pick a model class appropriate to the problem, make sure the model generalizes rather than memorizes, split data so that claim can actually be checked, and use the bias and variance tradeoff to reason about where a particular model sits on the spectrum between too simple and too flexible. The next two posts go one level deeper on each side of that spectrum. Numerical analysis for error reduction works through concrete techniques for moving a model along the bias and variance tradeoff deliberately. Qualitative modeling looks at the other kind of decision touched on in the hospital example: building and validating rule based or expert informed models when interpretability, not raw accuracy, is the primary requirement.