Your AI Model May Not Be the Problem. Your Dataset Might Be
Your AI Model May Not Be the Problem. Your Dataset Might Be.
When an ML model underperforms, teams tend to look in the same direction first: the model.
Try another architecture. Tune the hyperparameters. Train longer. Change the loss function. Add another 10,000 images.
Sometimes that is exactly what is needed.
But there is another possibility that is much easier to overlook:
The model may be doing a perfectly reasonable job with an imperfect representation of the real world.
At US-DATA, we work on data collection, annotation, and QA for machine learning projects. This gives us an unusual view of model failures: we often encounter them from the data side rather than the architecture side.
And one lesson appears again and again.
The number of examples in a dataset matters far less than most teams assume if those examples don’t represent the situations in which the model actually fails.
A 96% model with a very specific problem
Consider a computer vision system used in grocery retail.
The model analyzes video and identifies products. According to the project’s internal quality metric, it was already performing at around 96%.
At first glance, this sounds like a reasonably successful model.
But the remaining errors weren’t random.
The system struggled primarily with products that looked similar. Cheese versus butter was one example.
That distinction matters.
If errors were distributed randomly across the entire dataset, the team might reasonably look at the model’s general capacity.
But if errors cluster around a small number of classes and scenarios, the question changes.
Instead of asking:
“How can we make the entire model better?”
we can ask:
“What is different about the data where the model fails?”
In this particular project, AI output could be compared with actual checkout sales.
When the sales system showed that an item had been sold but the vision system had failed to register the expected event, the corresponding video could be investigated.
That created a feedback loop.
Production error → manual inspection → difficult examples → annotation → dataset update → retraining → evaluation.
Rather than feeding the model thousands of additional random product images, the team concentrated on examples that exposed an existing weakness.
After several iterations, the project’s internal quality metric increased from approximately 96% to more than 99.5%.
The important part isn’t the percentage itself.
It’s how the improvement was achieved.
The dataset wasn’t necessarily too small.
It was missing information in precisely the places where the model needed it.
10,000 images can still be a poor dataset
Dataset planning is still surprisingly often reduced to a number.
“We need 1,000 images per class.”
“Let’s collect another 20,000 frames.”
“We already have 100,000 images.”
But image count and real-world coverage are two different things.
Imagine 10,000 photographs of the same product.
Same camera.
Similar lighting.
Similar angle.
Similar background.
Technically, you have a large dataset.
From the model’s perspective, however, you may have shown it the same part of the world thousands of times.
Now change the lighting.
Rotate the object.
Partially occlude it.
Replace the camera.
Introduce a rare defect.
Put the model into production.
Suddenly, the “large” dataset doesn’t look so large anymore.
A more useful way to think about coverage is through combinations:
object × state × viewpoint × lighting × camera × environment × edge case
This becomes especially important in computer vision tasks involving product condition, defects, or quality assessment.
The same defect can look completely different from another angle. A surface anomaly that is obvious head-on may become almost invisible at 60 degrees. Warm and cool lighting can change color signals. A different camera can change the distribution again.
The question shouldn’t simply be:
“How many images do we have?”
It should be:
“How much of the world the model will encounter is represented in those images?”
When two annotators disagree, don’t immediately blame the annotators
Another source of model problems appears before training even begins.
Two annotators receive the same image.
They assign different labels.
The obvious conclusion is that one of them made a mistake.
But consider another explanation: the instruction doesn’t contain enough information to determine the correct answer.
We encountered this problem in a project involving more than 100,000 images from a pizza chain.
The annotation specification included multiple product elements and defects.
Some cases looked simple on paper.
For example: identify an area where cheese hasn’t melted properly.
But what exactly does “properly” mean?
Where does that defect begin?
Where does it end?
What does a borderline example look like?
Now consider a pizza crust that is both twisted and overbaked.
Is this a shape defect?
A baking defect?
Both?
These aren’t questions that can be solved by telling annotators to “pay more attention.”
They require a rule.
And that rule must be applied consistently across thousands of images and potentially many different annotators.
This is why pilot annotation is so important.
Finding an ambiguous class definition after 500 images is inconvenient.
Finding it after 100,000 images can mean identifying affected records, reannotating them, repeating QA, rebuilding parts of the dataset, and potentially retraining models.
Annotation guidelines are not documentation that sits next to the dataset.
They are part of the dataset.
Annotation QA isn’t just checking boxes and polygons
A bounding box can be geometrically perfect and still be completely wrong.
Imagine an object outlined with pixel-perfect accuracy but assigned to the wrong class.
A geometry check passes.
The training signal is still incorrect.
Production annotation therefore needs several different layers of quality control.
Technical validity matters: coordinates, files, masks, polygons, class IDs.
Completeness matters: did we annotate everything that should have been annotated?
Semantic correctness matters: is this actually the right class?
Get US-DATA Data Annotation’s stories in your inbox
Join Medium for free to get updates from this writer.
Consistency matters: are different annotators applying the same rule?
Coverage matters: do rare but business-critical situations exist in sufficient numbers?
And difficult cases may need expert review rather than ordinary sampling.
This changes the role of QA.
QA is no longer a final inspection performed after annotation is finished.
It becomes part of the production loop.
Production changes the dataset problem
Even a very good training dataset has an expiration problem.
The real world doesn’t stay still.
In retail, packaging changes.
In industrial environments, equipment changes.
Cameras are replaced.
Lighting conditions shift.
New products appear.
Customer behavior changes.
A model can remain technically identical while its input distribution slowly moves away from what existed during training.
In the retail project mentioned earlier, packaging designs changed regularly — in some months, between 3 and 25 updates occurred.
To a person, redesigned butter is still butter.
To a vision model, color, typography, logo placement, contrast, imagery, and even package shape may all have changed.
This is why the idea of creating a dataset once and considering the data work finished is increasingly unrealistic for production AI.
A more useful model is:
production → errors → hard cases → annotation → dataset → retraining → production
The dataset becomes a living part of the ML system.
Your model can help tell you what to annotate next
This leads to one of the most useful changes in how annotation can be organized.
Don’t treat every unlabeled example as equally valuable.
Production systems generate enormous amounts of data. Labeling all of it is expensive and, in many cases, unnecessary.
Instead, look for examples that contain new information.
Cases where model confidence is low.
Cases where predictions disagree with business data.
New object appearances.
Rare defects.
Unusual viewpoints.
New cameras.
New environments.
Classes the model systematically confuses.
These are hard cases.
And hard cases often have far more training value than another batch of examples the model already handles perfectly.
This turns annotation from a volume-driven process into an information-driven process.
The question becomes not:
“How much can we annotate?”
but:
“Which annotations are most likely to improve the model?”
Sometimes you don’t need to rebuild the dataset
Discovering a data problem can create another dangerous assumption:
“We have to start again.”
Usually, that should not be the first conclusion.
Suppose you have 200,000 annotated images, but investigation shows that most errors are concentrated in two similar classes.
Perhaps only 12,000 images belong to those classes.
And after filtering them, only 2,000 appear genuinely ambiguous.
Why reannotate 200,000 images?
A better approach is to identify the affected slice, fix the underlying rule, reannotate the highest-risk examples, add missing hard cases, run QA on the corrected segment, and evaluate the model again.
This is targeted reannotation.
The principle is simple:
Don’t fix what already works.
Eventually, every serious dataset needs a history
As ML systems mature, another problem appears.
A team opens a dataset created a year ago.
Someone asks:
Where did these images come from?
Which version of the annotation guideline was used?
Why does this class exist?
When was its definition changed?
Which dataset version trained model v4?
Which images contain personal or licensed data?
Who approved the disputed cases?
If the answers live in someone’s memory, Slack history, or an old spreadsheet, the dataset becomes increasingly difficult to trust.
This is where provenance, metadata, versioning, and data governance stop being enterprise buzzwords and become engineering necessities.
A production dataset needs something resembling a biography.
Where it came from.
How it changed.
What rules created it.
What corrections were made.
Which model versions used it.
Before changing the model, investigate its mistakes
None of this means that architecture doesn’t matter.
Of course it does.
Models can fail because of preprocessing, architecture, loss functions, hyperparameters, compute limitations, or the formulation of the ML problem itself.
But data should be investigated before assuming that another architecture will solve everything.
When a model underperforms, start by segmenting its failures.
Which classes does it confuse?
Which cameras produce more errors?
Does performance change at night?
Did failures begin after a packaging update?
Are rare scenarios represented in training?
Are annotators applying the same definitions?
Is the test set genuinely independent?
Has production drifted away from the original training distribution?
The goal is to replace:
“Our model isn’t accurate enough.”
with something much more useful:
“The model confuses A and B under conditions X and Y, and those situations are underrepresented in the training data.”
Now you have an engineering problem you can actually work on.
The full US-DATA Guide
We’ve published a much more detailed guide covering the complete data lifecycle behind these problems:
Why an AI Model Performs Poorly: How to Check the Dataset, Annotation, and Data Quality
It includes real US-DATA project examples and detailed sections on dataset coverage, annotation guidelines, multi-level QA, targeted reannotation, data drift, hard cases, continuous annotation, team responsibilities, provenance, and data governance.
Read the full online guide:
https://usdataml.com/en/articles/Why-an-AI-Model-Performs-Poorly/
Download the PDF edition:
https://usdataml.com/researches/Why%20an%20AI%20Model-US-DATA-GUIDE.pdf
US-DATA works with data collection, annotation, and quality control for computer vision and other machine learning projects.
The model is only as useful as the world represented in its data.
