Generation: Getting Coverage, Not Just Volume

Ask a model for a hundred customer support questions and read them. You will find perhaps eight distinct shapes, repeated with substitutions. The same opening constructions. The same complaint categories. A striking preference for certain invented names and companies.

This is not a failure of the model. It is the model doing exactly what it was trained to do: producing high-probability text. High-probability text is, by definition, typical text, and a thousand independent samples from a peaked distribution land near the mode a thousand times.

The consequence for training is direct. A model fine-tuned on that set learns those eight shapes very well and learns nothing about the long tail of real inputs, which is precisely where a deployed system encounters trouble.

And the dataset looks fine. A hundred thousand rows, no duplicates by exact match, varied surface text. Volume disguises the problem, which is why it has to be measured rather than eyeballed.

Everything in this lesson is a technique for forcing the sampler away from the mode without simply making it noisier.

The instinctive fix is to raise temperature, and it does not do what people expect.

Temperature rescales the logits before the softmax, flattening the distribution so lower-probability tokens become more likely. That produces more variation in wording, and it produces it by degrading the quality of every local decision.

What you want is different examples. What temperature gives you is the same example told less carefully. The eight underlying shapes persist; they arrive with more unusual word choices, more grammatical oddities, and more outright errors.

Past a certain point the trade is clearly bad: the diversity gain is superficial and the quality loss is real, and you are now generating training data that teaches a student to make the mistakes a high-temperature sampler makes.

The reason is structural. Temperature perturbs token-level decisions. Diversity of content is decided by what the model is conditioning on, which is the prompt. Changing the prompt moves the whole distribution; changing temperature only widens it around wherever the prompt put it.

So the lever that works is conditioning, not sampling.

The highest-return technique in synthetic data generation is also the simplest: put something different in every prompt.

Instead of asking a hundred times for a support question, ask once per seed, where the seed varies the situation. A product category, a customer's level of technical knowledge, an emotional register, a channel, a time of day, a prior interaction, a specific error code.

Each seed relocates the conditional distribution. The model is no longer sampling from what is a typical support question, which has one mode, but from what is a typical support question from a frustrated enterprise administrator about a failed SSO configuration at 2am, which has a different one.

The combinatorics do the work. Six attributes with eight values each give 262,144 distinct conditioning contexts, from a seed list you can write in an afternoon.

The design rule is that seeds should vary things that change the answer, not just the wording. Varying the customer's name changes nothing. Varying their expertise changes the vocabulary, the assumed context, and the appropriate response length.

Self-Instruct systematises seed conditioning into a loop that grows its own seed pool, and it is the ancestor of most instruction-tuning datasets.

Start with a small pool of human-written task instructions, on the order of a hundred and seventy in the original work. Then iterate.

Sample a few instructions from the pool and put them in the prompt as examples. Ask the model to write new, different instructions. Filter the results: discard anything too similar to what the pool already contains, using a similarity threshold on n-gram overlap, and discard anything malformed or unanswerable. Add the survivors to the pool. Repeat.

The similarity filter is the load-bearing component. Without it the pool fills with paraphrases and the loop converges to a narrow region within a few rounds. With it, each new instruction is required to be different from everything already collected, so the pool is pushed outward rather than densified.

Once the instruction pool is large enough, generate responses for each. The two stages are separable, and treating instruction diversity as its own problem is the reason this works.

Self-Instruct produces variety at roughly constant difficulty, because a model asked for a new task tends to produce another easy one. Evol-Instruct addresses that by evolving existing instructions along two directions.

In-depth evolution makes an instruction harder while keeping its subject. Add a constraint. Deepen the question so it requires more inference. Replace a general term with a specific one. Increase the number of reasoning steps required. Complicate the input, for instance by supplying data in a messier form.

In-breadth evolution produces a new instruction in a related but distinct area, moving sideways rather than up.

Applied repeatedly, the pool acquires a difficulty gradient: simple instructions, and progressively harder descendants of them.

The failure mode to watch is evolution into nonsense. Several rounds of add a constraint can produce instructions that are self-contradictory or impossible, and those are worse than useless as training data because they teach a model to answer unanswerable questions. An elimination step that discards instructions the generator itself cannot answer coherently is not optional.

The techniques compose into one loop, and seeing where each sits explains why skipping any of them produces a characteristic failure.

A seed pool feeds prompt construction. Seeds may be human-written, drawn from real data, or produced by earlier rounds of the loop.

Prompt construction combines a seed with attribute conditioning, and passes it to the generator.

Generated candidates hit a novelty filter that compares each against everything already accepted. Survivors are added to the dataset, and the good ones are also fed back into the seed pool, which is what makes the loop expand rather than repeat.

A separate evolution branch takes accepted instructions and produces harder or adjacent versions, feeding them back into prompt construction.

Remove the novelty filter and the loop converges to a narrow region within a few rounds. Remove the feedback edge and it never expands past the initial seeds. Remove evolution and difficulty stays flat.

The response-generation stage sits after all of this, deliberately, because it is cheaper to fix the diversity of ten thousand instructions than of ten thousand full examples.

Where structure is known, the strongest generator is not a language model at all.

Programmatic generation constructs examples from rules, and its defining property is that ground truth is known by construction because you generated the answer before the question.

A maths dataset: sample an expression tree, evaluate it exactly, then render it as a word problem. The answer is correct by arithmetic, not by a model's opinion.

A SQL dataset: generate a schema, generate a query against it, execute it on synthetic rows, and render the query as a natural language request. The mapping is exact.

A structured-extraction dataset: build the record first, then have a model write a document that contains it. The labels cannot be wrong, because the label produced the text.

That last inversion is worth noticing. Generating the answer and then the question converts a labelling problem, which is hard and error-prone, into a rendering problem, which is easy.

The limitation is realism. Templated text has a signature, and a model trained only on it learns to handle a language nobody speaks. The usual remedy is a hybrid: programmatic ground truth, model-generated surface form.

Diversity claims have to be measured, because reading a sample is systematically misleading: a human reader sees fifty varied-looking rows and does not perceive that they occupy one corner of the space.

Embedding spread. Embed every example, then look at the distribution of pairwise distances or the volume of the resulting cloud. A tight cluster is a narrow dataset regardless of row count.

Cluster count. Cluster the embeddings and count how many meaningful groups exist, and how unevenly populated they are. A hundred thousand examples in twelve clusters is twelve examples with variations.

N-gram overlap. The cheap proxy Self-Instruct uses. High overlap between examples indicates paraphrase rather than variety.

Nearest-neighbour distance. For each example, distance to its closest neighbour. A distribution concentrated near zero means near-duplicates the exact-match check missed.

The most informative comparison is against real data. Embed a sample of real inputs and your synthetic set in the same space and compare the regions they occupy. The usual finding is a synthetic cloud sitting inside a much larger real one, and the gap between them is exactly the traffic your model will handle badly.

The examples worth having are the ones a generator will not produce spontaneously, because they are rare by construction and a sampler goes to the mode.

Asking for edge cases directly produces a model's idea of an edge case, which is a mildly unusual normal case. Three approaches work better.

Enumerate the failure taxonomy first. Write the list of ways the task can go wrong: ambiguous input, contradictory instructions, missing required information, adversarial phrasing, out-of-scope requests, mixed languages. Then generate against each category deliberately. This converts a diversity problem into a coverage checklist.

Mine real failures. Every production error is a template for a family of similar inputs. Take the ones you have and generate variations, which is the highest-value synthetic data available because the seed is genuinely real.

Perturb systematically. Take working examples and break them in defined ways: truncate, inject typos, remove a field, contradict an earlier statement.

And remember that a dataset needs the cases where the correct answer is a refusal or a request for clarification, which generators rarely produce unless asked.

In rough order of return on effort, for a team starting from a naive generation script.

Write a seed attribute list and cross it into the prompts. This is an afternoon of work and usually the largest single improvement, because it moves the conditional distribution rather than widening it.

Add a novelty filter against accepted examples. Cheap n-gram overlap is sufficient to start, and it is what stops the pool from densifying.

Separate instruction generation from response generation, so diversity can be fixed on the cheap half.

Measure embedding spread against real inputs, and keep measuring it as the dataset grows. This is the number that tells you whether the previous three steps worked.

Enumerate a failure taxonomy and generate against it explicitly, rather than hoping edge cases appear.

Use programmatic generation wherever ground truth can be constructed, since it is the only method whose labels cannot be wrong.

What none of this addresses is whether the generated examples are any good. Coverage and correctness are separate problems, and the next lesson is about the second one.