Generating Synthetic Data for Model Training

Imagine you are asked to build an AI model that predicts health outcomes for patients. The most obvious source of training material is the records that already exist: real patient files, collected over years of care. Yet in many organizations those records cannot simply be handed to a model-building team. The data is valuable precisely because it describes real people, and that same fact is what makes it difficult to use.

This article follows one problem through a short sequence of steps: privacy concerns in data usage, and the approach the course describes for reducing them, which is synthetic data. As you read, keep a running picture of the path a dataset takes from the real world into a model, because the core idea is about where the sensitive part of that path stops.

The contrast between the two kinds of data is the core of this topic. Real records contain sensitive information, and in healthcare, legislation makes it hard, if not impossible, to use them to train a model. Synthetic records are generated to mimic them and are described as containing no sensitive information. That single difference, sensitivity, is what decides which kind of data a team is allowed to feed into training.

Synthetic data is often described as the only option where human-generated data cannot be used because of privacy concerns. The two cases the course names are synthetic patient records and synthetic claims. Insurance claims are another kind of record where privacy is a serious concern, so the same reasoning applies there.

The diagram below traces the path. Real data remains the starting point, and synthetic data is added to it. The sensitive real dataset feeds a generator, which produces a synthetic dataset. The generated portion does not go straight into training. It must be evaluated first, just as real data must be checked before it is used to train a model. Follow the arrows and notice the point where the sensitive information stops flowing.

Read the diagram as a boundary. Everything to the left of the synthetic dataset carries the sensitivity of the real people. The synthetic dataset is the point at which that sensitivity is said to be absent, which is why it can be used where the real records cannot. The boundary does not remove the need for judgment, however. The evaluation step still sits between generation and training.

A dataset is designed by first deciding the behaviors the model should learn, then choosing data that demonstrates them. The data you need is shaped by your use case and by the training phase the model is in. Pre-training draws on different data than instruction finetuning or preference finetuning does. Even so, dataset design across all of these phases rests on the same three criteria: quality, coverage, and quantity.

Quantity gets most of the attention in discussions about training, but the other two criteria matter just as much. Keep that in mind, because the rest of the design logic depends on it.

The course is firm that synthetic data must be evaluated to ensure its quality before it is used to train models. This applies to generated data in the same way it applies to real data. A generated example can be wrong, off-topic, or unrepresentative, and training on it can teach the model those flaws.

The flowchart below shows the order in which a generated record moves through the check. Notice that a record which does not pass is not sent into the training set. The loop back to generation is a pedagogical illustration of how a failed record is handled, not a fixed procedure from the course.

Healthcare is the clearest case where privacy concerns are significant. Legislation in healthcare makes it hard, if not impossible, to use real patient records to train a model. Insurance is the second industry the course names, because claims data also describes real people and their sensitive circumstances. In both industries the value of the data and the difficulty of using it come from the same source: the records describe real individuals.

A data flywheel describes a model that continually improves upon itself. The implication of using synthetic data is that, in theory, it is possible to train a model that keeps improving this way. Each round of improvement produces material for the next round, so progress builds on itself. The diagram below traces one turn of the cycle and what happens on each pass.

Follow one turn. The model produces output. That output is checked by a feedback signal. If the signal is reliable, the output becomes new training data, which feeds the next training round and yields an improved model. The improved model then produces the next round of output, and the cycle repeats. The loop is only as good as the step where feedback is judged. If the feedback is unreliable, the next round is built on a flawed foundation.

The loop is attractive, but whether it works in practice is another story. The flywheel depends on the quality of what the model feeds back into itself. A cycle that reinforces mistakes is not an improvement. The course gives two contrasting cases that show what separates a working loop from a failing one.

In the working case, a reported study found that about 20 percent of solutions were initially incorrect but self-corrected. This indicated that the model learned from execution feedback and improved its performance. The feedback came from running the code, a signal that reliably separated good output from bad.

The failing case is the same loop with a weaker signal. If a human labeler answers a question using knowledge the model does not have, the labeler is effectively teaching the model to hallucinate. The label looks correct to a person but carries information the model cannot reproduce from its own inputs, so the model learns to produce answers without grounds.