Ask what determines a fine-tuned model’s quality and you’ll hear about base models, ranks, learning rates. The honest answer is less glamorous: the dataset decides almost everything, and in applied fine-tuning that dataset is nearly always synthetic — generated by a strong LLM, not written by people. That’s not a shortcut to be embarrassed about; done well, it’s the method. Done carelessly, it’s how you spend GPU money teaching a model to be confidently mediocre.

Here’s how the sausage is made, and where it goes wrong.

Why synthetic at all

A fine-tuning example is a demonstration: given this input, produce this output. For a model that answers questions over your documentation, that means thousands of question→answer pairs grounded in your material. Hand-writing them is weeks of expert time; the experts refuse, reasonably. Meanwhile a strong LLM, shown a passage of your material, can generate plausible user questions and correct, grounded answers in seconds, for pennies.

The economics are decisive, but there’s a quality argument too: a generator can be instructed to cover the space systematically — every section, every edge case, every phrasing style — where human writers drift toward the examples that are easy to write.

The failure mode nobody warns you about: monotony

Left to its own devices, an LLM generating questions from a passage produces the same shapes over and over. “What is X?” “What does Y mean?” Definitional, polite, well-formed. Generate ten thousand of these and you’ve built a dataset with the surface area of a few hundred — and a model that performs beautifully on questions phrased like a quiz and stumbles on everything else.

This is the synthetic-data version of overfitting, and it happens before training even starts. Real users don’t ask quiz questions. They ask compound questions, vague ones, questions with wrong assumptions baked in (“why does the API return XML?” when it returns JSON), comparisons, how-do-I’s typed in a hurry with the product name misspelt.

The fix is structural, not hopeful: vary the instruction, not just the passage. Good pipelines explicitly enumerate facets — question types (factual, comparative, procedural, troubleshooting), personas (novice, expert, annoyed), difficulty levels — and force the generator through combinations of them. Some go further and build a topic tree over the corpus first, so coverage is guaranteed by construction rather than sampled by luck.

The second failure mode: drift

A generator answering questions “about” your passage will happily supplement it with its own background knowledge — current as of its training data, generic where your product is specific, and occasionally flat wrong. Every such answer teaches your model something that isn’t in your documents. This is how a model fine-tuned on your v3 docs ends up describing v2 behaviour the generator remembered from the public internet.

The defence is grounding discipline: the generator is constrained to answer from the provided passage, and pairs whose answers can’t be traced to it are suspect. It’s also why generation should happen per-chunk rather than over the whole corpus at once — a bounded context leaves less room to freelance.

Where humans belong in the loop

Not writing examples — judging them. The highest-leverage ten minutes in the whole pipeline is a human skimming a random sample of generated pairs before training. You’re not proofreading; you’re looking for systematic rot: questions nobody would ask, answers that hedge, a generator that misunderstood what the product does. One person reviewing fifty pairs catches the problems that would otherwise be baked into ten thousand.

The second human touchpoint is rating a small preview batch and regenerating with feedback — “questions are too formal, answers too long” — before committing to the full run. Steering the generator on fifty examples is cheap; discovering the problem after training is not.

Quantity, since you’ll ask

Less than everyone assumes. For behaviour shaping — format, tone, tool habits — hundreds of high-quality pairs move a model visibly. For domain Q&A over a document set, low thousands is a sensible target. Past that, returns diminish fast, and a dataset twice as large but 10% sloppier is a worse dataset. When in doubt, spend the budget on diversity and review, not on volume — and hold some of it back for evaluation, because data you train on can never again tell you whether training worked.

Ekcron’s Data Studio is built around exactly this loop: it generates training pairs from your documents with enforced diversity, shows you a preview batch to rate and refine before the full run, and holds out an untouched slice for evaluation. Try it at Ekcron.