The big idea

What is a synthetic data pipeline?

Good models need lots of good data — but human labeling is slow, expensive, and often unavailable for a new task or a rare case. LLMs can generate training and eval data far faster and cheaper. The catch: a naive "generate 10,000 examples" gives you a repetitive, error-riddled pile that makes models worse. The value isn't generating data — it's generating diverse, correct, useful data.

A synthetic data pipeline manufactures quality datasets with a strong teacher model, then earns their usefulness through diversity steering, quality filtering, and verification. The output feeds distillation (train a smaller model), augmentation (fill data gaps), and eval sets. Generate is easy; diversity + validity are the system.

How to read this: Each step opens with a real design decision — make the call before I show you what ships. Watch the pipeline grow, and at the end drop the filter and disable diversity to see garbage-in and mode collapse. Hit Begin.

Step 1 · Why "just generate" fails

Repetitive and wrong

The obvious approach: prompt an LLM "generate 10,000 training examples for task X" and use the output. Why is that dataset bad?

Design decision: Prompt an LLM to "generate 10,000 examples" and use them directly. What's wrong?

The call: Low diversity (mode collapse) + errors (hallucinations, wrong labels, malformed) — training on it teaches narrowness and mistakes. — Unsteered, the model clusters around a few templates (low diversity) and confidently produces some wrong or malformed examples (errors). A model trained on that learns a narrow slice with baked-in mistakes. The pipeline must add diversity and filter/verify quality.

Unsteered generation fails two ways. Low diversity: the model clusters around a few patterns (mode collapse), so the dataset covers a narrow slice of the real distribution. Errors: it confidently produces some hallucinated, wrong-label, or malformed examples. Train on that and the model learns narrowness and mistakes. The generation is the easy 10%; making the data diverse and correct is the system.

Diversity + validity are the product: Raw generations are neither varied nor reliably correct. A synthetic data pipeline is mostly the machinery that fixes those two problems — steering variety and filtering/verifying quality — because that's what determines whether the resulting model improves or degrades.

Step 2 · Spec in, dataset out

The pipeline shape

Frame it as a pipeline. What does it take in, what stages does it run, and what does it guarantee about the output?

The pipeline takes a task spec — the task, an output schema, a few seed examples, and constraints — and runs stages: generate (teacher model) → diversify (steer variety) → filter (reject bad) → verify (check correctness) → store. The guarantee isn't "lots of data" but "diverse, filtered, validated data fit for training/eval." The spec (especially the seeds and schema) steers everything; each stage removes a failure mode of raw generation.

Generate then curate: Think generate-and-curate: cheap over-generation followed by aggressive selection. You generate more than you need and keep only the diverse, correct subset. The stages after generation are where quality is won — the teacher just supplies raw candidates.

Step 3 · The teacher

Generation with a strong model

Candidates have to come from somewhere. What generates them, and how do you steer what gets generated?

Use a strong teacher model prompted with templates, the seed examples, and often personas or roles to shape style and content. You can generate inputs, outputs, or both (e.g. a question and its answer), and use techniques like self-instruct (bootstrap new tasks from seeds) or having the teacher produce step-by-step reasoning. The teacher is usually a bigger/better model than the one you'll train — you're transferring its capability into data.

Teacher → data → student: The teacher is a capable model whose knowledge you're crystallizing into examples. Seeds and templates steer the domain; personas/roles add variety and realism. Generating reasoning traces (not just answers) is a common way to make the data teach how, not just what.

Step 4 · Cover the space

Steering diversity

Left alone, the teacher repeats itself — the number-one failure of synthetic data. How do you force it to cover the breadth of the real distribution instead of echoing a few templates?

Design decision: The teacher keeps producing similar examples (mode collapse). How do you get real diversity?

The call: Just generate more with the same prompt. — More of the same prompt gives more of the same output — it deepens mode collapse rather than fixing it. You must vary the generation systematically and dedup.

Steer diversity explicitly. Sweep a space of attributes — topics, difficulty, style, personas, edge cases — so each generation targets a different region of the distribution (attribute/topic sampling); raise sampling temperature for variety; and de-duplicate near-identical outputs (e.g. by embedding similarity). This turns "the model's favorite ten patterns" into broad coverage. Diversity is engineered, not hoped for — it's the difference between data that generalizes and data that collapses.

Engineer the coverage: Mode collapse is the default; diversity is a design task. By parameterizing generation over an attribute grid (and deduping), you cover the space deliberately. A model trained on diverse synthetic data generalizes; one trained on collapsed data memorizes a sliver.

Step 5 · Reject the bad ones

Quality filtering

Even from a good teacher, some generations are malformed, off-task, low-quality, or mislabeled. Letting those into the dataset poisons training. How do you keep only the good ones?

Filter every candidate before it enters the dataset. Cheap rule/format checks first (schema valid? right length? on-task?), then a model-as-judge to score quality/correctness and reject low-scoring examples — and often generate extra so you can afford to throw many away. This is generate-and-select: over-produce, then keep only the high-quality subset. Filtering is what makes synthetic data trustworthy — without it, the teacher's confident mistakes become the student's learned mistakes.

Over-generate, aggressively select: Quality comes from selection, not from the teacher being perfect. Generate a surplus, apply rule checks + an LLM judge, and discard aggressively. A smaller, cleaner dataset beats a larger, dirtier one for training — filtering is the highest-leverage stage.

Step 6 · Prove it where you can

Verification & grounding

Filtering catches obvious junk, but for factual or code data you can often do better than a judge's opinion — you can check correctness. How, and why does it matter so much?

Verify correctness whenever the task allows a ground truth. Generated code? Execute it against tests and keep only what passes. Factual claims? Check against a source (retrieval/grounding) or require citations. Math? Verify the answer. This is far stronger than a judge guessing, and it's how you get reliable synthetic data for domains where wrong labels are poison. Verification turns "the teacher says it's right" into "we proved it's right."

Execute/check > judge-opinion: Where correctness is checkable (code runs, math computes, facts are sourced), verify it rather than trusting the model. Execution-based filtering (keep code that passes tests) is a gold-standard technique — it grounds the dataset in objective correctness, not model confidence.

Step 7 · What it's for

Distillation, augmentation & evals

You have a clean, diverse, verified dataset. What do you actually do with synthetic data?

Three main uses. Distillation: train a smaller, cheaper student model on the strong teacher's outputs — capturing much of its capability at a fraction of the cost. Augmentation: fill gaps in real data (rare classes, edge cases, new tasks) or expand scarce datasets. Eval sets: generate test cases to measure a model (with care about contamination). Done well, this is a flywheel: a strong model generates data that trains/improves models, cheaper than human labeling.

The teacher→student flywheel: Synthetic data's headline use is distillation: crystallize a big model's ability into data and train a small model on it. Plus augmentation for coverage and generated evals. The economics — cheaper and faster than humans — are why synthetic data is everywhere, when its quality is controlled.

Step 8 · The sharp edges

Collapse, bias, contamination & rights

Synthetic data has serious traps: model collapse (training on synthetic degrades over generations), bias amplification, test-set contamination, and licensing of teacher outputs.

Avoid model collapse — recursively training models on their own synthetic output degrades quality/diversity over generations — by mixing in real data, enforcing diversity, and verifying quality (don't train blindly on unfiltered self-generated data). Watch bias: the teacher's biases get amplified in the data, so measure and rebalance. Prevent contamination: never let synthetic eval data leak into training, and don't generate evals from the same distribution you'll test on naively. Respect licensing/terms of the teacher model's outputs. And always evaluate the downstream model on real held-out data — synthetic data is a means, real-world performance is the judge.

Design for the unhappy path: Collapse → mix real data + diversity + verification. Bias → measure + rebalance. Contamination → strict train/eval separation. Rights → respect terms. Synthetic data can quietly degrade or mislead if unmanaged, so the guardrails (real data anchor, quality gates, clean evals) are as important as the generation itself.

You did it

You just designed a synthetic data pipeline.

• N — a
• T — h
• A —
• E — n
• O — v
• V — e
• U — s