The data problem

Fine-tuning needs examples. Thousands of them, in a consistent format.

For most business subjects, those examples do not exist in any collectable form.

Three reasons:

Confidentiality. Real audit findings, client contracts, support tickets — you cannot train on those, and often you cannot legally keep them for that purpose.

Volume. Even where real examples exist, there are rarely enough. A company might have a few hundred nonconformity reports. Fine-tuning wants far more.

Consistency. Real data is written by different people in different ways. Training on it teaches the model that inconsistency.

Synthetic data solves all three — with a cost, covered below.

How it works

Start from a knowledge base. A structured set of source material — standards, rules, definitions, terminology.

Generate examples from it. Each one an input and the output you want.

At volume. Hundreds of thousands, covering every combination systematically.

AboutKnowledge’s published quality models used exactly this approach. Both model cards state that the data was generated synthetically from a compact ISO and quality-management knowledge base.

One million records for the compliance analyzer. Five hundred thousand for the quality Q&A model, drawn from a million-record set.

What it gives you

Coverage. You can generate examples for every standard, every clause, every verdict type — rather than whatever happened to be available.

AboutKnowledge’s dataset covers ISO 9001, 14001, 45001, 27001, 13485 and 50001, plus IATF 16949 and AS9100D, along with PDCA, CAPA, 8D, 5 Whys, FMEA, SPC, MSA, 5S, Lean and Six Sigma.

No real collection would cover that evenly. Some standards would be over-represented and some barely present.

Consistency. Every example follows the same format, which is what teaches the model to produce that format reliably.

No confidentiality problem. Nothing in the training data belongs to a client.

Volume on demand. If you need more, generate more.

The cost

The limitation is real and it should be stated plainly.

Both AboutKnowledge model cards say it: synthetic data can contain occasional grammar artifacts or mix standards in generic answers.

What that means in practice:

Small errors get learned. If the generation produced a slightly wrong phrasing in some examples, the model learns that phrasing.

Generic answers can blur. Asked something that spans standards, the model may produce an answer mixing requirements that belong to different ones.

It is only as good as the knowledge base. An error in the source is reproduced across every example generated from it.

Which is why both model cards say the same thing: always verify against the official standard text for compliance decisions.

Making it good

Five things that determine quality.

A correct knowledge base. Everything derives from it. This is where the effort belongs — an error here appears in a million examples.

Realistic inputs. If real users write short informal statements, the training inputs should look like that. Training on polished formal input produces a model that struggles with how people actually write.

Consistent output structure. Every example the same shape. This is what the model learns.

Deliberate variety. Different phrasings, different lengths, different edge cases. Generation that produces near-identical examples teaches the model a narrow pattern.

Review a sample by hand. Read a few hundred. You will find systematic errors, and finding them before training is much cheaper than after.

That last point is the one people skip, and it is the cheapest quality control available.

Where the volume comes from

A useful thing to notice in these two models:

The quality Q&A model used 500,000 records over 10,000 steps.

The compliance analyzer used 1,000,000 records over 3,000 steps.

Different balances of data and training. More data with fewer passes, or less data with more passes.

Both reached similar training loss — 0.1618 and 0.1742.

Which suggests there is no single right answer, and that the balance depends on the task and the model size.

And a broader point: having a million records available meant the option existed to use half. Generating more than you need is cheap, and it gives you room to experiment.

When synthetic data is the wrong answer

When real data exists at volume and you can use it. Real examples beat generated ones, if you have enough and they are consistent.

When the subject has no clear source of truth. Synthetic generation needs something to generate from. A subject that is genuinely a matter of judgement rather than documented rules does not have that.

When the errors would be dangerous. For anything where a subtly wrong answer causes real harm, the artifacts synthetic data introduces are a serious concern rather than an acceptable trade.

Which is exactly why both of these model cards limit their models to drafting and triage, and say so.

The short version

Synthetic data makes fine-tuning possible when real examples are confidential, too few, or too inconsistent.

It buys coverage and consistency. It costs you the errors in your source, reproduced across everything.

Put the effort into the knowledge base, make the inputs look like real ones, and read a sample by hand before training.

And publish the limitation. Both of these models say plainly that synthetic data can produce artifacts and that compliance decisions need verifying against the official text. That is the honest position.