Synthetic Data Isn't New. The Scale Is.
The mechanism underlying synthetic data for fine-tuning is not new. What has changed is scale and accessibility. Where it works, where it breaks, and what the defensible production pattern actually looks like.
The mechanism underlying synthetic data for fine-tuning is not new. Hinton described knowledge distillation in 2015: a stronger model (the teacher) generates soft labels for a training set, and a smaller model (the student) trains on those labels rather than on hard ground truth. The student learns to approximate the teacher's output distribution, which carries more information than binary correct/incorrect labels. The student is compressed but not degraded in the ways that simple compression would produce.
What has changed is scale, accessibility, and the specific ways in which this mechanism is now being applied. The availability of very capable teacher models via API, the infrastructure for generating synthetic datasets programmatically, and the emergence of cases where synthetic data straightforwardly outperforms human-labeled data have brought the technique from an interesting research direction to a practical tool. The failure modes are specific enough that the distinction between good and bad use matters.
Where synthetic data actually helps
Format and style normalization is the clearest case. You have a base model with good general capabilities but inconsistent output formatting: it sometimes produces the required JSON, sometimes wraps it in explanation text, sometimes uses slightly different field names. The correct output for any given input is unambiguous; the problem is that the model doesn't reliably produce it. A synthetic dataset of (input, correct output) pairs, generated by a teacher model configured to always produce the correct format, is cheap to generate and produces reliable fine-tuning signal. This is a good use of synthetic data.
Data augmentation for low-resource tasks is the second strong case. You have a task with 500 labeled examples, which is not enough for reliable fine-tuning. A teacher model can generate variations of those examples, including paraphrased inputs, reformulated questions, and alternative phrasings, that expand the dataset while preserving the label distribution. The resulting dataset of 5,000 examples is not equivalent to 5,000 human-labeled examples, but it is typically much better than 500 human-labeled examples, particularly for tasks where the core challenge is input diversity rather than label accuracy.
Fine-grained reasoning traces are a more recent application that has produced strong results in specific settings. Rather than labeling final outputs, you use a teacher model to generate step-by-step reasoning chains for a set of problems, then train the student model to produce similar reasoning chains. The student learns not just the answer but the reasoning structure, which generalizes better to novel problems. This is the approach behind several recent small-model results that have achieved surprising performance relative to their parameter count.
The common pattern across the good cases is that the synthetic data is teaching behavior, not truth. It teaches the model how to format, how to vary inputs while preserving labels, how to expose reasoning structure, or how to imitate a stronger model's procedure on a bounded task. That boundary matters. When the target is behavioral regularity, synthetic data can be extremely useful; when the target is factual authority, the same mechanism becomes fragile.
Why knowledge injection fails
The most common misuse of synthetic data is for knowledge injection: generating a synthetic dataset that teaches the student model facts about a domain, with the expectation that the student will reliably recall those facts in deployment.
This fails for the same structural reason that fine-tuning-based knowledge injection fails with human-labeled data: the model is not storing facts in a lookup table. It is adjusting its output distribution based on the patterns in the training data. If you generate 10,000 synthetic question-answer pairs about your company's product documentation and fine-tune on them, the resulting model will produce outputs that sound like they're drawing on that documentation. The factual accuracy of those outputs is not guaranteed, and the failure mode is specifically bad: the model produces confidently wrong outputs in the domain where you've trained it to sound authoritative.
The reason this happens: the teacher model generating the synthetic data makes mistakes. It confuses similar entities, it misremembers specific values, it fills gaps in its knowledge with plausible-sounding fabrications. These errors are in the synthetic dataset, and the student model learns them alongside the correct information. Unlike a database, you cannot inspect the fine-tuned model and identify which facts it has stored incorrectly.
Retrieval is the right solution to knowledge injection. Synthetic data is not.
The teacher ceiling
A structural limit of synthetic data for capability improvement: the student cannot exceed the teacher. More precisely, the student's capability on the task the synthetic data covers is bounded by the teacher's capability on that task. If the teacher makes systematic errors, consistently misunderstands a particular type of reasoning, or has blind spots in a particular domain, the student learns those errors.
This limit is binding in specific ways. For tasks where the teacher model is near the frontier, such as common reasoning tasks, general language tasks, and code generation in popular languages, the student can approach the teacher's capability with much smaller parameter count, and this is useful. For tasks where the teacher model is itself unreliable, such as niche technical domains, tasks requiring precise numerical reasoning, or tasks requiring knowledge that was underrepresented in the teacher's training, synthetic data amplifies the teacher's failures rather than compensating for them.
The practical implication is that synthetic data quality assessment requires evaluating the teacher's reliability on the specific task before generating training data. If the teacher achieves 90% accuracy on your task, synthetic data will produce a student that can approach 90% accuracy. If the teacher achieves 60% accuracy on your task, synthetic data will produce a student that achieves approximately 60% accuracy and does so with high confidence, which is worse than a student that achieves 60% accuracy with appropriate uncertainty.
The diversity problem
Synthetic datasets generated by a single teacher model have a diversity problem. The teacher has a characteristic style, a characteristic set of mistakes, and a characteristic distribution over output variations. These characteristics transfer to the synthetic dataset, and from there to the fine-tuned student.
Human-labeled data has diversity that emerges from the fact that it was labeled by humans with different linguistic styles, different error patterns, and different ways of approaching edge cases. This diversity is noise, but it is also a regularizer. It forces the model to generalize across human variation rather than overfitting to a single annotator's patterns.
Mitigation strategies include generating synthetic data with multiple teacher models (different checkpoints, different temperatures, different few-shot examples), explicitly injecting variation into the generation prompts, and mixing synthetic data with human-labeled data where available. The last option is usually the most effective: synthetic data augmenting a small human dataset is generally better than synthetic data alone.
The verification gap
A property of human-labeled data that synthetic data lacks: humans can label things they don't know how to generate. A human rater can reliably identify whether a piece of code is correct, whether a translation is accurate, whether a summary is faithful, even if they couldn't produce that output themselves. This asymmetry between generation and verification is what makes human evaluation hard to replace entirely.
Teacher models don't have this asymmetry in the same way. A teacher model is typically as good at verifying as it is at generating, which means it makes similar errors in both directions. If the teacher can't reliably generate a correct solution to a particular type of problem, it also can't reliably identify whether a proposed solution is correct. Synthetic data generated without an independent verification step (a different model, a symbolic checker, a human reviewer on a sample) will include errors that no downstream filter catches.
This is the current practical limit of fully automated synthetic data pipelines. For tasks with verifiable outputs, such as code execution, mathematical proofs, and structured data with integrity constraints, automated verification is possible. For tasks where correctness is a matter of judgment, the verification gap remains open.
The production pattern that seems most defensible is therefore not "generate a million examples and train." It is generate, filter, verify, sample, and only then train. The filter can be a symbolic checker, a second model with different failure modes, a human review pass over a stratified sample, or some combination of all three. The point is not to make synthetic data pure, because it never is. The point is to understand the error distribution before the student model learns it as if it were signal.