Synthetic tabular data: training CTGAN and TabDDPM models

Rare classes in tabular data prevent a model from learning, and predictions fail exactly where they matter most. We train generative models on the customer's data and synthesize the missing examples — turnkey, with reports on sample quality and suitability. The result is robust predictions on rare scenarios.
Frequently Asked Questions

Why tabular data generation breaks down on rare classes

Tabular data generation breaks down not on volume, but on the tails of the distribution. Class imbalance in a dataset of the 99:1 kind is common: the model confidently reproduces the majority and memorizes the few dozen rows that represent the rare class.

Similarity metrics and histograms do not show this — the failure surfaces later, when a classifier or scoring model is trained on the synthetic data.

Class-conditional generation (the CTGAN approach and diffusion models) helps exactly as long as there is statistics inside the class.

When there are only dozens of rare records, the discriminator memorizes them and outputs almost verbatim copies of the original rows — repackaging data, not new observations. Diffusion does not restore a decision boundary where there are no examples for it either.

Missing values and outliers in the data add a second layer of loss. Mean imputation erases the very fact that a value is missing, and that fact is informative: "credit history not requested" is a signal, not a hole.

Outlier clipping narrows the tails, and the model loses exactly the cases for which it is being built.

De-identification of personal data is a third constraint: a combination of quasi-identifiers is often unique, and a synthetic row remains tied to a specific person, while privacy-protecting noise hits rare classes hardest.

Row copying does not solve the task: volume grows, information does not increase, and the model becomes overconfident on duplicates. We explain how this is addressed with class-conditional generation, explicit missing-value indicators, and privacy control.

Effect of tabular data synthesis in prediction tasks

Synthetic data for machine learning has an effect where the real dataset is insufficient: rare class, missing values, incomplete segments.

Below is what we check during acceptance together with the customer so that augmentation of the training set produces a measurable result, not just a nice number in a report.

Rare classes and missing values

  • The rare class share in training is brought to the target level — the overall metric improves not at the expense of the majority class.
  • Model quality on the rare class is calculated separately: recall and precision for it before and after synthesis, on the same split.
  • Missing values are imputed according to the feature distribution, not by the column mean — otherwise the generator replicates the bias.
  • Synthetic rows do not enter the holdout part: validation is performed on real records that the model has not seen.

Reproducibility and privacy control

  • The run uses a fixed seed and configuration version — training is reproducible a month later, not "approximately similar".
  • We compare CTGAN generators and tabular diffusion models on the same protocol and choose by measured effect.
  • Privacy is checked with a reconstruction attack: proximity of synthetic data to real rows, share of direct matches, behavior on small subgroups.
  • For sensitive data — an isolated environment, role-based access, and an access log; the result is documented in a protocol with applicability boundaries.

Synthesis methods: rules, statistics, generative models

The synthesis method is selected for the feature types and for which dependencies between columns need to be preserved.

Feature masking rules and statistical copying with noise give a predictable result on small datasets, when relationships are specified manually and there are few of them.

Adversarial and diffusion synthesis models restore correlations themselves, but require a sufficient number of rows and careful training setup.

Option When suitable Limitations
Rules and feature masking Mixed types, need control over values and reproducibility Does not transfer hidden relationships between columns
Statistical copying with noise Numeric features, fast run on small datasets Blurs rare categories and distribution tails
Adversarial synthesis models Complex interactions, class skew, many categories Training is unstable, mode selection needed
Diffusion models for tabular synthesis Mixed types, high distribution accuracy Long training, sensitivity to dataset size

How to choose an option for the task

We focus on data composition: when the share of categorical features exceeds half, adversarial approaches CTGAN maintain joint distributions more stably, while diffusion TabDDPM preserves rare values more accurately.

On smaller datasets, the distribution "drifts" for both, and then statistical copying with noise is more advantageous, while rare classes are supplemented by masking rules.

The constraint on feature types is also strict: dates and text fields require separate preprocessing, otherwise the model produces formally valid but meaningless values.

How model training on customer data proceeds

The customer data audit comes first: we review volume, column types, missing share, rare categories, and the relationship of features to the target variable.

Already at this step it is clear where synthetic data will repeat biases of the original dataset and where data will be insufficient for stable training.

Audit and problem statement

We fix which properties need to be preserved: distributions of numeric columns, joint category frequencies, logical constraints such as "closing date is not earlier than opening date".

Then we agree on acceptance metrics — without them, the debate about synthetic quality becomes subjective.

  1. Label columns: numeric, categorical, dates, and service identifiers that are not used in synthesis.
  2. Form a holdout set for validation — it does not participate in training and remains the comparison point until the end of work.
  3. Train the generative model on prepared data, separately by segments if distributions within the table are heterogeneous.
  4. Tune synthesis parameters: model depth, number of epochs, class ratio. Rare categories are balanced manually, otherwise the model does not reproduce them.
  5. Evaluate synthetic quality: compare distributions, check preservation of correlations between features.
  6. Deliver the model and report: training scripts, configuration, retraining rules when new data arrives.

Validation of result on holdout set

Acceptance is not based on row "similarity". The control model is trained on synthetic data and validated on a real holdout set: if the quality gap with the model on original data does not exceed the agreed threshold, the batch is accepted. Otherwise we return to tuning synthesis parameters, not rewrite the problem statement.

Synthesis artifacts: model, feature schema, reports

Tabular data synthesis is valuable not for a result in a notebook, but for a set of artifacts that your team runs, checks, and retrains without us.

We deliver not a "model in words", but a reproducible package: from weights and feature schema to quality report and retraining rules.

  • Weights of the trained synthesis model with a checksum, training mode description, and fixed environment.
  • Feature schema and metadata: column types, valid ranges, category levels, rules for handling missing and rare values.
  • Synthetic data quality report — for each feature and for joint distributions.
  • Model retraining policy: triggers, dataset size, validation procedure before rollout.
  • Synthesis model documentation: architecture, hyperparameters, applicability limitations, known weaknesses.
  • Generation and training scripts — run with one command on your environment.
  • Privacy diagnostics: verification that training set rows cannot be reconstructed from synthetic data.

What is included in the quality report

We compare synthetic data with original data by marginal and pairwise distributions, share of unique rows, and matching category proportions.

We separately calculate similarity metrics and separability: if a discriminator model easily distinguishes synthetic from real rows, the generator is sent back for revision.

Each metric comes with a baseline value so that on next retraining degradation is visible, not just an absolute number.

How we deliver the model and retraining policy

The package is deployed in your environment: inference, input data drift monitoring, and retraining script. The policy specifies which shifts in feature schema or metric drops trigger retraining, who initiates it, and by what criteria the new version is accepted. This way the synthesis model lives as a regular service, not a one-off experiment.

Case study: restored class balance in a request registry

A customer service request registry over 18 months — about 400 thousand records, and the "decline during charge-off" class occupied 0.7% of rows.

On such a distribution, the model effectively adapted to the majority class: recall on the rare class stayed at 0.12, and it was precisely these misses that most often reached production.

Initial state of the registry

Class weighting and majority class undersampling were tried before us. The former shifted the decision threshold and tripled false positives; the latter discarded more than half the rows and dropped precision on the frequent class.

Manual labeling of rare cases ran into the frequency of the event itself — it was not possible to collect a statistically significant volume in a reasonable time.

What changed after dataset synthesis

The rare class was synthesized further with the CTGAN model, controlling joint distributions by amount, contact channel, operation type, and customer tenure.

Synthetic data went only into the training part: validation and test sets remained entirely real, otherwise the metrics would measure generator quality, not model quality.

The rare class share in the training set grew from 0.7% to 15%, while the divergence of feature distributions from the original remained within statistical error.

Recall on the rare class rose from 0.12 to 0.71, the number of missed declines on the test set decreased by more than five times, and false positives increased by 1.5 percentage points.

The decline class, which previously was detected only after charge-off, is now filtered out before the operation is applied.

How adversarial tabular synthesis differs from diffusion

Both families solve one task — tabular data generation — but the mechanics are different. Adversarial synthesis trains a generator against a discriminator, while diffusion restores a table from a sequentially noised state. Hence the practical differences: in stability, speed, and behavior on mixed features.

Stability of model training is the main difference. The adversarial pair is prone to collapse: the generator quickly converges on a narrow set of plausible rows and loses rare categories.

This is treated by selecting the ratio of network training steps, diversity penalties, and distribution control, but almost always requires several iterations.

The diffusion scheme trains against a fixed reconstruction objective, so the loss curve is smoother and less dependent on the balance of the two networks. The price is time: each row takes many steps of the reverse process. The adversarial generator outputs a row in one pass, so a large array is assembled in minutes.

On mixed features, the gap is more noticeable. In a table, numbers, categories, dates, and missing values coexist, and the adversarial model more often produces impossible combinations such as age 12 with tenure 20.

Diffusion processes each type with its own noise process and missing-value mask, so it better maintains joint dependencies.

The answer to which synthesis method to choose depends not on fashion, but on requirements: share of rare categories, importance of joint dependencies, volume and frequency of generation.

A correct comparison of generation approaches is to train both families on the same dataset and see how many rows are rejected by rules and how closely model quality on synthetic data matches quality on real data.

Common technical doubts about synthetic datasets

Engineering-level doubts are not about row plausibility, but about privacy, rare class, and distribution stability. We collected four objections that most often arise when defending a model on synthetic data.

Will real customers end up in the synthetic data?

The generator learns on distributions rather than storing rows: the output is combinations of values that were not present in the original dataset.

We check synthetic data privacy as a separate step — calculate the proximity of each row to the nearest real record and discard anything that came closer than the agreed threshold.

The rare class is too small for training

Conditional generators (CTGAN, TabDDPM) multiply the rare class by label rather than copying individual examples — otherwise the model learns noise.

We fix the target class ratio in advance and verify quality by training on synthetic data with evaluation on real data specifically for the rare class.

Will mixed feature types break the generator?

We bring continuous features to a common form, encode categorical ones, and reproduce missing values as a separate signal. The inverse transformation returns column types, ranges, and valid values — the dataset is plugged into the existing pipeline without manual cleaning.

Data drifts — synthetic data will become outdated

Distributions drift: tariffs, channels, and behavior change. We rebuild synthetic data on a schedule, track divergence by columns and slices, and retrain the generator as soon as it deviates from current data. We capture drift with metrics before it manifests in model quality.

Let's discuss the task: how work on synthesis begins

To come back with an estimate and work plan rather than general words, we need a minimum of context about the data and how the result will be used.

The checklist below covers data preparation for the start in one to two hours on the customer side — but it immediately shows where synthesis will have an effect and where it is more reasonable to stay with the real dataset.

  • Target task: what exactly we predict or generate and which metric is considered success.
  • Source extract for the available period — CSV, Parquet, or export from storage.
  • Column description: types, units of measurement, valid ranges, which fields are confidential.
  • Rare classes and slices: where data is objectively insufficient — the main candidate for additional synthesis.
  • Constraints: de-identification requirements, prohibition on moving data outside your environment.
  • Application point: model training, test environment, reporting, or load-testing dataset.

Next we profile the dataset: proportions of rare categories, correlations, missing values, period biases.

This determines the choice of approach — generative adversarial scheme or diffusion model — and the validation scheme: comparison of distributions by columns, preservation of relationships between features, and control of the risk of reproducing real records.

Describe the task in any convenient way — we will discuss the data synthesis task concretely. If you plan to order AI solution development for your environment, we will start by reviewing these inputs and come back with a work plan and timeline estimate.

AI Development Areas

Latest works

  • B2B ADVANCE company website development
    B2B ADVANCE company website development
    1542
  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1393
  • Website development for BELFINGROUP
    Website development for BELFINGROUP
    1081
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1368
  • B2B Advance company logo design
    B2B Advance company logo design
    815
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1139