Data Quality and Dataset Curation

Discussions about training data often focus on how much data a model sees. This article argues that the amount is only part of the picture. Building a training dataset is shaped by what you want the model to do and by the training phase the model is in, and the quality of the data matters as much as its size. The sections that follow trace how a dataset is designed, how the three core criteria interact, how synthetic data enters the process, and what a data flywheel can and cannot promise.

Building a training dataset can feel like a mysterious craft, but the underlying logic is direct. You begin by deciding what behaviors you want the model to learn. Then you design a dataset that demonstrates those behaviors. The data you need is shaped by two things at once: your use case and the training phase the model is in. Pre-training draws on different data than instruction finetuning or preference finetuning does.

The order matters. Data choices come after the behavior decision, not before it. A team that starts by collecting whatever data is easy to get has no clear test for whether the data teaches anything useful.

Dataset design across all training phases rests on the same three criteria: quality, coverage, and quantity. Quantity receives most of the attention in discussions about training, but the other two matter just as much.

The three criteria are not independent. Coverage determines whether a large dataset is useful at all, because a million examples that all look alike leave gaps the model never learns to fill. Quality determines whether the quantity you collect helps or hurts, because noisy examples add volume without adding correct behavior. Teams have also found that increasing the diversity of their datasets is a key way to improve model performance. Diversity sits at the intersection of coverage and quality, since a varied set of examples only helps if each example is also correct.

Consider two candidate training datasets. The first is very large but spans only a few behaviors. The second is much smaller but includes many different situations. The comparison below shows why the second may be the more useful dataset, even though it contains less data.

Because acquiring high-quality data is difficult, many teams have turned to synthetic data. Synthetic data is programmatically generated to supplement real data. The source explains that the difficulty comes from steps that resist automation. Annotating data is hard, but writing annotation guidelines is harder. Generating data can be automated to some degree, but verifying that the generated data is correct is harder still. The judgment about what data you want, and attention to details, cannot be handed off to a tool.

The practical appeal is that generation can be automated in ways that collection and annotation cannot. A process that produces candidate examples quickly can supplement real data at a scale that manual work would struggle to reach. The source is careful to add that this does not remove the need for careful thinking. Synthetic data changes where the effort goes. Much of the effort moves from producing raw examples to deciding what is wanted and checking what was produced.

The source is firm on one point: synthetic data must be evaluated to ensure its quality before it is used to train models. This applies to generated data in the same way it applies to real data. A generated example can be wrong, off-topic, or unrepresentative, and training on it can teach the model those flaws. The diagram traces the path a generated example takes. Real data remains the starting point, and the generated portion does not enter training directly.

A data flywheel describes a model that continually improves upon itself. The source notes that the implication of using synthetic data is that, in theory, it is possible to train a model that keeps improving this way. Each round of improvement produces material for the next round, so progress builds on itself. The loop is attractive, but the source is careful about whether it works in practice. The flywheel depends on the quality of what the model feeds back into itself.

The loop works only when the feedback it carries is reliable. The source offers a case where feedback clearly helped. In one reported study, about 20 percent of solutions were initially incorrect but self-corrected, which indicated that the model learned from execution feedback and improved its performance. Here the feedback came from running the code, a signal that reliably separated good output from bad.