Main Challenges of Machine Learning

Where the challenges of machine learning come from

Projects fail in two places, and it is worth being blunt about which. Either the data is wrong for the question, or the model does not generalise beyond what it was shown. Every specific problem in this chapter is a variety of one of those two, and the first is far more common than the second.

That ordering matters because it is the reverse of where most people spend their time. Newcomers tune hyperparameters for a week on a dataset that was never going to work. Experienced practitioners look hard at the data first and reach for a different estimator last.

The tools for building models are covered elsewhere in this course. This chapter is about the things that go wrong with them, including two — leakage and drift — that produce excellent-looking metrics right up to the point where the system reaches production.

Bad data: too little, unrepresentative, dirty

Not enough data. Holding data on the problem is one of the three conditions a problem must meet before machine learning applies, and how much you need scales with how complicated the pattern is, not with how important the problem feels. A linear relationship across three features might be learnable from a few hundred rows. Image classification from scratch needs tens of thousands. The signal that you are short is a model whose score swings wildly when you change the random seed.

Non-representative data. This is the one that ends careers. Your training set must resemble the cases the model will actually see. A recruitment screener trained on ten years of hires learns who the company hired, not who succeeded — and if hiring was skewed, the model reproduces the skew with a veneer of objectivity. The failure is invisible in testing, because the test set carries the same bias as the training set — which is why where your labels come from is a question to settle before the modelling starts, not after.

Poor quality data. Duplicated rows from a botched join. Sensors that report zero when they mean “offline”. Currency columns mixing pounds and euros because someone changed a form in 2022. Time spent on this is not preparation for the work; it is the work.

Irrelevant features. Extra columns that carry no signal do not sit there harmlessly. They give a flexible model more opportunity to find coincidences, and they dilute the columns that matter.

There is a habit worth building here: before fitting anything, write down what the model should be able to predict and why, in one sentence, using the actual column names. If you cannot, no algorithm will supply the missing reasoning.

Bad generalisation: overfitting and underfitting

Overfitting is a model that has learnt the training data rather than the pattern in it. It performs beautifully on rows it has seen and badly on anything new. It comes from a model with too much flexibility for the amount of data available: the optimiser described in how machines learn from data is doing its job faithfully, driving training loss down, and nothing in that loss knows about rows it was never shown.

import numpy as np
from sklearn.preprocessing import PolynomialFeatures
from sklearn.linear_model import LinearRegression
from sklearn.pipeline import make_pipeline
from sklearn.model_selection import train_test_split
from sklearn.metrics import mean_squared_error

rng = np.random.default_rng(0)
x = np.sort(rng.uniform(0, 10, 30)).reshape(-1, 1)
y = 2.5 * np.sin(x.ravel() / 2) + 0.4 * x.ravel() + rng.normal(0, 0.5, 30)

x_tr, x_te, y_tr, y_te = train_test_split(x, y, test_size=0.4, random_state=0)

for degree in [1, 3, 15]:
    model = make_pipeline(PolynomialFeatures(degree), LinearRegression())
    model.fit(x_tr, y_tr)
    print(degree,
          round(mean_squared_error(y_tr, model.predict(x_tr)), 3),
          round(mean_squared_error(y_te, model.predict(x_te)), 3))

# degree  train error  held-out error
# 1       1.770        1.582
# 3       0.172        0.224
# 15      0.106        7266.816

Degree 15 has the lowest training error of the three. Its error on rows it has not seen is roughly forty thousand times worse. Judged on training performance alone it is the best model in the table, which is precisely why nobody sane judges a model on training performance.

Underfitting is the opposite: a model too rigid to capture the pattern. Degree 1 is underfitting here — it is a straight line through data that curves, and it is mediocre on training and held-out data alike. That symmetry is the diagnostic. Bad on both means underfitting; excellent on one and poor on the other means overfitting.

Leakage: the challenge that fakes success

Data leakage is information reaching the model during training that will not exist at prediction time. It is the single most expensive mistake in applied machine learning, because it produces results that look outstanding and collapse on deployment.

A hospital model predicting sepsis included a column recording whether a specific antibiotic had been prescribed. Accuracy was superb. The antibiotic is prescribed because a clinician already suspects sepsis, so the model had learned to predict the diagnosis from the response to the diagnosis. Useless at the moment a prediction is needed.

Leakage arrives in recognisable forms. A feature computed after the outcome occurred. Scaling or imputing across the whole dataset before splitting it, so test-set statistics bleed into training. Duplicate rows landing on both sides of a split. Random splits on time-series data, letting the model see the future. Tuning against the test set until it stops being a test.

Two habits prevent most of it. Do all preprocessing inside a Pipeline so it fits only on training folds, and for every feature ask literally when its value becomes known relative to the moment of prediction. If the answer is “after”, delete it. scikit-learn’s guide to common pitfalls and data leakage documents the preprocessing cases in detail.

Suspiciously good results deserve suspicion. A model that scores 0.99 on a problem humans find hard has almost certainly found a shortcut.

Drift: the challenge that arrives after launch

A model is a snapshot of a relationship that held when the data was collected. Relationships move. Customers change habits, competitors change prices, an upstream team renames a category, and accuracy slides downward without a single error being logged.

Nothing in the training process protects against this, and no test catches it, because the code is behaving exactly as written. Monitoring input distributions rather than only output accuracy is what catches drift early, and the reason is practical: accuracy needs the true labels, which often arrive months later, while the inputs are visible immediately.

Decide the retraining cadence before launch, and note that this is exactly the choice between batch and online learning arriving in operational clothing. A fraud model may need weekly refreshes; a model predicting building energy use may run for years. The wrong answer is having no answer, which in practice means the model runs untouched until somebody notices the numbers have been wrong for a quarter.

Frequently Asked Questions

What is the biggest challenge in machine learning?

Getting data that genuinely represents the cases the model will face. Insufficient volume can be worked around and algorithms can be swapped, but a training set that systematically differs from reality produces a model that fails in deployment while scoring well in testing, and no amount of tuning repairs that.

How much data do you need to train a model?

It depends on how complex the pattern is and how many features you have, not on a fixed rule. A simple relationship over a few columns may need hundreds of rows; image or text models need far more. Retrain with different random seeds — if scores swing widely, you need more data.

How do you know if your model is overfitting?

Compare error on the training data against error on data held out from training. Similar and low means you are fine. Very low on training and much higher on held-out data means the model has memorised rather than generalised. High on both is underfitting, which needs the opposite fix.

Key Takeaways

• Audit your data before tuning anything, because insufficient, biased or dirty inputs account for more failed projects than poor algorithm choice.
• Ask whether your training set resembles the population the model will actually score, since a biased sample fails silently and passes every test you run.
• Read training and held-out error together, as a large gap between them diagnoses overfitting and uniformly high errors diagnose underfitting.
• Treat a suspiciously excellent score as a leakage alarm, and check for every feature whether its value is known before the prediction moment.
• Set a retraining schedule and monitor input distributions from day one, because drift degrades accuracy without triggering a single error.