Synthetic Data: Generation, Filtering, and Validation

Synthetic data is not automatically private, unbiased, or useful because a generator produced it. A language model can repeat memorized text, a simulator can encode unrealistic assumptions, and a perfectly valid row can still make a downstream model worse. Generating examples is usually the easy part. Establishing what those examples represent is the engineering work.

The central thesis is: a synthetic dataset is a designed intervention on a target distribution, not a cheap imitation of real data. Its objective, source lineage, coverage, exclusions, and acceptance tests must be explicit. Validation must be independent of the mechanism that generated and filtered the data, or the pipeline will merely confirm its own assumptions.

This chapter uses a customer-support intent classifier as a worked example. The goal is to improve recognition of rare, operationally important intents without copying customer messages into a generation prompt. The same discipline applies to vision defects, tabular fraud scenarios, speech conditions, and test corpora for extraction systems.

Start with an Objective and a Data Contract #

“Create more training data” is not an objective. State the downstream decision, the population it serves, the deficiency being addressed, and the harms introduced by a bad example. Synthetic data can serve several different purposes:

• augment underrepresented regions of a training distribution;
• create controlled counterfactuals that vary one factor at a time;
• stress-test known boundaries and failure modes;
• exercise a schema or pipeline before real data exists;
• support privacy-preserving collaboration when the chosen method has evidence for that claim;
• simulate future or rare conditions under documented assumptions.

These purposes demand different datasets. Stress cases should not be mixed into training merely because they are available. Pipeline fixtures need deterministic edge values, not natural language diversity. A privacy objective needs a threat model and measurable protection, not a statement that names were replaced.

Write a data contract before selecting a generator. It should define the unit of data, label semantics, required and forbidden fields, valid ranges, population slices, provenance, retention, permitted uses, and quality states. Include a reason for every generated item, such as rare_intent, counterfactual, or format_boundary. A row without lineage should be rejected even when its content looks plausible.

For the support classifier, the unit is one inbound message with language, channel, intended label, allowed ambiguity, and scenario attributes. The contract forbids real account identifiers, copied tickets, names, email addresses, and order numbers. It also distinguishes a customer’s described intent from an agent’s eventual resolution: “I do not recognize this charge” is a dispute signal even if later investigation finds the charge valid.

Define success relative to the intended use. Training augmentation should improve or preserve performance on untouched real-world validation slices without unacceptable regressions. A stress corpus succeeds by exposing behavior, not by resembling production prevalence. Keeping those goals separate prevents a large synthetic score from being mistaken for evidence about real users.

Select Generators for the Structure You Need #

Generator choice determines which assumptions enter the dataset. Use the simplest generator capable of representing the needed variation, and combine generators when their errors are complementary.

Rule-based templates provide precise labels and controllable coverage. They are effective for structured combinations, boundary values, and protocol fixtures. Their weakness is repetitive surface form and the author’s blind spots. Simulation captures mechanisms such as sensor physics, queues, or financial state transitions, but simulated behavior is only as realistic as the model and parameter ranges.

Generative models provide linguistic or visual variety and can express complex conditional scenarios. They can also collapse toward familiar patterns, leak source material, produce inconsistent labels, and make subtle correlations difficult to trace. Fine-tuned generators inherit risks from their training corpus. Retrieval-assisted generation can increase domain specificity while creating a direct copying path that must be measured and governed.

Transformations create counterfactuals from approved seeds: alter tense, channel style, non-causal attributes, lighting, background, or noise while preserving the label. This is powerful when invariance is known. It is dangerous when the transformation changes the label, such as negating “I recognize this charge” or cropping away the object that justifies an image annotation.

Record a generation recipe with generator and configuration version, random seed where meaningful, input lineage, target scenario, and transformation history. A model name and prompt are not always enough for exact reproduction, but they still establish accountability. Store rejected-item reasons as aggregate metrics; retaining rejected sensitive payloads may conflict with the privacy objective.

Design Coverage Instead of Chasing Volume #

More rows amplify whatever the generator already does. Coverage planning begins with dimensions that can alter the downstream decision: label, language, message length, channel, ambiguity, spelling quality, product vocabulary, temporal phrasing, and whether several intents coexist. Sensitive or demographic attributes require a justified purpose, appropriate governance, and careful handling; adding invented identities casually can reinforce stereotypes rather than test fairness.

Create a coverage matrix from domain knowledge and observed gaps. Do not ask a generator to sample “diverse examples” and infer coverage afterward. Specify allowed combinations, impossible combinations, minimum representation for critical scenarios, and intentionally empty cells. Pairwise coverage can be practical when the full Cartesian product is enormous, while high-risk interactions may require explicit higher-order cases.

Prevalence and coverage are different. A balanced synthetic set can teach rare labels, but evaluating on that same balance gives a misleading operational picture. Retain the expected deployment prevalence in an independent real-data evaluation set, and use weighting or calibrated sampling when combining generated and observed data. Document the final mixing policy; a dataset that begins as a small augmentation can silently dominate training after repeated pipeline runs.

Counterfactual pairs are useful for testing causality. Change a merchant name while preserving the dispute intent, or change “I did not make this purchase” to “I did make this purchase” and require the label to change. Each pair should state which attributes are invariant and which are causal. This makes the desired behavior inspectable rather than relying only on aggregate class counts.

Coverage dashboards should report accepted examples by scenario recipe, not just by predicted label. If a filter disproportionately rejects short messages in one language, the accepted dataset may lose the exact slice it was intended to improve.

Work Through a Rare-Intent Augmentation #

Assume an existing classifier confuses payment_dispute with refund_request when messages are short or contain both a complaint and a desired remedy. The objective is to augment training around that boundary. The real validation and test sets are frozen before generation and are unavailable to the generator.

Domain owners first define label rules:

The team writes abstract scenario records rather than real messages:

{
  "scenarioId": "dispute-short-multilingual-01",
  "targetLabel": "payment_dispute",
  "language": "en",
  "channel": "mobile_chat",
  "attributes": {
    "recognizesPurchase": false,
    "mentionsRefund": true,
    "lengthBand": "short",
    "merchantType": "digital_subscription"
  },
  "forbiddenContent": ["real_person", "real_account", "real_ticket_text"]
}

A template generator establishes label-preserving skeletons. A language model paraphrases only those abstract scenarios under constraints, without access to production tickets or frozen evaluation cases. A separate labeling component predicts intent without seeing the target label. Deterministic checks reject forbidden patterns, malformed language tags, duplicate normalized text, and mismatches between stated attributes and generated fields.

Disagreement is not automatically bad generation. A reviewer may find that the scenario is legitimately ambiguous or that the label rule is incomplete. Such items enter an adjudication queue rather than being rewritten until a validator agrees. Accepted examples preserve scenario lineage and reviewer status. The training manifest pins a specific dataset version and mixing ratio so results can be attributed and rolled back.

For verification, compare a baseline classifier and an augmented classifier on the untouched real-data slices, especially short disputes, recognized-purchase refunds, multilingual messages, and ambiguous cases. Also test the generated counterfactual pairs. Synthetic holdout performance is diagnostic of recipe consistency, but the deployment claim must come from independent target-distribution evidence.

Filter in Stages Without Hiding Uncertainty #

A good filter pipeline resembles a compiler: cheap structural rejection first, semantic checks later, and an explicit reason at every exit. This reduces cost and makes bias in the acceptance process visible.

Start with schema, encoding, range, length, and policy checks. Then detect exact and near duplicates within the generated set and against permitted reference fingerprints. Validate relationships, such as totals matching line items or image annotations lying inside dimensions. Domain rules can reject impossible combinations. Specialized classifiers can score language, toxicity, label agreement, or visual quality, but each classifier has thresholds and blind spots.

Avoid a single opaque quality score. An item with fluent prose and the wrong label is not “mostly good.” Retain dimensions such as validity, fidelity, diversity, label confidence, safety, and privacy risk. Define which failures are terminal and which require review. Filters trained on the same model family as the generator may share errors, so use heterogeneous checks and human adjudication for consequential boundaries.

Deduplication requires semantic judgment. Exact hashing catches repeated bytes, normalized hashing catches superficial formatting changes, and embedding similarity can identify paraphrases. Aggressive similarity thresholds can erase legitimate short examples because many valid utterances are naturally alike. Review clusters and report how deduplication changes slice coverage.

Do not repeatedly regenerate only the rejected cells until every quota is filled. That optimization can produce unnatural edge cases tailored to the filter. Investigate why rejection concentrates, revise the scenario or generator deliberately, and version the change.

Detect Leakage and Evaluate Privacy Claims #

Leakage has several forms. Source leakage occurs when generated output reproduces records used to build or prompt the generator. Evaluation leakage occurs when test examples, answers, or close variants influence generation or filtering. Identity leakage exposes attributes that can be linked to a person. Label leakage inserts shortcuts, such as always mentioning “unauthorized” in one class, that make training easy without representing the real task.

Prevent evaluation leakage organizationally: split data before any prompt examples, retrieval index, generator tuning, or threshold selection. Restrict generator access to the approved training partition and synthetic scenario definitions. Hashes and access logs help, but semantic copies require near-duplicate and phrase-overlap analysis. Inspect suspicious matches manually under controlled access.

Replacing direct identifiers is pseudonymization, not proof of anonymity. Rare combinations, free text, locations, timestamps, and image backgrounds can re-identify people. If privacy is an objective, state the attacker knowledge being considered and choose a method with an appropriate guarantee. Differential privacy can bound the influence of a training record when implemented and accounted for correctly, but it trades utility for privacy and does not make downstream handling unrestricted.

Membership-inference and nearest-neighbor probes can reveal memorization risk, though passing them does not prove absence of leakage. Use canary strings only in controlled training experiments, never by planting secrets in production data. Compare similarity distributions for generated-to-training and held-out-to-training pairs, inspect outliers, and prevent raw sensitive examples from entering prompts merely to make output “realistic.”

Privacy review covers the pipeline, not just the final file: generator provider retention, caches, rejected outputs, human-review tools, experiment trackers, and exports all matter. Synthetic data should carry a usage policy because it may remain derived from regulated or licensed sources.

Validate Fidelity, Diversity, and Downstream Utility #

No single metric validates a synthetic dataset. Fidelity asks whether examples obey domain structure and plausible relationships. Diversity asks whether meaningful modes are covered without duplication. Utility asks whether the dataset improves the intended downstream task. Privacy asks whether records or identities can be inferred. These dimensions can conflict.

Compare distributions only on features whose meaning is understood. Matching every marginal statistic can preserve unwanted bias and still miss interactions. A synthetic tabular dataset can match age and outcome separately while inventing their relationship. Use conditional distributions, correlations, constraint violations, rare-category coverage, and expert review. For language and images, embedding-space plots can reveal clusters, but distance is not a substitute for semantic inspection.

Downstream validation should train the same pipeline under controlled variants: real-only baseline, synthetic-only diagnostic, and the proposed mixture. Keep initialization and tuning policy comparable, repeat stochastic training, and evaluate on untouched real data by slice. Check calibration and error costs, not only aggregate accuracy. A gain on a rare intent may be unacceptable if common refund requests are redirected incorrectly.

Test distribution shift explicitly. Generation recipes often reflect today’s ontology and vocabulary; deployment inputs evolve. Hold out time periods, channels, devices, or regions when appropriate, and inspect whether synthetic augmentation helps only examples that resemble its prompt style. Human experts should judge a blinded sample for label correctness, realism, missing modes, and harmful stereotypes, with disagreement recorded rather than averaged away.

Manage Tradeoffs, Review, and Dataset Operations #

Synthetic data trades collection cost for modeling and validation cost. It can target rare cases quickly, but generated diversity may be cosmetic. It can reduce direct exposure to real records, but a memorizing generator can recreate them. It can make labels cheap, but labels may encode the generator’s interpretation instead of domain truth. These tradeoffs should appear in the dataset card and approval decision.

Version source permissions, scenario catalog, generator, prompts or simulator parameters, filters, reviewer guidelines, accepted manifest, and training mixture. Make builds reproducible where possible and at least traceable where provider behavior is nondeterministic. Never let a mutable “latest” dataset flow directly into training. Changes in acceptance rate or scenario coverage should require review.

Human reviewers need calibrated tasks. Show scenario intent and provenance separately from generated content when checking fidelity, but blind them to generator identity when comparing quality. Use multiple reviewers on ambiguous or high-impact classes, define escalation, and audit systematic disagreement. Reviewer edits create new derived examples and need their own lineage.

In operation, monitor generator failures, filter rejection reasons, duplicate clusters, coverage cells, review disagreement, privacy alerts, and downstream slice behavior. Stop generation if a source permission changes, a provider retention policy becomes incompatible, leakage probes find suspicious matches, or a recipe begins filling quotas through near duplicates. Retire dataset versions when their ontology or consent basis is obsolete.

The important outcome is not a warehouse full of plausible samples. It is a governed dataset whose purpose, assumptions, provenance, blind spots, and measured effect are visible. Synthetic data earns trust only when independent evidence shows that it helps the intended population without smuggling in copied records, brittle shortcuts, or unexamined generator bias.