Developers often spend hours choosing between XGBoost, Random Forest, and neural networks.
They tune hyperparameters, compare models, and keep trying to improve accuracy.
But sometimes, the model isn't the problem.
The data is.
A powerful machine learning model can only learn from the information it receives. If that information is incomplete, incorrect, duplicated, or inconsistent, the model can learn the wrong patterns extremely well.
A Real-World ExampleImagine a company wants to predict which customers are likely to cancel their subscription.
The team collects data about:
• Customer activity
• Monthly spending
• Number of logins
• Support tickets
• Subscription plan
• Customer tenure
They train an XGBoost model and get 94% accuracy.
Looks great.
So they deploy it.
A few weeks later, the business team notices that the model is missing many customers who actually cancel.
The developers try another algorithm.
Then they tune the model again.
Still not much improvement.
Eventually, they investigate the data.
They discover:
• Some customer records were duplicated.
• Some churn labels were incorrect.
• Several features had missing values.
• Some customer information was stored in different formats.
• One feature contained information that was only available after the customer had already decided to cancel.
The model wasn't necessarily bad.
The data pipeline was.
And that is where many machine learning projects go wrong.
Garbage In, Garbage OutA machine learning model doesn't understand whether the data is good or bad.
It simply learns patterns from what we give it.
Bad Data
↓
Model learns bad patterns
↓
Great-looking metrics
↓
Poor real-world predictions
Let's look at some of the problems that can cause this.
Missing Data
Real-world data is messy.
A customer might have no recorded age, income, login history, or location.
Simply replacing missing values with zero can introduce information that isn't true.
The right approach depends on why the value is missing and what the feature represents.
Incorrect Labels
If we're teaching a model that certain customers churned when they actually didn't, the model is learning from incorrect answers.
A sophisticated algorithm cannot magically correct thousands of bad labels.
Before asking which model to use, ask:
Can we trust our labels?
Duplicates
Duplicates can make certain examples appear more important than they really are.
Even worse, if the same customer appears in both the training and testing data, the model may appear to perform extremely well because it has effectively seen that customer before.
A great test score doesn't mean much if the test data isn't truly independent. Outliers
An unusual value isn't automatically a bad value.
A customer spending ₹1,00,000 when most customers spend ₹1,000 could be a mistake.
Or it could be your most valuable customer.
Removing it without understanding the reason can be just as harmful as keeping bad data.
The goal isn't always to remove unusual data. It's to understand it.
Data Leakage
This is one of the most dangerous problems.
Suppose we're trying to predict whether a customer will cancel next month.
Now imagine our training data includes:
Cancellation Request Submitted
The model quickly learns that customers with a cancellation request are likely to churn.
The accuracy looks excellent.
But there's a problem.
At the moment we're supposed to make the prediction, we don't have that information yet.
The model has accidentally been given a clue about the future.
Training
↓
Future information included
↓
Excellent accuracy
↓
Production
↓
Information unavailable
↓
Poor predictions
A simple question can catch many leakage problems:
"Would this information actually be available when the prediction is made?"
Inconsistent Features
Data can also be technically valid but inconsistent.
For example:
India india INDIA IN
Indian
To us, these are obviously related.
To a machine learning pipeline, they can become different categories.
The same problem appears with dates, currencies, units, names, and other fields.
The model should learn business patterns, not formatting differences.
Before You Change the Model, Check the DataWhen a model performs poorly, our first instinct is often to try another algorithm.
But before switching models, investigate the dataset.
Ask:
• Are important values missing?
• Can we trust the labels?
• Are there duplicate records?
• Are the outliers real?
• Is there data leakage?
• Are features consistent?
• Does the training data actually represent production?
These questions aren't as exciting as choosing a new neural network architecture.
But they can have a much bigger impact.
The Bigger LessonMachine learning isn't just about finding the right algorithm.
It's about building a reliable pipeline:
Data
↓
Validation
↓ Cleaning ↓
Features
↓
Model
↓
Evaluation ↓
Production ↓
Monitoring
The model is only one part of that pipeline.
Sometimes, improving the model gives you a small improvement.
Fixing the data can completely change the result.
So the next time your model isn't performing as expected, don't immediately ask: "Which model should I try next?" Ask:
"Can I trust the data I'm giving it?"
Because a simple model trained on reliable data can be far more useful than a sophisticated model trained on unreliable data.
The model isn't always the problem.
Sometimes, your data is.
What's the most surprising data-quality problem you've encountered while building an ML system?