Effective Data Preparation for AI Models

Imagine you have collected a large pile of examples for teaching a model. Some came from public sources, some were written in-house, and some were labeled by people you have never met. Before any of it reaches a training run, you need an honest answer to a simple question: what is actually in this data? A model learns whatever patterns the examples contain, including the bad ones, so an unexamined dataset can quietly steer the model in directions you never intended.

This article covers the first stage of data preparation: inspecting a dataset to judge its quality and to learn how its contents are spread out. Inspection does not change the data. It produces understanding, and that understanding decides what you keep, what you fix, and what you remove later.

Inspection is a stage that sits between raw collection and training or tuning. Follow one dataset through the process and notice what each stage hands to the next. The raw collection enters first. Its origins are then checked, its distributions are measured, those distributions are sliced to look for skew, annotations are checked for disagreement, and only then do you decide what to change.

The earliest questions are about provenance, not statistics. Where did each part of the dataset originate? How was it processed along the way, for example by cleaning, filtering, or reformatting? Was it ever used for some other purpose before it arrived at your project? Each answer changes what the numbers mean. Two datasets with identical word counts can behave very differently if one was scraped and the other was written by specialists under a careful protocol.

Once you know the origins, you can measure the dataset. A distribution tells you how often each value of some property appears, or how a numeric property is spread across the examples. The source suggests several starting properties. Token frequency shows which tokens are common, which in turn reveals the vocabulary the data really relies on. Input length and response length show how big the examples are. You can also ask whether the data contains any special tokens, and whether the topics and languages present are spread across the examples in a way that matches your task.

Each of these properties belongs to a family of checks. Token frequency and special tokens describe the vocabulary and format of the text. Input and response lengths describe the size of the examples. Topic and language coverage describes relevance, that is, whether the content matches what the application will actually see. Keeping these families separate helps you decide which check answers which question.

The last question is a relevance question, and it is easy to skip. A dataset can be large and varied yet still be mostly about topics your application will never encounter. Measuring the topic and language distribution lets you compare what the data covers against what the task needs.

The statistics you choose are not limited to the obvious ones. The source describes a study by a group of Microsoft researchers from 2023 that examined the same set of instructions answered by two different models, GPT-3 and GPT-4. They measured the distribution of verb, direct object, and noun combinations in the responses, and they also measured response length. The pattern that emerged was that GPT-4 showed a broader and more varied range of verb-noun pairings and tended to produce longer responses.

The same technique that exposes differences between two generators can be turned on a dataset, because it reveals what kinds of language a set of examples actually contains. The source notes that this kind of analysis helps evaluate models as well as data. The lesson is that a useful statistic is one that matches a question you care about. Choose the measurement first, then let the question decide it.

A single overall distribution can look healthy while hiding real problems. The practice is to plot the same distributions again after splitting the data by source, by time, or by annotator. A slice that behaves differently from the rest deserves investigation. The diagram below compares the pooled view with a per-source view of the same response lengths from the earlier example. The pooled view reports a single average, while the per-source view shows where the long responses actually come from.

The source gives a clear reading rule. If one data source consistently produces very short responses, that is a finding about the source, not about the examples in general. Slicing can also answer more pointed questions. Do certain kinds of questions tend to receive longer or shorter responses? Do some kinds receive higher or lower scores? If the scores are supposed to follow a normal distribution, a fair test is to check whether the scores from each annotator follow that shape, rather than only checking the pooled scores.

Outliers need the same care. An extreme value can be a real and valuable example, an error, or a sign of something systematic. The source asks three questions in sequence: are there outliers, what might cause them, and what should be done with them. Answering the middle question usually requires looking at the examples themselves, which is a point the next section returns to.

Many datasets give the same example to more than one annotator. When that happens, you can compute inter-annotator disagreement, which measures how often the annotators' labels conflict. The source recommends this check directly: if each example has more than one annotation, compute the disagreement, then examine the examples where annotations conflict and resolve those conflicts. The flowchart below traces one item through that process, including the path taken when labels do not disagree.

Disagreement is information, not just noise to be deleted. Sometimes it signals an ambiguous instruction, sometimes an annotator who misunderstood the task, and sometimes a genuinely hard example where reasonable people differ. Resolving a conflict means deciding, for a documented reason, which label stands or how the example should be revised. Deleting the conflicting example without this review throws away the evidence that the task itself may need clearer wording.

Automated tools can compute distributions and flag disagreement quickly, but the source is clear that they do not replace manual inspection. Each method catches things the other can miss. A distribution can show that one source produces short responses, but only reading the examples shows whether the short responses are unhelpful, or whether they are exactly what the task asks for. Automated slicing finds where to look; reading tells you what you are looking at.

The author reports that spending about fifteen minutes reading a dataset directly has often revealed something that saved hours of later troubleshooting. A quote from an OpenAI co-founder, Greg Brockman, makes the same point, describing manual inspection of data as having probably the highest value relative to its prestige of any activity in machine learning.