Synthetic data for LLM fine-tuning: where quality breaks
In a narrow domain — law, medicine, industrial regulations — high-quality examples rarely number more than a few thousand.
Manual annotation stalls: experts spend weeks agreeing on wording, while fine-tuning on a small sample leads to overfitting — the model confidently reproduces phrases from the training set and does not transfer the logic to new cases.
The first temptation is to generate additional samples with a model, and that is where quality degradation begins.
When the generator is a related model, it replicates its own biases: formulaic introductions, a uniform reasoning structure, identical answers. Diversity collapses — thousands of examples describe a single case.
Annotation noise does not average out; it scales: the teacher's error repeats across hundreds of rows and becomes a regularity for the model.
The second trap is evaluation. If validation runs on the same generated sample, metrics rise but say nothing about behavior on real requests. There is also leakage: examples from the same source documents end up in both training and validation — the model memorizes answers. On live traffic, the assembly falls apart at the first atypical request.
Synthetic data for LLMs works when generation is controlled: the example schema and topic distribution are defined, the share of generated data is limited, every example passes a filter for duplicates and factual consistency, and part of the sample is checked by a human. We explain how this is covered.
What controlled generation of training samples provides
Rare classes drop out of the sample first: there are only a handful of live examples for them, and the model collapses them into the majority class.
Controlled generation of training samples closes this gap — dozens of real cases are expanded with hundreds of semantically consistent ones, and macro-averaging across classes stops failing on the tail of the distribution.
Manual annotation changes role: a human checks not every example but a stratified sample and edge cases. The generator does the rough layer — deduplication by embeddings, consistency checking of “request — answer” pairs, filtering out formulaic wording.
The amount of manual work is reduced severalfold, and the freed-up time goes to disputed examples where a human decision actually changes model behavior.
We keep example quality control as a separate annotation layer rather than inside a script: Argilla provides a review queue, versioning of edits, and tracking of disagreements between reviewers.
The share of rejected examples, inter-annotator agreement, and coverage of each class are visible — these numbers decide what to expand in the next iteration.
Training reproducibility rests on fixing the dataset version, prompt version, and generation seed: the same dataset yields the same result, and a discrepancy in metrics between runs indicates a data change rather than randomness.
This makes it possible to compare experiments with each other and roll the sample back to a previous version if quality has dropped.
Approaches to sample formation: generation, augmentation, transfer
A sample is almost never assembled in one way: pure synthesis covers volume and class balance, while real examples keep the distribution close to production. The mode is chosen based on how much data is already annotated and how strict the requirements for answer style are.
| Approach | When it fits | Limitations |
|---|---|---|
| Generation from scratch | Narrow domain, few annotated examples, imbalanced classes | Only embedded rules are reproduced; duplicate filtering and plausibility checks are needed |
| Augmentation of real examples | There is a base corpus, but rare scenarios are missing | Synthetic data inherits noise and biases from the original sample |
| Answer style transfer | A unified tone and answer format within the domain are needed | Its errors are transferred along with the style; quality drops outside the templates |
| Annotation without manual labor | There are unlabeled requests, reviews, dialogue history | Label accuracy is limited by the model's agreement with humans |
A common limitation of synthesis is distribution drift: the higher its share in the sample, the greater the risk that the model learns the generator's quirks rather than the subject domain.
Therefore the share of real data is fixed, deduplication is maintained, and the result is evaluated on a held-out real sample.
We select the mode for your domain: first we analyze which examples the model currently gets wrong, and only then decide what to generate, what to augment, and where style transfer is sufficient.
Stages of work on the sample: from audit to handover
Without a fixed work order, a fine-tuning sample turns into a set of examples whose quality is debated by taste. We go from data audit to validation on examples the generator has not seen: sample acceptance criteria are known before the start, not discussed after the first run.
What we fix at each step
-
Data audit. We count volume, duplicates, annotation quality, distribution by topic, length, and complexity. The output is a gap map: which scenarios are not covered and what will have to be synthesized.
-
Generation schema. We choose the basis — your corpus or a set of rules — and define the target class distribution and complexity level. We separately fix what the model does and what a human writes: otherwise the set comes out uniform.
-
Filtering rules. Exact and semantic deduplication, removal of examples overlapping with the control set, personal data checks, class balancing. The rules live in a config — they can be replayed.
-
Example validation. Automated format and structure checks plus sampled manual review: we calculate the share of matches with the reference and separately analyze edge cases.
-
Validation on a held-out sample. Metrics on data that did not participate in generation, comparison with the baseline model and with your current set. If the gain is not confirmed, we return to the generation schema.
-
Handover. We deliver the dataset in the agreed format, generation and filtering configurations, a metrics report, and a reproduction procedure. We teach your team to augment the sample without mixing it with the control set.
What you keep: sample, generator, documentation
We hand over not an archive of files but a working process: a set with the provenance history of each example, a generator that runs on your side, and documents by which the team reproduces the result without us.
Acceptance is not based on a description but on a run — generation is launched in your environment, and its output is checked against control sets.
- A dataset with a provenance passport: share of real and synthetic examples, distribution by topic, which checks each block passed.
- A generator in your environment: launch parameters, request templates, filtering and rejection rules, rerun scripts.
- Example selection rules: how duplicates and near-identical wording are filtered out, by what criteria an example goes into training and by what criteria it is rejected.
- Sample documentation: field schema, statistics by length and topic, known limitations, and blind spots of the set.
- Control sets: the held-out part and reference answers against which model versions before and after fine-tuning are compared.
- Update procedure: frequency of adding examples, who launches generation, which quality thresholds count as acceptance.
- Team instructions: step-by-step launch, troubleshooting common failures, what to look at in logs, and when to contact us.
A separate item is handover of the generator: a joint run on your data with a walkthrough of settings so that you can later change templates and filters yourselves.
The kit is assembled so that fine-tuning does not depend on the contractor: you can expand the topic coverage or rerun generation with your own team, and we join in on complex cases.
Practice: how a sample closed the example shortage in support
The client is a support service with a stream of requests in several languages: ticket classification and generation of a draft response for the operator.
The model was trained on an export from Zendesk, where rare scenarios — returns, disputed charges, integration failures — were represented by single examples.
For those, the assistant answered with a template or refused, and specialists annotated examples for rare topics manually for months.
What we did
We analyzed the request history, identified rare scenarios, and generated synthetic LLM data: “request — reference answer” pairs with variations in wording, tone, and language.
Each pair was run through automatic rules and checked against the company's regulations; disputed ones went through sampled manual acceptance; we kept about two-thirds of the generated volume.
What changed
On a held-out sample of real requests, the share of correct answers grew from 61% to 89%, and the refusal rate fell from 18% to 4%.
Coverage of rare scenarios in the training set grew from a few to hundreds of examples per topic, and manual annotation volume decreased by about threefold — specialists review disputed cases instead of writing examples from scratch.
We calculate quality metrics on the same set as before fine-tuning, so the before-and-after comparison remains valid.
How does synthetic data differ from annotation of real logs?
Annotation of real logs relies on fact: these are genuine formulations, live noise, the real class distribution.
The problem is different — a rare scenario rarely makes it into the logs, and on borderline examples annotators interpret the instruction differently, so label consistency drops. As a result, the class for which the model is fine-tuned ends up represented by a dozen examples.
Synthetic data is built in reverse order: first we describe the taxonomy of scenarios and the rules for acceptable answers, then we generate examples according to schemas and through a language model.
Next comes a mandatory validation loop: deduplication, filtering out template repetitions, sensitive data leakage checks, and evaluation by a judge model. This gives even coverage of classes that are almost absent from the logs.
| Criterion | Synthetic data | Annotation of real logs |
|---|---|---|
| Coverage of rare scenarios | Defined in advance by the schema | Depends on what made it into the logs |
| Label consistency | Uniform, defined by rules | Drops on borderline examples |
| Scaling | Limited by the generator and filters | Bottlenecked by annotator hours |
| Risk | The generator repeats its templates | Bias toward frequent scenarios, drift in interpretations |
In practice, a mixed sample wins. Synthetic data adds coverage and class balance, while real logs keep an anchor in live language and the real distribution — together they remove both the skew toward rare scenarios and the artificiality of wording.
We select the proportion by class: where there are few factual examples, the share of synthetic data is higher; where there are enough, we keep only log annotation.
At the same time, we assemble the control set exclusively from real logs; otherwise the metrics measure the quality of the generator, not of the model on production data.
Such a split makes it visible where synthesis actually added a class and where it merely diluted the sample with similar examples.
Frequently asked questions about data, privacy, and work acceptance
Before generation starts, the same questions come up: what goes into the model, where the boundary is between real documents and synthetic data, and what counts as acceptance. We answer directly.
Data privacy is handled by the workflow: generation runs in your environment or on an isolated environment, documents do not leave it, and the output is synthetic records with a controlled distribution.
Do real documents go into generation?
As a source of structure and terminology — yes; verbatim — no. Field schemas and statistics are extracted from the corpus, and the output examples do not reconstruct real clients. Before handover, we run a leakage check: we search for fragments matching the source corpus.
Is your annotation needed?
Usually no: labels are synthesized together with examples and are known in advance. Your annotation is needed for the control sample — a small share of real examples on which we check that the model has not overfit to synthetic data.
How does work acceptance proceed?
On your validation set: share of correct answers, robustness to paraphrases, and absence of degradation on real data. We take metrics on the same set before and after fine-tuning.
What does post-handover support include?
We deliver generator configurations, validation scripts, and documentation — so that retraining can be launched without us. After that we provide support: we update the set when the real data distribution shifts.
Let's discuss the task and come back with an estimate and plan
To estimate, we do not need a ready dataset — we need your domain and an understanding of which model errors are most costly.
In the first conversation, you describe the subject area, show 5–10 real requests and answers, and mark the places where the current model makes mistakes, refuses to answer, or answers too generally.
On our side, we check whether these examples contain a signal for generation: entity types, terminology, output formats, constraints, and prohibited wording — without this, synthetic LLM data comes out smooth but useless for fine-tuning.
Then the work proceeds step by step, and each step ends with an artifact that can be checked:
- Domain analysis — we compile a list of scenarios the model must handle and, separately, those where it must refuse.
- Generation schema — we fix what examples are assembled from: rules, templates, real fragments, a topic tree, and a complexity distribution.
- Pilot stage — we run a limited volume, look at the share of examples that passed quality checks, and at the gain on your test questions.
- Timeline estimate — we tie the scope of work to the acceptance metric, not to “making it beautiful”: how many examples, of what quality, with what validation.
- Work plan — stages, approval points, and what is required from you: access to examples, an expert for 2–3 one-hour sessions, and answers on disputed cases.
- Handover — generation scenarios, filtering rules, a metrics report, and a procedure by which you can grow the set yourselves.
What we need on our side: a domain expert contact, a sample of real requests, and clarity on what result is considered good. Part of this usually already exists internally — enough to start.
Describe the task in two paragraphs and attach data examples — we will come back with a timeline estimate, work plan, and boundaries of the pilot stage. If there are still few examples, we will suggest how to assemble a minimal set to start.
