Training Data
Training data is the set of examples a model learns from — the labelled transactions behind a fraud model, the trillions of tokens behind a language model, the annotated images behind a document reader — and it determines what the model can do and where it fails: the data's coverage becomes the model's coverage, its biases the model's biases, its errors the model's beliefs. Its provenance and rights are the first questions of any review.
- Also known as
- Training set, Training corpus, Labelled data, Dataset
- Used at
- every trained model; and, in policy and diligence, the object of most of the questions — provenance, consent, copyright, representativeness, leakage, retention
- Binding
- data-protection law (a customer's data used for training is a processing purpose that needs a lawful basis), the EU AI Act's data-governance duties for high-risk systems (relevance, representativeness, error checks, bias examination) and its training-data summary requirement for general-purpose models, and copyright law, under litigation for web-scraped corpora
- Typical scale
- thousands of labelled examples for a fine-tuned classifier; millions to billions of rows for fraud and credit; trillions of tokens for a frontier language model
- Typical problems
- selection bias (only the approved loans have outcomes), label noise, historical bias (past decisions encoded as ground truth), drift (the data no longer resembles the present), leakage (the answer hidden in a feature), duplication between training and test, and provenance gaps (nobody can say where a dataset came from)
- Typical controls
- a documented data pipeline with sources and dates, a datasheet for each dataset, point-in-time features, out-of-time splits, bias audits by segment, retention and deletion rules, and a register of vendor terms on whether the vendor may train on the company's data
- Parties
- the data engineers who build the pipelines, the analysts who label, the legal and privacy teams who clear the sources, the reviewers who read the datasheet, and, in an acquisition, the buyer's diligence team
How training data works in practice
A fintech assembles training data for a credit model: three years of applications, features as they were at decision time, outcomes at twelve months. Each choice shapes the model. Features as of the decision date, not as of today, or the model learns from information it will not have. Outcomes for approved loans only, so the declined population is missing and must be handled. Three years, so the pre-pandemic and post-pandemic regimes are both present in proportions that may not match the future. Segments where the company had few customers — a new region, a new product — are thin, and the model will be least reliable exactly where the company is growing. None of this is a modelling problem; all of it is the data, and the model card's first section describes it.
For language models the questions shift to provenance and rights. What did the vendor train on, and may the fintech's own data end up in the next version? (The API terms answer; enterprise agreements usually exclude training on customer data, consumer ones often do not.) Does the fine-tuning set contain personal data, and was the purpose disclosed? Do the synthetic examples generated by another model breach that model's terms? In an AI acquisition, the training data is the asset and the liability: a model trained on data the target had no right to use is a model the buyer may not be able to keep, and the diligence reads the datasheets, the licences and the deletion logs before it reads the benchmarks.
For a fintech, training data is the part of an AI system that regulators, courts and acquirers can ask about in detail, and the documentation of it is worth more than the model's last decimal of accuracy.
Example
A payments company buys a small fraud-analytics startup for its model, which outperforms the company's own by six points of AUC. Diligence asks for the training data's provenance. The answer: 40% came from a previous customer's transaction data under a contract that permitted model development "for the customer's benefit", with no clause about retention after the contract ended two years earlier. The buyer's lawyers judge the model's continued use a contractual risk; the price is cut by a third, the seller warrants and indemnifies, and the post-close plan retrains the model on the buyer's own data within six months. The retrained model is four points better than the buyer's old one, not six — the difference being what the questionable data had contributed.
Common mistakes
- Features computed as of today rather than as of the decision date. - Training and test sets that share customers or overlap in time. - No datasheet, so nobody can answer where the data came from when asked. - Sending customer data to a vendor whose terms allow training on it. - Buying a model without reading the licences behind its training data.