Data Verification

Imagine you have collected a large amount of text from the web to train a language model. On the surface, the text looks like language. But many of the pages were written in markup languages, and some of the content should never reach a model at all. Data preparation is the stage where you decide what stays, what goes, and what needs repair before training begins. This article focuses on the removal half of that work: taking out the things that do not belong in the dataset.

The source material names three broad kinds of unwanted data. The first is extraneous formatting tokens, such as HTML tags and Markdown symbols. The second is information that conflicts with policy, including personally identifiable information, sensitive data, copyrighted material, and toxic content. The third is low-quality data, which may look acceptable at a glance but makes the model worse. The guiding goal is stated directly: data needs to be cleaned to make your model performant and safe.

Many public datasets are scraped from the internet, and web pages are built from HTML. An HTML tag such as a paragraph or bold marker is an instruction for a browser about how to display text. It is not part of the words a reader sees. When a scraper copies a page, those tags often come along with the text. The result is that a model may be trained on characters whose only job is layout.

Markdown works the same way in a different style. Symbols used to mark headings, emphasis, or lists are formatting tokens rather than content. The source treats both kinds of token as extraneous. They are present in the data because of how it was collected or written, not because they carry meaning the model should learn.

The clearest way to see the difference is to compare a raw scraped string with the same string after its formatting tokens are removed. The example below is an original illustration, not a source excerpt.

Now follow a single scraped string through the decision. Each token is either content the model should learn or a formatting token that the source calls extraneous. The diagram marks which tokens are removed and what remains.

Removal is a decision based on what the model is supposed to learn, not a rule that applies everywhere. The source says that extraneous HTML tags and Markdown tokens are common in scraped data and that removing them is usually right, unless the model is meant to learn markup. So the question to ask is always the same: is the markup part of the lesson the model should take in?

If your goal is a model that writes or reads markup, the tags may be exactly the content you want to keep. For most general text training, they are noise. The flowchart below turns that question into a sequence of steps. Note that the source also says removal decisions should be checked against the model's goal and policy before any deletion happens.

The second kind of removal is driven by policy, not by formatting. The source says you need to clean your data of anything that is not compliant with your policies. It names four categories that commonly fall into that group. The categories differ in kind, as the table shows.

For structured data, the source gives a practical instruction: remove all the fields that you are not allowed to use. Its examples are a zip code, a name, and a gender field. The rule is about permission, not about whether a field seems important.

This matters because a restricted field may improve a model's predictions. If a policy forbids using the field, it leaves the dataset anyway. Usefulness to the model does not override a policy restriction.

The third kind of removal targets low-quality data: examples that are weak for training. The source points to data verification techniques for finding them. These examples are harder to catch than formatting tokens or restricted fields, because nothing about them is obviously wrong when you look at one record in isolation.

The source gives manual inspection a central role. Staring at data can help you notice patterns. Those patterns can become heuristics, which are rules of thumb you apply to flag suspect examples at scale. The useful heuristics are not always obvious. They may depend on something outside the text itself, such as how or when the example was produced.

A concrete finding from the source illustrates this. Kern et al. (2024) found that annotations made in the second half of an annotation session are of lower quality, likely due to annotator boredom or fatigue. A heuristic built on that finding would not look at the words of the annotation at all. It would look at the position of the example within the annotator's session.

The diagram is an illustrative layering rather than a fixed procedure from the source. It shows the idea the source describes: human inspection produces a rule, the rule is applied across many records, and matching records are flagged for closer review or removal while the rest pass.

The following example is an original illustration that applies the session-position idea. It uses invented numbers to show the reasoning, not real figures from the source.