Synthetic data

Overview

Synthetic data is data that a program produced rather than data that was recorded from real people, machines or events. The program might be a large language model writing practice questions, a physics simulator rendering street scenes, or a statistical model that has learned the patterns of a customer table and can sample new rows that look similar. The output is used much like real data: to train models, to test them, or to share a realistic dataset without exposing real records.

In 2026, synthetic data sits at the centre of several practices. Language model builders use generated instructions, answers and reasoning traces for supervised fine-tuning and preference training. Robotics and driving teams train and test in simulation. Banks, hospitals and public bodies use synthetic tables to let analysts and vendors work with realistic data without seeing anyone's personal information. And pre-trained tabular foundation models learn from millions of generated datasets. The companion page on synthetic data generation focuses on generators and priors; this page covers the full life cycle: where synthetic data comes from, how to judge it, how to protect privacy, and what can go wrong.

An everyday picture: a flight simulator. Pilots practise engine failures and storms that would be too dangerous or too rare to practise in a real aircraft. The simulator is only valuable because it behaves like the real plane in the ways that matter. If its physics were wrong, pilots would learn the wrong reflexes. Synthetic data works the same way: it is useful exactly to the extent that it is faithful where it counts, and harmful where it is not.

What it is

Synthetic data is judged along three axes. Fidelity asks whether it resembles the real data statistically. Utility asks whether models trained or tested on it behave as they would with real data. Privacy asks whether it leaks information about the real individuals it was learned from. These pull against each other: perfect fidelity would mean copying the real records, which destroys privacy.

Where it came from

Simulation-based training data is as old as computing, but synthetic data as a privacy tool has a clear statistical origin. In 1993 Donald Rubin proposed releasing fully synthetic versions of survey microdata, drawn from models fitted to the confidential data, so that analysts could work without access to real respondents. Statistical agencies developed this idea through the following decades.

Differential privacy, defined by Cynthia Dwork, Frank McSherry, Kobbi Nissim and Adam Smith in 2006, gave a mathematical way to bound what any output reveals about one person. Martín Abadi and colleagues introduced DP-SGD in 2016, making it practical to train neural networks, including data generators, with differential privacy. For tables, the Synthetic Data Vault project from MIT's Data to AI Lab was described in 2016, and Lei Xu and colleagues presented CTGAN and TVAE at NeurIPS 2019, adapting GANs and VAEs to mixed numeric and categorical columns. Diffusion-based tabular generators such as TabDDPM followed in 2023.

In language modelling, Geoffrey Hinton, Oriol Vinyals and Jeff Dean's 2015 paper on distillation showed the value of training on a teacher's outputs. Self-Instruct (Wang and colleagues, late 2022) had a model bootstrap its own instruction data. In March 2023 Stanford's Alpaca fine-tuned a LLaMA model on 52,000 instruction-following examples generated with an OpenAI model, showing how cheap synthetic instruction data could be. Microsoft's phi-1 paper, "Textbooks Are All You Need" (June 2023), trained a small code model on filtered web data of "textbook quality" plus textbook-style data generated by a larger model. Since then, generated data has become a standard ingredient in post-training pipelines.

The risks were studied in parallel. Ilia Shumailov and colleagues reported in Nature in July 2024 that models trained recursively on their own generated data suffer "model collapse": the tails of the original distribution vanish over generations. Matthias Gerstgrasser and colleagues showed in 2024 that collapse is avoided when synthetic data accumulates alongside the original real data rather than replacing it. Both results now shape how practitioners mix data.

How it works

LLM-generated text

A typical pipeline starts with seed material: a list of topics, a set of documents, or a few hand-written examples. A model is prompted to produce instructions, then answers, sometimes with critiques and revisions. Variety is forced by varying personas, difficulty, formats and topics. The output then goes through filtering: deduplication, rule checks, verification of code by running it or of maths by checking answers, and scoring by a judge model (see LLM as a judge). Only a fraction survives. The result feeds fine-tuning or preference methods such as DPO.

Simulation

A simulator gives perfect labels for free: every pixel's object class, every object's exact position. Domain randomisation varies textures, lighting, camera positions and physics parameters so that a model learns features that survive the jump to real data. Simulation is strong where physics is well understood and weak where reality is messy, such as deformable objects or human behaviour.

Tabular synthesis

A generator is fitted to a real table, then sampled. The main families:

• Gaussian copula: model each column's distribution separately, then capture the dependence between columns with a multivariate normal on transformed values. Fast and stable, but limited to fairly simple dependence.
• GANs (for example CTGAN): a generator and discriminator compete; conditional sampling and special normalisation handle categories and multi-modal numbers.
• VAEs (for example TVAE): encode rows into a latent space and decode samples back.
• Diffusion models: learn to reverse a noising process; often strong fidelity on complex tables.
• Autoregressive and LLM-based generators: generate a row one column at a time.

Privacy, fidelity and utility in formulas

Differential privacy:  Pr[ M(D) ∈ S ] ≤ e^ε · Pr[ M(D′) ∈ S ] + δ

Gaussian copula:       z_j = Φ⁻¹( F_j(x_j) ),   z ~ N(0, Σ)

Utility ratio (TSTR):  U = score( model trained on synthetic, tested on real )
                           / score( model trained on real, tested on real )

In the first line, M is the randomised mechanism that produces the synthetic data, D and D′ are any two datasets that differ in one person's record, S is any set of possible outputs, ε (epsilon) is the privacy budget, where smaller means stronger privacy, and δ is a small probability of the guarantee failing. In the second, x_j is a value in column j, F_j is that column's cumulative distribution, Φ⁻¹ is the inverse of the standard normal distribution, and Σ is the correlation matrix that captures how columns move together. In the third, both models are scored on the same real hold-out set with the same metric; a ratio near 1 means the synthetic data is almost as useful as the real data for that task.

A short code example

The open-source SDV library offers several synthesizers with a common interface. This follows its quickstart:

from sdv.datasets.demo import download_demo
from sdv.single_table import GaussianCopulaSynthesizer
from sdv.evaluation.single_table import evaluate_quality

real_data, metadata = download_demo(
    modality="single_table", dataset_name="fake_hotel_guests"
)

synthesizer = GaussianCopulaSynthesizer(metadata)
synthesizer.fit(data=real_data)
synthetic_data = synthesizer.sample(num_rows=500)

report = evaluate_quality(real_data, synthetic_data, metadata)

Note that a plain synthesizer like this offers no formal privacy guarantee. Rows can still sit close to real records.

Key concepts and terms

A worked example

This scenario is illustrative and does not describe a real organisation.

A regional hospital network wants an outside analytics vendor to build a readmission-risk model without receiving patient records. The real table has 120,000 admissions and 40 columns, including age, diagnosis codes, length of stay and a 30-day readmission flag with a rate of about 12 per cent.

1. Prepare. The data team removes direct identifiers, groups rare diagnosis codes and defines the metadata: column types, valid ranges and rules such as discharge date after admission date.
2. Train generators. They fit a Gaussian copula, a CTGAN and a differentially private generator with ε = 3, holding out 20 per cent of real rows that no generator sees.
3. Check fidelity. Column distributions match closely for all three. Pairwise correlations are best preserved by CTGAN; the private generator smooths some weaker relationships.
4. Check utility. A gradient-boosted classifier trained on real data reaches an AUC of 0.78 on the real hold-out. Trained on each synthetic set and tested on the same hold-out, it reaches 0.74 (copula), 0.76 (CTGAN) and 0.72 (private).
5. Check privacy. For the non-private sets, the team finds a small number of synthetic rows almost identical to real patients with rare conditions. A membership inference test confirms some leakage risk.
6. Decide. They share the differentially private set with the vendor, accepting the lower utility, and validate the vendor's final model on real data internally.

The lesson: utility and privacy must be measured together, and the right choice depends on who receives the data.

Strengths and limitations

Strengths:

• Scale and speed: large volumes can be generated cheaply once a generator exists.
• Coverage: rare events, edge cases and balanced classes can be produced on purpose.
• Labels for free: simulators know the ground truth exactly.
• Privacy support: with formal guarantees, synthetic data can reduce disclosure risk when sharing.
• Control: distributions, formats and difficulty can be set deliberately for testing.

Limitations:

• It cannot contain knowledge the generator does not have; errors and biases are copied or amplified.
• Synthetic tables can leak real records unless privacy is engineered and tested.
• Fidelity on simple statistics can hide failures on complex relationships or rare subgroups.
• Recursive training on generated data, without real data, risks model collapse.
• LLM-generated text tends to be less diverse than human writing and can carry the generator's style and errors.
• Licence terms of the generating model may restrict how outputs can be used to train other models.
• Synthetic data does not by itself make processing lawful; data protection rules such as GDPR still apply to the real data used to fit the generator.

How it compares with alternatives

These are often combined: real data where available, augmentation for robustness, synthetic data for rare cases and sharing, and federated or private training where data cannot move.

Practical guidance and best practices

1. Define the purpose first: training, testing, sharing or pre-training. Each needs different checks and different trade-offs between fidelity and privacy.
2. Always keep a real hold-out set that no generator has seen, and judge utility by train-on-synthetic, test-on-real.
3. Mix, do not replace. Keep real data in the training mix and accumulate synthetic data alongside it, rather than training generation after generation on model outputs.
4. Filter aggressively. Deduplicate (see deduplication), verify facts or code where possible, remove near-copies of real records and track the share of data that passes.
5. Force diversity in LLM generation by varying seeds, personas, topics, formats and difficulty, and measure diversity explicitly.
6. When privacy matters, use a generator with formal differential privacy, choose and document ε, and still run empirical attacks such as membership inference.
7. Check subgroups and tails, not only averages. Compare rare categories, extreme values and fairness-relevant groups.
8. Record provenance: generator, version, prompts or parameters, filters and the share of synthetic data in each training set, ideally in model cards and dataset documentation.
9. Read the licence and terms of any model used to generate training data.

Common mistakes

• Treating synthetic data as automatically anonymous and sharing it without privacy testing.
• Validating only on synthetic data, so test scores say nothing about real-world performance.
• Training repeatedly on outputs of models trained on outputs, discarding the original real data.
• Checking only column averages and missing broken relationships between columns.
• Generating thousands of near-identical LLM examples and mistaking volume for coverage.
• Forgetting that the generator copies biases present in the real data or in the generating model.

Frequently asked questions

Is synthetic data anonymous?

Not automatically. A generator that fits real data closely can reproduce real records, especially rare ones. Only a formal mechanism such as differential privacy gives a provable bound, and even then the bound depends on the chosen privacy budget. Treat privacy as something to engineer and test, and get advice on how the applicable data protection law treats your synthetic output.

What is model collapse, and should I worry?

Model collapse is the loss of diversity and accuracy that appears when models are trained, generation after generation, on data produced by earlier models. Rare patterns disappear first. Research published in Nature in 2024 demonstrated it for language models, VAEs and Gaussian mixtures. Later work showed that keeping the original real data and adding synthetic data on top, rather than replacing it, avoids collapse in their experiments. The practical lesson is to keep real data in the mix and track where every sample came from.

Can a model trained on synthetic data beat one trained on real data?

Sometimes, for specific reasons: synthetic data can add rare cases, balance classes or provide cleaner labels than noisy real data. Distillation can also transfer a strong teacher's ability to a small model. But synthetic data cannot add knowledge that neither the generator nor the real data contains, so gains are always bounded by the quality of the source.

How much synthetic data should I mix with real data?

There is no universal ratio. Start with real data as the anchor, add synthetic data in measured steps, and watch performance on a real hold-out set, including on subgroups. Stop when gains flatten or tail performance drops.

How do I evaluate a synthetic tabular dataset?

Measure three things. Fidelity: compare column distributions, pairwise relationships and constraints. Utility: train models on synthetic data and test on real hold-out data, and compare with a model trained on real data. Privacy: check distances to the closest real records and run membership inference attacks. Libraries such as SDV include quality reports, but you should add checks specific to your task.

Is it allowed to train on another company's model outputs?

It depends on that provider's terms of use and licence. Some prohibit using outputs to build competing models. Check the terms before generating training data, and record which model produced which data.

Glossary

• Synthetic data: data produced by a model, program or simulator rather than recorded from real events.
• Generator: the model or program that produces synthetic data.
• Copula: a function that joins separate column distributions into a joint distribution with a chosen dependence structure.
• CTGAN: a conditional GAN designed for mixed-type tabular data.
• DP-SGD: stochastic gradient descent with clipping and noise, giving differential privacy during training.
• Distillation: training a student model on a teacher model's outputs.
• Self-Instruct: a method in which a model generates its own instruction-tuning data from a small seed set.
• Hold-out set: real data kept aside and never used to train the generator or model.
• Provenance: a record of where each piece of data came from and how it was made.

Summary

Synthetic data is data generated by language models, simulators, statistical models or rules rather than recorded from the world. It now underpins instruction tuning, distillation, robotics simulation, privacy-preserving data sharing and the pre-training of tabular models. Its value depends on three properties that must be measured together: fidelity to the real data, utility for the real task, and privacy for the people behind the source data. Formal differential privacy gives provable protection at some cost to utility; plain generators do not. Research on model collapse shows that discarding real data in favour of recursively generated data degrades models, while accumulating synthetic data alongside real data avoids it in reported experiments. Keep a real hold-out set, filter and diversify generated data, test privacy empirically, document provenance, and treat synthetic data as a powerful supplement to real data rather than a replacement.

Related

It belongs to Training fundamentals in my stack, under Machine learning. Others in the same group: