Synthetic Data Generation for LLM/GenAI Courses

English עברית

Making your own training data with AI, explained simply. The trick is control: decide exactly what each example should contain, then build it on purpose instead of hoping. Below is the big idea, then thirteen steps, each with a good and a bad example.

The big idea

There are two ways to make data with AI. Only one gives you data you can trust.

What works

Make it on purpose

  • You choose the answer (the label) and what should vary, then pick each on purpose.
  • For images, you give the model a shape to follow: a pose, depth, or outline.
  • Every example comes with a label you already know is correct.
  • You can repeat it, look at it, and fix it.
✓ Do thisYou choose a sentiment and a genre for each of 500 movie reviews, build the prompt from them, so every review has the label you set.
✕ Not thisYou reuse one fixed prompt and hope variety appears, then find the 500 reviews all look nearly the same.
What doesn't

Just ask and hope

  • You ask for “some examples of X” and keep whatever the model returns.
  • You assume that saying the label makes it true.
  • You make everything in one go and never look at it.
  • You can't reproduce it, and you can't fix what went wrong.
✓ Do thisIf you start by just asking, treat it as a quick test, then switch to picking the attributes yourself and checking the output.
✕ Not thisYou ask for “500 reviews, some good and some bad,” keep 430 positive comedies, and trust labels you never verified.

The thirteen steps

In the order you meet them. Each step has a good example to copy and a bad one to avoid.

Phase 1 · Plan before you generate

1

Look for real data first

Before you make fake data, check whether real data already exists. Real data is almost always better, and you may only need to reshape it.

✓ Do thisYou need product reviews, so you find an open reviews dataset and relabel it for your task.
✕ Not thisYou skip searching and generate 10,000 fake reviews, when a public dataset was one search away.
2

Decide the labels and the variety up front

Before writing any prompt, know exactly what each example should teach (the label) and what should differ from one example to the next.

✓ Do thisYou list labels (spam / not spam), decide messages vary by length and tone, then pick each on purpose.
✕ Not thisYou ask for “some spam and some normal messages” and hope the mix comes out balanced.
3

Split your variables into “the answer” and “the rest”

One variable is the label you want to teach. The others just add variety, so the model can't cheat by latching onto the wrong thing. Then build the prompt from the values you picked.

✓ Do thisAnswer = sentiment. Variety = cuisine, tone, length. You pick one of each, then write the review prompt around them.
✕ Not thisEvery positive review happens to be about pizza, so the model learns “pizza = positive” instead of real sentiment.
4

Change the values, not fixed blocks of text

Get variety by changing the attributes and their values, then let the model write each example around them. Don’t build examples by shuffling a few fixed sentences, or they all come out with the same shape.

✓ Do thisYou set cuisine, tone, and length to different values and let the model write each review fresh from them.
✕ Not thisYou keep one template and only swap “great” for “terrible” and “pizza” for “sushi,” so every review reads the same.
5

Turn fuzzy words into a checklist

Don't ask for something you can't define or recognize. Break a vague idea into concrete features you can name and check.

✓ Do this“Beginner code” becomes bad variable names + no error handling + copy-pasted blocks, and you ask for those.
✕ Not thisYou ask for “code written by a beginner” and get code that looks fine, or is wrong in some random way.

Phase 2 · Make the data under control

6

Test your idea in ChatGPT before writing code

Try the prompt by hand first. Fix the wording in the chat window before you automate anything.

✓ Do thisYou paste the prompt into ChatGPT, see the output is off, and fix the wording in five minutes.
✕ Not thisYou write 200 lines of API code, run it on 5,000 samples, and only then notice the prompt was wrong.
7

Use the API to make it repeatable

Once the prompt works, run it from code so you can reproduce and scale it, and save everything about each example.

✓ Do thisFor each sample you save one row: the label, the prompt, the model, and the output.
✕ Not thisYou generate in the chat window and copy-paste results, so later you can't reproduce or trace anything.
8

Train your own generator when prompting isn't enough

If a general model can't match your special domain or style, fine-tune one on real examples so it produces the kind of data you actually need. Then check it doesn't just copy its training data.

✓ Do thisYou fine-tune an LLM on 300 real support tickets so it writes new ones in the same style, then test a model trained on them on real tickets.
✕ Not thisYou fine-tune on 20 samples, and the model just repeats them or invents unrealistic tickets.
9

For images, steer with a control signal

For pictures, words alone are not enough. Give the model a shape to follow, such as a pose, a depth map, or an outline, using tools like ControlNet.

✓ Do thisYou give a pose skeleton, so every generated person stands exactly in the position your task needs.
✕ Not thisYou only write “a person jumping” and get random poses you can't line up with your labels.

Phase 3 · Grow it safely

10

Make a little, then look

Generate a small batch, check it, fix the problems, then make more. Never make it all in one shot.

✓ Do thisYou make 20 examples, spot a labeling bug, fix it, then make the next 20.
✕ Not thisYou make 5,000 in one go, then discover every one has the same bug.
11

Debug on a few before scaling up

Prove the process works on a handful of samples before you make thousands.

✓ Do thisYou check that 10 samples cover every class and are labeled correctly, then scale to 10,000.
✕ Not thisYou assume it works, make 10,000, and half of them are mislabeled.

Phase 4 · Check and choose

12

Look at the data with your own eyes

Actually read and view your samples. Find the bad ones, and work out why they went wrong so you can fix the cause.

✓ Do thisYou read 50 samples, find contradictions, and trace them back to one confusing word in the prompt.
✕ Not thisYou skim only the nicest examples and assume the rest are just as good.
13

Try a few methods, keep the best

There is rarely one right way. Try a couple of approaches and keep the one that gives the best data for the lowest effort.

✓ Do thisYou compare generating from scratch against editing real examples, and keep whichever looks more realistic.
✕ Not thisYou use the first method that runs and never check whether another would work better.

Quick Links