Synthetic Data: Generating Candidates Is Easy, Increasing Useful Information Is Hard

Synthetic data refers to training samples produced by models, programs, or simulators, rather than samples directly observed from the target world and then recorded by humans. Here the 'producer' can be a language model, a code program, or a physical or business simulator; the content produced can be the input itself, labels, reasoning traces, preference pairs, code execution results, or even entire simulated interaction trajectories. The first step in understanding synthetic data is to distinguish two things: the number of samples and the amount of effective information carried by samples are two completely different properties.

A language model may write one million question-answer pairs, yet the effective information may be equivalent to only several thousand. The reason lies in the generation mechanism itself: the generator samples from the distribution it has learned, and it tends to reproduce patterns common in training, so samples within the same batch are highly correlated. The first sample and the one millionth sample may be only slight variations of the same template; no matter how many there are, they do not increase independence, novelty, or correctness. Real-world failure cases are often exactly rare, low-probability events, and these are the events that models are least likely to spontaneously produce when sampling. Expecting 'generating more' to automatically fill these gaps does not work.

The input to synthetic data is a set of real failure slices that need to be supplemented and explicit generation rules; the output is the generated samples. The real failure slices tell the generator 'where the gaps are,' and the generation rules tell it 'how to vary.' Only when the generated samples cover the real gaps and pass verification independent of the generator can the samples increase effective information. In other words, effective information is not created by the generator but carried by it: it must come from sources behind the generation mechanism that possess the real structure—rule bases, program semantics, simulator physics—and then the generator spreads this structure into samples that cover the gaps.

A concrete example is a refund assistant. Content that can be synthesized includes: combinations of policy boundaries (enumerating condition items from authoritative policy according to combination rules), colloquial paraphrases (rewriting formal expressions into various user phrasings), and tool error trajectories (simulating tool anomalies such as query timeouts and missing amount fields). But the real policy facts themselves, such as how long the refund window is for a certain type of order, must come from authoritative rule documents; a teacher model must not be allowed to 'create' them from memory. Once the source of facts is wrong, all subsequent combinations and paraphrases merely amplify that error.

This boundary also determines how to evaluate. A model performing more accurately on a synthetic test set only shows that it has adapted to that synthetic set—it may have simply memorized the wording and distribution preferred by the generator. The real conclusion must come from true held-out tests: cases that the generator has never seen and that are collected directly from the real world. Scores on a synthetic set are a signal of internal consistency, not evidence of external validity.

Therefore the correct starting point is: first start from real failure slices, clarify what is missing, and then choose the corresponding generation mechanism; rather than first generating massive amounts of data and then looking for uses afterward. The use of data comes from gaps, not from quantity.

Synthetic data is not a single category. The four sources—teacher models, programs, pseudo-labels, and data augmentation—differ in what they generate, where their ground truth comes from, and how they fail, so they cannot share a single set of trust assumptions. To judge whether a batch of synthetic data is reliable, you must first determine which source it belongs to. The inputs for this section are the type of gap, the available generators, and the available sources of ground truth; the output is a data pipeline with source types and verification requirements.

Teacher distillation refers to using a stronger model to generate demonstrations, explanations, or preference pairs to train another model. Its ground truth comes from the teacher's ability and from external verification. The main failure mode is transmitting bias and style: the teacher's own errors, wording habits, and biases are copied into generated samples in bulk, and the student learns the teacher's output distribution rather than the structure of the task itself. Therefore, the premise for teacher distillation is that the teacher is genuinely reliable on that task, or that independent external verification can filter out its errors.

Programs and simulators generate problems, labels, and even entire trajectories. Their ground truth comes from rules, execution results, or solvers: the label of a math problem can be determined by a solver, and a tool-call trajectory can be confirmed by program execution. The main failure mode lies in the gap between simulation and reality: the conditions, noise, and failure modes in the program world may not be the same as those in the real world, and a simulator, however precise, is only an approximate model of reality. Program skeletons are best suited to tasks with clear rules, because only when the rules are clear can execution results serve as authoritative labels.

Self-training refers to the model assigning pseudo-labels to unlabeled inputs and then using those pseudo-labels to continue training itself. Its ground truth comes from the model's own confidence or the consistency of multiple outputs. The main failure mode is confirming its own errors: the parts where the model is most confident are often exactly the parts it already knows; for the parts it does not know, the pseudo-labels are often wrong, so self-training strengthens existing abilities while also entrenching existing errors more deeply. Self-training relies on regions where the model is already reliable, rather than using it to open up new knowledge boundaries.

Data augmentation refers to rewriting, perturbing, or transforming existing samples to increase the amount of data. Its ground-truth assumption is that labels should remain unchanged under transformation: changing “Please help me return the order” to “I want to return this one” should not change the intent label. The main failure mode is that the transformation secretly changes the label: a different wording may turn a request into a complaint, turn an affirmation into a negation, or turn a computable problem into an uncomputable one. The premise for augmentation is that the transformation itself is label-preserving, and this requires a careful understanding of task semantics; you cannot assume that all transformations are safe.

Looking at these four sources together, each has its strengths. Programs construct verifiable skeletons and are responsible for factual and logical correctness; teacher models add linguistic diversity and are responsible for extending the skeleton to cover real expressions; self-training can only scale up in regions where the model is already reliable; augmentation requires that transformations do not change the label. A strongest combination is usually: programs construct verifiable skeletons, teacher models add linguistic diversity on top of them, and finally rules and manual sampling are used for review, connecting the verification steps of the different sources into the same pipeline.

It is precisely because the sources are so different that data provenance (provenance) becomes a hard requirement. Provenance records, for each sample, which input, which generator, which version, and which verification steps produced it. Samples from different sources must retain their own provenance and cannot be mixed into a vague “synthetic=true” label. Once a problem occurs—for example, if a batch of samples is shown to have incorrect labels—only with complete provenance can the affected samples be precisely withdrawn and the trust strength of different sources be distinguished. For synthetic data without provenance, once an error occurs, responsibility can no longer be located, and it is impossible to judge which results can still be trusted.

The output distribution of a synthetic data pipeline is not determined by the generator alone; it is the joint result of the generator, verifier, and mixing weights. It can be written clearly as a proportional relationship. Let x be a synthetic input and y be a label, answer, or trajectory. Then the relative density of the retained samples (x, y) satisfies:

q_retained(x,y) ∝ q_generated(x,y) × a(x,y) × w(x,y)

Here q_generated(x,y) denotes how often the generator produces the candidate, a(x,y) is the probability that the verifier accepts the candidate, and w(x,y) is the retention weight set for topic, difficulty, language, or risk. The symbol ∝ means “proportional to”: after multiplying these three terms, all retained candidates must be normalized so that the probabilities of all (x, y) sum to 1, yielding the true final distribution q_retained.

The meaning of this expression can be read directly: the generator determines where candidates can reach, the verifier determines who can pass, and the mixing weights determine how much of each passing candidate is retained. If any one of these three links changes, the final training distribution changes. Content that the generator never produces will not enter the training set no matter how lenient the verifier is or how high the weights are; content that the verifier rejects will be blocked even if the generator produces it in large quantities; and the mixing weights redistribute quantities among those that pass, determining how large a share long-tail topics and less common difficulty levels can occupy.

This expression also explains why a high verification pass rate and a high-quality retained set are two different things. Suppose the verifier only checks whether the final amount is correct. Then an answer whose reasoning process is completely wrong but which happens to arrive at the correct final number will also be accepted: a(x,y) is also close to 1 for such samples, and incorrect reasoning still enters the retained set in large quantities. Suppose further that easy questions naturally pass verification more easily, while hard questions have a low pass rate. Then the filtering step pushes the distribution further toward easy: even if the generator originally produced many hard questions, the verifier's rejections will systematically reduce them. A high acceptance rate may simply mean that the generator is catering to a weak verifier, not that the data has improved.

Therefore, when evaluating a pipeline, reporting only “how many items were ultimately retained” is meaningless. You should simultaneously report the number of candidates, the acceptance rate, the number after deduplication, the difficulty distribution and slice coverage, the verifier's own error rate, and the distance between the retained distribution and the true target distribution. The candidate count indicates the generator's coverage; the acceptance rate indicates how much the verifier intercepted; the deduplicated count indicates how many truly independent samples were added; the difficulty and slice coverage indicate whether gaps have been filled; the verifier error indicates how many mistakes have slipped in; and the distance to the target distribution indicates whether the final q_retained is still the desired distribution. Without any of these, it is impossible to judge whether the retained set is close to the actual gap or merely the product of the generator and verifier catering to each other.

There is an even more subtle role: the verifier is also a selector. It not only removes bad samples but also determines which styles and which solution methods can survive. A verifier biased toward standard wording will gradually eliminate nonstandard expressions; a verifier that only recognizes one type of solution path will cause other paths to disappear from the training set. The verifier participates in defining the shape of the training distribution, so it too must be independently evaluated; just because it is a “filter” does not mean it is neutral by default.

Apply the previous section's formulas to a real pipeline, and the numbers become intuitive. A generation process for refund boundary data: 100,000 synthetic refund samples go through rule validation, semantic deduplication, coverage quotas, and manual sampling in sequence, ultimately forming the training mixture. The entire process is like a funnel; Figure 1 shows this funnel; its goal is not to retain as much data as possible, but to leave data that is verifiable, non-duplicate, and covers the target slices. The loss in quantity at each step is only justified when it corresponds to a quality gain.

The four stages can be listed one by one. The first stage is generation, producing 100k candidates, 100% of the previous step; the question to spot-check at this step is: do the candidates really cover the gaps, or are they just piling up in regions the generator is familiar with? The second stage is rule validation, leaving 60k, 60%; this step removes clearly erroneous samples according to eligibility, amount, and evidence rules; the question to spot-check is: does the validator miss errors (fail to reject what should be rejected) or falsely reject correct samples (reject what should not be rejected)? The third stage is semantic deduplication, leaving 24k, 40% of the previous stage; this step uses semantic neighbors to find and delete samples with duplicated wording; the question to spot-check is: does it mistakenly delete rare expressions—the long-tail expressions that are rare but real, which may be the most valuable part? The fourth stage is coverage sampling, leaving 12k, 50% of the previous stage; this step corrects the remaining distribution according to language, difficulty, and risk quotas; the question to spot-check is: are the real target weights and long-tail coverage set correctly, and do the quotas themselves reflect the real-world distribution?

The overall acceptance rate of this pipeline is 12%. This number itself does not indicate good or bad: if only one thousand out of one million generated candidates are worth retaining, a low acceptance rate actually shows the pipeline is doing its job; conversely, a high acceptance rate could mean the validator is useless. The key is whether the reasons for rejection at each step are valid, and whether correct samples are also mistakenly killed. Each step requires manual spot checks for false rejections and false deletions, because reducing quantity itself does not equal improving quality—it is easy to delete samples, but hard to delete only those that should be deleted.

Finally, there is the mixing ratio issue. Suppose the training mixture has 60k samples in total, with 12k synthetic samples accounting for 20%. Just because synthetic candidates are “free”, you should not push the synthetic ratio all the way to 90%. Real data plays a role that synthetic data cannot replace: it preserves the tail of language—the real expressions that the generator cannot write—and external world constraints, such as real policy execution results and user behavior. Synthetic data expands coverage on top of real anchors, rather than replacing the anchors. Real samples anchor the distribution, synthetic samples fill the gaps, and the two are mixed according to the size of the target gap, not according to generation cost.

Among all verification methods, executable verification is the strongest kind: it does not rely on any model’s judgment, but lets facts speak for themselves. Substituting the answer to a math problem back into the equation yields a true equality, a piece of code passes all given tests, a JSON can be read by a parser without errors—these are deterministic, reproducible evidence. But the strength of executable verification has a precise boundary: it can only prove the assertions that have been written down, and nothing else.

The properties an executor can prove are limited. It proves that a program passes the given tests, but cannot prove that the tests cover boundaries that were not written down; it proves that substituting a result into an equation satisfies it, but cannot prove that the derivation process contains no errors; it proves that the JSON format is parseable, but cannot prove that the requirement itself is correct, nor that the code has no security vulnerabilities. A sample that passes all executable checks can still be “toxic”: it carries a behavior that happens to satisfy the assertions but is completely wrong outside the assertions. Verification strength depends entirely on how complete the assertions are; in areas not covered by assertions, the executor has no say.

What is more troublesome is that the generator will actively seek out loopholes in the verifier. When the generator’s goal is “passing verification” rather than “solving the problem”, it optimizes the signal given by the verifier instead of optimizing the true objective. This is reward hacking: the generator learns to exploit loopholes in tests, producing samples that pass all assertions but are worthless. The more fixed and public the verifier is, the easier it is to be turned into an optimization target.

The way to counter this is multiple verification and continuous adversarial testing. First, do not rely on only one type of verification: layer static rules, executable verification, and independent models or human review so that different types of checks complement each other. Second, perform a mutation test on the verifier itself: deliberately inject errors into correct samples and see whether the verifier can reject them. A verifier that cannot even catch deliberately introduced errors has no verification capability. Third, maintain hidden tests and update them regularly to avoid the generator overfitting public assertions—if the generator has seen all the test problems, it is merely memorizing answers.

For high-risk data, an even more fundamental principle is needed: rely on evidence from sources, not on majority votes among models. Teacher models and judge models from the same family may share the same batch of blind spots; their “agreement” does not constitute independent evidence. The consensus of two models from the same source carries no more information than a single model. Truly independent verification must come from different sources of truth—rules, execution, heterogeneous models, or humans. Different sources make evidence; the same source is merely an echo.

The most common mistake when evaluating synthetic data is using one metric as a substitute for another. Diversity, difficulty, and authenticity are three different properties and must be measured separately; a high score on any one of them does not automatically imply the other two are also good.

Start with diversity. A commonly used tool is embedding distance: convert texts into vectors and then measure how far apart two pieces of text are in representation space, typically used to find semantic neighbors. Its limitation is that a large distance only means the current representation model considers the two texts different; it does not guarantee that they are genuinely novel in task structure, nor that they correspond to real user populations. Lexical, semantic, structural, solution, and population diversity are different dimensions: random rewriting with high-temperature sampling can greatly increase wording-level differences without adding any task-structure differences—a hundred ways of saying the same thing do not broaden coverage. Similarly, a set of structurally diverse samples that all come from regions the generator is familiar with still fails to cover unrepresented real-world inputs.

Therefore, the inputs to evaluation are synthetic candidates, a real failure taxonomy, and target slices; the outputs are a set of complementary metrics: repetition rate, difficulty, coverage, real/synthetic separability, and downstream gain. First build a coverage matrix based on the real failure taxonomy, dividing the gaps into cells such as language, policy boundaries, missing fields, conflicting evidence, attacks, and tool failures, then set target quantities and real anchors in each cell. The value of the matrix is that it turns “coverage” from a slogan into a checklist that can be inspected cell by cell.

Each of the five metrics answers one question and also has something it cannot prove. n-gram or semantic repetition rate answers “whether there are too many near neighbors,” but cannot prove task-structure novelty; difficulty stratification answers “at which difficulty levels validation and models succeed,” but cannot prove relevance to reality; slice coverage answers “whether predefined combinations appear,” but cannot prove that the unknown long tail has been covered—the world outside the predefined combinations is exactly what is invisible; a real/synthetic classifier answers “how separable the two distributions are,” but cannot prove which side is more correct; separability only shows that the distributions differ, not that synthetic data is better or worse; downstream gain answers “how much task performance changed after training,” but cannot prove there are no side effects or that the effect is causally unique—the improvement may come from other causes.

Individual metrics cannot substitute for one another: semantic diversity does not prove relevance to reality, and complete slice coverage does not prove the unknown long tail has been covered. The final evidence can only come from held-out real tests and ablation experiments. The control design should include: a real-data baseline, adding synthetic data on top of the real-data baseline, replacing synthetic data with an equal amount of real data, and a label-shuffled control group. If adding synthetic data does not outperform an equal amount of real data, these synthetic samples do not provide marginal value beyond real data; if the label-shuffled control group also improves, the improvement is not coming from the true information in the labels. Only when these controls all hold up can synthetic data be shown to bring independent gains.

The claim that "models learning from models get worse with each generation" turns model collapse into an inevitable law, but the actual mechanism is more nuanced. Collapse is not determined by the act of "training a model on model outputs" itself, but by three things together: whether each generation replaces or accumulates data, what proportion is synthetic data, and how filtering and validation are carried out.

First, look at why collapse occurs. If each generation replaces the previous generation's real data with generated samples, the training distribution drifts further and further from the real distribution. Generators naturally undersample the tail: they tend to output the most common patterns from training, and rare languages and rare scenarios appear much less often in their output than in the real world. In the next generation, the model learns from this already tail-trimmed distribution, and the tail is trimmed another layer. Iterated in this way, rare patterns disappear generation by generation, while systematic errors and stylistic preferences, because they are always generated and always learned, are amplified generation by generation instead. Average performance may look fine because what is trimmed is low-probability events, but structural capability has already been lost.

The collapse path can be described by a mixture formula. The training distribution that the t-th generation model sees is:

Dₜ = (1 − α) × D_real + α × D_synthetic,t

where Dₜ is the training distribution seen by the t-th generation model, D_real is the retained original real data distribution, D_synthetic,t is the distribution of the t-th generation's generated data, and α is the proportion of synthetic data. Note that this equation only describes the mixture weight level: it says "how much of each generation's training set is real and how much is synthetic." But it does not describe the three factors that actually determine the rate of degradation—whether real data continues to accumulate across generations, which tails the generator misses, and how much error the verifier itself has. If D_real is present in every generation and accumulates across generations rather than being replaced, the degradation path will be significantly different; if the verifier can independently intercept errors, errors will not necessarily be amplified. Therefore, "synthetic data is bound to collapse" and "filtering alone is safe" are both oversimplifications; the actual conclusion depends on how replacement, accumulation, and filtering work together.

Corresponding monitoring metrics should also cover these dimensions: tail coverage, entropy, duplication rate, separability between real and synthetic data, correlation of errors across generations, and performance on a real held-out set. Among these, cross-generation error correlation is particularly noteworthy: if the errors made by generation t+1 overlap heavily with those of the previous generation, it indicates that errors are being copied rather than corrected. There is another key judgment rule: stable average accuracy does not mean there is no collapse. Minority languages and rare scenarios may have already disappeared while overall metrics remain stable. Only by continuously validating on real isolated slices can one distinguish "overall stability" from "tail disappearance"—two states that look identical in aggregate metrics.

The last line of defense is source labels. The internet already contains a large amount of unlabeled model-generated content; if this synthetic backflow is collected as newly appearing real data, teams will unknowingly feed model outputs back into models. Once source labels are lost, it is impossible to know which "new data" are actually echoes of one's own system. Therefore, as soon as a sample enters the pipeline, its source information must travel with it; this is the most basic means of preventing hidden self-loops.

Synthetic data has an assumption that is easy to take for granted: "Since we generated it ourselves, it naturally has no copyright, privacy, or test contamination issues." This assumption does not hold. The generator does not create content out of nowhere; it reproduces patterns and fragments from the training data. The teacher model may reproduce copyrighted content from the training corpus verbatim or approximately, and may also output personal information seen during training. The prompts themselves may contain restricted documents, bringing in the original text. A generated paraphrase, even if differently worded, may be a close neighbor of an evaluation question. PII refers to information that can be used to identify an individual, such as name and contact details; evaluation contamination refers to training data including test questions or their near-answers, inflating evaluation scores. Synthetic data also carries these three types of problems, and because it is large in volume and fast to generate, it may spread even faster.

Therefore the object of governance is not the abstract concept of "synthetic data", but the entire pipeline: seed data, generator, templates, validator, and mixing plan. The outputs of governance are samples with stable IDs, source lineage, license information, and withdrawal paths. To what extent should lineage be recorded? Generator snapshot, prompt template, sampling parameters, random seed, input source, validator version, rejection reason, and final mixing method: all are indispensable. Only when all these are recorded does "withdrawal" become an executable action, not just a slogan.

Governance actions are distributed across the various stages of generation. Before generation, check the purpose and sensitivity of seed data: whether restricted documents can enter prompts and whether personal information can be used for generation must be determined before the data enters the pipeline. After generation, scan for memorized fragments, PII, malicious content, and close neighbors of evaluation sets, blocking leakage before it is stored. At storage time, perform semantic deduplication, but preserve clusters and representative samples; do not delete long-tail expressions just for the sake of cleanliness. During mixing, set caps by source, difficulty, and group to prevent a single teacher model from dominating the entire training set, turning one model's blind spots into the blind spots of the entire set. For real held-out sets, strictly isolate them: their questions and answers derived from them are prohibited from entering any prompts.

If problems are discovered later, the role of lineage becomes apparent: affected data can be withdrawn along the lineage, and training runs that used this data can be located. But conversely, be clear-headed: a single passing scan only means that current rules did not find problems; it does not amount to a conclusion about copyright, privacy, or authorization. "Model-generated" is also not a rights conclusion—it does not mean the content is exempt from copyright or contractual constraints; specific legal and contractual judgments must be handled according to region and use. Scanners are engineering defenses, not legal advice.

Synthetic data is not a matter of the more you use the better; it belongs in the right gaps. It is best suited to tasks where ground truth can be verified independently and with certainty: clear rule-based ground truth, reliable simulators, executable answer verification, or the need to combine boundary cases under privacy and security constraints—the kind of gap where real samples are extremely scarce but the structure is known. For example, enumerating policy boundaries, combining code paths, generating math problems—in these scenarios, the generator can expand at scale, the verifier can independently check, and the two are not the same source of truth.

The cases where self-deception is easiest are exactly the opposite: open-world facts, cultural preferences, rare harms, real user intent, and tasks where the verifier and the teacher come from the same source. Open-world facts have no authoritative rules to check, so a generator can only repeat from training memory; cultural preferences and user intent exist among real people, and what a model samples is only its imagination of those people; rare harms, because they are rare, almost never appear in the generator’s output; and when the verifier and teacher are from the same source, an answer written by the teacher and judged by a judge from the same series has a high pass rate only as an echo. These scenarios should invest in real observation, expert annotation, and participatory evaluation, rather than continuing to scale up synthetic volume.

To decide where to invest, the best method is a small-scale experiment. Compare “adding synthetic data” against “real data, human annotation, or tool improvement with equal budget” side by side, and look at marginal returns by slice. If, after adding synthetic data, the model only becomes more like the teacher in style and wording while real metrics do not improve, stop scaling up. Cheap generation cost does not mean filtering, governance, and error costs are cheap: the verification, deduplication, lineage, scanning, and withdrawal steps discussed earlier each involve human and engineering overhead. The generation cost saved may be paid back many times over in governance.

Finally, have clear stopping conditions. When the novelty of new batches after deduplication, the gain on a real held-out set, or the marginal coverage approaches zero, stop generating for quantity KPI. The value of synthetic data lies in covering new effective information; once a new batch no longer brings novelty, no longer improves real performance, and no longer expands coverage, continuing to generate merely replicates samples from the same distribution again. At that point, the answer is clear: the problem is no longer data volume, and you must return to the real world to find new information.

The synthetic data methodology can be condensed into a causal chain from problem to practice, where each step depends on the previous one, and the whole chain breaks if any link is missing.

Step one: define quantifiable gaps from real failures. Collect real-world failure slices and classify them into specific slices—language, policy boundaries, missing fields, conflicting evidence, attacks, tool failures—and set a target quantity for each cell. Without this step, all subsequent generation is merely aimless expansion.

Step two: choose the appropriate generation mechanism for the gap. For tasks with clear rules, use programs to construct verifiable skeletons; where language diversity is needed, use teacher distillation to expand expression; use self-training only in regions where the model is already reliable; use augmentation only when transformations do not change labels. The truth structure of the generation mechanism must match the gap, not just use whatever tools are available.

Step three: verify with independent rules, execution, or human review. The verifier's source of truth must be independent of the generator; passing verification only proves that the written assertions hold. Therefore, combine static rules, execution verification, and heterogeneous human review, and periodically run mutation tests to prevent the verifier from being gamed.

Step four: semantic deduplication, then sample by difficulty and group quotas. Remove near-duplicate neighbors, but retain rare expressions and representative samples; use quotas to pull the retained distribution back toward the target shape, rather than letting the natural bias in pass rates determine the final distribution.

Step five: limit mixing ratios and retain real anchors. Real data anchors the tail of language and external-world constraints; synthetic samples only expand coverage on top of the real baseline. Mix the two according to gap size, not generation cost.

Step six: run ablations on a real held-out set and iterate along the lineage. Use controlled experiments—real baseline, plus synthetic, equal real data, shuffled labels—to test the marginal gain from synthetic data; withdraw problematic data by lineage, fix the generator or verifier, and then walk through the chain again.

No step in this chain is an isolated technique: each step's input is the previous step's output, and each step's output becomes the constraint for the next. From real failures to generation mechanisms, from verification to mixing ratios, from blending to ablation, and finally back to real failures—the entire value of synthetic data lies in whether it ultimately makes the model better on real-world held-out tests. If not, return to step one and redefine the gap, rather than returning to step three and generating more.