What is instruction tuning, and why its data does not scale like pretraining data

Buyers who have purchased a pretraining corpus once tend to assume the next purchase is the same thing at a smaller size. It is a different product. The unit of data changes, and with it everything about how quality is judged, how the set is compared across suppliers, and what a fair scope looks like.

Pretraining data is raw text. The only task inside it is "predict what comes next", and every document teaches it. Instruction data is a pair: a request written the way a user would write it, and the response you want the model to produce. That pairing has to be constructed, and constructed data carries a cost that raw text does not.

The unit of value is the pair, not the token

A corpus is compared per unit of text, and suppliers mostly differ on coverage and provenance. Instruction data is compared per verified pair, and suppliers differ on what the pair teaches. There is no per-item number that captures that difference.

Two suppliers can both deliver ten thousand pairs. In one set, nine thousand of them ask for a summary of a paragraph. In the other, the pairs are spread across extraction, rewriting, classification, refusal, and multi-step reasoning. The second set is worth more, and nothing on the invoice shows it.

So the first thing to write down is not a count. It is the list of behaviors you want the model to demonstrate, with an approximate share for each. That list is the specification. The count follows from it.

Why a few thousand careful pairs move a model

Published work on instruction tuning has found the same thing more than once: the number of distinct tasks represented in the data matters more than the number of examples per task, and gains on instructions the model has never seen come from that task diversity. Commonly used ranges for a narrow product surface sit in the low thousands to the low tens of thousands of pairs, and the count is set by how many distinct behaviors you need rather than by a target borrowed from a paper.

The mechanism explains the failure mode. The model is not acquiring a new capability from these pairs. It is learning which of its existing capabilities to apply, and in what form to present the answer. That is a routing and formatting lesson, and it is learned from the shape of the examples.

A set of two hundred thousand pairs drawn from ten templates teaches ten templates extremely well. If your product has thirty request shapes, the other twenty remain untaught no matter how many rows are added to the ten.

The task list comes before the data

Before a single pair is written, the taxonomy should exist as a document: one row per behavior, with a definition, an example, and the boundary case that separates it from its nearest neighbor.

Two checks are worth running on any set you are offered. Ask for the per-task counts and look at the distribution, because one dominant task means the model will be strong there and mediocre everywhere else. Then sample twenty instructions and read only the instructions, since near-duplicates with different wording are one data point repeated. Template inflation is the most common reason a set looks larger than it is.

Where the cost actually sits

Writing a plausible answer is the cheap part. Verification, answer diversity, and the negative cases are the expensive parts.

A fluent, confident, wrong answer is worse than no answer, because it teaches the model that the error is acceptable. Every pair therefore needs a check by someone who can tell a good answer from a well-written bad one, which is a different skill from writing one.

Answer diversity is the second cost. Many instructions have several valid responses, and a set where every response has the same length and tone teaches a single register. Two or three acceptable variants of a hard instruction are often worth more than three new easy instructions.

The third is the refusal boundary: pairs where the right response is to decline, to ask for clarification, or to state a limitation. Nobody writes these unless the specification asks for them, and they are the pairs that decide how the model behaves at the edges of its competence.

What to ask for when you are buying

Instruction data is a small purchase with a high price per item and a short shelf life, because the taxonomy follows your product rather than the market. Buying it by the unit, the way a corpus is bought, is how teams end up with a large set that changed nothing.

• The task taxonomy as a document, with per-task counts attached to it.
• Whether the pairs were written by people or generated and then reviewed, and if reviewed, by whom and against what rubric.
• A held-out slice kept out of the delivery, so you can measure the effect yourself on instructions the set has never seen.
• The share of pairs whose correct response is a refusal, a clarification request, or an explicit statement of inability.
• A pilot built from the hardest task in your taxonomy rather than the most common one, because the easy tasks pass every pilot.