Synthetic Data Generation

Synthetic Data Generation

Synthetic data is artificial data produced by a model fit to real data, designed to reproduce the real data’s statistical properties (marginals, correlations, joint structure) without being a copy of any real record. The goal is to make synthetic records useful for a downstream task while breaking the one-to-one link to real individuals.

This skill treats synthetic data generation as a discipline: when to use it, which generator to reach for, how to make it private, and most importantly how to prove it is good enough on the three axes that always compete: fidelity, utility, privacy.

When to use this skill

Use it when the task is to create data rather than analyze existing data: share data you cannot share in raw form, augment a too-small or imbalanced training set, populate a test/dev/CI environment without production PII, or release a public benchmark from a sensitive source.

Do not use it for plain class-rebalancing with off-the-shelf SMOTE (data-prep step, see da-4), abstract differential-privacy/k-anonymity theory (da-11), or feature encoding (da-17). Those skills are adjacent; this one owns the generation pipeline and its evaluation.

Core concepts

1. Why synthetic data

Inference, not fact: “synthetic surpasses real by 2030” is a vendor/analyst projection. Treat market-size and adoption numbers as directional.

2. Tabular synthesis methods

Tabular is the hard case: mixed types, non-Gaussian/multimodal continuous columns, imbalanced categoricals.

3. Deep generative methods

4. Class imbalance: resampling vs generative

5. Differentially private synthesis

Plain synthetic data is not automatically private; formal guarantees require DP built into training.

Caveat: high epsilon hollows out the guarantee. MST/PrivBayes at high epsilon still leak (arXiv 2402.06699, 2024). DP is only as strong as the epsilon you actually set.

6. Tools & frameworks

7. Evaluation: fidelity vs utility vs privacy

The three axes trade off (especially privacy vs fidelity/utility under DP). Measure all three.

8. Text & image synthesis (overview)

9. Regulatory context

Synthetic data is not automatically anonymous or out of GDPR scope. Fully synthetic data meeting the anonymisation bar escapes GDPR; partially synthetic data usually remains personal data. ICO’s March 2025 anonymisation guidance: effective anonymisation is a high bar requiring a documented re-identification-risk assessment (GDPR Local; RPC 2025; NIST). Treat a privacy claim as something you must measure (DCR + MIA, ideally under a DP budget), not something the word “synthetic” grants.

Methodology (end-to-end pipeline)

  1. Define the goal first (privacy share / augmentation / test data / rebalancing) — sets which axis you optimize and which gates you must pass.
  2. Profile and build metadata (types, keys, datetime formats, constraints). Bad metadata is the #1 cause of bad output.
  3. Split before you fit — hold out a real test set before training so TSTR and MIA are honest.
  4. Pick a generator by data + constraint — copula baseline; escalate to CTGAN/TVAE; diffusion (TabDDPM) for highest fidelity; switch to a DP synthesizer (PATE-GAN, MST/PrivBayes via SmartNoise) the moment a formal privacy guarantee is required.
  5. Fit, then enforce constraints — apply business rules / valid ranges; reject or post-process invalid rows.
  6. Evaluate on all three axes — fidelity, utility (TSTR vs TRTR), privacy (DCR + MIA). For DP, report epsilon.
  7. Iterate against the binding constraint — privacy fails: lower epsilon/regularize; utility fails: more capacity/epochs or change family. Expect to trade.
  8. Document generator, hyperparameters, epsilon, seed, metrics, and the re-identification-risk assessment (required for any GDPR/anonymisation claim).

Practical patterns

Anti-patterns

Troubleshooting

References