Synthetic Data Isn't Free Real Data: When to Use & How to Validate Without Bias

The previous article discussed using active learning to allocate limited expert labeling budget to high-value long-tail samples. However, some failure modes, patient subtypes, or fraud paths occur only a few times per year in real systems — too rare to collect or label.

Many teams' first reaction is to generate thousands of samples with a large model or generative model. A single prompt yields 10,000 samples at near-zero cost. But generating 10,000 samples does not equal gaining 10,000 new pieces of knowledge. Generative models inherit biases from prompts, source samples, and themselves, and may create statistically plausible but business-nonexistent combinations. A subtler risk is model collapse: Shumailov et al. (Nature, 2024) showed that when models repeatedly train on their own generated data, the distribution narrows, rare but valuable information is lost, and even common patterns degrade. Synthetic data is not free real data; it is a distinct data source requiring separate acceptance.

Synthetic data can supplement structure, boundaries, and scenario coverage, but cannot automatically prove real-world representativeness; it is worth entering formal training only when it brings reproducible task gains on real independent evaluation, and its generation process is auditable and traceable. When used for offline stress testing, it must be explicitly labeled and statistically isolated — it cannot prove real-world generalization.

The following uses rare fault simulation in equipment anomaly warning as a running example, solely to illustrate methods; it does not represent actual project data scale, model performance, or business results.

What Does "Generating 10,000" Actually Add?

Increasing data volume has two completely different meanings: increasing "sample count" and increasing "decision-relevant evidence."

Real sample increases usually bring new operating conditions, new failure modes, and new evidence relationships. Synthetic sample increases often just densify the existing distribution or interpolate between existing patterns. For the long-tail capabilities the model lacks most, such interpolation often misses the mark.

An extreme case is recursive training. Shumailov et al.'s model collapse research (Nature, 2024) demonstrates that when models continuously train on self-generated data, the distribution progressively narrows, rare but valuable information disappears, and eventually even common patterns degrade. In other words, feeding generated data to generative models long-term dilutes the real distribution rather than augmenting it.

Therefore, the first question when judging whether to use synthetic data is: do I want to supplement "quantity" or "evidence not yet sufficiently covered in the real world"? If the goal is the latter, synthetic data's value lies not in scale but in whether it can construct boundaries and combinations that are hard to collect in reality but genuinely exist in the business.

First Clarify Which Type of Problem You're Solving

Synthetic data is not a single action. Different purposes have different authenticity requirements, risks, and control methods.

Privacy Substitution : Real data cannot leave domain or be used for training. Typical approach: differential privacy synthesis, non-DP generated substitute records. Risk focus: non-DP schemes usually offer only empirical protection; DP schemes must verify assumptions, privacy budget, and implementation.

Rare Scenario Completion : Real long-tail samples too few. Typical approach: simulation, generative models to supplement boundaries. Risk focus: may create false combinations.

Physical Simulation : Real experiments costly or dangerous. Typical approach: generate curves based on mechanistic models. Risk focus: simulation assumptions ≠ reality.

Format Expansion : Missing certain expressions, languages, or structures. Typical approach: rewriting, template-based generation. Risk focus: surface changes, may not add information.

Adversarial Testing : Verify model behavior under extreme inputs. Typical approach: construct perturbations, out-of-bound inputs. Risk focus: must align with real failures.

If only for format expansion or adversarial testing, synthetic data is relatively controllable; if relied upon to fill critical capability gaps, it must be treated as a data product requiring independent proof, not "free samples."

This article draws a boundary: it does not conflate data augmentation, anonymization, and fully synthetic data. Data augmentation applies controlled transforms (crop, rotate, rewrite) on real samples to improve robustness, not necessarily adding new real-world evidence. Anonymization remains linked to real records, focusing on privacy risk control. Fully synthetic data, by design intent, does not directly rewrite a single real record, but that does not mean it cannot reproduce or leak real content — it must undergo more complete authenticity, privacy, and task validation. This article focuses on fully synthetic data; the other two are mentioned only where they interface with it.

Generation Methods Differ in Credibility

The same batch of "synthetic fault curves" produced by different methods has vastly different credibility.

Rule-based or simulator : e.g., using equipment thermodynamic and dynamic models to generate bearing wear curves. Pros: mechanism controllable, parameters traceable, can avoid impossible combinations within encoded physical constraints. Cons: simulation assumptions may oversimplify, missing real noise, assembly variations, and field interference.

Generative model-based : Diffusion models or LLMs generate samples with high coverage and rich forms, but inherit training data biases and may construct samples that "look like faults but have wrong mechanisms."

Hybrid generation : Generative model adds detail near simulation curves to expand boundary coverage. Richer than pure simulation, but generative model biases enter and still require isolated validation.

For the equipment anomaly warning case, physics-simulated composite fault curves are more credible than faults purely "imagined" by an LLM, provided the simulation model itself is calibrated on real operating conditions. Without calibration, it generates only "self-consistent fiction," not "transferable reality."

Five Validations: Authenticity, Validity, Diversity, Privacy, Task Gain

Synthetic data cannot be "generated and used"; it must pass at least five validations. Each answers a different question and cannot substitute for another.

Authenticity : Does it conform to real distribution and physical constraints? Equipment anomaly example: frequency, amplitude, decay within real ranges? Impossible operating conditions present?

Validity : Do samples, labels, and context satisfy intended use and constraints? Equipment anomaly example: fault labels, operating parameters, and maintenance context mutually consistent?

Diversity : Has it collapsed to a few modes? Equipment anomaly example: are generated faults just slight deformations of the same curve?

Privacy : Can real records still be re-identified? Equipment anomaly example: can generated "patients/customers" be traced back to specific individuals?

Task Gain : Does adding to training yield reproducible improvement on real target task? Equipment anomaly example: composite fault recall improved on real independent eval? Gain disappears when synthetic portion removed?

Authenticity cannot rely solely on statistical metrics. Matching mean and variance does not guarantee correct mechanism; a fabricated fault conforming to distribution may never occur on-site. Validity requires verifying that samples, labels, constraints, and context jointly hold. Task gain must land on real independent evaluation , not the generative model evaluating itself.

Privacy validation must be taken seriously. Stadler et al. (USENIX Security 2022) showed that evaluated generative synthetic data release schemes cannot stably achieve both strong privacy protection and high data utility, and privacy gains are hard to predict. NIST also notes that non-DP synthesis typically provides only informal privacy protection; even with DP, assumptions, privacy budget, implementation, and acceptable residual risk must be verified. NIST SP 800-226 therefore requires privacy validation when personal, customer, or commercially sensitive data is involved — it cannot be skipped or replaced with subjective "doesn't look like a real person" judgments.

Task gain is the final gate: whether synthetic data deserves to enter training depends on whether its improvement on real evaluation is reproducible. If it only performs well on generated data but shows no change on real independent sets, it has provided no new evidence.

Synthetic Data Restrictions Differ in Training vs. Evaluation Sets

This is the most easily overlooked point: the same batch of synthetic data follows completely different rules when placed in the training set versus the evaluation set.

Training set : Can supplement real data, but must record source, control proportion, and manage isolation from real data at asset, lineage, and version levels. Real independent evaluation samples and their labels must not enter the generation source samples, prompts, calibration, or filtering process.

Offline evaluation & ablation : Can use synthetic data for scarce scenario stress testing, but must be explicitly labeled and not mixed with real metrics in reporting.

Independent evaluation set : Should not mix synthetic samples with real independent evaluation reporting. Synthetic samples can be listed separately as stress test sets, but cannot replace real independent evaluation; if produced by the same generation process or same source samples, they cannot prove real-world generalization.

Online replay : Only for constructing extreme scenarios not yet occurred in real systems, and must be statistically isolated from real replay — synthetic results must not inflate real metrics.

Real-to-synthetic ratio must also be controlled. Synthetic data fills real coverage gaps, not replaces real data. Increasing proportion may make the model fit the generation mechanism rather than the real distribution, potentially degrading real long-tail capability; specific thresholds should be decided by ablation experiments and real independent evaluation, not fixed ratios.

Training set : Yes, as supplement. Main restriction: record source, control proportion, isolate to prevent leakage.

Offline evaluation / ablation : Yes, for scarce scenarios. Main restriction: explicit labeling, no mixing with real metrics.

Independent evaluation set : No mixing with synthetic samples. Main restriction: keep real, independent, unseen by training and generation.

Online replay : Cautious, only for unoccurred extreme scenarios. Main restriction: statistically isolated from real replay.

Generation Process Must Be Auditable

Synthetic data shares the same logic as the Dataset Contract, Manifest, and Registry discussed in Article 04: only when source, parameters, filtering, and confirmation are clear can it be trusted and rolled back.

A generation Manifest should record at minimum:

synthetic_data_manifest:
  manifest_id: synth-equipment-A-20260824-001
  purpose: rare-composite-fault-augmentation
  generation_method: physics-simulation
  simulator:
    name: rotating-equipment-dynamics-v2
    calibrated_on: real-baseline-2026Q2
    version: 2.3.1
  source_prompts: [] # only for generative model scenarios
  model_version: null
  filtering_rules:
    - drop_out_of_physical_range
    - deduplicate_by_cluster: cluster-017
  human_review:
    reviewer: rotating-equipment-specialist
    decision: approved
    notes: composite fault mechanism consistent with field
  real_to_synthetic_ratio: 8:2
  allowed_use: [training, offline-stress-test]
  forbidden_use: [holdout-eval, online-metric]
  lineage:
    derived_from: real-baseline-2026Q2
    registered_in: dataset-registry

The example parameters are for structural illustration only, not real thresholds. Every synthetic batch should bind generation method, version, filtering rules, and human approval to prevent later inability to explain "why this batch exists and who is responsible."

A candidate admission checklist can be organized as follows:

Purpose Match : Pass condition — corresponds to confirmed coverage gap. Fail action — return to coverage analysis.

Source Traceable : Pass condition — rules/simulator/model and version complete. Fail action — reject from library.

Purpose-Relevant Validation Complete : Pass condition — authenticity, validity, diversity, privacy, and task gain all have evidence. Fail action — roll back or discard.

Privacy Risk Acceptable : Pass condition — meets org privacy, security, data use requirements; risk assessment evidence retained. Fail action — regenerate, controlled use, or stop use.

Proportion Controlled : Pass condition — does not exceed set real/synthetic ratio. Fail action — reduce or isolate.

Usage Boundaries Clear : Pass condition — explicit allowed and forbidden uses. Fail action — supplement Contract.

Ablation experiment design should also be provided: fix real training set, set a few candidate synthetic proportions per local scenario, compare long-tail and high-risk action metrics on the same real independent evaluation set . Only when synthetic data's marginal gain is reproducible across multiple training runs, different random seeds, or time windows should proportion be increased; if gain disappears or real metrics degrade, stop and return to root cause analysis rather than continue adding volume.

Who's Responsible: Synthetic Data Needs an Owner

Synthetic data is not a "byproduct automatically produced by generation tools"; it should enter the data product responsibility chain. A complete generation and acceptance round contains at least five steps, each with a clear owner.

Step 1: Requirement Determination — Responsible: Business + Data. Input: coverage gap and long-tail matrix. Output: use case classification. Acceptance: use case matches real gap. Failure returns to: coverage analysis.

Step 2: Simulation / Generation — Responsible: Data Engineering + Algorithm. Input: rules, simulator, or model. Output: candidate synthetic set. Acceptance: source and parameters complete. Failure returns to: reselect generation method.

Step 3: Purpose-Relevant Validation — Responsible: Quality + Evaluation + Privacy Security. Input: synthetic set and real baseline. Output: validation report. Acceptance: respective validations complete; training admission additionally requires real independent eval gain. Failure returns to: roll back or discard.

Step 4: Admission & Registration — Responsible: Data Product Owner. Input: Manifest. Output: Registry entry. Acceptance: lineage and human confirmation complete. Failure returns to: supplement records.

Step 5: Training / Evaluation Use — Responsible: Algorithm + Evaluation. Input: admitted synthetic set. Output: version baseline. Acceptance: no contamination of independent evaluation. Failure returns to: isolate and retrain.

Early steps are defined by business and data, middle steps produced by engineering and algorithm, validation gated by quality and evaluation, final registration and usage rights owned by data product owner. Without this responsibility chain, synthetic data easily becomes an unattended "automatic data fabrication" pipeline.

Not All Scenarios Need Synthetic Data

If real data is already sufficient, or the gap should be solved by rules, collection, or process, synthetic data should not be introduced.

Prefer other mechanisms in the following cases:

Sample missing because collection pipeline is broken : fix sensors, fix linkage first, not generate data first.

Model error because label criteria unstable : fix rules, do arbitration (see Articles 05, 06); synthetic samples don't cure root cause.

Scenario not scarce, just normal distribution : random sampling with stratified coverage already sufficient.

Involves strong privacy and cannot be validated : prioritize data minimization, controlled access, non-export computation, or other assessed privacy mechanisms, not reliance on "looks anonymous."

Synthetic data also cannot solve fundamentally uncollectable problems with unknown mechanisms. When real samples are extremely few and even simulation models cannot be calibrated, generated data likely just amplifies ignorance more prettily. Whether to adopt simulation or generation in such cases requires separate assessment of authenticity, bias, and isolation boundaries, and must accept negation by real independent evaluation.

What a Runnable Synthetic Data Deliverable Should Include

Final delivery cannot be just a batch of generated files; it must include at least:

Purpose and gap description: Which real coverage gap the synthetic data addresses.

Generation Manifest: Method, version, prompts, filtering rules, and human confirmation.

Five validation reports: Authenticity, validity, diversity, privacy, and task gain.

Real/synthetic ratio and usage boundaries: How each is used in training, offline evaluation, independent evaluation, and online replay.

Ablation experiment design and results: Marginal gains on real independent evaluation at different proportions.

Responsibility chain and Registry entry: Who generated, validated, admitted, and owns rollback.

These artifacts should continue into the Dataset Contract, Manifest, and Registry defined in Article 04. Only when generation source, filtering rules, usage boundaries, and version lineage are clear does synthetic data transform from "seemingly free samples" into a trustworthy data product.

Summary

When real long-tail samples are scarce, synthetic data can indeed provide boundaries and combinations hard to obtain via real collection, but it is not free real data, nor does "generating 10,000" automatically bring 10,000 new knowledge pieces.

Before using synthetic data, clarify whether the purpose is privacy substitution, rare completion, simulation, format expansion, or adversarial testing, and distinguish augmentation, anonymization, and fully synthetic. On generation methods, rule-based or simulator-based is more controllable than pure generative models; hybrid generation requires isolated validation. Regardless of method, all must pass the five validations — authenticity, validity, diversity, privacy, and task gain — and training set vs. independent evaluation set rules differ: independent evaluation sets must not be contaminated by synthetic data.

Only when synthetic data brings reproducible gains on real independent evaluation, its generation process is auditable, and its responsibility chain is clear, does it deserve to enter training. Otherwise, continuing to add volume only dilutes the real distribution and may feed model errors deeper.

The hardest part of high-quality datasets is sometimes not "how to craft more data," but knowing which data should never be crafted at all.

Next article continues: When real data, synthetic data, and models are all in place but AI still makes mistakes, what exactly should be fixed — data, semantics, model, prompt, retrieval, or tools?