If someone told me they had a fine-tuning project going well, my first question would be: “How’s your dataset?” Not “which model?” Not “which technique?” The dataset. Because after building and studying a lot of these projects, I’ve come to believe something that I want to hand to you straight: your fine-tuning dataset is more important than your model choice, your technique, and your hyperparameters put together. Get the data right and mediocre methods produce excellent results. Get it wrong and no clever training method will save you.
This article is about how to build a fine-tuning dataset that actually works. It’s less glamorous than the model architectures we’ll get to next, and honestly, it’s where I’d rather you spent most of your energy.
What “good data” means for fine-tuning
Fine-tuning teaches by imitation. Every example in your dataset is telling the model, “when you see something like this input, respond like this output.” So your dataset is, quite literally, a demonstration of the behaviour you want. If your demonstrations are inconsistent, incomplete, or off-target, the model will faithfully learn to be inconsistent, incomplete, or off-target too.
Three qualities matter most, and they’re worth memorising because they’ll come up in every fine-tuning decision you make. Figure 1 lays them out.
Figure 1: A good fine-tuning dataset is high quality (each example is actually good), consistent (they all demonstrate the same behaviour in the same way), and covers the variety of inputs your model will face in real use.
Quality. Every example should be a good demonstration of what you want. The output should be correct, on-brand, and in the format you want, without exceptions. This matters more than you’d think, because the model will faithfully copy whatever’s in your data, including the mistakes. A dataset of a thousand mediocre examples is worse than a dataset of two hundred excellent ones.
Consistency. The examples should demonstrate the same behaviour in the same way. If half your examples use bullet points and half use paragraphs, the model learns to be inconsistent. If some of your customer-service examples are warm and some are terse, it will produce a confused mix of both. Pick one way, do it every time, and the model will pick it up cleanly.
Coverage. The examples should span the range of inputs your model will actually see in the wild. Common cases, edge cases, tricky cases, short inputs, long inputs, the whole distribution. A dataset that only covers happy-path inputs produces a model that only handles happy-path inputs.
Quality, consistency, coverage. Those are the three legs of a good dataset. If any one is missing, the model wobbles.
How much data do you actually need?
This is the second most-asked question after “should I fine-tune at all,” and the answer is encouraging: less than you probably think, if the quality is high. As a rough guide:
- A few hundred examples can be enough for narrow, well-defined tasks (a specific classification, a particular format, a consistent tone).
- A thousand or few thousand is a common sweet spot for style, format, or persona adjustments.
- Tens of thousands is more of an “if you have a very hard, very varied task” territory.
Don’t let anyone bully you into thinking you need hundreds of thousands of examples to start. What matters is that the examples you do have are good and cover your real use cases. I’d rather have 500 excellent examples than 50,000 sloppy ones every time.
The one exception: if your task is highly varied (many different sub-tasks, formats, or styles), you’ll need enough coverage of each. In practice this often means more data than a single-purpose task would need.
Where the examples come from
Practical sources for training examples, in rough order of quality:
- Human-written or human-corrected examples of the real thing. Actual support replies from your best agents. Actual well-edited pieces from your writers. If you have historical data that already shows the behaviour you want, this is gold. Curate the good ones and clean them up.
- Human-corrected outputs from a strong general model. Have a capable model draft, then have humans edit its output into what you want. You get scale from the model and quality from the humans. This is often the most practical route in real projects.
- Synthetic examples generated by a strong general model. Prompt a top-tier model to generate examples of your target behaviour, sometimes called “distillation.” Cheaper but riskier: quality is only as good as the prompting, and you have to spot-check aggressively. Use with care.
Whatever the source, someone with real judgement about your task should look at (and preferably clean up) every example. This is the unglamorous work that decides whether your fine-tune sings or flops.
The format: input and output pairs
You met the shape in the last article, but let’s make it more concrete. Each training example is an input paired with the ideal output. The exact schema varies by tool (some want conversation-style chat messages, others prompt-completion pairs), but the shape is always this pair.
Here’s a small example set for a “polite support reply” task:
[
{"input": "The website is completely broken and I've lost work!",
"output": "I'm really sorry, that sounds frustrating. Please let me know the last thing you were doing before the issue, and I'll help you recover what you can right away."},
{"input": "Do you offer student discounts?",
"output": "Yes, we do! Students with a valid academic email can activate a 30% discount on the Pricing page under 'Student Plans'."},
{"input": "cancel",
"output": "No problem, I can help you cancel. Could you confirm the email address on your account so I can find it? Cancellation takes effect at the end of the current billing cycle."}
]Notice a few things I did deliberately. Every response starts with a human acknowledgement. Every response is complete (no half answers). The tone stays warm and consistent across an angry customer, a curious one, and a curt one. That consistency is what the model will copy.
What to do about system prompts and context
An easy oversight: fine-tune with the same shape of input the model will see in production. If your live app puts a system prompt at the start of every conversation, your training examples should include that system prompt too. If your live app inserts retrieved passages before the user’s question (RAG plus a fine-tuned model, a common combination), your training examples should reflect that structure. The closer your training examples look to real production inputs, the better your fine-tune will generalise. Fine-tune the way you’ll serve.
Practical mistakes worth avoiding
Now the honest checklist of traps I’ve seen wreck otherwise-promising fine-tuning projects.
- Mixing “should” and “does.” Don’t include examples where the output was “how the intern actually did it” if that isn’t the behaviour you want the model to imitate. Every example is a lesson; make it the lesson you want taught.
- Inconsistent formatting or voice. As mentioned above, this quietly poisons the dataset. Do a formatting pass to standardise headings, punctuation, and structure before training.
- Sensitive data left in. Names, emails, internal identifiers, anything you wouldn’t want the model reproducing later. Do a redaction pass. Once it’s in the weights, you can’t un-train it easily.
- Test data mixed into training. Just like the evaluation article in the RAG track warned: hold some examples completely out for testing. If you evaluate on data the model was trained on, you’ll get flattering numbers and a system that fails on real inputs.
- All the tricky cases missing. If your dataset is only easy cases, the model does poorly on hard ones. Deliberately include a few of the tough examples you know real users will send.
Figure 2 rolls this all up as the practical workflow to follow.
Figure 2: A workable workflow. Gather examples from your best sources, clean and standardise them, redact sensitive information, hold out a test set for evaluation, and check for coverage before you train. This unglamorous flow is where most fine-tuning success is actually made.
The one habit that changes everything
If I had to leave you with one habit for dataset preparation, it would be this: read a sample of your dataset yourself, out loud, before you spend a rupee on training. Fifty examples, in order, aloud. You will spot inconsistencies, unclear examples, and voice drift that no automated check will catch. It takes twenty minutes. It saves entire training runs. Do it.
This is the unsexy secret behind the fine-tunes that actually work in production. The people building them aren’t running fancier training loops than everyone else. They’re spending far more time on the data than you’d guess.
Where we go from here
You now have a working sense of what makes a fine-tuning dataset good, how much of it you need, and how to prepare it well. With that foundation, we can go back to how the training itself is done and, importantly, how to do it efficiently.
Because there’s a practical problem we’ve been quietly ducking: full fine-tuning adjusts every weight in a giant model, which is expensive and hardware-hungry. A set of techniques can adjust only a tiny sliver of weights while getting most of the benefit, and that’s what has made fine-tuning practical for most people. That’s next.
Next in the series: Full Fine-Tuning vs LoRA & QLoRA, the parameter-efficient techniques that made fine-tuning practical.