There is a moment in almost every ML project when a draft model exists — not production-ready, but trained, evaluated, and generating predictions on a held-out set.
Most teams respond to this moment by looking at the metrics. Accuracy, F1, AUC. The number looks reasonable. They move on to the next phase.
That is a mistake.
The metrics tell you how often the model is wrong. They do not tell you where it is wrong, why it is wrong, or what the pattern of its mistakes reveals about the data, the problem framing, and the assumptions you have been carrying silently since the project began.
That information lives in the errors themselves — and most teams never read it.
What error analysis actually is
Error analysis is not a metric. It is a practice: systematically reading the cases your model got wrong, looking for structure in the failures, and asking what that structure means.
In a classification task, this means going through false positives and false negatives — not a confusion matrix, but the actual rows. In a regression task, it means examining the highest-residual cases. In a ranking task, it means looking at what got promoted or buried that shouldn't have.
The question you are asking is always the same: is there a pattern here that I can learn from?
Not: can I tune my way out of this? Not: which hyperparameter is responsible? Those questions come later, if at all. The first question is what the errors are about.
What you will find
In my experience, error analysis on a draft model almost always surfaces something important. The findings tend to cluster into a few recurring categories.
Data preparation errors. Mislabeled examples. Duplicates with conflicting labels. Features that were joined incorrectly, producing values that look plausible but are subtly wrong. These errors are invisible at the aggregate level — the model's average performance is not dramatically affected — but they are highly concentrated in the worst predictions. Reading the errors is often the fastest way to find them.
New feature ideas. A cluster of errors that share an obvious human-readable property — property the model has no variable for. The model struggles with a particular type of transaction, or a particular customer segment, because that distinction is not represented anywhere in the feature set. The error analysis names the gap. This is far more useful than running feature importance on the existing variables.
Reasons for outliers and unexpected behavior. Some errors are not mistakes — they are cases where the ground truth label is genuinely ambiguous, where the labeling policy was applied inconsistently, or where the example is legitimately unusual. Understanding which is which prevents wasted effort. You do not retrain your way out of labeling ambiguity.
Feature value segments that start to make sense. A continuous variable that behaves very differently above and below a threshold you had not considered. A categorical feature where two values that appear semantically similar turn out to be functionally distinct. The errors reveal the segmentation that the feature engineering missed.
None of these findings show up in the aggregate metrics. They require reading the cases.
Error analysis is a meeting
This is the part most teams skip entirely — and where, in my experience, the highest-value insights tend to come from.
Take a sample of the model's worst predictions and sit down with a domain expert or business stakeholder. Go through them one by one. For each case, ask: does this make sense to you? Why do you think the model got this wrong? What would you have predicted, and why?
The conversation that follows is rarely comfortable. It surfaces disagreements about what the label should have been. It reveals business rules that were never written down. It produces questions like: "wait, why does this customer have that value here — that doesn't match what I know about how this process works."
These are not edge cases. They are often the core of the problem.
Stakeholders who participate in an error analysis session develop a qualitatively different understanding of the model than those who only see the metrics. They stop asking "is it accurate?" and start asking "where does it fail, and does that matter for how we use it?" That is a much more useful question.
And occasionally, the stakeholder looks at a case the model got wrong and says: "actually, I think the model is right and the label is wrong." That happens more than you would expect. It is one of the ways a well-run ML project improves the quality of its own training data over time.
When to do it
Error analysis belongs after the first draft model, before any significant investment in model improvement.
The reason for the timing is that the errors at this stage are most informative. The model has learned enough to make non-trivial predictions, but has not yet been tuned in ways that might obscure the underlying structure of the problem. The mistakes are close to the surface.
Done at this stage, error analysis frequently changes the direction of the project — not just the model architecture, but the problem framing, the feature set, the labeling policy. These are expensive things to change after you have invested heavily in a particular approach. Catching them early is the point.
Error analysis should also happen after any significant retraining or feature change — not just the first time. The model's failure modes change as the model changes. A new feature that improves average performance may simultaneously introduce a new class of systematic errors that the aggregate metric does not flag.
What this is not
Error analysis is not cherry-picking. You are not looking for cases that confirm what you already believe, or for ammunition to justify a decision already made. You are sampling systematically — worst predictions, random sample of failures, edge cases by known subgroups — and reading what you find.
It is also not a substitute for the quantitative evaluation. The metrics still matter. They just do not tell the whole story.
The two practices are complementary. The metrics tell you how much the model is failing. The error analysis tells you what it means.
Closing thoughts
The instinct in ML projects is to treat the model as the unit of work. You train it, you evaluate it, you improve it. The errors are a number to be reduced, not a signal to be read.
This instinct is wrong — or at least incomplete.
The mistakes your model makes are one of the richest sources of signal available to you. They tell you what the data does not capture, where the problem framing is off, what the domain expert knows that the feature set does not. They are, in a meaningful sense, the gap between prediction and decision made visible.
Read them.