Home/AI & ML Glossary/Training Data

What is Training Data?

Training data is the set of examples a model learns from, and its coverage, label quality, and representativeness set a hard ceiling on how well any model trained on it can perform.

The plain definition

Training data is what the model sees while its parameters are being fitted. Everything the model knows comes from here. This is why the constraint is so unforgiving: no architecture, no amount of compute, and no clever loss function recovers information that is absent from the data.

It is also why the most valuable work on most machine learning projects is not modelling. It is curation — deciding what to collect, how to label it, what to exclude, and how to keep it current.

The four properties that matter

Representativeness. The training distribution should match what the model will meet in production. A defect detector trained only on well-lit factory images fails on the night shift. This mismatch, present from day one, is distinct from drift, which develops over time — but it produces the same symptom of unexplained live underperformance.

Label quality. Noisy labels impose a ceiling no model can exceed. Measure it: have two or three annotators label the same subset and compute inter-annotator agreement with Cohen's or Fleiss' kappa. If your experts agree only 70% of the time, no model will exceed roughly that on the same task, and the correct next step is to improve the labelling guidelines, not the architecture.

Coverage of the tail. Aggregate accuracy hides failures on rare but important cases. Deliberately over-sample edge cases relative to their natural frequency, and always evaluate them as their own slice rather than letting them dissolve into an average.

Freshness. Human behaviour, fraud patterns, and product mixes move. Data has a shelf life, and part of designing a system is deciding how often it must be refreshed.

Splitting it without fooling yourself

The three-way split — train, validation, test — only works if the splits are genuinely independent. Three ways it silently breaks:

Temporal leakage. Random splits on a time-ordered process train on the future. Any model that must run forward in time needs a forward split.

Group leakage. If the same patient, customer, device, or document appears on both sides, you measure memorisation of that entity rather than generalisation to new ones. Split by group identifier.

Duplicate leakage. Near-duplicates are endemic in scraped and user-generated data. Deduplicate before splitting, ideally with embedding similarity rather than exact hashing, because near-identical records defeat hash-based checks entirely.

Provenance is now a hard requirement

Where data came from has become a governance and legal question, not just an engineering one. Scraped web content carries copyright exposure. Customer data carries consent obligations under GDPR and similar regimes, including limits on repurposing data collected for one stated reason. Personal data may need to be deleted on request, which is straightforward in a database and genuinely difficult once it has been absorbed into model weights.

The practical implication is to maintain a dataset lineage record from the start: source, licence, consent basis, collection date, and any transformation applied. Reconstructing this after the fact is painful, and being unable to answer the question at all is increasingly a blocker to enterprise deployment. This is also why synthetic data has become interesting — it can sidestep consent constraints, at the cost of inheriting whatever bias the generator learned.

  • It sets the ceiling — no model exceeds the information present in its training data
  • Measure label noise — inter-annotator agreement bounds achievable accuracy
  • Split for independence — guard against temporal, group, and duplicate leakage
  • Track lineage — source, licence, consent, and date — reconstructing it later is far harder
FAQ

More on Training Data.

How much training data do I need?

Rather than guessing, measure the learning curve: train on 10%, 25%, 50%, and 100% of what you have and plot held-out accuracy against training-set size. A curve still rising steeply says more labelling will pay off. A curve that has flattened says the returns are now in better labels, better features, or a different framing — and further collection is largely wasted budget.

Is more data always better than better data?

No, and this is one of the more consistently expensive misconceptions in applied machine learning. Doubling a dataset while holding label noise constant yields modest gains; halving label noise often yields more. Deduplication, resolving annotator disagreement, and fixing systematic labelling errors typically beat volume increases per unit of effort — especially with fewer than roughly ten thousand examples.

Can I use customer data to train a model?

Sometimes, and it depends on what you told customers when you collected it. Under GDPR-style regimes, purpose limitation means data gathered to deliver a service cannot automatically be repurposed for model training. Practical requirements usually include a lawful basis, disclosure in the privacy notice, a data processing agreement where a vendor is involved, and a plan for deletion requests. Treat it as a question to answer before training, not after.

Free consultation

Applying this to a
real system?

We build and ship production machine learning. If training data is part of a problem you are working on, tell us about it.

Start the conversation

or write to us at [email protected]