Synthetic data for AI: useful coverage without false confidence

Synthetic data can help a team explore cases that are scarce, expensive to collect, or difficult to reproduce. It can also create a large dataset that mostly repeats a generator's habits. The difference depends on the purpose of the data, the controls around generation, and the independent evidence used to judge the result.

More rows do not automatically mean more information. A thousand polished examples built from the same underlying pattern may teach less than a smaller set covering genuinely different decisions. Before generating anything, identify the uncertainty you want the new data to reduce and the experiment that will tell you whether it helped.

This guide uses a fictional parcel-support classifier that distinguishes late delivery, damaged packaging, wrong item, and requests needing clarification. Every worked scenario is illustrative. The aim is to show how a team could design and audit a synthetic-data process, not to claim that synthetic examples have already improved a particular model.

Separate training, testing, and demonstration uses

Synthetic records can play several roles. Training examples influence a model. Test examples probe behavior. Demonstration records make a development interface usable without real customer data. These roles should have separate labels and handling rules because success in one role does not establish suitability for another.

A realistic-looking support message may be fine for a UI preview while containing an ambiguous category label that makes it unsuitable for training. A deliberately strange adversarial example can be useful for testing even though it does not represent ordinary traffic.

Write the intended role into the dataset specification. For the parcel classifier, one batch might expand development coverage of clarification requests. Another might exercise the interface's handling of empty fields. Combining them without provenance can make later evaluation difficult to interpret.

Start from an observable coverage gap

Review failures on appropriately obtained real or independently reviewed examples. Suppose the classifier handles explicit “wrong item” complaints but struggles when a customer describes the mismatch indirectly. That is a concrete gap to explore. “We need more data” is not yet an actionable generation plan.

Define the behavior the new examples should teach or test. A message saying the parcel contains shoes when a lamp was ordered should map to the relevant category even if it never uses the phrase “wrong item.” A message that names neither the order nor the received item may require clarification.

Keep the original failures available as diagnostic evidence, with the necessary permissions. They explain why the batch exists and help reviewers reject generated examples that are eloquent but unrelated to the target distinction.

Design dimensions that change the decision

Create a coverage matrix around meaningful variation: complaint type, clarity, message length, available evidence, language used by the audience, and combinations of issues. Add style variation after those dimensions are defined. Changing names and punctuation alone does little to expand decision coverage.

Include boundary cases. A customer may report a crushed box while saying the product works normally. Another may report a damaged product without mentioning packaging. The labeling policy must explain whether those belong to the same category or different ones.

Avoid making every combination equally common in the final evaluation by accident. A deliberately balanced development set can be useful for examining categories, but it does not estimate the distribution of incoming support traffic. Preserve the sampling design so metrics can be interpreted in the context of the question being asked.

Generate from facts when facts determine the label

One approach is to define a structured scenario first, then ask a generator to express it as a customer message. For example, the scenario can specify that the ordered item differs from the received item. Review whether the generated text actually preserves that fact before inheriting the scenario's label.

A generator can omit a crucial detail, add an extra problem, or change a negation. The intended label is therefore not automatically the correct label for the resulting text. Validate the relationship between the scenario and the written example, especially near ambiguous boundaries.

Keep the structured scenario and final text linked in provenance records. This makes it possible to diagnose whether a bad training example came from the scenario design, the wording step, or a later transformation rather than treating the whole pipeline as one opaque generator.

Keep independent judgment in the loop

If one model writes a message, assigns its label, and judges that label correct, agreement may simply reflect a shared misunderstanding. Use deterministic checks where they apply and independently reviewed samples for the decisions that require interpretation.

For the parcel classifier, reviewers can inspect whether the text contains enough information to distinguish a wrong item from a vague dissatisfaction complaint. Provide a written rubric and a disagreement process. A reviewer should be allowed to mark an example unusable instead of being forced to select a category.

Sample both accepted and rejected examples from automated filters. A filter that removes useful difficult cases can make the dataset appear cleaner while reducing its value. Record the reasons for rejection so changes to filtering can be evaluated rather than hidden inside a preprocessing script.

Examine diversity beyond word count

Look for repeated templates, sentence structures, vocabulary, and implied assumptions. A generator may overproduce polite, complete messages even when actual users write fragments. It may also repeat the same causal story across categories, creating shortcuts that a student model can learn.

Group near-duplicates and inspect the size of each family. Diversity metrics can help locate repetition, but manual review of representative groups remains useful. A low textual similarity score does not guarantee different reasoning requirements, and a high score can still contain an important change such as a negation.

Track coverage at the scenario level as well as the surface-text level. For this classifier, you want examples that vary the evidence needed for the label, not only examples that replace “package” with “parcel.” That distinction keeps generation tied to learning value.

Understand what model-collapse research does and does not say

The research paper The Curse of Recursion investigates degradation when generated content feeds later training generations and describes loss of parts of the original distribution. It offers a reason to examine provenance and recursive replacement carefully. It does not establish that every use of synthetic data is harmful.

The practical question for this project is narrower: does a particular generated batch improve the classifier on independent examples of the intended task? Answer that experimentally. Avoid using the phrase model collapse as a blanket explanation for every poor result or as proof that one fixed mixing ratio is universally safe.

Record whether examples came from original observations, human-authored scenarios, or earlier generated material. Repeatedly rewriting synthetic outputs without preserving that history can make a dataset look independent of the generator when it is not.

Protect an evaluation set from the generation process

Keep final evaluation examples out of generator prompts, template design, and filtering decisions. If you use an evaluation failure to design new training cases, move that example into the development record and preserve another independent check for the eventual release decision.

Group related examples when splitting. Multiple rewrites of one complaint should remain in the same partition. A random split across all rows can put close relatives into both training and test sets, producing an optimistic impression of generalization.

For the parcel classifier, evaluate on independently collected or authored messages that were not used to guide generation. Include realistic language and known hard cases. Synthetic evaluation can exercise a boundary, but success on it alone does not establish the system's error rate in actual customer traffic.

Test the contribution with a controlled comparison

Compare a baseline training setup with one that adds the candidate batch while keeping other important conditions fixed. If training randomness matters, use repeated runs or an appropriate uncertainty analysis. Record both aggregate results and category-level changes.

Look for negative transfer. Extra examples of indirect wrong-item complaints might improve that category while causing the classifier to overinterpret ambiguous messages. Inspect clarification behavior and the types of false positives, not only the total number of correct labels.

Also compare against an equal-effort alternative where practical. A small amount of targeted human labeling or a clearer category definition may help more than a large generated batch. The relevant decision is which use of the team's effort improves the finished system most reliably.

Treat privacy as a property to verify

Synthetic does not automatically mean free of sensitive information. A prompt containing real customer details can lead to outputs that repeat them, and a generated example can closely resemble its source. Decide what source material is permitted before sending it through the pipeline.

Use data minimization and appropriate access controls for generation inputs, outputs, and logs. Check for unwanted identifiers and copied passages as part of review. Those checks are useful safeguards, but they do not justify an absolute claim that no private information could remain.

For a development demonstration, prefer deliberately invented accounts and records with clear provenance. Keep them separate from production exports. A realistic interface does not require embedding genuine customer addresses or order numbers inside the examples shipped with the application.

Make the pipeline auditable and affordable

Assign every batch a version and store its purpose, generator configuration, scenario specification, filtering rules, review results, and allowed use. Preserve enough information to reproduce the process without retaining unnecessary private content. A future maintainer should know why a batch entered training.

Set limits on generation volume and review capacity. Producing ten thousand examples is not useful if only a tiny, unrepresentative fraction can be inspected and the filters have not been validated. Start with a batch small enough to learn where the process fails.

Track cost per accepted, useful example rather than cost per generated row. Include rejected outputs and reviewer effort. If a narrow scenario consistently produces unusable text, revise the specification instead of repeatedly paying for variations of the same defect.

Retire examples that no longer represent the task

Support policies and label definitions change. An example that was correct under an old taxonomy can become misleading after two categories are combined or a new clarification rule is introduced. Version labels and review affected batches when the policy changes.

Do not silently relabel all historical examples through a new model and assume the migration is complete. Inspect disagreements and preserve the reason for significant changes. Historical evaluation results should continue to refer to the policy and dataset version used at the time.

Keep a release note explaining which generated batches were included and what evidence justified them. Synthetic data is useful when it fills a specific gap, survives independent review, and improves performance where it matters. Its value comes from a controlled connection to the task, not from the size of the file it creates.

Further reading

The Curse of Recursion: Training on Generated Data Makes Models Forget