Data Quality and Validation for Training Sets

Many people who start building a model assume the hard part is the model itself. In practice, a team often spends more effort deciding what data the model should learn from. A dataset is rarely something you find ready-made. It usually has to be assembled from several places, cleaned, extended, and labeled before a model can use it. The name for that assembly work is data acquisition, and it is planned the way an engineer plans a supply chain: you need to know which inputs you require, where they can come from, what they cost, and what condition they will be in when they arrive.

The goal is a dataset that is large enough, varied enough, and accurate enough for the task, collected in a way that respects user privacy and the rules that apply to the data. Keep one question in mind as you read the rest of this article: for each record in the eventual dataset, where did it come from, and what has happened to it since?

Acquisition draws on four broad routes. The first is sourcing public data, which means finding datasets that other people have released. The second is purchasing proprietary data, which means paying a provider for data it holds and you do not. The third is annotating data, where people add labels or other information to examples that already exist. The fourth is synthesizing data, where new examples are generated from existing data or from templates.

These routes are not alternatives that you choose between once. They are combined. A single dataset can contain records from several sources, and the same dataset can pass through annotation and synthesis more than once. The sourcing routes supply raw records, while annotation and synthesis change those records or add to them.

Of the four routes, the one that usually matters most is the data your own application produces. The reason is distribution. Your application's records reflect the kinds of inputs your users actually send, in the proportions in which they actually send them. Public and purchased datasets were gathered for someone else's purpose, so how well they match your task is often only partial. Matching the distribution of the data you care about is difficult to achieve with other sources, which is why application data is described as ideal for the task.

Application data can also feed back into the product. A useful pattern is a loop in which users generate data, that data is used to improve the product, and the improved product generates more useful data. Teams often call this a data flywheel. Application data takes three broad forms: user content that users create, system-generated data that records how the product is used, and user feedback. The design of a feedback system is a topic of its own and is covered later in the course.

Before you invest in creating data, check whether a suitable dataset already exists. Data marketplaces hold both open and proprietary datasets, and some of them may match your requirements closely. In many projects, though, the result is a combination of several partial matches rather than one perfect dataset. The useful habit is to search first, then decide which parts still have to be built.

Public data has a second requirement that is easy to forget: a public dataset is not automatically safe to use. Before using one, check its license and try to understand where its contents came from. A license that permits commercial use can still cover a dataset that includes material collected under different terms. Public data is worth using, but it has to be inspected and validated like any other input.

Ready-made data also comes from evaluation harness tools. Some of them host benchmark datasets that are large enough to use for parameter-efficient fine-tuning. One example is the lm-evaluation-harness from EleutherAI, which hosts more than 400 benchmark datasets, averaging over 2,000 examples each. Even when a source like this is well known, the same license and provenance checks still apply before its data enters your training set.

A dataset changes at every step of acquisition, and the easiest way to see how is to follow one through the process. Suppose you are building a dataset of customer support conversations, where each record pairs a customer message with a good agent reply. The example below is a generated illustration, not a figure from a real project. Watch how the count and the quality change as each step is applied.

Start from the state the dataset has reached after the rewriting step: 4,200 records, of which 1,000 have been rewritten. The team then removes 300 records that the annotators flagged as unanswerable, and generates 400 new conversations from 10 templates. The diagram traces the record count through those two changes.

The support example contains a detail that is easy to overlook. The rewrite step produced no change in size, yet it was one of the most important steps for quality. Adding, removing, rewriting, and labeling affect size and quality in different ways. Adding and removing records change the count directly. Rewriting and labeling can improve quality without changing the count at all.

A practical way to apply this is to record two numbers after every operation: how many records the dataset holds, and what state its records are in. For rewriting and labeling, the second number is the one that moves. For removal and generation, both numbers move. Checking both together keeps you from celebrating a growing count while the records underneath it are getting worse.

Synthesis is the route that adds data from existing material. A common pattern is to write a small number of templates by hand, then use an AI model to produce many instances from them. Synthesis is useful for increasing the size of a dataset, particularly in areas where real examples are scarce.

Annotation adds the labels or other information that make data usable for training. Manual annotation is central to building a high-quality dataset, and it is rarely a single pass. Once annotators start working, a team often discovers that some labels are not helpful. The response is to revise the annotation guidelines and relabel the affected records.

Some errors are factual rather than stylistic, and those may call for a second group of annotators who check the first group's work. The cost of these loops is part of the acquisition budget, not an unexpected extra. Plan for them from the beginning.